Fortress Review — 動的多角レビュースキル

概要

実装のリスクレベルを自動判定し、必要十分なエージェントチームを動的に編成する。 「エージェント数を固定で増やす」のではなく、プロンプト精度×適切なNで信頼性を最大化する設計思想。

  ┌──────────────────────────────────────────────────────┐
  │  Step 0: 入力受付（Issue URL / PR URL / 計画テキスト）│
  └──────────────┬───────────────────────────────────────┘
                 ↓
  ┌──────────────────────────────────────────────────────┐
  │  Step 1: Tier判定（A/B/C → エージェント数を決定）    │
  └──────────────┬───────────────────────────────────────┘
                 ↓
  ┌──────────────────────────────────────────────────────┐
  │  Step 2: Round 1 — 並列独立レビュー                  │
  │  （Tier A: 5体 / Tier B: 3体 / Tier C: 2体）        │
  └──────────────┬───────────────────────────────────────┘
                 ↓
  ┌──────────────────────────────────────────────────────┐
  │  Step 3: Human Gate — トリアージ（省略不可）          │
  │  → Critical/High のみ Round 2 へ                     │
  └──────────────┬───────────────────────────────────────┘
                 ↓
  ┌──────────────────────────────────────────────────────┐
  │  Step 4: Round 2 — 絞り込み深掘り（1-2体、対象限定） │
  └──────────────┬───────────────────────────────────────┘
                 ↓
  ┌──────────────────────────────────────────────────────┐
  │  Step 5: 最終判定 — Go / No-Go / 条件付きGo          │
  └──────────────────────────────────────────────────────┘

設計根拠（三者分析の統合）

核心原則（三者一致点）

1. プロンプトの質 > エージェント数 — チェックリスト形式でPASS/FAIL＋根拠を強制
2. Human Gateは省略不可 — エージェント間統合の自動化を試みない
3. Round 2は全員再起動ではない — 問題箇所の深掘りのみ
4. Codexの強みはコード操作 — 抽象的判断ではなくgrep/テスト生成/影響範囲列挙

Step 0: 入力受付

以下のいずれかを受け付ける:

引数なし時のdiffベースフォールバック:

1. git diff staging...HEAD を試行
2. staging が存在しなければ git diff main...HEAD
3. diff が空（0行）なら「レビュー対象の変更がありません。/sub-review を推奨」と終了

取得すべき追加コンテキスト:

• 変更対象ファイルのリスト（git diff --stat or PR files）
• 関連する CLAUDE.md / プロジェクト規約
• 直近の障害履歴（該当領域に関するもの）

Step 1: Tier判定（スコアリング方式）

入力を分析し、以下のシグナルテーブルで該当項目にチェックを入れ、合計スコアでTierを自動判定する。

シグナルテーブル

Tier閾値

Tier判定チェックリスト

- [ ] DB migration が含まれるか（ALTER/CREATE TABLE、マイグレーションファイル）
- [ ] データモデル・型定義の変更があるか
- [ ] キャッシュ戦略の変更があるか
- [ ] 認証/認可ロジックの変更があるか
- [ ] 課金・サブスクリプション関連の変更があるか
- [ ] RLSポリシーの変更があるか
- [ ] 公開API契約（型・レスポンス形式）の変更があるか
- [ ] 新規外部依存の導入があるか
- [ ] アーキテクチャパターンの変更があるか
- [ ] 変更ファイルが6個以上か
- [ ] 複数モジュール（3層以上）を横断するか
- [ ] データ経路が3本以上影響を受けるか
- [ ] ロールバックが困難か
- [ ] 過去に障害が発生した領域か
- [ ] フィーチャーフラグなしの本番直接反映か

スコアシミュレーション（代表ケース）

判定手順

1. 入力（Issue/PR/計画）からシグナルを自動スキャン
2. 該当シグナルの重みを合算
3. スコア0の場合: fortress-reviewは不要。/sub-review を推奨して終了
4. Tier閾値と照合 → --tier オプションで手動上書き可能
5. 判定結果をユーザーに提示（--dry-run の場合はここで終了）

【Tier判定結果】
対象: Issue #XXX — {タイトル}
スコア: {N}点（内訳: データ層{N} + 認証課金{N} + アーキ{N} + 影響範囲{N} + 運用{N}）
Tier: {A/B/C}
エージェント構成: {Codex×N + Claude×N}

Step 2: Round 1 — 並列独立レビュー

Tier別エージェント構成

エージェント起動ルール

1. 全エージェントを1メッセージで並列起動する（直列禁止）
2. Claude SubAgent: Agent ツール（subagent_type: general-purpose）で起動。差分埋め込み方式 — diffをプロンプトに直接含め、ファイル探索させない
3. Codexエージェント: Agent ツール（subagent_type: general-purpose）で起動し、サブエージェント内でBashから codex exec --cd を実行。diff はCodex自身が取得（Windows 8191文字制限回避）
4. 各エージェントのプロンプトテンプレートは references/agent-prompts.md を参照
5. エージェントに 「あなたは絶対に失敗を許されないプロジェクトの最終責任者です」 と明記

プロンプト組み立て手順（CRITICAL: 省略禁止）

テンプレートのプレースホルダを以下の順序で置換してからエージェントを起動する:

1. references/agent-prompts.md の「共通ヘッダー」セクション全文をコピー
2. 各テンプレートの {共通ヘッダー} を上記テキストで置換
3. {プロジェクトディレクトリ} → git rev-parse --show-toplevel の結果
4. {diffベース} → Step 0で決定したdiffベース（staging...HEAD / main...HEAD / 指定commit）
5. {Issue本文 or 仕様テキスト} → Step 0で取得したIssue body
6. {git diff結果 or 計画テキスト} → Step 0で取得したdiff（500行超はファイル単位で分割し、各SubAgentには担当観点に関連するファイルのdiffのみを渡す。diffStatは全SubAgentに共通で渡す）
7. {diffStatの結果} → git diff --stat の出力

Codex未インストール時のフォールバック

Codex CLIが利用不可の場合、Codexエージェント（CA, CB, CR2）をClaude SubAgent（探索許可） で代替する。この場合のみ Read/Grep/Glob ツールの使用を許可し、影響範囲分析をClaude SubAgentに委任する。

--no-codex 指定時の代替構成

Claude探索許可エージェントは Read/Grep/Glob を使い、Codex-Aの「影響範囲分析」を担当する。

出力フォーマット（全エージェント共通・強制）

【検出項目】
- ID: FR-{Agent番号}-{連番}
- ファイル: {パス}:{行番号}
- カテゴリ: ARCHITECTURE | LOGIC | SECURITY | DATA_INTEGRITY | REQUIREMENT | OPERATIONAL
- 深刻度: CRITICAL | HIGH | MEDIUM | LOW | INFO
- 判定: PASS | FAIL | WARN
- 問題: {1-2文}
- 根拠: {コードから直接証明可能な事実}
- 修正案: {深刻度HIGH以上の場合のみ、具体的コード}
- 残存リスク: {修正後も残るリスクがあれば記載}

問題なしの場合: 「全項目PASS」と1行で報告。

Step 3: Human Gate（省略不可）

Round 1 の全エージェント結果を受け取った後:

3.1 自動集約

1. 全エージェントの出力から指摘を抽出
2. 同一指摘の統合（複数エージェントが検出 → クロスバリデーション済み マーク）
3. 深刻度でソート（CRITICAL → HIGH → MEDIUM → LOW → INFO）

3.2 トリアージテーブルの提示

## Fortress Review — Round 1 結果

### Tier: {A/B/C}（スコア: {N}点）
### エージェント: {起動したエージェント一覧}

| # | ID | カテゴリ | ファイル | 深刻度 | 判定 | クロス検証 | 問題概要 |
|---|-----|---------|---------|--------|------|-----------|---------|
| 1 | FR-CA-01 | SECURITY | src/... | CRITICAL | FAIL | Codex+Sub3 | ... |
| 2 | FR-S2-01 | LOGIC | src/... | HIGH | FAIL | | ... |

### Round 2 推奨
- CRITICAL/HIGH: {N}件 → Round 2 深掘り推奨
- MEDIUM以下: {N}件 → 記録のみ（Round 2不要）

**判断をお願いします:**
1. Round 2 に進む（CRITICAL/HIGH指摘を深掘り）
2. 指摘を確認して実装に進む（リスク受容）
3. 計画を修正してから再レビュー

3.3 全エージェントPASS時のショートカット

全エージェントが「全項目PASS」を返した場合: → トリアージテーブルに「指摘なし」と表示 → Step 5（最終判定: Go）に自動進行 → ユーザーに確認: 「全レビューアがPASS判定。Go で進行しますか？」

3.4 Human Gate の意義

エージェント間の矛盾解消を自動化しようとしない。 6体のエージェントが矛盾する指摘を出した場合、正しいのは「人間の判断」。 Human Gate は「ノイズフィルタ」であり「責任の所在を明確にする」仕組み。

Step 4: Round 2 — 絞り込み深掘り

Human Gateで「Round 2 に進む」が選択された場合のみ実行。

起動エージェント（最大2体）

Round 2 の入力

• Round 1 の全指摘（トリアージ済み）
• Human Gate での判断コメント
• 対象ファイルの現在の全文（diffだけでなく）

Step 5: 最終判定

Go / No-Go 基準

最終レポート

## Fortress Review 最終レポート

### 基本情報
- 対象: {Issue/PR/計画の概要}
- Tier: {A/B/C}（スコア: {N}点）
- エージェント総数: {R1: N体 + R2: N体}

### 判定: {Go / 条件付きGo / No-Go}

### 指摘サマリ
| 深刻度 | 検出 | 解決済 | 未解決 |
|--------|------|--------|--------|
| CRITICAL | N | N | N |
| HIGH | N | N | N |
| MEDIUM | N | N | N |

### クロスバリデーション（Codex+Claude双方が検出）
- {リスト}

### 残存リスク
- {修正後も残るリスクのリスト}

### 統計
- Round 1: {N}体 × {所要時間}
- Round 2: {N}体 × {所要時間}
- 総トークン: 約{N}
- Human Gate判断: {選択肢}

既存スキルとの連携

将来の統合構想

issue-planner（計画作成）
     ↓
fortress-review（計画の多角検証）  ← NEW
     ↓
issue-autopilot-batch（実装）
     ↓
sub-review（実装diffレビュー）
     ↓
e2e-test（動作検証）

オプション引数

トラブルシューティング

関連スキル

• design-review-checklist: 設計前の品質チェックリスト（Phase 1-9）。fortress-review の Claude-Sub1 が内部参照
• /sub-review (コマンド: ~/.claude/commands/sub-review.md): 実装後の5エージェント並列diffレビュー。fortress-review の後に実行
• agent-teams: 並列コーディングの所有権管理。fortress-review とは直交（レビュー vs 実装）
• issue-planner: 実装計画の自動生成。fortress-review の前に実行
• issue-autopilot-batch: バッチ実装パイプライン。Tier B以上で fortress-review を挟む構想
• skill-improve: スキル品質管理。fortress-review 自体の改善にも使用

改訂履歴