subagent を並列 (fan-out) で投げる判断基準

結論

並列にするのは全条件を満たす時だけ:

1. 3個以上 の独立タスクがある
2. タスク間で 状態を共有しない
3. ファイル境界が明確 (書き込みが衝突しない)
4. 各 subagent の 出力が長大 (親 context を汚したくない)

満たさないなら単一 subagent or 親で直接やった方が安く速い。

なぜ?

並列起動はトークンを N倍 消費する。失敗パターンとして「3並列で進めれば速い」が 7x コスト に膨れた事例が多数報告されている。

特に注意: - 設計判断のような依存タスクは順序が必要 → 並列にしない - 同じファイルを編集する2つ以上の subagent → 衝突する - 出力が短い(grep結果1行とか) → 親で Bash 直接の方が速い

fan-out が効くケース

• リサーチ: 4ソース(HN/dev.to/Reddit/blog)を別 subagent に分担 ← このレポの research-trends skill が好例
• 巨大コードベース探索: ディレクトリごとに Explore subagent
• クロスモデルレビュー: 同じ diff を Claude / Codex / Gemini に並列投入し結果合議
• 多ファイル type generation: スキーマから 10 個の型定義を生成、ファイル衝突なし

fan-out しないケース

• 「実装 → テスト → ドキュメント更新」のような順序ありの工程
• 1つの設計判断を各モデルにバラバラに任せる (結論が割れて統合不能になる)
• 短時間の grep / read 系 (親で直接やる)

投げる時の書き方

並列投げは1メッセージ内で複数 Task 呼び出しを同時に書く(別メッセージに分けない)。

主要なコツ: - 各 subagent に 「他の subagent と何を分担しているか」 を伝える - 出力フォーマットを 構造化 (Markdown表 or JSON) で固定し、親側でマージしやすく - 期待語数を上限指定(例: 1500-2000語)。爆発防止

マージ戦略 3 種

1. 多数決: 結果が割れたら過半数を採用
2. Opus 最終判断: 3 つの差分を親 Opus が読んで決定
3. テスト通ったパッチ採用: コード変更系で確実

出典

• _research/trends/2026-05-11-vibe-coding-trends.md (Subagent Fan-Out / 7x コスト)
• _research/multi-llm/2026-05-11-subagent-other-llm.md (cross-model review)
• https://www.mindstudio.ai/blog/claude-code-split-and-merge-pattern-sub-agents
• https://claudefa.st/blog/guide/agents/sub-agent-best-practices