AIに「レビューして」はもう古い？「敵対的検証」のすすめ

こんにちは、ログラスの松岡(@little_hand_s)です。

3行まとめ

• 「レビューして」でも指摘は返ってくる。「敵対的検証して」は課題がある前提で反証を試み、判定と根拠まで返してくるのが違い
• 敵対的検証はClaude Code公式も推奨するパターン。筆者のClaude Code環境では、一言でサブエージェントによる多視点検証が走った
• 指摘は鵜呑みにしない。採否を決めるのは人間。この記事自身も敵対的検証を通して書いています

先に謝っておきますが、多少キャッチーすぎるタイトルになっております。すみません！！🙇‍♂️
「レビューして」は今も有効で、使いどころのあるプロンプトです。この記事で紹介するのは、具体的な根拠を持ってもう一段品質を上げたい場面で使える「敵対的検証して」という選択肢と、使い分けの見極めです。

---

AIのリサーチ結果や設計案、もっともらしいけど鵜呑みにしていいのか不安になることはありませんか？私は実際、Claude Codeに任せた調査の内容が間違っていて、あとで問題になったことがあります。

「レビューして」と頼むのは悪くない対策です。それなりに的確な指摘も返ってきます。ただ、もう一段品質を上げたいとき、私が使っているのはこの一言です。

「レビューして」との違いは構えです。敵対的検証は「どこかに課題がある」という前提で反証を試み、指摘だけでなく検証の結果——判定と根拠——まで返してきます。だから成果物の品質が上がりやすく、返ってきた指摘を自分で判断しやすい。この記事では、敵対的検証とは何か、なぜ効くのか、どう頼めばいいのかを紹介します。

敵対的検証という考え方

敵対的検証（adversarial verification）とは、成果物を作った本人とは別の誰かが、「間違っているのでは」という前提であえて反証を試みることで品質を確かめる考え方です。

この発想自体は古くからあります。

• レッドチーム（red teaming）：1960年代の米軍ウォーゲームで敵役（赤＝ソ連）を演じたチームに由来します。のちにサイバーセキュリティへ広がり、現在はAI safetyの分野でAnthropicなどが自社モデルを攻撃的にテストする手法として使っています
• 悪魔の代弁者（devil's advocate）：カトリック教会の列聖審査に実在する役職です（1587年に制度化）。聖人候補にあえて不利な事実を突きつけ、安易な認定を防ぎます
• 反証主義：科学哲学者カール・ポパーは、仮説は証明されるのではなく、厳しい反証の試みに耐えることで暫定的に信頼される、と論じました

共通するのは「わざと反対側から叩くことで、結論を強くする」という構造です。

これがAIとの協働で特に効きます。理由は、AIの出力が常に「もっともらしい」からです。ハルシネーションが混ざっていても、雑な一般化があっても、見た目では区別できません。そして作った本人（AI）は、自分の出力に甘くなりがちです。だから、成果物を作った文脈から切り離した別の目に、壊すつもりで見させる必要があります。

Claude Codeには敵対的検証が組み込まれている

実はこのパターン、Claude Code自身が組み込みの機能の中で使っています。

/deep-research は、Web検索を複数の角度で並列実行したあと、集めた主張を重要度でランク付けし、上位の主張それぞれに対して3体の検証エージェントが反証を試みて投票します。3分の2が反証した主張はレポートから除外されます。内部プロンプトには「Be SKEPTICAL. Try to REFUTE this claim.（懐疑的であれ。この主張の反証を試みよ）」と書かれています。

/code-review も同じ構造です。複数エージェントが並列でバグを検出したあと、指摘ごとに別のエージェントが「本当に問題か」を再検証し、確信度の低い指摘を除外します。プロンプトには「If you are not certain an issue is real, do not flag it. False positives erode trust.（確信が持てないissueはフラグするな。偽陽性は信頼を損なう）」と明記されています。

Anthropicの公式ブログは、この型を Adversarial verification という名前付きパターンとして定義しています。

Adversarial verification: For each spawned agent, run a separate spawned agent to adversarially verify its output against a rubric or criteria.
（敵対的検証：エージェントに作業させたら、その出力を基準に照らして敵対的に検証する別のエージェントを走らせる）

公式ベストプラクティスにも「Add an adversarial review step（敵対的レビューのステップを追加せよ）」という専用セクションがあります。さらに検証の仕組みとして、fresh modelに反証を試みさせることで「作業したエージェント自身が自分を採点しない」構造を推奨しています。敵対的検証は、公式が推奨する正攻法です。

使い方：「敵対的検証して」と一言頼む

呼び出し方はシンプルです。成果物が出てきた場面で「敵対的検証して」と頼むだけです。成果物を作ったセッションでそのまま頼んで構いません。検証は別のfresh contextを持つサブエージェント側で行われるためです。対象を指定したいときは「この設計案を敵対的検証して」のように添えます。

実際の場面です。この記事を書く前、私は 「プロンプトを作り込まなくても、一言でAIが多視点の検証をしてくれる——その体験を紹介する」 という切り口案（企画メモ）を作りました。その案に対して送ったのが、この一言です。

今の案に敵対的検証して

もしくは

今の案に敵対的検証して。サブエージェントを立てて

これだけで、Claude Codeはスケプティック（懐疑役）のサブエージェント3体を「読者視点」「主張の正しさ」「記事としての成立性」に分けて並列起動しました。役割分担も検証観点も、こちらは指定していません。返ってきた判定の要点がこちらです。

• 読者視点：「条件付きGO（かなりNO-GO寄り）」——切り口案の核である「一言で検証が発動する」が、読者の環境で再現しない可能性への指摘
• 主張の正しさ：「そのままでは主張すべきでない」——1回の体験を「してくれる」と一般化しており、「私の環境ではこうなった」という観察報告に格下げすべきという指摘
• 記事としての成立性：「構成前に直すべき点あり」——主張を支える証拠が素材に足りていないという指摘

「レビューして」と比べたときの違いがここに出ています。改善点のリストではなく、課題がある前提で検討した上での、判定と根拠が返ってくる。だから受け取った側は、どの指摘が本当に効いていて、どれを採用すべきかを判断しやすいのです。

なぜ「レビューして」より効くのか。鍵は2つあります。

1つ目は敵対的な構えです。「課題がある」前提で反証を試みる役割を与えるため、成立していない箇所を探しにいく検討になり、指摘には判定と根拠が付きます。

2つ目はfresh contextです。サブエージェントは、成果物を作った会話の文脈をそのまま引き継ぎません。「これまでの流れ」に迎合できないため、独立した評価ができます。公式ベストプラクティスも（コードレビューの文脈で）、fresh contextのレビュアーは変更を生んだ推論を見ず、差分と与えられた基準だけを見るから独立に評価できる、と説明しています。

この2つは掛け算です。fresh contextでも「レビューして」では課題前提の検討になりませんし、同じ会話の中での「反証して」は流れに迎合する可能性があります。「敵対的検証して」の一言は、この両方を同時に引き出します。

カスタムエージェントの定義もワークフローの構築も、最初は不要です。まず一言から試して、繰り返し使うようになったら仕組み化を検討すれば十分です。

使いどころは、リサーチの裏取りのほか、設計メモ・提案書・ADRのブラッシュアップ、AIと壁打ちして作った案の最終チェックなど、「もっともらしい成果物を、出す前に一度疑いたい」場面です。

Claude Code以外での使い方：要件とプロンプト雛形

この型はClaude Code専用ではありません。敵対的検証を成立させる要件は4つです。

1. 独立性：成果物を作った文脈と切り離した、まっさらな目に検証させる
2. 反証の役割づけ：「レビューして」ではなく「反証を試みろ」と懐疑者の役割を与える
3. 接地（グラウンディング）：事実の主張は、記憶ではなく一次情報（検索・原典）に当たらせる
4. 判断できる出力：指摘に深刻度と根拠を付けさせ、人間が採否を決められる形にする

Claude Codeのサブエージェントは1を構造的に満たしますが、ChatGPTなど単一チャットのツールでは運用でカバーします。手順は3ステップです。

1. 新規セッションを開く（成果物を作った会話は使わない）
2. 成果物だけを貼る（経緯や意図の説明は貼らない。AIが要約などを返してきても無視してよい）
3. 以下の雛形を貼る

最後の「壊せなかった点」には2つの役割があります。成果物の一番堅い部分が分かること、そして全指摘が反証で埋まっていないかという過剰指摘のセンサーになることです。

使う上での注意点：採否を決めるのは人間

限界も押さえておきます。いずれもAnthropic自身が公式に認めているものです。

① 敵対的レビュアーは、健全な成果物にも指摘を出します。 公式ベストプラクティスは「ギャップを探せと指示されたレビュアーは、作業が健全でも大抵何か報告する。全部の指摘を追いかけると過剰設計に行き着く」と警告しています。指摘が出た＝間違っている、ではありません。

② 逆方向の失敗もあります。 検証エージェントの最大の失敗モードは、ろくに検証せず「合格」と判定する手抜きだと公式ブログが明記しています。注意が必要なのはむしろこちらです。①の過剰な指摘は、内容を見れば「言い過ぎだな」と気づいて却下しやすいのですが、敵対的検証の結果は普段の出力以上に「それっぽい」ため、「もう十分だろう」と思ってしまいがちです。「大丈夫」と言われても自分で見る——これは強く心がける必要があります。

③ コストがかかります。 Anthropicの社内テストでは、マルチエージェント構成は同等タスクをシングルエージェントで行う場合の3〜10倍のトークンを消費すると報告されています。公開前の記事、意思決定ドキュメント、リリース前のコードなど、やり直しコストが高い成果物に絞って使うのが現実的です。

④ 検証する側とされる側が同じモデルなら、盲点も共有します。 モデルの知識自体が間違っているタイプの誤りは、同じモデルの検証者ではすり抜ける可能性があります。回避策は2つ。1つは「一次情報に当たって」と接地を指示し、モデルの記憶ではなく外部の情報源で検証させること。もう1つは、重要な成果物では別のモデルに検証させることです（普段Claudeを使っているならCodexやGeminiなど）。前節の雛形を別ツールの新規セッションに貼れば、そのままクロスモデルの敵対的検証になります。

共通する結論は1つです。AIの指摘は正解ではありません。だからこそ、敵対的検証の出力に判定と根拠が付いていることが肝になります。それを材料に、受けるか、弱めて受けるか、却下するか——採否を決めるのは人間です。

この記事も敵対的検証している

採否判断の実例として、この記事自身の検証記録を示します。この記事は執筆前の段階で、切り口・構成・リサーチ結果に対して計8体のスケプティックによる検証をかけています（3節で見せた3つの判定はその一部です）。主な指摘と、私の判断は次のとおりです。

指摘	判断
「一言で発動」はn=1で、環境依存の可能性がある	直せなかった。実験で潰す代わりに、主張を「私の環境ではこうなった」に留めて環境注記を付けた（＝主張を弱めて受けた）
「棄却された叩き台」を成功譚として語るな。棄却が正しかった証拠はない	受けた。「採否を決めるのは人間」を記事の柱に昇格させた（前節がその結果です）
答えの一言が中盤まで出てこない。結論を先に出せ	一部受けた。冒頭に一言を置きつつ、概念から入る骨格は維持した
「一言でやってくれる」という汎用主張はやめて、招待型に書き換えろ	却下した。この記事のキモは手軽さなので、注記で誠実さを担保する道を選んだ

全部は受けていません。受ける、弱めて受ける、却下する。この採否の判断が、敵対的検証を使う側の仕事です。なお本文の事実関係も同じ方法で裏取りしており、「悪魔の代弁者は1983年に廃止された」（誤り。正しくは縮小）という事実誤認や、正しいけど文脈を落として引用すると一般化しすぎになる数字など、そのまま書くと危うい記述が計7件、事前に潰れています。

まとめ

• 「レビューして」でも指摘は返ってきます。「敵対的検証して」は課題がある前提で反証を試み、判定と根拠まで返してくるのが違いです
• Claude Codeなら一言から始められます（筆者の環境ではサブエージェントが立ち、多視点検証が走りました）。敵対的検証自体は公式も推奨するパターンです
• 事実の検証では「一次情報に当たって」を添えてください（接地）
• 返ってきた指摘は鵜呑みにせず、受ける・弱めて受ける・却下する。採否を決めるまでやって完成です

まずは直近のAIの成果物に、この一言を試してみてください。お試しは何にでも、常用はやり直しコストが高い成果物に絞るのがおすすめです。

物足りなければ強化版をどうぞ。