Cloudflareのキャッシュ、消すか無効化するか

商品画像を数点差し替えただけなのに、確実に反映させたくてCloudflareの「Purge Everything」を押している。押した直後はオリジンにアクセスが集中して、ECサイトの表示が重くなるのが気になる。かといって消さずにおくと、取引先から「まだ古い画像のままです」と連絡が来る。

Cloudflareは2026年9月28日、キャッシュを消す（purge）以外の選択肢として、キャッシュを無効化する（invalidate）機能を追加しました。消さずに「古い」という印を付け、次のリクエストでオリジンに「変わりましたか」と確かめる方式です。同じ日に、Cache Reserveを使っている場合のpurgeの挙動も変わりました。

サイト更新のたびにどちらを使うかを判断できるよう、公式ドキュメントの記述を整理し、使い分けは編集部の提案として分けて書きます。

purgeは消す、invalidateは古い印を付ける

無効化は「soft purge」とも呼ばれます。対象の指定方法はpurgeと同じで、URL、キャッシュタグ、ホスト名、URLプレフィックス、すべて（everything）です。違うのは、指定したキャッシュがどうなるかです。

ダッシュボードでは Caching > Configuration の「Invalidate Cache」から実行します。APIはリクエスト本文の形式がpurgeと同じで、エンドポイントだけを invalidate_cache に替えます。

curl --request POST \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/invalidate_cache" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{"tags":["product-images"]}'

APIトークンに必要な権限はpurgeと同じ「Cache Purge」です。無効化は新しい内容を先回りして取りに行くわけではなく、無効化した後に最初のリクエストが来た時点で再検証が始まります。

図で見てほしいのは、変わっていないファイルの扱いです。purgeすると、変更のない画像も含めてすべてオリジンから取り直します。無効化なら、オリジンが 304 Not Modified を返したファイルは保存済みの内容を使い回し、新しいTTLを設定し直します。公式ドキュメントが使い道として挙げているのは、同じキャッシュタグの画像群のように「一部だけが変わった」まとまりの更新です。

使い回せるのは、オリジンが304を返せるときだけ

無効化の効果は、オリジン側の対応で決まります。Cloudflareは、オリジンが最初に返した ETag か Last-Modified ヘッダーを使って条件付きリクエストを送ります。オリジンがどちらのヘッダーも返していない、または条件付きリクエストに304で答えられない場合は、purgeと同じく応答全体を取り直します。公式ドキュメントは「無効化は再利用を保証しない」と明記しています。

確認で気をつけたいのが、Cloudflare経由の応答に Last-Modified が付いていても、オリジンが返しているとは限らない点です。オリジンがどちらのヘッダーも返さない場合、Cloudflareは自身のキャッシュ時刻を Last-Modified としてブラウザに返すことがあります（smart revalidation towards users）。この値はオリジンへの再検証には使われないため、ヘッダーはCloudflareを通さずオリジンに直接リクエストして確認します。

ほかに、次の制約があります。

• 304の応答では、Cache Response Rulesで付けたキャッシュタグは更新されない。オリジンの Cache-Tag ヘッダーは、304の応答にも含めた場合だけ更新される。タグを付け直したい場合はpurgeする
• ダッシュボードや invalidate_cache での無効化は、Workers Cache（Workerが持つキャッシュ）には効かない。Workers CacheはゾーンではなくWorkerに属するため、Workerのコードから ctx.cache.purge() を呼ぶ

オリジンがどのヘッダーを返すかは、CMSやホスティングの設定で変わります。ヘッダーがキャッシュの挙動を左右する仕組みは更新したのに古いページが出る原因をヘッダーから見た記事でも整理しています。

オリジンが落ちると、古い内容を出し続ける

無効化で最も注意したいのは、オリジンが応答しないときの既定の挙動です。

再検証中に古い内容を返すかどうかは、キャッシュされた応答の Cache-Control で決まります。stale-while-revalidate があれば、Cloudflareは古い内容を返しながら裏で再検証します。なければ、リクエストは再検証の完了を待ちます。再検証中の配信は、Cache Rulesの「Serve stale content while revalidating」で止められます。

一方、オリジンが 5xx を返すか到達できない場合は別です。Cloudflareは、stale-if-error の指定がなくても、キャッシュに残っている限り無効化した内容を古いまま配信できます。公式ドキュメントのトラブルシューティングは、これが既定の挙動で、Cache Rulesの設定ではこの挙動は変わらないと書いています。止め方は次のとおりです。

• 配信する期間を限りたい: オリジンの応答に stale-if-error を秒数で付ける
• 配信させたくない: stale-if-error=0 を付ける
• Origin Cache Controlが有効なら、must-revalidate、proxy-revalidate、s-maxage でも止まる
• すぐに配信をやめたい: 無効化ではなくpurgeする

公式ドキュメントの例では、Cache-Control: public, max-age=3600, stale-while-revalidate=30 の応答を期限前に無効化すると、無効化から最大30秒は再検証しながら古い内容を返せます（猶予は無効化した時点から数える）。stale-if-error がないため、オリジンが障害中なら30秒を過ぎても、キャッシュに残っている限り古い内容を返し続けます。

ここからは編集部の整理です。障害中も表示を保てる点は、商品一覧や記事ページでは利点になります。一方で、価格の誤表示や掲載してはいけない情報を差し替えたいときは、この挙動が裏目に出ます。そうした更新は無効化で済ませず、purgeを使うと決めておくのが安全です。

Cache Reserveを使っているなら、purgeの意味が変わった

Cache Reserveは、キャッシュをR2のストレージに保持して、エッジから押し出されても残す有料の機能です。2026年9月28日から、Cache Reserveの内容に対するpurgeは、種類を問わず必ずキャッシュミスになりました。

これまでタグ・ホスト名・プレフィックス・すべてのpurgeは、Cache Reserveの内容に再検証の印を付けるだけでした（URL指定はもともと削除しており変更なし）。APIとダッシュボードの両方に適用され、エッジキャッシュと同じ扱いになりました。

公式の告知は、費用への影響として次の点を挙げ、こうしたpurgeを頻繁に使う場合はオリジンの転送量とCache Reserveの利用量を見直すよう促しています。

• purge後の最初のリクエストはCache Reserveのミスになり、変わっていない内容もオリジンが全体を返す。その内容をCache Reserveに書き直す処理はClass A操作として課金される
• タグ・ホスト名・プレフィックス・すべてのpurgeでは、内容はすぐには削除されない。後のリクエストで置き換わるか保持期間が終わるまで、保存料金がかかり続ける

料金表では、保存が月1GBあたり0.015ドル、Class A操作（書き込み）が100万件あたり4.50ドル、Class B操作（読み取り）が100万件あたり0.36ドルで、課金対象の件数は100万単位に切り上げられます。purgeのリクエスト自体は無料の操作です。

これまでの「再検証する」挙動を続けたい場合は、同じリクエストを invalidate_cache に送ります。ただし無効化で減るのはオリジンからの転送量で、Cache Reserveの操作回数は減りません。304を受けて保存済みの内容を更新する処理はClass A操作で、URL指定の無効化はリクエストを送った時点でも保存済みの内容を更新し、これもClass A操作です。また、Cache Reserveから返す内容は、stale-while-revalidate があっても再検証中に古いまま返されません。古い内容を返せるのはエッジキャッシュにあるコピーだけです。

更新の種類ごとに使い分け、ヘッダーで確かめる

ここからは、上記の仕様を踏まえた編集部の提案です。

1. 誤掲載・価格・削除の依頼など、古い内容を一度も出したくない更新はpurge。 公式ドキュメントのとおり、先にオリジン側の内容を更新・削除してからpurgeします。順番が逆だと、次のリクエストで古い版が再びキャッシュされます。
2. 画像群やCSSなど、一部だけ変わったまとまりの更新は無効化。 キャッシュタグやプレフィックスで範囲を絞ります。公式ドキュメントは、すべてを無効化すると大量の再検証が起こりうるため、必要最小の範囲を選ぶよう勧めています。
3. オリジンの応答ヘッダーを先に確認する。 ETag か Last-Modified を返し、条件付きリクエストに304で答えるか。障害時に古い内容を出す期間を stale-if-error で決めているか。
4. Cache Reserveを使っているなら、purgeの頻度と課金を見直す。 タグ単位のpurgeを定期的に流している仕組みがあれば、無効化に切り替えるか、転送量と操作回数の推移を確認します。

purgeと無効化は、同じアカウント単位の上限を共有します。片方を多用すると、もう片方に使える量が減ります。上限は同じプランのゾーン間でも共有されます。

タグ・ホスト名・プレフィックス・すべての1リクエストあたり最大件数は、全プランで100です。CIやCMSのフックから更新のたびに自動でpurgeしている場合、無効化を足すと同じ枠を食い合います。

無効化が効いたかを確かめる

公式ドキュメントの手順は次のとおりです。オリジンが ETag か Last-Modified を返すキャッシュ可能なURLを用意し、テスト中はオリジンの内容を変えません。再検証を直接見るため、テスト用の応答には stale-while-revalidate を付けず、正のTTLを設定します。

1. CF-Cache-Status が HIT になるまでURLにリクエストする
2. そのURLを無効化する
3. もう一度リクエストして応答ヘッダーを見る（curl --silent --show-error --dump-header - --output /dev/null <URL>）
4. オリジンのログで、条件付きリクエストが届き304を返したことを確認する

Tiered Cacheを使っていると、下位のデータセンターは上位に再検証するため、オリジンが304を返していても EXPIRED や MISS が見えることがあります。最終的な確認はオリジンのログで行います。purgeのAPIが返す HTTP 200 も受け付けの応答にすぎず、purge後は再リクエストして HIT でなくなったことを確かめます。

キャッシュの運用は、サイトを作った後の保守の一部です。更新手順を誰が持つかという観点はホームページを作って終わりにするリスクの記事でも扱っています。

2026年9月30日に、Cloudflareのchangelog（2026年9月28日の2件）、Invalidate cached contentのガイド、Purge cacheの上限表、Cache Reserveのページ（Purge behavior・Pricing・Operations）、Revalidation、Cloudflare cache responsesを、公式ドキュメントのソースリポジトリ（2026年9月29日時点）で照合しました。developers.cloudflare.com はこの環境から開けなかったため、同じ内容のソースファイルを読んでいます。Cloudflareのゾーンでの無効化・purgeの実行、CF-Cache-Status の観測、Cache Reserveの課金額は検証していません。ダッシュボードのメニュー名は英語表記のまま記載しています。

Cloudflare配下のサイトの運用ルールや、リニューアル時のキャッシュ設計の見直しは、グリームハブへご相談ください。

Sources

• Invalidate cached content instead of purging it — Cloudflare Changelog
• Purge now forces a cache miss for Cache Reserve content — Cloudflare Changelog
• Invalidate cached content — Cloudflare Cache docs
• Purge cache — Cloudflare Cache docs
• Cache Reserve — Cloudflare Cache docs
• Revalidation — Cloudflare Cache docs
• Cloudflare cache responses — Cloudflare Cache docs