AIエージェントをマルチテナントSaaSに組み込む場合、通常のWebアプリケーションとは質的に異なるデータ越境リスクが生じる。LLMが別テナントのデータを推論チェーンに取り込むと、そのデータはツール呼び出しや生成出力を通じて外部に流出する可能性がある。テナント境界の崩壊はデータ漏洩にとどまらず、エージェントの行動増幅によって被害範囲が拡大するため、設計段階からの構造的分離が必須となる。
なぜAIエージェントはマルチテナント分離が難しいのか
テナント境界は「プロンプトではなくプログラム側で強制する」原則が、AIエージェント分離設計の出発点です。
通常のSaaSアプリケーションでは、APIリクエストにテナントIDを付与しORM層でフィルタリングする設計が標準的だ。しかしAIエージェントは三つの面でこの前提を崩す。
RAGの検索段階: ベクトル類似度検索はテナント境界を無視する。あるテナントのクエリが別テナントの埋め込みベクトルと意味的に近い場合、フィルタなしでは自然に越境が起きる。研究では「4テナント共有コーパスで、悪意のない通常クエリの95%が他テナントデータを取得した」という結果も報告されている。
ツール呼び出しの委譲: AIが生成したツール引数にテナントIDを埋め込む設計では、プロンプトインジェクション等で他テナントのIDが引数に混入する可能性がある。ツール実行はDB書き込み・外部API呼び出しなど副作用を伴うため、越境が発生した場合の影響範囲が従来のSaaSより大きい。
可観測性ログへの混入: エージェントのトレースログには中間推論ステップ・取得文書チャンク・ツール呼び出しパラメータが記録される。これを共有ログ基盤に集約すると、可観測性パイプライン自体がデータ漏洩経路になる。
4つの分離レイヤーと設計パターン
エージェント分離は、データ層・実行環境・ID管理・可観測性の4層を揃えて初めて機能します。
データ層：Pool / Bridge / Silo
データストア分離には3パターンがある。
| パターン | 内容 | 適用場面 |
|---|---|---|
| Pool | 共有テーブル＋行レベルセキュリティ（RLS） | コスト優先のSMB・スタートアップ |
| Bridge | テナントごとに別スキーマ（同一インスタンス） | 中間的な境界強度が必要な場合 |
| Silo | テナントごとに専用インスタンス | 規制対象データ・医療・金融 |
AIエージェントがSQLを生成する場合、Pool（RLS）が最もリスクが高い。RLSポリシーは開発者が明示的に有効化したうえで、LLMが生成するすべてのクエリ経路に適用されていることをテスト環境で検証する必要がある。エンベロープ暗号化（テナントごとのKMS鍵＋Key Encryption Key）を組み合わせると、テナント退会時に鍵を破棄するだけでデータを暗号的に無効化できる。
ベクトルストアとRAGの分離
ベクトルDBのメタデータフィルタ（tenant_idフィールドへのpost-hocフィルタ）は実装ミスで無効化されやすく、構造的な分離を優先する。
- 名前空間分離（namespace per tenant）: 名前空間を指定しない検索は構造的に越境不可能になる。単一インスタンスを維持しながら境界を保てるためコスト効率が高い
- シャード分離: テナントごとに別シャードを割り当て。高スループット環境向け
- 専用インデックス（Siloモデル）: 規制対象テナントは別暗号化設定付きの専用インデックスで管理
実行環境（コンピュート層）の分離
エージェントがLLM生成コードを実行する場合（コーディングエージェント等）、そのコードは過去に監査されたことがない。通常のコンテナはホストカーネルを共有するため既知のエスケープCVEがある。
実用的な分離手段:
- gVisor: ユーザー空間カーネルがsyscallを傍受する。コンテナより強固だが互換性のトレードオフがある
- MicroVM（Firecrackerなど）: ハードウェア仮想化による分離。125ms未満で起動、5MB未満のオーバーヘッドでコーディングエージェントの実運用に適合する
実装優先度と段階的アプローチ
テナントIDをゲートウェイ・サービス・データ層の3箇所に埋め込み、LLM処理の前に確定させるのが最優先の実装です。
フェーズ1（即時実装）:
- APIゲートウェイでテナントIDをJWTクレームとして付与する。
tenant_id・user_id・roles・scopesを明示的に設定し、バックエンドサービス（LLMではなく）がテナントコンテキストを解決する - 全共有テーブルにRLSを有効化し、LLM生成クエリの経路もカバーされていることをテストで検証する
- ベクトルストアは名前空間分離で実装し、デフォルト-denyのエグレスポリシーで承認済みツールエンドポイントのみ許可する
フェーズ2（スケール時）:
- ポリシーエンジン（OPA/Rego）を導入し、分離違反をインフラ変更時にCIでブロックする
- 高リスクテナント（医療・金融等）はSiloモデルに移行し、テナントごとのKMS鍵でエンベロープ暗号化を実装する
- 可観測性パイプラインを分離する。規制対象テナントはOpenTelemetryの名前付きパイプラインで専用バックエンドにルーティングし、共有バックエンド送信前にPII削除を適用する
エージェントガバナンス体制の観点では、権限管理設計やLLMゲートウェイ設計と組み合わせて多層防御を構成することが重要だ。
規模別の留意点（SMB / エンタープライズ）
SMB向け: Poolモデル（RLS）から始め、ベクトルストアは名前空間分離で実装するのが現実的な出発点だ。コスト効率が高く、フェーズ1の実装で主要リスクをカバーできる。エンジニアリングリソースが限られる場合は、AIオペレーションサービスを通じて設計レビューと実装支援を外部委託できる。
エンタープライズ向け: 規制業種（医療・金融・士業）はSiloモデルを前提に設計し、SOC 2 Type IIのCC6系制御項目（論理アクセス・境界保護・送受信制限）のマッピングを初期設計に組み込む。RDE（Reinvention Deployed Engineering）サービスでは、マルチテナントエージェント基盤の設計から監査体制の整備まで一貫支援が可能だ。OPA／RegoとCIパイプラインを統合し、インフラ変更が分離ルールを違反しないことを機械的に保証する。
参考
- Multi-tenant isolation for AI agents: security architecture guide | Blaxel
- マルチテナントSaaSにAIエージェントを組み込むとき、テナント分離をどう設計するか | Zenn
- マルチテナント機能とコンテンツ分離 - Azure AI Search | Microsoft Learn
まとめ
マルチテナント環境でのエージェント分離は、データ層・実行環境・ID管理・可観測性の4層を揃えて初めて機能する。「プロンプトでテナントIDを渡せば分離できる」という前提が最大のリスクであり、バックエンドサービス側での構造的強制が設計の出発点となる。
ベクトルストアは名前空間分離を基本とし、規制対象テナントにはSiloモデルとKMS鍵管理を組み合わせた暗号的分離を適用する。可観測性パイプラインの分離は見落とされやすいが、ログがデータ漏洩経路になる点で軽視できない。
マルチテナントエージェント基盤の設計・運用のご相談はKuu株式会社のAIオペレーションサービスからお問い合わせください。