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