はじめに

「重い調べ物はsubagent（サブエージェント）に丸投げすれば、トークンを節約できる」。私はしばらく、そう思い込んでいました。半分は当たっていて、半分は間違いでした。

きっかけは、コンテキストがすぐ埋まるのが嫌で、ファイル探索やログ調査をかたっぱしからsubagentに投げるようにしたことです。狙いどおり、メインの会話は驚くほどスッキリしました。読み込んだ大量のファイルが自分の画面に積み上がらない。これは快適です。ところが、そのわりに使用量の減りが体感と合いません。むしろ、細かい調べ物まで投げていた時期のほうが、総消費は増えている気がしました。

理由は、subagentの仕組みを公式ドキュメントで読み直して腑に落ちました。subagentは、あなたの「主コンテキスト（メインの会話）」を軽くする道具ではありますが、「請求されるトークンの総量」を減らす道具ではないのです。この2つは、混同しがちですが別物です。今回は、なぜ丸投げで主コンテキストが減るのに総トークンが増えうるのか、その仕組みと、じゃあどこで使うと得なのかを整理します。

先に3行でまとめると

subagentは別ウィンドウで動く。読んだ中身は主コンテキストに積まれず、戻るのは要約だけ。だから主コンテキストは大きく減る
ただしsubagentは起動のたびにセットアップ（システムプロンプト・CLAUDE.md・git status）を読み直す。主ウィンドウのキャッシュも使えない。この重複が総トークンを押し上げる
得なのは「二度と参照しない大量の出力」を隔離するとき。小さな調べ物の丸投げは、主コンテキストは減っても総量は損をしやすい

この記事に出てくる用語の位置づけ

Claude Code独自の呼び名と、AI記事で一般に使う言葉が混ざります。迷ったらここに戻ってきてください。

用語	位置づけ	ざっくりの意味
subagent（サブエージェント）	一般用語（Claude Codeで機能化）	親セッションが仕事を委譲する子エージェント
fork	Claude Code独自	会話履歴ごと引き継いで分岐するsubagent
主コンテキスト	本記事の呼称	あなたが見ているメイン会話のコンテキストウィンドウ
コンテキストウィンドウ	一般用語	モデルが一度に読める入力の枠。埋まると圧縮が走る
プロンプトキャッシュ	一般用語	同じ前置きを再利用して再課金を抑える仕組み
CLAUDE.md	Claude Code独自	プロジェクトの方針を書いておく設定ファイル
`/context`	Claude Code独自	今のコンテキストの内訳を見るコマンド

「主コンテキスト」という言葉だけは記事の便宜で使っています。公式には単にコンテキストウィンドウと呼ばれるものの、あなたが見ているメイン会話ぶん、という意味で使い分けています。

まず結果

細かい話の前に、丸投げすると何がどう動くかを先に置いておきます。

見る場所	丸投げすると	ひとことで言うと
主コンテキスト（あなたの画面）	大きく減る	6,100トークン読んでも、戻るのは420トークンの要約だけ
subagent側の消費	別枠で発生する	読んだ6,100＋セットアップの再ロードが、見えないところで課金される
総請求トークン	タスクが小さいと増えがち	セットアップの重複ぶん、インラインより高くつくことがある

主コンテキストが減る、という体感は正しいです。ただそれは「節約」ではなく「隔離」です。消費が消えたのではなく、あなたに見えないウィンドウへ移動しただけ。ここが今回いちばん伝えたいところです。

subagentは別ウィンドウで動く

まず、subagentがなぜ主コンテキストを軽くできるのか。仕組みはシンプルで、subagentは主コンテキストとは別の、新しいコンテキストウィンドウで動くからです。

公式ドキュメントの表現を借りると、subagentは「独自のコンテキストウィンドウで、専用のシステムプロンプト・限定されたツール・独立した権限を持って動く」ものです。そして「まっさらで隔離されたコンテキストウィンドウから始まり、あなたの会話履歴も、これまで開いたスキルも、Claudeがすでに読んだファイルも見ない」。fork（会話履歴ごと引き継ぐ分岐）だけが例外で、これは「これまでの会話全体を引き継ぐ」動きになります。

公式のコンテキストウィンドウ解説には、ちょうどいい具体例が載っています。あるsubagentがファイルを6,100トークンぶん読み込み、あなたの主コンテキストに戻ってきたのは420トークンの要約だった、というものです。つまり主コンテキストに積まれる量は6,100から420へ、約93%も減ります。これが「コンテキストの節約」の正体です。読み散らかした調査ログを主会話に持ち込まずに済む、というのは確かに大きな利点です。

なぜ総トークンは増えうるのか

ここからが本題です。主コンテキストが軽くなるのはいいとして、消えたはずの6,100トークンはどこへ行ったのか。答えは、subagent側のウィンドウで、しっかり課金されています。しかも、それだけでは済みません。

subagentは起動のたびに、動くための下ごしらえを読み直します。公式ドキュメントによれば、新しいsubagentには次のものが渡されます。

委譲の指示文（親が書くタスクの依頼メッセージ）
そのエージェント用のシステムプロンプトと環境情報
CLAUDE.mdの階層すべて（親会話が読んでいるのと同じもの）
開始時点のgit statusのスナップショット、事前ロードされたスキル、他エージェントの一覧

問題は、これが主コンテキストのプロンプトキャッシュを使えないことです。forkだけは「システムプロンプトとツール定義が親と同一なので、最初のリクエストで親のプロンプトキャッシュを再利用できる」と明記されていて、だからこそ「同じ文脈が必要なタスクでは、まっさらなsubagentを立てるよりforkのほうが安い」とされています。裏を返すと、fork以外の普通のsubagentは、このセットアップを毎回まるごと新規に読み込む、ということです。

図にすると損得がはっきりします。自分でインラインに読めば、システムプロンプトはすでにキャッシュ済みなので、追加で乗るのはファイルの6,100トークンくらいです。ところがsubagentに丸投げすると、読み込みの6,100はそのまま発生したうえに、セットアップの再ロードが別途乗ります。上の図の右側は、その再ロードを約6,000トークンと仮に置いた試算です。数字は環境で変わりますが、方向は変わりません。主ウィンドウは軽くなるのに、総量はむしろ膨らむ。

図の「約6,000」は実測ではなく試算です。公式のコンテキストウィンドウ解説にあるシステムプロンプト4,200トークンに、環境情報やCLAUDE.mdぶんを足した概算で、あなたのCLAUDE.mdの分量やスキル設定によって上下します。正確な数字は、後述の /context と結果に付く注記で自分の環境を測ってください。

じゃあ、いつ丸投げが得なのか

ここまで読むと「subagentは損」に聞こえるかもしれませんが、そうではありません。損得は、隔離したい出力の大きさで決まります。

判断の軸を先に図にしておきます。丸投げするか、forkするか、主会話でそのまま読むか。分かれ目は「隔離したい出力の大きさ」と「文脈を引き継ぎたいか」の2つです。

得なのは、公式ドキュメントの言い方だと「検索結果・ログ・ファイルの中身のような、あとで参照しない大量の出力が主会話をあふれさせるとき」です。50個のファイルを読み回してようやく1つの結論が出るような調査なら、その50個ぶんを主コンテキストから隔離できる価値は、セットアップの再ロード数千トークンを軽く上回ります。逆に、数百トークンで済む小さな調べ物を投げると、隔離の利得よりセットアップの重複が勝って、主コンテキストは減るのに総量は損をします。

もう一つの分かれ目がレイテンシです。公式は「レイテンシが効くときは主会話で。forkでないsubagentはまっさらから始まるので、文脈を集め直す時間がかかる」と書いています。速さが欲しい小タスクほど、丸投げは不利になります。

コストを抑える具体策としては、次の2つが効きます。

やり方	効き方
同じ文脈のまま作業を分けたいなら `fork`	親のプロンプトキャッシュを再利用でき、まっさらなsubagentより安い
モデルを `model: haiku` に落とす	速くて安いモデルにタスクを回してコストを抑える

なお組み込みのExploreエージェントは、この辺りが最初から最適化されています。ExploreとPlanは「調査を速く安く保つため、CLAUDE.mdと親のgit statusを読み飛ばす」設計で、さらにExploreはClaude APIでモデルの上限がOpusに抑えられていて、親より高いモデルで走らないようになっています。用途が探索と割り切れるなら、自作subagentより組み込みのExploreに任せるほうが素直です。

丸投げのアンチパターン

私が実際にやらかした、あるいは危なかったパターンを挙げておきます。どれも「主コンテキストが減ったから得をした気になる」ことが根っこにあります。

やりがちな失敗	何が起きるか	どうするか
小さな調べ物まで全部subagentに投げる	主会話は綺麗になるが、セットアップの重複で総量が膨らむ	数百トークンで済むものは主会話でそのまま読む
同じ文脈の続き作業に新規subagentを立てる	文脈を毎回集め直し、キャッシュも効かない	文脈を引き継ぎたいなら `fork` を使う
主コンテキストの余裕＝節約、と考える	`/context` の余裕は増えても請求は別で増えている	主コンテキストと総トークンを分けて見る
隔離した出力を結局あとで何度も参照する	要約しか戻らないので、また読み直す羽目になる	後で使う情報は最初から主会話に置く

3つめは、私が長くハマっていた勘違いそのものです。/context に余白が戻ってくると、それだけで「節約できた」と錯覚します。でも余白が戻るのと請求が減るのは、まったく別の話でした。

自分の環境で測る

ここまでの数字はあくまで公式の例と試算です。いちばん確実なのは、自分の環境で測ることです。方法は2つあります。

ひとつは /context で、今のコンテキストの内訳を見ること。システムプロンプトやCLAUDE.mdが何トークンを占めているかがわかるので、subagentが起動のたびに読み直すセットアップの実サイズが見積もれます。もうひとつは、subagentが仕事を終えて要約を返すとき、結果に所要時間とトークン数の小さな注記が一緒に付くこと。これで「読み込みに対して、戻ってきた要約がどれくらいか」の実比が取れます。

自分のCLAUDE.mdが厚いプロジェクトほど、セットアップの再ロードは重くなります。もし丸投げを多用していて使用量が気になるなら、まずCLAUDE.mdの分量を /context で確認するところから始めると、効き目が見えやすいはずです。

おわりに

subagentを測り直して感じたのは、「コンテキストを空ける」と「トークンを節約する」を、自分がずっと同じものとして扱っていたということでした。実際には、subagentは前者のための道具で、後者は保証しません。むしろ小さく使うと総量は増える。この非対称を知っているかどうかで、丸投げの判断はだいぶ変わります。

Devinを使っていても、同じ論点にぶつかります。セッションを分けるか、ひとつの文脈で続けるか。マルチエージェントに割るか、単一で通すか。分けるほど画面は整理されますが、そのぶん立ち上げのコストは積み上がる。エージェントに任せる粒度をどう切るかは、Claude CodeでもDevinでも、結局は「隔離の利得が、立ち上げのコストを上回るか」で決まるのだと思います。次は、自分のプロジェクトで丸投げの前後を /context で実測して、どのくらいの調査サイズから元が取れるのか、境界線を測ってみるつもりです。

🚀 Devin専門の解説メディア「StartDevin」を運営中！
Devinの導入・使い方・最新アップデート・活用事例を、日本語でまとめています。
👉 StartDevin をチェックする（startdevin.jp）

この記事にぜひ いいね（LGTM） していただけると励みになります 🙌

参考リンク

Subagents（Claude Code公式ドキュメント）（一次情報。subagentのコンテキスト隔離とfork、モデル選択）
Explore the context window（Claude Code公式ドキュメント）（6,100→420の例と、コンテキストの内訳シミュレーション）
Slash commands（/context などのコマンド）