MCPサーバ91.8%が認証なし｜研究解説

【更新 2026-08-06】本記事を見直し、修正しました。主な修正点：「MCPに特化した公的ガイドラインは見当たらない」という記述を、米国NSAが2026年5月20日にMCPに特化した設計指針（CSI）を公開している事実にもとづき訂正し、出典に追加しました。

インターネットに直接つながったMCP（Model Context Protocol）サーバを実際に検査したところ、動的検査した414台のうち91.8%がOAuth認証を持っていなかったという調査結果が公開されました。2026年7月31日にarXivへ投稿された査読前論文「Exposed by Design」です。

MCPは、生成AIに社内ツールやデータベースを接続するための規格です。開発部門が試験的に立てたMCPサーバが、情シスの知らないところで外部公開されている——本稿はその可能性を、実測データで突きつける内容になっています。

この記事でわかること

  • 公開MCPサーバの実測調査で何が見つかったのか（具体的な数字）
  • なぜ「認証なしで公開される」事態が起きるのか
  • 情シスにとっての実務リスクと、自組織で今すぐ確認すべきこと
  • この研究をどこまで信じてよいか（査読前研究としての限界）

どんな研究なのか

論文はNicolás Padilla氏による単著で、arXiv（cs.CR / cs.AI）に2026年7月31日に投稿されました。査読前のプレプリントであり、第三者による検証を経ていない点は最初に押さえてください。

手法は2段構えです。まず crt.sh（証明書透明性ログ）、GitHub、npm、PyPI、HuggingFace、Smithery など11のデータソースから受動的にMCPサーバの所在を収集し、公開インターネット上で2万1,000超のサーバインスタンスを検出。次に「Corvus」という自作フレームワーク（34の検査モジュール／MCP固有の10の脆弱性クラス）で、2026年7月に4回の測定を実施しています。

「実際に動かして挙動を見た（動的検査）」という点が、これまでのMCPセキュリティ研究との違いです。当メディアでも過去に、実行時の証拠からMCPサーバの脆弱性を検出する研究（MCPサーバの脆弱性を実行証拠で検出｜研究解説）を取り上げましたが、今回は「研究室の中」ではなく「インターネットに実在するサーバ」が対象です。

何がわかったのか

論文が報告している主な数字を整理します。

項目 結果
公開インターネット上で検出されたMCPサーバ 21,000インスタンス超
稼働中と確認された本番サーバ 640台
動的検査を実施したサーバ 414台
報告対象となった脆弱性 68件
OAuth認証を持たないサーバ 検査した414台の91.8%
アクセス制御なしでシェル実行を公開していたツール 687インスタンス
3日以内に消滅したサーバ 確認済みサーバの41.6%

見つかった68件の脆弱性の内訳として挙げられているのは、SQLインジェクション、クラウドのメタデータサービスを狙うSSRF、プロンプトテンプレートインジェクション、カーソル操作によるパストラバーサルです。目新しい攻撃手法ではなく、Webアプリケーションで20年前から知られている古典的な欠陥が、そのままAI連携の入口に出ている構図といえます。

なぜ認証なしで公開されてしまうのか

答えは論文タイトルの「Exposed by Design（設計上、露出している）」に集約されます。MCPはもともと、開発者の手元のPCで標準入出力を介してAIとツールをつなぐ使い方が出発点でした。同じPCの中で完結するなら、認証は不要です。

ところがチームで共有しようとした途端、これをHTTPで外に出すことになります。そのとき「手元では要らなかった認証」が、そのまま省かれる。プロトコル自体の欠陥というより、ローカル前提の道具を、前提を変えずに公開した結果と読むのが妥当でしょう。

論文は、確認済みサーバの41.6%が3日で消えることを「セキュリティレビューを経ない高速な展開サイクル」の表れだと指摘しています。この解釈自体は推測を含みますが、実験用に立てて放置し、思い出したときに消す——という運用実態を想像させる数字ではあります。

情シスにとっての実務リスク

クラウド認証情報が抜かれる（SSRF）

報告された脆弱性のうち、被害範囲が最も大きくなりうるのがクラウドメタデータサービスを狙ったSSRFです。クラウド上のインスタンスは、内部からのみアクセスできる特殊なアドレスで自身のIAM認証情報を取得できます。MCPサーバが外部から指定されたURLを無防備に取得してしまうと、この認証情報が攻撃者に渡ります。

そうなると被害は「AIの回答が汚染される」では済みません。クラウドアカウント側への横展開が現実的な射程に入ります。小さな検証用サーバ1台が、本番環境への足がかりになりうるということです。

アクセス制御なしのシェル実行が687件

これは脆弱性というより、仕様としてリモートコード実行を提供している状態です。MCPは「AIに任せたい操作をツールとして登録する」仕組みなので、コマンド実行ツールを登録すること自体は自然な発想です。しかし認証をかけずに公開すれば、誰でもそのコマンドを叩ける入口になります。

3日で消えるサーバは棚卸しに映らない

情シスにとって、実はこの41.6%という数字が一番やっかいです。四半期に一度の資産棚卸しでは、3日で消えるサーバは構造的に捕捉できません。存在した痕跡だけ残して消え、事故が起きてから「そんなものがあったのか」と知ることになります。従来のシャドーITは少なくともしばらく居座ってくれましたが、AI連携の実験環境はもっと足が速い。

現場目線の所感

正直なところ、この論文を読んで最初に浮かんだのは「自社は大丈夫か」ではなく「自社に立っているかどうかを、そもそも把握できるのか」という不安でした。

MCPサーバを立てるのに、稟議も予算もサーバ調達も要りません。開発者がクラウドの小さなインスタンスかSaaSのホスティングでコマンドを数行叩けば動きます。情シスに相談が来る理由がないのです。悪意も違反意識もなく、ただ便利だから立てられる。そして本人にとっては「ちょっと試しただけ」なので、認証をかける動機も薄い。

禁止令を出しても、この種の「便利な実験」は止まりません。むしろ報告されなくなるぶん見えなくなります。止めるより、立てるなら最低限これは守ってほしいという線を先に示すほうが現実的だと感じます。認証は必須、シェル実行ツールは公開サーバに載せない、外部公開する前に一声かける。この3つくらいなら開発側も飲めるはずです。

関連して、AI連携の入口が攻撃対象になる話は他にもあります。ツール定義そのものに悪意ある命令を仕込む攻撃（MCPを狙う分散型ツール中毒攻撃「ShareLock」とは）や、開発環境の設定ファイルを汚染する手口（AIコーディング補助を狙う「設定汚染」攻撃）とあわせて読むと、面の広さが見えてきます。

情シスは何をすべきか

MCPに特化した公的ガイドラインは、国内では本稿執筆時点で見当たりません。海外では米国NSAのAIセキュリティセンター（AISC）が2026年5月20日に、MCPに特化した設計指針「Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation」を公開しており、シリアライズの扱い・信頼境界・エージェントの悪用といった設計上の課題と、本番環境で採用する組織向けの推奨事項をまとめています。国内資料としては、AI利用に伴うリスクの整理そのものは公的機関の資料が充実しています。まずはこちらを土台にするのが早道です。

  • IPA「AIセキュリティ」 … 「AI利用者のためのセキュリティ豆知識」「AIシステムに対する既知の攻撃と影響」などを公開。社内勉強会の資料としてそのまま使える形式なので、開発部門への啓発に向いています。
  • IPA「情報セキュリティ10大脅威 2026」 … 組織向け第3位に「AIの利用をめぐるサイバーリスク」が初選出されました。経営層に「AI連携の管理が必要」と説明する際の根拠として使いやすい材料です。
  • IPA「中小企業の情報セキュリティ対策ガイドライン」 … 資産の把握と管理という基本に立ち返るための定番資料。今回の「3日で消えるサーバ」問題は、結局のところ資産管理の問題です。

そのうえで、自組織で確認する順序としては「立っているかを知る」→「認証を確認する」→「権限を絞る」になります。まずは自社のグローバルIP帯やクラウド環境で、MCPが使う経路が外部公開されていないかを確認する。次に、公開されているなら認証の有無を確認する。最後に、そのサーバに登録されたツールがどこまでの操作を許しているかを見る、という流れです。技術的な確認は開発部門の協力が要るので、責める調子ではなく「一緒に棚卸ししたい」と持ちかけるのが現実的でしょう。

この研究の限界

実務判断に使う前に、押さえておきたい留保が3つあります。

  • 査読前のプレプリントである。単著であり、第三者の検証を経ていません。数字は今後変わりうるものとして扱ってください。
  • 「OAuthがない」は「認証がない」と同義ではない。論文が測っているのはOAuth認証の有無です。APIキーやネットワークACL、リバースプロキシ側での認証など、別の方法で守られているサーバが91.8%の中に含まれている可能性は残ります。ただし、公開ネットワーク上でそれらが適切に設定されている保証もありません。
  • 検出2万1,000件と本番640台の差は大きい。実際に動的検査したのは414台で、これが公開MCPサーバ全体を代表しているとは限りません。「2万1,000台が無防備」という読み方は誤りです。

とはいえ、414台という実測サンプルで9割超が同じ状態だったという事実は、傾向としては十分に重く受け止めてよいと考えます。

まとめ

  1. インターネット公開されたMCPサーバ414台の実測で、91.8%がOAuth認証を持たず、687のツールがアクセス制御なしでシェル実行を露出していた（査読前研究）。
  2. 脆弱性の中身はSQLインジェクションやSSRFといった古典的な欠陥で、特にクラウドメタデータを狙うSSRFはクラウドアカウントへの横展開につながる。
  3. 情シスにとっての本質的な課題は資産把握。確認済みサーバの41.6%が3日で消えており、通常の棚卸しサイクルでは捕捉できない。禁止より「立てるなら守る線」の提示が現実的。

出典

あわせて読みたい: マルチエージェントAIの盲点｜連結で崩れる安全性

タイトルとURLをコピーしました