| name | multi-review |
| description | 最大6サブエージェントを並列起動し、スコアベースで集約したレビューレポートを出力する。修正は行わない。 |
| user_invocable | true |
マルチレビュー
専門サブエージェント(.claude/agents/reviewer-*.md)を並列起動し、スコアベースで集約したレビューレポートを出力する。修正は行わない(修正込みのサイクルは /review-cycle を使う)。
Codex版は /codex-multi-review を使う。
レビュアー構成
常時起動(5レビュアー)
| # | 名前 | モデル | 専門領域 |
|---|
| A | reviewer-security | Opus | セキュリティ |
| B | reviewer-logic | Opus | ロジック・バグ |
| C | reviewer-architecture | Opus | 設計・アーキテクチャ |
| D | reviewer-testability | Opus | テスタビリティ・テスト網羅性 |
| F | reviewer-epistemics | Opus | 主張監査(報告文・コミットメッセージが対象。diffではない) |
条件付き起動(ネイティブコード含む場合のみ +1)
| # | 名前 | モデル | 専門領域 |
|---|
| E | reviewer-native | Opus | Swift/Kotlin(ウィジェット、共有DB、iOS/Android対称性) |
起動条件: レビュー対象に .swift または .kt ファイルが含まれる場合。
手順
Step 1: レビュー対象の確認
- ディレクトリの存在を必ずGlobで確認する(エージェントの報告を鵜呑みにしない)
- レビュー対象のファイル一覧を取得
- ネイティブコード判定: レビュー対象に
.swift / .kt ファイルが含まれるかGlobで確認
- ユーザーにレビュー対象を確認(ネイティブレビュアーEの起動有無も明示)
Step 2: 全レビュアー並列起動
全レビュアーを同時に起動する(ネイティブコードなしなら5、ありなら6)。レビュアーを省略しない。全員起動が必須。
.claude/agents/ にエージェント定義済み。Agentツールで起動する:
# 各エージェントに渡すプロンプト例
"以下のファイルをレビューしてください。\n\n対象:\n<ファイル一覧>"
起動パラメータ:
- name:
reviewer-security / reviewer-logic / reviewer-architecture / reviewer-testability / reviewer-epistemics (+ reviewer-native)
- model: エージェント定義側で指定済み(全レビュアー opus に統一。2026-06-12 Fable移行棚卸しで決定)
全Agentツール呼び出しを1つのメッセージで並列実行すること。
E (reviewer-native) にはSwift/Kotlinファイルのみ渡す。
F (reviewer-epistemics) にはファイル一覧ではなく「主張の材料」を渡す:
以下の報告文に含まれる主張を監査してください。
## セッション中のコミットメッセージ
<`git log --format="%h %B" <base>..HEAD` の出力>
## PR本文(あれば)
<PR body>
## 完了報告ドラフト
<これからユーザーに送る予定の報告・結論の要約。
「検証済み」「既存の問題」「影響なし」等の判断を含めて省略せずに書く>
完了報告ドラフトをまだ書いていない段階で起動する場合は、現時点での結論・判断(何を検証済みとし、何を既存問題と判断し、何を影響なしと見なしているか)を箇条書きで渡す。Fに渡す材料を整形する時に主張を弱める・ぼかすことを禁止する(監査対象の改変になる)。
Step 3: スコアベース集約
集約ルール
| 条件 | 判定 |
|---|
| confidence 80以上 | 修正対象 |
| confidence 75-79 だが、2人以上のレビュアーが同一箇所/同一問題に75以上を付与 | 修正対象 |
| confidence 75-79 で単独指摘 | 報告のみ |
| confidence 75未満 | レビュアー側でフィルタ済み(報告されない) |
集約手順
- 全レビュアーの結果が揃うまで集約しない(1つでも欠けたらリトライ)
- 同一箇所・同一問題の指摘をグループ化(ファイル:行番号 + 指摘内容で判定。Fの指摘はファイル:行番号を持たないので主張単位でグループ化)
- 上記ルールで修正対象を決定
- Critical → Warning → Infoの優先順でソート
Fの指摘の「修正」はコード修正ではなく、(a) 反証実験を実行して主張を観測に格上げする、(b) 報告文から主張を撤回する、(c) 「未検証の推測」とラベルを付ける、のいずれか。(c)を選びがちな場合は注意: 荷重主張(それが偽なら結論が崩れる)には原則(a)で応える。
出力形式
## 修正対象(confidence 80+ または 2人以上が75+)
### Critical
- [confidence: XX, reporters: A,C] ファイル:行番号 - 指摘内容
### Warning
- [confidence: XX, reporters: B] ファイル:行番号 - 指摘内容
### Info
- [confidence: XX, reporters: D] ファイル:行番号 - 指摘内容
## 報告のみ(confidence 75-79 単独)
- [confidence: 77, reporter: A] ファイル:行番号 - 指摘内容
## 各レビュアー判定
- A (Security): LGTM / NOT LGTM
- B (Logic): LGTM / NOT LGTM
- C (Architecture): LGTM / NOT LGTM
- D (Testability): LGTM / NOT LGTM
- E (Native): LGTM / NOT LGTM ※ネイティブコード含む場合のみ
- F (Epistemics): LGTM / NOT LGTM
レビュー結果の判断
- Critical指摘は実コードと突き合わせて裏取り必須: レビュアーはプロジェクトコンテキスト(DB実カラム名、ランタイム環境特性等)を持たないことがある。
tsc結果や実行結果など客観的証拠で判断する
- 偽陽性と判断したら根拠を示してスキップする。正しいコードを壊すリスクの方が高い
- Warningでもプロジェクト規約違反(
asキャスト等)は修正すべきと提案する
注意事項
- 計画書レビューと実装レビューは別物: 計画書のレビュー済み≠実装コードのレビュー済み