組織の利用環境 Isolation for Multi-tenant AI

マルチテナントAIのテナント分離は、同じサービスを使う組織どうしが、互いの文書、会話、メモリ、秘密情報、ツール操作へ許可なく到達しないようにする設計である。同時に、一方の大量利用で他方の応答や費用管理が破綻しないようにする資源分離も含む。モデルへ「他社の情報を出さない」と指示するだけでは、データ取得や操作権限の境界にならない。

テナントIDは検索タグにすぎない場合と、認証・認可と結び付いた境界である場合がある。入力文やクライアントの任意パラメータから得たIDをそのまま信用すると、別テナントのIDへ差し替えて検索できる。信頼できる認証情報と所属関係からサーバー側で対象テナントを確定し、検索、保存、非同期処理、ツール実行へ一貫して渡す必要がある。

Azure AI Searchの一次資料も、テナント別のインデックス、テナント別サービス、および混在方式を示している。[S1] ただし索引名を分けるだけでは、全索引を読める資格情報を持つアプリの誤配線を防げない。基盤上の分割と、実行主体に許す操作を合わせて設計する。

入口で認証しても、バックグラウンドジョブへテナントIDを渡さず、ワーカーの既定値で保存すれば、情報は混ざる。ジョブ、再試行、チェックポイント、オブジェクトキー、検索条件、ログへ、認証由来のテナントと処理IDを関連付ける。テナント情報が欠けたときに全体検索へ退避する設計は避け、処理を拒否する。

会話ID、ファイルID、メモリIDは、推測しにくいだけでは認可にならない。取得や更新のたびに、対象の所属と要求者の権限を照合する。利用者が複数テナントに所属する場合、ログイン主体と今回選択した組織を分けて扱い、切替時に会話・検索・キャッシュの文脈を持ち越さない。

共有エージェントIDが全社のツールへアクセスできる構成では、エージェント内部で選択ミスが起きると影響が広がる。MicrosoftのマルチテナントAgentic Systems資料は、共有ID、テナント単位ID、専用配備、委任認可などの選択肢と運用上の差を示す。[S2] 本稿では、その境界に沿ってツールゲートウェイがテナント・対象資源・操作・実行主体を検証することを提案する。LLMが生成したテナント名や操作引数は認可根拠にしない。

RAGでは、原文をテナント別に保存しても、チャンク、埋め込み、要約、再ランキング入力、評価集合が共有されることがある。検索結果だけでなく、モデルへ送る全コンテキストと、その前段のデバッグ出力も対象になる。キャッシュには、テナント、権限範囲、参照データの版を含む明確な区画を持たせる。類似文だからという理由で別区画の回答を返さない。

この点は抽象的な懸念だけではない。vLLM Semantic RouterのIssue #2134では、ユーザーごとの文字列を埋め込み入力へ追加しても、類似度による検索が別利用者の回答へ当たるという再現報告がある。[S3] これは報告された当時の構成の証拠であり、全版・全バックエンドが現在も同じ欠陥を持つという意味ではない。得るべき教訓は、識別子を文章に混ぜることと、候補を厳密に区分することが異なる点である。

共有モデルや検索サービスでは、利用者Aの長い入力や大量再試行で、Bの待ち時間が増えることがある。テナント別に同時実行、待ち行列、トークン・ツール回数、時間、費用の予算を設ける。上限到達時に無限再試行せず、拒否、保留、機能縮退を業務要件に応じて選ぶ。サービス全体の上限だけでは、誰が容量を消費したかを制御できない。

運用者の管理画面、ログ検索、サポート用の代理アクセスも分離境界である。通常利用者のAPIを分離していても、共有トレースへ全文を出力し、全担当者が読めるなら情報管理は成立しない。管理アクセスの目的、承認、期限、対象テナント、操作記録を定める。テナント削除時には文書以外のメモリやキャッシュ、非同期ジョブにも処理を伝播する。

同じ文面と同じローカルIDを持つ模擬データをA・Bに作り、両方向に検索、直接ID取得、添付参照、履歴再開、ツール実行、キャッシュヒット、ログ閲覧を試す。Aのアクセスが成功することに加えて、BからAが拒否されること、テナント情報欠落が拒否されることを確認する。管理者やバックグラウンド主体でも別に試験する。

権限を途中で失効させ、進行中のジョブとキャッシュ応答がどうなるかを確認する。ジョブ開始時の認可だけで長時間の全操作を許すか、操作直前にも再認可するかは、失効を反映すべき期限と副作用に応じて決める。テナント移行時は、新旧保存先の参照とコピー完了を検証し、接続先を切り替えたことだけで完了扱いにしない。

専用配備は誤った共有アプリ、運用者権限、外部サービスの設定まで自動で解決しない。一方、すべてを物理的に専用化すると費用や変更管理が過大になり、未修正の配備が増える場合もある。分離強度は契約、データ区分、障害影響、運用能力から選び、選択した境界を実際に検証する。

またテナント分離と、同じ組織内の利用者ごとの文書権限は別である。テナントAに属することだけで、Aの人事情報や経営資料を全員へ見せてよいわけではない。組織内の行・列・文書認可を追加し、回答、要約、ダウンロードにも引き継ぐ必要がある。

• 対象環境の認証、検索サービス、モデル契約、ツールID、資源予算、管理者運用は未取得。
• A/B相互拒否、ジョブ再開、失効、キャッシュ、削除、移行、負荷分離の実試験はNOT_RUN。
• 先行Luna完成本文は確認できず、旧記録は所在調査として保持する。既存製品が導入済みとは主張しない。

「認証由来のテナント文脈を全データ・操作経路へ渡し、保存先と実行主体の認可を強制して分離する」。一方、「テナントIDをプロンプトに書けば分離済み」「索引を分ければ全経路が安全」「専用GPUなら会話やログも分離済み」とはしない。

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

• [S1] Microsoft, Multitenancy and Content Isolation: https://learn.microsoft.com/en-us/azure/search/search-modeling-multitenant-saas-applications （索引・サービス単位の分離と運用上の差）
• [S2] Microsoft, Considerations for Multitenant Agentic Systems: https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/agentic-systems （ID・認可・テナント文脈）
• [S3] vLLM Semantic Router, Issue #2134: https://github.com/vllm-project/semantic-router/issues/2134 （2026-06の再現報告。現行全版への一般化はしない。キャッシュ固有の対策はEA-283も参照）
• 歴史的所在記録: https://docs.google.com/document/d/1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84/edit 、tab=t.0:21984–23383、特に22423–22490。完成本文を確認できなかったという記録であり、不存在の証明ではない。