Cloudflare の MCP server portal が社内ネットワーク限定の MCP サーバーへ接続可能に。ただし OAuth の入口は公開のまま
Cloudflare が 2026-09-22、MCP server portal がプライベートネットワーク上にのみ存在する MCP サーバーへ接続できるようにした。portal は Cloudflare Gateway を経由してプライベートホスト名・IP へ到達するため、MCP サーバー自体をインターネットへ公開する必要がない。手順は、Cloudflare Tunnel / Cloudflare Mesh / その他 Cloudflare One コネクタでサーバーのネットワークを接続し、プライベートホスト名または CIDR ルートを設定し、サーバー追加時に「Route traffic through Cloudflare Gateway」を有効にする、の3段階。重要な例外として、OAuth 認可サーバーのエンドポイント（authorization / token）はインターネットから到達できる必要がある。Dynamic Client Registration を使う構成では registration エンドポイントも公開されていなければならない。つまり MCP サーバー本体は閉じられるが、認可の入口は閉じられない。
ニュース原文を読む ↗要約
Cloudflare は 2026-09-22、MCP server portal が社内ネットワーク上にのみ存在する MCP サーバーへ接続できるようにしました。
portal は Cloudflare Gateway を経由してプライベートなホスト名・IP アドレスへ到達します。つまり、MCP サーバーをインターネットへ公開しないまま、MCP クライアントから使えるようになります。
この変更が解く問題は、AI エージェント導入で最初にぶつかる壁そのものです。 社内の基幹システム、在庫データベース、顧客管理——AI に触らせたい情報は、たいてい社内ネットワークの中にあります。MCP サーバーを立ててエージェントへ繋ごうとすると、「そのサーバーをどうやって外から届く場所に置くか」という問題が出ます。インターネットへ公開する以外の選択肢が、ここで増えました。
ただし、閉じられない部分が残ります。そこが実務上の要点です。
何が変わったか
設定手順は3段階です。
1つ目に、サーバーのネットワークを Cloudflare へ接続します。 Cloudflare Tunnel、Cloudflare Mesh、その他の Cloudflare One コネクタのいずれかを使います。既に Zero Trust 構成で社内リソースを Cloudflare 経由にしている組織なら、この土台は済んでいます。
2つ目に、プライベートホスト名または CIDR ルートを設定します。 ホスト名単位でも、IP レンジ単位でも指定できます。
3つ目に、サーバーを追加するときに「Route traffic through Cloudflare Gateway」を有効にします。 これがサーバー単位のスイッチなので、公開 MCP サーバーとプライベート MCP サーバーを同じ portal に混在させられます。
そしてここが重要な例外です。
公式は明記しています。OAuth 認可サーバーのエンドポイント——authorization エンドポイントと token エンドポイント——は、引き続きインターネットから到達できる必要があります。 さらに、Cloudflare が **Dynamic Client Registration（DCR）**で OAuth クライアントを自動登録する構成では、registration エンドポイントも公開されていなければなりません。
つまり「MCP サーバー本体は閉じられるが、認可の入口は閉じられない」という構成です。
これを「中途半端」と読むか「妥当」と読むかは、何を守りたいかによります。守りたいのがデータそのもの、業務ロジック、ツールの一覧なら、この構成で守れます。 MCP サーバーが公開する tool の定義もデータも、インターネットからは見えません。守りたいのが「自社が何かを認証している事実」まで含むなら、足りません。
業務インパクト
社内システムを AI エージェントへ繋ぐ案件の設計が、1段やりやすくなります。
これまでの選択肢は、おおむね3つでした。(1) MCP サーバーをインターネットへ公開して認証で守る、(2) エージェント自体を社内で動かす、(3) 諦める。 (1) はセキュリティ部門との交渉が重く、(2) は動かせるエージェントが限られます。今回、(1) の重さがかなり軽くなりました。
セキュリティレビューで説明しやすくなる、という点が実務では大きいです。 「MCP サーバーは外部から到達できません。Cloudflare Gateway 経由でのみ、認証済みのリクエストが届きます」という説明は、「認証を付けて公開します」より通りやすい。ただし OAuth エンドポイントの公開可達性は、レビュー資料に最初から書いてください。 後から「実は一部公開が必要でした」と出すと、信頼を失います。
前提条件の確認が要ります。 この機能は Cloudflare One / Access の上に乗っています。Cloudflare Tunnel や Mesh で社内ネットワークを Cloudflare へ繋いでいない組織にとっては、その導入が先です。「MCP のために Zero Trust 基盤を入れる」というのは、順番として無理があります。既に Cloudflare One を使っている組織にとっての追加機能、と読むのが正確です。
公式 changelog はプラン条件に言及していません。 実際に導入するなら、自社の契約で使えるかを先に確認してください。
同じ日、Cloudflare は Worker Previews も出しています。 そして前日には Browser Run のバインディングに outboundByHost（ホスト単位で別 Worker へ経路を回し、認証付与やプライベートサービス到達を挟める）が追加されました。「エージェントとプライベートネットワークの接続点を整える」という方向が、複数製品で同時に進んでいます。 個々の changelog は小さく見えますが、並べると設計の意図が読めます。
副業・個人活用視点
個人開発者にとって、直接の用途は限定的です。 Cloudflare One を個人で使っている人は多くありません。
ただし、受託・コンサルの文脈では材料になります。
中小企業から「うちのデータを AI に使わせたいが、外に出すのは怖い」という相談を受ける場面は増えています。このとき提示できる構成が1つ増えました。 「データは社内に置いたまま、Cloudflare 経由で AI から参照だけさせる」という説明は、抽象的な安心論ではなく具体的な構成として語れます。
提案するなら、限界も一緒に説明してください。 OAuth の入口は公開が必要です。「完全に閉じられます」と言って後から訂正するより、最初から「ここまでは閉じられ、ここは開きます」と線を引く方が、結果的に受注につながります。 制約を説明できる人は、制約を知っている人として扱われます。
学習の題材としては、「認可と資源の分離」という論点が扱えます。 なぜ MCP サーバー本体は閉じられて、OAuth エンドポイントは閉じられないのか。OAuth はブラウザのリダイレクトを経由する仕組みで、利用者のブラウザから直接叩かれるからです。 サーバー間通信なら経路を閉じられますが、人間のブラウザが介在する経路は閉じられない。この区別は MCP に限らず、あらゆる認証連携の設計で効きます。
「小さな changelog を並べて意図を読む」という読み方自体も、発信の題材になります。 今回の3件（MCP portal のプライベート対応、Worker Previews、Browser Run の outboundByHost）は、単体ではどれも1〜2段落の告知です。並べると「エージェントが閉域資源に触るための配管を敷いている」と読める。 ニュースを1件ずつ消費するのではなく、方向を読む練習の教材になります。