サブエージェントを並列に走らせる構成は以前から組めましたが、私がずっと窮屈に感じていたのは「サブエージェントの中からさらに委譲できない」ことでした。記事生成の自動運用では、生成役のサブエージェントが品質検証も整合性チェックも自分で抱え込むため、1つのコンテキストに役割が詰め込まれて精度が落ちていく。親エージェントが全工程の中継役を務める、いわば中間管理職の渋滞が起きていたのです。
2026年6月の更新で、この制約が外れました。サブエージェントが自身のサブエージェントを生成できるようになり、入れ子は最大5階層まで許容されます。早速、個人開発で回しているブログ自動運用の委譲構造を作り直してみたのですが、結論から言うと「5階層使えるからといって5階層使うべきではない」というのが現時点の実感です。その判断に至る過程を書き残しておきます。
フラットな並列から木構造の委譲へ — 何が変わったのか
これまでのサブエージェント構成は、親が複数の子を並列に起動する1段の扇形でした。子同士は対等で、子から先への委譲はできません。今回の更新で、子が孫を、孫がひ孫を起動できるようになり、委譲構造を木として設計できます。
この変化が効くのは、タスクの分解が自然に再帰的になる場面です。たとえば「4サイト分の記事を更新する」という親タスクは、「サイトごとの更新」という子タスクに分かれ、さらに「生成」と「検証」という孫タスクに分かれます。従来はこの3段目を親が直接管理するしかなく、親のコンテキストにサイト横断の詳細が流れ込んでいました。ネストが可能になったことで、各サイトの事情はその子の配下に閉じ、親は集約結果だけを見ればよくなります。
なお、リサーチプレビューの Dynamic workflows も多段のマルチエージェント構造を扱いますが、あちらはワークフロー定義側で編成を組む仕組みです。手元のプロンプト設計だけで木構造を作れるネストとは使い分けになります。Dynamic workflows の感触は Claude Code の Dynamic Workflow を動かして掴んだ、サブエージェント並列実行の勘所 に書きました。
5階層を試して最初にぶつかった「伝言ゲーム問題」
機能が出た日に、あえて5階層フルに使う構成を試しました。計画 → サイト別 → 記事生成 → セクション執筆 → 校正、という分解です。動くには動きます。ただ、出来上がった結果を見て気づいたのは、階層を1つ降りるたびに、上位の意図が少しずつ薄まることでした。
サブエージェントは独立したコンテキストで動き、親に返せるのは最終レポートのテキストだけです。つまり各階層が「下から受け取った結果を要約して上に返す」を繰り返すため、5階層では要約の要約の要約が親に届きます。私のケースでは、親が指定した文体上の細かい制約が3階層目あたりで落ち、5階層目の校正役には伝わっていませんでした。逆方向も同じで、最下層が発見した重要な違和感が、上がってくる間に1行の言及に圧縮されていたこともあります。
コストも素直に増えます。各階層が並列数を持つと呼び出し回数は乗算的に膨らみ、3階層×各3並列で27、4階層なら81です。深さはコンテキストの分離という利益と、情報減衰・コスト増という負債を同時に連れてきます。
私の結論 — 責務が3種類なら3階層で止める
数日試して落ち着いたのは、階層数はタスクの責務の種類数に合わせるという基準です。ブログ自動運用の場合、責務は「全体の計画と集約」「対象ごとの実行」「成果物の検証」の3種類なので、3階層で止めました。
- 親（計画）: テーマの重複チェックと、どのサイトに何を作るかの割り当てだけを行います。本文の中身には踏み込みません
- 子(実行): 1サイト分の記事生成に専念します。参照データの読み込みもこの階層に閉じます
- 孫（検証）: 品質ゲートの実行と判定だけを担当します。生成と検証を別コンテキストに分けることで、生成役が自分の文章を甘く採点する問題も避けられます
重要なのは、4階層目を足したくなったときに「それは新しい責務なのか、既存の責務の細分化なのか」を問うことだと感じています。セクション執筆は「実行」の細分化であって新しい責務ではないので、階層を増やすのではなく子のプロンプト内の手順として書く。この線引きをしてから、構造の見通しが大きく良くなりました。
深い委譲を組むときに守っている実務ルール
個人開発の限られた時間で3階層構成を安定運用に乗せる過程で、いくつかのルールが固まりました。
返すべき成果物の形式を各階層に明示する。要約減衰への対策として、各サブエージェントへの指示に「最後に必ずこの形式で報告する」という出力契約を書きます。私は次のような断片を子・孫の全プロンプトに入れています。
## 報告形式（必須・省略禁止）
- 成果物のパス: <生成/検証したファイルの絶対パス>
- 判定: PASS / FAIL のどちらか1語
- FAIL の場合: 違反項目を原文のまま引用（要約しない）
- 上位への申し送り: 1〜3行「原文のまま引用、要約しない」の一文が特に効きます。これがないと、検証役が見つけた違反が上に届く頃には「軽微な問題あり」に丸められてしまいます。
大きな状態はテキスト報告ではなくファイルで渡す。階層をまたいで受け渡す情報が増えるほど、レポート経由の受け渡しは破綻します。生成物や中間データはファイルに書き、報告にはパスだけを載せる方式が堅実でした。この設計は Subagent 間で状態を渡す3つの設計パターン — 4ヶ月のブログ自動生成で見えた使い分け で詳しく扱っています。
孫の沈黙は親から見えないと心得る。ネストが深くなると、最下層で止まったタスクの兆候が上位からは「子の応答が遅い」としか観測できません。各階層にタイムアウトの目安と「進捗がなければ部分結果で切り上げて報告する」指示を入れておくと、全体が道連れになる事故を防げます。返ってこないサブエージェントの切り分け自体は Claude Code のサブエージェントが結果を返さない時の診断手順 の手順がそのまま使えました。
まずはフラット構成の「中継だけの工程」を1つ下げてみる
5階層ネストは、使い倒す機能というより「設計の上限が外れた」と捉えるのが健全だと考えています。既にサブエージェントを並列で使っている方なら、最初の一歩としておすすめしたいのは、親エージェントが単に結果を右から左へ渡しているだけの工程を1つ見つけて、それを子の配下に移すことです。親のコンテキストが軽くなる効果は、その日のうちに体感できるはずです。
私自身、まだ運用を始めて数日の段階なので、長期で回したときの安定性はこれから見極めていきます。同じように多段の自動化を組んでいる方の参考になれば幸いです。