Gemini 明示的キャッシュ(cachedContents)
Gemini のキャッシュには2種類あります:
- 暗黙的キャッシュ(自動)— モデルが繰り返しのプロンプトプレフィックスを自動的に検出して再利用します。設定は不要です。これは プロンプトキャッシュ で説明しているデフォルトの挙動で、ヒットは「ベストエフォート」(best-effort)です。プレフィックスにわずかな変化があってもヒットしない場合があります。
- 明示的キャッシュ(本ページ)— 大きなコンテキストを能動的にキャッシュオブジェクトとして作成し、
cachedContents/{id}というハンドルを取得して、以降のgenerateContentリクエストで明示的に参照します。ヒットは確定的で、キャッシュが期限切れでない限り、参照すれば必ずヒットします。
繰り返し使用する内容の安定した大きなコンテキスト(長いドキュメント、コードベース、ナレッジベース、固定の system 指示)があり、ヒット率を制御可能にし、課金を予測可能にしたい場合は、明示的キャッシュを使ってください。
OfoxAI は Gemini ネイティブの cachedContents の 作成 / 参照 / 取得 / 削除 をサポートし、Google GenAI SDK と互換性があります。エンドポイントレベルのリファレンスは cachedContents API を参照してください。
明示的キャッシュを使うべき場面
| シナリオ | 推奨 |
|---|---|
| 大きな固定コンテキストに対する繰り返しの Q&A(ドキュメント QA、コードアシスタント) | ✅ 明示的キャッシュ |
| 確実にヒットさせたく、たまのミスも許容できない | ✅ 明示的キャッシュ |
| 短く・低頻度で・プレフィックスが変動するリクエスト | ❌ 暗黙的キャッシュで十分。キャッシュオブジェクトの管理は不要 |
| コンテキストが毎回変わる | ❌ キャッシュする意味がない |
明示的キャッシュは、キャッシュする内容が最小トークン閾値(モデルによりますが、おおむね 2,048〜4,096 token 以上)に達している必要があります。内容が小さすぎると作成に失敗するか、メリットがありません。
エンドポイント
OfoxAI は Gemini ネイティブプロトコルのもとで、完全な cachedContents エンドポイントを提供します:
POST https://api.ofox.ai/gemini/v1beta/cachedContents # 作成
GET https://api.ofox.ai/gemini/v1beta/cachedContents/{id} # 取得
DELETE https://api.ofox.ai/gemini/v1beta/cachedContents/{id} # 削除キャッシュを参照してコンテンツを生成する場合は、標準の generateContent エンドポイントを使い、リクエストボディに cachedContent を追加します:
POST https://api.ofox.ai/gemini/v1beta/models/{model}:generateContent認証
他の Gemini エンドポイントと同様に、x-goog-api-key Header を使用します:
x-goog-api-key: <あなたの OFOXAI_API_KEY>フル ワークフロー
以下では完全なフローを示します:キャッシュ作成 → キャッシュを参照して生成 → キャッシュ削除。
1. キャッシュを作成する
再利用したい大きなコンテキストを contents に入れ、model と ttl(存続時間)を指定します:
Python
from google import genai
from google.genai import types
client = genai.Client(
api_key="<あなたの OFOXAI_API_KEY>",
http_options={"api_version": "v1beta", "base_url": "https://api.ofox.ai/gemini"},
)
# 繰り返し使用する大きなドキュメント(最小トークン閾値に達している必要があります)
LONG_DOCUMENT = open("knowledge_base.txt").read()
cache = client.caches.create(
model="google/gemini-3.1-pro-preview",
config=types.CreateCachedContentConfig(
contents=[LONG_DOCUMENT],
ttl="600s", # キャッシュは10分間存続
),
)
print(cache.name) # cachedContents/xxxxxxxx —— 以降の参照に使うハンドル返ってくる name(cachedContents/xxxxxxxx の形式)がキャッシュハンドルです。以降の参照と管理のために保存しておいてください。
2. キャッシュを参照して生成する
generateContent リクエストで cachedContent を使ってキャッシュハンドルを参照します。contents には今回新しく追加する質問だけを入れます:
Python
response = client.models.generate_content(
model="google/gemini-3.1-pro-preview",
contents="上記のドキュメントに基づいて、要点を3つまとめてください",
config=types.GenerateContentConfig(
cached_content=cache.name, # キャッシュを参照
),
)
print(response.text)
# キャッシュヒット:キャッシュ部分はより低い「読み取り」料金で課金されます
print(response.usage_metadata.cached_content_token_count)ヒットすると、レスポンスの usageMetadata.cachedContentTokenCount にキャッシュを経由した token 数が表示されます。同じキャッシュは何度でも参照でき、期限切れになるまで毎回確定的にヒットします。
3. 取得と削除
キャッシュのメタ情報を取得する、または不要になったときに能動的に削除します(TTL の満了を待つ必要はありません):
Python
# 取得
info = client.caches.get(name=cache.name)
print(info.expire_time)
# 削除
client.caches.delete(name=cache.name)取得 / 削除では model を再度渡す必要はありません。OfoxAI はキャッシュハンドルだけでこのキャッシュを特定できます。
ライフサイクルと TTL
作成時に ttl で存続時間を指定します。形式は s で終わる秒数の文字列です(例:"600s")。
| パラメータ | 値 |
|---|---|
| 最小 / デフォルト TTL | 600s(10分) |
| 最大 TTL | 3600s(1時間) |
- TTL 内であれば、キャッシュは繰り返し参照でき、確定的にヒットします。
- TTL が満了するとキャッシュは自動的に無効化され、再度参照するとエラーになります(キャッシュはもう存在しません)。
- いつでも能動的に
deleteして早期に解放できます。
TTL が満了した、または削除済みのキャッシュを参照すると、リクエストは失敗します。クライアント側で「キャッシュ無効化」のケースを処理してください(エラーをキャッチしてキャッシュを再作成するか、通常のリクエストにフォールバックします)。
課金
明示的キャッシュは token 単位で透明に課金され、3つの部分に分かれます:
| ステージ | 計算式 | 説明 |
|---|---|---|
| キャッシュ作成 | totalTokenCount × cache_write 単価 | 「キャッシュ書き込み」料金で課金されます。totalTokenCount は作成レスポンスの usageMetadata から得られ、キャッシュされた token 数を表します |
| 参照ヒット | cachedContentTokenCount × cache_read 単価 | キャッシュ部分は「キャッシュ読み取り」料金で課金されます。標準入力価格の約 0.10x で、全量を再送するよりも大幅に安くなります |
| 参照時の新規コンテンツ | 今回新しく追加した prompt / 出力は標準価格 | つまり、毎回あなたが投げる新しい質問と、モデルの新しい回答です |
収益モデル:作成時に一度「書き込み」料金を払えば、以降はキャッシュされた内容を参照するたびに低価格の「読み取り」料金で課金され、「コンテキスト全体を全価格で再送する」コストを節約できます。参照回数が多いほど、お得になります。 各モデルの cache_write / cache_read 単価は モデルカタログ とコンソールの使用量統計を基準としてください。
OfoxAI での強化:確定的ルーティング
OfoxAI は複数の GCP リージョン / Vertex プロジェクト間でロードバランシングを行います。明示的キャッシュは region-scoped(リージョン紐付け) です:キャッシュを作成した GCP プロジェクトと同じプロジェクトで参照しなければならず、そうでないと 404 になります。
OfoxAI はこれを自動的に処理します:キャッシュ作成時にそのキャッシュが紐付く上流インスタンスを記録し、以降はキャッシュハンドルから逆引きして同じ上流へハードロックします。参照リクエストが user 識別子を持つかどうか、負荷がどうスケジューリングされるかに関わらず、参照はキャッシュを作成したプロジェクトへ正確にルーティングされ、ドリフトはゼロです。基盤となるリージョン分布を気にする必要はありません。
キャッシュの帰属には越権保護があります:キャッシュハンドルは、それを作成した API Key(および同じ帰属)からのみ参照 / 取得 / 削除でき、アカウントをまたいだアクセスは拒否されます(403)。
明示的キャッシュ vs 暗黙的キャッシュ
| 観点 | 暗黙的キャッシュ(自動) | 明示的キャッシュ(cachedContents) |
|---|---|---|
| トリガー方法 | 繰り返しプレフィックスを自動検出 | キャッシュオブジェクトを能動的に作成して参照 |
| ヒットの確定性 | ベストエフォート。プレフィックスがわずかに変わるとヒットしない場合あり | 確定的。期限切れでなければ必ずヒット |
| 管理の要否 | 不要 | ハンドルの作成 / 参照 / 削除が必要 |
| 適している用途 | 短く、プレフィックスがたまに重複する | 大きく、安定し、繰り返し再利用するコンテキスト |
| 課金 | ヒット時に読み取り料金の割引 | 作成時に書き込み料金 + 参照時に読み取り料金の割引 |
両者は併用できます。日常のリクエストでは暗黙的キャッシュを自動で効かせればよく、確実に繰り返し再利用する大きなコンテキストについては、さらに明示的キャッシュでヒットを固定します。暗黙的キャッシュの詳細は プロンプトキャッシュ を参照してください。