PRは全部通っていた。それでも壊れた――コーディングエージェント実運用で分かった「統合後」の問題

コーディングエージェント（AIコード生成）を本運用する際に、個々のプルリクエスト（PR）は小さく分け、テスト・CI・人間レビューを通す手法が広がっている。このやり方で1つのPRの品質はかなり向上する。だが運用を続けると、個別PRは全部通っているのに、複数の変更を統合した後のコードから必要な処理が消える現象が繰り返し起きた。merge conflictを解消しコンパイルできても、意味的には壊れている。検索対象を名前で限定したため変更経路を見落とす。各レイヤーでは正しくても、DBからフロントエンドに値が届く過程で意味が変わる。こうしたケースが次々と浮かぶと、問題の本質は「AIが間違ったコードを書いた」ではなく、「一度確認した変更の正しさが、時間経過や他の変更との統合後も自動的に有効だと仮定していた」ことだと分かる。

テスト結果もレビュー結果も、それらを確認した時点では有効だが、その後コードベースが変わると古くなる。merge conflictはテキスト上で解消できても、設計前提は壊れているかもしれない。AIが検索対象を定義し、同じAIがレビューすれば、冗長系は機能しない。また、バックエンド・API・フロントエンドを通す間に、ローカルには正しい値が「全体のフロー上では意図した形で伝わらない」ことも起きる。実装側の正確性と、全体系での意味の保存は別問題なのだ。

対策は「個別PRの品質だけに依存しない」ことだ。複雑な変更について、統合後のコード全体を別視点でレビューする。本来ルールの逆向き探索（「この状態を変更できる経路は全部どこか」と問う）をさせる。APIやスキーマの境界で、値の意味が保存されるか明示的に確認する。そして、別のAIモデルやシステムでのダブルチェック体制を作る。個別にいくら完璧でも、統合後に意味が変わる可能性は無くせない。むしろその想定の下で、多層防御を設計する必要がある。