再現性のないCSSバグとの付き合い方｜本番環境で突然崩れるあの恐怖を解決する

こんにちは！
今日は「再現性のないCSSバグ」についてお話しします。

これ、ほんまに厄介やん。
ローカルでは完璧に見えるのに、本番環境だけ崩れてる。
ページをリロードしたら直ってる。
ユーザーからの報告だけある。
こういう経験、ありませんか？
僕も何度も悔しい思いをしてきました。

再現性のないバグの正体

再現性のないバグって、実は「本当にランダムに起きてる」わけじゃないんです。
必ず何か原因があるんですよ。
単に、その原因が「条件付き」で発生してるだけなんです。

現場でよく見るのは、こういったパターンです。

• ブラウザキャッシュに古いCSSが残ってる
• CDNのエッジサーバーが古いファイルを配信してる
• ユーザーのブラウザストレージ内の古いメディアクエリ値
• JavaScript実行のタイミングで、CSSの読み込み順序が変わる
• 特定のネットワーク環境（モバイル、プロキシ経由）でのみ発生

「え、そんなことあるの？」って思われるかもしれませんが、ほんまにあるんですよ。
僕も最初の頃は、こういう原因に気づかずに何時間も悩んでました。

キャッシュとブラウザストレージの落とし穴

最もよくある原因は、ズバリ「キャッシュ周りの問題」です。
ローカル環境では、開発サーバーがキャッシュなしで動いていることが多いんですが、本番環境はそうじゃないんです。

チェックしてみてください。

• style.cssに「Cache-Control: max-age=31536000」みたいな長いキャッシュが設定されてない？
• CSSファイルのURLに、バージョン番号やハッシュが付いてない？
• CDNを使ってる場合、パージ（キャッシュ削除）がちゃんと動いてた？

ローカルではデベロッパーツールを開いて「Network」タブの「Disable cache」にチェックを入れてるから気づかないんですよね。
本番環境ではそのチェック、入ってないんです。

その他にも、Service Workerがバックグラウンドで古いCSSを返してることもあります。
これ、めっちゃ厄介で、ユーザーのブラウザを再起動しても直らないことがあるんです。

確実に切り分けする3つの手順

「あ、これ再現性ないな」って気づいたら、この3つを順番にやるといいですよ。

1. 本番環境でキャッシュなしアクセスを試す

まずはシンプルに、ブラウザキャッシュを完全にクリアしてアクセスしてみてください。
デベロッパーツールを開いて「Network」タブの「Disable cache」にチェックを入れて、リロードするんです。
それでも崩れてる場合は、キャッシュ問題ではなく別の原因があるはずです。

2. 本番ファイルをブラウザで確認する

デベロッパーツールの「Sources」タブを開いて、実際に読み込まれてるstyle.cssの内容を見てみてください。
「Network」タブで、CSSファイルのResponse Headersを確認するのもいいですよ。
「Last-Modified」の日付が、つい今しがたのアップロード時刻になってますか？

3. 異なるブラウザ・デバイスで試す

Chromeだけで試すのではなく、Safari、Firefox、Edge、あとはスマートフォンでも試してみてください。
「特定のブラウザでだけ起きる」という情報が得られれば、原因がグッと絞られます。

本番環境で試すときのコツ

実際に本番環境でデバッグするときの、ちょっとした工夫をお教えします。

まずは、ステージング環境がある場合はそこで試すべきです。
本番環境でうっかりconsole.log()を残しちゃったり、デバッグ用のCSSを入れっぱなしにするのは避けたいですから。

それでも本番環境で試す必要がある場合は、URLにクエリパラメータを付けるという手があります。
例えば、?cache-bust=123456みたいに付けるんです。
これでサーバー側のキャッシュをバイパスできることがあります。

あとは、シークレットウィンドウ（プライベートブラウジングモード）を使うのも効果的ですよ。
他の拡張機能やローカルストレージの影響を完全に排除できるんです。

もう一つ、大事なのは「タイミング」です。
ユーザーからの報告が「午前10時に見たら崩れてた」みたいな時間帯情報があったら、その時刻の前後にアップロードした内容を確認してみてください。
実は数時間のズレがあったりするんです。

まとめ

再現性のないCSSバグって、一見すると「謎の不具合」に見えますけど、実は必ず原因があるんです。
キャッシュ、ネットワークタイミング、ブラウザの状態、こういった「環境要因」をしっかり切り分けることが大事なんですよ。

本番環境で同じ症状を確認できたら、もう半分は解決したようなもんです。
あとは「どの条件下で発生するのか」を詰めていくだけなんです。

焦らず、一つずつ条件を消していく。
これが現場でのデバッグのコツですね。