Claude Codeのサブエージェントに調査を任せる判断：メイン会話を汚さない分担

公式が示す判断の軸

公式ドキュメントの「メイン会話とサブエージェントの選び方」は、次のように整理できます（要旨は筆者による言い換えです）。

• サブエージェント向き：冗長な出力が出て、メイン会話には要らない／ツールや権限を限定したい／単体で完結し、要約を返せる
• メイン会話向き：頻繁なやり取りや反復修正が要る／計画・実装・テストのように文脈を共有する／小さく狙いの定まった変更／レイテンシが重要

後半の基準は、公式ページの「サブエージェントとメイン会話のどちらを選ぶか」に基づく要旨です。

最後の点には理由があります。フォークではないサブエージェントはまっさらな状態で始まり、文脈を集め直す時間がかかることがあるためです。また、サブエージェントはメイン会話の履歴を見ません。受け取るのはClaudeが書いた依頼文が中心です（プロジェクトのCLAUDE.mdなどは読み込まれる仕様です）。つまり依頼文に書いていない前提は、相手に伝わっていないと考えるのが安全です。なお、ExploreとPlanはCLAUDE.mdを読み込まずに始まります。

任せる／任せないの判断表

• 数千行のログからエラーの原因候補を探す、判断：任せる、理由：生ログはメイン会話に不要で、要約だけ欲しい
• 認証・DB・APIなど独立した3領域を調べる、判断：任せる（並列）、理由：調査経路が互いに依存しないときに向く
• 不慣れなリポジトリで、ある機能の実装箇所を探す、判断：任せる、理由：読み取り専用の探索は組み込みのExploreが担う領域
• ライブラリのドキュメントを読んで該当箇所だけ知りたい、判断：任せる、理由：取得した長文を会話に残さずに済む
• 調べながら「こっちの方針で」と指示を変えたい、判断：任せない、理由：往復が必要で、途中で口を挟みにくい
• 調査結果をそのまま実装に使う（同じ文脈で続ける）、判断：任せない、理由：計画と実装が文脈を共有する
• 1〜2ファイルを見れば済む確認、判断：任せない、理由：起動と文脈の集め直しのほうが重い
• 設計の最終判断、仕様の採否、判断：任せない、理由：調査は任せても、決めるのは人

迷ったら「出力は大きいか」「後で原文を見返すか」の2点で決めます。出力が大きく、見返さないなら任せる候補です。

調査依頼文の型

サブエージェントは会話を見ていないため、依頼文には目的・範囲・除外・返し方を入れます。以下は説明用の型です。

【目的】
決済APIのタイムアウト設定がどこで決まっているかを知りたい。
（背景：本番で30秒を超えるリクエストが切断される。原因の仮説づくりに使う）

【調べる範囲】
- src/payment/ と config/ 配下
- 除外：node_modules、dist、テストのfixture

【やらないこと】
- ファイルの編集・コマンドによる変更は行わない（読み取りのみ）
- 推測で埋めない。見つからなければ「見つからなかった」と書く

【返す形式】（合計400字程度）
1. 結論：設定値と定義場所を、ファイルパス:行番号で3件まで
2. 根拠：該当箇所の短い抜粋（各5行以内）
3. 未確認：調べきれていない点と、その理由

ポイントは「やらないこと」と「未確認」の欄です。調査系の依頼は、見つからないときに推測で埋められるのが最大のリスクです。「見つからなかったと書く」を明示し、返答の長さも指定すると、メイン会話に戻る量も抑えられます。

毎回使うなら、読み取り専用の担当を定義する

同じ型の調査を繰り返すなら、.claude/agents/ にカスタムサブエージェントを置く方法があります。公式のフィールド（name、description、tools、model）に沿った説明用の例です。

---
name: code-researcher
description: コードベースやログを読み取り専用で調べ、根拠付きの要約を返す。出力が大きい調査で使う。
tools: Read, Grep, Glob
model: haiku
---

あなたは調査担当です。ファイルは編集しません。
結論、根拠（パス:行番号）、未確認事項の順に簡潔に報告してください。
推測は推測と明記し、見つからないものは見つからなかったと書いてください。

tools で読み取り系だけを許可すれば、調査中に書き換えが起きない構成にできます。model に軽量モデルを指定する方法は、公式ドキュメントでも費用を抑える選択肢として挙げられています。重要な調査では、結果の検証も行ってください。

返ってきた要約を人が確認するところ

サブエージェントの報告はメイン会話にとって「二次情報」です。次の3点は人が見ます。

1. 根拠のパスと行番号が実在するか：報告された場所を自分で開いて、抜粋と一致するか確認します。重要な結論ほどこの確認を省かないでください。
2. 「未確認」欄の扱い：空欄なら調べ尽くしたのではなく、書き忘れの可能性もあります。範囲外の領域がないか自分で考えます。
3. 次の作業に必要な事実だけをメイン会話に持ち込む：要約を鵜呑みに実装へ進まず、必要な根拠だけを指示に引用して続けます。

使いすぎないための注意

サブエージェントはメイン会話を軽くしますが、タダではありません。公式ドキュメントは、詳細な結果を返す多数のサブエージェントを動かすと、結果が戻る分のコンテキストを消費し、各サブエージェントも自分でトークンを使うと注意しています。費用管理のページでも、サブエージェント自身のリクエストは利用量に計上されると書かれています。

実務では次の運用が無難です。

• 並列に出すのは、互いに依存しない調査だけにする
• 依頼文で返答の長さを指定する（上の型の「400字程度」のような指定）
• 利用量が気になるときは /usage で確認する。サブスクリプションのプランでは、スキルやサブエージェントなどへの利用の内訳（アトリビューション）が表示されると、費用管理のページに記載されています

機密情報を含むログを渡す場合は、サブエージェントに渡す前に、社内の取り扱いルールに沿って伏せ字にするなどの処理をしてください。サブエージェントも通常のセッションと同じアカウント・設定のもとで動きます。