CloudflareがOrigin Range Requestsを全プランへ：大容量配信で変わること

Cloudflareは2026年10月23日、大きなファイルの一部を配信するOrigin Range Requestsを、すべてのプランで利用できるセルフサービス機能として発表した。Cache Ruleで対象を選び、従来のように範囲サイズを調整せず使える。

動画の途中再生や、大きなダウンロードの再開などに関係する更新。小さな部分を要求したのに、オリジンサーバーから大きすぎる範囲を取得してしまう問題へ取り組む仕組みだよ。

クライアントが要求する範囲は変えない

HTTPのRangeリクエストは、ファイル全体ではなく、特定のバイト範囲を要求するもの。対応する場合は206 Partial Contentと、どの範囲を返すかを示すContent-Rangeなどで応答する。

今回の機能は、利用者のブラウザが要求した範囲そのものを勝手に変えるものではない。Cloudflareが、その要求をキャッシュやオリジンへの取得からどう満たすかを変える。

キャッシュにある部分を読み、ない部分を内部の一定サイズの区切りに合わせて取得し、必要な部分を組み合わせる。利用者には要求した範囲を返す、という役割の違いを押さえよう。

「余分な取得が完全にゼロ」ではない

小さい要求でも、内部の区切りを丸ごと取得する場合はある。発表は、余分な作業をなくしたと説明するのではなく、従来の利用者が選ぶ範囲サイズに依存する問題を減らし、予測しやすくしたと説明している。

同時に進む取得を共有する仕組みや、ディスク上のデータと取得中のデータを組み合わせる改善も含まれる。表示する範囲を作るときは、同じ版のファイルか、全体サイズやETagが一致しているかなどを確認する。

対象にできる条件

この機能をオンにしても、本来キャッシュ不可の応答が自動的にキャッシュ可能になるわけではない。個人向け・認証付きの応答を、機能を使うためだけに公開キャッシュへ変えないようにしよう。

公式資料は、Caching > Cache Rulesで対象トラフィックを選び、Origin Range RequestsをOnにする方法を案内している。まず対象を限定し、現在のルールと競合しないか確認したいね。

性能改善の数字は、対象を付けて読む

Cloudflareは、R2でのp99の最初のバイトまでの時間が、おおむね半分になったことや、R2と似た用途の階層キャッシュ間トラフィックが約6%減ったことを報告している。

これはCloudflare側の対象環境での観測で、すべてのWebサイトが同じ割合で速くなるという保証ではない。小さいHTMLが中心のサイトへ、そのまま効果を当てはめないようにしよう。

編集部としては、練習用の大容量ファイルで通常取得・途中取得・再開・更新後の応答を比較し、206だけでなくContent-Rangeと実際の内容を照合することを勧める。この記事では公式の仕組みと条件を確認し、Cloudflare設定の変更や性能測定は行っていないよ。

応答の基本は206と部分取得、内容の版はETagと304も参考になるね。