Model Context Protocol (MCP) は、Anthropic により 2024年11月にリリースされました。さらに18か月後の2025年12月時点で、月間SDKダウンロード数は97百万に達し、あらゆる主要AIラボからの支援を受けるまでになりました。そして現在、Linux Foundation のディレクテッド・ファンドである Agentic AI Foundation (AAIF) の創設プロジェクトとして運営されています。
その採用は非常に速く進み、ほとんどのプロトコルが管理できるよりもさらに速いものでした。しかし、それにより直ちに問題が生じました。スケールした状態でAIエージェントを多数のMCPサーバーに直接接続することは、運用上持続不可能であり、またプロトコル自体がガバナンスを解決していないのです。
この記事では、MCP Gateway とは何か、インフラレベルで何をするのか、そしてプロダクションのエンタープライズ環境に向けてどのように評価すべきかを説明します。
MCP とは何か、そしてどんな課題を解決するのか？
ゲートウェイを理解する前に、まずMCPが何を標準化するのかを理解する必要があります。
エンタープライズのAIチームは歴史的に、いわゆる N×M 統合問題 に直面してきました。つまり、N 個のエージェントを M 個のツールに接続するには、N×M 個の個別のカスタム統合が必要になり、それぞれが独自の認証フロー、エラーハンドリングのロジック、そして資格情報（クレデンシャル）ストアを持つことになります。MCPがない場合、AIエージェントが組織内に広がるほど統合の複雑さは二次的に増大します。一方、MCPがあるとスケールは線形になります。
MCP は、HTTP 上で JSON-RPC 2.0 を用いて、AIモデルが外部ツールを発見し呼び出すための標準化された方法を定義します。エージェントはサーバーが何を公開しているかを理解するために tools/list リクエストを送信し、その後 call_tool を使ってそれらのツールを呼び出します。このハンドシェイクは、バックエンドが GitHub であれ Salesforce であれ Postgres であれ、あるいは社内APIであれ、いずれの場合でも一貫しています。
ただし、MCP が定義しないのは、「誰が、どのアイデンティティの下で、どのような制約で、そしてどのコストで呼び出せるのか」という点です。これらはガバナンスの問題であり、設計上プロトコル仕様の範囲外です。
MCP Gateway とは何か？
MCP Gateway は、AIエージェントと1つ以上のMCPサーバーの間に位置する、中央集権型のインフラレイヤーです。MCPトラフィック向けに専用設計された 特化型リバースプロキシ として機能し、認証、ルーティング、ポリシー施行、クレデンシャル管理、そしてオブザーバビリティを1か所で扱います。
エージェントの視点では、何も変わりません。エージェントは引き続き tools/list のハンドシェイクを行い、call_tool のリクエストを発行します。違いは、それらのリクエストが今はゲートウェイによって傍受され、ポリシーに照らして評価されたうえで、バックエンドのいずれかのシステムが実行する前にルーティングされる点です。
アーキテクチャ的には、次のような変化になります。
ゲートウェイなしの場合：
Agent A → GitHub MCP Server
Agent A → Slack MCP Server
Agent B → GitHub MCP Server
Agent B → Postgres MCP Server
Agent C → Salesforce MCP Server
...（N×M の接続、それぞれが独自の認証とクレデンシャルを管理）
ゲートウェイありの場合：
Agent A ──┐
Agent B ──┤──→ [MCP Gateway] ──→ GitHub MCP Server
Agent C ──┘ ──→ Slack MCP Server
──→ Postgres MCP Server
──→ Salesforce MCP Server
ゲートウェイは、セキュリティポリシー、アクセス制御、そしてオブザーバビリティを一貫して適用できる、唯一のボトルネック（関門）になります。MCP gateway に関する Hacker News の議論で指摘されているように、実務者は、中央集権型の MCP レジストリ、OAuth 連携、そしてキュレーションされたツールセットのスコーピングのような機能を求めています。これらは、プロトタイプだけでなく、組織規模で MCP を成立させるためのものです。
なぜ MCP だけではエンタープライズ環境で不十分なのか？
クレデンシャルの拡散
ゲートウェイがない場合、各エージェントは、アクセスするあらゆるツールに対して独自の API キー、OAuth トークン、そしてサービスアカウントの資格情報を持ちます。これらのクレデンシャルは、各種サービスに散らばった環境変数、設定ファイル、シークレットストアに格納されることになります。これは机上のリスクではありません。GitGuardian の調査では、2025年だけでも MCP の設定ファイル内で公開されていたユニークなシークレットが 24,008 個あったことが分かっています。中でも、Google API キーや PostgreSQL の接続文字列が最もよく漏えいしているタイプでした。クレデンシャルのローテーションは、複数のコードベースにわたって手作業で実施する必要があります。侵害されたエージェントに対してアクセスを取り消すには、そのエージェントが接触しているあらゆる統合を探し回らなければなりません。アクセス取り消しのための単一のポイントは存在しません。
集中管理されたアクセス制御がない
MCP にはネイティブのロールベースアクセス制御が定義されていません。もしエージェントがサーバーに接続できるなら、そのサーバーが公開しているすべてのツールを発見できてしまいます。財務エージェントは開発ツールを見ることができます。サポートエージェントはデータベース管理のエンドポイントを見ることができます。最小権限の原則は、プロトコルの外側で、毎回個々のエージェントに対して実装する必要があります。あるいは実装されないままになります。MCP-Scanner に関する Hacker News のスレッドで述べられているように、人々はスマートフォンにアプリを入れるのと同じ感覚で MCP を過剰に用意してしまい、最小権限を適用していません。
最小権限アクセスとは、エージェントが定義されたタスクに必要な特定のツールだけを見たり呼び出したりでき、それ以外は何もできないようにすべきだという原則です。MCPの文脈では、たとえばサポートエージェントはデプロイ用ツールを一切見るべきではなく、読み取り専用の分析エージェントは、基盤となるサーバーが何を公開しているかに関係なく、書き込み操作へのアクセスを持つべきではない、ということを意味します。
オブザーバビリティのブラックホール
エージェントがツールへ直接接続すると、どのエージェントが実際に何をしているかについての集約された全体像が得られません。複数ステップのワークフローをデバッグするには、N 個の異なるサーバーからのログをつなぎ合わせる必要があります。統一された実行タイムラインも、トレースの相関も、コストの帰属もありません。基準（ベースライン）がないため、異常は検知されません。
コストに関するガバナンスがない
MCP はトークン消費を追跡せず、利用制限も強制しません。エージェントはツールを繰り返し呼び出せてしまい、LLM 呼び出しや有料API操作が発生しても、予算上限は設定されません。エンタープライズ規模では、これは技術的な問題というより、財務面の制御問題になります。
セキュリティの攻撃対象領域
2025年4月、セキュリティ研究者が 分析を公開し、プロンプトインジェクション、ツールの権限によってツールを組み合わせてデータを持ち出せてしまう問題、そして見た目が似ているツールが信頼されたものを静かに置き換え得る問題など、複数の未解決のMCPセキュリティ問題を特定しました。中央集権型のゲートウェイは、この3つすべてを緩和するための実用的な強制ポイントです。
MCP Gateway は実際に何をするのか？
集中管理された認証とアイデンティティの伝播
プロダクションのゲートウェイは、受信するアイデンティティ（通常は JWT、PKCE を伴う OAuth 2.0、または OIDC）を検証し、そのアイデンティティを下流の MCP サーバーへ伝播させます。共通のサービスアカウントの下でエージェントが動くのではなく、特定の認証済みユーザーの代わりにリクエストが実行されるのです。
これは実際の脆弱性を確実に封じます。ユーザーがリポジトリを削除できないのであれば、そのユーザーのために動くエージェントも削除できません。認可はプロンプトに「あるもの」として想定されるのではなく、プロトコル層で強制されます。MCP仕様は2025年3月の改訂でOAuth 2.1のサポートを導入し、2025年6月には大幅な改良が加えられましたが、ゲートウェイ間では実装品質にばらつきがあります。エンタープライズのSSOを自動的に処理するものもあれば、サーバーごとに手動で設定が必要なものもあります。
Tool-Level RBAC
ゲートウェイはtools/listの応答を傍受し、要求しているエージェントの役割と権限に基づいてそれをフィルタリングします。機密性の高いツールは、単にエージェントのコンテキストに表示されません。たとえば次のような設定:
virtual_server:
name: support-scope
allow_tools:
- github.list_issues
- github.get_comments
- crm.update_ticket
...は、このエンドポイントを呼び出すエージェントが、データベース管理ツール、デプロイ制御、またはそもそも使うべきでないいかなる機能も決して目にしないことを意味します。これはモデルのパフォーマンスを直接改善し、行動可能な領域が意図的に制約されることでエージェントの推論がより正確になり、何か問題が起きたときの影響範囲（ブラスト半径）を小さくします。
Intelligent Routing
ゲートウェイは各リクエストを精査し、呼び出されるツールに基づいて適切なアップストリームのMCPサーバーへルーティングします。セッションアフィニティにより、状態を持つ複数ステップのエージェント会話を同じバックエンドサーバー上で維持します。ロードバランシングによりトラフィックを分散します。サーキットブレーカーは、アップストリーム側のツールが劣化した際に連鎖的な障害が起きるのを防ぎます。
Unified Observability
tools/listとcall_toolの各呼び出しはすべて、メタデータ（エージェントの識別情報、ユーザーコンテキスト、ツール引数、応答ステータス、レイテンシ）付きでログに記録されます。これにより、接続されたすべてのシステムにまたがる一貫した監査の履歴が作られます。メトリクスはPrometheus形式でエクスポートします。トレースはOpenTelemetry標準に従って行われます。これは、6つの異なるツールにまたがるマルチステップのエージェントタスクをデバッグするときに重要になります。
Cost Management
ゲートウェイは、繰り返し呼び出されるツールに対するキャッシュを実装し、エージェントまたはユーザーごとのレート制限を適用し、利用状況の分析を可視化できます。繰り返し呼び出されるツールに対するキャッシュ戦略は、LLMコストを大幅に削減し得ます。そして、そのようなことを大規模に実装する実用的な場所がゲートウェイです。
Credential Vaulting
APIキー、OAuthトークン、およびサービス認証情報はゲートウェイで一元的に保存されます。エージェントは生の認証情報を直接扱うことはありません。ローテーションポリシーは、各エージェントのコードベース全体ではなく、ゲートウェイ側で一度適用されます。
How Does an MCP Gateway Differ from an API Gateway?
従来のAPIゲートウェイは、ステートレスなクライアント・サーバーのリクエスト—レスポンスのサイクルを想定して設計されています。これはWebアプリケーションやモバイルアプリケーションで標準的な形です。HTTPルーティング、認証、レート制限、そしてRESTまたはGraphQLトラフィックの変換を扱います。
MCPゲートウェイは、AIエージェントに固有のステートフルでセッションを意識した、しばしば双方向の通信パターンを対象に設計されています。長時間実行されるエージェントタスクのコンテキストを理解します。複数の連続したツール呼び出しにわたってユーザーの識別情報を伝搬することができます。マルチステップのエージェントワークフローが実行途中でコンテキストを失わないように、セッション状態を維持します。tools/list → call_toolというプロトコルのサイクルを理解し、HTTP層だけでなく、そのセマンティックなレベルでポリシーを適用できます。
現代のエンタープライズのアーキテクチャでは、これらはどちらも通常並存します。APIはアプリケーションのサービスを提供します。APIゲートウェイは従来のHTTPトラフィックを統治します。MCPサーバーは、エージェントに対して選択された機能を公開します。MCPゲートウェイは、エージェントからツールへの通信を統治します。両者の関係は補完的です。
How Does an MCP Gateway Differ from an AI Gateway?
これは分けて考える価値があります。というのも、実務上よくある混乱の元だからです。AIゲートウェイを評価している購入者は、自分たちがMCPゲートウェイを見ている状況に陥りがちです。
AIゲートウェイはLLM推論の手前に位置します。どのモデルを呼び出すかを管理し、プロバイダー間（OpenAI、Anthropic、Mistral）のトラフィックをルーティングし、トークン予算を強制し、プロンプト／応答のログを処理し、モデルプロバイダーのAPIを単一のインターフェースの裏側に抽象化します。AIゲートウェイの役割はモデル呼び出しを統治することです。
MCPゲートウェイは、エージェントと、エージェントが呼び出すツールとの間に位置します。モデルがすでに「行動する」と判断した後に、エージェントがツール呼び出し：として何を実行できるかを統治します。2つの層は補完関係にあります。AIゲートウェイは、エージェントが使う「頭脳」を制御し、MCPゲートウェイは、その「手」を制御します。
成熟したエンタープライズのアーキテクチャでは、どちらも存在します。AIゲートウェイはモデルレベルのトラフィックを担当します。MCPゲートウェイは、モデルの出力が引き起こす下流のツール実行を担当します。
What Are the Categories of MCP Gateway Available?
ゲートウェイの全体像を理解するには、機能チェックリストだけでなく、主要な設計思想を理解する必要があります。
Managed Integration Platforms
これらは、大量の事前構築されたコネクタ群の背後で統合の複雑さを抽象化することにより、開発者のスピードを最優先にします。認証ライフサイクル管理（複雑なOAuth 2.1フローを含む）は、利用者の代わりに処理されます。
ComposioのMCP Gatewayは代表的な例です。主要なエンタープライズ向けSaaSアプリケーションにまたがる1000以上のツールとアクション、統一された認証レイヤー、SOC2およびISOの認証、アクションレベルRBAC、そしてゼロデータ保持のアーキテクチャを提供します。このアーキテクチャは、統合レイヤーを自前で抱え込むのではなく、エージェントを多数の異なるツールに素早く接続する必要があるチーム向けに設計されています。22種類のツールに対して22個の異なるMCPサーバーを使い分ける代わりに、1つのゲートウェイを導入し、単一の認証フローと監査の表面を通じて、幅広い事前構築済みの統合ライブラリにアクセスします。
試験導入（パイロット）から本番へ移行するほとんどのエンタープライズチームにとって、これが最も実用的な出発点です。アーキテクチャのより深いウォークスルーについては、ComposioによるMCPゲートウェイガイドを参照してください。
Security-First Proxies
これらは、セキュリティを主たる制約とし、パフォーマンスを二次的なものとして扱います。Lasso Securityは、ロードされる前に、プロンプトインジェクションを検知し、PIIをマスクし、MCPサーバーの評判スコアを計算するために、すべてのMCPトラフィックをリアルタイムに検査します。トレードオフはレイテンシです。深いセキュリティスキャンは100〜250msのオーバーヘッドを追加するため、このカテゴリはレイテンシに敏感なワークフローには不向きですが、コンプライアンスが妥協できない規制環境には適しています。
Infrastructure-Native Open Source
これらは、既存のコンテナネイティブなDevOpsワークフローに統合します。Docker MCP Gatewayは、よく知られたdocker mcpのCLIツールとコンテナベースのセキュリティを使って、MCPサーバーを分離されたDockerコンテナとして実行します。ObotはKubernetesネイティブであり、データソブリンティ（完全なデータ主権）を必要とする組織向けに設計されています。
どちらも、チームが統合レイヤーを自社で担う必要があります。チーム側ではMCPサーバーを用意し、ゲートウェイがそれらを統括します。マネージドプラットフォームより運用オーバーヘッドは高くなりますが、その分コントロールも大きくなります。
エンタープライズチームはゲートウェイを選ぶ際に何を評価すべきか？
デプロイモデル
クラウドホスト型のマネージドゲートウェイは本番までの時間を短縮しますが、データが外部のインフラを経由します。セルフホストまたはVPC配置のゲートウェイなら、データの主権（ソブリンティ）を確保できます。医療、金融、政府など、規制対象のデータが自社のクラウド内にとどまる必要があるチームにとっては、デプロイモデルはしばしば“後から考える”ものではなく、最初のフィルターになります。
認証標準
PKCE付きのOAuth 2.1、OIDC、SAMLへの対応を確認してください。ゲートウェイが、既存のIDプロバイダ（Okta、Microsoft Entra ID、Auth0）と統合できるか、また、オンビハーフ・オブ（代理）トークン伝播に対応しているかも確認します。これは、共有サービスアカウントではなく認証されたユーザーの身元でエージェントが動作するパターンです。
RBACの粒度
ゲートウェイのレベルでのRBAC（各ロールがどのツールを参照できるか）が最低ラインです。単一サーバー内で“書き込みは不可、読み取りは可”といった形でツール単位でRBACを提供するのは、より高度で、重大な影響範囲（ブラス卜レイドゥス）を大幅に抑えます。マーケティング資料の文言だけでなく、実際にどのように強制（enforcement）されるのかを確認してください。
観測性（Observability）の深さ
Prometheus互換のメトリクスとOpenTelemetryトレースが最低条件です。ゲートウェイがツール呼び出しを、特定のユーザーやエージェントに紐づけられるか（サービスアカウントだけでなく）、監査ログがコンプライアンス上のフォーマット要件を満たすか、ダッシュボードが異常検知やコスト帰属に対応しているか、さらにゲートウェイがゼロデータ保持アーキテクチャを提供しているか（ツール呼び出しのペイロードやクレデンシャルが、ゲートウェイ提供事業者のインフラに保存されないこと）も確認してください。これは、規制産業やデータ主権の要件がある場合に重要です。
統合の広さ vs ガバナンスの深さ
マネージドプラットフォームは広範な統合ライブラリを提供しますが、基盤となるインフラへのコントロールは限定的です。ガバナンス優先型のプラットフォームは深いコントロールを提供しますが、自前のサーバーを用意する必要があります。両方を必要とするチーム向けに、大規模なマネージド統合ライブラリとエンタープライズ品質のガバナンスを、ComposioのMCP Gatewayは現在唯一の選択肢として提供しています。これは単一製品で、500以上のツール／アクションに加え、SOC2準拠、RBAC、そしてゼロデータ保持を組み合わせています。
完全な比較は、開発者向けの最適なMCPゲートウェイをComposioが分解して解説した記事をご覧ください。
パフォーマンスのオーバーヘッド
プロキシを追加するたびにレイテンシが増えます。マネージドプラットフォームは通常、オーバーヘッドが10ms未満です。TrueFoundryはp95で5ms未満を公表しています。Lunar.dev MCPXはp99で約4msを公開しています。Docker MCP Gatewayはコンテナ管理によりオーバーヘッドが追加されます。ウォームパスの性能はコールドスタートより大幅に優れており、コールドスタートでは50〜200msの追加が起こり得ます。Lasso Securityは100〜250msです。応答時間がユーザーに見える会話型エージェントでは、これは重要です。バックグラウンドの自動化ワークフローでは、通常は問題になりません。
自社でMCPゲートウェイを構築する
カスタムゲートウェイの構築は可能ですが、難度の高い分散システムの課題を解決する必要があります。クレデンシャルのローテーション、分散レート制限、OAuth 2.1の状態管理、PII（個人情報）のマスキング、サーキットブレーカーなどです。MCP仕様が成長し、ツールAPIが変わり、セキュリティ要件が成熟するにつれて増え続ける保守負担が、真のコストです。初期の作り込みではありません。ほとんどのチームでは、ライセンスコストを考慮しても、DIYよりマネージドゲートウェイのほうが総保有コスト（TCO）が大幅に低くなります。
MCPセキュリティの脅威環境に関する注記
MCPデプロイメントに対するセキュリティ脅威は机上の空論ではありません。代表的なリスクとして、特権付きのサービスロールアクセスで動作するエージェントが、ユーザーからの入力を処理する際に、意図せずその指示を実行してしまい、正当な出力チャネルを通じて機密データを流出させる可能性があります。ゲートウェイレベルでの最小権限の原則が、主要な防御手段です。
LLMセキュリティに関するOWASPのガイダンスでは、プロンプトインジェクションがAIシステムに対する最も高リスクな攻撃ベクトルの1つであると挙げています。MCPゲートウェイは、それを緩和するための実用的な強制レイヤーです。JSON-RPCスキーマに対する入力検証、許可リスト化されたアクション、PIIのマスキング、そしてリアルタイムのツール評判スコアリングによって実現します。
ゲートウェイがない場合、MCPデプロイメントのセキュリティ姿勢は、N個の独立して管理されたエージェントのうち最も弱いリンクにしかなりません。
ゲートウェイはどれくらいのレイテンシを追加しますか？
マネージドプラットフォーム：通常、オーバーヘッドは10ms未満。高性能で目的特化されたゲートウェイ（TrueFoundry、Lunar.dev MCPX）：p99で5ms未満。セキュリティスキャン型ゲートウェイ（Lasso Security）：検査の深さにより100〜250ms。Docker MCP Gatewayのウォームパスのレイテンシは低く、コールドスタートのオーバーヘッドは50〜200ms追加される可能性があります。
MCPゲートウェイの次に来るもの
MCPの公開された方向性と、2026年初頭からのコミュニティでの議論を踏まえると、優先すべき4つの領域が明らかになっています。1つ目はトランスポートの進化（ロードバランサ互換性のためのステートレスなStreamable HTTP）、2つ目はエージェント通信のプリミティブ（Tasksプリミティブにおけるリトライのセマンティクスと有効期限ポリシー）、3つ目はガバナンスの成熟（正式なコントリビュータプロセス）、4つ目はエンタープライズ対応の準備（監査トレイル、SSO連携の認証、そしてゲートウェイのパターン）です。
ゲートウェイのパターンは、今ではプロトコルのロードマップ上で明確に取り上げられています。ゲートウェイ層はもはやアドオンではなく、エンタープライズ向けMCPデプロイメントのための正式なインフラとして整備されつつあります。
まずは主要な制約から始めてください。統合のスピードが最重要なら、マネージドプラットフォームが正解です。規制産業でのコンプライアンスが最重要なら、SOC 2認証、監査ログのフォーマット、そしてIdP連携を優先してください。データ主権が重要なら、VPCにデプロイ可能な選択肢を評価してください。レイテンシが体感に直結する会話型プロダクトであれば、SLAに対してp95の数値をベンチマークしてください。
Composio MCP Gatewayは、最初の、そして最も一般的なケースをカバーしています。つまり、エンタープライズチームが、幅広い統合ライブラリ、統一された認証、そしてインフラを自社で所有することなくコンプライアンス制御を備えて、プロトタイプから本番へ移行する必要がある場合です。要件がより限定的、または既存のMCPサーバーインフラがあるチームでは、上で取り上げた専門的なオプションのリストが、その判断に必要なトレードオフを示してくれます。
ゲートウェイのアーキテクチャパターンをより深く知るには、MCPゲートウェイに関するComposioの開発者向けガイドをご覧ください。ユースケース別にゲートウェイの選択肢を完全に比較するには、2026年版：開発者向けの最適なMCPゲートウェイをご覧ください。
よくある質問
1文で言うと、MCP Gatewayとは何ですか？
AIエージェントとMCPサーバーの間にある中央集権的なインフラ層で、認証を強制し、リクエストをルーティングし、アクセス制御を適用し、すべてのエージェントとツールのやり取りにわたって観測性を提供します。
MCP Gatewayは本番デプロイに必要ですか？
プロトコル仕様によって必須とされているわけではありません。しかし、2〜3台以上のMCPサーバー、複数チーム、規制対象データ、またはコンプライアンス上の義務があるデプロイでは、実務上必要になります。
MCPサーバーとMCPゲートウェイの違いは何ですか？
MCPサーバーはツールを実行します。GitHub、Postgres、Slack、または社内のAPIに接続し、各種操作を行います。MCPゲートウェイは、これらのサーバーへのアクセスを統制します。いずれのツールが実行される前に、アイデンティティ、可視性フィルタリング、ポリシー適用、ルーティングを処理します。
MCPゲートウェイはプロンプトインジェクションをどのように扱うべきですか？
Lasso Securityのようなセキュリティ重視のゲートウェイは、すべての通信をリアルタイムにスキャンし、インジェクション検出を引き起こすペイロードをブロックします。MintMCPのようなガバナンスプラットフォームは、入力スキーマの検証と、許可リスト化されたアクションのみを許可する仕組みを適用します。Composioのようなマネージドプラットフォームは、ツールの実装をサンドボックス化された環境で実行します。複数の防御レイヤーを重ねることが、現時点での最良の実践です。
自分のゲートウェイはどの認証標準をサポートすべきですか？
PKCE付きのOAuth 2.1、OIDC、SAML、そしてエンタープライズ向けIdPのサポート。MCP仕様では、2025年3月の改訂でOAuth 2.1が導入され、2025年6月に改良が加えられましたが、実装の品質は大きく異なります。オンビヘーフオブ（代理）アイデンティティの伝播フローを特にテストしてください。ここが、実装が最もよく分岐するポイントです。
