Skip to Content
Docs05. 運用セマンティックキャッシュと応答再利用
上級semantic-cachecachingcost-management更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

セマンティックキャッシュと応答再利用

この記事の目的

「同じような質問に、以前の答えを返す」応答キャッシュを、誤ヒット(似ているが違う質問に、間違った答えを高速に返す)を制御しながら設計できるようになります。完全一致から意味的類似までのキャッシュ階層を理解し、何をキャッシュしてよいか・どう無効化するか・どう計測するかを判断できる状態を目指します。入力側のプロンプトキャッシュプロンプトの固定部分(前方一致)の処理結果を再利用し、入力コストと応答開始までの時間を削減する仕組み。固定部分を先頭に置くプロンプト構造が前提。(コスト管理)とは別の、出力(応答)の再利用が主題です。

対象読者

  • LLM アプリのコスト・レイテンシを下げるため、応答キャッシュの導入を検討している運用・実装担当
  • 「よくある質問には即答したい」が、誤った答えを配ってしまうリスクを制御したいテックリード

前提知識

本文

概要: 入力側キャッシュと出力側キャッシュは別物

まず用語を分けます。LLM の「キャッシュ」には 2 種類あり、本記事は後者です。

種類何を再利用するか正本
プロンプトキャッシュ(入力側)プロンプト固定部分の処理結果を再利用し、入力コスト・初回応答時間を削減コスト管理 / 注意機構とコンテキストウィンドウの仕組み
応答キャッシュ(出力側・本記事)過去の最終応答そのものを、同じ/似た入力に返す本記事

応答キャッシュの狙いは、モデルを呼ばずに答えを返すことです。呼ばなければコストもレイテンシもゼロに近づきます。ただし「似ているが違う」入力に古い答えを返す誤ヒットのリスクがあり、その制御が設計の核心です。

キャッシュの階層: 完全一致 → 正規化一致 → 意味的類似

応答キャッシュは、キーの厳しさで 3 段階に分けられます。厳しいほど安全(誤ヒットが少ない)、緩いほどヒット率が上がる代わりに危険が増します。

階層キーヒット率誤ヒットリスク
完全一致入力文字列が完全一致言い換えは拾わない同じ権限・文脈・知識版で同じ答えを返せることが前提
正規化一致用途上、意味を変えないと確認した表記変換の後に一致確認済みの表記差を拾う正規化が意味を失うと誤ヒットする
意味的類似(セマンティック)埋め込みの距離がしきい値内言い換えも拾いうる。分布・しきい値次第あり(類似 ≠ 同一)

正規化では語順を落としません。A pays B と B pays A は同じ単語でも支払う側が逆です。大小文字・空白も、コード・識別子・引用文では意味を変ええます。例えば「単一の選択肢名の前後空白は無視する」と入力仕様で決めた場合にだけ、その変換をキーへ使います。自然言語全体に一律の安全な正規化があるとは扱いません。

セマンティックキャッシュ(semantic cache)は、この 3 段目 — 入力を埋め込みベクトルにし、過去の質問と意味的に近ければ同じ応答を返す方式です。完全一致を超えた再利用ができる一方、後述の本質的リスクを抱えます。まず完全一致・意味を保存する正規化で足りないかを確認し、それでも必要なときにセマンティックを評価します(Redis の実装ガイド )。

セマンティックキャッシュの構造と本質的リスク

セマンティックキャッシュの仕組みはシンプルです。

  • 構造: 入力を埋め込みでベクトル化し、キャッシュ済みの質問ベクトルと類似度を計算。しきい値内で最も近いものがあれば、その応答を返します
  • 本質的リスク(類似 ≠ 同一): 意味的に近くても、答えは違うことがあります。「東京の明日の天気は?」と「大阪の明日の天気は?」は埋め込み上は近いですが、答えは別です。「解約できますか?」と「解約したくないのですが?」も近くて逆です。しきい値を緩めるほど、この誤ヒットが増えます
  • 誤ヒットの被害を設計する: 誤ヒットは「速く・確信を持って・間違った答えを返す」ため、素の間違いより気づきにくく厄介です。しきい値は「ヒット率」でなく「誤ヒットの被害コスト」で決めます。間違えても軽微な用途は緩く、間違えると損害が出る用途は厳しく(またはセマンティックを使わない)

キャッシュしてよい応答の判断

そもそもキャッシュに向く応答と向かない応答があります。向かないものをキャッシュすると、事故になります。

  • 向く: 決定的(同じ入力に同じ答えでよい)・非パーソナライズ(誰に対しても同じ)・鮮度不問(古くならない)。例: 一般的な用語説明、定型 FAQ、変わらない仕様の質問
  • 向かない: パーソナライズされた応答(ユーザーの文脈・権限で変わる)・鮮度が要る情報(残高・在庫・当日の状況)・非決定的でよい創作系。これらをキャッシュすると、他人の答え・古い答え・不適切な使い回しになります
  • 判断を明示する: 「この応答はキャッシュ可か」を、パーソナライズ・鮮度・決定性の 3 軸で判断し、キャッシュ対象を絞ります。全応答を一律にキャッシュしないことが肝心です

無効化戦略

キャッシュは古くなるため、いつ捨てるかを設計します。放置は「古い答えを返し続ける」事故につながります。

テナント・ユーザー境界

マルチテナント複数のテナント(顧客・部門)が同一の Agent 基盤を共有する構成です。データ・設定・容量・費用を分けて設計し、認証キーを分けた場合も上流の共有上限と容量の隔離を別に確認します。・マルチユーザーのシステムでは、キャッシュの境界を誤ると情報漏えいになります。

  • キャッシュキーに境界を含める: テナント ID・ユーザーの権限スコープをキャッシュキーに含め、他テナント・他ユーザーの応答が混ざらないようにします(マルチテナント設計とテナント分離の分離原則の実装点)
  • パーソナライズ応答は共有しない: ユーザー固有の情報を含む応答は、そもそも共有キャッシュに載せません(前述の「向かない」)。権限で見え方が変わるデータは特に危険です
  • 境界の誤りは重大事故: キャッシュ経由の情報漏えいは、アクセス制御をすり抜けます。境界設計はコスト最適化より優先します

計測: ヒット率と品質低下を両方見る

キャッシュの効果は、片方だけ見ると誤ります。

  • ヒット率だけ見ない: 「ヒット率が上がった=成功」ではありません。しきい値を緩めればヒット率は上がりますが、誤ヒットも増えます。ヒット率と誤ヒット率・品質低下を並べて見ます
  • 誤ヒットを測る仕組み: サンプリングして「キャッシュ応答が、実際にモデルを呼んだ応答と乖離していないか」を評価します(Agent 評価の基礎の考え方をキャッシュ検証に適用)
  • コストと品質のトレードオフを可視化: 削減できたコスト・レイテンシと、誤ヒットによる品質低下を並べて、しきい値・対象を調整します

実務での注意点

アンチパターン

  • 全応答を一律にセマンティックキャッシュする → パーソナライズ・鮮度必須の応答まで使い回して事故になる → 決定性・非パーソナライズ・鮮度不問の応答に絞る
  • 語順・大小文字・空白を無条件に消す → 支払方向やコードの意味が異なる入力が同じキーになる → 入力仕様で意味を保存すると確認した変換だけを適用する
  • しきい値をヒット率だけで決める → 誤ヒットが増え、速く確信を持って間違える → 誤ヒットの被害コストでしきい値を決める
  • 知識源・モデル更新時にキャッシュを無効化しない → 古い答えを返し続ける → 更新イベントに無効化を連動させ、TTL も置く
  • キャッシュキーにテナント/権限境界を含めない → 他ユーザーの応答が漏れる → キーに境界を含め、パーソナライズ応答は共有しない
  • ヒット率だけを KPI にする → 品質低下を見逃す → 誤ヒット率・品質低下を併せて計測する

チェックリスト

  • 入力側(プロンプトキャッシュ)と出力側(応答キャッシュ)を区別している
  • まず完全一致・正規化一致で足りるかを確認し、必要な場合だけセマンティックにした
  • 正規化の意味保存を用途ごとに確認し、語順・否定・固有名詞・コードの差を区別するケースで検証した
  • しきい値を「誤ヒットの被害コスト」で決めている
  • キャッシュ対象を決定性・非パーソナライズ・鮮度不問の 3 軸で絞った
  • 知識源・プロンプト・モデルの更新にキャッシュ無効化を連動させ、TTL も置いた
  • キャッシュキーにテナント・権限境界を含め、パーソナライズ応答を共有していない
  • ヒット率と誤ヒット率・品質低下を両方計測している

関連トピック

参考資料

  • Redis: Semantic cache  — 類似度しきい値・名前空間・保持期限を持つ応答キャッシュの実装例。効果の数値は自分の質問分布で測定する(アクセス日: 2026-09-10)

TODO・未確認事項

なし

LLM ゲートウェイの設計バッチ処理の設計(バッチ API の活用)