Cloudflare は Agents Week 2026 で正式に Cloudflare Mesh を発表し、従来の VPN や SSH トンネルに代わる双方向多対多のネットワークトポロジーを採用し、AI 代理が Zero Trust ポリシーフレームワーク内で直接プライベートインフラにアクセスできるようにし、50ノードから始める無料プランも提供します。 （前提：Cloudflare が Kimi K2.5 に接続してから毎日700億トークンを処理、安全監査コストが77%削減） （補足：Cloudflare は Coinbase か Stripe か？この決定が AI 代理の支払い基準を決める）この記事の目次Toggle* VPN の死角：それはあなたが常にいることを前提としている* Mesh の技術基盤：双方向、全域、自動NAT穿透* Zero Trust ポリシーの自動適用：代理トラフィックに* ロードマップと未実現の約束* 開発者が今できること午前3時、あなたの AI Agent は最初の1万回の API リクエストを送ろうとしているが、VPN はまだウィンドウの切り替え中で、手動ログインを待ち続けている。これは 2026 年のエンジニアリングチームの現実だ。AI 代理が自主的にデータベースをクエリし、プライベートサービスに接続し始めると、私たちは気づく：既存のネットワークツール（VPN、SSH、Bastion Host）はすべて「人間」向けに設計されている。クリック、インタラクション、人間の介入が必要だ。全自動の AI 時代に直面し、これらのツールはむしろシステムの最も脆弱な単点故障となる。そこで、Cloudflare は昨日（14日）、年間イベント「Agents Week 2026」で正式に **Cloudflare Mesh** を発表し、自らこの構造的ギャップを埋めることを宣言した。AI 代理向けに設計されたネイティブなプライベートネットワークインフラを用いて、従来の人間操作用ツールに取って代わる。### VPN の死角：それはあなたが常にいることを前提としている従来の VPN の信頼モデルは暗黙の前提に基づいている：誰かが認証し、接続を開始し、アクセス行為に責任を持つ「人」がいる。これは AI 代理時代には困難だ。代理はインタラクティブな MFA のプロンプトを待たない。手動で SSH トンネルを設定できない。さらに重要なのは、一度 VPN 接続が確立されると、代理が何をしているのかほとんどわからないことだ：数ミリ秒であなたが予期しなかったデータにアクセスできる。もう一つの極端な選択肢は、サービスをパブリックネットワークに公開することだが、これは鍵を扉に差し込むのと同じだ。Cloudflare は発表の中で、これら三つの方法の共通の死角を直接指摘している：「これらの方案はすべて、代理が実際に何をしているのかを見ることができない。」Cloudflare Mesh の設計出発点は、まず可視性を解決し、その後に接続性を考えることだ。### Mesh の技術基盤：双方向、全域、自動NAT穿透Cloudflare の既存製品 Cloudflare Tunnel と比較すると、Mesh の最も重要な構造的違いは方向性にある。Tunnel は一方向：外部からあなたのインフラへトラフィックが流入する。Mesh は双方向多対多（bidirectional, many-to-many）：どのノードも能動的に他の任意のノードへ接続を開始でき、トラフィックは Cloudflare の世界中330都市のネットワークバックボーンを通じてルーティングされる。この設計は、エンジニアが最も頭を悩ませる問題、NAT 穿透を直接解決している。家庭用ネットワーク、オフィスのファイアウォール、クラウド VPC：複雑な NAT 設定は通常、手動でポートフォワーディングルールを設定する必要があるが、Mesh はこれをすべて自動化している。開発者にとっては、Cloudflare Developer Platform との統合が最も魅力的だ。wrangler.jsonc に Mesh をバインドすれば、Workers や Durable Objects は env.MESH.fetch() を通じてプライベートサービスを呼び出せる。外部 API を呼び出すのと同じ感覚だが、トラフィックは Cloudflare の Zero Trust ポリシーフレームワークから一切離れない。また、ブランド統合も行われている。元の WARP Connector は「Cloudflare Mesh node」に改名され、WARP Client は「Cloudflare One Client」に改名され、Mesh 製品ラインに統一された。### Zero Trust ポリシーの自動適用：代理トラフィックにCloudflare は、Mesh は新しい独立した製品ではなく、Cloudflare One SASE パッケージのネイティブな拡張であると強調している。これにより、企業の既存の Gateway ポリシー、デバイスのヘルスチェック、データ漏洩防止（DLP）などが、代理によるトラフィックに対しても自動的に適用される。 これは企業のセキュリティチームにとって非常に重要だ。AI 代理の問題は、「アクセスできるかどうか」だけでなく、「アクセス後に誰が管理しているか」も関係している。Mesh は代理トラフィックを既存のガバナンスフレームに組み込み、管理しやすくしている。価格設定も寛容で、無料枠は50ノードと50ユーザーまで。小規模チームや個人開発者の「家庭用実験室の代理アクセス」にはほぼ敷居がない。### 路線図と未実現の約束注目すべきは、Cloudflare の発表で詳細に述べられている複数のコア機能は、現時点ではロードマップにあり、まだリリースされていないことだ。* **Hostname Routing**（代理が wiki.local や api.staging.internal のような内部ネットドメイン名を直接解決してアクセスできる機能）は2026年夏にリリース予定* **Mesh DNS**（各ノードに postgres-staging.mesh のようなホスト名を自動割り当て）は遅れる* **Identity-Aware Routing** — トラフィックが主体代理（Principal）、スポンサー（Sponsor）、子代理（Agent）から発信されたかを区別できる機能は「計画中」で、明確なスケジュールは未定。コンテナサポート（Docker、Kubernetes、CI/CD 環境で Mesh ノードを展開）は2026年末まで待つ必要がある。つまり、現時点で使える Mesh は、Workers/Durable Objects の VPC バインドとノード間の基本的な通信能力に限られる。より詳細な代理のアイデンティティ管理は今後の課題だ。### 開発者が今できることCloudflare One エコシステムに既に参加しているチームは、Mesh の申請なしで、既存アカウントから直接有効化できる。Workers VPC の統合には、wrangler.jsonc に Mesh のバインドを追加し、その後 env.MESH.fetch() でプライベートエンドポイントを呼び出す。評価中のチームには、次のシナリオがおすすめだ：コーディングエージェントが staging データベースにアクセスする、またはクラウド上の代理がオフィス内ネットワークの API を呼び出す。これらの基本的な通信は今日からテスト可能だ。Hostname Routing のリリース前は、IP:ポート直アクセスも選択肢だが、理想的ではない。ドメイン名解決による代理の「内網のような」体験は、夏以降に期待される。
Cloudflare は Mesh を導入し VPN に取って代わる：AI 代理があなたの内部ネットワークに安全にアクセスできるようにし、無料で50ノードを提供
Cloudflare は Agents Week 2026 で正式に Cloudflare Mesh を発表し、従来の VPN や SSH トンネルに代わる双方向多対多のネットワークトポロジーを採用し、AI 代理が Zero Trust ポリシーフレームワーク内で直接プライベートインフラにアクセスできるようにし、50ノードから始める無料プランも提供します。
（前提：Cloudflare が Kimi K2.5 に接続してから毎日700億トークンを処理、安全監査コストが77%削減）
（補足：Cloudflare は Coinbase か Stripe か？この決定が AI 代理の支払い基準を決める）
この記事の目次
Toggle
午前3時、あなたの AI Agent は最初の1万回の API リクエストを送ろうとしているが、VPN はまだウィンドウの切り替え中で、手動ログインを待ち続けている。
これは 2026 年のエンジニアリングチームの現実だ。AI 代理が自主的にデータベースをクエリし、プライベートサービスに接続し始めると、私たちは気づく：既存のネットワークツール（VPN、SSH、Bastion Host）はすべて「人間」向けに設計されている。クリック、インタラクション、人間の介入が必要だ。
全自動の AI 時代に直面し、これらのツールはむしろシステムの最も脆弱な単点故障となる。
そこで、Cloudflare は昨日（14日）、年間イベント「Agents Week 2026」で正式に Cloudflare Mesh を発表し、自らこの構造的ギャップを埋めることを宣言した。AI 代理向けに設計されたネイティブなプライベートネットワークインフラを用いて、従来の人間操作用ツールに取って代わる。
VPN の死角：それはあなたが常にいることを前提としている
従来の VPN の信頼モデルは暗黙の前提に基づいている：誰かが認証し、接続を開始し、アクセス行為に責任を持つ「人」がいる。これは AI 代理時代には困難だ。
代理はインタラクティブな MFA のプロンプトを待たない。手動で SSH トンネルを設定できない。さらに重要なのは、一度 VPN 接続が確立されると、代理が何をしているのかほとんどわからないことだ：数ミリ秒であなたが予期しなかったデータにアクセスできる。
もう一つの極端な選択肢は、サービスをパブリックネットワークに公開することだが、これは鍵を扉に差し込むのと同じだ。Cloudflare は発表の中で、これら三つの方法の共通の死角を直接指摘している：「これらの方案はすべて、代理が実際に何をしているのかを見ることができない。」
Cloudflare Mesh の設計出発点は、まず可視性を解決し、その後に接続性を考えることだ。
Mesh の技術基盤：双方向、全域、自動NAT穿透
Cloudflare の既存製品 Cloudflare Tunnel と比較すると、Mesh の最も重要な構造的違いは方向性にある。
Tunnel は一方向：外部からあなたのインフラへトラフィックが流入する。Mesh は双方向多対多（bidirectional, many-to-many）：どのノードも能動的に他の任意のノードへ接続を開始でき、トラフィックは Cloudflare の世界中330都市のネットワークバックボーンを通じてルーティングされる。
この設計は、エンジニアが最も頭を悩ませる問題、NAT 穿透を直接解決している。家庭用ネットワーク、オフィスのファイアウォール、クラウド VPC：複雑な NAT 設定は通常、手動でポートフォワーディングルールを設定する必要があるが、Mesh はこれをすべて自動化している。
開発者にとっては、Cloudflare Developer Platform との統合が最も魅力的だ。wrangler.jsonc に Mesh をバインドすれば、Workers や Durable Objects は env.MESH.fetch() を通じてプライベートサービスを呼び出せる。外部 API を呼び出すのと同じ感覚だが、トラフィックは Cloudflare の Zero Trust ポリシーフレームワークから一切離れない。
また、ブランド統合も行われている。元の WARP Connector は「Cloudflare Mesh node」に改名され、WARP Client は「Cloudflare One Client」に改名され、Mesh 製品ラインに統一された。
Zero Trust ポリシーの自動適用：代理トラフィックに
Cloudflare は、Mesh は新しい独立した製品ではなく、Cloudflare One SASE パッケージのネイティブな拡張であると強調している。
これにより、企業の既存の Gateway ポリシー、デバイスのヘルスチェック、データ漏洩防止（DLP）などが、代理によるトラフィックに対しても自動的に適用される。
これは企業のセキュリティチームにとって非常に重要だ。AI 代理の問題は、「アクセスできるかどうか」だけでなく、「アクセス後に誰が管理しているか」も関係している。Mesh は代理トラフィックを既存のガバナンスフレームに組み込み、管理しやすくしている。
価格設定も寛容で、無料枠は50ノードと50ユーザーまで。小規模チームや個人開発者の「家庭用実験室の代理アクセス」にはほぼ敷居がない。
路線図と未実現の約束
注目すべきは、Cloudflare の発表で詳細に述べられている複数のコア機能は、現時点ではロードマップにあり、まだリリースされていないことだ。
コンテナサポート（Docker、Kubernetes、CI/CD 環境で Mesh ノードを展開）は2026年末まで待つ必要がある。
つまり、現時点で使える Mesh は、Workers/Durable Objects の VPC バインドとノード間の基本的な通信能力に限られる。より詳細な代理のアイデンティティ管理は今後の課題だ。
開発者が今できること
Cloudflare One エコシステムに既に参加しているチームは、Mesh の申請なしで、既存アカウントから直接有効化できる。Workers VPC の統合には、wrangler.jsonc に Mesh のバインドを追加し、その後 env.MESH.fetch() でプライベートエンドポイントを呼び出す。
評価中のチームには、次のシナリオがおすすめだ：コーディングエージェントが staging データベースにアクセスする、またはクラウド上の代理がオフィス内ネットワークの API を呼び出す。これらの基本的な通信は今日からテスト可能だ。
Hostname Routing のリリース前は、IP:ポート直アクセスも選択肢だが、理想的ではない。ドメイン名解決による代理の「内網のような」体験は、夏以降に期待される。