キャッシュとは？
仕組み・種類・削除方法をわかりやすく解説

キャッシュとは、結果を保存して後の処理で再利用する仕組み

コンピューター分野のキャッシュ（cache）は、取得や計算に時間がかかるデータを、元の場所より近い場所または高速な保存領域へ置き、次回以降の処理を速くする仕組みです。CPUキャッシュ、DNSキャッシュ、ブラウザキャッシュ、CDNキャッシュ、データベース照会結果のキャッシュなど、用途は幅広くあります。

この記事で扱う中心はWebキャッシュです。RFC 9111のHTTPキャッシュでは、あるリクエストに対する応答メッセージを保存し、後のリクエストへ回答するために再利用します。重要なのは、保存したデータそのものよりも、次の4点です。

リクエストがHIT・MISS・304へ分かれる仕組み

キャッシュはURLだけを見て、保存済みコピーを無条件に返すわけではありません。対象URI、HTTPメソッド、Varyで指定されたリクエストヘッダー、認証やCookie、製品固有のキー規則などから候補を選び、鮮度と再検証条件を評価します。

キャッシュのメリットと、設計を誤ったときのリスク

キャッシュの価値は「速くなる」だけではありません。オリジンへの到達回数、データ転送量、データベース照会、動的生成を減らせるため、安定性と運用コストにも影響します。ただし、効果とリスクは同じ設定の裏表です。

Webキャッシュの種類は、保存場所と共有範囲で分ける

一つのページでも、ブラウザ、CDN、リバースプロキシ、CMS、アプリケーション、データベースの前後に複数のキャッシュが重なります。「キャッシュを消した」と言うだけでは不十分で、どの層を操作したかを明確にする必要があります。

HTTPキャッシュを制御・観測する主要ヘッダー

HTTPでは、保存可否、共有範囲、鮮度、再検証、表現差、現在年齢、通過したキャッシュの処理結果を複数のヘッダーで表します。最初に「公開応答か」「利用者ごとに変わるか」「URLを変更できるか」「何分まで旧版を許容できるか」を決め、それから値を選びます。

Cache-Controlでよく使うディレクティブ

用途別のCache-Control設定例

次の例は出発点です。すべてのサイトへ同じ値を貼り付けるのではなく、URLを変更できるか、更新後に何秒まで旧版を許容できるか、個人情報を含むか、CDNやブラウザのどちらで再利用したいかを確認して調整します。

Cache-Control: public, max-age=31536000, immutable

Cache-Control: no-cache
ETag: "page-v42"

Cache-Control: public, max-age=30, s-maxage=300,
               stale-while-revalidate=60, stale-if-error=600
Vary: Accept-Encoding

Cache-Control: private, no-store

キャッシュを削除するとどうなる？層ごとの消し方と安全な更新

キャッシュを削除すると、次回は保存済み結果を使えず、元データの取得・再計算・再生成が発生します。適切な設計なら元の注文、会員、記事、画像原本は消えません。ただし、ブラウザの削除画面でCookieやサイトデータまで同時に選ぶと、ログイン状態やローカル保存情報へ影響する場合があります。

更新を早く安全に反映する5つの方法

キャッシュが効いているか確認する方法

「表示が古い」「HITしない」「ログイン後だけ違う」といった問題は、最初に層を特定し、実際の応答ヘッダーを記録すると切り分けやすくなります。ブラウザの見た目だけで判断せず、同じURLを条件を変えて複数回確認します。

Chrome DevToolsで確認する

1. DevToolsのNetworkを開き、対象ページを読み込みます。
2. 対象リクエストを選び、HeadersでCache-Control、Age、ETag、Vary、Cache-Statusや製品固有ヘッダーを確認します。
3. Sizeや転送表示に「memory cache」「disk cache」、Statusに304が出ているか確認します。
4. 初回利用者を再現したいときはDisable cacheを有効にします。これは主にブラウザキャッシュの影響を外す操作で、CDNをpurgeする機能ではありません。
5. ログイン有無、言語、クエリ、Cookie、端末条件を変え、別の応答が同じキーで混ざっていないか確認します。

curlで応答ヘッダーを記録する

# 応答ヘッダーだけを取得
curl -I https://example.com/assets/app.v8.css

# 再検証を要求して挙動を比較
curl -I -H 'Cache-Control: no-cache' https://example.com/

# ETagを使った条件付きリクエスト
curl -I -H 'If-None-Match: "page-v42"' https://example.com/

リクエスト側のCache-Control: no-cacheは、保存済み応答の削除命令ではありません。経路上のキャッシュへ再検証を求める意図であり、CDNやブラウザの実装・設定によって挙動が異なります。

キャッシュとSEO・Core Web Vitalsの関係

キャッシュそのものに「設定すれば検索順位が上がる」という単独の保証はありません。ただし、適切なブラウザキャッシュ、CDN、サーバー内キャッシュは、サーバー応答とリソース転送を減らし、表示体験を改善する土台になります。

キャッシュ設計でよくある失敗と公開前チェックリスト

公開前に確認する10項目

• 公開・利用者別・機密の3分類ができている
• 同じURLで応答が変わる条件を列挙した
• 静的資産に内容ハッシュまたは版を付けている
• HTML・APIの旧版許容時間を決めている
• ETagまたはLast-Modifiedで再検証できる
• 個人向け応答が共有キャッシュへ入らない
• 更新イベントとpurge・失効処理が連携している
• ログイン有無、言語、クエリ、端末差をテストした
• 全件purge後のオリジン負荷を想定した
• 問題発生時のbypass・切り戻し手順がある

キャッシュについてよくある質問

確認した標準仕様・公式資料

HTTPキャッシュの意味と制御は標準仕様を優先し、ブラウザ・CDN・検索関連の実装や確認方法は各公式資料で照合しました。CDN、CMS、リバースプロキシでは独自ルールがあるため、実運用では利用製品の資料も併せて確認してください。

• RFC 9111 — HTTP Caching
• RFC 9110 — HTTP Semantics
• RFC 9211 — The Cache-Status HTTP Response Header Field
• RFC 9213 — Targeted HTTP Cache Control
• RFC 8246 — HTTP Immutable Responses
• RFC 5861 — stale-while-revalidate / stale-if-error
• MDN Web Docs — HTTP caching
• MDN Web Docs — Cache-Control
• MDN Web Docs — Cache API
• Chrome for Developers — Network features reference
• Cloudflare Docs — Purge cache
• Google Search Central — Core Web Vitals

事実確認日：2026年7月29日。標準仕様と実装資料の内容が異なる場合、仕様上の意味と製品固有の挙動を分けて記載しています。

配信・転送・表示速度を続けて確認する

キャッシュは、保存場所より先に再利用条件と更新方法を決める

キャッシュとは、過去の応答や計算結果を保存し、条件が合う後続処理で再利用する仕組みです。ブラウザ、CDN、リバースプロキシ、CMS、アプリ内では、共有範囲、キー、消し方、観測方法が異なります。

静的ファイルは版付きURLで長期保存し、更新されるHTMLやAPIは鮮度と再検証を設計し、個人向け応答は共有しない。 さらに、対象単位のpurge、MISS集中への備え、ログイン・言語・公開直後の検証、切り戻しまで用意すれば、速度と正しさを両立できます。