プロンプトキャッシュとは？KV Cacheとの違いと効かない原因を整理する
長いシステム指示、同じ道具定義、共通資料を毎回モデルへ送るLLMアプリでは、入力の前半を繰り返し計算する。プロンプトキャッシュは、同じ接頭部分を処理した中間状態を再利用し、入力処理の時間と費用を減らす仕組みである。
キャッシュが使われても、前回の回答がそのまま返るわけではない。新しい入力と出力生成は通常どおり処理される。同じ質問で同じ答えを保証する機能でも、モデルが扱える文脈長を増やす機能でもない。
KV Cacheと同じ言葉でも利用範囲が違う
モデルは入力トークンを処理するとき、Attentionで使うKeyとValueの中間状態を作る。一般的なKV Cacheは、一回の生成や会話の途中で過去トークンの計算を繰り返さないために使われる。前の記事で扱ったKV Cacheは、主に推論内部の計算とメモリの仕組みである。
プロンプトキャッシュは、その中間状態を後続の別リクエストでも使える形にし、共通するプロンプトの接頭部分を再処理しない仕組みだ。OpenAIの資料も、変更されていない先頭トークンに対応するKV状態を保存し、後続リクエストで一致する場合に再利用すると説明している。
出力キャッシュとも異なる。出力キャッシュは、同じキーに保存した完成済み回答をアプリが返す。一方、プロンプトキャッシュではモデルが新しい回答を生成する。最新情報や利用者ごとの状態が必要な処理でも、共通する前半だけを再利用できる。
一致するのは接頭部分である
キャッシュは、文章のどこかに同じ段落があれば効くわけではない。先頭から同じ順序で続く接頭部分が一致する必要がある。途中に時刻、利用者ID、ランダムな識別子を入れると、その位置以降は一致しなくなる。
例えば次の順序は再利用しやすい。
- 共通の開発者指示
- 固定した道具定義
- 多くの利用者で共有する資料
- 利用者固有の状態
- 今回の質問
変わりにくい内容を前へ、毎回変わる内容を後ろへ置く。文章が同じでも、道具の定義順、JSON Schema、応答形式、推論設定などが変わると、モデルへ渡される実際の文脈が変化し、キャッシュが途切れる場合がある。
見た目の文字列ではなく、APIがモデルへ組み立てた文脈の一致が条件になる。SDKの更新、設定変更、道具の追加を行ったときは、キャッシュ命中率も確認する。
長い固定部分が繰り返される仕事で効く
プロンプトキャッシュが有効なのは、再利用する共通部分が十分に長く、同じ構成の要求が短時間に繰り返される場合である。例えば、大きな操作手順、長い出力Schema、多数の道具定義、共通資料を持つ問い合わせが候補になる。
短い指示に毎回まったく異なる質問を送るだけなら、設計を複雑にしても効果は小さい。長い資料でも利用者ごとに異なり、一度しか使わないなら、書き込みと管理の負担に見合わないことがある。
OpenAIの現行資料では、対象モデルごとにキャッシュ可能な最小長、読み書きの料金、保持期間、明示的な区切りの対応が異なる。具体的な値を設計へ固定せず、採用するモデルの公式資料と料金表を確認する。
会話履歴は追記して前半を保つ
複数ターンの会話では、以前のメッセージをそのまま残し、新しいメッセージを末尾へ追加すれば、長くなった共通履歴を再利用しやすい。過去の文章を毎回整形し直したり、時刻を差し替えたりすると、変えた位置から先の一致が失われる。
一方、文脈が長くなりすぎれば、圧縮や古い履歴の削除が必要になる。圧縮後は接頭部分が変わり、以前のキャッシュを利用できない場合がある。キャッシュ効率を優先して不要な会話を残し続けると、入力費用、品質、プライバシーに悪影響が出る。
会話に必要な情報だけを残す文脈管理を先に行い、その安定した部分をキャッシュする。キャッシュ命中率のためにデータ保持方針を変えない。
道具定義を毎回並べ替えない
エージェントでは、道具の名前、説明、引数Schemaが長い共通部分になる。利用可能な道具が同じなのに配列の順序が毎回変われば、接頭部分が一致しない。
定義と順序を版管理し、利用者ごとの許可は別の仕組みで絞る。道具を使わせない依頼で定義そのものを削るとキャッシュは途切れるため、APIが許せば呼び出し可否だけを後段の設定で制御する方法がある。ただし、キャッシュ効率のために不要な道具をモデルへ公開し、権限を広げてはいけない。
道具Schemaを変更したら、以前のキャッシュが効かなくなることを正常な動作として扱う。古いSchemaの中間状態を新しい道具へ無理に流用する設計は避ける。
命中率だけでなく削減量を見る
キャッシュが効いているかは、APIの使用量に含まれるキャッシュ済み入力トークンなどで確認する。要求件数のうち何件が命中したかだけではなく、総入力トークンのうちどれだけ再利用できたかを見る。
次の指標を変更前後で比較する。
- キャッシュから読まれた入力トークンの割合
- 最初の出力が始まるまでの時間
- 一件当たりの入力費用
- キャッシュ書き込みと読み取りを含む総費用
- キャッシュなしでも必要だった入力長
- 品質と失敗率
キャッシュ命中率が上がっても、共通部分を水増ししたため総入力が長くなれば改善とは限らない。必要な指示を短くする、道具を遅延読み込みする、不要な資料を検索で絞る方が先に効く場合もある。
キャッシュミスを版の違いとして調べる
命中しないときは、先頭から差分を探す。時刻や追跡ID、利用者固有情報、道具順、Schema、出力形式、モデル、推論設定、履歴の圧縮などを確認する。
実際の入力全文をログへ残すと機密情報が増える。プロンプトの各部分に版IDと安全なハッシュを付け、どの区間が変わったかを記録する方法がある。共通指示版、道具定義版、資料版、動的部分の境界を観測できれば、本文を広く保存せずに原因を絞れる。
キャッシュは保持期間内でも必ず命中するとは限らない。提供者側の配置や容量によって再利用できない場合を想定し、キャッシュなしでも正しく動く構成にする。命中を正しさの条件にしてはいけない。
プライバシーと利用者間の分離を確認する
プロンプトキャッシュは中間状態を保持するため、利用するモデル、地域、組織設定の保持条件を確認する。前の記事で扱ったデータフロー図に、キャッシュの内容、場所、期間、削除可能性を追加する。
複数利用者が同じ共通指示を使う場合でも、利用者固有の情報を共通接頭部分へ混ぜない。提供者が組織や地域を越えて共有しない設計であっても、アプリ側のキャッシュキー、使用量集計、ログから他の利用者の存在を推測できないかを確認する。
機密情報を含む共有資料をキャッシュしてよいかは、モデルAPIへ送ってよいかとは別に検討する。保持設定や契約要件を満たさない場合は、費用削減よりデータ方針を優先する。
出力キャッシュは別の無効化設計が必要になる
プロンプトキャッシュと混同されやすいのが、質問と回答を保存して再利用する出力キャッシュや、意味が近い質問へ過去回答を返すSemantic Cacheである。これらはモデルを呼ばず完成済み回答を返せるため速いが、古い情報、権限違い、利用者固有の状態を誤って返す危険がある。
出力を再利用するなら、モデル版、プロンプト版、根拠文書版、権限、基準時刻をキーへ含め、どの変更で無効化するかを決める。書き込み、金銭、安全判断は古い出力だけで実行しない。
プロンプトキャッシュは出力を再利用しないため、この無効化問題の範囲は異なる。それでも、構成変更後の命中と保持条件を観測し、品質評価を省略しない。
プロンプトキャッシュの基本は、変わらない長い部分を前へ置き、変わる部分を後ろへ追記することだ。KV Cacheや出力キャッシュとの違いを分け、命中トークン、遅延、総費用、データ保持を一緒に測れば、仕組みを複雑にする価値があるか判断できる。