everything-claude-code/docs/ja-JP/skills/santa-method/SKILL.md

name, description, origin

name	description	origin
santa-method	収束ループを持つマルチエージェント敵対的検証。2つの独立したレビューエージェントが両方合格して初めて出力を出荷できます。	Ronald Skelton - Founder, RapportScore.ai

Santa Method

マルチエージェント敵対的検証フレームワーク。リストを作り、二度確認する。問題があれば、良くなるまで修正する。

核心的な洞察: 自分の出力をレビューする単一のエージェントは、その出力を生み出したのと同じバイアス、知識のギャップ、体系的なエラーを共有しています。共有コンテキストを持たない2人の独立したレビュアーは、この障害モードを解消します。

起動するタイミング

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

• 出力が公開、デプロイ、またはエンドユーザーに提供される場合
• コンプライアンス、規制、またはブランドの制約が適用される必要がある場合
• コードが人間のレビューなしに本番環境にデプロイされる場合
• コンテンツの正確性が重要な場合（技術文書、教育資料、顧客向けコピー）
• スポットチェックで体系的なパターンを見逃す可能性のある大規模バッチ生成
• ハルシネーションリスクが高い場合（主張、統計、API リファレンス、法的言語）

内部ドラフト、探索的調査、または確定的な検証がある場合（それらにはビルド/テスト/Lint パイプラインを使用）には使用しないでください。

アーキテクチャ

┌─────────────┐
│  GENERATOR   │  フェーズ1: リストを作る
│  (Agent A)   │  成果物を生成する
└──────┬───────┘
       │ output
       ▼
┌──────────────────────────────┐
│     DUAL INDEPENDENT REVIEW   │  フェーズ2: 二度確認する
│                                │
│  ┌───────────┐ ┌───────────┐  │  2つのエージェント、同じルーブリック、
│  │ Reviewer B │ │ Reviewer C │  │  共有コンテキストなし
│  └─────┬─────┘ └─────┬─────┘  │
│        │              │        │
└────────┼──────────────┼────────┘
         │              │
         ▼              ▼
┌──────────────────────────────┐
│        VERDICT GATE           │  フェーズ3: 良いか悪いか
│                                │
│  B passes AND C passes → NICE  │  両方が合格する必要がある。
│  Otherwise → NAUGHTY           │  例外なし。
└──────┬──────────────┬─────────┘
       │              │
    NICE           NAUGHTY
       │              │
       ▼              ▼
   [ SHIP ]    ┌─────────────┐
               │  FIX CYCLE   │  フェーズ4: 良くなるまで修正
               │              │
               │ iteration++  │  全フラグを収集する。
               │ if i > MAX:  │  全問題を修正する。
               │   escalate   │  両レビュアーを再実行する。
               │ else:        │  収束するまでループ。
               │   goto Ph.2  │
               └──────────────┘

フェーズの詳細

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

主要タスクを実行します。通常の生成ワークフローに変更はありません。Santa Method は生成後の検証レイヤーであり、生成戦略ではありません。

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

フェーズ2: 二度確認する（独立したデュアルレビュー）

2つのレビューエージェントを並列で起動します。重要な不変条件:

1. コンテキスト分離 — どちらのレビュアーも相手の評価を見ない
2. 同一ルーブリック — 両方が同じ評価基準を受け取る
3. 同じ入力 — 両方がオリジナルの仕様と生成された出力を受け取る
4. 構造化出力 — それぞれが散文ではなく型付き判定を返す

REVIEWER_PROMPT = """
あなたは独立した品質レビュアーです。この出力に対する他のレビューは見ていません。

## タスク仕様
{task_spec}

## レビュー対象の出力
{output}

## 評価ルーブリック
{rubric}

## 指示
各ルーブリック基準に対して出力を評価してください。それぞれに対して:
- PASS: 基準が完全に満たされ、問題なし
- FAIL: 特定の問題が見つかった（正確な問題を引用）

評価を構造化JSONとして返してください:
{
  "verdict": "PASS" | "FAIL",
  "checks": [
    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
  ],
  "critical_issues": ["..."],   // 修正が必要なブロッカー
  "suggestions": ["..."]         // ブロックしない改善提案
}

厳格に評価してください。あなたの仕事は問題を見つけることであり、承認することではありません。
"""

# レビュアーを並列で起動（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: 良いか悪いかの判定（Verdict Gate）

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人のレビュアーだけが問題を検知した場合、その問題は実在します。もう1人のレビュアーのブラインドスポットこそ、Santa Method が解消しようとしている障害モードです。

フェーズ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="フラグが立てられた問題のみを修正してください。リファクタリングや未要求の変更は行わないでください。"
    )

    # 修正した出力で両方のレビュアーを再実行する（新しいエージェント、前のラウンドの記憶なし）
    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 セッションでエージェントツールを使用してレビュアーを起動する
# 速度のために両エージェントを並列で実行する

# エージェントツール呼び出しの擬似コード
reviewer_b = Agent(
    description="Santa Review B",
    prompt=f"この出力の品質をレビューしてください...\n\nルーブリック:\n{rubric}\n\n出力:\n{output}"
)
reviewer_c = Agent(
    description="Santa Review C",
    prompt=f"この出力の品質をレビューしてください...\n\nルーブリック:\n{rubric}\n\n出力:\n{output}"
)

パターンB: 逐次インライン（フォールバック）

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

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

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

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

大規模バッチ（100件以上）の場合、全アイテムへの完全な Santa 適用はコスト的に非現実的です。層別サンプリングを使用します:

1. ランダムサンプルで Santa を実行（バッチの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人目のレビュアーか人間のスポットチェックを追加
コスト爆発	大規模出力に対して多すぎるイテレーション	バッチサンプリングパターン。検証サイクルあたりの予算上限。

他のスキルとの統合

スキル	関係
Verification Loop	確定的なチェック（ビルド、Lint、テスト）に使用。Santa はセマンティックチェック（正確性、ハルシネーション）に使用。先に検証ループを実行し、その後 Santa を実行。
Eval ハーネス	Santa Method の結果がEval メトリクスに反映される。Santa の実行全体で pass@k を追跡して、経時的なジェネレーターの品質を測定。
Continuous Learning v2	Santa の発見が本能になる。同じ基準での繰り返し失敗 → パターンを避ける学習された行動。
Strategic Compact	コンパクト前に Santa を実行する。検証途中でレビューコンテキストを失わない。

メトリクス

Santa Method の効果を測定するためにこれらを追跡します:

• 初回合格率: ラウンド1で Santa を通過する出力の % （目標: >70%）
• 収束までの平均イテレーション: NICE になるまでの平均ラウンド数（目標: <1.5）
• 問題の分類: 失敗の種類の分布（ハルシネーション対完全性対コンプライアンス）
• レビュアー合意: 両方のレビュアーがフラグを立てた問題 対 片方のみの % （低い合意 = ルーブリックの改善が必要）
• エスケープ率: Santa が検知すべきだったが出荷後に見つかった問題（目標: 0）

コスト分析

Santa Method は検証サイクルあたり、生成単体のトークンコストの約2〜3倍のコストがかかります。高リスクな出力のほとんどにとって、これは割安です:

Santa のコスト = (生成トークン) + 2×(ラウンドあたりのレビュートークン) × (平均ラウンド数)
Santa を使わないコスト = (評判の損害) + (修正の労力) + (信頼の侵食)

バッチ操作では、サンプリングパターンにより、体系的な問題の>90%を検知しながら、完全な検証の約15〜20%のコストに削減されます。