Cloudflare Cache Rulesの設定方法｜CDNキャッシュ・除外・Purgeを安全に運用する
CloudflareのCDNは、オリジンサーバーまで取りに行く回数を減らし、利用者に近い拠点からコンテンツを返します。しかし、何でも長く保存すれば速くなるわけではありません。個人別ページや更新直後の情報を誤ってキャッシュすると、古い内容や別利用者向けの内容を返す事故になります。
Cache Rulesを使うと、URL、ホスト名、パス、拡張子などの条件に応じてキャッシュ可否やTTLを制御できます。重要なのは、ルール作成より前に『共有してよいレスポンス』と『毎回オリジンで処理すべきレスポンス』を分類することです。
Cloudflareのキャッシュ設定は、静的資産から始め、公開HTMLを必要に応じて追加し、ログイン・管理画面・フォーム・個別APIを明示的に除外するのが安全です。更新時のPurgeとCF-Cache-Statusなどの確認まで一つの運用にします。
本記事のポイント
- 最初に静的ファイルと公開HTML、除外すべき個別ページを分類します。
- ログイン、カート、管理画面、フォーム確認・完了、個別APIはCookieや認証を考慮して除外します。
- 更新時のPurgeとレスポンスヘッダー確認を運用へ組み込み、キャッシュヒット率だけで評価しません。
この記事で分かること
| 確認対象 | 見る内容 | 判断のポイント |
|---|---|---|
| 静的資産 | 画像、CSS、JavaScript、フォント | 標準動作を確認し長めのTTLを検討 |
| 公開HTML | 全利用者へ同じ内容を返すページ | 更新頻度とPurge手順を前提に追加 |
| 個別ページ | ログイン、会員、カート、管理画面 | 原則としてキャッシュを回避 |
| 業務経路 | フォーム、Webhook、API | 認証・Cookie・POST・応答内容で判断 |
| 更新処理 | 公開、差し替え、緊急訂正 | 対象URL単位のPurgeを標準化 |
標準キャッシュ動作を先に理解する
Cloudflareはファイル拡張子やレスポンス条件などに基づいて標準のキャッシュ判断を行います。Cache Rulesを追加する前に、対象URLへリクエストし、レスポンスヘッダー、オリジンのCache-Control、Cookie、認証状態を確認します。
『キャッシュされていない』理由がオリジンのヘッダーなのか、Cloudflareの標準動作なのか、既存ルールなのかを分けると、不要な強制キャッシュを避けられます。
Cache Rulesで対象と除外を明示する
公開HTMLをキャッシュする場合は、対象ホスト・パスを狭く始めます。管理画面、プレビュー、検索結果、会員領域、カート、決済、フォーム確認・完了などは、パスだけでなく認証Cookieやレスポンスの性質も確認します。
ルールが複数ある場合は評価順序と条件の重なりを確認します。広いルールの後に例外を置いたつもりでも、別の設定で再度キャッシュ対象になることがあります。変更前後のルール一覧とテストURLを記録します。
Edge TTLとBrowser TTLを分ける
Edge TTLはCloudflareの拠点に保持する時間、Browser TTLは利用者のブラウザへ保存を許す時間です。Cloudflare側をPurgeしても、ブラウザ側の長いキャッシュが残れば利用者には古い内容が見える場合があります。
更新頻度が高いHTMLと、内容がハッシュ付きファイル名で変わる静的資産では適切なTTLが異なります。『長いほど良い』ではなく、更新方式と緊急差し替え要件で決めます。
Cache KeyとCookieの扱いを慎重に決める
クエリパラメータ、ヘッダー、CookieをCache Keyへ含めるかで、同じURLを同じキャッシュとして扱う範囲が変わります。不要なパラメータをすべて別キャッシュにすると効率が落ち、必要な個別条件を無視すると誤配信になります。
まずはデフォルトに近い構成で観測し、計測用パラメータ、言語、デバイス、ログイン状態など、実際にレスポンスが変わる要因だけを設計します。
Purgeと公開後確認を運用へ組み込む
更新時はPurge Everythingを常用せず、対象URLやタグなど、影響を限定できる方法を優先します。全消去は一時的にオリジン負荷を上げ、サイト全体のキャッシュを温め直す必要があります。
公開後は対象URL、関連画像、CSS、JavaScriptを確認し、CF-Cache-Status、Age、Cache-Controlなどを見ます。問い合わせフォームなどの重要経路は、キャッシュ変更後も実送信テストを行います。
本番導入で必要な変更管理と評価方法
Cloudflareの設定は通信経路の手前で効くため、小さな変更でも複数ページや外部連携へ影響します。開発・検証環境で再現できるものは先に試し、本番では対象ホスト、パス、利用者、時間帯を限定して段階反映します。変更票には目的、変更前後、実施者、承認者、確認URL、期待結果、切り戻し条件を残します。
確認は「画面が開くか」だけで終えません。HTTPステータス、レスポンスヘッダー、認証、フォームやAPIの完了、オリジンログ、Cloudflareイベントを同じ時刻で照合します。正常系だけでなく、権限なし、期限切れ、過剰アクセス、外部API停止、再送などの異常系も試し、利用者へ返すエラーと運用担当者が見る証拠を分けます。
導入効果は、表示速度やブロック件数など一つの数値だけで評価しません。可用性、正常完了率、オリジン負荷、エラー率、誤検知、サポート問い合わせ、変更作業時間、月額・従量費を導入前後で比較します。性能が上がっても問い合わせやログインの失敗が増えていれば、事業成果としては改善していません。
料金と上限は利用プランや使用量で変わります。無料枠や小規模検証の結果をそのまま本番へ外挿せず、ピーク時のリクエスト、保存・操作、ログ量、利用者数、サポート、監査要件を公式料金ページと契約条件で確認します。上限へ近づいたときの通知と、機能を縮退させる順序も決めます。
設定の所有者と定期レビュー日を決め、不要なルール、トークン、例外、接続先を残しません。Cloudflare画面だけでなく、設定のエクスポート、コード、変更履歴、復旧手順をチームで参照できる場所へ保管します。担当者の退職や委託先変更があっても、誰が承認し、どこまで戻せるか分かる状態を維持します。
公開後は一週間程度の観測期間を設け、導入前と同じ時間帯・同じURL・同じ業務操作で比較します。異常がなくても、例外が増え続けていないか、想定外の回避策が現場で使われていないかを確認します。問題が見つかった場合は、影響を受けた利用者とデータを特定し、暫定回避と恒久修正を分けて記録します。
また、Cloudflare以外の構成要素を含む依存関係図を残します。DNS、レジストラ、オリジン、IdP、メール、外部API、監視、CI/CDのどこで設定が重複し、どこが単一障害点になるかを明示します。障害時に別サービスの担当者へ連絡すべき条件も決めておくと、Cloudflare側だけを調べ続ける時間を減らせます。
本番の設定変更は、可能ならAPIやInfrastructure as Codeで再現可能にし、画面で行った緊急変更も後から正本へ戻します。秘密情報は設定ファイルへ直接書かず、環境ごとのSecret管理へ分離します。手作業とコードの状態がずれると、次回デプロイで緊急修正が消えるため、復旧後の同期までをインシデント対応に含めます。
公開・変更前チェックリスト
- 静的・公開HTML・個別ページを分類した
- 管理画面・ログイン・フォーム・APIの除外を確認した
- Edge TTLとBrowser TTLを分けて決めた
- Cookieとクエリによるレスポンス差を確認した
- ルールの評価順序を記録した
- 対象URL単位のPurge手順を用意した
- 公開後にヘッダーと主要業務経路を確認した
よくある質問
Cache Everythingは使うべきですか？
全利用者へ同じ内容を返せる範囲に限定し、個別ページの除外と更新時Purgeを設計できる場合に検討します。サイト全体へ無条件に適用しません。
CF-Cache-StatusがDYNAMICなら異常ですか？
必ずしも異常ではありません。レスポンスの種類、Cookie、Cache-Control、ルールなどによりキャッシュ対象外になるため、期待する動作と照合します。
Purge Everythingは危険ですか？
緊急時には有効ですが、全オブジェクトがミスになりオリジン負荷が上がります。通常更新では対象を限定する方が安全です。
WordPressの管理画面もキャッシュされますか？
管理画面やログイン状態は除外する必要があります。プラグインやテーマの動的処理もあるため、WordPress向け設定を別途確認します。
関連ページと関連記事
仕様確認に使った公式情報
Cloudflareの機能、プラン、上限、画面構成は更新されます。実装時は利用する機能の最新公式ドキュメントも確認してください。
まとめ
Cloudflareのキャッシュを安全に効かせるため、対象・除外・TTL・更新時Purge・検証方法を実務順に整理します。 設定を有効にしただけで完了とせず、正常系・異常系・切り戻しを同じ手順で確認することが、安全な運用につながります。
