サイトを更新したのに一部の人だけ古いまま見える原因｜長期キャッシュの仕組みと、ファイル名を変える運用
サイトを更新したのに一部の人だけ古いまま見える原因｜長期キャッシュの仕組みと、ファイル名を変える運用
「サイトの料金表を更新したのに、お客様から『前の値段のままですよ』と連絡が来た。自分のパソコンで見ると、ちゃんと新しくなっている」——サイトを運用していると、いつかこの状況に出会います。全員が古いわけではなく、一部の人だけ古いまま。再現しようにも手元では再現できないので、原因の見当がつかないまま「そのうち直るだろう」と放置されがちです。
結論を先に書きます。この現象の主因は、CSSやJavaScript（サイトの見た目や動きを作るファイル）に設定された長期ブラウザキャッシュです。長期キャッシュが効いているファイルは、サーバー上で中身を差し替えても、以前に訪問したことのある人のブラウザには届きません。だから「初めて来た人・久しぶりの人には新しく、よく来てくれる人にだけ古い」という、一見不思議な分かれ方をします。
対処の正解は、スーパーリロードの案内でも、待つことでもなく、表示に関わる修正はファイル名を変えて公開するという運用です。この記事では、なぜ一部の人だけ古くなるのかという仕組みと、弊社が名古屋で26店舗分のサイトを運用する中で固めた切り分け手順・設計をまとめます。
結論：長期キャッシュのファイルは「中身の差し替え」では届かない
まず仕組みから押さえます。ブラウザは一度ダウンロードしたファイルを手元に保存し（これがブラウザキャッシュです）、次回の訪問ではサーバーに取りに行かずに手元のコピーを使います。どのくらいの期間コピーを使い続けるかは、サーバーが返す「Cache-Control」というヘッダで決まります。
高速化を意識して作られたサイトでは、CSSやJSに「max-age=31536000, immutable」——1年間、このファイルは変わらないものとして扱ってよい——という指定がされていることが珍しくありません。immutable（不変）という指定が付いていると、ブラウザは「新しくなっていないかサーバーに確認する」ことすらしません。1年間、黙って手元のコピーを使い続けます。
ここで重要なのは、この設定自体は間違いではないということです。CSSやJSを毎回ダウンロードさせないことで表示は確実に速くなり、表示速度はSEOにも離脱率にも効きます。長期キャッシュは、正しく使えば味方です。
問題は、この設定と「同じファイル名のまま中身だけ差し替える」更新方法の組み合わせです。サーバー上のstyle.cssを新しい内容に上書きしても、既訪問者のブラウザは「style.cssは1年変わらない」と約束された古いコピーを持っているので、サーバーに取りに来ません。更新が届くのは、キャッシュを持っていない人だけ。これが「一部の人だけ古い」の正体です。
だから長期キャッシュを使うサイトでは、中身を変えたらファイル名も変えるのが大前提になります。style.cssをstyle-v2.cssにする、あるいはビルドツールが自動で付ける「index-a1b2c3.js」のようなハッシュ付きファイル名を使う。ファイル名が変われば、ブラウザにとっては「持っていない新しいファイル」なので、必ず取りに来ます。ハッシュ付きファイル名は飾りではなく、この運用のための設計です。
実例：26店舗サイトの価格表記を一括更新したときの設計
弊社が運用している名古屋の美容サロンFC（26店舗分のサイト）で、メニュー価格の表記を全店一括で変更したときの実例です。この店舗サイト群は表示速度を優先して、JSファイルに1年のimmutableキャッシュを設定しています。
このとき「サーバー上のJSの中身だけを差し替える」方法を選ぶと、更新は既訪問者に届きません。リピーターの多い美容室のサイトで一番見てほしい常連のお客様にこそ旧価格が表示され続ける、という一番避けたい事態になります。そこで実際の作業は次の形にしました。
- 変更後のJSを新しいファイル名（日付入りの版名を付与）で配置する
- HTML側の読み込み参照を新ファイル名に書き換える
- 公開後、実際の配信内容に新しい価格文字列が含まれるかを確認する
HTMLファイル自体は短期キャッシュ（または毎回確認）にしてあるので、HTMLの参照が変われば全訪問者が数分内に新しいJSを取りに来ます。「HTMLは短く、CSS/JSは長く＋ファイル名で更新」という役割分担が、長期キャッシュ運用の基本形です。
起こりうる落とし穴も設計に入れておく
この運用には、知らないと引っかかるリスクが2つあるので、先に潰しておきます。
1つ目は、サーバー側キャッシュの時間差です。 共有レンタルサーバーの多くは、ブラウザとは別にサーバー側にもキャッシュ（一時保存）の仕組みを持っています。ここで注意したいのが、同じファイルでも圧縮方式（無圧縮・gzip・brotli）ごとに別々にキャッシュされる場合があることです。確認コマンド（curl）で無圧縮版を取得して「新しくなった」と判断しても、ブラウザが受け取る圧縮版はまだ古い、というずれが数分単位で起こりえます。公開直後の確認は、実際のブラウザ（またはブラウザと同じ圧縮リクエスト）で行うのが確実です。
2つ目は、確認した気になって実は別の問題だった、というケースです。 「反映されない＝キャッシュ」と思い込むと判断を誤ります。見分け方は単純で、時間を置いて取得したファイルのサイズが1バイトも変わらないなら、キャッシュではなく「そもそも更新できていない」を疑うべきです。サーバー側キャッシュの保持時間は多くの共有サーバーで数分程度（例えばCSS・JS・画像で2分といった設定が公式マニュアルに明記されている国内サーバーもあります）なので、数時間待っても同一なら原因は別にあります。
「一部の人だけ古い」と言われたときの切り分け手順
実際に連絡が来たときに、原因を順に絞り込む手順です。上から順に確認します。
手順1：サーバー上の実物が新しいかを確認する
まず「更新作業が本当に完了しているか」を疑います。シークレットウィンドウ（キャッシュを使わない閲覧モード）で開くか、URLの末尾に「?check=1」のような適当な文字を付けて開きます。これで新しい表示になれば、サーバー上の実物は新しく、原因はキャッシュ側です。
シークレットウィンドウでも古い場合は、更新そのものができていません。実務では「タイトルはキャッシュで古く見えていただけ、ロゴは本当に修正漏れだった」というように、キャッシュと修正漏れが混在しているケースが実際にあります。1カ所直っていることを確認して「全部直った」と判断せず、指摘された箇所を個別に確認します。
手順2：どのファイルが長期キャッシュかを確認する
ブラウザの開発者ツール（F12キー）のネットワークタブでページを再読み込みし、CSS・JSファイルの「Cache-Control」欄を見ます。「max-age=31536000」や「immutable」とあれば長期キャッシュです。あわせてファイル名を見て、ハッシュ（英数字の羅列）や版番号が付いているかを確認します。
- ハッシュ付きファイル名＋長期キャッシュ：設計は正しい。更新時にファイル名が変わっているかを確認する
- 固定ファイル名（style.cssなど）＋長期キャッシュ：今回の症状が構造的に起こる組み合わせ。運用の見直しが必要
手順3：ファイル名を変えて再公開する
固定ファイル名で長期キャッシュが効いてしまっている場合、すでに配られた1年キャッシュを外部から消す方法はありません。できるのは「新しいファイル名で公開し直し、HTMLの参照を差し替える」ことだけです。お客様に「Ctrl+Shift+Rで再読み込みしてください」と案内する方法もありますが、案内が届くのは連絡をくれた1人だけで、同じ状態の他の訪問者には届きません。個別の案内は応急処置、ファイル名変更が恒久対応と区別しておきます。
なお、WordPressのテーマやプラグインの多くが「style.css?ver=6.4.2」のようにバージョン番号をURLに付けているのは、まさにこの仕組みの簡易版です。番号が変わればブラウザは別URLとして取り直します。自作のCSSを直接編集している場合は、この番号が変わらないため同じ症状が出ることがあります。
長期キャッシュを「設定しない」のも損：正しい設定とセットで使う
逆のパターンにも触れておきます。共有レンタルサーバーの初期状態では、キャッシュや圧縮のヘッダが一切設定されていないことがあります。この場合「更新が届かない問題」は起きませんが、訪問のたびに全ファイルをダウンロードさせるため表示が遅く、ページ速度の診断ツールでも減点され続けます。
弊社で運用しているサイトでも、キャッシュヘッダ皆無の状態から.htaccess（サーバーの設定ファイル）で圧縮と長期キャッシュを設定し、表示速度の評価を改善した実例があります。まとめると、次の組み合わせが基本形です。
| 対象 | キャッシュ設定 | 更新の届け方 |
|---|---|---|
| HTML | 短期（数分〜なし） | 上書きすれば全員に届く |
| CSS・JS | 長期（1年＋immutable） | ファイル名を変えてHTMLの参照を更新 |
| 画像 | 長期 | 差し替え時はファイル名を変える |
長期キャッシュだけ設定して、ファイル名を変えない運用を続けるのが一番危険な組み合わせです。速度のためにキャッシュを強くするなら、更新の届け方も必ずセットで設計します。
まとめ：「誰に届いていないか」で原因が分かる
サイトを更新したのに一部の人だけ古いまま見える現象は、故障ではなく、長期ブラウザキャッシュの仕様どおりの動きです。ポイントを整理します。
- 長期キャッシュ（immutable）が付いたCSS・JSは、中身を差し替えても既訪問者には届かない。「よく来る人ほど古い」のはこのため
- 表示に関わる修正はファイル名を変えて公開し、HTMLの参照を更新するのが恒久対応。スーパーリロードの案内は応急処置にしかならない
- 切り分けは「シークレットウィンドウで新しいか」→「Cache-Controlとファイル名の組み合わせ」の順。時間を置いてもファイルサイズが変わらないなら、キャッシュではなく更新漏れを疑う
- 公開直後の確認は実際のブラウザで。サーバー側キャッシュは圧縮方式ごとに残ることがあり、コマンド確認だけではずれが出る
- 長期キャッシュ自体は表示速度の味方。設定しないのも損で、「HTMLは短く、CSS/JSは長く＋ファイル名運用」のセットで使う
「一部の人だけ古い」は、キャッシュを持っている人と持っていない人の差がそのまま見えている状態です。仕組みが分かれば、原因の特定も対処も数分で終わります。もし自社サイトがどの設定になっているか分からない、更新のたびに反映で困っている、という場合は、現在の設定の診断からお手伝いできますので、お気軽にご相談ください。