エージェントに MCP サーバーを直接配るのをやめる。Cloudflare の MCP server portals が GA

要約

Cloudflare は 2026-09-24、**MCP server portals を一般提供（GA）**にしました。ベータからの昇格です。

MCP（Model Context Protocol）は、AI エージェントが外部ツールに接続するための規格です。普及するにつれて現れたのが「配り方」の問題でした。エージェントごとに、使わせたい MCP サーバーの接続情報を個別に設定する。エージェントが増え、MCP サーバーが増えると、組み合わせの数だけ設定が増えます。誰がどのツールに繋がっているかを把握できなくなり、通信内容も見えず、認可を取り消すにも設定を1つずつ辿ることになります。

MCP server portals は、この構造を変えるものです。承認済みの MCP サーバー群に対して、単一のエンドポイントを提供します。 エージェントはポータル1つに繋ぎ、その先で何が使えるかはポータル側の設定で決まります。認可・可視化・統制が1か所に集まるわけです。

ベータ以降に追加された機能が6つあり、ここが GA の実質的な中身です。

Gateway ルーティングにより、HTTP ログと DLP（データ損失防止）スキャンが効くようになりました。エージェントが MCP サーバーへ何を送り、何を受け取っているかが記録され、機微な情報の流出を検知できます。

Code Mode ポリシーは、ポータルがツール定義をどこまで圧縮し、トークン消費を抑えるかを制御します。MCP サーバーのツール定義は、接続するたびにコンテキストへ読み込まれます。サーバーが増えるほど、実際の作業に使う前にコンテキストが埋まっていくという問題への対処です。

静的 OAuth クレデンシャルへの対応で、Dynamic Client Registration に非対応のプロバイダーも収容できるようになりました。セッション管理により、ポータル側からサーバーの再接続と認可の変更ができます。サービストークン認証は、自律エージェントやマシン間（M2M）アクセスに対応するためのものです。Logpush 対応で、アクティビティを外部ストレージや SIEM へエクスポートできます。

なお 2026-09-22 には、プライベートネットワーク上の MCP サーバーへ Gateway 経由で到達する機能も追加されています。社内 MCP サーバーを外に公開せずにポータル配下へ入れられる構成が、これで揃った形です。

提供範囲は「すべての Cloudflare 顧客」で、changelog 上にプラン階層の限定は記載されていません。

何が変わったか

• MCP server portals が GA（承認済み MCP サーバーへの単一エンドポイント）
• Gateway ルーティング — HTTP ログと DLP スキャンが有効に
• Code Mode ポリシー — ツール定義の圧縮度とトークン消費を制御
• 静的 OAuth クレデンシャル — Dynamic Client Registration 非対応プロバイダーを収容
• セッション管理 — ポータルからサーバーの再接続・認可変更が可能
• サービストークン認証 — 自律エージェント / M2M アクセスに対応
• Logpush 対応 — 外部ストレージ・SIEM へアクティビティを出力
• 関連: 2026-09-22 にプライベートネットワーク上の MCP サーバーへの Gateway 経由到達を追加
• 提供範囲: すべての Cloudflare 顧客（プラン限定の記載なし）

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

社内でエージェントを複数動かしている組織にとって、これは接続設計を見直す機会になります。

現状でよくあるのは、エージェントごとに MCP サーバーの接続情報を直接持たせる構成です。開発チームのエージェントには GitHub と社内 Wiki、サポートチームのエージェントには CRM とナレッジベース、というように。この構成は最初は簡単ですが、規模が増えると統制が破綻します。 新しいエージェントが増えるたびに接続を配り直し、あるツールへのアクセスを止めたければ全エージェントの設定を確認して回ることになります。

ポータル経由にすると、この作業が1か所に集まります。 ツールの追加・削除はポータル側で行い、エージェント側の設定は変わりません。これは権限管理の常套手段で、MCP に固有の話ではありません。 目新しさはありませんが、MCP の世界でそれが使える状態になったこと自体が前進です。

情報システム部門の承認という観点では、Logpush と DLP が決定的です。 エージェントに社内データへのアクセスを許すとき、必ず出る質問が「何が外に出ているか追跡できるのか」です。エージェントが直接 MCP サーバーへ繋ぐ構成では、この質問に答えられません。 ポータル経由で Gateway を通れば、HTTP ログが残り、DLP がスキャンし、Logpush で既存の SIEM に流し込めます。すでに運用している監査の枠組みに、エージェントの通信を載せられるということです。これは承認を取る難易度を実質的に下げます。

Code Mode ポリシーは、地味ですが効きます。 MCP サーバーを増やすと、ツール定義がコンテキストを圧迫します。10個のサーバーを繋いだ結果、実際の作業を始める前にコンテキストの相当部分が定義で埋まる、という状態は珍しくありません。圧縮度を制御できるということは、「繋げる数」と「使えるコンテキスト」のトレードオフを設定で調整できるということです。エージェントの性能とコストの両方に効きます。

サービストークン認証は、無人運用の前提条件です。 対話型のエージェントなら、利用者の OAuth で認可できます。しかしスケジュールで動くエージェントや、他のシステムから呼び出されるエージェントには、認可する人間がいません。 サービストークンがないと、この種の運用は成立しないか、共有アカウントの使い回しという最悪の形になります。自律エージェントを本番運用する計画があるなら、ここが要件に入ります。

導入の順序としては、まず既存のエージェントと MCP サーバーの対応表を作ることをおすすめします。 ポータルに集約する価値は、対応関係が複雑なほど大きくなります。エージェントが1つ、MCP サーバーが2つ、という規模なら、ポータルを挟む手間の方が上回ります。 自社がどの規模にいるかを先に確認してください。

副業・個人活用視点

個人開発者にとっては、直接使うより「こういう問題が起きる」という予告として読む価値があります。

個人で MCP を使うとき、サーバーは数個で、繋ぐのは自分のエージェントだけです。ポータルを挟む理由はありません。しかし、クライアントワークで MCP を使う構成を提案するようになると、話が変わります。

最初に聞かれるのはほぼ確実に「ログは残るのか」です。 社内データにアクセスする仕組みを提案して、監査の話が出ないことはありません。このとき「MCP サーバーに直接繋ぎます」という設計だと、そこで止まります。 ポータルを挟む構成を知っていれば、「Gateway 経由でログを取り、Logpush で既存の SIEM に流します」と答えられます。提案が通るかどうかが、この一点で決まることがあります。

Code Mode ポリシーの話は、自分の実装にも跳ね返ります。 MCP サーバーを繋ぎすぎるとコンテキストが埋まる、という現象は個人利用でも起きます。エージェントの回答が急に雑になったとき、原因がツール定義の肥大化であることは珍しくありません。 Cloudflare がこれを制御対象として実装したという事実は、この問題が一般的で、放置すると実害が出ることの裏づけです。自分の環境でも、繋いでいる MCP サーバーの数と、実際に使っているツールの数を照合してみる価値があります。

「単一エンドポイントに集約する」という設計パターン自体が、汎用的な学びです。 これは MCP に限らず、API ゲートウェイ、リバースプロキシ、SSO と同じ構造です。多対多の接続を、多対1対多に組み替えることで、中央で統制できるようにする。 個人開発では過剰ですが、規模が増えた瞬間に必要になる形です。「今は要らないが、いつ必要になるか」を判断できることが、設計の経験値になります。

注意点を1つ。 提供範囲は「すべての Cloudflare 顧客」と書かれていますが、Cloudflare One / Access の利用が前提になる機能です。 Workers だけを使っている環境でそのまま使えるわけではありません。提案の前に、相手がどの Cloudflare 製品を使っているかを確認してください。