AgentCore Gateway の MCP サーバー統合による MCP アーキテクチャの変革

このブログは Transform your MCP architecture: Unite MCP servers through AgentCore Gateway の翻訳記事です。
—
AI エージェントが大規模に利用されていく中で、独自の Model Context Protocol (MCP) サーバーを作成し、特定のユースケースやドメイン、組織の機能やチーム向けに AI エージェントをカスタマイズするケースが増えています。また、既存の MCP サーバーやオープンソースの MCP サーバーを AI ワークフロー用に統合する必要もあります。カスタムビルド、パブリック利用可能、オープンソースなどの様々な形態の MCP サーバーを、AI エージェントが容易に利用できる組織全体で統一されたインターフェースに効率的に統合する方法が必要です。

今年の初めに AWS は Amazon Bedrock AgentCore Gateway を発表しました。これは完全マネージド型サービスで、中央集約型の MCP サーバーとして機能し、エージェントがツールを発見、アクセス、呼び出すための統一されたインターフェースを提供します。そして直近では、AgentCore Gateway に既存の MCP サーバーをターゲットタイプとしてサポートする機能拡張を実施しました。この機能により、複数のタスク固有の MCP サーバーを、単一の MCP ゲートウェイインターフェースの背後にグループ化できます。これにより、個別のゲートウェイを維持する運用の複雑さが軽減され、(AgentCore Gateway のターゲットとしてこれまで利用可能であった) REST API や AWS Lambda 関数と同様に中央集約型のツールおよび認証管理が提供されます。

中央集約型のアプローチを取らない場合、1) 組織全体でツールを発見し共有することが困難となる、2) 複数の MCP サーバー間での認証管理が複雑になる、3) 各サーバーに対して個別のゲートウェイインスタンスを維持する管理工数、が課題となります。Amazon Bedrock AgentCore Gateway は、既存の MCP サーバーをネイティブターゲットとして扱うことでこれらの課題を解決し、ルーティング、認証、ツール管理のための単一の制御ポイントを顧客に提供します。これにより、MCP サーバーの統合が他のターゲットをゲートウェイに追加するのと同じ様に簡単に実現できます。

MCP のサイロを打破する: エンタープライズチームが統一された Gateway を必要とする理由

複数のチームが特定のドメイン用に特化した MCP サーバーを運用する e コマース注文システムのケースを考えてみましょう。

• ショッピングカートチームはカート管理ツールを持つ MCP サーバーを運用しています。
• 製品カタログチームは製品の閲覧と検索のための MCP サーバーを運用しています。
• プロモーションチームはプロモーションロジックを処理する MCP サーバーを運用しています。

以前は、注文エージェントはこれらの各 MCP サーバーに個別に接続し認証コンテキストを管理する必要がありました。AgentCore Gateway の MCP サーバーターゲットにより、単一のゲートウェイの下に統合しながら、チーム固有の所有権とアクセス制御を維持できるようになりました。このアプローチの威力は、組織利用における MCP サーバーの設計を柔軟にできることです。複数のロジックに基づいて MCP サーバーをグループ化できます。

• ビジネスユニットとの整合: MCP サーバーをビジネスユニットごとに整理します。
• 製品機能の境界: 各製品チームがドメイン固有のツールを持つ MCP サーバーを所有し、明確な所有権を維持しながらエージェント用の統一されたインターフェースを提供します。
• セキュリティとアクセス制御: 異なる MCP サーバーには異なる認証メカニズムが必要です。ゲートウェイが認証の複雑さを処理し、認可されたエージェントが必要なツールに簡単にアクセスできるようにします。

次の図は、注文エージェントが AgentCore Gateway を通じて複数の MCP サーバーとやり取りする様子を示しています。エージェントはゲートウェイに接続し、利用可能なツールを発見します。各チームはドメイン固有のツールを管理しながら、組織全体での一貫したエージェント利用体験に貢献します。ゲートウェイはツール名の競合、認証を処理し、ツール全体で統一的なセマンティック検索を提供します。

AgentCore Gateway は、最新のエージェントアーキテクチャにおける統合ハブとして機能し、多様なエージェント実装を幅広いツールプロバイダーと接続するための統一されたインターフェースを提供します。図に示されているアーキテクチャは、ゲートウェイがエージェントとツール実装アプローチの間のギャップを埋める方法を示しており、現在は MCP サーバーターゲットを直接統合する機能が強化されています。

AgentCore Gateway 統合アーキテクチャ

AgentCore Gateway では、ターゲットがエージェントに提供するツールを規定します。ターゲットには Lambda 関数、OpenAPI 仕様、Smithy モデル、MCP サーバー、その他のツール定義を指定することができます。

アーキテクチャのターゲット統合側は、ツール統合におけるゲートウェイの汎用性を示しています。MCP サーバーターゲット機能により、ゲートウェイはパブリック MCP サーバーからのツールを直接組み込むことができ、他のターゲットタイプと同等に扱います。この機能は、ある AgentCore Gateway インスタンスが別のインスタンスのターゲットとして機能するフェデレーションシナリオにも拡張され、組織の境界を越えた階層的なツール編成が可能になります。ゲートウェイは、ツールとして公開されるエージェントを持つ AgentCore Runtime インスタンス、プライベート MCP サーバー、従来の AWS Lambda 関数、Smithy および AWS サービス API の両方とシームレスに統合できます。

ターゲットの多様性に加えて、ゲートウェイの認証アーキテクチャは更なる運用上のメリットを提供します。ゲートウェイは、インバウンド認証をターゲットシステムから切り離し、エージェントが単一のインターフェースを通じて複数の ID プロバイダーを使用するツールにアクセスできるようにします。この中央集約型のアプローチにより、AI エージェントの開発、デプロイ、メンテナンスが簡素化されます。MCP サーバーターゲットにも同じアプローチを使用でき、ゲートウェイがターゲット用に構成された ID プロバイダーを使用してサーバーとのインターフェースの複雑さを管理します。

ゲートウェイが提供する認証機能により、統一されたアーキテクチャでツールを管理することができます。エージェントがツールの発見を要求すると、ゲートウェイはターゲットの種類によらず一貫したツール情報を提供します。セマンティック検索機能はツールタイプ全体で動作するため、エージェントは実装に関係なく関連するツールを発見できます。ツールの呼び出し中、ゲートウェイは必要なプロトコル変換、認証フロー、データ変換を処理し、異なるターゲットシステムの複雑さを管理しながら、エージェントにクリーンで一貫したインターフェースを提示します。

MCP サーバーターゲットサポートの追加は、ゲートウェイの機能における重要な進化を表しています。従来の API や Lambda 関数を維持しながら、MCP ネイティブツールを直接統合できるようになりました。この柔軟性により、段階的な移行戦略が可能になり、チームは既存の統合を継続的に運用しながら、独自のペースで MCP ネイティブ実装を採用できます。ゲートウェイの同期メカニズムは、異なるターゲットタイプ間でツール定義が最新の状態を保つことを保証し、その認証および承認システムは、基盤となるツール実装に関係なく一貫したセキュリティ制御を提供します。

ゲートウェイは、MCP サーバー、従来の API、サーバーレス関数を一貫したツール環境に統合します。この機能は、エンタープライズグレードのセキュリティとパフォーマンスとともに、エージェントコンピューティングにとって有益なインフラストラクチャとなります。

ソリューションのウォークスルー

このセクションでは、AgentCore Gateway で MCP サーバーターゲットを設定する手順をご紹介します。MCP サーバーを AgentCore Gateway に追加することで、大規模な MCP サーバーを管理する際のツール管理、セキュリティ認証、運用のベストプラクティスを一元化できます。

AgentCore Gateway へ MCP Server を追加する

AgentCore Gateway を作成し、MCP Server をターゲットとして追加します。

前提条件

次の前提条件を確認してください。

• Amazon Bedrock AgentCore アクセス権を持つ AWS アカウント。詳細については、Permissions for AgentCore Runtime のドキュメントを参照してください。
• Python 3.12 以降
• OAuth 2.0 の基本的な理解

複数のインターフェースを通じてゲートウェイを作成し、ターゲットを追加できます。

• AWS SDK for Python (Boto3)
• AWS Management Console
• AWS Command Line Interface (AWS CLI)
• 高速で簡単なセットアップのための AgentCore starter toolkit

次の実用的な例とコードスニペットは、Amazon Bedrock AgentCore Gateway のセットアップと使用方法を示しています。インタラクティブに操作したい場合は、GitHub の Jupyter Notebook サンプルをご参照ください。

ゲートウェイを作成する

ゲートウェイを作成するには、AgentCore starter toolkit を使用して、JWT ベースのインバウンド認証用に Amazon Cognito を使用したデフォルトの認証構成を作成できます。Cognito の代わりに別の OAuth 2.0 準拠の認証プロバイダーを使用することもできます。

import time
import boto3

gateway_client = boto3.client("bedrock-agentcore-control")

# 認証構成を作成します。この Gateway へのアクセスを承認されるクライアントを指定します
auth_config = {
    "customJWTAuthorizer": {
        "allowedClients": ['<cognito_client_id>'], # クライアントは Cognito で構成された ClientId と一致する必要があります
        "discoveryUrl": '<cognito_oauth_discovery_url>',
    }
}

# create_gateway API を呼び出します
# この操作は非同期なので、Gateway の作成に時間がかかる場合があります
# この Gateway は CUSTOM_JWT オーソライザー、つまり auth_config で参照する Cognito User Pool を活用します
def deploy_gateway(poll_interval=5):
    create_response = gateway_client.create_gateway(
        name="DemoGateway",
        roleArn="<IAM Role>", # IAM Role には Gateway の作成/一覧表示/取得/削除の権限が必要です
        protocolType="MCP",
        authorizerType="CUSTOM_JWT",
        authorizerConfiguration=auth_config,
        description="AgentCore Gateway with MCP Server Target",
    )
    gatewayID = create_response["gatewayId"]
    gatewayURL = create_response["gatewayUrl"]
    
    # デプロイを待機します
    while True:
        status_response = gateway_client.get_gateway(gatewayIdentifier=gatewayID)
        status = status_response["status"]
        if status == "READY":
            print("✅ AgentCore Gateway is READY!")
            break
        elif status in ["FAILED"]:
            print(f"❌ Deployment failed: {status}")
            return None
        print(f"Status: {status} - waiting...")
        time.sleep(poll_interval)

if __name__ == "__main__":
    deploy_gateway()

# < > の値は実際の値に置き換える必要があります

サンプル MCP Server を作成する

例として、静的な応答を返す 3 つの簡単なツールを持つサンプル MCP サーバーを作成しましょう。サーバーは stateless_http=True を指定した FastMCP を使用しており、これは AgentCore Runtime の互換性に必要です。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP(host="0.0.0.0", stateless_http=True)

@mcp.tool()
def getOrder() -> int:
    """注文を取得します"""
    return 123

@mcp.tool()
def updateOrder(orderId: int) -> int:
    """既存の注文を更新します"""
    return 456

@mcp.tool()
def cancelOrder(orderId: int) -> int:
    """既存の注文をキャンセルします"""
    return 789

if __name__ == "__main__":
    mcp.run(transport="streamable-http")

AgentCore Runtime デプロイを構成する

次に、starter toolkit を使用して AgentCore Runtime デプロイを構成します。このツールキットは、起動時に Amazon ECR リポジトリを作成し、AgentCore Runtime へのデプロイ用の Dockerfile を生成できます。この実装は例として示しているもののため、実際には独自の MCP サーバー実装を使用してください。実際の環境では、MCP サーバーのインバウンド認証はゲートウェイの構成とは異なる可能性があります。その場合、Runtime 認証用の Amazon Cognito ユーザープールを作成する サンプルコードを参照してください。

from bedrock_agentcore_starter_toolkit import Runtime
from boto3.session import Session

boto_session = Session()
region = boto_session.region_name
print(f"Using AWS region: {region}")

required_files = ['mcp_server.py', 'requirements.txt']
for file in required_files:
    if not os.path.exists(file):
        raise FileNotFoundError(f"Required file {file} not found")
print("All required files found ✓")

agentcore_runtime = Runtime()

auth_config = {
    "customJWTAuthorizer": {
        "allowedClients": [
            '<runtime_cognito_client_id>' # クライアントは Cognito で構成された ClientId と一致する必要があり、Gateway Cognito プロバイダーとは別にすることができます
        ],
        "discoveryUrl": '<cognito_oauth_discovery_url>',
    }
}

print("Configuring AgentCore Runtime...")
response = agentcore_runtime.configure(
    entrypoint="mcp_server.py",
    auto_create_execution_role=True,
    auto_create_ecr=True,
    requirements_file="requirements.txt",
    region=region,
    authorizer_configuration=auth_config,
    protocol="MCP",
    agent_name="mcp_server_agentcore"
)
print("Configuration completed ✓")

# < > の値は実際の値に置き換える必要があります

MCP サーバーを AgentCore Runtime 上で起動する

Dockerfile ができたので、MCP サーバーを AgentCore Runtime 上で起動しましょう。

print("Launching MCP server to AgentCore Runtime...")
print("This may take several minutes...")
launch_result = agentcore_runtime.launch()
agent_arn = launch_result.agent_arn
agent_id = launch_result.agent_id
print("Launch completed ✓")

encoded_arn = agent_arn.replace(':', '%3A').replace('/', '%2F')
mcp_url = f"https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{encoded_arn}/invocations?qualifier=DEFAULT"

print(f"Agent ARN: {launch_result.agent_arn}")
print(f"Agent ID: {launch_result.agent_id}")

AgentCore Gateway のターゲットとして MCP サーバーを作成する

AgentCore Gateway が AgentCore Runtime 上の MCP サーバーへアクセスする際のアウトバウンド認証用に、AgentCore Identity Resource Credential Provider を作成します。

identity_client = boto3.client('bedrock-agentcore-control', region_name=region)

cognito_provider = identity_client.create_oauth2_credential_provider(
    name="gateway-mcp-server-identity",
    credentialProviderVendor="CustomOauth2",
    oauth2ProviderConfigInput={
        'customOauth2ProviderConfig': {
            'oauthDiscovery': {
                'discoveryUrl': '<cognito_oauth_discovery_url>',
            },
            'clientId': '<runtime_cognito_client_id>', # クライアントは Runtime オーソライザー用に Cognito で構成された ClientId と一致する必要があります
            'clientSecret': '<cognito_client_secret>'
        }
    }
)
cognito_provider_arn = cognito_provider['credentialProviderArn']
print(cognito_provider_arn)

# < > の値は実際の値に置き換える必要があります

MCP サーバーを指すゲートウェイターゲットを作成します。

gateway_client = boto3.client("bedrock-agentcore-control", region_name=region)
create_gateway_target_response = gateway_client.create_gateway_target(
    name="mcp-server-target",
    gatewayIdentifier=gatewayID,
    targetConfiguration={"mcp": {"mcpServer": {"endpoint": mcp_url}}},
    credentialProviderConfigurations=[
        {
            "credentialProviderType": "OAUTH",
            "credentialProvider": {
                "oauthCredentialProvider": {
                    "providerArn": cognito_provider_arn,
                    "scopes": ["<cognito_oauth_scopes>"],
                }
            },
        },
    ],
)  # ゲートウェイターゲットを非同期に作成します
gatewayTargetID = create_gateway_target_response["targetId"]

# < > の値は実際の値に置き換える必要があります

ゲートウェイターゲットを作成した後、get_gateway_target API 呼び出しを使用してゲートウェイターゲットのステータスを確認するポーリング処理を実装します。

import time

def poll_for_status(interval=5):
    # READY ステータスをポーリングします
    while True:
        gateway_target_response = gateway_client.get_gateway_target(gatewayIdentifier=gatewayID, targetId=gatewayTargetID)
        status = gateway_target_response["status"]
        if status == 'READY':
            break
        elif status in ['FAILED', 'UPDATE_UNSUCCESSFUL', 'SYNCHRONIZE_UNSUCCESSFUL']:
            raise Exception(f"Gateway target failed with status: {status}")
        time.sleep(interval)

poll_for_status()

Strands Agents フレームワークでゲートウェイをテストする

MCP サーバーからツールをリストするために、Strands Agents でゲートウェイをテストしてみましょう。異なるエージェントフレームワークで構築された他の MCP 互換エージェントも使用できます。

from strands import Agent
from mcp.client.streamable_http import streamablehttp_client
from strands.tools.mcp.mcp_client import MCPClient

def create_streamable_http_transport():
    return streamablehttp_client(gatewayURL,headers={"Authorization": f"Bearer {token}"})

client = MCPClient(create_streamable_http_transport)

with client:
    # listTools を呼び出します
    tools = client.list_tools_sync()
    # モデルとツールを使用してエージェントを作成します
    agent = Agent(model=yourmodel,tools=tools) ## 任意のモデルに置き換えることができます
    # サンプルプロンプトでエージェントを呼び出します。これは MCP listTools のみを呼び出し、LLM がアクセスできるツールのリストを取得します。以下は実際にツールを呼び出しません。
    agent("Hi , can you list all tools available to you")
    # サンプルプロンプトでエージェントを呼び出し、ツールを呼び出して応答を表示します
    agent("Get the Order id")

AgentCore Gateway での MCP サーバーのツール定義の更新

SynchronizeGatewayTargets API は、MCP サーバーターゲットからのツールのオンデマンド同期を可能にする新しい非同期操作です。MCP サーバーは、エージェントが発見して呼び出すことができるツールをホストします。時間の経過とともに、これらのツールを更新する必要があったり、既存の MCP サーバーターゲットに新しいツールを導入する必要があったりする場合があります。プロトコルハンドシェイクを実行し、利用可能なツールをインデックス化する SynchronizeGatewayTargets API を通じて外部 MCP サーバーに接続できます。この API により、MCP サーバーのツール構成を変更した後に、ツール定義を更新するタイミングを明示的に制御できます。

ターゲットが OAuth 認証で構成されている場合、API はまず AgentCore Identity サービスとやり取りして、指定された認証情報プロバイダーから必要な認証情報を取得します。これらの認証情報は、MCP サーバーとの通信を開始する前に、鮮度と利用可否について検証されます。認証情報の取得が失敗した場合、または期限切れのトークンが返された場合、同期操作は適切なエラー詳細とともに即座に失敗し、ターゲットは FAILED 状態に遷移します。認証なしで構成されたターゲットの場合、API はツール同期に直接進みます。

ツール処理ワークフローは、セッションを確立するための MCP サーバーへの初期化呼び出しから始まります。初期化が成功した後、API は MCP サーバーの tools/list 機能にページ分割された呼び出しを行い、パフォーマンスとリソース使用率を最適化するために 100 個のバッチでツールを処理します。各ツールのバッチは正規化を受け、API はターゲット固有のプレフィックスを追加して、他のターゲットからのツールとの命名の競合を防ぎます。処理中、ツール定義は異なるターゲットタイプ間での一貫性を促進するために正規化されますが、元の MCP サーバー定義からの重要なメタデータは保持されます。

同期フローは次のときに開始されます。

1. 運用管理者が SynchronizeGatewayTargets API を開始し、AgentCore Gateway をトリガーして構成された MCP ターゲットを更新します。
2. ゲートウェイは MCP ターゲットへの安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。
3. 次に、ゲートウェイはバージョン機能を取得するために MCP サーバーとの安全なセッションを初期化します。
4. 最後に、ゲートウェイは MCP サーバーの tools/list エンドポイントにページ分割された呼び出しを行ってツール定義を取得し、ゲートウェイが最新で正確なツールのリストを維持することを保証します。

SynchronizeGatewayTargets API は、AgentCore Gateway 内で MCP ターゲットを管理する際の重要な課題に対処します。それは、システムのパフォーマンスとリソース使用率を最適化しながら、利用可能なツールの正確な表現を維持することです。この明示的な同期アプローチが価値がある理由は次のとおりです。

スキーマの一貫性管理: 明示的な同期がない場合、AgentCore Gateway は ListTools 操作中に MCP サーバーへのリアルタイム呼び出しを行う必要があるか (レイテンシと信頼性に影響)、古いツール定義を提供するリスクがあります。SynchronizeGatewayTargets API は、新しいツールをデプロイした後や MCP サーバーで既存のツールを更新した後など、戦略的なタイミングでツールスキーマを更新できる制御されたメカニズムを提供します。このアプローチにより、ゲートウェイのツール定義がパフォーマンスを損なうことなくターゲット MCP サーバーの機能を正確に反映することが保証されます。

• パフォーマンスへの影響のトレードオフ: API は、不整合な状態につながる可能性のある同時変更を防ぐために、同期中に楽観的ロックを実装しています。これは、競合がある場合に複数の同期リクエストが再試行する必要がある可能性があることを意味しますが、このトレードオフは次の理由から許容されます。
  • ツールスキーマの変更は、通常の実行時の発生ではなく、頻度の低い運用イベントです
  • 同期のパフォーマンスコストは、通常のツール呼び出し中ではなく、明示的に要求されたときにのみ発生します
  • キャッシュされたツール定義により、同期している間でも ListTools 操作に一貫して高いパフォーマンスが得られます。

SynchronizeGatewayTargets API を呼び出す

次のサンプルコードを使用して、SynchronizeGatewayTargets API を呼び出します。

gateway_client = boto3.client('bedrock-agentcore-control', region_name=REGION)

synchronize_gateway_response = gateway_client.synchronize_gateway_targets(
    gatewayIdentifier=gatewayID,
    targetIdList=[gatewayTargetID]
)

print(synchronize_gateway_response)

ツールスキーマの暗黙的な同期

CreateGatewayTarget および UpdateGatewayTarget 操作中、AgentCore Gateway は明示的な SynchronizeGatewayTargets API とは異なる暗黙的な同期を実行します。この暗黙的な同期により、MCP ターゲットが有効で最新のツール定義で作成または更新されることが保証され、READY 状態のターゲットはすぐに使用可能と保証されます。これにより、作成/更新操作が他のターゲットタイプよりも時間がかかる可能性がありますが、検証されたツール定義のないターゲットを持つことの複雑さと潜在的な問題を防ぐのに役立ちます。

暗黙的な同期フローは次のときに開始されます。

1. 運用管理者が CreateGatewayTarget または UpdateGatewayTarget 操作を使用して MCP ターゲットを作成または更新します。
2. AgentCore Gateway は新規または更新された MCP ターゲットを構成します。
3. ゲートウェイはツール定義を更新するために非同期で同期プロセスをトリガーします。
4. ゲートウェイは安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。
5. 次に、ゲートウェイはバージョン機能を取得するために MCP サーバーとの安全なセッションを初期化します。
6. 最後に、ゲートウェイは MCP サーバーの tools/list エンドポイントにページ分割された呼び出しを行ってツール定義を取得し、ゲートウェイが最新で正確なツールのリストを維持することを保証します。

MCP ターゲットの ListTools の動作

AgentCore Gateway の ListTools 操作は、MCP ターゲットから以前に同期されたツール定義へのアクセスを提供し、パフォーマンスと信頼性を優先するキャッシュファーストアプローチに従います。ツール定義が静的に定義されている従来の OpenAPI または Lambda ターゲットとは異なり、MCP ターゲットツールは同期操作を通じて発見され、キャッシュされます。クライアントが ListTools を呼び出すと、ゲートウェイは MCP サーバーへのリアルタイム呼び出しを行うのではなく、永続ストレージからツール定義を取得します。これらの定義は、ターゲット作成/更新中の暗黙的な同期、または明示的な SynchronizeGatewayTargets API 呼び出しを通じて事前に取得したものです。この操作は正規化されたツール定義のページ分割されたリストを返します。

MCP ターゲットの InvokeTool (tools/call) の動作

MCP ターゲットの InvokeTool 操作は、ListTools を通じて発見されたツールの実際の実行を処理し、ターゲット MCP サーバーとのリアルタイム通信を管理します。キャッシュベースの ListTools 操作とは異なり、tools/call は MCP サーバーとのアクティブな通信を必要とし、特定の認証、セッション管理、エラー処理が発生します。tools/call リクエストが到着すると、AgentCore Gateway はまず、ツールが同期された定義に存在することを検証します。MCP ターゲットの場合、AgentCore Gateway は MCP サーバーとのセッションを確立するために初期化呼び出しを実行します。ターゲットが OAuth 認証情報で構成されている場合、AgentCore Gateway は initialize 呼び出しを行う前に AgentCore Identity から新しい認証情報を取得します。これにより、ListTools が期限切れの認証情報を持つキャッシュされたツールを返した場合でも、実際の呼び出しは有効な認証を使用することが保証されます。

インバウンド認証フローは次のときに開始されます。

1. MCP クライアントは MCP プロトコルバージョンを使用したリクエストを AgentCore Gateway に初期化します。
2. 次に、クライアントは tools/call リクエストをゲートウェイに送信します。
3. ゲートウェイは安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。
4. ゲートウェイは MCP サーバーとの安全なセッションを初期化して、ツールの実際の実行を呼び出して処理します。

MCP ターゲットの検索ツールの動作

AgentCore Gateway の検索機能により、MCP ターゲットを含む異なるターゲットタイプ全体でツールのセマンティック検索が可能になります。MCP ターゲットの場合、検索機能は同期操作中にキャプチャされ、インデックス化された正規化されたツール定義で動作し、リアルタイムの MCP サーバー通信なしで効率的なセマンティック検索を提供します。

ツール定義が MCP ターゲットから同期されると、AgentCore Gateway は各ツールの名前、説明、パラメータの説明に対して自動的にベクトル表現を生成します。これらのベクトル表現は正規化されたツール定義と一緒に保存され、検索クエリの意図とコンテキストを理解するセマンティック検索を可能にします。従来のキーワードマッチングとは異なり、正確な用語が一致しない場合でもエージェントは関連するツールを発見できます。

ゲートウェイを通じて MCP サーバーツールを検索する

次の例を使用してゲートウェイを通じてツールを検索します。

import requests
import json

def search_tools(gateway_url, access_token, query):
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {access_token}"
    }

    payload = {
        "jsonrpc": "2.0",
        "id": "search-tools-request",
        "method": "tools/call",
        "params": {
            "name": "x_amz_bedrock_agentcore_search",
            "arguments": {
                "query": query
            }
        }
    }

    response = requests.post(gateway_url, headers=headers, json=payload, timeout=5)
    response.raise_for_status()
    return response.json()

# 使用例
token_response = utils.get_token(user_pool_id, client_id, client_secret, scopeString, REGION)
access_token = token_response['access_token']
results = search_tools(gatewayURL, access_token, "math operations")
print(json.dumps(results, indent=2))

まとめ

最近発表された Amazon Bedrock AgentCore Gateway でのターゲットタイプとしての MCP サーバーサポートは、エンタープライズ AI エージェント開発における進歩です。この新機能は、セキュリティと運用効率を維持しながら MCP サーバー実装をスケーリングする際の重要な課題に対処します。既存の MCP サーバーを REST API や Lambda 関数と一緒に統合することにより、AgentCore Gateway は大規模なツール統合のためのより統一された、安全で管理しやすいソリューションを提供します。組織は、統一された認証、簡素化されたツール検出、削減されたメンテナンスオーバーヘッドの恩恵を受けながら、単一の中央集約型インターフェースを通じてツールを管理できるようになりました。

詳細情報と高度な構成については、GitHub のコードサンプル、Amazon Bedrock AgentCore Gateway 開発者ガイド、Amazon AgentCore Gateway の料金を参照してください。

著者について

Frank Dallezotte は AWS の Senior Solutions Architect で、独立系ソフトウェアベンダーと協力して AWS 上でスケーラブルなアプリケーションを設計および構築することに情熱を持っています。彼はソフトウェアの作成、ビルドパイプラインの実装、クラウドでのこれらのソリューションのデプロイに関する経験があります。

Ganesh Thiyagarajan は Amazon Web Services (AWS) の Senior Solutions Architect で、ソフトウェアアーキテクチャ、IT コンサルティング、ソリューション提供において 20 年以上の経験があります。彼は ISV が AWS 上でアプリケーションを変革し、モダナイズするのを支援しています。また、AI/ML テクニカルフィールドコミュニティの一員として、顧客が Gen AI ソリューションを構築および拡張するのを支援しています。

Dhawal Patel は Amazon Web Services (AWS) の Principal Generative AI Tech lead です。彼は、Agentic AI、Deep learning、分散コンピューティングに関連する問題について、大企業から中規模のスタートアップまでさまざまな組織と協力してきました。