CloudflareのOrigin Range Requestsで変わる大容量ファイルの部分取得

CloudflareがOrigin Range Requestsの全プラン提供を発表しました。取得範囲の調整をCDNに任せる仕組みと、導入時に残るオリジン応答・キャッシュ容量の条件を整理します。

こはるの読みどころ

利用者に返すバイト数と、オリジンから読むバイト数は別なんだね。この違いを押さえると、導入後に見るべきログが分かるよ。

動画の途中へ移動したり、大きなファイルの一部だけを読んだりするとき、利用者が必要とするデータはファイル全体のごく一部です。では、CDNの裏側でも、その分だけの通信で済んでいるのでしょうか。

Cloudflareは2026年10月23日、Origin Range Requestsの全プラン提供を発表しました。取得範囲のサイズ調整を利用者から引き受ける変更です。公式発表

導入を判断するには、クライアントへ返す範囲と、オリジンから取得する範囲の違いを押さえたいところです。この違いから、機能が省いてくれる作業と、運用側に残る確認事項を見ていきましょう。

HTTPのRange指定とキャッシュの取得単位は一致しない

HTTPでは、たとえばGETにRange: bytes=1024-2047を付けると、その区間を要求できます。バイト位置は0から始まり、終端も含むので、長さは2047 - 1024 + 1 = 1024バイトです。これはRFC 9110のバイト範囲仕様に基づく説明用の計算です。

ただし、キャッシュが保存・取得する単位まで、この1024バイトに合わせる必要はありません。大きな応答を固定サイズで分割する方式は、NGINXのsliceモジュールにもあります。同モジュールでは分割範囲をキャッシュキーに含め、分割サイズを小さくしすぎるとメモリ使用や開くファイル数が増える点に注意が必要です。細かければよい、とは限らないわけですね。

Origin Range Requestsは、Pingoraのチャンク保存を使い、保存済み・取得中・不足しているデータを組み合わせます。同じ範囲を取得中なら、その処理を共有できます。Cloudflareの実装解説

現在の範囲取得仕様では、オリジンへの取得を1 MiB境界にそろえます。次は、1 MiB以上ある未圧縮ファイルの先頭部分が未キャッシュだった場合の説明例です。実測ログではありません。

通信する区間	バイト範囲の例	長さ
クライアントが要求する部分	1024–2047	1 KiB
オリジンから取得し得る部分	0–1048575	1 MiB
クライアントへ返す部分	1024–2047	1 KiB

余分な取得が完全になくなるわけではありません。運用上は、クライアントへの応答サイズだけを見て、オリジンの通信量も同じだと判断しないことがポイントです。

部分応答をつなぐにはオリジンの整合性が必要

複数の部分応答をつなぐなら、それぞれが同じファイルの同じ表現を指していなければなりません。HTTPのバイト範囲は、圧縮されていれば圧縮後のバイト列に対する位置です。展開前と展開後の位置をそのまま混ぜられない理由も、RFC 9110から分かります。

Cloudflareが生成するオリジン要求にはAccept-Encoding: identityが付きます。キャッシュする206応答には、要求と整合するContent-Range、区間長と一致するContent-Lengthが必要で、Transfer-Encodingは付けません。未圧縮で返し、総サイズと、ETagを返す場合はその有無・値を各応答でそろえる必要があります。部分応答の要件

オリジンがRangeを無視して200で全体を返す場合、Cloudflareは利用できますが、全体の取得が必要になります。2026年9月2日のAPI対応告知にも、この挙動が明記されています。まず対象ファイルで部分応答が実際に返るかを見るのが、導入前の具体的な一歩です。

全プラン対応でもファイル全体のキャッシュ上限は残る

Origin Range Requestsを有効にしても、通常のキャッシュ対象条件は変わりません。容量判定は要求した部分ではなくファイル全体に対して行われ、Cache Reserveとの併用も非対応です。Cache Rulesの設定仕様

2026年10月24日時点のキャッシュ容量制限は、Free・Pro・Businessが512 MB、Enterpriseは既定で5 GBです。Enterpriseでは上限引き上げの相談が案内されています。

たとえば、全体で2 GBあるファイルのうち1 KiBだけを要求しても、512 MBの上限を回避してキャッシュできる、という意味にはなりません。大容量ファイルへの採用では、部分取得の頻度を調べる前に、ファイル全体が契約上の上限に収まるかを切り分けたいところです。

Cache Rulesで対象を絞り、待ち時間と転送量を測る

設定は、対象のホスト名やパスを絞ったCache RuleでOrigin Range RequestsをOnにします。APIではorigin_range_requests.modeにonを指定します。offはこの機能によるオリジン範囲取得を止めますが、完全なキャッシュからの部分配信は可能です。defaultはプラットフォームの既定に従い、調査時点では既定で有効になる拡張子はありません。設定値の意味

なお、Rulesets API対応は2026年9月2日の変更履歴に既に記載されています。10月23日のブログ発表日を、APIの初回提供日と読み替えないようにします。

Cloudflareが報告したR2の結果は、p99 TTFBが約半分になり、後続の改善でR2と類似ワークロードの階層間キャッシュ通信が前週比約6%減ったというものです。TTFBは最初のバイトまでの時間で、ダウンロード完了時間とは異なります。自分の配信で同じ改善率が得られる保証ではありません。性能結果

導入時には、同じファイルと要求パターンで有効化前後を比べる方法を提案します。キャッシュの冷えた状態と温まった状態を分け、TTFBに加えてオリジンの送信バイト数・要求回数、応答途中の切断を追うと、速さと取得負荷を一緒に評価できます。これは記事としての検証提案で、実施済みの測定結果ではありません。

冒頭の問いに戻ると、小さな部分要求でも裏側の取得量が同じとは限りません。Origin Range Requestsを使う判断は、分割サイズ選びから、対象ファイルの適格性とオリジンの応答品質を確かめる作業へ移ります。その条件を満たした経路で、待ち時間と転送量の両方を測るのが実務的です。