プロンプトキャッシュ（プロンプトキャッシュ）
LLM APIプロバイダが提供するプラットフォームレベルのキャッシュ機構。リクエスト間で共通するプロンプトのプレフィックス部分（システムプロンプトや長大なコンテキスト）をサーバー側で保持し、2回目以降の処理コストとレイテンシを大幅に削減する。
プロンプトキャッシュとは
プロンプトキャッシュ（Prompt Cache / Prompt Caching）は、LLM APIプロバイダが提供するサーバーサイドのキャッシュ機構である。複数のAPIリクエスト間で共通するプロンプトのプレフィックス（先頭部分）をサーバー上に保持し、2回目以降のリクエストではプレフィックス部分のKVキャッシュ計算をスキップすることで、コストとレイテンシを削減する。
この技術が特に有効なのは、長大なシステムプロンプト、RAGで取得した大量のコンテキスト文書、Few-shot例、コードベース全体をコンテキストに含めるような利用パターンである。
主要プロバイダの実装比較
Anthropic Prompt Caching
2024年8月にリリースされた Anthropic のプロンプトキャッシュは、明示的なキャッシュ制御を提供する。リクエスト内の特定ブロック（system, tool定義, user messageなど）に cache_control: \{"type": "ephemeral"\} マーカーを付与すると、そのブロックまでのプレフィックスがサーバー側にキャッシュされる。
| 項目 | 値 |
|---|---|
| キャッシュ書き込みコスト | 通常入力の1.25倍 |
| キャッシュヒットコスト | 通常入力の0.1倍（90%割引） |
| TTL | 5分（最終アクセスから） |
| 最小キャッシュ単位 | 1024トークン |
| 対応モデル | Claude Sonnet 4, Claude Opus 4, Claude Haiku 3.5 |
OpenAI Cached Input Tokens
OpenAI は自動プロンプトキャッシュを2024年10月に導入した。ユーザー側の明示的な制御は不要で、1024トークン以上の共通プレフィックスがあれば自動的にキャッシュされる。
| 項目 | 値 |
|---|---|
| キャッシュ書き込みコスト | 追加コストなし |
| キャッシュヒットコスト | 通常入力の0.5倍（50%割引） |
| TTL | 5-10分（トラフィックに依存） |
| 最小キャッシュ単位 | 1024トークン |
| 対応モデル | GPT-4o, GPT-4o-mini, o1, o3 |
Google Gemini Context Caching
Google は Context Caching として提供し、明示的にキャッシュを作成・管理するAPIを持つ。キャッシュの作成と利用が明確に分離されており、TTLもユーザーが指定できる。
| 項目 | 値 |
|---|---|
| キャッシュストレージ | $4.50/1M トークン/時間 |
| キャッシュヒットコスト | 通常入力の0.25倍（75%割引） |
| TTL | ユーザー指定（デフォルト1時間） |
| 最小キャッシュ単位 | 32,768トークン |
| 対応モデル | Gemini 2.5 Pro, Gemini 2.5 Flash |
プロンプトキャッシュの最適化戦略
プレフィックスの設計
キャッシュヒット率を最大化するには、リクエスト間で変化しない部分を先頭に配置する。
[高キャッシュ効率] システムプロンプト → ツール定義 → 参考文書 → 会話履歴 → ユーザー入力
[低キャッシュ効率] ユーザー入力 → 参考文書 → システムプロンプト → ツール定義
変動部分（ユーザー入力、最新の会話ターン）は常にプロンプトの末尾に配置することで、共通プレフィックスが最大化される。
コスト最適化のシナリオ
- 多ターン会話: システムプロンプト（2000トークン）+ 会話履歴（増加）の構成で、システムプロンプト部分が毎回キャッシュヒットする。10ターンの会話で入力コストを約40%削減
- RAGパイプライン: 同一ドキュメントに対する複数の質問で、ドキュメントコンテキスト（10,000-50,000トークン）がキャッシュされる。コスト削減率は70-85%
- エージェント実行: ツール定義（数千トークン）が全ステップで共通。20ステップのエージェント実行でツール定義部分のコストを90%削減
Anthropic での実装例
Anthropic のプロンプトキャッシュを使用する場合、レスポンスヘッダーに cache_creation_input_tokens と cache_read_input_tokens が返却される。
初回リクエスト（キャッシュ書き込み）では cache_creation_input_tokens にトークン数が計上され、通常入力の1.25倍の料金が発生する。2回目以降のリクエスト（キャッシュヒット）では cache_read_input_tokens に計上され、通常入力の0.1倍の料金となる。
TTLは最終アクセスから5分間で、アクセスがあるたびにリセットされる。高頻度のリクエスト（5分以内に再度同じプレフィックスを送信）ではキャッシュが維持され続ける。
FAQ
プロンプトキャッシュはRAGと相性が良いですか？
非常に相性が良い。RAGパイプラインでは同一ドキュメント群に対して異なる質問を投げるケースが多く、ドキュメントコンテキスト部分がキャッシュに乗る。10,000トークンのコンテキストに対して10回の質問を投げる場合、2回目以降の9リクエストでコンテキスト部分のコストが90%削減され、全体で約80%のコスト削減を実現する。
キャッシュのTTLが切れた場合のコスト影響は？
キャッシュミス時は通常料金が適用される。Anthropicの場合、5分以内に次のリクエストを送れなければキャッシュが失効し、再度キャッシュ書き込みコスト（1.25倍）が発生する。断続的な利用パターンではキャッシュ書き込みコストが上乗せになるため、利用頻度が低い場合はキャッシュを使わない方がコスト効率が良い場合もある。
プロンプトキャッシュとセマンティックキャッシュの違いは何ですか？
プロンプトキャッシュはAPIプロバイダが提供するインフラレベルの最適化で、共通プレフィックスのKVキャッシュ計算をスキップする。セマンティックキャッシュはアプリケーションレベルの最適化で、意味的に類似するプロンプトに対して過去のLLMレスポンス全体を再利用する。前者はコスト削減率が固定的（入力トークン比）だが確実、後者はヒットすればAPI呼び出し自体が不要になるが誤ヒットのリスクがある。