直したはずのコードが画面に反映されず、古い表示のままのモニターを前に落ち着いて原因を考えている一人運用の保守担当者
保守・改修約11分

「直したのに直らない」を切り分ける｜キャッシュを疑う順番

コードは直した。ファイルもアップした。なのに、ブラウザで開くと画面は古いまま——。 保守運用をしていると、この「直したのに直らない」に何度も出会いますよね。自分の直し方を疑い始めて、同じ場所を何度も見返し、そのうち「もしかしてバグが別にある？」と不安がふくらんでいく。あの時間、地味に消耗します。

でも、こういうときの犯人は、コードそのものではなくどこかに残った「古い値」＝キャッシュであることがとても多いです。原因は「あなたの修正ミス」ではなく、「表示までの経路のどこかで、古いものがまだ生きている」だけかもしれません。

この記事では、「直したのに直らない」に出会ったとき、キャッシュを手前から順番に疑って切り分ける手順を一緒に整理します。むやみに全部消して回るのではなく、どこから見れば早いかの話です。

結論：まず「本当に直っていない」のか「表示だけ古い」のかを1回だけ確かめます（別ブラウザやシークレットウィンドウで開く）。表示だけ古いなら、①ブラウザ → ②CDN/リバースプロキシ → ③アプリ（ページ・OPcache等）→ ④データ（DB・オブジェクトキャッシュ）の順に、手前から一段ずつ疑います。いきなり全キャッシュを消すのではなく、「どの層で古いままか」を先に特定するのが、結果として一番早くて安全です。

キャッシュの仕組みは、構成（CDNの有無、WordPressか自作か、Redis等を使っているか）で大きく変わります。順番と考え方を出発点に、自分の現場の道具に置き換えて使ってください。

何が起きているか：古い値は「1か所」ではなく「経路のどこか」に残る

「直したのに直らない」がやっかいなのは、古い値が残る場所が1つではないからです。ユーザーの画面にたどり着くまでに、内容は何度もどこかに「保存」されています。

つまり必要なのは「全部消す気合い」ではなく、どの層で古いままなのかを1つに絞る目です。次から、その順番を見ていきます。

キャッシュを手前から疑う4つの層

ブラウザ・CDN・アプリ・データの4つの層を手前から順にたどってキャッシュを切り分ける流れ図
「ブラウザ→配信→アプリ→データ」の手前から順に。どの層で古いままかを一つに絞る

大事なのは、ユーザーに近い「手前」から順に疑うことです。手前で片づけばそれで終わりますし、手前を確かめずに奥（DBなど）から触ると、原因でない層まで消して回ることになります。

① まず「自分の環境」を疑う（ブラウザ）

いちばん最初にやるのは、コードを見直すことではなく、別の見方でもう一度開くことです。ここで「実は直っていた」と分かるケースが、驚くほど多いです。

ここで別ブラウザだと新しく見えるなら、犯人は自分のブラウザキャッシュです。奥の層は触らなくて大丈夫。逆に、どの環境で見ても古いなら、原因はもっと奥にあります。次の②へ進みます。

ここで一呼吸。「自分の環境だけだった」と分かっても、確認の仕方が慎重だっただけで、恥ずかしいことではありません。手前から確かめたからこそ、無駄に奥を触らずに済んでいます。

② 配信の途中を疑う（CDN・リバースプロキシ）

どの環境でも古いなら、次はユーザーとサーバーのあいだにいる層です。CloudflareなどのCDN、nginx等のリバースプロキシ、キャッシュプラグインが、古いページやファイルを配って返していることがあります。

パージしたら、また①のシークレットウィンドウで開き直して確かめます。「消す→確かめる」を1層ずつやるのが、すれ違いを防ぐコツです。

③ アプリの中を疑う（ページキャッシュ・OPcache など）

配信層でも直らないなら、アプリケーションの内側です。ここは仕組みが分かれます。

ここは環境（言語・フレームワーク・デプロイ方法）で手順がまったく違うところです。自分の現場の「デプロイ後にやること」に、これらのクリアが手順として入っているかを確認しておくと、次から迷いません。

④ データの層を疑う（DB・オブジェクトキャッシュ）

見た目の入れ物ではなく、中身の値そのものが古いパターンです。手前を全部消しても直らないときは、ここを疑います。

この層に来たら、消す前にまずバックアップ・件数確認を。とくにDBのデータを触る操作は、キャッシュのつもりで本体を壊さないよう、手前の層で本当に絞り込めているかを確かめてから動きます。

具体例：「価格を直したのに、古い価格のまま表示される」

よくある報告で、順番に切り分けてみます。

犯人は1つではなく、②と③と④に少しずつ残っていたわけです。もし最初に「全部まとめて消す」をやっていたら、どこが効いたのか分からず、次に同じことが起きたとき、また全消しに頼ることになります。手前から一段ずつ確かめたからこそ、「この構成では価格変更のたびに②③④を消す必要がある」という次に活きる知識が残りました。

影響：疑う順番を持つと、何が変わるか

キャッシュの切り分け順を1枚持っておくと、直す力そのものより先に、焦りと手戻りが減ります。

逆に、毎回いきなり全部のキャッシュを消していると、たまたま直った日と、消してもいない層のせいで直らず半日溶かす日の差が大きくなります。順番は、その日の自分を助ける道具です。

明日やること：自分の現場の「キャッシュ地図」を1枚書く

立派な資料は要りません。明日できる、いちばん小さな一歩はこれです。

  1. 自分が担当するサイトで、ユーザーの画面までにキャッシュしている層を思いつくだけ書き出す（ブラウザ／CDN／プロキシ／プラグイン／OPcache／Redis／DBの集計値など）。
  2. それぞれの層について、「消し方（コマンド・管理画面の場所）」を1行メモする。
  3. 分からない層があれば、それが「次に詰まりやすい場所」です。印だけ付けておく。
  4. 次に「直したのに直らない」が来たら、この地図を手前から順にたどる。
  5. 実際に効いた層に印を付け、「変更のたびに消すべき層」をメモに残す。

きれいに描かなくて大丈夫です。「どこに古い値が残りうるか」の地図が1枚あるだけで、次の自分（や引き継ぐ人）が、同じ全消しループに迷い込まずに済みます。

「直したのに直らない」チェックリスト

切り分けに着手するとき、これだけ確認できているかを見る項目です。コピーして、自分のメモに当ててみてください。全部を毎回そろえる必要はありません。

まず外せない最低ラインはこの3つです。急いでいても、ここだけは押さえます。

次の項目は、手前で片づかないとき・原因が複数にまたがるときに追加で確認します。当てはまらなければ飛ばして大丈夫です。

全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「別ブラウザで確かめたか」さえ押さえられれば、ありもしないバグを探して消耗するより、ずっと確かな一歩になります。

よければ、こちらも

キャッシュの切り分けは、落ち着いて動くための「順番」があるほど楽になります。表示の異常を追う技と、本番で消して回るときの備えをセットにしておくと、次の「直らない」がだいぶ軽くなります。

古い表示のまま止まっていた原因がキャッシュだと突き止め、正しく反映された画面を見て肩の力が抜けた保守運用の担当者

「直したのに直らない」がこわいのは、自分の直し方を疑い始めてしまうからです。でも、手前から順にキャッシュを疑うと決めるだけで、霧はかなり晴れます。多くの場合、あなたの修正は正しくて、ただどこかに古い値がまだ座っていただけです。 今日は、自分の現場のキャッシュ地図を1枚描いてみるところからで十分です。その1枚が、次の「直らない」を、迷路ではなく手順に変えてくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語