Subagentがある分野により詳しいわけではないなら、タスクを委任する際に「役割」を特別に記述する必要はありますか？
役割の記述がまったく無意味というわけではないが、その効果は一般的に過大評価されている。役割記述が本当に効果を発揮するのは、Claudeがその隔離されたコンテキスト内で、比較的一貫したトーンや視点でタスクを処理する助けになる場面だ（例えば「セキュリティ監査」の視点でコードをレビューするよう求めると、スタイルの問題ではなく脆弱性に出力が集中しやすくなる）。これは「フィルターを設定する」ことに近く、「追加の知識を与える」ことではない。
むしろ力を入れる価値があるのは、委任時に添えるタスク記述そのものを十分具体的にすることだ——Subagentにはメイン対話の背景がないため、タスク記述が曖昧だと、Subagentは推測で欠けた文脈を補うしかなく、期待からずれた結果を出しやすくなる。役割設定に形容詞を積み重ねるより、タスクの範囲と期待される出力形式を明確に書くことに時間を使う方がよい。
タスク自体は複雑ではないが、過程で多くのファイルを読む必要がある場合、これもSubagentを使うべきシグナルと言えますか？
答えはイエスであり、これはまさに「タスクの難易度」と「隔離すべきかどうか」が異なる2つの判断軸であることを示している。タスク自体は単純でも（例えば「このプロジェクト内で非推奨関数を使用しているすべての箇所を見つける」）、その過程で大量のファイル検索が必要で、大量の中間結果が生成される場合、タスク自体に「専門的判断」が不要であっても、Subagentへの委任は良いタイミングだ——なぜなら本当に隔離すべきは検索過程で生じるノイズであり、タスクの難易度ではないからだ。
逆に、難しいタスク（複雑なデータベース移行戦略の設計など）で、思考プロセス全体がメイン対話が既に持っているプロジェクトの文脈と密接にやり取りしながら進める必要がある場合、メイン対話の履歴が見えないSubagentへの委任はむしろ不向きだ。必要な背景情報が大幅に欠けてしまうからだ。判断基準は常に「ノイズが蓄積するかどうか」であり、「タスクが難しそうに聞こえるかどうか」ではない。
Subagentが返す結果要約に、メイン対話が後で必要とする詳細が漏れていた場合、救済する方法はありますか？
これは委任設計で最も陥りやすい落とし穴だ。メインAgentはSubagentの最終的な結果要約しか受け取らないため、その要約に含まれなかった中間の詳細は、Subagentの実行が終了した時点で事実上失われる。後から「詳細を聞き返す」ことはできない——そのコンテキストはもう存在しないからだ。
実務上の対策は、委任のタスク記述を書く段階で「このタスク終了後、メイン対話が後で必要とする可能性のある情報は何か」をあらかじめ考え抜き、それらの項目を要約に含めるよう明確にSubagentに要求することだ。結果が返ってきてから何かが漏れていたと気づくのでは遅い。もし本当に重要な詳細が漏れてしまった場合、通常は新しいSubagentを起動し直し、タスク範囲をその欠けていた部分を含むように調整して、もう一度実行するしかない——これこそが、事後の救済よりもタスク記述を十分完全に書くことの方がはるかに重要である理由だ。
私は普段Claude Codeではなく claude.ai のブラウザ版でチャットしていますが、このSubagentの仕組みは私に関係がありますか？
Subagentは現在、主にClaude Codeのような、ファイルシステムアクセスと複数ターンのツール呼び出し能力を持つエージェント的環境で使われており、ウェブ版チャットインターフェース自体にはこの機能はない。しかし、このメカニズムの背後にある判断ロジックを理解することは、どんな場面でClaudeと協働する場合でも役立つ——特に「ノイズを隔離すること」と「能力を追加すること」が別のことだという原則は、あなた自身が一つの対話をどう組み立てるかにも同様に当てはまる。
例えば、同じ対話スレッドの中で先に大量の探索的なデータ収集を行い、その後、そのノイズに邪魔されたくない集中力を要する分析タスクに移りたい場合、新しい対話ウィンドウを開き、精製された要点だけを貼り付けることは、実質的にSubagentがやろうとしていることを手動で再現しているに等しい——すべてを一つのウィンドウに詰め込み、Claude自身にノイズと信号を選り分けさせることを期待するのではなく、クリーンなコンテキストと引き換えに品質を得るという発想だ。
初めてSubagentに触れる人は、直感的だが誤ったメンタルモデルを頭の中に作りやすい：メインAgentは「ジェネラリスト」で、Subagentはそれぞれの分野に特化した「専門家」であり、コードレビューには「コードレビュー専門家」を、リサーチタスクには「リサーチ専門家」を呼び出す——まるで各Subagentの内部に異なるバージョンの、能力の違うClaudeが搭載されているかのように。
この直感は十分理解できる——大半のSubagentの名前やdescriptionは、専門的な役割を記述しているように見えるからだ。しかしこのモデルは仕組みとして誤りだ。Claudeはどの一つのコンテキストウィンドウにおいても、もともと完全な知識を備えており、「Subagent」として割り当てられたからといって、ある分野に詳しくなるわけではない。Subagentが実際に行っていることは、能力を増やすことではなく、隔離を増やすことだ。
メインAgentがあるタスクを委任するのに適していると判断すると、Subagentを起動する——このSubagentは完全に独立した、まったく新しいコンテキストウィンドウを持ち、メイン対話の履歴を継承せず、メインAgentがそれまでに読んだファイル、呼び出したツール、使用したSkillも見えない。メインAgentがSubagentに情報を伝える唯一の手段は、委任時に添えるタスク記述のテキストだけだ。
Subagentはこの自分だけのクリーンなコンテキスト内で、ファイルを読み、コードを検索し、コマンドを実行し、タスクを独立して完了する。その過程で生成されるすべての中間情報はSubagent自身のコンテキストに留まり、メインAgentはこのプロセスをまったく見ることができず、Subagentが最後に返す結果の要約だけを受け取る。この特性は、Subagent同士、およびSubagentとメイン対話との間の情報伝達が、「委任時のタスク記述」と「完了後の結果要約」という2つの狭い窓口だけに限られることを意味し、探索過程で蓄積されたノイズは一切外に漏れない。
Subagentがなぜ重要かを理解するには、まずそれが解決する本来の問題を理解する必要がある：標準的なClaude Codeの対話は固定サイズのコンテキストウィンドウを持ち、数時間に及ぶプロジェクトでは、探索的なファイル読み込み、コード検索、ウェブ検索から蓄積される出力だけでも、かなりの割合を占める可能性がある。一度の探索で50個のファイルを読んで本当に必要な1個を見つけた場合、残り49個のファイルの内容は依然としてコンテキストに残り続け、その後のすべての応答生成時にモデルが本当に集中できる情報密度を継続的に薄めていく。
この現象はしばしば「コンテキスト腐敗」（Context Rot）と呼ばれる——モデルが賢さを失ったわけではなく、モデルがコンテキスト内のすべての内容に同等に注意を払わなければならず、ノイズの割合が上がるにつれて本当に重要なシグナルが自然に薄まってしまうということだ。Subagentが解決するのはまさにこの問題である：探索過程で大量のノイズを生み出す作業を、使い捨ての独立したコンテキストに隔離することで、ノイズがメイン対話にまったく流れ込まないようにし、メインAgentは精製された結果だけを受け取る。
Subagentを「ある分野により詳しい専門家」と誤解すると、Subagentのdescriptionや委任タスクを設計する際、身分や専門的背景を強調する記述（例えば「あなたはシニアセキュリティ監査専門家です」）になりがちで、本当に検討すべき点を見落としてしまう：このタスクは、メイン対話が見る必要のない大量の中間プロセスを生成するかどうか？もし答えがノーであれば——タスク自体の出力が簡潔で、大量の探索を伴わない場合——Subagentに委任することは、新しいコンテキストを起動し背景情報を再収集する遅延コストを増やすだけで、実質的なメリットがない可能性がある。
正しい設計思考は逆から問うべきだ：このタスクは、メインコンテキストに残しておく必要のない大量のノイズを蓄積するか？特定のツールの使用権限を制限する必要があるか？作業自体が自己完結しており、簡潔な要約にまとめて返せるものか？この3つの問いへの答えが肯定的であるほど、Subagentへの委任の価値は高まる——重要なのは常に「隔離すべきかどうか」であり、「誰がより詳しいか」ではない。
Subagentが「専門家」ではないと明確になれば、Skillとの分業の境界線もはっきりする：Skillは再利用可能な知識やワークフローを、メイン対話の既存コンテキストに直接読み込むもので、「強化」に属する。Subagentは独立したコンテキストを起動してタスクを実行し、結果をメイン対話に収束させるもので、「隔離」に属する。現在の対話でClaudeに新しい能力を持たせたいときはSkillを探し、大量のノイズを生む可能性のあるタスクを見えない場所に移したいときはSubagentを探すべきだ。両者は組み合わせて使うこともでき、例えばSubagentに特定のSkillを事前に読み込ませ、隔離されたコンテキスト内でその能力を活用させることができる。
もう一つ注目すべき点は、Subagent同士は入れ子になって起動できないということだ——あるSubagentが実行中に本来なら委任をトリガーするような状況に遭遇した場合、それはさらに次の層のSubagentを生成するのではなく、自身のコンテキスト内で直接処理する。これは隔離メカニズム自体が新たな複雑性の源にならないようにするためでもある。
次にSubagentを使うかどうかを検討する前に、「このタスクには専門家が必要」という発想を手放し、代わりに自問しよう：このタスクを完了する過程で生成される詳細のうち、メイン対話が本当に保持しておく必要のあるものはどれくらいあるか？答えがゼロに近ければ、それこそがSubagentに委任すべき本当のシグナルであり、タスクの難易度や「専門知識」が必要かどうかとはまったく関係がない。委任タスクを設計する際は、役割設定を積み重ねるよりも、「メイン対話にとってどんな要約が返ってくれば最も役立つか」に重点を置く方が、Subagentの本当の価値を発揮できる。