LLM プロンプトキャッシュ #2：Claude・GPT・Gemini・DeepSeek を比較

要点（TL;DR） —— 主要な 5 つの LLM プロバイダーは、プロンプトキャッシュを大きく異なる 5 つの形で提供している。明示的マーカー（Claude）、完全自動（GPT-5、DeepSeek-v4）、暗黙＋明示のハイブリッド（Gemini、Qwen）、あるいはアーキテクチャレベルのディスク永続化（DeepSeek の MLA）だ。本記事では機能ごとの比較に加え、あなたのワークロード向けに採点するための5 次元の評価フレームワークを提供する——コスト、ヒット率の予測可能性、レイテンシ、TTL の適合度、API の使いやすさ。アーキテクチャの背景は第 1 部：キャッシュの原理を、実測値と動く Python は第 3 部：チュートリアルを参照。

シリーズ：全 4 部の第 2 部 · 前回：第 1 部 — キャッシュの原理 · 次回：第 3 部 — 動くコードのチュートリアル · 第 4 部 — ユースケース別の最適 LLM

1. LLM キャッシュ種別の分類法

プロバイダーごとの解説に入る前に、押さえておくべき 4 つの設計軸を整理する。

1.1 制御方式：明示 vs 暗黙 vs ハイブリッド

• 明示 —— 開発者がプロンプトのどの部分をキャッシュするかをマークする（Anthropic Claude の cache_control）。制御性は最大。コード変更が必要。
• 暗黙 / 自動 —— プロバイダーが一致するプレフィックスを自動検出する（OpenAI GPT-5、DeepSeek-v4）。コード変更ゼロ。ヒットを強制する手段はない。
• ハイブリッド —— 両モードが利用可能。呼び出しごとに選べる（Gemini、Qwen）。

1.2 永続性：インメモリ vs ディスク永続化

API の表層ではなく、プロバイダーの KV キャッシュアーキテクチャによって決まる。

• インメモリ（HBM） —— キャッシュは GPU メモリ上に存在し、寿命が短く（分単位）、最小チャンクが大きい（1,024 トークン）。ほとんどのプロバイダーのデフォルト。
• ディスク永続化 —— キャッシュを SSD/NVMe に永続化し、TTL がはるかに長く粒度も細かい。DeepSeek はこれを大規模に提供しており、KV キャッシュを約 4 倍縮小する Multi-head Latent Attention（MLA）圧縮によって実現している（DeepSeek-AI, 2024）。

1.3 粒度：一致の解像度

どれだけ小さいプレフィックスで割引を得られるか？

• 64 トークン —— DeepSeek（業界最細）
• 128 トークン —— OpenAI（一致の増分）
• 1,024 トークン —— Claude、OpenAI、Gemini、Qwen でキャッシュ可能な最小チャンク

粒度が細かいほど、部分的なプレフィックスの重なりもカウントされる——小さなプロンプトの変動に対してはるかに寛容になる。

1.4 オブジェクトモデル：呼び出しごとのマーカー vs 名前付きキャッシュオブジェクト

• 呼び出しごとのマーカー —— 各リクエストがキャッシュ対象の内容をインライン化し、プロバイダーがハッシュ化する（Claude、OpenAI、DeepSeek、Qwen 暗黙）。
• 名前付きキャッシュオブジェクト —— 開発者が別途の API 呼び出しでキャッシュを作成し、cache_id を取得して後から参照する（Gemini 明示、Qwen 明示）。手間が増える代わりに明示的なライフサイクル制御を得られる。

これら 4 つの軸は相互に作用する。あるプロバイダーの提供形態は、各軸のどこに位置するかで表される。次節では各プロバイダーを個別に見ていく。

2. プロバイダー別の詳細

2.1 Anthropic Claude —— 明示・インメモリ・1,024 トークン粒度

主力モデル（2026-05）： claude-haiku-4-5、claude-sonnet-4-5 / 4-6、claude-opus-4-5 / 4-6 / 4-7。

キャッシュ API。 system や messages 配列の任意の位置に、最大 4 つの cache_control ブレークポイントをマークできる。キャッシュヒットのコストは基本入力レートの約 10%、キャッシュ書き込みは 125%（25% のプレミアム）。デフォルト TTL は 5 分のスライディング（ヒットのたびにリセット）で、1 時間のオプションもある。

価格の形。 Anthropic は価格ページでモデルごとに 100 万トークンあたりのレートを公開している。キャッシュ割引はファミリー全体で一貫している。claude-sonnet-4-5 で 8,000 トークンの system プロンプトを 1 日 10 万回呼び出す場合、プレフィックスが温まれば呼び出しごとのコストはおよそ 8〜10 倍下がる——1 回のヒットで損益分岐する。

TTL の挙動。 デフォルトは 5 分のスライディング——ヒットのたびに有効期限が 5 分先に延びる。1 時間 TTL は書き込みコストが倍になるが、アイドル間隔が 5 分超のワークロードには必須だ。

粒度。 1,024 トークンが最小。ハッシュは正確なトークン列に対して取られるため、先頭の 1 文字を変えるだけでプレフィックス全体が無効化される。

API の使いやすさ。 最高。マルチブレークポイント設計により、「決して変わらない」+「めったに変わらない」+「タスクごとに変わる」を独立してキャッシュできる——プロンプトの各部分が異なる頻度で変化するエージェントや RAG ワークロードでは同クラス最良だ。

落とし穴。

• cache_control を付け忘れるとキャッシュがまったく効かない——GPT や DeepSeek と違い、暗黙のフォールバックがない。
• キャッシュのハッシュは tool/function 配列の中でも順序に敏感だ——決定論的にソートすること。
• 5 分のデフォルトは、明示的なキープアライブがない散発的なバッチジョブには向かない。
• ゲートウェイ経由で Claude を呼ぶ場合は、ゲートウェイが cache_control マーカー付きの Anthropic ネイティブ /v1/messages パスをサポートしているか確認すること（OpenAI 互換の /chat/completions パスは通常マーカーを伝播しない——ゲートウェイの base URL を指す Anthropic SDK を使うこと）。

最適な用途。 長コンテキストのエージェント、安定した system プロンプトを持つマルチターンチャット、レイヤー化キャッシュを使う構造化 RAG。

2.2 OpenAI GPT-5.x —— 自動・インメモリ・1,024 トークン粒度

主力モデル（2026-05）： gpt-5.4-nano、gpt-5.4-mini、gpt-5.2、gpt-5.4-pro、gpt-5.5-pro。コード向け Codex バリアント：gpt-5.2-codex、gpt-5.3-codex。

キャッシュ API。 何もする必要なし——1,024 トークン以上の各リクエストで自動的に有効になる。キャッシュヒットは入力レートの 50% で課金され、書き込みプレミアムはなし。一致の増分は 128 トークン。

価格の形。 OpenAI は価格ページで 100 万トークンあたりのレートを公開している。キャッシュ入力は 50% オフ、出力は変わらない。

実測（2026-05-25、約 6,900 トークンの system プロンプト）：

* gpt-5.4-mini のヒット回の補完はミス回よりもかなり短く、ここでのコスト差はキャッシュ割引と補完長のばらつきが混ざっている。5 倍のレイテンシ低下（3.63 → 0.73 s）の方がよりクリーンなシグナルだ。

TTL の挙動。 正確な値は非公開。現場の報告では負荷とプレフィックスの人気度に応じて 5〜60 分と幅がある。人気の共有プレフィックスはより長く生き残る（LRU が優遇する）。

API の使いやすさ。 ごく簡単——既存コードがそのまま動く。prompt_tokens_details.cached_tokens を記録してヒット率を計測する。

落とし穴。

• ヒットを強制する手段はない。トラフィックが一意なプレフィックスを生むなら何も得られない。
• 50% の割引は Claude/DeepSeek の 90%/75% より浅い（Gemini 暗黙の約 25% と同程度）。
• ストリーミングでは最後のチャンクでのみキャッシュヒットが報告されることがある——慎重に計装し、stream_options={"include_usage": True} を渡すこと。

最適な用途。 リトロフィットのコストが限界的な節約を上回る、既存の GPT 利用コードベース。プレフィックスの繰り返しが自然に高いバースト型トラフィック。

2.3 Google Gemini —— ハイブリッド・インメモリ・名前付きキャッシュオブジェクト

主力モデル（2026-05）： gemini-2.5-flash、gemini-2.5-pro、gemini-3-flash-preview、gemini-3.1-pro-preview、gemini-3.1-flash-lite-preview。

キャッシュ API。 2 つのモード：

• 暗黙：GPT のように自動。キャッシュトークンは入力レートの約 25% で課金。ストレージ料金なし、セットアップ不要。
• 明示：別途の API 呼び出しで cachedContent オブジェクトを作成する。以降のリクエストで名前で参照する。キャッシュトークンは約 10%（より低い）で課金されるが、100 万トークンあたりの時間単位のストレージ料金を支払う。

価格の形。 長コンテキストは Gemini の強み。価格はコンテキスト長のカテゴリに応じてスケールする（20 万未満 vs 20 万超のしきい値で、より高いトークン単価）。

実測（2026-05-25）：

TTL の挙動。 暗黙：分単位、非開示。明示：開発者が設定、デフォルト 1 時間、最大 24 時間。

API の使いやすさ。 明示キャッシュは 2 段階のフロー（作成 → 参照）が必要。cachedContent のライフサイクル（作成、TTL 更新、削除）はあなたの責任だ。

落とし穴。

• ストレージ料金は低ボリュームの明示キャッシュにとって致命的だ。 自分の呼び出し頻度で必ず損益分岐を計算すること。
• 暗黙キャッシュのヒット率は変動が大きい。コストモデリングで当てにしないこと。
• キャッシュオブジェクトはリージョンに紐づく——マルチリージョンのアプリは重複したキャッシュが必要。
• gemini-*-pro は推論モデルだ。max_tokens が小さいと補完が隠れた思考に消費され、completion_tokens=0 が見える。ユーザー向けのパスでは max_tokens を 256 以上に上げること。

最適な用途。 1 つの大きな文書（2 万トークン超）を 1 時間に 10 回以上クエリ。動画 Q&A。企業 PDF に対するマルチモーダル RAG。

2.4 DeepSeek-v4 —— 自動・ディスク永続化・64 トークン粒度

主力モデル（2026-05）： deepseek-v4-flash（汎用）、deepseek-v4-flash（この世代では coder 系ワークロードもカバー）。

キャッシュ API。 GPT のように自動——ただしキャッシュをディスクに永続化できるほどコンパクトにする MLA 圧縮によって駆動される。キャッシュヒットは入力レートの約 25% で課金、書き込みプレミアムなし。最小一致：64 トークン。

価格の形。 DeepSeek の価格ページでは人民元建てのレート。ヒット率はおおよそ 75% の入力コスト削減に換算される。

実測（2026-05-25）：

TTL の挙動。 時間単位、高トラフィックのプレフィックスではときにそれより長い。ディスク永続化のストレージにより、他社ならインメモリキャッシュを退避させるような GPU メモリ圧迫を生き延びる。

粒度。 64 トークンの最小値は業界最小。小さなプロンプト編集をしてもプレフィックスの大部分は一致したままで、1,024 トークンのプロバイダーのように完全には無効化されない。

API の使いやすさ。 OpenAI 形式の API。base URL を差し替えるだけ。標準の prompt_tokens_details.cached_tokens フィールド。

落とし穴。

• DeepSeek ファミリーのモデルのみ。このキャッシュを他のモデルファミリーで使う方法はない。
• 英語の品質は優秀だが、最難関の推論ベンチマークでは Claude/GPT-5 に後れを取る。

最適な用途。 中国語のワークロード（コスト）。粒度が重要な高頻度プレフィックスのワークロード（検索順序が不安定な RAG）。コスト重視のバッチジョブ。

2.5 Alibaba Qwen3 —— ハイブリッド・インメモリ・名前付きキャッシュオブジェクト + 暗黙

主力モデル（2026-05）： qwen3-max、qwen3.5-plus、qwen3.5-flash。ビジョンバリアント：qwen3-vl-plus、qwen3-vl-flash。

キャッシュ API。 2 つのモード：

• 暗黙：常時オン、GPT のよう。キャッシュ部分は入力レートの約 20% で課金。
• 明示：カスタム TTL でキャッシュを API 経由で作成。ヒットは約 10%、書き込みは 125%。

実測（2026-05-25）：

TTL の挙動。 デフォルト 5 分、キャッシュオブジェクトごとに設定可能。明示はスライディングウィンドウ、暗黙は短い固定 TTL。

API の使いやすさ。 暗黙は GPT 形式（作業ゼロ）。明示はキャッシュのライフサイクルを伴う 2 段階のフロー。

落とし穴。

• 現時点で明示キャッシュをサポートするのは qwen3-max と qwen3.5-plus のみ。
• マルチリージョン（シンガポール、米国）の提供は順次拡大中——非中国データで依存する前にリージョンを確認すること。
• Anthropic/OpenAI と比べてドキュメントに欠落がある——実証的なテストを推奨。

最適な用途。 厳密なキャッシュ制御が必要な中国の企業ワークロード。すでに Alibaba Cloud を利用している顧客。

3. 横並び比較

3.1 割引構造（ベンダードキュメント、2026-05）

3.2 TTL・粒度・永続性

3.3 7K トークンのプレフィックスでの実測レイテンシ（2026-05-25）

† Claude の各行は、Anthropic ネイティブの /v1/messages エンドポイントで cache_control マーカーを付けて計測したもの（第 3 部 §2を参照）。Claude の最大の強みはコストにある（入力で約 88〜89% オフ——完全なコスト表は第 3 部 §2を参照）。Anthropic 公表の数値によれば、10 万トークン超のプロンプトでは TTFT の改善が劇的に拡大する。

単一の逐次実行、同時負荷なし。あなたの数値はリージョン、時間帯、競合するテナント負荷によって変動する。

4. 5 次元の評価フレームワーク

「Claude は 90% 節約」のような見出しは興味深いが、何を選ぶべきかを教えてくれることはめったにない。各プロバイダーをあなたのワークロードについてこの 5 次元で採点し、あなたが重視するものに応じて重み付けしよう。

4.1 100 万トークンあたりの実効コスト（ヒット率で加重）

基本価格を比べるのではなく、実際のヒット率での期待コストを比べること：

effective_cost = base × (1 - hit_rate × (1 - discount)) + write_premium × write_rate

70% のプレフィックス繰り返し（典型的なチャットボット）の計算例：

• Claude：約 90% 割引 × 0.7 ヒット + 25% 書き込み × 0.3 → 実効 ≈ base × 0.45
• GPT-5：約 50% × 0.7 + 0 → 実効 ≈ base × 0.65
• Gemini 暗黙：約 75% × 0.7 + 0 → 実効 ≈ base × 0.48
• DeepSeek-v4：約 75% × 0.7 + 0 → 実効 ≈ base × 0.48

各ベンダー実際の基本レート（プロバイダーごとに異なる）を掛ければ、比較可能なドル額が得られる。採点：自分のワークロードについて effective_cost を計算する。低いほど良い。

4.2 ヒット率の予測可能性

• 明示キャッシュ勢（Claude、Qwen 明示、Gemini 明示）—— 予測可能性が高い。マークすれば（TTL 内で）ヒットする。
• 自動キャッシュ勢（GPT-5、DeepSeek-v4、Gemini 暗黙、Qwen 暗黙）—— プレフィックスの類似度かつプロバイダー負荷（LRU 退避）に依存する。

コストに紐づく SLA なら明示を選ぶこと。ベストエフォートの最適化なら自動で十分。

4.3 TTL ↔ トラフィックのリズムの適合

4.4 キャッシュミス時のレイテンシ

ヒット時は速いがミス時は遅いプロバイダーは、ヒット率が高くなければ依然として問題だ。§3.3 の両方の数値を比較し、期待ヒット率で重み付けすること。

4.5 API の使いやすさと移行コスト

• 移行コスト最小：GPT-5 ↔ DeepSeek-v4（どちらも OpenAI 形式、どちらも自動キャッシュ）。
• 中程度：GPT-5 → Gemini 暗黙（SDK は異なるが、書き直すキャッシュコードはない）。
• 高い：GPT-5 → Claude（cache_control の追加とプロンプトレイヤーの再構成が必須）。
• 最も高い：ゲートウェイなしで単一 → 複数プロバイダーへ（複数のキャッシュ API）。

5. ワークロード形態別のクイック結論

6. 移行の検討事項

採点が「乗り換えるべき」と言うなら、計画しておくべきことが 3 つある。

データ移動。 キャッシュされたプレフィックスはプロバイダー間で移らない——乗り換えのたびにコールドスタートだ。ウォームアップ中は通常より高いコストが数時間続くことを見込んでおくこと。

プロンプトの再設計。 Anthropic のマルチブレークポイント設計は、実はどのプロバイダーにとってもより良いレイヤー化されたプロンプト構造を促す——一度リファクタリングすれば非 Claude のパスにも恩恵がある。

ゲートウェイによるヘッジ。 迷うなら Token Gateway 経由でルーティングする。単一ベンダーにコミットせずに選択肢を残せるが、ホップが 1 つ増え、（ゲートウェイによっては）ベンダー固有のキャッシュ制御へのアクセスを失う可能性がある。Synthorai ゲートウェイが実際に何をするのか、そしてどの主張を疑うべきかは第 3 部 §9を参照。

7. 時とともに変わるもの

これらの比較の耐久性について一言：本記事の数値は変動する。キャッシュは価格競争の機能となり、プロバイダーは数か月ごとに提供内容を更新している。注目すべきことが 2 つ：

• TTL の延長。 Anthropic の 1 時間オプションは GA。Gemini は複数日まで延びるかもしれない。TTL の不安は和らぐと見込まれる。
• 粒度。 OpenAI と Anthropic はいずれ 1,024 トークンの最小値を撤廃する可能性が高い。DeepSeek の 64 トークンのバーが新たな期待値を設定した。

割引が収束すると、差別化要因は見出しの節約額ではなく、API の使いやすさとレイテンシになる。

次回：第 3 部 — プロンプトキャッシュのチュートリアル：動く Python では、上記のアーキテクチャの全体像を実行可能なコードに変え、§3.3 のレイテンシ表を、あなた自身で実行できるベンチマークとして再現する。

よくある質問

総合的に見て、最も安価なプロンプトキャッシュを持つ LLM プロバイダーはどれ？ ヒット率が同等（約 75%）の場合、当社の 2026-05 の実測では、中国語ワークロードは deepseek-v4-flash、英語は gemini-2.5-flash 暗黙が、100 万トークンあたりの実効コストで最も安価だ。claude-sonnet-4-5 は単一呼び出しの割引が最も深い（約 90%）が基本価格が高い——ヒット率が 85% を超えるときに勝つ。自分のヒット率を §4.1 の式に入れてみよう。

なぜ Gemini は低ボリュームのワークロードで高くなるのか？ 明示キャッシュの時間単位のストレージ料金が、キャッシュを頻繁にクエリしない限り割引を食いつぶす。低ボリュームのワークロードには Gemini の暗黙キャッシュ（ストレージ料金なし、約 25% 割引）を使うこと。

Claude の cache_control を OpenAI で使えるか？ 直接は使えない——それぞれ別のキャッシュ実装だ。OpenAI 互換の /chat/completions エンドポイントでは、このフィールドは非 Anthropic モデルに対して通常は何もしない（それらのモデルはどのみち自動キャッシュする）。Claude については、マーカー付きの Anthropic ネイティブ /v1/messages エンドポイントを使うこと。

DeepSeek の MLA アーキテクチャは独自仕様か？ 論文（DeepSeek-AI 2024）は公開されている。他のプロバイダーも MLA 式の KV 圧縮を採用できるが、それには基盤モデルの再学習が必要で、ランタイムのスイッチではない。2026-05 時点で、本番で提供している主要プロバイダーは依然として DeepSeek だけだ。

オープンソースのセルフホストモデルはどうか？ vLLM、SGLang などの推論エンジンはプレフィックスキャッシュをネイティブにサポートしている（PagedAttention 論文がその基礎）。H100/H200 でセルフホストするなら、LMCache などでディスク永続化キャッシュを実装できる。ここでの価格分析はマネージドサービスにのみ当てはまる——セルフホストの経済性はまったく異なる。

なぜこの比較に Mistral、Cohere、Llama API プロバイダーがないのか？ 2026-05 時点で、これらのキャッシュ提供は成熟度が低い。Mistral のキャッシュはアーリーアクセス、Cohere は明示キャッシュを公開しておらず、Llama API プロバイダー（Groq、Together、Replicate）はばらつきが大きい。機能セットが安定したら再検討する。

出典：Anthropic Prompt Caching · OpenAI Prompt Caching · Google Gemini Context Caching · DeepSeek KV Cache · Alibaba Bailian Context Cache · DeepSeek-V2 / MLA paper · PagedAttention / vLLM (Kwon et al. 2023)。実測値は https://synthorai.io/v1 にて 2026-05-25 に測定。

← ブログに戻る