developersIO
AgentCore Gateway × VPC Lambda でAI Starterのマルチエージェントを構築してみた

AgentCore Gateway × VPC Lambda でAI Starterのマルチエージェントを構築してみた

既存の MCP 統合を活かし、AgentCore Gateway の MCP ターゲットで VPC Lambda サブエージェントをツールとして公開。アプリコード変更なしでマルチエージェント構成を実現した手順とハマりポイントをまとめます。
Amazon Bedrock AgentCoreAWS LambdaModel Context Protocol (MCP)Amazon Bedrock
2026.07.21

はじめに

AI Starterに「サブエージェント」を追加したい場面に遭遇しました。親エージェント（アシスタント）が自分で処理しきれないタスクを専門のサブエージェントに委譲し、その結果を取り込んで回答する——いわゆるマルチエージェント構成です。

AI Starterに MCP（Model Context Protocol）統合が実装されており、外部の MCP サーバーをツールとして呼び出す仕組みがあります。この既存の MCP 統合を活用して、サブエージェントを追加できないか？ という疑問から調査を始めました。

AI Starterにサブエージェントを追加できるか？

MCP 統合の仕組み

調べてみると、AI Starterの MCP クライアントは Streamable HTTP Transport を使ってリモート MCP サーバーと通信しています。流れはシンプルです：

  1. MCP サーバーの URL を登録
  2. 起動時に tools/list でツール一覧を取得
  3. LLM がツール呼び出しを決定 → tools/call で実行
  4. 結果を LLM のコンテキストに返す

つまり、MCP サーバーとして振る舞うエンドポイントさえ用意すれば、アプリケーション側は「単なるツール」として扱います。サブエージェントの内部が LLM を呼び出していようが、単純なロジックだろうが、MCP のインターフェースさえ満たせば透過的に動きます。

AgentCore Gateway が MCP アグリゲーターになる

ここで Amazon Bedrock AgentCore Gateway の出番です。AgentCore Gateway には MCP ターゲット という機能があり、Lambda 関数を MCP ツールとしてラップしてくれます。

構成図：

agentcore-gateway-mcp-multi-agent-vpc-lambda-architecture

Gateway が tools/list に応答し、Lambda ベースのサブエージェントをツールとして公開してくれるため、アプリケーション側のコード変更は不要です。

MCP ターゲット vs HTTP ターゲット

AgentCore Gateway には「MCP ターゲット」と「HTTP ターゲット」の2種類があります。ここで重要な発見がありました：

MCP ターゲット HTTP ターゲット
tools/list で発見可能 はい いいえ
ツールスキーマ定義 必要（name, description, inputSchema） 不要（パススルー）
用途 ツールとして呼び出し API プロキシ

HTTP ターゲットは tools/list に現れないため、MCP クライアントからは見えません。サブエージェントとして使うなら MCP ターゲット一択 です。

VPC Lambda でサブエージェントを構築する

セキュリティグループのインバウンドルールを追加

セキュリティグループのインバウンドルールに HTTPS (443) / ソース: 自身の SG を追加します。これにより、同じ SG 内の Lambda から VPC Endpoint へ HTTPS 通信が可能になります。

  1. VPC コンソール → セキュリティグループ → インバウンドのルールを編集
    SCR-20260717-jfsh (1)

  2. ルールを追加を押す

  3. タイプ： HTTPS

  4. ソース： カスタム

  5. 対象： 自身のセキュリティグループID

  6. ルールを保存を押す
    SCR-20260717-jgkr (2)

VPC Endpoint の作成

VPC 内の Lambda から Bedrock を呼ぶには、VPC Endpoint が必要です（NAT Gateway は不要）。

  1. VPC コンソール → エンドポイント → エンドポイントを作成

  2. タイプ: AWSのサービス
    SCR-20260717-jbzf

  3. サービス: com.amazonaws.ap-northeast-1.bedrock-runtime
    SCR-20260717-jcan

  4. VPCを選択
    SCR-20260717-jccm (1)

  5. サブネットを選択
    SCR-20260717-jcfa (1)

  6. セキュリティグループを選択
    SCR-20260717-jcgn (1)

Lambda 関数の作成

VPC Lambda でサブエージェントを実装します。ここでは「要約エージェント」を例にします。

  • ランタイム: Python 3.12
  • VPC: VPC Endpoint と同じ VPC・サブネット・SG を指定
  • タイムアウト: LLM 呼び出しがあるため 30 秒以上に設定
  • IAM ロール: bedrock:InvokeModel 権限を付与
  1. Lambda コンソール → 関数 → 関数を作成
    SCR-20260717-jcrh (1)

２. 一つから作成 を選択
SCR-20260717-jgrv

  1. 安価のため、 ARM64アーキテクチャ を有効化

  2. VPCを有効化

  3. セキュリティグループを選択

  4. 保存ボタンを押す
    SCR-20260717-jgpx (2)

  5. 関数を作成を押す
    SCR-20260717-jgyw (1)

  6. 以下の内容でLambdaの関数を設定

lambda_function.py
import boto3
import json

bedrock = boto3.client("bedrock-runtime")

SYSTEM_PROMPT = "You are a summarizer. Summarize the given text concisely in bullet points."

def lambda_handler(event, context):
    text = event.get("text", "")
    response = bedrock.converse(
        modelId="jp.anthropic.claude-haiku-4-5-20251001-v1:0",
        system=[{"text": SYSTEM_PROMPT}],
        messages=[{"role": "user", "content": [{"text": text}]}],
        inferenceConfig={"maxTokens": 2048},
    )
    return {
        "result": response["output"]["message"]["content"][0]["text"]
    }

SCR-20260717-jhmc

  1. 設定 → アクセス権限 → 編集
    SCR-20260717-jikr (1)

  2. タイムアウト：１分

  3. 新しいロールの作成を選択
    SCR-20260717-jkph (1)

  4. 以下の内容でロールを作成

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "*"
    }
  ]
}

SCR-20260717-jjxm (1)

  1. Test → Creat new test event
    SCR-20260717-jlch (1)

  2. Invocation type: Syncronous

  3. Events sharing settings: Private

  4. JSON eventを以下の内容で設定

{
  "text": "Amazon Bedrock is a fully managed service that makes foundation models from leading AI companies available through a single API. It offers a broad range of models to choose from, along with capabilities to build generative AI applications with security, privacy, and responsible AI."
}

SCR-20260717-jlju (1)

テストが成功すれば大丈夫です。

AgentCore Gateway のセットアップ

  1. Bedrock コンソール → AgentCore → ゲートウェイ → ゲートウェイを作成

  2. IAMアクセス許可: デフォルトロールの作成

  3. ターゲット: MCP target
    SCR-20260717-kumu (2)

  4. ターゲットタイプ: Lambda ARN

  5. Lambda ARN: 前作ったLambdaのARN
    SCR-20260717-kuoq (1)

  6. インラインスキーマ（JSON エディタに入力）:

[
  {
    "name": "summarize_text",
    "description": "Summarize given text into concise bullet points. Use when user asks to summarize long content.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "text": {
          "type": "string",
          "description": "The text to summarize"
        }
      },
      "required": ["text"]
    }
  }
]

SCR-20260717-kxim (1)

スキーマは inputSchema 部分だけでなく、name と description を含む配列形式で記述する必要があります。inputSchema だけ貼ると以下のバリデーションエラーになります：

Value at 'targetConfiguration.mcp.lambda.toolSchema.inlinePayload.1.member.name'
failed to satisfy constraint: Member must not be null

JWT 認証を使う場合、Amazon Cognito User Pool の情報を設定します：

  • Issuer: https://cognito-idp.ap-northeast-1.amazonaws.com/<USER_POOL_ID>
  • Audience: Cognito App Client ID

MCP エンドポイントの動作確認

Gateway 作成後に発行される MCP エンドポイント URL で動作確認します。

# ツール一覧の取得
curl -X POST \
  https://<GATEWAY_ID>.gateway.bedrock-agentcore.ap-northeast-1.amazonaws.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

レスポンスにツールが表示されれば成功です。ツール名は Gateway が自動的にターゲット名をプレフィックスとして付与します（例: target-xxx___summarize_text）。

# ツールの実行テスト
curl -X POST \
  https://<GATEWAY_ID>.gateway.bedrock-agentcore.ap-northeast-1.amazonaws.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"<TARGET_PREFIX>___summarize_text","arguments":{"text":"テスト用のテキスト..."}}}'

SCR-20260717-lpnx (1)

SCR-20260717-lpxg (1)

AI Starter でサブエージェントを構築する

外部サービスを追加する

  1. AI Starter 管理コンソール → 外部サービス
    SCR-20260717-mhnd

  2. 新規追加を選択
    SCR-20260718-name

  3. サービスURL: 前作ったAgentCore ゲートウェイのURL
    SCR-20260718-nbmw (1)

新規アシスタント（ユースケース）を作成する

  1. AI Starter 管理コンソール → アシスタント
  2. MCPサーバーに先作った外部サービスを選択
    SCR-20260718-ndqe

AI Starter で動作を確認する

  1. AI Starter → ユースケース

  2. 先作ったアシスタント（ユースケース）を選択
    SCR-20260718-nehu (1)

  3. 登録した要約機能をテストする
    SCR-20260718-nerc (1)

SCR-20260718-nevt
登録されたMCPツールが呼び出されます。

SCR-20260718-nfaw (1)
生成した内容が返却されます。

ハマりポイント集

構築中に遭遇した問題とその解決策をまとめます。

1. Cross-Region Inference Profile のルーティング

症状: jp.anthropic.claude-haiku-4-5-20251001-v1:0 を使うと、IAM ポリシーで ap-northeast-1 のリソースを許可しているのに AccessDeniedException が発生。

原因: jp. プレフィックスの推論プロファイルは、AWS が内部的に日本リージョン群（ap-northeast-1, ap-northeast-3 等）にルーティングします。ap-northeast-1 だけ許可していると、ap-northeast-3（大阪）にルーティングされた際にアクセス拒否されます。

解決策: ステージング環境では IAM ポリシーの Resource を "*" にする。本番環境では必要なリージョンすべてを明示的に許可するか、arn:aws:bedrock:*:<ACCOUNT_ID>:inference-profile/* のようにワイルドカードを使います。

2. 推論プロファイル ARN のフォーマット

症状: IAM ポリシーで arn:aws:bedrock:ap-northeast-1::foundation-model/* を指定すると AccessDeniedException。

原因: jp. プレフィックス付きモデルは 推論プロファイルであり、foundation-model ではなく inference-profile の ARN フォーマットを使います。また、ARN にはアカウント ID が必要です。

# NG
arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-*

# OK
arn:aws:bedrock:*:<ACCOUNT_ID>:inference-profile/jp.anthropic.*

3. Marketplace 権限

症状: Lambda 単体テストでは成功するが、Gateway 経由だと AccessDeniedException（Marketplace actions 関連）。

原因: Anthropic モデルの初回呼び出し時に aws-marketplace:ViewSubscriptions と aws-marketplace:Subscribe 権限が必要になるケースがあります。2026年7月現在、Bedrock のモデルアクセスは自動有効化されましたが、Marketplace 連携の権限は別途必要です。

解決策: Lambda の IAM ロールに以下のポリシーを追加。

{
  "Effect": "Allow",
  "Action": [
    "aws-marketplace:ViewSubscriptions",
    "aws-marketplace:Subscribe"
  ],
  "Resource": "*"
}

4. Gateway ターゲットのスキーマバリデーション

症状: ターゲット追加時に inlinePayload.1.member.name failed to satisfy constraint: Member must not be null。

原因: 2つのパターンがあります。

  1. インラインスキーマに inputSchema だけ貼って name / description を含めていない
  2. コンソールのフォームに空のツール行が残っている（インデックス 1 = 2行目が空）

解決策: [{name, description, inputSchema}] の配列形式で記述し、空行がないことを確認します。

5. Gateway IAM ロールの伝播遅延

症状: Gateway 作成直後にターゲットを追加すると Gateway service is not authorized to perform AssumeRole on Gateway role。

原因: IAM ロール作成直後は AWS 内部での伝播に数十秒かかることがあります。

解決策: 30 秒ほど待ってからリトライします。

まとめ

AgentCore Gateway の MCP ターゲットを活用することで、既存アプリケーションのコードを変更せずにマルチエージェント構成を実現できました。

構成のポイント：

  • 既存の MCP 統合を活かし、Gateway を「MCP サーバー」として登録するだけ
  • サブエージェントは VPC Lambda + Bedrock で実装（VPC Endpoint 経由、NAT 不要）
  • Gateway が MCP プロトコルを仲介し、ツール発見（tools/list）と実行（tools/call）を透過的に処理
  • MCP ターゲットを増やせばサブエージェントをスケールアウトできる

実務での判断基準：

  • サブエージェントごとに専用の Lambda を用意し、システムプロンプトで役割を特化させる
  • Gateway 認証は MVP では None でも良いが、本番では JWT（Cognito）を推奨
  • VPC Lambda を使う場合、VPC Endpoint のセキュリティグループ設定を忘れずに
  • IAM ポリシーでは推論プロファイルの ARN フォーマットと cross-region ルーティングに注意

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

[Amazon Bedrock] AgentCoreをVPCにデプロイして自然言語でAuroraに問い合わせてみました
SIN@製造BT部
2026.04.14
AgentCore CLI で Lambda を MCP ツール化する - Gateway 機能を試してみた 【備忘録】
こーすけ
2026.04.03
[小ネタ]Amazon Bedrock AgentCore Gatewayで認証なしオプションが追加されたので試してみた
神野 雄大
2025.12.01
Amazon Bedrock AgentCore Gatewayをマネジメントコンソールで作成してみた
桑野翔
2026.06.01