[](https://devin.ai/ja) [](https://devin.ai/ja/blog) # レガシーコードとAI：大規模ERPのコード資産に挑むワークスアプリケーションズのモダナイゼーション戦略 Cognition2026年11月2日13分で読めます ![DevinCon Track A ワークスアプリケーションズ 高島慎氏の講演](https://devin.ai/images/blog/devincon-2026-works-applications-modernization/cover.jpg) 株式会社ワークスアプリケーションズ CTO室 室長 高島 慎\ （DevinCon 2026 Track A「ユースケース／デベロップメント・マイグレーション／レガシーモダナイゼーション」） ## 概要 ワークスアプリケーションズは1996年創業。大手企業向けERP・グループウェアから、中堅・中小企業でも活用できるSaaS製品までを展開し、約2,500社の導入実績を持つ。従業員は国内外で約950名。日本語形態素解析エンジン「Sudachi」をオープンソースとして公開し、累計7200万件超のダウンロードを記録していることでも知られる。 高島慎氏の講演は2部構成だった。前半はDevinの全社導入と運用の裏側、後半は主力ERP製品が抱える大規模なレガシーコードのモダナイゼーションである。冒頭で氏はこう断っている――「これから説明する内容は、モダナイゼーションの完了を報告するものではなく、いままさに取り組んでいる途中経過の報告です」。 ## 導入前の空気：ツールはあるのに、実感がない 1年前、同社の開発者はGitHub CopilotやChatGPT・Codexを利用できる状態にあった。それでも生産性向上の実感は十分ではなかった。当時の課題は3つに整理される。 - コードを書く速度は上がっても、製品仕様の調査速度が上がった気がしない - ローカルAIエージェントは頻繁にコマンド承認を求めるため、結局PCの前に張り付く必要がある。かといって安全にバイパスする仕組みの構築には手間がかかる - 一部の開発者の生産性は上がっているが、そのノウハウが広まらない 2025年8月からDevinの検証を開始し、この3点それぞれに手応えを得た。仕様調査にはAsk Devin、コマンド承認の問題にはクラウド上のサンドボックス、ノウハウ共有にはセッションがクラウド上で共有される仕組み。実際にTeamsプランを契約し、小規模なWebアプリケーション生成タスクで他のローカルAIコーディングエージェントと比較したところ、結果は明快だった。約6時間（人間の確認待ちを含む）に対してDevinは12分。コマンド確認の要求は数十回に対してゼロ。成果物の修正箇所も、比較対象が多数だったのに対しDevinは1箇所だった。 同年11月、経営陣（CEO・CTO）の強いプッシュもあってエンタープライズプランを契約する。高島氏はここでキーノートの内容に触れ、「日本はトップダウンよりボトムアップ、という話がありましたが、弊社の場合はかなりトップダウンでした」と述べた。 ![Devin Teamsプランでの有効性検証（小規模Webアプリケーション生成タスク）](https://devin.ai/images/blog/devincon-2026-works-applications-modernization/teams-plan-test.png) Devin Teamsプランでの有効性検証（小規模Webアプリケーション生成タスク） ![現在のDevin利用状況（2026年7月時点）：国内外およそ470ユーザー](https://devin.ai/images/blog/devincon-2026-works-applications-modernization/usage.png) 現在のDevin利用状況（2026年7月時点）：国内外およそ470ユーザー ## 数字で見る全社展開 3か月の先行検証を経て、2月から社内全体に開放。7月時点の月間アクティブユーザーは471ユーザー、月10回以上利用するユーザーも230名と右肩上がりだ。成果は明確な指標に表れている。 - マージ済みPRに占めるDevin Cloud生成PRの比率：件数ベースで31%、コード行数ベースで45%（7月） - 非開発者（コンサルタント部門）によるAsk Devinの実行回数：月6800回超 - 管理部門でも財務業務・事務業務の補助に利用 運用面で高島氏が高く評価したのが、Devinのオーガニゼーション機能である。同社では権限を階層化して運用しており、CTO室が全社のACU割当量の配分調停を、各部門管理者が部門内のユーザー管理とACU消費のコントロールを、セキュリティ担当部門がセキュリティ施策の承認を担う。利用費用は毎月のACU消費量に応じて各部門に按分負担させており、その結果「必要最低限のコスト意識が醸成され、有効利用につながっている」という。 さらに、Viewer／Developer／Reviewer／Pioneerという4階層のカスタムロールを設定し、資格に応じた機能制御を行っている。7月からはDevin Desktop・CLIも全社展開した。ローカルエージェントである以上セキュリティ上の考慮が増えるため、利用可能モデルの制限、コマンド・拡張機能・MCPの許可リスト方式、そしてリスク理解度確認テストの合格を利用資格に含めるという3つの制限を課した。 モデル選定の基準がユニークだ。Cognitionが公開しているベンチマーク「Frontier Code 1.1」を用い、1タスクあたりの平均コストが3ドル以下かつパレートフロント付近のモデルを選んで開放している。最高スコアのモデルでなくとも十分な精度が得られることが分かっているためだ。 ![AIモデルの選択にはFrontierCode 1.1 Mainベンチマークを利用](https://devin.ai/images/blog/devincon-2026-works-applications-modernization/model-selection.png) AIモデルの選択にはFrontierCode 1.1 Mainベンチマークを利用 管理者視点での要望も率直に語られた。個人単位のACU上限（講演直前にリリースされたという）、Desktop・CLIにおけるプロンプトの収集と公開、そしてDevin Desktop・CLIでの貢献度の算出――「継続的に予算を確保し経営陣が納得するためには、材料として数値が出せると嬉しい」。 ![マージ済みPRに占めるDevin生成PRのシェアの推移](https://devin.ai/images/blog/devincon-2026-works-applications-modernization/pr-share.png) マージ済みPRに占めるDevin生成PRのシェアの推移 ## 巨大なレガシー：何が「レガシー」なのか 後半のテーマは主力ERP製品である。高島氏は『レガシーソフトウェア改善ガイド』が挙げるレガシープロジェクトの4つの性質を引き、そのすべてを満たすと認めた。 - **古い**：2004年に初期バージョンリリース - **大きい**：アプリケーション数約7300、画面数約26000、テーブル数5万以上 - **引き継がれている**：開発メンバーは数多の世代交代を経ている - **ドキュメントが不十分**：すべてのアプリケーションの仕様書が充足しているとは言えない 現行アーキテクチャは、もともとデスクトップ型のクライアントサーバー構成だったものをWeb化したもの。大きな工数を投じて達成したWeb化の後も、従来の開発言語で書かれたフロントエンドサーバー周辺が膨大なレガシーとして残った。ここで氏は明確に釘を刺している。 「言語そのものに問題があるわけではなくて、弊社独自の使い方によって保守上の課題が生まれた、というところがレガシーです」 7300のアプリケーションをコード規模で3クラスに分けた分析結果も示された。1万行未満のクラス1が62%（平均画面数1.5）、1万〜6万行のクラス2が34%（平均画面数3.9）で、ここまでで96%。6万行以上のクラス3は4%だが平均画面数は22に達する。興味深いのは、規模が大きいアプリほど開発者の仕様把握レベルが高いという相関だ。複雑さは活発な顧客要望に応えてきた結果であり、頻繁に改修されるものほど中身が理解されている。この前提が、後述する移行戦略に効いてくる。 問題点は「2026年基準での保守性の低さ」に集約される。AIによる機能追加・修正が困難、開発者の継続確保と教育に課題、テスタビリティとオブザーバビリティの不足。同社は経営レベルでリアーキテクチャを意思決定し、複数年の予算を確保した。 ![ERPを構成する7,300アプリケーションのコード規模別分布（クラス1〜3）](https://devin.ai/images/blog/devincon-2026-works-applications-modernization/app-distribution.png) ERPを構成する7,300アプリケーションのコード規模別分布（クラス1〜3） ## 3つのアプローチと、AIコンバージョンの試行錯誤 モダナイゼーションは3つのアプローチを併走させている。 - **AI利用コンバージョン**：従来型フロントエンド＋JavaベースのアプリをReact＋Javaベースに変換する。Devinを活用。実現性に不確実性は残るが、保守性の課題を広範囲に解決できる - **機械的コンバージョン**：既存のUI部品・ライブラリに1対1対応するものを開発し、決定的なロジックで既存コードを置換する。機械的コンバージョンを専門とする外部ベンダーの力を借りて仕組みを構築中。保守性の課題すべては解決しないが確実性がある - **リライト**：既存ERPの部分モジュールを切り出し、マルチテナントSaaSとして製品化する。コストが大きいため、製品戦略上重要な領域に限定してピンポイントで実施 講演の中心は1つ目のAIコンバージョンである。変更のポイントは従来型フロントエンド＋JavaからReact＋Javaへの変換で、外部仕様は変更しない／データベースのテーブル構造とクエリも変更しない／バッチプログラムも変更しない／アプリケーション単位で段階的に変更してリリースするという「しないこと」を明確に決めて進めている。 手順は、既存コードをいったん仕様書に変換し、その仕様書から移行後のコードを生成するという流れだ。この過程で、実践から得られた解決策が積み上がっている。 - **挙動の統一**：複数アプリ間で挙動を完全に統一できないことが分かったため、統一したい箇所はライブラリ化してアプリ生成時に組み込む形にした - **テストループ**：既存コード1万行以上に複雑度が上がると生成アプリの品質が低下するため、コード生成後にE2Eテストループを回して不具合を修正する - **セッションの分割**：さらに複雑なアプリではテストをスキップするなどの品質劣化が見られ、またE2Eテストループを回すコストも高かったため、実装フェーズとテストフェーズのセッションを分割した(後にさらに細かく分割) - **仕様中心のスキル化**：十分な仕様書を人間が書けば複雑なアプリでもコード生成できると分かったため、その部分を形式化・スキル化する取り組みを進行中 ツール選択も実利的に変化してきた。当初はDevin CloudとClaude Codeを併用（テストループのコスト効率を理由にClaude Codeを利用）していたが、Devin Desktopが同じACUプールで使えるようになり、同等の性能とコスト効率が得られたため現在は移行している。現時点でDevinが担っているのは、既存コードから仕様書を作る部分、仕様書から移行コードを生成する部分、新基盤ライブラリを書く部分である。 現在地は、コンバート処方の確立と新基盤ライブラリの開発という最初のステップで「6合目から7合目」。前者の完了条件は移行対象アプリの96%（クラス2まで）に適用可能な移行資産を構築し、後から参画する移行開発者が利用できる状態にすること。それが終われば量産フェーズに入り、クラス2までは低い手作業割合で、クラス3は手作業割合が高くても移行できることを目指す。 ![まだまだ乗り越える壁があります：現在地とこれから](https://devin.ai/images/blog/devincon-2026-works-applications-modernization/roadmap.png) まだまだ乗り越える壁があります：現在地とこれから ![コンバート手段のアウトライン：既存コード→仕様書群→移行後コード](https://devin.ai/images/blog/devincon-2026-works-applications-modernization/conversion-outline.png) コンバート手段のアウトライン：既存コード→仕様書群→移行後コード ## インサイト：「任せられるか」と「任せていいか」は別の問い パネルディスカッションで高島氏が示した視点は、この講演で最も示唆的な部分かもしれない。AIにどこまで任せられるかという問いに対し、氏はまず「向いていないマイグレーションはあまり想像がつかない」と答えている。GUIアプリケーションのマイグレーションは当初できないだろうと思って始めたが、やってみると相当できることに驚いたという。 そのうえで、こう付け加えた。 「任せられるかという話とは別に、任せるべきかどうかという話もあると思っています。共通基盤のライブラリを作る部分は完全にAIに任せることもきっとできると思うんですけども、それをすべきかと言われると疑問符があって。そこも任せてしまうと、保守フェーズで組織としての保守能力が失われてしまう」 だから同社は、共通基盤のような領域については人間が理解した状態を意図的に残している。品質保証についても同様だ。「お客様が、AIがいいと言ったからいいです、と受け入れてくれるような社会的受容はまだない」という現実認識のもと、最終的な品質保証は人間の仕事として残ると見る。 有識者の巻き込みについては、経営レベルで「腹をくくってマイグレーションする」と決めたことが大きかったと振り返りつつ、それだけでは足りなかったとも語る。なぜこの変更をするのか、メリットは何か、逆に変えられない部分は何か――それらを明記した5万字規模の文書を人間の手で書き、不安を和らげる努力をしたという。Devinの社内浸透が進み、AIに機能追加を任せられる比率が高まるにつれて移行に積極的に関与する人が増え、いまでは組織としての拒否感はかなり薄まったと感じている。 ## まとめ 高島氏の報告は、AI活用の成功事例集ではない。7300ものアプリケーションという規模に対して、何を変えないと決め、どのクラスのアプリまでを自動化の射程に入れ、どこから先を人間の仕事として残すか――その線引きを一つずつ検証で確かめていく作業の記録である。 Frontier Code 1.1を元に利用するAIモデルを選び、ACUを部門按分してコスト意識を醸成し、リスク理解度テストを利用資格に組み込む。そうした運用設計の細かさは、大規模組織でAIを「使わせる」ことの難しさを知る者の手つきだ。そして「任せていいのか」という問いを立て続ける姿勢こそ、モダナイゼーションを完走するための備えなのだろう。 目次 [概要](#概要)[導入前の空気：ツールはあるのに、実感がない](#導入前の空気ツールはあるのに実感がない)[数字で見る全社展開](#数字で見る全社展開)[巨大なレガシー：何が「レガシー」なのか](#巨大なレガシー何がレガシーなのか)[3つのアプローチと、AIコンバージョンの試行錯誤](#3つのアプローチとaiコンバージョンの試行錯誤)[インサイト：「任せられるか」と「任せていいか」は別の問い](#インサイト任せられるかと任せていいかは別の問い)[まとめ](#まとめ)