Claude Codeのサブエージェントはいつ使うべき？判断基準を5つの問いで整理

「サブエージェントを使えばいい」は間違い

Claude Codeのサブエージェントは強力な仕組みですが、何でも委譲すればいいわけではありません。コンテキストの節約になる場面もあれば、逆にコストが増えたり管理が煩雑になったりする場面もあります。

サブエージェントを使う根拠は「コンテキストの分離」です。 側タスクが大量のファイルや出力を読み込む場合、それをメインの会話に持ち込むとコンテキストを圧迫し、後続の指示の精度が下がります。サブエージェントはそのタスクを別のコンテキストウィンドウで処理してサマリーだけを返すため、メインの会話をクリーンに保てます。

逆に、単純な1ファイル修正や短い調査はサブエージェントを挟まず直接依頼する方が速くてシンプルです。判断を間違えると、「サブエージェントを立ち上げたが結果を読み解くのが大変で、直接聞いた方が早かった」という状況になります。

このページでは「使うべき場面」「使わなくていい場面」を5つの問いで整理し、すぐ判断できる枠組みを提供します。

サブエージェントの仕組み（組み込み3種、スコープ4種、frontmatterフィールド）はClaude Codeのサブエージェントとは？使いどころと注意点で扱っています。このページは「いつ使うか」の判断に絞った内容です。

5つの判断基準

問い1：タスクが「読み込み量が多い調査」か？

大量のファイルを横断して調べる調査タスクは、サブエージェント委譲の最有力候補です。

公式ドキュメントでは「Delegate research with ‘use subagents to investigate X’. They explore in a separate context, keeping your main conversation clean for implementation.（調査はサブエージェントに委譲せよ。別コンテキストで探索し、メイン会話を実装向けにクリーンに保つ）」と明記されています。

サブエージェントに向く調査タスク例：

• 「認証フローがどう実装されているか調べてほしい」（複数ファイルにまたがる）
• 「既存のOAuthユーティリティがないか探してほしい」（横断検索）
• 「このエラーに関連するコードを網羅的に探してほしい」（grep系の大量読み込み）

依頼例：

Use subagents to investigate how our authentication system handles token refresh, and whether we have any existing OAuth utilities I should reuse.

この場合サブエージェント（Explore）が別コンテキストでファイルを読み込み、サマリーだけを返します。メイン会話は調査結果を受け取って実装に集中できます。

直接依頼でよい調査タスク例：

• 「この関数の引数の型を確認して」（1ファイル・短い確認）
• 「package.jsonのバージョンを教えて」（即答できる単純な参照）

問い2：タスクが「並列に進めてよいか」？

複数の独立したタスクを同時に進めたい場合、サブエージェントは有効です。片方の結果を待たずに両方を動かせます。

並列化が有効な例：

• 「フロントエンドのバグ調査」と「バックエンドのAPIエラー調査」を同時に
• 「セキュリティレビュー」と「パフォーマンス計測」を同時に
• 「テスト追加」と「ドキュメント更新」を同時に（互いに依存しない場合）

並列化できない例：

• AのコードをBが参照する（前後依存がある）
• 同一ファイルを2つのエージェントが編集する（競合する）

依存関係があるタスクを無理に並列化すると、片方の結果が出る前にもう片方が間違った仮定で動き始めます。並列化はあくまで「独立している」タスクにのみ有効です。

問い3：「結果がメインの会話に不要なゴミ」になるか？

サブエージェントに向くタスクのもう一つの指標は、「大量の出力が出るが、その詳細はメインの会話では使わない」場合です。

典型例：

メインの会話にすべて流し込むと、後の指示が「ノイズの海」に埋もれます。サブエージェントが出力を処理してサマリーだけを返す構造にすることで、メインのコンテキストを守れます。

問い4：「専門的な制約を持たせたいか」？

特定の役割に特化させたいとき（読み取り専用・特定ツールのみ・特定モデルなど）、カスタムサブエージェントを作ると再利用しやすくなります。

よく使われるカスタムサブエージェントのパターン：

セキュリティレビュー専用：

---
name: security-reviewer
description: コードのセキュリティ問題（インジェクション・認証・秘密情報漏えい）をレビューする
tools: Read, Grep, Glob, Bash
model: opus
---
セキュリティエンジニアとして、コードを以下の観点でレビューしてください：
- インジェクション脆弱性（SQL・XSS・コマンドインジェクション）
- 認証・認可の不備
- 秘密情報や資格情報のハードコード
- 安全でないデータ処理

具体的な行番号と修正案を提示してください。

読み取り専用の調査エージェント：

---
name: repo-scout
description: コードベースを調査して構造・パターン・実装を要約する。変更は行わない。
tools: Read, Grep, Glob
model: haiku
---
リポジトリを読み取り専用で調査し、指定された内容についての要約を返してください。
ファイルの変更は一切行いません。

このような専門エージェントを.claude/agents/に置いておくと、「セキュリティレビューエージェントを使ってこのPRをレビューして」のように自然言語で呼び出せます。

問い5：「コスト・速度のトレードオフを意識しているか」？

サブエージェントは追加のAPIリクエストを発生させます。単純なタスクをサブエージェントに投げるとオーバーヘッドが増えます。

モデル選択とコストのポイント：

• 組み込みの Explore エージェント はClaude Haikuを使用するため、読み取り専用の調査には高速・低コストです
• カスタムサブエージェントでモデルを指定しない場合は親会話のモデルを継承します
• 単純な調査タスクは model: haiku を指定すると節約できます

コスト管理の詳しい観点は別記事で扱います。ここでは「単純な作業に多機能なサブエージェントを使わない」という原則を押さえてください。

判断フロー：サブエージェントを使うべきか

以下のフローで判断できます。

依頼が来た
│
├─ 大量ファイル読み込みが必要？
│    YES → サブエージェント（Explore or general-purpose）
│    NO  → 次へ
│
├─ 独立した並列タスク？
│    YES → サブエージェント（複数起動）
│    NO  → 次へ
│
├─ 結果の詳細がメインに不要（サマリーだけ欲しい）？
│    YES → サブエージェント
│    NO  → 次へ
│
├─ 専門的な制約・役割を持たせたい？
│    YES → カスタムサブエージェント
│    NO  → 次へ
│
└─ 上記すべてNO → 直接依頼で十分

使わなくていい場面（よくある誤用）

単純な1ファイル修正

「この関数の引数の型を変えて」「このコメントを更新して」のような変更は、サブエージェントを挟む必要はありません。コンテキストへの影響が小さく、直接依頼の方が速いです。

すでに目の前にある情報の確認

「さっき見たエラーの行番号は？」のような、現在のコンテキストにある情報の確認をサブエージェントに投げると、空のコンテキストで始まるサブエージェントは答えられません。

前の作業結果が必要な逐次タスク

「AをやってからBをやって」という前後依存のあるタスクを別々のサブエージェントに投げると、後続エージェントが前の結果を知りません。この場合は同じコンテキストで続けるか、前のエージェントの出力を明示的に渡す必要があります。

サブエージェントが多すぎる（増えすぎ防止）

サブエージェントを増やすと管理コストも上がります。「同じ役割のサブエージェントを複数作っている」「呼び出したことすら忘れている」という状況になったら、役割を統合することを検討してください。/agentsコマンドで現在の一覧を確認できます。

実際の使い方：依頼文の例

調査をサブエージェントに委譲する

Use subagents to investigate how our authentication system handles
token refresh. Return a summary of the key files and logic flow.
Don't make any changes.

実装後のレビューをサブエージェントに委譲する

Use a subagent to review the rate limiter implementation in
@src/middleware/rateLimiter.ts for edge cases and race conditions.

カスタムサブエージェントを明示指定する

Use the security-reviewer agent to review @src/api/user.ts

サブエージェントを使うか使わないかは、依頼文に「Use subagents to …」または「Use a subagent to …」を入れるかどうかで制御できます。書かなければClaude Codeが自動判断しますが、明示指定した方が意図が伝わりやすいです。

コンテキスト設計との関係

サブエージェントの判断はコンテキスト設計の一部です。コンテキストを守る方法は「入れない」か「別コンテキストで処理させる」かのどちらかで、サブエージェントは後者にあたります。

全体的なコンテキスト管理の観点（3層モデル・/clear・Hooks前処理など）はClaude Codeに必要な情報だけ渡すコンテキスト設計で詳しく扱っています。

まとめ：5つの問いで判断する

サブエージェントを使うかの判断は次の5問で決まります。

1. 大量ファイルを横断する調査か？ → YES なら Explore or general-purpose
2. 並列に進められる独立タスクか？ → YES なら複数サブエージェント
3. 詳細はメインに不要・サマリーだけほしいか？ → YES なら委譲
4. 専門的な制約を持たせたいか？ → YES ならカスタムサブエージェント定義
5. 上記すべてNOか？ → 直接依頼で十分

サブエージェントは「コンテキストを守る手段」です。使う目的が「コンテキスト分離」にあるときだけ使い、それ以外は直接依頼でシンプルに進めましょう。

サブエージェントの仕組みをさらに深堀りしたい場合はClaude Codeのサブエージェントとは？使いどころと注意点を、タスクの粒度設計を学びたい場合は大きな開発タスクをClaude Codeに渡す前の分解方法を参照してください。