Santa Method
マルチエージェント敵対的検証フレームワーク。リストを作り、二度確認する。問題があれば、良くなるまで修正する。
核心的な洞察: 自分の出力をレビューする単一のエージェントは、その出力を生み出したのと同じバイアス、知識のギャップ、体系的なエラーを共有しています。共有コンテキストを持たない2人の独立したレビュアーは、この障害モードを解消します。
起動するタイミング
以下の場合にこのスキルを呼び出します:
- 出力が公開、デプロイ、またはエンドユーザーに提供される場合
- コンプライアンス、規制、またはブランドの制約が適用される必要がある場合
- コードが人間のレビューなしに本番環境にデプロイされる場合
- コンテンツの正確性が重要な場合(技術文書、教育資料、顧客向けコピー)
- スポットチェックで体系的なパターンを見逃す可能性のある大規模バッチ生成
- ハルシネーションリスクが高い場合(主張、統計、API リファレンス、法的言語)
内部ドラフト、探索的調査、または確定的な検証がある場合(それらにはビルド/テスト/Lint パイプラインを使用)には使用しないでください。
アーキテクチャ
フェーズの詳細
フェーズ1: リストを作る(生成)
主要タスクを実行します。通常の生成ワークフローに変更はありません。Santa Method は生成後の検証レイヤーであり、生成戦略ではありません。
フェーズ2: 二度確認する(独立したデュアルレビュー)
2つのレビューエージェントを並列で起動します。重要な不変条件:
- コンテキスト分離 — どちらのレビュアーも相手の評価を見ない
- 同一ルーブリック — 両方が同じ評価基準を受け取る
- 同じ入力 — 両方がオリジナルの仕様と生成された出力を受け取る
- 構造化出力 — それぞれが散文ではなく型付き判定を返す
ルーブリックの設計
ルーブリックは最も重要な入力です。曖昧なルーブリックは曖昧なレビューを生みます。すべての基準には客観的な合否条件が必要です。
ドメイン固有のルーブリック拡張
コンテンツ/マーケティング:
- ブランドボイスの遵守
- SEO要件の充足(キーワード密度、メタタグ、構造)
- 競合他社の商標の誤用なし
- CTAが存在し正しくリンクされている
コード:
- 型安全性(
anyリークなし、適切なnull処理) - エラー処理のカバレッジ
- セキュリティ(コードにシークレットなし、入力検証、インジェクション防止)
- 新しいパスのテストカバレッジ
コンプライアンスが重要な場合(規制対象、法的、財務的):
- 結果の保証や根拠のない主張なし
- 必要な免責事項が存在する
- 承認された用語のみ
- 管轄区域に適した言語
フェーズ3: 良いか悪いかの判定(Verdict Gate)
両方が合格する必要がある理由: 1人のレビュアーだけが問題を検知した場合、その問題は実在します。もう1人のレビュアーのブラインドスポットこそ、Santa Method が解消しようとしている障害モードです。
フェーズ4: 良くなるまで修正する(収束ループ)
重要: 各レビューラウンドは新鮮なエージェントを使用します。レビュアーは前のラウンドの記憶を持ってはいけません。前のコンテキストはアンカリングバイアスを生み出すためです。
実装パターン
パターンA: Claude Code サブエージェント(推奨)
サブエージェントは真のコンテキスト分離を提供します。各レビュアーは共有状態を持たない別個のプロセスです。
パターンB: 逐次インライン(フォールバック)
サブエージェントが利用できない場合、明示的なコンテキストリセットで分離をシミュレートします:
- 出力を生成する
- 新しいコンテキスト: 「あなたはレビュアー1です。このルーブリックのみに対して評価してください。問題を見つけてください。」
- 所見を逐語的に記録する
- コンテキストを完全にクリアする
- 新しいコンテキスト: 「あなたはレビュアー2です。このルーブリックのみに対して評価してください。問題を見つけてください。」
- 両方のレビューを比較し、修正して繰り返す
サブエージェントパターンは厳密に優れています — インラインシミュレーションはレビュアー間のコンテキスト漏れのリスクがあります。
パターンC: バッチサンプリング
大規模バッチ(100件以上)の場合、全アイテムへの完全な Santa 適用はコスト的に非現実的です。層別サンプリングを使用します:
- ランダムサンプルで Santa を実行(バッチの10〜15%、最低5件)
- 種類別に失敗を分類(ハルシネーション、コンプライアンス、完全性など)
- 体系的なパターンが現れた場合、バッチ全体に対象を絞った修正を適用
- 修正されたバッチを再サンプリングして再検証
- クリーンなサンプルが合格するまで継続
障害モードと緩和策
他のスキルとの統合
メトリクス
Santa Method の効果を測定するためにこれらを追跡します:
- 初回合格率: ラウンド1で Santa を通過する出力の % (目標: >70%)
- 収束までの平均イテレーション: NICE になるまでの平均ラウンド数(目標: <1.5)
- 問題の分類: 失敗の種類の分布(ハルシネーション対完全性対コンプライアンス)
- レビュアー合意: 両方のレビュアーがフラグを立てた問題 対 片方のみの % (低い合意 = ルーブリックの改善が必要)
- エスケープ率: Santa が検知すべきだったが出荷後に見つかった問題(目標: 0)
コスト分析
Santa Method は検証サイクルあたり、生成単体のトークンコストの約2〜3倍のコストがかかります。高リスクな出力のほとんどにとって、これは割安です:
バッチ操作では、サンプリングパターンにより、体系的な問題の>90%を検知しながら、完全な検証の約15〜20%のコストに削減されます。



