<style>
.oh-hero{padding:clamp(24px,5vw,48px);border-radius:24px;color:#fff;background:linear-gradient(120deg,#18283b,#225c78 54%,#37a0a1)}.oh-hero h2{color:#fff;margin:.3em 0}.oh-kicker{font-size:.8rem;font-weight:800;letter-spacing:.12em;color:#bceff1}.oh-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:11px;margin:22px 0}.oh-card{padding:17px;border:1px solid #c6e0e4;border-radius:15px;background:#f2fbfb}.oh-card strong{display:block;color:#196a76;font-size:1.12rem}.oh-table{overflow-x:auto;margin:20px 0}.oh-table table{min-width:650px;width:100%;border-collapse:collapse}.oh-table th,.oh-table td{padding:11px;border:1px solid #c6d9e0;text-align:left;vertical-align:top}.oh-table th{background:#e7f5f6}.oh-note{padding:16px 19px;border-left:5px solid #db963c;border-radius:10px;background:#fff7e9;margin:20px 0}.oh-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:8px;margin:20px 0}.oh-step{padding:15px;border:1px solid #b9d9df;border-radius:14px;background:#f2fbfb}.oh-step b{display:block;color:#176a78}@media(max-width:760px){.oh-grid,.oh-flow{grid-template-columns:1fr}}
</style>
CLOUD / PRIVACY INFRASTRUCTURE
送り主を知らずに、リクエストを処理する
OHTTPは「送信元を知るリレー」と「内容を読めるゲートウェイ」を分ける。Cloudflareの新サービスは後者の運用を引き受けるが、プライバシーはサービスを有効にするだけで完成しない。
3行で要約
- Cloudflareは2026年10月2日、暗号化されたHTTPを復号しアプリへ渡す「OHTTP Gateway」のクローズドベータを発表した。今秋の有料アドオンとしての提供を予定し、現時点では待機リストを案内している。[¹]
- OHTTPでは別々の運営主体によるリレーとゲートウェイを組み合わせる。リレーは利用者のIPアドレスを見られるが本文は読めず、ゲートウェイは本文を復号するが元のIPを直接見ない。[¹][²]
- 匿名化されるのは主にネットワーク上の識別情報。本文にメールアドレスなどを入れれば、アプリ側はその情報を見られる。導入時はデータ内容と運営主体の分離も設計する。[¹][²]
背景：通常のHTTPでサーバーが知ること
一般のWebリクエストでは、アプリの手前のサーバーが送信元IPアドレスや接続情報を知る。本文に個人情報がなくても、接続元を手掛かりに複数の通信を結び付けられる場合がある。OHTTP（Oblivious HTTP）は、HTTPメッセージを暗号化し、別の中継者を通して届けるIETF標準の仕組みだ。規格は2024年1月のRFC 9458として公開されており、今回新たに発明されたプロトコルではない。[²]
何が新しいのか
Cloudflareは従来、リレー役を「Privacy Gateway」として提供してきた。今回その名称をCloudflare OHTTP Relayへ改め、別途Cloudflare OHTTP Gatewayを発表した。アプリをすでにCloudflareのCDNやWorkersの背後で動かす事業者は、Cloudflareをゲートウェイ側に置き、別の事業者のリレーを使う選択肢を得る。[¹]
利用者本文をゲートウェイ向けに暗号化
別事業者のリレー利用者IPを見る／本文は読めない
Cloudflare Gateway復号する／元のIPは直接見ない
アプリ通常のHTTPとして処理
Cloudflareが自社のリレーとゲートウェイを同時に担当しないことが重要だ。両方を同じ主体が運営すると、送信元と本文を突き合わせる余地が生まれる。発表によれば、新GatewayはCloudflare WorkersやCloudflareでプロキシされたホストから来たリクエストの復号を拒む設計としている。[¹]
技術的なポイント
クライアントはゲートウェイの公開鍵を使い、HPKEという暗号方式でHTTPメッセージを包む。リレーは暗号化された内容を転送し、ゲートウェイが復号してアプリに渡す。RFC 9458は、ゲートウェイが利用者のIPを知らず、リレーが平文HTTPを見ないという境界を定義する。[²]
Cloudflareの説明では、ゾーンの /.well-known/ohttp-gateway で公開鍵の提供とOHTTP受付を行い、復号後のリクエストを元のアプリへ送る設計だ。Cloudflare Accessを復号前に適用し、許可されたリレーからの通信に絞れるとしている。標準形式とチャンク化形式の双方を扱う予定だが、いずれも製品発表時点の説明であり、利用可能な契約・地域は確認が必要だ。[¹]
どの主体が何を見られるか| 主体 | 見られる情報 | 原則見られない情報 |
|---|
| リレー | 利用者の接続元IP、通信時刻など | 暗号化されたHTTP本文 |
| ゲートウェイ | 復号後のリクエスト内容 | 利用者の元のIP（リレー経由の場合） |
| アプリ | 本文内の入力情報 | ネットワーク上の元のIP |
開発者・企業向けの導入手順
まず「アプリが利用者のIPを知らなくてもよい」処理を選ぶ。匿名の問い合わせや統計送信など、複数リクエストを同一人物へ結び付ける必要が小さい用途が候補になる。次に、本文・Cookie・認証ヘッダー・端末IDに識別子がないか棚卸しする。ネットワークだけ隠しても、内容に識別子が残れば目的は達成できない。[¹][²]
Cloudflareの新Gatewayを評価するなら、待機リストと提供条件を確認し、別の事業者が運営するリレーを用意する。クライアント側のOHTTP対応、鍵取得、リレーのログ方針、Gateway側の許可ポリシーを検証する。最後に、通常のHTTPと比べた遅延、失敗率、エラー時の情報漏えいを測る。[¹]
リスクと限界
まだ一般提供ではない。2026年10月2日の発表はクローズドベータと待機リストの案内で、今秋の有料アドオン提供は予定だ。正式な価格、提供地域、利用開始日は個別に確認する。[¹]
- RFC 9458は、Cookieや本文に残る識別子を消さない。状態を伴う一般的なWebアプリすべてに向くわけではない。[²]
- リレーとゲートウェイが協力してログを突き合わせる場合、期待した分離は崩れる。契約、運営、ログ保持を確認する。[¹][²]
- 暗号化と中継は追加の処理・遅延を伴う。用途に応じて計測が必要だ。[²]
今後注目すべき点
一般提供時期と料金、第三者リレーとの相互運用性、実測遅延、鍵管理と監査の仕様を確認したい。OHTTPの価値は「完全匿名」を約束することではなく、どの主体にも利用者IDと本文の両方を渡さない設計を検証可能にすることにある。
最終確認日：2026年10月4日（日本時間）
参照元
- Cloudflare公式発表：OHTTP Gateway（2026年10月2日）
- IETF RFC 9458：Oblivious HTTP（2024年1月）
- Cloudflare公式ドキュメント：OHTTP Relayの構成