Claude Code のサブエージェントはいつ元が取れるか: ジョブ別の判定と、メインセッションのほうが安いケース

Claude Code のサブエージェントのページは、「いつ使うべきか」に一文で答えています。脇の作業が「後で参照しない検索結果、ログ、ファイル内容でメイン会話をあふれさせてしまう場合です。サブエージェントはその作業を自分のコンテキストで行い、要約だけを返します」。自分のトランスクリプト 2 週間分を調べると、バックグラウンドのサブエージェントは価格換算した使用量の約 11.5% を占め、その 64% がキャッシュ書き込みでした。つまりサブエージェントは、散らかった出力を読むためのコストをちゃんと払っています。ドキュメントの一文が触れていないのは、代わりに何が返ってきて、それと一緒に何を失うかです。

委任すると 3 つのことが同時に変わります。1 つ目はトークンです。出力は別の場所に、別の料金で、別の寿命でキャッシュされます。2 つ目は証拠です。親が見るのはサブエージェントによる説明で、生の出力はディスク上のトランスクリプトに残り、何かおかしいと感じない限り誰も開きません。3 つ目はフレーミングです。新規のサブエージェントは、問題についての親の仮説を持ち込みません。それこそが狙いという場合もあります。以下のジョブでは、この 3 つの交換条件がそれぞれ違います。

何が何に基づいているかがわかるように、ラベルを付けておきます。ドキュメント記載は、Claude Code のドキュメントがそのパターンを説明しているもの。実測は、自分の環境でそれについて何かを測ったもので、その記事を主張の箇所にリンクしています。報告は、Anthropic が自社のリサーチシステム（Claude Code ではありません）の結果として公表したものです。コストについての推論は定価ベースの計算で、どのジョブも両方のやり方で実行して比べたことはありません。

Claude Code のサブエージェントはタスクのコストをどう変えるのか？

変わるのは、ツール出力がキャッシュされる場所です。メイン会話では、ツールの結果はコンテキストに残り、コンパクション、/clear、または Claude Code による古いツール結果の消去が起きるまで、以降のリクエストのたびに読み直されます。サブエージェントでは、同じ出力はサブエージェント自身のコンテキストで読まれ、親に届くのはその結果だけです。

既定値はプロンプトキャッシュのドキュメントが決めています。プランの使用量の範囲内で Claude のサブスクリプションを使っている場合、メイン会話には 1 時間のキャッシュが付きます。サブエージェントは「サブスクリプションであっても、より長い設定を選ぶまでは」5 分で、サブエージェントの最初のリクエストは「2 つのプレフィックスが異なるため、親のキャッシュを読みません」。API キー、クラウドプロバイダー、usage credits の場合は、メイン会話も既定で 5 分です。promptCacheTtl と subagentPromptCacheTtl で、それぞれのバケットを変更できます。Claude Code のコスト内訳にある Opus 5.5 の定価では、キャッシュ読み取りは基本入力の 0.05 倍、5 分の書き込みは 1.25 倍、1 時間の書き込みは 2 倍です。

ミスなしでキャッシュに残り続ける、理想化した出力のかたまりを考えてみます。サブスクリプションの既定のメイン会話では、これは 2 倍で 1 回書き込まれ、以降のリクエスト 20 回ごとに基本入力 1 回分の料金をもう一度払って読み直されます（20 × 0.05）。サブエージェントは 1.25 倍で書き込み、数回読んで、そのまま置いていきます。その代わりにサブエージェントは起動コストを払います。指示、ツール定義、ブリーフをコールドの状態で書き込むコストです。起動コストの大きさは、どのサブエージェントのトランスクリプトでも、最初のリクエストのキャッシュ書き込みトークンとして読み取れます。

サブエージェント自身の読み取りと、それが返す要約はいったん脇に置きます。すると損益分岐点は、それを超えると委任のほうが安くなるかたまりのサイズとして、起動コストの倍数で表せます。

サブスクリプションでは、大きなかたまりは、直後にセッションが終わったとしてもサブエージェントのほうが安くなります。1 時間の書き込みのほうが 5 分の書き込みより高いからです。両方とも 5 分の場合、書き込みは差し引きゼロで、起動コストをまかなえるのは避けられた読み直しだけです。数えるのは API リクエストで、自分が打つメッセージではありません。ツール結果を返すレスポンスのたびに、新しいリクエストが 1 つ始まります。

実際には、起動コストは小さいほうでした。バックグラウンドのサブエージェントの監査（実測）では、最初のリクエストはサブエージェントのキャッシュ書き込みの約 10% でした。残りはその後、サブエージェントが読み込んだ内容とキャッシュの再構築から来ていて、トランスクリプトからはこの 2 つを区別できません。同じ監査からは、それぞれ異なる作業を集計した数字ですが、キャッシュされたトークン 1 つあたりの生涯価格の目安も出ます。メイン会話では書き込み 1 回あたり 29.6 回の読み取りで、定価の比率で基本入力の約 3.5 倍。バックグラウンドのサブエージェントでは 9.4 回で、約 1.7 倍です。ジョブが違うので、比較ではなくあくまで概略です。

フォークならコールドスタートを省けます。フォークは親の指示、ツール、履歴をそのまま引き継ぐので、キャッシュのドキュメントによれば「最初のリクエストは親のキャッシュを読みます」。サブエージェントのドキュメントも、フォークは「同じコンテキストを必要とするタスクでは、新規のサブエージェントより安く済みます」と書いています。安い理由とリスクが高い理由は同じで、この点はレビューの節でもう一度出てきます。そしてどれも同じ 1 つの上限から引かれます。サブエージェントは「独自のリクエストを送り、それはメイン会話と同じ使用量の上限にカウントされます」。

Claude Code のサブエージェントにテストスイートを実行させるべきか？

はい。いちばんわかりやすいケースです。ドキュメントの「Isolate high-volume operations」の最初の例が、まさにこのプロンプトです。

Use a subagent to run the test suite and report only the failing tests with their error messages

テストのフル実行は「後で参照しない出力」の典型で、たいてい量も多いので、損益分岐点を大きく上回ります。手放すのはログです。自分ならドキュメントのプロンプトからもう一歩進めて、失敗したテスト名とエラーメッセージを原文のまま返すよう頼みます。そうすれば、何かつじつまが合わないときに、その報告をトランスクリプトと突き合わせて確認できます。

出力の末尾だけが欲しいという狭い用途なら、もっと安い手段があります。コストのページには、テストコマンドを書き換えて最後の 100 行だけを残す PreToolUse フックが載っています。シェルのフィルターなので、2 つ目のコンテキストの料金はかかりません。サブエージェントがフックより役に立つのは、失敗を切り詰めるのではなく、読んで分類する必要があるときです。

遅いテストスイートには、もう 1 つコストがあります。サブエージェントのキャッシュは既定で 5 分なので、コマンドを待って 5 分以上アイドルになったサブエージェントは、期限切れのキャッシュに戻ってくることになります。2.1.318 以降は、これを防ぐために、バックグラウンドのサブエージェントのシェルコマンドが 3 分後にバックグラウンドへ移ります。自分の監査では、このケースはまれでした。同じサブエージェントの前回のリクエストから 5 分以上たって届いたリクエストは、バックグラウンドのサブエージェントのキャッシュ書き込みの 0.73% でした。これは代理指標で、しかも自分のサブエージェントは長いビルドをほとんど走らせていません。

コードベース検索に Claude Code のサブエージェントを使う価値はあるか？

頭に入っていないリポジトリで「この挙動はどこにあるのか」を探すなら、答えが小さくても価値はあります。組み込みの Explore エージェントは読み取り専用で、ドキュメントによれば「Explore と Plan は、リサーチを速く安価に保つため、CLAUDE.md ファイルと git status のスナップショットなしで起動します」。

ここでの論点は、トークンよりもフレーミングです。8 月に、クリーンなコンテキストの検索役をいつも使っていると書きました。新規の検索役はコードを読みますが、バグについてこちらの仮説を抱えた検索役は、その仮説を裏付ける証拠を見つけてきます。だから線を引く基準は出力の量ではありません。どのファイルかわかっているなら、自分で grep します。サブエージェントは起動コストを丸ごと払って、同じ数行を返すだけです。わかっているつもりなだけなら、それこそクリーンな検索役を使う場面です。

料金にも落とし穴があります。Explore は Haiku ではなく、親の会話のモデルで動きます。v2.1.198 以降はセッションのモデルを Opus を上限として引き継ぐので、Opus のセッションでは検索がすべて Opus の呼び出しになります。これは Haiku 5.5 のサブエージェントの記事で追ったとおりです（Fable のセッションでは、接続方法によって変わるとドキュメントは書いています）。CLAUDE_CODE_SUBAGENT_MODEL だけでは Explore と Plan のモデルは変わりません。その記事のとおり CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 を追加するか、model: haiku を指定した Explore という名前の独自エージェントを定義します。また Explore は使い切りです。エージェント ID を返さず、再開もできないので、後で広げたくなりそうな検索は general-purpose かカスタムエージェントに任せます。

Claude Code のサブエージェントに diff をレビューさせるべきか？

はい。そしてこれは、計算上はメインに残るべきなのに、それでも委任すべきケースです。メイン会話はすでに diff を持っているので、レビュー役は親がキャッシュ済みのものを読むためにコストを払うことになります。その代わりに手に入るのは、作成者のフレーミングを共有しない読み手です。コードを書いたセッションを引き継いだレビュー役は、そのセッションが捨てた推測まで引き継ぎます。しかもその推測は、結論と同じ平板な口調で書かれています。

ドキュメントの例にある code-reviewer は、tools: Read, Grep, Glob, Bash を持つ読み取り専用のサブエージェントで、git diff から作業を始めます。この出発点が大事なのは、ブリーフを書くのが親だからです。レビュー役に渡すのは diff とチェックリストで、変更が何をするかについての作成者の説明ではありません。

同じ理由で、このジョブにフォークは向いていません。しかも 2.1.302 以降、フォークは claude -p と Agent SDK でも既定でオンです。2.1.302 で中立的なプロンプトを 1 回だけ試したとき（実測：Haiku、自分のプラグインとエージェントを読み込んだ状態）、モデルが要求したのはフォークではなく general-purpose でした。1 つのモデルでの 1 回の実行は、あなたの環境については何も示しません。レビューのステップでは、permissions.deny に "Agent(fork)" を追加するか、CLAUDE_CODE_FORK_SUBAGENT=0 を設定します。どちらもドキュメントに記載があります。

要約の問題がいちばん鋭く出るのがここです。「問題は見つかりませんでした」も要約だからです。指摘にはファイルと行番号を付けてもらい、1 件ずつ数秒で確認できるようにします。空のレビューは、~/.claude/projects/ の下にあるサブエージェントのトランスクリプトで、実際に diff を開いたことが確認できるまでは未検証として扱います。

並列リサーチで Claude Code のサブエージェントは元が取れるか？

場合によります。そしてこれは、サブエージェントが節約にならない唯一のジョブです。ファンアウトは、1 つのコンテキストで使える以上のトークンを使って成果を買う手法です。ドキュメントの「Run parallel research」パターンは、別々のモジュールに複数のサブエージェントを立ち上げるもので、「リサーチの経路が互いに依存しないときに最もうまく機能する」と書かれています。あわせて、多くのサブエージェントがそれぞれ詳細な結果を返すと「かなりのコンテキストを消費し、各サブエージェントも実行中に自分のトークンを使う」という警告もあります。

もっとも強い数字は報告で、2025 年 6 月の Anthropic のリサーチシステムの記事から来ています。Claude Opus 4 と Sonnet 4 で動く Research 機能についての記事です。数字はそれぞれ別の比較から出ています。単一の Opus 4 エージェントと比べて、マルチエージェント構成は社内のリサーチ評価で 90.2% 高いスコアを出しました。BrowseComp では、トークン使用量だけで性能のばらつきの 80% を説明できました。そしてチャットとの比較では「エージェントは通常、チャットでのやり取りの約 4 倍のトークンを使い、マルチエージェントシステムはチャットの約 15 倍のトークンを使う」。この記事は、コーディングにとって重要な線も引いています。「ほとんどのコーディングタスクは、リサーチに比べて本当に並列化できる作業が少ない」。

数字抜きでも通用する教訓もあります。各サブエージェントには、目的、出力形式、ツールと情報源についての指針、明確な境界が必要です。Anthropic によれば、ブリーフが曖昧だとエージェントは作業を重複させたり、抜けを残したり、必要なものを見落としたりしました。また「伝言ゲーム」を減らすため、同社のサブエージェントは作業を外部システムに保存し、「軽量な参照を返して」いました。Claude Code に置き換えるとこうなります。各リサーチ役に調査結果をファイルへ書かせ、すべての主張の横にソース URL か、ファイルと行番号の引用を付けさせ、パスを返させます。言い換えへのパスも、言い換えであることに変わりはありません。親が確認できるのは、引用があるからです。

並列編集は Claude Code のサブエージェントに任せるべきか？

ほとんどの場合、任せません。編集が返すのは小さな diff なので、隔離する価値のある出力がありません。得られるのは実時間の短縮だけで、それは別々のセッションの役目です。ドキュメントも同じ境界を引いています。「並列で動かし続ける必要がある作業や、1 つのコンテキストウィンドウに収まらない作業は、別々のセッションで実行してください」。

仕組みも同じ方向を指しています。サブエージェントはメイン会話の作業ディレクトリで起動するので、並列のサブエージェントは 1 つのチェックアウトを編集することになります。isolation: worktree を使うとサブエージェントは自分用のコピーを持てますが、そのコピーは「既定では親セッションの HEAD ではなく、デフォルトブランチから分岐」します。worktree.baseRef を "head" にすればコミットは持ち込めますが、自分のテストでは、コミットしていない変更はそれでも置き去りになりました。機能の実装途中では、それが普通の状態です。コミットするか、変更を明示的に渡してください。

2.1.316 での worktree のテスト（実測、claude -p --worktree のセッション。サブエージェントは使っていません）では、2 つの worktree が 1 つのポートで衝突し、Docker Compose はそれぞれに別の Postgres ボリュームを用意しようとし、既定のベースはプッシュしていないコミットを飛ばしました。ドキュメントによればサブエージェントの worktree も同じ worktree.baseRef を使うので、isolation: worktree でも同じことが起きると予想しています。その部分は未検証です。

メインの Claude Code セッションがサブエージェントより安いのはどんなときか？

作業が複数のステップでコンテキストを共有するとき、あるいは出力が損益分岐点を下回るほど小さいときです。ドキュメントは、メイン会話にとどまるべき 4 つのケースを挙げています。頻繁なやり取りや反復的な改善。計画、実装、テストのように、大きなコンテキストを共有する複数のフェーズ。素早く的を絞った変更。そしてレイテンシです。フォーク以外のサブエージェントは「まっさらな状態で起動し、コンテキストを集めるのに時間がかかることがある」からです。

どれもコストの形に対応しています。反復すると起動が繰り返されるか、再開することになりますが、再開が安く済むのはサブエージェントの 5 分のキャッシュが温かいあいだだけです。フェーズを共有するなら、親がすでに持っているコンテキストをサブエージェントに渡さなければならず、そこまで中身の濃いブリーフを書けば、節約したかった分の大半は消えます。作業が本当に一続きの思考なら、それは新規のサブエージェントではなくフォークの仕事です。的を絞った変更は、隔離するほどの出力を生みません。すでに会話にあるものについての質問なら、ドキュメントは /btw を勧めています。/btw は「ツールにアクセスできず、回答は履歴に追加されません」。

サブエージェントの連鎖（1 つでレビューし、次で修正する）もドキュメントに載っていますが、どのホップも要約として親を経由します。修正役がレビュー役の結論ではなく証拠を必要とするなら、ステップの間で指摘をファイルに書き出してください。

Claude Code のサブエージェントはどのモデルで動かすべきか？

意図して振り分けない限り、親のモデルです。ドキュメントによれば、定義したサブエージェントは「それを起動した会話と同じモデルで動きます」。Claude Code は、呼び出しごとのパラメーター、定義の model フィールド、CLAUDE_CODE_SUBAGENT_MODEL、親のモデルの順に参照し、CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 は最初の 2 つを上書きします。コストのページは、「単純なサブエージェントのタスク」には model: haiku を勧めています。

節約を見積もる前に、エイリアスが何に解決されるかを確認してください。haiku は Anthropic API では Haiku 5.5 を指しますが、Bedrock、Google Cloud、Microsoft Foundry、Claude Platform on AWS ではまだ Haiku 4.5 にマッピングされます。それに Haiku 5.5 はトークン単価が安いのであって、タスク単位で自動的に安くなるわけではありません。1 回の呼び出しに収まる要約こそ、その料金体系が想定している用途です。長い検索ループでは 100K の長文プロンプト料金が効いてくるので、Haiku 5.5 のサブエージェントの記事で説明したように、先に effort を固定し、/autocompact 100k を設定します。レビューについていちばん近い根拠は Bug Hunt Bench です。仕込まれたバグ 105 件中、Haiku 5.5（max effort）が見つけたのは 21.5 件、Opus 5.5（xhigh）は 36 件でした。

Claude Code のサブエージェントが自分のセッションで元を取れているかはどう確かめるか？

まず割合を見て、次にその中身を見ます。Pro、Max、Ultra、Team、Enterprise のプランでは、/usage が直近の使用量のうちサブエージェントの分を、24 時間または 7 日間の割合として表示します。計算はローカルの履歴から行われます。Prompt cache (main) の行はメイン会話だけが対象なので、サブエージェント自身のキャッシュの挙動を見るには ~/.claude/projects/ の下のトランスクリプトが必要です。

その監査を行ったとき（実測、Max プラン、10 月 22 日から 11 月 4 日）、バックグラウンドのサブエージェントは価格換算した使用量の約 11.5% で、そのコストの 64% は 5 分のキャッシュ書き込みでした。書き込みの大半は最初のリクエストより後に発生していて、監査では新しい内容とキャッシュの再構築を区別できませんでした。スクリプトはその記事にあります。同じジョブをメイン会話で行っていたらもっと高くついたかどうかは、このスクリプトではわかりません。両方のやり方で実行していないからです。

つまり、ドキュメントの基準である「後で参照しない出力」は、判断の半分にすぎません。残りの半分はこうです。起動コストを上回るだけの量があるか（サブスクリプションでは、その量は多くありません）。結果がトランスクリプトと突き合わせて確認できる形で返ってくるか。そしてそのジョブに、自分のフレーミングを持たない読み手が必要か。テスト実行は 3 つすべてを満たします。ファイルがわかっている grep は 1 つ目で落ちます。レビューはコストの基準では落ちますが、それでも委任すべきです。