結果の再利用 Isolation／Cross-user Leakage対策

AIのキャッシュ分離は、一度生成・検索した結果を再利用するとき、別の利用者や権限範囲へ内容が漏れないようにする設計である。同じ質問であっても、利用できる文書、会話履歴、テナント、利用目的が違えば、再利用してよい回答も違う。「意味が近い」「同じモデルを使う」という条件は、情報を共有してよい根拠にはならない。

LLMの回答キャッシュだけでなく、検索結果、ツール結果、会話要約、アプリのメモリ、CDN、ブラウザ、実行中の同時要求をまとめる仕組みも調べる必要がある。一層だけで利用者別キーを実装しても、前後の共有層が同じ結果を返せば分離は崩れる。

キャッシュ名が同じでも、保存内容、区画、失効方法、提供者の保証は違う。入力トークンの処理を省く仕組みを、アプリが保存する回答の共有許可と同一視しない。どの層が何の内容を保持するかを一覧化する。

公開FAQのように全員へ同じ情報を返す用途は、共有キャッシュが適する場合がある。一方、顧客契約、人事、個人の作業状態に基づく回答は、利用者または認可範囲を分ける必要がある。同じテナントの中でも閲覧権限が異なるため、tenant_idだけで十分とは限らない。

キーや区画の候補には、認証由来のテナント・主体、権限またはポリシーの版、参照データの版、モデル・プロンプト版、検索・ツール設定、会話の必要部分がある。ただし全情報を平文でキーに含めれば、キーやログ自体から機密情報が漏れる。秘匿識別子の設計、正規化、区切り、衝突、長さ、バージョンを管理する。ハッシュ化は表現の工夫であり、取得者への認可の代わりではない。

共通グループの回答を共有する場合、そのグループが同じ名前を持つだけでなく、同じ閲覧可能範囲を持つことを確認する。権限が動的なら、ヒット時に参照文書の現在の認可を再検査するか、認可変更で区画を失効させる設計が必要になる。許可リストが取得できないとき、古い回答をそのまま返すかは業務要件に照らして明示的に決める。機密用途では検査不能時に再利用しない構成を検討する。

意味的キャッシュでは、質問にユーザーIDを付け足して埋め込むだけでは、別ユーザーの質問が十分遠くなる保証がない。vLLM Semantic RouterのIssue #2134は、ユーザーごとの接頭辞を使う構成でも別利用者の回答が返ったとする再現報告である。[S1] 検証すべきなのは識別文字列が違うことだけでなく、実際のキャッシュ検索が別区画の候補を排除することである。

対応PR #2135は2026-06-16にマージされ、インメモリバックエンドで類似度とは別の厳密なscope gateを設ける変更を示している。PRは他バックエンドへの追随と、候補の事後除外によるヒット率の限界を別に記述する。[S2] この修正が存在することから、未確認の配備版や全バックエンドの修正済みを推定しない。実使用コミット、バックエンド、設定を照合する。

Azure API Managementの意味的キャッシュ資料も、類似回答が不適切・古い・安全でない場合があると注意し、vary-byでキャッシュを区分する仕組みを示す。[S3] ただしどの値で区分するかは実装側の責任である。本文のuserフィールドや任意ヘッダーではなく、認証と認可に結び付いた値を使い、lookupとstoreで同じ範囲を適用する。類似度閾値を厳しくすることと、アクセス範囲を強制することは別の対策である。

利用者Aの質問「今月の契約額は」がAの文書に基づいて回答され、その結果が質問文だけで保存されたとする。Bが同じ質問をしたとき、モデルを呼ばずAの回答が返れば、検索の認可は実行されない。対策はキャッシュを認可済みの区画へ保存し、ヒット経路にも同じ境界を適用すること。検索APIの権限テストだけでは検出できない。

別の経路として、AとBの同時質問を一つの実行へまとめるsingle-flight処理がある。永続キャッシュを利用者別にしても、進行中要求のキーが質問文だけなら、BがAの実行結果を受け取る可能性がある。永続化されない共有状態も含めて区画を揃える。

管理者が権限を削除した後も、TTLが残っている間は以前の回答が表示される場合がある。TTLは保持時間の上限を補助するものであり、即時失効を意味しない。データ・権限・プロンプトの変更イベントから失効対象を引ける仕組み、または版の変更で古い区画を使わない仕組みを設ける。旧データをバックアップから復元した後にも失効条件を適用する。

不正な利用者が共有キャッシュへ任意の回答を保存できれば、情報漏えいに加えて、他者の回答を汚染する問題になる。登録経路の認証、区画を変更する権限、値の形式、書込み元の来歴を管理する。信頼できない保存値を、そのまま実行可能なオブジェクトへ復元する設計も避ける。

可観測性では、利用者別のヒット・ミス、拒否、不一致、失効遅延、対象版を記録する。ただし問題調査のためにキャッシュの機密全文を広いログへ転記しない。保存・閲覧の監査と、回答内容そのものの保持を分ける。漏えいが疑われる場合は、該当区画または機能の再利用を停止し、影響対象を識別して失効・権限修正・再検証を行う。

模擬データを用意し、Aの回答を保存した後、Bから同じ質問、言い換え、長い質問を送って漏えいしないことを確認する。テナント切替、組織内の権限差、ID欠落、失効、削除、並行実行、外部キャッシュ障害、復旧後を含める。埋め込みが同一でも別区画を返さない試験は、類似度に依存しない境界の確認に有効である。

厳密な区画を付けると、共有ANN索引の上位候補が他区画に偏り、正当な回答もヒットしなくなる場合がある。ヒット率を戻すために区画検査を外さず、検索対象の分割や候補探索方法を調整する。測定は、情報の越境がないことと、同じ区画で十分再利用できることを別指標にする。

• 実使用のキャッシュ層、バックエンド、キー、認証由来scope、失効方式、提供者の推論キャッシュ仕様は未取得。
• クロスユーザー、同時要求、権限失効、削除伝播、汚染、障害復旧、実ヒット率の試験はNOT_RUN。
• Issue／PRは当時の再現と限定された修正の証拠。対象配備の影響有無・修正版・全バックエンドの現在状態は未判定。

「再利用を許す範囲を明示し、類似度とは独立した認可区画と失効制御を、保存・検索・同時要求の全経路で強制する」。一方、「IDをプロンプトへ混ぜれば分離済み」「類似度を上げれば漏えいしない」「TTLがあるので権限失効も即時」「修正PRがマージ済みだから全配備が安全」とはしない。

確認日: 2026-10-20。工程・制御・試験の組合せは本稿の設計提案。

• [S1] vLLM Semantic Router Issue #2134: https://github.com/vllm-project/semantic-router/issues/2134 （ユーザーscopeの再現報告。EA-281で扱う全体分離の具体例）
• [S2] vLLM Semantic Router PR #2135: https://github.com/vllm-project/semantic-router/pull/2135 （インメモリ修正、マージ日、バックエンドとヒット率の限界）
• [S3] Microsoft llm-semantic-cache-lookup policy: https://learn.microsoft.com/en-us/azure/api-management/llm-semantic-cache-lookup-policy （類似検索とvary-by区分。現行の実配備設定を別途確認）
• 歴史的所在記録: https://docs.google.com/document/d/1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84/edit 、tab=t.0:21984–23383、特に22423–22490。完成先行本文は確認できず、所在確認記録を保持した新候補である。