MCP Gateway（MCP ゲートウェイ）vs プロキシ vs レジストリ：本当に必要なのはどれか

MCP ゲートウェイ（MCP Gateway） とは、AI クライアントと多数の MCP サーバーの間に置かれる単一のエンドポイントです。クライアントはゲートウェイに一度接続するだけで済み、ゲートウェイがユーザーを認証し、どのツールを見せて呼び出させるかを決め、各呼び出しを適切なアップストリームサーバーへルーティングし、認証情報を注入し、すべてをログに残します。Model Context Protocol 向けに作られた API ゲートウェイと考えるとわかりやすいでしょう。

MCP プロキシはより単純な部品（MCP トラフィックを転送し、多くの場合トランスポートの変換も担う）で、レジストリはどんなサーバーが存在するかを教えてくれるカタログです。多くのチームはまずサーバーに直接接続し、トランスポートが合わないときにプロキシを追加し、複数の人やエージェントが同じサーバー群を共有するようになった段階でゲートウェイを導入します。本記事では三者の違い、お金をかける価値のある機能、そして今日実際にデプロイできるゲートウェイを紹介します。

なぜ MCP ゲートウェイが存在するのか

MCP 自体はシンプルなクライアント・サーバー型プロトコルです（MCP の仕組みを参照）。各クライアントがそれぞれのサーバーに個別に接続します。Claude Code で 3 つのサーバーを使う個人開発者ならそれで十分です。しかし次のような状況では破綻します：

• 10 クライアント × 10 サーバー なら設定エントリは 100 個になり、それぞれが自分の API キーを抱えます。
• 「誰がどのツールを呼んだのか？」に誰も答えられない。 各サーバーがそれぞれのやり方でログを取る（あるいは取らない）からです。
• 各サーバーが OAuth を個別に実装している。 まったく実装していないサーバーもあります。
• エージェントに見えるツールが多すぎる。 すべてのサーバーのすべてのツールを読み込むとコンテキストが肥大化し、モデルが危険なツールを選ぶリスクも上がります（MCP ツールディスカバリーを参照）。

ゲートウェイはこれらの関心事を一か所に集約します。かつて API ゲートウェイが REST マイクロサービスに対して果たした役割と同じです。

MCP ゲートウェイ vs プロキシ vs レジストリ

この 3 つの用語はマーケティング文書では混同されがちなので、実務上の違いを整理します：

実務上のポイントを 2 つ：

• ゲートウェイは「意見を持ったプロキシ」です。 どのゲートウェイもトラフィックをプロキシしますが、すべてのプロキシがゲートウェイというわけではありません。ID・ポリシー・監査を扱わないなら、それはプロキシと呼ぶべきです。
• 多くのゲートウェイはレジストリを内蔵しています。 ContextForge と MCPJungle はどちらも「レジストリ + ゲートウェイ」を名乗っており、サーバーを一度登録すればゲートウェイがそれを公開します。一方、公式の MCP Registry（まだプレビュー段階）のような公開レジストリは server.json メタデータを公開するだけで、リクエスト経路には一切入りません。

MCP ゲートウェイのコア機能

製品を比較するときは、次の 6 つの能力を確認してください。

1. 認証と OAuth の終端

ゲートウェイこそが、クライアントが直接話す OAuth 保護リソースであるべきです。ユーザーは自社の ID プロバイダーで一度サインインし、ゲートウェイは自身の認証情報でアップストリームサーバーを呼び出します。これが重要なのは、MCP 仕様が トークンパススルー（token passthrough） を明示的に禁止しているからです。セキュリティのベストプラクティスによれば、MCP サーバーは "MUST NOT accept any tokens that were not explicitly issued for the MCP server"（その MCP サーバー宛てに明示的に発行されたものではないトークンを受け入れてはならない）とされています。クライアントのトークンをそのまま下流 API に転送する素朴なプロキシはこのルールに違反します。同じ文書では OAuth プロキシに対する confused deputy（混乱した代理人） 攻撃も説明され、クライアントごとの同意取得が必須とされています。全体の流れは MCP の認証と OAuth を参照してください。

2. ポリシーとアクセス制御

誰がどのサーバー、どのツールを使えるのか？優れたゲートウェイはこれを共有 API キーではなく、ID グループやロールに結び付けます。Microsoft のゲートウェイは Entra ID のアプリロール、Kong は Consumer と Consumer Group の ACL、Cloudflare は Zero Trust の Access ポリシーを使います。

3. ツールのフィルタリングとキュレーション

クライアントごとにツールのサブセットを公開します。サポートボットには読み取り専用ツールを、エンジニアにはフルセットを、といった具合です。これはセキュリティ対策であると同時に、コンテキストウィンドウの最適化でもあります。許可リスト、ツール単位の有効化・無効化、ツール名や説明の書き換え機能があるかを確認しましょう（Cloudflare portals はエイリアスと説明の上書きに対応しています）。

4. 監査ログと可観測性

すべてのツール呼び出しについて、ユーザー、クライアント、ツール名、引数（必要に応じてマスク）、結果ステータスを記録すべきです。OpenTelemetry へのエクスポートがあればなお良く、MCP トラフィックを他のトレースと並べて確認できます。

5. 多重化と集約

1 つのエンドポイントで多数のサーバー。ゲートウェイはすべてのアップストリームの tools/list 結果をマージし、名前の衝突を避けるために名前空間を付け（MCPJungle は server__tool という規約を採用）、各 tools/call を正しいバックエンドへルーティングします。さらに一歩進んで、通常の REST API を MCP ツールとしてラップするゲートウェイもあります（ContextForge と Kong はどちらも対応）。

6. シークレット管理

アップストリームの API キーは各自のノート PC ではなくゲートウェイに置きます。Docker のゲートウェイは起動時にシークレットをサーバーコンテナへ注入し、ContextForge は保存された認証シークレットを暗号化します。ツールのレスポンスに含まれるシークレットや個人情報をマスクするゲートウェイもあります（Lasso のプラグイン）。

これらの機能が対処する脅威モデル全体については、MCP セキュリティのベストプラクティスをお読みください。

2026 年の MCP ゲートウェイの選択肢

以下の製品はすべて、2026 年 10 月に公式ドキュメントまたはリポジトリで確認したものです。

Docker MCP Gateway

Docker のゲートウェイは各 MCP サーバーを隔離されたコンテナとして動かし、1 つのエンドポイントからまとめて公開します。サーバーをプロファイルにまとめ、docker mcp gateway run --profile <name> で起動し、Claude Code・Cursor・VS Code から接続します。Docker Desktop に同梱される docker mcp CLI プラグインとして提供され、Compose を使ってヘッドレスでも動かせます。詳しい手順は Docker MCP Gateway セットアップガイドを参照してください。

Microsoft MCP Gateway

Kubernetes 上で動くリバースプロキシ兼管理レイヤーです。ルーティング（サーバーごとの /adapters/{name}/mcp と、/mcp のツールルーター）、サーバーインスタンスのデプロイと管理を担い、Microsoft Entra ID のベアラートークンとアプリロールでリクエストを認可します。REST のコントロールプレーンと Web 管理ポータルも備えています。サーバーがすでに AKS などの Kubernetes クラスターで動いているなら有力な選択肢です。

IBM ContextForge

Apache-2.0 ライセンスのレジストリ兼ゲートウェイで、MCP サーバー、A2A エージェント、REST/gRPC API を 1 つのエンドポイントの背後に統合します。主な機能は 仮想サーバー（選んだツールを新しい MCP エンドポイントにまとめる）、REST から MCP への変換、管理 UI、豊富なプラグイン群、OpenTelemetry トレーシングです。インストール：

pip install mcp-contextforge-gateway

または ghcr.io/ibm/mcp-context-forge コンテナを実行します。JWT_SECRET_KEY と AUTH_ENCRYPTION_SECRET がないと起動を拒否します。生成方法は README に記載されています。

Kong AI MCP Proxy

Kong がすでに API ゲートウェイなら、AI MCP Proxy プラグインが MCP と HTTP を橋渡しします。既存の MCP サーバーをプロキシする、REST API を MCP ツールに変換する、複数のプラグインインスタンスのツールを 1 つの MCP サーバーに集約する、といった使い方ができます。ツール単位のアクセス制御には Consumer ACL を使います。Kong Gateway 3.12+ が必要で、AI Gateway Enterprise の一部として提供されています。

Cloudflare MCP server portals

Cloudflare Zero Trust のマネージドな選択肢です。ポータルは複数の MCP サーバーを https://subdomain.your-domain/mcp 形式の 1 つの URL の背後にまとめます。ユーザーは Cloudflare Access でサインインし、Allow ポリシーで各ユーザーに見えるサーバーが決まり、管理者は公開するツールとプロンプトを選別し、Access がツールリクエストをログに残します。Cloudflare 上のドメインと、Zero Trust に設定済みの ID プロバイダーが必要です。ドキュメントでは、Access がそのサーバーの OAuth プロバイダーでもない限り、ブロックされたユーザーでも直接 URL でアップストリームサーバーにアクセスできると注意しているので、オリジン側も保護してください。

MCPJungle

セルフホスト型の「レジストリ + ゲートウェイ」で、単一のエンドポイント（デフォルトは http://localhost:8080/mcp）を提供します。ツールグループ（厳選したツールのサブセットを専用エンドポイントで公開）と、クライアント許可リスト・アクセストークン・メトリクスを備えたエンタープライズモードに対応しています。brew install mcpjungle/mcpjungle/mcpjungle または Docker Compose でインストールできます。

Lasso MCP Gateway

プラグインベースのローカルゲートウェイ（pip install mcp-gateway）で、既存の mcp.json を読み込み、サーバーを起動してトラフィックをサニタイズします。プラグインでシークレットやトークンのマスク（basic）、Presidio による個人情報のマスク（presidio）、Lasso のホスト型ガードレールの適用（lasso、API キーが必要）、呼び出しのトレース（xetrack）が行えます。--scan モードでは使用前にサーバーの評判とツール説明をチェックします。

MCP ゲートウェイが必要なとき（不要なとき）

おそらく不要なケース：

• Filesystem や Playwright など、少数のローカルサーバーを使う個人開発者。クライアントの設定ファイルがそのままゲートウェイです。
• GitHub MCP Server のように、OAuth を正しく実装済みのファーストパーティのリモートサーバーだけを使う場合。直接接続しましょう（リモート MCP サーバーガイド）。
• stdio サーバーを HTTP サーバーにしたいだけの場合。それはゲートウェイではなくプロキシの仕事です。

おそらく必要なケース：

• 数人以上の人やエージェントが同じサーバー群を共有しており、アクセスの追加・削除・取り消しを一か所で行いたい。
• セキュリティやコンプライアンス部門から、すべてのツール呼び出しについてユーザーに紐づいたログを求められている。
• アップストリームの API キーが多くのノート PC の設定ファイルに貼り付けられている。
• チームやエージェントごとに異なるツールセットを提供したい、あるいは本番エージェントから破壊的なツールを隠したい。
• 社内 API を MCP ツールとして公開し、その前段に認証・レート制限・監査を置きたい。

選び方： ローカルの開発スタックなら Docker。Kubernetes と Entra ID なら Microsoft。すでに Kong や Cloudflare を使っているならそれを活用。オープンソースのセルフホストで幅広いプロトコル対応が欲しいなら ContextForge。軽量なチーム構成なら MCPJungle。既存の設定に情報漏えい対策を加えたいなら Lasso。どれを選ぶにしても、トークンをパススルーせず認証を終端することを必ず確認してください。

次のステップ

• mcp.so で MCP サーバーを探し、ゲートウェイの背後に置くサーバーを計画しましょう。カテゴリから探すこともできます。
• Docker MCP Gateway セットアップガイドで、10 分でローカルにゲートウェイを試せます。
• 本番投入の前に、MCP セキュリティのベストプラクティスと MCP の OAuth 認証を確認してください。