Cloudflare Gateway が MCP トラフィックを検出 — シャドー MCP の可視化と Portal 経由の強制

要約

2026-08-14、Cloudflare が Cloudflare One に MCP（Model Context Protocol）トラフィックを検出して統制するための機能群を追加しました。狙いは明確で、組織内で誰がどの MCP サーバーへ接続しているかを可視化し、承認済みサーバーだけを通す運用へ寄せることです。

背景にあるのは「シャドー MCP」の問題です。MCP はエージェントに外部ツールを接続する標準として急速に普及しましたが、接続はエンジニア個人の手元で完結します。情シスから見ると、社内の誰がどの MCP サーバーに何を渡しているのかが分からない状態が生まれていました。SaaS のシャドー IT と同じ構図が、より粒度の細かいところで再発しています。

検出はプロトコルレベルのヒューリスティックで行います。MCP 仕様 2025-11-25 以降で必須となった MCP-Protocol-Version ヘッダを主な手がかりとし、2026-07-28 のステートレスプロトコルで導入された Mcp-Method と Mcp-Name から操作内容とツール名を取得します。ここで公式が明記している制約が重要です。ヘッダの存在は MCP である強い根拠になるが、非存在は MCP でないことの証明にはならない。つまり検出は完全ではなく、すり抜けを前提にした設計が必要になります。

追加された要素は4点です。Gateway ポリシーで使える experimental.is_mcp == true セレクタ、組織内の MCP 利用状況を俯瞰するダッシュボード、Portal 経由（mcp_portal）と直接接続を区別する Traffic Source セレクタ、そして MCP Portals での手動 OAuth 認証情報の設定です。最後の一つは、動的クライアント登録に対応しない MCP サーバーも Portal に載せられるようにするもので、地味ですが対応範囲を広げます。

公式が示す運用手順は 可視化 → 突き合わせ → Portal 化 → 強制の順です。いきなり遮断するのではなく、まず観察してから承認リストを作れ、という段取りになっています。

何が変わったか

• Gateway の Network / HTTP ポリシーで experimental.is_mcp == true を条件に使えるようになった
• MCP トラフィックダッシュボードが追加され、MCP を提供しているホスト、発生させているユーザー、Portal を迂回しているリクエストを確認できる。任意期間で総リクエスト数・ユニークユーザー数・ユニークサーバー数を表示する
• Traffic Source セレクタで、Portal 経由のリクエスト（mcp_portal）と直接接続を区別してポリシーを書ける
• MCP Portals で、事前登録済み OAuth クライアントの認証情報を管理者が手動設定できるようになった。ダッシュボード表示のコールバック URL を上流プロバイダーへ登録して使う
• 検出は MCP-Protocol-Version ヘッダを主な手がかりとし、Mcp-Method / Mcp-Name から操作とツール名を取得する
• 公式は「ヘッダの非存在は MCP でないことの証明にはならない」と制約を明記している

業務インパクト（一般企業向け）

エージェント利用の統制について、初めて実行可能な打ち手が出てきたという位置づけの更新です。

これまで多くの組織で、MCP に関する統制はドキュメント上のルールに留まっていました。「承認していない MCP サーバーに接続しないこと」と書いても、守られているかを確認する手段がありません。今回の変更で、少なくとも Gateway を通る通信については実測できるようになります。ルールと実態の差分を数字で示せることの意味は大きく、統制の議論が「べき論」から「現状こうなっている」へ移ります。

導入の進め方として、公式が示す順序は妥当です。最初にやるべきは遮断ではなく観察です。ダッシュボードで数週間分の実態を見ると、想定していなかったサーバーへの接続が出てくる可能性が高い。そこで初めて、承認する・Portal に載せる・禁止する、の仕分けができます。いきなり is_mcp で遮断すると、業務で使われている正当な接続まで止めて反発を招きます。

強制段階で効くのが Traffic Source との組み合わせです。「MCP であること」だけを条件にすると承認済みの接続も引っかかりますが、「MCP であり、かつ Portal 経由でない」という条件なら、承認済みは通しつつ直接接続だけを止められます。この2条件の組み合わせが今回の実質的な中核です。

注意点が2つあります。1つは検出の不完全性で、公式が自ら述べているとおりヘッダを付けない実装は検出をすり抜けます。「Gateway で検出できるものが全て」と考えると、把握できていない領域を見落とします。ネットワーク経路そのものの統制（管理された経路以外を通さない）と組み合わせないと、可視化の網には穴が残ります。2つ目は experimental.is_mcp という名称で、experimental 扱いのセレクタである以上、仕様が変わる可能性を織り込んだ運用が要ります。本番ポリシーの唯一の条件にするのは早い段階かもしれません。

手動 OAuth 設定の追加は、実務的には対応できる MCP サーバーの範囲が広がったことを意味します。動的クライアント登録に未対応のサーバーは Portal に載せられず、結果として「承認したいが Portal 化できない」という詰まり方をしていました。ここが解けると、承認リストと Portal 化の範囲を一致させやすくなります。

副業・個人活用視点

個人利用の観点では、直接使う機能ではありません。Cloudflare One の管理者向け機能であり、個人開発者が自分のために設定するものではないためです。

それでも知っておく価値があるのは、MCP がネットワーク側から見えるものになったという事実です。クライアントワークで MCP サーバーを構築・接続する場合、接続先の組織で今後この種の検出が入る可能性があります。「動いていたのに急に繋がらなくなった」という事態を避けるには、構築時点で情シス側の承認経路を確認しておくのが安全です。承認済みリストに載せてもらう、Portal 経由に寄せる、といった段取りが必要になる組織が増えていきます。

案件として拾うなら、シャドー MCP の棚卸しが分かりやすい切り口です。Cloudflare One を既に使っている組織なら、ダッシュボードを有効にして実態を出し、承認・Portal 化・遮断の仕分け案を作るところまでが一つの仕事になります。エージェント利用が広がっている組織ほど、誰も全体像を持っていない状態になりがちで、そこを可視化するだけで価値が出ます。

技術的な理解としては、MCP-Protocol-Version というヘッダ一つで検出が成立している点を押さえておくと応用が効きます。プロトコルに識別可能なマーカーがあるかどうかが、ネットワーク層で統制できるかを決めます。自分で MCP サーバーを作るときも、仕様どおりヘッダを付けておく方が、企業ネットワークの中で扱いやすい実装になります。

発信のネタとしては、MCP の統制がどこまで技術的に可能かを整理した内容が刺さります。「エージェントに何でも繋げるのは危険だ」という抽象論は既に飽和していますが、具体的にどのレイヤーで何が検出でき、何がすり抜けるのかを書いた記事はまだ少ない。公式が検出の限界を明記している点は、そのまま良い題材になります。