Claude Codeのサブエージェントは5階層まで子を産める｜実際どう使っているか

Q: agent-teamsのような機能を使えば、この運用はもっと楽になりますか？

agent-teams等の一部オーケストレーション機能は公式に experimental と明記されています。本記事の運用は素のサブエージェント委譲だけで組んでおり、実験的機能への本番依存は避けています。

子に投げた作業のログを、そのまま親のcontextに戻したら、先に息切れするのは親の方だ。それを防ぐ構造として、Claude Codeはサブエージェントの入れ子を5階層まで許している。

Claude Codeにはサブエージェント機能があり、子がさらに子を産む形で最大5階層まで入れ子にできる。個人開発でClaude Codeを日常的に酷使している身として、「子に何を投げ、親に何を残すか」の実際の運用パターンをまとめる。比較記事ではない。実際に使っている委譲の型と、それが何を守っているかを書く。

Claude Codeのサブエージェントは何階層まで子を産めるのか？
どの作業を子に投げて、どの作業を親でやるべきか？
実際にどう使っているか？親=オーケストレータ・子=並列リサーチという運用
なぜ子には「圧縮要約だけ返す」ルールを課しているのか？
session-limitで子が死んでも成果を失わない設計とは？
子の「完了しました」報告はそのまま信じていいのか？
dynamic workflowsやbackground subagentの権限プロンプトはどう関係するか？
5階層まで子を産める機能を、結局どう使えばいいのか？
よくある質問

Claude Codeのサブエージェントは何階層まで子を産めるのか？

結論から言うと、Claude Codeのサブエージェントは子がさらに子を産む形で最大5階層まで入れ子にできる（2026年6月のW24・v2.1.166-176で公式に確認済み）。ただしこれは上限であって推奨される深さではない。実運用では2階層で足りることがほとんどだ。

1階層 — 親が直接作業する。委譲なし
2階層 — 親が子に委譲する。日常的な調査・実装委譲はほぼここ
3階層以上 — 子がさらに専門化したサブタスクを自分の子に振る場合のみ

階層を増やすほど「子の子」の報告が親に届くまでの伝言が長くなり、途中で情報が薄まるリスクも増える。5階層という上限を知っていることと、毎回それを使い切ることは別の話だ。

どの作業を子に投げて、どの作業を親でやるべきか？

結論は、「トークンを食うが結論は短い」作業は子に投げ、「委譲の往復コストの方が高い」作業は親に残す、という切り分けだ。実際に使い分けている基準は次の表の通り。

作業	委譲先	理由
複数ファイルにまたがる調査・grep	子	大量の検索結果を親に流さず、要約だけ受け取る
ログ・テスト出力の解析	子	数千行の出力で親のcontextを圧迫させない
5ファイル超の書き換え	子	diffの結論だけ親に戻す
スクリーンショット・視覚UI検証	子	画像の読み込みトークンを子に閉じ込める
設計・計画の検討	子	思考の往復を親の外で消費させる
単一ファイルの編集	親	委譲する往復コストの方が高い
ユーザーとの対話・確認	親	子に投げる意味がない

この表は固定ルールというより、何度も子への委譲で親のcontextを溶かした経験から逆算した経験則だ。「大量の生データを読む作業」と「短い結論を出す作業」を分けて、前者だけを子に押し出す、という発想が軸になっている。

実際にどう使っているか？親=オーケストレータ・子=並列リサーチという運用

結論は、親を上位モデルによるオーケストレータに固定し、子は基本Sonnetで並列に走らせる、という役割分担だ。子は複数同時に走らせることが多く、親には各子の圧縮要約だけが返ってくる。

親の役割は「タスクを分解し、どの子に何を振るか決め、返ってきた要約を統合して次の判断を下す」ことに絞る。子の役割は「振られた範囲だけを調査・実装し、生の作業過程は自分の中に閉じ、結論だけを構造化して返す」こと。子にSonnetを当てる理由は基本的な実装・調査の重さに見合うからで、この基準自体はモデルの使い分けの記事で書いたタスクの重さに応じた振り分けと同じ考え方に沿っている。

複数の子を並列で走らせる場合、独立したタスクは同一メッセージ内でまとめて起動する。逐次で1体ずつ待つより、親が待機する時間そのものが短くなる。

なぜ子には「圧縮要約だけ返す」ルールを課しているのか？

結論は、親のcontextは有限で、一度raw出力（ログ・grep結果・画像・大量diff）で埋まると、その後の判断の質そのものが落ちるからだ。子に圧縮要約だけを返させるのは、親を「指揮に使える余白」のまま保つための制約になる。

委譲プロンプトには「rawは自分の作業領域に保存し、親には構造化された結論だけ返せ」「画像やraw outputは返さない」と明示している。これをしないと、5階層のうち1階層分の委譲だけでも親のcontextがログで埋まり、結局親自身が長時間作業できなくなる。親のcontextを溶かさないことは、そのままコストを下げる4つのレバーの記事で書いたコスト管理にも直結する話で、委譲の設計とコスト管理は根っこでつながっている。

なお、何を委譲するかはその場の気分で決めず、CLAUDE.mdに判定表として書き出して固定してある。迷う余地を残すと、面倒なときほど親で抱え込んでしまうからだ。

子に投げるもの — スクリーンショット撮影や視覚的なUI検証、デザイン参照画像との比較、3ファイルを超える横断調査、大量のログやテスト出力の解析、5ファイルを超える書き換え、計画立案・設計検討、コードレビュー。

親でやるもの — 単一ファイルの編集、1〜2コマンドで結果が短い処理、ユーザーとの対話・確認、簡単な質問への回答。

判定基準は「その作業の出力が親のcontextを大きく食うか」の一点だ。画像・大量ログ・多数ファイルのdiffは、必要なのは結論だけなのに生の量が多い。だから子の中に閉じる。逆に、出力が短くて判断が要るものは親に置いたままにする。

session-limitで子が死んでも成果を失わない設計とは？

結論は、子に「rawを先にディスクへ保存し、区切りごとに逐次追記し、最後に圧縮して親へ返す」という手順を課すことだ。この手順を踏んでいれば、子がセッション上限の途中で死んでも、ディスク上の成果は生き残る。

実際にあった話として、あるブログ記事の執筆作業で並行して走らせた子4体のうち3体が、セッション上限で作業途中に制限死したことがある。それでも4体全部が「先にファイルを作成し、節ごとに追記する」手順を共有していたため、raw原稿は全量ディスクから回収できた。もし「全部やってから最後にまとめて書く」手順だったら、この3体分の作業はそのまま消えていたはずだ。今回のこの記事自体も、同じ理由で最初の数分でファイルを作成し、節ごとに追記しながら書いている。

子の「完了しました」報告はそのまま信じていいのか？

結論は、信じない、だ。子が「commitしました」「実装完了です」と報告してきても、親は必ずtranscriptとgit logを突き合わせて実物を確認してから次に進む。子の報告は「意図」の記述であって「結果の証明」ではない。

子agentの委譲プロンプト自体に「trust but verify（信じるが確認する）：子の要約はその子が何をしようとしたかの記述であり、必ずしも実際に行ったことと一致しない」という前提を置いている。子がコードを書いた・編集したと言っていても、親は変更が実際にファイルへ反映されているかを自分で確認する。この一手間を省くと、子の勘違いや報告漏れにそのまま気づけなくなる。

ズレが起きた回数そのものは記録していないので、頻度の数字は出せない。ただ、確認先を「子の報告文」ではなく「実物」——git log、ファイルの中身、テストの実行結果——に固定するというルールのほうは、例外なく守っている。数えていなくても、この一手間を省かないこと自体が、コストの安い保険になっている。

dynamic workflowsやbackground subagentの権限プロンプトはどう関係するか？

ここまで書いた委譲は、Taskツールでその場ごとに子を呼ぶ都度spawn型（最大5階層）だ。これとは別に、/workflowsから呼び出すdynamic workflowsという型もある（2026年6月のW22で公式確認済み）。オーケストレーションスクリプトが複数のsubagentを決まった手順で呼び出す仕組みで、都度その場で判断して子を呼ぶのではなく、手順自体を先に組んでおく用途に向く。

もう一つ押さえておきたいのが、background実行中のsubagentが権限を求めたときの挙動だ。子をバックグラウンドで走らせていても、破壊的な操作など許可が必要な場面に当たると、その確認プロンプトは親のセッションに表示される（2026年6月のW26で確認済み）。完全な「投げっぱなし」にはならず、親は子が権限待ちで止まっていないか気にかける必要がある。子として動くSonnetが過負荷で応答しなくなったときの保険は、fallbackModelの記事で書いた設定がそのまま効く。

なお、チームメンバー間で直接やり取りする一部のオーケストレーション機能（agent-teams等）は、公式に「experimental」と明記されている。本記事で書いた運用は、実験的機能ではなく素のTaskツールによる委譲だけで組んでおり、実験的機能に本番の作業を依存させることは避けている。

5階層まで子を産める機能を、結局どう使えばいいのか？

5階層は上限であって目標ではない。実際に効いているのは、①子に何を投げるかの切り分け（使い分け表）、②子には圧縮要約だけを返させる制約、③raw先行保存による耐障害性、④子の「完了しました」報告を鵜呑みにせず実物で検証する習慣、の4点だ。

親を上位モデルによるオーケストレータ、子をSonnetによる並列リサーチ役に固定し、子の生の作業過程は子の中に閉じて要約だけを親に返す。この型を守っている限り、階層を深くしなくても、親のcontextを溶かさずに大きな調査・実装を回せる。dynamic workflowsやagent-teamsのような新しい機構も出てきているが、まずは素のsubagent委譲でこの4点を徹底する方が、実験的機能に頼るより再現性が高い。