// シス担のミカタ
CDN・エッジ

キャッシュ無効化 きゃっしゅむこうか

CDNキャッシュパージコンテンツ配信TTLキャッシュクリア
キャッシュ無効化について教えて

簡単に言うとこんな感じ！

CDNやブラウザが「古いデータを覚えたまま」配信し続けないよう、「そのキャッシュ、もう忘れて！」と強制リセットする操作だよ。サイトを更新したのに古い画像が出続けるのを直すアレ！

キャッシュ無効化とは

キャッシュ無効化（Cache Invalidation）とは、CDN・プロキシ・ブラウザなどが一時保存（キャッシュ）しているコンテンツを「古い・無効」とみなし、強制的に削除または更新させる仕組みです。Webサイトのデザイン変更や価格情報の更新など、サーバー側のコンテンツが変わったときに、利用者が古いデータを見続けないようにするために行います。

通常、キャッシュにはTTL（Time To Live：有効期限）が設定されており、期限が切れると自動的に再取得されます。しかしTTLが長い場合は期限切れを待たずに即座に無効化しなければなりません。たとえばECサイトで価格や在庫を更新したのに、CDNが古いページを配信し続けると、ユーザーが誤った情報で購入しようとするトラブルにつながります。

キャッシュ無効化は「パージ（Purge）」とも呼ばれ、CDNベンダーの管理コンソールやAPIから実行できます。正しく設計・運用することで、**配信の速さ（キャッシュのメリット）と情報の正確さ（鮮度）**を両立させることができます。

キャッシュ無効化の主な方式

方式概要向いているケース
URLパージ特定のURLのキャッシュだけ削除1記事・1画像だけ更新したとき
タグベースパージコンテンツにタグを付け、タグ単位で一括削除カテゴリ・商品群など関連コンテンツをまとめて更新
全体パージ（Purge All）CDN上のキャッシュを全削除大規模リニューアル時。負荷が集中するリスクあり
TTL短縮有効期限を短く設定し自動更新を早める常に変わる可能性がある動的コンテンツ
条件付きリクエストETag / Last-Modified でサーバーと差分確認変更があった場合だけ再取得したいとき

覚え方：「パージは外科手術、TTLは薬の効き目」

パージ（強制削除）は「今すぐ古いものを切り取る外科手術」、TTL短縮は「薬の効き目を短くして定期的に飲み直す」イメージ。即効性ならパージ、運用コストを抑えるならTTL調整、と使い分けるのがコツです。

キャッシュのライフサイクル

コンテンツ更新
    │
    ▼
CDNにキャッシュが残っている？
    │
    ├─ YES ─→ TTL内？
    │              │
    │              ├─ YES ─→ 古いコンテンツを配信 ← ⚠️ 問題発生
    │              │              └─ 解決策: キャッシュ無効化（パージ）
    │              └─ NO  ─→ オリジンから再取得 → 最新を配信 ✅
    │
    └─ NO  ─→ オリジンから取得 → キャッシュ保存 → 配信 ✅

歴史と背景

  • 1990年代前半：Webが普及し始め、同じリソースへのリクエストが集中。ブラウザキャッシュ・プロキシキャッシュが登場し、ネットワーク負荷を軽減する手段として広まる
  • 1997年：HTTP/1.1（RFC 2068）が策定され、Cache-Control・ETag・Expires などキャッシュ制御の標準ヘッダーが整備される。無効化の基本的な仕組みもここで確立
  • 2000年代：Akamai・Limelight などCDNベンダーが台頭。大規模コンテンツ配信でのキャッシュパージAPIが実装され、運用ツールとして一般化
  • 2010年代：CloudflareやAWS CloudFrontが普及し、タグベースパージ（Surrogate-Key / Cache-Tag）という粒度の細かい無効化手法が登場。CMSとCDNが連携して自動パージを行う仕組みが広まる
  • 2015年以降：HTTP/2・HTTP/3の普及とともに、サーバープッシュやプリロードといった先読み技術も発展。キャッシュ戦略はより高度・複雑になり、無効化の設計が重要な課題として認識される
  • 現在：JamstackやヘッドレスCMSの普及で「コンテンツ更新 → 自動パージ → 再ビルド」のパイプラインが当たり前に。DevOpsの一部として管理される

CDNプロバイダー別の無効化方法比較

CDNプロバイダー別 キャッシュ無効化の比較 プロバイダー パージ方式 タグベース API対応 Cloudflare URL / タグ / 全体 ✅ Cache-Tag ✅ REST API AWS CloudFront URL / ワイルドカード ❌（パス指定のみ） ✅ AWS SDK/CLI Fastly URL / Surrogate-Key ✅ Surrogate-Key ✅ REST API Akamai URL / CP-Code ✅ CP-Code ✅ Fast Purge API 💡 発注・選定時のポイント • CMSと連携した自動パージが必要なら「タグベースパージ対応」のCDNを選ぶと運用が楽 • Cloudflare・Fastlyはタグ粒度が細かく、大規模サイトのコンテンツ管理に向いている

HTTPキャッシュ制御ヘッダーとの関係

キャッシュ無効化は「CDN側の操作」ですが、HTTPレスポンスヘッダーでもキャッシュの振る舞いをコントロールできます。

# キャッシュさせたい（1日間）
Cache-Control: public, max-age=86400

# キャッシュさせない（常に最新を取得）
Cache-Control: no-store

# キャッシュするが必ず検証（ETagで差分確認）
Cache-Control: no-cache

# タグを付与してCDNでタグパージを可能にする（Cloudflare例）
Cache-Tag: product-123, category-shoes

関連する規格・RFC

規格・RFC番号内容
RFC 7234HTTP/1.1 キャッシュの基本仕様（Cache-Control・Expires など）
RFC 7232条件付きリクエスト（ETag・Last-Modified による差分検証）
RFC 9111HTTP キャッシュ（RFC 7234 を更新した現行仕様、2022年）
RFC 8246HTTP Immutable Response（変更されないリソースの宣言）

関連用語