LLM セマンティック・キャッシング：95%ヒット率神話（そして実運用データが実際に示すこと）

今朝OpenAIのダッシュボードを開いて、あの懐かしい胃の底のような感覚を覚えました。先月より数字が高い。やっぱり。誰かがセマンティックキャッシュの話をしていました――「レスポンスを“ただ”キャッシュするだけで、コストを90%削減できる。」それで、あなたは調べてみたのです。

ベンダーのページには、どこも同じことが書かれています。95%のキャッシュヒット率、90%のコスト削減、ミリ秒のレスポンス。ですが、あなたは自分たちのトラフィックで数字を計算してみると、現実はまったく違いました。かなり、です。

この記事では、セマンティックキャッシュが実際にどう機能するのか、公開されている本番環境のヒット率（マーケティング数字ではない）、そしてどんなユースケースが恩恵を受けるのか――逆にどんな用途には向かないのか、を分解して説明します。

TL;DR

1. 公開された本番環境のヒット率は20〜45%であり、90〜95%ではありません。95%という数字は、キャッシュヒットの頻度ではなく、キャッシュマッチの精度を指しています。
2. 20%のヒット率でも実際にお金を節約できます。月5KドルのLLM請求であれば月1,000ドルです。そのうえキャッシュされたリクエストのレイテンシは2〜5秒から5ミリ秒未満にまで削減されます。
3. まずは厳密キャッシュから始めます。セマンティックキャッシュを追加するのは、その追加によるわずかな改善が複雑さに見合う場合だけにしてください。

厳密キャッシュ（Exact Caching）とセマンティックキャッシュ：別々の問題

アーキテクチャに踏み込む前に、この区別が重要なのは、多くのチームはまず厳密キャッシュから始めるべきであり、厳密キャッシュだけでは十分にカバーできない場合に限ってセマンティックキャッシュを追加するべきだからです。

厳密キャッシュ（Exact caching）

SHA-256で、プロンプト全体（モデル名、temperature、その他のパラメータを含む）をハッシュ化します。ハッシュが保存されたリクエストと一致したら、キャッシュされたレスポンスを返します。あいまいさはゼロです――プロンプトは同一なので、そのレスポンスも正当です。

cache_key = sha256(model + prompt + str(temperature) + str(max_tokens))
cached = redis.get(cache_key)
if cached:
    return cached  # <5ms, zero LLM cost
response = call_llm(prompt)
redis.set(cache_key, response, ttl=3600)
return response

長所: 偽陽性なし。サブミリ秒のルックアップ。実装が簡単。
短所: 言い換えられた重複は取り逃します。「パスワードをリセットするには？」と「パスワードリセットのヘルプ」は別々のハッシュになります。

厳密キャッシュ単体でも、思ったより多くのトラフィックを捉えられます。平均的な本番アプリは15〜30%の同一リクエストを送ります。自動化されたパイプライン、リトライ、そして同じFAQを聞くユーザーなどが要因です。

セマンティックキャッシュ（Semantic caching）

プロンプトのベクトル埋め込み（embedding）を生成し、保存された埋め込みとコサイン類似度で比較します。類似度がしきい値を超える場合は、キャッシュされたレスポンスを返します。言い換えられた重複を拾えるようになります。

embedding = embed_model.encode(prompt)  # ~2-5ms
matches = vector_db.search(embedding, threshold=0.92)
if matches:
    return matches[0].response  # <5ms total
response = call_llm(prompt)
vector_db.upsert(embedding, response, ttl=3600)
return response

長所: 文言が異なっていても、意味的に類似したリクエストを拾える。
短所: 埋め込み生成に2〜5msかかります。偽陽性が発生する可能性があります。しきい値の調整は重要で、ユースケース依存です。

「95%」神話：数字は実際どう言っているのか

「95%のキャッシュヒット率」という主張は、ベンダーのマーケティングページのあちこちで見かけます。では、公開されているデータは実際に何を示しているのでしょうか：

95%という数字は、たどっていくとほぼ常にマッチ精度を指しています。つまり「キャッシュが返すレスポンスがクエリに対して正しい」割合が95%という意味です。キャッシュにヒットするクエリが95%という意味ではありません。これらは根本的に異なる指標です。

本番環境でのセマンティックキャッシュの率直な範囲は20〜45%のヒット率です。ユースケースの影響が非常に大きいです。

学術ベンチマークが誤解を招く理由：学術ベンチマークでは、似た質問を意図的に同じグループにまとめた、厳選されたデータセットでテストします。本番トラフィックはもっとごちゃごちゃしています――実際のクエリの60〜70%は、本当に一意です。研究論文で示される61〜69%のヒット率は、本番の多様性に触れるとそのままでは通用しません。

ユースケース別のヒット率：キャッシュが効く（効かない）場所

パターン：回答の範囲が限定され、入力が反復される場合はキャッシュがよく効きます。オープンエンドで、文脈に依存する、あるいは創造的なタスクでは効きません。

閾値問題：0.85 vs. 0.92 vs. 0.98

コサイン類似度の閾値（しきいち）は、セマンティックキャッシュにおいて最も重要で、かつ最も語られないことが多い設定です。これは、あなたのキャッシュが「役に立つ」のか「危険」なのかを決めるつまみ（ノブ）です。

• 閾値 0.85（強気）: キャッシュヒットは増えますが、誤検知率も高くなります。「パスワードをリセットする方法」は「メールアドレスを変更する方法」にマッチするかもしれません—意図は似ていますが答えが違います。回答が多少不正確でも許容される、FAQのようなユースケースに適しています。
• 閾値 0.92（バランス型）: 多くの本番運用ユースケースにおける最適域（スイートスポット）です。明確な言い換えは拾いつつ、区別されるべき（ただし似ているだけの）クエリは弾きます。
• 閾値 0.98（慎重）: ほぼ完全一致のマッチングです。誤検知は非常に少ない一方で、拾えるのは最も明白な言い換えに限られます。この時点では、厳密なキャッシュがほぼ同量を、誤検知ゼロのリスクで実現できます。

ユニバーサルに正しい閾値はありません。アプリケーションにおける誤った回答のコスト次第です。わずかに間違ったFAQ回答を返すカスタマーサポートボットなら許容できます。しかし、別の症状に対するキャッシュ回答を返してしまう医療アドバイス用アプリは危険です。

誰も警告してくれない5つの失敗パターン

1. 同一に見える文脈依存クエリ

ユーザーAが注文番号#4521について「状況は？」と聞き、ユーザーBが注文番号#7893について同じく聞く場合、埋め込み（エンベディング）はほぼ同一になります。ユーザー単位またはセッション単位のキャッシュキーがないと、ユーザーBはユーザーAの注文状況を取得してしまいます。キャッシュキーには関連する文脈を含める必要があります—プロンプト文だけでは不十分です。

2. 時間に敏感なクエリが陳腐な回答を返す

「GPT-5の最新価格はいくら？」を先週キャッシュしていた場合、今週価格が変わっていれば間違いになります。TTLは役立ちますが、適切なTTLはクエリの種類によって異なります。価格の質問は数時間単位のTTLが必要です。FAQ回答は数日間キャッシュできます。万能のTTLは、陳腐な回答か低いヒット率のどちらかを保証します。

3. 埋め込みモデルのドリフト

埋め込みモデルを更新すると、これまでキャッシュされていた埋め込みはすべて無効になります。古い埋め込みと新しい埋め込みの類似度スコアには意味がありません。埋め込みモデルのバージョンに紐づけたキャッシュ無効化の戦略が必要です。多くのチームは、モデル更新後に不正確なキャッシュ応答が急増してから、このことを苦い経験として学びます。

4. 不正なレスポンスによるキャッシュポイズニング

LLMが幻覚（ハルシネーション）や誤ったレスポンスを返し、それをキャッシュしてしまうと、以後の類似クエリはすべて同じ誤った回答を受け取ります。キャッシュは誤りを増幅します。対策：キャッシュ前に品質チェックを追加する（信頼度スコア、長さの検証、フォーマットチェックなど）、またはユーザーに「キャッシュされた回答は誤り」とフラグ付けさせてキャッシュの無効化（エビクション）を引き起こせるようにすることです。

5. ストリーミング応答のキャッシュの複雑さ

ほとんどのLLM呼び出しはストリーミングを使います（stream: true）。ストリームの途中でレスポンスをキャッシュすることはできません。レスポンス全文をバッファしてから保存する必要があります。キャッシュヒット時、あなたは次のどちらかを行います：完全なレスポンスを即座に返す（クライアントが期待しているストリーミング契約を壊す）か、キャッシュ済みレスポンスを分割して疑似的にストリーミングする（人工的な遅延を加える）かです。どちらもベンダーがほとんど言及しないエンジニアリング上の負担になります。

金額の計算：キャッシュが実際に節約するもの

月に $5,000 をLLM APIに費やしているチームの場合：

節約は2つの要因から生まれます：回避できたLLM呼び出し（明白なもの）と、削減されたレイテンシ（隠れたもの）です。キャッシュヒットは、2〜5秒ではなく5ms未満で返ってきます。顧客向けアプリケーションでは、このレイテンシ改善が金額の節約よりも重要になることがよくあります。

キャッシュを実行するコスト自体は最小です。埋め込み生成は小さなモデル（text-embedding-3-small、$0.02/1Mトークン）を使います。Redis か専用のベクタDBにおけるベクタストレージは、キャッシュサイズに応じて月$50〜$200です。インフラコストは、ヒット率が10%でも節約額の5%未満に収まります。

正しいアーキテクチャ：厳密キャッシュとセマンティックキャッシュをレイヤ化する

最善のアプローチは、まず厳密一致をチェックする2層キャッシュ（高速・ゼロリスク）を行い、必要なときだけセマンティックなマッチングにフォールバックすることです：

# レイヤー 1：厳密キャッシュ（サブms、誤検知ゼロ）
exact_key = sha256(model + prompt + params)
if exact_hit := cache.get(exact_key):
    return exact_hit

# レイヤー 2：セマンティックキャッシュ（2-5ms、閾値で制御）
embedding = embed(prompt)
semantic_hit = vector_db.search(embedding, threshold=0.92)
if semantic_hit:
    return semantic_hit.response

# キャッシュミス：LLMを呼び出す
response = call_llm(prompt)

返却形式: {"translated": "翻訳されたHTML"}# 両方のレイヤーに書き込むcache.set(exact_key, response, ttl=3600)
vector_db.upsert(embedding, response, ttl=3600)

return response

オンボーディングした平均的なアプリでは、リクエストの18%が初日から完全な重複であることが分かります — 意味的なマッチングがまだ始まる前です。

キャッシュバックエンドは、あなたが思うほど重要ではありません。インメモリはシングルインスタンスのプロキシに適しています。Redisは分散デプロイで機能します。専用のベクターデータベース（Qdrant、Pinecone）は、キャッシュの件数が100万エントリを超える場合に限って価値があります — それ未満なら、ベクタ検索付きのRedisで十分で、運用もより簡単です。

実装から始めるのではなく、計測から始める

最もよくあるミスは、トラフィックの様子を理解する前にキャッシュ層を構築してしまうことです。意味的キャッシングの実装に2週間使ったとしても、トラフィックの90%がユニークで、文脈依存のクエリであり、ヒット率の天井が12%だと分かるかもしれません。

まず計測します：

1. 1週間、すべてのプロンプトをログに残します。 ハッシュ化します。完全な重複の数を数えます。これがあなたの下限です。
2. 1,000件のリクエストをサンプルします。 埋め込みを生成します。それらをクラスタリングします。0.92の類似度しきい値以内に入る数を数えます。これがあなたの上限です。
3. 節約見込みを見積もります。 下限のヒット率 × 毎月のLLM支出 ＝ 確実な節約。上限のヒット率 × 毎月の支出 ＝ 最大で可能な節約。両方の数値が月200ドル未満なら、キャッシングにかかる工学的な労力は割に合いません。

両方の数値が労力を正当化するなら、まずは完全なキャッシュだけから始めてください。2週間実行します。次に、その上に意味的キャッシングを追加し、限界的な改善幅を比較します。意味的キャッシングが完全キャッシングに対して5〜8ポイントしか追加しないのであれば、誤検知のリスクによって、その複雑さが正当化されない可能性があります。

私たちはPreto.aiを構築しています — あなたのトラフィック全体で、完全に重複したリクエストや意味的に類似したリクエストを検出して、LLMコストを最適化します。何かを作る前に、キャッシュの可能性と見込みの節約額を確認できます。最大10Kリクエストまでは無料です。