Cloudflareは2026年4月14日、プライベートネットワークを相互接続し、AIエージェントなどに安全なアクセスを提供する「Cloudflare Mesh」を発表した。背景には、AIエージェントが社内APIやデータベース、自宅ネットワーク上のサービスにアクセスする場面が増える一方で、VPNやSSHトンネルのような人間向けの既存手法では、安全な接続管理や可視化が難しくなっていたと指摘している。

• Secure private networking for everyone: users, nodes, agents, Workers — introducing Cloudflare Mesh - Cloudflare Blog

既存のCloudflare TunnelがCloudflareエッジから特定のプライベートサービスへ接続する単方向の用途に向くのに対し、Cloudflare Meshは双方向で多対多のプライベートネットワークを提供する。各デバイスやノードは、リソースごとに個別のTunnelを設けなくても、プライベートIPで相互にアクセスできるようになる。

すべての通信は世界330都市以上に展開するCloudflareのグローバルネットワークを経由するため、NATトラバーサルの課題を避けつつ、リレーサーバーによる遅延や信頼性の低下も抑えられるとしている。

Cloudflare MeshはすべてのCloudflareアカウントで、1アカウント当たり無料で最大50ノード・50ユーザーまで利用できる。利用を開始するには、Cloudflareダッシュボードの「Networking」メニューにある「Mesh」で設定を行う。

なおCloudflare Oneを利用している場合は、WARP ConnectorがCloudflare Mesh nodeに、WARP ClientがCloudflare One Clientに名称変更される一方、既存のGatewayポリシーやAccessルール、device posture checksはMeshトラフィックにもそのまま適用できるとしている。

開発者向けには、Cloudflare Workersからプライベートネットワークへ接続するためのWorkers VPCとAgents SDK（npm i agents）を組み合わせることで、Cloudflare Workersからプライベートバックエンドに接続するリモートMCPサーバーも構築できるとしている。さらに、wrangler.jsoncファイルで予約語のcf1:networkを使えば、アカウントのCloudflare Meshネットワークをバインドできる。これにより、WorkerやAgents SDKで構築したエージェントは、個別ホストを登録しなくてもMesh上の内部ホストへアクセスできるようになるという。

注意点として、現時点ではアクセス先の指定はIPアドレスベースに限られていること、また、ノードはネットワークレイヤーで個別のアイデンティティを持たないため、Gatewayポリシー側でも各ノードを別々には識別できないことが挙げられる。

今後はIPアドレス依存の運用を減らすため、今夏にホスト名ルーティング、今年後半に内部ホスト名を自動付与するMesh DNSとコンテナ環境向けのMesh Docker imageを導入する計画だという。あわせて、各ノードやエージェントをGatewayポリシーで個別に評価できる「Identity-aware routing」も開発中とのこと。