柔軟性と、AI 実行環境の安全な相互接続。
"つなぐ" の前提が、変わりはじめている。
Mini Session #1 / 15 min · Cloudflare Blog "introducing Cloudflare Mesh" より
コーディングエージェントはステージング DB を叩き、本番エージェントは内部 API を呼ぶ。"つなぐ" の前提が変わると、WAN の前提も変わる。
ユーザー・エージェント・Workers・VPC が、同じネットワークで
会話する世界。
1 本のコネクタ・1 つのバイナリで、すべての "つなぎたいもの" を同じプライベート網に。
既存の Gateway / Access / Posture が、そのまま Mesh トラフィックにも効く。
ひとつの安全な接続を張る Tunnel が原点。
それを多対多のプライベート網へ広げたのが Mesh。
Tunnel は双方向こそ持たないが、公開サーバーを完全に守って公開できる。 内部を双方向につなぐのが Mesh。
"外に出すや単一拠点への接続" は Tunnel、"内側でつなぐ" は Mesh。どちらも同じ Cloudflare One 上。
構成例。公開サイトを Tunnel で守り、その同じバックエンドが Mesh の私設網(マルチクラウド + AI)
NAT 配下同士の通信で リレーサーバーを自前で持つ必要なし。Cloudflare 経由で一発で繋がる。
マルチクラウド・拠点間も パブリック網よりも安定して低遅延。落ちた時のフォールバック経路も同じ網内。
すべてのパケットが Cloudflare のセキュリティスタックを通る。Gateway / DLP / Posture が "つなぐ" と同じ場所で効く。
Workers VPC を Mesh と統合。Workers / Durable Objects / Agents SDK のコードから プライベート IP に直接 fetch できる。
wrangler.jsonc + worker.ts// wrangler.jsonc — Mesh ネットワーク全体を Worker にバインド "vpc_networks": [ { "binding": "MESH", "network_id": "cf1:network", "remote": true } ] // worker.ts — エージェントが社内 API / DB を呼ぶ export default { async fetch(req, env) { const r = await env.MESH.fetch("http://10.0.1.50/api/data"); return new Response(await r.text()); } };
ssh postgres-staging.mesh拠点をつなぐ箱から、ユーザー・ノード・エージェントを一枚に乗せる "プライベート網" へ。
Cloudflare Mesh = ユーザー・ノード・エージェントを、
ひとつのプライベート網に。