配布資料 52事例 #12: 「小さな変更」と承認したはずが、実測で別物になった

プランを承認するというのは、実はその差分の規模を承認しているのだと、あとで気づきました。

何が起きたか

DB スキーマのリレーションを nullable 化する設計案について、AI は影響範囲を「一部の管理機能のみ」と見積もりました。 その見積もりを前提にプランを承認しました。

ところが実装に入って型チェックを回すと、12ファイル・40箇所以上で null 対応が必要と判明しました。

承認したプランの前提が崩れたので、実装を進めずに代替案（NOT NULL 維持 + 代表レコード方式）へ切り替えました。

なぜ起きたのか

表面的には、影響範囲を grep もせずに印象で見積もったことです。

構造はこうです。 プランの承認は「実装後の差分規模」への承認を含意します。 それなのに見積もりが実測に基づいていませんでした。

スキーマの optionality 変更は、型システムを通じて全読み取り箇所へ波及します。 この波及は grep では数えきれず、実際にコンパイラを回さないと分かりません。

そこから生まれたルール

「optionality 変更の提案前に読取箇所を数える。5箇所以上ならスキーマだけ先に当てて型チェックの試走で実数を確認する。プラン本文に『影響範囲: N ファイル / M 箇所』を明記する。10箇所を超えるなら、理想案と現実案の両方を提示する」

理由の言語化も残してあります。 「誤った見積もりは、『小さな変更』と思って承認した PR を別物にする」

どう機械に守らせたか

運用ルールのみです。設計判断ロールの遵守事項に収載し、セッション開始時の規律注入で在中させています。

機械化するなら「スキーマ変更を含むプランには tsc 実測値の記載を必須にする」チェックが考えられます。 題材プロジェクトでは規律で運用しています。

持ち帰るなら

AI に計画を立てさせるときは、影響範囲の数字に「実測か、印象か」のラベルを付けさせてください。

「影響: 小」ではなく「影響: 12ファイル40箇所（tsc 実測）」と書かせます。

見積もりが外れたときのルールも決めておきます。実測が承認時の前提を超えたら、進めずに戻って再承認。 これは人間のチーム開発の変更管理と同じで、AI にも同じ統制が要ります。