subagent と役割分担（寄り道：/review）
ここまで主役だった /debug は、現在の作業環境で 1 つのエージェントが調査から修正までこなしました。しかし変更が大きくなると、別の構えが必要になります。この章は、/debug では出てこない複数エージェントの並列を、/review への寄り道で補います。
作る人と評価する人を分ける
ハーネスには「実装したエージェントに、自分の実装を評価させない」という原則があります。Generator-Evaluator 分離です。
理由は単純で、自分が書いたものは「だいたい良い」と評価しがちだからです（self-evaluation bias）。この偏りを避けるため、subagent は役割で分かれています。
- Generator（作る役）:
implementer（実装）、refactorer（リファクタ） - Evaluator（評価する役）:
code-reviewer、architect、test-strategist、infra-reviewer - 両方（調べて直す）:
debugger
/debug と対をなす debugger subagent が「両方」に位置するのは、調査と修正が不可分だからです。一方、レビューは評価役に徹します。
寄り道：大きな変更を 3 視点で並列レビューする
変更が広範囲（多くのファイル・複数ドメインの横断）になると、1 人のレビュアーでは見落としが出ます。そこで multi-perspective-review という構成で、3 つの視点を並列に走らせます。これは ~/.claude/teams/ に置かれた team 定義（🔧 自作）で、どの subagent をどう組み合わせるかを 1 ファイルに記述したものです。subagent を spawn する機構そのものは Claude Code 標準（📦）です。
3 者はそれぞれ独立した視点でレビューし、結果を統合します。実装の細かいバグは code-reviewer、設計の歪みは architect、テストの抜けは test-strategist——と、見る角度を変えることで、1 視点では拾えない問題を捕まえます。
subagent のもう 1 つの利点は、別のコンテキストで動くことです。大量のコードを読み込む調査やレビューを subagent に任せれば、メインの会話がその情報で埋まりません。/debug（現環境で即時）と debugger subagent（隔離環境でじっくり）の使い分けも、この発想です。
さらにこの環境では、subagent の最終報告を save-subagent-result.sh（hooks の仕組み で見た PostToolUse hook）が完了の瞬間にディスクへ保存します。レート上限やクラッシュでセッションが落ちても、subagent が長時間かけた調査結果は失われません。
/debug との対比
/debug（主役） | /review + multi-perspective（寄り道） | |
|---|---|---|
| エージェント数 | 1（現在の環境） | 3 を並列 spawn |
| 役割 | 調べて直す（両方） | 評価に徹する（read-only） |
| 向く場面 | 局所的なバグ修正 | 広範囲・複数ドメインの変更 |
| 狙い | 真因を特定して直す | 多視点で見落としを減らす |
/debug の単線の流れと、/review の並列の構え。どちらも「1 つのエージェントの判断を鵜呑みにしない」というハーネスの姿勢の表れです。/debug は反復で自分を疑い、/review は別視点を立てて疑います。アプローチは違っても、狙いは同じです。
要点は次のとおりです。
- 自己評価の偏りを避けるため、subagent は Generator（作る）と Evaluator（評価する）に分かれる
- 大きな変更は
multi-perspective-reviewで 3 視点（code-reviewer / architect / test-strategist）を並列レビュー - subagent は役割分担に加え、コンテキストの隔離という利点も持つ
/debugの反復と/reviewの多視点は、どちらも単一判断を鵜呑みにしないための構え
次は Guide と Sensor のペア で、十字分類の典型を /grill-me への寄り道で見ます。