MCPゲートウェイ：複数のMCPサーバーを大規模に管理する方法

多くの場合、まずは1台のMCPサーバーから始まります。開発者がGitHubをClaudeやCursorに接続すれば、すぐに動作します。その後、誰かがSlackを追加し、次にJira、そして社内データベースを追加していきます。

6か月後には、開発者一人ひとりが独自の設定ファイル、APIキー、サーバーのリストを持つことになる。

現状では、どのエージェントが本番データにアクセスできるのか把握できていません。エンジニアが退職すると、その人が作成したトークンをすべて追跡しなければなりません。新しいサーバーを追加するには、15件のクライアント設定を手作業で更新する必要があります。

恐ろしいのは、エージェントが予期せぬ動作をした際、そもそもなぜそれが起きたのかを説明できる単一のログが存在しないという点だ。

トークンは2つ目のコスト要因です。接続された各サーバーは、そのツール定義をコンテキストウィンドウに読み込みます。Anthropicが実施した5台のサーバーからなるセットアップの測定では、エージェントが1件のリクエストを読み込む前に、ツール定義として約55,000トークンが消費されていました。

つまり、複数のMCPサーバーを管理するには、2つの課題があります。1つは一元的なアクセス制御、もう1つは各エージェントのツールリストを最小限に抑えることです。MCPゲートウェイは、前者をデフォルトで処理します。後者については、ツールのフィルタリングや検索を行う場合にのみ処理します。本記事では、評価に値する5つのゲートウェイ、それぞれのコスト、そしてエージェントに支障をきたすことなく導入する方法について解説します。

MCPゲートウェイとは？

リクエストが到着すると、ゲートウェイはリクエスト元を確認し、そのユーザーやエージェントがどのツールを閲覧できるかをチェックします。各アップストリームサーバーからツール定義を取得し、名前にはプレフィックスを付けることで、`github_create_issue`と`jira_create_issue`が衝突しないようにします。フィルタリングで除外されたものはすべて破棄されるため、モデルには整理された単一のリストのみが表示されます。

モデルがツールを選択すると、ゲートウェイはそのツールを所有するサーバーへ呼び出しをルーティングし、そのサーバーの認証情報を添付します。ほとんどの製品では、エージェントが認証情報を保持することはありません。すべての呼び出しは1つのポイントを経由するため、ゲートウェイは何が呼び出され、誰によって呼び出され、どのような応答が返ってきたかをログに記録できます。

ツールの選択やサーバーの安全性は、フィルタリングや許可の設定方法に依然として依存関係があり、これについては以下の「手順」セクションで解説します。

MCPゲートウェイは、レジストリ、LLMゲートウェイ、APIゲートウェイとどう違うのか？

これら4つはすべて、クライアントとクライアントが必要とするリソースの間に位置するため、チームはこれらを混同しがちです。

その違いは、それぞれが処理するトラフィックの性質にあります。MCPゲートウェイはエージェントがツールを呼び出せるかどうかを判断するのに対し、レジストリはクライアントにどのサーバーが存在するかを伝えるだけで、リクエストを中継することは決してありません。LLMゲートウェイとAPIゲートウェイは異なるトラフィックを処理します。前者はプロンプトにどのモデルが応答するかを選択し、後者はサービスへの通常のHTTP呼び出しを保護します。

実際には、その境界線は曖昧です。例えば、Kong AI GatewayのようなツールはLLMとMCPのトラフィックを単一のコントロールプレーンを経由して送信し、ContextForgeはゲートウェイと並行してレジストリを運用しています。製品を比較する際は、各製品が実際にどのレイヤーをカバーしているかを確認してください。

Anthropic、GitHub、PulseMCP、およびMicrosoftの支援を受けて、2025年9月に公式のMCPレジストリがリリースされました。1年が経過した現在も、まだプレビュー段階にあります。サーバーの検出にはこれを利用しつつ、承認済みサーバーのリストは独自に管理しておくことをお勧めします。

MCPゲートウェイはトークンの使用量を削減しますか？

確かにそうですが、それはツールをフィルタリングしたり検索したりする場合に限られます。すべてのMCPサーバーには一連のツールが付属しており、各ツールにはAIがそれを使用する前に読み込まなければならない記述があります。そして、それらの記述はトークンを消費します。ゲートウェイはすべてのサーバーを一か所に集約します。フィルタリングするように設定しない限り、AIには依然としてすべてのサーバーのすべてのツールが表示されるため、AIは以前と同じ量の記述を読み込むことになります。

ゲートウェイがタスクに不要なツールを隠蔽して初めて、トークンの節約が可能になります。

コストは問題の半分に過ぎません。よくある失敗要因は、モデルが誤ったツールを選択したり、誤ったパラメーターを渡したりすることです。これは特に、notification-send-userやnotification-send-channelのように、ツール名が似ている場合に起こりやすくなります。Anthropicのドキュメントによると、利用可能なツールが30～50を超えるとツールの選択精度が低下し始めるとされており、数台のサーバーだけでその閾値を超えてしまうこともあります。

Anthropicが推奨する対策は、最初に検索ツールを読み込み、タスクに必要な3～5つのツールのみを取り込むことです。 50以上のMCPツールを用いたテストでは、コンテキストの総量が約77,000トークンから約8,700トークンに減少し、Anthropicはこれを85%の削減と報告しています。 社内でのMCP評価における精度も向上しました。Opus 4ではツール検索を有効にしたことで49%から74%に、Opus 4.5では79.5%から88.1%に上昇しました。

MCPを用いたコード実行に関する同社の調査結果は、さらに踏み込んだものです。エージェントがツールファイルのフォルダを閲覧し、必要な定義のみを読み込んだところ、Google DriveからSalesforceへのあるワークフローで、トークン数が15万から2,000に減少しました。しかし、このアプローチでは、エージェントが記述するコードのためにサンドボックス環境が必要となり、それ自体が運用コストとなります。

ゲートウェイには、これに対処するための2つの方法があります。

まず、ツールリストを手作業で絞り込む方法があります。 Dockerのプロフィール機能を使えば、サーバーごとに個別のツールを許可リストに登録できます。ContextForgeの仮想サーバーは、複数のアップストリームサーバーから厳選されたツールセットを公開し、ComposioのTool Routerはセッションを固定のリストにピンできます。

2つ目は、呼び出し時の検索機能です。AgentCore Gatewayには、エージェントが平易な言葉でクエリを実行できる組み込みのセマンティック検索ツールが搭載されており、Composioも実行時にツールを検索することができます。

Anthropicの指針では、定義が10,000トークンを超えたり、ツールが10個以上になった時点で対応するよう推奨しています。ほとんどのAIワークフロー自動化セットアップはすぐにこの基準を超え、マルチエージェントワークフローではさらに早く超えてしまいます。

最適なMCPゲートウェイとは？

「MCPゲートウェイ」と称する製品は数多くありますが、その中にはサーバーのディレクトリに近いものもあります。このリストでは、セットアップの中間に位置するツールに限定しています。エージェントは1つのエンドポイントに接続し、ゲートウェイはその背後にあるサーバーにアクセスし、通過するトラフィックに対して少なくとも1つの実質的な制御が可能になります。

その制御とは、サインイン、ツールの許可リスト、あるいは監査ログなどである可能性があります。

5つのツールが候補に残りました。これらはすべて同じ問題を解決しますが、その方法はそれぞれ異なります。適切な選択は、エージェントがすでにどこで実行されているかによって決まります。開発者のノートPC、自社インフラ、既存のKongセットアップ、AWS、あるいはSaaSアプリなどです。

1. Docker MCPゲートウェイ（Dockerデスクトップでのローカル開発に最適）

Docker MCPゲートウェイは、DockerデスクトップのMCPツールキットを支えるオープンソースエンジンです。すでにツールキットを有効にしてデスクトップをご利用の場合は、追加のセットアップなしでゲートウェイがバックグラウンドで動作します。サーバーの無秩序な増加に対するその解決策は、コンテナです。各MCPサーバーは、権限、ネットワークアクセス、リソースが制限された独自のコンテナ内で実行され、エージェントがそのツールのいずれかを必要とする場合にのみ、ゲートウェイによって起動されます。

プロフィールを使えば、セットアップを一か所にまとめて管理できます。プロフィールはプロジェクトに必要なサーバーをグループ化し、Cursor、VS Code、Claude デスクトップ、Claude コードなど、接続するすべてのクライアントが同じセットアップを使用します。プロフィールを OCI レジストリにプッシュしてチームメンバーがプルできるようにすれば、手作業で編集した15個の設定ファイルを1つの共有定義に置き換えることができます。

プロフィール内では、GitHub.create_issueなどの個々のツールを有効にし、そのサーバーの残りの部分は無効にしておくことができます。これが、Dockerがモデルのツールリストをコンパクトに保っている理由です。

認証情報は設定ファイルに保存されません。ゲートウェイは、Docker Desktopのシークレットストアからシークレットを取得し、サーバーの起動時にそれらを追加します。また、必要なサーバーに対してはOAuthによるサインインも処理します。組み込みのロギング機能とコールトレースにより、どのツールが実行されたかが確認できます。ゲートウェイは単に呼び出しをルーティングするだけであり、実際の処理は自動化のために実行するAIエージェントが行います。導入にあたっては、Docker MCPカタログに200以上のツールやサービスがリストされています。

限界点： このゲートウェイは、自身のマシン上でサーバーを実行する開発者向けに構築されています。Docker AI Governanceのバージョンが、Docker営業部門からの招待制であるため、チーム全体のポリシー制御を自身で登録することはできません。手動インストールによりDockerデスクトップなしでゲートウェイを実行することは可能ですが、シークレットの管理は依然としてデスクトップに依存しています。

Docker MCPゲートウェイについて、実際のユーザーはどのような評価をしているのでしょうか

あるユーザーのレビューには次のように書かれています：

DockerのMCPゲートウェイは、ローカル開発には実に優れています。サーバーごとのコンテナ分離や、Dockerデスクトップに組み込まれた認証情報の管理機能などが挙げられますが、チーム間やリージョンを超えた企業ガバナンスを想定して設計されたものではありません。

2. IBM ContextForge（セルフホスト型、チーム単位のツールセットに最適）

IBM ContextForgeは、自社のインフラ上で実行するオープンソースのゲートウェイおよびレジストリです。MCPサーバー、エージェント間（A2A）サービス、および通常のRESTやgRPC APIを、1つのエンドポイントの背後に統合します。PyPIからインストールしたり、コンテナとして実行したり、プロジェクトのHelmチャートを使用してKubernetesにデプロイしたりすることができます。

この製品の最大の特徴は、仮想サーバー機能です。ゲートウェイに登録されているすべてのツールから必要なものを選び、それらを単一の名前でバンドルし、クライアントにそのバンドルのエンドポイントを指定します。財務担当者は財務ツールを受け取り、サポート担当者は別のツールセットを受け取りますが、どちらの担当者も相手の定義をロードすることはありません。各仮想サーバーは、プライベート、チーム共有、またはパブリックのいずれかに設定できます。

また、既存のAPIをMCPツールとして活用することも可能です。RESTエンドポイントを指定するだけで、JSONスキーマを自動的に取得します。さらに、このツールはサーバーリフレクションを通じてgRPCサービスを変換します。これにより、社内のAPIごとにラッパーサーバーを作成する手間が省けます。

各アップストリームサーバーは独自のOAuth設定を保持し、ContextForgeはユーザーごとにトークンを保存するため、2つのサーバーで異なるIDプロバイダーを使用することが可能です。管理用UIにはリアルタイムのログビューアが搭載されており、トレースデータはOpenTelemetryを介してJaeger、Zipkin、Datadogなどのバックエンドに送信されます。40以上のプラグインにより、追加のトランスポートや連携機能が利用可能です。

限界点： 実行、パッチ適用、スケーリングはすべて自分で行う必要があります。強力なシークレット鍵を生成するまで、ゲートウェイは起動しません。このプロジェクトでは本番環境での運用にPostgreSQLを推奨しており、サポートはGitHubの問題やディスカッションを通じて行われます。

IBM ContextForgeについて、実際のユーザーはどのような感想を述べているのでしょうか

あるユーザーのレビューには次のように書かれています：

Apacheライセンスを採用し、本格的なKubernetesインフラをすでに運用しているユーザー向けに構築されています。真に実用的なソリューションへと成熟しており、本格的なガバナンスやモニタリング機能に加え、自社の他のAPIと並行してMCPを管理することも可能です。ただし、小規模なソリューションに比べてスタンドアップには手間がかかるため、週末にさっと作れるようなプロジェクトではありません。

3. Kong AI Gateway（すでにKongを導入しているチームに最適）

Kongは、MCPトラフィックをAPIトラフィックの一種として扱います。チームですでにKong GatewayやKong Konnectを運用している場合、MCPのサポートは、既存のゲートウェイ上のプラグインとして提供されます。APIで利用しているのと同じ認証、レートリミット、ロギング機能が使用されます。

その中核となるのが、AI MCP Proxyプラグインです。これは、すでに稼働しているMCPサーバーの前に配置することも、OpenAPIスキーマを持つ任意のAPIを、カスタムコードなしでMCPツールに変換することも可能です。また、複数のAPIのツールを1つのMCPエンドポイントに統合できるため、エージェントはサービスごとに個別に接続するのではなく、1回だけ接続すれば済みます。

アクセス制御はツールごとに機能します。コンシューマーまたはコンシューマーグループごとに許可リストと拒否リストを設定すると、エージェントがツールリストを要求した際、Kongはその特定の呼び出し元が使用できるツールのみを返します。許可または拒否されたすべてのアクセス試行は、プラグインの監査ログに記録されます。エージェントは呼び出せないツールをロードすることはないため、フィルタリングされたリストによりコンテキストのサイズも抑えられます。

サインインは、OpenID ConnectやAI MCP OAuth2プラグインを含むKongの認証プラグインを通じて行われます。MCPトラフィックログには、セッションID、JSON-RPCメソッド、ペイロード、レイテンシ、エラーが記録され、トレースをOpenTelemetryに送信することも可能です。さらに、LLMトラフィックをKongのAI Gateway経由でルーティングすれば、モデルトラフィックとツールトラフィックは1つのコントロールプレーンを共有します。

制限事項： Konnectでは、SSOおよびプラットフォーム監査ログはEnterpriseエディションでのみ利用可能です。AI MCP ProxyプラグインはWebSocketやgRPCの上流通信をサポートしておらず、AIガードレールはMCPリクエストには適用されません。REST変換にはAPIごとに有効なOpenAPIスキーマが必要であり、ツールごとのACLにはKong Gateway 3.13以降が必要です。 MCPクライアントからのPingも、月間リクエスト総数にカウントされます。

Kong AI Gatewayについて、実際のユーザーからはどのような声が寄せられているのでしょうか

あるユーザーのレビューには次のように書かれています：

すでにKongを運用しているなら、これは理にかなっています。もはや単にMCPを付け加えただけのものではなく、エージェント間のトラフィックを含む、真に目的特化型のサポートが提供されています。また、7月中旬にはAIガバナンス企業と提携し、ポリシーチェックをゲートウェイに直接組み込みました。ただし、より高度な機能の一部については、有料プランが必要になる可能性があります。

4. Amazon Bedrock AgentCore Gateway（AWS上で実行されるエージェントに最適）

Amazon Bedrock AgentCore GatewayはAWSのフルマネージド型ソリューションであるため、ホスティングやスケーリングの手間が一切かかりません。エージェントは、ツール用に単一のエンドポイントを利用できます。また、AgentCoreは、OpenAPIやSmithyの仕様、Lambda機能、既存のMCPサーバーを、カスタムコードを記述することなくMCPツールに変換します。さらに、Salesforce、Slack、Jira、Asana、Zendeskとのワンクリック統合機能も備えています。

ツール検索機能が組み込まれています。ゲートウェイの作成時にセマンティック検索を有効にすると、エージェントは自然言語でクエリを実行できる検索ツール（x_amz_bedrock_agentcore_search）を利用できるようになります。これにより、エージェントはカタログ全体を読み込むのではなく、タスクに必要なツールのみを取得できます。これはAnthropicが説明しているオンデマンドのパターンと同じもので、クライアント側ではなくゲートウェイ側で実行されます。

認証は双方向で機能します。インバウンド時、ゲートウェイはAWS IAMまたはIDプロバイダーからのJWTを通じて、呼び出し元を検証します。アウトバウンド時、ゲートウェイはOAuth、APIキー、またはIAM役割を使用して各ツールにサインインし、それらの認証情報を自ら追加するため、エージェントが認証情報を保持することはありません。ゲートウェイ経由でAgentCore Identityを使用する場合、追加費用は一切かかりません。また、AgentCore Policyでは、Cedarで記述されたルールに基づいて各ツールへの呼び出しを検証できます。

このゲートウェイは、CrewAI、LangGraph、LlamaIndex、Strands Agents などのオープンソースフレームワークや、あらゆるモデルと連携可能です。2026年6月のアップデートでは、MCPプロンプトとリソース、ストリーミングおよびセッション管理、タスク途中の承認を求める機能、および OAuth の代理トークン交換機能が追加されました。

弱点： AWS上でのみ動作するため、セルフホスティングはできません。料金体系は複数のAgentCoreサービスにわたって利用量ベースであるため、定額制に比べて月額コストの予測が難しくなります。 AWS自身の例によると、毎月5,000万件のインタラクションを処理するエージェント（各インタラクションにつき検索1回、ツール呼び出し4回）の場合、月額コストは約2,250ドルとなり、その半分以上を検索が占めています。セマンティック検索は18のAWSリージョンで利用可能です。各ゲートウェイは、設定したMCPプロトコルバージョンのみを受け付け、可観測性機能はCloudWatchを通じて提供されますが、これには別途費用がかかります。

Amazon Bedrock AgentCore Gatewayについて、実際のユーザーはどのような評価をしているのでしょうか

あるユーザーのレビューには次のように書かれています：

その複雑さは、いくつかの側面から生じています。1）ユーザーはAWSの認証情報や環境を設定する必要があること、2）開発者はAgentCoreを使用するためにエージェントコードを完全に記述し、アノテーションを付ける必要があること、そして3）コンテキスト管理には特定のプログラミングモデルが必要であり、それがすべてのフレームワークで機能するとは限らないことです。

5. Composio（サーバーを稼働させずにエージェントをSaaSアプリに接続するのに最適）

Composioは、Gmail、Slack、GitHub、HubSpot、Salesforceなど、1,500以上のアプリにエージェントを接続するマネージドプラットフォームです。サーバーを運用する必要はありません。エージェントやAIクライアントは1つのMCP URLに接続するだけで、OAuthフローやAPIキーからリフレッシュトークンに至るまで、各アプリへのサインイン処理はすべてComposioが代行します。

ゲートウェイの処理の大部分は「ツールルーター」で行われます。ユーザーごとに、必要なツールキットを含むセッションを作成すると、Composioはスコープ指定されたMCPエンドポイントを返します。セッション内では、ツールの正確なリストをピンしたり、特定のツールをブロックしたり、読み取り専用や破壊的といったMCPヒントに基づいてフィルタリングしたりできます。また、ツールは実行時にカタログを検索し、タスクに必要なツールのみを読み込むことができるため、エージェントのコンテキストを小さく抑えることができます。

許可設定では、ツール呼び出しのたびに承認を必要とするか、セッションごとに一度の承認で済むように設定でき、ツールごとに「常に許可」または「常に拒否」というオーバーライドも可能です。セッションはユーザーごとに作成されるため、各ユーザーの接続アカウントは分離され、1人のユーザーが同じアプリに対して複数のアカウントを接続することも可能です。カタログにないアプリでも、MCPサーバーがあれば、カスタムサーバーとして無料で追加できます。

Claude、ChatGPT、Cursor、Claude Code、その他のあらゆるMCPクライアントに加え、LangChain、LlamaIndex、CrewAI、OpenAI Agents SDKなどのフレームワークとも連携可能です。多段階のタスクについては、Composioは各実行が独自の隔離されたサンドボックス内で実行されるリモートランタイムを提供しています。同社はSOC 2 Type IIへの準拠およびISO 27001:2022の認証を取得していると報告しています。

際立った機能

価格

評価

限界点： これはマネージドサービスであるため、「BYOC（Bring-Your-Own-Cloud）」展開を設定しない限り、ツールからの呼び出しやユーザーが保存した認証情報はすべてComposioのクラウドを経由します。MCP経由で接続する場合、SDKのツール呼び出しフックやスキーマの変更は実行されず、独自のコードで定義されたカスタムツールはMCPエンドポイントでは利用できません。 2026年5月、Composioはセキュリティインシデントを公表しました。このインシデントにより、アクティブな接続の約0.3％（その大部分がGitHub）が漏洩し、顧客はAPIキーのローテーションを余儀なくされました。セキュリティレビューの際には、同社の報告書も参照してください。

Composioについて、実際のユーザーはどのような感想を述べているのでしょうか

あるユーザーのレビューには次のように書かれています：

GmailやSlackなど1,000以上のアプリを擁する、膨大なライブラリを備えたマネージドMCPプラットフォームです。最大の利点は、すべての統合機能を自社で構築・保守する必要がないことです。また、ComposioはVPCでのセルフホスティングや組み込みSDKもサポートしており、柔軟なデプロイメントオプションを提供します。

MCPゲートウェイの費用はどれくらいか？

価格は、マネージドサービスを利用するかどうか、あるいはインフラを自社で運用するかによって異なります。

オープンソースのゲートウェイにはライセンス料はかかりませんが、ホスティング、メンテナンス、セキュリティには依然として費用がかかります。マネージドゲートウェイでは、ツールの呼び出し、検索、コントロールプレーン、その他の利用に対して課金されます。

どのゲートウェイがコスト面で有利かは、現在運用している環境によって異なります。 ComposioやAmazon Bedrock AgentCore Gatewayは、インフラ関連の作業をより多くベンダー側に委ね、使用量に応じた課金を行います。Docker MCP GatewayやIBM ContextForgeにはライセンス料がかかりませんが、ホスティングやメンテナンスのコストはユーザー側が負担することになります。Kongは、チームがすでにKongを運用している場合に最も経済的に有利です。MCPのためだけにKongを導入すると、新たなプラットフォームとライセンスコストが追加されるためです。

MCPゲートウェイの選び方

価格によってリストは絞り込めますが、それだけで決定が下されることはめったにありません。

より適切な出発点は、あなたが調査を始めたきっかけとなった問題そのものです。ほとんどのチームが直面している問題は、次の2つのいずれかです。どのツールが誰によって呼び出されているかを把握・制御できない、あるいはエージェントがあまりにも多くのツール定義を読み込みすぎて、誤ったツールを選択し始めてしまう、というものです。両方の問題を抱えているチームもあります。

どの問題が最も深刻かを把握できれば、ゲートウェイに何をやることかが分かり、またどの機能はなくても済むかが分かります。

まず、エージェントがすでに実行されている場所から始めましょう

このガイドで紹介する5つのゲートウェイは基本的な機能は共通しているため、決定要因となるのは通常、すでに導入済みのスタックです。

エージェントが主に個々のユーザーに代わってSaaSアプリ内で動作する場合、Composioは各ユーザーのOAuth接続を自動的に管理するため、最も手間を省くことができます。その代償として、これらの認証情報はComposioのクラウド上に保存されるため、セキュリティチームによる確認が必要になるでしょう。

開発者のノートPCに分散し、連携が取れていないワークフローに悩まされているチームにとって、Docker MCP Gatewayは当然の第一ステップとなります。Dockerデスクトップをすでに利用しているチームに適しており、すべてのサーバーを個別のコンテナで実行し、チーム全体で1つのプロフィールを共有できます。後日、チーム全体のガバナンスが必要になった場合は、Dockerの営業担当と別途会話する必要があります。

インフラを自社で管理することを好むプラットフォームチームは、IBM ContextForgeを選ぶ傾向があります。その仮想サーバーにより、各チームに独自のツールセットが提供され、内部のRESTおよびgRPCサービスをMCPツールに変換することができます。また、セルフホスティングに伴うパッチ適用、スケーリング、オンコールの仕事も自ら担うことになります。

Kong AI Gateway は、MCPトラフィックを、チームがすでにAPIに対して適用しているのと同じポリシーの下に置きます。SSOやプラットフォーム監査ログが必要な場合は、どちらもEnterprise版限定の機能であるため、Enterprise版の導入予算を確保してください。

AWS上で開発を行うチームにとって、Amazon Bedrock AgentCore Gatewayはすべての管理を一元化し、ゲートウェイ上でセマンティックなツール検索機能を提供します。検索呼び出し、ツール呼び出し、CloudWatchはそれぞれ個別に課金されるため、利用量に応じた請求額を早めに試算しておくことをお勧めします。

小規模なチーム向けに数台の安定したサーバーを運用している場合、現時点ではゲートウェイは必要ないかもしれません。チームごとの許可設定や一元化されたログが必要になるまでは、バージョン管理システムに保存された共有設定とシークレットマネージャーで同様の要件をカバーできます。

コミットする前に、何をチェックすべきでしょうか？

有力候補が決まったら、契約を結ぶ前に、自社のセットアップに合わせてテストを行ってください。機能紹介ページには、後々重要になる詳細が省かれていることが多いため、セキュリティおよびプラットフォーム担当の責任者と、以下の具体的な質問について確認してください：

その比較によって、答えは通常明らかになります。ゲートウェイが設定の変更を記録するだけで、エージェントが実際にどのツールを使用したかを表示できない場合、監査には耐えられません。また、ツールリストを絞り込まずにサーバーを接続する場合、エージェントは依然としてすべてのツール定義を読み込むことになるため、トークンの使用量は変わりません。

既存のMCPサーバーをゲートウェイに移行するにはどうすればよいですか？

最も安全な導入方法は、まずリスクの低いサーバーを1台移行し、新しい経路の信頼性が確認されるまで、従来の経路を稼働させ続けることです。

まずは現状把握から始めましょう

各サーバーについて、所有者、提供されているツール、アクセス可能なデータ、およびツール定義にかかるトークンの概算数をメモしてください。また、この段階で不要なものを整理する絶好の機会でもあります。ほとんどのカタログには、数ヶ月間誰も呼び出していないツールが含まれており、移行前にそれらを削除することで、ガバナンスの対象となる範囲を縮小できます。

信頼境界ごとにサーバーをグループ化する

プライベートデータを読み取るサーバー、信頼できないコンテンツを扱うサーバー、外部へデータを送信できるサーバーを、それぞれ別々のツールセットに配置し、1つのエージェントがこれら3つすべてを保持しないようにします。この組み合わせこそが、InvariantLabsによるGitHub MCPのプロンプト注入デモを可能にしたものです。また、各サーバーが現在もメンテナンスされていることを確認してください。GitHubやSlackを含む、当初のMCPリファレンスサーバーのいくつかは、現在アーカイブに移され、更新が提供されなくなっています。

グループの設定が完了したら、小規模なパイロット運用を実施してください

パイロット運用が成功したら、書き込み可能なサーバーを1台ずつ移行します。各移行の前にロールバック基準を設定しておけば、インシデント発生中に元に戻すかどうかをその場で判断する必要がなくなります。ゲートウェイ経由の経路が数週間問題なく稼働するまで、直接設定を維持し、その後、古い認証情報とクライアント接続を無効化してください。

どのゲートウェイを選択する場合でも、1つのルールが適用されます。MCP仕様では、トークンのパススルーが禁止されています。ゲートウェイは、自身に対して発行されたトークンのみを受け入れ、クライアントのトークンを転送するのではなく、個別に認証された独自の認証情報を使用してダウンストリームサーバーを呼び出す必要があります。本番トラフィックを移行する前に、ゲートウェイの設定がこのルールに従っていることを確認してください。

ClickUpはMCPゲートウェイとどのように連携するのでしょうか？

ClickUpは、ゲートウェイの両側からMCPに接続します。

Claude、Cursor、ChatGPTなど、ClickUp外のAIアプリは、他のサーバーと同様にゲートウェイの背後に配置されたClickUp MCPサーバーを経由してワークスペースにアクセスします。ClickUp内では、Super AgentsやBrain²が、ユーザーが接続した外部のMCPサーバー上のツールを利用することができ、そのゲートウェイもその一つとなり得ます。

ClickUp MCPサーバーをゲートウェイの背後に配置してください

ClickUp MCPサーバーはhttps://mcp.clickup.com/mcp で稼働しており、「Free Forever」を含むすべてのプランで利用可能です。OAuthのみを受け付けるため、ゲートウェイが個人のAPIキーを保存したり、ユーザーが離脱した際にキーを更新したりする必要はありません。独自のクライアントを構築する場合は、PKCE対応のOAuth 2.1をサポートする必要があります。 ClickUpでは承認済みクライアントの許可リストを管理しているため、リストにないクライアントについては、まず審査に提出する必要があります。

接続が完了すると、エージェントはタスクの作成やルーティング、タスクやドキュメントに基づくステータス更新、作業時間の記録、タスク・ドキュメント・コメントの検索、チャットスレッドの要約を行うことができます。これにより、エージェントはプロンプトごとにプロジェクトのコンテキストを貼り付ける必要がなく、自らそのコンテキストを参照できるようになります。

ゲートウェイを介したレートリミットについては、さらに詳しく検討する必要があります。このリミットはワークスペース全体に適用され、接続されたすべてのクライアントが同じ共有割り当て量を消費します。「Everything AI」アドオンがない場合、ClickUpではMCP呼び出し数を24時間ごとのローリング期間ごとに制限しており、「Free Forever」プランでは100回、「Enterprise」プランでは最大5,000回までとなっています。

このアドオンを使用すると、MCPのリクエストはパブリックAPIの1分あたりのリミットに従うようになります。そのリミットは、「Free Forever」、「Unlimited」、「Business」プランでは1分あたり100リクエスト、「Enterprise」プランでは最大10,000リクエストとなっています。ClickUpでは、現時点ではMCPの使用状況が表示されません。複数のチームが1つのゲートウェイを経由してClickUpにアクセスする場合は、ゲートウェイでチームごとのリミットを設定し、1人の多忙なエージェントが他の全員の割り当てを使い果たすことがないようにしてください。

スーパーエージェントをMCPサーバーに接続する

逆に、ClickUpアプリセンターから外部のMCPサーバーを、ワークスペース全体に対して、あるいは自分だけを対象として接続することも可能です。各接続タイプを追加できるユーザーは、管理者が決定します。サーバーが接続された後、各スーパーエージェントにどのツールを割り当てるか（すべて、または特定のツールのみ）を選択します。これは、このガイドの前半で説明したツールリストの絞り込みと同じ考え方であり、ワークスペース内のエージェントに適用されるものです。

接続先のサーバーがゲートウェイである場合は、まず2つの点を確認してください。ClickUpは変動するクラウドIPアドレスから接続するため、IP許可リストでは通過できません。また、ゲートウェイにはOAuthまたはAPIキーで保護されたパブリックURLが必要です。ClickUpのワークスペース監査ログには、サーバーへの接続、更新、切断を行ったユーザーが記録されます。各エージェントが実際にどのツールを呼び出したかの記録については、ゲートウェイのログを確認する必要があります。

ClickUpで展開状況を追跡する

上記のインベントリ作成とパイロット実施のステップでは、見落としがちな細かい決定事項が数多く発生します。各サーバーをリスト内のタスクとして追加し、所有者、データアクセス、トラストグループ、トークンコストに関するカスタムフィールドを設定します。次に、各移行タスクにリンクされたドキュメントにロールバックの基準を記述します。パイロットが失敗した場合やアップストリームサーバーがアーカイブされた場合でも、所有者情報や完全な履歴がすべて一箇所にまとめられています。

抱えている課題に適したゲートウェイを選びましょう

このガイドの各セクションは、すべて同じ2つの役割に帰着します。

第一に「制御」です。つまり、エンドポイントが1つ、認証情報の保管場所が1か所、そしてどのエージェントがどのツールを呼び出したかの記録が1つという構成です。このガイドで紹介する5つのゲートウェイはすべて、何らかの形でこの要件を満たしていますが、大きな違いは、インフラのどの部分を自ら運用するかという点にあります。第二の役割は、各エージェントのツールリストを最小限に抑えることです。この点において、ゲートウェイが役立つのは、フィルタリングや検索を設定した場合に限られます。

何か契約書に署名する前に、手持ちのツールを数え、それぞれの定義がいくつのトークンを使用しているかを把握しておきましょう。

誰も利用していないものは除外し、残りを信頼境界ごとにグループ分けして、まず1台の読み取り専用サーバーをゲートウェイ経由で移行させてみてください。もしClickUpがそのサーバーの一つであれば、ClickUp MCPサーバー経由で接続し、エージェントがプロジェクトのコンテキスト全体を把握した上で、タスク、ドキュメント、チャットをどのように処理するかを確認してください。

MCPゲートウェイに関するよくある質問

最適なMCPゲートウェイとはどれでしょうか？

最適なMCPゲートウェイは、エージェントがすでにどこで実行されているかによって異なります。Docker MCP Gatewayはローカル開発に適しています。IBM ContextForgeは、セルフホスティングを希望するチームに適しています。Kong AI GatewayはすでにKongを利用しているチームに適しており、Amazon Bedrock AgentCore GatewayはAWS上のエージェントに適しています。Composioは、多数のSaaSアプリをまたがって動作するエージェントに適しています。規制対象の業界では、セルフホスティングまたはプライベート展開のオプション、ツールごとのアクセス制御、および個々のツール呼び出しのログを確認してください。

MCPはAPIゲートウェイなのでしょうか？

いいえ。Model Context Protocol（MCP）は、AIアプリがツールやデータに接続する方法を定義する仕様です。MCPゲートウェイは、その仕様に基づいて構築されたソフトウェアです。エージェントとMCPサーバーの間に位置し、アクセス、認証情報、およびロギングを処理します。その動作はHTTPとAPIゲートウェイに似ています。HTTPがリクエストのルールを設定し、ゲートウェイがどのリクエストを通すかを決定します。

MCPゲートウェイは必要ですか？

複数のサーバーにまたがって、どのツールに誰がアクセスできるかを制御したい場合や、エージェントの動作履歴を一元的に記録したい場合には、MCPゲートウェイが必要です。少人数のチームが数台の安定したサーバーを運用している場合は、バージョン管理システムに保存された共有設定とシークレットマネージャーで、ほぼ同等の機能を実現できます。チームごとのツールアクセス権限の設定や、認証情報を一元管理する場所が必要になった時点で、ゲートウェイの真価が発揮されます。

ゲートウェイの背後に配置されたMCPサーバーのセキュリティはどうか？

ゲートウェイは、MCPサーバーのセキュリティ対策を容易にします。ただし、それ単体でサーバーを安全にするわけではありません。ゲートウェイは、認証情報を一か所に集約し、各呼び出し元が使用できるツールをリミットし、呼び出しを一元的にログに記録します。Invariant LabsがGitHubのMCPサーバーで実証したように、信頼できるサーバーを経由してプロンプトインジェクションが発生する可能性は依然として残っています。プライベートデータを読み取ったり、信頼できないコンテンツを処理したり、外部へデータを送信したりするツールは、別のツールセットに分離しておくべきです。 ゲートウェイがクライアントのトークンを転送しないよう確実に確認してください。また、更新が提供されなくなったサーバーの使用は中止してください。

ツールの検索機能は、アクセス制御に取って代わるものなのでしょうか？

いいえ。ツール検索は、エージェントがタスクに対してどのツールを認識するかを決定します。アクセス制御は、そのエージェントがツールを呼び出すことを許可されるかどうかを決定します。例えば、Amazon Bedrock AgentCore Gatewayでは、セマンティック検索と認証を別々の機能として扱っています。呼び出し元が使用を許可されているツールに対してのみ検索を実行し、ツールが実際に実行される際に再度許可を確認します。検索からツールを隠すことが唯一の保護手段である場合、そのツールは保護されていないことになります。

MCPゲートウェイの監査ログには何を記録すべきか？

MCPゲートウェイの監査ログには、各呼び出しを行ったユーザー、関与したエージェントやツール、処理を担当したサーバー、呼び出しが許可されたか拒否されたか、発生日時、および返された応答内容が記録されるべきです。例として、KongのAI MCP Proxyプラグインは、許可および拒否されたすべてのツールへのアクセス試行をログに記録します。購入前に、ログがアカウントや設定の変更だけでなく個々のツール呼び出しも網羅していることを確認し、さらにログの保存期間やエクスポートが可能かどうかを確認してください。