3つのキャッシュは保存するものが違う

LLMのコスト削減や高速化を調べると、「キャッシュ」という言葉が3種類出てきます。KVキャッシュはモデル内部の計算結果を保存します。プロンプトキャッシュは、その計算結果をリクエストをまたいで使い回すしくみです。セマンティックキャッシュは、過去の質問と回答をアプリ側で保存します。3つは保存する層がまったく違います。混同すると、「キャッシュを入れたのに料金が下がらない」「キャッシュのせいで間違った回答が出た」といった問題の原因を切り分けられません。

種類保存するもの管理する人効く場所回答内容への影響
KVキャッシュ注意機構の中間計算結果推論エンジン1回の生成の中なし
プロンプトキャッシュプロンプト先頭部分のKVキャッシュAPIの提供者(開発者は構成を工夫)同じ先頭を持つ複数のリクエストなし
セマンティックキャッシュ質問の埋め込みと過去の回答アプリ開発者意味が近い質問あり(過去の回答をそのまま返す)

以降は、就業規則や経費精算のルールに答える社内FAQボットを例に、それぞれの動きを見ていきます。

KVキャッシュはモデル内部の計算結果

LLMは文章を1トークンずつ生成します。トークンとは、モデルが文章を処理するときの単位です。次のトークンを決めるとき、モデルは注意機構(アテンション:文中のどの部分に注目するかを計算するしくみ)で、それまでの全トークンを参照します。そのときに使う各トークンのKey(キー)とValue(バリュー)というベクトルを保存しておくのがKVキャッシュです。保存しておかないと、1トークン生成するたびに過去の全トークンを計算し直すことになります。

KVキャッシュを管理するのは推論エンジンです。vLLMやSGLangのようなエンジンが、GPUメモリの上で確保と解放を行います。APIでモデルを使うだけなら、開発者が直接触ることはありません。自前のGPUでオープンモデルを動かす場合は事情が変わります。KVキャッシュのメモリ量が同時に処理できるリクエスト数や扱える文章の長さを左右するため、設定項目として目にします。

プロンプトキャッシュはKVキャッシュをリクエストをまたいで使い回す

通常、KVキャッシュは1回のリクエストが終われば捨てられます。プロンプトキャッシュは、プロンプト先頭部分のKVキャッシュを一定時間残します。次のリクエストの先頭が同じなら、その計算を省きます。主要APIはそれぞれ提供していますが、使い方は異なります。AnthropicのClaude APIは、cache_controlでキャッシュする範囲を明示します。OpenAIのAPIは、一定以上の長さのプロンプトに自動で適用します。GoogleのGemini APIにはコンテキストキャッシュという機能があります。

効果は、キャッシュされた部分の入力料金の割引と、最初のトークンが返るまでの時間の短縮です。モデルの計算そのものは変わらないため、回答の内容には影響しません。執筆時点では、キャッシュの有効期間は数分から設定次第で1時間程度です。対象になる最小トークン数や割引率はサービスごとに違い、変更もあるため、各社の公式ドキュメントで確認してください。

固定部分を先頭に置かないとキャッシュが効かない理由

プロンプトキャッシュは、プロンプトの先頭から一致している部分だけを再利用します。途中だけが一致していても使えません。理由はKVキャッシュの性質にあります。LLMの注意機構では、各トークンの計算結果がそれより前の全トークンに依存します。先頭の1文字が変われば、その後ろにある全トークンのKeyとValueも変わります。そのため、後ろに同じ文章があっても再利用できません。

社内FAQボットの悪い並びと良い並び

次の並びでは、キャッシュがほとんど効きません。

今日の日付: 2026-10-15 / 質問者: 営業部 佐藤
あなたは社内FAQボットです。回答ルール(約2,000トークン)
就業規則・経費規程の全文(約30,000トークン)
質問: 出張の日当はいくらですか?

先頭の日付と質問者名がリクエストごとに変わります。そのため、後ろにある3万トークン超の規程全文が毎回計算し直されます。固定部分を前に、変わる部分を後ろに並べ替えると、規程全文までがキャッシュの対象になります。

あなたは社内FAQボットです。回答ルール(固定)
就業規則・経費規程の全文(固定)
――ここまでがキャッシュ対象――
今日の日付: 2026-10-15 / 質問者: 営業部 佐藤
検索で取得した関連条文(質問ごとに変わる)
質問: 出張の日当はいくらですか?

見落としやすい原因もあります。システムプロンプトに秒単位の現在時刻を埋め込む、ツール定義の順番がリクエストごとに入れ替わる、JSONのキーの順序が安定しない、といったケースです。どれも先頭部分を変えてしまいます。キャッシュが効いているかは、APIレスポンスの使用量欄で確認します。Claude APIではcache_read_input_tokens、OpenAIではcached_tokensが該当します。

セマンティックキャッシュは過去の回答をアプリ側で使い回す

セマンティックキャッシュは、アプリ開発者がLLMの手前に置くしくみです。質問文を埋め込み(文章の意味を数値の並びに変換したもの)にして、回答と一緒に保存します。新しい質問が来たら、保存済みの質問と意味の近さを比べます。近さがしきい値を超えれば、LLMを呼ばずに保存済みの回答を返します。実装にはGPTCacheのようなライブラリや、Redisなどのベクトル検索機能が使われます。LLMの呼び出し自体を省くため、ヒットしたときのコストと待ち時間はプロンプトキャッシュより大きく下がります。その代わり、返す内容は過去の回答そのものです。

失敗例:別の質問に誤った回答を返す

社内FAQボットで「正社員の在宅勤務手当はいくらですか?」という質問と回答が保存されていたとします。後から「契約社員の在宅勤務手当はいくらですか?」と聞かれました。2つの文章はほぼ同じ単語でできているため、埋め込みの近さは非常に高くなります。結果として、契約社員に正社員向けの金額が返ります。同じ失敗は「東京オフィス」と「大阪オフィス」の違いや、「申請できますか」と「申請できませんか」のような否定の有無でも起こります。埋め込みは話題の近さを捉えるのが得意ですが、回答を分ける細かな条件の違いには弱いためです。規程が改定されたのにキャッシュが残り、古い締め日を答え続ける失敗もあります。

誤回答を防ぐ設計

まず、回答を分ける条件をキャッシュのキーに含めます。雇用形態、拠点、規程のバージョンなどを、意味の近さとは別に完全一致で照合します。しきい値は、実際の質問ログから「同じ回答でよい組」と「違う回答が必要な組」を集めて検証してから決めます。勘で決めてはいけません。FAQや規程を更新したら、関連するキャッシュを消す処理も用意します。個人の勤怠や給与のように質問者によって答えが変わる質問は、キャッシュの対象から外します。

どのキャッシュから手を付けるか

APIを使っているなら、最初に取り組むのはプロンプトキャッシュです。回答の品質が落ちる心配がなく、作業はプロンプトの並べ替えが中心です。固定部分を先頭に集めて、使用量欄でキャッシュの読み込みトークンが増えたことを確かめてください。KVキャッシュを意識するのは、自前でモデルを動かす場合です。推論エンジンのプレフィックスキャッシュ機能(vLLMのAutomatic Prefix Cachingなど)を有効にするかを検討します。セマンティックキャッシュは、質問ログを調べて同じ趣旨の質問が多く、かつ回答が質問者の属性で変わらない場合に限って導入します。誤回答が業務に与える影響を許容できるかを、導入前に決めておく必要があります。