
Claude・OpenAI・Gemini のプロンプトキャッシュを比較してみた — 設計思想・コスト・実装の違い
はじめに
LLM を API 経由で使っていると、同じシステムプロンプトや大きなドキュメントを何度も送信するケースが出てきます。「毎回同じ 10 万トークンを送って全額課金されるのはもったいないな…」と思ったことはありませんか?
そこで各プロバイダーが提供する プロンプトキャッシュ の仕組みを調べてみたところ、Claude・OpenAI・Gemini で設計思想がまったく異なることがわかりました。本記事では、3 社のキャッシュ戦略を 設計思想・プレフィックスマッチングの仕組み・コスト構造・実装コード の観点から比較します。
3 社のキャッシュ設計思想 — 手動・全自動・二層構造
まず最も大きな違いは「開発者にどこまで制御を委ねるか」という設計思想です。
| Claude | OpenAI | Gemini | |
|---|---|---|---|
| 方式 | 明示的のみ(ephemeral) | 暗黙的のみ(自動) | 両方あり |
| 設定 | cache_control breakpoint を手動配置 |
設定不要、自動検出 | 明示的: CachedContent オブジェクト作成 / 暗黙的: 自動 |
| 一言で言うと | 開発者が完全制御 | プラットフォームにお任せ | ユースケースで使い分け |
- Claude は「開発者が明示的にキャッシュ対象を指定する」方式。制御性が高い反面、正しい順序で配置しないとキャッシュミスになります
- OpenAI は「何もしなくても勝手にキャッシュしてくれる」方式。開発者の負担はゼロですが、ヒットするかどうかの保証もありません
- Gemini は「明示的キャッシュ(保証あり)と暗黙的キャッシュ(ベストエフォート)の二層構造」。ユースケースに応じて使い分けられます
プレフィックスマッチングの仕組み
3 社ともキャッシュは プレフィックスベース で動作します。つまり、リクエストの先頭から一致する部分がキャッシュ対象になります。ただし、その扱い方に大きな違いがあります。
Claude — 順序が命
Claude のキャッシュで最も重要なのは コンテンツの配置順序 です。cache_control breakpoint より上のすべてのコンテンツがキャッシュ対象になるため、以下のルールを守る必要があります。

途中で 1 文字でも変わると、それ以降のキャッシュは無効になります。安定したコンテンツを上に、可変コンテンツを下に置くのが鉄則です。
OpenAI — 自動検出
OpenAI はプレフィックスの一致を自動で検出します。開発者が順序を意識する必要はほとんどありませんが、実用的には system prompt を固定し、可変部分を後ろに置く方がキャッシュヒット率は上がります。
Gemini — 明示的キャッシュはプレフィックス関係なし
Gemini の明示的キャッシュは、事前に CachedContent オブジェクトとしてアップロードするため、プレフィックスの順序は関係ありません。暗黙的キャッシュの場合は他社と同様、プレフィックスベースで動作します。
コスト最適化の比較
各プロバイダーのキャッシュに関わるコスト構造を比較します。
| Claude | OpenAI | Gemini(明示的) | Gemini(暗黙的) | |
|---|---|---|---|---|
| 最小トークン | ~1,024〜4,096(モデル依存) | 1,024 | 32,768 | 少ない |
| 読取割引 | 90% | 50% | ~75% | ~75% |
| 書込追加料金 | +25% | なし | なし | なし |
| ストレージ課金 | なし | なし | あり(時間課金) | なし |
| TTL | 5 分(ヒットでリセット) | 5〜10 分(頻度で延長、最大 1 時間) | 設定可能(デフォルト 1 時間) | 制御不可 |
| ヒット保証 | プレフィックス一致なら保証 | ベストエフォート | 保証 | ベストエフォート |
コスト面のポイント
- Claude は読取割引 90% と最大ですが、書込に +25% のサーチャージがかかります。短い TTL(5 分)内に複数回ヒットしないと損をする可能性があります
- OpenAI は書込追加料金なし・割引 50% と、リスクが低くリターンもそこそこのバランス型です
- Gemini 明示的 は保証付きで ~75% 割引ですが、ストレージの時間課金があるため、利用頻度が低いと逆にコスト増になりえます
- Gemini 暗黙的 は追加コストゼロでヒットすればラッキー、という位置づけです
使い分けの判断基準
同一プロンプト短期間に繰り返し多い + 制御したい → Claude(最大割引)or Gemini 明示的(保証)
手間かけたくない → OpenAI(自動)or Gemini 暗黙的
大量ドキュメント + 確実性必要 → Gemini 明示的(32k+ 前提)
実装コード例
Claude — Ephemeral Cache with Breakpoints
from anthropic import Anthropic
client = Anthropic()
# キャッシュしたい大きなドキュメントを読み込む
large_document = open("my_document.txt").read()
response = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=1024,
system=[
{
"type": "text",
"text": "You are a helpful assistant that analyzes documents.",
},
{
# 大きいドキュメントをここに置く(上部=安定コンテンツ)
"type": "text",
"text": "<document>" + large_document + "</document>",
"cache_control": {"type": "ephemeral"}, # ← breakpoint
},
],
# 可変コンテンツは下(キャッシュ対象外)
messages=[
{"role": "user", "content": "Summarize the key points."}
],
)
# キャッシュ状況確認
print(f"Cache write: {response.usage.cache_creation_input_tokens}")
print(f"Cache read: {response.usage.cache_read_input_tokens}")
# 1 回目: cache_creation_input_tokens > 0(書込、+25% コスト)
# 2 回目: cache_read_input_tokens > 0 (読取、-90% コスト)
ポイント: cache_control の位置より上がすべてキャッシュ対象。順序を変えるとキャッシュミスになります。
OpenAI — 自動キャッシュ(コード変更不要)
from openai import OpenAI
client = OpenAI()
large_document = open("my_document.txt").read()
# 普通に呼ぶだけ。キャッシュ設定は一切不要
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "system",
"content": "You are a helpful assistant that analyzes documents.",
},
{
"role": "user",
"content": "<document>" + large_document + "</document>\n\n"
"Summarize the key points.",
},
],
)
# usage に cached_tokens が出る
print(f"Cached: {response.usage.prompt_tokens_details.cached_tokens}")
# 自動検出なのでヒットするかは保証なし
ポイント: 開発者は何もしません。プレフィックスが 1,024 トークン以上一致すれば自動でキャッシュされる可能性があります。
Gemini — 明示的キャッシュ(保証あり)
from google import genai
from google.genai import types
import datetime
client = genai.Client()
large_document = open("my_document.txt").read()
# Step 1: CachedContent を事前作成(TTL 付き)
cache = client.caches.create(
model="gemini-2.5-flash",
config=types.CreateCachedContentConfig(
display_name="my-doc-cache",
contents=[
types.Content(
role="user",
parts=[types.Part(text=large_document)],
)
],
system_instruction="You are a helpful assistant that analyzes documents.",
ttl=datetime.timedelta(hours=2), # 2 時間保持
),
)
print(f"Cache created: {cache.name}")
# Step 2: キャッシュ参照して生成(TTL 内は確実ヒット)
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="Summarize the key points.",
config=types.GenerateContentConfig(
cached_content=cache.name, # ← キャッシュ参照
),
)
print(response.text)
# Step 3: 不要になったら削除(ストレージ課金を止める)
client.caches.delete(name=cache.name)
ポイント: キャッシュは API オブジェクトとして永続管理します。TTL 内は 100% ヒット保証ですが、32,768 トークン以上が必要でストレージ時間課金もあります。
まとめ
3 社のプロンプトキャッシュを比較した結果、設計思想が根本的に異なることがわかりました。
| 観点 | Claude | OpenAI | Gemini |
|---|---|---|---|
| 思想 | 開発者が制御 | プラットフォームが自動化 | 選択肢を提供 |
| 導入コスト | 中(順序設計が必要) | 低(変更不要) | 高(明示的)/ 低(暗黙的) |
| 最大割引 | 90% | 50% | ~75% |
| 確実性 | 高(正しく実装すれば) | 低(ベストエフォート) | 最高(明示的)/ 低(暗黙的) |
実務での判断基準としては:
- コスト最小化が最優先 → Claude(90% 割引、ただし設計に注意)
- とにかく楽にやりたい → OpenAI(コード変更ゼロ)
- 大きいドキュメント + 確実にキャッシュしたい → Gemini 明示的キャッシュ
- まずは試してみたい → Gemini 暗黙的キャッシュ or OpenAI







