gemini-3
Gemini 3 コンテキストキャッシュの判断ガイド
Gemini3 Team · 2026年10月14日 · 21 min read
Keywords: Gemini 3, コンテキストキャッシング, Gemini API, コスト最適化
Published: 2026年10月14日 Author: Gemini3 Team
入力の繰り返しは検討のきっかけになります
仮にあなたのチームが同じ製品ハンドブックについて 20 の異なる質問をしたとします。すべてのリクエストでハンドブック全体を送信すると、大量の入力が重複する可能性があります。共有素材が大量で、安定しており、再利用される場合、コンテキストキャッシングは検討する価値があります。すべてのリクエストで異なる短いドキュメントを使用する場合は、それほど魅力的ではありません。
このガイドは、オリジナルのハンドブックシナリオと編集図解を用いて、Gemini API ユーザー向けの判断プロセスを提供します。測定された節約効果を報告したり、より速い応答を約束したり、MidassAI Chat 内のキャッシングスイッチを説明したりするものではありません。サードパーティのチャットサービスは独自のコンテキスト処理を実装している可能性があります。その文書化された動作は 別途検証してください。
まず、実際に使用している API を選択してください。 Google の現在の Interactions キャッシングドキュメント は暗黙的キャッシングについて説明しています。また、generateContent キャッシングドキュメント は、サポートされている Gemini 3 および 2.5 モデル向けの明示的キャッシュオブジェクトについても説明しています。Interactions 統合に明示的キャッシュの指示をコピーしないでください。
質問間で何を同じに保つべきか?

図解では、青いブロックは同じハンドブックのリビジョンです。3 つの小さなブロックは異なる質問です。これが探すべきパターンです。共通の素材を最初に、タスク固有の素材を後に配置します。この図はリクエストの構成を説明するものであり、リクエストが暗黙的キャッシュにヒットするという保証ではありません。
効果的な共有コンテキストは、意図的なパッケージです。ハンドブックのテキスト、バージョン識別子、そしてすべての質問に 実際に適用される指示です。変更されるタイムスタンプ、ランダムな識別子、または無関係な挨拶を安定した素材の前に配置しないでください。アプリケーションのログ識別子は、推論目的で役立たない場合、モデル入力外に保持してください。
最適化する前に、3 つの質問に答えてください。ソースはセッション中に変更されますか?すべてのユーザーにパッケージ全体を使用する権限がありますか?アプリケーションは各回答をソースリビジョンにトレースできますか?いずれかの答えが不明確な場合は、繰り返しトークンを減らす試みの前に、ソース選択とアクセス制御を修正してください。
2 つのメカニズム、異なる責任
| 質問 | 暗黙的キャッシング | 明示的キャッシング |
|---|---|---|
| キャッシュオブジェクトを管理するのは誰? | アプリケーションで作成するオブジェクトなし | アプリケーションがキャッシュを作成し参照する |
| 類似プロンプトによる再利用は保証されるか? | いいえ。実際の使用状況を検査する | キャッシュ参照と返された使用状況を確認する |
| ここで重要なのはどの API パスか? | 現在の API のキャッシングガイドに従う | サポートされている generateContent モデルとメソッドを使用する |
| 何を計画する必要があるか? | 安定した共有プレフィックスと測定 | ソースバージョン、有効期限、クリーンアップ、総コスト |
Google のドキュメントによると、暗黙的キャッシングはモデルごとの入力しきい値を条件として、Gemini 2.5 以降のモデルでデフォルトで有効になっています。共通の素材を早期に配置し、類似のプレフィックスを 短い時間間隔で送信することを推奨しています。しきい値は単語数やファイルサイズの見積もりではなく、トークン数です。すべての Gemini 3 バリアントが同一の制限を持っていると 仮定するのではなく、正確にサポートされているモデルを 確認してください。
明示的キャッシングは 有効期間や削除の管理作業を追加します。現在の generateContent ガイドは、期間が指定されていない場合のデフォルト TTL が 1 時間であることを説明しており、保存トークンの期間とキャッシュされた入力およびその他のリクエスト料金を区別しています。これらは API の動作であり、最終的な請求書についての保証ではありません。実装前に該当するモデルと API ドキュメントを再確認してください。
明確な終了時点のあるハンドブックセッション
これは本番環境の実測記録ではなく、再現可能な計画例です。チームはハンドブックリビジョン 7 を持ち、短いレビューセッションを予想し、3 つの質問への回答を望んでいます。オンボーディングで何が変わったか、どの例外に承認が必要か、エスカレーション手順がどこにあるかです。
暗黙的キャッシングの場合、同じ安定したソースプレフィックスを中心に各リクエストを構成し、その後で質問を変化させます。各レスポンスについて返された使用状況を記録します。類似の入力は再利用の機会です。実際に何が起こったかは、実際の使用状況のみが 示します。
サポートされている generateContent 統合における明示的キャッシングの場合:
- クリーンで承認されたハンドブックリビジョンを準備し、適切なツールでそのトークンを数えます。
- リソースを作成する前に、モデルのキャッシュサポートと制限を確認します。
- 意図的に選択したライフタイムでキャッシュを作成し、その識別子、モデル、ソースリビジョンを保存します。
- 質問のためにそのキャッシュを参照し、選択したモデルをキャッシュと一致させます。
- 返された使用状況を記録し、回答をハンドブックに対してレビューします。
- レビュー終了時にキャッシュを削除するか、選択した有効期限に計画されたライフタイムを処理させます。
アプリケーションはこれらのステップを実装する必要があります。自然言語プロンプト単独ではキャッシュを作成または管理できません。API 認証情報はサーバー上に保持し、記事、クライアントサイドコード、分析ログの外に置いてください。
バージョン変更には新たな判断が必要です

ライフサイクル図解は、リビジョン変更を 既存内容の直接編集ではなく、ブランチとして示しています。Google の generateContent ガイドは有効期限や TTL の更新を許可していますが、キャッシュされたコンテンツ自体は許可していません。ハンドブックリビジョン 8 が回答を変更する場合、新しい承認されたコンテキストを構築し、古いリビジョンへの新しい質問のルーティングを停止してください。
有用なアプリケーション記録は、キャッシュ識別子をソースチェックサム、正確なモデル、作成時間、有効期限、アクセススコープに関連付けます。これは Gemini API によって約束されたフィールドのリストではなく、アプリケーションの簿記推奨事項です。人間が読める表示名が正しいドキュメントを一意に識別すると 決して仮定しないでください。
また、キャッシュクリーンアップとドキュメント保持を分離してください。キャッシュを削除することは、アップロードされたすべてのソースファイル、ローカルコピー、またはログが削除された証拠ではありません。各場所に独自の保持ルールを適用してください。ドキュメントアーカイブとして保存されたコンテンツを読み戻すのではなく、キャッシュメタデータの取得をドキュメントは許可しているため、権威あるソースを既存の制御下に保持してください。
魅力的な数字ではなく、ワークロード全体を比較してください
明示的キャッシュを保持するかどうかを決定する前に、小さな評価シートを使用してください。ソースリビジョン、質問、モデルを一定に保ちます。割引率をでっち上げるのではなく、セッション期間と実際の使用状況を記録します。
| 記録 | 重要な理由 |
|---|---|
| 正確な API、モデル、ソースリビジョン | 2 つの試行を比較可能に保つ |
| 実際に質問された数 | 期待される需要ではなく再利用を測定する |
| キャッシュされたおよびキャッシュされていない入力使用量 | 再利用が発生した場所を示す |
| 出力使用量 | 入力をキャプチャしても出力作業は除去されない |
| キャッシュライフタイムとストレージ料金 | 長いアイドル期間が結果を変える可能性がある |
| 回答チェックと失敗 | 間違ったリビジョンが回答する場合、低コストは有用ではない |
アカウント、モデル、API の現在の請求条件で合計を計算してください。該当する場合、キャッシュ作成または入力処理料金、ストレージ期間、キャッシュされていない質問トークン、生成された出力を含めます。その合計を、明示的に管理されたキャッシュなしの同じワークロードと比較してください。暗黙的な再利用もベースラインに影響を与える可能性があるため、実際の使用状況を検査せずにベースラインを「キャッシュなし」とラベル付けしないでください。
この記事は意図的に現在の価格表を提供していません。価格とモデルの可用性はワークフローとは 独立して変更される可能性があります。評価を実行する際に適用される金額については、公式価格ページ を使用してください。
キャッシングが次のステップとして不適切な場合を認識する
一回限りの短い質問、絶えず変化するソースバンドル、または信頼できるドキュメントバージョンマップのないプロジェクトは、キャッシュよりも良い入力選択からより多くを得る可能性があります。無関係なページを削除し、独立したタスクを分割し、最初に回答品質をテストしてください。キャッシュしきい値を越えるために単にプロンプトを 水増ししないでください。それはワークロードを変更し、最適化の目的を 損なう可能性があります。
キャッシュがセッション中に有効期限切れになった場合、失敗を 明示的に処理してください。意図したソースリビジョンを再ロードし、残りの作業が 必要とする場合のみリソースを再作成してください。別のドキュメントを 説明なく置換したり、同じ有効期限切れの参照を 再試行し続けたりしないでください。ユーザーが何が失われたか 推測せずに回復できるように質問を保存してください。
最後に、キャッシングは入力を再利用しますが、回答を検証したり、モデルの制限を超えてコンテキストウィンドウを増やしたりしません。別のプログラムが消費する出力の場合、再利用計画を 構造化出力検証ワークフロー とペアにしてください。よく整理されたソースとチェックされた結果は、同じ信頼性問題の異なる部分を解決します。