プロンプトキャッシュ（プロンプトキャッシュ）
LLM APIプロバイダが提供する入力トークンのキャッシュ機能。システムプロンプトやFew-shot例などの固定的な入力プレフィックスをサーバー側でキャッシュし、2回目以降のリクエストで入力トークン料金を50-90%削減する仕組み。
プロンプトキャッシュとは、LLM APIプロバイダがサーバーインフラ側で提供する入力トークンのキャッシュ機能である。リクエスト間で共通するプレフィックス部分（システムプロンプト、Few-shot例、長大なコンテキストドキュメント等）をキャッシュし、再処理を省略することで入力トークン料金を大幅に削減する。
概要
2024年にAnthropicがClaude向けにPrompt Cachingを発表して以降、OpenAI（Cached Tokens）、Google（Gemini Context Caching）が相次いで同等機能を提供し、2026年現在ではLLM API利用における標準的なコスト最適化手法となっている。
プロンプトキャッシュの基本原理は単純である。LLMへのリクエストにおいて、トークン列の先頭（プレフィックス）が前回のリクエストと一致する場合、その部分の内部計算結果（KVキャッシュ）をサーバー側で保持・再利用する。ユーザーはAPIリクエストのフォーマットに小さな変更を加えるだけで恩恵を受けられる。
プロバイダ別仕様比較
| 仕様 | Anthropic Prompt Caching | OpenAI Cached Tokens | Google Context Caching |
|---|---|---|---|
| 対応モデル | Claude 3.5 Sonnet/Haiku/Opus, Claude 3 | GPT-4o, GPT-4o-mini, o1系列 | Gemini 1.5 Pro/Flash, Gemini 2.0 |
| 最小キャッシュ長 | 1,024トークン(Sonnet/Opus)/2,048(Haiku) | 1,024トークン | 32,768トークン |
| キャッシュTTL | 5分（使用で自動延長） | 非公開（自動管理） | 明示指定（最小1分） |
| 書き込みコスト | 入力料金の1.25倍 | なし（自動） | なし |
| 読み取り割引 | 入力料金の90%オフ | 入力料金の50%オフ | 入力料金の75%オフ |
| 有効化方法 | cache_control指定 | 自動（オプトアウト不可） | API明示指定 |
| 最大キャッシュ数 | 4ブレークポイント/リクエスト | 制限なし（自動） | 明示作成 |
コスト計算例
Anthropic Claude 3.5 Sonnet
通常入力: $3.00/1Mトークン
- キャッシュ書き込み: $3.75/1Mトークン（1.25倍）
- キャッシュ読み取り: $0.30/1Mトークン（90%オフ）
計算例: システムプロンプト4,000トークン + Few-shot例6,000トークン = 10,000トークンをキャッシュ
- 初回: $3.75 × 0.01 = $0.0375（書き込み）
- 2回目以降: $0.30 × 0.01 = $0.003（読み取り）
- 通常: $3.00 × 0.01 = $0.03（毎回）
- 10回利用で: キャッシュ有り = $0.0375 + 9×$0.003 = $0.0645 / キャッシュ無し = 10×$0.03 = $0.30 → 78%削減
OpenAI GPT-4o
通常入力: $2.50/1Mトークン
- キャッシュ読み取り: $1.25/1Mトークン（50%オフ）
- 書き込みコスト: なし（自動キャッシュ）
計算例: 同条件10,000トークン、10回利用
- キャッシュ有り = $0.025 + 9×$0.0125 = $0.1375 / キャッシュ無し = 10×$0.025 = $0.25 → 45%削減
実装パターン
Anthropic（明示指定方式）
APIリクエストのsystemメッセージ内にcache_controlマーカーを配置:
- systemメッセージのブロック末尾に
cache_control: {"type": "ephemeral"}を付与 - 最大4つのキャッシュブレークポイントを設定可能
- 多段キャッシュ: システムプロンプト（BP1）→ Few-shot例（BP2）→ ドキュメント（BP3）→ 会話履歴（BP4）
OpenAI（自動方式）
特別な設定不要で自動的にキャッシュが適用:
- 1,024トークン以上の共通プレフィックスが自動検出される
- レスポンスのusageオブジェクトにcached_tokensが含まれる
- 開発者はキャッシュ率をモニタリングし、プロンプト構成を最適化
Google（明示作成方式）
CachedContent APIでキャッシュを明示的に作成・管理:
- 32,768トークン以上のコンテンツが対象
- キャッシュの保存期間を明示指定（デフォルト1時間）
- 保管料: $1.00/1Mトークン/時間（Gemini 1.5 Pro）
- 長大ドキュメント（100K+トークン）のRAG代替として有効
最適化のベストプラクティス
- プロンプト構成の安定化: キャッシュ対象部分を先頭に固定し、変動部分を末尾に配置
- バッチ処理の集約: キャッシュTTL（5分）内に連続リクエストを集約
- 段階的キャッシュ: Anthropicの4段ブレークポイントを活用し、変動頻度別に分離
- モニタリング: キャッシュヒット率を定期監視し、低下時はプロンプト構成を見直す
よくある質問（FAQ）
Q1: プロンプトキャッシュは応答品質に影響しますか？ A: 影響しない。キャッシュされるのはモデル内部のKV計算結果であり、出力生成のプロセスは完全に同一。キャッシュ有無で応答内容が変わることはない。
Q2: Anthropicのキャッシュは5分で消えてしまいますか？ A: TTLは5分だが、キャッシュにヒットするリクエストが来るたびに自動延長される。定期的にリクエストがある限りキャッシュは維持される。完全にリクエストが途絶えて5分経過すると失効する。
Q3: OpenAIとAnthropicのどちらのキャッシュがお得ですか？ A: リクエスト頻度と入力サイズによる。高頻度（TTL内に10+リクエスト）かつ大きなシステムプロンプト（4K+トークン）ならAnthropicの90%オフが圧倒的に有利。低頻度または小さいプレフィックスならOpenAIの自動キャッシュ（50%オフ、設定不要）が手軽。
Q4: マルチターン会話でもキャッシュは効きますか？ A: 効く。会話履歴を含むプロンプト全体のプレフィックスが一致する限りキャッシュが適用される。Anthropicでは会話履歴の末尾にブレークポイントを置くことで、ターン追加時も前ターンまでのキャッシュが再利用される。
まとめ
- プロンプトキャッシュはLLM APIコスト最適化の最も手軽な手法（設定変更のみ）
- Anthropic: 90%オフ（明示設定）、OpenAI: 50%オフ（自動）、Google: 75%オフ（明示作成）
- システムプロンプト+Few-shot例の固定化で最大効果を発揮
- 応答品質への影響はゼロ（内部KV計算結果のキャッシュ）
- 10回利用で45-78%のコスト削減が実現可能