multimodal media 結果の再利用のUUID衝突・組織の利用環境隔離

revision_id: EA-758-RESEARCH-20261027-R1 evidence_as_of: 2026-10-27 JST status: RESEARCH_COMPLETE / INDEPENDENT_REVIEW_PENDING

画像、音声、動画などの前処理結果を再利用するキャッシュでは、メディアを識別するキーが、処理の正確さと情報境界に影響します。UUIDという名前の識別子でも、それだけで所有者の認証やアクセス制御にはなりません。同じキーが別の内容を指す、別tenantの要求が同じキー空間に入る、内容を更新しても以前のキーを使い続ける、といった場合に、要求したメディアと実際に使われるキャッシュが食い違う可能性があります。

本稿はvLLMの現行公式資料を具体例に、偶発的な重複、予測可能な識別子、内容とキーの不一致、共有プロセスの限界を区別します。本文の運用設計は提案です。すべての推論エンジンに同じキャッシュ実装があることや、特定配備で情報流出が起きたことを主張するものではありません。

vLLMのSecurity資料[S1]は、指定されたmedia UUIDを内容のハッシュに代わるキャッシュ識別子として使い、共有サーバーで異なるメディアに同じUUIDを与えると、先行要求のキャッシュが使われるリスクを説明しています。対象はprocessor、encoder output、prefixの各キャッシュに関係します。これは「ランダムな値が偶然一致する確率」だけの問題ではありません。

同資料は、cache_saltによるprefix block共有の分離を追加防御として説明する一方、同一サーバープロセスを共有するtenant間の完全な隔離は提供しないと明記しています。saltだけで全種類のmedia cacheがtenant別になったと断言できません。強い分離が必要な場合の専用インスタンスと、認証したtenantごとに識別子を管理するgatewayが示されています。

Multimodal Inputs資料[S2]では、キャッシュヒットを期待してメディア本体を省略する用法と、対応するキャッシュがなければ要求が失敗する条件が説明されています。したがって識別子だけを送る処理には、権限と有効性の確認、miss時の回復手順が必要です。以下は、この確認事実から導く実装・運用上の整理です。

設計上は、メディアの論理ID、内容の版、所有tenant、利用を許可された主体、推論基盤へ渡すキャッシュキーを分けます。表示用ファイル名やURLをそのまま共有キャッシュのキーにすると、同名ファイル、上書きされたURL、一時署名の変化などが、意図しない再利用や無駄な再処理につながり得ます。どの条件で同じ内容と扱うかを明示する必要があります。

gatewayが認証済みtenantと内容の版を基に内部識別子を発行し、外部から受け取ったUUIDをそのまま全体のキー空間へ通さない構成が考えられます。これは提案するアプリケーション側の管理であり、vLLMが自動的に所有権を管理するという意味ではありません。クライアントの自己申告tenantではなく、認証結果と資産の権限から対応を決めます。

高い予測困難性は識別子の推測を難しくしますが、取得した識別子を他人が使えないことまで保証しません。URL、ログ、エラー、共有チャットなどから値が伝わる場合もあります。識別子の発行だけでなく、再利用時の所有権・許可範囲の確認を、エンジンの手前で行う必要があります。

同じ論理ファイルでも内容が変われば、旧キャッシュの再利用が不適切になることがあります。内容を更新した場合に内部キーを変える、キーと内容の対応を不変にするなど、更新規則を定めます。再試行でも同じキーを維持するのは、対象内容と権限が変わっていないことを確認できる場合に限ります。

前処理器、画像解像度、動画フレーム選択、音声変換、モデルやencoderの版などが変わる場合も、再利用してよいかの確認が必要です。どの条件をエンジン自身がキーへ含めるかは対象版の実装次第です。含まれると推測して省略せず、キャッシュ互換性の契約として確認します。未確認なら新しい処理系へ旧キャッシュを流用しない方針を選べます。

複数段のキャッシュがある場合は、gatewayの対応表、media processor、encoder、KV/prefix、外部キャッシュを別々に棚卸しします。ある段を消去したことが他段の消去まで意味するとは限りません。保存先、共有範囲、失効方法、容量、観測できるhit/missを段ごとに記録します。

隔離の選択は、同じプロセスを共有するtenantが互いに信頼できるか、扱う情報、侵害時の影響範囲で決めます。識別子の名前空間とsaltは特定の再利用を制御する補助になりますが、プロセス、メモリー、管理権限、ログまで独立させるものではありません。強い機密性が必要なら、配備単位と運用権限を含めて分離します。

共有を減らすとキャッシュ効率が下がり、前処理やprefillが増える場合があります。その費用を避けるために全tenant共通の識別子へ戻せば、前提とした情報境界も変わります。性能評価には分離を適用した状態を使い、隔離を外したベンチマーク値を本番の性能保証にしません。

saltの管理でも、共有を許す範囲と秘密の配布範囲をそろえます。tenant名のような公開識別子を秘密の代替にせず、通常ログへ値を出さないようにします。saltを交換すると旧キャッシュを共有しなくなることがありますが、それだけで全データの削除や全段の失効が完了したとは判定しません。

メディア本体を省略する要求は、キャッシュの存在を前提にします。eviction、再起動、別replicaへのrouting、内容更新、権限変更があれば、その前提が崩れることがあります。miss時は、権限を再確認したうえで正しい内容を再送する、利用者へ再取得を求める、処理を停止するなど、業務に合う回復を選びます。

missを成功扱いして別のメディアへ置き換えたり、拒否を避けるため共有名前空間で再試行したりしません。処理結果がどの内容の版に由来するかを追跡できるようにし、キャッシュの都合で参照先が変わった場合に検知できる記録を残します。入力識別子と出力本文が結び付かない場合、回答内容だけから取り違えを見つけるのは困難です。

削除やアクセス権取消しでは、元のストレージだけでなく、対応表と各キャッシュへの影響を確認します。提供機能で即時削除を保証できない場合は、当該キーでの利用を手前で拒否するなど、失効後の再利用を防ぐ経路を持ちます。実装していない削除伝播時間を約束しません。

以下は許可された隔離環境で、模擬tenantと非機密メディアを使う防御確認の提案です。本RUNで実行した結果ではありません。

試験では出力の見た目だけでなく、入力の内容版、実効tenant、cache段、hit/miss、routing先を照合します。監視のためにメディア本体やsaltを共有ログへ出す必要はありません。安全な内部識別子と、制限された監査用の対応表を使い分けます。

• 対象配備のvLLM release/commit、モデル、全cache層、gatewayの認可、削除伝播、tenantの信頼関係は未確認です。確認したlatest資料の機能が既存配備にもあるとは断定しません。
• UUID重複、cross-tenant隔離、salt、eviction、失効、再起動、内容更新の実動試験はすべてNOT_RUNです。現実の漏えい事例を再現したとは記述しません。
• SAFE_WORDINGは「media識別子の一意性と所有権を管理し、cache層と配備構成ごとに再利用の境界を検証する」です。「UUIDv4だけで認可済み」「cache_saltだけで全tenantを隔離」「ハッシュ既定値ならtenant分離済み」とは表現しません。

[S1] vLLM, Security, https://docs.vllm.ai/en/latest/usage/security/ 。2026-10-27 JST確認。Multi-Tenant Deployments、Prefix Cache Timing Side-Channel Mitigation、Multimodal Media UUID Security。UUIDの挙動、saltの適用範囲、共有プロセスの限界の根拠です。

[S2] vLLM, Multimodal Inputs, https://docs.vllm.ai/en/latest/features/multimodal_inputs/ 。同日確認。UUIDを用いた再利用・入力省略とmiss時の条件の根拠です。オンライン例にURLをUUIDへ使う記述があっても、本稿のmulti-tenant設計ではSecurity資料の要件を優先して評価します。

統合台帳EA_MASTER!759の正規topicを維持しました。原案Google Doc 1_9XrDkXlopnx39HlRa1YDO8yRvOEBXup2vvY6senU7s、EA-758見出しt.0:249511には、基礎調査済みとの申告と未検証のSecurity URLが残っていました。今回その一次資料と追加資料を取得し、正式改訂がないことを改訂キー範囲で確認して本文を作成しました。先行するSOURCE_EA_RELATION接続行は確認できず、未確認の他engine比較やtenant試験は完成事実に含めていません。