3行でいうと
- Anthropicが提供するプロンプトキャッシュは、「前置きが完全に同じ」ときだけ効く、入力側の割引です。出力は毎回モデルが作ります。セマンティックキャッシュは、これとは別の層で、似た質問に保存済みの答えをそのまま返します。
- 「似ている」の判定はしきい値で決まり、公式の文書は、間違った答えを返す可能性を、仕組み上のものとして明記しています。しかも、数字の向きが製品で逆です。Azureは小さいほど厳しいと明記され、Redisは「類似度がしきい値を上回れば一致」という書き方から、大きいほど厳しい向きと読めました。
- 実用では、しきい値のほかに、利用者ごとの分け方、保存期間、複数ターンの会話の扱いを決める必要があります。節約の見積もりは、「当たる割合」と「毎回かかる照合の費用」の2つで決まります。
この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認しました。プレビューの製品もあり、仕様は変わることがあります。
先に結論
- セマンティックキャッシュは「意味が近い質問なら、答えも使い回せる」という仮定に賭ける仕組みです。外れたときに、利用者には間違った答えが返ります。公式の文書は、この外れを、仕組みに含まれる性質として説明しています。
- 向いているのは、同じ種類の質問が繰り返され、答えがあまり変わらない場面（よくある質問への応答など）です。Redisの文書は、よくある質問に答えるボットは、アカウント固有の金融の質問に答えるボットより緩いしきい値に耐えられる、という比較を書いています。
- 提供元のプロンプトキャッシュを先に使い、それでも足りないときにだけ検討する、という順番が考えられます。これは僕らの見立てです。
3つの「キャッシュ」を区別する
「キャッシュ」という言葉は、AIのAPIで少なくとも3つの別の意味で使われます。
| 何を保存するか | 当たる条件 | 当たると | |
|---|---|---|---|
| プロンプトキャッシュ（Anthropic） | 同じ前置きの処理 | 前置きが完全に同じ | 入力の単価が下がる。出力は毎回作られる |
| 完全一致の応答キャッシュ（Cloudflare AI Gateway） | 返事そのもの | リクエスト全体が同一 | モデルを呼ばずに返る |
| セマンティックキャッシュ（Azure、Redis、GPTCache） | 質問の意味の数値化と返事 | 質問の意味が、しきい値以内に近い | モデルを呼ばずに返る |
Anthropicの文書は、キャッシュに当たるには、前置きが100%同じであることが要ると書き、似ているだけの前置きは当たらないと説明しています。このキャッシュは、組織をまたいで共有されません。
Cloudflareの文書は、同一のリクエストにだけ効くと書き、キー（SHA-256の値）は、提供元、エンドポイント、モデル、認証の見出し、リクエストの本文全体から作られます。意味の近さで探すセマンティック検索は、将来の計画として書かれていて、現時点では提供されていません。
プロンプトキャッシュの料金や条件の細かい話は、別の記事で扱っています。ここでは、セマンティックキャッシュが、その外側の層だと押さえておけば十分です。
仕組み：保存と検索の流れ
AzureとRedisの文書から、共通の流れが読み取れます。
- 質問が来たら、先に埋め込み（文章の意味を数字の列にしたもの）を作ります。これには別のモデルを呼びます。
- 保存済みの質問の埋め込みと照らし合わせ（ベクトル検索）、近さ（類似度）が基準を満たす保存済みの質問を探します。
- あれば、保存済みの返事を返します（ヒット）。モデルは呼びません。
- なければ、モデルを呼んで答えを作り、質問の埋め込みと答えを保存します。保存期間（TTL）を決めておきます。
Azure API Managementでは、これが2つの設定（ポリシー）に分かれていて、受け付ける側に照合（llm-semantic-cache-lookup）、返事を返す側に保存（llm-semantic-cache-store）を置きます。保存の側で、保存期間を秒で決めます（文書の例は60秒）。対応するAPIは、OpenAIのChat CompletionsとResponses、AnthropicのMessages（v2の階層のみ）、Google Vertex AIです。照合の失敗はエラーにならない、と書かれています。
Redisの「LangCache」では、検索の呼び出し（entries/search）で質問を送り、空なら自分でモデルを呼んで、保存の呼び出し（entries）で質問と答えを送ります。
GPTCacheは、MITライセンスのPythonのライブラリで、埋め込みの生成、類似度の評価、返事の保存、ベクトルの保存（ベクトルデータベース。Milvus、FAISS、Chroma、Qdrantなど）を、4つの部品として持つ作りです。
しきい値：数字の向きが逆
「どれくらい近ければ、同じとみなすか」の数字がしきい値です。
- Azure：
score-thresholdは0.0から1.0で、小さいほど、より近い意味でないと返しません。文書は、低い値（例えば0.05）から始めて調整するよう勧め、0.2を超えると、不一致が起きうると書きます。敏感な場面では低くする、とも書かれています。設定の説明の例は0.05で、有効化の手順の例は0.15です。 - Redis（LangCache）：既定は0.85で、始める目安は0.8から0.9です。高いほど厳しい向きと読めます（原文は「類似度がしきい値を上回れば一致」と書き、数字の大小と厳しさは直接は書いていません）。厳しくすると間違った答えのリスクが減る、とは書かれています。
数字をそのまま比べることはできません。どちらの数字も、「どの距離の定義か」は文書で確認できませんでした。Redisは距離の計算を書いておらず、Azureも、点数の定義は読んだ範囲に見当たりませんでした。厳しい側の値から始めて調整する、というのが、2社の共通の勧めです。Redisは、「まず厳しく」始めるよう書いています。
Azure API Managementの設定項目（公式の記載）
llm-semantic-cache-lookup
| 項目 | 必須 | 内容 |
|---|---|---|
score-threshold |
はい | 0.0〜1.0。小さいほど近い意味が必要 |
embeddings-backend-id |
はい | 埋め込みを作る呼び出し先 |
embeddings-backend-auth |
はい | system-assigned のみ |
ignore-system-messages |
いいえ（既定 false） | true にすると、システム文を比べる対象から外す。文書は true を推奨 |
max-message-count |
いいえ | 会話の件数がこの数を超えたら、キャッシュを使わない |
vary-by（子要素） |
いいえ | キャッシュを分ける条件。契約（サブスクリプションID）などで分ける。複数あれば連結 |
llm-semantic-cache-store：duration（秒、必須）、cache-response（既定 false。省略時は200 OKの返事だけ保存）。
その他の記載：外部のキャッシュ（Azure Managed Redis。検索の機能RediSearchが必要で、キャッシュを作るときにしか有効にできない）と、埋め込み用の別のモデルの配備が要ります。照合の直後に、レート制限を置くよう勧められています。コンテンツの安全性のポリシーも検討するよう書かれています。
落とし穴
公式の文書に書かれた点を、4つにまとめます。
1. 外れる（偽の当たり）。 Azureの2つの文書は、似ているだけの質問に、間違った、古い、またはそのリクエストに安全でない返事を返すことがあるので、評価して安全策を足すよう書いています。GPTCacheの文書は、当たりの誤り（偽陽性）と、当たるはずのものが外れる誤り（偽陰性）の両方が起きうると書いています。
2. 古くなる。 保存期間（TTL）が長いほど、世の中や社内の情報が変わったあとも、古い答えを返し続けます。Azureの例は60秒でした。どのくらいが適切かは、答えの内容によります。僕らが読んだ範囲では、目安の数字は見当たりませんでした。
3. 分けずに混ぜる。 Azureは vary-by で、契約（サブスクリプションID）ごとにキャッシュを分ける例を示しています。分けないと、ある人の情報を含む答えが、似た質問をした別の人に返ることがある、というのは僕らの推論です。Redisは、最大5個の属性（タグ）を付けられると書いています。提供元のキャッシュは組織ごとに分かれていますが、自分で作る層は、自分で分ける設計が要ります。
4. 会話の途中。 複数ターンの会話では、直前の1文だけが似ていても、文脈が違えば答えは違います。Azureの max-message-count は、会話が長いときにキャッシュを使わない設定で、ignore-system-messages は、システム文を比べる対象から外す設定です。
GPTCacheの文書には、運用面の注意もあります。保存の入れ替えが件数だけで決まり、メモリ不足の原因になりうること、APIが変わりうること、新しいモデルやAPIの対応を維持者が止めていること、他のLLM（AnthropicやHugging Face Hubなど）への対応が、READMEの一覧で未完了の項目になっていることです（Hugging Faceは、埋め込みの側では対応済みと別に書かれています）。
費用：当たる割合と、毎回の照合費の2つで決まる
セマンティックキャッシュは、当たれば本体のモデルの呼び出しが丸ごと要りません。しかし、当たるかどうかにかかわらず、質問のたびに埋め込みを作る費用と、保存や検索の費用がかかります。簡単な式は次のとおりです（僕らの整理）。
1件あたりの節約 ≒ ヒット率h × 本体の1件の費用C − 照合の1件の費用e
損益分岐のヒット率 ≒ e ÷ C
例えば、eがCの20分の1なら、ヒット率が5%を超えると、費用の面では黒字になる、という計算です（数字は式の説明のための仮の値です）。この式には、間違った答えを返した損害は入っていません。
Redisの文書は、節約の目安を「月の出力トークン費 × ヒット率」とし、入力トークンの分は、埋め込みと保存の費用とほぼ相殺される、と書いています。例は、月の費用が200ドルで、60%が出力なら出力は120ドル、ヒット率50%なら約60ドルの節約、という計算です。これはRedisの試算の例で、実測値ではありません。
プロンプトキャッシュは、当たったときの読み取りが、通常の入力の0.1倍（モデルによっては0.05倍など）とAnthropicのプロンプトキャッシュの文書に書かれていますが、出力は通常どおりかかります。つまり、セマンティックキャッシュが節約できるのは、プロンプトキャッシュでは削れない出力側の費用です。その代わり、間違いの可能性を引き受けます。
使うかどうかの見立て
見立てです。次のように考えると、無理が少ないと思います。
- まず、前置きを固定してプロンプトキャッシュを効かせ、出力を短くする（出力の上限を決める）。それでも費用や速さが足りないときに、検討する。
- 質問が決まったパターンに集まり、答えが短期間で変わらない場面（よくある質問、社内手続きの案内）から始める。個人情報を含む答えや、日付に依存する答えは、対象から外すか、利用者ごとに厳密に分ける。
- しきい値は厳しいほうから始め、当たった例を抜き取りで確かめ、少しずつ緩める。厳しいほうから始める点は、Redisの文書が勧めるとおりです。
- 当たった件数と、人が「間違い」と指摘した件数を、記録する。
気をつけること
- この記事は、実際に使って確かめた記録ではありません。文書に書かれた機能と注意の整理です。
- Redisのページは、最初に取得したURLでは本文が取れず、移転後のURL（
context-engine以下）で読みました。LangCacheはプレビューと書かれています。 - Redisの距離の計算方法、保存期間の既定値、削除の仕組みは、読んだページに書かれていませんでした。Azureの点数の定義も、読んだ範囲では確認できていません。「ない」とは断定しません。
- 埋め込みモデルの1トークンあたりの価格は、OpenAIとGoogleの料金ページの範囲で見つけられなかったので、費用の式は記号のままです。
- GPTCacheは、公式のGitHubのREADMEです。最新のリリースの日付は、取得した範囲に出ていませんでした。「10倍安く」「100倍速く」という見出しの主張は、プロジェクト自身の表現で、この記事では確認していません。
- WebFetchは要約を返すため、原文のままではなく、言い換えています。要約に混じった推論は、事実として使っていません。
- 料金や仕様、対応モデルは、よく変わります。個別の判断は、公式の文書で最新を確認してください。助言ではありません。
出典
- llm-semantic-cache-lookup policy（Azure API Management、Microsoft Learn、Microsoft、2026年10月16日確認）
- llm-semantic-cache-store policy（Azure API Management、Microsoft Learn、Microsoft、2026年10月16日確認）
- Enable semantic caching for LLM APIs（Azure API Management、Microsoft Learn、Microsoft、2026年10月16日確認）
- LangCache（Redis Docs、Redis、2026年10月16日確認）
- LangCache concepts（Redis Docs、Redis、2026年10月16日確認）
- Caching（AI Gateway、Cloudflare Docs、Cloudflare、2026年10月16日確認）
- GPTCache（GitHub、Zilliz、2026年10月16日確認）
- Prompt caching（Claude Platform Docs、Anthropic、2026年10月16日確認）
更新履歴
- 2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した