AIで既存システムを改修する前に｜名古屋の中小企業が整える3つの土台

既存システムでは「資料・コード・テスト」のずれが壁になる

長く使う業務システムは、改修を重ねるうちに設計書が古くなったり、変更後のテストが不足したりします。生成AIに資料だけを渡しても、実際の処理や例外条件と食い違えば、提案をそのまま採用できません。

NTTは仕様・設計・コードの関係を構造化し、不整合やテスト不足を見つける技術を紹介しています。予備実験では、サンプルアプリの設計書に入れた誤り41件のうち、提案手法が33件（80％）、従来の関連資料検索型手法（RAG）が11件（27％）を検出しました。これは限定した予備実験の結果で、一般の業務システムで同じ成果を保証するものではありません。AIに改修を任せる前に、資料・実装・テストの関係を人が確認することが出発点です。

名古屋の中小企業が改修前に整えたい3つの土台

1. 仕様書に担当者と更新日を付ける

対象機能の設計書や操作手順を集め、誰が確認した資料か、いつ実装と照らしたかを記録します。資料が見つからない部分や判断が分かれる条件には印を付け、AIにも確定情報として扱わせないようにします。

2. 仕様と実装の対応を小さく確かめる

一度に全システムを読み解くのではなく、問い合わせ受付や帳票出力など、変更予定の一機能を選びます。入力から出力までの流れ、参照データ、例外処理が、資料とコードの両方でどう表現されているかを担当者と確認します。

3. 変更前後に試す条件を決める

通常の入力だけでなく、空欄・上限値・権限の違いなど、失敗時や境界の条件も書き出します。AIが作った修正案やテストは、既存の動作と照らして人がレビューし、実データではなく安全な検証環境で確認してから反映しましょう。

AIに任せる範囲と人が確認する操作の決め方は、前日のAIエージェント運用ルールの記事でも整理しています。

明日できること：変更予定の一機能を一枚に書く

機能名、参照する資料、関連する処理、確認するテスト、最終判断者を一枚にまとめます。まずは既存の手順書やテスト記録を埋め、分からない箇所を担当者へ確認するだけでも、AIを使う前の手戻りを減らせます。

まとめ

AIによる既存システムの改修は、資料・実装・テストの関係が見えるほど安全に検討しやすくなります。まず一機能から現状を照らし合わせ、確認できた範囲で試しましょう。

出典：NTT「人が読む既存ソフトウェア資産を、AIが読む開発資産へ」（2026年10月23日）。数値は同社の予備実験で報告された結果です。