複数の企業が同じAI基盤を共有するマルチテナント環境で、自社のデータが他社に漏れるリスクをどう防ぐか。この難題に対し、ソフトウェア企業PARはアマゾン ウェブ サービスの基盤上で「暗号署名」「意味検証」「SQL分割」の3層を組み合わせた防御構造を構築、大規模言語モデル自体が侵害されてもデータ隔離を維持する実装を公開した。

三層の独立した防御、それぞれの役割

PARが実装したのは、互いに独立して機能する三層の防御機構だ。第一層はAWS SigV4によるリクエストの暗号署名で、テナントのなりすましや改ざんを検知する。第二層はAmazon Bedrock上の意味検証で、リクエスト内容がテナントの権限範囲を逸脱していないか自然言語のレベルで確認する。第三層はSplit-Plane SQLによるプログラム的なデータ分離で、データベースレベルでテナント間の境界を物理的に維持する。各層は単独でも一定の防御力を発揮する設計で、一層が破られても他の層でカバーできる多層防御の考え方が取られている。LLM自体がプロンプト操作などで侵害されたシナリオを想定し、AIに依存しない防御層を組み合わせている点が特徴的だ。

なぜLLMに特化した防御が必要なのか

従来のSaaSアプリケーションでは、アクセス制御はコードで明示的に記述できた。しかしLLMを組み込んだシステムでは、自然言語の指示でデータベースにアクセスする経路が生まれ、従来のコードベースの制御だけでは不十分になる。悪意あるプロンプト注入や、モデルのハルシネーションによって、本来アクセスできないテナントのデータが引き出されるリスクが現実のものとなっている。PARの事例は、AIの柔軟性を維持しながら、テナント境界を侵害されない構造的対策を示している。これは、金融や医療など厳格なデータ分離が求められる業界がLLMを本格導入する際の参照モデルとなり得る。

SaaS事業者が迫られるデータ隔離の再設計

この事例が示唆するのは、マルチテナントSaaS事業者にとってLLMの導入がセキュリティ設計の全面的な見直しを迫るという現実だ。単一のLLMエンドポイントを全テナントで共有すると、プロンプトの工夫だけではデータ分離を保証できない。PARの三層構造は、クラウド基盤のサービスを組み合わせて対応できることを示したが、同時にLLMを組み込むシステムにはAIの外側での防御設計が不可避であることも浮き彫りにしている。今後、エンタープライズ向けSaaSの競争軸は、単にLLMを搭載するかどうかではなく、いかに安全なマルチテナント環境を提供できるかに移っていく可能性がある。

クラウド各社のAIセキュリティ戦略に波及

PARの実装はAWSのSigV4やBedrockといった固有サービスに依存しているが、この三層防御の概念自体は各クラウドベンダーに波及する可能性を持つ。マイクロソフトのAzureやグーグルのGoogle Cloudも、マルチテナントAI環境でのデータ漏洩防止策を強化しており、暗号鍵管理やポリシー評価エンジンとAIサービスの統合競争が加速している。LLMがエンタープライズ領域に浸透するにつれ、AI自体の性能だけでなく、その周辺のセキュリティ基盤がクラウドベンダー間の差別化要素となりつつある。PARの事例は、こうした競争の中で実運用に耐える具体的な設計パターンが現れ始めたことを示している。