2025年 Amazon Bedrock AgentCoreまとめ

by Yudai Jinno

Slide 1

Slide 1 text

2025年 Amazon Bedrock AgentCoreまとめ Hello！神野雄大（Jinno Yudai/@yjinn448208）

Slide 2

Slide 2 text

改訂履歴 2 更新の履歴を記載しております。本資料は継続アップデートを前提としております。バージョン更新日付更新内容 1.0.0 2025/12/31 初版 1.0.1 2026/1/1 Runtime（HTTP）の要件および、Amazon Bedrock AgentCore SDKのデコレータによる簡略化のメリットを説明したスライドを追加 1.0.2 2026/1/11 Identityの説明を強化 1.03 2026/1/18 GatewayのIAM認証の例を追加、Gateway Policy:Semantic Search の場合の挙動を追加

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

対象と目的 4 本資料はAmazon Bedrock AgentCoreを知ってもらうために幅広く知識を詰め込んだ資料になります。一部難しい箇所はスキップいただいても構いません。少しでも AgentCoreでAIエージェントを作りたいと思っていただけたら幸いです！対象対象と目的 ● Amazon Bedrock AgentCoreをもっと知りたいと思っている方目的 ● Amazon Bedrock AgentCoreの全体像をふんわりと理解してもらう ● Amazon Bedrock AgentCoreでAIエージェントを作りたい！と思っていただく！！

Slide 5

Slide 5 text

謝り 5 残念ながら本資料で全て説明できているわけではございません。より詳細に知りたいと思った方は、手前味噌で恐縮ですが私のブログから関連するトピックを読んでいただくと理解が深まると思います。時間の兼ね合いでスキップしている箇所もあるので、また本資料は継続的にアップデートしていきます！！！（あくまでベストエフォートですが・・・）ブログ：https://dev.classmethod.jp/author/yjinn/ アップデート予定！！！

Slide 6

Slide 6 text

6 皆さん10月に一般公開（GA）されたAmazon Bedrock AgentCoreを使っていますか？？ Agent君

Slide 7

Slide 7 text

7 勿体無い！！AIエージェントを作る上で魅力的な機能がいっぱいあるから今から機能説明するよ！！！ Agent君え、触っていないよ・・・機能も多いしなんだか難しそう。私

Slide 8

Slide 8 text

8 まずはAmazon Bedrock AgentCoreの概要から説明しますね！ Agent君

Slide 9

Slide 9 text

Amazon Bedrock AgentCoreについて 9

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Amazon Bedrock AgentCoreはデプロイするためのRuntime機能をベースに認証機能 IdentityなどAIエージェントを開発する上で便利な機能が備わっています。 Amazon Bedrock AgentCoreが持つ機能群 11 ● Runtime：AIエージェントの実行環境 ● Identity：認証機能 ● Gateway：MCPツールの集約機能、外部サービスのMCPツール化機能 ● Memory：記憶機能 ● Observability：AIエージェントの挙動を可視化 ● Evaluations：AIエージェントの評価機能（Preview） ● Built in tools ○ Code Interpreter：コード実行環境 ○ Browser：ブラウザ実行環境

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

13 AIエージェントって言葉はよく聞くけど、何を意味しているか迷うポイントですよね。今から簡単に説明しますね！　 Agent君便利そう・・・！！ただそもそもAIエージェントって何？？私

Slide 14

Slide 14 text

LLM、RAG、ツール利用とAIの利用は進歩してきましたが、AIエージェントはさらに一歩進んだ存在です。単にツールを使うだけでなく、タスクをこなすための計画を立て、実行し、評価し、自己管理することができます。 Appendix:AIエージェント 14 ユーザーエージェント韓国旅行の予約をお願いわかりました！まずは計画から考えて実行します！検索ツールで航空券・ホテル情報を収集カレンダーツールで予定の空き状況を確認予約システムAPIで航空券・宿泊を確保メールツールで予約確認書を送信実行計画

Slide 15

Slide 15 text

AIエージェントとは、自律的に判断・行動できるAIシステムのことです。ユーザーの指示を理解し、必要なツールを自身で計画を立てて使いながらタスクを実行します。まさに人間の代理として計画的に作業を行うからエージェントなんですね。 Appendix:AIエージェントのイメージ 15 私旅行会社の人今まで AIエージェントを活用した結果私 AIエージェント調査ツールツール実行 1/1に韓国旅行にいきたい 1/1の13時のフライトはいかがですか？ 1/1に韓国旅行にいきたい（自分でツール選択&調査した結果） 1/1の13時のフライトはどうですか？

Slide 16

Slide 16 text

AIエージェントを特徴づける2つの中核的な特性が、自律性と知性です。自律性により、エージェントは人間の指示を待たずに目標に向かって自ら動き続けることを可能にし、知性により、複雑な状況を理解し、推論し、最適な判断を下すことを可能とします。 Appendix:AIエージェントが持つ特性 16 ⾃律性 Success！⾃分⼀⼈で最後までやり遂げる！知性 xxxについて教えて資料によると yyyですこの質問なら、この資料を読んで判断して返事するか必要に応じて外部環境を活用参照

Slide 17

Slide 17 text

よく使われているClaude Codeも、まさにAIエージェントの一種です。ファイルを読み込み、コードを生成・修正し、テストを実行し、エラーを自己修正する...これらはまさにエージェントの自律性と知性の表れです。 Appendix:AIエージェントが持つ特性 17 AIエージェント Claude Code コーディングエージェント

Slide 18

Slide 18 text

18 それならRuntimeだね。まずはAIエージェントの実行環境について説明するよ。 Agent君なるほど！AIエージェントについて理解できたよ！まずはAgentCoreのコア機能から教えて！私

Slide 19

Slide 19 text

Amazon Bedrock AgentCore Runtime 19

Slide 20

Slide 20 text

Runtime機能は、AIエージェントを実行するための「身体」（LLMが「脳」）として機能します。サーバーレスで自動スケールし、ユーザーセッションごとに専用のマイクロ VMを提供することでセキュアな実行環境を実現します。 Amazon Bedrock AgentCore Runtime 20 AgentCore Runtime ユーザー Strands Agents Bedrock LLM エージェントに質問 AIエージェント Bedrockを使用

Slide 21

Slide 21 text

AgentCore Runtimeの強みは柔軟性にあります。後述の要件を満たせば、Strands Agents、LangGraph、Mastraなど、どんなエージェントフレームワークでも選択でき、LLMもBedrock、OpenAI、Geminiなど自由に組み合わせられます。 Amazon Bedrock AgentCore Runtimeの柔軟性 21 AgentCore Runtime ユーザー Mastra Azure OpenAI LLM エージェントに質問 AIエージェント Azure OpenAI を使用

Slide 22

Slide 22 text

HTTP プロトコルの場合、下記エンドポイントの要件を満たす必要があるのでAmazon Bedrock AgentCore SDKを使わずに実装する場合は注意したいですね。使用したいプロトコルがA2A・MCPの場合は別途要件があります。 Runtime（HTTP）の要件 22 Runtime 項目要件備考ホスト 0.0.0.0 ポート 8080 固定必須エンドポイント POST /invocations 処理のエントリーポイント必須エンドポイント GET /ping ヘルスチェック用オプションエンドポイント /ws - WebSocket 双方向ストリーミングしたい場合のみプラットフォーム ARM64 ARM64のみ対応 Runtime（HTTP）の要件参考：https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-http-protocol-contract.html

Slide 23

Slide 23 text

Amazon Bedrock AgentCore SDKを使えば、Runtimeで起動するAIエージェントの実装が簡単に可能です。処理のエントリーポイントをデコレーターで指定すれば自動的に Runtimeに必要なエンドポイントを実装してくれます。 Amazon Bedrock AgentCore SDKを活用した実装 23 デコレーターでエントリーポイントを指定することで自動的にポート8080、/invocationsエンドポイントとして処理が呼び出される /pingエンドポイントなども自前で実装不要

Slide 24

Slide 24 text

24 その通り！とってもシンプルに実装できるフレームワークなので AgentCoreからは少し脱線するけど大事だから説明しますね！ Agent君あれ、Strands Agentsって何？AIエージェントを実装するようなフレームワークなのかな？私

Slide 25

Slide 25 text

Strands Agentsは、AWSが提供するオープンソースSDKで、AIエージェントの構築をシンプルにします。開発者は複雑なワークフローを複雑なコードで実装する必要がなく、目標とツールを定義するだけでエージェントが構築できます。 Strands Agents 25 Strands Agents たった3行で実行できる

Slide 26

Slide 26 text

TypeScript版もPython版同様にシンプルに書けるのが特徴です。AgentCoreのデプロイも公式ドキュメントに記載があるので展開可能です。ただ現時点ではPython版と比べると使用できない機能もあるので注意です。（今後同期予定） Strands Agents（TypeScript版） 26 変わらずたった3行で実行できる

Slide 27

Slide 27 text

Strands Agentsは生成AIがタスクを達成するために実行計画を立て適切なツールを使うための仕組みであるエージェンティックループ（Agentic Loop）が存在します。LLMの実行、ツールの選択、ツールの実行結果を返却といったループを簡単に実装可能です。 Agentic Loop 27 Strands Agents AIエージェントユーザータスクを依頼 Bedrock LLM 指示を入力 Tool MCP Server 状況に応じてツール利用失敗してもタスクが成功するまで自動で反復して実行可能 Agentic Loop

Slide 28

Slide 28 text

ツール実行も下記のようなシンプルな実装で自動的に使われますツール実装のイメージ 28 ツールを定義して呼び出すだけで機能

Slide 29

Slide 29 text

データ分析ツールツールもエージェント化することも可能です。Agent As Toolsと呼ばれます。エージェント同士で協調して、自律的に判断したい時に便利です。 Agent As Tools 29 Strands Agents メインエージェントデータ分析エージェントレポート作成エージェントレポート作成ツールこのデータを分析して情報をわかりやすくまとめて

Slide 30

Slide 30 text

30 AgentCoreへのデプロイも簡単なので説明していきますね！ Agent君シンプルにAIエージェントを実装できて良いね！！早速処理を書いたからAgentCoreにデプロイしたい！！！私

Slide 31

Slide 31 text

デプロイはシンプルです。Starter Toolkitを使用すると3つのコマンド（configure、 launch、invoke）だけで、AWS環境へのデプロイが完了および利用できます。まずはAgentCoreの設定をするconfigureコマンドから確認します。 Starter Toolkit configure コマンド 31 agentcore configure Dockerfile .bedrock_ agentcore.yaml ● デプロイ方法の選択（Zipかコンテナイメージ） ○ 推奨はZipアップロード（直接デプロイ） ● IAMロールの設定（自動作成も可能） ● コンテナの場合はECRの設定、Zipの場合はS3バケットの指定（自動作成も可能） ● Zipの場合はPythonバージョンの指定、requirements.txt などのパッケージ管理ファイルの指定 ● 認証の設定（デフォルトはIAM） ● メモリーの設定（オプション） .dockerignore コンテナだった場合

Slide 32

Slide 32 text

シンプルな実装イメージ 32 シンプルなコードを書いてデプロイ手順を進めていきます。デコレーターでエントリーポイントを指定することで自動的に/invocationsエンドポイントとして処理が呼び出される

Slide 33

Slide 33 text

configureコマンドは対話で設定が可能で、エントリーポイントに処理を書いたコードを指定して、設定を進めると定義ファイルが作成されます。 Starter Toolkit configure コマンド 33 対話形式で設定可能 .bedrock_ agentcore.yaml デプロイ方法、依存関係、使用するIAMロールの ARNやS3バケットのARNなどを設定します。特に指定しなければ自動で作成されます。 Dockerfile コンテナの場合作成される .dockerignore

Slide 34

Slide 34 text

Starter Toolkit create コマンド 34 直近のアップデートでconﬁgureコマンドの代わりにcreateコマンドも使用可能となりました。ゼロからAIエージェントのテンプレートを使ってセットアップが対話型で可能になります。ゼロからサクッと動くものを作りたい際はこのコマンドの方がお手軽かもしれませんね。 .bedrock_ agentcore.yaml ソースコード一式 .bedrock_ agentcore.yaml ソースコード一式 IaCのコード一式 Starter Toolkitによるデプロイ方法を選択 IaCによるデプロイ方法を選択 CDKかTerraformを選択可能

Slide 35

Slide 35 text

Starter Toolkit dev コマンド 35 デプロイする前にagentcore devコマンドを実行するとローカル環境でサーバーを建てられます。テストや動作確認をするのに良いですね。ユーザー Strands Agents Bedrock LLM エージェントに質問 AIエージェント Bedrockを使用 agentcore invoke —dev ローカル環境（agentcore devで起動）

Slide 36

Slide 36 text

Starter Toolkit launch（deploy）コマンド 36 conﬁgureコマンド実行後はagentcore launchでデプロイ可能です。最近名称が変わって deployコマンドでもデプロイ可能です。deployコマンドとlaunchコマンドで実現できる機能は同じです。 AgentCore Runtime Strands Agents agentcore launch デプロイ AIエージェント

Slide 37

Slide 37 text

デプロイ実施 37 launchコマンドを実行してデプロイが完了します。 deployコマンドでもデプロイ可能

Slide 38

Slide 38 text

デプロイで実行される流れ（Zipアップロードによる直接デプロイ） 38 Zipアップロードによる直接デプロイはコンソールからも同じようにできますが、コマンド上でやるのが依存関係のパッケージなどを読み解いて、自動でS3にアップロードしてくれるので便利です。 .bedrock_ agentcore.yaml agentcore launch実行時ファイル参照依存関係を自動でパッケージングして ZipでS3にアップロードソースコード AgentCore Runtime requirements.txt S3 ダウンロードして使用 S3バケットも自動作成可能

Slide 39

Slide 39 text

デプロイで実行される流れ（コンテナ版） 39 コンテナの場合はlaunchコマンドを実行することで裏でコンテナのビルド走り、ECRへイメージがプッシュされます。このイメージをAgentCore RuntimeがPullして使用します。 agentcore launch実行時 Dockerﬁle .bedrock_ agentcore.yaml ファイル参照イメージビルド実行イメージPush AgentCore Runtime ECR イメージPull .dockerignore ソースコード CodeBuild ビルド環境やECRも自動作成可能

Slide 40

Slide 40 text

AgentCore Runtime Starter Toolkit invokeコマンド 40 デプロイしたエージェントはagentcore invokeコマンドで簡単に呼び出せます。 SDKや curlなどでももちろん呼び出し可能です。ユーザー Strands Agents Bedrock LLM エージェントに質問 AIエージェント Bedrockを使用 agentcore invoke

Slide 41

Slide 41 text

Starter Toolkit invokeコマンド 41 invokeコマンドを実行して呼び出すと下記のように動作確認ができます。

Slide 42

Slide 42 text

ストリーミングレスポンスも可能 42 ストリーミングで返信すること可能です。下記実装に変更してデプロイを実施して、呼び出してみます。ストリーミング処理に変更

Slide 43

Slide 43 text

ストリーミングレスポンスも可能 43 呼び出してみるとストリーミングでレスポンスが返却されることを確認できます。 ● チャンク単位でストリーミングで返信

Slide 44

Slide 44 text

44 いくつかあるので、Runtimeでポイントになりそうなところをピックアップして紹介しますね！ Agent君本当にあっという間にデプロイできた・・・AgentCore Runtime便利ですね・・・細かく意識しておかないといけないポイントはあるの？？私

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

公式ドキュメントに直接アップロードかコンテナイメージかなどの比較情報などあるので見ておくと参考になると思います。 Zipファイルによる直接デプロイかコンテナイメージか 46 引用：https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runti me-get-started-code-deploy.html#runtime-code-deploy-concepts

Slide 47

Slide 47 text

IaCでのデプロイ 47 IaCも対応しています。インフラ環境としてAgentCoreを使用する場合は、ぜひIaCでの管理も検討ください。Terraform、CDK、CloudFormationが対応しています。 Starter Toolkitは便利ですが本番環境を運用するとなるとIaCの方が管理に向いていると思います。 Runtime CDK Terraform CloudFormation IaCツール実装デプロイ

Slide 48

Slide 48 text

Appendix:L2 Constructの実装イメージ 48 StarterToolkitと似たような実装で実現できます。使い勝手が良くて個人的に使用しています。

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

名前付きエンドポイントも作成可能で、特定のバージョンを指定することが可能です。名前付きエンドポイント 50 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 51

Slide 51 text

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

Slide 52

Slide 52 text

現時点で対応しているプロトコルはHTTPS、MCP、A2Aとなります。例えばMCP ServerをAgentCoreにホストして、ローカルのMCP Clientなどから使用することも可能です。 Runtime の対応プロトコル 52 MCPクライアント（ex.Claude Code）リクエスト with アクセストークン AgentCore Runtime IdP (ex.Cognito) MCP Server アクセストークン取得

Slide 53

Slide 53 text

MCP Proxy for AWSを使えばIAM認証を活用して、ローカルのAWS認証情報を使ってアクセスすることも可能です。 MCP Proxy for AWS 53 MCPクライアント（ex.Claude Code）リクエスト with IAM Sig V4認証 AgentCore Runtime MCP Server MCP Proxy for AWS ローカルの AWS 認証情報を使用して MCP 通信を SigV4 で署名

Slide 54

Slide 54 text

実際にMCP Proxy for AWSを活用した記事もDevIOに記載があるので、ぜひご参照ください。 MCP Proxy for AWS 54 https://dev.classmethod.jp/articles/agentcore-mcp-iam-auth-ai-coding-tools/

Slide 55

Slide 55 text

WebSocketにも対応しているため、双方向ストリーミングにも対応しています。そのため、リアルタイムでの音声のやり取りのような会話の割り込みも可能になります。双方向ストリーミングも可能 55 AIエージェントユーザー AgentCore Runtime XXXを実行してお願い！！！ XXXを実行しますね。以下を初期化中です・・・（結果をまたずに）あ、やっぱりYYYをすぐやって。了解です！！XXXをやめて、 YYYをすぐに実行しますね。双方向で会話が可能なため、結果を待たずに割り込み可能にエンドポイント：wss://bedrock-agentcore..amazon aws.com/runtimes//ws

Slide 56

Slide 56 text

SDKのデコレータを使用することでWebSocket用のエンドポイントを作成してくれます。サクッと実装するには便利ですね。双方向ストリーミングも可能 56 ● デコレータを使用することで、 8080番ポート、/wsエンドポイントでの待ち受けを可能に

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

59 それならIdentityですね！！認証はAIエージェントをホストする上でとっても大事ですから丁寧に説明します！ Agent君おおお、盛りだくさんでした・・・！奥が深いですね・・！次の機能を知りたいです！認証はとっても大事なので気になっています！！私

Slide 60

Slide 60 text

Amazon Bedrock AgentCore Identity 60

Slide 61

Slide 61 text

Amazon Bedrock AgentCore IdentityはAIエージェントの認証・認可機能を実現するマネージドサービスです。Inbound Auth / Outbound Authの2つ種類が存在します。 Amazon Bedrock AgentCore Identity 61 Inbound Auth Outbound Auth Runtime Identity IdP (ex.Cognito) リクエスト with アクセストークントークン検証 Runtime Identity Secrets Manager IdP(ex.Cognito) リクエスト可能 API KeyやSecret取得トークン取得( M2M) 外部サービス利用時

Slide 62

Slide 62 text

Inbound AuthはRuntimeやGatewayに対する認証機能です。IAM認証はもちろんのこと、CognitoやAuth0などのIdPと連携したJWT認証も実現可能です。Gatewayは加えて認証なしのオプションも選択可能です。（Runtimeは認証なしは不可） Inbound Auth 62 IdP (ex.Cognito) アクセストークン取得 Runtime Identity トークンが有効な場合、呼び出し可能リクエスト with アクセストークンアクセストークンを検証 JWT IAM Runtime Identity 権限が適切な場合、呼び出し可能リクエスト with IAM Sig V4認証

Slide 63

Slide 63 text

Outbound AuthはAIエージェントが外部サービスを呼び出すための認可機能です。 API キーやSecret認証情報をSecrets Managerで安全に管理し、自動で取得します。下記は APIキーの例です。 Outbound Auth（API Key） 63 Runtime リクエスト Identity Secrets Manager Azure OpenAIへリクエスト API Keyを取得 Azure OpenAI リクエスト with API Key

Slide 64

Slide 64 text

SDKで提供されているデコレーターを使って簡単にAPI Keyを取得可能です。こみ入った処理を自前で実装しなくていいのはありがたいですね。 Outbound Auth（API Key） 64

Slide 65

Slide 65 text

Outbound AuthでMachine to Machine（M2M）の場合は下記フローで外部サービスを利用するための認証・認可が実施されます。例えばRuntime→Gatewayを例にみてみます。 Outbound Auth（M2M） 65 Runtime Identity Gateway IdP(ex.Cognito) リクエストリクエスト with Secret Secrets Manager 取得したSecretを使って Gatewayアクセス⽤のアクセストークンを取得 IdPのSecretを取得リクエスト with Gateway⽤アクセストークン

Slide 66

Slide 66 text

こちらもデコレーターを使って簡単に短命トークンを自動で取得可能です。込み入った処理を自前で実装しなくていいのはありがたいです。 Outbound Auth（M2M） 66

Slide 67

Slide 67 text

最初のAgentCore Identityしようと書いてあるフローがデコレーターの実装でいい感じに自動化されます。嬉しいですね。 Outbound Auth（M2M） 67 デコレーターでこのプロセスが簡略化

Slide 68

Slide 68 text

もちろんInbound AuthとOutbound Authは併用可能です。下記はエージェントは Inbound AuthでCognitoを使用し、Gateway経由でツール（Lambda関数）を使用するためにOutbound Authで短命のアクセストークンを別途取得して実行を可能にします。 Inbound AuthとOutbound Authの組み合わせ 68 Runtime Identity Gateway IdP(ex.Cognito) アクセストークン取得リクエストリクエスト with Secret Secrets Manager 取得したSecretを使って Gatewayアクセス⽤のアクセストークンを取得 IdPのSecretを取得リクエスト with Gateway⽤アクセストークン IdP(ex.Cognito) リクエスト with アクセストークン Lambda関数ターゲットを実⾏ Inbound Auth Outbound Auth Identity トークンの検証起動

Slide 69

Slide 69 text

ちなみに前ページの構成ならGatewayはIAM認証も可能なので、M2Mを使用するかは要件に応じて検討しましょう。シンプルに1エージェントかつ1GatewayならIAM認証がシンプルかもしれませんね。補足：GatewayのIAM認証 69 Runtime Gateway アクセストークン取得 IdP(ex.Cognito) リクエスト with アクセストークン Lambda関数ターゲットを実⾏ Inbound Auth Identity トークンの検証起動リクエスト with IAM Sig V4認証 MCP Proxy for AWS を使って簡単に実現可能

Slide 70

Slide 70 text

Runtimeは IAM または JWT 認証が必須です。Gatewayは加えて認証なしも選択可能ですが、本番公開する場合はセキュリティに要注意です。注意点は公式ドキュメントを参照しましょう。 Appendix:Inbound Authの認証方式 70 認証方式 Runtime Gateway 備考 IAM（SigV4） ⚪ ⚪ JWT ⚪ ⚪ Cognito、Auto0など認証なし ✖ ⚪ 公開にあたって公式ドキュメントの注意を参照した方が良い Inbound Authの認証方式

Slide 71

Slide 71 text

Runtime上のエージェントは AgentCore Identity 経由で OAuth トークン / API Key を取得し、外部サービスへ安全にアクセス可能とします。下記はその認証・認可方式の一覧です。今回は説明していませんが、M2Mに加えてユーザー委任型も実現できます。 Appendix:Outbound Authの認証・認可方式（Runtime） 71 認証方式対応備考 OAuth (Client Credentials) ⚪ M2M OAuth (Authorization Code) ⚪ ユーザー委任 API Key ⚪ Outbound Authの認可方式（Runtime）ユーザー委任認証の例：https://docs.aws.amazon.com/ja_jp/bedrock-agentcore/latest/devguide/identity-getting-started-google.html

Slide 72

Slide 72 text

Gatewayはターゲットタイプに応じて認証・認可方式が異なるので注意しましょう。 Lambda は IAM のみ、MCP server は OAuth (Client Credentials) または認証なしのみなど特徴があります。OpenAPIがターゲットならユーザー委任型も対応しています。 Appendix:Outbound Authの認証・認可方式（Gateway） 72 ターゲット IAM OAuth (Client Credentials) OAuth (Authorization Code) API Key 認証なし API Gateway ⚪ ✖ ✖ ⚪ ✖ Lambda ⚪ ✖ ✖ ✖ ✖ MCP server ✖ ⚪ ✖ ✖ ⚪ OpenAPI ✖ ⚪ ⚪ ⚪ ✖ Smithy ⚪ ⚪ ⚪ ✖ ✖ Outbound Authの認可方式（Gateway）参考：https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html

Slide 73

Slide 73 text

73 AgentCore Memoryで会話などの記憶情報を持たせることができます！今からご紹介しますね！！ Agent君 Identity使いこなして各種サービスと連携しつつ、セキュアなAIエージェントにしたいですね！Runtimeを実装しているけど、どのデータベースに記憶を持たせるのがいいのかな？DynamoDB？私

Slide 74

Slide 74 text

Amazon Bedrock AgentCore Memory 74

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

Memoryは大きく分けて短期記憶と長期記憶の2種類の記憶を管理できます。短期記憶と長期記憶 76 短期記憶 ● セッション中の会話履歴を保持 ● 最大365日まで保存可能 ● リアルタイムでアクセス可能長期記憶 ● 短期記憶から自動的に戦略に基づく情報を抽出しベクトルで保存 ● 抽出するための4つのビルトイン戦略およびカスタムの戦略を設定可能 ● ビルトインの戦略は4つ提供されている ○ Semantic Memory Strategy ■ 知識や事実を保存 ○ UserPreference Strategy ■ ユーザーの好みや傾向を保存 ○ Summary Memory Strategy ■ 会話のサマリーを保存 ○ Episodic Memory Strategy ■ やり取りから教訓を保存自動抽出

Slide 77

Slide 77 text

短期記憶はユーザー毎にactor_id、セッション毎にsession_idがビルトインの属性で存在するので簡単にユーザー毎の会話履歴を保持可能となります。記憶構造のイメージ 77 memory_id:memory-001 actor_id:user-001 session_id:sess ion_001 Q:xxxについて教えて A:YYY actor_id:user-002 session_id:sess ion_002 Q:zzzについて教えて A:TTT session_id:sess ion_001 Q:DDDについて教えて A:EEE session_id:sess ion_002 Q:FFFについて教えて A:XXX

Slide 78

Slide 78 text

短期記憶の単位はChatGPTやCluadeなどの会話履歴タブがイメージしやすいです。記憶構造のイメージ 78 actor_id：ユーザーの識別の単位 session_id：一連の会話履歴の単位

Slide 79

Slide 79 text

長期記憶は、短期記憶から自動的に重要な情報を抽出・統合する機能です。抽出されたインサイトはベクトルデータとして保存され、セマンティック検索により関連性の高い記憶を効率的に取得できます。短期記憶から長期記憶への抽出イメージ 79 AIエージェント短期記憶りんごについて教えて大好きなんです。質問履歴を記録長期記憶自動的にベクトル化して抽出 AIエージェント私の好みを教えて UserPreference Memory Strategyを設定好みについてセマンティック検索あなたはりんごが好きですね。

Slide 80

Slide 80 text

短期記憶から長期記憶への抽出はStrategyを設定することで簡単に設定できます。 actor_idやsession_idでNamespaceを作成して、ユーザー単位やセッション単位など、どういった単位で抽出するかを設定可能です。長期記憶の設定イメージ 80 ● UserPreferenceMemoryStrategy ○ Namespace : /retail-agent/{actor_id}/preferences ○ 特定の顧客の好みを抽出 ● SemanticMemoryStrategy ○ Namespace : /retail-agent/product-knowledge ○ ユーザーがアクセスできる共有製品情報を抽出 ● SummaryMemoryStrategy ○ Namespace : /support-agent/{actor_id}/case-summaries/{session_id} ○ 過去のサポートケースの概要やサマリーを抽出使用例のイメージ

Slide 81

Slide 81 text

81 Episodic Memoryは他の抽出戦略と少し異なるので説明しますね！ Agent君あれ、長期戦略ってもう一つあったよね。Episodic Memory・・・これはどう使うの？？私

Slide 82

Slide 82 text

Amazon Bedrock AgentCore Memory Episodic Memory 82 新しい長期記憶戦略が追加されました。エピソード記憶といって、今までのやり取りからAIエージェントがユーザーのリクエストを効果的に満たすためのナレッジや教訓に昇華できる面白い戦略です。2段階で抽出が行われるのが他の長期記憶戦略とは異なる特徴となっています。 ConsolidationとReﬂectionの2段階で抽出を実現

Slide 83

Slide 83 text

Amazon Bedrock AgentCore Memory Episodic Memory 83 より具体的に長期記憶への保存プロセスを確認してみます。短期記憶のやり取りからエピソードを抽出し、構造化してさらに複数のエピソードからも振り返りを行い、別途構造化して記憶されるのが特徴になっています。 Extraction（抽出） Consolidation（統合） Reﬂection（振り返り）インタラクションを分析し、エピソードの完了を自動で判定。完了時点でのレコードを生成関連イベントを構造化された1つの記録に統合複数のエピソードを横断分析し、成功パターンや失敗からの解決策など、広範囲な洞察を抽出長期記憶短期記憶 Episode Memoryとして抽出 Reﬂectionとして抽出

Slide 84

Slide 84 text

実際に試す 84 計算機AIエージェントを作成して、エピソード記憶を長期記憶に設定して試してみました。NameSpaceはEpisode MemoryとReflectionでそれぞれ設定する必要があります。 Episode Memoryがセッション単位、Reflectionはユーザー単位とします。計算機AIエージェント私 Runtime 短期記憶長期記憶 12 + 31 = 123 （わざと間違える）違います・・・ 43です。やり取りを記録抽出 Episode Memory：/strategies/{memoryStrate gyId}/actors/{actorId}/sessions/{se ssionId} Reflection：/strategies/{memoryStra tegyId}/actors/{actorId} 参考：https://dev.classmethod.jp/articles/amazon-bedrock-agentcore-episodic-memory- strategy/

Slide 85

Slide 85 text

Episode Memory 85 エピソードが完了すると、会話内容が5つの観点で構造化されます。何が起きて、なぜ成功/失敗したかが記録されます。かなり詳細にエピソードとして記憶されている印象です下記観点でやり取りをエピソード記憶として構造化 ● situation（状況） ● intent（意図） ● assessment（評価） ● justiﬁcation（根拠） ● reﬂection（振り返り） ● turns（各ターンの詳細）

Slide 86

Slide 86 text

Reﬂection 86 複数のエピソードを横断して分析し、パターンやベストプラクティスを抽出します。エージェントが将来のタスクで活用できる学びとして保存されます。下記観点でやり取りを教訓として構造化 ● title（パターンのタイトル） ● use_cases（適用可能なユースケース） ● hints（実践的なヒント） ● conﬁdence（信頼度スコア）

Slide 87

Slide 87 text

ユースケースの例 87 経験などを記憶させて回答させるケースには向いている印象ですね。あとは振り返ってよりAIエージェントの作業練度を高めたいといったオペレーションにも良さそうです。具体的なユースケース例が見つかりましたらまた共有させていただきます！ユースケース説明カスタマーサポート過去の対応パターンから効果的な解決策を学習エージェント駆動ワークフロー過去のタスク実行経験を次のタスクに活用コードアシスタントセッション履歴に基づいたコンテキスト理解トラブルシューティング過去の問題解決パターンを参照パーソナル生産性ツールユーザーの作業パターンを学習

Slide 88

Slide 88 text

88 安心してください！Strands AgentsのAgentCore Memory Session Managerを使えば簡単にAIエージェントと連携できます！ Agent君総じてMemory機能便利そうですね！！私のAIエージェントに取り込みたいのですが実装って難しいんですか・・・？私

Slide 89

Slide 89 text

Strands AgentsにSession Managerといった便利な機能があります。この機能を活用することで、シームレスにMemoryを利用できて実装が簡単です。　 Amazon Bedrock AgentCore MemoryとStrands Agentsとの連携 89 ● MemoryID、SessionID、ActorIDの設定をしてセッションマネージャーを作成し、Agentの引数に設定すればMemory と連携可能

Slide 90

Slide 90 text

長期記憶の連携も簡単に設定できます。NameSpaceを設定すればOKです。 Amazon Bedrock AgentCore MemoryとStrands Agentsとの連携 90 ● Conﬁgの設定に長期記憶戦略の設定を行えば使用可能 ● NameSpaceを設定 ● Episodic Memoryも設定可能 ● 複数の長期記憶戦略の設定も可能

Slide 91

Slide 91 text

91 よかったです！！次はGatewayといった少しわかりづらい機能について説明していきますね。 Agent君おおお、これなら簡単に自分のAIエージェントに組み込めそうですね！早速試してみます！私

Slide 92

Slide 92 text

Amazon Bedrock AgentCore Gateway 92

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

95 そう思いますよね・・・！！今からGatewayのメリットを説明してきますね！ Agent君え、GatewayってMCPサーバーをホストするものではないんですね。何に使うんですか？？何だかGatewayを使うことでより複雑になっている気が・・・RuntimeでMCPサーバー自体はホストできますし・・・私

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

Strands Agentsではtool_call_syncメソッドが存在し、Gatewayに紐づいているツール情報を取得することができます。具体的なツール同期の処理 99 AIエージェント Gateway ユーザー XXXをやって Gatewayに紐づいたツール情報取得たくさんのツールターゲット

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

GatewayでSemantic Searchを有効にすると、ツール名 x_amz_bedrock_agentcore_searchを呼び出せます。 Semantic Searchのリクエスト・レスポンス例 101 リクエストレスポンス

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

106 そうですね！後はGatewayがたくさんのツールを活用できるといったことはきめ細かい権限制御も必要になってきますよね。そこでいくつかきめ細かい権限制御ができる機能があるので紹介します。 Agent君なるほど！！だいぶ理解できました！！MCPツールを中央集約的に管理したい際にGatewayは輝くイメージですね！！私

Slide 107

Slide 107 text

Policyは12月にPreviewリリースされた機能です。ポリシー言語であるCedarを使って、きめ細やかにツールの認可制御ができるようになりました。AIエージェントが返金処理を実施するツールを利用する例を考えてみます。 Gateway Policy（Preview） 107 AIエージェント Gateway $50返⾦するで返⾦ツール使うで⾦額が $200未満か評価 OK 返⾦ツール AIエージェント Gateway $1000返⾦するで返⾦ツール使うで⾦額が $200未満か評価 NG ✖ ⚪ ポリシーに適合している場合ポリシーに適合していない場合

Slide 108

Slide 108 text

Gateway Policy ツール拒否のイメージ 108 ポリシーで許可されていないツールを実行した場合は実行を拒否されます。 AIエージェント Gateway ユーザーツールCを実行して Gatewayに紐づくたくさんのツール tools/call 一覧取得ツールCを実行するよポリシーで許可されたツール Policy ツールA ツールB ツールC ツールD ツールCは実行できないよツールAとBのみ許可

Slide 109

Slide 109 text

Gateway Policy 109 ポリシーで拒否される場合は下記のような権限不足のエラーが返却されます。

Slide 110

Slide 110 text

Gateway Policy 110 ツールの一覧を取得するTool/Listの場合はPolicyで許可されたツールのみ表示される形となります。ALLOWしていない、もしくは明示的にDenyしているツールは表示されません。 AIエージェント Gateway ユーザーツールの一覧を教えて Gatewayに紐づくたくさんのツール tools/list 一覧取得 Gatewayに紐づくツールの一覧を取得するよポリシーで許可されたツール Policy ツールA ツールB ツールC ツールD 使用できるツールはA とBだよツールAとBのみ許可

Slide 111

Slide 111 text

Gateway Policy:Semantic Searchの場合 111 注意点としてSemantic Searchでツールを検索した場合はポリシーの条件が評価されず、検索結果が単純に返却されます。権限に応じて動的に検索結果をフィルタリングしたい場合は後述するResponse Interceptorを活用する形になります。 AIエージェント Gateway ユーザー入金処理のツールを教えて Gatewayに紐づくたくさんのツール x_amz_bedrock_agentco re_searchツールで検索（Semantic Searchを実行するツール）一覧取得入金処理のツールを検索するよポリシーで許可されたツール Policy ツールA ツールB ツールC ツールD 入金処理のツールはツールAとツールCだよツールAとBのみ許可

Slide 112

Slide 112 text

注意：Gateway Policyで発生するエラー 112 Policyを使用する際はGatewayのService-Linked Roleには必要な権限があります。下記のようなエラーが出た場合はIAMの権限が適切かチェックしましょう。後からGateway にPolicyを紐づけた際は要注意です。 Gateway Policy ステータスコードは200だがInternalServerEceptionが発生紐付け Service-Linked Roleに bedrock-agentcore:AuthorizeAction、 bedrock-agentcore:PartiallyAuthorizeAct ions、bedrock-agentcore:GetPolicyEngine の権限が必要

Slide 113

Slide 113 text

付与する具体的なIAM権限 113 Service-Linked RoleにPolicy用に付与する具体的な権限は下記イメージです。

Slide 114

Slide 114 text

Gateway Policyの評価方法 114 LOG_ONLY とENFORCEの2種類の評価方法が存在します。LOG_ONLYモードはログに評価記録を残すだけで実際にはDenyされません。そのため、まずは。LOG_ONLYモードで挙動確認して、設計通りDenyされているか判断して問題なければ、ツール実行の拒否まで実施するENFORCEに切り替えるのが良いかと思います。 AIエージェント Gateway ユーザーツールCを実行して Gatewayに紐づくたくさんのツール tools/call 一覧取得ツールCを実行するよポリシーで許可されたツール Policy （LOG ONLY）ツールA ツールB ツールC ツールD ツールCを実行しました（ログの記録のみなので実行は可能）ツールAとBのみ許可 CloudWatch 評価結果を記録

Slide 115

Slide 115 text

LOG_ONLY モードの確認 115 LOG_ONLY モードの評価結果はObservability機能として提供されているCloudWatchの Dashboardで確認可能です。拒否された全体の傾向や個々のトレースも確認することができます。ビジュアルで拒否の割合を確認個々のトレースから拒否されているリクエストを確認

Slide 116

Slide 116 text

直感的にかけるポリシー言語です。下記記載なら認証を受けたユーザーが process_refundツールをあるGateway経由で使用する時を対象にしています。また条件として、ロールはrefund-agentが対象で、amountが200未満の場合に利用できるといった条件を記載できます。注意点としてCedarはIAMと同じように許可しなければ暗黙的に全て拒否されるので注意が必要です。 Cedar言語 116

Slide 117

Slide 117 text

自然言語によるポリシー作成 117 Cedarポリシーは自然言語でLLMを活用して作成することも可能です。Cedarってなんだか難しそうって方にも便利な機能が備わっております。ただ強すぎる権限やエラーが発生する設定になることもあるので注意も必要です。ユーザー注文情報は参照可能で、更新や作成は不可にして欲しいです。コンソール上で入力情報を読み取ってポリシーが作成される

Slide 118

Slide 118 text

Gatewayへのリクエスト、GatewayからのレスポンスにLambda関数を介して介入する機能となります。きめ細かい認可制御などを可能にします。 Gateway Interceptors 118 引用：https://aws.amazon.com/jp/blogs/news/apply-ﬁne-grained-access-control-with-bedrock-agentcore-gateway-interceptors/

Slide 119

Slide 119 text

Gatewayに対してリクエスト・レスポンスにInterceptorsを使って介入できます。 Gateway Interceptors Request Interceptors Response Interceptors AIエージェント Request Interceptor Gateway Gateway Response Interceptor AIエージェントターゲットターゲット Gatewayがターゲットを呼び出す前に実行されます。ユースケース ● きめ細やかな認可制御（例：ユーザーグループに基づくツール実行可否） ● アクセストークンの変換（例：なりすまし防止） ● ガードレールとの連携などなど Gatewayがレスポンスをクライアントに返却する前に実行されます。 ● ツール一覧情報の権限に紐づく動的なフィルタリング ● 個人情報などの機密データのマスキング ● etc・・・ユースケース

Slide 120

Slide 120 text

Request Interceptorのユースケースも考えてみましょう。Gatewayの認証が通ると、ユーザーAの権限では実行させたくないツールも実行できるような状態になります。 Gateway Request Interceptor 120 AIエージェント Gateway ユーザーA （一般ユーザー）更新処理をしてほしい Gatewayに紐づくたくさんのツールユーザーAの権限ではツールAは実行させたくないが実行できてしまうユーザーAの権限ではこのツールしか実行させたくないユーザーB （管理者ユーザー）更新処理をして欲しい tools/call ツール実行更新処理 = ツールAを実行しますツールA

Slide 121

Slide 121 text

Request Interceptorを活用して、ユーザーの権限に応じてツールの実行を制御することができます。 Gateway Request Interceptor AIエージェント Gateway ユーザーA （一般ユーザー）更新処理をしてほしい Gatewayに紐づくたくさんのツールユーザーAの権限ではこのツールしか実行させたくないユーザーB （管理者ユーザー） tools/call ツール実行あなたの権限では更新処理 = ツールAを実行できませんでしたツールA Request Interceptor 権限NGならレスポンスを返却ユーザーAのアクセストークンをデコードして検証して、権限が適切か確認。権限がNGならレスポンスを返却するように

Slide 122

Slide 122 text

Response Interceptorのユースケースも考えてみましょう。GatewayにPolicyも何も付与していないと下記のように全てのツール情報が返却されてしまいます。 Gateway Response Interceptor 122 AIエージェント Gateway ユーザーA （一般ユーザー）ツールで何ができるの？ Gatewayに紐づくたくさんのツールユーザーAの権限では一部ツール情報しか取得してほしくないが全てのツールが取得できてしまう本当はユーザーAに取得させたいツール一覧ユーザーB （管理者ユーザー）ツールで何ができるの？ tools/list ツール情報取得全てのツール情報を返却 Aさんの権限では実行して欲しくないツールも提示しちゃうよ

Slide 123

Slide 123 text

Response Interceptorを活用して、ユーザーの権限に応じたツール一覧を返却することを可能とします。 Gateway Response Interceptor 123 AIエージェント Gateway ユーザーA （一般ユーザー）ツールで何ができるの？ Gatewayに紐づくたくさんのツール本当はユーザーAに取得させたいツール一覧ユーザーB （管理者ユーザー） tools/list ツール情報取得 Aさんが実行できるツールは下記の通りです。 Response Interceptor ユーザーに応じたツール一覧をフィルタリング Aさんの権限に応じて、ツールの一覧をフィルタリングする

Slide 124

Slide 124 text

124 はい、また考えたら教えてくださいね。次はAIエージェントの挙動を可視化する大事なObservability機能を説明してきますね！ Agent君 PolicyとInterceptorsを使ってきめ細やかい権限制御できるようになりますね！この2つの使い分けについてはまたじっくり考えたいです。私

Slide 125

Slide 125 text

Amazon Bedrock AgentCore Observability 125

Slide 126

Slide 126 text

Amazon Bedrock AgentCore ObservabilityはAIエージェントの各種メトリクス、トレース、スパンを可視化することが可能です。マネージドサービスで可視化を簡単に実現できます。 Amazon Bedrock AgentCore Observability 126 AIエージェント Amazon CloudWatch メトリクス‧トレースログを送信ダッシュボードを参照ユーザー

Slide 127

Slide 127 text

セッションは会話全体、トレースは1回のリクエスト、スパンは個別の処理を表します。セッション・トレース・スパンの関係 127 セッションID:abc-001（会話全体）トレースID:def-001 スパン POST /invocati ons スパン invoke_a gent Strands トレースID:def-002 スパン POST /invocati ons スパン invoke_a gent Strands

Slide 128

Slide 128 text

トランザクション検索を有効化すると、エージェントの実行フローを可視化できます。アカウントごとに1回だけ有効化すればOKです。 Amazon Bedrock AgentCore Observability 128

Slide 129

Slide 129 text

デプロイ時にaws-opentelemetry-distroが依存関係に含まれている必要があります。ただstarter toolkitを使ってコンテナを選択して、デプロイすると下記のように自動で Dockerfileに含まれて、自動的にトレースされます。依存関係（コンテナの場合） 129 開発端末 .bedrock_agentcore.yaml Dockerfile configureコマンドで作成 CMD ["opentelemetry-instrument", "python", "<>.py"]が⾃動的に含まれている launchコマンドでコンテナイメージをビルド＆Push ECR Runtime Pull トレース可能な状態に！！！

Slide 130

Slide 130 text

直接アップロードの場合はaws-opentelemetry-distroをrequirements.txtなどのパッケージ管理ファイルに依存関係を含めることでトレースされるようになります。create コマンドでテンプレートから作成した場合は自動的に含まれるので特に気にしなくてOK です。依存関係（直接アップロードの場合） 130 .bedrock_agentcore.yaml requirement s.txt conﬁgureコマンドで作成 launchコマンドでZipアップロード Runtime トレース可能な状態に！！！開発端末 aws-opentelemetry-distroが必要 S3 ダウンロード

Slide 131

Slide 131 text

アプリケーションログとOpenTelemetry形式のログの2種類が出力されます。 otel-rt-logsストリームにはOTEL形式、日付つきストリームにはアプリログが記録されます。 CloudWatchに出力されるログ 131 OTEL形式アプリログ

Slide 132

Slide 132 text

トレースを下記のように確認できます。処理時間やそれぞれのスパンでのメッセージ内容なども細かく確認できてどこがボトルネックになっているかも分析しやすいです。統合ダッシュボード 132 処理フローが可視化されているそれぞれのイベント内容を確認可能ツリー状にスパンを表現、処理時間も表⽰されている

Slide 133

Slide 133 text

Runtimeだけではなく、Memory、Identity、Gateway、Built-in tools、Evaluationsなどの機能もトレース可能なので便利です。挙動を見る際は積極的に活用していきたいですね。 Runtime以外での機能でもトレース可能 133 Memory Gateway ⻑期記憶が抽出された数ポリシーによって拒否された割合

Slide 134

Slide 134 text

134 積極的に可視化機能を使って、エージェントの動きを理解したいですね！次はAIエージェントで運用する上で大事な評価を実現する Evaluations機能について説明しますね！ Agent君可視化できるのは便利ですね・・・不明瞭な動きやエラーがあったらまずはこのダッシュボードを見て・・・って運用になりそうですね。また、Runtime以外も可視化されているのは便利ですね。特にGatewayとか拒否ポリシーかどうか挙動を見たい時もあると思いますし。私

Slide 135

Slide 135 text

Amazon Bedrock AgentCore Evaluations（Preview） 135

Slide 136

Slide 136 text

開発・運用しているAIエージェントの評価がコンソール上からできるようになりました。ダッシュボードからわかりやすく確認できます。LLMを使った評価（LLM-as-a-Judge）となります。 Amazon Bedrock AgentCore Evaluations（Preview） 136 AIエージェントユーザー Gateway ⼤阪の天気を教えて天気検索ツールを使って返事する！（ツールの結果を踏まえて）晴れです天気検索ツールリアルタイムでも質問に対する適切な回答‧ツール選択ができているかなど評価⼀連の流れを観点に基づいて評価

Slide 137

Slide 137 text

若干のラグはありつつもリアルタイムで評価も可能です。また、Starter Toolkitを使えばオンデマンドでの評価も実現できます。ログをベースに評価しているため既存のエージェントの動作には影響がありません。評価方法 137 Online evaluation On-demand evaluation ● リアルタイムでエージェント品質を継続的にモニタリング可能、サンプリング率やフィルタ条件を指定もできる。 ● 評価結果はObservabilityのダッシュボードからも確認可能 ● 特定のセッションIDなどを指定してオンデマンドで評価可能。 ● Starter Toolkitで簡単に実⾏可能どちらも運⽤中のエージェントには影響しない

Slide 138

Slide 138 text

オンライン評価の場合ならコンソール上から簡単に有効化することが可能です。最大10 個まで評価指標を用いて評価することが可能です。設定方法 138 どの評価指標を⽤いるか選択する（最⼤10個まで）評価にする対象のフィルタリングやサンプリング率を選択する

Slide 139

Slide 139 text

具体的な以下の観点で評価可能です。下記以外でもカスタム評価も実装可能となります。評価項目の一覧 139 Session-level Evaluator （セッション全体を評価） ● Goal Success Rate（⽬標達成率） ○ 会話セッション全体を通じて、ユーザーの⽬標が全て達成されたかを評価する Tool-level Evaluators （ツール呼び出しを評価） ● Tool Parameter Accuracy（ツールパラメータ正確性） ○ ツール呼び出し時のパラメータが会話コンテキストから正しく取得されているかを評価する ● Tool Selection Accuracy（ツール選択正確性） ○ 状況に応じて適切なツールが選択されているかを評価する

Slide 140

Slide 140 text

具体的な以下の観点で評価可能です。下記以外でもカスタム評価も実装可能となります。評価項目の一覧 140 Trace-level Evaluators （各ターンの応答を評価） ● Coherence（⼀貫性） ○ 応答に論理的な⽭盾、⾶躍、⾃⼰⽭盾がないかを評価する ● Conciseness（簡潔性） ○ 必要な情報を最⼩限の⾔葉で伝えているか、冗⻑でないかを評価する ● Context Relevance（コンテキスト関連性） ○ RAGなどで取得したコンテキストが質問に適切に関連しているかを評価する ● Correctness（正確性） ○ 応答内容が事実として正しいか、回答が正確かを評価する ● Faithfulness（忠実性） ○ 応答が会話履歴やツール出⼒と⽭盾していないかを評価する ● Conciseness（簡潔性） ○ 必要な情報を最⼩限の⾔葉で伝えているか、冗⻑でないかを評価する ● Harmfulness（有害性） ○ 侮辱、ヘイト、暴⼒、不適切な性的コンテンツなど有害な内容が含まれていないかを評価する

Slide 141

Slide 141 text

具体的な以下の観点で評価可能です。下記以外でもカスタム評価も実装可能となります。評価項目の一覧 141 Trace-level Evaluators （各ターンの応答を評価） ● Helpfulness（有⽤性） ○ ユーザーの⽬標達成に向けて、応答がどれだけ役⽴っているかを評価する ● Instruction Following（指⽰遵守） ○ ユーザーの明⽰的な指⽰（形式、⻑さ、スタイルなど）に従っているかを評価する ● Refusal（拒否検出） ○ エージェントがリクエストへの回答を拒否または回避しているかを検出する ● Response Relevance（応答関連性） ○ 応答がユーザーの質問やリクエストに直接答えているか、的外れでないかを評価する ● Stereotyping（ステレオタイプ検出） ○ 特定のグループに対する偏⾒やステレオタイプ的な内容が含まれていないかを評価する

Slide 142

Slide 142 text

オンデマンド評価の実施方法 142 オンデマンド評価はStarter Toolkit のevalコマンドで実行可能です。開発中で特定のセッションについて評価して欲しいタイミングなどサクッと確認できて便利ですね。評価する対象のセッション IDおよび、評価指標を指定実⾏コマンド評価結果点数や評価、評価の根拠を説明根拠については適切に評価しているか確認したいですね

Slide 143

Slide 143 text

具体的な評価の画面は下記のようになります。コンソール上のGenAI Observabilityダッシュボードから確認可能です。オンライン評価結果はダッシュボードから確認可能 143 各評価指標ごとにビジュアルでスコアを確認できる評価がNGだったケースから特定のセッションを確認することも可能

Slide 144

Slide 144 text

オンライン評価結果のログはCloudWatchに格納されていれます。ログを確認することも可能です。LLMによる評価のため、予想と異なる結果のケースもあるかと思います。気になれば適宜チェックして改善に活かしていきましょう！！ AIによる評価 144 ● explanationでAIが何を持って正解としたかの根拠を記載 ○ AIの根拠と想定が一致しているかは要チェック

Slide 145

Slide 145 text

145 はい、Evaluations機能を活用して、AIエージェントを育てていけると良いですね。次はAIエージェントが起こせるアクションを増やす便利な built-in tools機能について説明しますね。 Agent君 Evaluations機能は欠かせない機能ですね・・・AIエージェントは作って終わりではないから、継続的に評価してAIエージェントをよくしていきたいですね。またAIによる評価も適切かどうかの判断が必要ですね。私

Slide 146

Slide 146 text

Amazon Bedrock AgentCore built-in tools 146

Slide 147

Slide 147 text

Code Interpreter Code Interpreterは、AIが生成したコードを完全に隔離されたサンドボックスで安全に実行し、Browserはブラウザ操作による自動化を可能にします。データ分析からWebに対するアクションまで、エージェントの適用範囲を大きく広げる強力な機能です。 Amazon Bedrock AgentCore Built-in Tools（Code Interpreter & Browser） 147 Browser 引⽤：https://catalog.us-east-1.prod.workshops.aws/workshops/015a2de4-9522-4532-b2eb-639280dc31d8/en-US/60-agentcore-tools/62-browser-tool/01-browser-with-novaact 引⽤：https://catalog.us-east-1.prod.workshops.aws/workshops/015a2de4-9522-4532-b2eb-639280dc31d8/en-US/60-agentcore-tools/61-code-interpreter

Slide 148

Slide 148 text

148 はい、便利なのでユースケースに応じて活用していきたいですね！まずはCode Interpreterから説明していきます！ Agent君なるほど、ブラウザとコードの実行環境ですか。どちらもあったらエージェントの実行できるアクションの幅が広がりますね。私

Slide 149

Slide 149 text

生成AIが作成したコードを外部の安全な環境で実行するための機能となります。 Amazon Bedrock AgentCore Built-in Tools（Code Interpreter） 149 ● 完全に隔離されたサンドボックス環境でコード実⾏ ● Python、JavaScript、TypeScriptに対応 ● pandas、numpy、matplotlibなどのデータサイエンス系ライブラリが利⽤可能 ● インライン100MB、S3経由で最⼤5GBのファイル処理が可能 ● デフォルト15分、最⼤8時間の実⾏時間 ● セッション内でのファイルや変数の状態維持

Slide 150

Slide 150 text

動作イメージとしては下記のようなイメージで動作します。独立した環境で動作し、AI エージェントの実行環境に影響を与えることはございません。 Code Interpreterの実行イメージ 150 Amazon Bedrock AgentCore AgentCore Runtime AIエージェント Code Interpreter ツール経由で呼び出し生成AIが作成したコード独立した環境で安全に実行コードを実行実行環境には影響しない ✖

Slide 151

Slide 151 text

Code Interpreterで生成AIが作成したコードを実行するイメージは下記のようになります。 Code Interpreterのユースケース例 151

Slide 152

Slide 152 text

152 はい、Strands Agentsで簡単に実装できますよ！Code Interpreter用のツールが提供されています！ Agent君画像作成とか便利そうですね。また大規模なファイルはS3連携できたり、ビルトインのライブラリが入っているのも良いですね。ちなみに Strands Agentsで簡単に実行できたりしますか・・・？私

Slide 153

Slide 153 text

Strands AgentsでもCode Interpreterを操作する便利なツールが提供されていて、下記のようなコードでCode Interpreter上で作成したコードの実行を可能にします。 Strands Agentsでの活用 153 ● ツールをimportして初期化すれば、エージェントがツールとして Code Interpreterを可能に！参考：https://docs.aws.amazon.com/be drock-agentcore/latest/devguide/c ode-interpreter-using-strands.html

Slide 154

Slide 154 text

154 わかりました！Browser機能について説明します！ Agent君おお、簡単に実装できましたね。次はBrowser機能について説明をお願いします！私

Slide 155

Slide 155 text

Amazon Bedrock AgentCore Browserは生成AIがブラウザを操作するための実行環境を提供するサービスです。下記のような操作可能なブラウザをLLMがPlaywrightや Browser Useなどを活用して操作します。 Amazon Bedrock AgentCore Built-in Tools（Browser） 155 Browser AgentCore Runtime AIエージェント操作

Slide 156

Slide 156 text

Strands AgentsでもBrowserを操作する便利なツールが提供されていて、下記のようなコードでブラウザ操作を可能にします。 Strands Agentsとの統合 156 ● ツールをimportして初期化すれば、エージェントがツールとしてブラウザ操作を可能に！参考：https://docs.aws.amazon.c om/bedrock-agentcore/lates t/devguide/browser-onboardi ng.html

Slide 157

Slide 157 text

検索エンジンを使うとCAPTCHAに引っかかる可能性があります。一般的な検索にはブラウザ以外のMCPツール（Tavilyなど）の利用を推奨すると公式ドキュメントに記載がありました。あくまで使用用途としてはForm入力や特定ページのアクションなどWeb操作を自動化するのがいいかもしれませんね。注意：検索での使用について AgentCore Runtime AIエージェント Identity TavilyAPI Browser ブラウザ操作の自動化 Web検索 Secrets Manager API Key 取得リクエスト

Slide 158

Slide 158 text

CAPTCHA対策としてWeb Bot Auth（Preview）も提供されています。エージェントに暗号化された身元証明を付与することで、Cloudﬂare・Akamai等の主要 WAFプロバイダーに「正当な自動化ボット」として認識させ、CAPTCHA表示を減らす仕組みです。あくまでプレビュー機能であり、引き続き検索をメインで使う場合はMCP ツールなどで検索するやり方が手堅く感じます。 CAPTCHA対策（Preview） Reduce CAPTCHAs for AI agents browsing the web with Web Bot Auth (Preview) in Amazon Bedrock AgentCore Browser

Slide 159

Slide 159 text

159 はい、検索はまずはTavilyなどで実現できないかを検討するのが良いかと思います！Form入力や特定ページのアクションなどWeb操作を自動化する際にBrowserを使用するのが良いかと思います。 Agent君なるほど、検索のユースケースは向いていないんですね。検索はBrowserを活用せず、別の検索APIで実装するのを第一案にして、WebのForm入力や情報収集などの別アクションでBrowserを活用してみます！私

Slide 160

Slide 160 text

160 はい！今回説明したかった内容は以上となります！お疲れ様でした！！今回説明した内容はほんの一部でしかない箇所もあるので実際に触って理解を深めていってくださいね！ Agent君ブラウザ操作やコードを外部環境で実行したい時はBuilt-in tools便利ですね！これでAgentCoreの説明は以上かな？私

Slide 161

Slide 161 text

まとめ 161

Slide 162

Slide 162 text

162 もちろんAgentCoreの機能を全て使う必要はございません！！必要な要件に応じて使用する機能を組み立てて便利なAIエージェントを組み立ててもらえると良いかと思います！ Agent君 Agent君、説明ありがとう！！今日説明してもらった機能は全部使う必要があるのかな？いっぱいあって難しいなと思って・・・私

Slide 163

Slide 163 text

まとめ 163 この資料ではAgentCoreについて幅広く説明させていただきました。もちろん説明しきれていないことも多くありますが、少しでもAgentCoreに興味を持っていただけたり、理解が深まったら何よりでございます。来年はAgentCoreをより活用して便利なAIエージェントを生み出していきましょうー！！引き続き皆様のためになるよう本資料はアップデートしていきますので、よろしくお願いします！最後までご覧いただきありがとうございましたー！！

Slide 164

Slide 164 text

Thank you!