「並列で投げれば速い」——サブエージェントの話でよく耳にします。でも、本当に速くて安いのか。合成の問い合わせ8件を、逐次1体と並列4体・8体で実際に回して、時間とトークンとコストを測りました。結果は、わたしの予想と逆でした。
結論：8件の軽いバッチでは逐次が最速・最安だった
先に数字を置きます。8件のような1件が軽いバッチでは、逐次が最速で最安でした。並列8体は逐次より時間で約1.6倍、トークンで約7.7倍もかかっています。体を増やすほど遅く、そして高くなりました。
| 方式 | 子エージェント | wall-clock | 合計トークン | コスト概算(¥@160) |
|---|---|---|---|---|
| 逐次 | 1体 × 8件 | 35.0秒 | 42,204 | 約¥21 |
| 並列4 | 4体 × 2件 | 50.4秒 | 163,328 | 約¥82 |
| 並列8 | 8体 × 1件 | 55.1秒 | 324,652 | 約¥164 |
時間もトークンも、すべて自前の実測値です。数字の出どころは rapid-dev カテゴリ の他の検証記事と同じで、想像では埋めていません。ではなぜ、こうなったのか。
実験の設計（合成8件を逐次・並列4・並列8で回す）
題材は、架空 SaaS への問い合わせ8件です。実在の個人情報は使っていません。各件を「カテゴリ分類・40字要約・優先度」の3点で処理させました。今回はサブエージェント並列の効果だけを見たいので、タスク自体はわざと軽くしています。
- 逐次：子エージェント1体が8件を順に処理
- 並列4：4体を同時に spawn し、各2件を分担
- 並列8：8体を同時に spawn し、各1件を分担
ワーカーのモデルは軽い分類なので sonnet を指定しました。検証は2026年7月、モデルのバージョンは Claude Sonnet 4.6 系（導入期は Sonnet 5）です。時間は各ワーカーが処理の前後で date +%s%3N を打刻しました。spawn 発火から最後の終了までを wall-clock として測っています。トークンは Claude Code が返す実測の消費量を使いました。
実測：体を増やすほど遅く・高くなった
分類そのものは速いです。1件あたり数秒で終わります。ところが子エージェント1体を立ち上げる spawn には、今回の観測で12〜32秒かかりました。処理より、起動の方が重いのです。
もうひとつ、意外だったこと。並列8体を一度に投げても、8体が本当に同時には走りませんでした。各ワーカーの開始時刻は階段状にずれ、同時に動いていたのは2〜3体ほど。合計トークンは体数にほぼ比例して、42k → 163k → 325k と膨らみました。
なぜ並列が損したのか
1. spawn オーバーヘッドが実処理より重い
子エージェントは毎回コールドスタートです。専用の system prompt とツール定義を読み込み、最初の一手を出すまでに時間がかかります。1件が数秒で終わる軽いタスクだと、この固定コストが全体を支配します。体を増やしても待ち時間は縮まりません。
2. 「同期 spawn」は完全には並列化されない
ここがサブエージェント並列でいちばん誤解しやすい点でした。公式ドキュメントにも 「サブエージェントは単一セッション内で動く。多数を本当に並列で回すならバックグラウンドエージェントを見よ」とあります。同期的にまとめて投げても、実体は逐次〜部分並列。理論値どおりの8並列にはなりませんでした。
3. 固定オーバーヘッドが体数分だけ重複する
公式ドキュメントは 「各サブエージェントは自分専用の context window で動く」と明言しています。つまり体ごとに固定の文脈を持ち直します。実測でも1体あたり約40kトークンをほぼ固定で消費し、実タスクの中身は2k程度でした。8体に割れば、40k × 8 で約320k。分割した瞬間に、固定コストを人数分だけ払い直す構図です。
品質は落ちたか（分類は8/8一致）
気になるのは精度です。文脈を分けると雑になるのでは、という不安。結果はサブエージェント並列でも、カテゴリ分類は3方式すべてで8件中8件が一致しました。優先度だけ一部でブレましたが、これは主観のゆらぎで、並列が原因ではありません。少なくともこの独立バッチでは、損したのは時間とコストの側でした。
並列が効く条件・損する条件
ここまで並列に厳しい数字が並びましたが、並列がダメという話ではありません。分かれ目は「1件あたりの処理時間」と「spawn オーバーヘッド（約20秒/体）」の大小です。
サブエージェント並列が効くのは、1件が数分かかる重い処理を、独立に分割できて、本数が少ないときです。Σ(各処理時間) − max(処理時間) が spawn の重複コストを上回れば、初めて wall-clock が縮みます。役割別のコード調査や、章ごとの長文要約などが向きます。ただしトークンは必ず（体数−1）×約40k 増えるので、安くはなりません。時間を金で買う判断です。
逆に向かない場面は、今回のような軽いバッチ処理。1件が spawn オーバーヘッドを超えない限り、逐次で1体に全部やらせた方が速くて安上がりでした。この「予想が外れた」感覚こそ、実測しないと分からない部分です。
再現手順（コピペで動く形）
まず、繰り返し使うワーカーは再利用できるサブエージェントとして定義しておくと楽です。.claude/agents/ticket-classifier.md に置きます。
---
name: ticket-classifier
description: 問い合わせを分類・要約する軽量ワーカー
model: sonnet
tools: Bash
---
渡された問い合わせ文を「請求/技術サポート/解約/機能要望/その他」に
分類し、40字以内の要約と優先度(高/中/低)を返す。余計な探索はしない。時間の計測は、処理の前後をミリ秒で打刻するだけです。そのまま貼れば動きます。
START_MS=$(date +%s%3N)
# ここで処理（分類・要約など）を実行
END_MS=$(date +%s%3N)
echo "elapsed_ms=$((END_MS - START_MS))"並列時の wall-clock は、各ワーカーが吐いた開始・終了を集計します。logs.txt の各行に「START END」が並んでいる前提です。
# 最初の開始から最後の終了までを wall-clock として出す
awk 'NR==1{min=$1;max=$2}
{if($1<min)min=$1; if($2>max)max=$2}
END{print "wall_clock_ms=" max-min}' logs.txtコスト概算は公式の単価で出せます。今回のワーカー（sonnet）は 公式 pricing で入力 $3・出力 $15（100万トークンあたり）。1体あたり約40kトークンなら、入力換算でおよそ $0.12 です。体を増やすほど、この額が素直に人数倍になります。
まとめ
- 8件の軽いバッチでは、逐次が最速・最安（並列8体は時間1.6倍・トークン7.7倍）
- 子エージェントの spawn は12〜32秒かかり、1件が軽い処理では起動が支配的
- 同期 spawn は完全並列化せず、実体は逐次〜部分並列だった
- 各サブエージェントは自分の context window を持つため、固定約40kが体数分だけ重複する
- 分類精度は8/8で落ちない。損するのは時間とコストの側
- 並列が効くのは「1件が重い×独立×少数」。時間を金で買う判断になる
サブエージェント並列は、便利ですが万能ではありません。まずは自分のタスクで逐次と並列を1回ずつ測るのが近道です。日々の消費を抑える工夫は Claude Code の hooks でコスト浪費を止める にまとめました。スキルやサブエージェントの設計は 自作スキルの設計判断と落とし穴 が参考になります。こうした費用対効果を踏まえた業務自動化は、法人向けにも設計から構築まで請け負っています。
