
AgentCore CLI で Lambda を MCP ツール化する - Gateway 機能を試してみた 【備忘録】
はじめに
こんにちは!AI 事業本部のこーすけです。
今回は Amazon Bedrock AgentCore の Gateway 機能を紹介します。Gateway を使うと、既存の Lambda 関数や REST API を MCP ツールとして公開し、AI エージェントから呼び出せるようになります。
本記事では Gateway の概要を解説した後、シンプルな Lambda 関数を Gateway 経由で MCP ツール化する手順を説明します。
作成するアーキテクチャはこちらになります。

Amazon Bedrock AgentCore とは
Amazon Bedrock AgentCore は AI エージェントをローカルの試作段階から、本番環境で安全かつ大規模に運用するためのマネージド基盤です。特定のフレームワークやモデルに依存しない開発ができるほか、ダッシュボード(Observability)を備えており、エージェントの複雑な推論ステップを追跡できます。
AgentCore は以下の機能群で構成されています。
| 機能 | 概要 |
|---|---|
| Runtime | エージェントのサーバーレス実行環境。自動スケーリング・ストリーミング対応 |
| Gateway | API や Lambda を MCP ツールに変換し、統一エンドポイントで提供(本記事で紹介) |
| Memory | 会話履歴やコンテキストの永続化 |
| Identity | 認証・認可の管理 |
| Tools | Code Interpreter、Browser などの組み込みツール |
| Observability | 推論ステップやツール実行の可視化ダッシュボード |
今回はこの中から Gateway を取り上げます。
Gateway とは
AgentCore Gateway は、さまざまなバックエンドサービスを MCP(Model Context Protocol)ツールに変換して一つのエンドポイントにまとめるマネージドサービスです。 公式ドキュメントでは、Gateway の主要機能として以下の 6 つが挙げられています。
| 機能 | 概要 |
|---|---|
| Security Guard | OAuth 認可により、許可されたユーザー・エージェントのみがツールにアクセスできるようにする |
| Translation | MCP プロトコルのリクエストを API 呼び出しや Lambda 実行に自動変換。プロトコル統合やバージョン管理が不要になる |
| Composition | 複数の API・Lambda・ツールを単一の MCP エンドポイントに統合し、エージェントからのアクセスを一本化する |
| Secure Credential Exchange | ツールごとに異なる認証要件(API キー、OAuth 等)に対応した認証情報の注入を自動処理する |
| Semantic Tool Selection | 登録されたツール群からコンテキストに最適なツールを自動選択。プロンプトサイズの削減とレイテンシの低下に寄与する |
| Infrastructure Manager | サーバーレスで動作し、監視・監査機能を内蔵。インフラ管理のオーバーヘッドを排除する |
つまり、既存の Lambda や REST API を MCP ツール化でき、認証・スケーリング・ツール選択まで Gateway がまとめて面倒を見てくれます。
ターゲットの種類
Gateway には 様々なターゲットを追加できます。ターゲットとは Gateway が呼び出すバックエンドの接続先のことです。
| ターゲット | 概要 | ユースケース |
|---|---|---|
| Lambda 関数 | 既存の Lambda を MCP ツールとして公開 | 社内の業務ロジックをエージェントから利用 |
| API Gateway REST API | REST API ステージを MCP ツールに変換 | 既存の API Gateway をそのまま活用 |
| OpenAPI スキーマ | OpenAPI 仕様書から自動で MCP ツールを生成 | REST API をそのままエージェント対応 |
| Smithy モデル | AWS サービス API のインターフェース定義 | AWS サービスとの連携 |
| MCP サーバー | リモートの MCP サーバーを集約 | 複数の MCP サーバーを 1 エンドポイントに |
今回はシンプルな Lambda 関数をターゲットとして使います。
Gateway の認証方式
Gateway には インバウンド認証とアウトバウンド認証の 2 層があります。
インバウンド認証(誰が Gateway にアクセスできるか):
| 方式 | 概要 | ユースケース |
|---|---|---|
| NONE | 認証なし | ローカル開発・動作確認 |
| CUSTOM_JWT | JWT トークンによる認証 | Cognito や外部 IdP との連携 |
| IAM | AWS SigV4 署名による認証 | AWS サービス間連携 |
アウトバウンド認証(Gateway がバックエンドサービスにどう認証するか):
| 方式 | 概要 | ターゲット例 |
|---|---|---|
| IAM ロール | Gateway の実行ロールで呼び出し | Lambda、AWS サービス |
| API キー | Secrets Manager に保管したキーを自動注入 | 外部 REST API |
| OAuth(Client Credentials) | 2-legged OAuth。トークン取得・リフレッシュを自動処理 | Slack、Jira 等の SaaS |
| OAuth(Authorization Code) | 3-legged OAuth。ユーザー委任アクセス | ユーザーの権限で操作する SaaS |
今回はインバウンドに CUSTOM_JWT(Cognito)、アウトバウンドに IAM ロール(Lambda 呼び出し) の構成にします。
Lambda を Gateway で MCP ツール化してみよう
こちらの公式ドキュメントが参考になります。
全体の流れ
- AgentCore プロジェクトを作成する
- Lambda 関数を作成する
- ツールスキーマを作成する
- Cognito ユーザープールを作成する
- Gateway を追加する(CUSTOM_JWT)
- Lambda ターゲットを追加する
- デプロイする
- 動作確認する
前提条件
- AgentCore CLI がインストール済み
- AWS CLI がインストール済みで認証情報が設定済み
本検証では v0.5.0 を使用しました。
# AgentCore CLI のインストール
npm install -g @aws/agentcore
ステップ 1: AgentCore プロジェクトの作成
まず、Gateway を管理する AgentCore プロジェクトを作成します。
agentcore create \
--name GatewayDemo \
--language python \
--build container \
--protocol http \
--framework strands \
--model-provider bedrock \
--memory none \
--network-mode PUBLIC
これで AgentCore プロジェクトの雛形ができました。ここに Gateway とターゲットを追加していきます。
ステップ 2: Lambda 関数の作成
Gateway のターゲットとなる Lambda 関数を作成します。Gateway の動作を確認しやすいよう、定型文を返すシンプルな関数にします。
def lambda_handler(event, context):
name = event.get("name", "World")
return {
"message": f"Hello, {name}! This response is from Lambda via AgentCore Gateway."
}
AWS CLI で Lambda 関数を作成します。
# Lambda 用の IAM ロールを作成
aws iam create-role \
--role-name hello-gateway-role \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy \
--role-name hello-gateway-role \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
# Lambda 関数のコードを zip 化
zip lambda_function.zip lambda_function.py
# Lambda 関数を作成
aws lambda create-function \
--function-name hello-gateway \
--runtime python3.13 \
--handler lambda_function.lambda_handler \
--role arn:aws:iam::123456789012:role/hello-gateway-role \
--zip-file fileb://lambda_function.zip
ここで Lambda の ARN を控えておきます。後で Gateway のターゲット設定に使います。
arn:aws:lambda:ap-northeast-1:123456789012:function:hello-gateway
ステップ 3: ツールスキーマの作成
Gateway が Lambda を MCP ツールとして公開するには、ツールの入出力を定義する ツールスキーマ(tools.json)が必要です。
inputSchema で定義したプロパティが、そのまま Lambda 側 の event として渡されます。今回は name を受け取って挨拶を返す、という定義です。
[
{
"name": "hello",
"description": "名前を受け取って挨拶メッセージを返します。",
"inputSchema": {
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "挨拶する相手の名前"
}
},
"required": ["name"]
}
}
]
ステップ 4: Cognito ユーザープールの作成
Gateway のインバウンド認証に使う Cognito を準備します。
補足: AgentCore CLI では Cognito の作成をサポートしていないため、AWS CLI で手動作成します。
ユーザープールの作成
aws cognito-idp create-user-pool \
--pool-name hello-gateway-pool \
--query 'UserPool.Id' --output text
出力されたユーザープール ID を控えます(例: ap-northeast-1_XXXXXXXXX)。
M2M(Machine-to-Machine)認証フローとは
通常の認証フローではユーザーがログイン画面でパスワードを入力しますが、Gateway のようにサービス同士がやり取りする場面ではユーザーが介在しません。このようなサービス間認証には Client Credentials フロー(M2M 認証)を使います。
仕組みはシンプルで、クライアント ID とクライアントシークレットを Cognito の /oauth2/token エンドポイントに送ると、アクセストークンが返ってきます。このトークンに含まれるスコープ(gateway/invoke など)で、アクセスできるリソースを制御します。
クライアント ID + シークレット → Cognito /oauth2/token → アクセストークン(スコープ付き)
このフローを使うために、以下の 3 つを作成します。
- ドメイン - OAuth2 エンドポイント(
/oauth2/token)のホスト名 - リソースサーバー + スコープ - アクセス範囲の定義(
gateway/invoke) - アプリクライアント - Client Credentials フローが有効なクライアント(シークレット付き)
Gateway 用クライアントの作成 ( M2M 認証フロー )
Gateway の認証に使う OAuth クライアントを作成します。M2M 認証フローでトークンを取得するため、リソースサーバーとカスタムスコープも作成します。
# ドメインの作成(OAuth2 エンドポイント用)
aws cognito-idp create-user-pool-domain \
--user-pool-id <USER_POOL_ID> \
--domain hello-gateway-pool
# リソースサーバーとカスタムスコープの作成
aws cognito-idp create-resource-server \
--user-pool-id <USER_POOL_ID> \
--identifier "gateway" \
--name "Gateway API" \
--scopes '[{"ScopeName":"invoke","ScopeDescription":"Invoke gateway tools"}]'
# Gateway 用クライアントの作成
aws cognito-idp create-user-pool-client \
--user-pool-id <USER_POOL_ID> \
--client-name hello-gateway-m2m-client \
--generate-secret \
--allowed-o-auth-flows client_credentials \
--allowed-o-auth-scopes "gateway/invoke" \
--allowed-o-auth-flows-user-pool-client \
--supported-identity-providers COGNITO
出力からクライアント ID を控えます。続けてクライアントシークレットを取得します。
aws cognito-idp describe-user-pool-client \
--user-pool-id <USER_POOL_ID> \
--client-id <CLIENT_ID> \
--query 'UserPoolClient.ClientSecret' --output text
ここまでで以下の情報が揃います。
| 項目 | 値の例 |
|---|---|
| ユーザープール ID | ap-northeast-1_XXXXXXXXX |
| クライアント ID | xxxxxxxxxxxxxxxxxxxxxxxxxx |
| クライアントシークレット | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| ドメイン | hello-gateway-pool |
| Discovery URL | https://cognito-idp.ap-northeast-1.amazonaws.com/<USER_POOL_ID>/.well-known/openid-configuration |
ステップ 5: Gateway の追加(CUSTOM_JWT)
補足: ツールのアップデートが早くドキュメントが追いついていない箇所が多々あります。
--helpから確認し、適宜オプション名を読み替えてください。
Cognito の情報を使って、JWT 認証付きの Gateway を追加します。
agentcore add gateway \
--name HelloGateway \
--authorizer-type CUSTOM_JWT \
--discovery-url https://cognito-idp.ap-northeast-1.amazonaws.com/<USER_POOL_ID>/.well-known/openid-configuration \
--allowed-audience <CLIENT_ID> \
--allowed-clients <CLIENT_ID> \
--client-id <CLIENT_ID> \
--client-secret <CLIENT_SECRET> \
--runtimes GatewayDemo
--name: Gateway の名前--authorizer-type CUSTOM_JWT: JWT トークンによる認証--discovery-url: Cognito の OIDC ディスカバリ URL--allowed-audience: JWT の audience クレームで許可する値--allowed-clients: 許可するクライアント ID--client-id: Gateway がベアラートークンを取得する際の OAuth クライアント ID--client-secret: Gateway がベアラートークンを取得する際の OAuth クライアントシークレット--runtimes: 関連付ける Runtime の名前
ステップ 6: Lambda ターゲットの追加
Gateway に Lambda 関数をターゲットとして追加します。
agentcore add gateway-target \
--name HelloLambda \
--type lambda-function-arn \
--lambda-arn arn:aws:lambda:ap-northeast-1:<ACCOUNT_ID>:function:hello-gateway \
--tool-schema-file tools.json \
--gateway HelloGateway
--name: ターゲットの名前--type lambda-function-arn: ターゲットの種類(Lambda 関数)--lambda-arn: Lambda 関数の ARN--tool-schema-file: ツールスキーマのファイルパス--gateway: 追加先の Gateway 名
ここまででAgentCoreの設定ファイルは以下のようになりました。
{
"$schema": "https://schema.agentcore.aws.dev/v1/agentcore.json",
"name": "GatewayDemo",
"version": 1,
"managedBy": "CDK",
"tags": {
"agentcore:created-by": "agentcore-cli",
"agentcore:project-name": "GatewayDemo"
},
"runtimes": [
{
"name": "GatewayDemo",
"build": "Container",
"entrypoint": "main.py",
"codeLocation": "app/GatewayDemo/",
"runtimeVersion": "PYTHON_3_13",
"networkMode": "PUBLIC",
"protocol": "HTTP"
}
],
"memories": [],
"credentials": [
{
"authorizerType": "OAuthCredentialProvider",
"name": "HelloGateway-oauth",
"discoveryUrl":
"https://cognito-idp.ap-northeast-1.amazonaws.com/<USER_POOL_ID>/.well-known/openid-configuration",
"vendor": "CustomOauth2",
"managed": true,
"usage": "inbound"
}
],
"evaluators": [],
"onlineEvalConfigs": [],
"agentCoreGateways": [
{
"name": "HelloGateway",
"description": "Gateway for HelloGateway",
"targets": [
{
"name": "HelloLambda",
"targetType": "lambdaFunctionArn",
"lambdaFunctionArn": {
"lambdaArn": "arn:aws:lambda:ap-northeast-1:<ACCOUNT_ID>:function:hello-gateway",
"toolSchemaFile": "tools.json"
}
}
],
"authorizerType": "CUSTOM_JWT",
"authorizerConfiguration": {
"customJwtAuthorizer": {
"discoveryUrl":
"https://cognito-idp.ap-northeast-1.amazonaws.com/<USER_POOL_ID>/.well-known/openid-configuration",
"allowedClients": [
"<CLIENT_ID>"
]
}
},
"enableSemanticSearch": true,
"exceptionLevel": "NONE"
}
],
"unassignedTargets": [],
"policyEngines": []
}
ステップ 7: デプロイ
agentcore deploy
CUSTOM_JWT を設定した場合、Gateway のベアラートークン取得に使う OAuth 認証情報の入力を求められます。今回は「Enter credentials manually」を選択しました。

「Enter API Key」という表記が紛らわしいですが、先ほど控えておいた Cognito の情報を入力します。
Enter API Key (1/2) → Cognito のクライアント ID を入力
Enter API Key (2/2) → Cognito のクライアントシークレットを入力

デプロイの完了までは 5 分くらいかかりました。

ステップ 8: 動作確認
デプロイが完了したら、Gateway のエンドポイントを確認します。
agentcore status

アクセストークンの取得
Gateway にアクセスするには、M2M 認証フローでアクセストークンを取得します。
export TOKEN=$(curl -s -X POST \
"https://<DOMAIN>.auth.ap-northeast-1.amazoncognito.com/oauth2/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=<CLIENT_ID>&client_secret=<CLIENT_SECRET>&scope=gateway/invoke" \
| python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")
ツール一覧の確認
Gateway の MCP エンドポイントに対して、tools/list リクエストを送ります。
curl -X POST <GATEWAY_URL>/mcp \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
ツールスキーマで定義した hello ツールが返ってくれば成功です。ツール名が HelloLambda___hello({ターゲット名}___{ツール名})になっている点に注目してください。

ツールの呼び出し
登録されていることが分かったので、実際にツールを呼び出してみます。
curl -X POST <GATEWAY_URL>/mcp \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"HelloLambda___hello","arguments":{"name":"こーすけ"}}}'

Lambda が返した定型文がそのまま返ってきました!Gateway がリクエストを MCP プロトコルから Lambda の呼び出しに変換し、再度レスポンスを MCP 形式に戻していることが分かりました!
補足
Lambda 側で受け取る情報
Gateway 経由で呼び出された Lambda の event には、ツールスキーマの inputSchema で定義したプロパティがフラットに渡されます。
# event の中身
{"name": "こーすけ"}
API Gateway のプロキシ統合とは異なり、ヘッダーやパスの情報は含まれません。ツールの入力パラメータだけが渡されるシンプルな構造になっていました。
また、context.client_context.custom から Gateway のメタ情報を取得できます(執筆時点での確認内容です。キー名は今後変更される可能性があります)。
def lambda_handler(event, context):
# どのツールとして呼ばれたか
tool_name = context.client_context.custom['bedrockAgentCoreToolName']
# Gateway ID
gateway_id = context.client_context.custom['bedrockAgentCoreGatewayId']
# ターゲット ID
target_id = context.client_context.custom['bedrockAgentCoreTargetId']
アーキテクチャ図
今回は私が手動でGatewayのテスト実行を行いましたが、Runtimeなどエージェントから実行される際のフローは以下になります。

リクエストの流れ:
- クライアントが Cognito の
/oauth2/tokenにクライアント ID・シークレットを送り、アクセストークンを取得する(M2M 認証) - 取得したトークンを
Authorization: Bearerヘッダーに付けて、Gateway の/mcpエンドポイントに MCP リクエストを送る - Gateway が JWT を検証し(
allowedClientsでclient_idを照合)、認証を通過したリクエストをターゲットに振り分ける - Gateway が
tools.jsonのinputSchemaに基づいて MCP リクエストを Lambda のeventに変換し、Lambda を呼び出す - Lambda のレスポンスを MCP 形式に変換してクライアントに返す
おわりに
AgentCore Gateway を使って、シンプルな Lambda 関数を MCP ツールとして公開する手順を紹介しました。
AgentCore CLI を使って構築しましたが、Preview 段階というところもありいくつか戸惑うポイントもありました。
- Cognito の準備が手動: AgentCore CLI は Gateway の作成をサポートしていますが、認証に必要な Cognito ユーザープール・リソースサーバー・アプリクライアントの作成はサポートしていません。結果として AWS CLI で手動作成する必要があり、手順が増えた印象です。
- CLI のオプション名がドキュメントと乖離: ツールのアップデートが早く、公式ドキュメントやリポジトリの README に書かれたオプション名が実際の CLI と一致しないことが多々ありました。オプション引数の名前など、
--helpで確認しながら進める必要がありました。 - デプロイ時のクレデンシャル入力の UI: 「Enter API Key」という表記で Cognito のクライアント ID・シークレットを求められるなど、UI の表現が直感的でない箇所があります。
これからのアップデートに期待したいです。
とはいえ、AgentCore Gateway 自体の仕組みは強力で、エージェントに様々なツールを渡す選択肢として非常に有望だと思います。







