Anthropicがキャッシュ TTLを静かに引き下げ — Claude Codeユーザーのコスト増加問題を徹底解説

はじめに

2026年3月6日を境に、Claude Codeのプロンプトキャッシュに異変が起きた。それまでデフォルトだった1時間のキャッシュTTLが、5分間に切り替わったのだ。GitHub Issue #46829に投稿された詳細な分析によると、あるユーザーの119,866件のAPIコールを集計した結果、約**$2,500の超過コスト**が発生していたことが判明。HNでは363ポイントを獲得し、開発者コミュニティで大きな議論を巻き起こしている。この記事では、何が起きたのか、プロンプトキャッシュの仕組みとコスト構造、そして開発者が取るべき対策を解説する。

何が変わったのか — 1時間から5分への切り替え

時系列で追う変化

Issue投稿者が2台のマシンで取得したログデータによると、変化は明確だ。

  • 2月1日〜3月5日: キャッシュ書き込みはすべて1時間TTL。5分TTLのトークンはゼロ
  • 3月6日: 初めて5分TTLのトークンが出現(混在状態)
  • 3月8日以降: 5分TTLが全体の**83%**を占めるように
  • 3月21日: 5分TTLが**93%**にまで拡大

33日間にわたり2台のマシンで一貫して1時間TTLだったものが、3月6日を境に突然切り替わった。この一貫性が「意図的な変更だった」と推測される根拠となっている。

Anthropic公式の回答

Anthropicの開発者Jarred Sumner氏はIssueで以下のように回答した。

  • 3月6日の変更は意図的なものであり、バグではない
  • 「キャッシュ最適化の一環」として実施
  • クライアントがリクエストごとにTTLを選択する仕組みに変更
  • すべてを1時間TTLにすると、書き込みコストが高いため逆にコスト増になる

ただし、この変更はリリースノートや公式ブログでは事前告知されておらず、ユーザーが自らのログを分析して初めて発覚した形だ。

プロンプトキャッシュの仕組み — なぜTTLがコストに直結するのか

キャッシュの基本動作

プロンプトキャッシュとは、APIリクエストの中で変化しない部分(システムプロンプト、ツール定義、会話履歴の前半など)をサーバー側に保存し、次回以降のリクエストで再利用する仕組みだ。

  1. キャッシュ書き込み(cache write): 初回リクエスト時にプロンプトの一部をキャッシュに保存。書き込みコストが発生
  2. キャッシュ読み取り(cache read): TTL内に同じプロンプトプレフィックスでリクエストすると、安価な読み取り料金で再利用
  3. キャッシュ失効: TTLを過ぎるとキャッシュが消え、次回は再び書き込みコストが発生

重要なのは書き込みと読み取りのコスト差だ。Claude Sonnet 4.6の場合を見てみよう。

操作料金(100万トークンあたり)倍率
通常の入力$3.001×
5分キャッシュ書き込み$3.751.25×
1時間キャッシュ書き込み$6.002×
キャッシュ読み取り$0.300.1×

キャッシュ読み取りは通常入力のわずか10分の1。一度キャッシュに書き込めば、TTL内の再利用は極めて安価になる。逆に言えば、キャッシュが頻繁に失効すると、高額な書き込みが何度も発生する。

5分TTLが高くつく理由

Claude Codeのような対話型ツールでは、ユーザーがコードを読んだり考えたりする「間」が頻繁に生まれる。5分以上の中断は日常的だ。

5分TTLの場合、こうした自然な中断のたびにキャッシュが失効する。次のリクエストでは、システムプロンプトや会話履歴といった大量のコンテキスト(数万〜数十万トークン)を丸ごと再書き込みしなければならない。Issue投稿者のデータでは、5分TTLに書き込まれた2.2億トークンが57億回のキャッシュ読み取りを生成しており、本来は1時間TTLで保持すべき高頻度再利用パターンだったことがわかる。

コストへの影響 — 実データが示す超過額

Issue投稿者が公開した実コストデータは衝撃的だ。

Claude Sonnet 4.6の月別分析

月実際のコスト1h TTL想定コスト超過額超過率
2月(1h TTL期間)$1,120$1,108$121.1%
3月(5m TTL移行後)$2,776$2,057$71925.9%
4月$1,193$1,017$17614.8%

2月の超過率がわずか1.1%なのに対し、3月は25.9%に跳ね上がっている。利用量の増加ではなく、TTL変更だけでこの差が生まれている。

サブスクリプション(Pro/Max)ユーザーへの影響も深刻だった。キャッシュ書き込みトークンはフルレートでクォータ消費されるため、3月になって初めて5時間の利用制限に到達するユーザーが続出した。

Anthropicの反論 — 「1時間TTLの方がむしろ高い」

Anthropicの主張にも一理ある。1時間TTLの書き込みコストは5分TTLの約1.6倍(Sonnetで$3.75 vs $6.00)だ。キャッシュが1回しか再利用されないようなリクエスト(一度きりの質問や短いセッション)では、高い書き込みコストを払って1時間保持する意味がない。

つまり、最適なTTLはユーザーの利用パターンに依存する。

  • 長時間の開発セッション: 1時間TTLが有利(キャッシュ読み取りで大幅に節約)
  • 単発のリクエスト: 5分TTLが有利(不要な書き込みコストを抑制)

現在のClaude Codeはリクエストごとに最適なTTLを選択するロジックに変更されている。v2.1.90では、クォータ超過時に5分TTLに固定されるバグも修正された。

開発者が知っておくべきこと

API利用者向け

自前でClaude APIを使っている場合、TTLは開発者が制御できる。cache_controlパラメータでリクエストごとに指定可能だ。

{
  "cache_control": {
    "type": "ephemeral",
    "ttl": "1h"
  }
}

長時間再利用するシステムプロンプトやツール定義には1時間TTLを、単発リクエストには5分TTLを使い分けるのがコスト最適化の基本戦略になる。

Claude Codeユーザー向け

Claude Code経由の利用ではTTLを直接制御できないが、以下の点を意識するとよい。

  • 作業の中断は5分以内を意識: 離席するならセッションのコンパクト(/compact)を実行してからにする
  • キャッシュ無効化のトリガーを理解: ツール定義やシステムプロンプトの変更、fastモードの切り替えでキャッシュが全無効化される
  • 利用状況の監視: ~/.claude/projects/ 配下のJSONLファイルでキャッシュのヒット率を確認できる

まとめ

  • Anthropicは3月6日にキャッシュTTLのデフォルトを1時間から5分に変更した。「キャッシュ最適化」の一環だが、事前告知はなかった
  • 長時間セッションの多いClaude Codeユーザーにとって、最大25%のコスト増加が確認された
  • API利用者はcache_controlパラメータで1時間TTLを明示的に指定することで影響を回避できる
  • 今回の件は、LLMの料金体系におけるキャッシュ戦略の重要性を改めて浮き彫りにした。インフラ側の「最適化」がユーザーのコストに直結するため、利用パターンに応じた設定の理解が欠かせない

ソース