Claude Code に実装を任せたあと、こう打ち込んだことがあるはずだ。
この実装をレビューして
そして返ってくるのは、たいてい「概ね問題ありません。強いて言えば変数名を…」という類のものだ。次の日に本番でヌルポが出る。
Anthropic の公式ベストプラクティスは、この現象に対して明確な処方箋を置いている。レビューを別コンテキストの敵対的検証ステップとして構造化せよ、というものだ。単なる言い回しの好みではなく、エージェントの動作原理から導かれた設計指針になっている。
1. なぜ「レビューして」は通ってしまうのか
問題は Claude の性格ではなく、採点者が受験者と同一人物であるという構造にある。
同じセッションで「実装して」→「レビューして」と続けたとき、レビューする側のコンテキストには何が入っているか。実装に至るまでの探索、選んだ設計方針、そこで下した判断の理由——つまり**「なぜこれで良いと考えたか」という論拠一式**が丸ごと残っている。その状態で自分の書いたコードを評価すれば、結論は最初から決まっている。ドキュメントもこの点を率直に認めていて、まっさらなコンテキストのほうがコードレビューに向くのは、Claude が直前に自分で書いたコードに肩入れしないからだと説明している。
さらに厄介なのは、失敗が「明らかな失敗」の顔をしていないことだ。ベストプラクティスは典型的な失敗パターンのひとつとして「trust-then-verify gap」——もっともらしく見えるがエッジケースを踏み抜く実装——を挙げている。もっともらしさは、生成モデルが最も得意とする出力である。そしてレビュアーが同一コンテキストにいる限り、もっともらしさは検出対象ではなく前提になる。
「レビューして」というプロンプトは、暗黙のうちに確認を依頼している。確認を頼まれた相手は確認する。それだけの話だ。
2. ドキュメントが実際に推奨していること
該当箇所は 2 つある。
「Give Claude a way to verify its work」 の節では、停止条件の担保方法を段階的に並べたうえで、最も強い手段のひとつとして「second opinion」を挙げている。検証用のサブエージェントに結果を反証させることで、作業したエージェントが自分を採点する状態を解消する、という整理だ。ここで使われている動詞は “check” ではなく “refute”(反証する)であることに注意したい。
「Add an adversarial review step」 の節はさらに直接的だ。要点をまとめるとこうなる。
- レビュアーはフレッシュなサブエージェントのコンテキストで走らせる
- レビュアーが見るのは diff と、あなたが与えた基準だけ。その変更を生んだ推論過程は見えない
- 見えないからこそ、レビュアーは結果をそれ自体の是非として評価できる
- 無人で長く走らせるほど、完了と見なす前の独立チェックの価値は上がる
つまり推奨の意図は「厳しく言えば厳しく見てくれる」ではない。情報を遮断することで、追認が構造的に不可能な位置にレビュアーを置くことにある。敵対性は態度ではなく配置の問題だ。
3. 敵対的検証が効く 3 つのメカニズム
(a) コンテキストの分離 — 追認の材料を渡さない
サブエージェントは独立したコンテキストウィンドウで動く。これはドキュメント全体を貫く「コンテキストは最も重要な希少資源」という前提とも噛み合う。レビューのためにファイルを大量に読ませても本体セッションは汚れないし、レビュアー側には弁護材料が存在しない。
「別ウィンドウで Writer / Reviewer を分ける」パターンも同じ原理だ。ドキュメントは実装セッション A とレビューセッション B を往復させる表を載せているが、サブエージェント方式ならレビュー結果が実装セッションに直接返るため、あなたがウィンドウ間で指摘をコピペする必要がなくなる。
(b) 立証責任の反転
「レビューして」は Is this OK? を訊いている。反証を求めるプロンプトは Show me where this breaks. を訊いている。前者のデフォルト回答は「OK」で、後者のデフォルト回答は存在しない。何かを持ってくるまで仕事が終わらない。
これは「証拠を見せろ」という別の推奨とも直結する。ドキュメントは、成功を主張させるのではなくテスト出力・実行したコマンドとその戻り値・スクリーンショットといった証拠を提示させろと言っている。あなたが検証を自前でやり直すより、証拠を読むほうが速いからだ。反証プロンプトは、この「証拠ベース」を検証側にも強制する。
(c) 合格条件の外部化
敵対的レビューが最も効くのは、何をもって指摘とするかを先に固定したときだ。ドキュメントの例はここが上手い。
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.
指摘対象が「PLAN.md に対する差分」に固定されている。レビュアーの主観ではなく、外部に置かれた仕様が判定基準になっている。だから「良し悪し」ではなく「充足/未充足」で答えが返る。
4. 実践パターン
最小構成:バンドル済みスキルを使う
正しさの確認だけなら、まず /code-review を叩けばいい。現在の diff をフレッシュなサブエージェントでバグ観点からレビューし、結果をセッションに返してくれる。プロンプトを書く必要がない。
計画との突き合わせ:自分で書く
/code-review はバグを見る。「計画どおりか」を見たいなら自分でプロンプトを書け、というのがドキュメントの立場だ。書くべき要素は 3 つ。
- 何をチェックするか(対象の diff / ファイル)
- 何に照らすか(PLAN.md、SPEC.md、Issue、テスト表)
- 何を指摘と見なすか(スコープ外変更、要件の欠落、テストのないエッジケース)
日本語で書くならこう。
サブエージェントを使って、レート制限の diff を PLAN.md に対して検証して。
- PLAN.md の各要件が実装されているか、1 件ずつ充足/未充足で判定
- 列挙されたエッジケースにテストがあるか
- タスクのスコープ外が変更されていないか
指摘は「正しさ」と「明記された要件」に影響するものだけ。スタイルの好みは報告しない。
判定には根拠(ファイル名と行、テスト出力)を必ず添えて。
常設化:専用サブエージェントを定義する
毎回書くのが面倒なら .claude/agents/ に置く。ドキュメントの security-reviewer が良い雛形で、ツールを Read, Grep, Glob, Bash に絞ってある——書けないレビュアーは自分で直して誤魔化すことができない。
---
name: adversarial-verifier
description: 実装が仕様を満たさない証拠を探す
tools: Read, Grep, Glob, Bash
model: opus
---
あなたの仕事は実装を承認することではなく、仕様を満たしていない証拠を見つけることです。
- 与えられた diff と受け入れ基準だけを見て判断する
- 各指摘に、再現手順または該当行の根拠を付ける
- 根拠を示せない懸念は報告しない
- 正しさ・明記された要件に影響しないものは報告しない
- 反証が見つからない場合は「見つからない」と述べ、探した範囲を示す
最後の 2 行が重要だ。理由は次章。
5. 副作用:敵対的レビュアーは「何もない」と言いたがらない
ここを飛ばすと逆効果になる。ドキュメント自身が警告している通り、ギャップを探せと言われたレビュアーは、実装が健全でもたいていギャップを報告する。そう頼まれたからだ。そして全指摘を潰しにかかると、過剰な抽象化、不要な防御的コード、起こり得ないケースのテストが積み上がる——つまりオーバーエンジニアリングに着地する。
反証の要求は、偽陽性の生産と表裏一体である。抑え方は 3 つ。
| 手当て | 具体的には |
|---|---|
| 指摘の閾値を明示する | 「正しさと明記された要件に影響するものだけ。それ以外は optional 扱い」 |
| 根拠を必須にする | 再現手順・該当行・テスト出力を出せない指摘は報告させない |
| 空の結果を許可する | 「反証が見つからなければ、探した範囲とともにそう述べてよい」 |
「敵対的に検証して」は魔法の呪文ではなく、感度を上げる代わりに特異度を下げるツマミだと理解しておくのがいい。閾値と根拠要求は、下がった特異度を買い戻すための対価だ。
6. どこに効くか:自律実行の時間に比例する
ドキュメントの言い方を借りれば、Claude が無人で長く動くほど、独立した検査の価値は上がる。これが推奨の射程を決めている。
- タイポ修正やログ 1 行の追加 → 敵対的レビューは不要。オーバーヘッドのほうが大きい
- 複数ファイルにまたがる機能実装、自分が不慣れな領域、
--permission-mode autoでの放置実行、agent team による長時間ラン → 完了と見なす前の独立チェックが実質的に唯一の防波堤
そしてこれは、ドキュメントが繰り返す「検証できないものは出荷するな」の系でもある。テスト・ビルド・スクリーンショットのような決定的なチェックが書けるなら、まずそれを書くほうが強い。敵対的レビューは決定的なチェックを書けない部分——仕様との整合、スコープの逸脱、想定していなかったエッジケース——を埋めるための、確率的だが安価な二の矢だと位置づけるのが正確だ。
まとめ
「レビューして」が効かないのは Claude が甘いからではない。採点者に答案の下書きを渡しているからだ。
推奨の意図を一文にすると:
レビュアーから「なぜそう書いたか」を取り上げ、diff と外部化された合格基準だけを与え、承認ではなく反証を求める。そのうえで、指摘の閾値と根拠要求で偽陽性を絞る。
「敵対的」という語は攻撃性ではなく独立性を指している。実装した本人に採点させない、という一点に尽きる。そして最後の砦は依然としてあなただ——ドキュメントが証拠の提示にこだわるのは、あなたが検証をやり直すためではなく、証拠を読むだけで済ませるためである。
参考
- Claude Code Best practices — Add an adversarial review step / Give Claude a way to verify its work / Avoid common failure patterns https://code.claude.com/docs/en/best-practices
- Subagents: https://code.claude.com/docs/en/sub-agents
- Agent teams: https://code.claude.com/docs/en/agent-teams
