2026年4月に Cloudflare Mesh という製品が発表されました。旧 WARP Connector のリブランドですが、機能拡張と合わせて新たなメッシュネットワーキング製品として位置づけられています。実際に触ってみた感想と、既存の VPN や他社 SASE 製品との違いについて整理してみました。
Cloudflare Mesh とは何か
シンプルに言えば、「Linux サーバーに warp-cli を入れるだけで、複数拠点が一つのプライベートネットワークになる」というものです。各参加者に 100.96.0.0/12 の Mesh IP が自動割り当てされ、TCP/UDP/ICMP で双方向・多対多の通信が可能になります。
旧 WARP Connector からの主な変更点：
- ノード上限が 10 → 50 に増加
- 専用ダッシュボード（ネットワークマップ、診断、ウィザード）
- Workers からの VPC アクセスが
cf1:networkバインディングで可能に - HA（Active-Passive）対応
実際の構成例
自宅の MacBook、AWS の EC2、Oracle Cloud のインスタンスを繋げてみました。全体の構成はこんな感じです：
MacBook (WARP Client)
Mesh IP: 100.96.0.1
|
v
================== Cloudflare Edge ==================
| |
AWS EC2 OCI Instance
Mesh IP: 100.96.0.3 Mesh IP: 100.96.0.2
VPC: 10.0.1.0/24 VCN: 10.0.2.0/24
設定にかかった時間は、AWS と OCI のルートテーブル変更を含めて20分程度。 apt install してトークンを入れるだけなので、手順書を作るほどでもありませんでした。
他社製品と何が違うのか
SASE 市場は Zscaler、Netskope、CATO、Palo Alto などが入り混じっていますが、Cloudflare Mesh は明確に異なるポジションを取っています。
専用ハードウェアが不要
| ベンダー | 拠点側に必要なもの |
|---|---|
| Cloudflare Mesh | Linux ホスト 1台 |
| Zscaler | Branch Connector VM |
| Netskope | SASE Gateway HW or VM |
| CATO | Socket HW or vSocket |
| Palo Alto | ION アプライアンス |
他社は全て専用アプライアンスか VM が必要です。Mesh は apt install cloudflare-warp だけ。コスト面でも運用面でも、この差は大きいです。
WAN 契約が不要
CATO は自社バックボーン利用が前提、Palo Alto や Zscaler は SD-WAN ライセンスが別途必要。Mesh は Cloudflare の 330+ 拠点のエッジを利用します。既存のインターネット接続で動作し、追加の回線契約は不要です。
Cloudflare WAN との使い分け
Mesh はノード上限 50、ソフトウェアベースのメッシュ接続に適しています。一方、Cloudflare WAN（旧 Magic WAN）は GRE/IPsec トンネルで対応ルーターと接続し、数十〜数千サイトの大規模展開が必要な場合に選ばれます。
シンプルな拠点間接続が必要なら Mesh、既存ネットワーク機器との統合やエンタープライズ級の WAN 機能が必要なら WAN、という使い分けです。
Tunnel との使い分け
同じ Cloudflare 内でも Tunnel（cloudflared）と Mesh は明確に役割が分かれています：
| 項目 | Tunnel | Mesh |
|---|---|---|
| トラフィック方向 | 一方向（Cloudflare → 内部） | 双方向（全参加者間） |
| トポロジ | Star | Full Mesh |
| サーバー → WARP 端末 | 不可 | 可能 |
| サーバー → サーバー | 不可 | 可能 |
| プロトコル | HTTP / TCP | TCP / UDP / ICMP |
Web アプリを「公開」したい場合は Tunnel、拠点間で「相互通信」したい場合は Mesh、という使い分けです。同一サーバー上で併用も可能です。
セットアップ
Split Tunnel の設定
デフォルトの除外リストに 100.64.0.0/10 が含まれていますが、これは Mesh IP のレンジ 100.96.0.0/12 を包含しています。結果として、Client → Mesh IP への通信がローカル NIC に送出され、タイムアウトします。
対処は単純で、除外リストから 100.64.0.0/10 を削除するだけ。CGNAT レンジですが、一般的な企業ネットワークでは使用されていないため、副作用はほぼありません。
Mesh 参加者間のアクセス制御
Gateway Network Policy は Mesh IP 間の通信に効きません。Mesh 参加者間のトラフィックは Cloudflare Edge 上でダイレクトにルーティングされるためです。
アクセス制御は以下の方法で行います：
- Split Tunnel：特定の Mesh IP を除外リストに入れると到達不能に
- OS ファイアウォール：各ノードの iptables/nftables で細粒度制御
IdP グループで「Mesh 利用者」を管理し、プロファイルを分離することで、チーム別の接続先制御も可能です。
Workers との統合が面白い
cf1:network バインディングを使うと、Workers から直接プライベートネットワークにアクセスできます。これは他の SASE ベンダーには存在しない機能です。
ユースケースの一例：
- 社内 API にアクセスする Slack Bot
- プライベート DB にアクセスするダッシュボード
- 社内システムを連携するワークフロー
- AI エージェント利用、連携（後述）
従来は Tunnel + パブリックホスト名で迂回していたものが、シンプルに書けるようになります。
AI エージェントとの相性
最近の AI エージェント（Claude Code, Cursor, Codex など）がステージング環境の DB や内部 API にアクセスしたい場面が増えています。これらのリソースがプライベート VPC 内にある場合、従来はインターネット公開かフル VPN 接続が必要でした。
Mesh を使うと、以下のようなワークフローが自然に実現できます：
1. コーディングエージェントの環境アクセス
開発者が「デプロイ状況を確認して」「ステージング DB の analytics を確認して」とエージェントに依頼した際、Mesh 経由でプライベートリソースに安全に到達できます。
2. Workers 上で動作するプロダクト組み込みエージェント
Agents SDK で構築したエージェントが cf1:network バインディングを使い、内部 API やデータベースにアクセス。MCP (Model Context Protocol) サーバーと組み合わせることで、スコープ付きのアクセス権限と監査証跡を維持できます。
3. パーソナルエージェントの安全な公開
自宅の Mac mini で動作する OpenClaw などのエージェントを、外出先のデバイスから安全に利用。パスワードだけの保護より堅牢で、シェルアクセスやファイルシステムアクセスを持つエージェントのリスクを低減できます。
wrangler.jsonc での設定例：
"vpc_networks": [
{ "binding": "MESH", "network_id": "cf1:network", "remote": true },
{ "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]
このバインディングを使うと、エージェントは env.MESH.fetch("http://10.0.1.50/api/data") で内部ホストに到達できます。個別のホスト登録は不要で、Mesh 内の任意のエンドポイントにアクセス可能です。
まとめ：Cloudflare Mesh と WAN の使い分け
Cloudflare 内での選択として、Mesh と WAN は明確に役割が分かれています。
Cloudflare Mesh を選ぶ場面：
- Linux ホストにソフトウェアを入れるだけで始めたい
- 複数クラウド / オンプレ拠点を簡単にメッシュ接続したい
- リモートユーザー、サーバー、エージェント間の相互通信が必要
- Workers からプライベートネットワークへのアクセスが必要
Cloudflare WAN を選ぶ場面：
- 既存のルーター・ファイアウォールと GRE/IPsec で統合したい
- L7 アプリ可視化やファイアウォール機能が必要
- Active-Active 回線冗長が必要
Mesh はソフトウェアベースで手軽に始められ、WAN は既存ネットワーク機器との統合とエンタープライズ級の機能を提供します。どちらも Cloudflare One プラットフォーム上で動作する点は共通です。
個人的には、ゼロからの構築やクラウド主体の環境であれば Mesh のシンプルさが魅力的です。Linux サーバーに apt install するだけで始められる手軽さは、検証環境の構築や開発用途で活きてくると思います。
参考リンク