メインコンテンツへスキップ
Dev Tools 23分で読める

Claude Codeのキャッシュを1時間に戻す方法、ENABLE_PROMPT_CACHING_1Hの全て

#Claude Code#Anthropic#プロンプトキャッシュ#コスト最適化#Bedrock#Vertex AI

「4月2日を境に、Claude Codeの日次コストが$6.28から$15.54に跳ね上がった。コードベースもワークフローも変えていない」。Redditで1,140セッション分のログを分析した米国の開発者が報告した実測値だ（Reddit r/ClaudeAI 経由）。原因は本人の使い方ではなかった。Anthropicが2026年3月、Claude Codeのプロンプトキャッシュ既定TTLを1時間から5分に予告なく短縮していた。

短縮はその後ユーザーの不満を受けて環境変数で巻き戻せるようになり、2026年5月にはBedrock専用フラグだったENABLE_PROMPT_CACHING_1H_BEDROCKに加え、Anthropic API・Vertex AI・Microsoft Foundryでも使える汎用版ENABLE_PROMPT_CACHING_1Hが用意された（GitHub Issue #48082）。本稿はこの変数の使い方と、本当にコストが下がるのかを実価格で検証する。

この記事はこんな人におすすめ
  • Claude Code APIをヘビーに使っており、月のAPI請求額が体感より高くて困っている開発者
  • Bedrock / Vertex AI 経由でClaudeを業務に組み込んでいるエンジニア
  • 「最近Claude Codeのクォータがすぐ尽きる」と感じているPro/Maxサブスクリプション利用者

何が起きたのか：3月の「サイレント変更」

事の経緯はシンプルだが、影響範囲は大きかった。

GitHub Issue #46829に投稿された分析によれば、Claude Codeのトランスクリプトログを2026年1月11日から4月11日まで横断的に確認したところ、3月1日から4月1日までは100%がephemeral_1hタイプのキャッシュを利用していた。それが4月2日を境に切り替わり、4月3日にはほぼ全てのキャッシュタイプがephemeral_5mに変わっていた（Issue #46829）。

XDA-Developersはこの変更を「Anthropicが密かにClaude Codeの1時間キャッシュをnerfした」と報じ、ユーザー側のトークン予算が圧迫される構造を解説した（XDA-Developers, 2026年4月）。コスト面で見れば、これは無視できる変更ではなかった。

キャッシュTTL書き込みコスト読み出しコスト損益分岐
5分（既定）入力トークンの1.25倍入力トークンの0.1倍1回読めば元が取れる
1時間（明示指定）入力トークンの2倍入力トークンの0.1倍2回読めば元が取れる

数字はAnthropic公式の料金ページに明記されている。ポイントは5分既定でもキャッシュ自体は機能する点だ。問題は5分以内に同じコンテキストを再利用できなかったケースで発生する。

5分が経過すると、Claude Codeは次のターンで全コンテキストを書き込み価格（1.25倍）で再アップロードする。Reddit投稿者の実測では、1日あたりのキャッシュバースト（再書き込み回数）が39回から199回に増加し、Opusでの日次コストが約2.5倍になった（XDA-Developers経由のRedditユーザー分析）。バーストが多発する作業パターンとは、要するに「考えながら書く普通のコーディング」のことだ。

プロンプトキャッシュの仕組みを最短で押さえる

実装に入る前に、何にお金がかかっているのかを正確に理解しておく。

プロンプトキャッシュはClaude APIの機能で、システムプロンプト、ツール定義、過去の会話履歴などの繰り返される長いコンテキストをサーバー側に保持し、次回以降のリクエストではフルテキストを再送せずキャッシュキーで参照する仕組みだ（Claude API Docs - Prompt caching）。

クライアント側はcache_controlオブジェクトで「ここまでをキャッシュしてほしい」と指示する。Claude Codeは内部でこの指示を自動的に挿入してくれるため、開発者が直接APIを叩いていなければ意識する必要はない。意識すべきは**TTL（キャッシュの有効期間）**だ。

Anthropic公式は3種類の状態を区別している。

  • キャッシュ書き込み（cache creation）: 新しくキャッシュを作るリクエスト。書き込み価格で課金される。
  • キャッシュ読み出し（cache read）: 既存キャッシュをヒットするリクエスト。基本入力価格の10%で済む。
  • TTL満了後の再書き込み: 「キャッシュバースト」とも呼ばれる。再びキャッシュ書き込み価格が発生する。

ClaudeCodeCamp.comはこのモデルをわかりやすく整理している。「100ターンのOpusコーディングセッションは、キャッシュなしだと$50〜$100の入力トークンコストがかかる。キャッシュ有効なら$10〜$19。1Mあたり読み出しは$0.50で、通常価格$5の10%」（ClaudeCodeCamp）。差は5倍以上。

つまりキャッシュが効くか効かないかで、月のAPI請求額に5倍の差が出ることがある。そして5分TTLは、人間の作業ペースとは噛み合わない。誰しもコーヒーを取りに席を立ち、Slackを読み、考え込む。その6分間が積み重なるとバーストが199回になる。

ENABLE_PROMPT_CACHING_1Hの使い方

ここからが実装の話だ。利用経路によって設定がやや異なる。

Anthropic API（直接利用）

シェルで環境変数をエクスポートしてからclaudeを起動する。

export ENABLE_PROMPT_CACHING_1H=1
claude

これで当該セッション中のキャッシュ書き込みリクエストに"ttl": "1h"が自動付与される。永続化したい場合は~/.zshrcや~/.bashrcに書く、もしくはdirenv等でプロジェクト単位に切り替える運用が現実的だ。

Amazon Bedrock

Bedrock経由のClaude Codeでは初期に専用フラグが用意されていた。

export ENABLE_PROMPT_CACHING_1H_BEDROCK=1
export CLAUDE_CODE_USE_BEDROCK=1
claude

汎用版ENABLE_PROMPT_CACHING_1HもBedrock環境で機能するため、新規にセットアップするなら汎用版を使えば良い（GitHub Issue #48082）。

直接APIを叩く場合はcache_controlに明示的にTTLを指定する。

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

AWSの公式ブログにはInvokeModelとConverseの両APIでの記述例が掲載されている（AWS Machine Learning Blog - Bedrock prompt caching）。

Google Vertex AI / Microsoft Foundry

Vertex AIでもClaude Anthropic SDKを通じてttl: "1h"を指定可能だ（Vertex AI Documentation）。Claude Code経由なら、汎用環境変数で同じく機能する。

キャッシュを無効化したいとき

逆に意図的にキャッシュを切るときは別の変数を使う。

export DISABLE_PROMPT_CACHING=1

復活させるときはunset DISABLE_PROMPT_CACHINGしてから再起動する。デバッグ用途や、コンテキストの汚染を疑った時の切り分けに使える。

損益分岐の実計算：どんなときに1時間TTLが得か

「2倍の書き込みコストを払ってでも1時間TTLが有利になるのはいつか」を、Opus 4.7の現行価格で計算する。

Opus 4.7の入力単価は1Mトークンあたり$5（Anthropic Pricing）。これを基準に各キャッシュ操作の単価を出す。

操作5分TTL1時間TTL
通常入力$5.00 / 1M$5.00 / 1M
キャッシュ書き込み$6.25 / 1M$10.00 / 1M
キャッシュ読み出し$0.50 / 1M$0.50 / 1M

100,000トークンのシステムプロンプト＋会話履歴を保持したセッションを想定する。

ケースA：反復が少ない単発タスク（書き込み1回 + 読み出し1回）

  • 5分TTL: $6.25/1M × 0.1M + $0.50/1M × 0.1M = $0.675
  • 1時間TTL: $10.00/1M × 0.1M + $0.50/1M × 0.1M = $1.05

このパターンでは5分TTLが約36%安い。

ケースB：30分間で5回の対話（書き込み1回 + 読み出し5回、5分TTLは1回バースト発生）

  • 5分TTL: 書き込み2回（=$6.25×2×0.1） + 読み出し4回（=$0.50×4×0.1）= $1.45
  • 1時間TTL: 書き込み1回 + 読み出し5回 = $10×0.1 + $0.50×5×0.1 = $1.25

すでに1時間TTLが約14%安い。

ケースC：1時間の作業セッション（書き込み1回 + 読み出し10回、5分TTLは2〜3回バースト）

  • 5分TTL（バースト3回想定）: 書き込み4回 + 読み出し7回 = $6.25×4×0.1 + $0.50×7×0.1 = $2.85
  • 1時間TTL: 書き込み1回 + 読み出し10回 = $10×0.1 + $0.50×10×0.1 = $1.50

1時間TTLが約47%安い。普段のコーディング作業のリズムが、まさにこのケースCに近い人は多いはず。

結論として、「Claude Codeを開いたまま30分以上作業する」典型的な使い方では1時間TTLが明確に有利だ。 短いタスクが多い、または1セッションで複数の独立した話題を切り替える使い方なら5分TTLでも問題ない。

サブスクリプションプラン利用者への影響

ここが厄介な論点だ。1時間TTLは公式仕様上「API課金のみ」で、Pro/Maxサブスクリプションには料金面で組み込まれていない（ClaudeCodeCamp分析）。

ところが2026年3月のサイレント変更以前は、サブスクリプション経由でも内部的に1時間TTLが使われており、結果としてクォータの保ちが良かった形跡が複数のユーザーログから観測されていた。Anthropicは「Claude Codeのクォータが想定より早く尽きている」と公式に認め、不具合修正を進めると表明した（The Register, 2026年3月31日）。

つまり3月の変更は「バグ修正」とも「サブスクリプション側の暗黙的優遇撤回」とも解釈できる。日本のユーザーの間でも「最近Claude Codeで挨拶3回でクォータが尽きる」という声が上がっていたが、それはコンテキスト初期化の度にキャッシュ書き込みが満額計上される構造変化を反映している可能性が高い（WEEX Crypto News, 2026年）。

サブスクリプション利用者にできることは限られる。

  • APIキー併用に切り替え、ヘビーな日はENABLE_PROMPT_CACHING_1H=1で運用する
  • Maxプランへのアップグレードで5時間ウィンドウを稼ぐ（5月のSpaceX契約で限度が2倍になった点は別記事で解説した: AnthropicがSpaceX Colossus-1と契約、Claude Code制限が即日2倍に）
  • 長時間セッションを避け、/clearをこまめに使ってコンテキストを縮小する

設定する前に確認すべき注意点

ENABLE_PROMPT_CACHING_1H=1を入れれば常に得、というわけではない。3つの注意点がある。

1. 書き込みが一度きりで終わるタスクには逆効果

GitHub Actionsで毎回新しいセッションを立ち上げ、1回API叩いて終わる、というタイプの自動化には1時間TTLは不利だ。書き込みコストが2倍になるだけで読み出しの恩恵を受けない。CI/CDジョブには5分TTL、もしくはキャッシュ無効が向く。

2. キャッシュキーは内容ハッシュで決まる

システムプロンプトやツール定義をわずかでも書き換えると、別のキャッシュエントリーになる。1時間TTLでも前のキャッシュには戻れない。プロンプトのバージョン管理を雑にやっていると、キャッシュ恩恵がほぼゼロになるケースがあるので注意したい。

3. クォータ計算とコスト計算は別物

サブスクリプション利用者の場合、ドル建てコストではなく「メッセージ数クォータ」で制限される。1時間TTLがクォータ削減に直接効くかはAnthropicが公開していないため、効果測定は実利用ログで確認するしかない。

自分（電脳狐影）ならこう運用する

PMの視点で、ヘビーユーザーとカジュアルユーザーで運用を分ける。

ヘビーユーザー（1日3時間以上Claude Codeを開く人）: APIキーでの直接利用に切り替え、~/.zshrcにexport ENABLE_PROMPT_CACHING_1H=1を書く。長いセッションを継続する作業スタイルに対し、ケースCの計算通り月のコストを30〜45%圧縮できる。

カジュアルユーザー（散発的に短いタスクをこなす人）: 設定はいじらない。5分TTL既定のままでも、ケースAでは1時間TTLより安い。

チーム運用: プロジェクトディレクトリに.envrcを置き、direnvで「このリポジトリでは1時間TTL」を強制する。Slack botやCI向けの軽量タスクでは無効化する。プロジェクト単位の運用が一番ハマりにくい。

そして全員に共通する原則として、システムプロンプトとツール定義の意図しない書き換えを避ける。コメントの誤字修正でもキャッシュキーは変わる。プロンプトの編集はGit管理し、変更頻度を意識する。

ノート

Anthropicがサイレント変更を予告なく実施した経緯から、今後も同様の挙動変更が起きる可能性は排除できない。コスト最適化を運用に組み込むなら、APIレスポンスのcache_creation_input_tokensとcache_read_input_tokensを定期的にロギングし、比率を可視化しておく。バースト率が急変したらアラートが出る仕組みが望ましい。

関連記事

Claude Codeのコストとクォータ周りは、本稿で扱った1時間TTLの問題以外にも論点がある。

次のステップ

本稿で紹介した環境変数は環境を選んで運用しないと逆効果になります。まずはご自身の利用ログを1週間分集め、キャッシュ書き込みと読み出しの比率を可視化することから始めてください。比率が読み出し2倍以上ならENABLE_PROMPT_CACHING_1Hの導入を検討する価値があります。

関連記事を読む

免責事項: 本記事内のAPI料金や設定仕様は2026年5月11日時点の公開情報に基づくものです。価格・仕様は予告なく変更される可能性があります。実際の請求は各プロバイダの最新ドキュメントとご自身の利用ログでご確認ください。

Share