Cloudflare MeshとエンタープライズMCP参照アーキテクチャ
目次
Cloudflareが4月14日、Agents Week 2026の一環として2本の発表を行った。Cloudflare Meshと「エンタープライズMCP参照アーキテクチャ」だ。
2つは別々の製品だが、解決しようとしている問題は連続している。コーディングエージェント（Claude Code、Cursor、Codex）がステージング環境のデータベースや社内Wikiにアクセスするにはまずネットワークレベルでそのリソースへ到達できなければならない。それを担うのがMeshだ。到達できるようになった後、どのエージェントがどのMCPツールをどの権限で呼べるかを管理する層がMCP参照アーキテクチャの担当だ。
Mesh記事内でCloudflareは「ネットワーク到達性とツール実行権限は分離して考えるべきで、Meshが前者、MCPサーバーの認証設計が後者を担う」と明記している。2つは意図的にセットで設計されている。
SandboxesのGA、Durable Object Facets、統合CLIについては Agents Week全体をまとめた記事 を参照。
Cloudflare Mesh、エージェント向けプライベートネットワーク
AIエージェントが普及してきたことで、プライベートネットワーク設計の前提が崩れつつある。従来のVPNやSSHトンネルは「人間がログインして使う」前提で設計されており、自律的に動くエージェントはそこに収まらない。
| 手段 | 問題点 |
|---|---|
| サービスを公開する | 攻撃面が広がる。認証ミス一発でアウト |
| SSHトンネルを手動で張る | エージェントが動くたびにセットアップが必要 |
| VPN全体を通す | ラップトップ全体がVPN経由になる。エージェントの挙動を区別できない |
| クレデンシャルをエージェントに渡す | 漏洩リスク。どのエージェントが何をしたか追跡できない |
Meshはこの「エージェントが勝手には繋げない問題」をプラットフォームとして解決する。
MeshとWARP Connectorの関係
Meshは完全な新製品ではなく、既存のWARP Connectorを発展させたものだ。
- WARP Connector（Cloudflareのヘッドレスネットワーククライアント） → Cloudflare Meshノード（サーバー・VM・コンテナ上で動く）
- WARP Client → Cloudflare One Client（ラップトップ・スマートフォン用）
既存のWARP Connector環境はそのまま移行なしで使える。ノード上限は従来の10台から50台に引き上げられた。アカウントあたり50ノード・50ユーザーまでは無料だ。
Cloudflare Oneにすでに加入している組織は、Mesh用のダッシュボード（Networking > Mesh）が追加で使えるようになる。インタラクティブなネットワークマップ、ノード管理、ルート設定、診断ツール、セットアップウィザードが一箇所にまとまった。
接続シナリオ
| シナリオ | 構成 |
|---|---|
| ホームLLMへのモバイルアクセス | Mac miniにMeshノード、スマートフォンにCloudflare One Client。プライベートIPで接続でき、公開インターネットへの露出不要 |
| コーディングエージェントのステージング接続 | Claude CodeやCursorがステージングDBやプライベートAPIを参照。Gatewayポリシーでアクセス先を細かく制御できる |
| Workers上のエージェントからプライベートサービスへ | Agents SDKで作ったWorkerが内部APIやDBを呼ぶ。Workers VPCのネットワークバインディング経由でMeshネットワーク全体にアクセス |
Workers VPC統合
Cloudflare Workersの設定ファイル wrangler.jsonc のネットワークバインディングで設定する。
"vpc_networks": [
{ "binding": "MESH", "network_id": "cf1:network", "remote": true },
{ "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]cf1:network はアカウントのMeshネットワーク全体を指す予約キーワード。WorkerコードはバインディングのURLをフェッチするだけで、ネットワーク実装の詳細を意識しなくていい。
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext) {
const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");
const dbResponse = await env.AWS_VPC.fetch("http://internal-db.corp.local:5432");
return new Response(await apiResponse.text());
},
};Cloudflare Tunnel（プライベートサービスをCloudflare経由で安全に公開するリバースプロキシ）との違いは方向性だ。Tunnelは単方向なのに対し、Meshは双方向・多対多の通信が可能だ。Mesh上のどのノードからも他のノードのプライベートIPへアクセスできる。複数のサービスを繋ぐときにそれぞれTunnelを設定する必要がなくなる。
セキュリティ
MeshトラフィックはすべてCloudflare Oneプラットフォームを通過するため、既存のセキュリティコントロールがそのまま適用される。
| 機能 | 内容 |
|---|---|
| Gatewayポリシー | DNSフィルタリング、ネットワーク・HTTPポリシー |
| デバイスポスチャ（端末の状態確認） | OS バージョン・暗号化・ファイアウォール等の健全性チェック |
| Access for Infrastructure | SSHとRDPのセッション管理、セッション録画・監査ログ |
| DLP（Data Loss Prevention） | センシティブデータの外部流出防止 |
現時点ではMeshノードはネットワーク層で「Workerからのリクエスト」として扱われ、どのエージェントが何を呼んだか識別できない。エージェント単位のIDとポリシー評価は今後の開発項目とされている。
ロードマップ
| 機能 | 時期 | 概要 |
|---|---|---|
| ホスト名ルーティング | 2026年夏 | wiki.local のようなプライベートホスト名でルーティング。IPアドレスのリスト管理が不要になる |
| Mesh DNS | 未定 | 全ノード・デバイスに postgres-staging.mesh のような内部ホスト名を自動割当 |
| アイデンティティ対応ルーティング | 未定 | ノード・デバイス・エージェントそれぞれに区別可能なIDを持たせ、ポリシーをIPレンジではなくID単位で記述できるようにする |
アイデンティティ対応ルーティングが実現すれば、「このMCPツールを呼べるのはスコープAを持つエージェントのみ」のようなきめ細かい制御が可能になる。
NAT越えとグローバルネットワーキング
Tailscaleなど他のメッシュVPNはSTUN/TURNリレーサーバー（NAT越えのための中継サーバー）を組み合わせてNATを越えるが、リレー拠点（PoP）の数が限られると一部のトラフィックでレイテンシが増える。
Cloudflare Meshは全トラフィックをCloudflareのエッジ（330都市以上）経由でルーティングする。P2P直接接続への試みはなく、最初からCloudflareのバックボーンを通す設計だ。「劣化したフォールバック経路」が存在しないことをCloudflareは差別化点として強調する。クロスリージョン・マルチクラウドのトラフィックではパブリックインターネットより速くなるケースが多い。
トレードオフとして、すべてのトラフィックがCloudflare経由になるため、Cloudflare自体の可用性に依存する。Tailscaleと比較されることが多いが、同列というよりCloudflare Oneのセキュリティスタックとの統合を前提にした別設計という位置づけだ。
エンタープライズMCP参照アーキテクチャ
MCPが開発者の個人環境で動く分には問題は少ない。ローカルMCPサーバーにコードリポジトリや社内Wikiへのアクセス権を与え、Claude CodeやCursorのセッション内で使う、という使い方が典型だ。
企業規模になると話が変わる。部署ごとに別々のMCPサーバーが乱立し、誰がどのサーバーを使っているかの把握ができなくなる。認可は各サーバーが独自実装し、監査ログは存在しない。ローカルサーバーはサプライチェーンリスク（依存パッケージ経由での侵害）の温床でもある。プロンプトインジェクション攻撃の対策が各チームに丸投げされる。
| レイヤー | コンポーネント | 役割 |
|---|---|---|
| クライアント層 | Claude、Cursor等のAIクライアント | エンドユーザーのAIツール |
| 認証・ポータル層 | MCP Server Portal + Cloudflare Access | SSO/MFA、一元化されたサーバー発見 |
| 実行層 | Remote MCP Servers on Workers | グローバル展開、CI/CD統合 |
| 監視・制御層 | AI Gateway + Gateway DLP | トークン管理、Shadow MCP検出 |
MCP Server Portalによる一元化
従来は各MCPサーバーに個別接続していたところを、Portal経由で一本化する。Portal自体もMCPサーバーとして振る舞い、背後にある複数のサーバーへのリクエストを束ねる。
AIクライアントからはPortalのエンドポイント1つを設定するだけになる。ログ記録とDLP（データ損失防止）検査はPortalで集中管理される。新しいMCPサーバーを追加しても、クライアント側の設定変更は不要だ。
前段にCloudflare Accessを配置すると、企業のSSOとMFAがそのままMCPへの認証として機能する。IPアドレス、デバイス証明書、地理情報といったコンテキスト属性による条件付きアクセスも適用できる。MCPの認証はOAuth 2.1（認可プロトコル）ベースで、ユーザーが明示的に許可したスコープのみをMCPサーバーに渡す。エージェントが意図せず広い権限でAPIを叩く状況を防ぐ設計だ。
新しいMCPサーバーを追加する際は、テンプレートから生成するだけで認証設定、シークレット管理、デフォルト拒否の書き込み制御が自動で付いてくる。
Code Mode：トークンコストを94%削減
Code Modeは今回の発表の中でも特に実務インパクトが大きい機能だ。
MCP接続時、クライアントはサーバーが公開するすべてのツール定義をコンテキストウィンドウ（モデルが一度に処理できるテキスト量の上限）に読み込む。ツールが増えるほどトークン消費が線形に増加し、コンテキストを圧迫する。Cloudflareの内部MCPポータルで4つのMCPサーバーを接続すると52のツール定義が生成され、約9,400トークンを消費する。
Code Modeを有効化すると同じ環境で約600トークンまで圧縮された。94%の削減だ。しかもMCPサーバーをさらに追加してもトークン数はほぼ固定のまま増えない。
仕組みは52のツールを2つのツールに統合することだ。
| ツール | 役割 |
|---|---|
portal_codemode_search | ツール定義をJavaScriptで検索する |
portal_codemode_execute | JavaScriptコードを実行してAPIを呼び出す |
モデルはこの2ツールだけを知っていれば済む。実際の操作は execute に渡すJavaScriptの中で行う。ツール定義全体を事前にコンテキストへ押し込む代わりに、モデルがコードで動的に調べる形だ。
// ツールを検索して絞り込む
const tools = await codemode.tools();
return tools
.filter(t => t.name.includes("jira") || t.name.includes("drive"))
.map(t => ({
name: t.name,
params: Object.keys(t.inputSchema.properties || {})
}));// 複数操作を1回の実行呼び出しで連鎖させる
const tickets = await codemode.jira_search_jira_with_jql({
jql: 'project = BLOG AND status = "In Progress"'
});
const attachments = await codemode.drive_list_files({
query: tickets.map(t => t.id).join(" OR ")
});
return { tickets, attachments };コードの実行はCloudflare WorkersのDynamic Worker（軽量V8サンドボックス）で行われる。ファイルシステムも環境変数も存在しない分離環境で、外部フェッチはデフォルトで無効化されている。有効化はPortalのURLに ?codemode=search_and_execute を付けるだけだ。
Shadow MCPの検出
Shadow MCPとは、企業のITガバナンスが把握していないMCPトラフィックのことだ。従業員が個人の判断で外部MCPサービスに接続し、社内データをそのサービスに渡している状況が典型例になる。
Cloudflare Gatewayで利用できる新しい検出ルールセットは3層のアプローチを取る。
| 検出層 | 方法 |
|---|---|
| ホスト名パターン | mcp.* のワイルドカードマッチングと、mcp.stripe.com のような既知MCPサーバーのホスト名リストを組み合わせ |
| URIパターン | /mcp や /mcp/sse へのアクセスを識別 |
| ボディインスペクション（DLPプロファイル） | MCPはJSON-RPC（JSON形式の遠隔手続き呼び出し）over HTTPを使うため、リクエストの method フィールドを検査。ホスト名やURIを変えた迂回も検出 |
const DLP_REGEX_PATTERNS = [
{ name: "MCP Initialize", regex: '"method"\\s{0,5}:\\s{0,5}"initialize"' },
{ name: "MCP Tools Call", regex: '"method"\\s{0,5}:\\s{0,5}"tools/call"' },
{ name: "MCP Resources Read", regex: '"method"\\s{0,5}:\\s{0,5}"resources/read"' },
{ name: "MCP Protocol Version", regex: '"protocolVersion"\\s{0,5}:\\s{0,5}"202[4-9]' }
];検出したトラフィックに対してはブロック、リダイレクト、ログ記録のいずれかを選択できる。承認されたPortal経由へのリダイレクトが典型的な運用になるだろう。
AI Gatewayとの組み合わせ
MCPクライアントとLLMの間にAI Gatewayを挟む構成も推奨されている。CloudflareのAI Gatewayについては WAFと同日リリースしたAIセキュリティ機能の記事 で詳しく触れている。
エンタープライズ文脈での追加効果は2点ある。従業員ごと・チームごとにトークン消費量の上限を設定できる点と、LLMプロバイダーを抽象化してベンダーロックインを避けられる点だ。Code Modeで基本コストを下げつつ、外れ値となる使い方をAI Gatewayで抑制する組み合わせが機能する。
下層のMeshがエージェントをプライベートリソースへ繋ぎ、上層のMCP参照アーキテクチャがアクセスを管理する。どちらもCloudflare Oneの既存セキュリティスタックに乗るので、新たなセキュリティレイヤーを一から作る必要がない。個々のMCPサーバーの実装レベルの脆弱性については「オープンソース50件のスキャン結果」を参照。