GEMINI LABEN
SIRI — WWDC 2026で刷新版SiriがGoogle Geminiモデルで動くと確定。ただしEUではDMAによりiOS 27時点で提供されませんFLASH3.5 — Gemini 3.5 FlashがGA。エージェント・コーディングで持続的なフロンティア性能を発揮する最上位FlashモデルですIMAGE-GA — Gemini 3.1 Flash Image / 3.1 Pro Imageがネイティブ視覚モデルとしてGA。preview版は6/25に終了予定MANAGED-AGENTS — Gemini APIでManaged Agentsが公開プレビュー。Googleホストの隔離Linuxサンドボックスで自律エージェントを構築できますFILE-SEARCH — File Searchがマルチモーダル対応。gemini-embedding-2で画像のネイティブ埋め込み・検索が可能になりましたDEPRECATION — gemini-3.1-flash-image-preview / gemini-3-pro-image-previewは6/25に停止。GA版への移行をお早めにSIRI — WWDC 2026で刷新版SiriがGoogle Geminiモデルで動くと確定。ただしEUではDMAによりiOS 27時点で提供されませんFLASH3.5 — Gemini 3.5 FlashがGA。エージェント・コーディングで持続的なフロンティア性能を発揮する最上位FlashモデルですIMAGE-GA — Gemini 3.1 Flash Image / 3.1 Pro Imageがネイティブ視覚モデルとしてGA。preview版は6/25に終了予定MANAGED-AGENTS — Gemini APIでManaged Agentsが公開プレビュー。Googleホストの隔離Linuxサンドボックスで自律エージェントを構築できますFILE-SEARCH — File Searchがマルチモーダル対応。gemini-embedding-2で画像のネイティブ埋め込み・検索が可能になりましたDEPRECATION — gemini-3.1-flash-image-preview / gemini-3-pro-image-previewは6/25に停止。GA版への移行をお早めに
記事一覧/API / SDK
API / SDK/2026-05-05上級

Gemini API のキャッシュ戦略で月3万円を6,000円にした:Context Caching・Implicit Caching の本番設計

Gemini API のContext CachingとImplicit Cachingを正しく設計することでAPI費用を80%削減した実践ガイド。キャッシュ選定の判断基準、動作確認済み実装コード、本番でのトラブルシュートまで体系的に解説します。

gemini-api286context-caching6implicit-caching2cost-optimization20production90python131

プレミアム記事

Gemini APIのコスト請求を見て「先月より倍になっている」と焦った経験は、API開発者なら一度はあるのではないでしょうか。私が運営するAIサービスで月の請求が3万円を超えたとき、最初に疑ったのはトークン数の増加でした。でも実際の問題は全く別のところにありました。

同じ長文のシステムプロンプト(約15,000トークン)を、毎回のリクエストで送信し続けていたのです。ユーザーが一言「今日の天気は?」と聞くだけで、裏側では15,000トークン以上のコンテキストが毎回送られていました。

ここで扱うのはそのときに学んだGemini APIのキャッシュ設計を体系的にまとめます。Context Cachingの導入からImplicit Cachingの活用まで、実際に動くコードと一緒に解説します。

Gemini API にある3種類の「キャッシュ」を整理する

まず混乱しがちな用語を整理しましょう。Gemini APIには主に3つのキャッシュの概念があります。

Context Caching(コンテキストキャッシュ): 自分で明示的にキャッシュを作成する機能です。長いシステムプロンプトや参照ドキュメントをあらかじめキャッシュしておき、後続のリクエストで使い回します。キャッシュの保存にはストレージコストがかかりますが、キャッシュヒット時の入力トークン料金が大幅に安くなります。

Implicit Caching(暗黙的キャッシュ): Googleが自動で行うキャッシュです。同一または酷似するプロンプトのプレフィックスを検出し、自動的にキャッシュを適用します。設定不要で、ユーザーは意識しなくてもキャッシュの恩恵を受けられます(ただし確実に効くとは限りません)。

アプリケーション層のKVキャッシュ: RedisやCloudflare KVを使い、レスポンス全体をキャッシュするアプリケーション側の工夫です。全く同一のリクエストに対してAPIを呼ばずにキャッシュ済みレスポンスを返します。

ここで扱うのはContext CachingとImplicit Cachingを深掘りします。この2つを正しく理解するだけで、コストは劇的に変わります。

Context Caching:意図的にキャッシュして確実にコストを下げる

いつContext Cachingを使うべきか

Context Cachingが効果的なのは、同じ大きなコンテキストを複数のリクエストで繰り返し使う場合です。具体的には:

  • 長いシステムプロンプト(5,000トークン以上が目安)
  • 参照ドキュメント(マニュアル、仕様書、FAQなど)
  • Few-shotの例(多数のサンプルを毎回送っている場合)
  • コードベース全体をコンテキストに含めるツール

逆に、リクエストごとに内容が変わるコンテキスト(ユーザー入力、リアルタイムデータなど)はキャッシュの恩恵を受けられません。

コスト削減の実際の計算

Context Cachingのコストは主に2つです:

ストレージコスト:キャッシュ1トークンあたり $0.000001/時間(Gemini 2.5 Pro の場合)
キャッシュヒット時の入力コスト:通常入力の約25%

例えば15,000トークンのシステムプロンプトを1日100回使う場合:

通常の場合:
  15,000 tokens × 100 req × $0.00000125/token = $1.875/日 ≈ 月5,600円

Context Cachingを使う場合:
  ストレージ:15,000 × 24時間 × $0.000001 = $0.36/日(1日保持)
  ヒット時入力:15,000 × 100 × $0.00000125 × 0.25 = $0.469/日
  合計:$0.829/日 ≈ 月2,500円(約55%削減)

リクエスト数が多いほど、また固定コンテキストが長いほど削減率は上がります。

Context Cachingの基本実装

import google.generativeai as genai
import time
from google.generativeai import caching
 
# APIキーの設定
genai.configure(api_key="YOUR_GEMINI_API_KEY")
 
# キャッシュするシステムコンテキスト(例:長大なFAQドキュメント)
LARGE_SYSTEM_CONTEXT = """
あなたは当社のカスタマーサポートAIです。
以下の製品マニュアルと FAQ を参照して回答してください。
 
[製品マニュアル - 全15,000トークン相当のコンテンツ]
... (ここに大量のドキュメントが入る)
"""
 
def create_context_cache(content: str, ttl_seconds: int = 3600) -> caching.CachedContent:
    """コンテキストキャッシュを作成する"""
    cache = caching.CachedContent.create(
        model="models/gemini-2.5-pro",
        system_instruction=content,
        ttl=f"{ttl_seconds}s",
        display_name="support-context-cache"
    )
    print(f"✅ キャッシュ作成: {cache.name}")
    print(f"   有効期限: {cache.expire_time}")
    return cache
 
def get_or_create_cache(content: str) -> caching.CachedContent:
    """既存のキャッシュを再利用するか、新規作成する"""
    # 既存のキャッシュを検索
    for cached in caching.CachedContent.list():
        if cached.display_name == "support-context-cache":
            print(f"♻️  既存キャッシュを再利用: {cached.name}")
            return cached
    
    # なければ新規作成
    return create_context_cache(content)
 
def chat_with_cache(cache: caching.CachedContent, user_message: str) -> dict:
    """キャッシュを使ってGeminiにリクエストする"""
    model = genai.GenerativeModel.from_cached_content(cached_content=cache)
    
    response = model.generate_content(user_message)
    
    # トークン使用量の確認
    usage = response.usage_metadata
    return {
        "text": response.text,
        "cached_tokens": usage.cached_content_token_count,
        "input_tokens": usage.prompt_token_count,
        "output_tokens": usage.candidates_token_count,
    }
 
# 実際の使用例
cache = get_or_create_cache(LARGE_SYSTEM_CONTEXT)
 
questions = [
    "返品ポリシーを教えてください",
    "配送にどれくらいかかりますか?",
    "会員登録はどうすればいいですか?"
]
 
for q in questions:
    result = chat_with_cache(cache, q)
    print(f"\n質問: {q}")
    print(f"回答: {result['text'][:100]}...")
    print(f"キャッシュトークン: {result['cached_tokens']} / 入力トークン合計: {result['input_tokens']}")
    # cached_tokensが大きいほどコスト削減効果が出ている

このコードで注目すべきは get_or_create_cache() 関数です。プロセスを再起動しても既存のキャッシュを検索して再利用するため、キャッシュの作り直しによる無駄なコストを防げます。

TTL(有効期限)の適切な設計

TTLの設定は思ったより重要です。短すぎるとキャッシュが頻繁に失効してストレージコスト+再作成のオーバーヘッドが発生します。長すぎると古いコンテンツが参照され続けます。

from datetime import datetime, timezone
 
def calculate_optimal_ttl(daily_request_count: int, cache_creation_cost_tokens: int) -> int:
    """
    最適なTTLを計算する。
    リクエスト数が少ない夜間はキャッシュを維持しない方がコスト効率が良い場合も。
    """
    current_hour = datetime.now(timezone.utc).hour
    
    # ピーク時間(JST 9時〜22時 = UTC 0時〜13時)
    is_peak_hours = 0 <= current_hour <= 13
    
    if is_peak_hours and daily_request_count > 50:
        # ピーク時は長めのTTL
        return 7200  # 2時間
    elif daily_request_count > 10:
        return 3600  # 1時間
    else:
        # リクエストが少ない場合はキャッシュをあまり長く持たない
        return 1800  # 30分
 
# Context Cachingの最小トークン要件を確認する
def check_cache_eligibility(content: str) -> tuple[bool, str]:
    """キャッシュ対象として適切かチェックする"""
    # Gemini 2.5 Pro のContext Cachingは最低32,768トークン必要
    # 簡易推定(実際は genai.count_tokens() を使う)
    estimated_tokens = len(content) // 4  # 概算
    
    if estimated_tokens < 32768:
        return False, f"トークン数不足: 約{estimated_tokens}トークン(最低32,768必要)"
    return True, f"キャッシュ適用可能: 約{estimated_tokens}トークン"

注意が必要なのは、Gemini 2.5 ProのContext Cachingには最低32,768トークンという制限があります(モデルによって異なります)。これを満たさないと 400 INVALID_ARGUMENT エラーになります。これが「キャッシュを設定したのに効かない」原因の一つです。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
月3万円のGemini API費用が6,000円になった設計判断を全工程ステップで追体験できる
Context Caching・Implicit Caching・KVキャッシュの使い分け基準と動作確認済みコードをすぐに使える形で手に入れられる
本番でキャッシュが効かない原因TOP5の診断チェックリストと修正手順を習得できる
Stripe による安全な決済 · いつでもキャンセル可能
シェア

お読みいただきありがとうございます

Gemini Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

API / SDK2026-05-08
Gemini API implicit caching が効かない・課金がおかしい — 原因別トラブルシューティング
Gemini API の implicit caching が効かない、キャッシュヒット率が低い、コスト削減を期待したのに請求が変わらないといった問題を、原因別に整理して解決策をコード付きで紹介します。
API / SDK2026-04-19
Gemini API キャッシュ戦略の運用ノート — Context Caching と Implicit Caching を本番で組み合わせて月額費用を抑える
Context Caching と Implicit Caching を個人開発アプリの本番運用で組み合わせた実装メモ。動くコード・実測コスト・運用で気づいた7つの落とし穴を、AdMob 連携アプリの文脈で整理しています。
API / SDK2026-04-16
Gemini API × Gemma 4 ハイブリッド推論アーキテクチャ実装ガイド — APIコストを70%削減する本番設計パターン
Gemini API と Gemma 4 ローカル推論を組み合わせたハイブリッドアーキテクチャの設計・実装を解説します。リクエストルーティング・コスト試算・本番デプロイまで、動作するコード付きで体系的に紹介します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →