MCPゲートウェイの利便性の裏側に、どんな構造的リスクが潜んでいるのか。1年間にわたるMCPセキュリティ調査が明らかにした事実をもとに、本記事ではそのリスクの実像を解説します。なかでも最も明確な事例として注目を集めたSmitheryインシデントを取り上げ、企業チームが本番データへのアクセスを管理型MCPプラットフォームに委ねる前に確認すべき評価ポイントを整理します。

MCPゲートウェイとは、AIエージェントとバックエンドデータシステムの間に配置される単一のエントリーポイントであり、ツール呼び出しの認証・認可・ロギングを一元管理する仕組みです。MCPプロトコル自体はセキュリティを強制しないため、アクセス制御・認証情報管理・操作記録の方法はすべてゲートウェイの実装に委ねられます。CData Connect AIはこのゲートウェイ機能をマネージドSaaS型で提供し、エンタープライズデータへのAIエージェントアクセスを安全に統制します。

1年間のMCPセキュリティインシデントに共通する点とは？

2025年6月、GitGuardianの研究者Gaetan FerryがSmithery.aiのパストラバーサル脆弱性を公表した際、これは単発の出来事として捉えられがちでした。設定ミスによるビルドパラメータの問題、責任ある開示、48時間でのパッチ適用。それで一件落着、と思われました。

しかし、その後の数ヶ月で状況は変わりました。2025年9月、悪意のあるMCPパッケージがパブリックレジストリに初めて登場します。タイポスクワッティング、偽の公式サーバー、依存性インジェクションといった手口です。同月、週1,500回ダウンロードされていた非公式のPostmark MCPサーバーが密かに改ざんされ、send_email関数にBCCフィールドが追加されました。送信されるすべてのメールが、攻撃者のアドレスに静かにコピーされていたのです。エラーはなし。警告もなし。ツールは期待どおりに動作していました――ただ、同時に攻撃者のためにも動いていたというだけで。2025年7月には、トレンドマイクロのスキャンで、認証もトラフィック暗号化も施されていない492のMCPサーバーインスタンスが発見されました。2026年初頭までに、その露出はクラウドにも広がっています。2026年3月に3,000台以上のMCPサーバーを対象に行われた調査では、OAuthを使用しているのはわずか8.5%。残りは静的で長期有効なAPIキーに依存しており、有効期限はなく、スコープ設定も容易でなく、誰かが手動でローテーションするまで有効なままです。AIエージェントに対してOAuthベースのIDモデルを適用する設計思想については、AIエージェントのID管理を簡素化｜OAuth活用術で詳しく解説しています。

Smitheryのインシデントは、最初の警告でした。その後MCPエコシステム全体で繰り返し確認されてきたリスクカテゴリが、初めて明確に記録された事例です。企業チームが問うべきは、MCPセキュリティを真剣に受け止めるかどうかではありません。貴社が構築しようとしているインフラが、そのリスクに対処できる設計になっているかどうかです。

Smitheryで何が起きたか？共有ホスティングモデルのリスクを検証

Smithery.aiは、MCPサーバーのホスティングレジストリです。その仕組みは単純明快です。開発者がMCPサーバーのコードを含むGitHubリポジトリを提出すると、Smitheryがそれをビルドし、fly.io上で稼働する共有インフラ上で生成されたサーバーをホストします。これは、独自のデプロイパイプラインを管理することなく、MCPサーバーを稼働させる便利な方法です。

脆弱性の起点は、各サーバーの smithery.yaml ファイルに含まれるビルド設定パラメータ dockerBuildPath でした。Smitheryはこのパラメータを検証していませんでした。そのため攻撃者は、提出されたリポジトリの外側——具体的にはビルドユーザーのホームフォルダを含む親ディレクトリ——を指すように値を操作し、そこをDockerビルドコンテキストとして利用できました。この細工を施したビルド設定と攻撃者が制御するDockerfileを組み合わせることで、ある研究者はビルドユーザーの .docker/config.json を外部へ持ち出すことに成功しました。このファイルにはfly.ioの認証トークンが含まれていました。

このトークンには過大な権限が付与されていました。Dockerレジストリへのアクセス権にとどまらず、fly.ioのマシンAPI——Smitheryがホストする3,000以上のアプリケーション全体をカバーするもの——を完全に制御できる権限まで含んでいたのです。パッチ適用前にこの脆弱性が悪用されていれば、攻撃者はホストされているどのサーバーでも任意のコードを実行し、クライアントがそれらのサーバー経由で送信していたAPIキーや認証トークンを傍受できた可能性があります。Smitheryは開示から48時間以内に修正を完了しており、修正前の悪意ある悪用が確認されたという証拠はありません。GitGuardianによる当初の開示は詳細にわたっており、直接読む価値があります。彼らが記録した事実はいかなる要約よりも有益であり、適切な帰属表記とともに参照することをお勧めします。

パッチで修正されない構造的リスクとは？

このパッチは特定の脆弱性を解決するものです。しかし、単一の誤設定されたビルドパラメータが、何千ものサーバーおよびその背後にあるエンタープライズシステムの潜在的な侵害につながるという構造的な特性は、依然として変わりません。その特性とは、中央集権的な共有ホスティングモデルであり、この教訓は、単一のオペレーターが管理する共有インフラ上でユーザーが制御するコードを実行するあらゆるプラットフォームに当てはまります。

共有ホスティングモデルでは、事業者のインフラがすべてのテナントの基盤となります。事業者レベルで権限過剰な認証情報が1つでも存在すれば、それは事実上マスターキーです。これは理論上のリスク分類ではなく、サプライチェーン攻撃がこれほど根強く、防御が難しい理由と同じメカニズムです。攻撃者の狙いは特定の1組織ではなく、その組織が依存する信頼された共有プラットフォームそのものです。プラットフォームを一度侵害すれば、下流のすべての利用者へのアクセス権を手にすることになります。GitGuardianはSmitheryのインシデントをSalesloftのOAuthサプライチェーン侵害と明確に比較しており、構造的な類似性は明白です。

MCPサーバーは、この攻撃パターンにおいて特に価値の高い標的です。AIエージェントと業務データシステム——データベース、CRM、ERP、金融プラットフォーム——の間に直接位置するからです。エージェントはSalesforceに直接クエリを送信するのではなく、MCPサーバー上のツールを呼び出し、そのツールがエージェントの代わりに認証してクエリを実行します。MCPサーバーを制御する者が、データへのアクセス経路を握るのです。集中型ホスティング・共有インフラ認証情報・静的な下流認証情報——この三つの組み合わせが、Smitheryシナリオにおける影響範囲をこれほど広大なものにしており、MCPセキュリティインシデントというパターン全体を真剣に受け止めるべき理由でもあります。

企業セキュリティチームにとってより根本的な問いは、特定のプラットフォームが特定の脆弱性に対処しているかどうかではありません。たいていのプラットフォームは、遅かれ早かれ対処します。問うべきは、その基盤となるホスティングモデルが、AIエージェントがアクセスするデータにとって許容できる水準の構造的リスクしか生まないかどうかです。

参考として、MCPエコシステムで確認されている主な攻撃パターンを整理します。これらはいずれも、共有インフラ上でユーザー制御のコードを実行するアーキテクチャで被害規模が拡大しやすい点が共通しています。

• ツールポイズニング：ツール定義のメタデータに悪意ある指示を埋め込み、AIエージェントが通常の呼び出しの中で攻撃コードを実行してしまう手法。

• ラグプル攻撃：セキュリティレビュー通過後にツール定義を密かに変更し、悪意ある動作を追加する。MCPクライアントの多くは承認後の変更をユーザーに通知しない。

• タイポスクワッティング・サプライチェーン汚染：正規パッケージに似た名前の悪意あるMCPサーバーをレジストリに公開し、誤インストールを誘導する。分析済みMCPサーバーのうちコマンドインジェクション脆弱性が43%で確認されている。

• 認証なし公開サーバー：2026年3月の調査ではMCPサーバーの91.5%がOAuthを使用しておらず、静的APIキーが長期間有効なまま運用されている。

真に安全なMCPアーキテクチャに求められる要件は？

管理型MCPプラットフォームを評価する際、最初に問うべきは「このプラットフォームが侵害されたら、実際に何が起きるのか」です。その答えを決めるのは機能リストではなく、アーキテクチャです。具体的には、侵害がどこまで波及するか、どれだけ長く悪用され続けるか、そして発生した際にどれだけ速く気づけるか——この3点です。

この3つの観点が、本番データをMCPプラットフォームに委ねる前に確認すべき構造的特性に対応しています。

影響範囲：1つの侵害がどこまで広がるか？　これは主に認証情報のアーキテクチャによって決まります。プラットフォームが共有インフラ認証情報——複数テナントにまたがるトークン、キー、ビルドコンテキストなど——を使用している場合、1つの脆弱性が悪用されればプラットフォーム上のすべての接続に波及しかねません。Smitheryのインシデントはその最も明確な例です。権限過剰なトークンが1つあるだけで、3,000台以上のサーバーが危険にさらされました。一方、接続ごと・ユーザーごとの認証情報とベンダー管理のコネクタを採用し、ユーザーが管理するビルドパイプラインを持たないプラットフォームであれば、侵害の波及は単一の接続の範囲内に収まります。ただし、ベンダー管理のコネクタはプラットフォームのコネクタロードマップへの依存を生みます。本番AIインフラを構築する多くの企業にとってこれは許容できる制約ですが、採用前に理解しておく価値があります。

悪用可能な期間：脆弱性が露呈した状態はどのくらい続くのか？ 2026年3月の調査でOAuthを使用しているMCPサーバーがわずか8.5%だったのは偶然ではありません。静的APIキーは現在のエコシステムで最も抵抗の少ない選択肢であり、誰かが手動でローテーションするまで有効なままです。サプライチェーン侵害、改ざんされたツール定義、ホスティング環境への侵入——どの経路であれ静的キーを入手した攻撃者には、必要なだけ時間があります。有効期限が短く取り消し可能な認証情報——OAuth 2.0やSSOセッションなど——を使えば、この攻撃の窓は大幅に狭まります。これは特定のプラットフォーム機能の問題というより、そのプラットフォームが実現できる、あるいはデフォルトで採用している「認証情報の管理水準」の問題です。

可視性：侵害をどれだけ迅速に検知し、その影響を封じ込めることができるか？ ユーザーごとのアクセス制御は、サーバーが侵害された後でも攻撃者が到達できる範囲を絞り込みます。データベースをMCP経由でAIに接続する際のガバナンス設計の具体例として、PostgreSQLをChatGPTにセキュア接続！MCPガバナンス完全ガイドが参考になります。ただしこれは、アクセスポリシーが事前にきちんと設計されている場合に限った話です。スコープが雑な接続は、周囲のアーキテクチャがどれほど優れていても実質的な保護になりません。監査ログは、何か問題が起きたことをどれだけ早く把握できるか、そして何が影響を受けたかを左右します。どちらも重要であり、設定しておくだけでなく、能動的に活用することが前提です。

これら3つの視点に照らし合わせ、過去1年間のMCPセキュリティ調査によって具体化された構造的リスクに対し、CData Connect AIのアーキテクチャがどのように対応しているかを以下に示します。

集中型ゲートウェイ対CData Connect AI：何が違うのか？

CData Connect AIは、エンタープライズ向けのマネージドMCPプラットフォームです。機能面の詳細な比較については各種MCPを徹底比較！Connect AIとオープンソースMCPの機能・セキュリティ・コストもあわせてご覧ください。そのアーキテクチャは、Smitheryインシデントが浮き彫りにした構造的リスクに正面から対処します——個別のバグにパッチを当てるのではなく、そもそも影響範囲が最大化するような設計判断を避けることで。なお、CDataのデータ連携製品群はGartner® Magic Quadrant™（2024年・2025年版）に継続的に評価されており、エンタープライズ品質の信頼性が第三者機関によっても認められています。

影響範囲の抑制において、防御はアーキテクチャレベルで組み込まれています。Connect AIはユーザーが提出するビルドパイプラインではなく、ベンダーが管理するコネクタを使用します。ユーザーが制御するコードがCDataの共有インフラ上で実行される仕組みがそもそも存在しないため、dockerBuildPath に相当するものもありません。Smitheryの脆弱性が占めていた攻撃対象領域は、同じ形では存在しないのです。また全ティアにわたって、Connect AIはユーザー定義の認証情報をサポートしています。各ユーザーはプラットフォーム全体で共有される管理者認証情報ではなく、自身のサービス認証情報を使って接続を認証します。ホストされているすべての接続にまたがる共有管理トークンは存在しません。Smitheryインシデントでfly.ioトークンがあれほど甚大な影響をもたらしたのは、まさにこの設計の違いによるものでした。外部Vaultによる一元的な認証情報管理を必要とする組織向けには、BusinessティアでAzure Key Vault統合が利用可能です。認証情報はConnect AI内ではなくVault内に保存・ローテーションされ、読み取りのたびに監査証跡が残ります。なお実用上の注意点として、Key Vault統合は現在「共有認証」方式を採用しているため、ユーザー定義の認証情報モデルとは独立して動作します。ユーザーごとの分離を優先するか、集中管理されたVault制御を優先するかによって、適切な選択は異なります。オンプレミスデータへのアクセスをよりコントロール可能な形で実現したい場合は、Connect AI × Connect Gateway × API Server によるアクセスパターンも設計の参考になります。

悪用可能な期間に関して、Connect AIは各データソースで利用可能な最も安全な認証スキームをサポートするという方針を取ります。データソースがOAuth、SSO、またはそれに準じる短命な認証情報モデルをサポートしていれば、Connect AIはそれを使います。静的APIキーしかサポートしていないデータソースについては、Connect AIがそれより弱い認証情報を持ち込むことはしませんが、データソース側の制約を超えることもできません。プラットフォームがすべてを最低水準に平均化することはなく、各データソースで使える最良の認証方式を尊重します。その結果、悪用可能な期間はデータソースの認証モデルによって決まり、プラットフォーム自体がセキュリティを低下させることはありません。Connect AI自体へのアクセスについては、MCP向けにOAuthとBasic認証の両方に対応しているほか、SAML、OpenID Connect、Microsoft Entra ID、ADFS、LDAP、Ping Federate、OktaによるSSO統合もサポートしています。貴社が他のサービスで既に使用しているIDインフラストラクチャを通じて、Connect AIへのアクセスをそのまま管理できます。

可視性については、Connect AIはクエリログと監査ログの両方を維持し、すべての操作についてタイムスタンプ・クエリテキスト・ユーザーID・ステータスを記録します。セキュリティチームはこれを使って、何が起きたか・どのデータが操作されたかを後から再現できます。アクセス権限はユーザーごと・接続ごとに設定でき、特定の操作（SELECT、INSERT、UPDATE、DELETE、EXECUTE）に絞ることができます。セッションが侵害された場合でも、攻撃者が行えることはそのユーザーに許可された操作の範囲内に収まります。エージェントの動作についてリアルタイムの異常検知やアクティブなアラートが必要な場合は、クエリログと監査ログを既存のSIEMツールに連携させることも可能です。これらすべては、保存データおよび転送中のデータをカバーする多層的なセキュリティモデルのもとで動作し、SOC 2 Type IIおよびISO認証のセキュリティ基準に準拠しています。

以下の表は、文書化された機能に基づいた構造上の違いをまとめたものです：

企業のAIチームはこの調査結果をどう活かすべきか？

共有型MCPゲートウェイサービスを現在利用している場合、過去1年間のMCPセキュリティ調査結果は一つの契機になります。AIエージェントがそのサービスを経由してどんな認証情報を送信しているか、それが静的なAPIキーか短命トークンか、そしてゲートウェイのオペレーターレベルのインフラが侵害された場合の露出範囲を改めて確認してみてください。これらは今や、理論上の懸念ではなく実証されたシナリオです。

本番環境向けにMCPプラットフォームを評価している場合は、コネクタ数や機能リストに加えて、アーキテクチャの分離・認証情報のスコープ設定・ビルドインフラの分離も評価基準に加えるべきです。プラットフォームの成熟度は、接続できるデータソースの数だけで測れるものではありません。インフラのどこかが侵害されたとき何が起きるか——それによって測られます。共有インフラ上でユーザー制御のコードを実行しているかどうかを確認し、認証情報の保存・スコープ設定・ローテーション方法を問い、エージェントの実際の行動についてどれだけの監査可視性があるかを確かめてください。

具体的には、次の優先度別アクションリストを参考に進めることをお勧めします。

• 即座に：既存のMCPサーバーと接続ツールのインベントリを作成し、静的APIキーの一覧と各キーのスコープ設定状況を把握する。

• 30日以内：OAuth/SSO対応の短命トークンへの移行を開始する。CData Connect AIの無料トライアルで、テナント分離型アーキテクチャを実際に検証してみる。

• 90日以内：MCPエージェントのアクティビティログをSIEMに連携させる。ユーザー・接続・操作種別（SELECT/INSERT/DELETE等）の単位で権限ポリシーを設計・適用する。

Connect AIがMCPゲートウェイセキュリティの答えになる理由

CData Connect AIは、ユーザー制御のコードを共有インフラ上で実行しない設計、接続ごと・ユーザーごとの認証情報分離、OAuth/SSOによる短命トークン認証、そしてすべての操作を記録する監査ログにより、Smitheryインシデントが示した構造的リスクをアーキテクチャレベルで対処しています。

外部調達型のソリューションでは、複数部門への全社展開が2週間以内で完了した事例もあり、内製開発と比べて立ち上げコストを大幅に抑えられる点が評価されています。

Connect AIの基本的な接続設定から試してみたい方にはCData Connect ハンズオンが入門として最適です。本番AIインフラのセキュリティ水準を詳しく確認したい場合は、cdata.com/security/ の「Security Kit」をご覧ください。アーキテクチャドキュメント、セキュリティポリシー、コンプライアンス情報（SOC 2 Type II）をまとめています。貴社のMCP環境への適合についてはソリューションアーキテクトがご相談に応じます。詳しくは jp.cdata.com/ai からお問い合わせください。