Model Context Protocol（MCP）は、大規模言語モデル（LLM）が構造化された宣言的なリクエストを通じて外部サービスと対話できるようにするための標準として台頭しています。MCPは、顧客レコードの取得やワークフローの開始など、エージェントが何をしたいかを記述するための一貫した方法を提供します。バックエンドの実装の詳細に強く依存する必要はありません。

このプロトコルはLLMが外部システムと対話する方法を定義していますが、それらのシステムがどのように公開され、統制され、セキュリティ保護されるかについては規定していません。ほとんどの実装には、MCPに準拠した形式でサービスを公開するMCPサーバーと、複数のサーバーにわたるエージェントリクエストのルーティングと管理を支援するMCPゲートウェイが含まれています。

組織がMCPを採用するにつれ、信頼と制御に関する課題に直面するケースが増えています。最近のCyberPressの報告では、不適切に保護されたMCPサーバーが、特に公開されている場合、不正なエージェントに悪用される可能性があることが明らかにされました。これらのリスクはプロトコル自体に起因するものではなく、すべてのMCPサーバーがデフォルトで安全に信頼できるという前提から生じています。

重要な教訓は、MCPが安全でないということではなく、MCPに準拠したサーバーをデフォルトで安全と見なすことが、実際のリスクを生み出す可能性があるということです。

MCPゲートウェイが存在する理由—そしてその限界

複雑さを管理するために、多くの組織は複数のMCPサーバー間でのアクセスを一元化する方法としてMCPゲートウェイを実装しています。これらのゲートウェイは一般的に以下の機能を提供します：

• エージェントに対して単一のエンドポイントを提供する

• 分散したMCPサーバーにリクエストをルーティングする

• 基本的なアクセス制御とレート制限を実施する

• サービスディスカバリーまたはメタデータルックアップを提供する

この構造は理論的には有用です。複数のバックエンドを抽象化し、AIエージェントにシンプルで統合されたインターフェースを提供します。

しかし実際には、ほとんどのMCPゲートウェイは根本的な問題に対処していません：

• 各基盤となるMCPサーバーが適切にセキュリティ保護され、統制され、維持されていることを前提としています。

• データアクセス、ポリシーの実施、セマンティックの忠実性ではなく、サービスオーケストレーションを問題として扱います。

• 組織は引き続き、異なるバックエンドシステムに接続する数十の個別のMCPサーバーを構築、デプロイ、維持する必要があります。

SupergatewayやMintMCPなどのオープンフレームワークは、独立してデプロイされたMCPサーバー間のルーティングに価値があり、LLM間の連携などの機能をサポートするものもあります。CData Connect AIはそのクラスのルーティングインフラを置き換えることを目指していません。代わりに、単一の管理されたMCPインターフェースを通じて、幅広いエンタープライズデータソース全体でクエリルーティングとセマンティックアクセスを提供します。エンタープライズデータへの統制されたアクセスに注力する組織にとって、Connect AIはMCPスタックの異なる、しばしばより基本的なレイヤーに対応しています。

ゲートウェイはリクエストをルーティングできます。しかし、その背後にある問題を修正することはできません。

独自のMCPスタックを構築・管理する際の隠れたコスト

多くのチームは、ナレッジベースをクエリするエージェント、APIを呼び出すスクリプト、SaaSプラットフォームへのプロトタイプインターフェースなど、いくつかのシンプルなサービスからMCPの取り組みを始めます。しかし、これを実際の本番環境にスケールアップするためには、ゲートウェイの背後にあるすべてを構築し、セキュリティ保護する必要があります。

それには以下が含まれます：

• 公開したいすべてのシステム（CRM、ERP、HRIS、データウェアハウスなど）のMCPサーバー

• すべてのリクエストに対する認証、認可、および監査ログ

• エージェントがオブジェクトの関係やフィールドのセマンティクスを理解するためのメタデータモデリング

• ワークフローとセッション全体のコンテキスト追跡

• 監視、負荷分散、フェイルオーバーを備えた高可用性インフラ

エージェント、ユースケース、データシステムの数が増えるにつれて、ミスが生じる可能性のある領域も拡大します。設定を誤ったサーバーが1つあるだけで、機密データが漏洩したり、意図しないアクションが許可されたりする可能性があります。

さらに悪いことに、ほとんどのオープンソースMCPサーバーは最初からセキュリティが強化されているわけではありません。これらは信頼できるネットワーク、協調的なエージェント、プロトタイプのシナリオを前提としており、敵対的な環境やコンプライアンス監査を想定していません。

実際に発生しているMCPゲートウェイのセキュリティリスク

セキュリティ研究者とプラットフォームチームは、実際のMCPスタックで深刻な脆弱性をすでに発見しています：

• 認証制御なしでデプロイされたオープンなMCPサーバー

• サービス間で再利用される静的トークンと長期間有効な認証情報

• エージェントコンテキスト間の分離の欠如

• 外部サーバーへの接続にユーザーが送信したURLを使用するゲートウェイツール（ID検証なし）

これらの問題は、技術的リスクとサプライチェーンリスクの両方をもたらします。ゲートウェイの背後にある悪意のある、または侵害されたMCPサーバーは、データやインフラへのバックドアとして機能する可能性があります。適切なガバナンスがなければ、どのエージェントがいつ、どのようなポリシーの下で何にアクセスしたかを追跡することが困難になります。

エンタープライズはそのような露出を許容できません。

エンタープライズAIが本当に必要とするもの：セキュアで統制されたMCPプラットフォーム

MCPを安全に採用するために、エンタープライズは単なるルーティング以上のものを必要としています。スケールに対応し、本番環境向けに堅牢化され、設計によって統制されたインフラが必要です。

それは以下を意味します：

• オプションのセーフガードではなく、セキュアなデフォルト

• 誰がどのような条件下で何にアクセスできるかに対する一元化されたガバナンス

• エージェントがソースシステムを正確に解釈できるセマンティックの忠実性

• エッジだけでなく、アクセスレイヤーでのポリシー実施

• すべてのインタラクションの監査証跡

また、すべてのサーバー、接続、コンテキストマネージャーを社内で構築・維持する負担を取り除くことも意味します。

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

CData Connect AIはまさにこの目的のために構築されました：場当たり的なMCPスタックを、完全に管理されたセキュアバイデフォルトのMCPプラットフォームに置き換えることです。

それは両方として機能します：

• MCPゲートウェイとして：サービス全体のリクエストをルーティング、統制、管理する

• MCPサーバーレイヤーとして：セマンティックインテリジェンスと完全忠実度のアクセスでエンタープライズシステムをLLMエージェントに公開する

主なプラットフォーム機能

• 350以上のエンタープライズシステムへのライブで統制されたアクセス：Salesforce、SAP、Snowflake、NetSuite、WorkdayなどのシステムへのプリビルドコネクターをMCPに準拠したエンドポイントとして提供。

• セキュアバイデフォルトのIDおよびアクセス制御：強制認証、ロールベースアクセス、行・フィールドレベルのポリシーサポート、継続的な監視。

• 完全なメタデータモデリング：エージェントはオブジェクト、フィールド、リレーションシップ、カスタムスキーマへの構造化されたアクセスを取得できます。プロンプトエンジニアリングのハックは不要です。

• 管理するインフラは不要：CDataがプラットフォームをホストします。スケーラビリティ、アップグレード、パッチ適用、認証情報のローテーション、および可観測性を処理します。

• 実際のエンタープライズニーズのために構築：デモだけではありません。単なるツールルーティングでもありません。Connect AIはすべてのリクエストに本番グレードのセマンティクス、セキュリティ、コンプライアンスをもたらします。

AIスタックをセキュアなインフラに委ねる

MCPの約束は現実です：ツールとデータへのモジュラーでエージェントベースのアクセス。しかし、実装を誤るコストは高すぎます。特に、実際のデータ、ユーザー、決定が関わっている場合はなおさらです。

ほとんどのMCPゲートウェイは、その背後にある最も弱いサーバーと同程度の強度しかありません。セキュアなプラットフォームがなければ、エージェント、トークン、サービス、ログの分散したパッチワークを管理することになります。

CData Connect AIは必要なコントロールを提供します。エンタープライズ全体でMCPを採用する最速、最安全、最も統制された方法です。

今すぐ無料トライアルを開始して、AIエージェントをエンタープライズデータ環境に安全に導入しましょう。

※本記事はCData US ブログEnterprise AI Needs More than MCP Gatewaysの翻訳です。