Geminiにおけるコンテキストキャッシュを検討すべきタイミング

Last updated at 2025-05-05Posted at 2025-05-05

課題感

生成AIを使用する際に同じ入力トークン（ファイルなど）をモデルに何度も渡すことがあります。この際にインプットのトークン数が多いと、プロンプトを実行するたびに入力のトークン数の処理が必要になり利用料金が増加してしまいます。
ここでコンテキストキャッシュを利用することで入力トークンをキャッシュに保存してから、キャッシュに保存されたトークンを後続のリクエストで参照することができます。
結果的にキャッシュに保存されたトークンを使用する方が、同じトークンを繰り返し渡すよりも費用が少なくなります。

一方で入力トークンの数やプロンプトの実行する回数によって毎回入力トークンを処理すべきか、コンテキストキャッシュを検討すべきかが変わってくるのではないかと考えました。

そこでどのような場合にコンテキストキャッシュを使用すべきかを検討しまとめたいと思います。

コンテキストキャッシュの概要

ドキュメントによるとコンテキストキャッシュを使用する状況は以下とのことです。
ユースケースとしては入力に使用するトークン数が多く、それに対して何度もクエリを行う場合が考えられます。

広範なシステム指示を伴う chatbot

長時間の動画ファイルの繰り返し分析

大規模なドキュメントセットに対する繰り返しのクエリ

頻繁なコードリポジトリの分析やバグ修正

コンテキストキャッシュは無料のサービスではなく運用コストを削減するための有料のサービスで以下の特徴があります。

キャッシュトークン数:通常の入力トークン数と比較して割引料金で請求
保存期間:キャッシュに保存されたトークンの保存時間（TTL）。キャッシュに保存されたトークン数のTTL時間に基づいて課金。TTL の最小値や最大値に制限はなし
その他の項目:入力トークンや出力トークンがキャッシュされていない場合などは別の料金が適用

また注意点としては以下もあります。

コンテキストキャッシュの最小入力トークン数は4,096で、最大数は指定されたモデルの最大数と同じです。

モデルは、キャッシュに保存されたトークンと通常の入力トークンを区別しません。キャッシュに保存されたコンテンツは、プロンプトの接頭辞です。

コンテキストキャッシュには特別なレートや使用量の上限はありません。GenerateContent の標準レートの上限が適用され、トークンの上限にはキャッシュに保存されたトークンが含まれます。

キャッシュに保存されているトークン数は、キャッシュサービスの create、get、list オペレーションから usage_metadata で返されます。また、キャッシュを使用している場合は GenerateContent でも返されます。