Amazon Bedrock AgentCore × CDKでマルチエージェントを構築した話

2026/2/25の JAWS-UG東京 ランチタイムLT会 #32 にて登壇させていただいた際の資料です。

Transcript

1. Amazon Bedrock AgentCore × CDK で Amazon Bedrock AgentCore × CDK で マルチエージェントを構築した話 マルチエージェントを構築した話 1 1
2. 自己紹介 プロフィール ニックネーム： くらっち 年齢: 25歳（新卒3年目） ピーディーシー株式会社 システム開発部 ↓ お猿さんアイコンが目印！ 業務内容 社内業務用Webアプリ開発 （Ruby on Rails） AIについてのR&D →主にBedrock AgentCore QA業務 →主に試験部分 2 2
3. 今回お話しする内容 3 3
4. AWS CDKでマルチエージェントを構築した話 4 4
5. やったことについての概要 1. 社内業務用Webアプリ にAIチャット機能を実装 StrandsAgents × Bedrock AgentCore Runtime 2. エージェントがMCPサーバを使えるように実装 FastMCP × Bedrock AgentCore Runtime Lambda × Bedrock AgentCore Gateway 3. ユーザの意図によってタスクを分けるために複数のエージェントを実装 全て、StrandsAgents × Bedrock AgentCore Runtime 5 5
6. エージェント構成 ※ draw.io MCP を使いました / 各AgentはA2Aではなく、Tools as Agentで連携しています 6 6
7. なんでA2Aではなく Tool as Agent？ サブエージェントをチェアマンエージェントとしてそのまま使いたい場面が想定され るから 7 7
8. なぜ AWS CDK？ デプロイが必要なリソースが多すぎる リソース 数 備考 Elastic Container Registry 7 個 エージェント×6, 自社プロダクトMCP×1 Bedrock AgentCore Runtime 7 個 エージェント×6, 自社プロダクトMCP×1 Lambda 関数 21 個 社内業務用システムAPI用（各テーブルにつき1つ...） AgentCore MCP Gateway 1 個 ターゲットに21個のLambdaを割り当て AgentCore Memory 1 個 親エージェントにのみメモリを紐付け CloudWatch N個 AgentCore Runtime, Lambdaごとに作成 → マネコンでポチポチは無理 → CDKで1発で作っちまおう！ 8 8
9. CDK コード① Lambda × 21 をループで生成 テーブル名リストをループし、Lambda と GatewayTarget をセットで生成 lambda_tables = ["users", "makers", "devices", ...(21個)] for table in lambda_tables: fn = _lambda.Function( ...中略... ) gateway_target = bedrockagentcore.CfnGatewayTarget( ...中略... ) → テーブルを追加したい場合は lambda_tables にテーブル名を足すだけ → Bedrock AgentCore Runtimeも同様にループする 9 9
10. CDK コード② DockerImageAsset で ECR 自動プッシュ Docker ビルド → ECR プッシュ → Runtime への URI 参照までループで1発完結 agent_image_dirs = { "yyyyy-chairman-agent": ".../chairman_agent", "yyyyy-xxxxxxx-api-agent": ".../xxxxxxx_api_agent", "yyyyy-yyyyy-api-agent": ".../yyyyy_api_agent", ...中略... } for agent_name, docker_dir in agent_image_dirs.items(): image_asset = ecr_assets.DockerImageAsset( # image_asset.image_uri を Runtime に直接渡せる self, f"{agent_name}Image", directory=docker_dir, ) 10 10
11. CDK コード③ ループ後に ARN を後注入 各エージェントを作成後に、プロパティをオーバーライドすることで、ARNを注入 # ループ終了後にまとめて注入 child_arn_map = { "yyyyy-xxxxxxx-manual-search-agent": "xxxxxxx_MANUAL_SEARCH_AGENT_ARN", "yyyyy-xxxxxxx-api-agent": "xxxxxxx_API_AGENT_ARN", "yyyyy-yyyyy-api-agent": "yyyyy_API_AGENT_ARN", ... } for child_name, env_key in child_arn_map.items(): chairman_runtime.add_property_override( # add_property_override でデプロイ時に正しい ARN が注入される f"EnvironmentVariables.{env_key}", runtimes[child_name].attr_agent_runtime_arn, # CloudFormation の GetAtt ) 11 11
12. ハマったポイント ① IAMロールに何の権限を割り当てれば良いんやろか！ Bedrock AgentCore Runtime → Bedrock AgentCore Runtime に必要な権限 Bedrock AgentCore Gateway → Lambda に必要な権限 Bedrock AgentCore Runtime → CloudWatchに必要な権限 ② CloudWatchのロググループは作ってあげなきゃいけなかった Bedrock AgentCore Observabilityでエージェントの処理を見たい時に、 「ロググループがない...」となりました →boto3によるデプロイはロググループが自動作成される 12 12
13. まとめ 1. A2A か Tool as Agent かは、そのエージェントの使い方を意識して決める 2. 複数エージェントの管理はCDKが便利！楽！ 3. 環境変数は後からオーバーライドできる 4. エージェント監視のためのロググループは明示的に作る！ 5. Bedrock AgentCore Runtime・Bedrock AgentCore Gateway×Lambdaなどの 決まりきった構成のものはSkill化しておきましょう！（最低限のIAMも含む） Skill化できるのもCDKの強み！ 13 13
14. とは言ったものの... 14 14
15. こんな大規模なエージェント構成を 管理するの大変... 15 15
16. 管理のしやすさを捨ててまで 1つのCDKにまとめなくても良いかもなぁ... と学びになりました。 16 16
17. ご清聴ありがとうございました ご清聴ありがとうございました 17 17