Cloudflare Workersは受信TCP接続を受け付けられるようになった。2017年のサービス開始以来、Workerはデータベースや外部サービスに対してアウトバウンドのソケット接続を開くことはできたが、サーバーとして処理できるのはHTTPのみだった。新たに追加されたconnect(socket)ハンドラーによってこの制約がなくなり、その最初の実装例としてgRPCサポートが提供される。
この発表はAgents Weekの期間中に行われた。同イベントは音声AIをテーマとしており、音声AIでは、低レイテンシとクライアントとモデル間の永続的な双方向接続が重要になる。しかし、その根底にある機能は、この文脈から受ける印象よりも広範な用途を持つ。
3つの機能が同時に提供されたが、それぞれ実現できる機能の上限は異なる。
connect(socket) ハンドラーは、Cloudflareが非HTTPトラフィック向けに提供している既存のインバウンドプロキシであるSpectrumを経由してWorkerにルーティングされた、生の受信ソケット接続を受け付ける。Workerは、そのソケットを直接読み書きできるほか、別のWorkerへ引き渡したり、Durable Objectへ渡すことも可能だ。
export default { async connect(socket): Promise<void> { const writer = socket.writable.getWriter(); await writer.write(new TextEncoder().encode("Hello, world!
")); await writer.close(); }, } satisfies ExportedHandler; Durable Objectからは、getTcpPort()を通じてソケットをContainerへ引き渡すことができ、ここがフルデュプレックス通信経路の終点となる。 Cloudflareは、変更を加えずに動作する例として、Go製のgRPCエコーサーバーとPythonのsocketserverを紹介している。同社によれば、これによりクライアントとサーバー間で、あらゆるプログラミング言語で実装された任意のプログラムを、TCPベースの任意のプロトコル上でフルデュプレックス通信させる道が開かれるという。
Workers自体で利用できる機能はより限定的だ。Containerを使わなくても、Unary RPC（単項RPC）およびサーバーストリーミングRPCサービスを提供できるほか、外部のgRPCサーバーを呼び出すこともできる。しかし、双方向ストリーミングには対応していない。この仕組みはネイティブサポートというよりは変換である。開発者はgRPC-webを利用してコードを記述し、Cloudflareが受信したgRPC通信をgRPC-webへ変換する。また、送信時にはgRPC-webを再びgRPCへ変換して外部と通信する。
その理由について、Cloudflareはプラットフォーム側の制約を率直に説明している。HTTP/2ではリクエストがストリームIDを持つフレームに分割され、gRPCはストリーミング、キャンセル、フロー制御、トレーラーといった機能を実現するために、このストリーム単位の制御に依存している。しかし、fetch()に代表されるWebプラットフォームのAPIは、こうしたHTTP/2の内部機構を公開していない。ブラウザーも同じ制約を抱えており、そのためにgRPC-webが存在する。また、Cloudflareは2020年から、WAFやBot Managementがメッセージ内容を検査できるように、リバースプロキシ内部でgRPC通信をHTTP/1.1へ変換する仕組みを導入している。
Cloudflareの発表に対する返信の中で、Sebastian Buzdugan氏が、この制約を実運用の観点から捉えた疑問を投げかけた。同氏は、WorkersがgRPCストリームに必要なバックプレッシャー制御を十分に提供しているのかを問い、実装の完成度を左右するのはストリーミング時の細かなエッジケースへの対応だと指摘した。しかし記事では、この点についての説明は行われていない。
実際には、既存のクライアント側を変更する必要はない。Workersは、grpc-swift-2やgrpc-kotlinを利用するモバイルアプリ向けにgRPCサービスを提供できるほか、WorkersがREST APIの前段に配置されるのと同様に、既存のgRPCバックエンドのフロントエンドとして動作もできる。サーバー側の実装も、オープンソースの@connectrpc/connectパッケージを使用すれば、数行のコードで実装できる。
Cloudflareが今回の発表でもっとも率直に説明しているのは、この機能を一般提供（GA）ではなくプライベートベータとして公開した理由だ。同社は社内でgRPCを利用していないのだ。
Cloudflareでは、gRPCの代わりにCap'n Proto、Cap'n Web、そしてCloudflare Workersに組み込まれたJavaScriptネイティブのRPCシステムを利用している。新しい機能をリリースする際には、まず自分たち自身で実際に使っていることを重視している。
これは、ベンダーが新機能の発表と同時に公表する内容としては異例であり、利用者に対して率直な期待値を示している。Cloudflareは、まずは限定されたgRPC開発者コミュニティと協力しながら実装の完成度を検証し、そのうえで広く提供したいとしている。導入を検討するチームは、この説明は単なる謙遜ではなく、機能の成熟度に関するシグナルとして受け取るべきだ。
プラットフォーム担当者にとって重要なのは、この機能が発表されたユースケース以外に何を実現できるかという点だ。Workersはこの8年間、HTTPに限定されていたため、メッセージブローカー、データベースプロキシ、独自のバイナリプロトコル、その他TCPソケット接続を前提とする多くのワークロードを実行できなかった。今回、ソケットをWorkerからDurable Object、さらにContainerへ引き渡せるようになったことで、Cloudflareのエッジは任意のTCP通信の終端として機能するようになる。その手前にはJavaScriptによるルーティングロジックを配置できるため、接続先の振り分けや制御をエッジ上で柔軟に実装できる。
このルーティングの位置付けは注目に値する。Workerは接続をどこへ転送するかを決定する前に、その接続を受け取って処理できる。これは、APIゲートウェイがリクエストを転送する前にルーティングや認可の判断を行う仕組みと同じ構造を、HTTPではなく生のTCPソケットに適用したものと言える。ただし、その位置にあるWorkerがソケットに対してどの程度の検査やポリシー制御できるのかについては、今回の発表では触れられていない。
gRPCの観点もまた、特定のタイミングで浮上している。MCPの2026-07-28仕様では、従来のHTTPトランスポートに加えて、gRPCがオプションのトランスポートとして追加された。これに対して開発者たちは、エージェント基盤の多くが、MCP以前から存在していたRPC（Remote Procedure Call）の考え方を再発見しているに過ぎないと指摘している。Googleが約10年前に公開したgRPCは、HTTPを中心に設計されたシステムにおいてさえ、マシン間通信の有力な選択肢として繰り返し採用され続けている。
今回の発表で紹介されたすべての機能は、現時点ではサインアップ制のプライベートベータとして提供されている一方で、Cloudflareは自社のSNS投稿で「gRPCサポートが利用可能になった」と発表し、変換レイヤーなしでエッジ上でgRPCをネイティブに提供できるかのように説明している。そのため、その告知を見て詳細を確認した人は、実際の提供範囲が宣伝内容より限定的であると感じるだろう。Cloudflareによると、次はUDPベースのプロトコルが対応対象になるという。