これまでのコスト最適化の記事（AgentOps④・コスト編）やキャパシティ運用編では、セマンティックキャッシュ（回答キャッシュ）を「入れるべきもの」としておすすめしてきました。似た質問には過去の回答を使い回せば、LLMの呼び出しが減り、コストもレイテンシも下がります。
今回はその裏側を扱います。回答キャッシュは全利用者で共有されるため、1回の汚染が似た質問をしたすべての人に配られます。LLMに毒を入れるのは難しくても、キャッシュに毒を入れるのは、条件がそろえば「質問を1回投げるだけ」で済むことがあります。
本稿は、LLMルーティング層のセキュリティ設計ガイド（5/28）の続編です。「コスト最適化の層が、そのまま攻撃面になる」という構図を、今回はキャッシュ層で整理します。
対象読者：社内AIアシスタントやAI搭載SaaSを運用する情シス・開発チーム、CISO／セキュリティ担当、コスト削減のためにセマンティックキャッシュの導入を検討している方
免責事項：本記事は2026年9月時点の公開情報、研究論文および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。
- はじめに——”コスト削減の層”が、いちばん広く毒を配る層になる
- 前提——セマンティックキャッシュの仕組みと、なぜ危ないのか
- 攻撃の全体像——4つの手口
- 第1の防御層：キャッシュキー設計——「何を同じ質問とみなすか」を厳密にする
- 第2の防御層：書き込み前の検証——「キャッシュしてよい回答か」を判定する
- 第3の防御層：テナント分離——キャッシュ層にも”境界”を引く
- 第4の防御層：TTLと失効——”古い正解”を毒にしない
- 監視と検知——キャッシュを”見える化”する
- コストとのトレードオフ——「安全に効く」キャッシュにする
- 多層防御チェックリスト
- よくある質問（Q&A）
- まとめ——キャッシュは「過去の誰かの回答」を配る仕組みだと認識する
- 関連記事
- 参考リンク
はじめに——”コスト削減の層”が、いちばん広く毒を配る層になる
AIセキュリティの議論は、これまで「モデルに何を入力させないか」「モデルが何を出力しないか」を中心に進んできました。プロンプトインジェクション対策も、出力フィルタも、基本的にはLLMの入口と出口を守る考え方です。
ところが、セマンティックキャッシュを入れた瞬間に、LLMを通らない回答経路が生まれます。キャッシュにヒットした質問には、LLMは呼ばれず、保存済みの回答がそのまま返ります。そのとき、次のような問題が起こりえます。
- その回答が作られたときの入力のチェックは、今回の質問者には適用されていない
- その回答が作られたときの権限・テナントは、今回の質問者と同じとは限らない
- その回答が作られたときの社内規程・価格・手順は、今も正しいとは限らない
つまり、キャッシュは「過去のある時点・ある利用者・ある権限で作られた回答」を、条件の違う別の利用者に配る仕組みです。この性質を理解しないまま入れると、コスト削減の層が、組織でいちばん広く毒を配る層になってしまいます。
前提——セマンティックキャッシュの仕組みと、なぜ危ないのか
3種類の「キャッシュ」を区別する
LLMまわりで「キャッシュ」と呼ばれるものは、主に3種類あります。本稿が扱うのは3つ目のセマンティックキャッシュです。
| 種類 | 何を保存するか | ヒット条件 | 主なリスク |
|---|---|---|---|
| 完全一致キャッシュ | 質問文と回答のペア | 質問文が完全に一致 | キー設計ミスによるテナント間漏洩 |
| プロンプトキャッシュ（プレフィックス／KVキャッシュ） | プロンプト先頭部分の計算結果 | 先頭のトークン列が一致 | タイミングによる情報推測、ハッシュ衝突 |
| セマンティックキャッシュ（回答キャッシュ） | 質問の埋め込みベクトルと回答 | 意味が「似ている」（類似度がしきい値以上） | 汚染の拡散、類似度の悪用、テナント越境、古い回答の固定化 |
セマンティックキャッシュが特に危ないのは、ヒット条件が「一致」ではなく「似ている」だからです。言い回しが違う質問にも同じ回答を返せることがコスト削減効果の源泉ですが、同時に攻撃者が作った質問にも、正規の利用者の質問にも、同じ回答を返してしまうことを意味します。
1回の汚染が”何百人”に配られる構造
社内アシスタントで「経費精算の振込先を変更するには？」という質問が1日に数百回あるとします。セマンティックキャッシュは、最初の1回の回答を保存し、残りの数百回に使い回します。
もし最初の1回が攻撃者の質問で、その回答に偽の手順や偽のURLが含まれていたらどうなるでしょうか。以降、同じ意味の質問をした全員に、その偽の回答が配られます。しかもLLMは呼ばれないので、出力フィルタやガードレールがLLM側にしか入っていない構成では、2回目以降は一度もチェックされません。
既存記事との違い（本稿の守備範囲）
| 既存記事 | 扱った対象 | 本稿との違い |
|---|---|---|
| タイミング攻撃・サイドチャネル（4/26） | キャッシュヒットの時間差から情報を読み取る攻撃 | 本稿はキャッシュの中身そのものを汚す、または境界を越えさせる攻撃 |
| メモリ汚染（3/28） | 個々のエージェントの長期記憶 | 本稿は全員が共有するキャッシュ。被害が一気に広がる |
| マルチテナント分離（4/1） | データとベクトルDBの分離 | 本稿は見落とされがちなキャッシュ層の分離 |
| LLMルーティング層（5/28） | コスト層のうちルーティング | 本稿はコスト層のうちキャッシュ |
標準フレームワークでの位置づけ
OWASP Top 10 for LLM Applications（2025年版）には「キャッシュ」という独立項目はありませんが、本稿の攻撃は複数の項目にまたがります。
- LLM04：Data and Model Poisoning——キャッシュへの汚染回答の書き込み
- LLM02：Sensitive Information Disclosure——テナント・権限をまたぐキャッシュヒットによる漏洩
- LLM08：Vector and Embedding Weaknesses——埋め込みの類似度を悪用したキー衝突、アクセス制御の欠落
- LLM09：Misinformation——古くなった回答の固定化
研究面でも、2026年に入ってセマンティックキャッシュを狙う攻撃の報告が相次いでいます。NDSS 2026では、主要クラウドのセマンティックキャッシュ機能に対するポイズニング攻撃や、vLLM・SGLang・GPTCacheなどのサービング基盤におけるキャッシュ関連の脅威が報告されました。ICML 2026採択の論文では、埋め込みの類似度を「あいまいなハッシュ」とみなして衝突を起こし、LLMの応答を乗っ取る攻撃が示されています（詳細は末尾の参考リンクを参照）。
攻撃の全体像——4つの手口
攻撃1：キャッシュポイズニング（汚染された回答の書き込み）
攻撃者は、よく聞かれる質問と意味が近い質問を先回りして投げ、悪意ある内容を含む回答を生成させてキャッシュに書き込ませます。手口としては次のようなものがあります。
- プロンプトインジェクションとの組み合わせ：質問に指示を埋め込み、偽のURLや偽の手順を含む回答を生成させる。その回答が「正規の質問への回答」としてキャッシュされる
- 間接インジェクション経由：RAGが参照する文書やWebページに仕込んだ指示で回答を歪め、その回答がキャッシュされる
- キャッシュ未作成のタイミングを狙う：新機能のリリース直後、規程改定直後、キャッシュのクリア直後など、「最初の1回」を取りやすい時期を狙う
ポイントは、攻撃者が汚すのは自分の回答だけでよいことです。その回答がキャッシュに入れば、あとは仕組みが勝手に配ってくれます。
攻撃2：類似度しきい値の悪用（キー衝突・なりすましヒット）
セマンティックキャッシュは「類似度が0.9以上ならヒット」のように、しきい値で判定します。攻撃者はこの判定を逆手に取ります。
- 衝突を狙った質問の作成：表面上は無害だが、埋め込み空間では狙った質問に近くなる文を作り、汚染回答を「狙った質問のキー」に結び付ける
- 意図の異なる質問への誤ヒット：「解約方法」と「解約を防ぐ方法」、「A社の契約条件」と「B社の契約条件」のように、単語は近いが意味が違う質問が同じ回答に当たる。攻撃でなくても誤回答が起きる
- しきい値の緩さの探索：しきい値を下げてヒット率を上げている構成ほど、衝突を作りやすくなる
「ヒット率を上げたい」というコスト側の動機と、「別の意味の質問にはヒットさせたくない」という安全側の要請は、構造的に対立しています。
攻撃3：権限・テナントをまたぐキャッシュヒット（テナント間漏洩）
最も被害が大きく、しかも攻撃者が不要な「事故」として起こりやすいのがこれです。
- テナントをまたぐヒット：A社の社員が「当社の来期の価格改定は？」と聞いた回答がキャッシュされ、B社の社員の同じ質問にヒットして、A社の情報がB社に返る
- 権限をまたぐヒット：人事部長が「今期の昇給テーブルは？」と聞いた回答（RAGで人事資料を参照）が、一般社員の同じ質問にヒットする。RAG側でアクセス制御していても、キャッシュがRAGより手前にあるとアクセス制御がまるごと迂回される
- 個人コンテキストの混入：「私の残り有給は？」への回答（特定個人の数値を含む）が、他の社員の同じ質問に返る
データとベクトルDBをテナントごとに分離していても、その手前に全テナント共有のキャッシュが1つあれば、分離は意味を失います。
攻撃4：古い回答の固定化（ステイル回答）
攻撃ではなく運用の問題に見えますが、攻撃者に悪用されることもあります。
- 規程・価格・手順が改定されたのに、改定前の回答がキャッシュから返り続ける
- モデルやシステムプロンプトを安全なものに更新したのに、更新前の（安全性の低い）回答がキャッシュから返り続ける
- 攻撃者が汚染回答のヒットを定期的に起こし、アクセス頻度ベースの削除（LRUなど）から逃れさせる
特に2点目は見落とされがちです。ガードレールを強化しても、キャッシュを失効させなければ、古い回答は古いガードレールのまま配られ続けます。
| 攻撃 | 狙い | 典型的なシグナル | 主な防御 |
|---|---|---|---|
| キャッシュポイズニング | 汚染回答を多数に配る | 新規エントリへのヒット急増、URL・連絡先を含む回答 | 書き込み前の検証、書き込み元の制限 |
| 類似度しきい値の悪用 | 狙った質問に汚染回答を返す | 低い類似度でのヒット増加、意図不一致 | 用途別しきい値、ヒット時の意図再確認 |
| テナント・権限の越境 | 他者の情報を取得 | エントリ作成者と利用者の属性不一致 | キャッシュキーへのスコープ組み込み、テナント分離 |
| 古い回答の固定化 | 誤情報・旧ポリシーの存続 | ソース更新後もヒットが続く | TTL、イベント駆動の失効、来歴管理 |
第1の防御層：キャッシュキー設計——「何を同じ質問とみなすか」を厳密にする
キーには「質問文」以外の文脈を必ず含める
キャッシュの事故の多くは、キーが「質問文（またはその埋め込み）」だけで構成されていることから起こります。同じ質問でも、誰が・どの権限で・どの設定で聞いたかによって正しい回答は変わります。キーには少なくとも次を含めます。
| キーに含める要素 | 含めないと起こること |
|---|---|
| テナントID | テナント間漏洩 |
| 権限スコープ（ロール・部署・アクセス可能な文書集合のID） | 同一テナント内での権限越境 |
| モデルID・バージョン | モデル更新後も旧モデルの回答が返る |
| システムプロンプト・ガードレール設定のハッシュ | 安全設定の更新が反映されない |
| RAGインデックス（参照データ）のバージョン | 文書更新後も古い回答が返る |
| 言語・ロケール | 別言語向けの回答が返る |
実装上は、これらの要素を名前空間（パーティション）として扱い、その中でのみ類似度検索を行うのが基本です。イメージは次のとおりです。
名前空間 = hash(テナントID, 権限スコープID, モデルID, プロンプト設定版, RAGインデックス版, ロケール)
検索 = 名前空間の中だけで、質問の埋め込みを類似度検索
「全体で類似度検索してから、メタデータでフィルタする」方式は、フィルタの実装漏れ1つで越境が起きます。先に名前空間で絞り、その中だけを検索する方が安全です。
類似度しきい値は「用途別」に決める
しきい値を全体で1つにするのはやめましょう。誤ヒットしたときの被害の大きさで分けます。
- 一般的なFAQ・公開情報：比較的緩めでよい（誤ヒットの被害が小さい）
- 手順・操作案内（振込、設定変更、解約など）：厳しめにする。誤った手順は実害につながる
- 数値・条件・個別判断（価格、契約条件、人事・法務）：原則キャッシュしない、または完全一致のみ
しきい値を決めるときは、ヒット率だけでなく「意味の異なる質問ペア」（否定形、主語違い、対象企業違いなど）で誤ヒット率を評価してください。
ハッシュは暗号学的なものを使う
完全一致キャッシュやプレフィックスキャッシュのキーに、高速だが衝突耐性のないハッシュ関数を使っていると、意図的な衝突で他人のエントリに当てられるおそれがあります。研究報告を受けて、主要なサービング基盤でもSHA-256などへの切り替えや、ハッシュへのランダム値（ソルト）付与が進んでいます。自社実装やOSSを使う場合は、キー計算のハッシュ関数を確認しましょう。
第2の防御層：書き込み前の検証——「キャッシュしてよい回答か」を判定する
そもそもキャッシュしないものを決める
最も効果が高いのは、キャッシュ対象を絞ることです。次の回答はキャッシュから除外します。
- 個人情報・個人に固有の数値を含む回答（「私の〜」系の質問）
- ツール実行・外部API呼び出しの結果に依存する回答（在庫、残高、ステータスなど）
- 権限によって内容が変わる文書を参照した回答（スコープをキーに入れない場合）
- マルチターン会話の途中の回答（前の会話に依存するため）
- ガードレールや出力フィルタが警告・修正を行った回答
- URL、電話番号、振込先、コマンドなど、実行を促す要素を含む回答（許可リスト外のもの）
書き込みゲートを設ける
キャッシュへの書き込みは「LLMが回答を返したら自動で保存」ではなく、ゲートを通過したものだけにします。
- 出力検査：PII検出、許可リスト外のURL・連絡先の検出、プロンプトインジェクションの痕跡の検出
- 書き込み元の信頼度：新規アカウント、外部公開の窓口、異常検知でフラグが立った利用者の質問からは書き込まない
- 複数回一致の確認：同じ意味の質問に対して、異なる利用者・異なる時点で生成した回答がN回一致してから本登録する（初回は「仮登録」扱いでヒットさせない）
- 来歴（プロベナンス）の記録：誰の質問から、いつ、どのモデル・どの設定・どの参照文書で生成したかを、エントリと一緒に保存する
3の「複数回一致」は、攻撃者が「最初の1回」を取るだけではキャッシュを汚せなくなるため、ポイズニングに対して特に有効です。その代わりキャッシュが効き始めるまでに時間がかかるので、よく聞かれる質問ほど効果とのバランスが取りやすくなります。
読み出し時にも軽く再確認する
ヒットしたからといって無条件に返さず、次の確認を挟むと、類似度の悪用に強くなります。
- 意図の一致確認：元の質問と今回の質問の意図が同じか、小型モデルや分類器で確認する（否定・対象・主語の違いを検出）
- 出力フィルタの再適用：キャッシュから返す回答にも、現行の出力フィルタを通す。フィルタの更新が古いエントリにも効くようになる
小型モデルでの確認は、フルサイズのLLMを呼ぶより大幅に安価です。コスト削減効果を大きく損なわずに安全性を上げられます。
第3の防御層：テナント分離——キャッシュ層にも”境界”を引く
分離方式の選び方
| 方式 | 内容 | 安全性 | コスト効率 |
|---|---|---|---|
| テナント別のキャッシュインスタンス | 物理的・インスタンス単位で分ける | 高い | 低い（ヒット率が下がる、運用が増える） |
| 名前空間（パーティション）分離 | 同じ基盤でキー空間をテナント別に分け、検索範囲を限定 | 中〜高 | 中 |
| 共有キャッシュ＋メタデータフィルタ | 全体を検索し、結果をテナントIDで絞る | 低い（フィルタ漏れで越境） | 高い |
多くの組織では「名前空間分離」が現実的な落としどころです。規制業種や機密度の高い顧客を抱えるSaaSでは、テナント別インスタンスも検討してください。
共有してよいのは「公開情報の層」だけ
コスト効率のために全テナントで共有したい場合は、キャッシュを2階層に分けます。
- 共有層：公開ドキュメント、製品の一般的な使い方など、どのテナントに返しても問題ない回答だけ。RAGで顧客データを参照した回答は入れない
- テナント層：それ以外すべて。テナント・権限スコープで名前空間を分ける
どちらの層に書くかは、回答の内容ではなく生成時に参照したデータの出どころで機械的に決めるのが安全です。「内容を見て判断する」方式は、判定ミスがそのまま漏洩になります。
同一テナント内の権限も分ける
テナント分離だけでは、社内の権限越境（役員向け情報が一般社員に返るなど）は防げません。RAGの参照先にアクセス制御がある場合は、アクセス可能な文書集合のIDを権限スコープとしてキーに含めます。ロールが多すぎて名前空間が細かくなりすぎる場合は、権限依存の回答はキャッシュしない、と割り切るのも有効な選択です。
第4の防御層：TTLと失効——”古い正解”を毒にしない
TTLはコンテンツの種類で決める
| コンテンツ | TTLの目安 | 理由 |
|---|---|---|
| 一般的な使い方・用語説明 | 長め（数日〜数週間） | 変化が少なく、誤りの被害も小さい |
| 社内規程・手順 | 中程度＋改定時に即失効 | 改定後に古い手順が残ると実害が出る |
| 価格・在庫・ステータス | キャッシュしない、または数分 | リアルタイム性が必要 |
| セキュリティ・法務関連の回答 | 短め＋ポリシー更新時に即失効 | 古い判断が残るリスクが大きい |
上記は目安です。実際の値は、自社の更新頻度と誤回答の影響度で決めてください。
イベント駆動で失効させる
TTLだけに頼らず、次のイベントで関連エントリを失効させる仕組みを入れます。キーにバージョンを含めておけば（第1の防御層）、バージョンが変わった時点で古いエントリには自然にヒットしなくなります。
- RAGの参照文書の更新・削除
- モデルの切り替え（ModelOps編で扱ったモデル移行のタイミング）
- システムプロンプト・ガードレール設定の変更
- 権限・組織構成の変更（異動、退職、契約終了したテナント）
汚染発覚時に「一括パージ」できるようにする
第2の防御層で来歴を記録しておくと、汚染が見つかったときに「この利用者の質問から作られたエントリ」「この期間にこの文書を参照して作られたエントリ」をまとめて削除できます。来歴がないと、キャッシュ全体をクリアするしかなく、コストが一時的に跳ね上がります。
監視と検知——キャッシュを”見える化”する
キャッシュはLLMを通らないため、LLM側のログだけでは異常に気づけません。キャッシュ層にも専用の指標を持たせます。
| 指標 | 見ている異常 |
|---|---|
| 新規エントリへのヒット数の急増 | 汚染回答が拡散し始めている |
| しきい値ぎりぎりの類似度でのヒット比率 | 衝突を狙った攻撃、しきい値が緩すぎる |
| エントリ作成者と利用者の属性不一致（テナント・権限） | 越境。本来は常にゼロであるべき |
| URL・連絡先を含むエントリの数と配布回数 | フィッシング型の汚染 |
| ソース更新後もヒットし続けるエントリ | 失効漏れ |
| キャッシュ経由の回答へのユーザーの低評価・通報 | 誤回答の固定化 |
汚染が疑われたときの初動は、次の順番です（インシデント運用編の流れと合わせて運用してください）。
- 隔離：疑わしいエントリをヒット対象から外す（削除ではなく隔離し、証拠として保存）
- 影響範囲の特定：そのエントリを「いつ・誰に・何回」配ったかをログから洗い出す
- パージ：来歴をたどって、同じ書き込み元・同じ参照文書から作られたエントリを一括削除
- 利用者への通知：誤った手順やURLを受け取った可能性がある利用者に連絡する
- 再発防止：書き込みゲート、しきい値、キー設計のどこが抜けていたかを振り返る
2の「誰に配ったか」を答えられるよう、キャッシュヒット時にもエントリIDと利用者IDをログに残しておくことが重要です。
コストとのトレードオフ——「安全に効く」キャッシュにする
ここまでの対策を全部入れると、ヒット率は下がります。ただし、下がり方は一様ではありません。
- コスト削減効果の大部分は、公開情報・一般的なFAQに集中しがちです。この層は共有キャッシュでもリスクが小さく、対策を入れても効果はあまり落ちません
- 個人・権限依存の回答はもともとヒット率が低く、キャッシュから外しても失うコスト削減効果は限られます
- 読み出し時の意図確認に小型モデルを使えば、追加コストはフルサイズLLMの呼び出しよりかなり小さく抑えられます
導入前に、実際の質問ログで「どのカテゴリの質問がヒット率を稼いでいるか」を分析しましょう。多くの場合、安全に共有できる領域だけで、コスト削減効果の大半を確保できることが見えてきます。
多層防御チェックリスト
| 層 | 対策 | 主に効く攻撃 |
|---|---|---|
| キー設計 | テナントID・権限スコープをキー（名前空間）に含める | テナント・権限の越境 |
| キー設計 | モデル・プロンプト設定・RAGインデックスのバージョンをキーに含める | 古い回答の固定化 |
| キー設計 | 用途別の類似度しきい値、暗号学的ハッシュ | 類似度の悪用・衝突 |
| 書き込み | 個人・ツール依存・権限依存の回答をキャッシュしない | 越境・漏洩 |
| 書き込み | 出力検査、書き込み元の制限、複数回一致での本登録 | ポイズニング |
| 書き込み | 来歴（生成元・モデル・参照文書）の記録 | 汚染後の一括パージ |
| 読み出し | 意図一致の確認、現行の出力フィルタの再適用 | 類似度の悪用・ポイズニング |
| 分離 | 名前空間分離または専用インスタンス、共有層は公開情報のみ | テナント間漏洩 |
| 失効 | コンテンツ別TTL、イベント駆動の失効 | 古い回答の固定化 |
| 監視 | 越境ヒット（常時ゼロ）、新規エントリのヒット急増、低類似度ヒットの監視 | 全般 |
| 対応 | 隔離→影響範囲特定→一括パージ→利用者通知の手順化 | 全般 |
よくある質問（Q&A）
Q1. RAGのアクセス制御をしっかりしていれば、キャッシュ経由の漏洩は起きませんか？
起きえます。キャッシュがRAGより手前にある構成では、キャッシュにヒットした時点でRAGは呼ばれず、アクセス制御のチェックも行われません。権限スコープをキャッシュキーに含めるか、権限依存の回答をキャッシュしないようにする必要があります。
Q2. LLM側にガードレールを入れているので、キャッシュの回答も安全ではないですか？
生成時点では安全でも、キャッシュから返すときにはガードレールを通りません。ガードレールを後から強化しても、古いエントリには反映されません。読み出し時の出力フィルタ再適用と、ガードレール設定のバージョンをキーに含める対策を組み合わせてください。
Q3. クラウドのマネージドなセマンティックキャッシュ機能を使えば安全ですか？
基盤の実装品質は上がりますが、キー設計・キャッシュ対象の選定・しきい値・テナント分離の方針は、利用者側の設計に委ねられる部分が大きいです。研究では主要クラウドのセマンティックキャッシュでもポイズニングが成立しうることが報告されています。「マネージドだから安全」ではなく、本稿のチェックリストで自社の設定を確認してください。
Q4. プロンプトキャッシュ（プレフィックスキャッシュ）も同じ対策が必要ですか？
プロンプトキャッシュは回答そのものではなく計算の途中結果を保存するため、「汚染回答が配られる」リスクはセマンティックキャッシュより小さいと言えます。ただし、ハッシュ衝突やタイミングによる情報推測のリスクはあります。前者はハッシュ関数の確認、後者はタイミング攻撃対策ガイドを参照してください。
Q5. 中小企業の社内アシスタントでも、ここまでの対策が必要ですか？
すべてを一度に入れる必要はありません。最低限、次の3つから始めてください。
- 個人・権限に依存する回答をキャッシュしない
- モデル・システムプロンプト・参照文書の更新時にキャッシュを失効させる
- URL・振込先・連絡先を含む回答はキャッシュしない
この3つだけでも、被害が大きい事故の多くを防げます。
まとめ——キャッシュは「過去の誰かの回答」を配る仕組みだと認識する
セマンティックキャッシュは、コスト削減とレイテンシ改善に大きく効く一方で、過去のある時点・ある利用者・ある権限で作られた回答を、条件の違う別の利用者に配る仕組みでもあります。この性質が、汚染の拡散、類似度の悪用、テナント越境、古い回答の固定化という4つのリスクを生みます。
守り方は、次の4層です。
- キー設計：「何を同じ質問とみなすか」に、テナント・権限・バージョンを含める
- 書き込み前の検証：キャッシュしてよい回答だけを、検証してから保存する
- テナント分離：データとベクトルDBだけでなく、キャッシュ層にも境界を引く
- TTLと失効：古い正解を毒にしない
「コスト最適化の層は、攻撃面でもある」——ルーティング層に続き、キャッシュ層もこの前提で設計することが、安く・速く・安全にAIを運用するための基本姿勢です。
関連記事
- 【2026年版】AIエージェントの「モデルカスケード／LLMルーティング層」セキュリティ設計ガイド——コスト層のもう1つの攻撃面
- AIエージェントの「タイミング攻撃・サイドチャネル攻撃」対策ガイド【2026年版】——キャッシュヒットの時間差から情報を読む攻撃
- AIエージェントの「メモリ汚染」攻撃対策ガイド【2026年版】——個々のエージェントの長期記憶を狙う攻撃
- AIエージェントの「マルチテナント分離」設計ガイド【2026年版】——データとベクトルDBの分離
- 【AgentOps④・コスト】「動くが、高すぎて続かない」を越える——セマンティックキャッシュ導入の考え方
参考リンク
- OWASP Top 10 for LLM Applications（2025年版）
- NDSS 2026「When Cache Poisoning Meets LLM Systems: Semantic Cache Poisoning and Its Countermeasures」
- NDSS 2026「Cache Me, Catch You: Cache Related Security Threats in LLM Serving Frameworks」（PDF）
- arXiv「From Similarity to Vulnerability: Key Collision Attack on LLM Semantic Caching」（ICML 2026）
コメント