コーディングエージェントのトークンの大半は「考える」ではなく I/O。どの作業を安いモデルに回してよいかを 3 つの判定軸で決める

先に結論を。コーディングエージェントが食っているトークンの大半は推論ではなく I/O です。 1 つのメソッドについて答えるために 5 つのファイルを読む。隣に並んだ 20 個と同じ形のテストを もう 1 つ書く（「Thousands of tokens gone and almost zero reasoning」と Mazmanov 氏は書いています）。 委譲してよいかどうかの一線は「出力が既存のパターンから推定できるか」——推定できるなら 安いモデルに回せます。できない作業、つまりファイルをまたいだ因果の推論は、回した瞬間に 見落としが出ます。

Spotify の Dimitri Mazmanov 氏が 2026-09-03 に公開した Portal by Spotify cut my Claude Code token usage by 90% は、この委譲を 2 つの mode だけで組み、Java monorepo の 4 シナリオで bulk-read の平均削減が 約 90% だったと報告しています。この 90% は彼らの環境・彼らの負荷での測定値で、どの コードベースでも出る数字ではなく、当方の製品がこの比率を出すという話でもありません。

本稿は、その構成を特定のプラットフォームから外します。判定軸 3 本、設定として何を書くのか、 そして他人の削減率ではなく自分の 4 つの数字から見積もる式の順です。

エージェントのトークンは何に消えているのか——会話の層と探索の層は別の財布

同じ形は日本でも測られています。ペパボの Claude Code のトークン削減を実測した は、意味検索 MCP サーバー semble の実ログを集計しています。累計 331 回の検索で、全ファイルを 読んだ場合の相当量が約 830 万トークン、semble 経由の送信量が約 50 万トークン、削減率 93% （同じく彼らの環境での読み取り）。手段は違いますが——Spotify は別モデルへの委譲、ペパボは 意味検索——削っている場所は同じです。

その「場所」を言語化しているのが ナレッジグラフを活用して Claude Code のトークンを 10 分の 1 にする です。曰く、トークン消費には 2 つの層がある。会話の蓄積は /clear や /compact、CLAUDE.md の 整理で減らせるが、エージェントがコードを調べる行為そのものは会話をいくら整理しても減らない。 同記事は Codebase-Memory（2026）を引いて、この探索が 1 回の問い合わせで数千トークンを消費し、 読んだ内容の大半は最終的な回答に使われないと書いています。

つまり運用術と委譲は別の財布です。前者は毎ターン固定で載る常駐コスト、後者は調査 1 回ごとの 変動コスト。片方をやれば済む、という関係ではありません。

委譲してよい作業の判定軸は 3 本——出力の推定可能性・行番号の要否・ファイル横断の因果

Spotify の記事で一番使えるのは、実は削減率ではなく「What doesn’t work」の節です。氏が挙げた 「できなかったこと」3 つを、肯定形に組み直します。

3 行目が一番きつい制約です。氏のテストでは worker モデルが表層のパターンは見つけた一方、 微妙な thread-safety のバグを見落とした（Claude は正しいコンテキストを与えられたら数秒で 見つけた、とも）。だからルーティングからは debugging、アーキテクチャの判断、safety-critical な コードを明示的に除外しています。

この境界の位置は、別の実験からも裏づけが取れます。CodeRabbit が 2026-09-04 に公開した GPT-6 Astra in code review は、actionable bug coverage（ラベル付きのバグを、開発者が手を打てる指摘としてどれだけ拾えたか） で GPT-6 Astra を評価しています。全体で拾えた数は GPT-5.6 Sol より約 4% 多い（Opus 5 比では 22% 多い）。ところが難しい cross-file の部分集合では、Sol 比 20%、Opus 5 比 33% まで開く。 いずれも相対的な増加率で、パーセントポイント差ではありません。全体の評価には簡単なレビューも 含まれ、そこでは強いモデルが差をつける余地が少ないからです。

片方は委譲の失敗例、片方はモデル間の性能差。別々のことを測っていて、線を引く場所は同じです。 簡単な作業まで含めた全体では高いモデルの上積みが 4% どまり、cross-file だけ見ると 20%—— 同じ 2 モデルの差が、作業の質で 5 倍に開く。この開き方こそが降格の可否を分ける線です。 ただし記事自身が注釈を付けています——これは review 性能の一部の記述であって、すべての PR で 同じ差が出るという約束ではなく、early, directional result である、と。

設定として何を書くのか——2 つの mode、閾値、強制点

Spotify の実装は Portal という自社プラットフォーム上の mode ですが、書いてあることの ほとんどは実装に依存しません。分解すると 3 層です。

1 層目、worker の宣言。 mode は「命令文・モデル・パラメータ・ツール」を宣言するだけの オブジェクトです。読み取り用の bulk-reader には「構造化された箇条書きのみを出せ。挨拶も 前置きも散文も禁止。各項目は正確な名前・型・行番号で始めろ」、生成用の code-writer には 「既存のパターン・規約・命名・スタイルに正確に合わせろ。コードだけを出せ」。どちらも temperature: 0.2、worker は記事の例では Gemini 2.5 Flash です。

この「output only the code」の一行に、氏はわざわざ節を割いています。これが無いと worker は markdown fence と説明文で包んで返し、それを Claude 側が読み解く羽目になるからです。

2 層目、強制点。 初版は CLAUDE.md に規則を書く方式でしたが、規則が advisory で強制されない （エージェントが無視できる）、プロジェクトごとにコピーが要る、の 2 点で置き換えられました。 現行版は PreToolUse フックで、閾値（既定 350 行）を超える Read をブロックし、委譲用のスキルを 使えと返す。cat / head / tail / less / more も同様に捕捉。ただし狙い撃ちの読みは 通します——Claude はすでにどこを読むべきか分かっているからです。閾値は環境変数で動かせます。

{
  "env": {
    "SHUNT_MIN_LINES": "500"
  }
}

3 層目、呼び出し規約。 スキルファイルが、いつどう呼ぶかを書きます。フックがブロックした ときのメッセージがスキルを指し、スキルが呼び出し構文を示す。氏はこの重ね方を 「degrades gracefully」と説明しています——スキルの説明が読まれなくても、フックが高価な読みを 止めるからです。

一般名詞に置き換えると、mode = ルーティング先の宣言、フック = 強制点、スキル = 呼び出し規約。 固有なのは実装であって、構造ではありません。強制点をエージェント側のフックに置くか、 ルーティング層の規則に置くかは、そのうえでの設計の選択です。

どれだけ減るかは自分の 4 つの数字から出す——削減率を借りてはいけない

他人の 90% を自分の見積りに使わないでください。決めるのは次の 4 つの数字です。

節約はおおよそ r × (T_read − T_sum) × (p_f − p_w) に比例します。

4 つ目が曲者です。 生の価格差で計算すると、委譲の効果を過大に見積もります。arXiv の Inference Economics of Enterprise Coding Agents（2026-07-13）は、 単一開発者・連続する 28 日間 × 2 期の縦断ケーススタディで、prompt caching のヒット率 99.3% に より実現 API コストが 88.6% 下がり、実効単価 $0.57/M——共有 GPU スライスの按分単価 $2.83/M すら下回った、と報告しています（著者らは利用率依存の逆転と呼び、頑健な量は総支出と TCO の ほうだと明記。n=1・非ランダム化の事例研究です）。

ここから当方の判断を 1 つ。キャッシュがよく効いている読みを委譲に回すと、委譲先のほうが 高くつくことがあります。 同じファイルを何度も読む作業はヒット率が高く、frontier 側の実効単価が すでに落ちている。一方 worker への委譲は毎回が one-shot です（Spotify も 「invocation is ephemeral」と書いています）。同じトークンには両方は効きません——重複して 見積もると二重計上になります。繰り返される読みならキャッシュ、一度きりの大量読みなら委譲です。

規模感も押さえておきます。Mazmanov 氏によれば、エンジニアリング責任者の 4 分の 1 がすでに 開発者 1 人あたり月 $200〜$500 をトークンに使っており、$2,000 をゆうに超えるところも あるとのこと。委譲で削る対象は、この桁の支出です。

遅延も費用です。委譲は 1 回ごとにネットワーク往復で、応答は典型的に 10〜30 秒、Portal 側は 1 回の呼び出しを 30 秒で打ち切る。閾値が存在する理由がここです——小さい読みでは往復の オーバーヘッドが節約を上回ります。

導入の順序——測る、閾値を決める、それから委譲する

1. 内訳を取る。 /context と使用ログで、常駐コストと調査コストを分けます。常駐側が 膨らんでいるなら委譲より先にそちらで、 rules ファイルを最適化してコンテキスト消費を 78% 削減した の例では rules が 23.7k から 5.5k トークンへ落ちています。

2. 閾値を決める。 既定 350 行は出発点であって正解ではありません。自分の Read 呼び出しの 行数分布を見て、委譲の往復（10〜30 秒）が節約に見合う位置に置きます。狙い撃ちの読みは 通すこと——塞ぐと、編集のたびに委譲して要約を受け取り、行番号が合わずにやり直す、という 最悪の経路が生まれます。

3. 読みから始める。 Spotify の code-write が reference を必須引数にしている理由も 書かれています——合わせる対象が無ければ、worker はどこにも合わないコードを生成する。 読みの委譲が安定してから、テストや設定スタブのような「隣に手本がある」生成に広げてください。

最後に目標の置き方を 1 つ。削減率を目標にしないでください。 目標にすべきは、frontier モデルに読ませたファイルのうち答えに使われなかった行数です。90% は出ることも出ないことも ある副産物ですが、この行数は誰の環境でも自分で数えられます。