Cloudflare WorkersのTCP解放：エッジコンピューティングのパラダイムシフト

2017年の登場以来、Cloudflare Workersは「HTTPの申し子」としてエッジコンピューティングの覇権を握ってきた。しかし、我々エンジニアにとって、この8年間は常に「HTTPというプロトコル層の制約」との戦いでもあった。データベースへの直接接続、カスタムバイナリプロトコルによる低遅延通信、あるいはレガシーなメッセージキューとの連携。これらを実現しようとするたびに、我々は「HTTP/1.1やHTTP/2のフレームワークに無理やり押し込む」というスパゲッティコードのような回避策を強いられてきた。今回発表されたconnect(socket)ハンドラーの導入は、単なる機能追加ではない。これは、WorkersがHTTPという「Webの枠組み」を脱ぎ捨て、OSレベルのソケット通信という「ネットワークの深淵」に直接アクセスできるようになったことを意味する。

具体的には、connect(socket)ハンドラーを通じて、生のインバウンドTCPソケットを直接ハンドリングできるようになった。これは、Cloudflareの既存のイングレスプロキシである「Spectrum」を介してルーティングされる。開発者は、受け取ったソケットをそのまま別のWorkerに渡すことも、Durable Objectsを介してコンテナへ転送することも可能だ。例えば、Goで書かれたgRPCエコーサーバーやPythonのsocketserverを、コードを一切修正することなくエッジで動かせるという事実は、我々が長年夢見てきた「サーバーレスの真の汎用化」への第一歩と言えるだろう。これまでHTTPの制約で諦めていた「ステートフルな双方向通信」が、エッジの極めて近い場所で完結する。これは、デッドロックやレイテンシの増大に悩まされてきた分散システム設計者にとって、まさに福音である。

今回のアップデートの目玉であるgRPC対応だが、ここにはCloudflareという企業の「誠実さ」と「技術的現実主義」が色濃く反映されている。Workers自体は、gRPCの双方向ストリーミングをネイティブにサポートしているわけではない。現状では、gRPC-webを介した変換レイヤーとして実装されている。これは、HTTP/2のストリームIDやトレーラー制御といった、ブラウザのfetch() APIでは露出していない低レイヤーの制御が、Workersの実行環境でも同様に隠蔽されているためだ。Cloudflareは、2020年からWAFやBot管理のためにgRPCをHTTP/1.1に変換する技術を磨いてきた。今回の実装は、その知見を応用した「賢い翻訳」である。

特筆すべきは、Cloudflareが公式に「我々は社内でgRPCを使っていない」と明言した点だ。彼らはCap’n Protoや独自のJavaScriptネイティブRPCシステムを優先している。この「自社で使っていない技術を、まずはプライベートベータとして慎重に提供する」という姿勢は、単なる謙遜ではない。技術コミュニティに対する「我々は、自分たちが使いこなせないものを、安易に一般公開してエンジニアを混乱させたくない」という強いメッセージだ。これは、リリースを急ぐあまり不安定なAPIを乱発する他社プラットフォームとは一線を画す。以下の表は、今回の機能提供におけるレイヤーごとの対応状況を整理したものだ。

この構成は、プラットフォームチームにとって「どこで処理を完結させるか」という明確な設計指針を示している。単純なリクエスト処理ならWorkersで完結させ、複雑な双方向通信やレガシーなバイナリプロトコルが必要な場合はDurable Objectsからコンテナへ逃がす。この「エッジにおけるルーティングの柔軟性」こそが、次世代のアーキテクチャを決定づける鍵となるだろう。

今回のアップデートは、エージェントAIの台頭という文脈とも密接にリンクしている。MCP（Model Context Protocol）の仕様でもgRPCがトランスポートとして採用されるなど、機械同士の通信において「RPCの再発見」が起きている。我々エンジニアは、HTTPという「人間向けのWeb」を、機械同士の「高速なバイナリ通信」に無理やり適用しようとして、多くのオーバーヘッドを支払ってきた。CloudflareがTCPを解放したことは、この「HTTP偏重の時代」の終わりを告げる合図かもしれない。しかし、ここで我々が直面するのは「自由度の代償」である。生のTCPを扱うということは、バックプレッシャーの制御、コネクションのライフサイクル管理、そしてセキュリティの境界線設計を、すべて自分たちの責任で実装しなければならないことを意味する。

明日から我々が取るべき対策は明確だ。まずは、現在HTTPで実装しているマイクロサービス間の通信のうち、どれが「TCPの直接通信」に置き換えることで、レイテンシやスループットの劇的な改善が見込めるかを再評価することだ。特に、モバイルアプリのバックエンドや、リアルタイム性が求められるAIエージェントの通信経路は、真っ先に検証対象となるべきだ。しかし、忘れてはならない。技術は「何ができるか」ではなく「何を選択しないか」で決まる。TCPが使えるようになったからといって、すべての通信をTCPに移行するのは愚策だ。HTTPが持つキャッシュ性、可観測性、そしてエコシステムの恩恵を捨てるリスクを、我々は常に天秤にかける必要がある。

最後に、読者であるあなたに問いたい。エッジが「単なるHTTPのキャッシュサーバー」から「汎用的なTCPの終端点」へと進化する中で、あなたの設計するシステムは、依然として「HTTPの制約」に縛られたままではないか？ ネットワークの境界が消失し、コードが世界中のエッジで同時に実行される時代において、あなたが守り続けている「サーバーサイドの常識」は、本当に明日も通用するのか？ この技術的転換点を、単なる「新機能の追加」として消費するのか、それとも「分散システムの設計思想を根本から書き換えるチャンス」と捉えるのか。その判断が、数年後のあなたのエンジニアとしての価値を決定づけることになるだろう。