HTTPキャッシュの落とし穴【2025年版】：認証・個別化・キー設計を完全理解

1. 認証とキャッシュの基本原則

• Authorization ヘッダ付きリクエストは共有キャッシュ対象外（RFC準拠）
• Set-Cookie を返すレスポンスは、不用意にパブリックキャッシュさせない
• 個別化が絡む場合は Cache-Control: private または no-store を検討

2. Varyの爆発（キャッシュ断片化）

• Vary: Accept-Language, Accept-Encoding, Origin などが多いほどキーが増殖
• 最小限の Vary に抑え、CDNキー（パス/クエリ/ヘッダ）を明示的に設計

Key = scheme + host + path + canonical(query[allowlist]) + headers[allowlist]

3. キー正規化とクエリ許可リスト

• 無関係なクエリ（utm_* など）をキーから除外
• 重要なクエリのみ許可（例：page, sort, tag）

4. Cache Poisoning対策

• X-Forwarded-Proto/Host 等をキーに含める or 正規化
• ヘッダによる動的分岐は Vary を忘れない
• リダイレクト先を正規化（オープンリダイレクト回避）

5. SWRと個別化の両立（段階的キャッシュ）

• ベースHTML/共通データはSWRで高速化
• ユーザー固有はクライアントフェッチ or Edgeで差し込み（ESI/フラグメント）

// app/page.tsx（概念）：共通はSSG/ISR、ユーザー固有はクライアントでフェッチ
export default async function Page() {
  const common = await getCommonCacheable(); // revalidate:60
  return <Shell common={common} />;
}

6. CDN/エッジでの注意

• Cookieバインド or 署名クエリで鍵付きキャッシュ（パブリックに混ぜない）
• stale-while-revalidate と stale-if-error を積極活用

7. ありがちな事故と対処

• GETで状態変更 → キャッシュ破綻（必ずPOST/CSRF保護）
• Cache-Control: public で個人情報を返却 → データ漏洩（private/no-store）
• Vary 漏れで誤配信 → キーに必要なヘッダを必ず含める

8. チェックリスト

• 共有キャッシュ対象にしてよいレスポンスか？
• キーは許可リストで正規化されているか？
• 個別化部分を分離できているか？
• SWRと安全性のバランスは取れているか？

まとめ

鍵は「キー設計」。個別化は分離し、SWRで“速さ”を担保しつつ、誤配信と漏洩を未然に防ぎましょう。