AgentCoreで実現するマルチテナントAIエージェント

AgentCoreで実現するマルチテナントAIエージェント伊賀裕展 2025年12月20日

| 2 ©︎ Copyright ExaW iz ards Inc. All Right
s R es erv ed. 自己紹介 Pub lic 名前 > 伊賀裕展会社 > エクサウィザーズ職種 > ソフトウェアエンジニア好きなサービス > Amazon Bedrock AgentCore Twitter > @iganin_dev LinkedIn > https://www.linkedin.com/in/hironobu-iga- 79994010a/

マルチテナント SaaSについてマルチテナントの課題 AgentCoreでの対処注意事項 - Quotas まとめ 01. 02.
03. 04. 05.

マルチテナント SaaSについて 01.

s R es erv ed. SaaS 従来型ソフトウェアとSaaS Pub lic 従来型 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/the-initial-motivation.html • 製品をインストールしたスタンドアロン環境で運用 • 実行する製品のバージョンをカスタマーが制御 • 新機能のリリースのオーバーヘッドが大きくなる

s R es erv ed. SaaS 従来型ソフトウェアとSaaS Pub lic 従来型 • 製品をインストールしたスタンドアロン環境で運用 • 実行する製品のバージョンをカスタマーが制御 • 新機能のリリースのオーバーヘッドが非常に大きくなるチームのサイクル時間が長くなり、新機能がユーザーの手に届くまでの時間が伸びる結果として、市場のダイナミクスに対応する能力を損なう可能性がある https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/the-initial-motivation.html

s R es erv ed. SaaS 従来型ソフトウェアとSaaS Pub lic 従来型 SaaS https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/moving-to-a-unified-experience.html • 製品をインストールしたスタンドアロン環境で運用 • 実行する製品のバージョンをカスタマーが制御 • 新機能のリリースのオーバーヘッドが非常に大きくなるチームのサイクル時間が長くなり、新機能がユーザーの手に届くまでの時間が伸びる結果として、市場のダイナミクスに対応する能力を損なう可能性がある • すべてのテナントは 1 つの集合的な SaaS 環境で管理される • すべてのテナントが同じバージョンのアプリケーションを実行 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/the-initial-motivation.html

s R es erv ed. SaaS 従来型ソフトウェアとSaaS Pub lic 従来型 SaaS • 製品をインストールしたスタンドアロン環境で運用 • 実行する製品のバージョンをカスタマーが制御 • 新機能のリリースのオーバーヘッドが非常に大きくなるチームのサイクル時間が長くなり、新機能がユーザーの手に届くまでの時間が伸びる結果として、市場のダイナミクスに対応する能力を損なう可能性がある • すべてのテナントは 1 つの集合的な SaaS 環境で管理される • すべてのテナントが同じバージョンのアプリケーションを実行単一の共有プロセスですべてのテナントに新しい機能をデプロイ可能運用上のオーバーヘッドを増やすことなく新しいテナントを追加可能 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/the-initial-motivation.html https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/moving-to-a-unified-experience.html

s R es erv ed. SaaS SaaS Pub lic 顧客ごとの個別導入ではなく多数の顧客に同じ仕組みを提供するつまり、同じシステムを、複数の顧客が同時に使う顧客間で環境を共有する「マルチテナント」が重要になる

s R es erv ed. SaaS SaaSのコントロールプレーンとアプリケーションプレーン Pub lic アドミニストレーションアプリケーション SaaS アプリケーションコントロールプレーンアプリケーションプレーンオンボーディング支払い管理メトリクステナント管理アイデンティティ管理アドミンユーザー管理サービスサービスコアサービステナントプロビジョニングサービスサービスアプリケーションサービスデータデータ

s R es erv ed. SaaS SaaSのコントロールプレーンとアプリケーションプレーン Pub lic アドミニストレーションアプリケーション SaaS アプリケーションコントロールプレーンアプリケーションプレーンオンボーディング支払い管理メトリクステナント管理アイデンティティ管理アドミンユーザー管理サービスサービスコアサービステナントプロビジョニングサービスサービスデータデータコントロールプレーンはSaaS全体で1つアプリケーションプレーンはSaaSで複数のデプロイパターンアプリケーションサービス

s R es erv ed. SaaS アプリケーションプレーンにおけるデプロイパターン Pub lic サイロプールサービスデータサービスサービスデータサービステナント 1 テナント 2 サービスデータサービステナント 1 テナント 2 サービスデータサービスデータテナント 1 テナント 2 サービスデータサービステナント 3 データハイブリッド

s R es erv ed. SaaS サイロモデル(専用モデル) 各テナントでインフラストラクチャを占有メリット • 強力で自然なテナント分離 • リソース消費がテナントと直接紐づくデメリット • コストが高くなる傾向がある • テナント数が増えると運用が複雑化するなど... Pub lic サービスデータサービスサービスデータサービステナント 1 テナント 2

s R es erv ed. SaaS プールモデル(共有モデル) Pub lic 複数テナントでインフラストラクチャを共有メリット • 高いリソース効率 • 迅速なオンボーディングデメリット • 設計と実装が複雑化しやすい傾向がある • データ分離のための厳格なアクセス制御など... サービスデータサービステナント 1 テナント 2

s R es erv ed. SaaS ハイブリッドモデル(混合モデル) Pub lic サイロとプールが共存リソースごとの例 • Computingはプール • Databaseはサイロ Tierによる違いの例 • プレミアムはサイロ • 通常は一部リソースをプールサービスデータサービスデータテナント 1 テナント 2 サービスデータサービステナント 3 データ

s R es erv ed. SaaS アプリケーションプレーンにおけるデプロイパターン Pub lic サイロハイブリッドプールサービスデータサービスサービスデータサービステナント 1 テナント 2 サービスデータサービステナント 1 テナント 2 サービスデータサービスデータテナント 1 テナント 2 サービスデータサービステナント 3 データテナントのティアリソース効率運用効率を考慮して、どのパターンにするかを検討する

s R es erv ed. SaaS さらなる詳細はSaaS Lensで... Pub lic サイロ、プールのメリット・デメリットは他にもあります AWS Well-Architected フレームワーク SaaS レンズにより詳細が載っていますので、ぜひご確認ください！ https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/silo-isolation.html https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/pool-isolation.html https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/bridge-model.html

マルチテナントの課題 02.

s R es erv ed. マルチテナントの課題課題の一覧・テナントコンテキストの伝播・データのパーティショニング・テナント分離・うるさい隣人問題・テナントごとのオブサーバビリティ・etc Pub lic

s R es erv ed. マルチテナントの課題テナントコンテキスト Pub lic SaaS 環境全体で使用されるテナントに関する重要な情報(※1) • テナントID o テナントの固有識別子 • テナントティア o standard, premiumなど • etc ※1 http://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/saas-identity.html

s R es erv ed. マルチテナントの課題テナントコンテキストの伝播テナントコンテキストはマルチテナントを扱う上での重要情報ルーティングやアクセス制御などの基礎となる SaaS全体に伝播する必要がある Pub lic

s R es erv ed. マルチテナントの課題データのパーティショニング個々のテナントに対してテナントデータがどのように保存されるかを決めるサイロ：データは分離され混合されることは基本的にはないプール：データは混在するので、テナント識別子などでテナントと紐づける例： DynamoDB サイロ： 1テナント 1テーブルプール：テーブルのPartitioning Key にテナント識別子を使用 Pub lic

s R es erv ed. マルチテナントの課題データのパーティション化 - Dynamo DB Pub lic サイロプール

s R es erv ed. マルチテナントの課題テナント分離テナントコンテキストを使用してリソースへのアクセスを制限するアプリケーションロジックだけでなくストレージ / DBレイヤーでの保護を追加する多層防御の実現により、よりセキュアな実装が可能 Pub lic

s R es erv ed. マルチテナントの課題テナント分離 - DynamoDB Dynamo DBの例 Policyでアクセスを制御 dynamodb:LeadingKeys DynamoDBのpartition keyの値 Partition keyがtenant id と同一のデータしかアクセスできないことが保証される Pub lic Permission Policy の例 { "Effect": "Allow", "Action": [...], "Resource": [...], "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": [ "{tenant_id}" ] } } }

s R es erv ed. マルチテナントの課題うるさい隣人問題プールされているリソース • 特定のテナントがリソースを大きく使用 • テナント間の不公平・リソース枯渇 • システム全体の不安定化対処 • 使用量の監視 o 閾値を超えた際のスロットル o レイトリミットの実装 o 閾値を超えたらティアを変更する • キューを使った制御 • オートスケーリングの導入 Pub lic

s R es erv ed. マルチテナントの課題テナントごとのオブサーバビリティ Pub lic 通常のメトリクスではテナントはファーストクラスの指標ではないメトリクスにテナントコンテキストを含める必要があるその上で、テナントを加味したダッシュボードを作成する https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/tenant-insights.html

s R es erv ed. AgentCoreにおける対応 03.

s R es erv ed. AgentCore Amazon Bedrock AgentCore Pub lic Amazon Bedrock AgentCore は、あらゆるフレームワークと基盤モデルを使用して、大規模かつ安全に、非常に効果的なエージェントを構築、デプロイ、運用するためのエージェントプラットフォーム https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html

s R es erv ed. AgentCore AgentCoreにおける対応 Pub lic 基本的には従来の対応と大きな差はないサービスごとにサイロ / プールを決めるその上で、テナントコンテキストの伝播、データパーティショニング、テナント分離を検討これ以降、以下のコンポーネントに関して確認する • AgentCore Runtime • AgentCore Memory • AgentCore Gateway

s R es erv ed. AgentCore Runtime A.

s R es erv ed. AgentCore Runtime AgentCore Runtime Pub lic AI エージェントやツールのデプロイと実行に特化した、安全でサーバーレスなホスティング環境を提供 • セッション分離 • モデルの柔軟性 • フレームワーク非依存 • 消費ベースの価格設定モデル • etc https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/01-AgentCore-runtime

s R es erv ed. AgentCore Runtime AgentCore Runtimeのセッション分離 Pub lic Firecracker MicroVM レベルで分離メモリ等のコンタミネーションを避けられる AWS re:Invent 2025 - Transforming from SaaS to multi-tenant agentic SaaS (SAS304)

s R es erv ed. AgentCore Runtime AgentCore Runtime とテナントコンテキスト Pub lic AgentCore Runtime では Agent やツールがホスティングされる入り口として、テナントコンテキストをクライアントから受け取る必要があるその上で、テナントコンテキストをダウンストリームに伝える Tenant Context

s R es erv ed. AgentCore Runtime Runtimeへのテナントコンテキストの伝播 Pub lic 手順 • IdPをCognitoとして、カスタムクレームでテナントコンテキストを定義 • Pre Token Generation Lambda Triggerでアクセストークンにカスタムトークンを含める • AgentCore RuntimeのrequestHeaderAllowlistにAuthorizationを登録 • PyJWTパッケージなどでクレームを取得

s R es erv ed. AgentCore Runtime JWT 使用 • JWTを使用してテナントコンテキストを伝える • 署名されているため、検証することでかいざんされていないことを保証できる Pub lic { "iss": 発行者の識別子, "sub": ユーザー識別子, ”cid”: ”client_id", "exp": トークンの有効期限のタイムスタンプ, "iat": トークン発行日時のタイムスタンプ, "aud" : トークンの受信者識別子, "scopes": 情報の範囲や権限, "tenant_id": テナント識別子, "tenant_tier": テナントのティア } テナントコンテキストを含める

s R es erv ed. AgentCore Runtime CognitoにおけるCustom Claimsの設定 Pub lic CognitoのUserPoolにcustom claimsを定義し、テナントコンテキストを含める

s R es erv ed. AgentCore Runtime Pre Token Generation Lambda Trigger Pub lic Custom Claims は通常 ID Token に含まれるが Acccess Token には含まれない Pre Token Generation Lambda Trigger で Access Token にも含めるようにする Version2 を使用

s R es erv ed. AgentCore Runtime Pre Token Generation Lambda Trigger Pub lic def lambda_handler(event, context): # ユーザー属性からテナントコンテキストを取得 tenant_id = event.get('request', {}).get('userAttributes', {}).get('custom:tenant_id') tenant_tier = event.get('request', {}).get('userAttributes', {}).get('custom:tenant_tier') # アクセストークンにテナントコンテキストを追加 event['response'] = event.get('response', {}) event['response']['claimsAndScopeOverrideDetails'] = { 'accessTokenGeneration': { 'claimsToAddOrOverride': {' tenant_id': tenant_id , tenant_tier: tenant_tier } } } return event

s R es erv ed. AgentCore Runtime RuntimeのrequestHeaderAllowlistの設定 Pub lic Runtimeの requestHeaderAllowlist で Authorization を許可し、 tokenをRuntimeから取得できるようにする agentcore configure --entrypoint agent.py \ --name sample_agent \ --execution-role sample-role-arn \ --requirements-file requirements.txt \ --authorizer-config "{\"customJWTAuthorizer\": ~~~ \ --request-header-allowlist "Authorization"

s R es erv ed. AgentCore Runtime RuntimeのcontextからJWTを取得しデコードする Pub lic Runtimeのentrypointのcontextからtokenを取得しPyJWKClientでdecodeする claims からテナントコンテキストを取得できる @app.entrypoint def invoke(payload, context): auth_header = context.request_headers.get('Authorization') token = auth_header.replace('Bearer ', '') if auth_header.startswith(' Bearer ') else auth_header jwks_client = PyJWKClient(jwks_url) signing_key = jwks_client.get_signing_key_from_jwt(token) decoded = jwt.decode( access_token, signing_key.key, algorithms=["RS256"], issuer=f"https://cognito-idp.{region}.amazonaws.com/{user_pool_id}", options={"require": ["exp", "iat", "iss", "token_use"]}, )

s R es erv ed. テナントコンテキストの伝播 Runtime以降のテナントコンテキストの伝播 Pub lic Runtime以降のダウンストリームへのテナントコンテキストの伝播 JWTを利用する場合以下の2つの方法がある • Impersonation - なりすまし • Act on behalf Delegation - 代理実行

s R es erv ed. テナントコンテキストの伝播 Impersonation - なりすまし Pub lic クライアントから受け取ったTokenをダウンストリームに渡し続ける同一Tokenなので、Scopeも元のまま... scope> item:read, record:write scope> item:read, record:write scope> item:read, record:write

s R es erv ed. テナントコンテキストの伝播 Act on behalf Delegation - 代理実行 Pub lic クライアントから受け取ったTokenを変更しながらダウンストリームに渡す下の例ではtoolに渡される際にscopeが絞られている scope> item:read, record:write scope> item:read Scope> record: write

s R es erv ed. テナントコンテキストの伝播なりすましでおきる問題 Pub lic クライアントから受け取ったTokenをダウンストリームに渡し続ける最小権限の原則に違反し、必要以上に大きな権限を持つことになる下流に渡したTokenが漏れた場合に「サービス全体のアクセス」ができてしまう混乱した代理人問題が起きる可能性もある scope> item:read, record:write

s R es erv ed. テナントコンテキストの伝播 AI Agent では代理実行パターンを使う Pub lic ホップ毎に Token Exchange を行う代理実行パターンで認証・認可情報をつたえる代理実行パターンによって、最小権限の原則を守り、セキュリティを高く保つ AIエージェント A AIエージェント B サービス A

s R es erv ed. テナントコンテキストの伝播 Token Exchange について Pub lic Token Exchangeについて、2025年12月18日に 14-token-exchange-at-request-interceptorというサンプルが amazon-bedrock-agentcore-samplesに追加されました。ご興味のある方はぜひ確認してみてください！

s R es erv ed. AgentCore Memory B.

s R es erv ed. AgentCore Memory AgentCore Memory Pub lic AIエージェントに過去のインタラクションを記憶する機能を提供するフルマネージドサービス短期的なコンテキストと長期的な知識の保持の両方をシンプルかつ強力に処理可能 https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html

s R es erv ed. AgentCore Memory AgentCore Memory Pub lic AgentCore Memoryにはユーザーとの会話履歴が保存されるユーザー、テナント固有の情報も含まれる可能性があるデータ層としてデータパーティショニングやテナント分離がとても重要テナント A ユーザー A メモリーテナント A ユーザー B メモリーテナント B ユーザー C メモリー

s R es erv ed. AgentCore Memory Memoryのデータパーティショニング Long Term Memory namespaceで論理分離 namespaceにテナントコンテキストを含める actorId=${tenantId}:${userId} namespace=/strategy/{memoryStrategyId}/a ctor/{actorId} Pub lic Short Term Memory actorId, sessionIdで分離 actorIdにテナントコンテキストを含める例： actorId=${tenantId}:${userId}

s R es erv ed. AgentCore Memory Memoryのテナント分離 Pub lic ActorIdやnamespaceに対してIAM PolicyのConditionで条件を絞る Runtime から AWS STSを使用して一時credentialsを発行して使用

s R es erv ed. AgentCore Memory Memoryのテナント分離手順 Pub lic • IAM Roleに付与するPermisson Policyを定義 • IAM Roleに付与するTrust Policyを定義 o ① assumeRoleの呼び出し許可 o ② SessionTag付け許可 • STSでTagを付与してassumeRoleを実行 • 一時クレデンシャルを用いたMemoryへのアクセス

s R es erv ed. AgentCore Memory Memoryのテナント分離 - Permission Policy ① Pub lic Short Term Memoryへのアクセス許可 bedrock-agentcore:actorIdをconditionで指定する { "Sid": "ShortTermMemoryPolicy", "Effect": "Allow", "Action": [... ], "Resource": ["arn:aws:bedrock-agentcore:{REGION}:{account_id}:memory/{memory_id}"], "Condition": { "StringEquals": { "bedrock-agentcore:actorId": "${aws:PrincipalTag/actorId}" } } }

s R es erv ed. AgentCore Memory Memoryのテナント分離 - Permission Policy ② Pub lic Long Term Memory へのアクセス許可 bedrock-agentcore:namespaceをconditionで指定する { "Sid": "LongTermMemoryPolicy", "Effect": "Allow", "Action": [... ], "Resource": ["arn:aws:bedrock-agentcore:{REGION}:{account_id}:memory/{memory_id}"], "Condition": { "StringEquals": { "bedrock-agentcore:namespace": "/strategies/${strategy_id}/actor/${aws:PrincipalTag/actorId}" } } }

s R es erv ed. AgentCore Memory Memoryのテナント分離 - Trust Policy Pub lic IAM RoleにRuntimeに対する実行権限とTag付けの信頼ポリシーをつける AssumeRoleでTagをつけるためにはsts:TagSessionの信頼ポリシーが必要 { "Sid":"AllowAssumeFromRuntime", "Effect": "Allow", "Principal": { "AWS": ${"Arn"} }, "Action": "sts:AssumeRole" } { "Sid": "AllowTagSession", "Effect": "Allow", "Principal": { "AWS": ${"Arn"} }, "Action": "sts:TagSession", "Condition": { "ForAllValues:StringEquals": { "aws:TagKeys": ["actorId"] } } Runtimeに対して実行許可 actorIdのTag付けを許可

s R es erv ed. AgentCore Memory Memoryのテナント分離 - STS assumeRole Pub lic STSでassumeRoleを実行し、一時クレデンシャルを作成する def assume_tenant_role(tenant_id: str, user_id: str) -> Dict[str, str]: sts = boto3.client("sts", region_name=AWS_REGION) resp = sts.assume_role( RoleArn=TENANT_ROLE_ARN, RoleSessionName="session_name", DurationSeconds=900, Tags=[{"Key": "actorId", "Value": f"{tenant_id}:{user_id}"], ) creds = resp["Credentials"] return { "access_key": creds["AccessKeyId"], "secret_key": creds["SecretAccessKey"], "session_token": creds["SessionToken"], }

s R es erv ed. AgentCore Memory Memoryのテナント分離 - Memoryへのアクセス Pub lic 一時クレデンシャルを用いてclientを生成、Memoryにアクセスする client = boto3.client( 'bedrock-agentcore', aws_access_key_id=access_key, aws_secret_access_key=secret_key, aws_session_token=session_token ) client.list_events( memoryId=memory_id, sessionId=session_id, actorId=actor_id, maxResults=5 )

s R es erv ed. AgentCore Memory Memoryのテナント分離 Pub lic Permisson Policy の Condition でテナントの条件をつける STSのassumeRole のタグでテナントコンテキストを指定 assumeRole で取得した一時クレデンシャルでアクセス上記でテナント分離を実現テナント A ユーザー A メモリーテナント B ユーザー B メモリーテナント A ユーザー A

s R es erv ed. AgentCore Memory AgentCore Memoryのテナント分離サンプル Pub lic より詳しく知りたい方や実際に手元で試したい方 amazon-bedrock-agentcore-samplesの 01-tutorials/04-AgentCore-memory/05-memory-security-patterns にAgentCore Memoryのテナント分離サンプルがあります！ CognitoのId Poolを使用した方法もあるのでぜひご参照ください！

s R es erv ed. AgentCore Gateway C.

s R es erv ed. AgentCore Gateway AgentCore Gateway Pub lic 外部リソースをエージェント互換のツールとして公開するフルマネージドサービス • 複数の API、関数、ツールを単一の MCP エンドポイントに統合 • インバウンドとアウトバウンドの認証のサポートエージェントが利用するツールの出入り口になるので、アクセス制御が重要 https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/02-AgentCore-gateway

s R es erv ed. AgentCore Gateway AgentCore Gateway のアクセス制御 Pub lic AgentCore Gatewayのアクセス制御方法は主に3つ Inbound Auth、 AgentCore Policy、 Gateway Interceptor Inbound Auth AgentCore Policy Gateway Interceptor 普通かなり細かい細かい制御の粒度

s R es erv ed. AgentCore Gateway AgentCore Gateway のアクセス制御 Pub lic AgentCore Gatewayのアクセス制御方法は主に3つ Inbound Auth、 AgentCore Policy、 Gateway Interceptor Inbound Auth AgentCore Policy Gateway Interceptor Gateway Interceptor を中心に見る制御の粒度普通細かいかなり細かい

s R es erv ed. AgentCore Gateway AgentCore Gateway Interceptor Pub lic Gatewayのrequestとresponseに対して介入することができる https://aws.amazon.com/jp/blogs/news/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/

s R es erv ed. AgentCore Gateway AgentCore Gateway Interceptor Pub lic 様々なことが可能で細かいアクセス制御なども可能 AWS re:Invent 2025 - Scale agent tools with Amazon Bedrock AgentCore Gateway (AIM3313)

s R es erv ed. AgentCore Gateway Interceptorにテナントコンテキストを伝える Pub lic AgentCore Gateway Interceptorにテナントコンテキストを伝える以下の手順で実施する • GatewayのInbound AuthをCUSTOM_JWTで設定する • JWTにテナントコンテキストを含める • GatewayのinterceptorConfigurationsを設定する • Request InterceptorでTokenからテナントコンテキストを取得する

s R es erv ed. AgentCore Gateway AgentCore Gateway Interceptor の Inbound Auth 設定 Pub lic GatewayでInboundの認可にCUSTOM_JWTを指定する JWTにテナントコンテキストを含める gateway_response = agentcore_client.create_gateway( .... authorizerType="CUSTOM_JWT", authorizerConfiguration={ "customJWTAuthorizer": "discoveryUrl": "DISCOVERY_URL", "allowedClients": ["CLIENT_ID"] } }, ... )

s R es erv ed. AgentCore Gateway AgentCore Gateway Interceptor の設定 Pub lic InterceptorConfigurationsでintetrceptorの設定を行う PassRequestHeadersをTrueにすることでAuthorization HeaderをInterceptorで受け取れる gateway_response = agentcore_client.create_gateway( interceptorConfigurations=[{ "interceptor": {"lambda": {"arn": lambda_arn}}, "interceptionPoints": ["REQUEST"], "inputConfiguration": {"passRequestHeaders": True} }], .... roleArn=iam_response['Role']['Arn'] )

s R es erv ed. AgentCore Gateway Request Interceptor テナントコンテキストの取得 Pub lic HeadersからJWT tokenを取得し、テナントコンテキストを取得する PyJWTパッケージなどでデコードしてクレームからテナントコンテキストを取得する mcp_data = event.get('mcp', {}) gateway_request = mcp_data.get('gatewayRequest', {}) headers = gateway_request.get('headers', {}) auth_header = headers.get('authorization', '') or headers.get('Authorization', '') decoded = "bearer token をdecodeする処理" tenant_id = decoded["tenant_id"]

s R es erv ed. AgentCore Gateway AgentCore Gateway への mcp リクエスト Pub lic AgentCore Gateway への mcp リクエストは下記 • tools/list o 使用可能なMCP Tool の一覧を取得する • tools/call o 指定したToolの呼び出し

s R es erv ed. AgentCore Gateway mcpリクエストへのInterceptorでの介入 Pub lic どのタイミングで介入するかを考える • tools/list o 使用して良いToolとして返却される前にFilterしたい -> Response • tools/call o Toolが実行される前に阻止したい -> Request

s R es erv ed. AgentCore Gateway AgentCore Gateway Interceptor による制御 Pub lic Gateway Interceptorでの制御を以下のように整理する • Request Interceptor o tools/callに対して介入する o テナントでツール実行が許可されているか確認し、実行を制御する • Reponse Interceptor o tools/listに対して介入する o テナントに許可されたツールか確認し、フィルターした結果を返却する

s R es erv ed. AgentCore Gateway Request Interceptor のペイロード Pub lic headersやbodyなどのリクエストの中身が取得できる bodyのmethod から呼び出しの種類を判別できる tools/call -> ツールの呼び出し / tools/list -> ツール一覧の取得 { "interceptorInputVersion": "1.0", "mcp": { "gatewayRequest": { "headers": { "Authorization": "Bearer token...", ... }, "body": { "jsonrpc": "2.0", "method": "tools/list", ... } }, "requestContext": { ... } } }

s R es erv ed. AgentCore Gateway Request Interceptor の返却値 Pub lic transformedGatewayRequestを含めて返却する必要があるなりすましパターンを避けるため Authorization HeaderのJWT Tokenをそのまま流さないことに注意 return { "interceptorOutputVersion": "1.0", "mcp": { "transformedGatewayRequest": { "headers": { "Accept": "application/json", "Content-Type": "application/json" }, "body": extended_body } } }

s R es erv ed. AgentCore Gateway Request Interceptor でのツール呼び出し制御 Pub lic methodがtools/call(ツール呼び出し)の場合はテナントコンテキストから呼び出し可否を判断する if method == "tools/call": tool_name = params.get("name", "") if not _is_tool_allowed(tenant_id, tool_name): return { "mcp": { "transformedGatewayResponse": { "statusCode": 403, "headers": {"Content-Type": "application/json"}, "body": ..., } } } テナントが Toolの使用ができるか確認する def is_tool_allowed(…): DynamoDB等からtenantの情報取得 tenantの使用可能toolを確認 tool_nameが一覧にあるか確認

s R es erv ed. AgentCore Gateway Response Interceptor のペイロード Pub lic gatewayResponseにtargetからのresponseが含まれる "interceptorInputVersion": "1.0", "mcp": { "gatewayRequest": { ... }, "requestContext": { ... }, "gatewayResponse": { "statusCode": 200, "headers": { ... }, "body": { "jsonrpc": "2.0", "result": { "tools": [ ... ] } }}}}

s R es erv ed. AgentCore Gateway Response Interceptor の返却値 Pub lic transformedGatewayResponseを返却値に含める { "interceptorOutputVersion": "1.0", "mcp": { "transformedGatewayResponse": { "statusCode": 200, "headers": { ... }, "body": { ... } } } }

s R es erv ed. AgentCore Gateway Response Interceptor でのツール一覧のフィルター Pub lic TargetからのResponseに対してテナントコンテキストから返却するToolをフィルターする tools = gateway_response['body']['result'].get('tools', []) filtered_tools = filter_tools_by_tenant(tools, tenant_id) return { "interceptorOutputVersion": "1.0", "mcp": { "transformedGatewayResponse": { "statusCode": 200, "headers": { ... }, "body": { "result": { "tools": filtered_tools } }}}} テナントが Toolの使用ができるか確認する def filter_tools_by_tenant(…): DynamoDB等からtenantの情報取得 tenantの使用可能toolを確認 Toolsからtenantが使用できるtool のみフィルターして返却

s R es erv ed. AgentCore Gateway AgentCore Gateway Interceptor の制御 Pub lic 呼び出し制御 • listTools o Response Interceptorにてテナントに許されたツールのフィルターをかける • InvokeTool o Request Interceptorでテナントのツール呼び出し許可を確認し、実行を制御する

s R es erv ed. 注意事項 - Quotas 04.

s R es erv ed. 注意事項 Quotas – AgentCore Identity Pub lic AgentCore Identityのquotas Workload identities1,000 Resource OAuth2 credential providers 50 Resource API Key credential providers 50 上記全て Adjustable NO、つまり上限緩和できない https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html

s R es erv ed. 注意事項 AgentCore Identity の quotasが意味すること Pub lic Workload identities は Runtime や Gateway の生成に合わせ1つ自動生成される Runtimeの数 + Gatewayの数 <= 1,000 API Key, OAuth2による連携先1つにつき、credential providersが少なくとも1つ必要 OAuth2 による認可先 <= 50 API Keyによる認可先 <= 50

s R es erv ed. 注意事項想定ユースケース Pub lic SaaSで契約しているテナントごとの接続先を考えるテナント A: サービスA, サービスB テナント B: サービスA 同じサービスでもテナントごとに Client IdとClient Secretは異なるテナント x サービスの数だけ credential providersが必要テナントA テナントB サービス A サービス B サービス A

s R es erv ed. 注意事項想定ユースケース Pub lic SaaSで契約しているテナントごとの接続先を考えるテナント A: サービスA, サービスB テナント B: サービスA 同じサービスに接続するGateway Targetが複数 • 選択肢 ①: Gatewayに関してはサイロを選択する o Gateway内に似たTargetが存在しないようにする • 選択肢 ②: Gateway Interceptors でツール返却を制限する

s R es erv ed. 注意事項テナントごとのサードパーティーサービスへのOAuthアクセス Pub lic 選択肢 ①で考えてみる • テナントごとのサイロ Gateway • テナントごと、サービスごとの Credential Provider

s R es erv ed. 注意事項テナントごとのサードパーティーサービスへのOAuthアクセス Pub lic テナントごとに、サードパーティーサービスごとに Client ID, Client Secretが必要 credential providersの必要数 >= テナント数 x サードパーティーサービス数 quotasを考慮すると以下である必要がある... テナント数 x サードパーティーサービス数 <= 50

s R es erv ed. 注意事項テナントごとにサービスにOAuthでアクセスする Pub lic Quotasを考慮すると現時点ではテナントそれぞれが、外部サービスにOAuthで接続することは難しい.... ワークアラウンド下記どちらも未検証ですが、考えうる選択肢として... • 1 AWS アカウント 1 テナントのフルスタックサイロ構成 o 少数テナントの間は良いが、テナント数が増えると... o クロスアカウントの制約で何か問題が起きないか... • credential providersと同様の機能を自作する o とはいえ、Workload identitiesのquotasは引き続き問題となる...

s R es erv ed. 注意事項サービス設計の際には必ずquotasを確認 Pub lic quotasの中には上限緩和できないものもあるサービスの設計にクリティカルに響く場合もあるサービスを検討する際は、quotas上問題ないか確認しましょう

s R es erv ed. まとめ 05.

s R es erv ed. まとめ Pub lic • サービスの要件に合わせてリソースごとにプール / サイロどちらにするか決める • マルチテナントの各種の課題にテナントコンテキストを用いて対処する o データパーティショニング o テナント分離 • テナントコンテキストを含めたJWTはそのままSaaS全体に流すことはしない o なりすましパターンではなく代理実行パターンでトークンを流す • AgentCoreのquotasをよく確認し、サービスの要件に適うか判断する • amazon-bedrock-agentcore-samples サンプルがとても参考になるまとめ

s R es erv ed.

s R es erv ed. 参考資料

s R es erv ed. 参考資料 re:Invent 2025 Pub lic • Integration patterns for multi-tenant systems (SAS312) • Building multi-tenant SaaS agents with Amazon Bedrock AgentCore (SAS407) • Transforming from SaaS to multi-tenant agentic SaaS (SAS304) • Using GenAI to profile, scale, and optimize your multi-tenant SaaS architecture • sample-saas-multi-agents-workshop • Workshop Next-gen agentic SaaS: Transforming to an agent-powered experience

s R es erv ed. 参考資料 AgentCore Pub lic • Amazon Bedrock AgentCore Developer Guide • amazon-bedrock-agentcore-samples

s R es erv ed. 参考資料 SaaS Pub lic • Rethinking SaaS in the Agentic Era - Whitepaper • SaaS アーキテクチャの基礎 AWS ホワイトペーパー • Building multi-tenant architectures for agentic AI on AWS • AWS Well-Architected フレームワーク SaaS レンズ

s R es erv ed.

AgentCoreで実現するマルチテナントAIエージェント

AgentCoreで実現するマルチテナントAIエージェント

More Decks by iganin

Other Decks in Technology

Featured

Transcript