TL

Cloud Service

Cache Reserve

オリジンへのアクセスを減らしキャッシュヒット率を底上げする永続キャッシュ層。R2を裏側の保管先に使い、オリジン費用と負荷を削減できる。

中級パフォーマンス効率コスト最適化信頼性
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.通常のエッジキャッシュより長く・広くコンテンツを保持する、R2ベースの永続的な追加キャッシュ層。
  • 2.エッジのキャッシュから溢れたコンテンツをReserveに退避し、オリジンへのリクエストを減らしてコストと負荷を下げる。
  • 3.Cache Rulesと組み合わせて対象パスやTTLを制御するのが基本の使い方。

解決する課題

  • 通常のエッジキャッシュは容量や保持期間に限りがあり、アクセス頻度が低いコンテンツはすぐに追い出されてオリジンへ取りに行く回数が増える
  • オリジンへのアクセスが増えると、その分の転送費用やオリジン側の負荷が増大する
  • 特に画像・動画・静的アセットのように「たまにしかアクセスされないが数は多い」コンテンツで、キャッシュヒット率を底上げしたい

主要概念と用語

  • Cache Reserve: 通常のエッジキャッシュとは別に用意される、より大容量・長期保持向けの永続キャッシュ層
  • エッジキャッシュ（通常キャッシュ）: 各データセンターが持つ揮発性のキャッシュ。容量や保持期間に制約がある
  • オリジン: キャッシュミス時に実際のコンテンツを取得しに行く元のサーバー
  • Cache Rules: どのリクエストをキャッシュ対象にするか、TTLをどう設定するかを制御するルール機能
  • キャッシュヒット率: リクエスト全体のうちキャッシュから応答できた割合。高いほどオリジン負荷が下がる

仕様・制限・クォータ

  • 裏側のストレージにはR2を利用しており、保存容量あたりの課金とオペレーション課金が発生する
  • 対象にできるのはキャッシュ可能なコンテンツ（キャッシュ不可のレスポンスやCookie付きの動的コンテンツなどは対象外）
  • 有効化はゾーン単位で行い、Cache Rulesと組み合わせて対象を絞り込むのが一般的
  • 通常のエッジキャッシュと役割が異なるため、既存のCache-Controlやページルールの設定と整合させる必要がある

内部の仕組み

Cache Reserveは、通常のエッジキャッシュの「上位互換」ではなく、その後段に位置する追加の永続層です。リクエストが来ると、まず各データセンターのエッジキャッシュを確認し、そこにヒットしなければ次にCache Reserveを確認し、それでもミスした場合に初めてオリジンへ取りに行きます。一度取得したコンテンツはエッジキャッシュとReserveの両方、あるいはReserve側に長期保存され、以降の同じリクエストはオリジンまで到達せずに応答できます。

裏側のストレージ機構にはオブジェクトストレージが使われており、揮発性のエッジキャッシュに比べて格段に長い期間、コンテンツを保持できます。これにより「アクセス頻度は低いが総数の多いロングテールなコンテンツ」でもキャッシュに残り続け、オリジンへのヒットを大きく減らせます。

通常キャッシュとの役割分担

Cache Reserveは通常のエッジキャッシュを置き換えるものではありません。エッジキャッシュは低レイテンシな一次キャッシュとして機能し続け、Reserveはそこから溢れた・期限切れになったコンテンツの受け皿として、オリジンへの到達を減らす二次キャッシュの役割を担います。

設計パターン / ベストプラクティス

  • 画像・動画配信の最適化: アクセス頻度にばらつきのある大量の静的アセットをReserve対象にし、オリジンの転送費用を削減
  • Cache Rulesとの併用: パスパターンやコンテンツタイプで対象を絞り込み、キャッシュすべきでない動的コンテンツを除外
  • 長いTTLの併用: Reserveの効果を活かすには、そもそも長めのキャッシュ保持を許容する設計にする
  • オリジンコスト削減が目的の場合の優先適用: オリジン側の転送量課金が大きいワークロードほど効果が見込みやすい

運用・監視

  • キャッシュのヒット/ミス状況はCache Analytics等のダッシュボードで確認し、Reserve導入前後のオリジンリクエスト数の変化を追う
  • レスポンスヘッダーでキャッシュステータス（ヒットしたか、どの層でヒットしたか）を確認できる
  • 想定通りにヒット率が改善しない場合は、Cache-ControlヘッダーやCache Rulesの設定でキャッシュ対象外になっていないかを確認する

コスト

Cache Reserveは裏側のオブジェクトストレージを利用するため、保存容量とオペレーション（読み書き回数）に応じた費用がかかります。一方でオリジンへのリクエストや転送が減ることで、オリジン側のコスト（転送量課金やサーバー負荷）が下がるため、両者のバランスで導入効果を評価します。オリジン側のコストが高い、あるいはロングテールなコンテンツが多いワークロードほど、Reserve導入によるコスト削減効果が大きくなる傾向があります。

セキュリティ

  • キャッシュされるのはオリジンから返されたレスポンスそのものであり、Reserve自体がアクセス制御ロジックを持つわけではない
  • 認証が必要なコンテンツやユーザー固有のレスポンスを誤ってキャッシュ対象にしないよう、Cache Rulesやオリジンのキャッシュ関連ヘッダー設計に注意する
  • 保存されるデータは基盤側で保護されるが、機密情報を含むレスポンスをキャッシュしないという設計判断はアプリケーション側の責務
キャッシュ対象の見極め

動的でユーザーごとに内容が変わるレスポンスを誤ってキャッシュしてしまうと、他ユーザーに意図しない情報が返る恐れがあります。Cache ReserveはCache Rulesで明示的に対象を絞り込み、静的で共有可能なコンテンツに限定するのが安全です。

関連サービス・比較

観点Cache Reserve通常のエッジキャッシュ
保持期間長期間保持しやすい容量・期間に制約がある
裏側の仕組みオブジェクトストレージベース各拠点の揮発性キャッシュ
主目的オリジンへのヒットを減らすエンドユーザーへの低レイテンシ応答
課金保存容量・オペレーション課金基本的に別途課金なし

ハンズオン / CLI例

# ゾーンのCache Reserve設定状況を確認
wrangler cache-reserve status --zone <ゾーンID>

# Cache Reserveを有効化
wrangler cache-reserve enable --zone <ゾーンID>

# 必要に応じて無効化
wrangler cache-reserve disable --zone <ゾーンID>

Cloudflare Service

Cache Reserveを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

ストレージ

比較で見る軸

クラウド: Cloudflare / カテゴリ: ストレージ / 難易度: intermediate

導入後に効く点

エッジのキャッシュから溢れたコンテンツをReserveに退避し、オリジンへのリクエストを減らしてコストと負荷を下げる。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Cloudflare
カテゴリ
ストレージ
難易度
intermediate
関連資格
—
設計柱
performance / cost / reliability

判断チェックリスト

  • 自社の用途が「ストレージ / performance」に近いか確認する。
  • 強みである「通常のエッジキャッシュより長く・広くコンテンツを保持する、R2ベースの永続的な追加キャッシュ層。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

ストレージperformancecostreliability
参考: 公式ドキュメント