実装する AI とレビューする AI を分けたら、見落としが激減した話

これは「レガシー移行で学んだこと」シリーズの第2回です。第1回は buildが通っただけでは終わらない を参照ください。

前回、「Doneを固定値にせず、review 2サイクルで回す」という運用について書きました。今回はその運用を 誰が回しているのか、つまりエージェントの役割分担について書きます。

単一エージェント運用の限界

最初、私はClaude Code 1体にほぼ全部の仕事を任せていました。タスクを投げて、実装してもらって、「レビューもついでにして」と頼む。

これは一見スムーズに見えて、実は見落としの温床でした。書いた本人に「これ大丈夫？」と聞いているのと同じで、どうしても自分の実装にバイアスがかかります。

具体的に、私が遭遇した「単体レビューの穴」はこんな感じです。

• 実装者自身が「動くはず」と信じ込んでいる箇所は、reviewでも素通りする
• 「build通った」で意識が切り替わってしまい、業務的な挙動差分まで見に行かない
• 画面横断の整合性（同じフォームパターンの他画面にも影響するか）が検査対象から漏れる

これを埋めるには、実装と検査は別の視点で回す必要がある と感じました。

Orchestrator + Sub Agentへの切り替え

切り替えた運用はこんな形です。

1. Orchestrator（受付係）: 入ってきた依頼がどのレーン（analysis / backend / frontend / review / qa）に属するかを判定する。Evidence 3点（source of truth / migration intent / target file）と最初の編集対象を必ず明示させる
2. 実装Sub Agent: Orchestratorに判定されたレーンで実装する。build/testを通すところまでは通常通り
3. Reviewer Sub Agent: 実装完了後に別Sub Agentを起動。実装エージェントが見落としやすい観点を専用でチェックする
4. 修正: Reviewer指摘を実装Sub Agentに戻して修正
5. 再Review: Reviewer Sub Agentを再起動、blockerなしを確認してクローズ

ポイントは、Reviewer Sub Agentに レーン別のチェックリスト を持たせることです。たとえばフロントエンド側のForm+Buttonパターンなら、以下を必ず見るようにしています。

• 値の更新がTab / blur依存になっていないか（クリックだけで完結するか）
• stale-binding: クリック時点で古いモデル値を読んでしまう構造になっていないか
• クリック後に意図しない上書きや消失が起きないか

これは単に「レビューして」と頼んでいては絶対に出てこない観点で、Reviewer専用Sub Agentに固定観点として持たせてやっと出てきます。

「実装」と「レビュー」を分けた効果

体感では、1サイクルあたりの指摘件数は変わらないか、むしろ増えました。つまり今まで見つけられていなかった ということです。

実際にReviewer Sub Agentが拾った指摘の例:

• blocker級: 全受付モードで表示すべき操作列が、別条件で消えていた
• high級: 権限条件が本来より厳しくて、表示対象行が減っていた
• medium級: Oracle関数の呼び出しが抜けて、名称ではなくコード表示のままになっていた

いずれもbuild/testは通っていて、実装者Sub Agent視点では「Done」でした。Reviewerを分離して初めて浮いてきた指摘です。

Rate Limit時の運用

現実的な話として、Sub Agentを並列で使うとrate limitに引っかかることがあります。そのときは以下のルールで回しています。

• 別Sub Agent（別アカウント / 別モデル）に切り替えて実行
• それでも不可なら、task logに close decision: no、SubAgent review 実行を試行したが usage rate limit により実行不可 と明記して停止
• 次サイクル開始時に未完了のreviewから拾い直す

「止めたこと自体が記録される」状態にしておくと、人間の記憶頼りで取りこぼすのを避けられます。

わかったこと

• 1体のAIに「書いて、見て、直して」までやらせるのは、書いた本人に自己採点させているのと同じ。構造的に見落としが出る
• Orchestratorに レーン判定とEvidence 3点の確認 を強制させると、実装Sub Agentが勝手に暴走して違う箇所を触る事故が減った
• Reviewer Sub Agentに レーン別の固定観点（stale-binding / click-only path / data-lossなど） を持たせると、1回目のレビューの網目が細かくなる
• 人間は「次に何をやるか」と「Done更新」に集中できるようになった。コードを全部読む必要が減った

次にやること

実装Sub AgentとReviewer Sub Agent、どのAIモデルを割り当てるかでも結果は変わります。私は今、Claude CodeとCodexをプロジェクト内で 使い分けて いて、それぞれに得意領域があることが見えてきました。次の記事ではその話を書きます。

おまけ

基本的に、SKILLとAgentTeamの定義が共有されがちですが「人とLLMが行った会話の流れで出てきた作業事項」に関しては、Orchestratorは起動しないという弱点があります。このへんはHook活用の是非を問う記事で改めて紹介させてください。