Claude Codeサブエージェント完全解説：使うべき5場面と使わない場面

コードを書かないAIエンジニア@もるふぉです。

Claude Codeのサブエージェント、ちゃんと使いこなせていますか。

セッションが長くなるにつれてレスポンスが鈍くなってきた経験、ありませんか。

「あれ、なんか遅くなったな」「さっきまでちゃんと動いてたのに」——そのヤキモキ、コンテキスト枯渇が原因であることが多いんですよ。

大量のファイルを読ませて、何度もやり取りして、コードレビューもして...と積み重ねていくと、コンテキストウィンドウが圧迫されて応答品質がじわじわ落ちていきます。

この問題への回答として、Anthropicが2026年4月7日に公式ブログ記事を公開しました。

タイトルは「How and When to Use Subagents in Claude Code」。

Claude Codeのサブエージェントを「いつ使うべきか」「いつ使わないべきか」の判断基準が、かなり具体的に書かれています。

この記事では、その公式ブログの内容をエンジニア向けに日本語で解説します。

「サブエージェントって聞いたことはあるけど、実際どう使い分ければいいの？」という疑問に、公式が出した答えをそのままお届けします。

How and when to use subagents in Claude Code | Claude

When to delegate research, parallelize tasks, or get a fresh review with Claude Code subagents—and when to stick with the main session.

claude.com

サブエージェントとは何か──メイン会話とは別の「独立したClaude」

まず「サブエージェントとは何か」を正確に押さえておきましょう。

仕組みが分かると、なぜコンテキスト枯渇に効くのかが腑に落ちます。

コンテキストウィンドウが分離される本質的な意味

Claude Codeのサブエージェントは、メインの会話とは別の独立したコンテキストウィンドウを持つClaudeインスタンスです。

Anthropicの公式ブログでは次のように定義しています。

A subagent is an isolated Claude instance with its own context window. It takes a task, does the work, and returns only the result.

ポイントは「コンテキストウィンドウが分離されている」という点です。

「ブラウザのタブ」をイメージすると分かりやすいですね。

メインの作業タブはそのままに、別タブで調査を進めて、結果だけをメインに持ってくる。

メインのコンテキストにはノイズが入らない。

これがサブエージェントの本質的な価値です。

通常の会話との処理フローの違い

通常の会話とサブエージェントでは、処理フローが根本的に異なります。

通常の会話フロー：

1. ユーザーが指示を出す
2. Claude Codeがファイルを読む（コンテキストに追加される）
3. Claude Codeが処理する（コンテキストに追加される）
4. 結果を返す（コンテキストに追加される）
5. 次の指示...（ここまでの全履歴がコンテキストに残る）

サブエージェントを使ったフロー：

1. ユーザーが指示を出す
2. メインのClaudeがサブエージェントを起動する
3. サブエージェントが独自のコンテキストで作業する
4. 結果のサマリーだけがメインに返される
5. メインのコンテキストには結果だけが残る

この違いは実務で大きな差を生みます。

例えば「このコードベースのAPI設計を調査して」という指示を出すと、通常の会話では数十ファイルの内容がコンテキストを埋め尽くしますが、サブエージェントなら「APIは3つのグループに分かれていて...」という要約だけがメインに返ってきます。

つまり、「何十ファイルも読んだ重さ」を一切メインに持ち込まずに、必要な情報だけを受け取れるんです。

さらにサブエージェントには複数の権限レベルを設定できます。

リサーチ用のサブエージェントには読み取り専用アクセス、実装用には編集権限を与える、といった使い分けが可能です。

ビルトインのサブエージェントタイプは3種類あります。

仕組みが掴めたところで、次は「いつ使うのか」という実用上の核心に入ります。

ここが、公式ブログで一番面白いところなんですよ。

Anthropicが示す「使うべき5つの場面」

ここからが本記事の核心です。

Anthropicの公式ブログが示した「サブエージェントを使うべき5つの場面」を、それぞれ解説します。

特に重要なのが、公式が提示した具体的な数値基準です。

公式ブログでは、10ファイル以上を探索する必要がある場合、または3つ以上の独立したタスクがある場合は、サブエージェントへの委譲を検討すべきだとしています。

「10ファイル以上」「3つ以上の独立タスク」——抽象的ではなく数値で判断できるのが地味にありがたいですよね。

迷わずに済みます。

リサーチが重いタスク（ファイル10個以上が目安）

サブエージェントが最も効果を発揮する場面の一つが、リサーチ重視のタスクです。

例えば「このプロジェクトの認証フローを調べて」という指示。

実際にやるとなると、コントローラー、ミドルウェア、設定ファイル、テストコードなど、10個以上のファイルを横断的に読む必要があります。

通常の会話でこれをやると、読んだファイルの内容がどんどんコンテキストに積み上がり、後半の分析精度が下がります。

サブエージェントに委譲すれば、調査結果の要約だけが返ってくるので、メインのコンテキストはクリーンなままです。

Before I implement user notifications, use a subagent to research:
- How are emails currently sent in this codebase?
- What notification patterns already exist?
- Where should new notification logic live?

Summarize findings, then we'll plan the implementation together.

ファイル10個という基準は実感とも合います。

5〜6ファイル程度なら普通の会話で十分ですが、10個を超えるとコンテキストの圧迫が体感できるようになります。

依存関係がない3つ以上の並列タスク

2つ目の場面は、互いに依存しないタスクが3つ以上あるケースです。

例えば、3つのAPIファイルに同じパターンのエラーハンドリングを追加する作業。

各ファイルの修正は独立しているので、並列に処理できます。

Use parallel subagents to update the error handling in these files:
- src/api/users.ts
- src/api/orders.ts
- src/api/products.ts

Each should follow the pattern established in src/api/auth.ts.
Work on all three simultaneously.

複数のサブエージェントが同時に動くので、順番に処理するよりも明らかに速く完了します。

特に「やることは同じ、ファイルが違うだけ」というパターンは、並列実行の恩恵を最も受けやすいです。

文脈バイアスのない客観的レビュー

3つ目は、ちょっと意外かもしれませんが「バイアスのないレビュー」です。

メインの会話でコードを書いた後に「レビューして」とお願いすると、Claude Codeは自分が書いたコードに対して甘くなる傾向があります。

これはClaude Codeに限らず、人間でも同じですよね。

自分で書いたものは正しく見えがちです。

サブエージェントを使うと、メインの会話で積み重ねた文脈を一切持たない状態でレビューを実行できます。

Use a fresh subagent with read-only access to review my implementation.
It should not see our previous discussion. I want an unbiased review.

Check for: security vulnerabilities, unhandled edge cases, and error
handling gaps. Be critical.

Anthropicの公式ブログでは、/clearコマンドとの違いも指摘しています。

/clearはメインの会話をリセットしてしまいますが、サブエージェントなら会話を保持したまま独立したレビューを得られます。

これは実務上かなり大きなメリットです。

「会話は続けながら、レビューだけフラットな目で見てもらう」——これ、人間チームだとなかなか難しいですよね。

コミット前の独立検証

4つ目はコミット前の検証です。

レビューに近いですが、こちらはより実行寄りの作業です。

実装したコードをコミットする前に、サブエージェントに「テストが通るか」「型エラーがないか」「セキュリティ上の問題がないか」を独立して検証させる。

メインの会話は次のタスクに進めつつ、バックグラウンドで検証を走らせるイメージです。

サブエージェントのコンテキストには実装の経緯が入っていないので、「この変更は意図したものだから問題ない」という判断バイアスがかかりにくいのがポイントです。

見落とされがちなエッジケースの検出に特に効果を発揮します。

設計→実装→テストのパイプラインワークフロー

5つ目は、段階的に処理を進めるパイプラインワークフローです。

Let's build this feature as a pipeline:

1. First subagent: Design the API contract and write it to
   docs/api-spec.md
2. Second subagent: Implement the backend endpoints based on that spec
3. Third subagent: Write integration tests for the implementation

Each stage should complete before the next begins.

これは並列実行ではなく、各段階を独立したサブエージェントに任せる直列パターンです。

設計と実装とテストを同じコンテキストで行うと、後半の作業が前半のノイズに影響されます。

パイプライン化することで、各段階が専門的かつクリーンな状態で処理されます。

設計フェーズの試行錯誤がコンテキストに残ったまま実装に入ると、捨てたはずのアイデアに引きずられることがあります。

パイプラインワークフローはこの問題を綺麗に解決してくれます。

使うべき場面が掴めたところで、次は「使ってはいけない場面」です。

ここも公式が明確に書いてくれているので、これを知っているだけで無駄な試行錯誤を省けます。

Anthropicが「使わないほうがいい」と明示したケース

「使うべき場面」と同じくらい重要なのが「使わないほうがいい場面」です。

Anthropicの公式ブログはここも明確に書いてくれています。

前のステップの完全な出力が必要な順次作業

ステップ2がステップ1の完全な出力を必要とする場合、サブエージェントに分割するメリットはありません。

例えば「まずDBスキーマを設計して、その結果をもとにモデルを実装して」というタスク。

前のステップの詳細な結果が次のステップに不可欠なので、同一コンテキスト内で処理したほうが効率的です。

パイプラインワークフローとの違いが微妙に思えるかもしれませんが、パイプラインは「各段階の成果物（ファイル）を中間出力として保存できる」ケースに適しています。

一方、前の作業の文脈を丸ごと引き継ぐ必要がある作業は、分割しないほうがいいですね。

同一ファイルへの並列編集（コンフリクトリスク）

これは直感的に分かると思いますが、同じファイルを複数のサブエージェントが同時に編集するとコンフリクトが発生します。

Gitのマージコンフリクトと同じ問題です。

サブエージェントAが10行目を修正している間に、サブエージェントBも10行目を別の内容に修正してしまう。

異なるファイルへの並列編集は問題ありませんが、同一ファイルは避けるべきです。

小さなタスク（オーバーヘッドがメリットを超える）

サブエージェントの起動にはオーバーヘッドがあります。

新しいコンテキストウィンドウの初期化、タスクの受け渡し、結果の返却。

これらのコストは、タスクが小さいほど相対的に大きくなります。

「この変数名を直して」「このimport文を追加して」レベルの作業にサブエージェントを使う意味はないですね。

通常の会話で直接やるほうが速いです。

また、Anthropicは「すべてに特化したサブエージェントを作りすぎること」も注意点として挙げています。

過度な専門エージェント設計は管理コストが増えるだけで、実益が薄くなります。

サブエージェント間の相互通信が必要な場合

サブエージェント同士は互いのコンテキストを共有しません。

これは設計上の意図的な制限です。

もしサブエージェントAの結果をサブエージェントBが参照する必要がある、といった相互調整が必要なケースでは、サブエージェントは適していません。

Anthropicはこのケースに対して「Agent Teamsを検討せよ」としています。

Agent Teamsはセッションをまたいでエージェントが協調できる仕組みで、エージェント間で直接調整が可能です。

サブエージェントよりコストは高いですが、相互調整が必要なワークフローに適しています。

「使う場面・使わない場面」が整理できたところで、次は「実際にどう導入するか」です。

いきなり難しいことは不要で、今日から試せる入り口があります。

4段階の導入ステップ──会話型から自動化へ

サブエージェントの導入は段階的に進めるのがAnthropicの推奨です。

いきなりカスタムエージェントを作り込む必要はありません。

まず会話型で指示してみる

最初のステップは、普段のClaude Codeの会話の中でサブエージェントを自然言語で呼び出すことです。

「Use a subagent to...」と書くだけでいい。それだけです。

効果的な指示のコツは3つあります。

1. スコープを明確にする

# 良い例
"Use a subagent to explore how payments work in this codebase"

# 悪い例
"Use a subagent to explore everything"

2. 並列実行を明示的にリクエストする

"Use subagents to explore this codebase in parallel:
1. Find all API endpoints and summarize their purposes
2. Identify the database schema and relationships
3. Map out the authentication flow"

3. 戻り値の形式を指定する

"Return a summary of each, not the full file contents."

便利なショートカットも押さえておきましょう。

Ctrl+Bでサブエージェントをバックグラウンドに送り、/tasksで実行中のタスクを確認できます。

.claude/agents/ にカスタムサブエージェントを定義する

会話型で繰り返し同じパターンを使うようになったら、カスタムサブエージェントとして定義するステップに進みます。

.claude/agents/（プロジェクトルート）または~/.claude/agents/（ユーザーグローバル）にMarkdownファイルを作成します。

---
name: security-reviewer
description: Reviews code changes for security vulnerabilities,
  injection risks, auth issues, and sensitive data exposure.
  Use proactively before commits touching auth, payments, or user data.
tools: Read, Grep, Glob
model: sonnet
---

You are a security-focused code reviewer. Analyze the provided
changes for:
- SQL injection, XSS, and command injection risks
- Authentication and authorization gaps
- Sensitive data in logs, errors, or responses
- Insecure dependencies or configurations

Return a prioritized list of findings with file:line references
and a recommended fix for each.

ここで重要なのがdescriptionフィールドです。

Claude Codeはこの説明文を読んで、「この場面でこのサブエージェントを使うべきか」を自動判断します。

つまり、descriptionの書き方がサブエージェントの自動委譲の精度を左右します。

toolsフィールドで使えるツールを制限できるのも実用的です。

セキュリティレビュー用ならRead, Grep, Glob（読み取り専用）に絞ることで、レビュー中に意図しないファイル変更が起きるリスクを排除できます。

CLAUDE.md で呼び出しルールを明文化する

カスタムサブエージェントを作ったら、CLAUDE.mdにプロジェクト全体のルールとして呼び出し条件を書くのが次のステップです。

## Code review standards

When asked to review code, ALWAYS use a subagent with READ-ONLY access
(Glob, Grep, Read only). The review should ALWAYS check for:
- Security vulnerabilities
- Performance issues
- Adherence to project patterns in /docs/architecture.md

Return findings as a prioritized list with file:line references.

CLAUDE.mdに書いておくと、すべてのセッションで一貫した動作が保証されます。

チーム開発では特に有効で、メンバー全員が同じルールでサブエージェントを使えるようになります。

CLAUDE.mdに「リサーチ・調査・並列分析はサブエージェントに任せる」というルールを入れておくと、大きなタスクを投げたときにClaude Codeが自動的にサブエージェントを起動してくれます。

Skills / Hooks で自動化レベルを上げる

最後のステップは、SkillsとHooksによる自動化です。

Skillsは.claude/skills/に定義する複合ワークフローです。

例えば「コミット前の包括的レビュー」をSkillとして定義しておくと、/deep-reviewのようなスラッシュコマンドで呼び出せます。

# .claude/skills/deep-review/SKILL.md

---
name: deep-review
description: Comprehensive code review that checks security,
  performance, and style in parallel. Use when reviewing staged
  changes before a commit or PR.
---

Run three parallel subagent reviews on the staged changes:

1. Security review - check for vulnerabilities, injection risks,
   authentication issues, and sensitive data exposure
2. Performance review - check for N+1 queries, unnecessary iterations,
   memory leaks, and blocking operations
3. Style review - check for consistency with project patterns
   documented in /docs/style-guide.md

Synthesize findings into a single summary with priority-ranked issues.

Hooksはライフサイクルイベントに紐付く自動実行です。

例えば「Claude Codeが作業を終了しようとしたとき、テストが通っていなければブロックする」というフックが作れます。

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/check-tests.sh"
          }
        ]
      }
    ]
  }
}

Hooksまで使いこなせると、サブエージェントの委譲が完全に自動化されます。

ただし、いきなりここまでやる必要はありません。

会話型で十分にパターンを把握してから段階的に進めるのが、Anthropicの推奨するアプローチです。

導入ステップが分かったところで、次は具体的な使い方のパターンです。

「どんな場面でどう使えば効く」を5つ紹介します。

実践パターン5選

ここからは、サブエージェントの具体的な活用パターンを5つ紹介します。

実装前の並列リサーチ

新機能を実装する前に、コードベースの調査をサブエージェントに並列で委譲するパターンです。

例えば通知機能を追加する場合、以下の3つの調査を同時に走らせます。

• メール送信の既存実装を調べるサブエージェント
• 通知パターンの既存実装を調べるサブエージェント
• 新しい通知ロジックの配置場所を調べるサブエージェント

これらは互いに依存しないので、並列実行が可能です。

3つの調査結果がメインに返ってきたら、それを踏まえて実装計画を立てます。

プロンプトはシンプルで十分です。「Use parallel subagents to research: (1)... (2)... (3)... Summarize each.」とスコープを列挙するだけで、Claude Codeが自動的に複数のサブエージェントを起動してくれます。

RailsプロジェクトでバックグラウンドJobを追加するような場面でこれを使うと、既存のJob設計、Sidekiqの設定、関連するモデルのコールバックを並列で調査でき、事前調査の時間が明確に短縮されます。

PR並列コードレビュー

コードレビューを複数の観点で並列実行するパターンです。

品質・セキュリティ・パフォーマンスをそれぞれ独立したサブエージェントに担当させることで、各観点の深さが増します。

「セキュリティ担当」「パフォーマンス担当」「スタイル担当」のように役割を分けてプロンプトに明示すると、各サブエージェントが特定の観点に集中するため、網羅性が上がります。

1つのコンテキストで全部やろうとすると、どうしても浅くなりがちです。

このパターンは先ほど紹介した.claude/skills/deep-review/のSkillとして定義しておくと、日常的に使いやすくなります。

コンテキスト枯渇対策としてのサブエージェント分離

長時間のセッションでコンテキストが圧迫されてきたとき、重い処理をサブエージェントに逃がすパターンです。

メインのコンテキストには「今やっている作業の文脈」だけを残し、調査や検証はサブエージェントに委譲する。

サブエージェントは新しいコンテキストで動くので、メインの枯渇の影響を受けません。

Claude Codeの応答が明らかに遅くなったり、指示の理解精度が落ちてきたと感じたら、サブエージェントに仕事を分散することを検討してみてください。

「対症療法」として、これはかなり即効性があります。

読み取り専用サブエージェントでの安全な調査

サブエージェントのtoolsをRead, Grep, Globに限定することで、完全に読み取り専用のエージェントを作れます。

「調査はしてほしいが、ファイルは絶対に変更してほしくない」という場面で重宝します。

特に本番環境に近い設定ファイルを調査するときや、他チームのコードベースを確認するときに安心感があります。

ビルトインのExploreタイプも読み取り専用で動作するので、手軽に使いたい場合はそちらでも十分です。

バックグラウンドでのテスト実行

Ctrl+Bでサブエージェントをバックグラウンドに送り、メインの作業と並行してテストを走らせるパターンです。

実装を進めながら、バックグラウンドでは先ほど書いたコードのテストが実行されている。

テストが完了したら/tasksで結果を確認します。

地味ですが、実務では使用頻度が一番高いパターンかもしれません。

テスト実行を待っている時間は、積み重なるとかなりのロスになります。

次は、よくある誤解を整理しておきます。

特にトークンコストとコンテキスト共有については、思い込みで動いて「あれ？」となるケースがあるので確認しておきましょう。

よくある誤解と注意点

サブエージェントについて、よくある誤解を整理しておきます。

「並列実行=非同期実行」ではない

サブエージェントは並列実行が可能ですが、これは「非同期実行」とは異なります。

並列実行では複数のサブエージェントが同時に動きますが、メインのClaude Codeはそれらの完了を待ちます（バックグラウンド送信した場合を除く）。

完全にfire-and-forgetで走らせたいならCtrl+Bでバックグラウンドに送る必要があります。

この違いを理解しておかないと「並列にしたのに速くならない」と感じるケースがあるかもしれません。

トークン消費の増加に注意

サブエージェントは独自のコンテキストウィンドウを持つので、当然ながらトークン消費は増えます。

各サブエージェントがそれぞれコンテキストを初期化し、プロジェクトの情報を読み込み、処理を実行する。

この重複分がコストに跳ね返ります。

これはトレードオフです。

コンテキストの品質と処理速度の向上を、トークンコストの増加で買っている。

小さなタスクにサブエージェントを使うとコスト効率が悪くなるのは、このためです。

サブエージェント同士はコンテキストを共有しない

繰り返しになりますが、これは非常に重要な点です。

サブエージェントAが発見した情報を、サブエージェントBは参照できません。

各サブエージェントはメインのClaude Codeに結果を返すだけで、サブエージェント間の横の通信は存在しません。

これは制限であると同時に利点でもあります。

コンテキストが汚染されないからこそ、独立した客観的なレビューが可能になります。

エージェント間の相互通信が必要な複雑なワークフローには、Agent Teamsが適しています。

まとめ──「いつ使うか」の判断フロー

最後に、サブエージェントを「使うか使わないか」の判断フローをまとめます。

サブエージェントを使う：

• 10個以上のファイルを探索する必要がある
• 3つ以上の独立したタスクがある
• バイアスのない客観的なレビューが欲しい
• コミット前に独立した検証をしたい
• 設計→実装→テストのパイプラインを組みたい
• コンテキストが枯渇してきた

サブエージェントを使わない：

• 前のステップの完全な出力が次のステップに必要
• 同一ファイルを複数箇所同時に編集する
• 変数名の修正など小さなタスク
• サブエージェント間の相互通信が必要

導入は段階的に進めるのがおすすめです。

まずは会話型で「Use a subagent to...」と指示するところから始めて、繰り返し使うパターンが見えてきたら.claude/agents/にカスタムサブエージェントを定義する。

さらに成熟したらCLAUDE.mdやSkills、Hooksで自動化する。

Anthropicの公式ブログの結びの言葉が印象的だったので、ここで紹介しておきます。

The goal is to make subagent delegation effortless, so your attention stays on the work that matters.

サブエージェントの委譲を「意識しなくていいもの」にすること。

そうすることで、本当に重要な仕事に集中できる。

Claude Codeの真価は「コードを書くこと」ではなく「開発のオーケストレーション」にあると自分は思っています。

サブエージェントは、そのオーケストレーションを一段上のレベルに引き上げてくれる機能です。

まずは今日の普段のClaude Codeセッションで「Use a subagent to...」と1回試してみてください。

難しいセットアップは不要で、その一言で始まります。

「あ、こういうことか」と体感できるはずです。