サブエージェントの本当の効用は「速さ」ではなく「文脈の隔離」

Claude Code には「Agentツール」という仕組みがあります。これは、動いているエージェント（会話）の中から、別の独立したエージェント（会話）を子として起動できる機能です。子は親とは切り離された独自の文脈を持ち、独自にツール（ファイル読み書き・ターミナル・Web検索など）を使って作業を進め、終わったら親に結果を返します。

ここで重要なのは「独自の文脈」という部分です。AIの会話には、処理できる情報量に上限があります（これをコンテキストウィンドウと呼びます）。ひとつの会話の中で大量のファイル検索をしたり、何度もビルドエラーを繰り返したりすると、この枠が埋まっていきます。枠が圧迫されると、AIは過去のやりとりを参照しにくくなり、精度が落ちます。

サブエージェントを使うと、この「重い作業」を親の会話から切り出せます。子は別の文脈で汚れ仕事をこなし、親には結論だけ返す。親の会話は常にすっきりした状態を保てます。

具体的なイメージで言うと、ソフトウェアのE2Eテスト（実際に動くシステムを端から端まで通して確認するテスト）では、1回の実行で数十行から数百行のログが出ることがあります。しかも失敗したら原因を直して再実行、また失敗したら再実行、というデバッグループが必要です。この試行錯誤のログがすべて親の会話に流れ込んでくると、親の文脈は急速に消耗します。サブエージェントにこのループを任せ、「パスしたかどうか」だけを親に返すようにすれば、親は汚れません。

並列化による速度向上は、その副次的な恩恵にすぎません。本質は「机を分ける」ことにあります。

ネストの深さは「Agentツールを誰に渡すか」で決まる — 親方と職人モデル

多段のネストを理解するうえで、「親方と職人」という比喩が役立ちます。工務店を例にとってみましょう。現場監督（オーケストレーター）が全体の工程を管理し、大工・配管工・電気工（ワーカー）がそれぞれの専門作業を担います。親方は職人を束ねて指示を出し、作業結果を受け取ります。職人は自分の担当作業に集中します。職人の机がどれだけ道具や資材で散らかっていても、その散らかりは現場監督の机には出てきません。

Claude Code のサブエージェント設計でも、これと同じことができます。鍵になるのは「Agentツールを誰に渡すか」という設計上の判断です。

  • 親方（オーケストレーター）には Agentツールを渡す。子のエージェントを起動できる。つまり「さらに下にサブエージェントを持てる」。
  • 職人（ワーカー）には Agentツールを渡さない。自分の仕事はできるが子は起動できない。その工程で打ち止めになる。

この「渡す／渡さない」の設計だけで、ネストの階層を意図的に制御できます。実際、最深段のエージェントでは Agentツール自体が外れる仕様になっており（環境によって挙動は変わりますが、最大5段という上限が設けられています）、それ以上深くなれない安全装置が働きます。これは「意図せず無限に深くなる」ことを防ぐための設計と解釈できます。

職人の机（独立した文脈）でどれだけ作業が発生しても、親方の机には結論だけが届く。多段ネストを扱う際に最初に考えるべきは、まさにこの「Agentツールを誰に持たせるか」という一点です。

深くすればいいわけではない — 多段の弊害と「2層で足りるなら2層」の判断軸

ここまで読むと「なるべく多段にした方が良さそう」と感じるかもしれません。しかしrelmeaが実運用から得た結論は逆で、「必要な場面だけ深くする」です。多段ネストには固有の弊害があるためです。

多段ネストの3つの弊害

  • 伝言ゲームによる要件の劣化：司令塔の指示がオーケストレーターを経てワーカーに届くまで、段を経るほど細かいニュアンスが失われます。「少し厳しめにレビューして」が、2段3段を経ると「レビューした」という事実だけ返り、厳しさの水準が担保されなくなることがあります。
  • デバッグの追いにくさ：うまくいかなかったとき「どの段で失敗したか」を追うのが単層より格段に難しくなります。ログを追う手間が増え、根本特定に時間がかかります。
  • オーバーヘッドの増加：エージェントを起動するたびにコストと時間がかかります。単純な作業を多段に割っても、起動コストが積み重なるだけで旨味がありません。

relmeaの判断軸

relmeaが持つ判断軸はシンプルです。「その工程は、大量の中間ログを隔離しなければ親の文脈が圧迫されるか」。答えがNoなら、2層フラット（司令塔→サブエージェント直接）で動かします。Yesであり、かつ「ワーカーが独立して動ける作業単位として切り出せるか」も満たす場合に、初めて3層目を足す判断をします。

多段ネストは目的ではなく、文脈隔離という目的を達成するための手段です。relmeaでも、数十体規模のサブエージェントチームを運用しながら、多くの工程は今も2層フラット（メイン会話→サブエージェント）を設計判断として維持しています。「ネストできる＝すべき」ではありません。道具は必要な場面で使うものです。

多段ネストが効く工程・効かない工程 — relmeaの受入テストの実例

では具体的に、どんな工程が多段ネストに向いているのか。relmeaの開発フレームワーク（社内ではCrucibleと呼ぶ枠組み）の実例をもとに整理します。多段ネストが効く工程の特徴は、大きく3つあります。

効く工程1：大量の試行錯誤ログが出る工程

relmeaの受入テスト工程では、Playwright（ブラウザ自動操作によるテストツール）でシステム全体の動作確認を行います。このフェーズでは、オーケストレーター役のエージェントが「テスト実装役・デバッグ役・検証役」という3種類のワーカーを子として起動する多段構成を採用しています。テスト実装役が1件のテストを書いて実行し、失敗すればデバッグ役が原因を調べて修正し再実行する。この試行錯誤のすべてのログをオーケストレーターに返すのではなく、各ワーカーの文脈の中で完結させ、最後に「パスしたか否か」のサマリーだけを親に返す設計にしています。これにより、オーケストレーターの文脈は常にすっきりした状態を保てます。

効く工程2：検証役を実装役と別文脈に分けたい工程

実装を担当したエージェントに「自分の実装をレビューしてください」と頼んでも、どうしても甘い評価になりがちです（これは人間でも同じです）。実装役と検証役を別の文脈（別のサブエージェント）に分離すると、検証役は実装の経緯を知らない状態で独立したレビューができます。relmeaでは、この独立検証を担う役割を設け、実装フェーズとは別の文脈で敵対的にレビューする構成を採っています。

効く工程3：同種の作業を多数並列したい工程

たとえば複数のページを並行して実装する場合、各ページの担当ワーカーを並列で起動すれば、それぞれが独立した文脈で作業を進められます。あるページのビルドエラーが、別のページの実装に干渉しません。

逆に、効きにくい工程

  • 前のステップの結果を受けて次を判断する直列の意思決定（前後の依存が強く、途中で分離できない）
  • 短時間で終わる単純タスク（エージェント起動のオーバーヘッドの方が大きくなる）
  • 出力するログが少なく、親の文脈をほとんど消費しない工程

これらは、シンプルに2層フラットで扱う方が確実で速くなります。

始め方 — まず2層、大量ログが親を圧迫し始めたら1段だけネストする

実際に多段ネストを始めるにあたって、relmeaが推奨するアプローチは「最初から多段にしない」です。まず2層フラット（メイン会話からサブエージェントを直接起動する）で設計を始めてください。多くの作業はこれで十分です。

運用していく中で「この工程、大量のログが親に返ってきてコンテキストを圧迫しているな」と感じる場面が出てきたとき、初めてその工程だけに1段のネストを追加する判断をします。具体的な手順は次のとおりです。

  • 作業を「判断」と「手を動かす」に分ける：オーケストレーターが判断する部分と、ワーカーが手を動かす部分に切り分けます。ワーカー側が「大量のログを出す」「繰り返し試行が必要」「独立して動ける作業単位として切り出せる」の3つを満たしていれば、そこに1段のネストを足す価値があります。
  • ワーカーにはAgentツールを渡さない：これでネストはその1段で止まります。深さを意図的に決め、偶発的に増えないようにします。
  • ワーカーが親に返すのはサマリーだけにする：詳細なログをすべて返す設計にすると、ネストの意味がなくなります。「何をやって、どうなったか」を簡潔に返すよう指示に含めます。

多段ネストは、正しく使えば親の会話を長く・精度高く保つ強力な設計です。しかし深くすること自体が目的になった瞬間に、伝言ゲームとデバッグの難しさが始まります。まず2層から始め、必要になったら1段だけ足す。この判断軸を持っておくことが、Claude Code のサブエージェントをうまく使いこなす出発点になります。