セマンティックキャッシュとは？LLMの回答を安全に再利用する設計

セマンティックキャッシュを使うと、同じ内容に対するモデル呼び出しを減らせます。ただし、表現の異なるリクエストに同じ回答を返しても問題がない場合に限ります。処理は、プロンプトの埋め込みを作る、近傍を検索する、しきい値で判定する、保存済みの回答を返すかモデルを呼び出す、という4ステップです。難しいのは、よく似ていても、その回答を返してはいけないケースを見分けることです。

まずは、内容が安定しているヘルプセンターや、公開されている製品FAQから始めましょう。回答を生成する大規模言語モデル（LLM）が、質問の言い回しが変わるたびに、同じ公開ポリシーを説明し直す必要はありません。一方、口座残高や注文状況、返金処理のような操作は、この共有キャッシュの対象から外します。

以下の実装に関する情報は、2026年10月21日に一次資料のドキュメントで確認したものです。説明に使う店舗は架空のもので、類似度スコアも判断の仕組みを示すための例です。実際に埋め込みを計測した結果ではありません。

セマンティックキャッシュと完全一致キャッシュ、プロンプトキャッシュの違い

セマンティックキャッシュは、新しいリクエストが以前のリクエストと同じ意味だと判断できるときに、過去の回答を再利用します。サポート窓口の担当者が、承認済みの回答を書類棚から取り出す場面を思い浮かべてください。質問の言い方が違っても同じ書類を使えますが、担当者は、その回答がどのポリシーと顧客に適用できるかを確認します。

**埋め込み（embedding）**は、意味を比較するためにテキストを数値で表したものです。キャッシュには、以前のプロンプトの埋め込みと、その回答、識別に必要なコンテキストを保存します。新しいプロンプトも埋め込みに変換し、ベクトル検索で近いエントリを探します。Microsoftのセマンティックキャッシュのドキュメントでは、この回答再利用の仕組みと、会話のコンテキストが重要になる理由が説明されています。

キャッシュの種類によって、省ける処理は異なります。

完全一致の回答キャッシュでは、「このヘッドホンを返品できますか？」と「このヘッドホンは返品可能ですか？」は、通常は別のキーになります。セマンティックキャッシュなら、こうした言い換えを対応づけられます。ただし、どちらを使っても、古い回答や適用範囲を誤った回答を安全に使えるようになるわけではありません。

プロバイダー側のプロンプトキャッシュは、質問の意味が似ているからといって過去の回答を取り出す仕組みではありません。 Anthropicのプロンプトキャッシュのドキュメントでは、一致するプロンプトのプレフィックスを再利用する処理と、出力の生成が明確に分けられています。アプリケーションは引き続き、モデルに回答の生成を依頼します。この違いの背景にあるモデル内部の状態については、KVキャッシュの解説で説明しています。

これらのキャッシュは併用できます。完全一致の回答キャッシュ、セマンティックな回答キャッシュの順に確認し、それでも回答が見つからなければ、利用可能な場合はプロバイダー側のプロンプトキャッシュを使ってモデルを呼び出します。セマンティックキャッシュの効果は、こうした最適化を済ませた状態を基準に測定してください。

セマンティックキャッシュでLLMの回答を再利用する4ステップ

キャッシュ検索の目的は、許可されたコンテキストの範囲内で、再利用できる回答を見つけることです。検索を始める前に、認証済みのユーザーまたはテナント、適用されるポリシー、言語、そして回答内容を左右するその他の情報を確定させます。

1. 1

   1. プロンプトを埋め込みに変換する

   受け取った質問を、保存済みエントリと同じ埋め込みモデル、および互換性のある設定で埋め込みに変換します。リクエストの解釈に必要な会話のコンテキストも含めるか、単独で意味が通じる質問だけをキャッシュの対象にします。

   「私のものはどうですか？」だけでは、キャッシュキーとして不十分です。「私のもの」が何かを特定するために非公開の注文データが必要なら、共有の回答キャッシュを経由させません。

2. 2

   2. 近傍の候補を検索する

   許可されたスコープの中で、保存済みプロンプトの埋め込みから近い候補を探します。各候補の回答とメタデータ、つまり所有者、参照元のバージョン、有効期限を記述するフィールドを取得します。

   最近傍とは、見つかった中で最も近いエントリにすぎません。無関係なエントリである可能性もあります。何かが見つかっただけでは、キャッシュヒットとはいえません。

3. 3

   3. しきい値と再利用条件を確認する

   候補の類似度または距離を、事前に調整したしきい値と比較します。そのうえで、商品の状態、ポリシーのバージョン、アクセス可能な範囲など、回答を左右するフィールドが完全に一致していることを確認します。

   スコアが基準を満たしていても、コンテキストが一致しなければキャッシュミスとして扱います。必要なコンテキストを確実に特定できない場合も、同じくミスとして扱います。

4. 4

   4. 保存済みの回答を返すか、モデルを呼び出す

   ヒットと判定できたら、新たな生成呼び出しを行わずに保存済みの回答を返します。ミスの場合は通常のモデル呼び出しや検索ワークフローを実行して結果を返し、キャッシュへの保存条件を満たす場合に限って保存します。

   モデルの出力をすべて、自動的に再利用可能な回答にしてはいけません。誤りを含む回答、個人情報、一時的なツールの実行結果に依存する回答は、キャッシュに適さない場合があります。

セマンティック検索との大きな違いは、検索した後の処理にあります。検索は関連する資料を提示しますが、回答キャッシュは、過去の回答を今回のリクエストへの回答としてそのまま返すことがあります。そのため、誤った一致の影響が大きくなります。

再利用できる例と、似ていても再利用してはいけない例

条件が変わるだけで、よく似た質問でも同じ回答を使えなくなることがあります。未開封のヘッドホンは返品でき、開封済みのヘッドホンは返品できない架空の店舗を考えてみましょう。これは説明用の設定であり、実在する小売店のポリシーを示すものではありません。

キャッシュには、次の情報が保存されています。

• 保存済みの質問：「未開封のヘッドホンを返品できますか？」
• 保存済みの回答：「はい。この店舗の返品ポリシーでは、未開封のヘッドホンは返品対象です。」
• 保存済みのコンテキスト： 店舗の現行ポリシーのバージョン、ヘッドホンという商品カテゴリ、英語、condition=unopened。

この例に限り、コサイン類似度の下限を0.90とします。コサイン類似度はベクトルの向きを比較する指標であり、回答が正しい確率ではありません。以下のスコアは、判断の仕組みを示すために設定した架空の値です。

どちらも、スコアはしきい値を上回っています。しかし、回答を再利用できるのは、元の質問を言い換えただけのケースです。後者は商品も操作も、質問の表現の多くも共通していますが、回答を決める条件が変わっています。

商品の状態が分かっているなら、アプリケーションは構造化フィールドとして保持すべきです。テキストから状態を抽出する必要があり、その結果が不確かな場合は、通常の回答経路に戻します。埋め込みをもう一度比較しても、商品が開封済みかどうかを把握する代わりにはなりません。

回答を安全に再利用するための設定

しきい値、有効期間、スコープは組み合わせて機能します。しきい値だけを調整しても、意味は同じなのに別の回答が必要なリクエストへの対策にはなりません。

類似度のしきい値は、誤った回答を基準に調整する

しきい値を厳しくすると、有用なヒットの一部を逃す代わりに、誤った一致を減らせます。緩くすると再利用は増えますが、誤った再利用も増える可能性があります。自分たちの実際のリクエストから、言い換えとハードネガティブ、つまり質問は似ていても回答が異なるべき例を集め、ラベルを付けたデータセットを作りましょう。

日付、製品のバリエーション、否定表現、通貨、アカウントの役割、会話履歴が異なる例を含めます。判断すべきなのは、プロンプトが同じ話題を扱っているかではなく、保存済みの回答が新しいリクエストに対して有効かどうかです。

設定を変える前に、その指標の意味を確認してください。Redisのベクトル検索を使うアプリケーション向けのライブラリ、Redis Vector Library（RedisVL）では、distance_thresholdをRedisのCOSINE距離で指定します。ドキュメント上の範囲は0から2で、値が小さいほど一致の条件が厳しくなります。類似度の下限を指定する方式では、通常は逆方向に値を調整します。RedisVL APIリファレンス。

埋め込みモデル、データセット、製品をまたいで、そのまま使える万能なしきい値はありません。埋め込みモデルを変える場合も、計画的なインデックスの移行と、しきい値の再調整が必要です。古いベクトルと新しいベクトルを安易に混在させてはいけません。

TTLによる期限切れは、補助的な対策にすぎない

**Time to live（TTL）**は、エントリが期限切れになるまで再利用の対象であり続ける期間です。キャッシュにどれだけ長く置けるかではなく、古い回答をどこまで許容できるかで決めます。

内容が安定したドキュメントに基づく回答と、最新の在庫状況に関する回答では、必要な鮮度が異なります。後者はキャッシュしないほうがよい場合もあります。ポリシーを緊急に訂正した場合は、TTLが残っていても、影響するエントリを即座に無効化すべきです。

参照元やポリシーのバージョンを、再利用条件の確認に組み込みます。バージョンが変われば、古いエントリは一致しなくなります。RedisVLでは、デフォルトのTTLとエントリごとの上書きを設定できますが、適切な有効期間を決めるのはアプリケーション側です。RedisVLキャッシュAPI。

ユーザーごとのスコープは、厳密な境界にする

共有キャッシュを使うのは、共有を前提とした回答だけにします。テナントとは顧客組織のことです。同じ組織内でも従業員ごとにアクセス権が異なる場合は、テナントの境界だけでは不十分です。

特定のアカウントに関する回答には、認証済みのユーザーと現在の権限を反映したスコープが必要です。「私の更新日はいつですか？」という質問で、同じ質問をした全員の回答を横断検索してはいけません。本人を識別する情報は、ユーザーが書いた文や埋め込みではなく、信頼できるアプリケーションの認証から取得します。

候補を選ぶ前にスコープで絞り込み、回答を返す前に認可を検証します。権限の変更やデータの削除があれば、その影響を受ける再利用の経路を無効化しなければなりません。RedisVLのfilterable_fieldsとfilter_expressionはフィルタリングのための基本機能を提供しますが、アプリケーションの認可ポリシーを自動で定義するものではありません。フィルタリングのパラメータ。

コンテキストとバージョンを回答にひもづける

回答を左右するシステムプロンプト、モデルの要件、出力スキーマ、言語、参照元のバージョンに応じて、エントリのスコープを定めます。文章として保存した回答では、別の構造化形式を求める新しいリクエストには対応できません。

会話をキャッシュする場合、最後の文が同じでも、それ以前のどの話題を指しているかは異なり得ます。Microsoftのコンテキストウィンドウの解説では、この問題が明示されています。関連する履歴を表現し、検証できるのでなければ、単独で意味が通じる質問から始めてください。

実装方法を選ぶ：ゲートウェイ、Redis、ライブラリ

回答の適用範囲をどこで制御できるかを基準に、組み込む場所を選びます。以下は実装の例であり、相互に置き換えられる製品のランキングではありません。

ゲートウェイで実装する：Kong AI Semantic Cache

Kong AI Semantic Cacheは、KongのAI Gateway Enterpriseに含まれるプラグインです。モデルへのリクエストが通る入口であるゲートウェイに、セマンティックな回答キャッシュを配置します。ドキュメントでは、Redisまたはpgvectorの構成を使う埋め込みベースの検索が説明されています。設定リファレンスには、cache_ttl、message_countback、vectordb.thresholdが記載されています。

中央で管理され、同じ処理を繰り返すリクエストフローに適しています。主な制約は、アプリケーションのコンテキストです。ゲートウェイで区別できるのは、設定やリクエストに渡された情報だけです。パーソナライズされたチャットで有効にする前に、ユーザーの分離と会話履歴の扱いを確認してください。

設定名についても確認が必要です。Kongのプラグイン概要によると、完全一致キャッシュのオプションを有効にしても、類似度による一致判定は無効になりません。このスイッチを「完全一致だけを許可する安全モード」と解釈しないでください。

Redisでセマンティックキャッシュを実装する

ベクトル検索機能を持つデータストアのRedisを使えば、アプリケーション側で検索とキャッシュミス時の処理を管理できます。RedisVLのドキュメントにあるSemanticCacheは、checkとstoreの操作、メタデータ、フィルター、TTLの制御を提供します。RedisVLのドキュメント。

アプリケーションがすでにテナント、ポリシー、レコードのバージョンを把握しており、結果を返す前にそれらの条件を適用する必要がある場合に向いています。同じ構成は、要件を満たす別のベクトルストアでも実装できます。プロンプトのベクトルで候補を探し、保存済みの回答とメタデータで再利用の可否を決める構成です。

その代わり、管理の責任を引き受ける必要があります。ベクトルインデックスだけでは、キャッシュへの保存条件、無効化、認可、正しい回答は得られません。これらを実装・監視し、使用するベクトルクエリをサポートする環境を運用する必要があります。

ライブラリを使う：GPTCache

セマンティックキャッシュを構築するライブラリのGPTCacheは、埋め込みの生成、回答の保存、ベクトル検索、類似度の評価を、設定可能なコンポーネントに分けています。ドキュメントでは、すべてのモジュールの組み合わせに互換性があるわけではないと、明示的に注意しています。

アプリケーション内で検索や評価の仕組みを試したい開発者に向いています。主な制約は、組み込み時の検証を自分たちで担う必要があることです。選んだアダプターが、現在のモデルSDKやデプロイ環境で動作するかを確認し、スコープと鮮度の確認も同様に組み込んでください。ライブラリで抽象化しても、セマンティックなヒットが正しいと保証されるわけではありません。

リクエストのルーティング層も選定中なら、AIゲートウェイの比較やLiteLLMとOpenRouterの比較も、全体の判断に活用できます。キャッシュは、ルーティング、認証情報、オブザーバビリティと並ぶ要件のひとつです。

自分たちのリクエスト構成でLLMのコスト削減効果を計算する

キャッシュで費用を節約できるのは、省けた生成コストが、埋め込み、検索、保存、運用のコストを上回る場合だけです。ミスも計算に含めてください。キャッシュの処理コストがかかったうえで、モデルも呼び出すためです。

集計期間と通貨を統一します。Nは、完全一致キャッシュでのヒットを除き、セマンティックキャッシュ層に到達した対象リクエスト数です。Hは、再利用可能と判定したセマンティックなヒット数、Gは、単純化のためリクエストごとに同額と仮定した生成コスト、Eは、対象リクエストあたりの埋め込みと検索のコスト、Wは、ミスあたりのキャッシュ書き込みコスト、Fは、その期間の固定的なインフラ費用と運用費用です。

計算式は次のとおりです。

• セマンティックキャッシュ層がない場合： N × G
• 導入した場合： (N − H) × G + N × E + (N − H) × W + F
• 差し引きの削減額： H × G − N × E − (N − H) × W − F

実際のログを使って計算しましょう。再利用可能と判定したヒット数に、それによって省けたモデルのコストを掛けます。そこから、対象リクエストすべての検索コスト、ミス時の書き込みコスト、固定費を差し引きます。生成コストには、キャッシュ未使用時の定価ではなく、プロバイダー側のプロンプトキャッシュによる効果を反映した金額を使ってください。

この前提では、費用を回収できる条件は次のようになります。

H > [N × (E + W) + F] / (G + W)

リクエストごとの処理が異なるワークロードでは、H × Gを、実際にヒットした各リクエストで省けた生成コストの合計に置き換えます。キャッシュに保存しない回答がある場合は、実際の書き込み回数を使います。リトライ、評価用の呼び出し、運用作業も、対応する費用の合計に含めてください。ヒット率だけでは、再利用によって費用を回収できたかは分かりません。

レイテンシも同じ考え方で評価します。ヒットすれば生成処理を省けますが、ミスすると生成の前に埋め込みと検索が加わります。特に遅い応答も含めて、両方の経路を記録してください。重複の少ないワークロードでは、たまに発生するヒットが高速でも、全体としては遅くなる可能性があります。

セマンティックキャッシュは、どこが過大評価されがちですか？

「意味が似ている」だけでは、同じ回答でよいとは限りません。 キャッシュは既存の回答を選ぶ仕組みであり、その回答が今も正しいか、返す権限があるか、最新かを保証するものではありません。

最も誤解を招きやすいのは、誤ったヒットを監査せずに、ヒット率の改善だけを見ることです。しきい値を緩めれば、ダッシュボードの数字はよく見えても、サポート担当者の対応し直す手間が増えることがあります。キャッシュ済みの回答を新しいリクエストと照合して確認し、特に、再利用を許可する境界に近いケースを重点的に見てください。

回答キャッシュは、検索拡張生成（RAG）の代わりにもなりません。RAGは、検索した資料をモデルに渡して回答の生成に役立てる仕組みです。キャッシュをその前段に置くことはできますが、RAGの処理を省けば、新しい資料の検索も省くことになります。キャッシュ済みの回答を参照元のバージョンにひもづけるか、元になる情報の最新性が必要なときは再利用を避けてください。

「注文をキャンセルして」は、再利用できる質問ではなく、操作として扱います。過去の完了通知があっても、新しい操作が認可されたか、実行されたかは分かりません。操作の実行と今回の結果の取得は、通常のアプリケーションの処理経路で行います。

今始めるべき人と、最初に取り組むこと

同じ公開情報への質問を繰り返し受けるアプリケーションの開発者は、対象を絞って始めましょう。 内容が安定した問い合わせの意図を選び、許可するスコープを定め、比較用に完全一致キャッシュの基準値を残します。アプリケーションが再利用を許可する回答の種類を広げずに、同じ内容の生成呼び出しを減らせます。

運用担当者は、まずシャドー評価を行います。 通常の回答を返し続けながら、キャッシュならどの回答を返していたかをログに記録します。同じ意味の言い換えと、似ているが同じ回答を使えない例にラベルを付け、許容できない誤りを基準にしきい値を調整します。キャッシュの処理負荷、有効期限の動作、保存されている回答そのものの品質を測定してください。

製品を導入する立場なら、分離と無効化が機能する証拠を求めましょう。 機能一覧にセマンティックキャッシュがあるだけでは不十分です。異なるユーザーから同じ質問が来た場合の扱いと、ポリシーを変更した直後の挙動を確認してください。

質問の多くが、変動するレコードや、適用範囲を切り分けられない複数ターンの会話に依存するなら、導入を待ちましょう。 再利用できるリクエストをすでに完全一致キャッシュでカバーできていれば、セマンティック検索を加える効果は小さいかもしれません。プロバイダー側のプロンプトキャッシュなら、完成済みの回答を再利用しなくても、繰り返される入力プレフィックスの処理に役立ちます。

次の月曜日に着手するなら、ヘルプセンターの問い合わせの意図をひとつ選び、その言い換えと、意図的に紛らわしくした質問を集めます。キャッシュのスコープと無効化ルールを定め、シャドーモードで再生してください。誤った回答につながるケースが安全に除外されることを確認してから、回答の再利用を有効にします。

よくある質問

セマンティックキャッシュとは何ですか？

過去の回答を保存し、意味の類似性を使って取り出す仕組みです。再利用には、コンテキストの一致、有効な権限、十分な鮮度も必要です。

LLMで比較すべきキャッシュには、どのような3種類がありますか？

このLLMの設計判断では、完全一致の回答キャッシュ、セマンティックな回答キャッシュ、プロバイダー側のプロンプトキャッシュを区別します。この記事の比較には有用な分類ですが、コンピューターのあらゆるキャッシュを普遍的に分類したものではありません。

セマンティックキャッシュはどう実装しますか？

許可するスコープを定め、入力されたプロンプトを埋め込みに変換し、候補を検索します。調整済みのしきい値と再利用条件を確認したうえで、保存済みの回答を返すか、モデルを呼び出します。再利用を有効にする前に、有効期限、無効化、誤ったヒットの監視も組み込んでください。

CDNは単なるキャッシュですか？

いいえ。コンテンツ配信ネットワーク（CDN）は、複数の拠点にコンテンツの配信を分散させる仕組みです。キャッシュは、そのために使う仕組みのひとつです。CloudflareのCDNアーキテクチャを参照してください。

CloudflareはCDNですか、それともWAFですか？

Cloudflareは、CDNサービスと、アプリケーションへのトラフィックをフィルタリングするWebアプリケーションファイアウォール（WAF）の両方を提供しています。どちらの名称も、それだけでLLMの回答をセマンティックキャッシュする機能を意味するわけではありません。Cloudflareのアーキテクチャ。

CDNとRedisはどう違いますか？

CDNは、エッジネットワークを通じてコンテンツを配信します。Redisは、アプリケーションがキャッシュなどに使えるデータストアで、設定次第でセマンティックキャッシュも構築できます。システム内で担う役割が異なります。

CloudflareはCDNだけを提供しているのですか？

いいえ。Cloudflareのリファレンスアーキテクチャには、DNS、ファイアウォール、その他のエッジサービスも記載されています。

KafkaはRedisより優れていますか？

解決する課題が異なります。Apache Kafkaは、イベントストリーミングのプラットフォームです。ここで説明したRedisによるセマンティックな回答キャッシュを、そのまま置き換えるものではありません。

NetflixはRedisを使っていますか？

はい。Redisは、Netflixによる優先度付きキューでのRedisの利用を紹介し、NetflixのTimestoneに関する記事へのリンクも掲載しています。ただし、この過去の事例は、LLMのセマンティックキャッシュを使っている証拠でも、自分たちのアプリケーションで導入すべき理由でもありません。

信頼できるAIアプリケーションづくりの実践的な情報は、ニュースレターへの登録で受け取れます。