AgentCore Gatewayを使ってみよう！（補足資料）

Transcript

1. AgentCore Gatewayを 使ってみよう！ 補足資料 コンサルティング部 神野 雄大（Jinno Yudai）
2. 本編はSpeaker Deckからご覧ください Gatewayの役割や使い方を基礎から知りたい方はまず本編をご覧ください！ この補足では40分の登壇で語りきれなかった部分を熱く説明しています！！！！ speakerdeck.com/yuu551/agentcore-gateway-o-tsuka-te-miyou 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 2
3. をもっと知りたい方に向けて作りました！ 本編で話しきれなかった機能やGatewayの中の仕組みを接続先の登録から認証・ 認可や運用の備えまで詳しく紹介します！ Gateway 何をつなげられる？ Gatewayって⾯⽩そう！ ほかに何ができるの？ Gateway 接続の集約 Agent ツール API‧Agent 認証‧認可などの制御 モデル Gatewayの中では何をしている？ 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 3
4. 補足も量が多いね… 補足もページ数が多いね・・・ 全部読むのは大変そうだな・・・ 私 全部読まなくて大丈夫だよ！章の扉にどんなときに読む章かを書いておいたよ！ 気になる章から開いてね！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 4
5. Lambdaターゲット 本編の在庫確認を具体的に動かそう！ 本編で見た登録の流れを実際のコードと合わせて見てみます！ 5
6. 本編の在庫確認を自分でも動かしたい 本編の在庫確認を自分の環境でも動かしてみたい！ 登録の流れは分かったけど実際には何を書けばいいの？ 私 Gatewayの作り方、Lambdaのコード、送るリクエストを順に見よう。 うまく呼べないときの切り分け方もまとめたよ！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 6
7. なら簡単に作れる 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
8. 在庫数を返す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
9. ツール定義を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
10. 登録したツールで牛乳の在庫を調べる 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
11. ツールの呼び出し結果 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
12. の から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
13. はツールの結果を使って答える AgentにMILK-001の在庫を聞くとGatewayのツールで調べた在庫数をもとに答え てくれます！ Agent agentcore invoke の実行結果 $ agentcore invoke "商品コードMILK-001の在庫を調べて" 商品コードMILK-001の在庫数は**12個**です。 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 13
14. 答えだけでなくツールの呼び出しも確かめる 「12個です」と答えても本当に調べたかは回答だけでは分かりません。商品コー ドと返された在庫数と回答が一致するかログなどもみておきましょう！ Agent Gateway 在庫確認 inventory___get_stock product_id = MILK-001 商品コードを関数へ渡す stock = 12 stock = 12 をAgentへ返す 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 14
15. 色々なターゲットについて確認する OpenAPIの定義やMCPサーバー、Slackなどの 組み込みテンプレートを使う方法も確認します！ 15
16. 既存のAPIやMCPサーバーもつなぎたい 本編では既存のAPIやMCPサーバーもつなげると聞いたよ！ 他のターゲットについても知りたい！ 私 対応しているターゲットも多いからね！具体的に登録方法や違いを見ていこう！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 16
17. の定義を使って既存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
18. 公開済み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
19. サーバーの実行場所 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
20. ツール一覧を取得するタイミング 接続先のツールが変わったときの一覧の更新方法は2通りあります。DEFAULTは同 期済みの一覧を、DYNAMICは呼び出し時に取得した一覧を使います。ツールの更 新頻度や利用者ごとに取得したい一覧が変わるかどうかで選びます。 DEFAULT：同期した⼀覧を返す Agent Gateway DYNAMIC：呼び出し時に取得する MCPサーバー 登録時に同期 同期した⼀覧を持つ Agent Gateway MCPサーバー tools/list tools/list tools/list その時点の⼀覧 同期した⼀覧を返す ⼀覧を返す ツール変更時に再同期 tools/list 利⽤者に応じた⼀覧も、その時点で取得する 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 20
21. 普段使っているSaaSもつなげたい 自前のAPIやMCPサーバーはこうつなぐんだね。 SlackやJiraにもつなげたいけれど、定義を毎回書くのは大変そう…。 私 対応するSaaSなら組み込みテンプレートを選べるよ！ 使える操作を確かめて接続先と認証を設定すれば始められるんだ。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 21
22. の接続には組み込みテンプレートも使える 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
23. 認証設定の深掘り インバウンド認証、Agentと利用者の権限、アウトバウンド認証へのトークンの渡し方を深掘 りします！ 23
24. つながったツールを誰に使ってもらう？ 本編ではインバウンド認証とアウトバウンド認証を分けていたよね。 実際に作るとき誰の資格情報で接続先を呼ぶかは、どう決めればいい？ 私 インバウンド認証の方式と接続先へ渡す資格情報を順に選ぼう！ Agent自身の権限か、利用者の権限かで設定が変わるんだ。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 24
25. インバウンド認証で受け入れる相手を決める あらためてGatewayで呼び出し元をチェックするのがインバウンド認証です。 受け入れたい相手に合わせてIAMやJWTの方式を選びます。 受け入れたい相手 AWSの認証情報を持つAgent IdPでログインした利用者 IAMで誰かだけ確かめたい 認証・認可を別の構成へ任せる 選ぶ方式とインバウンド認証で確認すること AWS_IAM：IAM（SigV4）の署名と呼び出し許可を確認 CUSTOM_JWT：JWTの署名・発行元・宛先などを確認 AUTHENTICATE_ONLY：署名だけ確認。認可は別で判定 NONE：Gatewayでは認証・認可を行わない 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 25
26. あれ？どっちもIAM（SigV4）で確かめるよね？ あれ？AUTHENTICATE_ONLYもIAM（SigV4）の署名を確かめるんだよね？ AWS_IAMと何が違うの？？ 私 いいところに気づいたね！どっちも誰なのかは確かめるんだ。 違うのは呼んでいいかまでGatewayが判定するかどうかだよ！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 26
27. と の違い どちらも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
28. の同意後の処理をAWSに任せる ユーザー委任型（3LO）では、同意とログインした利用者を紐付ける処理が必要で す。AgentCore Identityの同意ポータルを使うとこのための画面やAPIを自作す る手間が減ります。 3LO 以前の検証で⾃作していた部分 同意ポータルを使う場合 AgentCore Identity コールバック画⾯ 外部サービスでの同意後に戻る 同意ポータル 接続画⾯‧同意後の紐付け API Gateway Lambda DynamoDB 利⽤者との紐付けをアプリで実装 画⾯と完了処理をAWSに任せる 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 28
29. 同意ポータルで接続してからAgentを使う 利用者はポータルからGitHubなどの外部サービスへログインし、Agentによるデー タアクセスを許可します。GatewayのインバウンドはJWT認証にし、ポータルと 同じOIDC発行元を使います。 ① 先にブラウザで接続を許可 接続‧同意 同意ポータル 利⽤者 OIDCでログインしてConnect GitHub 本⼈が許可 紐付ける AgentCore Identity 同意と利⽤者を紐付けて保管 ② 同意後にAgentから利⽤ Agent 利⽤者 利⽤者に紐づくトークンを取得 利⽤者のJWT Gateway JWT認証 本⼈のトークン GitHub API 本⼈のデータを返す 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 29
30. 同意ポータルの画面で見るとこうなる 利用者はポータルでGitHubをConnectして許可します。Connectedになればチャ ットのAgentが本人のGitHubを使えます！ 1 未接続の状態 2 Connectを押す！ GitHubで許可するとConnected 本⼈のトークンをIdentityが保管 3 チャットから本⼈のGitHubを使える Gateway経由で githubmcp___get_me が呼ばれた 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 30
31. 呼び出し元の権限を接続先へ引き継ぐ 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
32. トークンを交換する場合とそのまま渡す場合 利用者のJWTを接続先にも使う構成では、接続先用のトークンへ交換するOBOと 同じJWTをそのまま転送する方法があります。接続先が受け付ける宛先や権限に合 わせて選びます。 OBO：接続先⽤のトークンへ交換する 認証基盤 交換を依頼 Agent トークンA 認証基盤へ交換を依頼し 接続先⽤の権限を得る トークンB Gateway 交換したトークンB 接続先API 同じトークンA 接続先API JWT_PASSTHROUGH：受け取ったトークンを転送する Agent トークンA Gateway 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 32
33. はどんなときに使う？ 例えば店長のトークンを発注API向けのトークンに交換すると、店長の権限と Agentの身元を保ったまま不必要な情報を除いたトークンで発注APIを呼ぶことが できます。 OBO AgentCore Identity OBOで交換 店⻑のJWT 店⻑ Gateway 交換したトークン Agent 発注API 店⻑として受け付ける OBOでトークンを交換するとき そのまま転送するとき（Token passthrough） ‧接続先向けに範囲を絞ったトークンにしたい ‧接続先が受け取ったトークンを⾃分で検証する ‧利⽤者とAgentの両⽅の⾝元を伝えたい ‧Gatewayは本⼈確認だけして認可は任せる ‧追加の同意なしに次の接続先へ任せたい ‧トークンの宛先や権限は変わらない 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 33
34. 認可とGuardrails 操作とリクエスト内容をチェックしよう Cedarのルールをどう拡張するか見てみましょう！ 34
35. Cedarの細かい話も聞きたいな！ 本編ではルールの例を見ただけだから自分で書けるか不安…。 私 いいね！書き方をもう少し深掘りしていこう！ ルールの形と条件に使える値と判定の順番を押さえれば読み書きできるよ！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 35
36. のルールは効果・対象・条件の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 ARN>" // どこで：Gateway ) when { // 条件：すべて満たすと当てはまる principal.hasTag("role") && principal.getTag("role") == "store-staff" && context.input.product_id like "MILK-*" }; 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 36
37. 条件に書ける値は呼び出し元とツールの入力 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
38. 複数のルールが当てはまったときの判定 Cedarは当てはまるルールをすべて評価してから結果を決めます。forbidが1つで も当てはまれば拒否になり、どのルールにも当てはまらなければ拒否です。 当てはまったルール 結果 forbidが1つでもある 拒否（permitより優先） permitだけがある 許可 どれにも当てはまらない 拒否（デフォルトで拒否） forbidのunlessは「このforbidを外す条件」です。unlessで許可が増えることはありません。 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 38
39. 認可する操作名をスキーマに合わせる ルールの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
40. で操作をまとめて許可する Cedarのactionには「*」のようなワイルドカードを書けません。まとめて許可し たいツールを1つのターゲットに登録し、in でそのターゲット名を指定します。こ の単位をAction Groupと呼びます。 Action Group read-toolsに登録したツールをまとめて許可する permit( principal, action in AgentCore::Action::"read-tools", resource == AgentCore::Gateway::"<Gateway ARN>" ); == は1つの操作、in はターゲットに含まれるすべての操作を指します 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 40
41. 豆知識：書いたCedarは登録するときにチェックされる Policyを登録するとAWSがルールの中身を確かめます。validationModeのデフォ ルトは少しでも変なものがあったら失敗（FAIL_ON_ANY_FINDINGS）で、問題の あるルールは登録できません！ チェック スキーマ 自動推論 確認するポイント 存在しないツール名や型の違い 許可しすぎ・拒否しすぎ・効き目なし 無視できる？ 無視できない！ IGNORE_ALL_FINDINGSで無視できる（非推奨） 問題を無視して登録するIGNORE_ALL_FINDINGSも設定できますが、本番では非推奨です。 ちなみに試しに条件のないpermitを登録したら「Overly Permissive（許可しすぎ）」と弾かれまし た・・・！ 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 41
42. Policyっていきなり反映されちゃうの？しばらく様子見たいんだけど・・・ 私 様子見モードも提供されているよ！！！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 42
43. ログで判定を試してから拒否を有効にする ログ記録モード（LOG_ONLY）では判定の内容をログに残したまま拒否はされま せん。一方強制適用（ENFORCE）へ切り替えるとそのリクエストは遮断されま す。LOG_ONLYでログを見てENFORCEに切り替えていきましょう！ LOG_ONLY：判定を記録し、リクエストは通す Agent 同じリクエスト Policyの判定：DENY 判定の内容をログに残す 実⾏する API WAFのカウントモードみたいだね ENFORCE：拒否の判定を実⾏に反映する Agent 同じリクエスト Policyの判定：DENY 停⽌ 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 API 43
44. を通らない直接の呼び出しは接続先側で止める PolicyはGatewayを通ったリクエストだけを判定します。接続先を直接呼べるとル ールを迂回できるので、接続先側でIAMポリシーを駆使してGatewayからの呼び出 しに絞りましょう！ Gateway 接続先側でGateway実⾏ロールだけ許可 Lambda（発注処理） 呼び出せる主体をIAMで限る Gateway 呼び出し元 Runtime Policyで判定 IAMはリソースポリシー∕JWTは許可するGatewayを登録 Memory リソースポリシーで絞り、ほかは明⽰的に拒否 Gatewayを通らない直接の呼び出し 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 44
45. の検査結果をルールへどう書く？ Guardrails 本編では本文をGuardrailsで検査して送信を止めていたよね。 Cedarをどうやって書くの？？ 私 リクエストのどの項目を調べるかと判定のしきい値をルールに書くよ！ ここではRuntimeへ送る文章を例にコードの書き方を見てみよう。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 45
46. 内容の検査を拒否ルールに組み込む Runtimeへ送るプロンプトを暴力的なコンテンツかどうか検査し、しきい値を超え たら拒否する例です！ when guardrailsの書き方 forbid (principal, action == AgentCore::Action::"agent___POST:/invocations", resource == AgentCore::Gateway::"<Gateway ARN>") when guardrails { BedrockGuardrails::ContentFilter(["VIOLENCE"], [context.input.prompt]) ["VIOLENCE"].confidenceScore.greaterThan(decimal("0.2")) }; 通常のwhenとwhen guardrailsは別のルールに分ける。 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 46
47. 何を検査するかはデータパスで決まる ルールのcontext.input.promptはリクエスト本文のpromptを指します。フィールド名 を変えたら入力スキーマとルールも合わせましょう。存在しない項目や別の項目を検査し ていないか確認しましょう。 Runtimeへ送るJSON Guardrailsへ渡す値 { "prompt": "確認したい本文", promptを選ぶ 確認したい本⽂ "customer_id": "C-001" } context.input.prompt ⼊⼒スキーマも揃える 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 47
48. 検知のしきい値は想定されるユースケースで決める 実際に使うユースケースを整理して、LOG_ONLYで誤検知と見逃しを比べてからし きい値を決めていきましょう。 しきい値を低くする 実際に使う⽂章で決める 正常な問い合わせまで⽌める（誤検知） しきい値を⾼くする ⽌めたい内容を通す（⾒逃し） ユースケースを想定 LOG_ONLYで⽐較 ENFORCE 通常の問い合わせ 拒否したい⽂章 判断が分かれる⽂章 スコアと判定を記録 誤検知と⾒逃しを確認 しきい値を調整 拒否を適⽤ 同じ⼊⼒例で 結果を再確認 期待する判定も決める 検査結果は揺れ得る 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 48
49. アウトプットもチェックできる？？ Guardrailsってアウトプットもチェックできるの？？ 私 できるよー！！suppressOutput使えばアウトプットのチェックも可能です！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 49
50. 応答を止めるsuppressOutputの書き方 効果にsuppressOutputを書くと実行後の応答をGuardrailsで検査して止めます！ 通常のCedarやtemporalの条件は別のルールに書きます。 suppressOutputの書き方 suppressOutput (principal, action == AgentCore::Action::"agent___POST:/invocations", resource == AgentCore::Gateway::"<Gateway ARN>") when guardrails { BedrockGuardrails::SensitiveInformation(["EMAIL"], [context.output.text]).maxConfidenceScore() .greaterThan(decimal("0.5")) }; 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 50
51. リクエストの拒否と応答の抑止はタイミングが違う 入力を見て止めるforbidは接続先を呼ぶ前に判定します。suppressOutputは実行 後の応答を抑止するので違いを押さえておきましょう。 リクエスト受付 forbid ⼊⼒を⾒て⽌める suppressOutput 実⾏後の応答を抑⽌ 接続先へ送る 接続先が実⾏する 応答を返す 接続先へ送らない（実⾏されない） 実⾏済み 応答を返さない 処理は取り消されない 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 51
52. ちなみに・・・ 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
53. 履歴を使う認可 Temporal Policies 返金処理を例に前の呼び出しで確かめた承認を今回のリクエストと照合します！ 53
54. 人が承認した内容で実行してほしい 返金のような操作は過去の呼び出しの履歴も使って判断したいな。 前に承認を確かめた注文と金額と同じかどうかとか！ 私 利用者の権限に加えて前の呼び出しで確かめた承認結果も条件にできるよ！ 本編のスーパーがネットスーパーで返品を受け付ける場面で順に見ていこう。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 54
55. 返品した商品の代金を返す場面で考える ネットスーパーで返品された商品の代金3,000円を返す場面を考えてみます。管理 者が注文と金額を承認しその記録をシステムへ保存し、Agentは承認確認APIで事 前に承認されたものを対象に申請します。 注⽂123について、3,000円の返⾦を承認する 管理者 承認を保存するシステム 注⽂：123 承認⾦額：3,000円 承認済み：true APIで承認記録を確認 確認した後に 返⾦を依頼する 返⾦担当Agent 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 55
56. 承認済みかどうかを条件に加える この注文と金額が承認済みのものか確認したいですよね。変なリクエストが承認さ れたくないですし。今回使う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
57. 承認確認と返金を同じ履歴につなげる 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
58. 承認された注文と金額に一致する返金を許可する 3つの条件を突き合わせて判定します。条件に合わない依頼は返金APIへ送らずに止 めます。 前の承認確認の応答 今回の返⾦リクエスト 注⽂ 123 注⽂が⼀致 注⽂ 123 ⾦額 3,000円 ⾦額が⼀致 ⾦額 3,000円 確認から1時間以内 リクエストした時刻 応答した時刻 10:00 10:20 3つの条件を満たすので、返⾦APIへの呼び出しを許可 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 58
59. 過去の承認と今回の返金をコードで照合する 先ほどの条件をコードにすると次のようになります。承認記録と今回の依頼で、注 文と金額が同じかを照合します。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
60. 条件を部品ごとに読む 前のページのルールを部品に分けてみます。どの操作の・どの記録を・何と照合す るかを順に書いていきます。 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
61. ほかにも書けるTemporal条件 formerly以外にも回数や合計を条件にできます。返金の場面ならこんな使い方がで きます！ 書き方 formerly within since within count sum できること 前にあったかを確かめる ある操作のあとに別の操作が起きていないか 回数を数える 入力の値を合計する 返金での使い方イメージ 承認済みの返金に限って許可 1回の承認で返金を1回に限る 5分に3回を超えたら拒否 1日の返金額の合計で上限 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 61
62. Memoryコネクタ 利用者ごとに記憶の参照権限を意識する ほかの人の記憶を読ませない設定を見てみます！ 62
63. 共有するMemoryで誰の記憶を読めるようにする？ RuntimeからMemoryを使う流れは本編で分かったよ！ 同じ保存先をみんなで使うと他の人の記憶も読めたりしない・・・？ 私 ここからはGateway経由で利用者ごとに読める記憶を制限する例を見よう！ 接続先の登録からJWTと記憶の持ち主を照合する条件まで確かめていくよ。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 63
64. 保存先を固定するだけでは利用者を分離できない memoryIdは接続するMemoryの保存先を決めます。1つの保存先に複数の利用者 の記憶が入るので、取り出すときに所有者を照合する条件を別に用意します。 同じMemory mem-XXXX memoryIdを指定 利⽤者A 利⽤者Aのイベント actorId：user-A ⾃分の会話‧記憶 利⽤者Bのイベント 同じ保存先に 両⽅が⼊る actorId：user-B 別の⼈の会話‧記憶 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 64
65. 短期イベントの持ち主をJWTと照合する ログインした人が他人のactorIdを指定して読めないようにします。この例では検 証済みJWTのsubとリクエストのactorIdを比べ、一致する場合に許可します。 検証済みJWT リクエストに含まれる対象 actorId = user-A sub = user-A この例ではsubを actorIdに使っている Policyで照合 ⼀致 → ⾃分の記憶を許可 actorId = user-B 不⼀致 → 他⼈の記憶を拒否 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 65
66. 記憶の所有者とログインした利用者を照合する 先ほどの絵で書いた条件は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
67. 長期記憶は検索する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
68. Claude CodeからGatewayを使おう！ Claude CodeをGatewayにつないで試してみます！ 68
69. 作った検索ツールをClaude Codeでも使いたい Gatewayに登録した文書検索のツールを 普段使っているClaude Codeからも使える？ 私 同じGatewayを接続先として登録すれば使えるよ！ 認証方式に合わせて接続し、取得した文書を根拠に答えられるか確かめよう。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 69
70. から社内文書を根拠に答えてもらう Claude CodeからGatewayの検索ツールを呼ぶとManaged KBにある設計資料の 関連箇所と出典を取得できます。接続後はその内容を根拠に回答や実装を進められ るか確かめます。 Claude Code Retrieve 社内の設計資料を検索 Claude Code 検索結果を返す Gateway 関連箇所と出典 Managed KB 設計資料の根拠を⾒て、回答や実装へ進む 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 70
71. インバウンド認証でつなぎ方が変わる 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
72. 認証① 個人なら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
73. 認証② チームなら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
74. コネクタを追加するとログイン方法が検出される claude.aiのコネクタ追加画面でGatewayのURLを入れるとログインが要ることが 検出されました！今回のIdPはDCRに対応しないCognitoなので、登録済みの Client IDを使う設定を選びます。 1 ログインが要ることを検出 Gatewayが返す案内から「今すぐサインイン」 2 ⾃前のOAuthクライアントを使う CognitoはDCR⾮対応。登録したClient IDを⼊れる 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 74
75. にログインするとツールが表示される Connectを押すとCognitoのログイン画面が開きます。ログインするとGatewayの ツールがコネクタに並び、使う前に承認を求める設定になっていました。 Cognito 1 Cognitoにログイン 利⽤者本⼈として 2 Gatewayのツールが並ぶ inventory___get_stock。使う前に承認を求める設定が既定 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 75
76. チャットからGatewayのツールを呼べた！ 在庫を聞くとClaudeがツールを使ってよいか確認してきます。許可すると GatewayがLambdaを呼び在庫12個と答えてくれました！ 2 1 ツールを使う前に確認 Gatewayのツールの結果で答える Lambdaが返した在庫12個 ⼀度だけ許可‧常に許可‧拒否 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 76
77. にツールを足したら一覧を更新する Gatewayにツールを足してもコネクタの一覧はそのままです。メニューのツールリ ストを更新で、Gatewayの一覧を取り直すこともできます。 Gateway 1 Gatewayにツールを⾜す ターゲットを追加‧定義を更新 2 Gatewayの⼀覧が変わる MCPの取り込みは同期も要る 3 コネクタで⼀覧を取り直す 「ツールリストを更新」を押す 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 77
78. 認証なら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
79. HTTPパススルーを深掘りしよう！ 既存のAPIやMCPサーバー、別のAgentを 変換せずにそのまま通すしくみをもう少し見てみよう！ 79
80. 正直あえて選ぶ理由がわからない… HTTPパススルーって正直あえて選ぼうとは思わないんだよね… 既存のAPIならOpenAPIでツールにすればよくない？ 私 そう思うよね！分かれ目はAgentにツールとして選ばせたいかなんだ。 ツールにしない呼び方もあるから、そこを掘っていこう！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 80
81. ツールにして呼ぶかそのまま通すか 本編のおさらいですが、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
82. に選ばせない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
83. 接続先への認証も5つから選べる パススルーでも接続先への認証はGatewayが担ってくれます！接続先が受け付ける 方式に合わせて選びましょう！ 方式 IAM（SigV4） OAuth 呼び出し元のIAM トークンのパススルー APIキー Gatewayがすること Gatewayのロールで署名する Identityから取ったトークンを付ける 呼び出した人のIAMで署名する（インバウンドがIAMのとき） 受け取ったJWTを検証してそのまま渡す 保管庫のAPIキーをヘッダーに付ける 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 83
84. サーバーもそのまま中継できる？ MCP 既存のAPIは中継できたね！MCPサーバーも中継できるの？ MCPターゲットと何が違うんだろう。 私 できるよ！MCPサーバーへのリクエストもHTTPパススルーで中継できるんだ。 ツールを取り込むMCPターゲットとは経路が違うよ。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 84
85. サーバーを中継するか取り込むか 同じ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
86. どう選択するのがいいんだろう・・・？ うーん・・・まずはAgentにツールとして選ばせたいかで分けるのかな？選ばせな いならRuntimeのAgentかどうか、それ以外はHTTPパススルー・・・？正直バチ っとしたユースケースは私もまだ悩み中です！ Agentにツールとして選ばせたい？ はい MCPターゲット Lambda‧OpenAPI‧MCPサーバーを取り込む いいえ 相⼿はRuntimeのAgent？ はい Runtimeターゲット ARNを指定する いいえ HTTPパススルー 私 どれを選べばいいんだろう‧‧‧ MCP‧CUSTOMから選ぶ 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 86
87. モデル 複数のモデルをまとめて呼ぼう Gatewayでモデルをまとめるケースをもう少し深掘りしてみましょう！ 87
88. モデルを登録してSDKから呼んでみたい 色々なモデルをGatewayに統合できるのはわかったよ！ OpenAIのSDKから試すには何を登録すればいいの？ 私 組み込みコネクタと独自の接続先を登録する方法を見よう！ 登録したらモデル名を確かめてSDKの接続先URLをGatewayへ変えるよ。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 88
89. 用意された接続設定でモデルを使う 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
90. 独自の接続先には操作パスとモデルを登録する 組み込みコネクタにない接続先は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
91. 使えるモデルと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
92. に合わせてURLと認証を設定する OpenAI SDKとAnthropic SDKはURLへ付けるパスが異なります。base_urlを使 うSDKに合わせGatewayの認証方式に応じた資格情報も用意します。 SDK 設定するもの OpenAI SDKの base_url Anthropic SDKの base_url JWT認証 IAM認証 Gatewayへ接続するときの指定 https://<gateway-host>/inference/v1 https://<gateway-host>/inference Gatewayが検証するJWTをapi_keyへ渡す IAM（SigV4）で署名（サービス名bedrock-agentcore）。 InvokeGatewayを許可 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 92
93. 使い慣れたライブラリからGatewayを呼ぶ OpenAI SDKからGatewayに登録したモデルを呼ぶ例です。GatewayのJWTを渡 し、modelにターゲット名付きのモデルIDを指定します。 JWT認証のOpenAI SDK例 from openai import OpenAI client = OpenAI( base_url="https://<gateway-host>/inference/v1", api_key=jwt_token) response = client.chat.completions.create( model="models/<model-id>", messages=messages ) JWTとmessagesを用意し、<model-id>を利用するモデルIDへ置き換える。 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 93
94. モデルや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::"<GatewayのARN>") when guardrails { BedrockGuardrails::ContentFilter(["VIOLENCE"], [context.input.messages]) ["VIOLENCE"].confidenceScore.greaterThan(decimal("0.2")) }; 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 94
95. を使う場合はプロバイダーごとにポリシーを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
96. 利用量 使いすぎないように上限を決めよう 利用者やモデルごとの上限とクォータを見てみます！ 96
97. 利用量の上限を自分の構成で決めたい ありがたいことに使う人が増えてきたよ・・・ 利用者ごととモデルごとの上限のようなレート制限したい！ 私 本編で紹介した上限を利用者とモデルの枠に分けて具体化しよう！ 上限に達したときの動きと、トークン量の見積もり方も見ていくよ。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 97
98. リクエスト回数とトークン量で制限を考えよう 本編で紹介した利用量の制限を具体的な枠にしていきます。短い質問と長い文書の 要約では同じ1回でも消費するトークン数が違うので、回数とトークン量の両方を 制限しましょう。 依頼 呼び出し回数 短い質問（例） 今⽇の予定を要約して ⼊⼒ 出⼒ ⼊⼒ 100 ＋ 出⼒ 50 1回 ⻑い⽂書の要約（例） この資料全体を要約して 使ったトークン数 ⼊⼒ 20,000 ＋ 出⼒ 2,000 1回 回数は同じでも、使ったトークン数で負荷が変わる 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 98
99. 利用者ごとのリクエスト制限 利用者ごとのリクエスト制限も実施できます。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
100. 特定のモデルへの呼び出しを制限する モデルごとの共有枠も作れます。たとえば負荷の大きいモデルを全員で毎分20回ま でに制限し、ほかのモデルは別の枠で数えます。 Gatewayのモデル別の枠 Agent A models/model-X 全員の呼び出しを合計して、毎分20回 別のモデルの利⽤量は、別の枠で数える Agent B 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 100
101. 全体と利用者の上限を両方守ることも可能 接続先全体の枠に余裕があってもその人の枠を使い切っていれば拒否されます。リ クエストに適用される制限をすべて満たすことが、呼び出せる条件です。 このリクエストに適⽤される制限 リクエスト 利⽤者AのAgent 利⽤者Aの枠 10 / 10 回 → 超過 モデル全体の枠 12 / 20 回 → 余裕あり ⽚⽅でも満たさなければ、リクエストは拒否される 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 101
102. トークン使用量の見積もりと確定 トークン使用量は下の図のように数えます。受理時は入力トークン数を見積もって 受け付け、完了時に実使用量で確定します。そのため出力が想定を超えると一時的 に枠を上回ることがあります。 リクエストを受ける モデルが⽣成する 実使⽤量で精算 ⼊⼒トークンを⾒積もる 枠に余裕があれば受理 出⼒トークンが増える 完了時に実使⽤量を得る ⼊⼒＋出⼒を反映 残りの利⽤枠を更新 上限 ⼊⼒ 受理時点では、 出⼒の量は未確定 上限 ⼊⼒ 出⼒ 上限 ⼊⼒ 出⼒ 出⼒が多いと⼀時的に 上限を超える場合も 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 102
103. レート制限を超えたら待ち時間を確認する レート制限を超えたリクエストには制限の種類と待ち時間が返ります。呼び出し元 は案内された待ち時間（retryAfter）が過ぎてから、再び呼び出します。 Gatewayが返す制限の情報 metric：どの種類の制限か 呼び出す 呼び出し元 制限と待ち時間を返す limitKey：どの利⽤枠か retryAfter：再試⾏までの秒数 案内された時間を待ってから再試⾏する 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 103
104. Interceptor リクエストや応答に処理を挟もう ヘッダーの付与や独自の認可をLambdaで加えてみます！ 104
105. リクエストや応答に独自の処理を挟みたい APIへ送るヘッダーを付け足したいし、 利用者によって見せるツールも変えたいな。 私 InterceptorでLambdaの処理を挟めるよ！ リクエストや応答の加工と独自の認可を順番に見ていこう。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 105
106. リクエストや応答を途中で加工する 既存APIに必要なヘッダーを付けるなど、リクエストを調整したい場面です。 InterceptorでLambdaの処理を挟みリクエストや応答を加工できます。 Gateway Agent リクエスト REQUEST Lambda ヘッダーや本⽂を加⼯ 加⼯済み 加⼯後の応答 RESPONSE Lambda 応答の変換‧フィルタ 応答 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 接続先API 106
107. の使いどころ ヘッダーの付与のほか、ツールやMCP操作単位のアクセス制御や独自の認可にも 使えます。REQUESTは接続先を呼び出す前、RESPONSEはクライアントへ返す 前に実行されます。それぞれ1つ設定できます。 Interceptor 使いどころ リクエストの調整 応答の加工 細かなアクセス制御 独自の認可 例 既存APIが求めるヘッダーやトークンをリクエストに付け替える 応答の変換・フィルタや、独自ヘッダーの追加 ツールやMCP操作の単位で、通す・止めるを判定する Policyで書けない社内システムへの照会をLambdaで実装する 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 107
108. でツールの一覧を絞る たとえば店員用のAgentには発注のツールを見せたくないとします。RESPONSE Interceptorでtools/listの応答を加工すれば一覧から外せます。ただしツール名を 直接指定すれば呼べるので、発注ツールの認可も別途必要です。 Interceptor Gatewayからツールの⼀覧を返すとき 加⼯前の⼀覧 在庫確認 発注 tools/list RESPONSE 店員に⾒せるツールを選ぶ この例では発注を除く ⼀覧を絞っても tools/call の認可は別に必要 店員のAgent 在庫確認 必要なツールだけ Agentへ返す 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 108
109. 社内の権限情報を照会して呼び出しを許可する 呼び出しのたびに社内システムへ最新の権限を問い合わせたい場合もあります。 REQUEST InterceptorのLambdaで照会し、許可なら処理を続けます。拒否する 場合は接続先を呼ばずに応答を返せます。 tools/call Gateway 許可 REQUEST 利⽤者‧ツール‧引数を確認 Agent 拒否 エラーを返す APIは呼ばない 照会 発注を実⾏ 権限を返す 社内の権限管理システム 発注API 例：店員は拒否 店⻑なら許可 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 109
110. 認可はまずCedarで考えてInterceptorで補う 認可ならまずCedarで書けないかを考えます！Cedarでは手が届かない部分を Interceptorで補う使い分けイメージです！（Interceptorの方が自由ではあるの で・・・） 観点 向いている判定 社内システムへの照会 リクエスト・応答の加工 ルールの変更 判定の記録 Cedar（Policy） 認証情報・ツール名・入力で決まる条件 できない できない APIで登録してすぐ反映 判定ごとに自動でログに残る Interceptor（Lambda） 実行時に外から情報を取ってくる判定 できる できる コードを直して再デプロイ Lambdaに自分で書く REQUEST InterceptorはCedarより先にチェックするので組み合わせても使えます！ 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 110
111. その他 VPC Latticeでの接続とWAFでの守り方、Gatewayの切り出し方を見てみます！ 111
112. 社内だけのAPIもつなげたい 発注APIの公開範囲は社内ネットワークに限定しているんだ。 Gatewayから呼ぶために、外へ公開する必要がある？ 私 外へ公開しなくても大丈夫！VPC Latticeを使う接続方法があるよ。 つなぐ経路を見てみよう！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 112
113. 外部へ公開していない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
114. 社内ネットワークにある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
115. の入口に変なアクセスが来たら？ Gateway 社内のAPIにもつながったね！ でもGatewayの入口に怪しい通信が来たら手前で弾きたいな… 私 それならAWS WAFをGatewayに付けよう！ WAFで弾くものとPolicyで判断するものの違いも見ておこう。 Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 115
116. と で制御する対象の違い AWS WAFは不正な通信パターンの検査に加え、送信元IPによる許可・拒否もでき ます。GatewayにWeb ACLを関連付けて通信を検査し、利用者にその操作を許可 してよいかはPolicyで判断します。 WAF Policy Gateway リクエスト 呼び出し元 AWS WAF Policy Web ACLを関連付ける 利⽤者と操作を照合 送信元IPによる許可‧拒否 引数や内容も条件にする 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 116
117. は つにまとめる？分ける？ Gateway 1 Gatewayを使うチームも増えてきたよ！ 1つのGatewayにまとめるべき？部署ごとに分けるべき？ 私 どちらもありだよ！ インバウンド認証や上限、変更が届く範囲で決めよう！ Agent君 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 117
118. を用途ごとに分けるか共有するか 変更の影響や運用の責任を考えるとGatewayを共有する範囲も大切です。部署ごと に権限と運用を分けるか、接続設定を共通化するかを決めましょう。 Gateway 部署ごとに分ける 部署A 共通のGatewayを使う Gateway 部署A 共通Gateway 部署B Gateway インバウンド認証‧変更‧運⽤責任を分ける 部署B 設定を共有 接続設定と変更の影響範囲を共有する 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 118
119. 分けるか共有するかの判断軸 インバウンド認証と上限、変更の影響と運用する人を加味して考えましょう！ 共有する部署が増えるほど設定を共通化できますが、変更時に影響を受ける相手も 増えます・・・！ 判断軸 内容 インバウンド認証 インバウンド認証はGateway単位。IAMとJWTを使い分けるなら分ける 上限の共有 Gateway単位の上限に加え、アカウント単位の上限も確認する 変更の影響 ツール定義やPolicyの変更が届く範囲は共有している範囲と同じ 費用 Gateway本体の固定費はなく、呼び出し量とツール索引数で決まる 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 119
120. 補足までありがとうございました！！！！ 補足まで読んでいただきありがとうございました！Gatewayの基礎は本編で紹介 しているのでこちらも必要に応じてご参照ください！ 最新のアップデートや試した結果はブログで公開しています！ 本編をもう一度見る 最新情報を追いかける DevelopersIO 神野 雄大の記事一覧 アップデートの使い方や 実際に試した結果を紹介しています Speaker Deckで本編を見る dev.classmethod.jp/author/yjinn/ 接続 › 認証・認可 › 検索・Memory › Claude Code › HTTP・モデル › 運用 120