GenU にAgentCore Gateway を統合して Lambda 関数を MCP ツールとして使えるようにしてみた【備忘録】

2026.04.04

 はじめにこんにちは！AI 事業本部のこーすけです。
AWS の生成 AI アプリ向けリファレンス実装「GenU（Generative AI Use Cases）」には、AgentCore と連携してチャット UI 上で AI エージェントを動かす機能があります。今回は、AgentCore Gateway を使って Lambda 関数を MCP ツールとして GenU のエージェントから呼び出せるようにする方法を紹介します。
本記事では、Lambda 関数の作成から Gateway のセットアップ、GenU への統合まで、一連の流れを解説します。
備忘録なので結構説明がくどいところもあります。
こちらも併せてご覧ください。

https://dev.classmethod.jp/articles/agentcore-gateway/
 Amazon Bedrock AgentCore とはAmazon Bedrock AgentCore は、AI エージェントをローカルの試作段階から本番環境で安全かつ大規模に運用するためのマネージド基盤です。特定のフレームワークやモデルに依存しない開発ができるほか、推論ステップを可視化するダッシュボード（Observability）も備えています。


機能
概要


Runtime
エージェントのサーバーレス実行環境。自動スケーリング・ストリーミング対応

Gateway
API や Lambda を MCP ツールに変換し、統一エンドポイントで提供（本記事で使用）

Memory
会話履歴やコンテキストの永続化

Identity
認証・認可の管理

Tools
Code Interpreter、Browser などの組み込みツール

Observability
推論ステップやツール実行の可視化ダッシュボード

 AgentCore Gateway とはAgentCore Gateway は、さまざまなバックエンドサービスを MCP（Model Context Protocol）ツールに変換して一つのエンドポイントにまとめるマネージドサービスです。
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html
主な機能は以下の表のとおりです。


機能
概要


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 に追加できるターゲット（バックエンド接続先）は非常にバリエーションに富んでいます。


ターゲット
概要
ユースケース


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 エンドポイントに

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-supported-targets.html
今回はシンプルな Lambda 関数をターゲットとして使おうと思います。
 GenU（Generative AI Use Cases JP）とはGenU は AWS が公開している生成 AI アプリのリファレンス実装です。v5.0.0 から AgentCore 連携機能が追加され、チャット UI 上で MCP ツール付きの AI エージェントを簡単に動かせるようになりました。
https://github.com/aws-samples/generative-ai-use-cases
GenU の AgentCore ユースケースを有効化すると、以下のことができます。
チャット UI 上でエージェントと対話: 「AgentCore」ページが追加され、チャットができる
MCP ツールの利用: 現在時刻の取得、AWS ドキュメント検索、アーキテクチャ図の生成など、デフォルトで 7 つの MCP サーバーが使える
こちらのブログで、AgentCore を有効化し GenU をデプロイする手順を説明していますのでご覧ください。

https://dev.classmethod.jp/articles/genu-agentcore/
 mcp-proxy-for-aws とは今回の作業で出てくるトピックについてあらかじめ説明しておきます。

mcp-proxy-for-aws は、MCP クライアント（AI エージェント）と AWS 上の IAM で保護された MCP サーバーをつなぐブリッジです。
MCP の標準仕様が想定する認証方式は OAuth ですが、AgentCore Gateway はAWS IAM（SigV4）による認証もサポートしています。標準の MCP クライアントはSigV4 署名の仕組みを持っていないため、mcp-proxy-for-aws が間に入り、Runtime コンテナの IAM ロール認証情報を使ってリクエストに署名します。
主な機能は以下の通りです。
SigV4 認証の処理: AgentCore Runtime の IAM ロールを使って Gateway に認証
プロトコル変換: MCP と AWS API 呼び出しの橋渡し
動的ツール検出: Gateway が公開するツール一覧を自動取得
https://github.com/aws/mcp-proxy-for-aws
 どう動くのか今回実装する流れをシーケンス図で整理してみます。


ステップ
処理内容
詳細


①
ユーザーがチャットメッセージを送信
GenU の UI でユーザーが「hello-gateway ツールを使って挨拶して」とメッセージを送信

②
GenU が MCP リクエストを proxy に送信
Runtime が MCP （JSON-RPC リクエスト）でツール呼び出しリクエストを作成。

③
Proxy が IAM 認証情報を取得
mcp-proxy-for-aws が Runtime コンテナ内 の環境変数（AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN）から Runtime の IAM ロール認証情報を読み込み

④
Proxy が SigV4 署名を生成
取得した認証情報を使って AWS Signature Version 4 を計算し、Authorization ヘッダーに署名を追加

⑤
Proxy が認証済みリクエストを Gateway に送信
SigV4 署名付きの HTTPS リクエストを Gateway のエンドポイント（https://<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp）に POST

⑥
Gateway が署名を検証
Gateway は authorizerType: AWS_IAM の設定に従い、SigV4 署名を検証。IAM ロールに InvokeGateway 権限があるか確認

⑦
Gateway が Lambda を実行
認証成功後、Gateway は MCP リクエストから取得したパラメータ（{"name": "Kosuke"}）を Lambda の event として渡して実行

⑧
Lambda が結果を返す
Lambda が処理を実行し、{"message": "Hello, Kosuke!"} というレスポンスを Gateway に返却

⑨
Gateway が MCP レスポンスを返す
Gateway は Lambda の結果を MCP （JSON-RPC レスポンス）にラップして proxy に返却

⑩
ユーザーに結果を表示
GenU が MCP レスポンスを受け取り、エージェントの応答としてユーザーに「Hello, Kosuke! This response is from Lambda via AgentCore Gateway.」と表示

このプロキシのおかげで、MCP クライアント側（Runtime）は AWS 認証の詳細を意識せず、MCP ツールを利用できます。
 作業開始！前置きが長くなりすぎました。早速今回やることについて整理していきます！
 今回やることGenU には AgentCore の Generic Runtime が組み込まれており、デフォルトで複数の MCP ツール（時刻取得、AWS ドキュメント検索、アーキテクチャ図生成など）が使えます。
今回は、この Generic Runtime に Gateway を連携し、 Lambda 関数を MCP ツールとして登録します。すると、チャット UI 上のエージェントから Gateway 経由で MCP ツールとして Lambda 関数を呼び出せるようになります。
実装ステップは以下の通りです。
Lambda 関数を作成する
ツールスキーマを定義する
Gateway をデプロイする
GenU の設定に Gateway ARN を追加する
MCP 設定ファイルに Gateway 接続を追加する
GenU をデプロイして動作確認する
 前提条件GenU がデプロイ済み
AWS の認証情報が設定済み
AgentCore CLI がインストール済み（npm install -g @aws/agentcore）
https://github.com/aws/agentcore-cli
 ステップ 1: Lambda 関数の作成Gateway のターゲットとなる Lambda 関数を作成します。シンプルな挨拶関数にします。
lambda_function.py
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 関数を作成（リージョンとアカウント ID は適宜変更）
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 を控えておきます。
arn:aws:lambda:ap-northeast-1:123456789012:function:hello-gateway
 ステップ 2: ツールスキーマの作成Gateway が Lambda を MCP ツールとして公開するには、ツールの入出力を定義する ツールスキーマ（tools.json）が必要です。
inputSchema で定義したプロパティが、そのまま Lambda の event として渡されます。
tools.json
[
  {
    "name": "hello",
    "description": "名前を受け取って挨拶メッセージを返します。",
    "inputSchema": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string",
          "description": "挨拶する相手の名前"
        }
      },
      "required": ["name"]
    }
  }
]
 ステップ 3: Gateway のデプロイAgentCore CLI を使って プロジェクトを作成し、Gateway をデプロイします。
 1. AgentCore プロジェクトの作成詳しくは下記ブログをご覧ください。

https://dev.classmethod.jp/articles/genu-agent-core-cli/
agentcore create \
  --name GatewayDemo \
  --language python \
  --build container \
  --protocol http \
  --framework strands \
  --model-provider bedrock \
  --memory none \
  --network-mode PUBLIC
 2. Gateway の追加作成したプロジェクトに Gateway を紐づけます。
mcp-proxy-for-aws は Runtime の IAM ロール認証情報を使って SigV4 署名を生成します。そのため、Gateway 側のインバウンド認証を AWS_IAM に設定する必要があります。
本来であれば --authorizer-type AWS_IAM を指定したいところですが、CLI の制限により一旦 NONE で作成します。後で agentcore.json を直接編集して AWS_IAM に変更します。
agentcore add gateway \
  --name HelloGateway \
  --authorizer-type NONE \
  --runtimes GatewayDemo
注意: AgentCore CLI v0.5.0 時点では --authorizer-type に AWS_IAM を指定できません（NONE と CUSTOM_JWT のみ対応）。
公式ドキュメントでは AWS_IAM がサポートされていると記載されていますが、CLI の実装が追いついていないようです。今後のアップデートに期待しましょう。

https://github.com/aws/agentcore-cli/blob/main/docs/gateway.md
 3. Lambda ターゲットの追加Gateway に Lambda 関数をターゲットとして追加します。
agentcore add gateway-target \
  --name HelloLambda \
  --type lambda-function-arn \
  --lambda-arn arn:aws:lambda:ap-northeast-1:123456789012:function:hello-gateway \
  --tool-schema-file tools.json \
  --gateway HelloGateway
 4. agentcore.json を編集して認証タイプを AWS_IAM に変更ここで Gateway のインバウンド認証を AWS_IAM に設定します。
CLI では指定できませんが、agentcore.json のスキーマには AWS_IAM が定義されているため、直接編集すれば問題なくデプロイできます。
agentcore/agentcore.json の agentCoreGateways 内の authorizerType を NONE から AWS_IAM に変更します。
  "agentCoreGateways": [
    {
      "name": "HelloGateway",
      ...
-     "authorizerType": "NONE",
+     "authorizerType": "AWS_IAM",
      ...
    }
  ]
補足:
Gateway の認証タイプはデプロイ後に変更できません。必ず初回デプロイ前に agentcore.json を編集してください。
AgentCore CLI の将来のバージョンで --authorizer-type AWS_IAM がサポートされれば、この手動編集は不要になります。
 5. デプロイagentcore deploy
デプロイには 5 分程度かかります。
デプロイが完了したら、Gateway の情報を確認します。
agentcore status
ここから Gateway ID が取得できます。Gateway ARN と MCP エンドポイント URL は以下の形式で構成されます。GenU への統合に必要なので控えておいてください。
Gateway ARN:
arn:aws:bedrock-agentcore:<region>:<account-id>:gateway/<gateway-id>
Gateway MCP エンドポイント URL:
https://<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp
 ステップ 4:　 GenU の設定に Gateway ARN を追加それでは、作成した Gateway を GenU の Generic Runtime に統合していきます。
まず、GenU のプロジェクトディレクトリで packages/cdk/parameter.ts を編集します。
const envs: Record<string, Partial<StackInput>> = {
  myenv: {
    modelRegion: "us-east-1",
    createGenericAgentCoreRuntime: true,
    agentCoreGatewayArns: [
      "arn:aws:bedrock-agentcore:ap-northeast-1:<account-id>:gateway/<gateway-id>",
    ],
  },
};
agentCoreGatewayArns に Gateway の ARN を配列で指定します。これにより、GenU で CDK デプロイ時、以下の IAM ポリシーが Generic Runtime のロールに自動追加されます。
{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeGateway",
  "Resource": "arn:aws:bedrock-agentcore:ap-northeast-1:<account-id>:gateway/<gateway-id>"
}
agentCoreGatewayArns に Gateway の ARN を指定することで、最小権限の原則に従った IAM ポリシーが設定されます。
このように記載されている部分がここに該当しますね。 ARN を指定したGatewayのみをInvokeできる権限を自動で追加してくれます。

https://github.com/aws-samples/generative-ai-use-cases/blob/main/docs/ja/DEPLOY_OPTION.md#agentcore-ユースケースの有効化
 ステップ 5 : MCP 設定ファイルに Gateway 接続を追加次に、MCP 接続の設定を行います。
GenU の Generic Runtime で使用する MCP 設定ファイルに、Gateway への接続設定を追加します。
以下のエントリを mcpServers オブジェクトに追加します。
packages/cdk/lambda-python/generic-agent-core-runtime/mcp-configs/generic/mcp.json
{
  "mcpServers": {
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time"],
      "metadata": {
        "category": "Utility",
        "description": "Provides current time and date functionality"
      }
    },
    // ... (既存の MCP サーバー設定) ...
    "hello-gateway": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws",
        "https://<gateway-id>.gateway.bedrock-agentcore.ap-northeast-1.amazonaws.com/mcp"
      ],
      "metadata": {
        "category": "Custom",
        "description": "Lambda function via AgentCore Gateway"
      }
    }
  }
}
設定内容の説明：
サーバー名: hello-gateway（任意の名前で OK）
command: uvx - Python パッケージを一時的に実行
args: mcp-proxy-for-aws と Gateway の MCP エンドポイント URL を指定
metadata: UI での表示用情報
 ステップ 6: デプロイして動作確認GenU のプロジェクトディレクトリで CDK デプロイを実行します。
npm run cdk:deploy
デプロイが完了したら、GenU の Web UI にアクセスします。
https://xxxxxxxx.cloudfront.net
 1. AgentCore ページを開くサイドメニューから「AgentCore」を選択します。
 2. Lambda を呼び出すチャット入力欄に以下のようなメッセージを送信します。
hello-gateway ツールを使って、「こーすけ」に挨拶してください
エージェントが hello-gateway MCP サーバーのツールを呼び出し、Lambda 関数から返された挨拶メッセージが表示されます！
 3. トレースの確認レスポンスに表示される「トレース」セクションを展開すると、以下の情報が確認できます。
どのツールが呼び出されたか（HelloLambda___hello）
どんな引数で呼び出されたか（{"name": "こーすけ"}）
Lambda からの返り値
ちゃんと使用されていることが確認できました！

 おわりに本記事では、AgentCore Gateway を使って Lambda 関数を MCP ツール化し、GenU の Generic Runtime に統合してチャット UI から呼び出せるようにする一連の流れを紹介しました。
agentCoreGatewayArns への ARN 指定と mcp.json へのエンドポイント追加、この2つを設定するだけで既存の Lambda 関数を GenU のエージェントのツールとして使えるようになります。その他社内の業務ロジックや外部サービスとの連携など、様々なユースケースに応用できそうですね。

GenU にAgentCore Gateway を統合して Lambda 関数を MCP ツールとして使えるようにしてみた【備忘録】

はじめに

Amazon Bedrock AgentCore とは

AgentCore Gateway とは

GenU（Generative AI Use Cases JP）とは

mcp-proxy-for-aws とは

どう動くのか

作業開始！

今回やること

前提条件

ステップ 1: Lambda 関数の作成

ステップ 2: ツールスキーマの作成

ステップ 3: Gateway のデプロイ

1. AgentCore プロジェクトの作成

2. Gateway の追加

3. Lambda ターゲットの追加

4. agentcore.json を編集して認証タイプを AWS_IAM に変更

5. デプロイ

ステップ 4:　 GenU の設定に Gateway ARN を追加

ステップ 5 : MCP 設定ファイルに Gateway 接続を追加

ステップ 6: デプロイして動作確認

1. AgentCore ページを開く

2. Lambda を呼び出す

3. トレースの確認

おわりに

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS

機能	概要
Runtime	エージェントのサーバーレス実行環境。自動スケーリング・ストリーミング対応
Gateway	API や Lambda を MCP ツールに変換し、統一エンドポイントで提供（本記事で使用）
Memory	会話履歴やコンテキストの永続化
Identity	認証・認可の管理
Tools	Code Interpreter、Browser などの組み込みツール
Observability	推論ステップやツール実行の可視化ダッシュボード

機能	概要
Security Guard	OAuth 認可により、許可されたユーザー・エージェントのみがツールにアクセスできるようにする
Translation	MCP プロトコルのリクエストを API 呼び出しや Lambda 実行に自動変換。プロトコル統合やバージョン管理が不要になる
Composition	複数の API・Lambda・ツールを単一の MCP エンドポイントに統合し、エージェントからのアクセスを一本化する
Secure Credential Exchange	ツールごとに異なる認証要件（API キー、OAuth 等）に対応した認証情報の注入を自動処理する
Semantic Tool Selection	登録されたツール群からコンテキストに最適なツールを自動選択。プロンプトサイズの削減とレイテンシの低下に寄与する
Infrastructure Manager	サーバーレスで動作し、監視・監査機能を内蔵。インフラ管理のオーバーヘッドを排除する

ターゲット	概要	ユースケース
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 エンドポイントに

ステップ	処理内容	詳細
①	ユーザーがチャットメッセージを送信	GenU の UI でユーザーが「hello-gateway ツールを使って挨拶して」とメッセージを送信
②	GenU が MCP リクエストを proxy に送信	Runtime が MCP （JSON-RPC リクエスト）でツール呼び出しリクエストを作成。
③	Proxy が IAM 認証情報を取得	`mcp-proxy-for-aws` が Runtime コンテナ内の環境変数（`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`）から Runtime の IAM ロール認証情報を読み込み
④	Proxy が SigV4 署名を生成	取得した認証情報を使って AWS Signature Version 4 を計算し、`Authorization` ヘッダーに署名を追加
⑤	Proxy が認証済みリクエストを Gateway に送信	SigV4 署名付きの HTTPS リクエストを Gateway のエンドポイント（`https://<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp`）に POST
⑥	Gateway が署名を検証	Gateway は `authorizerType: AWS_IAM` の設定に従い、SigV4 署名を検証。IAM ロールに `InvokeGateway` 権限があるか確認
⑦	Gateway が Lambda を実行	認証成功後、Gateway は MCP リクエストから取得したパラメータ（`{"name": "Kosuke"}`）を Lambda の `event` として渡して実行
⑧	Lambda が結果を返す	Lambda が処理を実行し、`{"message": "Hello, Kosuke!"}` というレスポンスを Gateway に返却
⑨	Gateway が MCP レスポンスを返す	Gateway は Lambda の結果を MCP （JSON-RPC レスポンス）にラップして proxy に返却
⑩	ユーザーに結果を表示	GenU が MCP レスポンスを受け取り、エージェントの応答としてユーザーに「Hello, Kosuke! This response is from Lambda via AgentCore Gateway.」と表示

はじめに

Amazon Bedrock AgentCore とは

AgentCore Gateway とは

GenU（Generative AI Use Cases JP）とは

mcp-proxy-for-aws とは

どう動くのか

作業開始！

今回やること

前提条件

ステップ 1: Lambda 関数の作成

ステップ 2: ツールスキーマの作成

ステップ 3: Gateway のデプロイ

1. AgentCore プロジェクトの作成

2. Gateway の追加

3. Lambda ターゲットの追加

4. agentcore.json を編集して認証タイプを AWS_IAM に変更

5. デプロイ

ステップ 4: GenU の設定に Gateway ARN を追加

ステップ 5 : MCP 設定ファイルに Gateway 接続を追加

ステップ 6: デプロイして動作確認

1. AgentCore ページを開く

2. Lambda を呼び出す

3. トレースの確認

おわりに

関連記事

EVENTS

ステップ 4:　 GenU の設定に Gateway ARN を追加