キャッシュとは、応答や計算結果を保存し、条件が合う後続処理で再利用する仕組み
Webキャッシュは、あるリクエストへの応答を保存し、後のリクエストが再利用条件を満たすときに、その保存済み応答を使う仕組みです。
RFC 9111が定義するHTTPキャッシュでは、応答メッセージを保存し、後続リクエストへの回答に使います。再利用できれば、オリジンサーバーまで毎回取得しに行く転送、アプリケーション処理、データベース照会を減らせます。ただし、保存した時点で正しくても、更新後には古くなります。キャッシュは「最新情報を複製し続ける機能」ではなく、保存した版をどの条件と期間で使うかを管理する機能です。
freshとstale
freshは鮮度寿命の範囲内で再利用可能な状態、staleはその範囲を過ぎた状態です。staleになっても即削除されるとは限らず、再検証で有効と確認できれば再利用できます。
HITとMISS
再利用可能な保存済み応答が見つかればHIT、なければMISSとして上流へ取得します。製品ごとのHIT表示や中間状態は異なるため、レスポンスヘッダーと管理画面の定義を確認します。
キャッシュは正規データの代わりではない
キャッシュを消すと失われる唯一の注文情報や会員情報があるなら、それはキャッシュではなく保存設計の問題です。正規データはデータベースやオブジェクトストレージなどへ保持し、キャッシュは再生成・再取得できる派生物として扱います。
リクエストがHIT・MISS・304へ分かれる流れ
キャッシュは、URLだけを見て無条件にコピーを返すわけではありません。リクエストメソッド、対象URI、Varyで指定されたヘッダーなどから候補を選び、保存可能性、鮮度、再検証条件を評価します。次の2つは、よくある再利用パターンです。
freshな応答を再利用
current_age < freshness_lifetime → cached response
たとえばCache-Control: max-age=3600なら、応答生成からの年齢を考慮し、他の条件も満たす間は1時間の鮮度寿命として再利用できます。中間キャッシュを通った時間はAgeにも反映されます。
staleな応答を再検証
If-None-Match: "v7" → 304 Not Modified
保存済み応答のETagをIf-None-Matchで送り、現在の版と一致すればサーバーは304を返せます。本文を再送せず、保存済み本文を再利用します。版が違えば200と新しい本文を受け取ります。
画像ファイルを2回取得する例
- 1初回にGET /assets/logo.v7.svgを送り、サーバーから200 OK、Cache-Control: public, max-age=31536000, immutable、ETag: "v7"を受け取ります。
- 2ブラウザは応答本文と再利用条件を保存します。同じURLへの後続リクエストでは、freshで他の条件も合えばネットワーク転送なしで再利用できます。
- 3内容を変えるときはlogo.v8.svgのようにURLを変えます。HTMLが新URLを参照すれば、旧版を長期保存したまま新版を取得できます。
- 4URLを変えられないHTMLやAPIでは、短い鮮度寿命またはno-cacheとETagを使い、stale時に再検証して更新を判定します。
長期キャッシュは「長期間更新しない」という約束です。内容を上書きする運用と組み合わせず、内容変更時にURLも変える版管理か、確実なpurge・再検証手段を用意します。
Webキャッシュの主な種類と責任範囲
キャッシュは保存場所によって、利用者、共有範囲、消し方、観測方法が異なります。同じページに複数層が重なるため、「キャッシュを消した」と言うときは、どの層を操作したかを明記してください。
表は横にスクロールして、保存場所・向く対象・主なリスクを比較できます。
| 種類 | 保存場所・共有範囲 | 向く対象 | 主な注意点 |
|---|---|---|---|
| ブラウザキャッシュ | 利用者のブラウザ内。通常はその利用環境だけで再利用 | 画像、CSS、JavaScript、再検証可能なHTML | 利用者ごとに残存状況が違う。ブラウザの再読み込みだけでCDNやサーバー内キャッシュは消えない |
| 共有キャッシュ・CDN | 複数利用者の間にあるプロキシや配信拠点で共有 | 公開画像、静的ファイル、共有可能な公開応答 | 個人向け応答の混入、キー不足、拠点ごとの残存、purge範囲に注意 |
| リバースプロキシ | オリジンの手前に置く管理対象キャッシュ | 生成コストが高い公開HTMLやAPI応答 | 認証Cookie、言語、端末差、圧縮方式などをキーへ反映しないと誤配信する |
| ページキャッシュ | CMSやアプリが生成済みHTMLを保存 | 同じ入力から同じ公開ページを返す処理 | 下書き、予約公開、権限別表示、更新イベントとの無効化連携が必要 |
| オブジェクト・結果キャッシュ | アプリ内、メモリ、Redis等に計算結果や照会結果を保存 | 頻繁に再利用する設定値、集計、データベース照会結果 | キー設計、依存データ更新時の失効、メモリ上限、同時更新を管理する |
CDNはキャッシュそのものと同義ではない
CDNは地理的に分散した配信基盤で、キャッシュを主要機能として使うことがあります。しかし、CDNはTLS終端、ルーティング、保護機能なども持ち得ます。一方、ブラウザやアプリ内キャッシュはCDNなしでも使えます。製品名とキャッシュ層を分けて考えます。
HTTPキャッシュを制御する6つの要素
HTTPではCache-Control、検証子、Varyなどを組み合わせます。値を追加する前に、公開応答か個人向け応答か、URLを変更できるか、更新直後にどれだけ早く反映する必要があるかを決めてください。
max-age / s-maxage
max-ageは応答が生成されてからfreshとみなせる秒数です。s-maxageは共有キャッシュ向けの鮮度を上書きします。受信時からの単純タイマーではなく、Ageなどを含む現在年齢で判定します。
no-cache
保存禁止ではありません。保存済み応答を再利用する前に、オリジンで検証することを求めます。ETagやLast-Modifiedと組み合わせると、未変更時に304で本文転送を省けます。
no-store
キャッシュに応答を保存しないよう求めます。すでに保存済みの同URL応答を削除する指示ではありません。機密性、履歴機能、製品固有挙動を含めて選びます。
private / public
privateは共有キャッシュでの保存を禁止し、私用キャッシュに限定します。ログイン後や利用者別の応答では、Cookieがあるから安全と推測せず、明示的な制御を確認します。
Vary
同じURLでもAccept-LanguageやAccept-Encodingなどで応答が変わる場合、そのリクエストヘッダーをキャッシュキーの選択へ加えます。値の種類が多すぎるVaryはHIT率を下げます。
ETag / Last-Modified
保存済み応答が現在の版と同じか確認する検証子です。ETagは版を識別し、If-None-Matchと一致すれば304を返せます。Last-Modifiedは更新日時による条件付きリクエストに使われます。
ヘッダーを設定しないことも、一つの挙動を生む
明示的な鮮度情報がなくても、条件によってキャッシュがヒューリスティックに鮮度を計算する場合があります。「キャッシュしたくないから何も付けない」では意図を伝えられません。公開静的ファイル、更新されるHTML、個人向け応答の方針を分け、実際の応答ヘッダーで確認します。
キャッシュとCookie・セッション・データベース・バッファの違い
どれもデータを保持しますが、目的と正規性が違います。削除して再生成できる高速化用データなのか、利用者状態や業務記録として保持すべきデータなのかを分けると、事故を防げます。
| 用語 | 主な目的 | キャッシュとの違い |
|---|---|---|
| Cookie | ブラウザがサーバーとのやり取りに使う小さな状態情報。認証や設定の識別に使われる。 | 応答を再利用して処理を省くものではありません。Cookieにより応答が利用者別になる場合、共有キャッシュへの保存を避ける設計が必要です。 |
| セッション | ログイン状態や操作途中の状態を利用者単位で管理する仕組み。 | 失うと利用者体験や処理継続に影響する正規状態です。再生成可能な高速化用キャッシュとは保全要件が違います。 |
| データベース | 注文、会員、記事などの正規データを永続的に管理し、検索・更新する。 | キャッシュはデータベース照会結果を複製できますが、更新順序と失効が必要です。キャッシュだけを正規データにしません。 |
| バッファ | 処理速度や転送単位の差を吸収するため、一時的にデータを溜める領域。 | 同じ結果を将来の要求へ再利用することが主目的のキャッシュに対し、バッファは進行中の入出力を滑らかにする目的が中心です。 |
| CDN | 複数拠点からコンテンツを配信するネットワーク基盤。 | CDNは共有キャッシュを使えますが、キャッシュ以外の機能も持ちます。キャッシュはブラウザやサーバー内にも存在します。 |
| ブラウザ履歴・戻る | 訪問履歴とページ遷移を管理し、前後のページへ戻る機能。 | HTTPキャッシュと関係しますが同一ではありません。強制再読み込みやno-storeは戻る操作の体験にも影響し得ます。 |
「キャッシュクリア」は更新方法の総称ではない
ブラウザキャッシュの削除、CDNのpurge、CMSページキャッシュの削除、Redisの特定キー失効は別操作です。HTTPキャッシュ仕様には、中間キャッシュへ保存済みの応答を一括削除する汎用ディレクティブはありません。管理対象CDNでは管理画面やAPIで削除できますが、対象URL、カスタムキー、全削除の影響を確認します。
キャッシュを安全に導入・更新する5段階
最初からサイト全体へ長いTTLを設定せず、データ分類、キー、更新、観測、切り戻しを作ってから範囲を広げます。特にログイン、カート、決済、管理画面、プレビューは公開ページと分離します。
- 1
応答を公開・個人向け・機密へ分類する
公開画像や版付き静的ファイル、更新されるHTML、利用者別ページ、書き込みAPIを分けます。共有してはいけない応答を先に除外し、Set-CookieやAuthorizationを伴う経路を確認します。
- 2
キャッシュキーと鮮度を決める
URI、クエリ、言語、圧縮方式、端末差など、応答を変える要素を列挙します。更新頻度だけでTTLを決めず、古い情報が残る許容時間と更新方法から決めます。
- 3
再検証・版管理・purgeを実装する
HTMLやAPIはETag等で再検証し、静的資産は内容ハッシュや版をURLへ含めます。緊急修正用にURL単位のpurge手順を用意し、全件purgeは負荷急増を考慮します。
- 4
HIT率だけでなく正しさを検証する
未ログイン・ログイン、言語、端末、公開直後、削除直後を確認します。Age、Cache-Control、ETag、Vary、製品固有のcache-statusヘッダー、オリジン負荷、応答時間を記録します。
- 5
段階公開し、切り戻し条件を決める
対象URLや利用者割合を限定して公開します。他人の情報、古い価格、在庫不整合、ログイン誤表示が一件でも見つかれば、該当層をbypassまたは無効化し、purge後に原因を修正します。
全件purgeの直後は、オリジン負荷が急増し得る
保存済み応答を一斉に失うと、多数のMISSが同時にオリジンへ到達します。緊急時を除き、URLやタグ単位の無効化、版付きURLへの切替、事前ウォームアップ、リクエスト集約などを検討し、オリジン容量と監視を準備してください。
確認した標準仕様・公式資料
HTTPキャッシュの意味、鮮度、再検証、Cache-Control、ETag、Varyは標準仕様と公式資料で確認しました。実際のCDNやCMSでは独自キー、独自TTL、purge APIがあるため、製品資料も併せて確認してください。
Webキャッシュのよくある質問
Cache-Control: no-cacheは、保存を禁止しますか？
禁止しません。no-cacheは、保存済み応答を再利用する前にオリジンで検証することを求めます。保存自体を禁止する指示はno-storeです。ただし、no-storeを新しく返しても、すでに保存済みの同URL応答を削除する指示にはなりません。
毎日更新する記事ならmax-ageを24時間にすればよいですか？
更新直前に保存した利用者には、公開後も最大24時間近く旧版が残り得ます。更新を何時間遅らせてよいか、URLを変更できるか、ETagで再検証するか、CDNをpurgeするかから決めてください。更新間隔とTTLを同じにするだけでは反映時刻を保証できません。
ブラウザで強制再読み込みすれば、CDNキャッシュも消えますか？
通常は消えません。ブラウザ側の再読み込みと、共有CDNやサーバー内キャッシュの削除は別操作です。CDNは管理画面やAPI、CMSは製品機能、アプリ内キャッシュは対象キーの失効など、層ごとの手段を使います。
304 Not Modifiedなら、キャッシュから完全にオフラインで表示したのですか？
いいえ。304は、クライアントが条件付きリクエストを送り、サーバーが保存済み表現を再利用してよいと応答した結果です。本文転送は省けますが、検証の通信は発生しています。freshなローカルHITとは異なります。
キャッシュHIT率が高いほど、設定は良いと言えますか？
HIT率だけでは判断できません。個人向け応答を誤って共有したり、古い価格を長く返したりすれば、高HITでも失敗です。正しさ、漏えい防止、更新反映時間、オリジン負荷、応答時間を合わせて確認します。
キャッシュを削除すれば、元のデータも消えますか？
適切な設計では消えません。キャッシュは正規データから再生成・再取得できる派生物です。キャッシュ削除で唯一の注文や記事が失われる構成なら、正規データとキャッシュの責任が混同されています。
配信・転送・保存を続けて確認する
キャッシュは、保存場所より先に再利用条件と更新方法を決める
Webキャッシュは、応答や計算結果を保存し、条件が合う後続処理で再利用する仕組みです。ブラウザ、CDN、リバースプロキシ、アプリ内では共有範囲と消し方が違います。Cache-Controlで鮮度と保存範囲を示し、ETagなどで再検証し、Varyや製品固有キーで表現差を分離してください。版付きURL、対象単位のpurge、観測、段階公開、切り戻しまで用意すれば、速度と正しさを両立できます。
この記事の確認体制
Finite Field 編集部
RFC 9111・RFC 9110、Mozilla MDN、Cloudflareの公式資料を照合し、HTTPキャッシュの標準仕様と製品固有の管理操作を分けて編集しています。
Finite Fieldへ相談
キャッシュ・CDN・更新反映の設計を相談する
古いページが残る、ログイン後表示の共有が不安、CDNとCMSのどちらをpurgeすべきか分からない場合は、対象URL、応答ヘッダー、構成図、更新手順、再現時刻を準備してください。
キャッシュ設計を相談する現在の構成と要件を確認したうえで対応可否をご案内します。特定のHIT率、表示速度、無停止、即時反映を事前に保証するものではありません。