サンタメソッド は何をしますか？
マルチエージェント対抗検証フレームワーク。リストを作り、二度チェックする。いたずらなら、良い子になるまで直す。
核となる洞察：単一のエージェントが自身の出力をレビューすると、その出力を生み出したのと同じバイアス、知識ギャップ、系統的エラーを共有することになる。2つの独立したレビューアーがコンテキストを共有しないことで、この障害モードを打破する。
有効化するタイミング
以下の場合にこのスキルを呼び出してください：
- 出力が公開、デプロイ、またはエンドユーザーに消費される場合
- コンプライアンス、規制、またはブランド上の制約を強制する必要がある場合
- 人間のレビューなしでコードが本番環境に出荷される場合
- コンテンツの正確性が重要な場合（技術文書、教育資料、顧客向けコピー）
- 大規模なバッチ生成でスポットチェックが系統的パターンを見逃す場合
- 幻覚リスクが高い場合（主張、統計、APIリファレンス、法的文言）
内部ドラフト、探索的リサーチ、または決定論的検証が可能なタスク（ビルド/テスト/lintパイプラインを使用）には使用しないでください。
アーキテクチャ
┌─────────────┐
│ 生成 │ フェーズ1: リストを作る
│ (エージェントA)│ 成果物を生成する
└──────┬───────┘
│ 出力
▼
┌──────────────────────────────┐
│ 二重独立レビュー │ フェーズ2: 二度チェックする
│ │
│ ┌───────────┐ ┌───────────┐ │ 2つのエージェント、同じルーブリック、
│ │ レビューアB│ │ レビューアC│ │ コンテキストを共有しない
│ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │
└────────┼──────────────┼───────┘
│ │
▼ ▼
┌──────────────────────────────┐
│ 判定ゲート │ フェーズ3: 良い子かいたずらか
│ │
│ B合格 かつ C合格 → 良い子 │ 両方合格する必要がある。
│ それ以外 → いたずら │ 例外なし。
└──────┬──────────────┬────────┘
│ │
良い子 いたずら
│ │
▼ ▼
[ 出荷 ] ┌─────────────┐
│ 修正ループ │ フェーズ4: 良い子になるまで直す
│ │
│ イテレーション++│ すべてのフラグを収集する。
│ i > MAXの場合:│ すべての問題を修正する。
│ エスカレーション│ 両方のレビューアーを再実行する。
│ それ以外の場合:│ 収束するまでループする。
│ フェーズ2へ│
└──────────────┘
フェーズ詳細
フェーズ1: リストを作る（生成）
主要タスクを実行します。通常の生成ワークフローに変更はありません。サンタメソッドは生成後の検証レイヤーであり、生成戦略ではありません。
# 生成は通常通り実行
output = generate(task_spec)
フェーズ2: 二度チェックする（独立二重レビュー）
2つのレビューエージェントを並行して起動します。重要な不変条件：
- コンテキスト分離 — どちらのレビューアーも相手の評価を見ない
- 同一ルーブリック — 両方に同じ評価基準が渡される
- 同じ入力 — 両方とも元の仕様と生成された出力を受け取る
- 構造化出力 — それぞれが散文ではなく、型付けされた判定を返す
レビュアープロンプト = """
あなたは独立した品質レビューアーです。この出力に関する他のレビューは一切見ていません。
## タスク仕様
{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でnot-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
なぜ両方合格しなければならないのか：片方のレビューアーだけが問題を発見した場合でも、その問題は現実のものです。もう片方のレビューアーの盲点こそ、サンタメソッドが排除しようとする障害モードです。
フェーズ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セッション内で、Agentツールを使用してレビューアーを起動します
# 両方のエージェントが並行して実行され、速度が向上します
# Agentツール呼び出しの疑似コード
reviewer_b = Agent(
description="Santa Review B",
prompt=f"この出力の品質をレビューしてください...
ルーブリック:
{rubric}
出力:
{output}"
)
reviewer_c = Agent(
description="Santa Review C",
prompt=f"この出力の品質をレビューしてください...
ルーブリック:
{rubric}
出力:
{output}"
)
パターンB: 順次インライン（代替）
サブエージェントが利用できない場合、明示的なコンテキストリセットで分離をシミュレートします：
- 出力を生成
- 新しいコンテキスト：「あなたはレビューアー1です。このルーブリックに対してのみ評価してください。問題を見つけてください。」
- 結果をそのまま記録
- コンテキストを完全にクリア
- 新しいコンテキスト：「あなたはレビューアー2です。このルーブリックに対してのみ評価してください。問題を見つけてください。」
- 両方のレビューを比較し、修正、繰り返す
サブエージェントパターンがはるかに優れています — インラインシミュレーションはレビューアー間のコンテキスト漏洩のリスクがあります。
パターンC: バッチサンプリング
大規模バッチ（100+アイテム）の場合、すべてのアイテムに完全なサンタを適用するのはコストが高すぎます。層化サンプリングを使用します：
- ランダムサンプルに対してサンタを実行（バッチの10～15%、最小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人目のレビューアーまたは人間のスポットチェックを追加。 |
| コスト爆発 | 大規模出力でイテレーションが多すぎる | バッチサンプリングパターン。検証サイクルあたりの予算上限。 |
他のスキルとの統合
| スキル | 関係 |
|---|---|
| 検証ループ | 決定論的チェック（ビルド、lint、テスト）に使用。サンタは意味論的チェック（正確性、幻覚）に使用。検証ループを先に実行し、サンタを後に実行。 |
| Eval Harness | サンタメソッドの結果は評価指標にフィードされる。サンタ実行全体のpass@kを追跡して、生成品質の経時変化を測定。 |
| 継続的学習v2 | サンタの発見がインスティンクトになる。同じ基準での繰り返しの失敗 → そのパターンを避けるための学習動作。 |
| Strategic Compact | コンパクト化の前にサンタを実行。検証中のレビューコンテキストを失わない。 |
メトリクス
サンタメソッドの効果を測定するためにこれらを追跡します：
- 初回合格率: ラウンド1でサンタに合格する出力の割合（目標: >70%）
- 収束までの平均イテレーション数: NICEまでの平均ラウンド数（目標: <1.5）
- 問題分類: 障害タイプの分布（幻覚 vs. 完全性 vs. コンプライアンス）
- レビューアー一致率: 両方のレビューアーによってフラグが立てられた問題と片方のみの割合（一致率が低い = ルーブリックの調整が必要）
- エスケープ率: 出荷後に発見され、サンタが捕捉すべきだった問題（目標: 0）
コスト分析
サンタメソッドは、検証サイクル1回あたり、生成単独のトークンコストの約2～3倍かかります。ほとんどの高重要度出力にとって、これは割安です：
サンタのコスト = (生成トークン) + 2×(ラウンドあたりのレビュートークン) × (平均ラウンド数)
サンタを使わない場合のコスト = (評判の損害) + (修正努力) + (信頼の低下)
バッチ運用の場合、サンプリングパターンによりコストは完全検証の約15～20%に削減されながら、系統的問題の90%以上を捕捉します。