AgentCore Gatewayを使ってみよう！

Transcript

1. AgentCore Gatewayを 使ってみよう！ ~ たくさんある機能を紐解いてみよう ~ コンサルティング部 神野 雄大（Jinno Yudai）
2. 自己紹介 AgentCoreとスーパーマーケットが好きなエンジニアです！ ブログはこのアイ コンで書いていま す！ スーパーマーケットのラ・ムーと チーズナンが好きです！ 名前 神野 雄⼤（Jinno Yudai）/@yjinn448208 所属 クラスメソッド株式会社 クラウド事業統括本部 コンサルティング部 AIソリューションアーキテクト 認定 • Community Builder AI Engineering • AWS Ambassador 2026 好きな • Amazon Bedrock AgentCore サービス （⾃称⽇本⼀ブログを書いています）
3. 年前にAgentCoreの入門で登壇しました 昨年のDevelopersIO 2025 Osakaで、AgentCore全体の入門をお話ししまし た！あれから一年あっという間ですね・・・アップデートもたくさんありました。 1 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 3
4. 使っていますか？ AgentCore あれからはや1年・・・AgentCoreを触った方、 いますかー？挙手お願いしますー！ 私 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 4
5. ならAgentCore Gateway使っていますか？ この1年でAgentCore Gatewayを触った方、いますかー？ 挙手お願いしますー！ 私 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 5
6. あんまりいないよね・・・ あんまりいないですよね・・・ 私 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 6
7. 今日の熱い想い！ AgentCore Runtimeは使ったけれど、Gatewayはまだ…と いう方も多いはず！ 今日は多機能なAgentCore Gatewayに少しでも親しみが持 てるよう丁寧に解説できればと思います！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 7
8. 改めて対象と目的 AgentCoreやMCPの基礎からGatewayの接続・認可・運用まで一緒に見ていきま しょう！機能が多いので難しい箇所はあとから読み返しても大丈夫です。自分でも 何か使ってみたいと思ってもらえたら嬉しいです！ 対象 AgentCore Gatewayを知り、自分のAgentから外部へ接続したい方 目的 Gatewayの役割と接続方式の違いを理解する 必要な機能を選び、自分でもGatewayを使ってみたいと思っていただく！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 8
9. 本編と補足について 40分ですべてを語るのは難しいので一部は補足に回しています。すみません…。 説明しきれないところは別冊の補足資料に丁寧に書いています！ ごめんね‧‧ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 9
10. アジェンダ まずAgentCoreの基礎とMCPでツールをつなぐところから見ていきます！次に使 える人と許可する操作を決めて、マネージドな接続先・HTTP・モデルへ広げて運 用に備える順で見ていきましょう！ 1 2 3 4 5 6 基礎 AgentCoreとGatewayの役割 MCP ツールをつないで呼び出す 認証・認可 使える人とどの操作を許可するか マネージド接続先 文書・Web検索・Memory HTTP・モデル AgentやAPI、モデルへもつなぐ 運用 レート制限、簡単な運用のイメージ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 10
11. 基礎 AgentCoreとGatewayの役割 まずAIエージェントとは何かと、 それを載せるAgentCoreについて説明していきます！ 11
12. そもそもAIエージェントって何？ AIエージェントは自律的に目的に向けて次の行動を判断し依頼を進めます。LLM（大 規模言語モデル）の推論を使い、情報を調べたり処理を実行したりします。 このテーマについて 調べてまとめて まず情報を集めよう ⾜りなければ調べ直そう Agentが進める作業の例 調べる 必要な情報を集める ⽬的を伝える 利⽤者 確かめる Agent 集めた情報で⾜りるか考える まとめる 回答を返す 依頼に沿って回答を作る 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 12
13. に 回質問するだけの場合と何が違う？ エージェントは実行結果を見て次の行動を決める流れを繰り返し、必要なら追加で 調べてから回答します。 LLM 1 LLMを1回呼ぶだけの場合 AIエージェント ツールを実⾏ ⼊⼒を渡す 検索‧計算‧操作 質問や指⽰を送る LLMが推論 ⼊⼒から結果を⽣成 結果を受け取る ここで応答が完了 次の⾏動を判断 LLMを使って考える 追加の作業が 必要なら Agent 結果を確かめる ⼗分なら 回答して終了 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 13
14. ツール利用 なるほど！目的に向けて自分で次の行動を考えて進めるんだね。 MCPとかツールって聞くけど、エージェントとどう関係するの？ 私 関係大アリだよ！ ツールを使って、外部の操作や情報の取得ができるんだ。 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる Agent君 14
15. モデルが選んだツールをエージェントが実行する ツールは検索や計算などエージェントから道具を呼ぶ機能です。LLMは使う操作と 引数を出力し、実際のAPI呼び出しはエージェントのコードが行います。 ツールがないと… 今⽇の東京の天気は？ ツールがあると LLM Agentの実⾏コード 天気API ツールの使い⽅をLLMへ渡す 名前‧説明‧⼊⼒の条件 ツール名と引数 get_weather city = 東京 LLMだけ city = 東京 晴れです！ 晴れ‧25℃（例） もっともらしく作ってしまう ハルシネーション 実⾏結果を戻す APIを呼ぶのはAgentのコード 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 15
16. ツールごとに呼び方が違うと大変 在庫確認はREST API、発注は社内のSDK、検索は別の形式というようにツールご とに呼び方が違うとAgent側の書き方がツールの数だけ増えていきます・・・ ツールごとに 呼び⽅を覚えないと… Agent GET /stock?item=… 在庫確認 order.create(…) 発注 POST /search {…} 検索 ？ 次のツール REST API 社内のSDK 別の形式 また別の呼び⽅ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 16
17. ならどのツールも同じ呼び方で呼べる そこで使うのがMCPです！ツールがMCPで公開されていれば、在庫確認も発注も 検索も同じtools/callで呼べます！ MCP ツールごとに呼び⽅を覚える… GET /stock?… order.create(…) MCPなら同じ呼び⽅でいい！ 在庫確認 tools/call 在庫確認 発注 tools/call 発注 tools/call 検索 REST API 社内のSDK Agent MCPサーバー MCPサーバー Agent POST /search 検索 別の形式 MCPサーバー 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 17
18. ツールの一覧取得と呼び出し方の共通仕様MCP MCPはツールの一覧取得と呼び出し方を揃える共通仕様です。一覧で使えるツール と渡す値を知り、同じ手順で呼び出します。 tools/listで使えるツールを問い合わせる エージェント MCPクライアント 名前‧説明‧⼊⼒スキーマを返す tools/callに名前と引数を指定する 外部機能を公開 MCPサーバー 実⾏結果を返す 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 18
19. AgentCore おお、道具を使ってアクションできるようになったんだね！ それを載せる環境がAgentCoreってこと？ 私 そう！Agentを動かすRuntimeなどを含むサービス群がAgentCoreだよ。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 19
20. Amazon Bedrock AgentCore AgentCoreはAIエージェントの構築・運用に必要な機能を選んで使えるAWSサー ビス群です。今日はAIエージェントから外部への接続をまとめるGatewayの役割 を押さえましょう。 Amazon Bedrock AgentCore Runtime 外部呼び出し Agentのコードを 動かす場所 Memory Gateway 今回の主役 ツール‧APIなどへの 接続をまとめる Identity Policy Observability 接続先 なども提供 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 20
21. を動かすコードも自分で書くの？ Agent AgentCoreには動かす場所も接続の仕組みもあるんだね！すごい便利そう！ Agentの処理は自分でコードを書くの？ 私 モデルや指示、ツールをマネコンで設定して作れるHarnessもあるよ。 お手軽なんだよ！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 21
22. 設定からAgentを作れるHarness Agentを動かすコードを自分で用意する方法に加え、Harnessで設定から作る方 法もあります。使うモデル・指示・ツールを選ぶと推論とツール実行を繰り返す Agentを動かせます。 AgentCore Harness ⽤意する設定 使うモデル モデルで考え、ツールを呼ぶ 設定する Agentへの指⽰ 使わせるツール Agent ツール 結果を受け取り、次を考える この繰り返しと実⾏環境を任せられる コードは書かずコンソールを編集！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 22
23. 設定したAgentにプレイグラウンドで質問できる Harnessで作ったAgentはサクッとコンソールのプレイグラウンドからそのまま試 せます！！まず作ってためそう！！！ Harnessのプレイグラウンド（ブログの画⾯から抜粋） 設定したAgentに 設定したAgentに そのまま質問できる そのまま質問できる …（回答の続きは省略）… Agentが使ったツールも Agentが使ったツールも 確認可能 確認可能 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 23
24. ここからはGatewayの役割を見ていこう なるほどー簡単に作れるんだね！ 今日の主役Gatewayについて教えて。 私 Gatewayは外部の機能を呼び出す共通の窓口なんだ。 まずはコンビニのレジでいろいろな用事を頼む場面で考えてみよう！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 24
25. コンビニのレジのように入口をまとめる コンビニでは荷物の発送や料金の支払いを同じレジで頼めますよね。Gatewayも接 続先ごとに異なる機能をAgentが使う共通の入口へまとめます！ コンビニなら同じレジで頼める 荷物を送りたい！ 料⾦も⽀払いたい！ コンビニのレジ 発送‧料⾦⽀払いを受付 お客さん Gatewayなら同じ⼊⼝からツールを呼べる 使うツールと引数を指定 Agent 例：在庫確認‧商品コード Gateway 接続先‧認証を管理 配送会社 料⾦の⽀払先 在庫確認 Lambda 発注API 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 25
26. の役割 GatewayはAgentからツール・API・モデルを呼ぶ共通の窓口です。上の3段が接 続の方法、下段が利用を制御する機能で、一つずつ紐解いていきましょう！ AgentCore Gateway 接続先 AgentCore Gateway MCP ツールを集約‧検索 Lambda API‧MCP ⽂書検索 Web検索 HTTP Agent ⾊々なものに中継 別のAgent 既存API Memory Inference モデル名で接続先を選ぶ 認証‧認可 内容の検査 Bedrock 他社モデル 利⽤量の制限 ログ‧監視 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 26
27. 直接APIを呼べるのにGatewayは必要？ APIを呼ぶコードは自分でも書けます。そこにGatewayを挟むと経路が1つ増える ので、何が楽になるのか気になりますよね。煩雑さを増すだけではないのかな？ 直接つなぐ 間に挟む分だけ 複雑にならない？ 接続設定はAgent側へ Agent API Gatewayを通す Agent Gateway API 私 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 27
28. 直接接続とGateway経由 Agentや接続先が増えると同じ接続や認証の設定を複数の場所で持つことになりま すが、Gatewayにまとめれば共通で管理できます。接続先が少なく共通の制御も 不要なら、直接接続ももちろん可能です。 Agentごとに直接接続 Gateway経由で接続 Agent A API A‧Bの接続先と 認証設定を持つ API A Agent A API A API A‧Bの 接続設定を まとめて持つ Agent B API A‧Bの接続先と 認証設定を持つ Gateway API B Agent B API B 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 28
29. 接続先の呼び方で経路が3つに分かれる 一覧から選んで呼ぶMCP、APIなどにリクエストを中継するHTTP、モデルへの接 続をまとめるInference。まずはこの3つの呼び方があると押さえてください！ 利用場面と一緒に使い方を見ていきます！ ⼊⼝と接続先の認証 ∕ Policy‧Guardrails ∕ レート制限 ∕ 監視 呼び出すAgent Gateway MCPターゲット HTTPターゲット Inferenceターゲット パス /mcp パス /{targetName}/… パス /inference/v1/… ツールを⾒つけて呼び出す 個別の接続先へ転送する モデル名で接続先を選ぶ Lambda RuntimeのAgent BedrockなどのConnector Open API定義/API Gateway HTTP API 独⾃Provider MCPサーバー Memoryなど 検索など 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 29
30. Gatewayやれること多過ぎ！！！！！ こりゃ理解するのも一苦労だね・・・1つずつシンプルに見て いこう！ユースケースに従って考えていこう。 私 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 30
31. スーパーの在庫確認で考えてみよう 私が大好きなスーパーを例に「牛乳の在庫はありますか？」と聞かれた場面で考え ます。在庫を調べる処理をAgentから呼び、その後で発注の権限も考えてみましょ う！ ⽜乳まだ 在庫ありますか？ 商品コードを使って 在庫を調べよう 問い合わせ お客様 調査を依頼 店員 売り場を⼿伝うAgent 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 31
32. MCP ツールをつないで呼び出す 簡単な処理をGatewayに登録して、 Agentがツールを使うところまで見ていきましょう！ 32
33. まずはGatewayにツールを追加してみたいな！MCPサーバーとして使用してみ たい！ 私 いいね！！早速Lambda関数をGatewayに登録して接続する例を見ていこう！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 33
34. でツールをつないでみよう まずはMCPです。LambdaやAPIをツールとして登録しAgentが選んで呼び出して みます。在庫数を返すLambdaをつないでみましょう！ MCP 接続先 AgentCore Gateway MCP ツールを集約‧検索 Lambda API‧MCP ⽂書検索 Web検索 HTTP Agent ⾊々なものに中継 別のAgent 既存API Memory Inference モデル名で接続先を選ぶ 認証‧認可 内容の検査 Bedrock 他社モデル 利⽤量の制限 ログ‧監視 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 34
35. 複数のツールを1つの入口に集める Gatewayは複数の接続先のツールをまとめる仮想MCPサーバーです。Agentは /mcp エンドポイントで、一覧の取得とツールの呼び出しを行います。 Gateway /mcp ⼀覧取得‧呼び出し Agent ⼀覧‧実⾏結果 仮想MCPサーバー ターゲット：inventory get_stock 既存MCPサーバーの登録 Lambdaを呼ぶ 在庫確認 リクエストを中継 MCPサーバー 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 35
36. ターゲットは要件に合わせて選ぶ Lambda関数やAPI GatewayのREST APIステージ、OpenAPIやSmithyで定義し たAPIなどを登録できます。SaaSなどは組み込みのテンプレートも使えます！ （めっちゃターゲット多いですよね） MCP AgentCore Gateway MCPターゲット Lambda関数 API Gateway REST API API MCPサーバー 組み込み テンプレート 組み込み コネクタ 今回使う REST APIの ステージ OpenAPI スキーマ Smithyモデル URLを登録 連携サービス Managed KB Web Search 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 36
37. の処理とツール定義を用意する 在庫を調べる処理はLambdaに実装します。Agentがその処理を使えるよう「名 前・説明・入力」の条件をツール定義に書きます。 Lambda Lambdaで実⾏する処理 # 入力：商品コード ツール定義（Agentに伝える使い⽅） { "name": "get_stock", "description": "商品コードから在庫数を取得する", "inputSchema": { "properties": { "product_id": {"type": "string"} }, "required": ["product_id"] } {"product_id": "MILK-001"} 在庫確認のLambda # 結果：在庫数 {"stock": 12} 名前 説明 ⼊⼒の条件 ⽂字列 必須 } 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 37
38. を作ってLambdaを登録する ターゲットはGatewayに登録する接続先です。今回はinventoryという名前で、先 ほど用意したLambdaのARNとツール定義を登録します。Gatewayへの認証と Lambdaを呼ぶ権限も設定します。 Gateway AgentCore Gateway インバウンド認証 JWTやIAMを設定 Gateway実⾏ロール 対象Lambdaの実⾏を許可 ターゲット名：inventory get_stockのツール定義 ARNで指定 LambdaのARN 在庫確認のLambda 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 38
39. 登録したらAgentはどう使うの？ LambdaをGatewayに登録できたね！Agentには何を教えればいいの？ 私 GatewayのURLと認証情報を渡すよ。MCPでツールの一覧を取得すると、 在庫確認の使い方が分かるんだ。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 39
40. まずツールの一覧を取得する AgentがGatewayの/mcpエンドポイントへツールの一覧を取得するtools/listを 送ると、名前・説明・入力の定義が返ってきます。ツール名にはターゲット名が付 与され、inventory___get_stockという名前で一覧に返ってきます。 tools/list：ツールの⼀覧をください Agent 名前‧説明‧⼊⼒の定義を返す Gateway 返ってきたツールの1つ 商品コードが 必要なんだね inventory___get_stock 商品コードから在庫数を取得する product_id ⽂字列‧必須 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 40
41. 次にツールを呼び出す Agentがツールを呼び出すtools/callでツール名と商品コードを送ると、Gateway がLambdaを呼びます。この例では牛乳の商品コードMILK-001に対して在庫数12 を返します。 Agent Gateway 在庫確認 tools/call：inventory___get_stock product_id = MILK-001 stock = 12 ツールの実⾏結果を返す 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 41
42. 取得した結果を使ってAgentが回答する Agentはツールから受け取った在庫数を使って下記のように答えます！ 牛乳（MILK-001）の在庫は何本ありますか？ 私 在庫を確認したところ、12本あります。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 42
43. ツールを増やせるのは分かった！ でも数が増えたら全部の説明を毎回読むのは大変そうだね・・ 今回使うツールを先に探せないかな？ 私 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 43
44. 新入社員が使うSaaSを先輩に聞く例でまず考える 入社したばかりなら各種申請に使うSaaSを先輩に聞きますよね。使うサービスと 手順を教わってから自分で申請します。同様にAgentもまずSemantic Searchを 使って目的のツールを探し出し、その後に該当ツールを呼び出します。 1 新⼊社員 1 2 経費の申請は どこからできますか？ 経費精算はこのSaaSだよ 領収書を添付してね Semantic Searchでツールを探す 「⽜乳の在庫を調べたい」 Agent ツール名‧説明‧⼊⼒の仕様が返る 使い⽅を教わったら 新⼊社員が申請する 新⼊社員 先輩 2 教わった後に実⾏ 経費精算SaaS Agentがツールを呼び出す 商品コードを渡して在庫を確認 Agent この呼び出しで在庫数が返る ツール 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 44
45. ツールが集まったら今回使う候補を絞りたい すべてのツール定義を毎回モデルへ渡すと、使わない説明も入力に含まれます。何 百個もあったら大変ですよね。そこでSemantic Searchを使い一番やりたいこと に近いツールを見つけます。 ⽜乳の在庫を 調べたい 検索 Agent Gateway ツール群（名前‧説明‧⼊⼒条件を持つ） 在庫を確認 発注する 売上を集計 勤務を確認 Webを検索 申請を登録 配送を照会 返品を受付 会員を検索 ほか多数… 今回の候補（例） Semantic Search 在庫を確認 get_stock 定義をモデルへ渡す 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 45
46. 必要なツールを探してから呼び出す 検索するとツールの候補が返ります。検索ツールもtools/callで呼び、返された名 前と入力条件で次に在庫確認を実行します。 Gateway Agent 在庫確認 /mcp ① 検索ツールをtools/callで呼ぶ x_amz_bedrock_agentcore_search query：「⽜乳の在庫を調べたい」 候補：inventory___get_stock ② 選んだツールをtools/callで呼ぶ product_id = MILK-001 商品コードを渡して実⾏ 実⾏結果をAgentへ返す 在庫数12（例） 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 46
47. 認証・認可 使える人とどの操作を許可するか 誰の接続を許可するか、誰が何をしてよいか！ 大事なポイントですよね！！ 47
48. Agentからツールとして利用できるようになったね！！ただ、Gatewayの セキュリティってどうなの？無防備だと怖いよね・・・ 私 大丈夫！Gatewayの認証と認可を学んで安全に保護していこう！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 48
49. つながったら使える人と操作を決める MCPでツールを呼べるようになりました。次に誰からの接続を受け入れ、どの操 作を許可するかを接続先の権限と分けて考えます。 接続先 AgentCore Gateway MCP ツールを集約‧検索 Lambda API‧MCP ⽂書検索 Web検索 HTTP Agent ⾊々なものに中継 別のAgent 既存API Memory Inference モデル名で接続先を選ぶ 認証‧認可 内容の検査 Bedrock 他社モデル 利⽤量の制限 ログ‧監視 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 49
50. スマホのロック解除と銀行アプリのログインで考えてみる よくある例でスマホのロック解除と銀行アプリへのログインは別の認証ですよね。 GatewayもAgentから受け取る認証情報と、接続先を呼ぶために使う認証情報を 分けて設定します。 スマホのロックを解除する 銀⾏アプリにログインする 銀⾏アプリ ⾃分 パスコード •••• 端末が確認 インバウンド認証 Agent JWT ID ⾃分 パスワード ログイン Gateway アウトバウンド認証 実⾏ロール 銀⾏サービス 銀⾏が確認 Lambda 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 50
51. への認証と接続先への認証 Gatewayへの接続とGatewayから接続先を呼ぶときでは認証する相手が違いま す。前者がインバウンド認証、後者がアウトバウンド認証です。両方を設定して呼 び出しの制御を行います。 Gateway インバウンド認証 呼び出し元 アウトバウンド認証 Gateway Gatewayへの認証 誰からのリクエストを受け付けるか 接続先 接続先への認証 どの資格情報で接続先を呼ぶか 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 51
52. 入口で利用者を確かめて実行ロールでLambdaを呼ぶ インバウンド認証はJWT・IAM・AUTHENTICATE_ONLY・NONEから選べま す！この例はJWTで、検証したあとGateway実行ロールでLambdaを呼びます。 Gateway JWTを渡す Agent JWTに含まれる利⽤者 sub: clerk-01 利⽤者のJWTを検証 署名‧発⾏元などを確認 Gateway実⾏ロール lambda:InvokeFunction 実⾏ 在庫確認 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 52
53. の認証に通ってもAPIを呼べない？ Gateway Gatewayでインバウンド認証できたのに、その先のAPIから403が返ってき た・・・入口とは別物でここがアウトバウンド認証ってことかな？ 私 その通り！Gatewayを通っても、接続先のAPIには別の認証があるんだ。 何を渡すかはターゲットごとに設定するよ。誰の鍵で呼ぶかから見よう。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 53
54. アウトバウンド認証は誰の鍵で呼ぶかを決める アウトバウンド認証はGatewayが接続先を呼ぶときに見せる鍵のようなものです。 鍵は「Gatewayの鍵」と「頼んだ人の鍵」の2種類で、接続先がどちらを受け付け るかで選びます。 Gateway 接続先を呼ぶときの鍵 Gatewayの鍵 誰が頼んでも同じ権限 店員 どちらで呼ぶ？ 在庫API ⾒せられた鍵を確認 Agent 頼んだ⼈の鍵 ⼈ごとに権限が違う 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 54
55. の鍵で呼ぶと誰が頼んでも同じ権限になる Gatewayが自分の資格情報で接続先を呼ぶサービス認証（M2M）の方式です。店 員が頼んでも店長が頼んでもLambdaには同じGatewayとして届きます。 Gateway 店員 Gateway 店⻑ Gatewayの鍵 在庫確認 同じGatewayとして届く Agent 使える⽅式 IAMロール GATEWAY_IAM_ROLE（SigV4で署名） LambdaなどAWSの接続先 APIキー API_KEY（Identityに保管） キーで認証する外部のAPI OAuth（サービス⽤） Client Credentials（2LO）で取得 利⽤者に関係なく使う外部のAPI 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 55
56. 頼んだ人の鍵で呼ぶと人ごとに権限が変わる 頼んだ人の資格情報で接続先を呼ぶ、ユーザー委任型（3LO）の方式です。接続先 はその人として受け付けるので、店員と店長で見せるデータや使える操作を変えら れます。 店員 店⻑ Gateway 頼んだ⼈の鍵で 接続先を呼ぶ 店員の鍵 店⻑の鍵 在庫API 店員として受け付ける 在庫API 店⻑として受け付ける 使える⽅式 呼び出し元のIAM GatewayがAgentの代わりに署名する Runtime（HTTP）への接続で使える OAuth（本⼈の同意） 本⼈が許可して権限を任せる 外部サービスの本⼈のデータ トークン交換‧転送 利⽤者のJWTを接続先⽤に交換 またはそのまま接続先へ渡す 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 56
57. 使える鍵は接続先の種類で決まる どの鍵を使えるかはターゲットの種類で決まるので注意しましょう。今回の在庫確 認はLambdaなので、Gatewayの実行ロールで呼びます。 接続先の種類 Lambda関数 API Gatewayのステージ MCPサーバー・OpenAPI Smithyスキーマ AgentCore Runtime（HTTP） Gatewayの鍵 IAMロール IAMロール・APIキー IAMロール・APIキー・OAuth（サービス用） IAMロール・OAuth（サービス用） IAMロール・OAuth（サービス用） 頼んだ人の鍵 ― ― OAuth（本人の同意）・トークン交換 ― 呼び出し元のIAM・トークンの転送 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 57
58. ログインできたら何でも使ってよい？ 店員Aさんで無事ログインできました。その人に発注まで任せてよいのでしょう か？？「誰か」を確かめることと、「何を許すか」を決めることは別です！ 店員さんだと分かれば 発注もできるの？ Gatewayでチェック 認証 「誰か」を確かめる → 店員A 認可 発注を許すのは店⻑ → 店員Aは不可 店員Aの発注リクエストは接続先へ送らない 私 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 58
59. 店員と店長で使える操作を分ける この店では店員と店長に在庫確認を許可し、発注は店長に許可します。Agentが選 んだ操作と呼び出し元の権限を照らし合わせて判断します。 呼び出し元 在庫確認 店員 許可 店⻑ 許可 発注 拒否 許可 Gateway ＋ Policy Agentが選んだ操作 発注 呼び出し元 店員 表と照らし合わせる 発注処理へ送らない 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 59
60. の判定でGatewayがリクエストを止める Policyは「誰が・どの操作を・どの対象に行うか」をルールと照合します。 Gatewayが判定を依頼し許可されたリクエストを接続先へ送ります。 Policy ① ツールを呼ぶ ④ 許可なら転送 呼び出し元 Gateway ② 判定を依頼 拒否したリクエストは 接続先へ送らない 接続先 ③ ALLOW / DENY AgentCore Policy 誰が‧どの操作を‧どのGatewayで⾏うかをルールと照合 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 60
61. 認可をAgentの外に置いてルールを強制する 認可はAgentのコードにも書けますが、判定をGateway側に分離すればAgentの 実装に漏れがあっても接続先を呼び出す手前でリクエストを拒否できます。 Agentのコードで判定 Agentの外で判定 Agentのコード 認可コード（例） if can_order(user): call_tool() Gateway 許可時 発注 発注処理 各呼び出し経路に認可を組み込む 追加‧変更時にも、認可漏れがないか確認 Policyで判定 Agent 店⻑の発注を許可 店員の発注は拒否 店員の依頼 拒否を適⽤：ENFORCE 発注処理 接続先のIAMで、直接の呼び出しを制限 認可設定を変更する権限も分ける 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 61
62. 判定の元になるルールはどう書く？ Policyで判定するのは分かったよ！ その判定の元になるルールはどう書くの？ 私 Cedarという言語で書くんだ！ 簡単に紹介するね！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 62
63. 誰にどの操作を許可するかをルールにする ルールを書く言語がCedarというものです。「誰に・どの操作を・どのGateway」 で許可するかを宣言します。禁止ルールが優先され許可が1つもなければ拒否され ます。 必要な操作に許可を与える permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"inventory___get_stock", resource == AgentCore::Gateway::"<Gateway ARN>" ); 利用者による在庫確認を許可する例 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 63
64. 「発注しないで」という指示を権限でも守る Agentへの指示に加えツールを呼び出す時点でも判定します。店員の依頼で発注を 試みてもPolicyが拒否すれば、Gatewayは発注処理へリクエストを送りません。 Gateway 指⽰「発注しないで」 発注して 店員 発注をリクエスト 発注できるのは店⻑ 店員の権限 → 拒否 Agent 発注して 店⻑ Policyのルール 発注をリクエスト Agent 送らない 店⻑の権限 → 許可 発注処理 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 64
65. 送信する前に本文も検査したい 問い合わせの本文にメールアドレスが書かれているケースもあるな・・・ 送信する権限はあっても、この内容のままでは送りたくないな。 私 PolicyからAmazon Bedrock Guardrailsを呼び、本文を検査できるよ。 検査する項目と拒否する条件を指定しよう。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 65
66. による検査 送る文章の内容も検査できます。Amazon Bedrock Guardrailsで内容を検査 し、その結果の確信度としきい値をPolicyの拒否条件に使います。 Amazon Bedrock Guardrails 検知する対象 検知の例 有害なコンテンツ 暴力・憎悪・性的・不正行為などの表現（ContentFilter） プロンプト攻撃 ジェイルブレイク・プロンプトインジェクション・指示の漏えい（PromptAttack） 機密情報の混入 メール・電話番号・パスワード・AWSキーなど30種以上（SensitiveInformation） Guardrailリソースを別に作る必要はなく、Policyのルールへ検査条件を書いて利用できます。 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 66
67. 本文を検査して送信する前に止める 送信する権限があっても本文にメールアドレスを含めたくない場合があります。 Guardrailsで本文を検査し、スコアがしきい値を超えたらPolicyで拒否して Gatewayが送信ツールへのリクエストをブロックします。 tools/call ツール呼び出し 送信を⽌める Agent Gateway 判定依頼 検査する本⽂ 送信ツール DENY Policy Engine 連絡先は EMAILのスコア > 0.2 user@example.com 条件に当てはまるので拒否 本⽂を検査 0.8（例） Guardrails 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 67
68. 接続できることと操作してよいことは別 誰の依頼かを確かめるのが認証で、その人に在庫 確認や発注を許すかを決めるのが認可です！ Gatewayで接続し、Policyで任せてよい操作を 決めます！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 68
69. マネージド接続先 文書・Web検索・Memory AWSが提供しているマネージドな接続先を利用してGatewayを便利にしていきましょう！ 69
70. ツールの実装って全部自分でやる必要あるのかな？Web検索とか、ナレッ ジベース接続とか便利なものがAWSにあったりするの？？ 私 便利なものあるよ！！ここでは便利な接続先を見ていこうか！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 70
71. 回答に使う情報を増やすには 文書検索・Web検索・MemoryもAWSが用意したコネクタで簡単につなぐことが できます。Agentに何をして欲しいかに合わせて選びましょう！ 接続先 AgentCore Gateway MCP ツールを集約‧検索 Lambda API‧MCP ⽂書検索 Web検索 HTTP Agent ⾊々なものに中継 別のAgent 既存API Memory Inference モデル名で接続先を選ぶ 認証‧認可 内容の検査 Bedrock 他社モデル 利⽤量の制限 ログ‧監視 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 71
72. 社内の文書も調べさせたい 業務の手順書みたいな社内の文書もAgentに調べさせたいな。 PDFやテキストが社内に散らばってるんだけど。 サポート担当 それならManaged KB便利だよ！文書を同期しておけば、 Gatewayのコネクタから検索を呼べるんだ。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 72
73. マニュアルを開いてから答える 店舗マニュアルの内容を聞かれたら該当する箇所を調べてから答えますよね。 Agentも文書を検索し、その内容をもとに回答を生成します。この検索と生成を組 み合わせる仕組みがRAGです。RAGを作るのにManaged KBを使います。 店舗 マニュアル 発注 特売商品の発注って 誰に確認するんだっけ？ 店⻑に確認 書かれている条件を確かめて答える 店員 発注の項⽬を読む Managed KB ⽂書を検索 ⼈がマニュアルを調べるとき Agentも、必要な⽂書を検索して答える Gateway経由 本⽂と出典 ⾒つけた根拠と、質問をモデルへ渡す Agent 質問「特売商品の発注は？」 「店⻑に確認する」と出典を回答 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 73
74. 文書の取り込みと検索をManaged KBへ任せる この文書検索を使うには文書を取り込んで検索できる状態にしておく必要がありま す。Managed Knowledge Bases（Managed KB）なら、取り込みと検索基盤 の運用をAWSに任せられます。 あらかじめ⽂書を取り込む Managed KB データソースを同期 ⽂書の解析‧分割 S3の⽂書 例：業務の⼿順書 ⽂書を検索 Agent Retrieve 関連箇所‧出典 Gateway 検索結果 検索⽤の索引 関連する箇所を検索 本⽂と出典を返す 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 74
75. 文書の関連箇所と出典を使って答える たとえば店舗マニュアルをManaged KBへ取り込み、Gatewayのコネクタへ登録 します。Agentが必要なルールを検索すると、関連する本文と出典が返却されま す。Agentはその内容を使ってユーザーの質問に回答します。 発注ルールを検索 Agent 検索結果 Retrieve Gateway 本⽂と出典 Managed KB 返ってきた検索結果（例） 内容と出典を使って 回答しよう 「特売商品の発注は、店⻑に確認する」 出典：店舗マニュアルの「発注⼿順」 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 75
76. 社内文書には載っていない新情報は？ 社内ルールは調べられた！ 今月公開されたAWSの機能も調べたいな。 私 公開Webの情報はWeb Searchで探そう。 検索結果の出典も見ながら、社内文書と使い分けられるよ。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 76
77. で公開情報を調べる インターネット上の情報を検索したいときに使います。Amazonが運用するWebイ ンデックスに対して検索できます。（日本語検索の精度は少し怪しいので期待しす ぎに注意です・・・） Web Search Agent Gateway Web Search AgentCoreの新機能を調べたい 検索語と件数（5件）を渡す 本⽂‧URL‧タイトル‧公開⽇ 検索結果を返す 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 77
78. 前の相談を覚えていてほしい 少し話は変わるけど、作成したAgentに昨日の相談の続きをしたいんだけど、毎回、最初 から説明する必要があるの？ワイが作ったAgentすぐに物忘れするんだけど・・・ 私 LLMは前の会話を自動では引き継がないんだ！ Agentが会話履歴や好みなどを記憶するための方法を見てみよう。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 78
79. 前の会話は次の入力へ渡して使う LLM自体はステートレスで前の会話を自動では引き継ぎません。話の続きをするに はAgent側で履歴や好みを保存し、必要な情報を次の入力に加えます。その保存先 としてAgentCore Memoryを使えます。 前回の相談 前の会話を保存しておく 今回の相談 Agentが⼊⼒を組み⽴てる 今回の質問「Gatewayって何？」 「回答は⽇本語で」 保存 Agent AgentCore Memory 会話の履歴‧好みを保存 例：⽇本語での回答を希望 読む Agent LLMへ渡す⼊⼒ 今回の質問 ＋ ⽇本語で回答する指⽰ LLM⾃体はステートレス 前の会話も⼊⼒に含めて使う 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 79
80. AgentCore Memory AgentCore Memoryは会話の履歴や、会話から取り出した好み・事実を保存する サービスです。必要な記憶を読み出して次の相談に使います。まずはRuntimeから 直接使う構成を見てみましょう。 AgentCore Memory 会話を保存 Agent 必要な記憶を読み出す 短期記憶 「回答は⽇本語でお願いします」 設定した戦略で情報を抽出 ⻑期記憶 次の相談でも ⽇本語で答えよう 会話イベント 抽出した好み‧事実 好み：⽇本語での回答 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 80
81. の からMemoryを使える MemoryはRuntimeで動くAgentのコードからも直接使えます。会話を保存し、 抽出された好みなどを次の回答で参照します。 Runtime Agent AgentCore Runtime Agentのコード Memory IDを指定 SDKで保存‧取得 記憶を次の回答に使う 実⾏ロールにIAM権限 CreateEvent 会話を保存 AgentCore Memory 会話イベントを保存 「回答は⽇本語で」 RetrieveMemoryRecords 必要な⻑期記憶を検索 設定した戦略で抽出 ⾒つかった好み‧事実 ⻑期記憶（例） ⽇本語での回答を希望 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 81
82. あれ直接呼び出せるなら別にRuntimeでいいじゃん。 神野さんもよく直接呼び出していたよ！ 私 確かに直接でも全然いいよ！ ただメリットも少しあるんだ！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 82
83. を直接使えるのにGatewayを通すのはなぜ？ 誰の履歴かを確かめてから読ませたいとき、Gateway経由なら利用者のJWTを検 証して読める記憶や操作をPolicyで制限できるからです。Gatewayを通らない直 接アクセスは、Memory側のIAMでも止めます。 Memory 共有のIAMロールで直接使う例 AgentのIAM権限で呼び出す RuntimeのAgent 利⽤者に応じて、Agent側で記憶を選ぶ Memory 利⽤者のJWTでGatewayへ接続する 利⽤者のJWT RuntimeのAgent Gateway Policyで 記憶の所有者を照合 実⾏ロール Memory 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 83
84. マネージドな接続先を使いこなして、Gateway を簡単により便利なものに仕上げていこう！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 84
85. HTTP・モデル 接続をまとめる理由 何をまとめられるのか何が便利になるのか呼び出し方と一緒に見ていきましょう！ 85
86. MCPサーバーとして接続が主だったけど、GatewayってHTTPやモデルも集約 できるってあってなにこれ？？全然イメージできないんだけど・・・ 私 ぱっと見理解が難しいよね・・・なにをつなげられて何が嬉しいのか、ここで見 ていくよ！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 86
87. 既存のAPI・Agent・モデルにもつなぐ 次はHTTPとInferenceを確認してみましょう。既存のAPIや別のAgent、モデル への接続もまとめられます！ 接続先 AgentCore Gateway MCP ツールを集約‧検索 Lambda API‧MCP ⽂書検索 Web検索 HTTP Agent ⾊々なものに中継 別のAgent 既存API Memory Inference モデル名で接続先を選ぶ 認証‧認可 内容の検査 Bedrock 他社モデル 利⽤量の制限 ログ‧監視 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 87
88. 呼ぶときはエンドポイントの後ろのパスで分かれる エンドポイントは1つで後ろのパスで行き先が変わります！ /mcp MCPターゲット 例 tools/list や tools/call を送る ツールをまとめた1つのMCPサーバー /< ターゲット名>/invocations Runtimeターゲット ターゲット名>/<APIのパス> HTTPパススルー ターゲット名>/memories/… コネクタ（Memory） 例 /return-agent/invocations Gateway Gatewayの エンドポイント /< 例 /stock-api/items/MILK-001 /< RuntimeのAgentに依頼する ターゲット名を外して接続先のAPIへ 例 /my-memory/memories/<ID>/events MemoryのAPIをそのまま呼ぶ /inference/v1/… Inferenceターゲット 例 /inference/v1/chat/completions modelの値で提供元を選ぶ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 88
89. 今あるAPIの呼び方もそのまま使える？ Agentが既存の在庫APIみたいなものを呼ぶ場合を想定している？？これを Gateway経由でアクセスするって感じなのかな？ 私 そう！HTTPパススルーっていうやり方で、リクエストをそのまま中継するん だ。既存の呼び出し方のまま、接続の認証や制御をまとめられるよ！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 89
90. 自分でつなげるのになぜGateway？ あれ、APIを呼ぶコードはAgentからでも書けるよね。そこにGatewayを挟むと 何が嬉しいの？ 私 接続先の認証設定や利用ルールを、Agentごとに管理するのは大変だよね。そこ をGateway側にまとめられるんだ。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 90
91. サービスカウンターから売り場へ取り次ぐ場面を考えてみよう スーパーのサービスカウンターで担当売り場と確認したい商品を伝える場面を例に 比較しながら考えてみます。 乳製品担当の⽅に ⽜乳の在庫を聞きたい サービスカウンター 指定された売り場へ 商品と⽤件を取り次ぐ お客さん 宛先とHTTPリクエストを指定 stock-api Agent GET /items/MILK-001 Gateway 在庫を確認 この⽜乳を調べる 回答「在庫12個」 GETリクエスト 登録先へHTTPで中継 接続先の認証を引き受ける 乳製品担当 応答を返す 在庫API 指定した商品を調べる 応答例：在庫12個 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 91
92. 接続先の認証設定をAgentごとに持たせずに済む 各Agentで接続先の認証設定を持つと追加や更新のたびに複数の設定を確認しま す。Gateway側にまとめれば各AgentはGatewayへ認証し接続先ごとの認証は Gatewayに任せます。 Agentごとに接続設定を持つ Gateway側にまとめる APIの認証設定 Agent A モデルのAPIキー API Agent A APIの認証設定 Agent B API APIの認証設定 モデルのAPIキー Agent B APIの認証設定 Agent C Gateway モデル モデルのAPIキー Agentが増えると、設定する場所も増える モデルのAPIキー Agent C モデル 各AgentはGatewayへ認証する 接続先の認証設定は管理側で⽤意する 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 92
93. 利用ルールもGateway側で管理できる 新しいAgentを追加するときもGateway側で許可する操作と検査を設定でき、共 通の判定処理を各Agentに実装する手間を減らせます。 管理者 リクエスト 複数のAgent ルールを設定 Gateway API Policyで許可する操作を決める Guardrailsで⼊出⼒を検査する 別のAgent モデル ログ出⼒を設定し、Gatewayを通ったリクエストの失敗や拒否を調査可能 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 93
94. ターゲットにも種類がある！ RuntimeのAgentに頼むRuntimeターゲットとURLへそのまま通すHTTPパスス ルー、先ほど紹介したMemoryなどを呼ぶコネクタがあります。 HTTP HTTPターゲット（パスにターゲット名を付けて呼ぶ） Runtimeターゲット ARNで指定 HTTPパススルー URLで指定 別の設定 コネクタ Inference 組み込み モデル名で指定 モデルの推論を 提供元へ振り分ける RuntimeのAgentに リクエストを変換せずに通す Memoryなどを 依頼する protocolTypeで種類を選ぶ ⽤意された形で呼ぶ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 94
95. パススルーで既存のリクエストをそのまま通す HTTPパススルーはターゲット名を外し接続先のベースURLの後ろへ同じパスで転 送します！本文もそのまま転送されます。 HTTP Agent HTTPリクエストを送る Agentが送るリクエスト https://<Gatewayのエンドポイント> GatewayのURL /stock-api/items/MILK-001 Gateway stock-apiを外して転送 Gatewayが在庫APIへ送るリクエスト https://api.example.com stock-apiの接続先 /items/MILK-001 既存の在庫API /items/MILK-001 は在庫APIにもともとあるパスで、そのまま渡る 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 95
96. 別のAgentにも仕事を頼める？ 今あるAPIはパススルーでそのまま通せたね！ 調査や判断そのものを、別のAgentに任せたい時もあるんだよね！ 便利なAgentが別にいるのよ！ 私 それはRuntimeターゲットの出番！ ARNを指定すれば、Gateway経由でRuntimeのAgentに頼めるよ！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる Agent君 96
97. 次はRuntimeのAgentに頼む HTTPターゲットのうち、RuntimeのAgentに頼むのがRuntimeターゲットで す！登録にはRuntimeのARNを使います。コンソールではエージェントターゲット から作ります。 HTTPターゲット（パスにターゲット名を付けて呼ぶ） Runtimeターゲット ARNで指定 HTTPパススルー URLで指定 別の設定 コネクタ Inference 組み込み モデル名で指定 モデルの推論を 提供元へ振り分ける RuntimeのAgentに リクエストを変換せずに通す Memoryなどを 依頼する protocolTypeで種類を選ぶ ⽤意された形で呼ぶ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 97
98. 別のAgentに調査や判断を任せる RuntimeのAgentはRuntimeターゲットで外部のAgentはHTTPパススルーで通し ます。どちらもA2Aのまま届くので相手のAgent Cardを見て依頼します。 A2A Agent同⼠で依頼と結果をやりとりする共通仕様 調査を依頼する 依頼するAgent 担当Agentへ転送 Gateway 結果を返す 担当するAgent 結果を返す 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 98
99. モデルを変えるたびに接続を直すの？ Agentごとに使うモデルがバラバラなんだよね… モデルを変えるたびに接続先を直すのが大変！ 私 それならInferenceターゲット！ モデル名を指定すればGatewayが提供元へ振り分けるよ！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 99
100. モデルはInferenceターゲットでまとめる モデルはHTTPターゲットとは別のInferenceターゲットで扱います！Bedrockに 加えてOpenAIやAnthropicの提供元もまとめられます。 HTTPターゲット（パスにターゲット名を付けて呼ぶ） Runtimeターゲット ARNで指定 HTTPパススルー URLで指定 別の設定 コネクタ Inference 組み込み モデル名で指定 モデルの推論を 提供元へ振り分ける RuntimeのAgentに リクエストを変換せずに通す Memoryなどを 依頼する protocolTypeで種類を選ぶ ⽤意された形で呼ぶ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 100
101. 共通の注文端末でお店と料理を選ぶ例で考えてみる フードコートに共通の注文端末があれば1台の端末からお店と料理を選べます。 InferenceではAgentが使いたいモデル名を指定します。提供元が増えても接続先 や認証情報をGatewayでまとめて管理できます。 フードコートの場合 うどん屋 うどん屋さんの かけうどんを1つ！ お客さん Inferenceの場合 ラーメン屋 ほかのお店も 選べる Bedrock 他社モデル 共通の注⽂端末 別の候補も登録 Gateway 選んだお店へ 注⽂を送る modelを指定 Agent モデル名で送り先を選ぶ 接続先‧認証を管理 例：Bedrockのモデル 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 101
102. モデル名で登録した提供元へ振り分ける Inferenceターゲットはリクエストのモデル名から接続先を選びます。対応する提 供元はConnectorで接続し、独自の設定が必要ならProviderでURLや操作を登録 します。 modelの値（登録内容） 推論リクエスト クライアント Gateway model の値で 送り先を選ぶ リクエストの本⽂（例） "model": "<モデル名>" 接続のしかた 送り先 Bedrockのモデル 組み込みConnector Bedrock Mantle OpenAI‧Anthropic 組み込みConnector OpenAI / Anthropic 独⾃に登録したモデル 独⾃プロバイダー URL‧操作を設定 独⾃の接続先 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 102
103. 提供元のAPIキーを各Agentへ配らずに使う モデル提供元のAPIキーをIdentityに預けてGatewayがリクエストに付与して転送 します。キーの更新先を保管庫にまとめられ、各Agentへ配り直す手間がなくなり ます。 Identity 提供元のAPIキー 要約Agent キーを付与 キーを取得 モデル提供元A Gateway 相談Agent モデル提供元B 各AgentはGatewayへ認証し、提供元のキーはGatewayが使う 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 103
104. モデルを増やすときも利用ルールを統一できる HTTPのときと同じでモデルもGatewayにまとめれば複数チームのAgentから同じ ルールで使えます。新しいモデルは管理側で接続を用意し、開発側は同じエンドポ イントでモデル名を指定すれば使えます！ 管理者が接続先を追加‧変更 モデル名を指定 Agent Agent側は、対応するAPIで モデルを選んで呼び出す Gateway Bedrock 利⽤できるモデルを登録 提供元への接続‧認証を管理 Policy‧Guardrailsを適⽤ 他社モデル 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 104
105. 一見必要性がわかりづらいですが、エンドポイントを集約する ことで認証・認可などがやりやすくなるしガバナンスが効かせ やすくなりますね！！！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 105
106. 運用 使い続けるための備え 運用的な側面も軽く見てみましょう！ 106
107. 使う人が増えて呼び出しが集中したら？ Gatewayに集約するの便利だからほかのチームにも使ってもらいたいな。 一度にたくさんGateway経由で呼び出されても大丈夫？ 私 接続先の処理能力には限りがあるよ！ 利用量に枠を作って、呼び出しの集中を抑えよう。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 107
108. レート制限もできる 呼び出しの回数やモデルのトークン量、同時に処理する数を制限可能です。 死守したい利用量に合わせて組み合わせ、利用者やモデルなどの観点で制限する枠 を決めていきます。 requests tokens connections 何回呼ぶか ⼊⼒＋出⼒の量 同時に処理する数 処理中 秒‧分 Inference / 分 処理中 処理中 受理〜応答完了 利⽤者‧チーム‧ターゲット‧ツール‧モデルなどのキーで枠を分ける 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 108
109. GatewayとAgentはつなげたけど、Agentの処理が失敗するな・・・何が原因 なんだろう・・・ 私 ログを見て切り分けしていこう！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 109
110. 失敗したらどこで止まったかを調べる 呼び出しが失敗したらどこで止まったのかをCloudWatchのメトリクスやログで追 います。2026年9月に一般提供されたCloudWatch Omniならトレースから評価 まで1つの画面で確認できます！（ただ東京リージョン非対応・・・） 画⾯ Gatewayのログ出⼒先を設定 Amazon CloudWatch CloudWatch Logsへ配信する メトリクス‧ログで調べる 回数‧時間‧失敗や拒否の内容 メトリクス‧ログ‧スパン Gateway GenAI Observabilityで追う Agentの実⾏と関連する処理 処理A ツールA ツールB 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 110
111. は狙ったツールを使ってくれた？ Agent ログで呼び出しが成功したかは確認できそう！ Agentが在庫確認のツールを呼んだかその選び方も評価したいな！ 私 AgentCore Evaluationsで、実行の記録を評価できるよ！ 呼び出しの有無に加えてツール選択や引数も確かめてみよう。 Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 111
112. でツールの使い方を評価する Agentの実行をトレースに記録しツールの選択や引数を評価します。AgentCore Evaluationsは会話の文脈に合っていたかを判定し、スコアと理由を返却します。 AgentCore Evaluations Agent 在庫を確認 実⾏を 記録 ツール呼び出し Gateway CloudWatchのトレース 利⽤者の依頼‧会話の⽂脈 選んだツール‧引数‧実⾏結果 Agent側でテレメトリを設定 商品コード 在庫確認 get_stock AgentCore 記録を評価 Evaluations ツール選択は適切？ 引数は合っている？ スコアと理由を返す 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 112
113. ツール実行の確認と内容の確からしさをチェックする AgentCore Evaluationsを活用して呼び出したかどうかや適切なツールを使ってい るかを評価可能です！継続的にチェックするのが大切です。 テストケース（例） 依頼 「MILK-001の在庫を調べて」 期待する呼び出し inventory___get_stock 判定の観点 評価のしかた ツールを実⾏したか 独⾃の評価（コードベース） 名前‧引数の⼀致 トレースで実際の呼び出しと照合 その場⾯に合う ツールを選べたか 組み込み評価 依頼に合う 引数を渡せたか 組み込み評価 Builtin.ToolSelectionAccuracy product_id = "MILK-001" 対象の呼び出しがない ケースも試す Builtin.ToolParameterAccuracy 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 113
114. を一元化とガバナンスの視点で使う Gatewayは機能が多く複雑に感じますよね。接続先や認証設定をまとめる一元化 と、利用ルールを適用するガバナンスの視点で見ると存在意義を理解しやすくなり ます。 Gateway AgentCore Gateway ツール Lambdaなど ⼀元化 リクエスト Agent 接続先と認証設定をまとめる MCP‧HTTP‧Inference HTTP API‧Agent ガバナンス 利⽤ルールを適⽤して状況を把握する 認証‧認可‧利⽤量の制限‧ログ モデル 推論の提供元 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 114
115. まずはどこから試そう？ 使う場面が少し分かってきたよ！ でも自分で作るとなると、何から始めればいいかな？ 私 まずはツールを1つGateway経由で呼んでみよう！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 115
116. 最初はGateway経由でツールを1つ呼ぶことを試す まずはAgentからGatewayを通して1つのツールを呼ぶところまで試してみましょ う！下記のような構成です。 在庫数は？ 利⽤者 回答 ツールを呼ぶ Agent 実⾏結果 MILK-001 Gateway 在庫数12 在庫確認 Agentの回答（例） ⽜乳の在庫は12本です。 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 116
117. つずつ確認していこう！ 動かなかったらどこが原因かを処理プロセスに従って追って突き止めましょう！ 1 ④ ③ ② ① Lambdaを単体で確認 tools/callで呼ぶ tools/listで⼀覧を取得 Agentが回答する 「在庫は12です」 同じ在庫数12が返る ツール名を確認 inventory___get_stock MILK-001 → 在庫数12 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 117
118. 必要な接続先と制御を組み合わせた構成 1つのツールが成功したら要件に必要な接続先と利用ルールを加えます！ 下記は認証・認可・利用量の制限・監視を組み合わせたモリモリな構成例です。 AWS WAF Web ACLを関連付け リクエスト Agent AgentCore Gateway Lambda ⼊⼝の認証：JWT‧IAM Runtime Policy‧Guardrails 呼び出し回数‧トークン量を制限 Amazon CloudWatch ログ‧メトリクスで拒否や失敗を調べる Memory 既存API Bedrock 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 118
119. ってそもそも使わないとダメ？ Gateway いろいろ聞いて身も蓋もないけど・・・Gatewayって使わないとダメ？？ 私 無理に使わなくて大丈夫！困りごとに合う機能から足していこう。 接続先が1つで制御もいらないなら直接呼ぶのもありだよ！ Agent君 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 119
120. どんなときにGatewayを使う？ Agentが1つでつなぐ先も少ないなら直接呼べば十分だと思います！ ただ、複数のAgentから同じツールを使い外部への接続も統制したくなったら、 Gatewayを挟むと楽になります。 Agentごとに直接つなぐ Gatewayを挟む ツール利⽤ Runtime 在庫確認 ツール利⽤ SaaS MCPサーバー Runtime Gateway ツール利⽤ Runtime 在庫確認 在庫確認 SaaS MCPサーバー Runtime Policyで認可も まとめてかけられる SaaS MCPサーバー 同じツールの接続をAgentごとに持つ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 120
121. GatewayはAgentの外部接続と利用ルールをまとめる入口で す！接続先に合わせて方式を選び、使える人と許可する操作を 決めて運用していきます！ まずは既存のツールを1つつないで呼ぶところから試しましょ う！必要な機能をどんどん足していきましょう！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 121
122. 補足資料とブログもぜひ見てください Gatewayをもっと知りたい方へ補足資料も用意しました！ 最新のアップデートや試した結果はブログに書いています！ Gatewayをもっと知る 最新情報を追いかける DevelopersIO 神野 雄大 アップデートや 実際に試した結果を紹介しています！ Speaker Deckで補足資料を見る dev.classmethod.jp/author/yjinn/ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 122
123. おまけ・宣伝（Amazon Bedrockの本を書きました！） RAGとAIエージェントの構築から評価・運用までをまとめました！！！ 業務でも組み込んでみたい方に読んでもらえたら嬉しいです！！！ RAGとAIエージェントで進める業務効率化 Amazon Bedrock 実践ガイド 技術評論社 2026年11⽉4⽇ 発売予定！！！ 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 123
124. おわりに ご清聴ありがとうございました！！！ 今日の話が、Gatewayを使ってみるきっかけになれば嬉しいです！ このあとも、GatewayやAgentCoreの悩みがあれば気軽に声をかけてください！ Gateway‧AgentCoreの相談 このあとも気軽に話しましょう！ なんでも聞いてください！ 今の構成にGatewayは必要？ 既存のAPIやツールにつなげたい 認証‧認可や運⽤で迷っている 神野 基礎 › MCP › 認証・認可 › マネージド接続先 › HTTP・モデル › 運用 › まとめ › 試してみる 124