COBOLもJavaももう“塩漬け”にしなくていい？ AIを制御し「数年を数日まで」短縮できるレガシー刷新の今：Claude Codeベース「3つのAIエージェント」で高速化

老朽化し、仕様を知る担当者も退職するなどして塩漬けにされる「レガシーシステム」。調査だけで億単位のコストを要し、ビジネス変革の足かせになりかねない難題にAI駆動開発でどうアプローチできるのか。Scalarが取り組むAIエージェントを使ったモダナイゼーションについて聞いた。

[遠藤文康，＠IT]

　老朽化やブラックボックス化によって、調査だけでも億単位のコストがかかる――。開発当時の担当者が退職し、仕様を把握している人が不在となったCOBOLシステムなどレガシー化した基幹システムでは、刷新の必要性は分かっていても、継続的なシステム改善が進まないケースが少なくない。企業固有のビジネスロジックが深く組み込まれていれば、影響範囲を把握し切れないまま、下手に手を加えられない状態に陥っているシステムもある。

　独立行政法人情報処理推進機構（IPA）の報告書「DX動向2025」によると（図1）、国内では6割以上の組織がレガシーシステムを抱えている。明確に「レガシーはない」（20％）との回答を除けば、約8割ほどの企業がレガシーシステムを抱えていると見ることができる。

図1　ビジネスの足かせになるレガシーシステムが6割以上の企業に残存（提供：Scalar）

　レガシーシステムを維持し続ける代償は、単なるコスト増大にとどまらない。IT予算の多くがレガシーシステムの維持管理に費やされれば、攻めの新規投資ができず、データ活用などへの取り組みが阻害される。Scalarの代表取締役CEOで、IPAのデジタルアーキテクチャ・デザインセンター（DADC）の専門委員として調査にも携わる深津航氏は、セキュリティのリスクも高まっている点を挙げ、レガシーシステムを塩漬けにし続けることが困難になっている現状を指摘する。

　近年、ライブラリやフレームワークの脆弱（ぜいじゃく）性が発見される頻度は加速度的に高まっており（図2）、中には毎週のように更新が求められるエコシステムも存在する。これに対し、影響範囲の特定に時間がかかるレガシーシステムでは、パッチ適用の検討から実施までに数ヶ月、規模によっては年単位の時間を要することもあり、アップデートのサイクルが脆弱性の発見スピードに追い付かないという構造的な乖離（かいり）が生じている。

　「17年間もの間、手を付けられずにいたシステムが刷新に乗り出す背景にもセキュリティリスクがある」（深津氏）

図2　脆弱性の発見件数が加速（提供：Scalar）

　ランサムウェア（身代金要求型マルウェア）被害で実質的な業務停止が長引くような事案が目立っている昨今では、マルウェア被害があった場合の影響をできる限り小さくとどめる観点も重視され始めている。「モノリシック（一枚岩の）なアーキテクチャでデータベースを1つにしておくのではなく、データベースを分けておきたいという要望もある」（深津氏）

レガシーシステム刷新時の“三重苦”をどう乗り越えるか

　こうしてレガシーシステム刷新を迫る事情がある一方で、AIによってレガシーシステム刷新との向き合い方もまた変わりつつある。

Scalarの代表取締役CEO　深津航氏

　レガシーシステムをマイクロサービスへと移行することで、機能ごとに独立して修正や更新が可能になるものの、そもそも長年積み上げられた重厚長大なシステムを機能ごとに分割するのは容易ではない。深津氏によれば次のような課題がモダナイゼーションを進める際の三重苦となっているが、こうした障壁をAIを活用しつつ乗り越えるアプローチが有効に使われ始めている。

• 1．現行システムを読み解き、把握するのが難しい
  • レガシーシステムの仕様と現状のコードの解析に膨大な時間とコストがかかる
• 2．設計難易度が高い
  • ドメインの切り方と、ドメイン間の連携の設計難易度が高い
• 3．データ整合性の確保が難しい（実装が難しい）
  • マイクロサービス化すると、整合性の担保が難しく、実装の難易度が高くなる

　中規模のシステムでもその調査には120〜200人月、1億〜3億円ほどのコストがかかることに加え、いざマイクロサービス化しようにも、「既存のシステムを加味した上でドメイン駆動設計を行うのは複雑なパズルを解くようなもの」（深津氏）。マイクロサービス化すれば、ドメイン間のデータの整合性を保つ難しさがあり、設計と実装時の難易度が高い。

「Claude Code」で構築したAIエージェントで劇的に生産性向上

　こうしたレガシーシステム刷新の前提を根底から変え始めているのがAIだ。Scalarでは「Claude Code」で独自に構築したAIエージェントを活用することで、従来は年単位を要していた調査工程を、数日単位まで圧縮し得るアプローチを推進している。

　以降では、開発生産性を劇的に高めるためにどのような工夫が行われているのか、AIエージェントをどのような設計・方法で適切に制御するのか、レガシーシステムからの設計変更のハードルをどう乗り越えているのかなどを詳しく解説する。

「数年がかり」を「数日」に短縮できるレガシー刷新の新アプローチ

　その中核を担うのがClaude Codeをベースに構築した以下3つのAIエージェントで、これはGitHubでも公開されている。

• リファクタリングエージェント：現状分析・評価
• アーキテクチャ設計エージェント：DDD（ドメイン駆動設計）再設計・コード生成
• コーディングエージェント：実装計画・レビュー

　なおScalarでは、Claude Codeのコンテキストウィンドウが100万トークンになったことを受けて、これらのAIエージェントを統合した「Nexus Architect」も公開しており、今後はこちらをメンテナンスしていく予定だという。

　AIエージェントにはレガシーシステムの現状分析やDDD再設計、実装計画などマイクロサービス化を進めるための各種「スキル」が組み込まれている。エージェントを実行すると、ソースコードやドキュメントを解析し、現行システムの構造や機能を可視化した上で、設計書として再整理する。技術負債や密結合している箇所、改修時のリスクなども洗い出し、それを基にマイクロサービス化や移行のロードマップを作成できる仕掛けになっている。

　リファクタリングエージェントによる解析では、そのコード群にどのような機能が含まれているのか、また本来同じ機能としてまとまっているべき処理がまとめられているのかなどをレポートする。本来まとめて変更されるべき機能が整理されていれば改修範囲を限定しやすいが、そうでない場合は関係ない機能まで修正やテストが必要になる、といったことを評価できる。

「MMI」でどこから改善すべきかを可視化

　ここではシステムの変更しやすさを定量評価する「Modularity Maturity Index」（MMI）も活用している。機能の分割状況や結合の強さ、独立性などをモジュールごとに数値化し、どこが技術負債になっているのか、どこから改善すべきかを可視化する仕組みだ。

　「ある顧客システムでは約70％が類似コードだったケースもあった」（深津氏）。例えば各システムごとに認証・認可機能を個別実装する結果、ほぼ同じコードが複数箇所に散在しているなどだ。そうなると一方でパッチを適用しても一方では未修正のまま残るという具合で無駄やリスクが生じる。

　これについてScalarでは、図3にあるようにコンテナオーケストレーションツール「Kubernetes」上にインフラを集約し、その上で各機能をAPIとして整理する共通基盤への移行を推奨している。データアクセスについてはScalarが提供する分散トランザクションマネジャー「ScalarDB」で、またAPI管理については「Kong」で一元化する。これにより機能を追加する際もAPIを増やすだけで安全に拡張ができるし、パッチを各システムに個々に充てずに済む。

図3　マイクロサービスを運用する基盤の特徴（提供：Scalar）

　2026年4月には脆弱性の発見、パッチの作成、テストを自動的に実行する仕組みを作成することにも成功しているという。

図4　脆弱性チェック、パッチの作成、テストを自動化したフロー（提供：Scalar）

　なおAIエージェントで開発を進めると、直してはいけない箇所を直してしまうなど、意図せぬ変更が発生するリスクがある。それを前提にすると、AIを安全に使うための構造としてマイクロサービスの利点が生きてくる。マイクロサービスにして独立させることで指定したところだけを修正するようになる。コンテキストも小さくなるため、コード全体が破壊されるリスクが小さくなり、かつマイクロサービスごとに同時に開発をするので高速に進められる効果もある。

リリースサイクルを短くしつつ品質を安定化

　AI駆動開発の特徴として深津氏は、「要件定義からリリースまでが数カ月に1回や年に1回程度だったものが、数日に1回程度のリリースサイクルになる」と話す。そうなるとリリースごとにインフラを作るのでは間に合わないため、安全に早くリリースするためのDevSecOpsや、コスト配布のためのFinOpsの仕組みが必要になる。

図5　AI駆動開発ではリリースサイクルが短くなる（提供：Scalar）

　そうした課題に対し、ScalarではAI駆動開発を前提としたコントロールプレーンを構築している。具体的には、OSS（オープンソースソフトウェア）をベースに、資産管理からデプロイまでを1つのパイプラインとして統合。例えば、デプロイには「Argo CD」、資産管理には「Backstage」を採用。さらに、仮想マシンを自動的に最適化する「Karpenter」や、サービス単位のコストを可視化する「OpenCost」「Kubecost」などのツールを組み合わせ、安全かつ低コストにリリースを繰り返せる環境を整えている。

　GitLabとMCP（Model Context Protocol）サーバを連携させることで、AIエージェント自身が開発イシューを自動生成し、破壊テストやスケールテストまでを自律的に実行する仕組みまでも構築している。

図6　AI駆動開発のためのマイクロサービスアーキテクチャ基盤（提供：Scalar）

　「AIによって開発速度が飛躍的に高まるからこそ、インフラや運用の側も、それと同等のスピードで自動化されていなければ、全体の運用は破綻してしまう」と深津氏はその意図を強調する。

AIの暴走やコストを制御する共通基盤

　API管理にはKongのAPIゲートウェイを利用する。レートリミットやトレーシング用のプラグインなどを活用し、過剰なAPI呼び出しの抑制や、マイクロサービス間の通信を可視化する。

Kong　川村修平氏

　Kongでポストセールスエンジニアを務める川村修平氏は「AIエージェントが自律的に動く領域が増えるほど、消費するトークン数が増えていきがちなので、レートリミットをかける必要が出てくる」と説明する。

　こうしたAPIゲートウェイによる統制は、例えば市民開発のような形で事業部をまたいで開発が進むケースでも特に必要になる。「トークン消費量を一定に抑制する上で、またテクニカルスキルの程度によってセキュリティリスクへの影響が変わる点を考慮しても、APIゲートウェイのような中央集権的なレイヤーで最低限のガードレールを引く必要がある」（川村氏）。加えて、「APIやデータなどの資産をポータルのような形で共有化して、開発者やAIエージェントを作る人が、そこを見れば開発をスタートできるという状態を作ることも大事な側面」だ。

　ScalarではKong傘下になった「OpenMeter」を利用し、API単位でどれだけ呼び出され、どの程度コストが発生しているのかを可視化したり、コストを配賦したりする仕組みの整備も進めているという。基盤を統合することで、どの部署がどれだけリソースを消費したのか、コストのアロケーション（配分）を実施する必要性も出てくるためだ。

データアクセスの整合性を確保

　一方で、複数のマイクロサービスにまたがるトランザクションの整合性を保つことも重要になる。その役割を担うのがScalarDBだ。例えばRDBMS（リレーショナルデータベース管理システム）やNoSQLなど分散した異種のデータベースのアクセスを統合管理し、複数システム間で整合性を保つためのレイヤーとして機能する。AIエージェントが許可されていないデータへアクセスしようとした場合には、ScalarDB側の権限制御によってブロックできる。

　RAG（検索拡張生成）を構築する機能や、複数のデータベースにまたがったアクセス制御（認証・認可）、通信経路の暗号化、さらには障害発生時の自動リカバリーなどにも対応している。

AIを“制御可能な形”で開発プロセスへ組み込む

　AIを“制御可能な形”で開発プロセスへ組み込む工夫も重要になる。例えば「AIに文章だけで評価を任せると安易な回答に逃げてハルシネーションが起きやすくなる」（深津氏）ので、関数をどう調査すべきかについての評価基準を計算式として与えて調査を実行させている。また処理内容によっては、Pythonコードでスキャンをかけ、トークン消費を抑える工夫もしている。

図7　Claude Codeでのrulesの記述例（提供：Scalar）

　深津氏は「ハルシネーションは頭が良いモデルほどユーザーが求めるものに良い回答を出そうとするので起きやすくなる」と言い、そのため高度な判断が必要ない単純作業などでは、あえてClaudeの最上位よりも軽量なモデルである「Haiku」や「Sonnet」に実行させる切り替えも実施している。

　開発サイクルが加速し、生成されるプルリクエストが膨大になる中で、レビューにおいてはまずエージェントによるレビューを実施した上で、その結果を基に正しい書き方になっているかどうかを見ている。

　SAST（静的解析）やDAST（動的解析）によるセキュリティチェックではもはや人間よりもAIの方が正確で、実際、外部のセキュリティ監査では「1件も見つからずセキュリティ監査会社が根を上げている状態」（深津氏）

　むしろ「計画フェーズの方を見なくてはならない」と深津氏は語る。最初の開発準備工程においては、まずAIエージェントがハルシネーションを起こさずに正しくコードを書けるような状態を作ることを1カ月程度かけて実施する。

図8　AI駆動開発の生産性を向上させるプロセス（提供：Scalar）

部品単位で修正

　一般的なコーディングエージェントとの違いは、Scalarではあらかじめパターンごとに部品化し、それをAIエージェントのスキルとして組み込んでいる点にある。巨大で複雑な対象を処理しようとすると思いも寄らない変更が生じやすくなるので、対象をあらかじめ細分化しておくことで、変更を的確に反映できるようにする。

図9　再利用性が高い小さなサービス群を構成する（提供：Scalar）

　実際には「対象の部品をコピーし、『ここをこう直しなさい』というように音声で指示を与えていく」イメージだ。複雑な画面全体に対して音声で的確に修正指示を出すのは難しいので、特定の部品だけに範囲を絞ることが有効。UIにしてもAPIにしてもそうした部品化によって全体を組み上げていく。こうした手法は米国では「Compound Engineering」と呼ばれている。

AIで作り直した方が早いケースも

　Scalarでは2025年ごろから、AI駆動開発によるレガシーモダナイゼーションに本格的に取り組み始めた。それ以前は自分で書いた方が早い場面も多かったというが、AI側の進化もあり、また、プロジェクトチーム内で繰り返し発生するミスを減らす意味でも、パターン化できるものはAIに任せることにした。当初はハルシネーションやさまざまなミスがあったものの、そうした事象は「現在ではほぼゼロ」になっているそうだ。

図10　AI駆動開発を選択した経緯（提供：Scalar）

　もっともレガシーモダナイゼーションといっても、COBOLシステムのモダナイズからSolarisサーバのハードウェア保守期限切れに伴う移行、IBM Z上で動くアセンブラ資産の刷新、長年の改修によって複雑化したJavaシステムの再設計など、幅広い。

　AI駆動開発に関しても難易度やアプローチは異なり、深津氏は例えばCOBOLはビジネスロジックが書かれているのでAIが理解しやすく「AI駆動開発との相性が良い」と話す。一方で、過去にCOBOLからJavaへ自動変換されたシステムなどは、逆に難易度が高いケースもある。変換ツールによってビジネスルールが崩れた状態になっていて、Javaコードだけでは何をやっているのか分からないことがあるからだ。「結局、元のCOBOLを見ないと理解できないケースも多い」（深津氏）。また、ローコード／ノーコードツールで構築されたシステムについても、「現在はAIで一から作り直した方が早いケースも増えている」と指摘する。

図11　実プロジェクトでのAI適用領域（提供：Scalar）

マイクロサービス化によるモダナイゼーションはビジネスドメインで考える

　マイクロサービス化に関して深津氏は「ビジネスドメイン側を見る必要がある」と指摘する。実装の難易度やメンテナンスのしやすさなどテクノロジーサイドで判断するのではなく、重要なのはどの組織単位で意思決定ができるか。要は「会議の数を何回減らせるか」。例えばポイント機能だけを変更したくても、決済機能とポイント機能が密結合していれば、決済側への影響に関して会議が必要になる。そうなるとAIで作るスピード感を生かし切れないので、マイクロサービス化では「そのビジネスの組織単位の中での意思決定する人に対して1つのドメインを割り当てる」イメージになる。

　川村氏も「特定機能だけを変更したいのに、モノリスでは全体をビルドし直して再デプロイしなければならず、別機能のリリースに引っ張られてしまうこともある」と話す。また、認証系のように高負荷になりやすい機能がシステム全体のリソース設計へ影響を及ぼすケースもあり、「機能ごとの負荷特性に応じて個別に最適化できる点も、マイクロサービス化のメリットだ」と指摘する。

　もっとも、ドメイン分割やAPI設計には一定の難易度があり、分散システム化による複雑さが生じることもあるし、マイクロサービスは銀の弾丸ではない。一方で、本稿でも紹介したように、AI駆動開発によってレガシーモダナイゼーションの現実性が大きく変わり始めているのも事実だ。

---

　調査だけでも数億円、数年がかりの現実を前に「やりたくても手を付けられなかった」レガシーシステムの大規模な刷新も、AI駆動開発によってやり方次第で着手できるようになってきた。もちろん計画フェーズの設計や、仮にマイクロサービス化をする場合は設計・運用の難易度など越えるべきハードルはあるが、少なくとも「当時の担当者がいないから手が付けられない」「刷新の必要性は感じているが、現状把握だけで数年がかかる」といった、塩漬け状態を維持するための理由が“一昔前の言い訳”と捉えられてしまう日はすでに来ていると言えるだろう。