Axoniusは、既存のAWS展開を支える顧客ごとの分離モデルを手放すことなく、自社のサイバーセキュリティSaaSプラットフォームにAIエージェントを追加している。これは新しいAWS Machine Learning Blogのケーススタディで示されている。

同社はAmazon Bedrock AgentCoreを使い、数百の個別顧客環境向けにエージェントを実行した。この設計は、エージェント機能を追加するソフトウェアベンダーにとって中心的な課題に対処するものだ。つまり、エージェントは多数のテナントで有用でありつつ、提供先顧客のデータ、API、ID制御、運用コストに制限されなければならない。

AWSはこのアーキテクチャと報告された利点をベンダー自身の投稿で説明している。ソースにはAxoniusによる独立した性能テストや顧客コメントは含まれていないため、展開規模や運用上の成果に関する主張はAWS報告として扱うべきである。

Axoniusはサイロ型SaaSモデルを維持する

AxoniusはセキュリティおよびITチーム向けの資産インテリジェンス・プラットフォームを提供している。AWSによると、同サービスは1,400以上のシステムから情報を照合し、数百の分離された顧客環境を運用している。各顧客ワークロードは、ロードバランサー、データベース、汎用コンピュート基盤などのコンポーネントを含む専用のAmazon Virtual Private Cloud、つまりAmazon VPC内で実行される。

投稿で説明されている最初のAIエージェントは、大規模な企業環境を分析し、ギャップやリスクを特定し、複数の連携先から到着する数百万件のデータポイントを解釈する。AWSは、この機能によって新人アナリストが複雑な分析を行えるようにし、上級アナリストが何時間も手作業で調査する必要を減らすことを意図していると述べている。

Axoniusは、そのワークロードを共有SaaSアーキテクチャに移すのではなく、既存のテナントモデルにエージェントを従わせたかった。この決定が技術要件を形作った。つまり、ある顧客の環境を扱うエージェントは他の顧客のデータに到達してはならず、同時にサービスの既存の認証、デプロイ、APIパターンと統合されなければならない。

AIビルダーにとって重要なのは、ここでのマルチテナンシーは単に顧客IDをリクエストに割り当てることではないという点だ。エージェントは、セキュリティ製品に期待される境界を維持する形で、デプロイ、認可、接続、監視、課金されなければならない。

3つのデプロイパターンとそれぞれのトレードオフ

AWSは、SaaSエージェントのデプロイにおける3つの一般的なパターンとして、サイロ、プール、ブリッジを挙げて設計上の選択を整理している。

サイロ構成では、各テナントに専用リソースが割り当てられる。AgentCore Runtimeに適用すると、顧客ごとに専用エージェントを展開することを意味しうる。これは明確なインフラ境界を提供するが、プロビジョニング、更新、監視、廃止が必要なリソース数は増える。

プールモデルでは共有リソースを使う。1つのエージェントが複数のテナントにサービスを提供でき、各セッションには固有のセッションIDが割り当てられる。AWSによると、AgentCore Runtimeは各セッションに専用のmicroVMを提供し、アプリケーション層の制御がテナント間の分離を担う。

この方法はデプロイと顧客オンボーディングを簡素化する一方、アプリケーション側の責任を増やす。エージェントは各リクエストでテナントコンテキストを正しく解釈し、テナント間アクセスを防がなければならない。テナント固有の挙動には、共有デプロイ内で追加の条件分岐ロジックが必要になる場合もある。

ブリッジモデルは両者を組み合わせる。エージェント実行環境は共有しつつ、ツール層でより厳格なテナント制御を適用する。AWSが説明するアーキテクチャでは、AgentCore Gatewayがエージェントと外向きツールの間に置かれ、実行前にツール呼び出しをテナント境界に照らして検査できる。

AWSはこのハイブリッドパターンを、顧客システムへのアクセスに対する強い制御点を維持しながら、インフラのオーバーヘッドを削減する方法として示している。ケーススタディは本番実装の詳細をすべて明かしていないため、入手可能な証拠だけではAxoniusが各コンポーネントを共有リソースと専用リソースのどちらにどう割り当てたかを評価することはできない。

IDとツールアクセスも分離境界の一部

Axoniusにはすでに、テナント固有のAmazon EC2基盤上で動作する認証・認可モジュールがあった。必要だったのは、そのIDフローを置き換えずにエージェントを追加することだった。

AWSは、テナントがAmazon CognitoのようなOAuth 2.0 IDプロバイダーを通じて認証する設計を説明している。トークンには、たとえばカスタムのテナントIDといったテナント固有のクレームが含まれる。AgentCore Runtimeの組み込みJWT認可機能は、IDプロバイダーのディスカバリーエンドポイントを使ってトークンを検証し、エージェントはそのクレームを読み取ってリクエストを正しい顧客環境へルーティングする。

この分担は重要である。トークン検証は、リクエストが受け入れられたIDプロバイダーから来たことを示すが、エージェントとそのツールは依然としてテナントクレームを正しく適用する必要がある。実務上、安全境界は、プラットフォームの認可機構と、IDをAPI、データストア、ツールにマッピングするコードの両方に依存する。

同じ原則がサービス統合にも当てはまる。AWSによると、テナントに関連付けられたエージェントは、そのテナントのAPIへ安全にアクセスできなければならない。投稿では、AgentCore Gatewayを外向きのツール呼び出しに対する強制ポイントとして提示し、ツールが顧客ワークロードとやり取りする前にテナントコンテキストを確認できる層を作るとしている。

証跡、コスト管理、運用規模

AWSは、モデル呼び出しがエージェント費用の大部分を占めると予想されるため、コスト追跡をAxoniusの中核要件の1つとして挙げている。テナント別の会計は、SaaSプロバイダーがAI機能の価格設定、利用上限の設定、異常に高い消費を示す顧客やワークフローの特定を行ううえで役立つ。

同社はまた、既存のサイロ型継続デリバリープロセスにエージェントワークロードを追加する必要があった。これは見落とされやすい要件だ。試作ではうまく機能するアーキテクチャでも、各顧客環境が独自のデプロイライフサイクルを持つと運用が難しくなる。

可観測性も別の懸念として挙げられている。AWSによると、Axoniusは多数のエージェントに対して、障害調査に十分な詳細を持つフリートレベルの監視、アラート、トレースを必要としていた。こうした要件により、エージェント運用は通常のアプリケーション監視とは異なる。チームは、サービスが利用可能かどうかだけでなく、どのモデル呼び出し、ツール、セッション、テナント権限が結果に寄与したのかも理解する必要がある。

入手可能な証拠は、独立した監査人や顧客インタビューではなくAWSから提供されたものである。AWSは、AgentCoreによりAxoniusが、コンピュート分離、認証、可観測性のカスタム基盤をゼロから構築することなく、分離されたマルチテナントエージェントを展開できたと報告している。これはプラットフォームの役割に関するベンダーの主張であり、工数、セキュリティ、総コストを独立に検証した比較ではない。

ビルダーと企業購入者にとっての意味

SaaS企業にとって、Axoniusの事例はエージェント追加の実践的な手順を示している。まず既存のテナントモデルから始め、データとツールの境界を特定し、そのうえでどの制御をランタイム、アプリケーション、あるいはゲートウェイ層に置くかを決める。

この選択は製品経済にも影響する。専用リソースはより明確な分離とカスタマイズを提供するが、共有ランタイムはオンボーディングと運用を簡素化できる。ブリッジ設計は重複を減らせる一方、すべてのツール境界で慎重なポリシー適用を必要とする。どのモデルでも、認可失敗、壊れたテナントクレーム、過剰なツール権限、偶発的なデータ漏えいをテストする必要性はなくならない。

AI機能を評価する企業購入者は、テナントIDがエージェントリクエストにどう追従するのか、ツール呼び出しが独立に認可されるのか、モデル利用がどう帰属されるのか、インシデント対応のためにトレースがどう分離されるのかをベンダーに尋ねるべきだ。これらの質問は、エージェントが機密性の高い資産情報、設定情報、脆弱性情報を処理しうるセキュリティソフトウェアでは特に重要である。

より広い市場への示唆は、エージェントプラットフォームがモデルアクセスだけでなく運用のプリミティブでも競争しているということだ。ランタイム分離、ID統合、ゲートウェイ、デプロイ自動化、可観測性が、エージェントをデモから、SaaSプロバイダーが数百の環境でサポートできる製品へ移行できるかどうかを左右する。

今後注目すべき点

次の注目点は、AxoniusまたはAWSからの具体的な本番詳細だ。実運用で共有ランタイム、専用ランタイム、またはブリッジ構成のどれを使っているのか、テナントレベルのコスト帰属がどう実装されているのか、どの制御がアプリケーションコードとAgentCore Gatewayのどちらで強制されているのか、である。

ビルダーはまた、デプロイオーバーヘッド、インシデント対応、分離テストに関する独立した証拠にも注目すべきだ。モデル選択、スループット、レイテンシ、そして最初のAxoniusエージェントを動かすコストに関する詳細が増えれば、明示された設計目標を超えてアーキテクチャを評価しやすくなる。

Creati.aiの視点

Axoniusの例は、セキュリティ製品にチャットボットを追加することよりも、既存のSaaS制御プレーンにエージェント実行を適合させることに関するものだ。難しい作業は、ID、データアクセス、ツール、課金、リリース、デバッグを、その要求を所有するテナントに結び付けることにある。

AWSのケーススタディは、マネージドなエージェント基盤がISVにとって魅力的である理由を示しているが、プラットフォーム抽象化がアプリケーションレベルのセキュリティリスクを排除することを証明するものではない。ビルダーにとって最も重要な教訓は、テナントルーティングとツール認可を製品クリティカルな制御として扱い、大規模アーキテクチャを採用する前に、デプロイと障害データでベンダーの主張を検証することだ。