Amazon Bedrock AgentCore 本番導入への道アーキテクチャ設計の実践

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2025 Classmethod, Inc. 自己紹介 2 簡単な自己紹介をさせていただきます。本日はどうかよろしくお願いいたします。名前神野雄大（Jinno Yudai）/@yjinn448208 最近X始めました！所属クラスメソッド株式会社クラウド事業本部コンサルティング部ソリューションアーキテクト資格 ● Japan All AWS Top Engineers 2025 好きなサービス ● Amazon Bedrock AgentCore ブログはこのアイコンで書いています！ラ・ムーとチーズナンが好きです！

Slide 3

Slide 3 text

© 2025 Classmethod, Inc. 対象と目的 3 本日はAmazon Bedrock AgentCoreを使っている方に対して、深掘りする内容をお届けできればと思っております！対象対象と目的 ● Amazon Bedrock AgentCoreを触ったことがあるがお試しレベルで、本番導入の設計のポイントを知りたい目的 ● Amazon Bedrock AgentCoreのアーキテクチャ例を理解して検討できるようになる

Slide 4

Slide 4 text

© 2025 Classmethod, Inc. お断り 4 大変申し訳ないですが、本日の内容はAgentCoreを少し触ったことがある、何ができるかざっくりと理解していることを前提としています。もし触りの箇所から知りたい場合は手前味噌で恐縮ですが私のブログで解説しているのでみていただけると嬉しいです。 Amazon Bedrock AgentCoreを使ってみよう！〜各種機能のポイントを解説〜著者ページ Sorry・・・

Slide 5

Slide 5 text

© 2025 Classmethod, Inc. 5 内容今日は本番導入時に重要なポイントになりそうなトピックに絞ってお伝えさせていただきます。 ● Runtime ○ Endpointの活用方法 ○ CloudFront / Lambda + API Gateway Proxyパターン ○ フロントエンドとの連携 ○ Tips:lifecycle settings について ● Gateway ○ Gatewayの利用イメージ/Semantic Searchを活用する ● Memory ○ Identityと連携してユーザーの権限を絞る ● その他 ○ IaC・デプロイ手法

Slide 6

Slide 6 text

© 2025 Classmethod, Inc. Amazon Bedrock AgentCoreはAIエージェントを展開・運用するために最適なマネージドサービスとなります。マネージドサービスによりインフラ管理を排除し、開発者がエージェントのロジック構築に集中できる環境を提供します。 Amazon Bedrock AgentCore とは 6 Amazon Bedrock AgentCore ● AIエージェントのホスティング ○ Strands Agents、LangGraphなど多様なエージェントフレームワークに対応 ● 便利なマネージドサービス ○ AIエージェントを使用する上で認証・ツール連携など便利な機能がマネージドサービスとして提供（IdentityやMemoryなど）特徴

Slide 7

Slide 7 text

© 2025 Classmethod, Inc. Amazon Bedrock AgentCoreはRuntime、Identity、Memory、Gateway、Built-in Tools、Observabilityという6つのサービスが、それぞれ本番運用の具体的な課題を解決します。組み合わせても使用できる柔軟性を持っており、ニーズに応じた最適な構成を選択できます。 Amazon Bedrock AgentCoreの機能 7 Amazon Bedrock AgentCore Identity Gateway Built in tools Memory Runtime Identity Observability

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 2025 Classmethod, Inc. Runtimeにはエンドポイントが存在します。デプロイするたびにバージョンがインクリメントします。特に何も指定しなければエンドポイントを呼び出した時は最新バージョンの処理が呼ばれます。これがDEFAULTエンドポイントです。 Runtimeのエンドポイントについて 9 開発者ソースコード開発端末開発 AI エージェント開発 AgentCore Runtime バージョン1 バージョン2 バージョン3 デプロイインクリメント最新 DEFAULTエンドポイント：https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{E ncodedAgentARN}/invocations 紐づいている

Slide 10

Slide 10 text

© 2025 Classmethod, Inc. 名前付きエンドポイントも作成可能で、特定のバージョンを指定することが可能です。名前付きエンドポイント 10 AgentCore Runtime バージョン1 バージョン2 バージョン3 最新 DEFAULTエンドポイント：https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{E ncodedAgentARN}/invocations 紐付け prodエンドポイント：https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{E ncodedAgentARN}/invocations?qualiﬁer=prod 紐付け qualiﬁerを指定しなければ DEFAULTが呼ばれるよ！ PROD

Slide 11

Slide 11 text

© 2025 Classmethod, Inc. ここで本番稼働向けアーキテクチャを考えてみます。デフォルトのエンドポイントを使用するとインクリメントされるので、検証して然るべきタイミングでアップデートするようにします。 Runtime Endpointの活用方法 11 バージョン2 バージョン3 PRODエンドポイント DEFAULT 開発者入念にテストユーザー安定バージョンを利用テストOK！！ PRODエンドポイントをバージョン3のするぞ！！！バージョン3 PROD,DEFAULT ユーザー最新バージョンを利用 PRODをバージョン3 に紐付けおお、エージェントの返事がよくなっているぞ！！！！

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2025 Classmethod, Inc. 通常デプロイすると下記URLになりますが、リクエストを送るのにARN部分をエンコードしたり、アカウントIDが見えるの嫌ですよね。 Runtime標準のURLの課題 13 AgentCore Runtime リクエスト送信時のエンドポイント：https://bedrock-agentcore.ap-northeast-1.amazonaws.com/runtimes/arn%3Aaws%3Abedrock-agentcore%3Aap-northeast-1% 3A123456789012%3Aagent-runtime%2Fabcd1234/invocations AIエージェント私うーん・・・フロントエンドからリクエスト送る時にURLにアカウントIDが入っていたり、ARNをエンコードしないといけないの気になるな・・・カスタムドメインも使いたいな。

Slide 14

Slide 14 text

© 2025 Classmethod, Inc. AgentCore Runtimeの前段にCloudFrontをラップしてリクエストを受けることも可能です。CloudFrontをラップすることで、カスタムドメイン・WAFの利用なども可能になるのは嬉しいポイントです。 CloudFrontとの連携 14 AgentCore Runtime AIエージェントエンドポイント：https://bedrock-agentcore.ap-northeast -1.amazonaws.com/runtimes/arn%3Aaws% 3Abedrock-agentcore%3Aap-northeast-1% 3A123456789012%3Aagent-runtime%2Fab cd1234/invocations CloudFront エンドポイント：https://d1234abcd5678e.cloudfront.net/ カスタムドメインも可能 https://myagent-jinno.com （オプションで）アタッチ WAF フロントエンドリクエストリクエスト

Slide 15

Slide 15 text

© 2025 Classmethod, Inc. LambdaをAgentCoreの前段にラップしてリクエストを送ることも可能です。Lambdaは Functions URLを活用してリクエストを送れるようにします。Cognitoとの連携や独自のリクエスト・レスポンスを介したい場合はいいですよね。 Lambdaとの連携 15 AgentCore Runtime AIエージェント CloudFront Lambda フロントエンドリクエストリクエスト IAMの権限でのみ AgentCoreのリクエスト可能な状態へ Functions URL OACでCloudFront経由でのみアクセス可能に Cognito オプションで設定 WAF オプションで設定 SHA256計算 Lambda@Edge

Slide 16

Slide 16 text

© 2025 Classmethod, Inc. 直近のアップデートでAPI Gatewayがストリーミング応答に対応したので、CloudFront の代わりにAPI Gatewayをラップするのも選択肢としてあると思います。 API Gateway + Lambdaとの連携 16 AgentCore Runtime AIエージェント API Gateway Lambda フロントエンドリクエストリクエスト IAMの権限でのみ AgentCoreのリクエスト可能な状態へ実行 API Gateway経由でのみ実行可能に Cognito WAF オプションで設定

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2025 Classmethod, Inc. App RunnerやAmplifyはマネージドサービスで使い勝手もいいのですが、AIアプリケーションを作成する上で相性が悪い制約があるので注意したいです。 App RunnerやAmplifyの注意点 20 Amplify App Runner ● Next.js API routesのストリーミングが動作しない（バッファリングされる） ○ AI SDKなどをNext.js バックエンドで使用しようとすると使えなくて絶望する ● 120秒のリクエストタイムアウト ○ エージェントとのやり取りが長時間に及ぶとタイムアウトになる可能性 ● WebSocketサポートなし（roadmapで最多要望） ○ StreamlitはWebSocketを使用するためApp Runnerでホストするのは難しい

Slide 21

Slide 21 text

© 2025 Classmethod, Inc. Next.jsのバックエンドではストリーミング非対応のため、クライアント側から直接 AgentCoreに対してリクエストを送信する必要があります。 Amplifyのアーキテクチャ例 21 AgentCore Runtime AIエージェント Amplify フロントエンドユーザーリクエストリクエスト Next.jsのバックエンドではストリーミング非対応のため、クライアント側から直接 AgentCoreに対してリクエストを送信するエンドポイント：https://bedrock-agentcore.ap-northeast -1.amazonaws.com/runtimes/arn%3Aaws% 3Abedrock-agentcore%3Aap-northeast-1% 3A123456789012%3Aagent-runtime%2Fab cd1234/invocations

Slide 22

Slide 22 text

© 2025 Classmethod, Inc. Lambda関数にLambda Web Adapterを使ってNext.jsをホストするのが安上がりかつ手軽でいいと思います。下記のようなアーキテクチャです。 Lambdaのアーキテクチャ例 22 AgentCore Runtime AIエージェント CloudFront Lambda フロントエンドリクエスト Functions URL Cognito SHA256計算 Lambda@Edge ユーザーリクエスト SPAから直接呼出し JWT Bearer Token （Cognito Token使用） ServerSide（Lambda）経由 IAM認証

Slide 23

Slide 23 text

© 2025 Classmethod, Inc. 本番環境で手堅く実装したいならECS + ALBの組み合わせになるかと思います。ECS Express Modeが誕生したことによりECS + ALBの敷居が下がった印象もあります。ECS を使った最小コストはAppRunnerなどの最小コストよりは高いイメージでもありトレードオフですね。 ALB + ECSのアーキテクチャの例 23 AgentCore Runtime AIエージェントリクエスト Cognito ユーザーリクエスト ALB ECS フロントエンドリクエスト SPAから直接呼出し JWT Bearer Token （Cognito Token使用） ServerSide（Lambda）経由 IAM認証

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2025 Classmethod, Inc. Runtime には idleRuntimeSessionTimeout（アイドル時のタイムアウト）と maxLifetime（最大稼働時間）パラメータが存在し、セッションの自動終了タイミングを制御できます。 Tips:Runtime lifecycle settings 26 しばらくリクエストないから寝るか zzz・・・セッション idleRuntimeSessionTimeout アイドル状態が900秒経過お話しし続けたけど、8時間たったから寝るね・・・zzz セッション maxLifetime 8時間経過おはよう！（セッション開始）おはよう！（セッション開始）終了開始開始終了

Slide 27

Slide 27 text

© 2025 Classmethod, Inc. 公式ドキュメントにベストプラクティスの記載があるので、ぜひ設定される際は参考にすることをお勧めします。 Tips:Runtime lifecycle settings 27 まずはデフォルト値（idle: 15分、max: 8時間）で運用を開始し、実際の利用パターンを見ながら調整するのがベストプラクティスです。開発・デモ環境では短め（idle: 2-5分）に設定してコストを抑え、本番環境ではユーザー体験を優先して長め（idle: 10-15分）に設定することを推奨します。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2025 Classmethod, Inc. 既存のAPI、Lambda関数、MCP Server、各種サービスをMCP（Model Context Protocol）互換のツールに変換して、AIエージェントから簡単に呼び出せるようにしてくれるサービスです。 Amazon Bedrock AgentCore Gateway 29 Runtime Gateway Smithyモデル Lambda関数 OpenAPI仕様のAPI /mcp ツールとして呼び出し MCPに変換して実行 /MCP Toolsを中央集約的に管理 Remote MCP Server

Slide 30

Slide 30 text

© 2025 Classmethod, Inc. GatewayはMCP Server自体をホストするものではないです。あくまで既存のLambda 関数をツール化したり他のMCP Serverを中央集約的に管理するのが役目となります。 MCP Server自体をホストしたいならRuntimeを使うことになるかと思います。 Gatewayの役割について 30 Gateway MCP Server ✖ Runtime MCP Server Gateway AIエージェント /mcp Runtime MCP Server MCP Server Lambda関数 RuntimeにMCP Server をホスト Gatewayで中央集約

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© 2025 Classmethod, Inc. 下記のようにAgentCore Runtimeからツール利用する場合を比較してみます。左のようにそのままツール利用もできるので一見Gatewayを挟むことで複雑な気がします。 Gateway有無の比較 32 AgentCore Runtime Lambda関数 Remote MCP Server ツール利用ツール利用 AgentCore Runtime Gateway Lambda関数 Remote MCP Server ツール情報取得ツール利用 Gatewayを使わない場合 Gatewayを使う場合

Slide 33

Slide 33 text

© 2025 Classmethod, Inc. ですがこれが100個以上ツールがある場合はどうでしょうか・・・？？？毎回MCPツールの定義を書くコードを書いたり、はたまた適切なツールを連携できるのでしょうか？ Gatewayを使わない場合 33 AIエージェント Lambda関数 Remote MCP Server ツール利用 Gatewayを使わない場合たくさんのツール私 AIエージェントの処理コードに毎回、新しいツールのコードを書くのか・・・またこんな連携して適切なツールを選択できるのかしら？？どのツールが正しいんだ？？

Slide 34

Slide 34 text

© 2025 Classmethod, Inc. この疑問に対してAgentCore Gatewayが役立ちます。Gateway側に登録することで、 AIエージェント自体の処理は毎回変えずにツールの情報を同期取ることが可能かつ、適切なツールを探すのにはSemantic Search機能が使えます。 Gatewayを使う場合 34 Gateway Lambda関数 Remote MCP Server ツール情報取得ツール利用 Gatewayを使う場合たくさんのツール AIエージェント with Semantic Search Gatewayに登録されたツール情報同期できる Semantic Searchで適切なツールを見つけることができる

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2025 Classmethod, Inc. MCP Serverがツールとして大量に使える状態にあるとコンテキストを圧迫および不適切なツールを使用する可能性があります。そういった時にSemantic Search機能を使って適切なツールを見つけてAIエージェントに使わせましょう。 Semantic Search 36 引⽤：https://catalog.us-east-1.prod.workshops.aws/workshops/015a2de4-9522-4532-b2eb-639280dc31d8/en-US/30-agentcore-gateway/34-gateway-search-tools

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2025 Classmethod, Inc. Strands Agentsで実装する場合はcall_tool_syncで検索しつつ、適切なツールをAIエージェントと同期することが可能です。 Semantic Searchを活用してツール同期をする 38 AIエージェント Gateway ユーザー XXXをやって Gatewayに紐づいたツール情報を検索して取得たくさんのツールターゲット XXXに関連するツール探すで

Slide 39

Slide 39 text

© 2025 Classmethod, Inc. Semantic Searchを使用することでコンテキスト汚染を回避することにつながります。 ANTHROPICの記事もMCP Serverをツールとして登録しすぎると、ツールの定義や結果に過剰なトークンが消費され、エージェントの効率が低下する可能性があるといっています。 Appendix:MCP Serverをツールとして過剰に登録することによるコンテキストの汚染 39 Code execution with MCP: Building more efficient agentsより引用：https://www.anthropic.com/engineering/code-execution-with-mc p

Slide 40

Slide 40 text

© 2025 Classmethod, Inc. これは人間でも同じことが言えると思います。いきなり、新しい職場に行って全ての情報を詰め込まれても適切な行動はできず自分がやりたいことに対してアドバイスしてくれる人が欲しいですよね。AIエージェントも同じで、最適に実行できるようSemantic Searchで適切なツールを教えてあげるイメージを持つとわかりやすいです。 Appendix：現実での例 40 私 SaaS Slack Google Workspace XXXをしたいけど何を使ったらいいんだ？？？私 SaaS Slack GoogleWorkspace XXXをしたいけど何を使ったらいいんですか？？先輩 XXXならこのSaaSツールを使ったらいいよ。 ※ざっくりとした例えです、例えは正確ではない箇所もあります

Slide 41

Slide 41 text

© 2025 Classmethod, Inc. 組織に既存のLambda関数やMCP Serverがたくさんあって、組み合わせる場合は Gatewayに軍配が上がる気がします。あくまでオプションの選択肢で上記以外の用途なら無理に使う必要はない気もします。シンプルにLambda関数やRuntimeにMCP Servre をホストして使う方が早いと思います。 Gatewayの使い所所感 41 MCP Serverを新規でホストしたい。多くの数を展開する訳ではない。サクッと展開したいユーザー Runtime MCP Server MCP Server Lambda Gatewayを使用しないケース Gatewayを使用するケース接続するMCP Serverは既存のLambda関数を多数活用するし、MCP Serverは中央集約したいユーザー Gateway たくさんのツール RuntimeやLambdaなどにホスティング Gatewayで中央集約

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 2025 Classmethod, Inc. Runtime、Gatewayを介してMCP ServerをホストするにしてもVSCodeやCursorなどのエディターだとDCRのような動的なトークン認証が難しく、Barer Tokenを取得せざるを得ません。MCPの拡張で認証できるようになることを期待したいですね。 Appendix:エディタなどのMCP Clinetによるトークン認証の課題 43 ユーザー MCP Client Cognito アクセストークン取得アクセストークンを記載してMCP Serverを設定 Runtime アクセストークンを検証リクエスト with アクセストークン現状理想（まだ実現できません） ※大半のクライアントではユーザー MCP Client Cognito アクセストークン取得 MCP Serverを設定 Runtime アクセストークンを検証リクエストブラウザにリダイレクトしてアクセストークンを取得 ※わかりやすさのため簡易的に書いていて、正確なフローとしては表現しきれていませんトークン発行は面倒だな

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© 2025 Classmethod, Inc. AIエージェントに「記憶」を持たせることで、より賢く、よりパーソナライズされた対応が可能になります。AgentCore Memory機能は、短期記憶（会話履歴）と長期記憶（重要な情報の抽出）の両方をマネージドで提供します。開発者は複雑な記憶管理の実装に悩むことなく、エージェントに学習能力と文脈理解能力を付与できます。 Amazon Bedrock AgentCore Memory 45 Amazon Bedrock AgentCore ユーザー Strands Agents Bedrock LLM エージェントに質問 AIエージェント Bedrockを使用 Memory ● 会話履歴 ● サマリー ● 客観的事実

Slide 46

Slide 46 text

© 2025 Classmethod, Inc. 前提としてMemoryのデータ構造をおさえます。ユーザー毎にactor_id、セッション毎にsession_idがビルトインの属性で存在するので簡単にユーザー毎の会話履歴を保持可能となります。記憶のデータ構造 46 memory_id:memory-001 actor_id:user-001 session_001 Q:xxxについて教えて A:YYY actor_id:user-002 session_002 Q:zzzについて教えて A:TTT session_001 Q:DDDについて教えて A:EEE session_002 Q:FFFについて教えて A:XXX

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© 2025 Classmethod, Inc. それぞれのユーザーに対する記憶の取り出し方法 48 ユーザーの質問はactor_idでどのユーザーか識別されるので、リクエストでユーザーを識別する値を入れて、AIエージェント側でその値をactor_idとみなす形になるかと思います。 Amazon Bedrock AgentCore ユーザーA Strands Agents AIエージェント Memory ユーザーB ユーザーAの記憶 actor_id=user_ aで保存ユーザーBの記憶 actor_id=user_ aで保存質問質問ユーザーに応じた記憶を参照ユーザーがわかる識別子（ID など）をリクエストに含めるリクエストの値からactor_idとして各ユーザごとの記憶を取得する

Slide 49

Slide 49 text

© 2025 Classmethod, Inc. actor_idをJWTのsubクレームと紐付け 49 JWTをデコードしてactor_idに、デコードしたユーザー識別子をactor_idに入れて設定することも可能です。ユーザーごとのMemoryはIdentityと連携してこのように分離することが可能です。 Amazon Bedrock AgentCore ユーザーA Strands Agents AIエージェント Memory ユーザーB ユーザーAの記憶 actor_id = abc123-456-789 Cognito アクセストークンリクエスト with アクセストークン & IDトークン JWTをデコードしてユーザー情報を取得デコードしたユーザー情報に応じたユーザー情報を参照 sub: "abc123-456-789" email: "[email protected]" name: "Yamada Taro" actor_id = "abc123-456-789" として抽出して参照ユーザーBの記憶 actor_id = def123-456-789

Slide 50

Slide 50 text

© 2025 Classmethod, Inc. IAMでの制御 50 Memoryの権限制御ですがアプリケーションだけではなく、インフラ側でも制御可能です。アプリケーションの設定ミスなどによる他者の記憶アクセスを回避することが可能です。JWTのIDTokenを活用して、Strands Agentsの処理で動的にIAMの権限を取得して権限分離を実現できます。 sub: "abc123-456-789" email: "[email protected]" name: "Yamada Taro" JWTの中身が上記とすると、 actorIdが abc123-456-789の記憶しかアクセスできない権限に

Slide 51

Slide 51 text

© 2025 Classmethod, Inc. IAMでの制御イメージ 51 ユーザーAさんが保持している権限ではユーザーBさんの記憶にアクセスできません。アプリケーション側で誤ってユーザーBの記憶にアクセスしようとしてもIAMの権限で拒否されます。ユーザーA ユーザーB Memory ユーザーAの記憶 actorId=abc123 -456-789 ユーザーBの記憶 actorId=def123 -456-789 sub:abc123-456-789 sub:def123-456-789 誤ってアクセスアクセス不可 Memoryのアクセス権限は自分のsubクレームと同名のactorIdしかアクセスできない条件を指定しているため "bedrock-agentcore:actorId": "${cognito-identity.amazonaws.com:sub}

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© 2025 Classmethod, Inc. 今デプロイするやり方だと下記方法などがあるかと思います。Starter Toolkit、コンソール上から実施、IaC（CDK、Terraform、CloudFormation）などありますがそれぞれの立ち位置はどうでしょうか。 IaC/デプロイ手法 53 CDK Terraform CloudFormation IaCツール Starter Toolkit AWSコンソール /CLI conﬁgure/ launch/ invoke コマンド実行

Slide 54

Slide 54 text

© 2025 Classmethod, Inc. IaCでのデプロイ 54 IaCも対応しています。インフラ環境としてAgentCoreを使用する場合は、ぜひIaCでの管理も検討ください。Terraform、CDK、CloudFormationが対応しています。一部対応しきれていないものもございます。 AgentCore CDK Terraform CloudFormation IaCツール実装デプロイ

Slide 55

Slide 55 text

Slide 56

Slide 56 text

© 2025 Classmethod, Inc. Zipアップロードは250MB以下のパッケージをZIP形式で素早くデプロイでき、更新も高速です。一方、コンテナベースは1GBまでの大規模パッケージや特殊な依存関係に対応し、既存のCI/CDパイプラインも活用できます。開発フェーズでは直接コードで素早くプロトタイピングし、本番環境ではコンテナへ移行するハイブリッドアプローチも有効です。直接ファイルアップロードかコンテナイメージか 56 直接アップロードコンテナイメージ AgentCore zip化してアップロード ● 250MBまでのパッケージに対応 ● 更新も高速 AgentCore ビルドしてイメージをアップロード ECR PULL ● 1GBまでの大規模パッケージや依存関係に対応