料金表を差し替えたのに、取引先から「まだ古い金額が出ています」と連絡が来る。自分のパソコンでは新しい内容が表示されているので、再現もできない。
Web サイトの運用でいちばん説明しづらいのが、この手の「人によって見えているものが違う」現象です。そして相談を受けて調べると、原因がサイトの作り方ではなく、サーバーが返している目に見えないヘッダーだった、というケースが少なくありません。
厄介なのは、その原因が分かっても直せないことがある点です。「アプリケーション側を修正する必要があります」と言われて、そこで話が止まる。触れないシステムが原因なら、打つ手がなくなります。
「反映されない」と「毎回遅い」は同じ場所で起きている
Web ページが利用者に届くまでに、内容は複数の場所に控えを持ちます。おおまかには、閲覧者のブラウザ、その手前にある CDN、そして実際にページを生成しているサーバー（オリジン）の3層です。
古い内容が出続けるのは、このどこかに前回の控えが残っているからです。逆に、毎回サーバーまで問い合わせが飛んでしまうと、控えが効かないぶん表示が遅くなります。「反映されない」と「毎回遅い」は正反対の症状に見えて、どちらもキャッシュが意図どおりに効いていないという同じ原因から出てきます。
どちらに転ぶかを決めているのは、オリジンが応答と一緒に返すヘッダーです。代表的なものが次の3つです。
- Cache-Control — この内容をどれだけの時間、どこで保存してよいかの指示
- Set-Cookie — 利用者ごとに違う値を渡すもの。これが付いていると、共有の控えを作れないと判断されやすい
- ETag / Last-Modified — 内容が変わったかどうかを判定するための目印
問題は、これらがアプリケーションの奥のほうで自動的に付けられることが多い点です。古い CMS が全ページに一律で Set-Cookie を付けている、テーマやプラグインが独自に Cache-Control を書き換えている、といった状況は珍しくありません。
触れないシステムが原因、という詰まり方
制作会社を変えた後のサイトや、10年前に構築した業務システムに乗ったページでは、この構造が壁になります。
原因の特定まではできる。しかし修正しようとすると、改修の見積もりが必要になり、そもそもソースコードが手元にないこともある。実際に受けた相談では、レガシーサイトの引き継ぎと保守で扱ったように、稼働中のシステムに手を入れる前提だと費用も納期も跳ね上がります。表示速度の改善を提案しても、「そこまでするなら作り直す」となって、結局どちらも進まない。
画像の配信最適化はCDN による画像最適化のように外側だけで完結させやすい一方、HTML そのもののキャッシュはオリジンの指示に強く縛られてきました。これが、外側からは直せない領域として長く残っていた部分です。
応答を受け取った後に調整できるようになった
Cloudflare が2026年7月に公開した Cache Response Rules は、この制約に手を入れるものです。
従来のキャッシュ設定は、リクエストの内容（URL やホスト名など）を見て動くものでした。今回追加されたのは、オリジンが応答を返した後、その内容をキャッシュに書き込む前に評価される段階です。この位置に処理を挟めるようになったことで、オリジンのアプリケーションを変更せずに次のような調整ができます。
- Cache-Control の指示を書き換える
- キャッシュタグを付与して、後からまとめて破棄できるようにする
- Set-Cookie、ETag、Last-Modified といったヘッダーを取り除く
Cloudflare 自身が挙げている典型例は、「本来なら問題なくキャッシュできるはずの内容が、余計な Set-Cookie や誤った Cache-Control のせいでオリジンまで引き戻されてしまう」状況です。しかもそれらは、オリジン側では変更が難しい、あるいは不可能なことがある。直せない場所が原因であることを前提にした機能という位置づけです。
副次的な効果として、CDN の乗り換えも楽になります。移行のたびにオリジン側のヘッダー設定を合わせ込む作業が発生していたのが、外側で吸収できるようになるためです。
発注側から見て何が変わるか
技術的には CDN の設定機能の追加ですが、発注する立場から見ると意味が違ってきます。
これまで「アプリケーションの改修が必要です」と回答されていた症状の一部が、改修せずに設定で解決できる可能性が出てきたということです。そのため、症状を伝えるときの言い方も変わります。「サイトが遅い」「更新が反映されない」とだけ伝えると、たいてい作り直しの話になりますが、次のように事実を分けて伝えると、切り分けが早く終わります。
- どのページで起きているか（全ページか、特定のページだけか）
- 誰の環境で起きているか（社内だけか、社外からもか）
- いつからか（更新作業の直後か、以前からか）
- ログインが必要なページかどうか
この4点が揃っていれば、ブラウザ側の問題か、CDN の設定で対処できるのか、本当にアプリケーションの改修が要るのかを、初期の切り分けで判断できます。費用が発生する改修に進む前に確認すべきことがある、という前提を持てるかどうかが実務上の差になります。
外側で直すときに事故らせない線引き
一方で、キャッシュの設定を外側から書き換えるのは、扱いを間違えると影響が大きい操作でもあります。
とくに Set-Cookie を取り除く設定は注意が必要です。ログイン状態やカートの中身、フォームの入力途中の情報は Cookie で保持されていることが多く、これを一律に除去すると、利用者ごとに違うはずの内容が他の人にも表示されるという重大な事故につながります。
したがって、外側で調整してよいのは基本的に「誰が見ても同じ内容のページ」に限られます。会社案内、サービス紹介、記事、画像やスタイルシートといった静的な資産。逆に、マイページ、カート、問い合わせフォームの確認画面、管理画面は対象から外す。この線引きを設定に入る前に文書で固めておくことが、そのままリスク管理になります。
設定を入れた後の確認も、担当者自身のブラウザでは不十分です。キャッシュを消した状態、別の回線、別の端末で確認するところまでを手順に含めてください。
次にやること
自社サイトで「更新したのに反映されない」と言われた事例を、思い出せる範囲で書き出してみてください。どのページで、誰から、いつ言われたか。その3つが並ぶだけで、保守を依頼している相手に渡せる情報になります。原因の特定は相手の仕事ですが、切り分けの材料を渡せるかどうかで、返ってくる回答の精度が変わります。
もし過去に「アプリケーションの改修が必要」と言われて保留にしている案件があるなら、いまは前提が変わっている可能性があります。改修以外の選択肢がないか、あらためて確認する価値があります。
Web サイトの表示速度や更新が反映されない問題の切り分け、既存サイトの保守・リニューアルについては、グリームハブの HP 制作・リニューアル相談で承っています。現在の構成や契約状況によって取れる手段が変わるため、個別にご相談ください。お問い合わせからどうぞ。
