本日は、複数のクラウドにまたがるアプリをより簡単に構築できる新機能「Workers VPC（仮想プライベートクラウド）」のプレビューをご紹介します。
Workers VPC は、従来の仮想プライベートクラウド（VPC）を、特定のクラウドリージョンに依存しないネットワークとコンピューティング環境に合わせて現代的に再構築したものです。さらに、Workers VPC Private Linksで補完し、クラウド間での構築を容易にしています。この2つの機能により、Workersに以下の新しい能力が加わります：
Cloudflare上アプリのリソースを独立した環境にまとめます。Workers VPC内にあるリソース同士だけが通信できるようになり、アプリ間の通信を安全に分離できます（「Workers VPC」）。
Workers VPCを既存のパブリック/プライベート上のクラウドのVPCと接続します。これにより、まるで1つのVPC内にあるかのように、双方向に通信できます（「Workers VPC Private Link」）。
Workers VPCとWorkers VPC Private Linkを使うことで、Cloudflareと外部クラウド間の双方向接続を可能にします
外部VPCにリンクすると、Workers VPCは基盤となるリソースに直接アドレス指定できるようになるため、アプリケーション開発者は、ネットワーク層を意識することなく、アプリケーション層に集中した開発が可能になります。これは「クラウドをまたいで使える一つのVPC」のようなもので、サービス同士が自動でお互いを認識できる機能も最初から備わっています。
私たちは現在、Cloudflareの既存のプライベートネットワーク機能を土台として、このWorkers VPCを開発中で、2025年後半の提供を予定しています。私たちはこの製品のプレビュー版を早期に共有し、皆様からのご意見・ご要望を伺いたいと考えています。
複数のプライベートクラウド間でのアプリの構築は難しい
最近、Cloudflare Workersを選ぶ開発者が増加しており、リッチでステートフルなアプリケーションが構築されています。Workersの元々の想定使用範囲をはるかに超えて、システム全体を近代化し、より多くのビジネスロジックを移行するための基盤として使われています。Workersを選択されたお客様からは、外部データベースにアクセスするリアルタイムコラボレーションアプリケーション、セキュリティで保護されたAPIを使用する大規模なアプリケーション、可能な限りエンドユーザーに近いエージェントにビジネスロジックを公開するモデルコンテキストプロトコル（MCP）サーバーなど、さまざまな用途に使われています。
そして今、外部クラウドに最後に立ちはだかる壁はVPC（仮想プライベートクラウド）です。VPCはセキュリティ面で安心をもたらしますが、正直言って、Workersのようなモダンなプラットフォームでアプリを構築する場合は、かなりの足かせになります。これは暗黙的にレガシーVPCを使うように仕向け、ユーザーのデータやアプリの囲い込みし、ロックインさせることによるものです。
お客様からは「VPCが障壁になっている」という声を何度も聞きました。しかし、企業ポリシー上、VPCが義務付けられているのには十分な理由があるのも事実です。したがって、Workersからプライベートリソースにアクセスするには、1) 安全なアクセスを提供するために認証を実行する新しいパブリックAPIを作成するか、2) アクセスしたいリソースごとにCloudflare TunnelsとZero Trustを設定して拡張するかの、どちらかの方法を取る必要があります。これは構築を始める前に、かなりの複雑な手順を課すことになります。
当社ではWorkers上ですべてを構築できるよう、ストレージとコンピューティングのオプションをご利用いただけますが、アプリケーションやデータを一晩で移動できないことも理解しています。しかし、少なくとも現在において、お客様が既存のプライベートAPIとデータベースを使用して最新のアプリケーション、AIエージェント、リアルタイムのグローバルアプリケーションを構築するために、自由にWorkersを選択できるべきだと考えています。それがWorkers VPCを立ち上げた理由です。
私たちは、VPCを中心に構築することの難しさを身をもって知ってきました。2024年には、Hyperdriveでプライベートデータベースのサポートを発表しました。これにより、Cloudflare Workersから外部のVPC内にあるデータベースへ、Cloudflare Tunnelを使って接続できるようになりました。ポイントツーポイントの接続方式としては、非常にうまく機能しています。ただし、このソリューションには限界があり、外部クラウド内のリソースごとにCloudflare Tunnelを管理とスケーリングを行わなければならず、大規模で複雑なアーキテクチャには向いていないという課題があります。
私たちは、Workersを使ってシステムを近代化していく中でも、外部クラウドのリソースに簡単かつスケーラブルにアクセスできる、非常にシンプルな仕組みを提供したいと考えています。そして、これまでに培ってきたMagic WANやMagic Cloud Networkingの開発経験を活かして、それを可能にします。
そのため、Workers VPCでVPCをグローバルに展開します。また、Workers VPC Private Linksを使って従来のプライベートネットワークに接続できるようにします。これは、「安全で、グローバルで、複数クラウドに対応したアプリを、自由にWorkersで構築できる世界」を本気で目指した結果です。
グローバルなクロスクラウドアプリにはグローバルなVPCが必要
従来のプライベートネットワークの構築には多くの手間がかかり、複雑な階層構造が絡み、専任チームによる管理が必要です。特に当初のポイントツーポイントネットワークの想定を超えて成長したアーキテクチャの管理は複雑です。そのため、私たちは当社のプラットフォーム上で隔離された環境を簡単に構築できる仕組みが必要であると考えました。
Workers VPCは、その名の通り「仮想プライベートクラウド（Virtual Private Cloud）」です。これは、Workersと開発者プラットロームのリソース（R2、Workers KV、D1など）を、セキュアに相互接続できる専用の環境を構築する機能です。Cloudflareアカウント内の他のリソースは、これらにアクセスできません。VPCを使うと、特定のアプリに関連付けたリソースのセットを指定でき、アプリ同士でリソースが共有されないようにすることができます。
Workers VPCは、従来のVPCをCloudflare開発者プラットフォーム向けに再設計したものです。主な違いは、その仕組みにあります。一般的なVPCが地域ごとのIPベースで構築されているのに対し、Workers VPCはグローバル規模で構築され、Cloudflareネットワークは、そのすべてのデータセンターでリソースの分離を実行します。
また、既存のネットワークとシームレスに連携できるネットワーキング機能があり、お客様が信頼しているネットワークから決して離れないクロスクラウドアプリを構築することができます。それがWorkers VPC Private Linksです。
Workers VPC Private LinksはIPsecトンネルまたはCloudflare Network Interconnectを使って、AWS PrivateLinkなどと同様に、Workers VPCと外部クラウドのVPCを接続する機能です。Private Linkが確立されると、Cloudflare側と外部クラウド側のリソース同士が、あたかも1つのネットワークであるかのように通信できます。
Workers VPC Private Linkは、IPsecトンネルやCloudflare Network Interconnect用のゲートウェイを自動で用意し、CloudflareのリソースへルーティングできるようにDNSの設定も行います。
これを可能にするために、Workers VPCとPrivate Linkが連携し、外部クラウド内のリソースを自動で用意・管理します。これにより、両方のネットワーク間の接続が確立され、双方向ルーティングを可能にするために必要なリソースが設定されます。また、自分たちでリソースのプロビジョニングを行いたいチームのために、Workers VPC Private Linkは外部クラウドリソースをプロビジョニングするためのTerraformスクリプトも自動で提供します。
接続が確立されると、Workers VPCは外部VPC内のリソースを自動的に検出し、それぞれに固有のIDを付けた「バインディング」として利用可能になります。Workers VPCリソースバインディングを通して行われたリクエストは、外部VPCに自動的にルーティングされます。ホスト名でアクセスするリソースを使用している場合、そこでDNS解決が行われ、目的のリソースにルーティングされます。
例えば、Cloudflare Workersから外部VPC内のプライベートAPIへの接続は、名前付きのWorkers VPCリソースへのバインディングでfetch()を呼び出すだけです。
const response = await env.WORKERS_VPC_RESOURCE.fetch("/api/users/342");
逆に、外部VPCからCloudflareのリソースにアクセスする場合は（Workers VPC Private Linkによって、外部クラウド内のプライベートDNSに設定されている）標準化されたURLを指定するだけです。例えば外部VPC内のAPIからR2オブジェクトにアクセスする場合、指定されたURLにリクエストを送信します。
const response = await fetch("https://<account_id>.r2.cloudflarestorage.com.cloudflare-workers-vpc.com");
さらに嬉しいのは、Workers VPCは当社の既存のプラットフォーム上に構築されているため、当社のネットワーキング機能とルーティング機能をフルに活用することで、エグレス料金を削減しながら、グローバルアプリの構築が可能な点です。
第一に、Workers VPC Private LinkはCloudflare Network Interconnectを接続方式としてサポートしているため、外部クラウドからの通信にかかるエグレス料金を割引価格で利用でき、帯域コストを削減できます。第二に、Workers VPCは本質的にグローバルであるため、Workersとリソースを必要な場所に配置して、最適なパフォーマンスを実現することができます。たとえば、WorkersのSmart Placement機能を使えば、Workersを外部の地域VPCに最も近い地域に自動的に配置して、アプリのパフォーマンスを最大化することができます。
Workers VPCを使えば、今まで外部クラウドに閉じ込められていた多くのワークロードを、パブリックインターネットにさらすことなくCloudflare Workers上で安全に扱えるようになります。以下は、実際にユーザーから「Workers VPCで実現したい」と寄せられたアプリケーションの例です。
外部VPCのプライベートデータベースとコンテナにアクセスする、WorkersとDurable Objectsに構築されたリアルタイムキャンバスアプリケーションのアーキテクチャの例
Workersでアプリケーションの新しい機能を構築しようとしているとします。さらに、Durable Objectsを使ってリアルタイムの共同編集機能も加えたいとします。また、ライブ動画処理のためにFFmpegにアクセスする必要があるため、Containersも一緒に使用しています。それぞれのシナリオで、既存の従来のデータベースに状態の更新を保持したり、既存のAPIにアクセスする方法が必要になります。
以前は、WorkersとDurable Objectsから更新操作を処理するために専用APIを用意する必要がありましたが、Workers VPCを使えば既存のデータベースへ直接アクセスして更新することが可能です。
Model Context Protocol（MCP）サーバーを構築する場合も同じです。Workers上にMCPサーバーを構築している場合、特にスピード重視で開発を進めたい場合は、パブリックAPIとしてすぐに利用できない特定の機能を使いたいことがあります。Workers VPCを使えば、プライベートなAPIやデータベースを活用して、外部のMCPサーバー内に新しい機能を直接組み込むことができ、迅速かつセキュアにリリースできます。
R2、D1、KVからデータにアクセスする外部クラウドリソースのアーキテクチャの例
多くの開発チームが、Cloudflareの開発者プラットフォーム上にますます多くのデータを格納しています。たとえば、AIの学習データをR2にデータを置いて低エグレスコストを実現したり、アプリケーションデータをD1に保存して水平シャーディングで拡張性を確保したり、設定情報をKVに保存してグローバルにミリ秒単位での高速読み取りを実現しています。
次に、外部クラウド上のコンピュート環境からR2にある学習データを使って、LLM（大規模言語モデル）の学習やファインチューニングを行いたいとします。ユーザーデータにアクセスするため、セキュリティチームの提示する要件から、プライベートネットワーク経由である必要があります。同様に、特定の管理業務や分析処理のために、パブリックネットワークを介さずにD1およびKVのユーザーデータや設定データにアクセスする必要があります。Workers VPCを使えば、外部VPCからCloudflareリソースに対して直接かつプライベートなネットワーク経由でのアクセスが可能になります。自動設定されたプライベートDNSから分かりやすいホスト名で簡単にアクセスできます。
最後に、AIエージェントの例を見てみましょう。何といっても今はDeveloper Week 2025です！このAIエージェントは、Workers上に構築されており、検索拡張生成（RAG）を使用して、コンテキストウィンドウを最小化しながら、生成されたテキストの結果を改善します。
あなたは外部クラウドでPostgreSQLとElasticsearchを使用しています。理由はそこにデータがあることとpgvectorを気に入っているからです。開発のスピードを重視してWorkersを使うことにしましたが、当然ながらデータベースにもアクセスする必要があります。ところが、そのデータベースはプライベートネットワーク内にあり、インターネット経由ではアクセスできません。
新しいHyperdriveとCloudflare Tunnelをコンテナでプロビジョニングすることもできますが、既にWorkers VPCが設定・リンクされている環境であれば、WorkersまたはHyperdriveのいずれかを使用してデータベースに直接アクセスすることができます。
また、外部クラウドに新しいドキュメントが追加されたときに、自動でワークフローを開始して、新規ドキュメントの処理、チャンク化、エンベッディングの取得、結果としてアプリケーションの状態を更新しながら、ワークフローのステータスをエンドユーザーにリアルタイムで更新したい場合などを例に挙げます。
その場合、外部クラウドのサーバーレス関数からWorkflowsを起動することで対処できます。Workflowは、オブジェクトストレージの新しいドキュメントを取得し、必要に応じて処理し、Postgres内のベクトルストアを処理および更新するために、任意の埋め込みプロバイダー（Workers AIまたは他のプロバイダーを使用）を使用して、アプリケーションの状態を更新します。
これらは、Workers VPCが登場した初日から実現可能なワークロードの一例に過ぎません。お客様が今後構築されるものを楽しみにしています。また、グローバルなVPCを実現するために協力していけることを楽しみにしています。
Workers VPCによって、より多くをCloudflare Workers上で構築できるようになることをとても楽しみにしています。お客様のプライベートネットワーク内のAPIやデータベースに安全にアクセスできるようになることで、Workers上で構築可能なものの可能性が大きく広がると私たちは考えています。Workers VPCを使えば、今までアクセスできなかったプライベートリソースに接続できるようになり、より高速で高性能なアプリをすばやく開発・リリースできるようになります。もちろん、ContainersがWorkers VPCとネイティブに統合できるようにすることも予定されています。
現在、当社では、これまでに大規模なネットワーク接続で培ってきた基盤（ネットワークプリミティブやオンランプ）を活かして、Workers VPCの開発を進めています。2025年後半には、早期プレビュー版の提供を目指しています。
まずは、「Workersから外部クラウドへの接続」にフォーカスし、プライベートAPIやデータベースへのアクセスが必要なレガシーアプリをWorkersで近代化できるようにします。その後、双方向通信や複数のWorkers VPCネットワークの構成にも対応していく予定です。レガシークラウドにワークロードが縛られておりWorkers VPCのビジョンに関心がある方は、こちらからその旨をご連絡ください。