結論：PoCで立てたMCPサーバーは「外から見えていないか」を今日確認する

AIエージェントと社内システムを繋ぐ標準プロトコルMCP（Model Context Protocol）のサーバーが、インターネットから誰でも到達できる状態で12,520台確認された。Censysが2026年4月28日時点のスキャンで特定したもので、5月6日時点の追補では2万台超に増えている。さらに別の学術測定研究では、遠隔MCPサーバーの40.55%が認証なしでツールを公開していた。米国家安全保障局（NSA）は5月20日、MCPのセキュリティ設計指針を公表し、導入の速度に安全対策が追いついていないと警告している。

深刻なのは台数ではなく中身だ。Censysの分析では、露出したサーバーのうち687台がコマンド実行・シェル相当の操作を、1,056台がデータベースへの直接クエリを外部に開いていた。MCPはプロトコル仕様として認証を必須にしておらず、開発者がPoC（概念実証）で立てたサーバーが、認証なし・既定設定のまま公開されるケースが構造的に起きている。

「うちのMCPサーバー、認証はありますか。外から見えていませんか」——情シス・開発部門に今日できる質問はこれだ。

押さえるべき1点：MCPは既定では認証を要求しない。「立てれば動く」手軽さの裏で、社内データへの入口が認証なしでインターネットに開く。PoC段階のサーバーこそ棚卸しの最優先対象である。

何がどれだけ露出しているのか

調査・文書主な内容
Censys調査（2026年5月27日公表）12,520台のMCPサービスが8,758のIPで露出（4月28日時点）。5月6日時点で2万台超。米国39.7%、AWS系ASで22.4%
同・高リスク内訳コマンド実行・シェル系687台／DB直接クエリ系1,056台／攻撃ツール搭載31台
学術測定研究（arXiv、2026年5月）遠隔MCPサーバー7,973台を測定し40.55%が認証なし。OAuth実装の欠陥から9件のCVEを取得。検証可能な119台すべてに少なくとも1つの認証系欠陥
NSA設計指針（2026年5月20日）「Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation」を公表。最小権限・検証・分離・監視を要求

数字の出所は分けて読む必要がある。「12,520台」はCensysのインターネット全域スキャン、「約4割が認証なし」は別チームによる測定研究の数字だ。ただし両者の結論は一致している。MCPサーバーの相当数が、認証という最初の関門なしに外部へ開いている。

しかも認証を実装していれば安全とも言えない。測定研究では、OAuth対応サーバーのうち検証できた119台のすべてに認証系の欠陥が見つかり、動的クライアント登録（DCR）に関する欠陥は96.6%に及んだ。「認証あり」のチェックボックスを埋めるだけでは足りない。

なぜ自社事か：PoCの「とりあえず動いた」がそのまま本番になる

MCPは2024年末の登場から1年半で、AIエージェント連携の事実上の標準になった。社内文書検索、SaaS連携、データベース照会——AIエージェントに「手足」を生やす場面では、ほぼ必ずMCPサーバーが立つ。当社でもMCPで社内システムをAIエージェントに繋ぐ際の発注の考え方を解説してきたが、本記事の論点はその先にある。作り方ではなく、立てた後の露出・認証・運用だ。

危険な経路は典型的にこうなる。

  1. 開発者がクラウド上のVMでMCPサーバーをPoCとして起動する（既定で認証なし）
  2. 「社内から使えればいい」つもりが、ファイアウォール設定の漏れや0.0.0.0バインドで全世界に開く
  3. PoCが好評で、そのままの構成で利用が広がる。棚卸し台帳には載っていない
  4. スキャナーに発見される。コマンド実行系ツールを持つサーバーなら、そこが侵入口になる

NSAの指針が名指しする リスクも同じ構造だ。制御されない自動アクション、入力検証の欠如、認証・アクセス管理の弱さ、サービス拒否攻撃への脆弱さ。NSAは対策として、最小権限の付与、機微データを扱うツールのローカル実行、事前定義ルールによる入力スクリーニング、信頼レベルによるシステム分離、既存セキュリティ基盤と統合した詳細ログを挙げ、自動化されたアクションは高リスク操作として厳格な権限境界に閉じ込めるべきだとしている。

AI基盤そのものが攻撃対象になる流れは今週すでに現実化している。LLMゲートウェイLiteLLMの脆弱性がCISAの悪用確認カタログに登録された件はこちらの記事で解説したとおりで、露出したMCPサーバーはその次の標的と見るべきだ。

MCPサーバー公開前点検チェックリスト（7項目）

自社にMCPサーバーが1台でもあるなら、公開・継続利用の前に次の7項目を点検する。

  1. 台帳化：社内に存在するMCPサーバーをすべて列挙したか。PoC・個人検証・部門導入を含め、誰が・どこで・何のツールを持つサーバーを動かしているかを台帳にする
  2. 露出確認：各サーバーがインターネットから到達可能かを外側から確認したか。クラウドのセキュリティグループ、バインドアドレス、リバースプロキシ設定を点検する
  3. 認証の有無：認証なしで動いているサーバーはないか。最低限トークン認証、原則としてOAuth等の標準的な認可を必須化する
  4. 認証実装の検証：OAuthを使う場合、動的クライアント登録の扱い・リダイレクトURI検証など実装の正しさを確認したか（「認証あり」の96.6%に欠陥が出た領域）
  5. 最小権限：ツールが持つ権限は業務に必要な最小限か。コマンド実行・DB書き込み系ツールは本当に必要か再考する
  6. 分離：外部公開系と機微データ系のMCPサーバーを同居させていないか。信頼レベルでネットワークを分ける
  7. ログと監視：MCP経由の操作が監査ログに残り、SIEM等の既存監視に流れているか

チェックの勘所：最初の2項目（台帳化・露出確認）だけでも今日やる価値がある。Censysに見えているものは攻撃者にも見えている。「うちにMCPサーバーはあるか」に即答できない状態が、最も危険な状態だ。

よくある質問（FAQ）

Q. 社内ネットワークからしか使っていなければ安全か？ A. 露出の観点ではリスクは大きく下がるが、安全とは言い切れない。社内利用でも、認証なしのMCPサーバーは内部の誰でも・どの端末からでも操作できる。マルウェアに感染した端末が踏み台になれば、社内限定のはずのコマンド実行ツールが攻撃者の手足になる。最小権限・認証・ログの3点は社内利用でも省略すべきでない。

Q. PoC段階でもそこまでやる必要があるのか？ A. 少なくとも「外部露出させない」「コマンド実行・本番データ接続を持たせない」の2点は必須だ。PoCの構成がそのまま本番化するのは今回の露出12,520台が示す典型パターンであり、PoC開始時点でNSA指針の最小セット（認証・最小権限・分離）を入れておく方が、後から直すより安い。

Q. ベンダーに開発を委託している場合、何を確認すべきか？ A. ①MCPサーバーの設置場所と外部到達性、②認証方式と実装の検証結果、③ツールごとの権限一覧、④監査ログの出力先、の4点を書面で求めるとよい。AIエージェント導入前チェックリスト（MCP・外部ツール接続のガバナンス）に発注側の確認観点をまとめている。

社内で今日確認する実務チェック

この記事のテーマを自社に当てはめるときは、次の順で確認する。第一に、対象製品・対象バージョン・対象サービスが資産台帳に載っているか。第二に、インターネットや不要な社内セグメントから到達できないか。第三に、更新・緩和・監視の担当者と期限が明確か。第四に、委託先やクラウド運用先が関係する場合、回答を口頭ではなくチケットやメールで記録しているか。第五に、対応後にバージョン・設定・ログで完了を確認したかである。

脆弱性対応で最も危険なのは、「使っているか分からない」「担当が分からない」「ベンダーに任せているはず」という状態だ。今回の記事を読んだ時点で対象有無を即答できないなら、それ自体が改善テーマである。個別のパッチ適用だけでなく、資産台帳、脆弱性通知の受信経路、緊急対応の承認権限まで点検したい。

GXOへ相談する前に整理しておくと早い情報

相談前には、対象製品名、バージョン、設置場所、外部公開の有無、管理者、保守契約、更新可能な時間帯、過去の障害履歴を分かる範囲でまとめる。すべて揃っていなくてもよいが、「分からない項目」が多いほど、最初の支援はパッチ作業ではなく棚卸しと露出確認から始めるべきである。

30日で整える脆弱性対応ロードマップ

初日から3日目までは、対象有無の確認と暫定緩和に集中する。資産台帳、EDR/MDM、クラウド管理画面、保守ベンダーへの照会を使って、対象製品がどこにあるかを洗い出す。対象が見つかった場合は、外部公開の停止、アクセス制限、管理画面のIP制限、監視強化など、更新前にできる緩和策を先に入れる。

4日目から10日目までは、更新・設定変更・影響確認を進める。業務影響が大きい製品では、検証環境で更新手順を確認し、失敗時の切り戻し手順を用意する。更新後はバージョン表示だけでなく、実際に脆弱な経路が閉じているか、ログに不審なアクセスが残っていないかを確認する。

11日目から30日目までは、再発防止に使う。通知を誰が受けるか、KEVやJPCERT/CCなどの情報をどう優先度付けするか、休日・夜間の緊急判断を誰が承認するかを決める。今回のような高リスク通知に対して、次回は「対象有無を24時間以内に答えられる」状態を目標にする。

いつGXOに相談すべきか

  • AIエージェントやMCPのPoCを進めているが、露出・認証・権限の点検を自社でやり切る体制がない
  • 生成AI活用を全社展開する前に、MCPを含むAI基盤全体のセキュリティ設計を第三者の目で確認したい
  • ベンダー構築のMCP連携について、NSA指針相当の水準を満たしているか評価したい

GXOは生成AIセキュリティでMCP・AIエージェント基盤の露出評価と設計レビューを、AIエージェント開発で認証・最小権限を織り込んだセキュアな連携構築を提供している。→ MCP・AI基盤セキュリティの相談はこちら

関連記事

編集部注：公開後の更新方針

本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。

読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。

参考資料

本記事は2026年6月12日時点の公開情報をもとに作成。露出台数はスキャン時点（2026年4月28日・5月6日）の値であり変動する。NSA指針の詳細推奨事項は一次PDFの最新版を必ず確認すること。

「うちのMCPサーバー、認証ありますか？」に即答できますか

MCP・AIエージェント基盤の台帳化、外部露出の評価、認証・権限設計のレビューまで、NSA指針を踏まえた点検を支援します。PoC段階での設計相談にも対応します。

MCPセキュリティ点検の無料相談を予約する

※ 営業電話はしません | オンライン対応可 | PoC段階の相談歓迎