社内の在庫システムと、外部の物流会社のシステムをつなぐ。要件を詰めていくと、相手方が gRPC で受けたいと言ってくる。ここで、それまで検討していたエッジ側の構成が候補から外れます。
理由は単純で、Cloudflare Workers は2017年の登場以来、サーバーとしては HTTP しか受けられなかったからです。データベースや外部サービスに向けて自分から接続を開くことはできても、HTTP 以外の接続を受け付ける側には回れませんでした。gRPC や独自の TCP プロトコルが要件に入った時点で、素直に仮想マシンかコンテナサービスを選ぶことになります。
2026年8月の Agents Week で、この前提が動きました。
connect ハンドラで TCP を受ける
Cloudflare は Workers と Containers がinbound TCP 接続を受け付けられるようになったと発表しました。新しい connect(socket) ハンドラを通じ、Spectrum 経由でルーティングされます。Worker が HTTP 以外のプロトコルのサーバーになれる、というのが変更の中身です。
その上に載る最初のプロトコルとして gRPC が提供されました。扱いは Containers と Workers で分かれます。
| 実行環境 | gRPC のサポート範囲 |
|---|---|
| Containers | 任意の言語でフル双方向（full-duplex）の gRPC |
| Workers | unary とサーバーストリーミング（gRPC-web の自動変換経由） |
Workers 側は gRPC と gRPC-web を相互に変換するため、既存のクライアントとサーバーに手を入れずに間へ挟める構成が取れます。これは「新規に作り直す」ではなく「既にあるものの前に置く」用途で効きます。
現時点ではすべてプライベートベータです。Cloudflare は次に UDP ベースのプロトコルへ進むとしています。
どういう案件で効くのか
抽象的に聞こえるので、要件の形で挙げます。
1つ目は、既存の gRPC サービスを世界中から使わせたい場合。 330拠点以上のネットワークに gRPC サーバーを配置できるようになります。海外拠点からの接続遅延が課題になっている社内システムでは、素直に効く話です。
2つ目は、HTTP に載せ替えられない外部連携がある場合。 相手のシステムが gRPC 固定で、こちらの都合で REST にしてもらえない。この理由だけでエッジ構成を諦めていた案件が該当します。
3つ目は、機器やデバイスからの常時接続を受ける場合。 ここは TCP の受信そのものが要ります。ただし現時点で提供されているのは gRPC までなので、独自プロトコルを流したい構成は、まだ待ちの状態です。
プライベートベータを要件に入れない
ここが実務上いちばん大事なところです。プライベートベータの機能を、契約する案件の前提に置いてはいけません。
理由は3つあります。提供時期が確約されていないこと。 申し込んでも枠が来る保証はなく、開発着手日を決められません。仕様が変わり得ること。 ハンドラの形も制約も、正式提供までに動く可能性があります。サポート対象外であること。 障害時に頼れる窓口がベータ扱いのままです。
検証として触るのは有益です。技術選定の候補に入れておくのも構いません。ただし、「この機能が来る前提のスケジュール」を引いた瞬間に、その案件はコントロールを失います。 正式提供が半年遅れたときの逃げ道を、契約前に持っておく必要があります。
逃げ道の作り方
実務的には、gRPC を受ける層を差し替え可能にしておくのが確実です。
- プロトコル変換の層を、業務ロジックから分ける。 gRPC を受けて内部の呼び出しに変換する部分を薄く独立させておけば、その層の配置先だけを後から変えられます
- エッジでなくても成立する構成を第1案にする。 コンテナサービスや仮想マシンで先に動かし、エッジ移設は後続の改善として切り出す。先に動くものを作り、速度は後から取りに行く順番のほうが、納期の事故が起きません
- ベンダーロックインの度合いを事前に確認する。
connect(socket)ハンドラは Cloudflare 固有の書き方です。インフラの選定は移行可能性の選定でもあるため、どこまで固有 API に寄せるかを最初に決めてください
HTTP で足りるなら、それが最善
最後に、逆方向の確認も入れておきます。gRPC が要件に入る案件は、実際にはそれほど多くありません。
社内システム同士の連携で、通信量が中程度、リアルタイム性の要求も強くないのであれば、REST か、型を共有できる RPC ライブラリで十分に足ります。Workers 上に HTTP の API を素直に置く構成は今も有効で、扱える開発者の数もこちらが圧倒的に多い。
gRPC を選ぶ理由になるのは、相手方の都合で決まっている場合か、双方向ストリーミングが業務要件そのものである場合です。「速そうだから」で選ぶと、保守できる人を探す段階で詰まります。
次にやること
まず、現在検討中の案件で、HTTP 以外の通信が要件に入っているものがあるか確認してください。 ないのであれば、今回の変更は当面の判断に影響しません。半年後に選択肢が1つ増える、という程度の把握で十分です。
要件に入っているなら、その要件が相手方の固定条件なのか、こちら側の希望なのかを切り分けてください。 希望であれば HTTP に寄せるほうが早く安く済みます。固定条件であれば、エッジ配置は正式提供を待ち、まずは動く構成で立ち上げる段取りを組んでください。
システム間連携の設計、既存システムのクラウド移行、インフラ構成の選定については、グリームハブの開発・AI・自動化のご相談で承っています。連携先の条件と求められる応答性能によって適切な構成が変わるため、個別にご相談ください。お問い合わせからどうぞ。
