メインコンテンツへスキップ
Claude Code、Cline、Cursor を使っている場合でも、自作の Claude API 呼び出しをしている場合でも、プロンプトキャッシュは請求額を下げるための最も大きな調整ポイントです — キャッシュされた入力 token はわずか 0.1× で課金され、90% の割引になります。 このページは Anthropic の公式ドキュメント(platform.claude.com/docs/en/build-with-claude/prompt-caching)を基にしており、コピペしてすぐ使える例を APIYI の設定向けに調整しています。

一文で言うと

長く、繰り返し使う prompt のプレフィックス(システム指示 / 長い文書 / few-shot の例)を cache_control でマークします。サーバーがそれを保存し、同じプレフィックスで次のリクエストが来たときは再処理をスキップします — おおよそ 10 倍安く、速くなります。一定期間使われないと期限切れになります。

なぜ重要なのか — レート倍率を確認する

モデルの基本入力 token 価格(1×)に対する相対値: 損益分岐点:
  • 5分 TTL:同じプレフィックスをわずか2回再利用するだけで元が取れます(1.25 + 0.1 = 1.35 となり、キャッシュなしのリクエスト2回分の 2.0 より安価になります)。
  • 1時間 TTL:元を取るには3回の再利用が必要です(2 + 0.2 = 2.2 となり、3.0 より安価になります)。
TTLはスライディングウィンドウです。キャッシュヒットのたびに有効期限タイマーがリセットされるため、進行中の会話が意図せず期限切れになることはありません。TTLを超えて完全にアイドル状態になった場合のみ破棄されます。

適しているケース

  • 同じ長いシステム prompt が何度も呼び出される場合(エージェント、チャットボット)
  • マルチターンの会話(過去の各ターンが再利用可能なプレフィックスになります)
  • 1つのドキュメントに対するバッチ処理(1つの契約書に対して50個の質問を行うなど)
  • 安定した検索チャンクがプレフィックスを構成する RAG

適していないケース

  • すべての prompt が1文字目から異なっている場合
  • 全体として短く、モデルごとの最小要件(後述)を満たさない場合
  • ターンごとにアップロードされた添付ファイルを再構築するチャットクライアント(後述の「画像やファイルもキャッシュ可能」を参照)

3つの必須要件

3つすべてが必須です。

1. 明示的な cache_control マーカー

content は単なる文字列にはできません。これはコンテンツブロック配列である必要があり、キャッシュしたいブロックに cache_control を付与します。

2. 長さがモデルごとの最小値を超える必要がある

コンテンツがモデルの最小値より短い場合、マーカーがあってもキャッシュされません(エラーは発生せず、単に静かにスキップされます)。Anthropic の公式ドキュメントで確認済みです。
このしきい値はバージョン番号に対して単調に下がるわけではありません。推測しないでください。 最も直感に反する組み合わせは、Opus 5 が必要とするのはわずか 512 である一方、より古い Opus 4.6 / 4.5 は 4,096 を必要とすることです。これは8倍の差です。Haiku 4.5 も 4,096 であり、より古い Haiku 3.5(2,048)よりも高くなっています。したがって、「新しいモデルほどしきい値が低い」も「小さいモデルほどしきい値が低い」も成り立ちません。モデルを切り替えるたびに表を確認してください。
英語テキストは平均して token あたり約0.75語です。実際には、Opus 5 は約 380語以上 の安定したコンテンツからキャッシュされ、Sonnet 5 / Sonnet 4.6 は約 770語、Opus 4.6 / Haiku 4.5 はキャッシュが機能するまでに約 3,000語 必要です。最新のしきい値については、常に Anthropic の公式ドキュメントを参照してください。モデルバージョン間で変更される可能性があります。
APIYI で測定(2026-07-29)。 サイズを段階的に増やした固定プレフィックスを使用して書き込みしきい値を検証しました。claude-opus-5 は301 tokensではキャッシュ書き込みが発生せず、614では発生したため、公式の 512 を挟み込んでいます。claude-sonnet-5 は612では発生せず、1,250では発生したため、公式の 1,024 を挟み込んでいます。どちらも上記の表と一致しています。

3. プレフィックスはバイト単位で完全に一致する必要がある

キャッシュはプレフィックスベースです。リクエストの先頭から cache_control マーカーまでのバイトストリームは、前回のリクエストと完全に同一でなければなりません。空白、JSON キーの順序、タイムスタンプなど、1文字でも変更すると新しいプレフィックスとして扱われ、ヒットではなく新規書き込みが発生します。 実践的なルール:安定したものは先頭に、変動するものは末尾に配置します。

最小の実行例

同じ長いドキュメントを使って、異なる質問で 2 回リクエストを送信します。1 回目は書き込み、2 回目はヒットします:
期待される出力:
2 回目の呼び出しの read ≈ 1 回目の呼び出しの write — 同じプレフィックスが再利用されています。

キャッシュヒットの判定方法 — 3つの usage フィールド

すべてのレスポンスにおいて、usage は以下を報告します: 合計入力 tokens = 3つの合計値。 cache_read_input_tokens > 0 である限り、コストを節約できています。
非常に役立つセルフチェック:実際にヒットした場合、今回のターンの cache_read_input_tokens は前回のターンの cache_creation_input_tokens と完全に一致します — 前回のターンに入力された内容は1つのブロックとして返され、今回のターンの新規コンテンツのみが今回のターンの書き込みとしてカウントされます。したがって、read ≈ 前回の write はプレフィックス全体がヒットしたことを意味し、read が前回の write より明らかに小さい場合は前半部分のみがヒットしたことを意味します — その間の何かが変更されており、その差分が確認すべき場所の手がかりになります。

最もよくある落とし穴

Fable ファミリーでのセーフティフォールバックはキャッシュを無効化します。 claude-fable-5 / claude-fable-5-1 にはセーフティ分類器が組み込まれています。リクエストが高リスクなコンテンツに該当すると、モデルは拒絶(stop_reason: "refusal" を伴う HTTP 200)するか、Opus ファミリーにフォールバックし、レスポンス内のトップレベルの model には実際に回答したモデルがそのまま反映されます。これはモデル側の正常な動作であり、ゲートウェイの問題ではありません。キャッシュへの影響:フォールバックによってモデル、ひいてはキャッシュキーが切り替わるため、そのターンではそれ以前のターンが書き込んだ内容を読み取ることができません。次のターンが Fable に戻ると、キャッシュヒットが再開されます。拒絶されたターンでも cache_creation_input_tokens が報告される場合がありますが、その書き込みが後から読み取られることはありません。マルチターンのエージェントセッションでは、read が 0 に低下し、write が再び跳ね上がる孤立したターンとして現れます。対応方法:usage だけでミスと判断する前に、レスポンスの model および stop_reason を確認してください。拒絶された入力をそのまま再試行するのではなく、調整してから再送信してください。会話コンテンツをポリシー内に収めることが、これらのミスを最小限に抑える方法です。拒絶、フォールバック、および課金の詳細については、Fable 5.1 ローンチノート を参照してください。
プロンプトキャッシュは Anthropic ネイティブフォーマット(/v1/messages)でのみ動作します。 OpenAI 互換フォーマット(/v1/chat/completions)を通じて Claude を呼び出す場合、何を送信してもキャッシュフィールドは返されません。Claude Code、Cline、Cursor、および同様の高頻度クライアントでは、課金額を抑えたい場合はネイティブフォーマットが必須となります。

画像やファイルもキャッシュ可能 — ただし添付ファイルシナリオではヒットの安定性が低下します

まず、よくある誤解として、Claudeによる画像/ファイルのキャッシュが「信頼できない」わけではありません。 Anthropicは、テキスト、画像、ドキュメントのすべてが対等な条件でプロンプトキャッシュに入ることができると明記しています。 その本当の理由は、前述の厳格な要件にあります。キャッシュはリクエストの完全なプレフィックスと一致する必要があり、画像やファイルのバイトデータもそのプレフィックスの一部となります。ターン間でクライアントによる添付ファイルの組み立て方に変更が生じると、キャッシュは無効化されます。また、Anthropicは特定のケースとして、promptに画像が含まれているかどうかを変更すると、対応するキャッシュが無効化されることを明記しています。

2つのシナリオの違い

Claude Code、Cline、Cursorなどのコーディングクライアントは1列目に該当するため、通常キャッシュヒット率は安定しています。ChatboxやCherry StudioなどのGUIクライアントも、プレーンテキストの会話では同様に安定しています。ヒット率が低下するのは、会話にアップロードされたファイルや大きな画像添付が含まれている場合のみです。

添付ファイルシナリオでヒット率を回復する方法

  1. 添付ファイルを先頭に配置し、順序を固定する — 最もサイズが大きく安定したコンテンツであるため、プレフィックスに配置するのが適切です
  2. 各添付ファイルを一度エンコードしたら同じbase64を再利用する — ターンごとにファイルを再読み込みして再エンコードしないでください(再エンコードで同一のバイトデータが生成されるとは限りません)
  3. ターン間でコンテンツブロックの順序を変更しない — 特に「今回は画像を先頭に、次回は画像を末尾に」といった変更は避けてください
  4. 添付ファイルの後にcache_controlを配置する — これにより、添付ファイルがキャッシュされるプレフィックス内に収まるようになります
  5. 会話の途中で添付ファイルを追加または削除しない — 画像を1つ追加または削除するだけで、それ以降のプレフィックス全体が無効化されます
非技術系の同僚や顧客に説明する場合:Claudeのキャッシュは、テキスト、画像、ファイルを問わず同様にサポートしています。しかし、Chatboxなどのクライアントでは、会話にアップロードされたファイルや大きな画像添付が含まれると、クライアント側でそれらの添付ファイルや周囲のコンテキストを構成する方法がターンごとに変わる可能性があり、その結果、実効キャッシュヒット率が比較的変動しやすくなります。一方、プレーンテキストとコードコンテキストが中心となるコーディングシナリオでは、リクエストのコンテキストが基本的に安定しているため、キャッシュヒットは正常かつ極めて安定して発生します。このように説明することのメリットは、「Claude公式の画像/ファイルキャッシュにバグがある」という印象を与えるのではなく、クライアントがリクエストをどのように組み立てているかに原因があることを明確にできる点にあります。

詳細: マルチターン会話

cache_control を直近のユーザーメッセージの最後のコンテンツブロックに置きます。新しいターンが追加されるたびに、キャッシュされた読み取り範囲は前のターンの末尾まで自動的に拡張されます:
覚えておくべき厳しい制限は2つあります:
  • 1リクエストあたり、4 cache_control ブレークポイントまでです。
  • 各ブレークポイントのプレフィックス検索ウィンドウは 最大20コンテンツブロック前まで です。それより古いものはヒットの対象になりません。つまり、非常に長い会話では、最新のターンだけをマークしても、以前の履歴全体はカバーできません。
よくあるパターン: ツール定義、system prompt、長いドキュメント、最新の会話ターンそれぞれに1つずつブレークポイントを置き、4つのスロットをすべて使って、異なる頻度で変更されるセクションが互いのキャッシュを無効化しないようにします。

APIYI とキャッシュについて

APIYI はキャッシュ項目をエンドツーエンドで転送します。 あなたが送信したcache_controlは、上流の Claude(AWS Claude または Claude 公式リレー)にそのまま渡され、返されたcache_creation_input_tokens / cache_read_input_tokensはそのままあなたに返されます。コード側で特別な対応は不要です。
自己検証する方法:
  1. 1回目のリクエストでは、usage.cache_creation_input_tokens > 0(書き込み成功)となります。
  2. 数秒以内に、同じプレフィックスをもう一度送信すると、usage.cache_read_input_tokens > 0(ヒット)が表示されるはずです。
  3. 課金ダッシュボードでは、キャッシュ書き込み と キャッシュ読み取り が個別に明細化され、公式と同じ倍率(1.25× / 2× / 0.1×)で表示されます。

まとめ

1. マークを付ける

コンテンツブロックでの cache_control: {"type": "ephemeral"} — プレーン文字列の content は決してキャッシュされません。

2. 十分な長さ

Opus 5 ≥ 512; Sonnet 5 / Sonnet 4.6 ≥ 1,024; Opus 4.7 ≥ 2,048; Opus 4.6 / Haiku 4.5 ≥ 4,096 tokens。これらに満たない場合は通知なくスキップされます。

3. プレフィックスの安定性

前半を安定させ、後半に変動要素を配置します。1文字のズレでもキャッシュヒットしなくなります。

4. 使用量の確認

実際にコストを節約できたことを証明できるのは cache_read_input_tokens > 0 のみです。これは前のターンの cache_creation_input_tokens とほぼ同等になるはずです。

5. 添付ファイルを固定する

画像やファイルもキャッシュされますが、ターンごとに添付ファイルを再構築するとプレフィックスが崩れてしまいます — 先頭に配置し、順序を維持し、エンコードは1回だけにしてください。

関連リンク