Skip to main content
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価格()に対して: 損益分岐点:
  • 5分TTL: 同じプレフィックスを 2回再利用 するだけで損益分岐します(1.25 + 0.1 = 1.35、キャッシュなしの2回のリクエストより安いです)。
  • 1時間TTL: 3回再利用 で損益分岐します(2 + 0.2 = 2.2、3回のリクエストより安いです)。
TTLはスライディングウィンドウです。キャッシュヒットするたびに有効期限のタイマーがリセットされるため、アクティブな会話が途中で期限切れになることはありません。TTLを超えて本当にアイドル状態になった場合のみ、エビクションが発生します。

向いているケース

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

向いていないケース

  • すべてのpromptが最初の文字から異なる
  • 全体が短く、モデルごとの最小値(下記)を一度も超えない

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 は次を報告します: input token の合計 = 3 つすべての合計です。 cache_read_input_tokens > 0である限り、コストを節約できます。

最も一般的な落とし穴

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

詳細: マルチターン会話

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"} コンテンツブロック上で — plain-string 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 だけが、実際にコストを節約できたことを証明します。

関連リンク