Claude Code の Spawn（並列 subagent 起動）は本当に並列で効くのか

「Spawn」という言い方で雑に呼ばれているもの、つまり Claude Code の Agent ツールを 1 つのアシスタントメッセージ内で複数同時に呼ぶことについて、2026-05 時点の公式ドキュメントを読み直して整理した。

"Spawn" の正体

Claude Code には Agent ツール（旧称 Task、v2.1.63 で改名された）があり、これを介して subagent を起動する。subagent は親会話とは別の独立した会話インスタンスで、独自の context window・system prompt・tool 権限・モデル選択を持つ。

組み込み subagent として以下が用意されている（Create custom subagents）:

• Explore — read-only、Haiku、コード探索専用
• Plan — plan mode 中の調査用、read-only
• General-purpose — 全ツール使用可、複雑で多段な作業向け
• statusline-setup — /statusline 設定用、Sonnet
• claude-code-guide — Claude Code の機能質問応答、Haiku

カスタム subagent は .claude/agents/ または ~/.claude/agents/ に YAML front matter 付き Markdown で定義する。SDK では agents パラメータで programmatic に渡せる（Subagents in the SDK）。

呼び方は 2 通り: 親 Claude が description を見て自動 delegate するか、ユーザーが「Use the X agent to ...」と明示する。

並列で動くのか

動く。ただし条件がある。

公式 SDK ドキュメントは "Multiple subagents can run concurrently, dramatically speeding up complex workflows" と明記している（Subagents in the SDK – Parallelization）。1 つのアシスタントメッセージの中で Agent ツール呼び出しを複数並べると、ハーネスがそれらを同時に走らせて結果を集める。

ここを誤解しやすい: tool-result ループの毎ターンで Agent を 1 回ずつ呼んでも、それはターン直列であって並列ではない。並列になるのは 同一のアシスタント返答 に並んでいる Agent 呼び出しだけ。

なお subagent は更に subagent を spawn できない（無限ネスト防止）。Plan のドキュメントが明示している。

並列が効く場面

• 互いに依存しない、加算的な作業（テストランナーと style checker と security scanner を同時に流す等）
• 探索結果で本会話を汚したくないとき（subagent は要約だけ返すので親 context が膨らまない）
• 編集対象ファイルがエージェント間で重ならないとき
• 子の出力が「最終要約だけあれば足りる」種類のとき

Anthropic の multi-agent research の事例では並列化によって調査時間が最大 90% 削減されたと報告されている（Multi-agent research system）。

並列が無駄になる / バグを呼ぶ場面

• 同じファイルを複数 subagent が書く — 並列 Write/Edit は race になり、後勝ちで片方の変更が消える。ファイル所有権を agent ごとに分けないと事故る。
• 依存する作業 — A の出力を B が読む必要がある場合、並列起動しても B は古い状態を見るだけ。順序が必要なら順序付ける。
• タスクが軽すぎる — オーケストレーションと subagent 起動オーバーヘッドが本体作業を上回る。
• 重複探索 — subagent は親の会話履歴・system prompt・他 subagent の context を一切見ない。Agent ツールに渡した prompt 文字列がすべて。3 並列で似た grep を走らせれば、3 倍のトークンで同じ情報を 3 回読むことになる。

公式は明確に書いている: "The only channel from parent to subagent is the Agent tool's prompt string"（What subagents inherit）。

コストと制限

各 subagent は独立した会話なので、独自の context window と独自のトークン課金が発生する。並列 = ウォールクロックはほぼ同じ、合計トークンは N 倍。

Anthropic 自身の数値: chat に比べて agent は約 4×、multi-agent システムは約 15× のトークンを使う（Multi-agent research system）。これに見合うだけのタスク価値があるかが判断軸。

並列起動の明示的な同時数上限が Anthropic のドキュメントに数値で書かれているのは確認できなかった。実利用上はサブスクの rate limit と各 subagent の context 窓に縛られる、と理解しておくのが安全。

Windows では subagent prompt がコマンドライン長制限（8191 文字）に当たって失敗することがある旨が SDK ドキュメントの Troubleshooting に書かれている。

実用パターン

• ファイル所有境界を切る — agent A は src/api/、agent B は src/ui/、と prompt で明示。重ならせない。
• research → synthesis の 2 波構成 — 並列で複数 subagent に調査させ、戻ってきた要約を親が読んでから単独の synthesis agent に渡す。依存があるなら波を分ける。
• prompt は自己完結に — subagent は親の文脈を一切見ない。必要なファイルパス・エラーメッセージ・前提を全部 prompt に入れる。「3 時間の会議の要約 1 枚を渡して判断させる」くらいの解像度で書く必要がある（参考: Forked Subagents）。
• 返信の長さを縛る — prompt 末尾に「結果は X 行以内で要約」と書いておくと、親 context への汚染を抑えられる。
• Agent を subagent の tools に入れない — ネスト spawn は禁止されている（SDK note）。

結論

並列 subagent は「作業が本当に独立しているとき」に効く。効くのはウォールクロック時間であって、総計算量ではない。

「並列の方が速そうだから」で投げると、3 倍のトークンを払って 3 つの似た探索結果が返ってくるだけになる。判断基準は単純に sub-task が互いに独立か。独立なら並列、依存があるなら順次、軽い作業なら subagent を使わず親で直接やる、で十分。

参考・引用元

• Subagents in the SDK — 公式ドキュメント, Anthropic
• Subagents – Parallelization — 公式ドキュメント, Anthropic
• What subagents inherit — 公式ドキュメント, Anthropic
• How we built our multi-agent research system — エンジニアリングブログ, Anthropic
• Forked Subagents — 個人ブログ, Mejba Ahmed

2026-05-18