キャッシュは、一度取得・計算した結果を保存し、同じ結果が必要になったときに再利用する仕組みです。たとえば、記事一覧を毎回DBから集計する代わりに、直前の集計結果を返します。処理や通信を減らせますが、保存した後に元データが変わると、古い内容を返す場合があります。
ヒット・ミス・有効期限の関係
要求に使える保存済みの結果が見つかれば「キャッシュヒット」、見つからなければ「キャッシュミス」です。ミスした場合は、元のDBやAPIから取得・計算し直す処理が必要です。
保存結果をどの要求に使うかは「キー」で区別します。記事IDだけで足りる場合もあれば、検索条件、言語、ページ番号、利用者の権限まで含める必要がある場合もあります。違う結果を返すべき要求を同じキーへまとめると、速さ以前に内容が誤ります。
TTLは保持や再利用の期限を考えるときに使う時間です。ただし、アプリのキーが期限切れで消える仕組みと、HTTP応答が古くなって再検証される仕組みは同じではありません。「期限が来たら、必ずその場で元データを取り直す」と一括して考えないようにします。
古い内容が見えるときは、保存されている層を分ける
| 層 | 保存するものの例 | 調べる対象 |
|---|---|---|
| ブラウザ | CSS、画像、HTTP応答 | 実際の要求URL、メモリ・ディスクからの取得表示、応答ヘッダー |
| CDN | 複数利用者へ配るHTTP応答 | キャッシュキー、保持ルール、配信元の内容、事業者のヒット・ミス表示 |
| アプリ | Redisなどに置いた集計結果 | 対象キー、期限、更新時の無効化、キャッシュミス時の再生成 |
| データベース内部 | ディスク上のページなどのバッファ | DB固有の管理・統計。HTTPの更新反映と同じ操作で扱わない |
「自分だけ新しい」という現象だけでは、CDNやサーバーが原因だとは決められません。ブラウザに残る応答、ログイン状態、異なるURLや配信条件なども比較します。また、アプリを再起動しても、別プロセスのRedisやCDNにあるキャッシュが消えるとは限りません。
たとえばCSSを更新したのに色が変わらない場合は、ブラウザの開発者ツールで読み込んだCSSのURLと内容を確認します。そこが古ければ配信経路を追い、CSSが新しければ適用されるセレクターや別の上書きも調べます。原因を絞らず全キャッシュを消すと、元の問題を見失い、再計算の負荷だけが増えることがあります。
更新を反映する方法は、削除だけではない
代表的な方法は、期限を待つ、更新した対象を無効化する、内容に応じてキーやファイル名を変える、元の内容と同じか再検証する、というものです。CDNのパージは強制的な無効化に使えますが、毎回それが必須というわけではありません。
静的ファイルなら、たとえばapp.abc123.cssからapp.def456.cssへ変え、HTMLから新しいファイルを参照する方法があります。古いHTMLを見ている利用者のために、旧ファイルも必要な間は残します。クエリ文字列の版番号でも区別できる構成はありますが、CDNなどがクエリをキーに含めるかによって挙動は変わります。「URLへ文字を足せば必ず解決」とは言えません。
HTTPのCache-Control: no-cacheは、保存を禁止する指示ではなく、再利用前の検証を要求する指示です。保存させたくない応答にはno-store、共有キャッシュに保存させたくない個人向け応答にはprivateという別の意味があります。これらのヘッダーが、既に保存済みの全コピーやアプリ内部のRedisの値まで消すわけではありません。
保存してよい範囲と、消えてよい範囲を決める
公開記事一覧と、ログインした本人だけの情報は分けて扱います。Cookieがあるだけで共有保存を防げるとは限りません。共有範囲、キー、HTTPヘッダー、CDNの設定を合わせて確認し、別の利用者へ個人情報を返さない設計が必要です。
また、キャッシュは正本から再生成できることを前提に設計します。唯一のデータや未完了の仕事を、消去してよいキャッシュへ混ぜないようにします。バックアップは失った情報を復旧するための保存であり、再利用を速くするキャッシュとは目的が異なります。
アプリ内の具体例はRedisの保存・期限切れの実験、配信側はCDNの役割と導入判断で説明しています。
参考情報
2026年9月21日確認。