敵対的レビューとは — Claude Codeで別文脈のサブエージェントに差分を検証させる設計

敵対的レビューとは何か

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

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

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

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

この並びで見ると、敵対的レビューの立ち位置がはっきりします。/goalの評価者は独立した判定役ではありますが、ツールを呼べず会話の中身しか見られません。「テストが通った」という報告を信じるしかない場面もあります。敵対的レビューはサブエージェントとして差分やファイルそのものを読みに行けるため、報告を鵜呑みにせず根拠を自分で確認できるのが違いです。そのぶん、サブエージェントの起動と読み取りのコストがかかります。テストの合否のように機械で決まる条件はStop hookに任せ、モデルの判断が要る部分だけをここに回す分担が現実的です。

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のフロントマターで権限を絞り込めます。toolsを省くと全ツールを継承し、disallowedToolsは継承した一覧から指定のツールを外します。EditとWriteを外しておけば、レビュー役が指摘のついでに直してしまう事態を防げます。

---
name: diff-reviewer
description: Reviews a diff against a plan and reports gaps only.
disallowedTools: Edit, Write
maxTurns: 15
---
Review the diff you are given against the plan. Report only gaps that
affect correctness or the stated requirements. Do not fix anything.

これは公式のフロントマター欄(name・description・disallowedTools・maxTurns)に沿った例で、maxTurnsの15は任意の値です。組み込みのExploreとPlanは読み取り専用でWriteとEditが拒否されていますが、調査用の設計なので、指摘の基準まで決めたいときは自分で定義するほうが意図に合います。

forkしたサブエージェントは独立していない

サブエージェントなら何でも新しい文脈になるわけではありません。/subtask(v2.1.161〜v2.1.211と、agent viewを無効にした環境では/fork)で起動するforkは、会話履歴・システムプロンプト・ツール・モデルをすべて引き継ぎます。サブエージェントが本来持つ入力の分離が外れるので、レビュー役をforkで作ると、実装の経緯を知ったままの目で見ることになります。

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

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

仮説を互いに反証させるAgent Teams

Agent Teamsは実験的機能で、既定では無効です。有効にするにはCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を環境変数かsettings.jsonに設定します。

敵対的という語がいちばん文字どおりに当てはまるのは、Agent Teamsの調査パターンです。原因が分からないとき、1つのエージェントはもっともらしい説明を1つ見つけて探索をやめがちです。そこで複数のチームメイトに別々の仮説を調べさせ、互いの説を反証させます。

Spawn 5 agent teammates to investigate different hypotheses. Have them talk
to each other to try to disprove each other's theories, like a scientific
debate.

生き残った説が実際の原因である可能性が高い、というのが公式の説明です。差分の検証ではサブエージェントを呼べば足り、複数の視点を戦わせたい調査や設計の場面でAgent Teamsの出番があります。

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

Claude Codeにはコードレビューを実行する経路がすでに4つあり、Claude Codeコードレビュー — 4つの実行経路の使い分けで扱っています。ローカルの/code-review、自作のGitHub Actionsワークフロー、組織向けの管理Code Review機能、危険度の高いPR向けのultrareviewです。敵対的レビューはこれらと矛盾しません。ローカルの/code-reviewは現在の差分を新しいサブエージェントで見るスキルで、lowからmaxまでの強度指定、--fix(指摘の適用)、--comment(PRやGitLabのマージリクエストへの投稿)を取れます。

ultraを付ける、あるいはclaude ultrareviewで走らせるクラウド版のレビューは、ターミナルからも呼べます。v2.1.285で--helpを見ると、次の出力でした。

Usage: claude ultrareview [options] [target]
 
Run a cloud-hosted multi-agent code review of the current branch (or a PR number
/ base branch) and print the findings
 
Options:
  -h, --help           Display help for command
  --json               Print the raw bugs.json payload instead of formatted
                       findings
  --no-post            Do not post the findings to the PR (the default; accepted
                       for parity with the /ultrareview and /code-review ultra
                       flags)
  --post               Post the finished review's findings to the PR as you (PR
                       targets only; one plain comment, not a review)
  --timeout <minutes>  Maximum minutes to wait for the review to finish
                       (default: 45)

--postは既定で無効です。付けない限りPRには投稿されず、結果は手元に出力されます。付けた場合もPRを対象にしたときだけ有効で、投稿は1件の通常コメントです。無人の作業を締める前の検証としてスクリプトに組み込みやすい形です。

ただし実行ごとに使用クレジット(usage credits)が掛かります。プランに含まれる利用枠では賄われません。ProとMaxには一度きりで更新されない無料3回があり、TeamとEnterpriseに無料枠はありません。無料回を使い切った後は、変更の規模に応じて通常5〜25ドル分の使用クレジットが掛かります。途中で止めたり失敗したりした場合も無料回は1回として数えられ、有料のレビューは走った分だけが課金されます。使用クレジットを有効にしていないと、有料のレビューは起動できません。

起動方法で同意の取り方が変わります。対話セッションで/code-review ultraから始めると、確認ダイアログに範囲・残りの無料回数・見積もりが出ます。こちらは所要が通常5〜10分で、バックグラウンドタスクとして動くため、その間も手元のセッションは使えます。claude ultrareviewサブコマンドは、実行そのものが同意とみなされ、入力を待たずに始まり、結果が届くまで待ちます。

ローカルの/code-reviewは通常の利用枠に数えられます。Stop hookやローカルの/code-reviewで足りる検証まで、毎回ultrareviewに回す必要はありません。

4経路との違いは、道具ではなくどの時点で何を判定させるかです。4経路の記事が主に扱うのは「マージしてよいPRか」という人間のレビュー代替です。敵対的レビューが扱うのは「Claudeの自律実行を、次の作業に進めてよいか」というワークフロー内部の完了判定です。同じ/code-reviewでも、PRを開く前、セッションがまだ作業を続けている最中に挟めば、完了判定として働きます。

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

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

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

まとめ

機械で合否が決まる条件はStop hook、モデルの判断が要る検証だけをレビュー役のサブエージェントに回す分担が基本です。レビュー役はforkではなく、通常のサブエージェントで作ります。

よくある質問

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

差分1件のレビューなら、長い探索は要りません。maxTurnsに上限を置くと、到達した時点でサブエージェントは止まり、出力は途中結果として返ります(この印付けはv2.1.246以降)。Claudeは同じサブエージェントを再開して続きを進められるので、上限は小さめに置いておけます。