# コーディングエージェントのトークンの大半は「考える」ではなく I/O。どの作業を安いモデルに回してよいかを 3 つの判定軸で決める > Spotify の Dimitri Mazmanov 氏は、ファイル読みと定型コード生成を安いモデルへ委譲して bulk-read 平均約 90% 削減を報告しました（彼らの Java monorepo・4 シナリオでの結果）。本稿はその構成を特定プラットフォームから外し、委譲の可否を決める 3 つの判定軸、設定の書き方、そして削減率ではなく自分の 4 つの数字から見積もる式に組み直します。CodeRabbit の cross-file 実測が境界の位置を裏づけ、キャッシュのヒット率が式の符号を変えます。 - Published: 2026年9月5日 - Author: Leo Kaka, Engineering - Tags: coding-agents, routing, cost - Canonical: https://pirouter.ai/ja/blog/agent-io-not-thinking --- 先に結論を。**コーディングエージェントが食っているトークンの大半は推論ではなく 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%](https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90) は、この委譲を 2 つの mode だけで組み、Java monorepo の 4 シナリオで bulk-read の平均削減が 約 90% だったと報告しています。**この 90% は彼らの環境・彼らの負荷での測定値**で、どの コードベースでも出る数字ではなく、当方の製品がこの比率を出すという話でもありません。 本稿は、その構成を特定のプラットフォームから外します。判定軸 3 本、設定として何を書くのか、 そして**他人の削減率ではなく自分の 4 つの数字から見積もる式**の順です。 ## エージェントのトークンは何に消えているのか——会話の層と探索の層は別の財布 同じ形は日本でも測られています。ペパボの [Claude Code のトークン削減を実測した](https://zenn.dev/pepabo/articles/claude-code-token-reduction-measured) は、意味検索 MCP サーバー semble の実ログを集計しています。累計 331 回の検索で、全ファイルを 読んだ場合の相当量が約 830 万トークン、semble 経由の送信量が約 50 万トークン、**削減率 93%** （同じく彼らの環境での読み取り）。手段は違いますが——Spotify は別モデルへの委譲、ペパボは 意味検索——削っている場所は同じです。 その「場所」を言語化しているのが [ナレッジグラフを活用して Claude Code のトークンを 10 分の 1 にする](https://zenn.dev/nocodesolutions/articles/19f0d415af42be) です。曰く、トークン消費には 2 つの層がある。会話の蓄積は `/clear` や `/compact`、CLAUDE.md の 整理で減らせるが、**エージェントがコードを調べる行為そのもの**は会話をいくら整理しても減らない。 同記事は Codebase-Memory（2026）を引いて、この探索が 1 回の問い合わせで数千トークンを消費し、 読んだ内容の大半は最終的な回答に使われないと書いています。 つまり**運用術と委譲は別の財布**です。前者は毎ターン固定で載る常駐コスト、後者は調査 1 回ごとの 変動コスト。片方をやれば済む、という関係ではありません。 ## 委譲してよい作業の判定軸は 3 本——出力の推定可能性・行番号の要否・ファイル横断の因果 Spotify の記事で一番使えるのは、実は削減率ではなく「What doesn't work」の節です。氏が挙げた 「できなかったこと」3 つを、肯定形に組み直します。 | 判定軸 | 委譲してよい側 | 委譲してはいけない側 | |---|---|---| | 出力の推定可能性 | ✓ 既存のパターンから出力が決まる（定型テスト、設定スタブ、型スタブ） | ✗ 何を出すかがその場の判断で決まる | | 行番号の要否 | ✓ 内容の理解が目的（要約、一覧、どこに何があるか） | ✗ その結果で編集する（worker の要約は行番号が信用できない） | | ファイル横断の因果 | ✓ 各ファイルの中で閉じている | ✗ 変更の意図が離れた場所の結果につながる | 3 行目が一番きつい制約です。氏のテストでは worker モデルが表層のパターンは見つけた一方、 **微妙な thread-safety のバグを見落とした**（Claude は正しいコンテキストを与えられたら数秒で 見つけた、とも）。だからルーティングからは debugging、アーキテクチャの判断、safety-critical な コードを明示的に除外しています。 この境界の位置は、別の実験からも裏づけが取れます。CodeRabbit が 2026-09-04 に公開した [GPT-6 Astra in code review](https://www.coderabbit.ai/blog/gpt-6-astra-code-review-evaluation) は、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 はすでにどこを読むべきか分かっているからです。閾値は環境変数で動かせます。 ```json { "env": { "SHUNT_MIN_LINES": "500" } } ``` **3 層目、呼び出し規約。** スキルファイルが、いつどう呼ぶかを書きます。フックがブロックした ときのメッセージがスキルを指し、スキルが呼び出し構文を示す。氏はこの重ね方を 「degrades gracefully」と説明しています——スキルの説明が読まれなくても、フックが高価な読みを 止めるからです。 一般名詞に置き換えると、**mode = ルーティング先の宣言、フック = 強制点、スキル = 呼び出し規約**。 固有なのは実装であって、構造ではありません。強制点をエージェント側のフックに置くか、 ルーティング層の規則に置くかは、そのうえでの設計の選択です。 ## どれだけ減るかは自分の 4 つの数字から出す——削減率を借りてはいけない 他人の 90% を自分の見積りに使わないでください。**決めるのは次の 4 つの数字です。** | 変数 | 意味 | どこから取るか | |---|---|---| | `T_read` | 委譲対象になる読み込みの量 | 使用ログの集計（ccusage 等）、MCP サーバーのログ | | `T_sum` | worker が返す要約の量 | 委譲を 1 回試して実測 | | `r` | 全体のうち委譲に回る割合 | 閾値を決めてから Read 呼び出しの分布で確認 | | `p_f − p_w` | frontier と worker の**実効**単価差 | 価格ページ ×（1 − キャッシュヒット率） | 節約はおおよそ `r × (T_read − T_sum) × (p_f − p_w)` に比例します。 **4 つ目が曲者です。** 生の価格差で計算すると、委譲の効果を過大に見積もります。arXiv の [Inference Economics of Enterprise Coding Agents](https://arxiv.org/abs/2607.13080)（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% 削減した](https://zenn.dev/dazoyee/articles/7febc743586813) の例では rules が 23.7k から 5.5k トークンへ落ちています。 **2. 閾値を決める。** 既定 350 行は出発点であって正解ではありません。自分の Read 呼び出しの 行数分布を見て、委譲の往復（10〜30 秒）が節約に見合う位置に置きます。狙い撃ちの読みは 通すこと——塞ぐと、編集のたびに委譲して要約を受け取り、行番号が合わずにやり直す、という 最悪の経路が生まれます。 **3. 読みから始める。** Spotify の `code-write` が reference を必須引数にしている理由も 書かれています——合わせる対象が無ければ、worker はどこにも合わないコードを生成する。 読みの委譲が安定してから、テストや設定スタブのような「隣に手本がある」生成に広げてください。 最後に目標の置き方を 1 つ。**削減率を目標にしないでください。** 目標にすべきは、frontier モデルに読ませたファイルのうち**答えに使われなかった行数**です。90% は出ることも出ないことも ある副産物ですが、この行数は誰の環境でも自分で数えられます。 --- ## Sources ### engineering.atspotify.com - [Portal by Spotify cut my Claude Code token usage by 90%](https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90) ### zenn.dev - [Claude Code のトークン削減を実測した](https://zenn.dev/pepabo/articles/claude-code-token-reduction-measured) - [ナレッジグラフを活用して Claude Code のトークンを 10 分の 1 にする](https://zenn.dev/nocodesolutions/articles/19f0d415af42be) - [rules ファイルを最適化してコンテキスト消費を 78% 削減した](https://zenn.dev/dazoyee/articles/7febc743586813) ### coderabbit.ai - [GPT-6 Astra in code review](https://www.coderabbit.ai/blog/gpt-6-astra-code-review-evaluation) ### arxiv.org - [Inference Economics of Enterprise Coding Agents](https://arxiv.org/abs/2607.13080)