Adversarial Review（対立的レビュー）

成果物を「採点」するのではなく、破綻させにいく専任の敵対者を立てる。最も強い反例・悪用経路・前提の穴を能動的に探させ、その指摘で成果物を堅くする。協調的な評価器が見逃す、攻撃してはじめて露わになる失敗を捕まえるパターンである。

別名

呼称	出典
Red-Teaming / Devil's Advocate	セキュリティ・意思決定レビューの慣用
Multi-Agent Debate	Du et al.（複数モデルが討論して結論を検証）
Adversarial Critic	一般的呼称

問題

Evaluator-Optimizer と Reflection は「基準に照らして良いか？」を問う。だが協調的な評価器がルーブリックを埋めるだけでは、攻撃してはじめて見える失敗——セキュリティホール、境界値、隠れた前提、プロンプトインジェクション耐性、仕様の悪用（spec gaming）——を取りこぼす。

「品質を確認して」と頼まれた評価者は減点法で採点し、「破ってみせて」と頼まれた評価者は穴を攻める。問いの立て方が、見つかるものを変える。誤りが敵対的に悪用されうる領域では、協調的な評価だけでは頑健性を保証できない。

コンテキスト

適用する:

誤りが敵対的に悪用されうる成果物（セキュリティ、外部公開API、認証・課金ロジック）
前提の穴や境界条件が致命的なタスク、高リスクな意思決定の頑健性検証

適用しない（不要な）ケース:

明確なルーブリックで良否を尽くせるタスク——Evaluator-Optimizer で十分
時間予算が秒単位のタスク——攻防の反復は時間を食う
低リスクな出力——敵対者を「勝たせる」検証が費用に見合わない

解決

目的関数が生成側と逆のエージェントを立てる。その任務は成果物を採点することではなく、破綻させる最も強い反例・悪用経路・見落としを1つ見つけることである。見つかった破綻を塞ぎ、再度攻めさせる。討論形式（2体が対立する立場で論じ、審判が判定する）やレッド／ブルーチーム形式にもできる。反復は上限で止める（Budget Guard）。

python

def adversarial_review(artifact, max_rounds=3):
    for _ in range(max_rounds):
        attack = llm(                       # 敵対者: 破綻を探すのが任務（生成側と逆の目的）
            "この成果物を破綻させる最も強い反例・悪用経路・見落としを1つ挙げよ。"
            "無ければ「破綻なし」とだけ答えよ",
            artifact=artifact, role="adversary", context=None,   # 生成側の推論は渡さない
        )
        if "破綻なし" in attack:
            return artifact
        artifact = llm(                     # 生成側: 指摘された破綻を塞ぐ
            "指摘された破綻を塞いだ版を生成せよ",
            artifact=artifact, attack=attack,
        )
    return {"artifact": artifact, "residual_attack": attack}   # 残存指摘を添えて返す

実装の要点:

敵対者の目的関数を「破ること」にする。 「良いか評価して」ではなく「破ってみせろ」と指示する。インセンティブを生成側と逆に置くことが、この構造の核心
決定的な一撃を優先させる。 網羅的な採点より、最も効く反例・悪用を1つ探させる。見つけたら塞ぎ、再度攻めさせる
独立性を担保する。 生成側の推論過程を敵対者へ渡さない（Evaluator-Optimizer と同じく分離が効く）。討論形式では審判を別に立てる
反復を上限で止める。 攻防が発散する場合に備え Budget Guard を併用し、残存する指摘を添えて返す

トレードオフ

✅ 協調的な評価では出ない、悪用経路・境界条件・隠れた前提の破綻を発見できる
✅ セキュリティや高リスクな意思決定の頑健性を、出荷前に敵対的な観点で検証できる
⚠️ 呼出数が増え、コストとレイテンシが上がる。攻防が発散すれば Budget Guard で止める必要がある
⚠️ 敵対者が的外れな攻撃に固執すると空回りする。攻撃自体の妥当性を評価する仕組みが要る場合がある

クラウドパターンとの対応

クラウドパターン	本パターンでの再定義
（直接の対応は薄い）	古典的なクラウドデザインパターンに直接の祖先を持たない。強いて言えば Gatekeeper を「検証」ではなく「攻撃」として運用する構図に近い

これは、ソフトウェアのレッドチーム演習、N-version programming（多様な独立実装の相互検証）、コードレビューを「敵対的な読み」として行う実践の系譜に位置づけられる。

出典・参考

Du et al. — Improving Factuality and Reasoning in Language Models through Multiagent Debate（複数エージェントの討論による検証）
Anthropic — Building Effective Agents（独立した評価器・多視点による検証）
Microsoft — AI Agent Orchestration Patterns（maker-checker/critic の系譜。本パターンはこれを敵対的な目的関数へ振り切ったもの）

Adversarial Review（対立的レビュー） ​

別名 ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

クラウドパターンとの対応 ​

関連パターン ​

出典・参考 ​

Adversarial Review（対立的レビュー）

別名

問題

コンテキスト

解決

トレードオフ

クラウドパターンとの対応

関連パターン

出典・参考