NTT、既存ソフトの文書とコードをAIが使える開発資産へ変換

ニュースの要点

NTT株式会社は2026年10月23日、既存システムの仕様書、設計書、プログラム、テストの対応関係を整理し、AIが理解・活用できる開発資産へ変換する技術を確立したと発表しました。文書とコードの不整合を検出・補完する技術と、不足するテストを自動生成する技術を組み合わせます。

サンプルアプリを使った予備実験では、設計書に意図的に埋め込んだ41件の誤りのうち33件を検出しました。NTTが比較した従来手法は11件でした。別のテスト評価では、意図的に埋め込んだ6件のバグのうち4件と、既存の潜在バグ3件を検出したとしています。

長期運用で文書と実装がずれ、改修時の影響確認に手間がかかることが開発の背景です。今後は実際の開発・保守案件で有効性を検証します。商用提供の時期や料金は発表されていません。

ニュース出典: NTT「"人が読む"既存ソフトウェア資産を、"AIが読む"開発資産へ ～ドキュメントとコードの不整合や不十分なテストを自動で補完し、AI-Native開発※1への転換を加速～」（2026年10月23日）

イノベーション総研の考察

既存システムにAIを導入する際、書類を大量に読ませても、何が最新の正しい仕様なのかが定まらなければ改修の判断は難しくなります。今回の発表は、コードを生成する速さよりも、その前提となる開発資産の整合性に着目したものと読めます。

文書の検索から、仕様と実装の食い違いを探す工程へ

業務システムは、運用中の仕様変更や例外対応を重ねて使われます。NTTも、長期運用によって設計書とコードが一致しなくなり、どこを直すべきか、ほかの機能に影響しないかの確認が開発者の負担になると説明しています。

同社の技術は、関連文書を検索して回答の参考にするRAGとは異なり、仕様、設計、実装を機能単位で対応づけます。文書量や表現が異なる資料をそろえ、あるべき関係と照合することで不整合を見つける仕組みです。

既存システムのAI改修では、情報を集める作業と、仕様の正しさを確かめる作業を分けて投資を判断します。

新サービスを既存の会員管理や決済基盤へ接続する担当者の方にとっても、これは開発前の論点です。必要な文書が存在することと、現行業務を正しく表していることは同じではありません。仕様の確認費用を見込まずに生成工程だけを効率化しても、後工程で人の確認が増える可能性があります。

80％は41件の予備実験であり、本番品質の保証ではない

今回の検出率80％は、サンプルアプリの設計書に埋め込んだ41件中33件を検出した結果です。従来手法の27％も同じ41件中11件が分母です。幅広い企業システムの全不具合を80％発見した、という意味ではありません。

NTTは、既存研究の人によるレビュー結果とも対象や条件が異なるため単純比較できないと注記しています。別評価の6件中4件というバグ検出と、潜在バグ3件の発見も、不整合検出率とは異なる測定です。これらを足して一つの品質指標にしないことが必要です。

予備実験の検出率を採用する前に、自社の言語・文書・変更履歴で見逃しと誤検出を測ります。

見つからなかった不整合を人が拾えるのか、誤った指摘の確認にどれだけ時間がかかるのかも評価対象になります。検出率が上がっても、確認工数が増えるなら期待した生産性にはつながりません。工数削減率や本番障害の減少は今回公表されておらず、次段階で検証すべき仮説です。

テストの追加と、業務上の正解を決める責任を分ける

もう一つの技術は、既存テストを整理して不足する観点を特定し、異常な入力や境界値、機能の組み合わせなどを補完します。既存資産を捨てて全て作り直すのではなく、何をまだ確認していないかを見えるようにする点に意味があります。

ただし、文書とコードがそろっていても、両方が業務上の誤解を含む場合はあり得ます。機械が整合性を説明できることと、顧客への請求や権限設定などが本来の要件に合うことは、異なる確認です。これは今回の技術の欠陥を指摘する話ではなく、採用側が置くべき責任の境界です。

自動生成したテストの実行結果と、業務責任者が承認する受入条件を別々に残します。

たとえば、新しい料金プランを追加するなら、既存契約の請求が変わらないこと、例外顧客を正しく扱うこと、変更を取り消せることを先に定義します。その条件に生成テストを対応づければ、何を根拠に公開を認めたかが追跡できます。

実案件では整備費用を含めた改修一件当たりの負担を追う

NTTは今後、規模や特性の異なる既存システムへ適用し、対象言語や成果物、暗黙知の補完などを広げる方針です。今回示された技術が多様な現場へ展開できるかは、これからの評価になります。

導入を検討する企業では、一つの限定した改修を選び、従来の方法と比較する設計が考えられます。資料整理、対応関係の構築、人による指摘確認、テスト修正を含めて記録すれば、AIを動かす費用だけでは見えない負担が分かります。

実案件への展開判断は、初期整備と人の確認を含む総工数、見逃し、次回改修での再利用性を合わせて行います。

一度整えた関係が次の変更で更新できなければ、資産は再び古くなります。新規事業のリリース後も保守が続くことを前提に、更新の担当者と費用を置くことが、検証から継続利用へ進む判断材料になります。

まとめ

NTTの発表は、既存システムをAIが扱うための前工程と検証工程を整える取り組みです。予備実験の成果を本番の品質や工数削減と混同せず、整備・確認・更新まで含めた負担を実案件で測ることが、導入判断の要点になります。

関連記事: 仮説検証の進め方 ／ 新規事業の仮説の立て方