Cloudflare Mesh をリリース - ユーザー、ノード、エージェント、Workers 向けの安全なプライベートネットワーキング

 (blog.cloudflare.com)
5 ポイント 投稿者 GN⁺ 16 일 전 | 5件のコメント | WhatsAppで共有
  • AIエージェントが プライベートネットワークリソース に安全にアクセスする必要がある時代において、従来のVPNやSSHトンネルのようなツールには、人間ではなく自律ソフトウェアには適していない構造的な限界がある
  • Cloudflare Mesh は、1つの軽量コネクタで個人デバイス、リモートサーバー、エージェントをすべて接続する 双方向プライベートネットワーキング ソリューション
  • Workers VPC を拡張し、Agents SDK で構築したエージェント が Mesh ネットワークに直接アクセス可能で、単一バインディングの fetch() 呼び出しで内部サービスへの接続をサポート
  • 既存の Cloudflare One ユーザーは追加設定なしで、Gateway ポリシー、Access ルール、デバイスポスチャチェックが Mesh トラフィックに 自動適用
  • 50ノードおよび50ユーザーまで無料 提供、さらに330以上の都市にわたるグローバルエッジルーティングにより、スタートアップからエンタープライズまで即座に導入可能

エージェント時代のプライベートネットワークアクセスの課題

  • AIエージェントがステージングデータベースへのクエリ、内部API呼び出し、ホームネットワーク上のサービスへのアクセスなど、プライベートリソースに到達 しなければならないワークフローが急増
  • 既存ツールの限界:
    • VPN は インタラクティブログイン が必要
    • SSH トンネルは 手動設定 が必要
    • サービスをパブリックに公開すると セキュリティリスク が発生
    • エージェントが接続後に実際に何をしているかについての 可視性の欠如

3つの主要ワークフロー

  • 個人エージェントのリモートアクセス: Mac mini で OpenClaw を実行し、モバイルやノートPCからアクセスする際、パブリック公開するとシェル・ファイルシステム・ネットワークアクセスがすべて開放され、1つの設定ミスでセキュリティリスク が生じる
  • コーディングエージェントのステージング環境アクセス: Claude Code、Cursor、Codex のようなツールがプライベートクラウド VPC 内のサービスにアクセスするには、インターネット公開または VPC 全体のトンネリングが必要になる状況
  • デプロイ済みエージェントのプライベートサービス接続: Agents SDK ベースの Workers エージェントが内部 API やデータベースにアクセスする際、スコープ指定された権限、監査証跡、認証情報漏えいの防止 が必要

Cloudflare Mesh の構成と動作方式

  • 1つの軽量コネクタ（バイナリ）で個人デバイス、リモートサーバー、ユーザーエンドポイントをすべて接続
  • 接続されたデバイスは プライベートIP を通じて、Cloudflare のグローバルネットワーク（330以上の都市）を経由し双方向通信を行う
  • 既存の WARP Connector は Cloudflare Mesh node に、WARP Client は Cloudflare One Client に名称変更
  • 具体的な活用シナリオ:
    • iOS 向け Cloudflare One Client で、モバイルからローカルの Mac mini 上の OpenClaw に安全に接続
    • macOS 向け Cloudflare One Client で、ノートPC上のコーディングエージェントがステージングデータベースや API にアクセス
    • Linux サーバー上の Mesh ノード で外部クラウド VPC 同士を接続し、エージェントが外部プライベートネットワーク上のリソースや MCP にアクセス

Mesh と Tunnel の違い

  • Cloudflare Tunnel: Cloudflare エッジから特定のプライベートサービス（Web サーバー、データベース）への 単方向トラフィック のプロキシに適している
  • Cloudflare Mesh: すべてのデバイスとノードがプライベートIPで相互にアクセスできる 双方向・多対多（many-to-many）ネットワーク を提供
    • リソースごとに個別の Tunnel を設定する必要がなく、Mesh に接続されたすべてのリソースにアクセス可能

Cloudflare ネットワークの活用: NAT 越えの問題を解決

  • インターネットの大半は NAT（Network Address Translation） の背後にあり、2台のデバイスがともに NAT の背後にある場合、直接接続に失敗するとリレーサーバーに依存することになる
  • リレーインフラの PoP（Point of Presence）が限定的だと、かなりのトラフィックがリレー経由となり、遅延と信頼性低下 が発生
  • Cloudflare Mesh はすべてのトラフィックを Cloudflare のグローバルネットワークへルーティングし、別個のリレーサーバーなしで 一貫した性能を提供
  • クロスリージョン・マルチクラウドのトラフィックにおいて、パブリックインターネットルーティングより継続的に 優れた性能 を発揮

主な提供内容

  • 50ノード・50ユーザー無料: すべての Cloudflare アカウントに含まれる
  • グローバルエッジルーティング: 330以上の都市、最適化されたバックボーンルーティング、性能の落ちるフォールバック経路なし
  • Day 1 からのセキュリティ制御: Gateway ポリシー、DNS フィルタリング、DLP、トラフィック検査、デバイスポスチャチェックをすべて同一プラットフォーム上で有効化でき、各機能は トグル1つで切り替え 可能
  • 高可用性（HA）: 同一トークンで複数のコネクタを active-passive モードで実行し、同じ IP ルートを広告して障害時に 自動フェイルオーバー

Workers VPC 統合

  • Workers VPC を拡張し、Mesh ネットワーク全体を Workers と Durable Objects からアクセス可能 にする
  • wrangler.jsonc ファイルで cf1:network 予約キーワードを使って Mesh ネットワークにバインド:
    • "vpc_networks": [{ "binding": "MESH", "network_id": "cf1:network", "remote": true }]
  • Worker コード内で env.MESH.fetch("http://10.0.1.50/api/data";) の形で プライベートホストへ直接アクセス でき、事前登録は不要
  • Tunnel ベースの VPC バインディングと併用可能で、ネットワークセキュリティ方式の選択肢を拡大
  • これにより、プライベートデータベース、内部 API、MCP に安全にアクセスする クロスクラウドエージェントおよび MCP を構築可能

全体アーキテクチャの構成要素

  • Mesh ノード: サーバー、VM、コンテナ上でヘッドレス版の Cloudflare One Client を実行し、Mesh IP を割り当てて サービス間の双方向プライベートIP通信 を実現
  • デバイス: ノートPCやスマートフォンで Cloudflare One Client を実行して Mesh ノードへ直接アクセス — SSH、データベースクエリ、API 呼び出しをすべてプライベートIPで処理
  • Workers エージェント: Workers VPC Network バインディングを通じてプライベートサービスにアクセスし、ネットワークはエージェントの到達範囲を制御 し、MCP サーバーはエージェントの挙動を制御 する

今後のロードマップ

  • ホスト名ルーティング

    • この夏、Cloudflare Tunnel の ホスト名ルーティングを Mesh に拡張 予定
    • wiki.local や api.staging.internal のようなプライベートホスト名でトラフィックをルーティングし、IP リスト管理が不要 に
    • 動的 IP、オートスケーリンググループ、一時的なコンテナ環境でのルーティング複雑性を解消

  • Mesh DNS

    • 今年後半、Mesh に参加するすべてのノードとデバイスに 自動的にルーティング可能な内部ホスト名 を付与予定
    • DNS 設定や手動レコードなしで postgres-staging.mesh にアクセス可能
    • ホスト名ルーティングと組み合わせ、ssh postgres-staging.mesh や curl http://api-prod.mesh:3000/health のような IP アドレスなしのアクセス を実現

  • ID 認識ルーティング（Identity-aware Routing）

    • 現在の Mesh ノードはネットワークレイヤーで 共有 ID を使用し、デバイスはユーザー ID で認証されるが、ノードには Gateway ポリシーが識別できる個別のルーティング ID がない
    • 目標: 各ノード、デバイス、エージェントに 固有 ID を付与 し、IP 範囲ではなく接続主体ベースでポリシーを記述
    • エージェント ID モデル構想:
      • Principal/Sponsor: 行為を承認した人
      • Agent: 行為を実行する AI システム（セッション ID を含む）
      • Scope: エージェントに許可された作業範囲
    • これにより、「読み取りはエージェント可、書き込みは直接の人間のみ可」のような 細かなポリシー を実装予定
    • インフラはすでに構築済み（ノードごとのトークン、ユーザーごとの ID、サービスごとの VPC バインディング）で、ポリシーレイヤーでの ID 可視性 が現在実装中の部分

  • Mesh コンテナ対応

    • 現在 Mesh ノードは VM・ベアメタル Linux サーバーで実行
    • Kubernetes Pod、Docker Compose スタック、CI/CD ランナーなど コンテナ環境向け Mesh Docker イメージ を準備中
    • Docker Compose スタックに Mesh サイドカーを追加し、スタック内の全サービスにプライベートネットワークアクセスを付与
    • CI/CD パイプラインでは GitHub Actions ランナーが Mesh コンテナイメージを取得してネットワークに参加し、ステージング環境に対する統合テストを実行した後、コンテナ終了時にノードを自動削除
    • 今年後半に提供予定

開始方法

  • Cloudflare Mesh: Cloudflare ダッシュボードの Networking > Mesh から開始、50ノード・50ユーザーまで無料
  • Agents SDK + Workers VPC: npm i agents でインストールし、Workers VPC クイックスタートとリモート MCP サーバーガイドを参照
  • 既存の Cloudflare One ユーザー: 既存設定と互換性があり、Gateway ポリシー・デバイスポスチャチェック・Access ルールが Mesh トラフィックに自動適用

関連記事

5件のコメント

 
eoeoe 15 일 전

もともと自宅のコンピューターにトンネルを設定してRDPだけ使っていたんですが……エージェントも一度試してみないとですね！
 
yangeok 16 일 전

価格が無料で、セキュリティさえ良ければ無条件で使いますね（笑）

こういうのを見ると、DevOpsもどんな方向に変わっていくのか、だいたい見えてきますね
 
xguru 16 일 전

メッシュと聞いてTailscaleと似たものかと思ったのですが、少し違うんですね。
TailscaleのようなP2P方式ではなく、CFのエッジネットワークを経由する構成なので、
GatewayポリシーやDLPのようなセキュリティ機能が自動で適用され、
Workers/Agents SDKでは fetch() 一行でプライベートサービスを呼び出せるのが差別化ポイントですね。
自分は普通にTailscaleを使うかな…。
 
minhoryang 16 일 전

むしろ、TailscaleのDERPリレーの役割をCloudflare Edgeが担うことになるので、より強力な競合が現れたのではないかと思いました。TailscaleもP2Pができない場合はDERPリレー経由で通信を送るので。「リレーインフラのPoP(Point of Presence)が限定的だと、かなりの部分のトラフィックがリレーを経由することになり、遅延や信頼性の低下が発生する」という部分は、特にTailscaleのことを言っているように感じました。私は両方を混ぜて使うことになりそうです。さっそく実験してきます
 
minhoryang 15 일 전

Cloudflare Edge も 100.96.0.0/100. で始まる帯域を使っているんですね。Tailscale と一緒に使おうとしたのですが、インストールから利用まで少しずつ難しい点があります。私のように同時に使おうとしている方は参考にしてください。