santa-method

name santa-method description 収束ループを持つマルチエージェント敵対的検証。2つの独立したレビューエージェントが両方合格して初めて出力を出荷できます。 origin 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つのレビューエージェントを並列で起動します。重要な不変条件: コンテキスト分離 — どちらのレビュアーも相手の評価を見ない 同一ルーブリック — 両方が同じ評価基準を受け取る 同じ入力 — 両方がオリジナルの仕様と生成された出力を受け取る 構造化出力 — それぞれが散文ではなく型付き判定を返す 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です。このルーブリックのみに対して評価してください。問題を見つけてください。」 両方のレビューを比較し、修正して繰り返す サブエージェントパターンは厳密に優れています — インラインシミュレーションはレビュアー間のコンテキスト漏れのリスクがあります。 パターンC: バッチサンプリング 大規模バッチ（100件以上）の場合、全アイテムへの完全な Santa 適用はコスト的に非現実的です。層別サンプリングを使用します: ランダムサンプルで Santa を実行（バッチの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人目のレビュアーか人間のスポットチェックを追加 コスト爆発 大規模出力に対して多すぎるイテレーション バッチサンプリングパターン。検証サイクルあたりの予算上限。 他のスキルとの統合 スキル 関係 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%のコストに削減されます。