社内で利用されているMCPサーバーを可視化・統制する

こんにちは、ひろかずです。

これまで2本のブログで、AIコーディングとAIエージェントを取り巻く環境の守り方を整理してきました。

• 一本目：AIコーディング時代の「セキュリティの民主化」
• 二本目：Langflow脆弱性に学ぶAIエージェント基盤のシークレット統制2026

実はこの2本には、意図的に触れてこなかった「積み残し」があります。それが MCPサーバーの統制 です。

今回はこの積み残しを回収すべく、一筆書きます。

誰向けの記事なの？

「MCPって便利そうだけど、誰が何に繋いでいるのか全然見えない」「棚卸しシートを作ったけど、翌月にはもう実態と合っていない」。そんな課題を抱えている情シスやセキュリティチームの方に向けて、MCPサーバーを 可視化・統制するための現実的な方法論 を整理してみました。今回も、専門家でなくても読み進められるように、用語はその都度かみ砕いて説明していきます。

忙しい人向けの要約

• MCPサーバーはどう可視化・統制すればいい？ 「一覧を作る」のではなく、PCからの接続はCASB/SWG（Netskope）で、IaaS上のワークロードはCWPP（Wiz）で「常に見えている状態」を作り統制するのが現実的です。
• MCPサーバーは誰でも作れて、誰でも手元から繋げます。接続は個人のPCやワークロードの中で完結することが多く、 従来のSaaS統制の仕組みだけでは把握しきれません 。
• 「棚卸し」というアプローチはMCPには機能しません。一覧を作った瞬間から陳腐化が始まり、善し悪しの判定が中央に集まって統制側が疲弊し、新しいMCPサーバーは次々と現れるからです。
• PCからリモートMCPサーバーへの接続は、 Netskope Agentic Brokerで可視化・統制できます。Netskope Client展開済み環境では既存基盤を活用できますが、Agentic Brokerの利用にはアカウントチームへの有効化依頼とAgentic Brokerライセンス（DLPポリシー適用時はDLPアドオン）等の確認が必要です。
• クラウドプラットフォーム上のワークロードがセルフホストしているMCPサーバーや、ワークロードから接続しているリモートMCPサーバーは、 Wiz で可視化と棚卸しを自動化できます。
• 結論は一本目のブログの総括と同じです。AIワークロードは組織が管理するプラットフォームに集約してCWPP（Wiz）で見る。PCからの接続はCASB/SWG（Netskope）で見る。 「一覧を作る」のではなく「常に見えている状態を作り、統制していく」。これが本記事の主張です。

これまでのおさらい……何が積み残されていたの？

一本目のブログでは、AIコーディングが関わる環境を4つのレイヤーに整理しました。

• PC ：手元でAIエージェントを動かす実行環境。
• Repository ：AIコーディングで生成したコードを管理する場所。
• IaaS ：AIエージェントで構成したアプリケーションやワークロードが動く場所。AIエージェントやMCPサーバーがここで動くこともあります。
• SaaS ：ワークロードから見て、日々の業務で蓄積したデータが格納されている場所。

そして「爆発的に普及するAIエージェントの利用は止められないのだから、締め出すのではなく 受け皿を用意する 」という結論を導きました。

ただ、あの図にはMCPサーバーが描かれていながら、本文ではほとんど触れていません。理由はシンプルで、論点が広がりすぎてしまい、その記事で言いたかった結論がぼやけてしまう恐れがあったからです。

二本目のブログでも、対策として「社内外で稼働するAIワークフロー基盤・エージェントを洗い出す」と書きましたが、具体的な方法論までは踏み込めていませんでした。

本記事は、この2つの積み残しに対する回答編です。

なぜMCPサーバーの統制は難しいの？

MCP（Model Context Protocol）そのものの解説は「MCPとは何か 〜AIエージェントの為の標準プロトコル〜」に譲りますが、本記事に必要な分だけおさらいします。MCPは、AIエージェントを社内外のツールやデータに繋ぐ標準プロトコルです。そして接続先であるMCPサーバーは、 誰でも作れて、誰でも公開できます 。

その結果、何が起きているか。

• 有名企業製から個人作の野良サーバーまで、 玉石混交のMCPサーバー がインターネット上に溢れています。
  • 「そのMCPサーバーは安全か危険か」を見極める難しさは「そのMCPサーバーは安全か危険か。信頼性を見極める実務フレームワーク」で詳しく整理したとおりで、ツールポイズニングやRug Pull（承認後のツール記述子すり替え）といった MCP固有の攻撃手法 も体系化され始めています。
  • OWASP MCP Top 10のMCP03:2025 Tool Poisoningでは、tool poisoningのサブ手法としてrug pulls、schema poisoning、tool shadowingが整理されています（同フレームワークは2026年8月時点でbeta段階のため、引用時は最新版を確認してください）。
• 接続は個人のPC上の設定ファイル一つで完結します。MCPの仕様上、HTTPベースのリモートMCPサーバーはOAuth 2.1ベースの認可に対応できますが（認可自体はオプション）、ローカルのstdio型サーバーは仕様上、環境側から資格情報を取得する形が推奨されており、個別発行のAPIトークンを設定ファイルに置いて接続する実装もあります。いずれもSSOやOAuth連携の管理画面には現れにくく、 従来のSaaS統制の枠組みだけでは接続の事実を把握しきれません 。
• IaaS上のワークロードがMCPサーバーをセルフホストしたり、ワークロードやPCからリモートMCPサーバーに接続したりするケースも増えています。こちらは、申告ベースの棚卸しや従来のSaaS統制だけでは 統制側の目に触れにくい領域 です。

つまり、「見えない・止められない・良し悪しも判断できない」の三重苦です。これがMCPサーバー統制の現在地です。

統制の泣き所……棚卸しはなぜ機能しないの？

「まずは棚卸しから始めよう」と考えた方、正しい直感です。ただ、MCPサーバーに関しては、 棚卸しというアプローチそのものが上手くいきません 。理由は3つあります。

1. 一覧は作った瞬間から陳腐化する
   • 接続先の追加は個人の手元で完結します。棚卸しシートを埋めた翌日には、誰かが新しいMCPサーバーに繋いでいます。
2. 判定が中央に集まり、統制側が疲弊する
   • 接続先の善し悪しの判定を申請・審査制にすると、審査依頼が中央のセキュリティチームに集中します。一件ずつ出所・権限・実装を精査していては、件数に追いつけません。これは一本目のブログで指摘した「中央集権的な統制は追いつかない」構図の再演です。
3. 新しいMCPサーバーは次々と現れる
   • 審査が終わった頃には、もっと便利な別のサーバーが登場しています。ユーザーは待ってくれません。待たせれば、統制の外で勝手に繋ぐシャドーITに流れるだけです。

この構図、どこかで見覚えがありませんか。そう、 かつてのSaaS利用の統制とまったく同じ です。SaaSの利用申請を紙で審査していた時代は続きませんでした。CASBが登場し、「実際に使われているものを常時可視化し、リスクスコアに基づいてポリシーで制御する」方式に置き換わったのです。

MCPサーバーにも、同じ転換が必要です。 「一覧を作る」から「常に見えている状態を作り、統制できるようにする」への転換 です。

解決の糸口1……PCからの接続は CASB/SWG で見る

まずはPCのレイヤーです。手元のAIエージェント（Claude CodeやVS Codeなど）からリモートMCPサーバーへの接続には、CASB/SWG機能を有するNetskopeの Agentic Broker（正式名称はNetskope One Agentic Broker）が有力な受け皿になります。

Agentic Brokerは、暗号通信を復号し、MCPサーバーへのトラフィックを識別 します。どのPCがどのエージェントを用いて、どのMCPサーバーに、どんなツールリクエストを投げたのかという、これまで見えなかった非人間のトラフィックが、ログに記録されます。

特筆すべきは導入の軽さです。 Netskope Clientが既に展開されていれば、既存基盤を活用して事前定義の可視化テンプレート（Advanced Analytics上のAgentic Brokerダッシュボード）による可視化を進められます。ただしAgentic Brokerの利用には、対象のリモートMCP通信がNetskope Clientのステアリング設定でNetskopeへ送られていることに加え、アカウントチームへの有効化依頼とAgentic Brokerライセンスが必要で、DLPポリシーを適用する場合はDLPアドオンライセンスも要ります。また、MCP向けのリアルタイム保護ポリシーはSSL復号の対象となっている通信にのみ適用されます。

可視化のイメージ

可視化と統制は、それぞれ次のように対応します。

この構成の何が嬉しいかというと、 善し悪しの判定を中央のチームが一件ずつ捌かなくてよくなる という点です。SaaSのリスク評価でお馴染みのCCIがMCPサーバーにも拡張されているので、「信頼度スコアが一定以上のMCPサーバーのみ許可する」というポリシーを一度組んでしまえば、カタログに登録されたMCPサーバーについては、新しいものが現れても評価と統制が回り続けます。カタログ外のリモートMCPサーバーは、MCPトラフィック全体（現行UIではAgentic Accessポリシータイプの「Any MCP Server Traffic」）を既定でブロックしたうえで、Destination ProfileによるURL個別指定で制御します（Destinationオプションは既定で無効のため、Supportへ有効化を依頼します）。棚卸しの泣き所だった「継続性」が、ここである程度解決できます。

解決の糸口2……IaaS上のMCPサーバーはCWPPで棚卸しする

次はIaaSのレイヤーです。クラウドプラットフォーム上には、2種類のMCPサーバーが存在します。

• ワークロードが セルフホストしているMCPサーバー
• ワークロードから 接続しているリモートMCPサーバー

どちらもNetskope Clientを入れたPCからの通信には当たらず、Netskopeのプロキシへステアリングされない限り観測できないため、本記事ではAgentic Brokerの対象外として扱います（ワークロード通信をNetskopeへ向ける構成の可否はアカウントチームへ確認が必要です）。本記事では、 一本目のブログで紹介した Wiz で可視化と棚卸しを自動化するアプローチを紹介します。

ポイントは、これが 申告ベースではなく実態ベース だということです。Runtime Sensorはワークロード上で実際に発生したDNSクエリを見ているので、Sensorを導入したワークロードの観測範囲では「開発者が申告し忘れた接続」も申告に依存せず検出できます（Sensor未導入のワークロードや観測対象外の経路による接続はカバーされない点にはご注意ください）。Wiz AI-SPMのMCP discoveryも同様で、「いつの間にか誰かが立てていたMCPサーバー」が、ワークロードの脆弱性や露出の情報とともに一覧化されます。

二本目のブログで「社内外で稼働するAIワークフロー基盤・エージェントを洗い出す」と書いたときに欠けていた具体的な方法論がこれです。人が思い出しながらシートを埋めるのではなく、 スキャン機構に洗い出させる方式であれば、観測範囲の中で一覧が更新され続け、手作業よりはるかに陳腐化しにくくなります。

ここまでの話をまとめると、こうなります。

一本目のブログで総括したとおり、 AIのワークロードは組織が管理するプラットフォームに集約して、WizのようなCWPP製品で包括的に監査する 。そして PCからリモートMCPサーバーへの接続は、通信を統制するCASB/SWGであるNetskopeで可視化・制御する 。これは、二本目のブログで示した方法論の実装形でもあります。

MCPサーバーの普及は、AIコーディングと同じく、もう止められません。締め出せばシャドーITに流れるだけです。だからこそ、棚卸しシートと審査フローで水際を守ろうとするのではなく、 接続の実態が常に見えていて、ポリシーが自動で効き続ける受け皿 を先に用意しておく。それが、MCP時代の現実的な構えだと考えています。

よくある質問（FAQ）

• Q. MCPサーバーの棚卸しそのものが不要になるのですか？
  • A. 不要になるのは「人が思い出しながらシートを埋める棚卸し」です。Netskope Agentic BrokerのダッシュボードやWiz AI-SPMのMCP discoveryが接続と配置の実態を継続的に収集するので、一覧はその出力として手に入ります。
• Q. Netskope Agentic Brokerを使い始めるには何が必要ですか？
  • A. Netskope Clientが展開済みで、対象のリモートMCP通信がNetskopeへステアリングされていることに加え、アカウントチームへの有効化依頼とAgentic Brokerライセンスが必要です。DLPポリシーを適用するにはDLPアドオンライセンスも必要で、MCP向けのリアルタイム保護ポリシーはSSL復号の対象になっている通信にのみ効きます。
• Q. PCの中で動くローカルMCPサーバーは見えないままですか？
  • A. Agentic Brokerが扱うのはPCからリモートMCPサーバーへの通信ですが、Netskope ClientのAI Discovery（2026年8月時点でBeta、Windows/macOS対応）がエンドポイントを周期スキャンし、Netskopeが管理するAIシグネチャに登録済みのローカルMCPサーバーやAIエージェント、IDEやブラウザのAI拡張を棚卸しする機能を提供しはじめています（Windows 64-bit／macOS、Netskope Client 137.1以上。シグネチャ未登録の資産は検出されません）。これは資産の棚卸しであって、stdio経由のツール呼び出しをリアルタイムに統制する機能ではありません。
• Q. IaaS上のMCPサーバーは、WizとNetskopeのどちらで見るべきですか？
  • A. ワークロードにRuntime Sensor（Wiz Defendのアドオン）を入れられるなら、Wizによる非インラインのDNS観測が使えます（Sensor未導入の経路は対象外で、導入負荷は環境に依存します）。IaaS内で閉じたワークロード間のMCP通信をインラインで制御したい場合は、Netskope AI Gateway（MCP Gateway）を仮想アプライアンスとして配置し、エージェント側の接続先をGatewayへ向けます。

おわりに

本記事では、統制がむずかしいMCPサーバーについて、PCからリモートMCPサーバーへの接続はNetskope Agentic Brokerで「見えて統制できる状態」を、IaaS上のMCPサーバーとワークロードからの接続はWizで「常に見えている状態」を作る、という役割分担の方法論を紹介しました。PC内で完結するローカル（stdio型）MCPサーバーの棚卸しは、Netskope ClientのAI Discovery（Beta）のような周期スキャンが補う領域で、通信そのものの統制とは別物です。

この記事が誰かのお役に立てば嬉しいです。

用語集

• MCP（Model Context Protocol）：AIエージェントを社内外のツールやデータに繋ぐための標準プロトコルです。その接続先をMCPサーバーと呼びます。
• CASB/SWG：クラウドサービスやWebへの通信を仲介し、可視化・制御するセキュリティ製品群です。Netskopeが代表格です。
• CWPP：クラウド上のワークロード（VM・コンテナ・サーバーレス）を保護する製品群です。Wizが代表格です。
• CCI（Cloud Confidence Index）：Netskopeによるクラウドサービスのリスクスコアです。MCPサーバーにも拡張されており、能力、ツールの操作特性（読み取り専用か更新や削除が可能か）、認証方式などから信頼度をスコア化します。スコアに応じてPoor〜Excellentの5段階のCCL（Cloud Confidence Level）に分類され、CCLはポリシー条件として利用できます。
• リモートMCPサーバー／ローカルMCPサーバー：リモートMCPサーバーは主にStreamable HTTPでネットワーク越しに接続するMCPサーバー、ローカルMCPサーバーは典型的にはクライアントが子プロセスとして起動し標準入出力（stdio）で接続するMCPサーバーです。MCP仕様では、HTTPベースの接続向けにOAuth 2.1ベースの認可（採用はオプション）が定義され、stdio型は環境側から資格情報を取得する形が推奨されています。
• Wiz Runtime Sensor：ワークロード上で動作する軽量センサーです。プロセスや通信（DNSクエリを含む）をリアルタイムに観測します。Linux／Kubernetes向けはeBPFベースで、AWS Fargate／Azure Container Apps向けはptrace、Windows向けはWindows security APIを使う別実装です。
• シャドーIT／シャドーAI：組織の管理の外で勝手に使われるITやAIのことです。締め付けの強すぎる統制が生む副作用として現れます。