AIエージェントの登場によって、プライベートネットワークへのアクセスの考え方は大きく変わりました。コーディングエージェントは、ステージングデータベースへのクエリの実行権限を要求し、本番エージェントは、社内APIの呼び出し権限を要求します。さらに、パーソナルAIアシスタントは、ホームネットワーク上で稼働しているサービスへのアクセス権限を要求します。クライアントは人間やサービスだけに留まらず、エージェントも加わります。エージェントは自律的に動作し、セキュリティを維持する必要があるインフラに対して明示的に承認していないリクエストを行います。
しかし、これには、エージェントがプライベートなリソースにアクセスする必要があるのに対し、そのためのツールは人間向けに設計されていて自律的なソフトウェアには適しないという、共通の問題があります。VPNは対話的なログインを要求し、SSHトンネルは手動設定が必要です。サービスを公開するのはセキュリティリスクがあります。また、これらの方法では、接続後にエージェントが実際に何をしているのか可視化できません。
本日は、プライベートネットワーク同士を接続し、エージェントに安全なアクセスを提供するCloudflare Meshを発表します。また、MeshはCloudflare開発者プラットフォームと統合されており、これによりWorkers、Durable Objects、およびAgents SDKで構築されたエージェントがプライベートインフラストラクチャに直接アクセスできるようになります。
Cloudflare OneのSASEおよびZero Trustスイートをご利用の場合は、すでにMeshをご利用いただけます。エージェント主体のワークロードを保護するために、新しい技術パラダイムは必要ありません。必要なのは、その時代に対応して設計されたSASEであり、それがCloudflare Oneです。Cloudflare Meshは、よりシンプルなセットアップを実現する新しい体験で、これまで使い慣れた接続手段であるWARP Connector（現在はCloudflare Meshノード）とWARP Client（現在はCloudflare One Client）を活用します。これらを組み合わせることで、人間・開発者・エージェントのトラフィックを扱うプライベートネットワークを構築できます。Meshは既存のCloudflare One環境に直接統合され、既存のGatewayポリシー、Accessルール、デバイスポスチャチェックがそのまま適用されます。
もし開発者として、エージェントやサービス、チームのためのプライベートネットワークをすぐに使いたい場合、Meshから始めるのが最適です。数分でセットアップし、ネットワークを接続し、トラフィックを保護できます。さらにMeshはCloudflare One上で動作するため、必要に応じて高度な機能（きめ細やかなトラフィック制御を行うGatewayネットワーク、DNS、HTTPポリシー、SSHおよびRDPセッション管理のためのAccess for Infrastructure、安全なWebアクセスを実現するブラウザ分離、機密データがネットワークから漏洩するのを防ぐDLP、SaaSセキュリティのためのCASBなど）へと拡張できます。そのため、最初から完璧な計画を立てる必要ななく、必要な時に労力をかけて移行することもありません。
従来のプライベートネットワーキングは、サーバーへのSSH接続、データベースへのクエリ、社内APIへのアクセスなどのように、クライアントとリソースを接続するものでした。変わったのは「誰がクライアントなのか」です。1年前であれば開発者やサービスでしたが、現在ではエージェントがその中心になりつつあります。
これは理論上の話ではありません。実際のエコシステムを見れば明らかです。ツールへのアクセスを提供するMCP（Model Context Protocol）サーバーの急増、プライベートリポジトリやデータベースを読み取る必要があるコーディングエージェント、自宅のハードウェア上で動く個人アシスタントなど、いずれもエージェントが必要なリソースにアクセスできることを前提としています。しかし、それらのリソースがプライベートネットワーク内に隔離されている場合、エージェントはアクセスできずに行き詰まります。
これにより、現在セキュリティで保護することが難しい3つのワークフローが発生します：
モバイルデバイスからパーソナルエージェントにアクセスする：例えば、自宅のMac miniでOpenClawを動かしており、スマートフォンやカフェのノートPC、職場のマシンからアクセスしたいとします。しかし、パスワード付きであってもインターネットに公開するのは脆弱性を露呈するリスクがあります。そのエージェントはシェル、ファイルシステム、そして自宅ネットワークへのアクセス権を持っているため、設定を誤ると誰でもアクセスできてしまう可能性があります。
コーディングエージェントにステージング環境へのアクセスを許可する：手元のノートPCでClaude CodeやCursor、Codexを使い、デプロイ状況の確認やステージングデータベースの分析、社内オブジェクトストアの読み取りをさせたいとします。しかし、これらのサービスはプライベートなクラウドVPC内に存在するため、インターネットに公開するか、ノートパソコン全体をVPCにトンネリングしない限りアクセスできません。
デプロイ済みエージェントをプライベートサービスに接続する：Cloudflare Workers上でAgents SDKを使用してエージェントを組み込んだアプリを開発している場合、それらのエージェントは社内APIの呼び出しやデータベースへのクエリなど、インターネットに公開されていないサービスにアクセスする必要があります。その際には、権限を限定し、監査ログを取り、認証情報の漏洩を防ぎながらプライベートアクセスを実現する必要があります。
Cloudflare Mesh：ユーザー、ノード、エージェントをつなぐ単一のプライベートネットワーク
Cloudflare Meshは、開発者にとって使いやすいプライベートネットワーキングの仕組みです。単一の軽量コネクタ、単一のバイナリで、個人用デバイス、リモートサーバー、ユーザーエンドポイントのすべてを接続します。パターンごとに別のツールをインストールする必要はありません。ネットワークに1つコネクタを置くだけで、あらゆるアクセスパターンに対応できます。
いったん接続すると、プライベートネットワーク内のデバイスは、330都市以上に広がるCloudflareのグローバルネットワークを経由してプライベートIPを介して相互通信することができ、ネットワークの信頼性と制御が向上します。
Meshを使用することで、単一のソリューションで前述のすべてのエージェントシナリオを解決できるようになります。
スマートフォンにCloudflare One Client（iOS版）を入れることで、Meshのプライベートネットワーク経由で自宅のMac mini上で動くOpenClawに、安全に接続できます。
ノートPCにCloudflare One Client（macOS版）を入れることでプライベートネットワークに接続できるようになり、コーディングエージェントがステージングベースやAPIに到達して、クエリを実行できるようになります。
Linuxサーバー上のMeshノードを使用すると、外部クラウド内のVPC同士を接続し、エージェントが外部プライベートネットワーク内のリソースやMCPにアクセスできるようになります。
MeshはCloudflare One Clientをベースにしているため、すべての接続にCloudflare Oneのセキュリティ機能がそのまま適用されます。GatewayポリシーはMeshのトラフィックに適用され、デバイスポスチャチェックによって接続デバイスの安全性が確認されます。さらにDNSフィルタリングによって不審な不審なルックアップも検知されます。追加の設定なしで、人間向けのトラフィックと同じポリシーでエージェントのトラフィックも保護できます。
Meshの登場により、「TunnelではなくMeshを使うべき場面はいつか？」という疑問が出てくるかもしれません。どちらも外部ネットワークをCloudflareに安全に接続する仕組みですが、用途が異なります。Cloudflare Tunnelは、Cloudflareがエッジから特定のプライベートサービス（例えば、Webサーバーやデータベース）へのトラフィックをプロキシする、単方向トラフィックに適しています。
一方、Cloudflare Meshは完全な双方向の多対多ネットワークを提供します。Mesh内のすべてのデバイスやノードは、プライベートIPを使って相互にアクセスできます。ネットワーク内で実行されているアプリケーションまたはエージェントは、それぞれのリソースごとにTunnelを用意しなくても、Mesh上の他のリソースを発見してアクセスできます。
Cloudflare Meshは、メッシュネットワークのメリット（耐障害性、高い拡張性、低遅延、高いパフォーマンス）を提供しつつ、すべての通信をCloudflare経由でルーティングすることで、Meshネットワークの主要な課題であるNATトラバーサル（NAT越え）を解決します。
インターネットの大半はNAT（Network Address Translation）の背後にあります。NATは、複数のデバイスが1つのグローバルIPアドレスを共有できる仕組みで、外部と内部のアドレスを変換して通信を成立させる仕組みです。2つのデバイスがNATの背後にある場合、直接接続ができず、中継サーバー（リレー）を経由する必要が出てきます。リレーの拠点が限られていると、多くのトラフィックがそこを通ることになり、遅延や信頼性の低下に繋がります。また、自前でリレーサーバーを構築することも可能ですが、そのために追加のインフラを管理する負担が発生します。
Cloudflare Meshは他と差別化するアプローチを採用しています：すべてのMeshトラフィックは、インターネット最大級のWebサイトのトラフィックを支えるのと同じインフラストラクチャである、Cloudflareのグローバルネットワークを経由します。地域をまたぐマルチクラウドトラフィックにおいて、これは一般的なインターネット経路よりも安定して高速です。Cloudflareのエッジ自体が通信経路となるため、性能が落ちるフォールバック経路も存在しません。
また、Cloudflare経由でルーティングされることで、すべてのパケットがCloudflareのセキュリティ基盤を通過します。これがCloudflare One上にMeshを構築する大きな利点です。セキュリティを後から追加する必要はなく、最初から組み込まれています。さらに、このグローバル基盤を活用することで、以下の機能が初日から提供されます。
50ノードと50ユーザーまで無料：すべてのCloudflareアカウントに含まれ、チーム全体とステージング環境全体を単一のプライベートネットワーク上で利用できます。
グローバルエッジルーティング：330以上の都市に展開された最適化されたバックボーンを利用できます。小数拠点のリレーサーバーに依存する必要も、性能が落ちるフォールバック経路もありません。
初日から使えるセキュリティ制御：MeshはCloudflare One上で動作します。Gatewayポリシー、DNSフィルタリング、DLP、トラフィック検査、デバイスポスチャチェックなどを同じプラットフォームで利用できます。まずはシンプルなプライベート接続から始め、必要に応じてGatewayでトラフィックをフィルタリングしたり、Access for InfrastructureでSSHやRDPのセッション制御を行ったり、DLPで機密データの流出を防ぐことができます。すべての機能がトグルボタン1つでオン/オフを切り替えられます。
高可用性：高可用性を有効にしたMeshノードを作成し、アクティブ/パッシブモードで同じトークンを使用して複数のコネクタを起動します。同じIPルートをアドバタイズするため、1つがダウンしても、トラフィックは自動的にフェールオーバーされます。
Meshは、外部クラウドにまたがるエージェントとリソースを接続しますが、Agents SDKを使用してWorkers上に構築されたエージェントからも接続できる必要があります。これを可能にするため、Workers VPCを拡張し、Meshネットワーク全体をWorkersとDurable Objectsから利用できるようにしました。
これにより、WorkersからCloudflare Meshネットワークへ接続でき、単一のbindingのfetch()呼び出しでネットワーク全体にアクセス可能になります。これはWorkers VPCの既存のCloudflare Tunnelサポートを補完するもので、ネットワークを保護する方法において、より多くの選択肢を提供します。さらに、wrangler.jsoncファイルで、接続したいネットワーク全体を指定できるようになりました。Meshネットワークにバインドするには、アカウントのMeshネットワークを指す予約キーワードcf1:networkを使用します。
"vpc_networks": [
{ "binding": "MESH", "network_id": "cf1:network", "remote": true },
{ "binding": "AWS_VPC", "tunnel_id": "350fd307-...", "remote": true }
]
その後、Workerまたはエージェントのコード内でこの接続を使用することができます。
export default {
async fetch(request: Request, env: Env, ctx: ExecutionContext) {
// Reach any internal host on your Mesh, no pre-registration required
const apiResponse = await env.MESH.fetch("http://10.0.1.50/api/data");
// Internal hostname resolved via tunnel's private DNS resolver
const dbResponse = await env.AWS_VPC.fetch("http://internal-db.corp.local:5432");
return new Response(await apiResponse.text());
},
};
開発者プラットフォームをMeshネットワークに接続することで、プライベートデータベース、社内API、MCPにセキュアにアクセスできるWorkersを構築でき、アプリにエージェント機能を提供するクロスクラウドエージェントやMCPを構築することができます。さらに、エージェントがシステム全体を横断的に監視し、ログを突き合わせてリアルタイムで最適化を提案するといった使い方も可能になります。
Cloudflare Mesh、Workers VPC、Agents SDKを組み合わせることで、Cloudflareと外部クラウドの両方にまたがる、エージェント向けの統一されたプライベートネットワークが実現します。接続と実行環境を一体化することで、エージェントは世界中どこにあるリソースにも安全にアクセスできるようになります。
Meshノードは、サーバーやVM、コンテナに相当します。これらはCloudflare One Clientのヘッドレス版を実行し、Mesh用のIPアドレスを持ちます。サービス同士はプライベートIPを使い、Cloudflareのエッジを経由して双方向に通信します。
デバイスは、ノートPCやスマートフォンです。Cloudflare One Clientを実行し、Meshノードへ直接接続できます。SSH接続、データベースへのクエリ、API呼び出しなどをすべてプライベートIPで行えます。ローカルのコーディングエージェントも、この接続を利用してプライベートリソースにアクセスします。
Workers上のエージェントは、Workers VPCのNetwork bindingを通じてプライベートサービスにアクセスします。ネットワーク単位でアクセス権が制御され、MCPによって利用可能な操作が制限されます。ネットワークが「どこにアクセスできるか」を制御し、MCPサーバーが「何ができるか」を制御します。
現行バージョンのMeshは、安全で統合された接続の基盤を提供します。しかし、エージェント主体のワークフローが複雑になるにつれて、単なる接続性を超え、より直感的に管理でき、かつ「誰（または何）が通信しているか」を細かく把握できるネットワークが求められます。そこで、今年中に以下の機能を開発予定です。
今夏、Cloudflare Tunnelで提供しているホスト名ルーティングをMeshにも拡張します。これにより、wiki.localやapi.staging.internalといったプライベートホスト名でトラフィックを受け付けられるようになります。IPアドレスの管理や名前解決を意識する必要はありません。IPではなく名前でサービスにルーティングできます。動的IPやオートスケーリング、短命なコンテナを使う環境では、ルーティング管理の手間を大幅に減らすことができます。
現在は、ssh 100.64.0.5のようにMesh IPでノードにアクセスしますが、皆さんが期待するのは、postgres-staging、api-prod、nikitas-openclawのように名前でアクセスできることでしょう。
今年後半にはMesh DNSを提供予定で、Meshに参加したすべてのノードやデバイスに自動でルーティング可能な内部ホスト名が割り当てられます。DNSの設定や手動登録は不要です。例えば、postgres-stagingという名前のノードを追加すると、Mesh上のどのデバイスからでもpostgres-staging.meshで正しいMesh IPに解決されます。
ホスト名ルーティングと組み合わせることで、IPアドレスを意識したり管理したりせずに ssh postgres-staging.meshやcurl http://api-prod.mesh:3000/healthのようにアクセスできるようになります。
現在、MeshノードはCloudflareエッジに対して認証されますが、ネットワーク上では同一の識別として扱われます。一方、デバイスはCloudflare Oneクライアントを介してユーザーIDで認証されますが、ノードにはGatewayポリシーが区別できる個別のルーティング可能なIDがまだ実装されていません。
それを変えたいと思います。MeshのIDベースのルーティングで、各ノード、各デバイス、最終的には各エージェントに固有のIDを持たせ、それに基づいてポリシーを適用できるようにします。IPアドレスではなく、「誰が」「何が」接続しているかでルールを定義できるようになります。
これはエージェントにとって最も重要です。現在、Workers上で実行しているエージェントがVPC binding経由でツールを呼び出すと、ターゲットサービスはWorkerからのリクエストであることは確認できますが、どのエージェントが呼び出しているのか、誰が承認者なのか、どのスコープが許可されているのかはわかりません。Mesh側では、ノートPC上のローカルコーディングエージェントがステージング用のサービスに到達すると、Gatewayはデバイスのアイデンティティを認識しますが、エージェントのアイデンティティは認識しません。
現在、当社はエージェント自身がネットワーク上でアイデンティティを持つ仕組みの実現に取り組んでいます：
Principal / Sponsor：操作を許可した人（例：プラットフォームチームのNikita）
Agent：実行するAI（例：デプロイ支援エージェント、セッション#abc123）
Scope：エージェントに許可された操作範囲（例：デプロイの参照のみ、ロールバック実行など）
これにより、「Nikitaのエージェントからの読み取りは許可するが、書き込みは本人のみ」といったポリシーを書けるようになります。エージェントのトラフィックを人間のトラフィックと分離して制御でき、Nikitaに影響を与えることなく、エージェントのネットワークアクセスだけを取り消すことができます。
基盤はすでに整っています。Meshノードはノードごとのトークンでプロビジョニングされ、デバイスはユーザー単位のアイデンティティで認証され、Workers VPC bindingsはサービスごとのアクセスをスコープとします。欠けている部分は、これらのアイデンティティをポリシー層に表示して、Gatewayがそれらに基づいてルーティングとアクセスに関する決定を行えるようにすることです。私たちは、それを構築しています。
現在、MeshノードはVMや物理サーバー上で動作しますが、現代のインフラはコンテナ（Kubernetesポッド、Docker Composeスタック、一過性のCI/CDランナーなど）で実行されることが増えています。当社は現在、任意のコンテナ環境にMeshノードを追加できるMeshのDockerイメージを開発中です。
これにより、Docker ComposeにMeshのサイドカーを追加するだけで、スタック内のすべてのサービスにプライベートネットワーク接続を提供できます。たとえばステージング環境のコンテナから、本番VPC内のデータベースへMesh経由でアクセスする、といったことが可能になります。どちらのサービスも公開エンドポイントを持つ必要はありません。
また、ビルドやテスト中にプライベートインフラストラクチャにアクセスできるCI/CDパイプラインにも有用です。GitHub ActionsのランナーがMeshコンテナを起動してネットワークに参加し、ステージング環境に対して統合テストを実行し、終了後に破棄するといった使い方ができます。VPN認証情報を管理する必要も、トンネルを維持する必要もありません。コンテナが終了すればノードも消失します。
MeshのDockerイメージは、、今年後半に提供される予定です。
アイデンティティやルーティング機能は今後も進化していきますが、安全で統一されたネットワークの基盤はすでに利用可能です。クラウドの橋渡しとエージェントの保護を、わずか数分で始められます。
Cloudflare Meshを始める：Cloudflare ダッシュボードのNetworking > Meshに移動します。最大50ノード、50ユーザーまで無料です。
Agents SDKとWorkers VPCを使用してエージェントを構築する：Agents SDK（`npm i agents`）をインストールし、Workers VPCクイックスタートに従い、プライベートバックエンドアクセスを持つリモートMCPサーバーを構築します。
すでにCloudflare Oneをご利用されている方であれば、既存の構成のままMeshを利用いただけます。Gatewayポリシー、デバイスポスチャチェック、Accessルールは自動的にMeshの通信にも適用されます。最初のノードを追加するには、Meshのドキュメントを参照してください。