Claude Code のトークン、どこに消えてる？

はじめに

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

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

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

筆者もこれまで「なんとなく /clear した方がいいらしい」レベルの理解で運用していた部分があったので、この機会に要点を日本語でまとめつつ、実際に筆者がやっている運用と照らし合わせてみます。

結論から言うと、覚えるべきは「キャッシュを壊さない」「コンテキストに余計なものを入れない」の2つだけです。

TL;DR

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

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

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

価格を決める3つの要素

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

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

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

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

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

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

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

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

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

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

公式が推奨するテクニック

コマンド編

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

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

つまり「直近のやりとりが迷走したから消したい」なら /rewind、「この後1時間以上離席する」なら /compact です。キャッシュの TTL（サブスクリプションでは1時間）が切れる前に圧縮しておけば、要約処理自体はキャッシュ読み取り価格で安く済みます。

環境変数編

環境変数	効果
`MAX_THINKING_TOKENS=0`	思考トークンを無効化（単純作業向け）
`BASH_MAX_OUTPUT_LENGTH`	コマンド出力のプレビュー上限を制御
`ENABLE_PROMPT_CACHING_1H=1`	API キー利用時のキャッシュ TTL を5分→1時間に延長

API キー利用の方は3つ目が重要です。サブスクリプションだと TTL 1時間がデフォルトですが、API キーだと5分しかありません。5分考え込んでから次のメッセージを送ると、もうキャッシュは消えています。

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 に読ませていたわけで、ちょっと反省しています。

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

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

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

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

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

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

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

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

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

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

反省したこと

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

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

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

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

③ /context での定期点検

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

所感

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

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 の注意力も散らかります。トークン効率化は回答品質の改善でもある、というのが筆者の実感です。

まとめ

トークンコストは「モデル × トークン種別 × キャッシュ」で決まる。出力は入力の約5倍、キャッシュ読み取りは0.1倍
キャッシュを壊さない: モデルと effort はセッション開始時に固定。休憩前は /compact（TTL はサブスク1時間 / API キー5分）
コンテキストに積まない: /clear をこまめに、quiet フラグを活用、大出力はサブエージェントへ
直近ターンを消すだけなら /compact より /rewind（キャッシュ保持でほぼタダ）
毎日使うコマンドは quiet フラグ込みで CLAUDE.md に書いておく
/context で初期ロードを定期点検する

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

ではまた！