サブAgent：分けるべき時、分けないべき時

Claude Code には Agent ツールがあり、会話の途中で独立したサブ Agent を起動してタスクを任せることができる。サブ Agent は自分専用のコンテキストを持ち、作業が終わったら結果をメイン Agent に返す。

一見すると強力だが、実際に使ってみると、ほとんどの場面では必要ない。この記事では、サブ Agent を分けることが本当に効くケースと、ただの無駄になるケースを整理する。

サブ Agent の仕組み

CLAUDE.md やスラッシュコマンドから Agent ツールを直接呼び出すことはできない。これは Claude Code が内部的に使用するかどうかを判断するツールだ。ただし、プロンプトの書き方でその判断に影響を与えることはできる。

動作の流れ：

1. メイン Agent がサブ Agent を起動し、プロンプトを渡す
2. サブ Agent は独立したコンテキストで実行される。ファイル読み込み、検索、コマンド実行など、ほとんどのツールが使える
3. サブ Agent が完了すると、結果を1つのメッセージとしてメイン Agent に返す
4. メイン Agent はその結果を受け取って作業を続ける

重要な特性：

• 独立したコンテキスト：サブ Agent はメインの会話履歴を見ることができず、起動時に渡されたプロンプトだけが頼り
• 結果の圧縮：サブ Agent が内部で何十ファイル読もうが何コマンド実行しようが、メイン Agent に返るのは要約のみ
• 並列実行：複数のサブ Agent を同時に起動して並列に動かせる

サブ Agent を使うべき3つの場面

1. 並列的な調査・リサーチ

最も典型的なユースケース。Claude Code に何かを調べてもらいたいが、同時に複数の方向を探る必要がある場面だ。

たとえば「このプロジェクトの認証機構はどうなっている？」と聞いたとする。

サブ Agent なしだと、Claude Code は順番に処理する：auth controller を読む → middleware を読む → routes を読む → model を読む → 設定を読む……。一つずつ、遅い。

サブ Agent を使うと：

3つのサブ Agent を同時起動：
- Agent 1：controller と middleware 層の認証ロジックを調査
- Agent 2：model 層のユーザーとセッション設計を調査
- Agent 3：設定ファイルと環境変数の認証関連設定を調査

3方向を同時に調査し、結果を統合。CLAUDE.md でこう誘導できる：

## 調査系タスク
複数モジュールにまたがる問題を調査する際は、
複数のサブ Agent を並列に起動して分担調査し、
最後に結論をまとめること。

2. メインコンテキストの保護

Claude Code のコンテキストウィンドウには限りがある。あるサブタスクが大量のファイルを読む必要があるが、最終的に必要なのは結論だけ、という場合、サブ Agent を使えば「過程のゴミ」をメインコンテキストの外に追い出せる。

よくある例：

• 50個のファイルから特定 API の呼び出し箇所をすべて探し出し、パターンを分析する
• 大きな設定ファイルを解析して、必要なのは数個のキー値だけ
• テストファイル群をレビューして、カバレッジが十分かどうか判断する

これらのタスクの共通点は入力が大きく、出力が小さいこと。サブ Agent が内部で大量の情報を消化し、エッセンスだけを返す。

3. リスクのある操作の隔離

うまくいくか分からないタスクもある。サブ Agent に isolation: "worktree" パラメータを付けて使えば、独立した git worktree 内で作業が行われる。壊れても、今の作業ディレクトリには影響しない。

## 高リスクなリファクタリング
大規模なリファクタリングには worktree 隔離付きのサブ Agent を使う。
結果が正しいことを確認してからマージすること。

向いている場面：

• 試験的なリファクタリング：あるアプローチが有効かどうか、まずサブ Agent に試させる
• 方式の並列比較：2つのやり方を同時に実装して結果を比べる
• コード生成：大量のボイラープレートを生成し、レビューしてから取り込む

サブ Agent を使うべきでない場面

単純で直接的なタスク

「この関数名を camelCase から snake_case に変えて」—— こういうのは直接やればいい。サブ Agent の起動コスト（コンテキスト構築、返却待ち、結果のパース）のほうが、直接やるより遅くなる。

判断基準：Grep 1回 + Edit 1回で済むなら、Agent に分けるな。

強い依存関係がある順序タスク

「設定を読む → 設定に基づいてコードを修正 → 修正に基づいてテストを更新」

こうした連鎖的な依存があるタスクは、各ステップが前のステップの結果に依存する。サブ Agent に分けると、中間結果をプロンプト経由で受け渡す必要があり、面倒なうえに情報が落ちやすい。素直に順番に実行すればいい。

精密な制御が必要な修正

サブ Agent が返すのは要約テキストであり、構造化データではない。サブ Agent に精密な修正をさせたい場合（たとえば47行目に特定のコードを挿入するなど）、メイン Agent に直接やらせるほうが確実だ。

サブ Agent は「調査して結論を返す」のに向いている。「正確に修正を実行する」には向いていない。

コンテキストにまだ余裕がある時

会話が始まったばかりでコンテキストウィンドウがガラ空きなら、「コンテキスト保護」のために Agent を分ける必要はない。会話が長くなり、メイン Agent が履歴メッセージの圧縮を始めた頃に、重い作業をサブ Agent に任せることを検討すればいい。

実際の効果比較

具体例で見てみよう：Rails プロジェクトで before_action を使っている全コントローラーを調査し、認証・認可の実装パターンを分析する。

サブ Agent なし：

Claude Code がコントローラーファイルを1つずつ読み込み、そのたびにメインコンテキストを消費する。コントローラーが20個あれば、ファイル内容だけで大量のトークンを食いつぶす可能性がある。最終的に分析結果を出す時には、前半に読んだ詳細がコンテキスト圧縮で失われているかもしれない。

サブ Agent あり：

サブ Agent を起動："app/controllers/ 配下の全コントローラーを読み、
すべての before_action コールバックを見つけ、
認証・認可のパターンを分析し、分類した要約を返せ。"

サブ Agent が自分のコンテキスト内ですべてのファイルを読み切り、整理された要約を返す。メイン Agent のコンテキストはほぼ消費されず、結論を受け取ってすぐ次に進める。

CLAUDE.md でサブ Agent の使い方を誘導する

Claude Code にサブ Agent を使わせる／使わせないことを強制はできないが、CLAUDE.md で好みを伝えることはできる：

## Agent 使用の方針

### サブ Agent 向きのタスク
- モジュール横断的な調査（3ディレクトリ以上を同時に探索）
- 大規模なコード検索・集計
- 探索的リファクタリング（worktree 隔離付き）

### サブ Agent を使わないタスク
- 単一ファイルの修正
- 順序依存のある複数ステップ操作
- 修正箇所が明確なバグ修正

ひと言で判断する方法

このタスクの「過程」は「結論」よりずっと大きいか？

はいなら —— サブ Agent を使う。過程を消化させて、結論だけ受け取る。
いいえなら —— 直接やる。中間層を挟まない。

サブ Agent は多ければいいというものではない。並行処理フレームワークではなく、コンテキスト管理ツールだ。正しく使えば、大規模プロジェクトでも Claude Code の判断力を維持できる。間違った使い方をすれば、起動時間を浪費するだけだ。