Claude Codeのキャッシュ短縮で枠が枯渇、開発者が反発

月200ドルを払う開発者が、3月を境に使用枠の上限へ張り付くようになった。疑われているのは、Anthropicが静かに戻したキャッシュ保持時間だ。同社は値上げではないと言うが、請求書はそれを裏切っている。

情報の灯台

2026年4月14日

5分キャッシュへの巻き戻しが直撃した

発端は、Sean Swansonというユーザーが投稿したGitHub上のバグレポートだ。Swansonの分析によれば、Anthropicは2026年2月1日ごろにClaude Codeのコンテキストに対して1時間のキャッシュを導入し、3月7日ごろに再び5分のキャッシュへ戻したという。

プロンプトキャッシュは、同じ前提情報をモデルに何度も再処理させないための仕組みだ。Claudeのキャッシュは5分保持と1時間保持の2択で、書き込みコストは5分キャッシュで基本料金の25%増し、1時間キャッシュで100%増し、読み出しは基本料金の約10%という料金体系になっている。一度書けば以降は安く読める、というのが売りだ。

問題は、長時間セッションでClaude Codeを使い続ける開発者にとって、5分ではキャッシュがすぐに切れてしまうことだ。切れれば、次の一手で書き込みコストが再発生する。Swansonはこの変更を「Claude Codeの使われ方そのものに対して不釣り合いに不利だ」と表現した。

長時間・高コンテキストのセッションこそがClaude Codeの使い方を定義しているのに、5分のTTLはその用途に対して不釣り合いに厳しい。

Anthropic側の反論は「一発芸の方が多い」

この指摘に対し、Anthropic側から反論したのは意外な人物だった。JavaScriptランタイム「Bun」の作者として知られるJarred Sumnerだ。SumnerはBunごとAnthropicに買収され、現在は同社に在籍している。

Sumnerは分析そのものを「良い探偵仕事だ」と評価しつつ、5分キャッシュに戻したのはむしろコスト削減のためだと主張した。理由は、Claude Codeのリクエストの相当部分が「キャッシュしたコンテキストを使い回さずに一度で終わる単発呼び出し」だからだ、という。書き込みコストが安い5分キャッシュの方が、そうした使い方には合っている。キャッシュのTTLはクライアント側が自動で判定する仕組みで、ユーザーが選べるグローバル設定を用意する予定はないという。

Swansonは一部譲歩した。サブエージェントを走らせる使い方では、個々のエージェントが素早く対話するためキャッシュが切れにくく、書き込みコストの安い5分キャッシュの方が有利になる。そこまでは認めた。だが、話はそこで終わらない。

6か月以上にわたって月200ドルのサブスクライバーをやってきたが、3月までは枠の上限に引っかかったことは一度もなかった。

月200ドル、日本円にして約3万2,000円のプランで初めて枠に引っかかったのが3月──これがSwansonの実感だ。彼はこの消費ペースの上昇が、かつて優れていたサービスを使い物にならなくしていると書いている。Anthropicの説明と現場の請求書の間には、確かに距離がある。

100万トークンという重荷

もう一つの火種は、有料プランで使える100万トークンのコンテキストウィンドウだ。Claude Code 開発者のBoris Chernyは3月13日、Opus 4.6の100万トークン版をMax・Team・Enterpriseプランのデフォルトに据えると発表した。キャッシュが効いている間は快適だが、一度外れると一撃で高くつくのがこの巨大な枠の性質だ。

Cherny自身がそれを認めている。100万トークンのコンテキストでキャッシュミスが起きれば出費は跳ね上がり、「1時間以上席を外してから古いセッションを再開すれば、多くの場合はフルキャッシュミスになる」というのが彼の説明だ。Anthropicはデフォルトのコンテキストサイズを40万トークンへ下げる案を検討しており、希望者だけが100万トークンを選ぶ形にするという。設定項目自体はすでに存在する。

Chernyはコンテキストが膨らみがちな理由として、スキルの大量読み込み、多数のエージェントの並列実行、バックグラウンド自動化といった最近の使い方の変化を挙げた。ユーザーが勝手に重い使い方をしているわけではない。Anthropic自身が推している機能が、自社の課金構造を圧迫している、という構図だ。

100万トークンのコンテキストでプロンプトキャッシュがミスヒットすると、コストは跳ね上がる。

下位プランはさらに深刻

上位プランがこの状態なら、下の階層はもっと悲惨だ。月20ドル、日本円で約3,200円のProプラン利用者の一部は、5時間あたりわずか2プロンプトしか通らない事例まで報告している。「キャッシュ周りに複数のバグがある」と指摘する声もあり、そこまで来ると5分対1時間の議論以前の話だ。数字の土台そのものが信用できない。

さらに厄介なのは、性能そのものへの不満が並走していることだ。3月はOpusで一日中まともに仕事ができていたエンタープライズチームプランのユーザーが、3月末から4月にかけて2時間未満でセッション枠を使い切り、しかもモデルが同じ結論を何度も再発見する堂々巡りに陥っている、と証言している。「いや、やっぱりxをやるべきだ」という段落を、わずかに言葉を変えて何度も繰り返す挙動だ。同様の不満は、先週AMDのAIディレクターが公にぶつけた批判とも一致する。

質が落ち、消費は速い。この2つが同時に起きているなら、キャッシュTTLの話だけでは説明がつかない。枠という単位が、以前より少ない処理能力しか買えなくなっている可能性、と言い換えてもいい。

誰のための最適化か

キャッシュの使い分けそのものは、技術的にはまっとうな最適化だ。一発芸のリクエストが多数派なら、書き込みコストの安い5分キャッシュを標準にする判断には筋がある。Sumnerの言い分は嘘ではない。

問題は、それが「長時間ずっとClaude Codeに張り付いて、巨大なコンテキストを抱えて仕事をする開発者」を最適化の対象から外した瞬間に起きる。彼らこそが月200ドルを払っているユーザー層であり、Claude Codeを他のAIコーディング支援から際立たせてきた使い方の本丸でもある。多数決の最適化は、収益の最適化と同じとは限らない。

キャッシュTTLの調整で全部が説明できるとは思わない。裏側で何が変わったのか、外からは見えない。見えているのは、料金表は据え置きのまま、同じ金額で買える作業時間が縮んだという現場の実感だけだ。

Anthropicが次にどう動くかは、まだわからない。技術的な正しさを盾に押し切るのか、デフォルトの見直しまで踏み込むのか。40万トークンへのコンテキスト縮小案は、後者への入り口になるかもしれない。

参照元