社内Wikiを検索するMCPサーバーを自社で作り、チケット管理や会計のSaaSが公開するMCPサーバーもつなぎ始めると、情シスの手元には「どの社員が、どのAIクライアントから、どのサーバーにつないでいるか」の一覧がなくなります。接続先のURLや認証の設定は社員ごと・クライアントごとに配ることになり、退職者や異動者のアクセスを止めるときもサーバーを1つずつ確認するしかありません。何かあったときに「誰がどのツールを呼んだのか」を追おうとしても、ログはサーバーごとに別の場所にあります。
CloudflareのMCP server portalsは、この散らばりを1つの入口に集める仕組みです。2026年9月24日に一般提供（GA）となりました。何をまとめ、何はまとめきれないのかを公式ドキュメントで整理し、社内のAIエージェントやClaudeなどのクライアントから業務システムにつなぐ前に決めておくことを、編集部の提案として示します。
個別につなぐと、管理の単位が「サーバー×利用者」になる
ここは編集部の整理です。利用者がMCPサーバーを個別に登録すると、管理する組み合わせが「サーバーの数×利用者の数」だけ生まれます。
- 接続情報の配布。 サーバーごとのURL、APIキーやOAuthの設定を、利用者ごとに渡します
- 権限の変更。 異動・退職のたびに、各サーバーの側で利用者を外します
- 使えるツールの範囲。 削除や送信のような操作を含むサーバーでも、サーバーが公開するツールがそのまま利用者に見えます
- 記録。 呼び出しの記録はサーバーごとの形式で、横断して追えません
自社でMCPサーバーを作るときの設計は自社MCPサーバー群の構築実務ガイドで扱いました。本記事は、作った・契約したサーバーを社内に配る側の話です。
MCP server portalsは何をまとめるのか
公式ドキュメントの説明では、MCP server portalは複数のMCPサーバーを1つのHTTPエンドポイントに集約します。利用者は https://<サブドメイン>.<ドメイン>/mcp という1つのURLをクライアントに登録し、Cloudflare Accessで社内のIDプロバイダーにログインします。OAuthを必要とするサーバーには、ポータルの中で個別に認可します。
管理者が決められるのは次の範囲です。
- ポータルに入れる人。 ポータルごとに自動で作られるAccessアプリケーションに、Accessポリシーを付けます
- サーバーごとに見える人。 サーバーにもAccessポリシーを付け、Allowポリシーに合う利用者にだけ、そのサーバーをポータルの中で見せます
- 見せるツールとプロンプト。 ツールを個別にオフにしたり、APIで「既定は非表示、許可したものだけ公開」にしたりできます。名前と説明の書き換え（エイリアス）もできます
- 記録。 ポータルとサーバーごとにログを見られます。GAの告知は、Accessがツール・プロンプト・リソースの操作を記録すると書いています
前提として、ポータルのURLに使うドメインがCloudflare上で有効になっていること（フルセットアップかCNAMEセットアップ）と、Zero TrustにIDプロバイダーを設定済みであることが必要です。つなげるのはリモートのHTTP（Streamable HTTPまたはSSE）で動くMCPサーバーで、stdioだけで動くサーバーはそのままでは追加できません。
図は公式ドキュメントの記述をもとにした編集部の概念図で、実際の管理画面ではありません。ポリシーと記録の位置が「各サーバーの手前」から「1つの入口」に移ります。ただし、サーバーのURLへ直接つなぐ経路は、サーバー側を設定しない限り残ります（後述）。
Accessのアカウント上限の表には、1アカウントあたりMCPポータル20個、1ポータルあたりMCPサーバー80台、1ポータルあたりカスタムドメイン5個、ポータルのセッションの無操作タイムアウト24時間が載っています（Enterpriseでは引き上げの相談が可能とされています）。GAの告知は「すべてのCloudflareの顧客」に提供と書いていますが、料金とZero Trustのどのプランで何が使えるかはMCPポータルのドキュメントに記載がないため、公式の料金ページで確認してください。
オープンベータからGAまでに加わった6つの機能
2025年8月26日のオープンベータ開始から、GAの告知までに次の機能が加わっています。
| 機能 | できること | 押さえておく条件 |
|---|---|---|
| Gatewayを経由させる | ツール呼び出しをGatewayのHTTPログに載せ、DLPで機微な情報の送受信を止める | 対応はStreamable HTTPのみ。DLPポリシーはポータルのURLではなく接続先サーバーのホスト名に当てる |
| Code Modeのポリシー | ツール定義を検索用と実行用の2つにまとめる動作を、ポータルごとにOff / Opt-in / On by default / Enforcedから選ぶ | 既定はOpt-in。Code Modeを自前で有効にしている接続先サーバーには非対応 |
| 静的なOAuthクライアント資格情報 | 動的クライアント登録（DCR）に対応していない提供元に、登録済みのクライアントIDとシークレットでつなぐ | 利用者ごとの認証が必須。最初の利用者が認可するまで「Waiting」のまま |
| セッション管理 | クライアントの中からサーバーの有効・無効の切り替え、再認証、新しく追加されたサーバーの認可をする | ポータルのサインアウトで、ポータルと接続先のOAuthの認可をまとめて取り消す |
| サービストークン認証 | 人がブラウザでログインしない自律エージェントを、ヘッダーのトークンでつなぐ | ポータルと各サーバーの両方にService Authポリシーが必要。接続先へは管理者の資格情報で届く |
| Logpush | ポータルの記録を外部のストレージやSIEMに送る | Enterpriseプランのみ |
Gateway経由のDLPは、ツールへ送る内容と接続先からの応答の両方向に効き、一致するとクライアントにはエラーが返ります。「Do Not Inspect」のHTTPポリシーに当たる通信は検査されず、DLPの「AI prompt」プロファイルはMCPの通信には効かない、とドキュメントは注意しています。
Logpushの記録には、JSON-RPCのメソッド（tools/call、prompts/get、resources/readなど）、ツール名、利用者のメールアドレス、成否、応答時間などが含まれます。
2026年9月22日には、社内ネットワークにしかないMCPサーバーをCloudflare Tunnelなどでポータルにつなぐ機能も告知されました。Gateway経由が必須で、OAuthの認可・トークンのエンドポイントはインターネットから届く必要があります。
個別に接続する場合と何が変わるか
ポータルを1枚挟んだときの違いを、公式ドキュメントで確認できた範囲で並べます。
| 観点 | 利用者が個別に接続 | ポータル経由 |
|---|---|---|
| クライアントに登録するURL | サーバーの数だけ | ポータルの1つ |
| 誰が使えるか | 各サーバーの認証の設定次第 | ポータルとサーバーのAccessポリシー（メール、グループ、国、端末の状態などのセレクター） |
| 見えるツール | サーバーが公開するものすべて | ポータルごとに絞り込み・改名できる |
| 記録 | サーバーごとの形式 | ポータル・サーバー単位のログ。EnterpriseはLogpushで外部へ |
| 送る内容の検査 | 別途の仕組みが必要 | Gateway経由にすればDLPで検査・遮断 |
| サーバーのURLへの直接接続 | そのまま可能 | Accessをサーバー自体のOAuthプロバイダーにしない限り、可能なまま |
最後の行が、比較でいちばん見落としやすい点です。ドキュメントは、サーバーのAllowポリシーに合わない利用者も、サーバーの直接のURLを使えばAccessのポリシーを回避してつなげると注意しています。自社開発のサーバーを確実にAccessの内側に置くには、別ページ「Secure MCP servers」の手順でAccessをそのサーバーのOAuthプロバイダーにします。
モデルとMCPツールへの通信をまとめて1か所に通すAIゲートウェイという選択肢もあり、社内AIにゲートウェイを1枚挟むかで整理しました。MCP server portalsはMCPサーバーへの入口に絞った形です。
入れる前に確認しておく制約
公式ドキュメントの「Known limitations」「Policy limitations」などに、次の記述があります。
- ポータル経由で認可するサーバーには、Accessの一部のポリシーが効かない。 独立したMFA、目的の申告（purpose justification）、一時的な認証（承認者による許可）は求められません。メール・グループ・国・端末の状態などのセレクターは適用されます
- 管理者のOAuthトークンは、通知なく期限切れになる。 切れたサーバーは「Error」か「Sync Required」になり、利用者のポータルから消えます
- サービストークンは利用者ごとのOAuthを使えない。 つなぐサーバーは「Require user auth」をオフにし、管理者の資格情報で接続先に届きます
- プロキシ経由の接続を拒むサーバーがある。 登録で
403を返すサーバーは使えません - 端末の認証（Cloudflare One Clientからの引き継ぎ）には未対応。 初回はブラウザでAccessのログインを完了する必要があります
クライアントは、ポータルのトップページにClaude Desktop、Workers AI Playground、OpenCode、Windsurfなどの接続手順が表示されるとあります。ChatGPTなど名前のないクライアントの対応状況は、ドキュメントでは確認できませんでした。
導入時に決めること（編集部の提案）
ここからは、上記の仕様を踏まえた編集部の提案です。管理画面を開く前に、次の5点を文書にしておくと設定が迷いません。
- 対象のサーバーと、見せるツール。 各サーバーのツールを「読むだけ」「データを変える」「外部に送る」に分け、変える・送るツールは非表示（
default_disabled）から始める選択肢があります。ツール単位で書き込みの線を引く考え方はAIエージェントに更新を許す日で扱いました。 - ポリシーの単位。 ポータルを部署や用途で分けるのか、1つのポータルでサーバーごとのポリシーで出し分けるのかを決めます。MFAの追加や承認フローをポータル経由では強制できないため、それが必要なサーバーはポータルに入れない判断もあります。自社開発のサーバーは、直接のURLを塞ぐ設定（AccessをOAuthプロバイダーにする）までを1組にします。
- 利用者ごとの認証か、管理者の資格情報か。 「Require user auth」をオフにすると、利用者は管理者の資格情報で接続先に届きます。SaaS側の記録では誰の操作か区別しにくくなると編集部は見ています（SaaS側の記録は未確認）。オフにするサーバーを限り、ポータル側の記録を正とします。
- ログの保存先と期間。 管理画面で見るだけでよいのか、Logpushで自社のストレージやSIEMに送るのか（Enterpriseプランのみ）を決めます。送った内容の検査が要るサーバーは、Gateway経由にしてDLPのポリシーを接続先のホスト名に当てます。
- エージェント用のサービストークン。 エージェントごとにトークンを分け、どのサーバーのService Authポリシーに入れるかを表にします。接続先へは管理者の資格情報で届くため、つなぐサーバーは最小限にし、シークレットの更新と失効の担当も決めます。
あわせて、通知されない管理者トークンの期限切れに備え、サーバーの状態を確認する担当を決めます。
2026年9月30日に、CloudflareのGAの告知（2026年9月24日）、MCP server portals・Secure MCP serversの各ドキュメント、アカウント上限のページ、2026年9月22日の私設MCPサーバー対応と2026年2月27日のLogpush対応の告知を、公式ドキュメントのソースリポジトリで直接開いて照合しました。Cloudflare Zero Trustの環境と契約がないため、ポータルの作成・ポリシー設定・Gateway経由のDLP・サービストークン接続・ログの出力は実行しておらず、実際の画面と動作、各クライアントでの接続は検証していません。料金とプランごとの提供範囲は未確認です。
社内のAIエージェントや業務システムのMCP接続の設計、自動化の進め方は、グリームハブへご相談ください。
Sources
- MCP server portals are now generally available — Cloudflare Changelog
- MCP server portals — Cloudflare One docs
- Secure MCP servers — Cloudflare One docs
- Account limits — Cloudflare One docs
- Private MCP server support for MCP server portals — Cloudflare Changelog
- Export MCP server portal logs with Logpush — Cloudflare Changelog
- MCP server portals（オープンベータ） — Cloudflare Changelog
