仮に Claude Code の料金が1週間で $312 に達したとしましょう。サブエージェントの使い方を見直せば、翌週はより多くの作業をこなしながら $124 前後に収まる可能性があります——同じプロジェクトで支出はおよそ60%減。この数字は仕組みを説明するための例示であり、実測値ではありませんが、それが指し示す解決策は本物です。そしてそれは「安いモデルを使う」ではありません。
Claude Code サブエージェントというキーワードで検索すると、ほとんどの記事が並列処理のツールとして扱っています。実際にはコストのレバーです。それが誰も教えてくれなかった部分です。
長いスレッドがお金を浪費する理由
ようやく腑に落ちたのはこういうことです。1つの巨大な Claude Code セッションで作業していると、すべてのメッセージが会話履歴全体を引きずります。3時間後には、コンテキストウィンドウは古いファイルダンプ、行き詰まった試み、「いや、別のファイルだ」という自分の発言ログで埋め尽くされています。そのすべてに対してターンごとに料金が発生します。
サブエージェントは新鮮で狭いコンテキストを受け取ります。1つの作業を行い、簡潔なサマリーを返し、膨れ上がった作業コンテキストは消滅します。メインスレッドはサブエージェントが読んだ 8,000 トークン分のファイル内容を決して目にしません——3行の回答だけを受け取ります。
これがすべての仕掛けです。サブエージェントはコンテキストの分離。コンテキストの分離はコスト管理。
実際の作業分担方法
今は機能を大まかに4つのステップで構築し、それぞれに適切な担当を割り当てています。
メインエージェントは常にオーケストレーターです。計画を保持し、ほぼそれだけです。そして委任します：
- リサーチ用サブエージェントがコードベースを読み、「auth に関わる4つのファイルとその役割」を報告します。20ファイルを読み込んで、私には1段落が届きます。
- ビルダー用サブエージェントがその段落をもとに実際の変更を書きます。
- レビュアー用サブエージェントが、どういう経緯でここに至ったかの記憶なしに差分をコールドリードします。これにより、馬鹿げたミスを見つけるのが不思議なほど得意になります。
レビュアーが記憶喪失であることは仕様です。新しいエージェントは自分が書いたコードを合理化しません。
これらは .claude/agents/ に markdown ファイルとして定義します。最小限の例：
---
name: codebase-researcher
description: Finds and summarizes relevant files. Use before any change.
tools: Read, Grep, Glob
---
You locate the files relevant to the task and return a tight summary:
paths, what each does, and the 1-2 functions that matter. No code dumps.
tools の行に注目してください。リサーチャーには読み取り専用のツールを与えました。物理的にファイルを編集したりコマンドを実行したりすることができません。これにより、エージェントがテストスイートを11回実行して「調査」するという高コストな迷走の一類型を根絶できます。
最もコストがかかった失敗
曖昧な委任です。最初は「ログインのバグを修正して」というプロンプトでサブエージェントを起動していました。どこを見ればいいか分からないのでコードベース全体を最初から読み直し、節約しようとしていたトークンをそのまま焼いていました。サブエージェントはゼロから始めていたのです。
今はオーケストレーターが先に安価な偵察を行い、サブエージェントに具体的なターゲットを渡します：「auth/session.ts の中で、リフレッシュトークンがローテーションされていない。その関数だけを修正して」。入力が狭ければコンテキストも狭く、請求も小さい。
サブエージェントのプロンプトにファイル名がなければ、迷子になるためにお金を払っているようなものです。
サブエージェントを使わない方がいい場面
これには驚きました。サブエージェントは無料ではありません。ハンドオフにはオーバーヘッドがあり、タスクが小さければサブエージェントを起動するコストがインラインで実行するより高くなります。変数名を変えるだけ？メインスレッドでやりましょう。2行の変更に委員会は不要です。
私はスメルテストを使います：タスクをうまくこなすためにファイルを数個以上読む必要があるなら、サブエージェントで分離。そうでなければしない。並列化それ自体が目的になると、遅くなる分コストが高くなるだけです。
具体的な数字
こうした $312 の週は、どこにお金が消えているのでしょうか。大きな割合を占めるのは、セッションコンテキストにピン留めされた同じ4つの大きなファイルを、モデルがほぼ毎ターン読み直していることです。無数の再読み込みによる死。
再構成した週では、リサーチ用サブエージェントがそれらのファイルを1回読み、要約し、メインスレッドは要約の上を滑走します。ファイルがコンテキストに入るのは30回ではなくちょうど1回。この1つの行動変化が節約分のほぼすべてを占めます。
いくつかの小さな改善も積み重なりました。無関係なタスク間でコンテキストをクリアするようにしました（1つのセッションを丸一日動かすのをやめました）。大量のログをメインスレッドに貼り付けるのをやめ、サブエージェントにトリアージさせました。地道なリサーチには安いモデルを使い、実際のビルドとレビューには最強のモデルをとっておくようにしました——考えるのは頭のいい方に、取ってくるのは速い方に任せます。
現在の実際のセットアップ
3つのエージェントファイル：リサーチャー、ビルダー、レビュアー。リサーチャーとログトリアージエージェントは安くて速いモデルで動かします。ビルダーとレビュアーは私が持つ最強のモデルで——そこでのミスは別の形で高くつくからです。悪いコードはトークンより高い代償をもたらします。
オーケストレーターの仕事は軽量でいることです。メインスレッドがファイル内容を保持し始めた瞬間、何か間違えたと分かり、その作業をサブエージェントに押し込みます。
ソロ開発では、コンピューティングの請求書があなたの給料のルームメイトです。無駄にしないトークンすべてが利益になります。サブエージェントは速くなるためのものではありません——実際には速くなりますが。同じファイルを30回読むお金を払わないためのものです。私がそうしていたように。
今週の使用状況の内訳を確認してみてください。再読み込みだと賭けます。