Before / After で見る保守案件の違い — AIが正しく判断できる現場をつくる
はじめに
前回の記事では、仕様駆動開発（SDD）とは何か、
そしてなぜ AI 時代にそのアプローチが必要なのかを解説しました。
この記事では一歩踏み込み、
SDD を導入して AI が正しく判断できるようになった保守案件 と、
そうでない保守案件 の違いを Before / After で具体的に見ていきます。
結論：違いは「判断がどこにあるか」
最初に結論を述べます。
AI が正しく判断できるかどうかの違いは、コード量や設計力ではありません。
判断が、実装の前に明示されているかどうか。
この一点です。
Before / After の全体像
AI 時代の保守案件において、判断できない状態と判断できる状態の違いをまとめます。
| 観点 | Before：判断できない保守案件 | After：判断できる保守案件 |
|---|---|---|
| 影響範囲の確認 | コードを読んでから判断する | 仕様から即座に確認できる |
| 正解の所在 | コードや担当者の頭の中にある | 判断基準がドキュメントとして存在する |
| 判断の進め方 | 調査しながら判断が変わる | 判断を決め切ってから実装に入る |
| AI への指示 | 曖昧な指示しか渡せない | 明確な前提を渡せる |
この違いはスキルや経験の差ではありません。
判断をどこに置いているかの違いです。
変化① 調査の仕方が変わる
| 観点 | Before | After |
|---|---|---|
| 調査の起点 | まずコードを読む | まず仕様を見る |
| 調査方法 | 実装・ログから挙動を推測 | 影響範囲と前提条件を確認 |
| 調査の目的 | 正解を探す | 仕様と実装の差分を確認する |
Before の調査は、何が正解なのかを探す行為でした。
After では、仕様を前提に必要な箇所だけを確認する調査に変わります。
AI に渡す情報が「推測」から「確認済みの事実」になるため、生成されるコードの精度が上がります。
変化② 改修判断が変わる
| 観点 | Before | After |
|---|---|---|
| 安全性判断 | 正解が分からず不安なため安全側に倒す | 仕様を基準に判断できる |
| 過去の意図 | 人に聞かないと分からない | 仕様から確認できる |
| 修正範囲 | 安全側に倒して作業が膨らむ | 小さく決め切れる |
変化③ 引き継ぎの前提が変わる
| 観点 | Before | After |
|---|---|---|
| 引き継ぎ手段 | 口頭説明が中心 | ドキュメント参照 |
| 判断の背景 | 人依存 | 仕様として残る |
| 学習コスト | 担当交代ごとに発生 | 自走可能 |
これは単に「引き継ぎが楽になる」という話ではありません。
引き継ぎという行為そのものの前提が変わることを意味します。
過去の判断が仕様として残っていれば、新しい担当者も AI も、
同じ前提から始めることができます。
バイブコーディングとの決定的な違い
「仕様書を markdown で管理すれば同じでは？」と感じるかもしれません。
しかし、markdown に書かれていることと、
判断の基準になっていることは別です。
この順番の違いが、AI 時代の保守においては致命的な差になります。
Before から After へ移行する現実解：リバース仕様化
ここで疑問が湧きます。
「仕様書のない既存コード（Before）を、どうやって After にするのか？」
既存システムの全仕様を書き起こすのは現実的ではありません。
SDD では 「リバース仕様化」 というアプローチで、現実的に移行を進めます。
いきなり理想を目指すのではなく、
「今回触る箇所から順に、判断の空白地帯を埋めていく」 プロセスです。
保守作業をするたびに、システムが徐々に「AI が判断できる状態」へと塗り替わっていきます。
この状態がもたらす2つの結果
結果① 手戻りが減る
判断を先に決め切ることで、実装後に前提が覆ることがなくなります。
手戻りが減るのは、目的ではなく結果です。
結果② 判断が資産として残る
保守で生まれた判断は仕様として残り、
次の改修やバグ対応で再利用されます。
これは属人化を防ぐというより、
判断を個人から構造へ移すことを意味します。
まとめ
AI が正しく判断できる保守案件では、
- 判断が先に存在し
- 判断が明示され
- 判断が構造（仕様）に置かれています
この状態を「今日から」作るために、既存コードからでも始められるのがリバース仕様化です。
次に読む
では、この仕組みを あなたの GitHub Copilot 環境 で実現するには、
具体的にどうすればよいのでしょうか？
次の記事では、ツール cc-sdd を導入し、
仕様駆動開発の基本サイクル（Steering → Requirements → Design → Tasks）を
実際に回す手順を解説します。
Discussion