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