一行でいうと
メインの会話とは別のコンテキストウィンドウで働く、専門ワーカーです。自分の頭の中で作業して、結果の要約だけを返してきます。
仕事は別室へ渡し、メインの会話には整理された結果だけを戻します。
なぜ必要になったのか
調査を今の会話でやらせると、会話そのものが汚れます。サブエージェントは、この汚れを外に出す仕組みです。
Claudeに「このフォルダの全ファイルを調べて」と頼むと、何が起きるか。読んだ内容が全部、今の会話に流れ込みます。
その結果、こうなります。
- 会話が調査ログで埋まり、本来の作業の文脈が薄まる
- 前半で決めたはずのことを、後半で見失う
- 長くなった会話ほど、指示が効かなくなる
公式ドキュメントはこれを「キッチンシンク・セッション（流し台に何でも突っ込んだ状態）」と呼んでいます。ひとつのタスクで始めて、関係ない質問をして、また元のタスクに戻る。気づけばコンテキストが無関係な情報だらけになっている。
調査は別の頭にやらせ、こちらには結論だけが返ってくる。それが、サブエージェントの役割です。
仕組み: 新しく生まれた別人格
ここが理解の勘所です。サブエージェントは、あなたの会話の記憶を引き継ぎません。
公式のエンジニアリングブログ「Effective context engineering for AI agents」も、この設計の効果を数字で示しています。専門化したサブエージェントが自分のコンテキストで調べ物をこなし、メインの会話に返すのはだいたい1,000から2,000トークンに凝縮した要約だけです。どれだけ大量に読んでも、戻ってくる分量はこの範囲に収まります。
「優秀だが、事情を何も知らない外部の人」に依頼するイメージが近い。だから指示文には前提を書く必要があります。ここを忘れると、的外れな報告が返ってきます。
考案者のSid Bidasariaも、この設計を振り返って同じことを語っています。狙いはうまくいくと分かっている一番シンプルなことをやることで、今の実装はサブエージェントをツールとして扱う形になっています。
“I think when we first launched subagents, there was no good way for kind of like everyday users of an agentic coding product to create their own custom subagents. And the idea really was let's do the simple thing that works, right? It's like we want to do the absolute simplest thing that we know will work and people can play around with and experiment with. Right now, the way at least it's implemented in Claude code is it's subagent as a tool, it's an agent as a tool.”
筆者訳subagentsを最初にローンチした時、エージェント型コーディング製品の一般ユーザーが自分でカスタムsubagentを作る良い方法がなかった。本当の狙いは、うまくいくとわかっているシンプルなことをやろう、というものだった。確実にうまくいくとわかっている一番シンプルなことをやって、みんなが遊んだり実験したりできるようにしたかった。少なくとも今Claude Codeで実装されているやり方は、subagentをツールとして扱う、エージェントをツールとして扱う、というものだ。
$このフォルダの記事50本を調べて、内容が矛盾している組み合わせを探して。調査はサブエージェントに任せて、結果だけ表にまとめて
価値の核は「相関のない頭」
サブエージェントの価値は、速さではなく独立性にあります。作者のBoris Chernyも、そう説明しています。
同じ会話の中で3つの観点を検討させると、どうしても最初の観点に引きずられます。ところが、3つの別々の頭に独立して考えさせると、互いに相関のない結論が出てくる。その3つを突き合わせたほうが、結果の質が上がる。
これは第三者の意見を求めるときとまったく同じ理屈です。前任者の報告書を読ませてから意見を聞くのと、白紙の状態で見てもらうのとでは、意見の独立性が違います。
大きな仕事は「分けて配って、集める」形になります。メインが仕事を分割し、複数のサブエージェントに配り、結果を集約する。
よくある誤解と罠
罠1: 記憶が引き継がれると思っている
いちばん多い事故です。「さっき話した件で」と書いても、サブエージェントは何も知りません。指示文だけが世界のすべてです。
罠2: 直列の仕事を並列にしようとする
Aの結果が出ないとBに着手できない仕事は、いくら分身を増やしても速くなりません。並列で効くのは、互いに独立した仕事だけです。
罠3: 数を増やせば質が上がると思っている
増えるのはトークン消費です。質を上げるのは数ではなく、独立性と検証。3体に同じことを聞くより、3つの違う観点を割り当てるほうが効きます。
2026年に変わったこと
2026年、サブエージェントの扱いはより自動的になりました。
- バックグラウンド実行が既定になった（結果を即使う場合以外は裏で走る）
- サブエージェントがさらにサブエージェントを生む入れ子が可能に。深さは5階層まで
- 1セッションあたりの生成数の上限は既定200体
入れ子を作った本人Boris Chernyは、狙いを並列化の速さではなくコンテキスト管理だとはっきり説明しています。
“Just landed nested subagent support in Claude Code Starting to experiment more with agents kicking off agents as a way to better manage context. Capped at depth=5 to start, going out in today's release. Lmk what you think!”
筆者訳Claude Codeにネストサブエージェント対応がちょうど入った。エージェントがエージェントを起動する形をもっと試して、コンテキストをうまく管理する手段にしていきたい。まずは深さ5階層を上限にしている、今日のリリースに入る。感想を聞かせてほしい。
「気づいたら裏で何体も動いている」という状態が普通になりました。だからこそ、次の項目が効いてきます。
使いどころ
共通するのは、独立した目で見てほしい仕事です。
- 資料の一次スクリーニング（タイトル・要旨の振り分けを任せ、結論だけ受け取る）
- 長い業務マニュアルから該当箇所だけ抜き出す
- 自分の書いた原稿を「別の頭」に読ませて、独立に矛盾を探させる
- 複数の観点でのレビュー（構成・エビデンス・表現をそれぞれ別の頭に）
最後のものが、次の「Agent Teams」につながります。
今日のまとめ
- サブエージェントは別コンテキストの部下。会話を汚さず、要約だけ返す
- 記憶は引き継がれない。指示文に前提を書く
- 価値は速さより「相関のない独立した頭」。第三者の意見と同じ理屈
定義ファイルの書き方、モデル指定、並列実行と上限。
サブエージェントがなぜコンテキストを汚さずに済むのか、設計思想の一次資料。
次は、その部下たちが互いに話し始める「Agent Teams」です。