壁（1）AIの「できた」は当てにならない

2026年4月、AIエージェントのレガシーコード処理能力を測定するベンチマーク調査が公開されました（※3）。一般的なソフトウェア開発ベンチマークで70％を超える性能を示す最先端のAIモデルでも、レガシーコードの移行成功率は約15％にとどまります。

数字以上に深刻なのは、失敗の構造です。タスクに失敗したケースの97％で、AI自身は「正しく完了した」と判定していました。AIは間違えているのに、それに気づかず報告してしまう。これが「サイレント失敗」です。人間のミスとは性質が微妙に異なる、AI変換で新たに顕在化する品質問題です。

数百万～数千万ステップの移行で、AIが「成功」と報告するコードを人間が一行ずつ検証することは不可能です。

壁（2）AIの「変換率」だけでは、動作や保守性は測れない

AIによる変換技術は急速に進歩しています。しかし、変換後に正しく動作するか、保守性が高いかといった品質の測定・証明方法は、その進歩に追いついていないのが現状です。どのようなアプローチでもこうした検証は不可欠にも関わらず、変換ツールの紹介資料で目立つのは「変換率」や「工数削減率」といった数字です。

変換率の定義はツールによって幅があります。「コンパイルエラーが出なかった」で止まるものもあり、「業務として正しい結果を返すか」まで踏み込むものは多くありません。工数削減率もまた、生産性の指標であって、動作や保守性を測るものではありません。

さらに、変換率だけを頼りに変換を進めると、Javaの設計構造がCOBOL時代のまま残ることもあります。業界で“JaBOL”と俗称されるこの状態は、動きはしても、Javaエコシステムの利点を享受できず、技術的負債の形が変わっただけになりかねません。

図2：COBOLの構造が残るJavaの例

多くの案件が意図した成果に届かないという見通しには、変換精度の不足ではなく、動作と保守性を正確に測り、是正する方法論が変換技術に追いついていない背景があると考えられます。測れないものは早期に是正できず、問題は後工程で顕在化し、やり直しコストや工期遅延に繋がります。

壁（3）AIに入らない30年の暗黙知が、業務の再現を阻む

3つ目の壁は、最も見えにくいところにあります。

20年、30年と稼働してきたCOBOLシステムには、設計書に明文化されていない業務知識が無数に埋め込まれています。多くの場合、設計書の最終更新は10～15年前です。

「この丸め処理は特定の取引先との合意に基づく」「このフラグは年次バッチの例外ケースでのみ意味を持つ」などの背景は、コードにも設計書にも残っていないことが少なくありません。これらが失われれば、変換後のシステムは特定の取引や例外ケースで異なる結果を返します。

AIは「コードに書いてあること」を読み取る能力において人間を上回ります。しかし「なぜそう書かれているのか」「書かれていないが守るべき制約は何か」を推論する能力は限定的です。

我々の取り組み

NTTデータは、COBOLのJava移行において、設計から再構築するリビルドの研究開発を進めています。基盤起因のリスクを短期・低リスクで解消するにはリホストの合理性がありますが、動くJavaにとどまらず長期に保守・発展させられる資産としてのJavaを得るには、設計に立ち返る必要があるためです。

移行時の3つの壁に対しては、下記のノウハウを確立しています。

• サイレント失敗に対しては、変換・検証・修正のサイクルに品質ゲート（ハーネス）を組み込み、変換前後の動作を突き合わせる現新比較を回すことで、AIの誤りを機械的に検知する仕組みを構築しています。
• 変換率だけではなく、機能適合性（変換後のシステムが業務として正しい結果を返すか）や、保守性（COBOLの構造を引き継がない「綺麗なJava」になっているか）を測定の中心に据えています。
• 暗黙知に対しては、業務仕様、データ構造、有識者の知見を統合分析し、「設計コンテキスト」として体系化してからAIに投入することで、暗黙仕様の欠落を減らしています。

これらのノウハウを元に、大規模基幹系システムの実開発の中で、現実的な工数で品質を保ってリビルドを完遂できることを検証中です。

変換の速さを競うのではなく、AI時代の品質問題を解く方法論を確立する。期待した成果を得られない案件が過半を占めるとされる時代に、確実に成果を出す条件はそこにあると考えています。

詳しい方法論は、本日公開のホワイトペーパー「AI-Native時代のモダナイゼーション ― 目指すべき姿と品質保証の考え方（PDF：5.0MB）」で述べています。ご相談は、ページ下リンクからお問い合わせください。