多くの企業では、AIエージェントに社内システムへのアクセス権を与える動きがそのアクセスをどう統制するか、という議論よりも先に進んでいます。Model Context Protocol（MCP）サーバーを立てて、エージェントがソースコード管理やデータベース、チケット管理システム、社内APIなどに手を伸ばせるようにするチームが増えています。ただし、こうしたサーバーの一つひとつが、コマンドの実行やレコードの変更、ワークフローの起動までエージェントに許してしまう点は見過ごせません。

一元的なガバナンスがなければ、1台のサーバーが乗っ取られたり誤設定されたりしたときの被害範囲に歯止めが利きません。現実的に起きるのは「MCPサーバーの乱立」です。サーバーがそれぞれ孤立して動き、エージェントごとに別々の接続を管理する。ポリシーは共有されず、監査ログも一本化されず、どのエージェントにどのツールを見せるかを決める発見レイヤーもありません。この隙間を埋めるのがMCP Gatewayです。どれだけ成熟したAPI Gatewayであっても、その代役は務まりません。両者は異なるレイヤーで、異なる種類のトラフィックを統制しているからです。本記事では、API Gatewayが元々対応するようには作られていない領域を、MCP Gatewayがどう統制するのかを解説します。

本記事は、CDataがAI Gatewayをテーマに毎週火曜と木曜に配信している意思決定者向け学習シリーズの第3回です。

シリーズの概要こちら: AI Gateway：意思決定者向けの学習シリーズ

ポイント早わかり

定義：MCP Gatewayは、MCPトラフィック専用に設計されたリバースプロキシです。AIエージェントと、エージェントが呼び出すMCPサーバーの間に立ち、すべてのツール呼び出しをバックエンドに届く前に認証し、統制します。

API Gatewayとの違い：API GatewayはHTTPサービスのエンドポイント単位のアクセスを統制します。MCP Gatewayが統制するのはエージェントとツールの関係そのものです。エージェントがどのツールを発見できるか、各呼び出しが誰の権限で行われるか、エージェントに何が許されるかを決めます。

なぜ重要か：エージェントとツール間のトラフィックには、従来のAPI Gatewayの設計では想定していなかったガバナンス課題（ツール検出、ID伝播、人間による承認）が伴います。

MCP Gatewayとは？

MCPトラフィック専用のリバースプロキシ、それがMCP Gatewayです。AIエージェントとエージェントが呼び出すMCPサーバーの間に位置し、すべてのツール呼び出しをバックエンドシステムに届く前に捕捉して認証し、統制します。すべてのエージェントリクエストの経路上に立つこの一点集中の位置づけこそが、従来のインフラがHTTPトラフィックに対して行ってきたのと同じ形でポリシーを強制できる理由です。

MCPサーバーとの違いは、レイヤーの違いです。MCPサーバーはエージェントにツールを公開する存在です。GitHub、Postgres、Slack、社内APIなどにエージェントを接続し、エージェントが求める呼び出しを実行します。MCP Gatewayは、そうしたサーバー群の上位に立つコントロールプレーンです。どのエージェントがどのツールを、どの権限で、どんな制約のもとで見られるかを決めるのはMCP Gatewayの役割です。サーバーが実行レイヤーだとすれば、MCP Gatewayはガバナンスのレイヤーにあたります。

API Gatewayとの違いは、呼び出し元の違いです。API Gatewayはサービスの境界に立ち、外部クライアントから既知のエンドポイントへのリクエストを統制します。一方でMCP Gatewayはエージェントのループの内側に位置し、AIエージェントがより大きなエージェンティックワークフローの一手順として自律的に行うツール呼び出しを統制します。どちらもプロキシですが、相手にする主体も、扱うリクエストの種類も異なります。

その違いが最初に具体化するのが認証です。2025年版のMCP仕様はOAuth 2.1を標準として採用しており、OAuth 2.1のリソースサーバーとして動作するゲートウェイは、ツールを実行する前にトークンを検証し、スコープを強制します。ここで効いてくるのがToken Exchangeです。エージェントが持つ広い権限のトークンを、実際の利用者のIDに紐づく最小権限のトークンへ交換したうえでツールを呼び出す仕組みで、エージェントに恒常的な強い権限を持たせずに済みます。これによってシングルサインオン連携が可能になります。認証は、各サーバーが個別に実装する任意設定ではありません。今や本番運用の前提条件です。

API Gatewayの得意分野と限界は？

API Gatewayは、実績があり枠組みも確立されたインフラです。何が苦手かを名指しする前に、何を得意とするかを正確に押さえておく必要があります。API Gatewayはバックエンドの全ライフサイクル、つまり認証、レート制限、バージョン管理、トラフィック管理、そしてセキュリティ脅威に対する深いコンテンツ検査までを一手に引き受けます。マイクロサービスやREST APIの管理においては、API Gatewayが正解であり、この点はMCPの登場によっても変わりません。ただし、既存のAPIをそのままMCPサーバーとして公開する設計には注意が必要で、その落とし穴は既存APIのMCP化に潜む落とし穴で詳しく取り上げています。

API Gatewayの守備範囲は、エンドポイント単位のアクセスと、リクエストとレスポンスのやり取りです。どのクライアントがどのエンドポイントを呼べるかを決め、リクエストのスキーマを検証し、認証を強制し、トラフィックに上限をかけます。この前提には、呼び出す側がすでに目的のエンドポイントを知っているという想定があり、API Gatewayの仕事はその呼び出しを許可するか拒否するかだけです。

最初のギャップは発見の場面で生まれます。API Gatewayは、利用者にどのエンドポイントを見せてよいかを判断する必要がありません。クライアントはすでに行き先を知って接続してくるからです。エージェントはそうではありません。エージェントは利用可能なツールの一覧を受け取り、その中からどれを呼ぶかを自分で判断します。つまりツールの発見自体がガバナンス上の意思決定になるということです。発見レイヤーで統制がなければ、エージェントはユーザーが本来触れる権限を持たないツールまで見つけ出し、呼び出せてしまいます。

第二のギャップはワークフローの場面で生まれます。API Gatewayはリクエストを許可するか拒否するかを決めたら、そこで役目を終えます。MCPが持ち込むのは、途中で止めて再開する仕組みです。エージェントをワークフローの途中で一時停止させ、人間の承認者に回し、承認が下りれば再開する流れになります。従来型のAPI Gatewayにはこれに相当する仕組みがありません。もともと想定していたトラフィックが、途中で許可を求めて止まることを前提としていないからです。

ここで押さえておきたいのは、MCP Gatewayの導入が既存のAPI Gatewayを置き換える話ではないという点です。外部クライアントからサービスへ向かう南北方向のトラフィックは、これまでどおりAPI Gatewayが統制します。そのうえで、AIエージェントがツールを呼び出すMCPトラフィックだけをMCP Gatewayに切り出す、という共存構成が一般的です。既存の投資を捨てるのではなく、統制の空白地帯だけを埋める形になります。

両者の守備範囲を機能ごとに並べると、次のようになります。

エージェント層のツール検出とポリシー適用は？

この発見の問題は、導入規模が大きくなるほど深刻になります。エージェントが複数のMCPサーバーに接続すると、利用可能なすべてのツールを合算したリストを受け取ることになり、企業規模になるとその数は数百に達することもあります。ここで二つの問題が生じます。ツールの定義が積み重なってモデルのコンテキストウィンドウを圧迫しパフォーマンスを落とすこと、そしてエージェントが本来関わるべきでないツールまで見えてしまうことです。

MCP Gatewayは、全カタログを見せるのではなく、ポリシー、ロール、コンテキストに基づいてエージェントごとに見せるツールを絞り込むことで、この両方を解決します。一部の本番環境では踏み込んで、BM25のようなランキング手法によるセマンティックマッチングを適用し、あるクエリに関連する3〜5個のツールだけを浮かび上がらせています。これによってコンテキストウィンドウを小さく保ちながら、同じ場所でアクセスポリシーを強制できます。

ここからポリシー適用は、エンドポイントより下の階層にまで広がります。MCPでは、ガバナンスがツール全体だけでなく、関数とそのパラメータのレベルで行われます。企業は読み取り専用をデフォルトにし、書き込みはレビュー待ちにし、特定の部署や役割にだけ例外を認める、といった設計ができます。この粒度の細かさはエージェントの挙動と相性がよく、API Gatewayが表現するようには設計されていない領域です。

エージェントが取れる行動が増えるほど、リスクも大きくなります。データベースへの書き込み、ワークフローの起動、ファイルの削除は、多くの企業が人間の承認を必須とする類の操作です。センシティブな呼び出しに対して人間の承認を強制するゲートウェイがなければ、エージェントは意図から実行までの間にチェックポイントのないまま、取り消せない行動を起こしかねません。

ID伝播とエージェント間ルーティングの仕組みは？

本番環境でエージェントが自分自身として動くことはほとんどありません。エージェントは人間のユーザーの代理として動き、そのユーザーのアイデンティティをエージェントが行うすべてのツール呼び出しに引き継ぐのがMCP Gatewayの役目です。バックエンドシステムは、エージェントに専用の恒常的なアクセス権を与えるのではなく、リクエストごとにユーザー単位の権限を強制します。

この点が重要になる理由は、それが欠けた瞬間にはっきりします。CRMへのアクセス権が限られたユーザーの代理で動くエージェントは、ID伝播がなければ、そのユーザーが本来閲覧を許されていないレコードまで照会できてしまいます。この制約をゲートウェイ側で強制すれば、すべてのサーバーで一貫した挙動を保てます。個々のMCPサーバーがそれぞれ同じチェックを正しく再実装することに頼らずに済みます。

第二の能力はルーティングです。API Gatewayには、このレイヤーに相当する機能がありません。企業が単一のMCPサーバーだけで運用することは稀です。MCP Gatewayは、ツールの種類やデータソース、ポリシーに応じて各エージェントのリクエストを正しいバックエンドサーバーへ振り分ける、一つの統一エンドポイントを提供します。個々のサーバーを追加・廃止・更新するたびに、それに依存するすべてのエージェントを再設定する必要はありません。

静かに効いてくるのがスケーリングの計算です。各エージェントが各サーバーへ直接接続すると、その数はエージェント数×サーバー数で増え、このメッシュはあっという間に手に負えなくなるでしょう。ゲートウェイはこれを単一の接続点に集約して管理を一元化し、双方の数が増えてもエージェントのフットプリントを予測可能な範囲に保ちます。

エージェント通信の可観測性と監査は？

エージェントトラフィックの可観測性は、HTTPのログ取得とは異なる種類の計測課題です。ゲートウェイは、ツール呼び出しのレイテンシ、エラー率、呼び出しごとのトークン使用量、コストの帰属、エージェントごとの挙動パターンにわたる構造化テレメトリを出力する必要があります。標準的なリクエスト・レスポンスのログでは、エージェントの挙動を推論できるだけの精度でこれらを捉えられません。

規制業界では監査要件がさらに厳しくなります。コンプライアンス部門には、各エージェントがどのアイデンティティのもとで、どのデータを照会し、どんな操作を行ったのか、その正確な記録が必要です。API Gatewayのログはエンドポイントとレスポンスコードを記録しますが、ツール呼び出しの意味的な中身までは捉えません。これこそが監査担当者の知りたいことです。

レート制限も、より多くの軸で動く必要があります。エージェントトラフィックの場合、エージェントごとのリクエスト数、時間枠あたりのトークン消費量、ツール呼び出しごとのコストなど、複数の軸を同時に扱います。モデル呼び出しのコストはトークン数によって変動するため、API Gatewayが標準とする単一の秒間リクエスト数の上限だけでは、露出しているリスクの大半を見落とします。

この投資が最初に効いてくるのはデバッグの場面です。エージェントが想定外の結果を出したとき、最初に確認すべきはゲートウェイの監査ログです。それが経路全体をカバーする唯一の記録だからです。これがなければ、失敗がモデルのエラーなのか、ツール呼び出しのエラーなのか、データアクセスのエラーなのかを判別できず、すべてのインシデント対応がゼロからのスタートになりかねません。

自社のAPI Gatewayで足りているかどうかは、次の5点を確認すると判断できます。

• エージェントごとに、見せるツールを絞り込めていますか

• ツール呼び出しが、エージェントではなく利用者本人の権限で実行されていますか

• 書き込みや削除といった取り消せない操作に、人間の承認を挟めていますか

• どのエージェントが、誰の権限で、何を呼び出したかを構造化ログで追えますか

• リクエスト数だけでなく、トークン数やコストでも上限をかけられていますか

ひとつでも「いいえ」があれば、MCP Gatewayの追加を検討する段階だと考えてよいでしょう。

CData Connect AI：管理されたMCPプラットフォーム

CData Connect AIは、プラットフォームとして企業のMCP乱立を解決します。MCP Gatewayだけでは企業データにとって不十分な理由については、別記事でも詳しく取り上げました。Connect AIは、サイロ化したMCPサーバー群を一つのインターフェースにまとめるゲートウェイではありません。

Connect AIは、400種類以上の企業データソースに直接接続する単一のMCPプラットフォームであり、認証、ユーザー単位の権限強制、クエリの監査ログ、スキーマを意識したアクセス制御をあらかじめ備えています。多くのチームがゲートウェイに手を伸ばすのは、システムごとに個別のMCPサーバーを立ててしまい、それらを束ねる何かが必要になった段階です。

Connect AIはその必要性自体をなくします。サーバー群が本来つなごうとしていたデータソースに、すでに一つの統制されたインターフェースからアクセスできるからです。多くの企業にとって、Connect AIはゲートウェイを追加で運用する層を増やすのではなく、その必要性を置き換える存在になります。

実際に、AI SaaSとノーコードプラットフォームを提供するテクノロジー企業では、顧客ごとに個別のインテグレーションを作り込む方式が拡大の足かせになっていました。同社はMCPベースの共通インターフェースにアクセス経路を統一し、SAPやOracle、Microsoft ERP、Slackといったシステムへのガバナンスに準拠したアクセスを標準化しています。本番稼働までは2週間で完了し、データ連携にかかる期間は80%以上短縮されました。ゲートウェイをもう一段積むかどうかを考える前に、接続そのものを一本化できないかを検討する価値はあるでしょう。

よくある質問

MCP Gatewayは、本番運用に耐えるMCP導入と、統制の効かないMCP導入を分ける境界線です。そしてその中でも難しいのが、各エージェントがどのデータに触れてよいかを統制する部分です。

MCPのアクセス統制をConnect AIで実現する

API Gatewayではエージェントのツール呼び出しまで統制できません。CData Connect AIなら、400種類以上のデータソースへのアクセスをユーザー単位の権限で管理し、監査ログも標準で記録できます。開発チームとセキュリティチームが、同じ統制の上でMCPを運用できるようになります。

Connect AIの無料トライアルを開始し、AIエージェントに安全な業務データアクセスを提供しましょう。ドキュメントはこちらから確認できます。