AI-Readyが必要になるのは、文書と実装がずれるから
新規開発では、AIがコード生成やテスト作成を支援する場面が増えています。一方、長く運用してきたシステムには、会議で決めた意図、要件、設計書、実装、テストが別々の場所に残ります。改修を重ねると、設計書ではAとなっているのにコードはB、コードに追加した例外処理がテストされていない、といったずれが生まれます。
NTTは、ソフトウェア開発の約60%が既存システムの機能追加、保守、再開発だと説明しています。根拠に挙げたのはIPAの「ソフトウェア開発分析データ集2022」です。IPAの公開ページによると、同データ集は5,546プロジェクトの定量データを基にしています。[1][2]
AIにコードだけを読ませても、過去に「なぜそうしたか」は分からない場合があります。反対に文書検索だけでは現在の実装と食い違う説明を正しい前提として拾う恐れがあります。AI-Ready化は資料を一つの検索庫へ入れるだけでなく、機能単位で関係を結び直す考え方です。
二つの技術で、不整合とテスト不足を扱う
発表された仕組みは役割の異なる二つの技術で構成されます。[1]
| 技術 | 入力として扱うもの | 行うこと | 期待される出力 |
|---|---|---|---|
| トレーサビリティ分析 | 会議記録、仕様、設計文書、コード、テスト | 機能単位に分け、開発工程をまたぐ依存関係を推定 | 不整合や記載漏れ、変更影響を追える対応情報 |
| 網羅的テスト自動生成 | 整合した仕様、設計、コード、既存テスト | ISOの品質特性を基にテスト観点を整理し、未確認領域を探す | 境界値、異常系、条件の組み合わせなどを補う実行可能テスト |
トレーサビリティ分析では文書を同じ文字数で機械的に切るのではなく、各記述がどの機能に関係するかを見て分割の細かさを変えます。上流の仕様と下流のコードでは情報量や表現が違うため、要点と粒度をそろえて依存関係を判定するという説明です。
テスト生成では、既存テストがどの機能と品質観点を確認しているかを空間として整理します。正常系だけでなく、異常条件、境界値、複数条件の組み合わせ、機能同士の相互作用を見て、確認されていない領域へテストを足します。生成AIに仕様書から直接テストを書かせる方法と違い、先に観点と対応関係を構造化する点が特徴です。
コード単体の問題を探す静的解析とも対象が異なります。たとえばTechCreateで紹介したGitHub AI ScanとCodeQLは、リポジトリの脆弱性検出と修正が中心です。NTTの研究は要求や設計の意図、コード、テストのずれを工程横断で扱おうとしています。
「80%検出」はどの条件で得られたか
NTTはMacchinetta Frameworkのサンプルアプリ「ATRS」を使って予備実験を行いました。ATRSのコードはGitHubで公開され、Apache-2.0ライセンスを確認できます。NTTの発表では評価対象の規模を約32KSLOCとしています。[1][3]
不整合検出の実験では設計文書へ仕様やコードとの矛盾、情報の欠落など41件の誤りを意図的に埋めました。
| 方法 | 検出数 | 検出率 |
|---|---|---|
| 比較対象のRAG方式 | 11 / 41 | 27% |
| NTTの提案方式 | 33 / 41 | 80% |
80%という数字は検索で関係資料を参照するだけでなく、仕様、設計、コードの期待される関係を構造化して照合した結果です。すべての誤りを見つけたわけではなく、8件は検出できませんでした。NTTは過去研究のソフトウェアレビュー平均68%も挙げていますが、評価対象と条件が異なるため直接比較できないと明記しています。[1]
テスト生成の実験では意図的に埋めた6件のバグのうち4件、67%を検出しました。さらに、入力検証やエラーメッセージのテストが足りない領域で、意図的に埋めていなかった潜在バグを3件見つけたとしています。仕様などから生成AIへ直接テストを作らせた比較方式では、この3件を検出できませんでした。
ここで確認できるのは、サンプルアプリに対する予備的な有効性です。異なる言語、巨大な業務システム、文書品質が低い現場で同じ検出率になるかは未確認です。発表された実績と、今後の見通しを分けて読む必要があります。
導入判断では、製品選定より資産の棚卸しが先
NTTは今後、規模や特性の異なる既存システムで評価し、対応する開発資産とプログラミング言語、暗黙知の抽出、品質観点を広げる方針です。実際の開発・保守案件へ適用し、システム理解から影響分析、修正、テスト生成、実行までの効果を検証するとしています。[1]
| 今確認できること | まだ確認できないこと |
|---|---|
| 二つの技術の仕組み | 商用サービス名と提供開始日 |
| ATRSを使った予備実験の母数と結果 | 自社システムでの検出率と工数削減率 |
| 実案件へ適用する今後の方針 | 対応言語、価格、導入環境、データの取り扱い |
導入を検討する企業は発表を理由にすぐ予算化する段階ではありません。次の順で準備すると、将来この技術や類似製品を評価しやすくなります。
- 変更頻度と障害影響が大きい既存システムを一つ選ぶ。
- 要件、設計、コード、テスト、変更理由がどこにあるか一覧にする。
- 同じ機能について文書と実装が一致するかを少数サンプルで確かめる。
- AIへ渡せない機密情報、個人情報、外部委託先の資産を分ける。
- 不整合の検出率だけでなく、誤検出、見逃し、確認工数を測る。
担当者の仕事もAIが生成した修正をそのまま採用する形にはなりません。どの文書を更新元として扱うか、食い違いを誰が解消するか、生成テストが業務要件を満たすかを判断する役割が残ります。AI-Ready化の価値はAIへ仕事を丸投げすることではなく、改修の根拠を人とAIが追える状態へ戻す点にあります。
まとめ
- NTTのAI-Ready技術は仕様、設計、コード、テストの関係を構造化し、不整合検出と不足テストの生成を組み合わせます。
- 80%は約32KSLOCのサンプルアプリへ意図的に埋めた41件の誤りに対する予備実験で、一般的な商用性能ではありません。
- 企業が今持ち帰れるのは製品の購入判断ではなく、既存資産の所在、更新元となる文書、機密区分、評価指標を先に整える必要があるという点です。
読者のコメント (0)
コメントを残す