実践コースのLesson 9: コンテキスト管理を最適化するでは、サブエージェントを「コンテキストを節約する手段」として簡単に紹介しました。本ガイドでは、その先にある設計思想にまで踏み込みます。サブエージェントをいつ・どう使うべきか、メインエージェントとの役割分担をどう設計するか、そしてどんな失敗パターンに陥りやすいか。サブエージェントを「なんとなく便利な機能」から「意図的に設計するもの」へと理解を進めるためのガイドです。
このガイドで学べること
- サブエージェントが存在する根本的な理由
- メインエージェントとサブエージェントの役割分担の設計思想
- 並列実行と逐次実行をどう使い分けるか
- サブエージェントへのコンテキスト受け渡しの設計パターン
- 委譲しすぎ・コンテキスト共有不足といった、よくある失敗パターン
サブエージェントとは何か、なぜ必要か
サブエージェントとは、メインの会話とは独立したコンテキストウィンドウを持つ、特化型の「作業者」です。Claude Codeがコードベースを調査するとき、関連するファイルを何十個も読むことがありますが、それをメインの会話で行うと、調査の過程で読んだファイルの内容がすべてメインのコンテキストに残り続けます。
サブエージェントに調査を委譲すると、そのファイル群はサブエージェント側のコンテキストに留まり、メインの会話には「調査結果の要約」だけが返ってきます。これにより、メインの会話は本来のタスク（実装や意思決定）に集中できる状態を保てます。
graph TD
M["メインエージェント<br/>（実装・意思決定に集中）"]
S1["サブエージェントA<br/>（コードベース調査）"]
S2["サブエージェントB<br/>（実装後のレビュー）"]
M -->|"調査を委譲"| S1
S1 -->|"要約のみ返す"| M
M -->|"レビューを委譲"| S2
S2 -->|"指摘事項のみ返す"| M
style M fill:#e8f4fd,stroke:#1a73e8
style S1 fill:#fff3e0,stroke:#e65100
style S2 fill:#fff3e0,stroke:#e65100サブエージェントが必要とされる根本的な理由は、Claude Codeのコンテキストウィンドウが有限のリソースであり、満杯に近づくほど応答の品質が低下するという制約にあります。コンテキストを「使い切ってから心配するもの」ではなく、「常に管理すべき資源」として捉えたとき、サブエージェントへの委譲は最も強力な管理手段のひとつになります。
Claude Codeには、Explore（コードベース探索に特化した高速・読み取り専用エージェント）やPlan（実装計画の立案に特化したエージェント）といった組み込みのサブエージェントがあらかじめ用意されています。カスタムサブエージェントを作る前に、まずはこれらの組み込みエージェントがどう動くかを観察してみると、設計の感覚がつかみやすくなります。
メインエージェントとサブエージェントの役割分担の設計思想
サブエージェントを使いこなす上で最も重要なのは、「何でも委譲すればいい」わけではないという理解です。役割分担を設計する際の基本的な考え方を整理します。
メインエージェントは「意思決定と全体像」を担う
メインエージェントの役割は、ユーザーとの対話を通じて要件を理解し、タスク全体の計画を立て、最終的な実装判断を下すことです。複数のサブエージェントから返ってきた情報を統合し、矛盾があれば調整し、次のアクションを決定する「指揮者」のような立場にあります。
サブエージェントは「閉じたタスク」を担う
サブエージェントが向いているのは、入力と出力が明確で、途中の過程をメインの会話に残す必要がないタスクです。
| サブエージェントに向くタスク | 理由 |
|---|---|
| 大規模なコードベースの調査 | 大量のファイル読み込みが発生し、結果は要約で十分 |
| 実装後の独立したレビュー | 実装の文脈を引きずらない視点が価値を持つ |
| 並行して進められる独立した検証 | メインの作業を止めずに進められる |
| 定型化された繰り返し作業 | 同じ指示で何度も呼び出せる |
逆に、要件があいまいで対話を重ねながら詰めていく必要があるタスクや、ユーザーの好みやプロジェクトの文脈を逐一参照しながら進めるべきタスクは、サブエージェントに切り出すとかえって非効率になりがちです。サブエージェントはメインエージェントと違って、ユーザーと直接対話しながら方向修正することができないためです。
サブエージェントには明確な指示を渡し、明確な成果物を受け取る、という一方向的な関係を基本に設計しましょう。「どう進めるべきか一緒に考えてほしい」というような、対話を通じた方向性の模索はメインエージェントの役割であり、サブエージェントに持ち込むと指示が曖昧になり、成果物の質が安定しません。
並列実行 vs 逐次実行の使い分け
複数のサブエージェントを動かす際、並列に実行するか、順番に実行するかは、タスク間の依存関係によって決まります。
並列実行が適している場面
タスク同士が互いに独立しており、片方の結果がもう片方の入力にならない場合は、並列実行が有効です。たとえば「フロントエンドのコード規約を調査する」タスクと「バックエンドのAPI仕様を調査する」タスクは、互いに依存しないため並列に投げることができます。
graph LR
M["メインエージェント"]
A["サブエージェントA<br/>フロントエンド調査"]
B["サブエージェントB<br/>バックエンド調査"]
M --> A
M --> B
A --> R["結果を統合"]
B --> R
style M fill:#e8f4fd,stroke:#1a73e8並列実行の利点は、待ち時間を短縮できることに加えて、各サブエージェントが互いの調査結果に引っ張られず、独立した視点を保てることです。特にレビュー用途では、この「独立性」自体が価値を持ちます。
逐次実行が適している場面
一方のタスクの出力が、もう一方のタスクの入力として必要な場合は、逐次実行が必須です。たとえば「実装を行う」→「その実装をレビューする」という流れでは、レビューサブエージェントは実装結果（diff）を見て初めて意味のある指摘ができるため、並列化できません。
graph LR
M["メインエージェント"]
A["サブエージェントA<br/>実装"]
B["サブエージェントB<br/>実装をレビュー"]
M --> A --> B --> M
style M fill:#e8f4fd,stroke:#1a73e8実装を行ったセッションとは別の、新しいコンテキストでレビューさせる手法は「敵対的レビュー」とも呼ばれます。実装した本人（同じコンテキストを引きずっているエージェント）は、自分の実装の妥当性に無意識に引っ張られがちですが、新しいコンテキストのサブエージェントは diff と要件だけを見て、先入観なく評価できます。正確性を重視するレビューでは、この独立性が品質を大きく左右します。
判断のフローチャート
flowchart TD
A["複数のサブタスクがある"]
B{"タスクBはタスクAの<br/>結果を必要とするか?"}
C["逐次実行<br/>A → B の順で実行"]
D{"タスク同士は<br/>完全に独立しているか?"}
E["並列実行可能"]
F["部分的に依存関係あり<br/>依存する部分だけ逐次化"]
A --> B
B -->|はい| C
B -->|いいえ| D
D -->|はい| E
D -->|いいえ| F
style C fill:#fff3e0,stroke:#e65100
style E fill:#e8f5e9,stroke:#2e7d32サブエージェントへのコンテキスト受け渡し設計
サブエージェントは独立したコンテキストウィンドウを持つため、メインエージェントが知っている情報が自動的に引き継がれるわけではありません。何を、どう渡すかの設計が、サブエージェントの成果物の質を大きく左右します。
渡すべき情報を明示的に絞り込む
サブエージェントへの指示は、「何を調べてほしいか」「何を成果物として返してほしいか」を明確に書く必要があります。曖昧な指示を渡すと、サブエージェント側は何を優先すべきか判断できず、不要な範囲まで調査してしまったり、逆に必要な情報を見落としたりします。
良くない指示の例:
「認証まわりを調べて」
良い指示の例:
「認証システムがトークンのリフレッシュをどう処理しているか調査して。
既存のOAuthユーティリティ（src/auth/配下）があれば、その実装方針も
含めて報告して。報告は箇条書きで、関連ファイルのパスを明記すること」成果物のフォーマットを指定する
サブエージェントからの報告がメインエージェントにとって扱いやすい形になるよう、出力フォーマットも合わせて指示すると効果的です。「ファイルパスと行番号を明記してほしい」「指摘事項は深刻度付きでリストアップしてほしい」といった指定は、メインエージェントがその後の判断をスムーズに行うために役立ちます。
CLAUDE.mdの扱いに注意する
組み込みのExploreやPlanサブエージェントは、起動を高速・低コストに保つためにCLAUDE.mdや親セッションのgitステータスをあえて読み込みません。一方、それ以外の組み込み・カスタムサブエージェントは通常どおりCLAUDE.mdを読み込みます。「サブエージェントがプロジェクトのルールを守ってくれない」と感じた場合、まずはそのサブエージェントがそもそもCLAUDE.mdを読み込む種類のものかどうかを確認しましょう。
サブエージェントは新しいコンテキストウィンドウで動作するため、それまでのメインの会話でユーザーと交わしたやり取りの細かいニュアンスは引き継がれません。「さっき話していたあの件について」のような曖昧な参照ではなく、必要な背景情報を指示の中に書き下す必要があります。
よくある失敗パターン
サブエージェントの運用に慣れていないと陥りがちな失敗パターンを、実例ベースで紹介します。
失敗パターン1: 過度な委譲
「とりあえず全部サブエージェントに投げる」という運用は、一見効率的に見えて、実際には逆効果になることがあります。小さな確認作業や、対話しながら詰めるべき要件定義まで委譲してしまうと、サブエージェントとメインエージェントの間で何度も情報をやり取りする「往復コスト」が発生し、かえって時間がかかります。
対策: 委譲する前に「このタスクは入力と出力が明確に閉じているか」を自問しましょう。閉じていないタスクはメインエージェントで対話的に進める方が速いことが多いです。
失敗パターン2: コンテキスト共有不足
サブエージェントに「あれをやって」「いつものやつ」のような曖昧な指示を出し、必要な背景情報（プロジェクトの制約、関連ファイルの場所、期待する出力形式）を渡し忘れるパターンです。サブエージェントはメインの会話を見ていないため、こうした指示では見当違いの成果物が返ってくることが多くなります。
対策: 指示は「初めてこのプロジェクトに参加したメンバーに依頼する」つもりで、自己完結した文章にしましょう。
失敗パターン3: 並列化できないタスクを並列化してしまう
互いに依存関係のあるタスクを並列実行してしまうと、片方のサブエージェントが古い前提のまま作業を進めてしまい、後で統合する際に矛盾が生じます。たとえば「APIのインターフェースを設計する」タスクと「そのAPIを呼び出すフロントエンドコードを書く」タスクは、本来は逐次実行すべき関係です。
対策: タスクを並列に投げる前に、依存関係を一度紙に書き出してみる、あるいはメインエージェントに「これらのタスクは並列化できるか」を先に確認させるのも有効です。
失敗パターン4: レビューサブエージェントへの期待しすぎ
サブエージェントによるレビューは便利ですが、「指摘されたことがすべて」「指摘がなければ完璧」という過信は禁物です。レビューを依頼されたサブエージェントは、求められた通りギャップを探そうとするため、実装が健全であっても何かしらの指摘を返す傾向があります。すべての指摘を機械的に取り込もうとすると、過剰な防御的コードや、発生し得ないケースへの対応など、かえって複雑度を増す結果になりがちです。
対策: レビューサブエージェントには「正確性や要件充足に関わるギャップのみを報告し、スタイルの好みは対象外とする」など、報告の基準を明示しておきましょう。
実践コースとの関連
サブエージェントへの委譲は、Lesson 9: コンテキスト管理を最適化するで扱った「コンテキストウィンドウは有限の資源である」という前提の上に成り立つ実践です。本ガイドで扱った役割分担の設計思想は、Lesson 9で触れた「委譲が向いている場面」をさらに一段深掘りしたものだと位置づけてください。あわせて、複数プロジェクトを横断する場面でのセッション管理を扱うLesson 7: 複数プロジェクトで横断的に活用するも、関連する文脈として参考になります。
まとめ
サブエージェントは「コンテキストを節約する裏技」ではなく、メインエージェントとの明確な役割分担のもとに設計すべき仕組みです。メインエージェントが意思決定と全体像を担い、サブエージェントが閉じたタスクを担う。この基本構造を踏まえたうえで、タスクの依存関係に応じて並列・逐次を使い分け、自己完結した指示でコンテキストを受け渡す。これらを意識するだけで、サブエージェントは「なんとなく便利な機能」から「設計して使いこなす道具」へと変わっていくはずです。