Axonius、Bedrock AgentCoreで安全なマルチテナントAIエージェント

発表の背景

Axoniusは、Amazon Bedrock AgentCoreを使ったマルチテナントAIエージェントの設計を、AWSブログで公開した。Axoniusは資産管理プラットフォームを提供する企業で、1,400以上のシステムからデータを統合し、セキュリティ・ITチームの手動作業を最大50%削減するとされる。同社のSaaS基盤はAWS上にあり、数百の顧客環境を分離して運用している。

今回のAIエージェントは、企業環境の状態を解釈してギャップやリスクを特定する。AIが数百万のデータポイントを分析することで、ジュニアアナリストでも高度な分析を行えるようになるのが目標だ。

マルチテナントの3パターン

SaaSプロバイダーがAIエージェントを導入する際のアーキテクチャには、サイロ・プール・ブリッジの3つのパターンがある。サイロはテナントごとに専用リソースを用意し、プールは共有リソースを複数テナントで使う。ブリッジは一部をサイロ、他をプールにするハイブリッドだ。

AgentCoreのランタイムでは、プールモデルでもセッションごとに一意のセッションIDを割り当ててユーザーセッションを分離できる。ブリッジモデルでは、専用エージェントを共有のBedrock Knowledge Basesに接続するといった構成も可能だ。

Axoniusが選んだ構成

Axoniusは既存のSaaS運用がサイロモデルだったため、AIエージェントでも同じ方針を継続した。顧客ごとに専用のAgentCoreランタイムを用意し、各セッションは独立したマイクロVM上で実行される。アクセス制御はIAMのリソースベースポリシーのみで行い、シンプルな認可モデルを実現している。

主な構成要素は、AgentCoreランタイム、Amazon ECRに保存するテナント別コンテナイメージ、Amazon Bedrockの基盤モデル、Amazon Bedrock Knowledge Bases、Amazon Bedrock Guardrails、Amazon CloudWatchである。Knowledge BasesではS3ベクターを使用し、メタデータフィルタリングでテナント固有のデータを分離する。Guardrailsはコンテンツフィルタリングとトピック拒否ポリシーを提供し、CloudWatchはトークン消費量の監視とアラートに使われる。

代替案との比較

Axoniusが検討した他の選択肢として、共有ランタイムでJWTを使うプールモデルと、共有ランタイムにゲートウェイを組み合わせるブリッジモデルがある。プールモデルは運用するランタイムが1つで済み、新規顧客のオンボーディングが迅速だが、分離がアプリケーションコードに依存する。ブリッジモデルはCedarポリシーとLambdaインターセプターを使ってインフラ層で分離を強制できるが、設定の複雑さが増す。

サイロモデルは分離性が最も高い一方、AWSアカウントあたりのエージェント数が既定で1,000という上限がある。大規模な顧客基盤では上限の引き上げや容量計画が必要になる。また、テナントごとのプロビジョニング遅延や、運用・監視のオーバーヘッドも課題として挙げられる。

現時点での注意点

なお、このブログにはAxoniusの採用構成の概要は示されているが、具体的なコードやパフォーマンス数値は含まれていない。実際の本番適用には、CloudFormationやCDKによる自動化、CloudWatchを使った監視設定などが別途必要になる。

また、既存の認証・認可モジュールとの統合方法についても、概念的な説明に留まっている。日本企業が同様のサイロパターンを導入する際は、自社のアカウント構造やネットワーク要件に合わせた追加設計が求められるだろう。