CDNキャッシュが更新されない時の正しい対処法｜実際の現場で起こるケースと解決策

こんにちは！

今日は「CDNキャッシュが更新されない時の正しい対処法」について解説します。

これ、めっちゃよくある悩みなんですよね。
「CSSファイルを更新したのに、本番環境で古いスタイルが表示されたままや」という経験、みんなありませんか？

CDNキャッシュが本当に「更新されない」わけではない話

僕も昔、この問題で朝の2時間を無駄にした経験があります。
修正したJavaScriptファイルを本番環境にアップロードしたのに、ユーザーからは「表示が変わってない」という報告が来て……。
めっちゃ焦りましたね。

でもここで気づくべき大事なポイントなんですが、CDNキャッシュって「更新されない」んじゃなくて「更新されるまでの時間が長い」だけなんです。
ここを勘違いしてると、原因特定が難しくなるんですよ。

CDNの仕組みをざっくり説明するとこんな感じです：

• あなたが/css/style.cssをサーバーにアップロード
• CDNは「あ、このURLのファイル、キャッシュしてるな」って判定
• キャッシュのTTL（有効期限）が切れるまで、古いファイルを配信し続ける
• TTLが切れてから初めて、新しいファイルを取得して再度キャッシュ

つまりですね、CDNキャッシュの問題って「URLが変わってない」ことが原因なんです。
同じファイル名、同じパスで更新されたファイルをアップロードすると、CDNは「あ、新しい内容やん」って気づかずに、古いキャッシュを配信し続けちゃうんですよ。

実践的な対処法：キャッシュキーの工夫

ほんまに効果的な対策は「ファイルのURLを変える」ことです。
現場では主に2つの方法が使われています。

方法1：クエリストリングによるバージョニング

最もシンプルで、僕が一番よく使うやり方は、URLの末尾にバージョン番号やハッシュ値を付ける方法です。

具体例として、HTMLファイルでこう書くんですよ：

<link rel="stylesheet" href="/css/style.css?v=1.2.3">

このバージョン番号を1.2.4に変えると、CDNは「あ、新しいURLや」って認識して、新しいファイルを取得してくれます。
ほんま単純ですけど、効果は抜群ですよ。

ただしですね、毎回手作業でバージョン番号を管理するのは大変やん。
だから、本番環境ではビルドツールが自動で日時やハッシュ値を付けるように設定するんです。

例えばWebpackなら、output.filenameで[contenthash]を使うことで、ファイルの内容が変わった時だけ自動的に新しいハッシュ値が生成されます。

方法2：ファイルのハッシュ値をファイル名に含める

もっとプロフェッショナルな方法は、ファイル名そのものにハッシュ値を含める方法です。

ビルドプロセスで自動的にこんなファイルが生成されます：

• style.a3f5d2e1.css
• app.7b8c2f9d.js

ファイルの内容が1文字変わっても、ハッシュ値は完全に別物になります。
だから更新を検出できるんですね。

この方法は最高のキャッシュ効率が実現できます。
なぜなら、変わったファイルだけURLが変わるから、変わらなかったファイルはキャッシュをそのまま使い続けられるんです。

CDNのコンソールで確認する方法

対策を打ったのに、本当に新しいファイルが配信されてるのか確認したいですよね。
現場で僕が使ってる確認方法を紹介します。

ブラウザの開発者ツールで確認

Chrome、FirefoxなどのブラウザのNetwork タブで確認できます。

• F12キーで開発者ツールを開く
• 「Network」タブをクリック
• ページをリロード（キャッシュを無視するなら Ctrl+Shift+R）
• CSSやJavaScriptファイルをクリック
• 「Response」タブでファイルの内容を確認
• 「Headers」タブでCache-ControlやETagを確認

ここで大事なのは、ETagという値です。
ファイルが新しくなると、このETagも変わります。
前回と違うETagが見えれば「あ、CDNが新しいファイル取得したんやな」って確認できるんですよ。

HTTPヘッダーのCache-Controlを確認

Response Headers にCache-Controlというヘッダーが見えます。

例えばこんな感じです：

Cache-Control: public, max-age=86400

このmax-age=86400は「86400秒（つまり1日間）、このファイルをキャッシュしてね」という意味なんです。
つまり、更新しても1日間は古いファイルが配信され続けちゃうってわけですね。

本番環境では、ハッシュ値でファイル名を変える対策をしてるなら、このmax-ageをめっちゃ長くしても大丈夫です。
なぜなら、ファイルが変わったら別のURLになるから。

でも、ハッシュ値がない場合は、max-ageを短めに設定する必要があります。
ほんま、この設定は大事なんですよ。

CDNプロバイダーのダッシュボード

CloudFlare や AWS CloudFront を使ってるなら、プロバイダーのコンソールでもキャッシュ状況が確認できます。

CloudFlare の場合：

• ダッシュボードにログイン
• 対象のドメインを選択
• 「Caching」タブで現在のキャッシュ状況を確認
• 必要に応じて「Purge Cache」でキャッシュをクリア

AWS CloudFront の場合：

• CloudFront コンソールを開く
• Distribution を選択
• 「Invalidations」タブで特定のパスのキャッシュをクリア

緊急時はキャッシュをクリアしちゃうのが一番早いです。
でも毎回これをやってると、CD