/compact を実行したのに、トークンの費用が下がるどころか上がった——そんな経験はないでしょうか。コンテキストを圧縮して節約するはずの操作で、なぜか請求が膨らむ。直感に反するこの現象には、はっきりした仕組みがあります。

この記事では、(1) なぜ「圧縮したのに高くなる」が起きるのか、(2) 自分がそれを踏んでいるかを ccusage で確かめる方法、(3) 当面の回避策、を整理します。

きっかけは GitHub の起票 #70459(2026-06-23・v2.1.186)です。報告の中身そのものは筆者が踏んだわけではないので伝聞として扱い、検知と回避の方法は手元の運用の知識として書きます。

症状——「圧縮したのに、むしろ高い」

/compact(または自動圧縮)が走ったあとに、次の2つが同時に起きます。

コンテキストがほとんど減っていない。圧縮したはずなのに、トークンの使用量が高いまま。
その状態で、トークンの費用が跳ね上がる(体感で十数倍〜20倍)。

「圧縮=節約」と思っていると、原因がまったく見えません。エラーも警告も出ないので、月末の請求やクレジットの減りで初めて気づきます。

なぜ起きるか——2つの不具合が掛け算で効く

起票 #70459 の報告によると、自動圧縮の経路に2つの別々の不具合が重なっています。

不具合1: 古い事前計算を消費して、圧縮が浅くなる

Claude Code は、圧縮をなめらかにするために、バックグラウンドで「事前計算(precompute)」の要約をあらかじめ作っておきます。ところが報告では、/compact が約47分前に作られた古い事前計算を消費してしまったとされています。

古い事前計算は、その時点までの会話しか要約していません。だから、それ以降に積み上がった約20万トークン分のメッセージがそのまま(verbatim)残り、圧縮がほとんど効きません。事前計算が古くなっていないか、末尾がどれだけ伸びたか、を確認して作り直す仕組みがない、というのが報告の指摘です。

不具合2: 肥大した先頭部分が、読み込みでなく「書き込み」で課金される

ここが費用の跳ね上がりの核心です。プロンプトのキャッシュには2つのレートがあります。

キャッシュの読み込み(cache read): 安い($0.50/MTok 程度)
キャッシュの作成(cache creation / write): 高い($10/MTok 程度・約20倍)

通常は、変わらない先頭部分はキャッシュに載って「読み込み」で済みます。ところが報告では、リクエストのキャッシュの区切り(breakpoint)が末尾の毎回変わるメッセージに固定されているため、肥大した先頭部分(約19.6万トークン)が再利用されず、毎回「作成」レートで取り込み直されるとされています。読み込みなら安く済むものが、20倍のレートで、しかも圧縮が走るたびに繰り返されます。

不具合1でコンテキストが減らず、不具合2でその減らない先頭部分が高いレートで課金され続ける。掛け算で費用が膨らむ、という構図です。

自分が踏んでいるかを確かめる——`ccusage` でレートの比率を見る

ここからは手元の運用の知識として書きます。この現象は、キャッシュの「作成」と「読み込み」の比率を見れば、推測なしに分かります。

ccusage(npx で動くトークンの利用状況の集計ツール)で、直近のセッションの cache_creation と cache_read のトークンを確認します。

npx ccusage@latest

健全な運用では、cache_read が大半(キャッシュのヒット率が7〜9割)で、cache_creation は小さいはずです。もし、圧縮の前後で cache_creation の比率が急に上がり、cache_read を上回るようなら、この不具合を踏んでいる疑いが濃厚です。とくに「/compact を押した直後の数ターン」で cache_creation が膨らむなら、ほぼこれです。

月に一度、過去30日の cache_creation と cache_read の比率を取り、cache_read の割合が5割を切っていたら、原因を疑う習慣をつけておくと、請求で驚かずに済みます。

当面の回避策

仕組み自体は Claude Code の側の不具合なので、利用者の側でできるのは「踏みにくくする」「踏んだら早く抜ける」ことです。

自動圧縮を頻発させる設定を見直す。 報告の環境では、次の2つの設定が自動圧縮と事前計算を早めに・頻繁に発火させていました。
```
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1",   // 窓を200kに制限
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "80"  // 80%で自動圧縮
```
窓を小さくし、しきい値を下げるほど、自動圧縮と事前計算が何度も走り、古い事前計算を踏む機会が増えます。費用が気になるなら、しきい値を上げる(発火を減らす)か、これらの上書きを外して様子を見ます。
圧縮が浅いと気づいたら、/compact を重ねず /clear で切る。 圧縮しても使用量が減っていないなら、同じセッションで /compact を繰り返しても、古い事前計算を踏み続けるだけのことがあります。大事な文脈を手元のメモに退避してから /clear で一度切るほうが、肥大した先頭部分を高いレートで取り込み続けるより安く済みます。
長いセッションを避け、こまめに区切る。 そもそも約20万トークンまで膨らむ前に、区切りのよいところでセッションを分ければ、深い圧縮に頼る場面自体が減ります。

まとめ

/compact で費用が上がるのは、(1) 古い事前計算で圧縮が浅くなり、(2) 減らない先頭部分が読み込みでなく作成レート(約20倍)で課金される、という2つの不具合の掛け算。
自分が踏んでいるかは ccusage の cache_creation と cache_read の比率で分かる。圧縮の直後に cache_creation が膨らむのが兆候。
当面は、自動圧縮を頻発させる設定を見直し、浅い圧縮に気づいたら /compact を重ねず /clear で切る。

筆者は、Claude Code を800時間以上ほぼ無人で走らせるなかで、こうした「気づかないうちにトークンの費用が膨らむ」型の落とし穴——キャッシュの読み込み率の暴落、副の作業者の費用の暴走、自動圧縮まわりの無駄——を実機のログから一つずつ切り分けてきました。どこで費用が膨らんでいるかを実機のログから特定し、設定と文脈の管理とワークフローの設計で消費を半分まで減らす全手順は、Claude Code のトークン消費を半分にする本（¥2,500・第1章まで無料の試し読み）に26章でまとめています。この記事で触れたキャッシュの作成と読み込みの比率の話も、章の一つとして実データつきで扱っています。

無料で土台を整えたい方は、危ない操作や費用の暴走を実行の前で止めるフック群を cc-safe-setup（GitHub・MIT）に公開しています。