Claude Code のトークン節約を3週間実測した結果｜1往復は4割安くなり週の費用は横ばい

Claude Code のトークン消費を3週間実測し、設定・サブエージェント・フックで手を打ちました。

本体の1往復あたりの費用は4割以上下がりましたが、週の費用は横ばいでした。

安くなった分だけ、サブエージェントを多く回すようになったためです。

この記事は、筆者の環境で何を測り、何を打ち、何が測れて何が測れなかったかの記録です。

結論：効いたのは文脈を200kで畳む設定とサブエージェントの軽量化

測れた効果の大きい順に2つです。

• 1. 自動 compact を200kにする：700k 超の往復が消え、本体の平均文脈は417kから134kになりました
• 2. サブエージェントを Sonnet と道具を絞った worker にする：開始時の文脈が72kから26kになり、サブの1往復は $0.106 から $0.034（5日間）になりました

設定は次の2行です（~/.claude/settings.json の抜粋）。

{
  "autoCompactWindow": 200000,
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-sonnet-5"
  }
}

worker は、~/.claude/agents/worker.md に道具を絞って定義したサブエージェントです。

---
name: worker
tools: Bash, Read, Write, Edit, Grep, Glob, WebSearch, WebFetch
model: sonnet
---

数字は次のとおりです。

• 本体の1往復あたりの費用：$0.28（9/9〜9/15）→ $0.10（9/23〜9/29）。単価を Opus 5 に揃えても $0.283 → $0.160 で −43%
• API の往復数：15,325 回 → 46,522 回（約3倍）。増えたのはほぼサブエージェント側
• 週の費用（API 定価換算）：$3,381 → $3,224 → $3,259 でほぼ横ばい

費用を減らしたいなら、往復の数そのものを見張る必要があります。

1往復が安くなると、同じ予算で回せる仕事が増え、結果として費用は下がりませんでした。

金額は API 定価換算で実際の支払いではない

筆者の契約は Claude Max 20x の月額固定で、従量課金の追加利用は無効です。

設定ファイル（~/.claude.json）の契約情報で確かめました。

この記事の金額は、トークンの使用量を Anthropic の公式の料金表に当てはめた換算値です。

月額そのものは、公式ページの表示から確かめられなかったため書きません。

集計のしかた

• 対象：~/.claude/projects 配下の会話ログ（jsonl）の assistant 行の usage。メッセージ ID ごとに最後の1件を採用して合算
• 日付は日本時間。週は 9/9〜9/15（施策の前）、9/16〜9/22、9/23〜9/29（施策の後。9/29 は途中まで）
• 「本体」はセッション本体、「サブ」は subagents/ 配下の会話
• 単価は公式の料金表（2026年9月29日に確認）。モデルごとに、入力・キャッシュ書き込み（1時間）・キャッシュ読み出し・出力を分けて計算
• 除外：単価が分からない synthetic 317件と opus-4-6 の14件
• 反映していない：fast モードの割増（使っているか不明）

用語だけ確認します。

cache_read は、会話を1往復進めるたびに、それまでの文脈をキャッシュから読み直す分です。

cache_write は、文脈をキャッシュに書き込む分です。

compact（会話の要約）をするたびに、要約後の文脈を書き直すので cache_write が発生します。

費用の中身：施策の前の週は約7割が cache_read だった

Claude Code は1往復ごとに、それまでの文脈を全部送り直します。

キャッシュのおかげで読み出しの単価は入力の1/10（Opus 5.5 は1/20）に下がりますが、往復の数と文脈の大きさに比例して積み上がります。

公式の料金表（Anthropic の Pricing）の値は次のとおりです。

1時間キャッシュの書き込みは、Opus 5 が $10 / MTok、Opus 5.5 が $8 / MTok、Sonnet 5 が $4 / MTok です。

筆者の会話ログには1時間キャッシュの書き込みが記録されていたので、この単価で計算しています。

施策の前の週では、費用の70%が cache_read でした。

施策の後は cache_read の割合が下がり、compact のたびに走る cache_write が40%、出力が29%を占めるようになっています。

文脈を畳んだ代償が、cache_write として出ています。

9/16 に最初に分析したときは「74%が cache_read」と出ましたが、これは後で書く古い単価表による値でした。

公式の料金表で計算し直すと、同じ週で70%です。

読み直しは投入量の226倍だった

9/16 に分析した直近1週間は、往復14,891回、平均の文脈313kでした。

ユーザーの入力・ツール結果など、新しく文脈に足したトークンは20.1Mでしたが、往復のたびに読み直されて、読み直しの合計は4.53Bトークンになりました。

足した量の226倍です（最大の1件は625倍）。

cache_read は「足したトークン × それ以降の往復数」の合計にほぼ比例します。

この式で再現した値は5,063M、実測は4,654Mで、誤差は9%でした。

文脈は一度入ると、そのセッションが続く限り毎往復ぶん課金され続けます。

文脈は伸びると戻らない：同じ往復数で読み直しが3.1倍違った

9/17 の前後で、ほぼ同じ往復数のセッションを1本ずつ比べました。

セッション A（9/17 の前・1,229往復）は文脈が最大967kまで育ち、読み直しの累計が536Mトークン。

セッション B（9/17 の後・1,302往復）は最大171kで、累計は173Mトークンでした。

往復数はほぼ同じなのに、3.1倍の差です。

文脈の上限は1,000k（100万）ですが、8/3〜9/7 の会話ログには、上限近くまで育ったセッションが複数ありました（最大998k）。

文脈の中身は自分の出力と思考が58.6%

文脈に入った中身を、延べコストで割ると、いちばん大きいのはアシスタント自身の出力と思考の58.6%でした。

次が Bash の結果の14.6%、Read の6.7%、ブラウザ系の6.0%です。

ツール結果より、自分の出力と思考のほうが文脈を太らせていました。

右の図は、9/16 時点で作った試算（シミュレーション）です。

Bash を2つずつまとめると −29%、3つずつで −37%、200k で畳むと −53%、まとめる＋200k で畳むで −64%。

これは試算で、実測ではありません。

この試算から、往復を減らすより先に、文脈を畳むことを最優先にしました。

打った手と設定：9/16〜9/24 の全記録

日付は、設定ファイルの更新時刻と会話ログで確かめています。

9/17：自動 compact を200kにする

settings.json に autoCompactWindow: 200000 を入れ、文脈が200kに達したら自動で compact する設定にしました。

同じ日に Vercel プラグインを止め、CLAUDE.md に節を足しています。

効果ははっきり出ました。

本体の平均文脈は417k（9/9〜9/15）から、165k（9/16〜9/22）、134k（9/23〜9/29）へ。

700k を超える往復はなくなりました。

代償は compact の回数で、本体とサブを合わせて週30回から610回、1,217回に増え、前の章で見たとおり cache_write が増えました。

9/24：サブエージェントの既定を Sonnet に

環境変数 CLAUDE_CODE_SUBAGENT_MODEL は、サブエージェントの既定モデルを決める設定です。

公式ドキュメント（Subagents）では、呼び出し時の指定、サブエージェント定義の model、この環境変数、本体のモデルの順に優先されます。

筆者は claude-sonnet-5 を指定しました。

Sonnet 5 は入力 $2 / MTok、出力 $10 / MTok で、Opus 5 の入力 $5 / MTok、出力 $25 / MTok の4割です。

サブエージェントの費用のうち Sonnet が占める割合は、9/9〜9/15 は0.3%、9/23〜9/29 は32%、9/25〜9/29 の5日間では78%でした。

品質への影響は測っていません。

9/24：道具を絞った worker を作る

サブエージェントは、本体とは別の文脈で動きます。

公式ドキュメントによると、そこにはシステムプロンプト、依頼文、CLAUDE.md、git status などが入ります。

筆者の環境では、汎用の general-purpose の開始時の文脈が72kあったため、道具を絞った軽い版を作りました。

worker は Sonnet で、道具は Bash・Read・Write・Edit・Grep・Glob・WebSearch・WebFetch だけ。

ブラウザと MCP の道具は持たせていません。

本文には「往復を少なく、文脈を小さく保つ」ルール（コマンドの束ね、grep と sed で必要な範囲だけ読む、出力を head や tail で絞る、調べた結果はメモに書き出す、ツール呼び出しは40回以内）を書きました。

開始時の文脈の中央値は、general-purpose が72k（201体）、worker が26k（182体）でした。

小さくなった内訳が道具の定義の分なのか、ほかの理由なのかは、分けて測っていません。

9/24：general-purpose を worker に自動で振り替える

worker を作っても、汎用の general-purpose を選ぶことは残ります。

そこで PreToolUse フックで、Agent ツールの呼び出しを、種類が general-purpose なら worker に書き換えるようにしました。

公式ドキュメント（Hooks）では、PreToolUse フックは updatedInput で、ツールの入力を書き換えられます。

依頼文にブラウザや MCP を思わせる語があるときは、振り替えません。

止めることも、確認を取ることもしません。

ただし、このフックが働いた記録は、ログに1行しか残っていません（9/24 の17:07）。

9/25〜9/29 に出した276体のうち158体が worker でしたが、多くは CLAUDE.md の指示で最初から worker が選ばれた可能性が高く、確かめていません。

フックそのものの効果は、取れなかったと書くのが正確です。

9/24：文脈が大きいと知らせるフック

UserPromptSubmit フックで、文脈が120kと160kを超えたら、/clear や /compact の判断を促す注意を Claude に注入します。

同じ段の通知は30分に1回まで。

セッション開始から3時間以上で、会話ログが15MB以上になったときは、長時間の扱いとして2時間に1回だけ知らせます。

効果は取れませんでした。

通知の後に、実際に畳んだかどうかを測っていないためです。

効果が取れなかった手：MCP の deny・Compact Instructions・Bash の束ね

• MCP のツール216件を deny：使わない Vercel（191件）と Notion（25件）のツールを permissions.deny に入れ、道具の一覧が文脈に入る分を減らす狙いでした。deny には Bash の4件（gh pr merge や force push）も入っており、合計は220件です。しかし本体の開始時の文脈は減っていません（後述）
• Compact Instructions：compact 直後でも文脈が約117kあり、20.7時間で93回 compact していたため、CLAUDE.md に「要約は4,000字以内」と書きました。compact 直後の文脈は再測定していません
• Bash の束ねなどの運用：前の章の試算（−29〜37%）だけで、前後の比較は取れません

サブエージェントの種類別：開始時の文脈と体数の入れ替わり

開始時の文脈の中央値は、general-purpose が72k（201体）、Explore が43k（8体）、researcher が32k（64体）、worker と video-researcher が26k、otome-writer が16k（27体）でした。

9/16〜9/23 に出した250体は、general-purpose が220、Explore が25でした。

9/25〜9/29 の276体は、worker が158、researcher が42、general-purpose が30、otome-writer が24、video-researcher が18と入れ替わっています。

測り方：audit.py の出力と金額のずれ

日々の点検には、自作の集計スクリプト audit.py（token-audit スキル）を使っています。

直近168時間の呼び出し数、compaction の回数、画像 Read の回数、重いセッションの上位、サブエージェントの種類別の開始時の文脈を出します。

この出力では、直近168時間の呼び出しが本体16,376回、サブ30,402回、compaction が本体703回、サブ524回でした。

画像 Read は本体564回、サブ2,270回。

一番重いセッションの最大の文脈は180kです。

単価表が古く金額が約3倍に出ていた

この記事を書くために公式の料金表と突き合わせたところ、audit.py の単価表が古いことが分かりました。

Opus を入力 $15 / MTok、Sonnet を $3 / MTok で固定し、出力は入力の5倍、cache_write は1.25倍の固定でした。

Opus の $15 / MTok は、公式の料金表では提供終了（retired）になった Opus 4.1 と Opus 4 の単価です。

audit.py が出した直近168時間の合計は約 $10,679 でしたが、公式の料金表で計算し直すと、9/23〜9/29 は $3,259。

約3倍の開きです。

1時間キャッシュの書き込みの単価も、固定値では反映されていませんでした。

手元のメモに残していた「週 $6.7k」などの金額も同じ前提で高めに出ていたため、この記事では旧い金額を使っていません。

自作の集計は、単価表を公式のページと照合してから信じる。

今回のいちばんの反省です。

なお、この記事の集計は最後の usage 行を採用しており、最初の行を採用する audit.py より出力トークンがやや多く出ます。

結果：文脈が小さくなり1往復が安くなった

文脈サイズ別の費用：200k を超える往復が消えた

本体の往復を、そのときの文脈の大きさで分けました。

施策の前（9/9〜9/15）は、費用の92%が200k を超える往復でした。

施策の後（9/23〜9/29）は、本体の16,119往復がすべて200k未満です。

100〜200k の往復が15,117回・$1,483 で、大半を占めています。

日別の平均文脈と compact の回数

日別に見ると、9/17 の設定のあとで平均の文脈が下がり、compact が増えていきます。

ピークは 9/24 の551回でした。

往復数は3倍で本体の1往復は −43%

本体の1往復は $0.28 から $0.10 に下がりました。

ただし 9/23 に、メインのモデルが Opus 5 から Opus 5.5 に変わっていたことが会話ログから分かりました。

Opus 5.5 は cache_read が $0.20 / MTok（Opus 5 は $0.50 / MTok）で、この差が混ざっています。

全トークンを Opus 5 の単価に揃えて計算し直すと、本体の1往復は $0.283（9/9〜9/15）、$0.137（9/16〜9/22）、$0.160（9/23〜9/29）。

単価を揃えても、前後で −43% です。

一方で 9/23〜9/29 のほうが 9/16〜9/22 より上がっている点は、次の章で書きます。

週の費用は横ばいでサブエージェントの往復が増えた

週の合計は $3,381、$3,224、$3,259 と、ほとんど動いていません。

中身は入れ替わっていて、本体が $2,805 → $1,736 → $1,607 と4割ほど減り、サブエージェントが $575 → $1,488 → $1,653 と約2.9倍になりました。

サブの1往復の費用は、$0.106（9/9〜9/15）、$0.054（9/23〜9/29）、$0.034（9/25〜9/29 の5日間）と下がっています。

Sonnet と worker の効果です。

それでも、サブの往復数が 5,404 回から 30,403 回へ5.6倍に増え、費用全体では相殺されました。

出力トークンも 13.0M から 52.8M へ4倍に増え、そのうち 31.4M がサブの分です。

単価を揃えると 9/23〜9/29 は増えている

すべてのトークンを Opus 5 の単価で計算すると、週の費用は $3,384、$3,227、$5,710 です。

9/23〜9/29 は +69% になります。

単価の面では Opus 5.5 と Sonnet に助けられて横ばいで済んでいますが、量のほうは確かに増えています。

5日間だけを見ると、日額の平均は 9/9〜9/15 の $483 から 9/25〜9/29 の $222 に下がっています（−54%）。

ただし往復数は1日 2,189 回から 4,688 回へ倍以上で、仕事の量が違います。

施策の効果の証拠にはなりません。

筆者の運用としては、安く軽くなったサブエージェントに、以前なら本体でやっていた調べものや下書きを出す場面が増えました。

仕事の総量そのものが増えたのか、出し方が変わっただけなのかは、切り分けていません。

Max プランの週の利用枠への影響も見ていません。

本体の開始時の文脈は減っていなかった

本体セッションの最初の往復の文脈は、9/9〜9/15 が中央値32k（最小29k）、9/16〜9/23 が97k、9/25〜9/29 が90k（最小60k）でした。

MCP を deny しても、Compact Instructions を書いても、開始時の文脈は減っていません。

増えた原因は分かっていません。

compact 後の続きや再開が混ざっている可能性はありますが、確かめていません。

まとめと次にやること

効いた設定は冒頭の「結論」に書いたとおりです。

ほかに、9/23 に Opus 5.5 へ切り替わって cache_read の単価が下がり、費用の減少に混ざっています。

次にやることは4つです。

• 本体の開始時の文脈が32kから90kに増えた原因を調べる（compact 後の続きの混入か、固定部分の増加か）
• 施策を1つずつ入れて測り直し、単独の効果を分ける（今回は同時に入れたため分けられなかった）
• サブエージェントを Sonnet にした影響を、やり直しの回数などで測る
• 自作の集計の単価表を、公式の料金表と定期的に照合する

費用が横ばいだったことは、施策が無駄だったという意味ではありません。

1往復が安くなり、文脈が小さく保たれ、その分だけ多くの仕事をサブエージェントに任せられました。

一方で、費用を減らしたいなら、往復の数そのものを見張る必要があります。

※料金・無料枠・商用利用の条件は2026年9月29日時点の情報です。

最新の内容は公式サイトでご確認ください。