サンタ方式

マルチエージェント対抗検証フレームワーク。リストを作成し、2回チェックする。行動が悪い場合は、良い結果が得られるまで修正する。

コアインサイト：単一のエージェントが自身の出力をレビューするとき、その出力を生成した同じバイアス、知識の盲点、システム的エラーを共有する。共有コンテキストを持たない2つの独立した審査者は、このフェイルモード（故障様式）を打ち破ることができる。

いつアクティベートするか

以下の場合にこのスキルを呼び出します：

• 出力は公開、デプロイ、またはエンドユーザー向けに使用される
• コンプライアンス、規制、またはブランド制約を強制する必要がある
• コードは人間レビューなしで本番環境に配置される
• コンテンツの正確性が重要である（技術文書、教育資料、カスタマー向けコピー）
• 大規模バッチ生成であり、抜き取り検査では体系的なパターンを発見できない
• 幻覚リスクが高い（クレーム、統計、API リファレンス、法的言語）

使用しないでください：内部ドラフト、探索的研究、または決定論的検証を備えたタスク（これらはビルド/テスト/コード検査パイプラインを使用してください）。

アーキテクチャ

┌─────────────┐
│  ジェネレータ │  フェーズ 1：リストを作成
│  (エージェント A)│  成果物を生成
└──────┬───────┘
       │ 出力
       ▼
┌──────────────────────────────┐
│     二重独立審査              │  フェーズ 2：2回チェック
│                              │
│  ┌───────────┐ ┌───────────┐ │  2つのエージェント、同じスコアリング基準、
│  │ 審査者 B  │ │ 審査者 C  │ │  共有コンテキストなし
│  └─────┬─────┘ └─────┬─────┘ │
│        │              │       │
└────────┼──────────────┼───────┘
         │              │
         ▼              ▼
┌──────────────────────────────┐
│       判定ゲート              │  フェーズ 3：良い悪いを判定
│                              │
│  B合格かつC合格 → 良い       │  両者が合格する必要があります。
│  そうでなければ → 悪い       │  例外なし。
└──────┬──────────────┬────────┘
       │              │
      良い           悪い
       │              │
       ▼              ▼
   [ 公開 ]    ┌─────────────┐
               │  修正ループ  │  フェーズ 4：良い結果まで修正
               │              │
               │ イテレーション++│  すべてのフラグを収集します。
               │ if i > 最大値: │  すべての問題を修正します。
               │   エスカレート │  両方の審査者を再実行します。
               │ else:        │  収束まで繰り返します。
               │   フェーズ2へ │
               └──────────────┘

フェーズの詳細

フェーズ 1：リストを作成（生成）

主要なタスクを実行します。通常の生成ワークフローは変更しないでください。サンタ方式は生成戦略ではなく、生成後の検証レイヤーです。

# ジェネレータは通常通り実行
output = generate(task_spec)

フェーズ 2：2回チェック（独立二重審査）

2つの審査エージェントを並行して生成します。重要な不変式：

1. コンテキスト分離 — 2つの審査者は互いの評価を見ない
2. 同じスコアリング基準 — 両者が同じスコアリング基準を受け取る
3. 同じ入力 — 両者が元の仕様と生成された出力を受け取る
4. 構造化出力 — 各審査者は散文ではなく型付きの判定を返す

REVIEWER_PROMPT = """
You are an independent quality reviewer. You have NOT seen any other review of this output.

## Task Specification
{task_spec}

## Output Under Review
{output}

## Evaluation Rubric
{rubric}

## Instructions
Evaluate the output against EACH rubric criterion. For each:
- PASS: criterion fully met, no issues
- FAIL: specific issue found (cite the exact problem)

Return your assessment as structured JSON:
{
  "verdict": "PASS" | "FAIL",
  "checks": [
    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
  ],
  "critical_issues": ["..."],   // blockers that must be fixed
  "suggestions": ["..."]         // non-blocking improvements
}

Be rigorous. Your job is to find problems, not to approve.
"""

# 並行してレビュアーをスポーン (Claude Code サブエージェント)
review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer B")
review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer C")

# 両方が同時に実行 — どちらも相手を見ない

スコアリング基準の設計

スコアリング基準が最も重要な入力です。曖昧な基準は曖昧なレビューを生み出します。各基準には客観的な合格/不合格条件が必要です。

基準	合格条件	失敗信号
事実の正確性	すべての主張がソース資料または常識から検証可能	作られた統計、誤ったバージョン番号、存在しない API
幻覚なし	架空のエンティティ、引用、URL、または参考文献なし	存在しないページへのリンク、出所不明の引用
完全性	仕様のすべての要件が満たされている	欠落したセクション、漏れたエッジケース、不完全なカバレッジ
コンプライアンス	プロジェクト固有のすべての制約に合格	禁止用語の使用、トーン違反、規制不遵守
内部一貫性	出力内に矛盾なし	パートAがXと言い、パートBがXでないと言う
技術的正確性	コードがコンパイル/実行可能、アルゴリズムが合理的	構文エラー、ロジックエラー、誤った複雑性の主張

ドメイン固有のスコアリング基準拡張

コンテンツ/マーケティング：

• ブランドトーンの一貫性
• SEO 要件を満たす（キーワード密度、メタタグ、構造）
• 競合他社の商標乱用なし
• CTA の存在と正しいリンク

コード：

• 型安全性（any 流出なし、null の正しい処理）
• エラーハンドリングカバレッジ
• セキュリティ（コード内にシークレットなし、入力検証、インジェクション保護）
• 新しいパスのテストカバレッジ

コンプライアンス対応（規制、法律、金融）：

• 結果保証なし、未検証の主張なし
• 必要な免責事項が存在
• 承認済みの用語のみを使用
• 管轄権の言語に準拠

フェーズ 3：良い悪いを判定（判定ゲート）

def santa_verdict(review_b, review_c):
    """両方のレビュアーが合格する必要があります。部分的なクレジットなし。"""
    if review_b.verdict == "PASS" and review_c.verdict == "PASS":
        return "NICE"  # 公開する

    # 両方のレビュアーからフラグをマージ、重複排除
    all_issues = dedupe(review_b.critical_issues + review_c.critical_issues)
    all_suggestions = dedupe(review_b.suggestions + review_c.suggestions)

    return "NAUGHTY", all_issues, all_suggestions

なぜ両方が合格する必要があるのか：1つのレビュアーだけが問題を見つけた場合、その問題は実在します。もう一つのレビュアーの盲点こそが、サンタ方式が排除しようとしているフェイルモードです。

フェーズ 4：良い結果まで修正（収束ループ）

MAX_ITERATIONS = 3

for iteration in range(MAX_ITERATIONS):
    verdict, issues, suggestions = santa_verdict(review_b, review_c)

    if verdict == "NICE":
        log_santa_result(output, iteration, "passed")
        return ship(output)

    # すべての重大な問題を修正 (提案はオプション)
    output = fix_agent.execute(
        output=output,
        issues=issues,
        instruction="Fix ONLY the flagged issues. Do not refactor or add unrequested changes."
    )

    # 修正済み出力で両方のレビュアーを再実行 (新しいエージェント、前のラウンドの記憶なし)
    review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
    review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))

# イテレーション数が尽きた — エスカレート
log_santa_result(output, MAX_ITERATIONS, "escalated")
escalate_to_human(output, issues)

重要：各ラウンドでまったく新しいエージェントを使用します。レビュアーは前のラウンドの記憶を持ってはいけません。前のコンテキストはアンカリングバイアスを引き起こすからです。

実装パターン

パターン A：Claude Code サブエージェント（推奨）

サブエージェントは真の文脈分離を提供します。各レビュアーは共有状態のない独立したプロセスです。

# Claude Code セッションで、Agent ツールを使用してレビュアーをスポーンします
# 両方のエージェントが速度のために並行して実行

# Agent ツール呼び出しのための擬似コード
reviewer_b = Agent(
    description="Santa Review B",
    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
)
reviewer_c = Agent(
    description="Santa Review C",
    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
)

パターン B：順序付きインライン（代替案）

サブエージェントが利用不可の場合、明示的なコンテキストリセットで分離をシミュレートします：

1. 出力を生成
2. 新しいコンテキスト：「あなたはレビュアー1です。このスコアリング基準のみに基づいて評価します。問題を見つけてください。」
3. 発見を逐語的に記録
4. コンテキストを完全にクリア
5. 新しいコンテキスト：「あなたはレビュアー2です。このスコアリング基準のみに基づいて評価します。問題を見つけてください。」
6. 2つのレビューを比較し、修正し、繰り返す

サブエージェントパターンはインラインシミュレーションより厳密に優れています — インラインシミュレーションはレビュアー間のコンテキスト流出のリスクがあります。

パターン C：バッチサンプリング

大規模バッチ（100+ 項目）の場合、各項目に対して完全なサンタ方式を実行するのはコストが高いです。階層化サンプリングを使用します：

1. ランダムサンプル（バッチの 10-15%、最小 5 項目）でサンタ方式を実行
2. 失敗をタイプ別に分類（幻覚、コンプライアンス、完全性など）
3. システム的なパターンが出現した場合、バッチ全体に対してターゲット修正を適用
4. 修正されたバッチを再サンプルして再検証
5. クリーンなサンプルが合格するまで続ける

import random

def santa_batch(items, rubric, sample_rate=0.15):
    sample = random.sample(items, max(5, int(len(items) * sample_rate)))

    for item in sample:
        result = santa_full(item, rubric)
        if result.verdict == "NAUGHTY":
            pattern = classify_failure(result.issues)
            items = batch_fix(items, pattern)  # パターンに一致するすべての項目を修正
            return santa_batch(items, rubric)   # 再サンプル

    return items  # クリーンサンプル → バッチを公開

フェイルモードと緩和措置

フェイルモード	症状	緩和措置
無限ループ	修正後もレビュアーが引き続き新しい問題を見つける	最大反復回数制限（3回）。エスカレート。
ゴム判子	両方のレビュアーがすべてに合格	対抗的なプロンプト：「あなたの仕事は承認することではなく、問題を見つけることです。」
主観的ドリフト	レビュアーはエラーではなくスタイル設定をフラグ付けする	厳密なスコアリング基準、客観的な合格/不合格のみ
修正リグレッション	問題 A を修正すると問題 B が導入される	各ラウンドで新しいレビュアーを使用してリグレッションをキャッチ
レビュアー一致バイアス	両方のレビュアーが同じことを見落とす	独立性が緩和しますが排除はできません。重要な出力の場合、3番目のレビュアーを追加するか、人間による抽出検査を実施します。
コスト暴走	大規模な出力でイテレーション数が多すぎる	バッチサンプリングパターン。検証サイクルごとの予算上限。

他のスキルとの統合

スキル	関係
検証ループ	決定論的チェック（ビルド、コード検査、テスト）に使用。サンタ方式は意味論的チェック（正確性、幻覚）に使用。まず検証ループを実行し、次にサンタ方式を実行します。
評価ツール	サンタ方式の結果を評価メトリクスにフィードバック。サンタ方式実行でのpass@k を追跡して、生成器の品質を時系列で測定します。
継続学習 v2	サンタ方式の発見が本能になります。同じ基準での繰り返される失敗 → そのパターンを回避するために学習した行動。
戦略圧縮	圧縮の前にサンタ方式を実行します。検証プロセス中にレビューコンテキストを失わないでください。

メトリクス

サンタ方式の有効性を測定するために、以下のメトリクスを追跡します：

• 初回合格率：最初のラウンドでサンタ方式に合格する出力の割合（目標：>70%）
• 収束平均反復数：「良い」に到達するまでの平均ラウンド数（目標：<1.5）
• 問題分類：失敗タイプの分布（幻覚 vs. 完全性 vs. コンプライアンス）
• レビュアー一致度：両方のレビュアーがフラグを付けた問題 vs. 1つのレビュアーのみがフラグを付けた問題の割合（一致度が低い＝スコアリング基準を厳しくする必要あり）
• 逃亡率：サンタ方式がキャッチすべきだった公開後に検出された問題（目標：0）

コスト分析

各検証サイクルについて、サンタ方式のトークンコストは単独生成のおよそ 2-3 倍です。ほとんどの高リスク出力については、これはコスト効率が高いです：

サンタの費用 = (生成トークン) + 2×(ラウンドごとのレビュートークン) × (平均ラウンド数)
サンタなしの費用 = (評判ダメージ) + (修正努力) + (信頼の侵食)

バッチ操作の場合、サンプリングパターンはコストを完全検証の約 15-20% に削減しながら、システム的問題の 90% 以上をキャッチします。