everything-claude-code/docs/ja-JP/commands/santa-loop.md

---
description: 敵対的デュアルレビュー収束ループ — 2つの独立したモデルレビュアーがコード出荷前に両方とも承認する必要があります。
---

# Santa Loop

santa-methodスキルを使用した敵対的デュアルレビュー収束ループ。2つの独立したレビュアー（異なるモデル、共有コンテキストなし）が、コード出荷前に両方ともNICEを返す必要があります。

## 目的

現在のタスク出力に対して2つの独立したレビュアー（Claude Opus + 外部モデル）を実行します。コードがプッシュされる前に、両方がNICEを返す必要があります。どちらかがNAUGHTYを返した場合、フラグが立てられたすべての問題を修正し、コミットして、新しいレビュアーで再実行します（最大3ラウンド）。

## 使い方

```
/santa-loop [file-or-glob | description]
```

## ワークフロー

### ステップ 1: レビュー対象の特定

`$ARGUMENTS` からスコープを判定するか、コミットされていない変更にフォールバックします：

```bash
git diff --name-only HEAD
```

すべての変更ファイルを読み取り、完全なレビューコンテキストを構築します。`$ARGUMENTS` がパス、ファイル、または説明を指定している場合は、それをスコープとして使用します。

### ステップ 2: ルーブリックの構築

レビュー対象のファイルタイプに適したルーブリックを構築します。すべての基準には客観的なPASS/FAIL条件が必要です。最低限以下を含めてください：

| 基準 | 合格条件 |
|------|----------|
| 正確性 | ロジックが正しく、バグがなく、エッジケースを処理している |
| セキュリティ | シークレット、インジェクション、XSS、OWASP Top 10の問題がない |
| エラーハンドリング | エラーが明示的に処理され、暗黙的な無視がない |
| 完全性 | すべての要件が対処され、欠落ケースがない |
| 内部一貫性 | ファイル間またはセクション間の矛盾がない |
| リグレッションなし | 変更が既存の動作を壊さない |

ファイルタイプに基づいてドメイン固有の基準を追加します（例：TSの型安全性、Rustのメモリ安全性、SQLのマイグレーション安全性）。

### ステップ 3: デュアル独立レビュー

Agentツールを使用して2つのレビュアーを**並列で**起動します（同時実行のために両方を1つのメッセージで起動）。判定ゲートに進む前に、両方が完了する必要があります。

各レビュアーはすべてのルーブリック基準をPASSまたはFAILとして評価し、構造化されたJSONを返します：

```json
{
  "verdict": "PASS" | "FAIL",
  "checks": [
    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
  ],
  "critical_issues": ["..."],
  "suggestions": ["..."]
}
```

判定ゲート（ステップ 4）はこれらをNICE/NAUGHTYにマッピングします：両方PASS → NICE、どちらかFAIL → NAUGHTY。

#### レビュアー A: Claudeエージェント（常に実行）

完全なルーブリック + レビュー対象のすべてのファイルを持つエージェント（subagent_type: `code-reviewer`、model: `opus`）を起動します。プロンプトには以下を含める必要があります：
- 完全なルーブリック
- レビュー対象のすべてのファイル内容
- 「あなたは独立した品質レビュアーです。他のレビューは見ていません。あなたの仕事は問題を見つけることであり、承認することではありません。」
- 上記の構造化されたJSON判定を返すこと

#### レビュアー B: 外部モデル（外部CLIがインストールされていない場合のみClaudeフォールバック）

まず、利用可能なCLIを検出します：
```bash
command -v codex >/dev/null 2>&1 && echo "codex" || true
command -v gemini >/dev/null 2>&1 && echo "gemini" || true
```

レビュアープロンプト（レビュアー Aと同一のルーブリック + 指示）を構築し、一意の一時ファイルに書き込みます：
```bash
PROMPT_FILE=$(mktemp /tmp/santa-reviewer-b-XXXXXX.txt)
cat > "$PROMPT_FILE" << 'EOF'
... 完全なルーブリック + ファイル内容 + レビュアー指示 ...
EOF
```

最初に利用可能なCLIを使用します：

**Codex CLI**（インストールされている場合）
```bash
codex exec --sandbox read-only -m gpt-5.4 -C "$(pwd)" - < "$PROMPT_FILE"
rm -f "$PROMPT_FILE"
```

**Gemini CLI**（インストールされていてcodexがない場合）
```bash
gemini -p "$(cat "$PROMPT_FILE")" -m gemini-2.5-pro
rm -f "$PROMPT_FILE"
```

**Claudeエージェントフォールバック**（`codex`も`gemini`もインストールされていない場合のみ）
2番目のClaudeエージェント（subagent_type: `code-reviewer`、model: `opus`）を起動します。両方のレビュアーが同じモデルファミリーを共有しているため、真のモデル多様性は達成されなかったが、コンテキスト分離は引き続き適用される旨の警告をログに記録します。

すべての場合において、レビュアーはレビュアー Aと同じ構造化されたJSON判定を返す必要があります。

### ステップ 4: 判定ゲート

- **両方PASS** → **NICE** — ステップ 6（プッシュ）に進む
- **どちらかFAIL** → **NAUGHTY** — 両方のレビュアーからのすべてのクリティカルな問題をマージし、重複を排除し、ステップ 5に進む

### ステップ 5: 修正サイクル（NAUGHTYパス）

1. 両方のレビュアーからのすべてのクリティカルな問題を表示する
2. フラグが立てられたすべての問題を修正する — フラグが立てられたものだけを変更し、ついでのリファクタリングはしない
3. すべての修正を1つのコミットにまとめる：
   ```
   fix: address santa-loop review findings (round N)
   ```
4. **新しいレビュアー**でステップ 3を再実行する（前のラウンドの記憶なし）
5. 両方がPASSを返すまで繰り返す

**最大3イテレーション。** 3ラウンド後もNAUGHTYの場合、停止して残りの問題を提示します：

```
SANTA LOOP ESCALATION (exceeded 3 iterations)

3ラウンド後の残存問題：
- [両方のレビュアーからの未解決のクリティカルな問題をすべてリスト]

続行する前に手動レビューが必要です。
```

プッシュしないでください。

### ステップ 6: プッシュ（NICEパス）

両方のレビュアーがPASSを返した場合：

```bash
git push -u origin HEAD
```

### ステップ 7: 最終レポート

出力レポートを表示します（下記の出力セクションを参照）。

## 出力

```
SANTA VERDICT: [NICE / NAUGHTY (escalated)]

Reviewer A (Claude Opus):   [PASS/FAIL]
Reviewer B ([model used]):  [PASS/FAIL]

Agreement:
  Both flagged:      [両方が検出した問題]
  Reviewer A only:   [Aのみが検出した問題]
  Reviewer B only:   [Bのみが検出した問題]

Iterations: [N]/3
Result:     [PUSHED / ESCALATED TO USER]
```

## 注意事項

- レビュアー A（Claude Opus）は常に実行されます — ツール環境に関係なく、少なくとも1つの強力なレビュアーが保証されます。
- レビュアー Bの目標はモデル多様性です。GPT-5.4またはGemini 2.5 Proは真の独立性を提供します — 異なる学習データ、異なるバイアス、異なる死角。Claudeのみのフォールバックでもコンテキスト分離による価値はありますが、モデル多様性は失われます。
- 利用可能な最も強力なモデルが使用されます：レビュアー AにはOpus、レビュアー BにはGPT-5.4またはGemini 2.5 Pro。
- 外部レビュアーはレビュー中のリポジトリ変更を防ぐため、`--sandbox read-only`（Codex）で実行されます。
- 各ラウンドで新しいレビュアーを使用することで、以前の発見に対するアンカリングバイアスを防ぎます。
- ルーブリックは最も重要な入力です。レビュアーがゴム印承認をしたり、主観的なスタイルの問題をフラグに立てる場合は、ルーブリックを厳格化してください。
- NAUGHTYラウンドでコミットが行われるため、ループが中断されても修正は保持されます。
- プッシュはNICE後にのみ発生します — ループ中には決して行われません。