1 TerraformとStrands Agentsで Amazon Bedrock AgentCoreの SSO認証付きエージェントを量産しよう！ 2025/12/20 AI Builders Day 

2 はじめに 皆さん、AIエージェントの開発、やっていますか？ こんな状況の人、多いのではないでしょうか？ 上司 時代はAIエージェントだ！これを活用しない手はない！ 各々、AIエージェントを使って業務を効率化すること！ 皆さん？ 何したらいいかも、どうしたらいいかも分からないです！ 

3 みんなが似たようなものを作る＝車輪の再発明による効率の低下 ※せっかく効率化のための施策なのに無駄なことしていいの！？ プラットホームの安全性の確保 AIエージェントの活用・展開における問題 そもそもの使い方、作り方の学習コストが高く、なかなか着手できない 

4 そもそもの使い方、作り方の学習コストが高く、 なかなか着手できない みんなが似たようなものを作る＝車輪の再発明 による効率の低下 AIエージェントの活用展開における問題と解決策 プラットホームの安全性の確保 Infrastructure as Code(IaC)と フレームワーク活用による容易な 量産の仕組みを提供 自社のSSO認証による 一貫したユーザ体験の提供 Amazon Bedrock AgentCoreによる セキュアなプラットホームでの実行 

5 上記の課題解決のため、Amazon Bedrock AgentCoreとSSO認証の 仕組みをTerraformで構築するノウハウを紹介します Amazon Bedrock AgentCoreによる セキュアなプラットホームでの実行 Amazon Bedrock AgentCoreによる セキュアなプラットホームでの実行 Infrastructure as Code(IaC)と フレームワーク活用による容易な 量産の仕組みを提供 Infrastructure as Code(IaC)と フレームワーク活用による容易な 量産の仕組みを提供 自社のSSO認証による 一貫したユーザ体験の提供 自社のSSO認証による 一貫したユーザ体験の提供 ご留意いただきたい点 • 本登壇資料に記載されている内容は、2025/11/23時点のものです。 AI関連のサービスは日々更新されています。 最新の仕様については、AWSのドキュメントを確認してください。 • SSO認証は、本資料では例としてAuth0を使用しています(一部、Microsoft Entra IDも紹介)。 各社の認証基盤における設定方法は、皆様の会社の主管部門にお問い合わせください。 ※これから始めるならAmazon Cognitoがお手軽でお奨めです 

6 Amazon Bedrock AgentCoreとは  AIエージェントの実行・運用に特化したフルマネージド・サーバレスの実行基盤 ⇒ Amazon ECRまたはAmazon S3にデプロイしたらすぐ使える  AIエージェントのアプリケーション(ランタイム)はコンテナ上で実行 ⇒ 環境上の縛りが少なく、やりたいことはだいたいできる  APIのHTTPサーバは、ランタイムに包含されていて開発・詳細な設定が不要 AWS Cloud Amazon Bedrock AgentCore Agent Runtime Amazon ECR Amazon S3 SDK コード VSCode等の開発環境 .zip コンテナイメージ ZIPファイル 

7 Amazon Bedrock AgentCoreとは  AIエージェントの開発に必要なツール群がマネージドで揃っている Identity: Bedrock AgentCoreに対するインバウンド/アウトバウンド認証 Memory: LLMとの会話のメモリを制御 Gateway: MCPとの通信を行うためのゲートウェイ Code Interpreter: LLMが生成したコードをセキュアに実行する独立した環境 Browser: LLMにブラウザ操作させるための独立した環境 Observability: AIエージェントのトレースを確認するための基盤 Evaluations: 生成結果の評価を行い、エージェントの品質を確認可能にする Policy in AgentCore: Tool実行時に動作可能な範囲を制限する  利用料金は基本的にPay as you go(使った分だけ) 対話型エージェントでよく使う機能。簡単な実装方法を紹介 New!! 

8 と紹介すると、「簡単にできるよ！」と聞こえますが、ぶっちゃけ な人には相当ハードルが高いです(AWSﾁｮｯﾄﾜｶﾙ、な人でもつらい)。 「こういうのがあるから作ってね」では、組織のみんなは作れません(断言)。 何したらいいかも、どうしたらいいかも分からないです！ Infrastructure as Code(IaC)とフレームワーク活用による容易な量産の仕組みを提供 そこで として、Terraform(IaC)とStrands Agents(フレームワーク)の登場です。 皆さん？ 

9 Strands Agentsとは AWSが管理するオープンソース。AIエージェントの構築・実行を支援するSDK AIエージェントを素で開発すると、めちゃくちゃ面倒くさい！ プロンプト管理、モデル実行(AWSのBedrock API実行)、ツール管理、モデルレス ポンスの処理、マルチエージェントのオーケストレーション、などなど…… これらをシンプルに使えるようにAPIがまとめられている よく言われるのが、「3行でエージェントが作れる」 ※実際はちゃんと知らないと3行で作れないし、ほぼ意味のないコードだが、 AIエージェント開発のHello World体験としてはインパクトが大きい from strands import Agent agent = Agent() agent(“Hello World!!") 

10 Amazon Bedrock AgentCoreの定義 Terraformとは IBM HashiCorp社が提供するIaCの実行基盤。 HCL(HashiCorp Configuration Language)という言語を使い、クラウドの リソースを定義し、更新APIの実行結果や参照APIの内容を確認することが可能 クラウドベンダごとにProviderをアドオンするかたちで実行し、設定の連携が可能 ⇒ 今回のようにAuth0/Microsoft Entra IDといったSaaSとAWSの設定値を 連携して1コマンドで作成ができる Terraformリポジトリ Auth0 Provider AWS Provider OAuth2プロバイダの定義 設定値の連携 要は、AWS/SaaS混在の色々なマネコンを跨がずとも1発で環境が出来上がる夢のコマンド！ 要は、AWS/SaaS混在の色々なマネコンを跨がずとも1発で環境が出来上がる夢のコマンド！ 

11 Amazon Bedrock AgentCoreのTerraformにおける構成要素 今回使うのは、ランタイムとメモリの2つ • aws_bedrockagentcore_agent_runtime • aws_bedrockagentcore_memory その他のリソースはTerraformのドキュメント参照(今回は使いません) aws_bedrockagentcore_agent_runtime | Resources | hashicorp/aws | Terraform | Terraform Registry あれ？認証は？と思った方、安心してください。 Bedrock AgentCore Agent Runtimeは認証のための設定が可能で、裏でIdentityを勝手に 作成してくれます。 ※勝手に作成してほしくないけどしてしまうので、これを活用することにします ※※さらに言うと、勝手に作ったくせに勝手に消してくれず、自分で消すこともできなくなります…… あれ？認証は？と思った方、安心してください。 Bedrock AgentCore Agent Runtimeは認証のための設定が可能で、裏でIdentityを勝手に 作成してくれます。 ※勝手に作成してほしくないけどしてしまうので、これを活用することにします ※※さらに言うと、勝手に作ったくせに勝手に消してくれず、自分で消すこともできなくなります…… 

12 本資料で作成する基盤の構成図  ここから、以下の構成を作るためのTerraformのコードを説明します AWS Cloud Streamlit等の画面IF 認証 エージェント実行(JWTトークン付与) 検証情報の取得 Amazon Bedrock IAMロール Amazon CloudWatch Logs Amazon Bedrock AgentCore Agent Runtime Memory Strands Agents 

13 Terraformの準備  AWS Loginを使用している場合、Terraformのデフォルト設定だと、 credentialが取得できずにいきなり詰む → ~/.aws/credentialsの[default]セクションに以下を追記する [default] credential_process = aws configure export-credentials 

14 Amazon Bedrock AgentCore Agent Runtimeの構築  Amazon Bedrock AgentCore Agent Runtimeは、実際のAIエージェントの コードを実行する、心臓部となる部分 resource "aws_bedrockagentcore_agent_runtime" "example" { agent_runtime_name = "example" role_arn = aws_iam_role.example.arn agent_runtime_artifact { container_configuration { container_uri = "${aws_ecr_repository.example.repository_url}:latest" } } authorizer_configuration { custom_jwt_authorizer { discovery_url = "https://${var.auth0_domain}/.well-known/openid-configuration" allowed_audience = [auth0_resource_server.amazon_bedrock_agentcore_runtime_auth.identifier] } } network_configuration { network_mode = "PUBLIC" } request_header_configuration { request_header_allowlist = [ "Authorization", ] } environment_variables = { # 必要な環境変数を定義 } } ECRのリポジトリURLを指定 ※単純なコード実行のみならコードのアップロードも可能 OAuth2の検証設定 ここで指定したURLに情報を取得しにいって検証。 JWTトークンのaudがここと一致しないと検証失敗 ネットワーク設定 セキュアに運用する場合はVPC上での実行を推奨 HTTPリクエストヘッダを透過する設定 トークン検証をランタイムで行う場合、 Authorizationを入れておかないとエラーになる ※この設定はAWSのマネコンからは入れられず、さらに マネコンで他の項目を更新するとクリアされるので注意 IAMロールに必要な権限に ついては次スライド参照 

15 Amazon Bedrock AgentCore Agent Runtimeの構築(補足) Microsoft Entra IDでSSOする場合は、以下の部分を変更する  クライアントの実装上は、Auth0はaccess_tokenを使用するが、Microsoft Entra IDでは id_tokenを使用する(項目名の差異を意識した実装をする) authorizer_configuration { custom_jwt_authorizer { discovery_url = "https://login.microsoftonline.com/${var.entraid_tenant_id}/.well-known/openid-configuration" allowed_audience = [var.entraid_client_id] } } 

16 Amazon Bedrock AgentCore Agent Runtimeの構築(補足) aws_bedrockagentcore_agent_runtimeのリソースを作ると、DEFAULTエンド ポイントが作られる。個人やチーム向けのワークロードはこのエンドポイントで も問題ない。サービスとして提供する場合は、 aws_bedrockagentcore_agent_runtime_endpointリソースで検証/商用エンド ポイントを使い分ける なお、安全にエンドポイントを更新するための構成考察は以下の記事を参照。 resource "aws_bedrockagentcore_agent_runtime_endpoint" "example" { name = "production" agent_runtime_id = aws_bedrockagentcore_agent_runtime.example.agent_runtime_id } Amazon Bedrock AgentCoreのランタイムをAWS CodePipelineで安全に更新するためのパイプラインをTerraformで構 築する #BedrockAgentCore - Qiita 

17 Amazon Bedrock AgentCore Agent Runtimeの実行に必要な権限①  信頼性ポリシーは左記のように定義する resource "aws_iam_role" "example" { name = “ExampleRole" assume_role_policy = data.aws_iam_policy_document.assume.json } data "aws_iam_policy_document" "assume" { statement { effect = "Allow" principals { type = "Service" identifiers = ["bedrock-agentcore.amazonaws.com"] } actions = ["sts:AssumeRole"] condition { test = "StringEquals" variable = "aws:SourceAccount" values = [data.aws_caller_identity.self.id] } condition { test = "ArnLike" variable = "AWS:SourceArn" values = [ "arn:aws:bedrock-agentcore:${data.aws_region.current.region}: ${data.aws_caller_identity.self.id}:*", ] } } } 実際のコードでは改行入れない サービス名は ”bedrock-agentcore.amazonaws.com” 

18 Amazon Bedrock AgentCore Agent Runtimeの実行に必要な権限②  カスタムポリシーは左記のように設定 ※最小権限構成にしようとすると けっこう面倒臭い！  本スライドはECRまわり resource "aws_iam_role_policy" "custom" { name = "ExamplePolicy" role = aws_iam_role.example.id policy = data.aws_iam_policy_document.custom.json } data "aws_iam_policy_document" "custom" { statement { effect = "Allow" actions = [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer", ] resources = [ "arn:aws:ecr:${data.aws_region.current.region}:${data.aws_caller_identity.self.id}: repository/*", ] } statement { effect = "Allow" actions = [ "ecr:GetAuthorizationToken", ] resources = ["*"] } 実際のコードでは改行入れない 

19 Amazon Bedrock AgentCore Agent Runtimeの実行に必要な権限③  カスタムポリシーは左記のように設定 ※最小権限構成にしようとすると けっこう面倒臭い！  本スライドはCloudWatch Logsまわり  CloudWatch Logsのログストリームは 自動で作られるのでリソース名をピンポ イントで設定することができない statement { effect = "Allow" actions = [ "logs:DescribeLogStreams", "logs:CreateLogGroup", ] resources = [ "arn:aws:logs:${data.aws_region.current.region}:${data.aws_caller_identity.self.id}: log-group:/aws/bedrock-agentcore/runtimes/*", ] } statement { effect = "Allow" actions = [ "logs:DescribeLogGroups", ] resources = [ "arn:aws:logs:${data.aws_region.current.region}:${data.aws_caller_identity.self.id}: log-group:*", ] } statement { effect = "Allow" actions = [ "logs:CreateLogStream", "logs:PutLogEvents", ] resources = [ "arn:aws:logs:${data.aws_region.current.region}:${data.aws_caller_identity.self.id}: log-group:/aws/bedrock-agentcore/runtimes/*:log-stream:*", ] } 実際のコードでは改行入れない 実際のコードでは改行入れない 実際のコードでは改行入れない 

20 Amazon Bedrock AgentCore Agent Runtimeの実行に必要な権限④  カスタムポリシーは左記のように設定 ※最小権限構成にしようとすると けっこう面倒臭い！  本スライドはObservabilityまわり statement { effect = "Allow" actions = [ "xray:PutTraceSegments", "xray:PutTelemetryRecords", "xray:GetSamplingRules", "xray:GetSamplingTargets", ] resources = ["*"] } statement { effect = "Allow" actions = [ "cloudwatch:PutMetricData", ] resources = ["*"] condition { test = "StringEquals" variable = "cloudwatch:namespace" values = [ "bedrock-agentcore", ] } } 

21 Amazon Bedrock AgentCore Agent Runtimeの実行に必要な権限⑤  カスタムポリシーは左記のように設定 ※最小権限構成にしようとすると けっこう面倒臭い！  本スライドが重要！ statement { effect = "Allow" actions = [ "bedrock-agentcore:GetWorkloadAccessTokenForJWT", ] resources = [ "arn:aws:bedrock-agentcore:${data.aws_region.current.region}: ${data.aws_caller_identity.self.id}:workload-identity-directory/default", "arn:aws:bedrock-agentcore:${data.aws_region.current.region}: ${data.aws_caller_identity.self.id}:workload-identity-directory/default/workload-identity/*", ] } statement { effect = "Allow" actions = [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream", ] resources = [ "arn:aws:bedrock:*::foundation-model/*", "arn:aws:bedrock:${data.aws_region.current.region}:${data.aws_caller_identity.self.id}:*", "arn:aws:bedrock:ap-northeast-1:${data.aws_caller_identity.self.id}:*", ] } statement { effect = "Allow" actions = [ "bedrock-agentcore:CreateEvent", "bedrock-agentcore:ListEvents", "bedrock-agentcore:ListMemoryRecords", ] resources = [ aws_bedrockagentcore_memory.example.arn, ] } } JWT検証するための権限設定 Amazon Bedrock AgentCore Agent Runtimeを作る と、裏で勝手にWorkload Identityも作成される ※勝手に作らず自分で制御させてほしい…… Workload IdentityでJWT検証するために必要な権限 エージェントからはAmazon Bedrockの基盤モデル/ 推論プロファイルを実行するので必要な権限 リージョンは必要に応じて絞っておく 後述するAmazon Bedrock AgentCore Memoryの操 作に必要な権限 

22 Auth0の構築 Auth0では、以下のリソースを作成する  auth0_resource_server：トークン発行を担うサーバ  auth0_resource_server_scopes：認可スコープの決定  auth0_client：認証で接続するクライアントの定義 resource "auth0_resource_server" "amazon_bedrock_agentcore_runtime_auth" { name = "Amazon Bedrock AgentCore Runtime Resource Server" identifier = "urn:example_resource_server:api" signing_alg = "RS256" allow_offline_access = false token_lifetime = 3600 skip_consent_for_verifiable_first_party_clients = true enforce_policies = true token_dialect = "access_token" } resource "auth0_resource_server_scopes" "amazon_bedrock_agentcore_runtime_auth" { resource_server_identifier = auth0_resource_server.amazon_bedrock_agentcore_runtime_auth.identifier scopes { name = "invoke:agent" } } IdentifierがJWTのaudに設定される Amazon Bedrock AgentCore Agent Runtimeの authorizer_configuration.custom_jwt_authorizer.allo wed_audienceと一致させる必要あり 本登壇資料ではサンプルでinvoke:agentを認可 authorizer_configuration { custom_jwt_authorizer { discovery_url = "https://${var.auth0_domain}/.well-known/openid-configuration" allowed_audience = [auth0_resource_server.amazon_bedrock_agentcore_runtime_auth.identifier] } } 

23 resource "auth0_client" "amazon_bedrock_agentcore_runtime_auth" { name = "Amazon Bedrock AgentCore Runtime API" description = "API for Amazon Bedrock AgentCore Runtime authorization" app_type = "regular_web" custom_login_page_on = false is_first_party = true is_token_endpoint_ip_header_trusted = false oidc_conformant = true require_proof_of_possession = false grant_types = [ "authorization_code", "refresh_token", ] callbacks = [ http://localhost:8501/, ] jwt_configuration { alg = "RS256" lifetime_in_seconds = 3600 secret_encoded = false } refresh_token { leeway = 0 token_lifetime = 31557600 rotation_type = "non-rotating" expiration_type = "non-expiring" } } Auth0の構築② 認証時のコールバックURL ここが認証を実施するアプリケーション(Streamlit など)と不一致の場合エラーになるため合わせる ※完全一致にならないとエラー 本資料はサンプルのためセキュリティ設定はそこま でこだわっていない。実際にAuth0で運用する場合は、 正しくセキュリティ設計を行う • Auth0クライアント(アプリケーション)の 設定 streamlitなどで認証をする場合は”regular_web”を 設定 認可コードを取得できる権限を付与 

24 resource "aws_ecr_repository" "example" { name = local.ecr_repository_name image_tag_mutability = "MUTABLE" } data "aws_ecr_authorization_token" "token" {} resource "terraform_data" "image_push" { triggers_replace = { template_hash = sha256( join( "", concat( [for rel in sort(fileset("コードのパス", "**")) : filesha256("../コードのパス/${rel}")], ) ) ) } provisioner "local-exec" { command = <<-EOF docker buildx build --platform linux/arm64 ../script/agents -t ¥ ${aws_ecr_repository.example.repository_url}:latest; ¥ docker login -u AWS -p ${data.aws_ecr_authorization_token.token.password} ¥ ${data.aws_ecr_authorization_token.token.proxy_endpoint}; ¥ docker push ${aws_ecr_repository.example.repository_url}:latest EOF } } Amazon ECRのテクニック terraform_data.image_pushを、Agent Runtimeの depends_onに入れておくと、初回の「latestがな い」エラーを防止できて少しだけ幸せ • Amazon ECRを「AIエージェントのコー ドが変更されたときにPUSHする」を Terraformで実現したい場合の方法 • X86-64のCPUを使っている人はビルドに 死ぬほど時間がかかるので、さっさと ARMコンテナのAmazon CodeBuildのプ ロジェクトに移行しましょう コードの変更でトリガする 

25 FROM public.ecr.aws/docker/library/python:3.12-slim WORKDIR /app RUN --mount=type=cache,id=apt-lists,target=/var/lib/apt/lists,sharing=locked ¥ --mount=type=cache,id=apt-cache,target=/var/cache/apt,sharing=locked ¥ set -eux; ¥ apt update; ¥ apt install -y libreoffice poppler-utils curl && ¥ rm -rf /var/lib/apt/lists/* RUN curl -LsSf https://astral.sh/uv/install.sh | sh RUN cp -p /root/.local/bin/uv /usr/local/bin/uv RUN cp -p /root/.local/bin/uvx /usr/local/bin/uvx COPY ./pyproject.toml ./uv.lock ./ RUN mkdir src COPY src ./src RUN --mount=type=cache,target=/root/.cache/uv uv sync --frozen --no-dev --no-editable RUN useradd -m -u 1000 bedrock_agentcore USER bedrock_agentcore ENV DOCKER_CONTAINER=1 ENV VIRTUAL_ENV=/app/.venv ENV PATH="$VIRTUAL_ENV/bin:$PATH" EXPOSE 8080 CMD ["python", "-m", "agents"] Amazon ECRのテクニック② • Dockerfileは最小限にしてコンテナサイ ズを小さくしておく • 余計なファイルのCOPYがされないよ う、.dockerignoreを適切に設定しておく Pythonコードのコピーは、なるべく後ろに持ってく る。 ※前に置くとキャッシュが効かず、余計な処理を何 度もやることになる ※bedrock-agentcore-starter-toolkitのプレビュー当 初、この位置がイケていなくてビルドに時間がか かっていた 

26 import { for_each = var.initial_apply ? {} : { "example" = "dummy" } to = aws_cloudwatch_log_group.bedrock_agentcore[0] id = "/aws/bedrock-agentcore/runtimes/ ${aws_bedrockagentcore_agent_runtime.example.agent_runtime_id}-DEFAULT" } resource "aws_cloudwatch_log_group" "bedrock_agentcore" { count = var.initial_apply ? 0 : 1 name = "/aws/bedrock-agentcore/runtimes/ ${aws_bedrockagentcore_agent_runtime.example.agent_runtime_id}-DEFAULT" retention_in_days = 3 } Amazon CloudWatch Logsのテクニック 初回のみApply時に –var initial_apply=trueとして実 行することにしておけば、このimportブロックが発 動しない • Amazon CloueWatch Logsのロググルー プは勝手に作られてしまう • その上、ランダム文字列のランタイムID がロググループ名に含まれるため、 Lambdaのように先回りして作っておく こともできない • 一度Applyした後に、importブロックを 使ってimportすることでキレイに取り込 む 実際のコードでは改行入れない 実際のコードでは改行入れない リソース定義も、初回以降だけ有効になるようにし ておく 

27 Amazon Bedrock AgentCore Memoryの構築① メモリの構築は簡単で、以下でOK resource "aws_bedrockagentcore_memory" "example" { name = "Example_Memory" description = "Example Memory" event_expiry_duration = 7 } メモリをコードからAPI経由で呼び出す _bac = boto3.Session().client("bedrock-agentcore") def add_memory_event(actor: str, session_id: str, payload: list[dict]) -> None: try: response = _bac.create_event( memoryId=os.environ["AWS_BEDROCK_AGENTCORE_MEMORY_ID"], actorId=actor, sessionId=session_id, eventTimestamp=datetime.now(timezone.utc), payload=payload, ) except Exception as e: print(f"agent() error: {e}", exc_info=True) def get_memory(actor: str, session_id: str): payload = [] paginator = _bac.get_paginator("list_events") for page in paginator.paginate( memoryId=os.environ["AWS_BEDROCK_AGENTCORE_MEMORY_ID"], sessionId=session_id, actorId=actor, includePayloads=True, maxResults=5 ): for event in page.get("events", []): payload.append( { "role": event["payload"][0]["conversational"]["role"].lower(), "content": [event["payload"][0]["conversational"]["content"]], "event_time_stamp": event["eventTimestamp"], } ) sorted_payload = sorted(payload, key=lambda x: x["event_time_stamp"]) for sorted_payload_item in reversed(sorted_payload): if sorted_payload_item["role"] == "user": sorted_payload_item["content"].append({"cachePoint": {"type": "default"}}) return sorted_payload カスタムの暗号化要件があるならencryption_key_arnでKMSキーを 設定する(デフォルトはAWSマネージドキー) メモリは保存件数に応じて料金がかかるので、 event_expiry_duration を適宜設定する Prompt Cachingを利用する場合 Amazon Bedrock AgentCoreのPublic Preview発表 直後はこの書き方しかできなかったが、今は Strands Agentsがいい感じに対応してくれる 

28 Amazon Bedrock AgentCore Memoryの構築①(改) メモリの構築は簡単で、以下でOK resource "aws_bedrockagentcore_memory" "example" { name = "Example_Memory" description = "Example Memory" event_expiry_duration = 7 } メモリをStrand AgentsのSession Managerとして呼び出す from bedrock_agentcore.memory.integrations.strands.config import AgentCoreMemoryConfig from bedrock_agentcore.memory.integrations.strands.session_manager import AgentCoreMemorySessionManager # fmt: skip agentcore_memory_config = AgentCoreMemoryConfig( memory_id=os.environ["AWS_BEDROCK_AGENTCORE_MEMORY_ID"], session_id=session_id, actor_id=actor_id, ) session_manager = AgentCoreMemorySessionManager( region_name=os.environ["AWS_REGION"], agentcore_memory_config=agentcore_memory_config, ) agent = Agent( system_prompt=system_prompt, messages=messages, session_manager=session_manager, ) 

29 Amazon Bedrock AgentCore Memoryの構築② Amazon Bedrock AgentCore MemoryはActor IDによって領域を分けられる → つまり、Actor IDを適切に定義することで、簡易なマルチユーザのメモリが 構築可能 Actor IDは一意にしたいので、IdPのキーに任せる → IdPのキーはJWTのsubから取得可能。 → JWTは、Agent Runtimeのリクエストコンテキストに載ってくる (@app.entrypointの関数でcontext: RequestContextとして受取可能) claims = jwt.decode( context.request_headers.get("Authorization").replace("Bearer ", ""), options={"verify_signature": False }, ) actor_id = claims["sub"].replace("|", "_") agentcore_memory_config = AgentCoreMemoryConfig( memory_id=os.environ["AWS_BEDROCK_AGENTCORE_MEMORY_ID"], session_id=session_id, actor_id=actor_id, ) Auth0はsubが「auth0|ユーザID」で始まるが、 メモリのActor IDはパイプが禁止文字のため置 換している 

30 terraform apply後にアプリを起動！ ここまで実装してからローカルアプリを起動してみると、無事、Auth0のログイ ン画面が出るはずです(Microsoft Entra IDでもSSOのログイン画面が出るはず) ログイン後、Memoryの実装が必要なエージェントを 動かして、AWS CLIで以下の確認をしてみると、 メモリがActor IDの単位に作られていることがわかります $ aws bedrock-agentcore list-actors --memory-id 作成したメモリID --output text ACTORSUMMARIES xxxxxxxxxx ACTORSUMMARIES auth0_yyyyyyyyyy ACTORSUMMARIES auth0_zzzzzzzzzz $ aws bedrock-agentcore list-sessions --memory-id 作成したメモリID --actor-id xxxxxxxxxx { "sessionSummaries": [ { "sessionId": "065c408d-c0a1-4524-ae9a-8586d563a7f2", "actorId": “xxxxxxxxxx", "createdAt": "2025-11-22T12:28:02.730000+00:00" } ] } 他のActor IDのセッション情報は出てこない 

31 まとめ  ちょっと大変だけど…はじめの一歩を乗り越えればいずれも簡単に実装できる！ ※というか、皆さんコーディングエージェントでコード書きますよね？  みんなで楽しく快適なAIエージェント開発ライフを過ごしましょう！  今回作成したコードの全体は以下のGitHubリポジトリに格納しています Amazon Bedrock AgentCoreによる セキュアなプラットホームでの実行 Amazon Bedrock AgentCoreによる セキュアなプラットホームでの実行 Infrastructure as Code(IaC)と フレームワーク活用による容易な 量産の仕組みを提供 Infrastructure as Code(IaC)と フレームワーク活用による容易な 量産の仕組みを提供 自社のSSO認証による 一貫したユーザ体験の提供 自社のSSO認証による 一貫したユーザ体験の提供 GitHub - neruneruo/ai-builders-day-example