AIコーディングツールを開発フローに組み込んでいるチームで、計画・実装・レビュー・テストを同じモデルに一括で任せている場合は要注意です。1つのAIモデルに全工程を任せる設計が、なぜ非機能要件の見落としにつながるのか整理します。
コードレビュー体制や品質保証プロセスを設計する立場の方、あるいはAIエージェントをCI/CDパイプラインに組み込もうとしているアーキテクトの参考になれば幸いです。
何が起きるか
1つのチャットセッションで、同じLLM（大規模言語モデル、大量のテキストを学習して自然な応答を生成するAI）に計画立案からコード生成、レビュー、テスト作成まで通しで依頼するケースがあります。
この構成では、コードを書いたモデル自身がそのコードをレビューします。書いた本人が見えていない欠陥は、レビューの段になっても同じ理由で見えません。
さらにテストケースも同じモデルが作るため、そのモデルが最初から想定していなかった失敗モード（想定外の入力やタイミングで発生する不具合パターン）は、テストの対象からも漏れます。計画・実装・レビュー・テストという4つの独立した検証機会が、実質1つの視点に収束してしまう構造です。
これは組織のコードレビューで「書いた本人がセルフレビューだけで済ませる」状態に相当します。人間の開発チームであれば当然避ける体制を、AIエージェントに対しては無自覚に許してしまっているケースが見られます。
なぜ起きるか（原因の分解）
原因は大きく3層に分解できます。
1つ目は「モデルへの忠誠心」です。使い慣れたモデルを全工程に使い回すほうが、プロンプトの調整コストや出力形式のばらつきを抑えられるため、運用上は楽に感じられます。しかしこの利便性が、盲点を固定化する副作用を持っています。
2つ目は「ベンダーロックインの構造的リスク」です。単一のAIベンダー・単一モデルにパイプライン全体を依存させると、そのベンダーの障害・レート制限（API呼び出し回数の上限）・価格改定が起きた瞬間に、開発パイプライン全体が止まります。これはSREやアーキテクチャ設計で言う「単一障害点（SPOF: Single Point of Failure）」と同じ構図です。インフラを冗長化する発想が、AIモデルの利用設計には及んでいないケースが多く見られます。
3つ目は「コーディングスタイルの偏り」です。同じモデルにコードを書かせ続けると、そのモデルのデフォルトの書き方にコードベース全体が寄っていきます。すると、別のモデルなら「読みにくい」「意図が不明瞭」と指摘するはずの箇所が、レビュー時にも見過ごされます。これは技術的負債が静かに蓄積する典型パターンで、原因の可視化自体が難しいという厄介さがあります。
自分のプロジェクトが該当するか確認する方法
以下の観点で、現状のAI活用フローを棚卸ししてみてください。
- 計画（プランニング）・実装・レビュー・テスト作成を、同一のモデル（同一のAPIキー・同一のサブスクリプション契約）で行っていないか
- CI設定ファイル（
.github/workflows/*.ymlなど）内で、AIレビューを呼び出すジョブとコード生成を行うジョブが同じモデル名・同じエンドポイントを参照していないか - ADR（Architecture Decision Record、設計判断とその理由を残す記録）や開発ガイドラインに、使用モデルとその選定理由が明記されているか
- 直近のプルリクエストで、AIレビューコメントが指摘した欠陥の傾向に偏りがないか（同じ種類の指摘ばかりで、境界値やエラーハンドリングの指摘がほぼ出ていないなら要注意）
- 契約しているAIベンダーが1社のみで、障害時の代替手段を用意していないか
該当する項目が2つ以上あれば、パイプラインの設計を見直す価値があります。
対策の手順
段階を分けて、担当モデルを分散させる設計に切り替えます。
ステップ1: 計画担当モデルを固定する
推論力の高いモデルを選び、読み取り専用（read-only）でタスクの範囲を決める計画立案に専念させます。ここでコードを直接書かせないことで、計画段階の判断とコード生成段階の判断を分離します。
ステップ2: 実装担当モデルを分ける
計画を、高速で低コストなコード特化型モデルに渡します。テストを自動実行する「ハーネス」（実行環境・検証の枠組み）の中で動かし、生成コードがすぐに検証される状態にします。
ステップ3: レビュー担当を別モデルにする
実装したモデルとは異なるモデルにレビューを担当させます。明確なルール・再利用可能なスキル定義・堅牢なハーネスが整っていれば、レビューには低コストなモデルを使っても構いません。
ステップ4: テストの拡張を依頼する
レビュー担当モデルに、実装者が見落とした境界値や異常系のテストケースを追加させます。学習データや推論の傾向が異なるモデルほど、著者本人が想定しなかった失敗モードを発見しやすくなります。
ステップ5: 判断根拠を記録する
どの工程をどのモデルが担当し、どんな前提を置いたかをADRなどに残します。数か月ごとにモデルの組み合わせを見直し、新しいモデルのリリースに応じてローテーションします。
ステップ6: TDDに敵対的な役割分担を導入する
TDD（テスト駆動開発）のRed-Green-Refactorサイクルに、あえて3つの異なるモデルを割り当てる方法もあります。1つがテストを書き（Red）、別の1つが最小限の実装をし（Green）、さらに別の1つがリファクタリングの要否を判断します（Refactor）。役割ごとに視点を分離することで、単一モデルの盲点をサイクル全体でカバーします。
導入前に確認すること
単一モデル運用の落とし穴は、コスト最適化や利便性を優先した結果として静かに生まれます。
見直す際は、まず現状のパイプライン設定ファイルで計画・実装・レビュー・テストがどのモデルに紐づいているか棚卸ししてください。
次に、レビュー担当だけでも実装担当と別モデルに切り替え、直近数回のプルリクエストで指摘内容の傾向が変わるか比較してみてください。
最後に、モデルの割り当てと選定理由をADRとして残す運用を始めれば、盲点の再発にも気づきやすくなります。