Claude Code subagents — Task ツールによる役割分担
Explorer/Plan/Reviewerのsubagentsを起動して親のコンテキストを保護し、並列処理でスループットを向上させる。
ほとんどのユーザーが最後に活用する Claude Code の強みが Subagents(Task ツール)だ。1つのセッションで全てを処理すると親のコンテキストがすぐに埋まり、大きなタスクは1スレッドのボトルネックになる。Subagents を抽象化レイヤーとして扱い — Explorer が検索・要約し、Reviewer は差分だけを見る — 同じ時間で2倍の作業をこなせる。
Subagents の本質はツール数ではなく、コンテキスト保護にあると考える。以前は一つのセッションで全てを抱えることが「丁寧な仕事」だと思っていた。いまでは親が判断に集中できるからこそ品質が上がるためだと理解しているので、適切な委任設計が重要になる。
このガイドは Claude Code 1.x を対象とし、Claude Code セットアップと Hooks の上に、日常ワークフローをひとつ高いレベルに引き上げる。
TL;DR
- 親(Parent) は直接編集 + ビルド/テスト — 短く、素早い作業
- Explorer subagent — 「このコードベースのXはどこにある?」検索/要約。大きな結果を親に引き込まない
- Plan subagent — 大きな変更のためのステップバイステップ計画だけを返す
- Reviewer subagent — 親の差分のセカンドオピニオンレビュー
- Specialist — claude-api / security-reviewのようなドメイン固有のsubagents
コア原則 — コンテキスト保護 + 並列処理。
前提条件
- Claude Code 1.x インストール済み — Claude Code セットアップ
- プロジェクト基盤:
CLAUDE.md+.claude/settings.json - (オプション)Hooks ベースライン — 一部の親 Hooks は Subagents にも適用される
1. Task ツールの呼び出しモデル
Claude Code 内で、Task ツールは1つのプロンプトで新しいエージェントを起動する。Subagent は独自のコンテキストウィンドウを持ち — 親とメッセージを共有せず、最終結果メッセージだけが返ります。
親エージェント
│
├─ Task("Explore", "src/auth/のトークン検証ロジックを見つけて; 関数名 + ファイルパスだけ返して")
│ ↓ (別コンテキスト、最大100kトークン空き)
│ ↑ "validateToken: src/auth/verify.ts:42" ← 親は結果のみ受け取る
│
└─ Task("Reviewer", "最後のコミットの差分をセキュリティ視点でスキャンして")
↓
↑ "1件の発見: src/api/user.ts:88 — 潜在的なSQLインジェクション"
親のコンテキストには 最終サマリー1つ だけが追加される。Subagent が200ファイルを読んでも、親は1行を受け取る。
2. 4つのコアパターン
2.1 Explorer — 大きな検索結果を分離する
最も一般的。「Xはどこで定義されているか?」という質問をsubagentに委任。
"Explorerサブエージェントに委任:
'src/でuseAuthフックの定義と全ての使用箇所を見つけて。返す内容:
- def: ファイル:行
- usages: ファイル:行 × 全て
30行のサマリーに制限。コード本体は含めない。'"
親が受け取るのは30行。直接実行すると、grep + 複数ファイル読み取りで5〜20kトークンを消費していたはずだ。
使いどき:
- 新しいコードベースに入ったばかり
- 「この機能はどこにある?」
- 「このライブラリをどう使っているか?」
- 依存関係の影響分析
悪い使い方:
- 小さな検索 — 親が1行でgrepできる
- 全文を読む必要がある結果 — 親が直接読む方が速い
2.2 Plan — 大きな変更の計画だけ
5ファイル以上の変更 / 新モジュール / アーキテクチャ変更 — Plan Subagent が調査 + トレードオフ分析を行い、計画だけを返す。
"Planサブエージェントに委任:
'ステップバイステップの実行計画だけを返して。
要件: カテゴリごとに約7から10にシードを拡張。
制約: ビルド1分以内、verify:assets 100%。
出力: カテゴリ・トピック・アセットあり・推定行数の表 + 記述順序。
コードは書かない。'"
親が計画を受け取り、実行は親または他の Subagents に分散される。
2.3 Reviewer — セカンドオピニオン
別のコンテキストを持つエージェントが親の差分をレビュー。フレッシュな視点が親の見落としを捉える。
"Reviewerサブエージェントに委任:
'コミット4d2f0の差分をセキュリティ視点でレビューして。
具体的に: SQLインジェクション、XSS、ハードコードされたシークレット、競合状態。
出力: N件の発見 + ファイル:行 + 1行メモ。または「クリーン」。'"
親は自分のコードをよく知っているため問題を見逃しがちだ。Reviewer は同じ差分を別の視点から見る。
2.4 Specialist — ドメイン固有
特定領域(claude-api、security-review、code-reviewer、build-validator など)の Subagents で、豊富なドメイン知識と領域に適した出力形式を持つ。
"security-reviewに委任:
'現在のブランチの変更の包括的なセキュリティ評価。
スコープ: 認証 / 認可 / 入力バリデーション / シークレット / セッション / CSRF。'"
Specialist は通常、その領域に合わせてチューニングされた system prompt を持ち、結果の品質が高くなる。
3. 委任プロンプトの書き方
Subagent は親のコンテキストを見ません。プロンプトは自己完結型でなければなりません。
良いプロンプト
"src/で以下のパターンを見つけて:
- baseURLがハードコードされている `fetch(...)` の呼び出し
- 結果: ファイル:行 + 1行のコード + 推測されるbaseURLドメイン
- 30件に制限; それ以上の場合は '+N件以上' を追記
- コード本体は含めない — 行のみ"
悪いプロンプト
"さっきのfetchの件をレビューして" ← コンテキストなし、曖昧
"全てのfetch呼び出しを見つけて" ← 出力形式なし、巨大な出力のリスク
作成チェックリスト
- ゴール — 何を知りたいか
- スコープ — どこを(ディレクトリ/ファイル/範囲)
- 出力形式 — 表 / 行レベル / サマリーの長さ
- 除外事項 — 返してはいけないもの(コード本体、大きな差分)
- 停止条件 — N件の発見で停止
- 不明な場合 — 「わからない場合は、そう言う; 推測しない」
4. 並列実行 — 独立した委任を同時に送る
独立した作業は、複数の Task 呼び出しを1つのレスポンスにまとめることができる。Claude Code が並列に起動する。
"同時に3つ委任:
1) Explorer — 認証ファイルがどこにあるかをまとめて
2) Explorer — DBマイグレーション履歴をまとめて
3) Reviewer — 最後の5コミットのセキュリティレビュー
3つ全て受け取ったら、統合分析を行って。"
親は3つを同時に受け取る。時間が1/3になる。
並列化しないこと:
- Aの出力がBの入力になる — 順次実行
- 同じファイルを2つのタスクが編集する — 競合リスク
5. コンテキスト管理 — 委任 vs 直接
| シグナル | 委任 | 直接 |
|---|---|---|
| 結果を1〜2行に絞れる | ✅ | — |
| コード本体を親に取り込む必要がある | — | ✅ |
| 100ファイル以上の検索 | ✅ | — |
| 1〜2つのgrep | — | ✅ |
| 結果を直後に使う | — | ✅(委任+受取 > 直接) |
| 異なる視点が必要 | ✅(Reviewer) | — |
| ドメイン固有の知識 | ✅(Specialist) | — |
目安: タスクが親のコンテキストの20%を消費しそうなら委任を検討してください。
6. 実際のシナリオ
A. 新しいコードベースに入る
1. Explorer — フォルダ構造 + 主要5モジュールのサマリー
2. Explorer — README + CLAUDE.md(あれば)のキーポイント
3. Explorer — 最後の10コミットのサマリー
↓
4. 親 — 「このリポジトリについての1段落」に統合
B. 5ファイル以上の変更
1. Plan — 変更スコープ + ステップ + リスク表
2. 親 — 計画をレビューし、ステップバイステップで進める
3. 各ステップ後、Reviewer — 差分レビュー
4. 最終コミット前、Reviewer — 全変更のセカンドオピニオン
C. デバッグ
1. 親 — エラーログ + 再現パスを定義
2. Explorer — 関連するコードパスをトレース(スタックトレースから)
3. 親 — 仮説を立てて修正を試みる
4. 親 — ビルド/テストで検証
D. PRマージ直前
1. Reviewer — 差分のセキュリティ/パフォーマンスレビュー
2. Reviewer — 既存コードとの規約一貫性
3. Specialist(security-review) — 包括的な評価
4. 親 — 発見をPRコメントまたは修正にまとめる
7. Hooksとの組み合わせ
Claude Code Hooks の PreToolUse は Task 呼び出しも傍受できる。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Task",
"hooks": [
{
"type": "command",
"command": "/bin/bash -lc 'echo \"[delegate] $(jq -r .tool_input.description)\" >> ~/.claude/delegate.log'"
}
]
}
]
}
}委任回数と内容をログに残すことで、何を委任し何を直接行ったかをレビューできる。コスト追跡とパターン改善に役立ちる。
8. アンチパターン — 委任の誤用
8.1 全てを委任する
"1ファイルの編集でも委任" ← オーバーヘッドが増えるだけ
Subagent 呼び出しにはトークン/時間のコストがある。1秒の作業を30秒の委任に変えるのは無駄だ。
8.2 委任後に親が同じ検索をする
"Explorerが認証ファイルの場所をまとめた → 親が同じファイルをgrepする"
→ 委任が無意味になる。結果を信頼して次のステップに進みましょう。
8.3 出力量が多すぎる
"各ファイルの全コード + 5行の説明 + 使用本体を持ってきて"
→ これでは委任が親のコンテキストを節約しません。プロンプトで出力サイズを制限してください。
8.4 依存関係のある並列委任
"Aの結果がBに必要だが、両方を同時に委任"
→ BはAの結果を知らない。誤った前提で動いてしまう。順次実行が正解だ。
9. 分担マトリクス — 誰が何をするか
| タスク | 親(Main) | Explorer | Plan | Reviewer | Specialist |
|---|---|---|---|---|---|
| 小さなgrep | ✅ | — | — | — | — |
| コード変更 | ✅ | — | — | — | — |
| ビルド/テスト | ✅ | — | — | — | — |
| 大きな検索 | — | ✅ | — | — | — |
| 大きな変更計画 | — | — | ✅ | — | — |
| 差分レビュー | (小さいもののみ) | — | — | ✅ | ✅(セキュリティ) |
| 包括的なセキュリティ | — | — | — | — | ✅(security-review) |
| ドメインAPI使用 | — | — | — | — | ✅(claude-apiなど) |
次のステップ
- Claude Code セットアップ — 親エージェントの基盤
- Claude Code Hooks — 委任のログ/検証
- マルチエージェントワークフロー — マルチツール/エージェント統合シナリオ
- エージェントランナー — 自律実行 + Subagents の組み合わせ
参考リンク
変更履歴
- 2026-05-12 — 初版(devAlice M3 シード展開)