AnthropicのキャッシュTTL無告知変更とClaude Codeクォータ枯渇の構造
目次
Claude Codeには月$100のMax 5xプラン、月$200のMax 20xプランがある。
「Proの5倍」「Proの20倍」の使用量が使えるとされている。
では、Proの基準量はいくつなのか。
5倍とは具体的に何トークンなのか。
Anthropicはその数値を公開していない。
ユーザーがClaude Codeの使用量を確認する手段は限られている。
ターミナルでClaude Codeを起動したときに内部APIを叩いて取得される使用量グラフ、/usageコマンド、claude.aiのダッシュボード。
いずれも「今のウィンドウでどれくらい使ったか」をパーセンテージやバーで相対表示するだけで、「5時間ウィンドウあたり何トークンまで使えるか」という絶対値はどこにもない。
月$100を払って何を買ったのかが、数値として示されないまま販売されている。
この不透明さの上に、2026年3月から4月にかけて2つの問題が重なった。
「プロンプトキャッシュのTTLが無告知で変更された」という調査レポート（GitHub Issue #46829）と、「Pro Max 5xのクォータが1.5時間で尽きる」という報告（GitHub Issue #45756）。
後者はHacker Newsで635ポイント・565コメントを集めた。
クォータの基準値がわからないから、「何かおかしい」と感じても仕様変更なのか自分の使い方の問題なのか区別できない。
ユーザーは自身のセッションログを解析し、クォータの中身を逆算するところから始めるしかなかった。
プロンプトキャッシングの仕組み
Claude APIのPrompt CachingはAPIコールのたびにシステムプロンプトや長いコンテキストを再送信するコストを削減する機能だ。
送信済みのプロンプトプレフィックスをAnthropicのサーバー側にキャッシュしておき、同じ内容を次のリクエストが参照するとキャッシュ読み取りとして処理される。
TTLには2段階ある。
| TTL | 書き込みコスト（Sonnet） | 読み取りコスト | 特徴 |
|---|---|---|---|
| 5分 | $3.75/MTok（基本の1.25倍） | $0.30/MTok（基本の0.1倍） | 2026年3月以降のデフォルト。5分以内に再利用されれば自動リフレッシュ |
| 1時間 | $6.00/MTok（基本の2倍） | $0.30/MTok（同上） | 明示指定が必要。会話の間隔が5〜60分のケースで有効 |
書き込みより読み取りが12.5倍安い。
5分TTLの場合、コーヒーブレイク一つでキャッシュが失効し、次のリクエストで同じコンテキストを丸ごと再キャッシュ（書き込みコスト）しなければならない。
TTL変更の発覚
Issue #46829の投稿者（seanGSISG）は2台のマシン（LinuxワークステーションとWindowsラップトップ、別アカウント）から収集した119,866件のAPIコールのセッションログを分析した。
Claude CodeはAPIレスポンスのusageオブジェクトをJSONLファイルとして~/.claude/projects/に記録しており、そこにcache_creation.ephemeral_5m_input_tokensとephemeral_1h_input_tokensの内訳が含まれていた。
| フェーズ | 期間 | TTL挙動 |
|---|---|---|
| Phase 1 | 2026年1月 | 5分のみ（1時間ティアが存在しない時期） |
| Phase 2 | 2月1日〜3月5日 | 1時間のみ（33日間にわたって一貫） |
| Phase 3 | 3月6〜7日 | 混在（5分が再出現） |
| Phase 4 | 3月8日〜4月 | 5分が主体（1時間はごく少数） |
2026-02-15 | 5m: 0.00M | 1h: 13.61M ← 最重量日、100%が1時間
2026-02-28 | 5m: 0.00M | 1h: 16.15M ← 同様
2026-03-05 | 5m: 0.00M | 1h: 6.55M ← 最後のクリーンな1時間のみの日
2026-03-06 | 5m: 0.29M | 1h: 0.22M ← 5分が再出現
2026-03-08 | 5m: 16.86M | 1h: 3.44M ← 5分が83%
2026-03-21 | 5m: 21.37M | 1h: 1.70M ← 5分が93%クライアント側の変更はなく、Claude CodeのバージョンもUsageパターンも同一。
TTLティアはサーバー側でAnthropicが決定している。
そしてこの変更はどこにもアナウンスされなかった。
APIドキュメントにも、リリースノートにも、チェンジログにも記載なし。
119,866件のログを自力で解析してようやく判明した事実だった。
Anthropicのコスト主張
Issue内でAnthropicのエンジニア（notitatall）が回答した。
3月6日の変更はコストの削減です。すべてのリクエストで1時間TTLにするとコストが上がる場合があります。1時間書き込みは5分書き込みより約2倍の価格です。キャッシュが再利用される保証がなければ、より高い書き込みコストを埋め合わせる読み取りが発生しません。
投稿者が自身のデータを再分析したところ、セッション種別で分けると確かに構造的な違いがあった。
| セッション種別 | コール数 | 5分トークン | 1時間トークン |
|---|---|---|---|
| メインセッション | 46,376 | 35.3M | 165.1M |
| サブエージェント | 73,490 | 239.8M | 134.5M |
コール数の61%を占めるサブエージェントは中央値1.4秒の間隔で動作するため5分TTLでも失効しない。
サブエージェントにとっては5分書き込み（$3.75/MTok）のほうが1時間書き込み（$6.00/MTok）より安い。
訂正後の試算では、API従量課金ユーザーは3月6日の変更で約418ドル節約になるという結果になった。
ただしこの議論はAPI従量課金ユーザーに限った話だ。
サブスクリプションユーザーにとってはAPI単価ではなくクォータ消費速度が問題であり、TTL変更がクォータにどう影響するかは別の検証が必要になる。
Pro Max 5xクォータ枯渇の報告
Claude Maxプランには2つのティアがある。
| プラン | 月額 | 使用量の倍率（Pro比） |
|---|---|---|
| Max 5x | $100 | 5倍 |
| Max 20x | $200 | 20倍 |
クォータは5時間ウィンドウ単位でリセットされる。
Issue #45756の投稿者molu0219は詳細なデータを持ち込んだ。
クォータリセット後、「Q&Aと軽い開発作業」で691回のAPIコールを消費した1.5時間のウィンドウが問題だった。
| セッション | APIコール | キャッシュ読み取り | 出力トークン |
|---|---|---|---|
| vibehq（メイン） | 222 | 23.2Mトークン | 91k |
| token-analysis（バックグラウンド） | 296 | 57.6Mトークン | 145k |
| career-ops（バックグラウンド） | 173 | 23.1Mトークン | 148k |
| 合計 | 691 | 103.9Mトークン | 387k |
ユーザーが操作していたのはvibehqのみ。
残り2セッションは別ターミナルで開いたままの状態だったが、バックグラウンドで独自にAPIコールを継続し、共有クォータを消費していた。
コミュニティユーザーのcnighswongerが6ウィンドウ分のデータで「cache_readトークンがクォータにどう影響するか」を検証した結果は意外だった。
| 仮説 | 各ウィンドウの推定クォータ | 変動係数（CV） |
|---|---|---|
| cache_read = 0倍（カウントしない） | 約4.66Mトークン当量 | 34.4% |
| cache_read = 0.1倍（課金と同レート） | 約24.4Mトークン当量 | 101.6% |
| cache_read = 1.0倍（フルレート） | 約201.6Mトークン当量 | 123.7% |
変動係数が最も低い（データと最も一致する）のは「cache_readはクォータにほぼ影響しない」モデルだった。
クォータ消費の主因はキャッシュ読み取りではなく、別にあることになる。
だがこの検証自体、クォータの計算ロジックが公開されていないから必要になった作業だ。
そもそも「5倍」が何なのか誰も知らない
ここまでの調査を振り返ると、ユーザーたちがやっていることの異常さが見えてくる。
月$100を払っているサービスの中身を、セッションログを逆算して推測している。
Max 5xは「Proの5倍」、Max 20xは「Proの20倍」とされている。
だがProの基準量が何トークンなのかは公開されていない。
「5倍」の分母がわからない以上、「5倍」という数字には意味がない。
ユーザーがClaude Codeの使用状況を確認できる手段を具体的に見てみる。
| 手段 | 表示内容 |
|---|---|
| ターミナル起動時の使用量グラフ | Claude Code起動時にAnthropicの内部APIからウィンドウ使用率を取得。バーグラフでパーセンテージ表示 |
/usageコマンド | セッション内の使用状況をパーセンテージ表示 |
| claude.aiのダッシュボード | ブラウザから使用状況を確認。バーとパーセンテージ |
どの手段でも表示されるのはパーセンテージだけだ。
分母が何トークンなのか、どのトークン種別（入力、出力、cache_read、cache_creation）がどう重み付けされているのか、一切開示されていない。
しかもこれらの表示手段は公開APIやドキュメントに基づくものですらない。
ターミナル起動時のグラフはClaude Codeが内部的に叩いているAPIのレスポンスであり、そのエンドポイントの仕様は公開されていない。
ユーザーが自力で使用量を取得・記録するには、Claude Codeがローカルに書き出すセッションログ（~/.claude/projects/配下のJSONLファイル）を自分で解析するしかない。
前節でcnighswongerが「1ウィンドウあたり約4.66Mトークン当量」というMax 5xの推定値を算出したのは、まさにこの方法で6ウィンドウ分のデータを逆算した結果だ。
Anthropicはこの推定値を公式に確認も否定もしていない。
ユーザーが置かれている状況を整理する。
- 「5倍」が具体的にどれだけの処理量を意味するのか知らない
- クォータの残量はパーセンテージでしか見えず、分母が不明
- どのトークン種別がどの重みでクォータを消費するのか仕様がない
- TTLやキャッシュ計算ロジックがサーバー側で変更されても、クォータへの影響を自力で検証する手段がない
- 同じ作業をしても日によってクォータの減り方が違う理由を、セッションログを解析しない限り特定できない
月$100や$200のサブスクリプションで「何が買えるか」を数値で示さないまま販売しているサービスは、SaaS全体を見渡してもかなり珍しい。
クラウドコンピューティングでもAPIサービスでも、料金ページにはレート制限や含まれるリソース量が明記されるのが標準だ。
Anthropic自身のAPI料金ページにはモデルごとのトークン単価が明記されているのに、サブスクリプションプランだけは「5倍」「20倍」という相対表現で済ませている。
競合のOpenAIですら、ChatGPT Proのレート制限については「無制限（フェア・ユース）」と少なくとも建前上の基準を示している。
このブラックボックス構造の問題は、サーバー側で何が変わってもユーザーにはそれが見えないことだ。
TTLが変更されても、キャッシュの計算ロジックが変わっても、クォータの分母自体が変わっても、ユーザー側には「なんか今日減りが早い」としか映らない。
seanGSISGが119,866件のログを解析してTTL変更を立証したのも、cnighswongerがクォータの計算式を逆算したのも、本来であれば仕様書を読めば済む話だった。
コンテキスト肥大とクォータスパイクの構造
AnthropicエンジニアのBoris Cherny（@bcherny）がIssue #45756でコメントした。
根本原因として挙げたのは2点。
1つ目は1MトークンコンテキストウィンドウとTTLの組み合わせ。
Claude Codeのメインエージェントは1時間キャッシュを使用しているが、1時間以上セッションを中断して再開するとキャッシュが完全に失効する。
1Mコンテキスト付近まで膨らんだセッションで、これがauto-compact時にも発生する。
2つ目は複数のバックグラウンドエージェントによる共有クォータの消費だ。
graph TD
A[セッション開始] --> B[ツール呼び出し・ファイル読み込み]
B --> C[コンテキスト蓄積<br/>32k → 966kトークン]
C --> D{5分以上中断?}
D -->|はい| E[キャッシュ失効<br/>5分TTL]
D -->|いいえ| F[キャッシュ読み取り<br/>コスト低]
E --> G[cache_creation 発生<br/>フルコンテキストを再書き込み]
G --> H[クォータ大量消費]
C --> I{コンテキストが上限付近?}
I -->|はい| J[auto-compact 発生<br/>全コンテキストを1回のAPIコールで送信]
J --> K[最大級のクォータスパイク]
K --> A
H --> A投稿者の実測では、コンテキストが次のサイクルで推移した。
- セグメント1: 32k → 783k（835コール）→ auto-compact
- セグメント2: 39k → 966k（1,842コール）→ auto-compact
- セグメント3: 55k → 182k（222コール）→ アクティブ
1Mコンテキスト付近でauto-compactが走ると、そのAPI呼び出し1回で約960kトークンのcache_creationが発生する。
これが5分TTL環境では通常の操作中にも繰り返す。
Anthropicの対応策
Anthropicが発表した対応策は以下のとおり。
- コンテキストウィンドウのデフォルトを1Mから400kへ変更を検討中
- 古いセッションを再開する際に
/clearを促すUX改善（実装済み） - 現時点では
CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claudeを設定することで400kを試験的に使える - v2.1.90で別のバグ修正：クォータ使い切り後のセッション開始でオーバーエージが始まり5分TTLに固定されたままになる問題
ただしIssue #45756の投稿者はオーバーエージに入っていないケースだったため、この修正では説明がつかない。
クォータ消費とcache_readトークンの関係については「フォローアップする」と述べるにとどまった。
クォータの絶対値を公開する予定については、どちらのIssueでも言及がなかった。
コンテキスト縮小やUX改善、バグ修正といった対症療法は出しつつも、「クォータの中身を開示する」という根本的な透明性の改善には触れていない。
サードパーティ製ワークアラウンド
公式対応を待てないユーザーのために、コミュニティ側で2つの対処策が出ている。
1つ目はバージョン固定。
退行前のv2.1.81にピン留めする。npm install -g @anthropic-ai/claude-code@2.1.81で適用できる。
2つ目はインターセプタの導入。
claude-code-cache-fixが1時間TTLを強制し、キャッシュのフィンガープリント不安定を補正するとされている。
Max 20xプランのユーザーで約3〜4倍のクォータ改善を報告した例もある。
ただしいずれもサードパーティ製であり、Anthropicの管理外のツールだ。
以前報じたOpenClawの事例のように、こうしたツールの利用がポリシー上どう扱われるかは注意が必要だ。
OpenClawなどサードパーティハーネスのサブスク利用除外、Claude Codeの品質劣化を示すIssue、そして今回のTTLサイレント変更とクォータ不透明性。
2026年3月〜4月は無告知変更と情報非開示が重なった時期だった。
Hacker Newsのあるコメントが端的だった。
「rug pullされた後では、何かおかしいのか自分のせいなのかを毎回確認しなければならなくなる。その確認コストそのものが巨大なロス」。
調査に使われたツールはOSSとして公開されている。
cnighswonger/claude-code-cache-fixのquota-analysis --sourceモードで、自身の~/.claude/projects/ログを使って同様の分析ができる。