30秒サマリー
- 飲食業向けSaaS企業PARが、LLMを使った自然言語SQL分析基盤で300社超のテナント間データ漏洩を防ぐ3層アーキテクチャを公開
- LLM自体は非決定論的なため、プロンプト指示だけではデータ境界の保証にならないと明言
- AWS SigV4署名・Bedrockによる意味検証・Split-Plane SQLの各レイヤーが独立して機能し、LLM侵害時でも行レベルセキュリティを維持
何が起きたか
PAR Technology Corporationは300社超の飲食業テナントを抱えるSaaS企業で、ビジネスユーザーが自然言語で業績データを照会できるテキスト→SQL分析エージェントをAWS上で本番運用している。同社はAWS Machine Learning Blogにおいて、マルチテナント環境でのデータ隔離を実現した3層セキュリティアーキテクチャを詳述した。
システムが直面した根本的な課題は「同じ質問でもユーザーによって返すべき数値が全く異なる」点にある。例として、同一DBに対して「先週の総売上は？」と問い合わせた場合、2店舗を持つフランチャイズオーナーには8万4000ドル、全国200店を管轄するブランドマネージャーには920万ドルが正解となる。テナント間で誤ったデータが返ることは、データガバナンス違反であるだけでなく事業上の機密漏洩にもつながる。
同社が採用した3層アーキテクチャは以下の構成となっている。第1層はAPIエントリポイントでのAWS SigV4による暗号署名を用いたリクエスト認証。第2層はAmazon Bedrock上の推論エンジンが、データアクセス前に質問の意味的妥当性を検証するセマンティックバリデーション。第3層はSQL生成フェーズでのSplit-Plane SQL方式によるプログラム的データ隔離で、DBレイヤーで行レベルセキュリティを強制する。各レイヤーは独立して動作し、仮に他のレイヤーが突破されても第3層が単独でデータ境界を守る設計となっている。
インフラ面では、DatabricksデータウェアハウスはTLS 1.3通信と保存データ暗号化を採用し、暗号鍵はAWS KMSで自動ローテーション管理される。AWS IAMの一時的認証情報のみを使用し、長期アクセスキーは一切利用しない。すべてのデータアクセス操作は監査ログとして記録される。LLMの推論エンジンにはAnthropicのClaude Sonnet 4（モデルID: anthropic.claude-sonnet-4-20250514-v1:0）が使われているとブログ中で明記されている。
原典ハイライト
原文でPARは「LLMは1万回連続して正しくフィルタを適用しても、1万1回目に無言でそれを省略する可能性がある。マルチテナント分析システムにおいて非決定性はセキュリティ境界として不十分だ」と明確に述べており、プロンプト指示によるデータ制御の限界を設計思想の核心に置いている。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
LLMを業務データ基盤に組み込む際、「プロンプトで制御できる」という前提はセキュリティ設計として成立しないことが、実運用事例として明示された。LLMはアーキテクチャの内側に閉じ込め、データ境界の保証は決定論的なインフラ層で行うという設計原則が、コンプライアンス上の要件を満たす唯一の現実解として浮かび上がる。
日本企業への示唆
複数部門・グループ企業・パートナー企業が同一のLLM分析基盤を共有するSaaS型・社内基盤型システムを検討する日本企業にとって、このアーキテクチャは具体的な設計指針となる。特に注意すべきは3点。①LLMへのプロンプト注入だけではデータアクセス制御の根拠にならない（監査・コンプライアンス対応で問われる）。②SQL生成レイヤーでのプログラム的フィルタリングを必須要件として設計段階から組み込む必要がある。③AWS IAMの一時認証・KMS・CloudWatchの組み合わせはAWS環境での標準的実装として参照可能なため、自社環境の設計レビューに活用できる。
背景・経緯
PAR Technology Corporationは飲食業向けに300社超の顧客を持つSaaS企業。最初のバージョンはBedrockとDatabricksをシンプルに接続したPoC的構成だったが、実顧客データを扱う本番運用に向けてゼロトラスト要件を満たすため、アーキテクチャを抜本的に再設計した経緯が原文に記されている。
