🧰

AgentCore Gatewayで挑むMCP統合―見えた壁と突破口

に公開
AWS
Model Context Protocol
GenAI
AgentCore
tech

はじめに

AWSの公式ブログで「AgentCore Gateway の MCP サーバー統合による MCP アーキテクチャの変革」という記事が公開されました。この記事を読んで、複数のMCP（Model Context Protocol）サーバーを統合できるAgentCore Gatewayに興味を持ち、実際にGitHub Copilotから利用してみました。

本記事では、AgentCore Gatewayを構築し、AWS Knowledge、AWS CDK、AzureのMCPサーバーを統合してGitHub Copilotから活用した経験を共有します。

AgentCore Gatewayとは

AgentCore Gatewayは、Amazon Bedrock AgentCoreの機能の一つで、複数のツールやMCPサーバーを統合し、AIエージェントに統一されたインターフェースを提供するマネージドサービスです。

従来の課題

複数のMCPサーバーを運用する場合、以下のような課題がありました：

  • ツールの発見が困難: 各MCPサーバーが個別に存在するため、利用可能なツール全体を把握しづらい
  • 認証管理の複雑さ: それぞれのMCPサーバーに対して個別に認証を設定・管理する必要がある
  • 運用の手間: 各サーバーに対してゲートウェイインスタンスを維持する必要がある

AgentCore Gatewayの利点

AgentCore Gatewayは、これらの課題を以下のように解決します：

  • 統一されたインターフェース: 単一のエンドポイントから複数のMCPサーバーにアクセス可能
  • 中央集約型の認証管理: ゲートウェイレベルで認証を一元管理
  • セマンティック検索: 複数のターゲット（MCPサーバー、Lambda、OpenAPIなど）をまたいだツール検索が可能

構築したGatewayの構成

今回構築したAgentCore Gatewayには、以下の3つのMCPサーバーターゲットを登録しました：

  1. AWS Knowledge MCP Server - AWS公式ドキュメントの検索・取得
  2. AWS CDK MCP Server - AWS CDKのベストプラクティスやコード生成支援
  3. Azure Knowledge MCP Server - Azure/Microsoft公式ドキュメントの検索・取得

なぜこの構成にしたのか

この構成は、AgentCore Gatewayの機能を検証する目的で選びました：

公開MCPサーバーの統合（AWS Knowledge、Azure Knowledge）

AWS KnowledgeとAzure Knowledgeは、認証不要で利用できる公開MCPサーバーです。これらを選んだ理由は：

  • 簡単な検証: 認証設定なしでGatewayのターゲットとして追加できる
  • 実用性: 開発中に公式ドキュメントを参照する機会は多い
  • マルチクラウド対応の確認: 異なるクラウドベンダーのMCPサーバーを統合できることを確認

非公開MCPサーバーの模擬（AWS CDK）

AWS CDK MCPサーバーは、OAuth認証が必要な非公開サーバーとして構成しました：

  • セキュリティ要件: AgentCore Gatewayはパブリックにアクセス可能なエンドポイントを持つため、バックエンドのMCPサーバーをアクセス制御なしでパブリック公開するのは避けたい
  • 認証フローの検証: AgentCore Gatewayのアウトバウンド認証機能（OAuth 2.0）の動作を確認
  • Credential Providerの動作確認: AgentCore Identityを使った認証情報の管理を試す

この構成により、公開・非公開の両方のMCPサーバーをGatewayで統合できることを確認できました。

アーキテクチャ図

認証方式の選択：IAM認証

今回、Gatewayのインバウンド認証にはIAM認証を採用しました。これには以下の理由があります：

  • 透過的な認証体験: AWS認証情報（credentials）があれば、追加の設定なしで利用可能
    • 開発者個人の端末では、aws configureで設定済みのクレデンシャルをそのまま利用
    • EC2ベースのリモート開発環境では、インスタンスプロファイルにより利用者は全く設定作業なしで接続可能
  • セキュアなアクセス制御: IAMポリシーによる詳細な権限管理が可能

MCP Proxy for AWSによる接続

IAM認証で公開されているAgentCore Gatewayには、MCP Proxy for AWSを利用して接続できます。

MCP Proxy for AWSは、AWS Signature Version 4（SigV4）認証をサポートするMCPクライアント向けのプロキシツールです。これにより、GitHub CopilotやCursorなどのMCPクライアントから、IAM認証で保護されたAgentCore Gatewayに透過的にアクセスできます。

主な特徴：

  • AWS認証情報の自動処理（環境変数、プロファイル、インスタンスプロファイルなど）
  • SigV4署名の自動付与
  • MCPクライアントからは標準的なHTTPエンドポイントとして利用可能

このツールを使用することで、セキュアなIAM認証を維持しながら、様々なMCPクライアントからAgentCore Gatewayを簡単に利用できます。

登録されているツール一覧

今回のGatewayには、以下のようなツールが登録されています：

AgentCore Gateway共通

ツール名 説明
x_amz_bedrock_agentcore_search セマンティック検索ツール（複数ターゲットをまたいだツール検索）

AWS Knowledge関連

ツール名 説明
aws___search_documentation AWS公式ドキュメントの検索
aws___read_documentation AWS公式ドキュメントページの取得（Markdown形式）
aws___recommend 関連するAWSドキュメントページの推薦
aws___get_regional_availability AWSサービスのリージョン別可用性の確認
aws___list_regions AWSリージョンの一覧取得

AWS CDK関連

ツール名 説明
CDKGeneralGuidance CDKの一般的なベストプラクティス
CheckCDKNagSuppressions CDK Nag抑制の確認
ExplainCDKNagRule CDK Nagルールの説明
GenerateBedrockAgentSchema Bedrock Agent用のOpenAPIスキーマ生成
GetAwsSolutionsConstructPattern AWS Solutions Constructsパターンの検索
LambdaLayerDocumentationProvider Lambda Layerのドキュメント提供
SearchGenAICDKConstructs GenAI CDK Constructsの検索

Azure/Microsoft関連

ツール名 説明
microsoft_docs_search Microsoft公式ドキュメントの検索
microsoft_docs_fetch Microsoft公式ドキュメントページの取得
microsoft_code_sample_search Microsoftのコードサンプル検索

利用シーン：GitHub Copilotでの活用

AgentCore Gatewayを構築した後、GitHub Copilotから実際に利用してみました。

複数のMCPサーバーを横断した情報収集とコード生成

以下のような要求をGitHub Copilotに投げてみました：

AWSでWeb3層モデルのアプリを構築する際の最適なアーキテクチャを調べて、
ベストプラクティスに則ったCDKのコードを書いてください

GitHub Copilotは、この要求に対して以下のようにMCPサーバーを活用しました：

  1. 最適なツールを検索: x_amz_bedrock_agentcore_search でAWS Web 3層アーキテクチャに関連するツールを検索し、10個のツール候補を取得
  2. AWSドキュメント検索: aws-knowledge___aws___search_documentation で3層アーキテクチャのベストプラクティスを検索し、サーバーレス構成に関する3つのドキュメントを発見
  3. 詳細情報取得: aws-knowledge___aws___read_documentation でAWS Blogの「Building a three-tier architecture on a budget」を読み取り、CloudFront/S3 (Presentation)、API Gateway/Lambda (Logic)、DynamoDB (Data) という構成を確認
  4. CDKパターン取得: aws-cdk___GetAwsSolutionsConstructPattern で該当サービスを組み合わせたSolutions Constructsパターンを検索し、55個のパターンを取得

このように、複数のMCPサーバーにまたがる4つのツールを連続的に呼び出し、最新のドキュメントとベストプラクティスに基づいた情報を収集してCDKコード生成に活用しました。

課題：ツール数増加時のスケーラビリティ

AgentCore Gatewayを実際に使ってみて、将来的な課題としてツール数が増えた時のスケーラビリティが気になりました。

問題の詳細

MCPクライアント（GitHub CopilotやCursorなど）がMCPサーバーに接続する際、実装によっては以下のようなフローが発生する可能性があります：

  1. tools/listリクエストで利用可能なツール一覧を取得
  2. 各ツールの名前、説明、パラメータスキーマがすべて返される
  3. これらの情報がLLMのコンテキストに含まれる

今回の構成では16個のツールが登録されており、それぞれのツール定義が詳細な説明とパラメータスキーマを持っています。これらをすべて含めると、約10,000トークン相当の情報量になります。

さらに懸念されるのは、わずか16ツールで既に約10,000トークン相当を消費しているという事実です。もしAgentCore Gatewayに数十のMCPサーバーが登録され、数百のツールが利用可能になった場合、ツールリスト全体のサイズは非常に大きくなり、実装によっては大量のトークンを消費する可能性があります。これは実用上、考慮すべき点です。

ツールリストのサイズ（参考値）

実際のtools/listレスポンスのサイズを測定しました：

  • 測定対象: 16ツール分の完全な定義（ツール名、description、parametersのJSONスキーマ、各パラメータのdescription）
  • 文字数: 41,544文字
  • 推定トークン数: 約10,000トークン（日本語・英語混在テキストでは1トークン≒4文字として換算）

クライアント実装によっては、この情報がLLMのコンテキストに含まれる可能性があります。ツール数が数百に増えた場合、ツールリスト全体のサイズは数万〜数十万トークンに膨れ上がる可能性があり、スケーラビリティの観点から対策が必要になると考えられます。

解決策：セマンティック検索を活用したMCPサーバーの実装

スケーラビリティの課題に対処するため、AgentCore Gatewayのセマンティック検索機能を活用するMCPサーバーを実装しました。

実装したアーキテクチャ

設計のポイント

LLMに公開するツールを2つだけに絞るというアプローチを採用しました：

  1. search_tools - セマンティック検索ツール（Gateway の x_amz_bedrock_agentcore_search を呼び出し）
  2. invoke_tool - ツール実行ツール（Gateway の tools/call を呼び出し）

また、重要な工夫として各ツールの説明文を最初の1文のみに短縮しました（最大150文字）。これにより、スキーマは保持しつつ、トークン消費を大幅に削減できます。文字数に特段の根拠はありませんが、既にセマンティック検索によって適切なツールに絞り込まれている中からの選択には「この程度で大丈夫だろう」という判断です。

説明文の短縮処理の例：

## 元の説明（数百文字）
description = """Search AWS documentation using the official AWS Documentation Search API.

This tool retrieves relevant AWS documentation pages based on your search phrase.
It supports filtering by service, region, and content type..."""

## 短縮後（48文字）
brief_desc = "Search AWS documentation using the official AWS Documentation Search API."

動作フロー

実装したラッパーで、実際のユーザーリクエストを再度実施してみました：

ユーザーのリクエスト:

AWSでWeb3層モデルのアプリを構築する際の最適なアーキテクチャを調べて、
ベストプラクティスに則ったCDKのコードを書いてください

実装したラッパーでも同じ動作を実現:

ラッパー経由でも、GitHub Copilotは上記の利用シーンと同様に、セマンティック検索で必要なツールを発見し、複数のMCPサーバーをまたいでツールを実行して、最終的にCDKコードを生成できました。

実際の動作と効果

実装したMCPサーバーラッパーを使用して、上記のリクエストを処理した結果、以下の効果が検証されました：

トークン消費量の実測値

項目 トークン数
ツール定義（2つのツールのみ） 299
search_tools 結果（10ツールの概要） 522
invoke_tool 結果（実行結果） 1,755
合計 2,576

全16ツールの定義（約10,000トークン相当）と比較して、74%の削減を実現しました。

検証されたコンセプト

  1. 動的なツール発見: 必要な時に必要なツールだけをセマンティック検索で発見
  2. 高いスケーラビリティ: Gatewayに何百個のツールが登録されていても、常に2ツール+検索結果のみを公開
  3. トークン消費の大幅削減: ラッパーMCPサーバーで公開ツールを2つに絞り、説明文を短縮することで、全ツール定義の10,000トークン相当から2,576トークンへ74%削減

まとめ

AgentCore Gatewayを使ってMCPサーバーを統合し、さらにセマンティック検索を活用したスケーラブルなMCPサーバーを実装することで、以下の成果が得られました：

AgentCore Gatewayのメリット:

  • 統一されたインターフェースで複数のMCPサーバーを利用可能
  • IAM認証による透過的なアクセス
  • 強力なセマンティック検索機能

セマンティック検索活用による効果:

  • 動的なツール発見により、必要なツールのみを提示
  • ツール数が増えてもスケーラブルに対応可能
  • 74%の削減（全16ツールの定義 約10,000トークン相当 → 2,576トークン）
    • ただし、この削減効果はラッパーMCPサーバーで公開ツールを2つに絞り、説明文を短縮するなどの工夫を組み合わせた結果です

ラッパーMCPサーバーを介して実際のユーザーリクエストを処理した結果、セマンティック検索で関連ツールを発見し、AWS公式ドキュメントとCDKガイダンスを参照して、ベストプラクティスに則った3層アーキテクチャのCDKコードを生成できました。AgentCore Gatewayの強力なツール統合機能と、セマンティック検索を活用したスケーラブルなアプローチを組み合わせることで、実用的なAI支援開発環境を構築できました。

AgentCore Gatewayの想定ユースケース

最後に、AgentCore Gatewayの利用を検討する際の重要な注意点として、想定されるユースケースについて触れておきます。

AgentCore GatewayはProxyとして動作し、Gatewayを呼び出した利用者とは異なる認証主体（Credential Provider経由で取得した認証情報）としてターゲットのMCPサーバーを実行します。そのため、個人のアカウントや認証情報に依存する作業を行うためのMCPサーバーを統合する用途には適していません。

たとえば、個人のGitHubアカウントでリポジトリを操作するMCPサーバーや、個人のメールアカウントにアクセスするMCPサーバーなどをGatewayに登録しても、実行時には個人ではなくGatewayが使用する認証情報で動作するため、意図した動作になりません。

一方で、以下のようなユースケースには適しています：

  • 組織内のナレッジベースへのアクセス: 社内Wikiやドキュメント検索など、組織メンバー全員が利用できる情報源
  • 汎用的なユーティリティツール: 特定個人に紐付かない、組織内で共有される機能（データ変換、計算、検証など）
  • 公開情報へのアクセス: AWS/Azure公式ドキュメントなど、認証不要で誰でも利用できる外部サービス

AgentCore Gatewayは、特定個人向けではなく組織内のメンバーに幅広く提供するツール群を統合する際に、その真価を発揮すると思われます。

参考リンク

Discussion