共有インフラ、分離されたテナント：Amazon Bedrock AgentCore を使用したプールモデルマルチテナンシー

マルチテナント AI アプリケーションの構築には、新しいアーキテクチャ上の課題があります。顧客間の完全なテナント分離、異なる機能を持つサービス階層、テナントごとの詳細なコスト追跡、および観測可能性が必要です。これらがないと、顧客データの漏洩、適切なサービス品質の提供失敗、または予期しないコストが発生するリスクがあります。

この記事では、Amazon Bedrock AgentCore を使用して本番環境対応のマルチテナントシステムを実装するパターンを学びます。これらのパターンは、複数のクリニックや病院にサービスを提供する医療 AI エージェントを通じて示されます。記事は医療を例としていますが、アーキテクチャパターンと実装手法はさまざまなマルチテナント AI アプリケーションに広く適用できます。SaaS プラットフォーム、複数の事業部門をサービスするエンタープライズソリューション、または異なる顧客組織向けのマネージドサービスのいずれを構築する場合でも、これらのアーキテクチャパターンを使用できます。

学習内容：

• AWS ネイティブ機能を使用してエージェントアプリケーションで完全なテナント分離を実装する方法。
• 最小限のカスタムコードでサービス階層を差別化するパターン。
• テナントごとの詳細なコスト帰属の手法。
• スケーラブルなマルチテナント AI アーキテクチャのベストプラクティス。

このブログ記事は、「Amazon Bedrock AgentCore を使用したマルチテナントエージェントの構築」シリーズのパート 2 です。パート 1 では、マルチテナントエージェントアプリケーションをアーキテクチャする際の設計考慮事項と、Amazon Bedrock AgentCore で SaaS アーキテクチャの課題に対処するために必要なフレームワークについて説明しています。

サンプルコードの GitHub リポジトリ：https://github.com/aws-samples/sample-agentcore-and-multitenancy-blog

ソリューション概要

このソリューションは、Amazon Bedrock AgentCore のネイティブ機能を活用し、AWS マネージドサービスを使用して完全なテナント分離を実現する方法を示しています。アーキテクチャは、階層 → テナント → ユーザーの 3 レベル階層を実装し、ナレッジベースのドキュメント、メモリ、モデルアクセス、コスト追跡を通じて各層で分離を強制します。階層戦略は SaaS アプリケーションの一般的なパターンであり、テナントはニーズ（ベーシックやプレミアムなど）、使用パターン、または料金プランに基づいて異なるサービス階層にグループ化されます。各階層は、そのグループ内のテナントが利用できる一連の機能とサービス品質を定義します。このアプローチにより、SaaS プロバイダーは運用効率を維持しながら、差別化されたエクスペリエンスで多様な顧客ベースにサービスを提供できます。

医療 AI アシスタントの例

実際の動作を示すために、例のソリューションは 2 つのサービス階層を実装します。

ベーシック階層：主にシンプルなドキュメント検索と取得を必要とする小規模クリニック向けに設計。これらのタスクは小規模でコスト効率の良いモデルに適しているため、この階層では Mistral Ministral 3 8B Instruct を使用し、コストを低く抑えながらシンプルなクエリに対して正確な結果を提供します。

プレミアム階層：複雑な臨床分析を必要とする病院や専門センター向け。この階層では OpenAI GPT OSS 120B を使用し、高度な推論能力により正確なツール選択を実現します。これにはプレミアム階層の顧客のみが利用できる Web 検索ツールも含まれます。

各階層内で、ソリューションはプール分離モデルを使用します。テナントは専用の分離リソースではなく、同じ基盤インフラと計算リソースを共有します。プールモデルはリソース利用率を最大化し、運用を簡素化します。一方、テナント分離はスコープ付き識別子、アクセスポリシー、データパーティショニングなどの論理的分離メカニズムによって強制されます。階層戦略とプールモデルを組み合わせることで、コスト効率と差別化されたサービスレベルの柔軟性のバランスを取ることができます。

アーキテクチャ

AgentCore のプリミティブがどのように連携してこれらのマルチテナント課題を解決するかを見てみましょう。アーキテクチャ図は、認証されたユーザーからのリクエストが階層固有のエージェントを経由して分離されたドキュメントストレージに流れる様子を示しています。

ソリューションは以下の主要コンポーネントで構成されます。

• Amazon Cognito：ユーザー認証を管理し、テナントメタデータ（階層、clinic_id、ロール）を JWT クレームに保存します。これらのクレームは抽出され、リクエストペイロードを通じてテナントコンテキストとして伝播され、各ダウンストリームコンポーネントが操作を正しいテナントにスコープできるようにします。
• Amazon API Gateway：リクエストをルーティングし、使用計画を通じて階層ベースのレート制限を実施します。
• AWS Lambda：テナントコンテキストを抽出し、対応する Amazon Bedrock AgentCore エージェントを呼び出します。
• AgentCore コンポーネント：ランタイム（エージェント実行）、メモリ（会話状態）、アイデンティティ（エージェント ID 管理）、ゲートウェイ（ツールサーバー）、ポリシー（エージェントアクション境界）。
• Amazon S3：階層ごとに分離されたバケットに臨床ドキュメントを保存し、階層型プレフィックス構造でテナント分離を実現。
• Amazon Bedrock Knowledge Bases：セマンティック検索を提供し、メタデータフィルタリングでクエリを要求元テナントのドキュメントにスコープします。
• Amazon Bedrock project：コスト割り当てタグにより階層ごとのコスト追跡を可能にします。

ソリューションウォークスルー

このセクションでは、ソリューションの主要な側面について説明します。デプロイスクリプトを実行して、ソリューションのインフラストラクチャとアプリケーションをセットアップします。このセクションのコード抜粋は、アーキテクチャの主要な側面がソリューションのコンポーネントによってどのように対処されているかを説明するためにのみ使用されており、コマンドを実行したりコードスニペットを実行する必要はありません。

Amazon Bedrock AgentCore コンポーネント

アーキテクチャは 6 つのコア Bedrock AgentCore 機能を活用してマルチテナンシーを実現します。

AgentCore Runtime：ソリューションのエージェントに計算を提供し、各エージェントセッションは分離されたマイクロ VM で実行され、テナントレベルの計算分離を実現します。階層ごとに独立したエージェントインスタンスがホストされ、階層に適したモデルと機能が設定されます。

AgentCore Identity：統一された JWT ベースの認証モデルでマルチテナントアーキテクチャを保護します。Cognito ID トークンはランタイムとゲートウェイの両方の境界でユーザーを検証し、ツール Lambda はダウンストリームデータアクセス用に独自のスコープ付き資格情報を作成します。

AgentCore Memory：会話履歴はテナント間やテナント内のユーザー間で漏洩してはなりません。ソリューションはアプリケーションレベルと IAM ベースの属性ベースアクセス制御（ABAC）の 2 層でメモリ分離を実施します。アプリケーションレイヤーでは、AgentCore Memory は複合 actor_id を持つ階層型名前空間構造を使用して、テナントごとの会話データを整理します。

AgentCore Gateway：AgentCore Gateway は、Model Context Protocol（MCP）を使用して静的 Lambda 関数を動的でコンテキスト認識型のエージェントツールに変換します。MCP は AI エージェントを外部ツールに接続するためのオープンソース標準です。

各ランタイムには、エージェントコード実行前に Cognito ID トークンを検証するインバウンド JWT オーソライザーが設定されています。ID トークンには、カスタムクレームとしてテナントメタデータが含まれます。例：sub（ユーザー一意識別子）、iss（トークン発行者）、aud（Web クライアント ID）、token_use（トークンタイプ）、cognito:username（ログインユーザー名、メモリ分離に使用）、custom:tier（階層）、custom:clinic_id（テナント ID）、custom:role（ロール）。

ゲートウェイも JWT 認証で構成され、同じ Cognito 検出 URL とオーディエンスを使用します。エージェントがゲートウェイを呼び出すと、ユーザーの元の JWT を Bearer トークンとして転送し、テナントコンテキストヘッダー（X-Tier、X-Clinic-ID、X-S3-Prefix）を添付します。ゲートウェイはトークンを検証し、テナントヘッダーを metadataConfiguration を介してターゲット Lambda に伝播します。

ターゲット Lambda はユーザーの JWT を直接受信したり処理したりすることはありません。代わりに、信頼されたテナントヘッダー（CUSTOM_JWT オーソライザーを通過した認証済みリクエストのみ信頼）を読み取り、それらのヘッダーから派生したセッションタグを持つ TVM（トークンベンディングマシン）ロールを引き受けます。TVM ロールの ABAC ポリシーは、dynamodb:LeadingKeys 条件を使用して DynamoDB アクセスを制限し、各テナントがアプリケーションレベルのフィルタリングだけでなく IAM レベルでも自クリニックのデータのみをクエリできるようにします。

TVM メカニズム：実行時に、エージェントは Tier、ClinicId、UserId をセッションタグとして持つ TVM ロールを引き受け、そのテナントの名前空間にスコープされた一時的な資格情報を受け取ります。TVM ロールの信頼ポリシーは、エージェント実行ロールのみがこれを引き受けられること、および 3 つのセッションタグすべてが存在することを保証します。

この組み合わせにより、セキュリティを犠牲にすることなく、プールモデルのマルチテナンシーの柔軟性と効率が実現されます。