新規開発では生成AIが当たり前に使われ始めているのに、保守中の基幹システムではなぜか進まない。多くの開発現場で起きている状況です。原因はAIの性能ではありません。設計書が実コードと食い違い、テストが足りず、仕様の理由が人の頭にしか残っていないため、AIに渡せる材料が揃っていないのです。

打ち手は、コード・ドキュメント・テスト・ルールファイルの4点を「AIが読める状態」、いわゆるAI-Readyに整えることです。診断チェックリスト、不整合の扱い方、改修前のテストの取り方、ルールファイルの例、段階導入の順番を、現場にそのまま持ち込める形で並べました。

この記事でわかること

  • 既存システムの改修・保守で生成AIが効きにくい3つの原因
  • 「AI-Ready」の具体的な中身と、保守と移行で必要な準備が違う理由
  • 2026年10月に発表されたNTTの技術と、予備実験の数字の正しい読み方
  • 診断チェックリスト、特性テスト、ルールファイル（CLAUDE.md / AGENTS.md）の実践手順
  • 読むだけ、テスト補強、小改修、PRレビュー運用という4段階の導入順

既存システムで生成AIが効かない原因はドキュメント・テスト・暗黙知にある

既存システムは、AIが推測で埋めなければならない空白だらけです。この空白を人が埋め直さない限り、どれだけ高性能なモデルでも改修は安定しません。まず、新規開発との違いと、AI-Readyという言葉の中身を押さえます。

新規開発との違いはAIに渡せる材料の質

新規開発では、仕様もコードもテストも、その場で一緒に作れます。AIは最新の状態を前提に動けます。

既存システムは逆です。長年の改修で、設計書は一度書かれたきり放置されます。コードだけが更新され続け、テストは一部の画面にしか存在しません。そして「この分岐はなぜあるのか」という理由は、退職した担当者の頭の中にしかありません。

AIに「この機能を直して」と頼むと、実コードから推測して、もっともらしい修正が返ってきます。その推測が当たっているか、確かめる手段がない。ここが最大の問題です。

NTTの発表でも、ソフトウェア開発の約6割は既存システムの改修・保守・再開発などの追加開発だと述べられています。出典として示されているのは『ソフトウェア開発分析データ集2022』です。生成AIの効率化が新規開発に偏ってきたため、ここが次の主戦場になる、という整理です。

AI-Readyとは「三者が整合し、AIが辿れる」状態

AI-Readyを一言で言えば、ドキュメント・コード・テストの三者が互いに食い違わず、AIが関係をたどれる状態です。具体的には次の4条件を満たします。

条件満たしていない状態満たした状態
ドキュメントとコードが一致している設計書が3年前のまま現行コードから作り直した仕様がある
動作を確認する手段がある手作業の確認のみコマンド1つで合否が返る
設計の意図が残っている理由を知る人が不在判断理由がADRやPRの記録にある
AI向けの案内がある毎回口頭で説明するルールファイルに規約が書かれている

ADRとは、設計上の判断とその理由を短く残す記録のことです。「なぜそう作ったか」を後から説明できるのは、これがある場合だけです。

NTTの発表は何を示し、何を示していないか

NTTは2026年10月23日、「“人が読む”既存ソフトウェア資産を、“AIが読む”開発資産へ」と題する発表を行いました。詳細はNTTのニュースリリースにあります。

中身は2つの技術です。1つ目は、会議ログ・仕様書・設計書・コード・テストケースの関係を自動で構造化する「トレーサビリティ解析」。2つ目は、整合させた成果物から抜けているテストを洗い出して補う「網羅的テスト自動生成」です。

数字には条件が付きます。対象は Macchinetta Framework のサンプルアプリ「ATRS」（約32 KSLOC）で、発表自身が「予備実験」と明記しています。

  • 設計書に意図的に埋め込んだ41件の誤りのうち、従来手法（RAG）は11件（27%）、提案手法は33件（80%）を検出
  • 埋め込みバグ6件のうち4件（67%）を検出し、別に既存の潜在バグ3件も検出
  • 仕様書等から生成AIで直接テストを作った場合は、上記の既存の潜在バグ3件を検出できなかった

単一のサンプルアプリでの結果です。実用化を目指す段階で、提供開始時期は発表本文に記載がありません。今すぐ買えるサービスではなく、考え方の方向を示した発表と読むのが妥当でしょう。

それでも現場に使える示唆はあります。「仕様書から直接テストを作る」より「コードと整合させた上で観点から補う」ほうが、バグを拾えたという点です。後述する手順は、この考え方を既存のツールだけで実践する形にしてあります。

改修と移行は準備の中身が違う

混同されがちですが、COBOLからJavaへの言語移行（移行）と、仕様変更に伴う機能の追加・修正（改修）は別の課題です。

移行は「同じ入力に同じ出力が出るか」で合否を機械的に判定できます。一方、改修は変更後の期待挙動そのものが新しく、判定基準を先に決める必要があります。

2026年10月にOpenAIがレガシー言語の移行性能を公表し、COBOL移行の成功率が大きく伸びたと報じられました。ただし自己申告の数字で、第三者の再現は確認できていません。移行が得意になったことと、保守の改修が安全になったことは別の話。本記事が扱うのは後者です。

AI-Ready化は診断、不整合の整理、特性テストの順に進める

手順の順番を間違えると、AIが作ったドキュメントやテストの正しさを誰も保証できなくなります。診断で現状を測り、事実の基準を決め、改修前の挙動をテストで固定します。この順です。

現状を測る診断チェックリスト

最初に、対象システムがどの程度AI-Readyかを点検します。全項目を満たす必要はありません。空白がどこにあるかを知るのが目的です。

観点確認すること空白だったときの対処
ビルド・実行新しい環境でコマンドだけで起動できるか手順を README に書き出す
テスト1コマンドで全テストが走り、合否が返るか特性テストを足す（後述）
ドキュメント最終更新日と実コードの対応が追えるかコードから仕様を作り直す
規約命名・例外処理・ログの書き方が明文化されているかルールファイルに書く
意図「なぜ」を残した記録があるか改修のたびにADRかPR説明を残す
機密AIに渡してよいコードの基準があるか社内ガイドラインを先に作る

目安は、前提知識のない担当者が、リポジトリだけを読んで小さな変更を安全に入れられるかどうかです。AIも同じ立場だと考えると、点検の基準が定まります。

食い違いはコードを事実として扱い、文書を直す

設計書とコードが食い違っているとき、基本方針は「現に動いているコードを事実とする」です。本番で動いている挙動が、利用者にとっての実際の仕様だからです。

NTTの発表を報じた記事には、デモの宿泊予約システムの例が出ています。コードは「6カ月先まで検索可能」なのに、ドキュメントは「3カ月先まで」としていた、という食い違いです。こうした差は、新規機能を足す前に解消しておかないと、AIは古い側の記述を信じて修正案を出します。

とはいえ、コードが常に正しいわけではありません。バグが仕様と思われているケースがあるからです。次の手順で仕分けます。

  1. AIにコードを読ませ、機能単位で現行仕様の要約を作らせる
  2. 既存の設計書と突き合わせ、差分を一覧にする
  3. 差分ごとに「コードが正」「文書が正（コードのバグ）」「判断不能」へ分類する
  4. 判断不能は業務担当や仕様に詳しい人に確認し、結果を文書に反映する
  5. 文書に更新日と「コードから再生成した」旨を記録する

2と3の突き合わせはAIに任せられますが、4は人の仕事です。AIが作った文書も、実装との一致を検証するまでは「下書き」にとどまります。ソースから設計書を自動生成する国内サービスも出ていますが、どれも生成物の検証が前提になっています。

改修の前に特性テストで今の挙動を固定する

テスト不足への実務的な答えが、特性テスト（characterization test）です。Michael Feathers が提唱した考え方で、「あるべき挙動」ではなく「現に今こうなる」という挙動をテストとして固定します。

出力が複雑な機能には、ゴールデンマスターと呼ばれる方式が向きます。改修前の出力をスナップショットとして保存し、改修後に差分を比較します。日時やIDのような毎回変わる値は、比較から除外（マスク）しておく必要があります。

進め方は次のとおりです。

  1. 対象機能の入力パターンを決める（正常系、境界値、過去に障害が出た入力）
  2. 改修前のコードで出力を記録し、期待値として保存する
  3. 保存したテストが、改修前のコードで必ず通ることを確認する
  4. 改修を行い、差分が意図した範囲だけに収まることを確認する

ここに落とし穴があります。エージェントに「リファクタリングしてテストも追加して」と頼むと、改修後のコードを記述するテストが書かれます。挙動が壊れていてもテストは通ります。

だから、順番を守ります。テストは必ず改修前のコードに対して先に作り、書く役と直す役は別のセッションに分けます。テストを意図的に壊したとき失敗するか（ミューテーションテスト）まで確認できれば、なお安心です。

この発想は、NTTの結果とも方向が合っています。仕様書等から直接作ったテストでは潜在バグ3件を拾えなかった一方、整合させた成果物と観点から補ったテストは拾えました。ただし予備実験の結果で、理由まではリリースから分かりません。

ルールファイルはコードから読み取れないことだけを短く書く

ルールファイルは、AIに毎回渡す「新しく入った担当者への引き継ぎメモ」です。長く書くほど守られなくなるため、コードを読めば分かることは書きません。

書くことと書かないことの線引き

Claude Code のベストプラクティスは、CLAUDE.md を短く保つよう勧めています。長すぎると指示が無視されるためです。

書くこと書かないこと
コードから推測できないビルド・テストのコマンドコードを読めば分かる説明
既定と異なるコーディング規約詳細なAPI文書
アーキテクチャ上の決定とその理由頻繁に変わる情報
環境の癖、ハマりどころファイル単位の説明

保守システムでは、とくに「ハマりどころ」が効きます。たとえば次のような記述です。

# 概要
受注管理システム（Java 8 / Struts）。改修対象は order モジュール。

# コマンド
- ビルド: ./gradlew build
- 全テスト: ./gradlew test （約8分。変更範囲だけなら --tests で絞る）

# 規約
- 例外は業務例外クラス BizException に統一する（RuntimeException を直接投げない）
- 金額計算は BigDecimal。double を使わない

# ハマりどころ
- 帳票出力は月末バッチと共通のため、出力項目を変えるときは batch モジュールも確認する
- 税率は定数ではなく税率マスタのテーブルから取得する（過去の改修で直書きが混入した）
- 仕様書は2022年以降更新されていない。迷ったらコードと特性テストを正とする

最後の1行が大事です。どちらを事実として扱うかの優先順位を、AIにも伝えておきます。

ドメイン知識が多い場合は、ルールファイルに詰め込まず、必要なときだけ読み込ませる仕組み（Claude Code ならスキル）に分けます。必ず実行したい処理、たとえば変更後の自動テスト実行は、助言にとどまるルールファイルではなく、確実に動くフック機能で固定するのが確実です。この設計の考え方はハーネスエンジニアリングの記事で詳しく整理しています。

ツールごとの置き場所とサイズの制約

ツールごとに読まれるファイルが違います。複数のツールを併用する現場では、置き場所を揃えておく必要があります。

ツール読まれるファイル補足
Claude CodeCLAUDE.md短く保つ。詳細は別ファイルに分離
CodexAGENTS.mdルートから現在地まで連結、近いほど優先。結合サイズの既定上限は32 KiB
GitHub Copilot.github/copilot-instructions.md などパス別の指示ファイルもあり。AGENTS.md と CLAUDE.md も読める
Cursor、Gemini CLI、Devin ほかAGENTS.md必須項目のない Markdown 形式

モノレポのように大きな構成では、サブディレクトリごとに AGENTS.md を置きます。編集中のファイルに最も近いものが優先されるので、モジュール固有の規約は各モジュールに書けます。Codex は上限を超えると内容が切り捨てられるため、サイズの大きいファイルは分割が前提です。

読み込まれているかを確認するまでが設定

書いただけで安心しないことです。Codex では、codex --ask-for-approval never "Summarize the current instructions." で読み込まれた指示を要約させて確認できます。他のツールでも「いまの規約を要約して」と聞けば、同じ検証ができます。

ルールファイルは書いて終わりではなく、AIが間違えた箇所を見つけるたびに1行足していく育て方が定着します。Claude Codeの結晶化の記事で触れたように、やり取りの中で見つけた知見をファイルへ戻していく運用が、時間とともに効いてきます。

読むだけから始めて、PRレビュー運用まで四段階で広げる

いきなり本番コードの改修を任せないことです。リスクの低い用途から入り、各段階でテストとレビューの仕組みを作ってから次へ進みます。

四段階の導入ステップ

段階AIにやらせること通過条件
読むだけ構造の説明、影響範囲の調査、仕様の要約要約が人のレビューで概ね正しいと確認できた
テスト補強特性テストの作成、不足テストの洗い出し全テストが1コマンドで合否を返す
小改修影響が限られた不具合修正、軽微な機能追加改修前後でテスト差分が意図した範囲に収まる
PRレビュー運用改修提案を人がレビューする標準フローに載せる書く役と見る役が別で、記録が残る

第一段階の「読むだけ」でも成果は出ます。担当者の異動後に残ったシステムを、まずAIに読ませて構造を把握する。これだけで引き継ぎの負荷は下がります。

小改修に進むときは、探索、計画、実装、コミットの順に分けます。差分を一文で説明できる程度の修正なら計画は省略できますが、複数ファイルにまたがる改修は、先に計画を人が確認します。大量のファイルに同じ変更を入れる移行作業は、対象ファイルごとに繰り返し実行し、最初の2〜3件で出来を見てから全体に広げます。

PRレビューの運用設計はAIコードレビューと人間の役割分担、仕様を先に固めて進める方法は仕様駆動開発、組織全体への広げ方はAI駆動開発の導入の記事で整理しています。

担当者ごとに「何から手を付けるか」を任せると、ルールファイルの書き方もレビュー基準もばらつきます。AI駆動開発研修では、既存コードベースの診断、ルールファイルの設計、AIが書いた変更のレビューまでを、自社の題材に沿って身につけられます。

受託・情シスで先に決める責任分界と機密の扱い

SIerや情シスでは、技術より先に決める事項があります。

  • AIに渡してよいコードの範囲：顧客の機密情報、個人情報、認証情報を含むファイルは除外するルールを作る
  • 入力データの学習利用：利用するサービスの設定と規約を確認し、学習への利用を止められるかを確かめる
  • 責任の所在：AIが書いた変更でも、承認し納品する責任は人にある。レビュー者と承認者を契約と運用で明確にする
  • 権限：AIが実行できるコマンドを許可リストで絞り、本番環境へ到達できない環境で動かす

各ツールの法人向けデータ取り扱い条件は変わり得るため、導入時点でベンダーの最新規約を確認してください。受託開発では、顧客との契約でAI利用の可否を明記しておくと、後のトラブルを避けられます。

公開されている成果の数字は条件付きで読む

導入の稟議では、事例の数字が引き合いに出されます。ただ、公開されている数字の多くは、条件付きの自己申告です。

数字条件
不整合の検出が11件から33件（27%から80%）NTT。サンプルアプリ1本、誤りを意図的に41件埋め込んだ予備実験
法改正対応の改修が3人月から4時間（約100倍）富士通。2024年度の法改正対応の実証で、全300件のうち1件の事例から換算した値。第三者検証は確認できず
COBOL移行の成功率が大きく向上OpenAI。自己申告で、第三者の再現は確認できず

自社の稟議に使うなら、最初の一本で社内計測した数字が最も説得力を持ちます。改修にかかった時間、レビューで見つかった手戻り、テストで拾えた不具合を、AIありとなしで記録しておきます。

保守現場の定量効果について、導入企業側が一次情報で公開している例は、2026年10月時点では乏しいのが実情です。だからこそ、自社の実測が資産になります。

よくある質問

Q. 設計書がまったくない古いシステムでも生成AIは使えますか？

使えます。AIにコードを読ませて仕様の下書きを作らせ、人が検証して整えます。この設計書の再生成が、そのままAI-Ready化の第一歩です。

Q. AIが作った設計書やテストは信用してよいですか？

そのままは信用できません。実装との一致を検証して初めて使えます。特性テストは改修前のコードで通ることを確認し、設計書は業務担当者の確認を挟みます。

Q. まず何から着手するのがよいですか？

診断チェックリストの点検と、「読むだけ」の用途から始めます。コードの構造説明や影響範囲の調査なら、本番に影響を与えずに効果を測れます。

Q. NTTの技術はすぐ利用できますか？

いいえ。発表は実用化を目指す段階で、提供開始時期は本文に記載がありません。当面は、本記事の手順で既存のツールを使って準備を進めるのが現実的です。

Q. 機密性の高いコードをAIに読ませても問題ありませんか？

ガイドラインなしで読ませるのは避けてください。渡してよい範囲の基準を決め、学習利用の設定と規約を確認した上で、条件を満たすツールだけを使います。

まとめ

最初の一歩は、診断チェックリストを使って対象システムの空白を洗い出すこと。次に、改修前の挙動を特性テストで固定し、ルールファイルを短く書く。この3点を済ませてから、小さな改修で効果を測ります。

モデルの性能向上を待っても、設計書と実コードの食い違いは消えません。AIに渡せる状態は、自分たちの手で作るしかないのです。

診断から運用設計までを自社で進めたい場合は、AI駆動開発研修で、既存コードベースを題材にした進め方を実践的に学べます。

次に読みたい関連記事