本ガイドの例では
gemini-3.6-flash を使用します。ほかのモデルが Context Cache に対応しているかどうかは、プラットフォームのモデル説明および料金ページを参照してください。適したユースケース
複数のリクエストで同じ長いコンテンツを繰り返し送信する場合、次のような安定したプレフィックスをキャッシュできます。- 非常に長い system prompt
- 固定されたナレッジベースまたは製品ドキュメント
- マルチターン会話内の変化しない履歴メッセージ
- 繰り返し使用するツール定義と説明
基本的な使い方
安定したプレフィックスの最後のメッセージにある content block へcache_control を追加します。
ttl を省略した場合は、デフォルトで 5m が使用されます。メッセージ構造
次の構造を推奨します。cache_control を設定したメッセージと、それ以前のすべてのメッセージがキャッシュプレフィックスを構成します。その後ろには、少なくとも 1 件のリアルタイムメッセージが必要です。
OpenAI 互換リクエストの例
キャッシュ作成用の API を別途呼び出す必要はありません。
cache_control は「キャッシュ境界」と「キャッシュ有効期間」の両方を表します。ネイティブ Gemini リクエストの例
ネイティブ Gemini のgenerateContent インターフェースでも、contents[].parts[] への cache_control の追加に対応しています。
cache_control は、プラットフォームが Gemini リクエスト形式に追加した拡張フィールドです。プラットフォームは境界を認識すると、転送前にこのフィールドを削除し、キャッシュコンテンツ(cachedContent)を自動的に作成または再利用します。
ストリーミングインターフェースでは同じリクエストボディを使用し、URL だけを次のように変更します。
systemInstruction、境界より前の contents、TTL、tools を変更せず、境界より後ろのリアルタイムコンテンツだけを変更します。
作成と再利用の流れ
cache_control を含むリクエストを初めて送信する場合:
キャッシュの再利用
再度リクエストする際は、次の内容を変更しないでください。- モデル
cache_controlより前のすべてのメッセージcache_control.ttl- ツール定義(tools を使用する場合)
- ネイティブ Gemini リクエストの
systemInstruction
- 安定したプレフィックス内のテキストまたはメッセージ順序の変更
- モデルの変更
5mから1hへの変更- tools またはツールパラメータ定義の変更
- 異なる API ユーザーまたはチャネルの使用
Python の例
stable_messages を再利用し、最後の user メッセージだけを置き換えます。
キャッシュヒットの確認
OpenAI 互換レスポンス
レスポンス内の次の値を確認します。
システムはキャッシュを作成してから同じモデル呼び出し内で参照できるため、初回リクエストでも
cached_tokens が大きな値になる場合があります。
ネイティブ Gemini レスポンス
レスポンス内のusageMetadata.cachedContentTokenCount を確認します。
streamGenerateContent は、SSE レスポンスフレーム内に同じ usageMetadata を返します。クライアントはこのフィールドを含むレスポンスフレームを読み取り、最初のテキスト部分だけを確認しないようにしてください。
利用上の推奨事項
よくある質問
ネイティブ Gemini リクエスト形式でキャッシュを自動作成できますか?
ネイティブ Gemini リクエスト形式でキャッシュを自動作成できますか?
はい。
generateContent と streamGenerateContent は同じ cache_control 構造を使用します。境界は必ず contents[].parts[] 内に配置し、境界を設定した content の後ろに少なくとも 1 件のリアルタイム content を残す必要があります。リクエストでネイティブの cachedContent リソース名を明示的に指定している場合、プラットフォームはユーザーが指定したリソースを優先し、キャッシュの自動作成を行いません。キャッシュがヒットしないのはなぜですか?
キャッシュがヒットしないのはなぜですか?
一般的な原因は次のとおりです。
- 安定したプレフィックスが前回のリクエストと完全には一致していない
- TTL の有効期限が切れている
- モデルまたは tools を変更した
- キャッシュコンテンツがモデルで必要な最小 token 数に達していない
cache_controlを最後のメッセージに配置し、リアルタイム質問を残していない
cache_control を最後のメッセージに配置できますか?
cache_control を最後のメッセージに配置できますか?
推奨しません。通常、最後のメッセージは現在のリアルタイム質問であり、キャッシュすべきではありません。境界より後ろにリアルタイムメッセージがない場合、リクエストは通常モードで実行されます。
ほかの TTL を設定できますか?
ほかの TTL を設定できますか?
できません。現在対応しているのは
5m と 1h のみです。ほかの値を指定すると HTTP 400 が返されます。複数のキャッシュ境界を設定できますか?
複数のキャッシュ境界を設定できますか?
できます。ただし、すべての境界で同じ TTL を使用する必要があり、システムは最後の境界を使用します。通常は、構造を分かりやすくするため、リクエストごとに境界を 1 つだけ設定することを推奨します。
キャッシュが利用できないとリクエストは失敗しますか?
キャッシュが利用できないとリクエストは失敗しますか?
通常は失敗しません。キャッシュを作成または再利用する条件を満たしていない場合、システムは自動的に通常のリクエストを使用します。ただし、無効な TTL や異なる TTL の混在など、パラメータに誤りがある場合を除きます。
モデルで Context Cache が有効になっていない場合はどうなりますか?
モデルで Context Cache が有効になっていない場合はどうなりますか?
リクエストは自動的に通常モードで実行され、明示的なキャッシュは作成されず、キャッシュストレージ料金も発生しません。通常の入力、出力、および存在する可能性のある暗黙的キャッシュについては、そのモデルの従来のルールに従って引き続き課金されます。
cache_write_tokens が 0 なのはなぜですか?
cache_write_tokens が 0 なのはなぜですか?
これは Gemini コンテキストキャッシュの正常な動作です。キャッシュ作成コストは個別のキャッシュストレージ料金として記録され、OpenAI/Claude 形式の
cache_write_tokens でキャッシュ作成量を表すことはありません。cached_tokens が 0 より大きければ、必ず明示的なキャッシュが作成されたということですか?
cached_tokens が 0 より大きければ、必ず明示的なキャッシュが作成されたということですか?
必ずしもそうではありません。システム自体の暗黙的キャッシュがヒットする場合もあります。通常のユーザーはキャッシュから読み取った token を見て、今回のリクエストでキャッシュ読み取りが適用されたかどうかを判断できます。明示的なキャッシュ作成料金を確認するには、プラットフォームの使用量ログにある Context Cache storage の記録を参照してください。
キャッシュ料金はどのように計算されますか?
キャッシュ料金はどのように計算されますか?
キャッシュ作成時に、一度だけキャッシュストレージ料金が発生する場合があります。キャッシュ使用時は、ヒットした token がキャッシュ読み取り価格で課金されます。具体的な価格は、プラットフォームに表示されるモデル料金を参照してください。