Share
Embed
Slide 1
Slide 1 text
AgentCore Gatewayを
使ってみよう！
補足資料
コンサルティング部
神野
雄大（Jinno Yudai）
Slide 2
Slide 2 text
本編はSpeaker Deckからご覧ください
Gatewayの役割や使い方を基礎から知りたい方はまず本編をご覧ください！
この補足では40分の登壇で語りきれなかった部分を熱く説明しています！！！！
speakerdeck.com/yuu551/agentcore-gateway-o-tsuka-te-miyou
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
2
Slide 3
Slide 3 text
をもっと知りたい方に向けて作りました！
本編で話しきれなかった機能やGatewayの中の仕組みを接続先の登録から認証・
認可や運用の備えまで詳しく紹介します！
Gateway
何をつなげられる？
Gatewayって⾯⽩そう！
ほかに何ができるの？
Gateway
接続の集約
Agent
ツール
API‧Agent
認証‧認可などの制御
モデル
Gatewayの中では何をしている？
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
3
Slide 4
Slide 4 text
補足も量が多いね…
補足もページ数が多いね・・・
全部読むのは大変そうだな・・・
私
全部読まなくて大丈夫だよ！章の扉にどんなときに読む章かを書いておいたよ！
気になる章から開いてね！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
4
Slide 5
Slide 5 text
Lambdaターゲット
本編の在庫確認を具体的に動かそう！
本編で見た登録の流れを実際のコードと合わせて見てみます！
5
Slide 6
Slide 6 text
本編の在庫確認を自分でも動かしたい
本編の在庫確認を自分の環境でも動かしてみたい！
登録の流れは分かったけど実際には何を書けばいいの？
私
Gatewayの作り方、Lambdaのコード、送るリクエストを順に見よう。
うまく呼べないときの切り分け方もまとめたよ！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
6
Slide 7
Slide 7 text
なら簡単に作れる
GatewayはAgentCore CLIで簡単に作れます！順に足してdeployすれば完成で
す！agentcore と打てば対話形式のウィザードでも作れます。
AgentCore CLI
1
add gateway
Gatewayの設定を⾜す
2
add gateway-target
Lambdaのターゲットを⾜す
3
add agent
Agentを⾜す
4
deploy
CDKでまとめて作る
在庫確認のGatewayとAgentを作る流れ（オプションは後のページで）
agentcore create --project-name InventoryProject --no-agent
agentcore add gateway --name InventoryGateway --authorizer-type AWS_IAM
agentcore add gateway-target --name inventory --type lambda-function-arn ...
agentcore add agent --name InventoryAgent ...
agentcore deploy
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
7
Slide 8
Slide 8 text
在庫数を返すLambdaを用意する
接続の確認用に牛乳の商品コードMILK-001を受け取ったら在庫数12を返す関数を
用意します。Gatewayからはツール定義の入力（product_id）がそのままevent
に入って届きます。
lambda_function.py：固定の在庫数を返すLambda
def handler(event, context):
product_id = event["product_id"]
if product_id != "MILK-001":
return {"error": "商品コードを確認してください"}
return {"product_id": product_id, "stock": 12}
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
8
Slide 9
Slide 9 text
ツール定義をtools.jsonに書く
ツールの名前と説明と入力の条件をtools.jsonに書きます。
tools.json：在庫確認ツールの定義
[{
"name": "get_stock",
"description": "商品コードから在庫数を取得する",
"inputSchema": {
"type": "object",
"properties": {
"product_id": {"type": "string", "description": "在庫を調べる商品のコード"}
},
"required": ["product_id"]
}
}]
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
9
Slide 10
Slide 10 text
登録したツールで牛乳の在庫を調べる
GatewayとLambdaを紐付けしたら初回はAgentを介さずに、この本文を送って
通るかを確認します！
body.json：送るリクエストの本文
{
"jsonrpc": "2.0", "id": 1, "method": "tools/call",
"params": {
"name": "inventory___get_stock",
"arguments": {"product_id": "MILK-001"}
}
}
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
10
Slide 11
Slide 11 text
ツールの呼び出し結果
tools/callの応答ではLambdaが返した値がcontentに入ります。MILK-001と在庫
数12が入っていればツールを呼んで調べた結果だと分かります！
tools/callの応答（実際に返ってきたもの）
{
"jsonrpc": "2.0", "id": 1,
"result": {
"isError": false,
"content": [{
"type": "text",
"text": "{\"product_id\":\"MILK-001\",\"stock\":12}"
}]
}
}
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
11
Slide 12
Slide 12 text
の からGatewayへつないで呼ぶ
JWT認証ならStrandsのMCPClientにURLとトークンを渡すとAgentがツールを
選んで呼びます！IAM認証ならSigV4の署名が要ります。
Strands Agent
StrandsのAgentからGatewayのツールを使う例
from strands import Agent
from strands.tools.mcp import MCPClient
mcp_client = MCPClient(
url=gateway_url,
# 末尾が/mcpのGatewayのURL
headers={"Authorization": f"Bearer {token}"},
)
with mcp_client:
agent = Agent(tools=mcp_client.list_tools_sync())
agent("商品コードMILK-001の在庫を調べて")
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
12
Slide 13
Slide 13 text
はツールの結果を使って答える
AgentにMILK-001の在庫を聞くとGatewayのツールで調べた在庫数をもとに答え
てくれます！
Agent
agentcore invoke の実行結果
$ agentcore invoke "商品コードMILK-001の在庫を調べて"
商品コードMILK-001の在庫数は**12個**です。
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
13
Slide 14
Slide 14 text
答えだけでなくツールの呼び出しも確かめる
「12個です」と答えても本当に調べたかは回答だけでは分かりません。商品コー
ドと返された在庫数と回答が一致するかログなどもみておきましょう！
Agent
Gateway
在庫確認
inventory___get_stock
product_id = MILK-001
商品コードを関数へ渡す
stock = 12
stock = 12 をAgentへ返す
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
14
Slide 15
Slide 15 text
色々なターゲットについて確認する
OpenAPIの定義やMCPサーバー、Slackなどの
組み込みテンプレートを使う方法も確認します！
15
Slide 16
Slide 16 text
既存のAPIやMCPサーバーもつなぎたい
本編では既存のAPIやMCPサーバーもつなげると聞いたよ！
他のターゲットについても知りたい！
私
対応しているターゲットも多いからね！具体的に登録方法や違いを見ていこう！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
16
Slide 17
Slide 17 text
の定義を使って既存APIをツールにする
すでに在庫確認のAPIがあるならその定義を使えます！OpenAPIに記述したURL・
操作・引数をGatewayへ登録すると、Agentから呼べるMCPツールとして公開で
きます。
OpenAPI
Gateway
登録したOpenAPI定義
GET /stock/{product_id}
tools/call
Agent
ツールへ変換
公開するツール：get_stock
⼊⼒：product_id
既存の在庫API
HTTPで
呼び出す
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
17
Slide 18
Slide 18 text
公開済みAPIの定義を取り込む
API GatewayのREST APIなら公開済みステージの定義を取り込めます！
下記では在庫確認のGETメソッドを選びAgentに必要な操作を公開します。
Gatewayのターゲット
API Gateway
取り込むステージを選ぶ
REST APIの公開済みステージ
GET /stock/{product_id}
POST /orders
同⼀アカウント‧リージョンの公開API
定義を取り込む
公開するパス‧メソッドを絞る
Agentには在庫確認を公開
GET /stock/{product_id}
発注の操作は選択しない
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
18
Slide 19
Slide 19 text
サーバーの実行場所
MCPサーバーはAgentCore Runtime上に実装可能です！ALB + Fargateのよう
な既存MCPサーバーもGatewayに登録できます。ALBはIAM（SigV4）の署名を
検証しないので、接続先への認証はOAuthかAPIキーにします。
MCP
実⾏場所を選べる
Runtime上のMCP
Gateway
/mcp
Agent
URL＋接続先への認証
ツール
ツール
ツール
ツール
ツール
Streamable HTTPで接続
既存のツールを取り込む
既存MCPサーバー
ツール
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
19
Slide 20
Slide 20 text
ツール一覧を取得するタイミング
接続先のツールが変わったときの一覧の更新方法は2通りあります。DEFAULTは同
期済みの一覧を、DYNAMICは呼び出し時に取得した一覧を使います。ツールの更
新頻度や利用者ごとに取得したい一覧が変わるかどうかで選びます。
DEFAULT：同期した⼀覧を返す
Agent
Gateway
DYNAMIC：呼び出し時に取得する
MCPサーバー
登録時に同期
同期した⼀覧を持つ
Agent
Gateway
MCPサーバー
tools/list
tools/list
tools/list
その時点の⼀覧
同期した⼀覧を返す
⼀覧を返す
ツール変更時に再同期
tools/list
利⽤者に応じた⼀覧も、その時点で取得する
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
20
Slide 21
Slide 21 text
普段使っているSaaSもつなげたい
自前のAPIやMCPサーバーはこうつなぐんだね。
SlackやJiraにもつなげたいけれど、定義を毎回書くのは大変そう…。
私
対応するSaaSなら組み込みテンプレートを選べるよ！
使える操作を確かめて接続先と認証を設定すれば始められるんだ。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
21
Slide 22
Slide 22 text
の接続には組み込みテンプレートも使える
SlackやJiraなどのAPI定義は簡単に設定できるよう組み込みテンプレートに用意さ
れています。コンソールで対応テンプレートを選んで接続先と認証を設定すれば、
AgentからMCPツールとして呼び出せます。
SaaS
組み込みテンプレート
AgentCore Gateway
MCP
Agent
1
組み込みテンプレートを選ぶ
Slack
Jira
メッセージを投稿 課題を作成‧取得
ほかの
SaaSも
対応するAPIの定義を利⽤
2
接続先ごとの認証を設定
利⽤するSaaSの権限も確認
Slack
Jira
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
既存の
SaaS API
22
Slide 23
Slide 23 text
認証設定の深掘り
インバウンド認証、Agentと利用者の権限、アウトバウンド認証へのトークンの渡し方を深掘
りします！
23
Slide 24
Slide 24 text
つながったツールを誰に使ってもらう？
本編ではインバウンド認証とアウトバウンド認証を分けていたよね。
実際に作るとき誰の資格情報で接続先を呼ぶかは、どう決めればいい？
私
インバウンド認証の方式と接続先へ渡す資格情報を順に選ぼう！
Agent自身の権限か、利用者の権限かで設定が変わるんだ。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
24
Slide 25
Slide 25 text
インバウンド認証で受け入れる相手を決める
あらためてGatewayで呼び出し元をチェックするのがインバウンド認証です。
受け入れたい相手に合わせてIAMやJWTの方式を選びます。
受け入れたい相手
AWSの認証情報を持つAgent
IdPでログインした利用者
IAMで誰かだけ確かめたい
認証・認可を別の構成へ任せる
選ぶ方式とインバウンド認証で確認すること
AWS_IAM：IAM（SigV4）の署名と呼び出し許可を確認
CUSTOM_JWT：JWTの署名・発行元・宛先などを確認
AUTHENTICATE_ONLY：署名だけ確認。認可は別で判定
NONE：Gatewayでは認証・認可を行わない
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
25
Slide 26
Slide 26 text
あれ？どっちもIAM（SigV4）で確かめるよね？
あれ？AUTHENTICATE_ONLYもIAM（SigV4）の署名を確かめるんだよね？
AWS_IAMと何が違うの？？
私
いいところに気づいたね！どっちも誰なのかは確かめるんだ。
違うのは呼んでいいかまでGatewayが判定するかどうかだよ！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
26
Slide 27
Slide 27 text
と
の違い
どちらもIAM（SigV4）の署名で誰なのかを確かめます。AWS_IAMはIAMで呼ん
でよいかまでGatewayが判定し、AUTHENTICATE_ONLYはその判定をPolicyや
接続先に任せたい場合に使います！ちょっとややこしいですね・・・
AWS_IAM AUTHENTICATE_ONLY
AWS_IAM
Gatewayが許可まで判定
IAM（SigV4）で署名
1 署名が正しいか（誰なのか）
許可あり
2 IAMでInvokeGatewayを許可？
呼び出し元
AUTHENTICATE_ONLY
許可の判定はほかへ任せる
IAM（SigV4）で署名
呼び出し元
Gateway
Gateway
1 署名が正しいか（誰なのか）
呼んでよいかは判定しない
接続先
許可なしはここで拒否
そのまま渡す
ここで判定する
‧Policy
‧Interceptor
‧接続先（Runtimeなど）
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
27
Slide 28
Slide 28 text
の同意後の処理をAWSに任せる
ユーザー委任型（3LO）では、同意とログインした利用者を紐付ける処理が必要で
す。AgentCore Identityの同意ポータルを使うとこのための画面やAPIを自作す
る手間が減ります。
3LO
以前の検証で⾃作していた部分
同意ポータルを使う場合
AgentCore Identity
コールバック画⾯
外部サービスでの同意後に戻る
同意ポータル
接続画⾯‧同意後の紐付け
API Gateway
Lambda
DynamoDB
利⽤者との紐付けをアプリで実装
画⾯と完了処理をAWSに任せる
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
28
Slide 29
Slide 29 text
同意ポータルで接続してからAgentを使う
利用者はポータルからGitHubなどの外部サービスへログインし、Agentによるデー
タアクセスを許可します。GatewayのインバウンドはJWT認証にし、ポータルと
同じOIDC発行元を使います。
① 先にブラウザで接続を許可
接続‧同意
同意ポータル
利⽤者
OIDCでログインしてConnect
GitHub
本⼈が許可
紐付ける
AgentCore Identity
同意と利⽤者を紐付けて保管
② 同意後にAgentから利⽤
Agent
利⽤者
利⽤者に紐づくトークンを取得
利⽤者のJWT
Gateway
JWT認証
本⼈のトークン
GitHub API
本⼈のデータを返す
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
29
Slide 30
Slide 30 text
同意ポータルの画面で見るとこうなる
利用者はポータルでGitHubをConnectして許可します。Connectedになればチャ
ットのAgentが本人のGitHubを使えます！
1
未接続の状態
2
Connectを押す！
GitHubで許可するとConnected
本⼈のトークンをIdentityが保管
3
チャットから本⼈のGitHubを使える
Gateway経由で githubmcp___get_me が呼ばれた
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
30
Slide 31
Slide 31 text
呼び出し元の権限を接続先へ引き継ぐ
GATEWAY_IAM_ROLEはGateway実行ロールで、
CALLER_IAM_CREDENTIALSは呼び出したAgentのIAMロールで接続先を呼び
ます！
Gateway実⾏ロールで呼ぶ
Agent
AgentのIAMロール
GATEWAY_IAM_ROLE
Gateway
Gateway実⾏ロール
接続先が確認する権限
接続先の権限をGatewayにまとめて管理したいとき
Gateway実⾏ロール
呼び出したAgentのIAM権限を引き継ぐ
Agent
AgentのIAMロール
AWSの接続先
CALLER_IAM_CREDENTIALS
Gateway
Agentごとに接続先で使える権限を分けたいとき
AgentのIAMロール
AWSの接続先
接続先が確認する権限
AgentのIAMロール
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
31
Slide 32
Slide 32 text
トークンを交換する場合とそのまま渡す場合
利用者のJWTを接続先にも使う構成では、接続先用のトークンへ交換するOBOと
同じJWTをそのまま転送する方法があります。接続先が受け付ける宛先や権限に合
わせて選びます。
OBO：接続先⽤のトークンへ交換する
認証基盤
交換を依頼
Agent
トークンA
認証基盤へ交換を依頼し
接続先⽤の権限を得る
トークンB
Gateway
交換したトークンB
接続先API
同じトークンA
接続先API
JWT_PASSTHROUGH：受け取ったトークンを転送する
Agent
トークンA
Gateway
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
32
Slide 33
Slide 33 text
はどんなときに使う？
例えば店長のトークンを発注API向けのトークンに交換すると、店長の権限と
Agentの身元を保ったまま不必要な情報を除いたトークンで発注APIを呼ぶことが
できます。
OBO
AgentCore Identity
OBOで交換
店⻑のJWT
店⻑
Gateway
交換したトークン
Agent
発注API
店⻑として受け付ける
OBOでトークンを交換するとき
そのまま転送するとき（Token passthrough）
‧接続先向けに範囲を絞ったトークンにしたい
‧接続先が受け取ったトークンを⾃分で検証する
‧利⽤者とAgentの両⽅の⾝元を伝えたい
‧Gatewayは本⼈確認だけして認可は任せる
‧追加の同意なしに次の接続先へ任せたい
‧トークンの宛先や権限は変わらない
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
33
Slide 34
Slide 34 text
認可とGuardrails
操作とリクエスト内容をチェックしよう
Cedarのルールをどう拡張するか見てみましょう！
34
Slide 35
Slide 35 text
Cedarの細かい話も聞きたいな！
本編ではルールの例を見ただけだから自分で書けるか不安…。
私
いいね！書き方をもう少し深掘りしていこう！
ルールの形と条件に使える値と判定の順番を押さえれば読み書きできるよ！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
35
Slide 36
Slide 36 text
のルールは効果・対象・条件の3つで書く
1つのルールは効果（permitかforbid）と対象（誰が・何を・どこで）と条件
（whenかunless）でできています。在庫確認を店舗スタッフに限って許可する例
で見てみましょう！
Cedar
Cedarのルールの基本の形
permit(
// 効果：許可ならpermit、拒否ならforbid
principal is AgentCore::OAuthUser,
// 誰が：JWTでログインした利用者
action == AgentCore::Action::"inventory___get_stock",
// 何を：ツール
resource == AgentCore::Gateway::""
// どこで：Gateway
)
when {
// 条件：すべて満たすと当てはまる
principal.hasTag("role") &&
principal.getTag("role") == "store-staff" &&
context.input.product_id like "MILK-*"
};
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
36
Slide 37
Slide 37 text
条件に書ける値は呼び出し元とツールの入力
whenの中では呼び出し元の情報とツールへの入力を参照できます。呼び出し元の
書き方はインバウンド認証の方式で変わります。
参照するもの
JWTのクレーム
IAMのARN
ツールの入力
入力の有無
書き方の例
principal.getTag("role") == "admin"
principal.id like "*:assumed-role/AdminRole*"
context.input.amount < 500
context.input has shippingAddress
使える場面
CUSTOM_JWT
AWS_IAM
どちらでも
どちらでも
タグは hasTag で存在を確かめてから getTag で値を比べます。
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
37
Slide 38
Slide 38 text
複数のルールが当てはまったときの判定
Cedarは当てはまるルールをすべて評価してから結果を決めます。forbidが1つで
も当てはまれば拒否になり、どのルールにも当てはまらなければ拒否です。
当てはまったルール
結果
forbidが1つでもある
拒否（permitより優先）
permitだけがある
許可
どれにも当てはまらない
拒否（デフォルトで拒否）
forbidのunlessは「このforbidを外す条件」です。unlessで許可が増えることはありません。
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
38
Slide 39
Slide 39 text
認可する操作名をスキーマに合わせる
ルールのactionに書く名前は接続方式によって形が変わります。MCPはツール名、
HTTPはスキーマに定義したパステンプレートをそのまま操作名として照合しま
す。
対象
MCPツール
Runtime
Inference
Memory connector
actionの例
inventory___get_stock
order-agent___POST:/invocations
models___POST:/v1/chat/completions
memory___POST:/memories/{memoryId}/events
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
39
Slide 40
Slide 40 text
で操作をまとめて許可する
Cedarのactionには「*」のようなワイルドカードを書けません。まとめて許可し
たいツールを1つのターゲットに登録し、in でそのターゲット名を指定します。こ
の単位をAction Groupと呼びます。
Action Group
read-toolsに登録したツールをまとめて許可する
permit(
principal,
action in AgentCore::Action::"read-tools",
resource == AgentCore::Gateway::""
);
== は1つの操作、in はターゲットに含まれるすべての操作を指します
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
40
Slide 41
Slide 41 text
豆知識：書いたCedarは登録するときにチェックされる
Policyを登録するとAWSがルールの中身を確かめます。validationModeのデフォ
ルトは少しでも変なものがあったら失敗（FAIL_ON_ANY_FINDINGS）で、問題の
あるルールは登録できません！
チェック
スキーマ
自動推論
確認するポイント
存在しないツール名や型の違い
許可しすぎ・拒否しすぎ・効き目なし
無視できる？
無視できない！
IGNORE_ALL_FINDINGSで無視できる（非推奨）
問題を無視して登録するIGNORE_ALL_FINDINGSも設定できますが、本番では非推奨です。
ちなみに試しに条件のないpermitを登録したら「Overly Permissive（許可しすぎ）」と弾かれまし
た・・・！
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
41
Slide 42
Slide 42 text
Policyっていきなり反映されちゃうの？しばらく様子見たいんだけど・・・
私
様子見モードも提供されているよ！！！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
42
Slide 43
Slide 43 text
ログで判定を試してから拒否を有効にする
ログ記録モード（LOG_ONLY）では判定の内容をログに残したまま拒否はされま
せん。一方強制適用（ENFORCE）へ切り替えるとそのリクエストは遮断されま
す。LOG_ONLYでログを見てENFORCEに切り替えていきましょう！
LOG_ONLY：判定を記録し、リクエストは通す
Agent
同じリクエスト
Policyの判定：DENY
判定の内容をログに残す
実⾏する
API
WAFのカウントモードみたいだね
ENFORCE：拒否の判定を実⾏に反映する
Agent
同じリクエスト
Policyの判定：DENY
停⽌
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
API
43
Slide 44
Slide 44 text
を通らない直接の呼び出しは接続先側で止める
PolicyはGatewayを通ったリクエストだけを判定します。接続先を直接呼べるとル
ールを迂回できるので、接続先側でIAMポリシーを駆使してGatewayからの呼び出
しに絞りましょう！
Gateway
接続先側でGateway実⾏ロールだけ許可
Lambda（発注処理）
呼び出せる主体をIAMで限る
Gateway
呼び出し元
Runtime
Policyで判定
IAMはリソースポリシー∕JWTは許可するGatewayを登録
Memory
リソースポリシーで絞り、ほかは明⽰的に拒否
Gatewayを通らない直接の呼び出し
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
44
Slide 45
Slide 45 text
の検査結果をルールへどう書く？
Guardrails
本編では本文をGuardrailsで検査して送信を止めていたよね。
Cedarをどうやって書くの？？
私
リクエストのどの項目を調べるかと判定のしきい値をルールに書くよ！
ここではRuntimeへ送る文章を例にコードの書き方を見てみよう。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
45
Slide 46
Slide 46 text
内容の検査を拒否ルールに組み込む
Runtimeへ送るプロンプトを暴力的なコンテンツかどうか検査し、しきい値を超え
たら拒否する例です！
when guardrailsの書き方
forbid (principal,
action == AgentCore::Action::"agent___POST:/invocations",
resource == AgentCore::Gateway::"")
when guardrails {
BedrockGuardrails::ContentFilter(["VIOLENCE"],
[context.input.prompt])
["VIOLENCE"].confidenceScore.greaterThan(decimal("0.2"))
};
通常のwhenとwhen guardrailsは別のルールに分ける。
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
46
Slide 47
Slide 47 text
何を検査するかはデータパスで決まる
ルールのcontext.input.promptはリクエスト本文のpromptを指します。フィールド名
を変えたら入力スキーマとルールも合わせましょう。存在しない項目や別の項目を検査し
ていないか確認しましょう。
Runtimeへ送るJSON
Guardrailsへ渡す値
{
"prompt": "確認したい本文",
promptを選ぶ
確認したい本⽂
"customer_id": "C-001"
}
context.input.prompt
⼊⼒スキーマも揃える
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
47
Slide 48
Slide 48 text
検知のしきい値は想定されるユースケースで決める
実際に使うユースケースを整理して、LOG_ONLYで誤検知と見逃しを比べてからし
きい値を決めていきましょう。
しきい値を低くする
実際に使う⽂章で決める
正常な問い合わせまで⽌める（誤検知）
しきい値を⾼くする
⽌めたい内容を通す（⾒逃し）
ユースケースを想定
LOG_ONLYで⽐較
ENFORCE
通常の問い合わせ
拒否したい⽂章
判断が分かれる⽂章
スコアと判定を記録
誤検知と⾒逃しを確認
しきい値を調整
拒否を適⽤
同じ⼊⼒例で
結果を再確認
期待する判定も決める
検査結果は揺れ得る
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
48
Slide 49
Slide 49 text
アウトプットもチェックできる？？
Guardrailsってアウトプットもチェックできるの？？
私
できるよー！！suppressOutput使えばアウトプットのチェックも可能です！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
49
Slide 50
Slide 50 text
応答を止めるsuppressOutputの書き方
効果にsuppressOutputを書くと実行後の応答をGuardrailsで検査して止めます！
通常のCedarやtemporalの条件は別のルールに書きます。
suppressOutputの書き方
suppressOutput (principal,
action == AgentCore::Action::"agent___POST:/invocations",
resource == AgentCore::Gateway::"")
when guardrails {
BedrockGuardrails::SensitiveInformation(["EMAIL"],
[context.output.text]).maxConfidenceScore()
.greaterThan(decimal("0.5"))
};
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
50
Slide 51
Slide 51 text
リクエストの拒否と応答の抑止はタイミングが違う
入力を見て止めるforbidは接続先を呼ぶ前に判定します。suppressOutputは実行
後の応答を抑止するので違いを押さえておきましょう。
リクエスト受付
forbid
⼊⼒を⾒て⽌める
suppressOutput
実⾏後の応答を抑⽌
接続先へ送る
接続先が実⾏する
応答を返す
接続先へ送らない（実⾏されない）
実⾏済み
応答を返さない
処理は取り消されない
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
51
Slide 52
Slide 52 text
ちなみに・・・
2026年9月に試したときはJSONの応答は403で止まり、ストリーミングはメール
アドレスごと届きました！止めたい出力はストリーミングにしない構成にしましょ
う・・・いつか対応されるといいですね！
通常の応答（JSON）
まとめて検査して⽌める
403 Output blocked by policy
呼び出し元
Gateway
{"text": "…@example.com"}
RuntimeのAgent
Guardrailsで応答を検査
ストリーミング（SSE）
分割されたまま届く
Gateway
呼び出し元
そのまま利⽤者へ流す
taro.
yamada@exa
mple.com
RuntimeのAgent
200で届いた
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
52
Slide 53
Slide 53 text
履歴を使う認可
Temporal Policies
返金処理を例に前の呼び出しで確かめた承認を今回のリクエストと照合します！
53
Slide 54
Slide 54 text
人が承認した内容で実行してほしい
返金のような操作は過去の呼び出しの履歴も使って判断したいな。
前に承認を確かめた注文と金額と同じかどうかとか！
私
利用者の権限に加えて前の呼び出しで確かめた承認結果も条件にできるよ！
本編のスーパーがネットスーパーで返品を受け付ける場面で順に見ていこう。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
54
Slide 55
Slide 55 text
返品した商品の代金を返す場面で考える
ネットスーパーで返品された商品の代金3,000円を返す場面を考えてみます。管理
者が注文と金額を承認しその記録をシステムへ保存し、Agentは承認確認APIで事
前に承認されたものを対象に申請します。
注⽂123について、3,000円の返⾦を承認する
管理者
承認を保存するシステム
注⽂：123
承認⾦額：3,000円
承認済み：true
APIで承認記録を確認
確認した後に
返⾦を依頼する
返⾦担当Agent
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
55
Slide 56
Slide 56 text
承認済みかどうかを条件に加える
この注文と金額が承認済みのものか確認したいですよね。変なリクエストが承認さ
れたくないですし。今回使うTemporal Policiesでは、前の呼び出しの応答を履歴
に残して今回のリクエストと照合できます。
前の呼び出しの結果
今回の返⾦リクエスト
check_refund_approval
order_id：123
amount：3,000
approved：true
refund
order_id：123
amount：3,000
履歴と照合
同じセッション
指定した時間内
承認確認APIの応答を記録
条件が合えば返⾦を許可
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
56
Slide 57
Slide 57 text
承認確認と返金を同じ履歴につなげる
Agentは承認確認と返金の両方に同じPolicyセッションIDを付けます。Gatewayは
承認確認APIの応答をその履歴へ記録します。注文番号と、呼び出しをまとめるセ
ッションIDは別の値です。
Agent
Gateway
承認確認API
承認を確認（session = S-001）
注⽂123‧⾦額3,000円
approved = true
結果を返し、同じ履歴へ記録
次の返⾦も session = S-001
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
57
Slide 58
Slide 58 text
承認された注文と金額に一致する返金を許可する
3つの条件を突き合わせて判定します。条件に合わない依頼は返金APIへ送らずに止
めます。
前の承認確認の応答
今回の返⾦リクエスト
注⽂
123
注⽂が⼀致
注⽂
123
⾦額
3,000円
⾦額が⼀致
⾦額
3,000円
確認から1時間以内
リクエストした時刻
応答した時刻
10:00
10:20
3つの条件を満たすので、返⾦APIへの呼び出しを許可
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
58
Slide 59
Slide 59 text
過去の承認と今回の返金をコードで照合する
先ほどの条件をコードにすると次のようになります。承認記録と今回の依頼で、注
文と金額が同じかを照合します。1時間という期限もこのルールに含めます。この
Cedarを拡張した書き方はDogwoodと呼ばれています。
承認確認の応答を参照するTemporal条件の例
permit (principal, action == AgentCore::Action::"orders___refund",
resource) when temporal {
formerly within 1h
AgentCore::Action::"orders___check_refund_approval"::response{
eventResource: resource, output.approved: true,
input.order_id: context.input.order_id,
input.amount: context.input.amount
}
};
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
59
Slide 60
Slide 60 text
条件を部品ごとに読む
前のページのルールを部品に分けてみます。どの操作の・どの記録を・何と照合す
るかを順に書いていきます。
Temporal
書き方
when temporal { … }
formerly within 1h
Action::"…"::response
eventResource: resource
output.approved: true
input.amount: context.input.amount
意味
セッションの記録を使う条件のブロック
1時間以内に一度でもあったか（最大24時間）
その操作が成功して返した記録（request・errorも選べる）
同じGatewayの記録に絞る。毎回必ず書く
記録した応答の値を条件にする
記録した入力と今回の入力が同じか照合する
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
60
Slide 61
Slide 61 text
ほかにも書けるTemporal条件
formerly以外にも回数や合計を条件にできます。返金の場面ならこんな使い方がで
きます！
書き方
formerly within
since within
count
sum
できること
前にあったかを確かめる
ある操作のあとに別の操作が起きていないか
回数を数える
入力の値を合計する
返金での使い方イメージ
承認済みの返金に限って許可
1回の承認で返金を1回に限る
5分に3回を超えたら拒否
1日の返金額の合計で上限
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
61
Slide 62
Slide 62 text
Memoryコネクタ
利用者ごとに記憶の参照権限を意識する
ほかの人の記憶を読ませない設定を見てみます！
62
Slide 63
Slide 63 text
共有するMemoryで誰の記憶を読めるようにする？
RuntimeからMemoryを使う流れは本編で分かったよ！
同じ保存先をみんなで使うと他の人の記憶も読めたりしない・・・？
私
ここからはGateway経由で利用者ごとに読める記憶を制限する例を見よう！
接続先の登録からJWTと記憶の持ち主を照合する条件まで確かめていくよ。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
63
Slide 64
Slide 64 text
保存先を固定するだけでは利用者を分離できない
memoryIdは接続するMemoryの保存先を決めます。1つの保存先に複数の利用者
の記憶が入るので、取り出すときに所有者を照合する条件を別に用意します。
同じMemory mem-XXXX
memoryIdを指定
利⽤者A
利⽤者Aのイベント
actorId：user-A
⾃分の会話‧記憶
利⽤者Bのイベント
同じ保存先に
両⽅が⼊る
actorId：user-B
別の⼈の会話‧記憶
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
64
Slide 65
Slide 65 text
短期イベントの持ち主をJWTと照合する
ログインした人が他人のactorIdを指定して読めないようにします。この例では検
証済みJWTのsubとリクエストのactorIdを比べ、一致する場合に許可します。
検証済みJWT
リクエストに含まれる対象
actorId = user-A
sub = user-A
この例ではsubを
actorIdに使っている
Policyで照合
⼀致 → ⾃分の記憶を許可
actorId = user-B
不⼀致 → 他⼈の記憶を拒否
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
65
Slide 66
Slide 66 text
記憶の所有者とログインした利用者を照合する
先ほどの絵で書いた条件はCedarで記載すると下記のようになります！subクレー
ムが存在しているか、subとactorIdが一致しているかチェックする条件を記載しま
す。
actorIdとJWTを照合する条件
when {
principal.hasTag("sub")
&& context has input
&& context.input has actorId
&& context.input.actorId == principal.getTag("sub")
}
特定アクションを許可するpermitに付ける条件部分の例。
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
66
Slide 67
Slide 67 text
長期記憶は検索するnamespaceを照合する
長期記憶も制御したいですよね。利用者ごとのnamespaceに整理し、IdPが発行し
たクレームに許可する範囲を持たせ、検索リクエストのnamespacePathと比較し
制御を実施します。
検証済みJWT
利⽤者
user-A
namespaceクレーム
/users/user-A
記憶の検索リクエスト
Policyで
⼀致を確認
＝
操作
RetrieveMemoryRecords
namespacePath
⻑期記憶のnamespace
/users
user-A
user-B
users/user-A
⼀致する検索範囲を許可
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
67
Slide 68
Slide 68 text
Claude CodeからGatewayを使おう！
Claude CodeをGatewayにつないで試してみます！
68
Slide 69
Slide 69 text
作った検索ツールをClaude Codeでも使いたい
Gatewayに登録した文書検索のツールを
普段使っているClaude Codeからも使える？
私
同じGatewayを接続先として登録すれば使えるよ！
認証方式に合わせて接続し、取得した文書を根拠に答えられるか確かめよう。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
69
Slide 70
Slide 70 text
から社内文書を根拠に答えてもらう
Claude CodeからGatewayの検索ツールを呼ぶとManaged KBにある設計資料の
関連箇所と出典を取得できます。接続後はその内容を根拠に回答や実装を進められ
るか確かめます。
Claude Code
Retrieve
社内の設計資料を検索
Claude Code
検索結果を返す
Gateway
関連箇所と出典
Managed KB
設計資料の根拠を⾒て、回答や実装へ進む
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
70
Slide 71
Slide 71 text
インバウンド認証でつなぎ方が変わる
Claude Codeからのつなぎ方はGatewayのインバウンド認証で変わります。JWT
認証なら個人利用のClaude Code、チームはClaudeのコネクタでつなぐなどの使
い分けもできます！IAM認証ならMCP Proxy for AWSに署名を任せます。
1
個⼈：Claude CodeにOAuthのログインを任せる
2
チーム：Claudeのカスタムコネクタでつなぐ
JWT
Claude Code
claude.ai
Gatewayの
インバウンド認証は？
IAM
MCP Proxy for AWSに署名を任せる
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
71
Slide 72
Slide 72 text
認証① 個人ならClaude CodeにOAuthのログインを任せる
トークンのないリクエストにGatewayは401を返しどのIdPでログインすればよい
かを返却します。Claude Codeはそれを受けてブラウザでのログインを進め、取得
したトークンを付けて呼びます。
JWT
Claude Code
Gateway
CognitoなどのIdP
① トークンなしで呼ぶ
② 401とログイン先の案内
③ ブラウザでIdPにログイン
④ コールバックでトークンを受け取る
⑤ トークンを付けて呼ぶ
登録してログインする
claude mcp add --transport http --client-id "$CLIENT_ID" --callback-port 8080 \
company-docs "$GATEWAY_MCP_URL"
claude mcp login company-docs
# IdPのアプリに http://localhost:8080/callback を登録しておく
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
72
Slide 73
Slide 73 text
認証② チームならClaudeのカスタムコネクタでつなぐ
TeamやEnterpriseプランでは管理者がGatewayのURLをコネクタとして組織に登
録できます！メンバーはConnectで各自ログインすれば使えるので、個人でのやや
こしい設定は回避できて組織として使うならいいですね。
JWT
Anthropicのクラウド
Connectでログイン
claude.aiのコネクタ
GatewayのURLを登録
利⽤者
CognitoなどのIdP
コールバックURLを登録
トークン
OAuthのClient IDを指定
Secretが要るなら登録
トークンを付けて呼ぶ
Gateway
インターネットから届くURL
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
73
Slide 74
Slide 74 text
コネクタを追加するとログイン方法が検出される
claude.aiのコネクタ追加画面でGatewayのURLを入れるとログインが要ることが
検出されました！今回のIdPはDCRに対応しないCognitoなので、登録済みの
Client IDを使う設定を選びます。
1
ログインが要ることを検出
Gatewayが返す案内から「今すぐサインイン」
2
⾃前のOAuthクライアントを使う
CognitoはDCR⾮対応。登録したClient IDを⼊れる
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
74
Slide 75
Slide 75 text
にログインするとツールが表示される
Connectを押すとCognitoのログイン画面が開きます。ログインするとGatewayの
ツールがコネクタに並び、使う前に承認を求める設定になっていました。
Cognito
1
Cognitoにログイン
利⽤者本⼈として
2
Gatewayのツールが並ぶ
inventory___get_stock。使う前に承認を求める設定が既定
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
75
Slide 76
Slide 76 text
チャットからGatewayのツールを呼べた！
在庫を聞くとClaudeがツールを使ってよいか確認してきます。許可すると
GatewayがLambdaを呼び在庫12個と答えてくれました！
2
1
ツールを使う前に確認
Gatewayのツールの結果で答える
Lambdaが返した在庫12個
⼀度だけ許可‧常に許可‧拒否
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
76
Slide 77
Slide 77 text
にツールを足したら一覧を更新する
Gatewayにツールを足してもコネクタの一覧はそのままです。メニューのツールリ
ストを更新で、Gatewayの一覧を取り直すこともできます。
Gateway
1
Gatewayにツールを⾜す
ターゲットを追加‧定義を更新
2
Gatewayの⼀覧が変わる
MCPの取り込みは同期も要る
3
コネクタで⼀覧を取り直す
「ツールリストを更新」を押す
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
77
Slide 78
Slide 78 text
認証ならMCP Proxy for AWSに署名を任せる
IAM認証のGatewayを呼ぶにはリクエストへのIAM（SigV4）の署名が必要です。
PCでMCP Proxy for AWSを起動しておくとクライアント側に署名処理を持たず
に接続できます。
IAM
⾃分のPC
stdio
Claude Code
MCP Proxy for AWS
IAM（SigV4）の署名を
付けて転送する
署名済み
/mcp へ転送
Gateway
IAM認証
署名を確かめて受け付ける
PCのAWS認証情報
InvokeGatewayを許可しておく
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
78
Slide 79
Slide 79 text
HTTPパススルーを深掘りしよう！
既存のAPIやMCPサーバー、別のAgentを
変換せずにそのまま通すしくみをもう少し見てみよう！
79
Slide 80
Slide 80 text
正直あえて選ぶ理由がわからない…
HTTPパススルーって正直あえて選ぼうとは思わないんだよね…
既存のAPIならOpenAPIでツールにすればよくない？
私
そう思うよね！分かれ目はAgentにツールとして選ばせたいかなんだ。
ツールにしない呼び方もあるから、そこを掘っていこう！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
80
Slide 81
Slide 81 text
ツールにして呼ぶかそのまま通すか
本編のおさらいですが、MCPと違ってHTTPパススルーはリクエストを変換せず、
パスに付けたターゲット名を外して今のリクエストのまま転送します！
MCPターゲット
ツールとして呼ぶ
Agentが送るリクエスト（抜粋）
Agent
POST /mcp
"method": "tools/call"
"name": "inventory___get_stock"
"arguments": {"product_id": "MILK-001"}
HTTPターゲット
Gateway
ツール名からLambdaを呼ぶ
今のリクエストのまま中継する
Agentが送るリクエスト（抜粋）
Agent
在庫確認のLambda
POST /stock-api/check
{"product_id": "MILK-001"}
Gateway
既存の在庫API
POST /check
stock-apiを外して転送
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
81
Slide 82
Slide 82 text
に選ばせないAPIはパススルーを使ってみる
注文の確定のようにコードで決まった順に呼びたい外部APIもあります！宛先を
Gatewayに替えればAPIキーはGatewayが付けてくれて認証を肩代わりします。
LLM
開発者
注⽂の確定はLLMに任せず
コードで決まった順に呼びたい
Agentのコード（抜粋）
Gateway
# 利用者が確認したら注文を確定する
requests.post(
f"{GATEWAY_URL}/order-api/orders",
json=order, headers=gateway_auth)
APIキーを付ける
注⽂API
宛先をGatewayに替えるだけ
APIキーはIdentityに預けてGatewayが付けます。
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
82
Slide 83
Slide 83 text
接続先への認証も5つから選べる
パススルーでも接続先への認証はGatewayが担ってくれます！接続先が受け付ける
方式に合わせて選びましょう！
方式
IAM（SigV4）
OAuth
呼び出し元のIAM
トークンのパススルー
APIキー
Gatewayがすること
Gatewayのロールで署名する
Identityから取ったトークンを付ける
呼び出した人のIAMで署名する（インバウンドがIAMのとき）
受け取ったJWTを検証してそのまま渡す
保管庫のAPIキーをヘッダーに付ける
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
83
Slide 84
Slide 84 text
サーバーもそのまま中継できる？
MCP
既存のAPIは中継できたね！MCPサーバーも中継できるの？
MCPターゲットと何が違うんだろう。
私
できるよ！MCPサーバーへのリクエストもHTTPパススルーで中継できるんだ。
ツールを取り込むMCPターゲットとは経路が違うよ。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
84
Slide 85
Slide 85 text
サーバーを中継するか取り込むか
同じMCPサーバーでも中継ならサーバーの一覧と名前がそのまま使え同期もいりま
せん。ただSemantic Searchで探したいならMCPターゲットで取り込みが必要で
す。
MCP
HTTPパススルーで中継する
MCPターゲットで取り込む
Gateway
MCPサーバー
Agent
送る先
Gateway
MCPサーバー
Agent
送る先
POST /docs/mcp
ツール名 search_docs
POST /mcp
ツール名 docs___search_docs
‧1つのMCPサーバーをそのまま中継する
‧複数のサーバーを1つの⼀覧にまとめる
‧サーバーの⼀覧とツール名をそのまま使う
‧Semantic Searchで候補を探せる
‧同期はしない（⼀覧は毎回サーバーから取得）
‧ツール定義が変わったら同期し直す
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
85
Slide 86
Slide 86 text
どう選択するのがいいんだろう・・・？
うーん・・・まずはAgentにツールとして選ばせたいかで分けるのかな？選ばせな
いならRuntimeのAgentかどうか、それ以外はHTTPパススルー・・・？正直バチ
っとしたユースケースは私もまだ悩み中です！
Agentにツールとして選ばせたい？
はい
MCPターゲット
Lambda‧OpenAPI‧MCPサーバーを取り込む
いいえ
相⼿はRuntimeのAgent？
はい
Runtimeターゲット
ARNを指定する
いいえ
HTTPパススルー
私
どれを選べばいいんだろう‧‧‧
MCP‧CUSTOMから選ぶ
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
86
Slide 87
Slide 87 text
モデル
複数のモデルをまとめて呼ぼう
Gatewayでモデルをまとめるケースをもう少し深掘りしてみましょう！
87
Slide 88
Slide 88 text
モデルを登録してSDKから呼んでみたい
色々なモデルをGatewayに統合できるのはわかったよ！
OpenAIのSDKから試すには何を登録すればいいの？
私
組み込みコネクタと独自の接続先を登録する方法を見よう！
登録したらモデル名を確かめてSDKの接続先URLをGatewayへ変えるよ。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
88
Slide 89
Slide 89 text
用意された接続設定でモデルを使う
Amazon Bedrockのモデルへつなぐ例です。組み込みコネクタならconnectorId
を1つ指定すればモデル名やパスの読み替えをGatewayが自動でやってくれます！
他にもコネクタはopenai、anthropicなど用意されています！
Gateway
OpenAI SDKから送る
connectorId: bedrock-mantle
モデル名は短くてOK
コネクタがやってくれる
claude-opus-4-7
1
モデル名の頭に anthropic. を補う
2
呼び出しパスを接続先に合わせる
3
使える操作とモデル⼀覧を⽤意する
Amazon Bedrock
正式なモデルIDで届く
anthropic.claude-opus-4-7
選べる組み込みコネクタと接続先への認証
bedrock-mantle
openai
anthropic
Gatewayの実⾏ロール（IAM）
APIキー
APIキー
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
89
Slide 90
Slide 90 text
独自の接続先には操作パスとモデルを登録する
組み込みコネクタにない接続先はproviderで登録します。コネクタが自動でやっ
ていたことを次の4つとして自分で書きます！
Gateway
OpenAI SDKから送る
providerで⾃分で登録する4つ
Azureで付けたデプロイ名
1
endpoint：接続先のURL
デプロイ名でモデルを呼ぶ
my-deployment
2
path→providerPath：パスの対応
my-deployment
3
models：使えるモデル名
4
認証：APIキーを預ける
Azure AI Foundry
②のパスの対応：/inference のあとのパスを接続先のパスへ読み替える
Gatewayに届くパス（path）
接続先へ送る先（endpoint＋providerPath）
/v1/chat/completions
https://<
リソース名>…/openai/v1/chat/completions
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
90
Slide 91
Slide 91 text
使えるモデルとIDはGatewayに確認してみる
Gatewayのモデルは管理者があとから足したり変えたりします。開発者は「どのモ
デルをどのIDで書けばいい？」と迷いそうです。モデル一覧のエンドポイントをコ
ールして、返ってきたIDをそのままmodelに入れればOKです！
ターゲットを⾜す‧変える
管理者
Gateway
bedrock-mantle
Bedrockのモデル
my-openai
別のプロバイダー
どのモデルを
どのIDで書けばいい？
開発者
モデル⼀覧のエンドポイントをコール
GET /inference/v1/models
{"data": [
{"id": "bedrock-mantle/deepseek.v3.2"},
ターゲット名/モデルID
このIDをそのまま⼊れる！
{"id": "bedrock-mantle/mistral.devstral-2-123b"},
"model":
…（その他）
"bedrock-mantle/deepseek.v3.2"
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
91
Slide 92
Slide 92 text
に合わせてURLと認証を設定する
OpenAI SDKとAnthropic SDKはURLへ付けるパスが異なります。base_urlを使
うSDKに合わせGatewayの認証方式に応じた資格情報も用意します。
SDK
設定するもの
OpenAI SDKの
base_url
Anthropic SDKの
base_url
JWT認証
IAM認証
Gatewayへ接続するときの指定
https:///inference/v1
https:///inference
Gatewayが検証するJWTをapi_keyへ渡す
IAM（SigV4）で署名（サービス名bedrock-agentcore）。
InvokeGatewayを許可
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
92
Slide 93
Slide 93 text
使い慣れたライブラリからGatewayを呼ぶ
OpenAI SDKからGatewayに登録したモデルを呼ぶ例です。GatewayのJWTを渡
し、modelにターゲット名付きのモデルIDを指定します。
JWT認証のOpenAI SDK例
from openai import OpenAI
client = OpenAI(
base_url="https:///inference/v1",
api_key=jwt_token)
response = client.chat.completions.create(
model="models/", messages=messages
)
JWTとmessagesを用意し、を利用するモデルIDへ置き換える。
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
93
Slide 94
Slide 94 text
モデルやHTTPの呼び出しもCedarで制御する
モデルを呼ぶInferenceターゲットも既存APIを中継するHTTPパススルーもPolicy
で判定できます。下はモデルへのリクエストの本文をGuardrailsで検査する例で、
ENFORCEは既定で拒否するので全体を許可するpermitも入れています。
Bedrockのモデルへのリクエストを検査する例
permit (principal, action, resource is AgentCore::Gateway);
forbid (principal,
action == AgentCore::Action::"bedrock___POST:/v1/chat/completions",
resource == AgentCore::Gateway::"")
when guardrails {
BedrockGuardrails::ContentFilter(["VIOLENCE"], [context.input.messages])
["VIOLENCE"].confidenceScore.greaterThan(decimal("0.2"))
};
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
94
Slide 95
Slide 95 text
を使う場合はプロバイダーごとにポリシーを1本ずつ書いたよ
BedrockとAzureの2つのターゲットをaction inで1本にまとめると私の検証では
provider型のAzure側だけ正常なリクエストまで403になりました。ターゲットご
とに1本ずつ書くとどちらも期待どおり動きました。
Cedar
1本にまとめた書き⽅（action in）
Cedarのポリシー（抜粋）
forbid (principal, action in [
AgentCore::Action::"bedrock___POST:/v1/chat/completions",
AgentCore::Action::"azure___POST:/v1/chat/completions"],
resource …) when guardrails {…};
bedrock（connector）
期待どおり
azure（provider）
正常時も403
bedrock（connector）
期待どおり
azure（provider）
期待どおり
ターゲットごとに1本ずつ（action ==）
Cedarのポリシー（抜粋）
forbid (principal, action ==
AgentCore::Action::"bedrock___POST:/v1/chat/completions", …
forbid (principal, action ==
AgentCore::Action::"azure___POST:/v1/chat/completions", …
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
95
Slide 96
Slide 96 text
利用量
使いすぎないように上限を決めよう
利用者やモデルごとの上限とクォータを見てみます！
96
Slide 97
Slide 97 text
利用量の上限を自分の構成で決めたい
ありがたいことに使う人が増えてきたよ・・・
利用者ごととモデルごとの上限のようなレート制限したい！
私
本編で紹介した上限を利用者とモデルの枠に分けて具体化しよう！
上限に達したときの動きと、トークン量の見積もり方も見ていくよ。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
97
Slide 98
Slide 98 text
リクエスト回数とトークン量で制限を考えよう
本編で紹介した利用量の制限を具体的な枠にしていきます。短い質問と長い文書の
要約では同じ1回でも消費するトークン数が違うので、回数とトークン量の両方を
制限しましょう。
依頼
呼び出し回数
短い質問（例）
今⽇の予定を要約して
⼊⼒
出⼒
⼊⼒ 100 ＋ 出⼒ 50
1回
⻑い⽂書の要約（例）
この資料全体を要約して
使ったトークン数
⼊⼒ 20,000 ＋ 出⼒ 2,000
1回
回数は同じでも、使ったトークン数で負荷が変わる
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
98
Slide 99
Slide 99 text
利用者ごとのリクエスト制限
利用者ごとのリクエスト制限も実施できます。JWTに含まれる利用者識別子
（sub）ごとに枠を持てます。ワイルドカードで共通の上限を設定しても利用枠は
subごとに分かれ、一人がほかの利用者の枠を使うことはありません。
Gatewayの共通ルール：subごとに毎分10回
"$.context.jwt.sub": "*"
user-A
JWTのsub
user-A の利⽤枠
10 / 10 回 → 上限に到達
user-B
JWTのsub
user-B の利⽤枠
2 / 10 回 → まだ呼べる
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
99
Slide 100
Slide 100 text
特定のモデルへの呼び出しを制限する
モデルごとの共有枠も作れます。たとえば負荷の大きいモデルを全員で毎分20回ま
でに制限し、ほかのモデルは別の枠で数えます。
Gatewayのモデル別の枠
Agent A
models/model-X
全員の呼び出しを合計して、毎分20回
別のモデルの利⽤量は、別の枠で数える
Agent B
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
100
Slide 101
Slide 101 text
全体と利用者の上限を両方守ることも可能
接続先全体の枠に余裕があってもその人の枠を使い切っていれば拒否されます。リ
クエストに適用される制限をすべて満たすことが、呼び出せる条件です。
このリクエストに適⽤される制限
リクエスト
利⽤者AのAgent
利⽤者Aの枠
10 / 10 回 → 超過
モデル全体の枠
12 / 20 回 → 余裕あり
⽚⽅でも満たさなければ、リクエストは拒否される
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
101
Slide 102
Slide 102 text
トークン使用量の見積もりと確定
トークン使用量は下の図のように数えます。受理時は入力トークン数を見積もって
受け付け、完了時に実使用量で確定します。そのため出力が想定を超えると一時的
に枠を上回ることがあります。
リクエストを受ける
モデルが⽣成する
実使⽤量で精算
⼊⼒トークンを⾒積もる
枠に余裕があれば受理
出⼒トークンが増える
完了時に実使⽤量を得る
⼊⼒＋出⼒を反映
残りの利⽤枠を更新
上限
⼊⼒
受理時点では、
出⼒の量は未確定
上限
⼊⼒
出⼒
上限
⼊⼒
出⼒
出⼒が多いと⼀時的に
上限を超える場合も
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
102
Slide 103
Slide 103 text
レート制限を超えたら待ち時間を確認する
レート制限を超えたリクエストには制限の種類と待ち時間が返ります。呼び出し元
は案内された待ち時間（retryAfter）が過ぎてから、再び呼び出します。
Gatewayが返す制限の情報
metric：どの種類の制限か
呼び出す
呼び出し元
制限と待ち時間を返す
limitKey：どの利⽤枠か
retryAfter：再試⾏までの秒数
案内された時間を待ってから再試⾏する
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
103
Slide 104
Slide 104 text
Interceptor
リクエストや応答に処理を挟もう
ヘッダーの付与や独自の認可をLambdaで加えてみます！
104
Slide 105
Slide 105 text
リクエストや応答に独自の処理を挟みたい
APIへ送るヘッダーを付け足したいし、
利用者によって見せるツールも変えたいな。
私
InterceptorでLambdaの処理を挟めるよ！
リクエストや応答の加工と独自の認可を順番に見ていこう。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
105
Slide 106
Slide 106 text
リクエストや応答を途中で加工する
既存APIに必要なヘッダーを付けるなど、リクエストを調整したい場面です。
InterceptorでLambdaの処理を挟みリクエストや応答を加工できます。
Gateway
Agent
リクエスト
REQUEST Lambda
ヘッダーや本⽂を加⼯
加⼯済み
加⼯後の応答
RESPONSE Lambda
応答の変換‧フィルタ
応答
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
接続先API
106
Slide 107
Slide 107 text
の使いどころ
ヘッダーの付与のほか、ツールやMCP操作単位のアクセス制御や独自の認可にも
使えます。REQUESTは接続先を呼び出す前、RESPONSEはクライアントへ返す
前に実行されます。それぞれ1つ設定できます。
Interceptor
使いどころ
リクエストの調整
応答の加工
細かなアクセス制御
独自の認可
例
既存APIが求めるヘッダーやトークンをリクエストに付け替える
応答の変換・フィルタや、独自ヘッダーの追加
ツールやMCP操作の単位で、通す・止めるを判定する
Policyで書けない社内システムへの照会をLambdaで実装する
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
107
Slide 108
Slide 108 text
でツールの一覧を絞る
たとえば店員用のAgentには発注のツールを見せたくないとします。RESPONSE
Interceptorでtools/listの応答を加工すれば一覧から外せます。ただしツール名を
直接指定すれば呼べるので、発注ツールの認可も別途必要です。
Interceptor
Gatewayからツールの⼀覧を返すとき
加⼯前の⼀覧
在庫確認
発注
tools/list
RESPONSE
店員に⾒せるツールを選ぶ
この例では発注を除く
⼀覧を絞っても tools/call の認可は別に必要
店員のAgent
在庫確認
必要なツールだけ
Agentへ返す
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
108
Slide 109
Slide 109 text
社内の権限情報を照会して呼び出しを許可する
呼び出しのたびに社内システムへ最新の権限を問い合わせたい場合もあります。
REQUEST InterceptorのLambdaで照会し、許可なら処理を続けます。拒否する
場合は接続先を呼ばずに応答を返せます。
tools/call
Gateway
許可
REQUEST
利⽤者‧ツール‧引数を確認
Agent
拒否
エラーを返す
APIは呼ばない
照会
発注を実⾏
権限を返す
社内の権限管理システム
発注API
例：店員は拒否
店⻑なら許可
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
109
Slide 110
Slide 110 text
認可はまずCedarで考えてInterceptorで補う
認可ならまずCedarで書けないかを考えます！Cedarでは手が届かない部分を
Interceptorで補う使い分けイメージです！（Interceptorの方が自由ではあるの
で・・・）
観点
向いている判定
社内システムへの照会
リクエスト・応答の加工
ルールの変更
判定の記録
Cedar（Policy）
認証情報・ツール名・入力で決まる条件
できない
できない
APIで登録してすぐ反映
判定ごとに自動でログに残る
Interceptor（Lambda）
実行時に外から情報を取ってくる判定
できる
できる
コードを直して再デプロイ
Lambdaに自分で書く
REQUEST InterceptorはCedarより先にチェックするので組み合わせても使えます！
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
110
Slide 111
Slide 111 text
その他
VPC Latticeでの接続とWAFでの守り方、Gatewayの切り出し方を見てみます！
111
Slide 112
Slide 112 text
社内だけのAPIもつなげたい
発注APIの公開範囲は社内ネットワークに限定しているんだ。
Gatewayから呼ぶために、外へ公開する必要がある？
私
外へ公開しなくても大丈夫！VPC Latticeを使う接続方法があるよ。
つなぐ経路を見てみよう！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
112
Slide 113
Slide 113 text
外部へ公開していないAPIにも接続する
次につなぎたいAPIが外部へ公開されていないこともあります。VPC内で動くAPI
やMCPサーバーへはVPC Latticeを使い接続を可能にします。
接続先のVPC
VPC Lattice
プライベート
接続
Gateway
Resource
Configuration
接続先のDNS名など
Resource
Gateway
VPCへの⼊⼝
API‧MCP
URLの登録に加え、DNS‧TLS‧セキュリティグループも確認
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
113
Slide 114
Slide 114 text
社内ネットワークにあるIdPでも認証できる
社内VPCに置いたKeycloakのようなOAuth 2.0のIdPも利用できます。
privateEndpointを設定するとインバウンド認証のJWT検証に必要な鍵の取得や接
続先用トークンの取得をVPC Lattice経由で行えます。
Gateway‧Identity
privateEndpointを設定
社内のVPC
インバウンドのJWT検証
Discovery‧JWKSを取得
VPC Lattice
接続先⽤のOAuth認証
トークンを取得
プライベート接続
OAuth 2.0 IdP
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
114
Slide 115
Slide 115 text
の入口に変なアクセスが来たら？
Gateway
社内のAPIにもつながったね！
でもGatewayの入口に怪しい通信が来たら手前で弾きたいな…
私
それならAWS WAFをGatewayに付けよう！
WAFで弾くものとPolicyで判断するものの違いも見ておこう。
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
115
Slide 116
Slide 116 text
と で制御する対象の違い
AWS WAFは不正な通信パターンの検査に加え、送信元IPによる許可・拒否もでき
ます。GatewayにWeb ACLを関連付けて通信を検査し、利用者にその操作を許可
してよいかはPolicyで判断します。
WAF Policy
Gateway
リクエスト
呼び出し元
AWS WAF
Policy
Web ACLを関連付ける
利⽤者と操作を照合
送信元IPによる許可‧拒否
引数や内容も条件にする
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
116
Slide 117
Slide 117 text
は つにまとめる？分ける？
Gateway 1
Gatewayを使うチームも増えてきたよ！
1つのGatewayにまとめるべき？部署ごとに分けるべき？
私
どちらもありだよ！
インバウンド認証や上限、変更が届く範囲で決めよう！
Agent君
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
117
Slide 118
Slide 118 text
を用途ごとに分けるか共有するか
変更の影響や運用の責任を考えるとGatewayを共有する範囲も大切です。部署ごと
に権限と運用を分けるか、接続設定を共通化するかを決めましょう。
Gateway
部署ごとに分ける
部署A
共通のGatewayを使う
Gateway
部署A
共通Gateway
部署B
Gateway
インバウンド認証‧変更‧運⽤責任を分ける
部署B
設定を共有
接続設定と変更の影響範囲を共有する
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
118
Slide 119
Slide 119 text
分けるか共有するかの判断軸
インバウンド認証と上限、変更の影響と運用する人を加味して考えましょう！
共有する部署が増えるほど設定を共通化できますが、変更時に影響を受ける相手も
増えます・・・！
判断軸
内容
インバウンド認証 インバウンド認証はGateway単位。IAMとJWTを使い分けるなら分ける
上限の共有
Gateway単位の上限に加え、アカウント単位の上限も確認する
変更の影響
ツール定義やPolicyの変更が届く範囲は共有している範囲と同じ
費用
Gateway本体の固定費はなく、呼び出し量とツール索引数で決まる
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
119
Slide 120
Slide 120 text
補足までありがとうございました！！！！
補足まで読んでいただきありがとうございました！Gatewayの基礎は本編で紹介
しているのでこちらも必要に応じてご参照ください！
最新のアップデートや試した結果はブログで公開しています！
本編をもう一度見る
最新情報を追いかける
DevelopersIO
神野 雄大の記事一覧
アップデートの使い方や
実際に試した結果を紹介しています
Speaker Deckで本編を見る
dev.classmethod.jp/author/yjinn/
接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用
120
Slide 121
Slide 121 text
No content