はじめに
こんにちは！ アプリケーションサービス本部ディベロップメントサービス１課の森山です。
前回に引き続き、API Gateway に関連したアップデートを検証してみます。
今回検証するのは以下の２つのアップデートです。
API Gateway が MCP プロキシ対応を追加
API Gateway が MCP プロキシサポートを追加し、既存の REST API を MCP 互換エンドポイントに変換できるようになりました。
これで従来の REST API を 少ない作業で MCP 化し、AIエージェント で操作することが可能になりました。
Amazon Bedrock AgentCore にポリシー機能が追加
Amazon Bedrock AgentCore に Policy が追加され、エージェントのデプロイをスケールするための制御機能が追加されました。
なお、こちらはプレビュー機能ですので、必ず最新のドキュメントで仕様を確認することをお勧めします。
検証内容
今回はこの２つの新機能を活用し、決済・返金機能を持つ REST API を MCP 化しつつ、新機能を使った制御機能を試してみます。
この２つの新機能を組み合わせることで、既存の REST API を少ない作業で MCP (Model Context Protocol：AI エージェントがツールを利用するための標準プロトコル) 化できるかつ、柔軟なポリシーで操作を制御することができそうです。
検証の流れは以下の通りです:
- REST API を準備
- AgentCore Gateway で MCP 化（AI エージェントから操作可能に）
- MCP Inspector で動作確認
- Cedar ポリシーで操作を制御（特定の操作を許可/拒否）
- ポリシー適用後の動作確認
なお今回は us-east-1 で確認しました。
API Gateway の MCP 化を試してみる
まずは、MCP 化を進めていきます。
なお、今回は時系列で検証結果を記載していくので、トライアンドエラーな手順になっています。
先につまづきポイントを書いておきます。
- OpenAPI 仕様での定義: API Gateway を MCP 化するには、OpenAPI仕様に従って API を定義する必要があります。
operationIdやリクエスト/レスポンスのスキーマ定義が必須です。
準備
まずは MCP 化対象とする REST API を作成します。
今回は以下のように AWS SAM を利用し、AWS::Serverless::Functionを使った簡単な方法で、決済と返金の API を準備しておきます。
PaymentFunction: Type: AWS::Serverless::Function Properties: CodeUri: payment/ Handler: app.lambdaHandler Runtime: nodejs24.x Events: Payment: Type: Api Properties: Path: /payment Method: post
AWS SAM の完成系ソースは以下で公開しています。 （この後の手順で少し変更が入ります）
Lambda 関数の実装コードはリクエストパラメタをそのまま応答する程度のシンプルなものですので記載を割愛します。
AgentCore Gateway の作成
今回はマネジメントコンソール上から作成していきます。
名前はpayment-gatewayとし、インバウンド認証は JWT を使用した認証としておきます。
インバウンド認証は MCP を利用するクライアントに対する認証です。
画面の記載の通り、これを選択すると自動で M2M (Machine to Machine：マシン間通信) 用のユーザープールが作成されるので、ここからアクセストークンを発行し、Bearer 認証を行います。
検証だけであれば、インバウンド認証ば不要なのですが、この後ご紹介する Policy 機能では必須になるため設定しておきます。
ターゲットは新機能であるAPI Gatewayを選択し、先ほど作成した API および Stage を選択します。
その後、Select API Operationsで、MCP にツールとして持たせるエンドポイントを指定します。
Operation IDがない場合、Name overrideが必須、といったエラーが表示されるため、一旦適当な名前をつけます。
このoperationIdは、OpenAPI 仕様で API 操作を一意に識別するための ID で、MCP 化する際は、この ID がツール名として使用されます。
その後、保存をしようと以下のエラーが出てしまいました。
Operation IDも含め、OpenAPI 仕様で API を定義していないと Gateway 化できないようです。
想定ではあるのですが、各エンドポイント の役割、リクエストパラメータの構成（数や属性）を理解できないと MCP のツールとして使えないためだと思われます。
OpenAPI 仕様で API Gateway を作り直す
そこで、AWS SAMのテンプレートを以下のように OpenAPI 仕様に従って API を定義します。
PaymentApi: Type: AWS::Serverless::Api DependsOn: - PaymentFunction - RefundFunction Properties: StageName: Prod DefinitionBody: openapi: "3.0.1" info: title: Payment API version: "1.0.0" description: API for payment processing and refunds paths: /payment: post: summary: Create a payment description: Process a new payment transaction operationId: createPayment requestBody: required: true content: application/json: schema: type: object properties: amount: type: number description: type: string responses: "200": description: Payment created successfully content: application/json: schema: type: object properties: paymentId: type: string amount: type: number description: type: string status: type: string "400": description: Bad request content: application/json: schema: type: object properties: error: type: string x-amazon-apigateway-integration: type: aws_proxy httpMethod: POST uri: Fn::Sub: "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${PaymentFunction.Arn}/invocations" passthroughBehavior: when_no_match
これで、/paymentの操作 ID（operationId）、概要（summary）、リクエスト/レスポンスのスキーマ定義が実装されました。
再度試してみます。
Operation IDが自動反映されていますね。
最後に Gateway を保存し、作成完了です。
動作確認
これで MCP 化できたので、動作確認してみます。
今回は、MCP のクライアントとして、MCP Inspector を利用してみます。
nodejs 環境があれば、npx @modelcontextprotocol/inspectorのみで実行可能です。
まずは、MCP のエンドポイントを取得します。
Gateway の詳細のところに、Gateway リソース URL が定義されていますので、これをコピーしておきます。
そして、下記の通り、Transport Type をStreamable HTTPにし、Gateway リソース URL を設定します。
また、今回はインバウンド認証を実施しているので、Authentication のところにアクセストークンを設定しておきます。
アクセストークンは、AgentCore Gateway 作成時に自動生成された Cognito ユーザープールから取得します。
コマンド例を載せておきます。
curl -X POST https://[xxxxxxxxx].auth.us-east-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]"
ここまでの設定に問題なければ、接続が成功するはずです。
次に、List Toolsで MCP が利用できるツールを確認してみます。
問題なさそうですね！
次に、Payment ツール を実行してみます。
必要なパラメータを入力し、Run Toolを実行します。
成功しました！動いていそうです。
ポリシー機能を試してみる
次に、先ほど作成した Gateway にポリシーを設定してみます。
こちらも先につまづきポイントを書いておきます。
- IAM ポリシーの追加: ポリシー機能を利用する際、AgentCore Gateway のサービスロールに追加の権限が必要になります（検証では
BedrockAgentCoreFullAccessを使用しますが、本番環境では最小権限を推奨） - 明示的な許可を入れる: ○○ を禁止する、といったポリシーだけだと全ての操作が拒否されます。許可する操作を明示的にポリシーに記載する必要があります。
ポリシーの設定
では、作っていきます。
Bedrock Agent Core のメニューにPolicyというメニューがあるので、Create policy engineから作成していきます。
名前は検証用の名前を入れておきます。
次にポリシーを設定していきますが、ポリシーの制御は Cedar 言語（AWS が開発した認可ポリシー言語）で記載します。
これまで Amazon Verified Permissions という認可サービスで利用されていた言語で、 簡単に説明すると、「誰が（Principal）」「何を（Action）」「どのリソースに対して（Resource）」「どんな条件で（When）」「許可/拒否する（permit/forbid）」を細かく指定できる、属性ベースのアクセス制御を実現する言語です。
ただし今回の新機能は、この Cedar 言語を直接記述する必要がなく、自然言語で生成できます。
今回はgameがdescriptionに含まれる製品は購入できません。という制限を入れてみます。
このようなポリシーができましたので、保存してみます。
forbid (
principal,
action == AgentCore::Action::"api-gateway___createPayment",
resource ==
AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-east-1:[111122223333]:gateway/payment-gateway-jsl1d1ctoi"
)
when
{
(((context.input) has description) &&
(((context.input).description) like "*game*"))
};
しかし、この記載だと全ての操作が拒否されるというエラーが出ます。
どうやら、拒否だけではなく許可も必要な模様です。
では、少し表現を変えて、gameがdescriptionに含まれる製品以外は購入可能でポリシーを作ってみます。
permit (
principal,
action == AgentCore::Action::"api-gateway___createPayment",
resource ==
AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-east-1:[111122223333]:gateway/payment-gateway-jsl1d1ctoi"
)
when
{
!(((context.input) has description) &&
(((context.input).description) like "*game*"))
};
できました！
次に Policy に Gateway を紐付けます。
紐付け時には Enforcement modeの指定ができ、ログ表示だけするか、実際に拒否をするかの選択肢が出てきます。
今回は、Enable enforcementを選択しておきます。
これで紐付けも完成です！
動作確認（ポリシー）
では、MCP Inspector を利用し、ツールの確認から動作確認をしていきます。
・・・失敗しています。
このエラー原因について、公式ドキュメントに記載を見つけられなかったのですが、AgentCore Gateway のサービスロールが不足している模様です。
今回は検証のため、BedrockAgentCoreFullAccessを付与しておきます。
セキュリティ上の注意:
今回は検証のため、BedrockAgentCoreFullAccessを付与していますが、本番環境では必ず最小権限の原則に従い、必要な権限のみを付与してください。
再度試すと、エラーは出なくなりました。
しかし、返金(Refund)側のツールが消えていますね。
返金についてはポリシーで触れていないので、明示的に許可しないといけないようですが、一旦検証を進めます。
book を購入してみます。
成功です。
game を購入してみます。
"MCP error -32002: Tool Execution Denied: Tool call not allowed due to policy enforcement [No policy applies to the request (denied by default).]"となり、拒否されています！
No policy applies to the requestとあるように利用できるツールには明示的な許可が必要そうですね。
返金も許可してみる
最後に先ほど返金のツールが表示されていなかったので、返金は無条件に許可してみます。
出てきました！
動作も問題ないです。
まとめ
今回は、API Gateway の MCP プロキシ対応と Amazon Bedrock AgentCore のポリシー機能という 2 つの新機能を検証しました。
試してみるまで分からなかったのですが、OpenAPI 仕様での API 定義が必須であることや、ポリシーの挙動（許可も必要）も理解することができました。
OpenAPI 仕様での定義は必要ですが、API のロジック自体は変更せずに、生成 AI エージェントから安全に利用できる環境が作れるので、業務効率化なんかに使えるのかな。と感じました。
まだポリシー機能は、プレビュー機能のため、今後の動向を見守る必要はある点にはご注意ください！
この記事が誰かのお役に立てば幸いです！
