Claude Codeのサブエージェント完全活用 — Taskツールで作る並列開発パターン

要点

Claude Codeのサブエージェントは、メインの会話セッションとは独立したコンテキストで動く子エージェントです。Task ツール経由で起動し、調査・実装・レビューといった重い作業をメイン会話の文脈を汚さずに任せられます。

サブエージェントの実用価値は3点に集約できます。

• コンテキスト分離: 大量のファイル読みやグレップが必要な調査をサブエージェントに渡せば、メイン会話には要約だけが返り、context残量が温存される
• 並列化: 互いに独立した作業(複数領域の調査、独立した実装単位)を同時に走らせて時間を圧縮できる
• 役割の明確化: subagent_type で振る舞いを分け、汎用調査 / 探索専用 / 計画専用といった特化型を呼び分けられる

本記事は、サブエージェントの基本仕様を整理した上で、実際に使いどころのある6つのパターンと、避けるべき3つのアンチパターン、それから著者が実運用で使っている使い分け早見表を載せます。

サブエージェントとは何か

サブエージェントは、メインClaude Codeセッションが Task ツールを呼び出して起動する独立した子セッションです。子セッションは独自のシステムプロンプト・独自のコンテキストウィンドウ・独自のツール許可を持ち、与えられたタスクを最後まで実行して1通の結果メッセージをメインに返します。

メインから見ると、サブエージェントは「プロンプトを投げると数十秒〜数分後に要約が返ってくるブラックボックス」として振る舞います。中で何度もRead / Grepを繰り返していたとしても、メイン側にはそれらの中間ログは見えません。

Main agentとSubagentの主な違い

メイン会話を「指揮者」、サブエージェントを「専門楽器の奏者」と捉えると役割分担がイメージしやすいです。指揮者は曲全体の構成を把握し、奏者は局所的な演奏を完璧に仕上げる、という分業です。

Taskツールの動作モデル

Task ツールは以下の手順でサブエージェントを起動します。

1. メインが description(短い要約)・prompt(タスク本体)・subagent_type(任意、特化型)を指定
2. 子セッションが新規に作成され、専用のシステムプロンプトとツール許可で初期化される
3. 子セッションがプロンプトを実行(複数のツール呼び出しを内部で繰り返す)
4. 子セッションが完了メッセージをメインに返し、メイン側にはこの1通だけが見える

ここで重要なのは「メインに返るのは要約1通だけ」という事実です。子セッションが内部で100回Read / Grepを回しても、メインのコンテキストには一切残りません。これが「重い調査をサブエージェントに任せて、メインのcontextを温存する」運用の核です。

subagent_type による特化

subagent_type を指定すると、用途別に最適化された子エージェントが起動します。代表的なものは次の通りです。

• general-purpose: 既定の汎用型。多段ステップの調査やマルチファイル変更に向く
• Explore: 高速・読み取り専用の探索型。シンボル検索やファイル構造の俯瞰に向く
• Plan: 実装計画を立てるための設計型。step-by-stepのプランを返す

特化型は使えるツールが絞られていることが重要です。例えば Explore は書き込み系(Edit / Write)を持たないので、安全に並列で複数体走らせても書き込み衝突が起きません。

6つの実用パターン

ここからが本題です。サブエージェントが効くシーンを6パターンに分けて見ていきます。各パターンには「適用条件」「例」「注意点」を添えます。

パターン1: 並列Exploreで広域調査を一気に終わらせる

複数の独立した観点でコードベースを調べたいとき、Explore を並列に投げると人手で順次調べるより数倍速く全体像が掴めます。

適用条件: 観点同士が独立していて、調査結果が干渉しない

例: 「このプロジェクトの認証ロジックはどこか」「テストはどう構成されているか」「DBスキーマはどこで定義されているか」を3体並列で投げる

注意点: 並列体数は3〜5程度に留める。多すぎると返ってきた要約をメインで統合するコストが上がり、contextが混雑する

パターン2: コンテキスト隔離で重い調査をブラックボックス化

例えば「過去100 PRを全部読んでこの機能の変遷をまとめて」のようなタスクは、mainで直接やると100ファイル分のログがコンテキストに残ってcontext残量を圧迫します。サブエージェントに丸投げすれば、メインには要約1通だけ返ってくるので残量が温存されます。

適用条件: 結果は要約1通で十分、中間ログは不要

例: ファイル数百本のスキャン、git logの長期分析、外部APIへの複数fetch

注意点: サブエージェントは中間結果をメインに見せられないので、「途中経過を見ながら進路修正したい」タイプのタスクには不向き

パターン3: 独立タスクの真の並列実行

互いに依存しない実装単位を2〜3体のサブエージェント(general-purpose)で同時に進められます。例えば「フロントエンドのバナー UI追加」「バックエンドのAPIエンドポイント追加」「DBマイグレーション作成」を3体並列に投げる、といった具合です。

適用条件: タスク間にファイル衝突がない / 時間的依存がない

例: 異なるディレクトリ / 異なるサービスの実装、独立したテストの追加

注意点: 同じファイルを複数体が触ろうとすると後勝ちで上書きされる。事前に担当ファイルを明示してプロンプトに書く

パターン4: 計画と実装の分離(Plan + general-purpose)

複雑なリファクタや大規模な変更で、いきなり実装に入ると見落としが発生しがちです。先に Plan 型サブエージェントに設計プランを書かせ、人間(またはメイン)がそれをレビューしてから、general-purpose 型で実装に入る、という分離パターンが有効です。

適用条件: 影響範囲が広い変更、後戻り可能性を低くしたい変更

例: モジュール分割、ライブラリ移行、データモデル改修

注意点: 計画書をメインがレビューせずに自動で実装に渡すと、計画の穴がそのまま実装に流れる。プラン受領 → 確認 → 実装の3段を踏む

パターン5: レビュアー専用サブエージェント

実装が終わった後に、独立した目でdiffをレビューするサブエージェントを起動します。実装エージェント自身がセルフレビューするより、独立したコンテキストの目の方が見落としを拾いやすい性質があります。

適用条件: PR化前のセルフチェック、CIレビューを軽量に通す前段

例: コード品質12観点 + プロジェクト仕様9観点のレビュー、独自スタイルガイド準拠チェック

注意点: レビュアーに渡すプロンプトには判定基準を具体的に書く。「品質を確認」だけでは観点が散漫になる

パターン6: 検証 / 実機テストの隔離実行

「サンドボックスで実際にコマンドを叩いて動作確認したい」「複数の入力で挙動を試したい」といった検証は、結果ログがメインに残るとcontextを圧迫します。サブエージェントに「Nパターンで試して結果を要約して」と任せると、メインにはサマリだけが返ります。

適用条件: 検証ログが多量、最終的に必要なのは合否判定のみ

例: APIレスポンスのバリエーション確認、CLIフラグごとの挙動比較

注意点: サブエージェントの結果が「成功」と返ってきても、ログを見たいときはメインから再度 Bash で実行する必要がある

3つのアンチパターン

サブエージェントを使ってはいけないシーンも明確にあります。

アンチパターン1: 状態を引き継ぐ必要がある作業

サブエージェントは結果を1通返したら終了します。「途中まで書いたコードを引き継いで続きを書く」「会話履歴を見ながら段階的に進める」といった状態継続型の作業には向きません。Task を2回呼んでも、2回目の子セッションは1回目の中間状態を持っていません。

アンチパターン2: 軽すぎる単発作業

ファイル1つをReadして値を取り出す、Grepを1回だけ走らせる、といった軽量な単発作業にサブエージェントを使うと、起動オーバーヘッドの方が本タスクより重くなります。1〜2ツール呼び出しで済むタスクは、メインで直接やるべきです。

アンチパターン3: 細かい進路修正をしたい作業

サブエージェントは「投げたら戻ってくる」モデルです。投げる前に進路を全部決められない作業 — 例えば「これ書いてみて、見て、次どうするか決める」のような対話的探索 — には向きません。こういう作業はメインで対話しながら進める方が手戻りが少ないです。

著者の使い分け早見表

実運用で考えるべき判断軸は次の3つです。

1. 結果に必要なのは要約か、中間ログ込みか
2. タスクは並列化できるか(依存はあるか)
3. 進路修正のタイミングが必要か

これに沿って整理すると、次の早見表になります。

まとめ

サブエージェントは「コンテキストを汚さずに重い作業を任せる仕組み」と「並列化で時間を圧縮する仕組み」の二側面があります。どちらの恩恵を取りたいかで Task の使い方が変わります。

実用的な指針としては、まず Explore を並列で投げる広域調査から始めると効果を実感しやすく、慣れてきたら Plan + 実装の2段、並列実装の3段へと展開していく流れが無理がありません。アンチパターン(状態継続 / 軽量単発 / 対話的探索)を踏まないことだけを守れば、サブエージェントはClaude Codeの生産性を確実に底上げしてくれます。

関連:Claude Code Routines完全実践ガイドとAgent SDKでSlack botを作るを併読すると、並列実行の典型パターンが見えます。