本文へ移動
情シスのミカタ
ニュース約3分で読めます

Cloudflare、大容量配信の部分取得を改善、範囲サイズの調整が不要に

CloudflareがOrigin Range Requestsを全プランで提供開始。動画や大容量ファイルの部分取得で、範囲サイズの調整が不要になります。設定場所、対象外となる応答、導入前に確かめたいサーバー側の条件を整理します。

公開 情シスのミカタ編集部AIにより執筆チェック済み
文字
Cloudflare、大容量配信の部分取得を改善、範囲サイズの調整が不要に

この記事のまとめ

  • Origin Range Requestsを全プランで提供開始。部分取得の範囲サイズ調整が不要になります。
  • Caching > Cache Rulesで対象通信を指定して有効化。通常のキャッシュ対象条件は変わりません。
  • 導入前に配信元のバイト範囲要求への対応を確認。日本での提供は発表には書かれていません。
こんな方に#20代#30代#40代#50代#60代実務

Cloudflareは2026年10月23日、大容量ファイルの部分取得を扱う「Origin Range Requests」の提供を開始しました。全プランで利用でき、動画やソフトウェア配布などで、利用者が取得範囲のサイズを調整せずにキャッシュを活用できるようになります。

対象通信をルールで指定し、範囲サイズの調整を省く

範囲要求は、ファイル全体ではなく、必要な位置のデータだけを取得する要求です。Origin Range Requestsは、動画、大容量ダウンロード、ソフトウェア配布のほか、AIの学習・推論で使う大容量モデルファイルの転送や部分取得も想定しています。

設定場所は、管理画面の「Caching > Cache Rules」です。Cache Rulesで対象通信を指定し、「Origin Range Requests」をOnにして有効化します。APIからの設定にも対応し、範囲サイズの調整やサポートへの連絡は不要です。

旧方式では、ゾーンごとに範囲サイズとファイル拡張子を設定していました。同社によると、範囲を大きくすると余分な転送が増え、小さくすると要求数やメモリ負荷が増えるという課題がありました。新方式では、このサイズ調整を利用者が担う必要がなくなります。

なお、日本での提供は発表には書かれていません。

キャッシュ処理を変更、すべての応答が対象になるわけではない

同社によると、新方式はクライアントが送る範囲要求自体を変えず、一時保存したデータを使うキャッシュ側の処理を変更します。保存済みの部分を使い、不足分だけを固定長の単位で取得します。進行中のダウンロードを別の要求でも共有し、同じデータの重複取得を抑える仕組みです。

ただし、要求した範囲より取得単位が大きい場合は、新方式でも要求外のデータを取得します。「必要な部分だけを、余分な転送なしに取得できる」という意味ではありません。

同社はR2について、キャッシュにデータがある場合とない場合の双方で、最初のデータが届くまでの時間のp99が約半減したと説明しています。p99は、計測値を短い順に並べたときの99%地点の値です。また、追加改善後にはR2などの階層型キャッシュ通信量が前週比で約6%減ったとしています。これらは同社が示した結果であり、自社の配信でも同じ改善幅になると見込んで導入するものではありません。

通常のキャッシュ対象条件は変わりません。有効化しても、キャッシュできない応答は対象外です。部分取得を活用するには、配信元となるオリジンサーバーがバイト範囲要求に対応している必要があります。同社によると、安全に部分応答を構成できない場合は、ファイル全体を返します。

影響する会社・しない会社

  • 影響する: Cloudflareを使い、動画、大容量ダウンロード、ソフトウェア配布で部分取得を扱う会社です。全プランが対象のため、契約プランだけを理由に検討対象から外す必要はありません。
  • 影響する: 旧範囲キャッシュ機能を利用していた会社です。一般提供に先立ち、既存利用者は新方式へ移行済みとされています。以前のサイズ設定を前提にした運用手順は、確認対象になります。
  • 影響しない: キャッシュ不可の応答を配信している場合、その応答は今回の機能を有効にしても対象になりません。キャッシュ可否の条件を変える機能ではありません。

情シスが今日やること

  1. 有効化前に、対象の配信を絞ります。 Webサイトや配信基盤の担当者に、動画、配布ファイル、AIモデルファイルで部分取得を使っているか確認します。ファイルが大きいという理由だけで一括適用せず、対象通信を整理します。
  2. 管理画面でルールを確認します。 「Caching > Cache Rules」を開き、対象通信に使うルールと「Origin Range Requests」の設定を確認します。旧機能を利用していた場合は、新方式への移行を踏まえて運用手順も見直します。
  3. 設定変更前に、配信元の担当者へ確認します。 オリジンサーバーがバイト範囲要求に対応しているか、対象の応答がキャッシュ可能かを確かめます。対応していない通信を、今回の機能だけで部分取得できるようになるとは考えないでください。
  4. 有効化後に、配信担当者と効果を確かめます。 部分取得の応答や転送量を確認し、要求外のデータ取得や全体応答が起こり得ることも共有します。同社は特定ファイル形式で新方式を標準にする意向ですが、これは今後の予定です。現時点の設定と将来の標準化を分けて管理してください。

出典・参考

このニュースは、公式発表と報道をもとに AI を使って作成し、出典と照らして確かめています。まちがいに気づいたら直し、更新日を改めます。

チェック済み。この記事は監修者によってチェックされました。(2026年10月24日)

執筆

情シスのミカタ編集部AIにより執筆

書いた AI: AI記者(ニュース)

企業・官公庁の公式発表を読み、事実を抜き出してから自分の言葉でニュースを書きます。記事には「影響する会社・しない会社」と「情シスが今日やること」を必ず入れます。書いた記事は別のAIが出典と照らして確かめ、通ったものだけを公開します。公式発表を読めない話題は、2つ以上の報道機関が伝えたものだけを「報道から」として書きます。使っているAI: OpenAI GPT-6.1 Sol。

監修

佐々木 航株式会社Game

代表取締役。工学部出身で、21歳で起業してからシステム会社の経営一筋で8期目。アプリの受託開発から始め、いまはAIを使ったシステムソリューションを手がけています。150社以上の企業とのプロジェクトで培った開発と情報システムの現場の経験と声を形にし、激動の時代を乗り越えたいと考えています。

メモ: 掲載時に自動で(しばらくの間)

記事は AI が書き、機械の検査と別の AI の校閲を通してから公開しています。人が見ているもの・見ていないものはAI の使い方に書いています。まちがいに気づいたら訂正・ご指摘からお知らせください。直したら、記事の最後に何を直したかを書きます。

役に立ったら、いいねと共有をお願いします