Claude Codeのトークン消費が異常に速い──3つの原因とソースコード流出が裏付けたキャッシュバグ¶

対象 / ポイント

対象: Claude Codeで使用量の異常消費を経験している、または今後のリスクを把握しておきたい開発者・チームリード

ポイント:

「2倍キャンペーン終了」「ピーク時の意図的制限」「プロンプトキャッシュのバグ」の3要因が同時に重なっている
キャッシュバグはコスト10〜20倍膨張を引き起こし、Max $100/月プランでも実質1〜2時間で枯渇する
3/31のソースコード流出で、バグの技術的原因（attestationシステムとanti-distillation）が裏付けられた

何が起きているのか¶

2026年3月23日ごろから、Claude Codeのトークン消費速度がおかしいという報告がReddit・GitHub・Discordで一斉に上がり始めた。

症状は深刻だ。Max 5x（ $100/月）のユーザーが、以前は8時間使えていた同じワークロードを1時間で使い切る。Max 20x（$ 200/月）でも、1プロンプトで使用量が21%から100%に跳ね上がったという報告がある¹。Proプラン（$20/月）では3プロンプト程度でリミットに到達するケースも報告されている。

Anthropicはこの状況を認めている。「リミットが予想よりはるかに速く消費されている。チームの最優先事項として調査中」と公式に発言した²。

ただし、この問題は単一の原因ではない。3つの異なる要因が同じ週に重なったことで、体感上の影響が増幅された。

時系列で整理する¶

いつ、何が起きたのか？

日付	出来事
3/13	オフピーク2倍キャンペーン開始（全プラン対象）
3/23	トークン異常消費の報告が急増
3/26	Anthropicがピーク時リミット制限を公式発表
3/28	2倍キャンペーン終了
3/31	npm経由でソースコード流出。キャッシュバグの存在が裏付けられる

3つの要因を順番に見ていく。

要因1：2倍キャンペーンの終了¶

3月13日〜28日、Anthropicは「Spring Break」プロモーションとして、オフピーク時間帯（平日ET 8am-2pm以外＋週末終日）に全プランの使用量を2倍に引き上げた³。

このキャンペーンには背景がある。2月末のOpenAI・ペンタゴン契約騒動でChatGPTからの大量移行が起き、3月初旬にClaude がApp Storeの無料アプリ1位を初めて獲得した。急増したユーザーをつなぎとめつつ、ピーク外のGPU稼働率を上げる狙いだった。

問題は終了後だ。2週間にわたって2倍の容量に慣れたユーザーが、3月29日から通常リミットに戻った。2倍が「通常」の基準線になっていたため、元に戻っただけで「制限が厳しくなった」という認知のズレが生じた⁴。

これ自体はバグではなく、予告どおりの仕様変更だ。ただし、以下の2つの要因と時期が完全に重なったことが混乱を深くした。

要因2：ピーク時の意図的な制限強化¶

3月26日、Anthropicエンジニアの Thariq Shihipar が公式に発表した内容はこうだ⁵。

平日PT 5am-11am（ET 8am-2pm / JST 21時-翌3時）のピーク時間帯に、5時間セッションリミットの消費速度を速くする。週間の総リミットは変わらない。

つまり、同じプロンプトでも朝の時間帯なら消費量が大きくなる。約7%のユーザーが影響を受けるとAnthropicは推定している。

日本のユーザーにとっては、PT 5am-11amはJST 21時〜翌3時にあたる（3月はサマータイム適用でPDT=UTC-7）。深夜作業をしない限り直接の影響は小さい。ただし、グローバルチームで作業している場合や、自動化パイプラインを常時実行している場合は注意が必要だ。

要因3：プロンプトキャッシュのバグ（核心）¶

なぜ同じワークロードでトークン消費が10〜20倍になるのか？ 3つの要因のうち、これが最もインパクトが大きい。

キャッシュの仕組み¶

Claude Codeは会話のたびにAPIにリクエストを送る。送られるデータは「システムプロンプト＋ツール定義＋これまでの会話履歴＋今回のメッセージ」の全量だ。会話が長くなれば20万トークンを超えることもある。

毎回20万トークンをフル処理していたら、コストが爆発する。そこで「プロンプトキャッシュ」が効く。前回と同じ部分はキャッシュから読み込み（コスト1/10）、新しく増えた部分だけを処理する仕組みだ⁶。

以下の図で、正常時とバグ発生時の違いを示す。

graph LR
    subgraph normal["正常時 - キャッシュが効いている"]
        A1["Turn 1"] -->|"全量を初回処理"| B1["cache_create 大"]
        B1 --> C1["$0.15"]
        A2["Turn 2"] -->|"前回分をキャッシュから読む"| B2["cache_read 大"]
        B2 --> C2["$0.05"]
        A3["Turn 3"] -->|"さらに蓄積をキャッシュ活用"| B3["cache_read さらに大"]
        B3 --> C3["$0.02"]
    end

    subgraph bug["バグ発生時 - キャッシュが毎回壊れる"]
        X1["Turn 1"] -->|"全量を初回処理"| Y1["cache_create 大"]
        Y1 --> Z1["$0.15"]
        X2["Turn 2"] -->|"キャッシュ無効で再処理"| Y2["cache_create 大"]
        Y2 --> Z2["$0.15"]
        X3["Turn 3"] -->|"履歴増加分も全量処理"| Y3["cache_create さらに大"]
        Y3 --> Z3["$0.40"]
    end

正常時は「初回だけ高く、あとはどんどん安くなる」。バグ発生時は「毎回が初回扱い。しかも会話が長くなるほど高くなる」。この差がコスト10〜20倍の正体だ。

Claude Codeチームはキャッシュヒット率をSEV（重大障害）レベルの指標として監視しているとされている。製品の経済性そのものがキャッシュ前提で成り立っている。

実データで見る「壊れ方」¶

GitHub Issue #34629に、同一ワークロードでバージョンだけを変えた定量的な再現報告がある⁷。

v2.1.68（正常動作）のログ：

ターン	cache_read	cache_create	コスト
1	13,997	22,946	$0.15
2	32,849	4,636	$0.05
3	36,846	879	$0.03
4	37,295	802	$0.02

cache_read（キャッシュから安く読めたトークン数）がターンごとに増えていく。逆にcache_create（新たに処理が必要だったトークン数）は急減する。Turn 4では新規処理はわずか802トークンで、コストは$0.02まで下がる。

v2.1.76（バグあり）では、この構造が完全に崩壊する。 cache_readはシステムプロンプト分の約14,500トークンで固定されたまま成長しない。会話履歴が毎ターン「新規データ」として処理され続ける。ターンが進むほど会話が長くなる分、cache_createは増え続け、コストは $0.04→$ 0.40と膨張する。

このバグはモデルに依存しない。同じOpus 4.6でもv2.1.68なら正常、v2.1.76では壊れる。バージョン依存の明確なリグレッションだ。

ソースコード流出が明らかにしたもの¶

なぜキャッシュが壊れるのか？ 3月31日、npmパッケージのビルド設定ミスにより、Claude Codeの全ソースコード（TypeScript、約51万行）が意図せず公開された⁸。Anthropicは数時間で取り下げたが、すでに広くミラーされた後だった。

流出コードを分析した開発者たちが、キャッシュ破壊の原因となりうる2つの仕組みを特定している。

原因候補①：リクエストごとに変わる「証明データ」¶

Claude Codeは、APIリクエストのたびに「このリクエストは正規のCLIから送られている」という証明データ（attestation）を生成して付加する⁹。不正利用を防ぐための仕組みだ。

問題は、この証明データがリクエストごとに異なる値を持つ点にある。キャッシュはプレフィックス（先頭からの内容）のハッシュで一致判定する。証明データが変わるとハッシュも変わるため、前回のキャッシュが「別物」と判定されて破棄される。

正規利用を守る仕組みが、結果としてキャッシュを壊していた可能性がある。

原因候補②：偽ツールのサイレント注入¶

もうひとつ、ANTI_DISTILLATION_CCというフラグが見つかった。有効時、APIが偽のツール定義をシステムプロンプトにこっそり挿入する。競合がClaude Codeの通信を傍受してモデル学習に使う「蒸留攻撃」を妨害する目的だ¹⁰。

ツール定義はキャッシュプレフィックスの一部なので、偽ツールの注入内容がリクエスト間で変動すれば、同じ理屈でキャッシュが無効化される。このフラグはフィーチャーフラグで制御されており全ユーザーに常時有効かは不明だが、有効化されたユーザーではキャッシュ破壊の直接的な原因になりうる。

クローズドだから見つからなかったバグ¶

これらの問題は、コードが公開される前から外部の開発者グループが挙動の異常として指摘していた。しかし、クローズドソースであったために「ここにバグがある」とピンポイントで示すことができなかった。

流出によって51万行のコードが読めるようになった結果、数時間で原因候補が特定された。テストがゼロであること（64,464行に対して）、3,167行・486分岐点の巨大関数が存在すること等、品質面の構造的な問題も可視化された⁹。

Anthropicは以前、Claude Codeをリバースエンジニアリングした開発者に法的措置をとった経緯がある。それが今回、ビルド設定のミスで全コードが公開され、結果としてユーザーに実害を与えていたバグの発見が加速した。クローズドソースで守りたかった知的財産が、クローズドであるがゆえに品質問題の発見を遅らせていた──OSSの議論に一石を投じる事例だ。

ユーザーができる対策¶

根本修正はAnthropicのパッチ待ちだが、現時点で効果が報告されている対策を整理する。

即効性のある対策：

オフピーク時間帯に作業をずらす。JST基準ではPT 5am-11am = JST 21時〜翌3時がピーク。日中の作業であれば制限強化の影響を受けない
セッションを短く区切る。/clearで新しいセッションを開始し、コンテキストの蓄積によるキャッシュ破壊の影響を最小化する
/compactで会話を圧縮する。コンテキストウィンドウの肥大化を防ぎ、トークン消費を抑える
Sonnetをデフォルトにする。Opusはトークン単価が約5倍。/modelでSonnetに切り替え、Opusは複雑な設計判断だけに使う

中期的な対策：

バージョンの固定を検討する。キャッシュが正常動作するバージョン（報告ではv2.1.68以前）への固定で改善した事例がある。ただし公式サポート対象外のため自己責任
--resumeフラグを避ける。セッション再開時にフルコンテキストの再処理が走り、キャッシュバグの影響を最も受ける
APIキー課金への切り替えを検討する。サブスクリプションの不透明なクォータではなく、従量課金にすることで消費量を正確に把握できる

この問題が示していること¶

今回の問題は、3つの異なるレイヤー（マーケティング施策・インフラ制約・ソフトウェアバグ）が同じ週に重なったことで深刻化した。どれか1つだけなら許容範囲だったかもしれないが、同時発生によってMax $200/月のユーザーが実質フリーティア並みの使用量しか得られない状況が生まれた。

コードが意図せず公開されたことで、クローズドのままでは発見が遅れていたであろうバグの原因が数時間で特定された。Claude Codeはテストゼロで51万行のコードを本番運用しており、品質管理の構造的な課題がある。基盤モデル（Opus 4.6）の能力は業界最高水準だが、それを包むCLIの品質がボトルネックになっている。

ここから得られる教訓はひとつ。インフラの信頼性は、モデル性能とは別のレイヤーの問題だ。 Claude Codeが開発者に不可欠なツールとなったいま、その品質保証の仕組み──テスト、キャッシュ監視、リリースプロセス──が問われている。キャッシュバグの修正パッチは近日中に出る可能性が高いが、3月31日時点で公式タイムラインは示されていない。GitHubのIssue #34629を追跡しておくことを推奨する。