■ 1. 「レビューして」と「敵対的検証して」の違い
- 「レビューして」は改善点のリストを返す
- 「敵対的検証して」は「課題がある」前提で反証を試み、指摘に判定と根拠を付けて返す
- 判定と根拠が付くことで、受け手が採否を判断しやすくなる
■ 2. 敵対的検証の思想的背景
- レッドチーム（red teaming）:
- 1960年代の米軍ウォーゲームで敵役を演じたチームに由来
- サイバーセキュリティやAI safetyの分野へ広がり、AnthropicもAIモデルを攻撃的にテストする手法として採用
- 悪魔の代弁者（devil's advocate）:
- カトリック教会の列聖審査に1587年に制度化された役職
- 聖人候補にあえて不利な事実を突きつけ、安易な認定を防ぐ
- 反証主義:
- 科学哲学者カール・ポパーの論：仮説は厳しい反証の試みに耐えることで暫定的に信頼される
- 共通構造:
- 「わざと反対側から叩くことで結論を強くする」という発想
■ 3. Claude Code への組み込み
- Claude Codeの以下の組み込みコマンドには敵対的検証が利用されている
- /deep-research
- /code-review
- /deep-research の構造:
- 複数角度でWeb検索を並列実行しランク付け
- 上位の主張に対して3体の検証エージェントが反証を試み投票
- 3分の2が反証した主張はレポートから除外
- 内部プロンプト：「Be SKEPTICAL. Try to REFUTE this claim.」
- /code-review の構造:
- 複数エージェントが並列でバグを検出
- 指摘ごとに別のエージェントが再検証し、確信度の低い指摘を除外
- 内部プロンプト：「確信が持てないissueはフラグするな。偽陽性は信頼を損なう」
- Anthropic公式ブログによる定義:
- 「Adversarial verification: エージェントに作業させたら、その出力を基準に照らして敵対的に検証する別のエージェントを走らせる」
- 公式ベストプラクティスにも「Add an adversarial review step」という専用セクションが存在
■ 4. 使い方
- 成果物が出た場面で「敵対的検証して」と一言頼むだけ
- 対象を指定する場合：「この設計案を敵対的検証して」
- サブエージェントを明示する場合：「サブエージェントを立てて敵対的に検証して」
- 検証は別のfresh contextを持つサブエージェント側で行われるため、同じセッション内で頼んでよい
■ 5. 「レビューして」より効く2つの理由
- 敵対的な構え:
- 「課題がある」前提で反証を試みる役割を与えるため、指摘に判定と根拠が付く
- fresh context:
- サブエージェントは成果物を作った会話の文脈を引き継がない
- 「これまでの流れ」に迎合できないため、独立した評価が可能
- 2つは掛け算:
- fresh contextでも「レビューして」では課題前提の検討にならない
- 同じ会話内での「反証して」は流れに迎合する可能性がある
- 「敵対的検証して」の一言が両方を同時に引き出す
■ 6. Claude Code以外での使い方と要件
- 敵対的検証を成立させる4要件:
- 独立性：成果物を作った文脈と切り離したまっさらな目に検証させる
- 反証の役割づけ：懐疑者の役割を与える
- 接地（グラウンディング）：事実の主張は一次情報（検索・原典）に当たらせる
- 判断できる出力：指摘に深刻度と根拠を付けさせ人間が採否を決められる形にする
- 単一チャットツールでの手順（3ステップ）:
- 新規セッションを開く（成果物を作った会話は使わない）
- 成果物だけを貼る（経緯や意図の説明は貼らない）
- 敵対的検証プロンプト雛形を貼る
- プロンプト雛形の要点:
- 独立した懐疑的なレビュアー（skeptic）として反証に徹するよう指定
- 良い点は書かず、成立しない可能性のある箇所だけを挙げる
- 事実の主張はWeb検索や一次情報で裏を取り、確認できなければ「未検証」と明記
- 出力形式：指摘・深刻度・根拠・確度の4項目を付ける
- 最後に「反証を試みたが壊せなかった点」を記載
■ 7. 注意点と限界
- 過剰指摘:
- 敵対的レビュアーは健全な成果物にも指摘を出す
- 公式ベストプラクティスの警告：「全指摘を追いかけると過剰設計に行き着く」
- 手抜き判定:
- 検証エージェントの最大の失敗モードは「ろくに検証せず合格と判定する手抜き」（公式ブログ）
- 「大丈夫」と言われても自分で確認する姿勢が必要
- コスト:
- マルチエージェント構成はシングルエージェントの3〜10倍のトークンを消費（Anthropic社内テスト）
- やり直しコストが高い成果物に絞って使うのが現実的
- 同一モデルの盲点:
- 検証する側とされる側が同じモデルなら盲点も共有する
- 回避策1：「一次情報に当たって」と接地を指示する
- 回避策2：重要な成果物では別のモデルに検証させる（クロスモデル検証）
- 共通する結論:
- AIの指摘は正解ではない
- 受ける・弱めて受ける・却下する採否判断が人間の仕事
■ 8. 記事自体への敵対的検証の適用例
- 執筆前に切り口・構成・リサーチ結果に対して計8体のスケプティックによる検証を実施
- 主な指摘と採否判断:
- 「一言で発動はn=1で環境依存の可能性」→ 主張を「私の環境ではこうなった」に留め環境注記を付けた（弱めて受けた）
- 「棄却された叩き台を成功譚として語るな」→ 「採否を決めるのは人間」を記事の柱に昇格させた（受けた）
- 「答えの一言が中盤まで出てこない」→ 冒頭に一言を置きつつ概念から入る骨格は維持した（一部受けた）
- 「一言でやってくれるという汎用主張はやめろ」→ 注記で誠実さを担保する道を選んだ（却下した）
- 事実関係の裏取りで計7件の危うい記述を事前に排除