Skip to main content
Claude モデルごとに最小キャッシュ可能トークンのしきい値が異なり(512 / 1,024 / 2,048 / 4,096 のいずれか)、モデルバージョンの新旧とは比例しません。例えば Claude Opus 4.8 は 1,024、Claude Opus 4.7 は 2,048、Claude Opus 4.6 / 4.5 と Claude Haiku 4.5 は 4,096 です。完全な区分は後述の「キャッシュの制限」を参照してください。しきい値を下回る内容は cache_control を付けてもキャッシュに書き込まれず、エラーにもなりません。
Messages APIを使用してプロンプトキャッシュを実装する方法の例を以下に示します。
応答:
この例では、「高慢と偏見」の全文がcache_controlパラメータを介してキャッシュされています。これにより、この長いテキストを複数回のAPI呼び出しで再利用でき、毎回再処理する必要がなくなります。ユーザーメッセージを変更するだけで、キャッシュされたコンテンツを利用しながら、この本に関するさまざまな質問をすることができ、応答速度が向上し、効率が向上します。

プロンプトキャッシュの仕組み

プロンプトキャッシュが有効なリクエストを送信すると、次のようになります。
  1. システムは、最近のクエリで指定されたキャッシュブレークポイントより前のプロンプトプレフィックスがすでにキャッシュされているかどうかを確認します。
  2. 見つかった場合、キャッシュされたバージョンが使用され、処理時間とコストが削減されます。
  3. そうでない場合、システムは完全なプロンプトを処理し、応答の開始時にプレフィックス部分をキャッシュします。
これは、次のようなシナリオで特に役立ちます。
  • 大量の例を含むプロンプト
  • 大量のコンテキストまたは背景情報
  • 一貫した指示を持つ繰り返しのタスク
  • 長時間の複数ターン会話
キャッシュのデフォルトの有効期間は5分で、キャッシュされたコンテンツが使用されるたびに更新されます。また、より長いキャッシュ期間が必要なシナリオ向けに、1時間キャッシュもサポートしています。

プロンプトキャッシュは完全なプレフィックスをキャッシュします

プロンプトキャッシュは、toolssystemmessagesを順序通りに含み、cache_controlでマークされたコンテンツブロックまで、プロンプト全体を参照します。

よくある間違い:キャッシュを「書き込むだけで読み取れない」

最もよくある失敗のシナリオは、リクエストごとにcache_creation_input_tokensが大きい(ずっとキャッシュを書き込んでいる)のに、cache_read_input_tokensが常に0(一度も読み取れない)というもので、まったくコスト削減になっていません。 根本原因はただ一つ:キャッシュブレークポイント(cache_control)より前のコンテンツが、2回のリクエストの間に変化していることです。キャッシュヒットには、ブレークポイントおよびそれより前のすべてのコンテンツ(toolssystemmessagesの順)がバイト単位で完全に一致していることが必要です。ブレークポイントより前で一文字でも変わると、プレフィックスキャッシュ全体が無効になり、再度書き込まれます。

❌ 誤った書き方:毎回変化する質問をブレークポイントの前に置く

次のターンで質問を「请列出其中的关键风险点。」に変えると、ブレークポイントより前のコンテンツが変化し、その後ろにある大きなドキュメントのキャッシュも読み取れなくなります。

✅ 正しい書き方:大きなドキュメントを最前に + ブレークポイント + 質問を最後に

次のターンでは、この最後の質問ブロックのみを置き換える(大きなドキュメントはそのまま変更しない)ことで、キャッシュにヒットします。

実測比較(claude-opus-4-6、2回の呼び出しは数秒間隔)

ポイント:
  1. 固定不変の大きなブロック(参考ドキュメント、長いコンテキスト)をmessagesのユーザーメッセージの最前に置き、cache_controlをその末尾に付けます。このコンテンツは一文字も変更してはいけません
  2. 毎回変化する質問/指示はブレークポイントより後(同じuserメッセージ内の大きなドキュメントの後、または後続のメッセージ)に置きます。複数ターンの会話では後ろに追記するだけにし、過去のメッセージを戻って修正しないでください。
  3. thinkingを有効にする場合、過去のアシスタントのターンの思考ブロックはそのまま返送する必要があります。さもないとプレフィックスが同様に途切れます(後述の「キャッシュできないコンテンツ」を参照)。
  4. ブロックが最小キャッシュしきい値(モデルにより 512〜4,096 トークンと異なります。後述の「キャッシュの制限」を参照)未満の場合、cache_controlをマークしてもキャッシュに書き込まれません。これは想定どおりの動作です。

キャッシュの料金

プロンプトキャッシュには新しい料金体系が採用されています。以下の表は、サポートされている各モデルの100万トークンあたりの価格を示しています。 注意:
  • 5分キャッシュ書き込みトークン価格は基本入力トークン価格の1.25倍です。
  • 1時間キャッシュ書き込みトークン価格は基本入力トークン価格の2倍です。
  • キャッシュ読み取りトークン価格は基本入力トークン価格の0.1倍です。
  • 通常の入力および出力トークンはプラットフォームの標準料金で課金されます。

プロンプトキャッシュの実装方法

サポートされているモデル

Anthropic Claude の全モデルがプロンプトキャッシュをサポートしています。Claude Opus 4.8 / 4.7 / 4.6 / 4.5、Claude Sonnet 5 / 4.6 / 4.5、Claude Haiku 4.5、Claude Fable 5 などの現行モデルに加え、Claude Opus 4、Sonnet 4、Sonnet 3.7、Sonnet 3.5、Haiku 3.5、Haiku 3、Opus 3 などの旧モデルも含まれます。各モデルの最小キャッシュ可能トークンのしきい値は後述の「キャッシュの制限」を参照してください。

自動キャッシュ(トップレベル cache_control)

リクエストボディの最上位に cache_control フィールドを 1 つ追加するだけで自動キャッシュを有効にできます。システムはキャッシュブレークポイントを最後のキャッシュ可能なブロックに自動的に適用し、会話の増加に合わせて自動的に前方へ移動させるため、マルチターン会話のローリングキャッシュに適しています。自動ブレークポイントは 4 つのブレークポイントスロットのうち 1 つを占有し、ブロック単位の明示的ブレークポイントと組み合わせて使用できます。Amazon Bedrock は自動キャッシュに対応していません。
キャッシュ境界を正確に制御したい場合は、後述のブロック単位の明示的ブレークポイントを使用してください。

プロンプト構造の構築

静的コンテンツ(ツール定義、システム指示、コンテキスト、例)をプロンプトの先頭に配置します。cache_controlパラメータを使用して、キャッシュする再利用可能なコンテンツの終了位置をマークします。 キャッシュプレフィックスは、toolssystem、そしてmessagesの順に作成されます。 cache_controlパラメータを使用すると、最大4つのキャッシュブレークポイントを定義でき、異なる再利用可能な部分を個別にキャッシュできます。各ブレークポイントについて、システムは以前の位置のキャッシュヒットを自動的にチェックし、見つかった場合は最長の合致するプレフィックスを使用します。

キャッシュの制限

最小キャッシュ可能プロンプト長はモデルごとに異なり、バージョンの新旧とは比例しません。 cache_controlがマークされていても、短いプロンプトはキャッシュできません。この量より少ないトークンをキャッシュしようとするリクエストは、キャッシュを使用せずに処理されます。プロンプトがキャッシュされたかどうかを確認するには、応答の使用状況フィールドを確認してください。 同時リクエストの場合、キャッシュエントリは最初の応答が開始された後にのみ利用可能になることに注意してください。並列リクエストのキャッシュヒットが必要な場合は、後続のリクエストを送信する前に最初の応答を待ってください。 現在サポートされているキャッシュ生存期間:
  • “ephemeral”:デフォルトの5分間の有効期間
  • 1時間キャッシュcache_control"ttl": "1h"を設定します。より長いキャッシュ期間が必要なシナリオ向けです

1時間キャッシュ期間

より長いキャッシュ期間が必要なシナリオ向けに、1時間キャッシュオプションを提供しています。 cache_controlの定義にttlを含めるだけでよく、追加のリクエストヘッダーは不要です:

1時間キャッシュを使用するタイミング

1時間キャッシュは特に以下の場合に役立ちます。
  • バッチ処理ジョブ:共通のプレフィックスを持つ大量のリクエストを処理する場合
  • 長時間のセッション:長い指示やアップロードされたドキュメントを含む、長期間にわたってコンテキストを維持する必要がある会話
  • 大規模なドキュメント分析:同じドキュメントに対して複数回異なる種類の分析を行う場合
  • コードベースの質問応答:長期間にわたって同じコードベースに対して複数回クエリを実行する場合

異なるTTLの組み合わせ

同じリクエスト内で異なるキャッシュ期間を組み合わせることができます。

キャッシュ可能なコンテンツ

リクエスト内の各ブロックはcache_controlでキャッシュを指定できます。これには以下が含まれます。
  • ツール:tools配列内のツール定義
  • システムメッセージ:system配列内のコンテンツブロック
  • メッセージ:messages.content配列内のコンテンツブロック。ユーザーとアシスタントの会話ターンを含む
  • 画像とドキュメント:ユーザー会話ターン中のmessages.content配列内のコンテンツブロック
  • ツール使用とツール結果:ユーザーとアシスタント会話ターン中のmessages.content配列内のコンテンツブロック
これらの要素はすべて、cache_controlタグを使用して、その部分のリクエストのキャッシュを有効にできます。

キャッシュできないコンテンツ

ほとんどのリクエストブロックはキャッシュできますが、いくつかの例外があります。
  • 思考ブロックcache_controlを使用して直接キャッシュすることはできません。ただし、思考ブロックが以前のアシスタントのターンに表示された場合、他のコンテンツと一緒にキャッシュできます。この方法でキャッシュされた場合、キャッシュから読み取ると入力トークンとしてカウントされます。
  • サブコンテンツブロック(参照など)はそれ自体を直接キャッシュすることはできません。代わりに、トップレベルのブロックをキャッシュします。
  • 空のテキストブロックはキャッシュできません。

キャッシュパフォーマンスの追跡

応答内のこれらのAPI応答フィールド(またはストリーミング時のmessage_startイベント)を介してキャッシュパフォーマンスを監視します。
  • cache_creation_input_tokens: 新しいキャッシュエントリが作成されたときにキャッシュに書き込まれたトークン数
  • cache_read_input_tokens: キャッシュから取得されたトークン数
  • input_tokens: キャッシュから読み取られなかった、またはキャッシュの作成に使用された入力トークン数

効果的なキャッシュのベストプラクティス

プロンプトキャッシュのパフォーマンスを最適化するには:
  • システム指示、背景情報、大規模なコンテキスト、または頻繁に使用されるツール定義など、安定した再利用可能なコンテンツをキャッシュします。
  • 最高のパフォーマンスを得るために、キャッシュコンテンツをプロンプトの先頭に配置します。
  • 異なるキャッシュ可能なプレフィックス部分を区切るために、キャッシュブレークポイントを戦略的に使用します。
  • キャッシュヒット率を定期的に分析し、必要に応じて戦略を調整します。
  • 長期的に使用するコンテンツの場合、より良い費用対効果のために1時間キャッシュの使用を検討します。

さまざまなユースケースの最適化

シナリオに応じてプロンプトキャッシュ戦略を調整します。
  • 会話エージェント:長時間の会話のコストと遅延を削減します。特に、長い指示やアップロードされたドキュメントを含む会話の場合。
  • プログラミングアシスタント:プロンプトに関連する部分やコードベースの要約バージョンを保持することで、自動補完とコードベースの質問応答を改善します。
  • 大規模ドキュメント処理:応答の遅延を増やすことなく、プロンプトに完全な長文資料(画像を含む)を埋め込みます。
  • 詳細な指示セット:Claudeの応答を微調整するために、広範な指示、手順、および例のリストを共有します。開発者は通常、プロンプトに1つまたは2つの例を含めますが、プロンプトキャッシュを使用すると、20以上の高品質な回答の多様な例を含めることで、より良いパフォーマンスを得ることができます。
  • エージェントツール使用:複数のツール呼び出しと反復的なコード変更を含むシナリオのパフォーマンスを向上させます。各ステップは通常、新しいAPI呼び出しを必要とします。
  • 書籍、論文、ドキュメント、ポッドキャストの記録、その他の長文コンテンツとの会話:プロンプトにドキュメント全体を埋め込むことで、ユーザーが質問できるようにします。

よくある問題の解決

  • キャッシュ部分が異なる呼び出し間で完全に同じであり、同じ位置にcache_controlがマークされていることを確認してください。
  • 呼び出しがキャッシュの有効期間内(5分または1時間)であることを確認してください。
  • tool_choiceと画像の有無が呼び出し間で一貫していることを確認してください。
  • キャッシュしたトークン数が最小要件を満たしていることを確認してください。
  • システムはキャッシュブレークポイントより前の位置のキャッシュされたコンテンツを使用しようとしますが、追加のcache_controlパラメータを使用して、プロンプトの前の部分のキャッシュを確実に検索できます。これは、非常に長いコンテンツブロックのリストを含むクエリに役立つ場合があります。
tool_choiceまたはプロンプト内の任意の場所の画像の有無を変更すると、キャッシュが無効になり、新しいキャッシュエントリが作成されることに注意してください。

キャッシュの保存と共有

  • 組織の分離: キャッシュは組織間で分離されています。異なる組織は、同じプロンプトを使用してもキャッシュを共有することはありません。
  • 正確な一致: キャッシュヒットには、cache_controlでマークされたブロックの前のすべてのテキストと画像、およびそれ自体を含む、100%同じプロンプトセグメントが必要です。キャッシュの読み取りと作成中に、同じブロックをcache_controlでマークする必要があります。
  • 出力トークンの生成: プロンプトキャッシュは出力トークンの生成には影響しません。受け取る応答は、プロンプトキャッシュを使用しない場合とまったく同じです。

クライアント / プラットフォームでClaudeキャッシュを有効にする

多くのクライアントのインターフェースにはcache_controlを直接入力する場所がなく、それぞれの「シンタックスシュガー」やスイッチで代わりに注入します。基盤となるルールは上記とまったく同じです——キャッシュされるプレフィックスは毎ターン一文字も変えてはならず、変化するコンテンツはキャッシュブレークポイントより後に置くことです。さもないと「書き込むだけで読み取れない」状態になります(上記の「よくある間違い」を参照)。

Dify(Aihubmixプラグイン経由)

AihubmixのDifyプラグインは、Anthropic公式プラグインのシンタックスシュガーを継承しており、2ステップで有効にできます。
  1. キャッシュしたいプロンプト(固定不変のシステムプロンプト / 長いコンテキスト)を<cache>…</cache>で囲むと、プラグインがその箇所を自動的にcache_controlブレークポイントに変換します。
  2. モデルパラメータで「大きなメッセージの自動キャッシュしきい値」を正の整数に設定します。コンテンツがそのトークンしきい値に達して初めて実際にキャッシュが書き込まれます(下記「キャッシュの制限」の最小キャッシュ制約を依然として受けます。Opus 4.5/4.6、Haiku 4.5は4096トークン)。0または空欄に設定すると無効になります。
プラグインのインストールと設定についてはDifyプラグインを参照してください。

Cherry Studio

Cherry StudioはAihubmix経由でClaudeを呼び出す際、デフォルトではキャッシュを有効にしていません(「キャッシュトークンしきい値」のデフォルトは0)。プロバイダーの「API設定」で有効にする必要があります。
  1. Aihubmixプロバイダー名の右側にある歯車をクリックして「API設定」(API Settings)を開きます。
AihubmixプロバイダーのAPI設定を開く
  1. 以下の3項目を設定すると、クライアントがそれに基づいてClaudeに自動的にcache_controlを注入します。
  • キャッシュトークンしきい値(Cache Token Threshold):コンテンツがそのトークン数を超えた場合のみキャッシュブレークポイントを注入します(正の数で有効、0または空欄で無効)。
  • システムメッセージをキャッシュ(Cache System Message):有効にするとsystemメッセージにキャッシュブレークポイントを付けます(固定の長いシステムプロンプトのキャッシュに適しています)。
  • 最後のN件のメッセージをキャッシュ(Cache Last N Messages):直近のN件のメッセージにキャッシュブレークポイントを付けます(複数ターン会話のローリングキャッシュに適しています)。
API設定でキャッシュトークンしきい値、システムメッセージをキャッシュ、最後のN件のメッセージをキャッシュを設定する
接続手順についてはCherry Studioを参照してください。
上記のしきい値はクライアントが「いつブレークポイントを注入するか」を決めるだけで、Anthropicの最小キャッシュ要件を変更するものではありません。実際の書き込みには、キャッシュされるコンテンツが最小キャッシュトークン(Opus 4.5/4.6、Haiku 4.5は4096)に達している必要があります。毎ターン変化するコンテンツ(ローテーションする指示など)をキャッシュされるシステムプロンプトに入れると、同様に「書き込むだけで読み取れない」状態になります。

よくある質問(FAQ)

キャッシュを書き込んでいる(cache_creation_input_tokensが大きい)のに、なぜずっと読み取れない(cache_read_input_tokensが0)のですか?

キャッシュブレークポイント(cache_control)より前のコンテンツが2回のリクエストの間に変化したためです。ヒットには、ブレークポイントおよびそれより前のすべてのコンテンツがバイト単位で一致している必要があります。毎ターン変化するコンテンツをブレークポイントの前に置くと、プレフィックスキャッシュ全体が無効になり、毎ターン再書き込みされます。固定コンテンツを最前に、変化するコンテンツをブレークポイントより後に置けば解決します。詳しくは上記の「よくある間違い」を参照してください。

キャッシュには最低どれくらいのトークンが必要ですか?

最小キャッシュ長を下回るコンテンツは、cache_controlをマークしてもキャッシュされません。Claude Opus 4.5/4.6、Haiku 4.5は4096トークン、その他のClaudeモデルは多くが1024トークン、Haiku 3/3.5は2048トークンです。詳しくは前述の「キャッシュの制限」を参照してください。

キャッシュの有効期間はどれくらいですか?1時間に変更できますか?

デフォルトは5分で、ヒットするたびに無料で更新されます。より長くしたい場合はcache_control"ttl": "1h"を設定するだけでよく、追加のリクエストヘッダーは不要です。1時間キャッシュの書き込みは基本入力価格の2倍で課金されます。詳しくは前述の「1時間キャッシュ期間」を参照してください。

Dify / Cherry Studioではどうやってキャッシュを有効にしますか?

これらのクライアントではcache_controlを直接入力しません。Difyはキャッシュしたいコンテンツを<cache>…</cache>で囲み、「大きなメッセージの自動キャッシュしきい値」を設定します。Cherry Studioは「API設定」で「キャッシュトークンしきい値 / システムメッセージをキャッシュ / 最後のN件のメッセージをキャッシュ」を設定します。詳しくは上記の「クライアント / プラットフォームでClaudeキャッシュを有効にする」を参照してください。

異なるモデルのサポート状況

  • プロンプトキャッシュのサポートは、モデル自体に依存します。
  • モデル自体がサポートしており、関連するパラメータを明示的に宣言する必要がない場合、OpenAI互換形式での転送はサポートされます。
  • OpenAIはデフォルトでPrompt Cachingをサポートしており、自動的に有効になります(プレフィックス ≥1024 Token)。GPT-5.6より前のモデルはキャッシュ書き込みに追加課金がなく、非アクティブ5〜10分後に自動的に削除されます。GPT-5.6以降はキャッシュ書き込みが入力価格の1.25倍、読み取りが0.1倍で課金され、キャッシュは最低30分間保持され、明示的キャッシュブレークポイントに対応します。詳しくは GPT プロンプトキャッシュ を参照してください。
  • Claudeはネイティブのcache_control: { type: "ephemeral" }宣言が必要です。キャッシュ料金は通常の入力の1.25倍(5分)または2倍(1時間)で、キャッシュされたトークンの読み取り費用は0.1倍です。有効期間は5分または1時間です。ドキュメント
  • Deepseek V3とR1はネイティブでサポートされており、キャッシュ料金は通常の入力の1倍で、キャッシュされたトークンの読み取り費用は0.1倍です。ドキュメント
  • Geminiモデルは暗黙的なキャッシュをサポートしています。
    • 暗黙的なキャッシュ:すべてのGemini 2.5モデルでデフォルトで有効になっています。リクエストがキャッシュにヒットした場合、コスト削減が自動的に適用されます。この機能は2025年5月8日から有効です。コンテキストキャッシュの最小入力トークン数:Gemini 2.5 Flashは1,024、Gemini 2.5 Proは2,048。
      • 暗黙的なキャッシュヒット率を高めるヒント:
        • 共通の大きなコンテンツブロックをプロンプトの先頭に配置します。
        • 短期間にプレフィックスが類似するリクエストを送信してみてください。
      • 応答オブジェクトのusage_metadataフィールドで、キャッシュヒットしたトークン数を確認できます。
      • コスト削減は、プリフィルキャッシュヒット数に基づいて測定されます。プリフィルキャッシュとYouTubeビデオのプリプロセスキャッシュのみが暗黙的なキャッシュをサポートしています。

最終更新日:2026-07-10