Claude Code のトークン、どこに消えてる？節約の基本は2つだけ

はじめに

朝から Claude Code でずっと作業して、夕方に利用上限のメッセージ。でも振り返ってみると、終わったのは小さめのタスクが2つだけ。「今日のトークン、一体どこに消えたんだ…」となったこと、ありませんか？

筆者はあります。長く続けたセッションほど1回のやりとりが重く、遅く、高くつくようになっていく。実はこれ、気のせいではなく仕組みで説明できる現象です。

この記事は、Claude Code の利用上限に思ったより早く届いてしまう人が、トークンがどこで消えているかを特定して、そこを削るまでの手順をまとめたものです。

結論から言うと、覚えることは2つだけです。

キャッシュを壊さない — モデルと effort はセッション開始時に決めて途中で変えない。休憩の前に /compact
コンテキストに余計なものを積まない — 無関係なタスクの間は /clear。出力の多いコマンドは quiet フラグかサブエージェントへ

元ネタは、2026年8月14日に Anthropic 公式ブログで公開された Maximizing the value of your Claude Code sessions です。セッションのトークンがどこで消費されて、どうすれば無駄なく使えるかを解説した、かなり実用的な内容でした。

筆者もこれまで「なんとなく /clear した方がいいらしい」レベルの理解で運用していた部分があったので、要点を日本語でまとめつつ、実際にやっている運用と照らし合わせてみます。公式の記述と筆者の運用は節を分けて書いているので、どこまでが公式の推奨でどこからが筆者の話かは読み分けられるはずです。

2026-10-02 追記: 公式ドキュメントコストを効果的に管理するを読み直して、「どこに消えているかを測る」節と /compact の引数指定を追記し、MAX_THINKING_TOKENS の記述を現行の仕様に合わせて訂正しました。

TL;DR

公式の推奨をぎゅっと圧縮するとこうなります：

削る前に /usage と /context でどこに消えているかを測る
無関係なタスクの間は /clear する
モデルと effort はセッション開始時に決めて、途中で変えない
ファイルは名前で説明せず @-mention で直接添付する
出力が多いコマンドには quiet フラグを付けるか、サブエージェントに逃がす
休憩前は /compact（キャッシュの TTL が切れる前に）

まず「どこに消えているか」を測る

節約の話に入る前に、測る手段を押さえておきます。感覚で削っても、効いているのか分からないので。

`/usage` でセッションの内訳とキャッシュ命中率を見る

公式ドキュメントによると、/usage のセッションブロックには現在のセッションのトークン使用統計が出ます。モデルごとの入力・出力・キャッシュ読み取り・キャッシュ書き込みが並ぶので、「出力が重いのか、コンテキストが重いのか」がまず切り分けられます。

ここで見たいのが Prompt cache (main) の行です。ドキュメントに載っている例がこれ：

Prompt cache (main):   14 requests · 91% of input tokens from cache · 2 misses (last 6m 10s ago, 310.2k tokens re-cached) · 1 expected rebuild (compaction or tool-result clearing) · warm (1h TTL, last activity 40s ago)

読み方は公式ドキュメントの説明どおりで、

misses: キャッシュが既に持っていた内容を再処理してしまったリクエスト。likely cause: tool definitions changed のように原因の候補まで出ることがあります
expected rebuild: /compact や古いツール結果のクリアによる、想定内の再構築
warm / cold: キャッシュされた先頭部分が TTL 内にあるかどうか

後述の「キャッシュを壊さない」が効いているかは、この行の命中率で確認できます。サブスクリプションプランの場合、セッションのドル表示は請求とは関係ない数字ですが、キャッシュ命中率とトークン内訳はプランに関係なく読めます。

さらに Pro / Max / Team / Enterprise では、プラン制限に対する内訳も表示されます。公式ドキュメントによると、スキル・サブエージェント・プラグイン・個別の MCP サーバーに紐づく使用量が合計に対する割合で出て、「長いコンテキスト」「キャッシュミス」といった挙動は最近の使用量の 10% 以上を占めるとフラグが付きます。d / w で直近 24 時間と 7 日間を切り替えられます。

「どこに消えてる？」にいちばん直接答えてくれるのは、ここです。

`/context` で初期ロードを点検する

まっさらなセッションで /context を実行すると、MCP ツールやスキルなどの初期ロード内容が見えます。筆者の環境は MCP サーバーを盛りがちなので、点検したら使っていないツール定義がそれなりに場所を取っていました。心当たりのある方は一度見てみてください。

MCP について公式ドキュメントに補足があって、ツール定義は既定で遅延ロードされ、Claude が実際にそのツールを使うまではツール名とサーバーの指示だけがコンテキストに入るそうです。それでもサーバーを増やせば増えるので、/mcp で使っていないものを無効化すること、gh や aws のように CLI がある領域は MCP サーバーより CLI に任せる方がコンテキスト効率が良いことが勧められています。

筆者の /context で場所を取っていたのも、まさに使っていないサーバーの定義でした。逆に、ブラウザ上の UI フィードバックを Claude Code に渡す Agentation のように CLI では代替できないものは残す価値があるので、この「CLI があるなら CLI」という線引きは分かりやすいです。

初期ロードには CLAUDE.md も含まれます。公式ドキュメントは CLAUDE.md を 200 行以下に保つことを目標に挙げ、特定のワークフロー向けの詳しい指示は呼ばれたときだけ読まれる skills 側に移すことを勧めています。どこまで削れるかは CLAUDE.md、太らせすぎてない？で扱っています。

なお、コンテキスト使用率をステータスラインに出して常時監視する方法も公式ドキュメントで案内されています。筆者はまだ設定していないので、効果の実感はこれからです。

なぜトークンが「思ったより」消えるのか

価格を決める3つの要素

公式記事によると、トークンのコストは3つの要素で決まります。

要素	内容
モデル	大きいモデルほど入力・出力ともに高い
トークン種別	出力トークンは入力の約5倍高い（逐次デコードのため）
プロンプトキャッシュ	キャッシュ読み取りは入力価格の0.1倍、書き込みは最大2倍

この中で一番効いてくるのがプロンプトキャッシュです。

プロンプトキャッシュの仕組み

仕組みはシンプルで、リクエストの先頭部分が前回と完全に一致していれば、サーバーが前回の状態を再利用してくれます。一致している部分は 0.1 倍の価格で読み取られ、続きの部分だけが新規処理されます。

逆に言うと、先頭部分が変わった瞬間、キャッシュは全部無効です。会話の途中で /model や /effort を変えると、それまでの全コンテキストを通常価格（書き込みは最大2倍）で再構築することになります。

これが「モデルと effort はセッション開始時に決めろ」の理由です。地味ですが、これを知っているかどうかで長いセッションのコストがけっこう変わります。

コンテキストは「積もる」

もうひとつの重要ポイントは、Claude が一度読んだものはセッションが続く限り残り続けることです。

ファイルの中身、コマンドの出力、検索結果。全部です。キャッシュされるとはいえ、ターン40では過去39ターン分の全コンテキストを毎回引き連れて処理しています。長いセッションほど1ターンあたりのコストが重くなるのはこのためです。

公式ドキュメントは、長いセッションで使用量が増える理由として、この「長いコンテキスト」と「キャッシュミス」に加えて、スケジュール済みタスク、他セッションからのメッセージ、サブエージェントやエージェントチームの分も挙げています。どれもセッションがアイドルでも毎回フルのコンテキストを送るのが共通点です。開いたまま放置しているセッションがある人は、ここも疑いどころです。

節約テクニック① キャッシュを壊さない

モデルと effort はセッション開始時に固定する

前述のとおり、途中変更は全コンテキストの再プリフィルを招きます。難しい設計やデバッグで effort を上げたいなら、/clear して新しいセッションで始めるのが安いです。

TTL が切れる前に `/compact`

キャッシュには有効期間（TTL）があります。公式ドキュメントの現行の説明では、

使い方	キャッシュ TTL
サブスクリプション	1 時間
サブスクリプション（使用クレジットを使用中）	5 分
API キー・クラウドプロバイダー	既定 5 分

となっています。TTL より長く離席すると、復帰後の最初のメッセージはキャッシュをミスして全コンテキストを再処理します。1時間以上離れると分かっているなら、離れる前に /compact しておけば、要約処理自体はキャッシュ読み取り価格で安く済みます。

API キー利用の方は、環境変数でキャッシュ TTL を延長する手もあります。

環境変数	効果
`BASH_MAX_OUTPUT_LENGTH`	コマンド出力のプレビュー上限を制御
`ENABLE_PROMPT_CACHING_1H=1`	API キー利用時のキャッシュ TTL を5分→1時間に延長

直近のターンを捨てるだけなら `/rewind`

/rewind は末尾のターンを切り落とすだけなので、それ以前のキャッシュはそのまま生きています。迷走したやりとりを消すのに /compact を使うのは、もったいない選択です。

節約テクニック② コンテキストに積まない

無関係なタスクの間は `/clear`

これが一番効きます。公式ドキュメントも「古いコンテキストは後続のすべてのメッセージでトークンを無駄にする」と書いていて、/clear 自体にコストはかかりません。/clear の前に /rename でセッションに名前を付けておけば、後から /resume で戻れます。

quiet フラグを既定にする

コマンド出力もコンテキストに積もるので、公式は quiet フラグの活用を勧めています。例として挙がっているのはこれ：

npx vitest run <file> --reporter=dot

テストの詳細ログではなくドット表示だけにすることで、コンテキストに入る量を最小化するわけです。そして公式いわく、毎日使う2〜3個のコマンドは quiet フラグ込みで CLAUDE.md に書いておけとのこと。これは今日からできるやつですね。

実際、筆者もこれを機に CLAUDE.md へ quiet フラグ込みで3つ登録しました：

# テストはドット表示。落ちたときだけ詳細が出る
npx vitest run <file> --reporter=dot

# lint は warning を抑えて error だけ（その名も --quiet）
npx eslint . --quiet

# git は要約表示を既定に。全文 diff は必要なファイルだけ見る
git log --oneline -20
git diff --stat

どれも出力が数行に収まるので、何度実行してもコンテキストがほぼ汚れません。逆に言うと、これまで毎回テストのフルログを Claude に読ませていたわけで、ちょっと反省しています。

なお、quiet フラグでは足りない場合に、PreToolUse hook でコマンド出力を Claude が見る前にフィルタする方法も公式ドキュメントに載っています。10,000 行のログを読ませる代わりに hook 側で ERROR を grep しておく、という発想です。筆者はまだ試していないので、効果は紹介までにとどめます。

大きな出力はサブエージェントへ

出力がどうしても大きくなる作業（大量のログ解析など）は、サブエージェントに逃がすのが定石です。サブエージェントは自分専用のコンテキストウィンドウを持ち、親セッションに返ってくるのは最終的な回答だけ。ただしファイルの再読み込みが発生するというトレードオフも率直に書かれています。万能ではないです。

単純作業では思考を軽くする

拡張思考は既定で有効で、思考トークンは出力トークンとして課金されます。タイポ修正やリネームのような作業に深い推論は要らないので、ここは軽くしたいところ。

ただしこの操作方法は、記事公開時点から変わっています。公開当時は「MAX_THINKING_TOKENS=0 で思考トークンを無効化」と書いていましたが、現行の公式ドキュメントでは、

MAX_THINKING_TOKENS で予算を下げられるのは固定思考予算を持つモデルだけ（例: MAX_THINKING_TOKENS=8000）
適応推論モデルはゼロ以外の予算を無視するので、代わりに努力レベル（/effort）を使う
Opus 5.5 / Sonnet 5.5 / Fable では思考をオフにできない

となっています。つまり今は /effort で下げるのが正解です。ここは訂正しておきます。

`/clear`・`/compact`・`/rewind` の使い分け

コマンドが似ていて混ざりやすいので、表にしておきます。

コマンド	使いどころ
`/clear`	新しいタスクを始めるとき。コンテキストをリセット。それ自体のコストはかからない
`/context`	まっさらなセッションで実行して、初期ロード内容を点検
`/usage`	今のセッションの内訳とキャッシュ命中率を確認
`/compact`	長い休憩の前に。会話を要約に置き換える
`/rewind`	直近のターンだけ捨てたいとき。キャッシュが保持されるので実質タダ
`/rename`	`/clear` する前にセッションに名前を付けて後から探せるように

/compact と /rewind の使い分けは筆者も曖昧だったのですが、公式の説明で腑に落ちました。/rewind は末尾のターンを切り落とすだけなので、それ以前のキャッシュはそのまま生きています。一方 /compact は会話全体を短い要約に置き換えるので、キャッシュの再構築コストがかかります。

つまり「直近のやりとりが迷走したから消したい」なら /rewind、「この後1時間以上離席する」なら /compact です。そして継続性が要らないなら /clear です。公式ドキュメントは「/compact は要約するコンテキストを読み込むので、大きなコンテキストの圧縮それ自体が大きなリクエストになる」と書いていて、新しく始めればいいだけの場面で /compact を選ぶ理由はありません。

`/compact` には「何を残すか」を渡せる

これは筆者が知らなかった機能です。公式ドキュメントによると、/compact に引数を付けると、要約中に何を保持するかを指示できます。

/compact Focus on code samples and API usage

さらに、プロジェクトルートの CLAUDE.md に圧縮時の方針を書いておくこともできます。

# Compact instructions

When you are using compact, please focus on test output and code changes

毎回同じことを打つより、CLAUDE.md に寄せた方が楽そうです。

auto-compact は「間に合わなかったとき」の保険

コンテキストが上限に近づくと、Claude Code が古い履歴を自動で要約して領域を解放します（auto-compact）。公式ドキュメントはこの警告を使用制限とは別物だと明記しています。

ただ、作業の途中で発動されると文脈の切れ方を選べません。区切りのいいところで自分から /compact する方が、残すものをコントロールできます。

筆者の運用と照らし合わせてみる

ここからは、筆者が実際にやっている運用を公式推奨と突き合わせてみます。

やっていて正解だったこと

① 無関係なタスク間の /clear

筆者はグローバルの CLAUDE.md に「無関係なタスクの間は /clear する」と書いて運用しています。ブログ執筆の後にアプリのデバッグを始めるとき、前のコンテキストは邪魔なだけなんですよね。公式のど真ん中の推奨でした。

② 探索系タスクのサブエージェント委譲

「このリポジトリで○○ってどこで定義されてる？」みたいな探索は、サブエージェントに投げてメインのコンテキストを汚さないようにしています。検索の試行錯誤（Glob して Grep して読んで違った、の繰り返し）が全部メインセッションに積もると、本題に使えるコンテキストが目減りしていくので。

③ 軽い作業は軽いモデルへ

定型変換やファイル整理みたいな作業は Haiku などの軽いモデルのサブエージェントに委譲しています。公式も「モデルを Haiku に指定した軽い反復作業」をサブエージェントの適所として挙げていました。

反省したこと

① effort をセッション単位で決める「理由」を知らなかった

筆者は元々「難しい設計やデバッグのときはセッション単位で effort を上げる」という運用にしていたのですが、正直に言うと、なんとなくそうしていただけでした。今回、途中変更が全コンテキストの再プリフィル（最大2倍価格）を引き起こすと知って、初めて「セッション単位」が正解だった理由が分かりました。結果オーライですが、知らないって怖い。

② /rewind をほぼ使っていなかった

迷走したやりとりを消すのにも /compact を使いがちだったのですが、末尾を捨てるだけなら /rewind の方が圧倒的に安い。使い分けの基準ができたのは収穫でした。

③ /compact に引数を渡せることを知らなかった

上に書いたとおりです。「要約で大事な部分が落ちた」と感じたことは何度かあったので、残したいものを指定できると知っていれば違ったはずです。CLAUDE.md 側に書く形は、これから運用してみます。

所感

この記事でいちばん好きなのは、この一文です。

Being efficient with tokens doesn't mean using fewer of them overall. It means making sure the ones you do use go towards the thing you actually asked for.

（トークン効率とは、使う量を減らすことではない。使ったトークンが、本当に頼みたかったことに向かうようにすることだ）

ケチる話ではなく、同じ量のトークンでどれだけ前に進めるかという話なんですよね。コンテキストに無駄なログが山積みのセッションは、コストが高いだけでなく、Claude の注意力も散らかります。トークン効率化は回答品質の改善でもある、というのが筆者の実感です。

そしてもうひとつ思ったのは、節約の話は測る手段とセットでないと続かないということ。/usage のキャッシュ命中率みたいな分かりやすい数字があると、「さっきの /model 切り替え、もったいなかったな」が後から見えます。見えると直せます。

まとめ

削る前に測る。/usage でセッションの内訳とキャッシュ命中率、/context で初期ロードを点検する
トークンコストは「モデル × トークン種別 × キャッシュ」で決まる。出力は入力の約5倍、キャッシュ読み取りは0.1倍
キャッシュを壊さない: モデルと effort はセッション開始時に固定。休憩前は /compact（TTL はサブスク1時間 / 使用クレジット中・API キーは5分）
コンテキストに積まない: /clear をこまめに、quiet フラグを活用、大出力はサブエージェントへ
使い分けは、継続性が要らないなら /clear、直近ターンだけなら /rewind、離席前なら /compact
/compact は引数や CLAUDE.md の # Compact instructions で「何を残すか」を指定できる
単純作業の思考を軽くするのは今は /effort。MAX_THINKING_TOKENS は固定思考予算のモデル向け
毎日使うコマンドは quiet フラグ込みで CLAUDE.md に書いておく

公式記事と公式ドキュメントは具体例も豊富なので、原文もぜひ読んでみてください。

ではまた！