NTT は2026年10月23日、長く使っているシステムの仕様書・設計書・コード・テスト の対応関係を自動で整理し、ずれや記載漏れ、足りないテストを見つけて補う技術を確立したと発表しました。改修を重ねたシステムでは、設計書と実際のコードが合わなくなっていることが多く、生成AI に改修を手伝わせようとしても、AIがシステムを正しく理解できません。NTTは、こうした既存の資産を「AIが理解・活用できる状態(AI-Ready)」に変える技術だとしています。
情シス や社内SE にとって、古い業務システムの改修は、設計書が当てにならない、どこを直すと何に響くか分からない、という悩みと一緒にあります。発表は研究の成果で、製品として使える時期は書かれていませんが、AIで改修を進める前に何をそろえておくべきかの手がかりになります。
NTTの10月23日の発表のポイント 出典: NTT「"人が読む"既存ソフトウェア資産を、"AIが読む"開発資産へ」 (引用)
2つの技術
技術
していること
トレーサビリティ解析技術
会議の記録、仕様書、設計書、コード、テストのように散らばった成果物を、機能ごとのまとまりに分けて対応づける。要求工学のISOなどの国際標準をもとに構造を作り、工程の間のずれや記載漏れを見つけて補う
網羅的なテスト自動生成技術
ISOの品質特性をもとに、どの機能をどの観点で確かめるべきかを整理した「テスト観点空間」を作る。今あるテストをそこに対応づけ、確かめられていない観点のテストを補う
NTTは、ソフトウェアの開発の約6割は、既存のシステムの改修・保守・再開発の「追加開発」だとしています(『ソフトウェア開発分析データ集2022』による)。生成AIの活用は新しく作る開発が中心で、追加開発への活用が課題だという見方です。
予備実験の結果
予備実験は、NTTのJavaのフレームワーク「Macchinetta Framework」のサンプルアプリ「ATRS」(コードは約3.2万行)で行いました。
設計書に埋め込んだ誤りの検出の結果(対象41件) 出典: NTT「"人が読む"既存ソフトウェア資産を、"AIが読む"開発資産へ」 (引用)
確かめたこと
結果
設計書にわざと入れた誤り41件(仕様書やコードとの矛盾、抜け漏れなど)を見つけられるか
提案の手法は33件(80%)。従来の手法(RAG)は11件(27%)
埋め込んだバグ6件を、補ったテストで見つけられるか
4件(67%)。さらに、もともとあった潜在バグ3件を見つけた(入力の確かめやエラーのメッセージのテストが足りない箇所)
仕様書などから生成AIで直接テストを作った場合
上の潜在バグは、どれも見つけられなかった
NTTは、レビューでの欠陥の検出率が平均68%だったとする既存の研究を挙げつつ、評価の対象や条件が違うため単純には比べられないとしています。実験はサンプルアプリでの予備のもので、規模や性質の違う実際のシステムでの評価はこれからです。
これから
NTTは、いろいろな規模・特性のシステムへの適用の評価を進め、対象とする成果物やプログラミング言語、暗黙知の抽出、品質の観点とテストの技法を広げるとしています。実際の開発・保守の案件に当てて、システムの理解から影響の範囲の特定、改修、テストの生成と実行までを、生成AIと組んで通しで行う有効性を確かめる予定です。成果は、2026年11月18日〜25日のNTT R&D FORUM 2026で展示します。