Cloudflareへデプロイしたのに反映されないとき、最初の30分でやること
Cloudflareへデプロイしたのに反映されないとき、最初の30分で「どの版が配信中か確定 → 取り違え（環境/ドメイン/ルート）排除 → キャッシュ層（ブラウザ/CDN/オリジン）切り分け」で止血する手順です。
Cloudflareへデプロイしたのに「見た目が変わらない」「古いまま」に見えるときは、まず原因を 3つの層（ブラウザ / CDN / オリジン） に分けるのが最短です。
この記事は、Cloudflare（Workers/Pages/OpenNextなど）で「デプロイは成功したのに反映されない」状況になったとき、最初の30分で“止血”する手順をチェックリスト化したものです。
関連:
0. まず結論（先にやる順番）
最初の30分は「原因を当てにいく」より、「今どの版が配信されているかを確定する」ことを優先します。
- 反映されていない“場所”を確定（自分のブラウザだけ？ 一部の地域だけ？ 全員？）
- “今配信されている版”を確定（ヘッダ/HTML/アセットで判断）
- ルーティング/環境/プロジェクト取り違え（プレビュー・別環境・別ドメイン）を疑う
- キャッシュ層を疑う（ブラウザ → CDN → オリジンの順）
- 収束後に、再発防止の観測点（ビルドID表示/ヘッダ/ログ）を入れる
1. 影響範囲を固定する（最優先）
まずは「自分だけ」なのか「全員」なのかを確定します。
- 別端末（スマホ/PC）で同じURLを見る
- 別ブラウザ（Chrome/Safari等）で見る
- シークレット/プライベートで見る
- 可能なら 別回線（モバイル回線）で見る
ここで「自分のブラウザだけ」なら、ほぼ ブラウザキャッシュ/Service Worker 側です（Cloudflare側に手を入れる前に直せます）。
2. “今配信されている版”を確定する（推理禁止）
反映されないときに一番やりがちなのが、違う環境/違う版を見て推理することです。必ず“証拠”で固定します。
- HTMLのソースに 新しい文言 があるか（目視）
- 可能なら
curl -I <URL>で レスポンスヘッダ を見る（cache-control/etag/last-modifiedなど） - ブラウザのDevToolsで Network を開き、HTML/JS/CSSが本当に更新されているかを見る
ポイント:
- HTMLが古い → CDN/オリジン/ルーティング側の疑いが強い
- HTMLは新しいがJS/CSSが古い → アセットのキャッシュ（長すぎるTTLや配信先の取り違え）
- HTMLもアセットも新しいのに見た目が古い → Service Worker / アプリ側のキャッシュ（クライアントロジック）の疑い
3. 取り違え（プレビュー・環境・ドメイン・ルート）を潰す
Cloudflareの反映事故で多いのは「デプロイ先の取り違え」です。次を順に潰します。
- ProductionではなくPreview を見ていないか（URL/環境名）
- 別プロジェクト にデプロイしていないか（Workers/Pagesプロジェクト名）
- 別ドメイン/別サブドメイン を見ていないか（
wwwあり/なし、末尾スラッシュ、リダイレクト） - Route（ルート）設定 が意図どおりか（Workersのルーティング、Pagesのカスタムドメイン割当）
- 環境変数 の差で“挙動が変わって見える”だけではないか（API URL、機能フラグ等）
この段階で「確実に本番の正しいURLを見ている」が確定してから、キャッシュ層に進みます。
4. キャッシュを疑う（ブラウザ → CDN → オリジン）
4-1. ブラウザ（最優先・最短）
- DevToolsで Disable cache を有効にしてリロード
- ハードリロード（ブラウザ機能）を試す
- Service Worker が入っている場合は、更新/解除を確認（Applicationタブなど）
「シークレットでは新しいのに通常では古い」なら、ほぼここが原因です。
4-2. CDN（Cloudflareキャッシュ）
Cloudflareのキャッシュが原因かを確かめるには、まず“キャッシュが効いている証拠”を取ります。
cf-cache-statusなどキャッシュ関連ヘッダが見えるか- HTMLがキャッシュされているのか、アセットだけなのか
対処は、いきなり全消しではなく 最小の対象から にします（影響とコストを最小化）。
- 対象URLだけ を更新対象にする（可能なら）
- まずは アセットの更新（ファイル名がハッシュ化されていれば、多くは勝手に解決します）
4-3. オリジン（実はデプロイが差し替わっていない）
CDNの問題に見えて、実際は「新しい版がオリジンに存在しない」こともあります。
- ビルド/デプロイの成果物が本当に変わっているか
- 本番環境変数が想定どおりか（変えていないつもりが変わっている等）
- “同じコードに見えるが生成結果が変わる”要素がないか（データソース、API、ビルド時刻依存など）
5. 再発防止（30分の外）
止血できた後にやることです（最初の30分ではやりません）。
- HTMLに ビルドID/コミット短縮ID を埋め込む（“今の版”を一発で確定できる）
- 主要URLの ヘッダ観測（cache-control/etag等）を定期チェックする
- “本番URLが本番環境を見ている”ことを自動で検査する（preview混入防止）
SiteOpsで“反映されない”を早期検知する（再発防止）
反映事故は、気づくのが遅いほど機会損失が増えます。再発防止としては「誰が見ても“今の版”が分かる」状態に寄せるのが効きます。
- “今配信中の版”を、チーム内で同じ根拠（ヘッダ/ビルドID）で確認できる状態にする
- 反映が遅れた瞬間に、最初の30分で“止血”できるチェックリストを持つ
状況が再現できない/原因が複合している場合は、相談だけ先に進めるのも有効です。
この記事を書いた人
川原
SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。
関連記事
次にやること
複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。
料金を見る相談したい / お問い合わせ