AgentCore の機能、全部要る？ ユースケース別にAWSサービスとの組み合わせ方を 一緒に整理しよう AWS Summit Japan Builder Community Lounge チョークトーク 6/26 （金）11:30 ~ 12:00 クラスメソッド株式会社 クラウド事業本部コンサルティング部 神野 雄大（Jinno Yudai） 

2 自己紹介 

自己紹介 3 簡単な自己紹介をさせていただきます。本日はどうかよろしくお願いいたします。 名前 神野 雄大（Jinno Yudai）/@yjinn448208 所属 クラスメソッド株式会社 クラウド事業本部 コンサルティング部 AIソリューションアーキテクト 認定・ 活動 ● Community Builder AI Engineering ● AWS Ambassador 2026 好きな サービス ブログはこのアイ コンで書いていま す！ ● Amazon Bedrock AgentCore （自称日本一ブログを書いています） スーパーマーケットのラ・ムーと チーズナンが好きです！ スピーカー 

対象と目的 4 今日はAgentCoreを触り始めた方、これから自分のユースケースに合わせて設計したい 方に向けてチョークトークを進めていきます。一緒に考えながら、設計判断の軸を持ち 帰ってもらったら嬉しいです。 対象 対象と目的 ● AgentCoreの機能は知っているが、自分のケースにどう組むか迷っている ● これからAIエージェントを設計・導入していきたい 目的 ● ユースケース別に「どのAgentCoreの機能を使い、どこは既存のAWSサービスでを 活用するか」を一緒に設計する ● 「自分のケースならこう設計する」という判断軸を持ち帰る スピーカー 

今日やること 5 今日はAgentCoreの機能を丁寧に紹介するのではなく、ユースケースに基づいて、どの 機能を採用し、どういった設計が良いかをディスカッションできればと思います。 AgentCoreのざっくり紹介 ユースケース収集 設計に落とし込み 構成図を描く 自分が実装するならこうすればよいのかのヒントを掴んでいただく！ AgentCoreの全体像を俯瞰 して紹介します。全部は使 わない、を最初に共有しま す。 作りたい／興味のあるエー ジェントを挙手で募集。利 用者・目的・接続先・制約 の4点に分解していきます。 集めたケースから1つか2つ 選び、どの機能を採用し、 どこは既存AWSサービスで 組むかを一緒に判断しま す。 ホワイトボードにアーキテ クチャを起こし、実際に使 える構成をイメージしてい きます。 スピーカー 

6 早速ですがAgentCoreをマスターしているぜ！という方いますか？ 挙手お願いしますー！ 私 コミュニケーション アイスブレイク 

7 では続いてAgentCore触ったことあるよーって方はいますか？ 挙手お願いしますー！ 私 コミュニケーション アイスブレイク 

8 AgentCore全く触ったことがない、興味はある！って方はいますか？ 挙手お願いしますー！ 私 コミュニケーション アイスブレイク 

9 今日AgentCoreについて何か知りたい話題がある方いますかー？ 挙手お願いしますー！そして何を知りたいか教えてください！ 私 コミュニケーション アイスブレイク 

10 AgentCoreのざっくり紹介 

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

Amazon Bedrock AgentCoreはデプロイするためのRuntime機能をベースに認証機能 IdentityなどAIエージェントを開発する上で便利な機能が備わっています。アップデー トも多くかなり多機能です。 Amazon Bedrock AgentCoreが持つ機能群 12 ● Runtime：AIエージェントの実行環境 ● Identity：認証機能 ● Gateway：MCPツールの集約機能、外部サービスのMCPツール化機能 ● Memory：記憶機能 ● Observability：AIエージェントの挙動を可視化 ● Evaluations：AIエージェントの評価機能 ● Built in tools ○ Code Interpreter：コード実行環境 ○ Browser：ブラウザ実行環境 ● Policy：Gateway経由のツール呼び出しを認可制御する機能 ● AWS Agent Registry：組織内のSkills、MCP Server、A2A Agentの管理機能 ● Optimization：プロンプトやツール説明を改善、バージョン管理機能 ● Payments：AIエージェントによる決済機能 ● Harness：簡単にAIエージェントを作成可能 スピーカー 

13 多機能ですよね・・・全部必要はないです！ 要件に応じて必要なものだけ使えば大丈夫ですよ！ Agent君 ええ、なんとなく便利なのは分かったけど機能多すぎない・・・！？ 全部使ったらええの？？ 私 スピーカー 

プリミティブの数は膨大ですが、全部を必ずしも使う必要はないです。 要件に応じて必要なものを使えばOKです。例えばQ&Aサイトのようなシンプルな例なら 下記のような組み合わせで実装可能です。 Amazon Bedrock AgentCoreの連携イメージ 14 AgentCore Runtime AIエージェント AWS Amplify ユーザー リクエスト リクエスト with アクセストークン フロントエンド ログインしてアクセストークン を取得 Amazon Cognito トークンの検証 AgentCore Identityの Inbound Auth Knowledge Bases RAGとして使用 ベクトルDBにAmazon S3 Vectorsを使用することで低 コストで運用可能 Q&Aサイトの構成イメージ AgentCoreはRuntimeとMemory、Identity、Observabilityを使用 AgentCore Observability エージェントの動きを可 視化 スピーカー AgentCore Memory 記憶機能 

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

SaaSと連携するようなAIエージェントを使うならGatewayの利用も検討しますが、無理 に使う必要もないかもしれません。複数のAI Agentから接続かつ外部接続を統制したい などあれば採用するモチベーションにつながります。 Amazon Bedrock AgentCoreの連携イメージ② 16 AgentCore Runtime Lambda関数 Remote MCP Server ツール利用 SaaS AgentCore Runtime Lambda関数 Remote MCP Server ツール利用 SaaS 同じようなツールを作って重複している AgentCore Gatewayを使う場合 AgentCore Gateway Lambda関数 Remote MCP Server ツール利用 SaaS AgentCore Runtime AgentCore Runtime 同じツールを使うならGatewayを仲介すると ツールの連携も統制が取れてスッキリ Policyを活用して 認可制御も可能 スピーカー 

17 ユースケースからどう組み立てていくか気になりますよね！ 今日はチョークトークなので実際にどういったユースケースがあるか聞 いてみましょう！ Agent君 なるほど・・・AWSサービスみたいに、用途に合わせてAgentCoreの機 能も組み合わせていくんだね・・・！！ 実際のユースケースから考えてみたいな・・・！ 私 スピーカー 

機能の説明に入る前に — 皆さんが「作りたい・気になっている」AIエージェントを教え てください。近いものに挙手、なければその場でいただけると嬉しいです！ まず整理させてください 18 社内ドキュメント検索 業務自動化 カスタマーサポート 　その他生の声を大募集！ データ分析・レポート生成 スーパーマーケットリサーチ （個人の野望） コミュニケーション 集めた意見をホワイトボードに書いていきます！ 

1つのユースケースに集中して、皆さんで会話していきましょう。 具体的な項目があった方が整理やすいので下記項目を埋めるような感覚で会話していき ましょう。 ユースケース① 19 コミュニケーション 目的 何をしたい？ ユーザーと対話する必要は あるか？ 利用者 誰が使うか？ 使う人によって権限を意識 する必要はあるか？ 外部接続先 SaaS / 社内API / RAG Web / DBに接続したい か？ 制約 何が怖い？ 権限・監査・誤操作 社内ポリシー、コスト、 ネットワーク 集めた意見をディスカッションしながらホワイトボードに書いていきます！ 

整理したアーキテクチャを実際にホワイトボードに書き出してみます。先ほど紹介した 下記のようなアーキテクチャ図のイメージです。 ユースケース① 20 コミュニケーション IMAGE ディスカッションしながらホワイトボード構成図を書いてみます！ 

要件に応じてどういったAWSサービスを採用するか超簡易ですがリストも用意しまし た。これを組み合わせてアーキテクチャ構成のイメージを膨らませていきます。一例で これが全てではありません。 ユースケース①（AWSサービスの組み合わせイメージ） 21 コミュニケーション Amplify フロントエンド バックエンド AWS Lambda Amazon ECS ベクトルDB S3 Vectors Amazon OpenSearch Bedrock その他機能 Guardrails Knowledge Bases S3 Amazon CloudFront AgentCore Runtime Gateway Identity Memory Observability etc・・・ Amazon API Gateway その他AWSサービス 

22 そうですね！便利な機能はいっぱいあるのですが、やりたいことや制約なども考 えながら現実的な落とし所を見つける感覚です。 （時間があれば）せっかくなのでもう1つユースケースから考えてみましょう！ Agent君 なるほど・・・アーキテクチャをユースケースから整理するのは面白い ですね。色々な制約がある中で組み合わせていく感覚ですね。 私 スピーカー 

1つのユースケースに集中して、皆さんで会話していきましょう。 具体的な項目があった方が整理やすいので下記項目を埋めるような感覚で会話していき ましょう。 ユースケース② 23 コミュニケーション 集めた意見をディスカッションしながらホワイトボードに書いていきます！ 社内ドキュメント検索 業務自動化 カスタマーサポート 　その他生の声を大募集！ データ分析・レポート生成 スーパーマーケットリサーチ 

1つのユースケースに集中して、皆さんで会話していきましょう。 具体的な項目があった方が整理やすいので下記項目を埋めるような感覚で会話していき ましょう。 ユースケース② 24 コミュニケーション 目的 何をしたい？ ユーザーと対話する必要は あるか？ 利用者 誰が使うか？ 権限を意識する必要はある か？ 外部接続先 SaaS / 社内API / RAG Web / DBに接続したい か？ 制約 何が怖い？ 権限・監査・誤操作 社内ポリシー 集めた意見をディスカッションしながらホワイトボードに書いていきます！ 

整理したアーキテクチャを実際にホワイトボードに書き出してみます。先ほど紹介した 下記のようなアーキテクチャ図のイメージです。 ユースケース② 25 コミュニケーション IMAGE ディスカッションしながらホワイトボード構成図を書いてみます！ 

要件に応じてどういったAWSサービスを採用するか超簡易ですがリストも用意しまし た。これを組み合わせてアーキテクチャ構成のイメージを膨らませていきます。一例で これが全てではありません。 ユースケース②（AWSサービスの組み合わせイメージ） 26 コミュニケーション Amplify フロントエンド バックエンド AWS Lambda Amazon ECS ベクトルDB S3 Vectors Amazon OpenSearch Bedrock その他機能 Guardrails Knowledge Bases S3 Amazon CloudFront AgentCore Runtime Gateway Identity Memory Observability etc・・・ Amazon API Gateway その他AWSサービス 

27 いざ、自分で・・・となると難しいですよね・・・！ そこでまずは整理の基準を書いてみたので一緒に見てみましょう！ Agent君 勉強になりました！自分でもできるようになりたいですね・・・！ 体系だって今日みたいにどう整理したらいいかな？ 私 スピーカー 

ユースケースを最初の頃は型で整理していくといいかもしれませんね。私もざっくりと 考えたのですが下記のような形です。こう言ったイメージも皆様も自分なりに持つと アーキテクチャ設計がやりやすくなると思います。判断軸はいっぱいあると思いますが あくまで一例を共有します。 どう整理していくか 28 スピーカー AgentCore採用判断のイメージ 1. そもそもAI Agentを作る必要があるか？ビジネスロジックだけで十分か？ 2. 実行基盤はRuntimeか、Lambda/ECSを採用するか？VPC内に配置する必要がある か？ 3. ユーザー認証は必要か？サービス間の連携はどうするか？ 4. 外部ツールは直接呼ぶか、Gatewayで集約するか？ 5. Memoryは必要か？短期記憶だけか、長期記憶まで必要か？ 6. 危険な操作（更新や削除）は外側でどう止めるか？PolicyやInterceptorで認可制御 するか 7. 本番後に何を観測・評価し、どう改善するか？ 

質疑応答 29 質疑応答も時間が許す限りなんでもどうぞ！！ コミュニケーション 

おわりに 30 スピーカー AgentCoreは、すべての機能を使い切るものではなく、 ユースケースや制約に合わせて組み合わせるための選択肢です。 今日ホワイトボードで整理したように、 「どの要件をAgentCoreの機能で実現するか」 「どの要件を既存AWSサービスで連携するか」 「どのように認証・認可・評価・Observabilityを入れるか」 を考えることで、自分のケースに合った構成を選びやすくなります。 まずはRuntimeを使ってAIエージェントを作って、それから機能を追加していくでも十 分です 今日の議論が、皆さんのAIエージェント設計のヒントになれば嬉しいです！ 

Thank you!