Claude Codeの敵対的レビューパターン — 新しい文脈で差分を検証させる

敵対的レビューとは何か

実装を行ったセッションとは別のサブエージェントに、新しい文脈で差分を検証させる設計パターンです。レビュー役のサブエージェントに見えるのは差分と検証基準だけで、実装セッションがどう考えてその変更に至ったかという経緯は一切見えません。実装の理屈を共有していないぶん、結果だけを独立した基準で評価できます。

Claude Codeを無人で長く走らせるほど、この独立したチェックの価値は上がります。人が張り付いて見ていないあいだ、Claudeは「終わったように見える」時点で作業を止めます。そこに実装セッション自身とは違う目を1つ挟むだけで、見落としを拾える確率が上がります。サブエージェント自体の仕組み(独立コンテキスト・ツール制限)はClaude Code Sub-agents完全ガイドで扱っています。

「完了したか」を判定する4つの方法

Claude Codeが自分の作業を終えたと判断する仕組みは1つではありません。どれだけ厳しくチェックを利かせたいかで選ぶ手段が変わります。

この並びで見ると、敵対的レビューの立ち位置がはっきりします。/goalの評価者は独立した判定役ではありますが、ツールを呼べず会話の中身しか見られません。「テストが通った」という報告を信じるしかない場面もあります。敵対的レビューはサブエージェントとして差分やファイルそのものを読みに行けるため、報告を鵜呑みにせず根拠を自分で確認できるのが違いです。手軽さでは劣りますが、検証の強さでは4つの中で最も重く、最も確かです。

2つの呼び出し方

敵対的レビューは大きく2通りの使い方があります。何を確認したいかで選びます。

正しさだけを機械的に見るなら/code-reviewスキル

同梱の/code-reviewスキルを呼ぶと、現在の差分をバグの観点で新しいサブエージェント内でレビューし、指摘をセッションへ返します。PRを指定して/code-review high 1234のように呼べば、そのPRを対象にできます。汎用の正しさチェックであれば、プロンプトを自分で書く必要はありません。

計画との突き合わせなら自分でプロンプトを書く

「要件を全部満たしているか」のように計画と照らし合わせたいときは、レビュープロンプトを自分で書きます。ポイントは3つを明示することです。何を確認するか(対象の差分)、何と照らし合わせるか(計画やPLAN.md)、何を指摘として扱うか(スタイルの好みではなく欠落)。

Use a subagent to review the rate limiter diff against PLAN.md. Check that
every requirement is implemented, the listed edge cases have tests, and
nothing outside the task's scope changed. Report gaps, not style preferences.

レビュー役はサブエージェントとして動くため、指摘は実装セッションへ直接返ります。窓をまたいで指摘をコピーする手間がなく、実装側はその場で直して再レビューに回せます。

似た発想に、実装用と検証用で2つの対話セッションを人が使い分けるWriter/Reviewerパターンがあります。片方のセッションで実装し、もう片方のセッションにその成果物を見せてレビューさせ、指摘を実装側へ手動で持ち帰る流れです。敵対的レビューとの違いは自動化の度合いです。Writer/Reviewerは人がセッション間で指摘をコピーする前提ですが、敵対的レビューはサブエージェントとして呼ぶため、指摘は実装セッションへ直接返り、無人のループに組み込めます。

レビュー役には書き込み権限を渡さない

カスタムサブエージェントとしてレビュー役を定義するなら、toolsとdisallowedToolsのフロントマターで権限を絞り込めます。継承した全ツールからEdit・Writeを明示的に外しておけば、レビュー役が「指摘するついでに直してしまう」事態を防げます。実装と検証が同じツール権限を持っていると、独立した目で見ているつもりが結局は実装の続きになりがちです。読むだけ・報告するだけに権限を絞ることが、敵対的レビューを名前どおりの独立した検証にする最小の設定です。

指摘を鵜呑みにしない — 過剰検出のわな

この一言があるかどうかで、レビューの実用性が変わります。「指摘を探せ」とだけ頼むと、実装側は指摘の重みを自分で判断するしかありません。「正しさと要件に関わるものだけ報告する」と最初から絞っておけば、返ってきた指摘はそのまま対応の優先度になります。

長時間の自律実行ではAgent Teamsでループを回し続ける

タスクが1本で終わらず、長時間にわたって多数のタスクを自律的にこなす運用では、実装→敵対的レビュー→修正のループを1回きりで終わらせず回し続ける必要があります。この場合はAgent Teamsを使い、記録された指摘を人が後から抜き打ちで確認する形に倒すと、張り付いていなくてもループが止まりません。

使い分けは、対象がタスク1本かどうかで決まります。1回の実装差分の正しさを検証するだけなら、これまで見てきたようにサブエージェントを都度呼び出せば足ります。一方、複数のタスクをまたいで実装→レビュー→修正のループを止めずに回し続けたい場合は、Agent Teamsでその繰り返しの器そのものを持たせる形になります。

既存のコードレビュー機能との違い

Claude Codeにはコードレビューを実行する経路がすでに4つあり、Claude Codeコードレビュー — 4つの実行経路の使い分けで扱っています。ローカルの/code-review、自作のGitHub Actionsワークフロー、組織向けの管理Code Review機能、危険度の高いPR向けのultrareviewです。敵対的レビューはこれらと矛盾しません。むしろ/code-reviewスキルはその4経路の1つを、サブエージェントという実行単位から見た呼び方です。

違いは目的です。4経路の記事が扱うのは「マージしてよいPRか」という人間のレビュー代替です。敵対的レビューが扱うのは「Claudeの自律実行を、次の作業に進めてよいか」というワークフロー内部の完了判定です。PRを開く前、セッションがまだ作業を続けている最中に挟む点が、PRレビューの4経路とは根本的に異なります。

オーケストレーターの「同時多視点レビュー」との違い

Claude Codeオーケストレーター設計では、観点を分けた複数体を同時に走らせて差分をレビューする型を紹介しています。セキュリティ・互換性・可読性のように観点を分担し、指摘の粒度を揃える使い方です。

敵対的レビューはこれとは別の軸で効きます。同時多視点レビューは「1つの差分を複数の角度から見る」ための型で、指揮役が観点を割り振ります。敵対的レビューは「実装した本人が自分を採点しない」ための型で、観点の数よりも独立性そのものが目的です。両方を組み合わせ、独立したレビュー役に複数の観点を持たせることもできます。

まとめ

敵対的レビューは、実装セッションとは別のサブエージェントに新しい文脈で差分を検証させる設計パターンです。実装セッション自身に採点させない、という一点がすべての土台になります。/goalの評価者が会話しか見られないのに対し、敵対的レビューは差分やファイルそのものを読みに行けます。正しさだけなら/code-reviewスキル、計画との突き合わせなら自分で書いたプロンプトを使い、「正しさと要件に関わる欠落だけを報告する」と指示して過剰検出を防ぎます。長時間の自律実行ではAgent Teamsでループを回し続け、記録された指摘を後から抜き打ちで確認する運用に倒します。

よくある質問

レビュー役のサブエージェントに実装の意図やチャット履歴を見せたほうがよいですか

見せないほうが独立性が保てます。実装の理屈を共有すると、レビュー役も同じ思い込みに引きずられやすくなります。渡すのは差分と検証基準だけにとどめ、結果を独立した目で評価させます。

/code-reviewと自分で書くプロンプト、どちらを先に試すべきですか

汎用の正しさチェックなら/code-reviewが手早く済みます。要件や仕様との突き合わせのように、そのタスク固有の基準があるときは自分でプロンプトを書き、対象・照らし合わせる計画・指摘の基準の3点を明示します。

Stop hookと敵対的レビューは同時に使えますか

使えます。Stop hookはスクリプトで合否を判定する決定的なゲートで、敵対的レビューはモデルによる判断です。テストやビルドの合否はStop hookで機械的に締め、要件との整合性や設計上の欠落は敵対的レビューで見る、という役割分担が可能です。

レビュー役のサブエージェントは何ターンくらいで終わらせるべきですか

差分1件のレビューであれば、長々と探索させる必要はありません。サブエージェントの設定にはmaxTurnsでターン数の上限を設けるフィールドがあり、レビューの範囲が明確なら上限を絞って早めに切り上げさせるほうが、無関係な深掘りを防げます。

指摘が1件も返ってこなかったら信用してよいですか

「欠落を探せ」という指示自体が指摘を誘発しやすいため、0件という結果はそれなりに重みがあります。ただし検証基準が曖昧なまま投げていないか(対象・計画・指摘基準の3点が明示されているか)は見直す価値があります。基準が緩ければ、指摘が出ないのは基準の緩さが原因かもしれません。0件を鵜呑みにせず、まずは指示の具体性を疑うところから確認します。