AI・機械学習
上級

LLMプロンプトキャッシング(エルエルエムプロンプトキャッシング)

LLM推論時に同一または類似のプロンプトに対する計算結果をキャッシュし、応答速度の向上とコスト削減を実現する最適化技術の総称。

0 回閲覧
0 いいね

LLMプロンプトキャッシングとは

LLMプロンプトキャッシング(Prompt Caching)は、大規模言語モデルの推論プロセスにおいて、繰り返し使用されるプロンプトやプレフィックスの計算結果を保存・再利用する最適化技術である。Transformer ベースの LLM では、入力トークン列に対して Self-Attention の Key-Value(KV)ペアを逐次計算する必要があるが、システムプロンプトや共通のコンテキスト部分は多くのリクエストで同一であるため、これらの中間計算結果をキャッシュすることで大幅な効率化が可能になる。

2024年後半から2025年にかけて、Anthropic の Claude、OpenAI の GPT-4o、Google の Gemini など主要な商用 LLM プロバイダが相次いでプロンプトキャッシング機能を提供開始し、API 利用コストの削減とレイテンシの短縮を同時に実現できるようになった。特にエージェント型アプリケーションやRAGシステムなど、長大なシステムプロンプトを繰り返し送信するユースケースで効果が顕著である。

プロンプトキャッシングの仕組み

プロンプトキャッシングの基本原理は、Transformer の推論パイプラインにおける KV キャッシュの永続化にある。通常の推論フローでは以下のステップが発生する。

  1. トークナイゼーション: 入力テキストをトークン列に変換
  2. エンベディング: トークンをベクトル表現に変換
  3. Attention 計算: 各レイヤーで Query・Key・Value を計算し Self-Attention を実行
  4. 出力生成: 最終レイヤーの出力から次トークンを予測

このうちステップ3が計算コストの大部分を占める。プロンプトキャッシングでは、入力プロンプトの共通プレフィックス部分について計算済みの KV ペアを GPU メモリまたは高速ストレージに保存し、後続リクエストでは保存済みの KV ペアを読み込んで残りの部分のみ計算する。

処理段階キャッシュなしキャッシュあり
プレフィックス KV 計算毎回実行スキップ(キャッシュ読込)
可変部分 KV 計算実行実行
Attention スコア計算全トークン対象全トークン対象(KV は既存)
レイテンシベースライン50-85% 削減
コストベースライン50-90% 削減

キャッシュのヒット判定は一般にプレフィックスマッチングで行われる。つまり、入力トークン列の先頭から何トークン目まで前回のリクエストと一致するかを確認し、一致部分のKVキャッシュを再利用する。このため、システムプロンプトを入力の先頭に配置することがキャッシュ効率を最大化する鍵となる。

主要プロバイダのキャッシング実装比較

各 LLM プロバイダは独自のプロンプトキャッシング実装を提供しており、仕様や料金体系が異なる。

プロバイダ機能名キャッシュ TTL最小トークン数料金割引明示的制御
Anthropic (Claude)Prompt Caching5分(利用で延長)1,024入力90%OFF / 書込25%UPcache_control ブレークポイント
OpenAI (GPT-4o)Automatic Caching5-10分1,024入力50%OFF自動(制御不可)
Google (Gemini)Context Caching最大48時間(設定可)32,768入力75%OFF / 保存料別途明示的キャッシュ作成 API
DeepSeekPrompt Caching数分64入力90%OFF自動(ヒット率表示)

Anthropic の実装は cache_control パラメータで明示的にキャッシュブレークポイントを指定でき、システムプロンプト・ツール定義・会話履歴の各部分に対して細かくキャッシュ戦略を設定できる点が特徴的である。一方 OpenAI は完全自動でプレフィックスマッチングを行い、開発者側の設定は不要だがキャッシュの制御もできない。

Google Gemini のコンテキストキャッシングは最も柔軟性が高く、TTL を最大48時間まで設定可能で、大量の参照ドキュメントを長時間キャッシュしておくユースケースに適している。ただし保存料が別途発生するため、利用頻度との損益分岐点を事前に計算する必要がある。

キャッシュ効率を最大化する設計パターン

プロンプトキャッシングの効果を最大限引き出すには、プロンプト構造の設計段階からキャッシュを意識する必要がある。

パターン1: プレフィックス固定化

[システムプロンプト(固定)] → [ツール定義(固定)] → [参照ドキュメント(セッション固定)] → [会話履歴(可変)] → [ユーザー入力(可変)]

固定部分をプロンプトの先頭に集約し、可変部分を末尾に配置することで、プレフィックスマッチの一致長を最大化する。

パターン2: 階層型キャッシュ

大規模なRAGシステムでは、以下の多段キャッシュ構造が有効である。

  • L1キャッシュ: システムプロンプト + ツール定義(全リクエスト共通)
  • L2キャッシュ: ユーザーセッション固有のコンテキスト(セッション内共通)
  • L3キャッシュ: 検索結果ドキュメント(クエリ依存)

パターン3: バッチ処理の活用

同一プレフィックスを共有する複数のリクエストをバッチでまとめて送信することで、キャッシュの書き込みコストを1回に抑えつつ、全リクエストでキャッシュヒットの恩恵を受けられる。

ユースケース別の効果測定

実際のアプリケーションでのプロンプトキャッシングの効果を定量的に示す。

ユースケースプロンプト長キャッシュ対象レイテンシ削減コスト削減
チャットボット2,000-5,000トークンシステムプロンプト30-50%40-60%
RAGシステム10,000-50,000トークンドキュメント+プロンプト50-70%60-80%
コード生成エージェント20,000-100,000トークンツール定義+コンテキスト60-85%70-90%
ドキュメント分析50,000-200,000トークン参照ドキュメント70-90%80-95%

特にコード生成エージェントやドキュメント分析のように長大なコンテキストを繰り返し参照するケースでは、キャッシングの効果が劇的に表れる。Claude Code のようなエージェントシステムでは、会話の進行に伴いコンテキストが蓄積されるため、プロンプトキャッシングなしでは応答時間とコストが急激に増大する。

制約と注意点

プロンプトキャッシングには以下の制約がある。

  1. プレフィックスマッチ限定: ほとんどの実装はプレフィックス(先頭一致)のみ対応。途中や末尾の一致ではキャッシュが効かない
  2. TTL の有限性: キャッシュは一定時間で失効する。低頻度のリクエストではキャッシュミスが頻発する
  3. 最小トークン数: プロバイダごとに最小キャッシュ単位が設定されており、短いプロンプトではキャッシュが適用されない
  4. 書き込みコスト: Anthropic など一部プロバイダではキャッシュ書き込み時に追加料金が発生する
  5. セキュリティ境界: マルチテナント環境ではテナント間のキャッシュ分離が必須。共有キャッシュによる情報漏洩リスクに注意

よくある質問(FAQ)

Q1: プロンプトキャッシングはどのような場合に導入すべきですか?

A1: 以下の条件に該当する場合に特に効果的です。(1) 長いシステムプロンプトやツール定義を使用している、(2) 同一ユーザーとの複数ターンの会話がある、(3) RAGで大量のドキュメントをコンテキストに含めている、(4) バッチ処理で同一テンプレートを繰り返し使用している。目安として、プレフィックス部分が1,024トークン以上あり、5分以内に複数回のリクエストが発生する場合はコスト削減効果が期待できます。

Q2: Anthropic の cache_control と OpenAI の自動キャッシングはどちらが優れていますか?

A2: ユースケースによって異なります。Anthropic の明示的制御は、キャッシュ対象を細かく指定でき、キャッシュヒット率を最適化できるため、プロンプト構造を精密に制御したい場合に優れています。一方、OpenAI の自動キャッシングは設定不要で手軽に導入でき、プロンプト設計を変更せずに恩恵を受けられます。大規模なエージェントシステムでは Anthropic 型の明示的制御が有利で、シンプルなチャットボットでは OpenAI 型の自動方式が導入コスト面で有利です。

Q3: セマンティックキャッシングとプレフィックスキャッシングの違いは何ですか?

A3: プレフィックスキャッシングはトークン列の完全一致でキャッシュを判定するのに対し、セマンティックキャッシングは入力の意味的類似度に基づいてキャッシュヒットを判定します。セマンティックキャッシングはエンベディングモデルで入力をベクトル化し、過去のクエリとのコサイン類似度が閾値を超えた場合に過去の応答を返します。プレフィックスキャッシングは LLM プロバイダ側で実装される低レイヤーの最適化であるのに対し、セマンティックキャッシングはアプリケーション層で実装するため、両者は併用可能です。

Q4: キャッシュの TTL が切れた場合のフォールバック戦略はありますか?

A4: TTL切れによるキャッシュミスを最小化するには、(1) 定期的なウォームアップリクエストで TTL を延長する、(2) キャッシュミス時のレイテンシ増大をユーザーに通知するUI設計を行う、(3) 複数のキャッシュ階層を設けて L1 ミス時に L2 でカバーする、といった戦略があります。Anthropic Claude の場合、キャッシュ使用のたびに TTL が5分延長されるため、アクティブなセッションではキャッシュが切れにくい設計になっています。