Skip to main content

第12章：キャッシュ基礎（速くするけど壊さない）⚡🧠

この章では、Firebase Hosting を爆速にしつつ「更新したのに反映されない😇」事故を減らすための、いちばん大事な“考え方→設定→検証”をまとめます🚀

1) キャッシュって何が起きてるの？（2階建てで考える）🏢🏢​

Two Layers of Cache

キャッシュはざっくり 2か所にあります👇

  • ブラウザキャッシュ（あなたのPCのChromeが持つ）🧠
  • CDNキャッシュ（世界中の中継地点が持つ）🌍⚡ Firebase Hosting は グローバルCDNで静的ファイルを自動キャッシュし、再デプロイするとCDN側のキャッシュはクリアされます🧹✨ (Firebase)

ただし注意！⚠️ Functions / Cloud Run みたいな“動的”は、CDNに基本キャッシュされません（URLの中身が人や入力で変わるから）(Firebase) → 動的をCDNにキャッシュしたいなら、後半の「おまけ」も見てね🙂

2) Cache-Control をざっくり理解しよう📦​

Cache-Control Cheatsheet

キャッシュの挙動は、基本 Cache-Control ヘッダーで決まります📌 (Firebase)

よく出るやつだけ覚えればOK！🙆‍♂️

  • public：CDNもブラウザもキャッシュしていいよ🙆‍♀️ (Firebase)
  • private：ブラウザだけキャッシュしてね（CDNはダメ）🙅‍♀️ ※Firebase Hosting は動的コンテンツに デフォルト private を付けがち (Firebase)
  • max-age=秒：ブラウザが「何秒まで古くてもOKか」⏱️ (Firebase)
  • s-maxage=秒：CDNなど共有キャッシュ用の寿命（max-ageより優先）🌍⏱️ (Firebase)
  • no-cache：保存はしてもいいけど、使う前に“更新確認(再検証)”してね🔁
  • no-store：保存しないで🗑️（超安全だけど遅くなりやすい）
  • immutable：このファイルは変わらない前提でOK（主に“ハッシュ付き”ファイル向け）🧊

3) React + Hosting の「壊れない定番」ルール🍣✨​

The Stale HTML Problem

ここが最重要！💥 React(Viteなど)のビルドは、JS/CSSがだいたい ファイル名にハッシュ（例: app.a1b2c3.js）が付きます。 この“ハッシュ付き資産”は 1年キャッシュしてOK🙆‍♂️（ファイル名が変わる＝別物だから）

一方で…

  • index.html（またはSPAの入口HTML）を長期キャッシュ ❌ → 古いHTMLが残る → そのHTMLが 古いJSを参照 → もう存在しないJSを取りに行って 404 / 真っ白 😇

なので、基本方針はこう👇

  • HTML（SPA入口）：短命 or 再検証（no-cache など）🔁
  • ハッシュ付きのJS/CSS/画像/フォント：長期キャッシュ（public, max-age=31536000, immutable）🚀
  • サービスワーカー sw.js があるなら：短命（更新しやすくする）🧯

4) firebase.json でキャッシュを設定する🧾🛠️​

Safe Caching Strategy

Firebase Hosting は firebase.json の hosting.headers でレスポンスヘッダーを付けられます✍️ (Firebase) しかも ルールは上から順に評価される（順番が大事）📌 (Firebase) さらに重要：ヘッダーのマッチングは rewrites より先に行われます（SPAの /about などは “/about でマッチ” する）🧠 (Firebase)

4-1) まずはコピペでOKな“鉄板セット”🥇​

Configuration Cascade

目的：SPAのどのURLでもHTMLは更新確認、資産は長期キャッシュ✅

{
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],

    "headers": [
      {
        "source": "**",
        "headers": [
          { "key": "Cache-Control", "value": "no-cache" }
        ]
      },
      {
        "source": "**/*.@(js|css|png|jpg|jpeg|gif|svg|webp|ico|woff|woff2|ttf|otf|map)",
        "headers": [
          { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
        ]
      },
      {
        "source": "/sw.js",
        "headers": [
          { "key": "Cache-Control", "value": "no-cache" }
        ]
      }
    ]
  }
}

ポイント解説🧠✨

  • source: "**" で 全部をいったん no-cache（SPAの /about みたいなURLにも効かせたい）
  • その後に、拡張子で 資産だけ長期キャッシュに上書き（順番が命）📌 (Firebase)
  • sw.js は更新トラブルの温床になりがちなので、短命に寄せる🧯

💡 もし dist じゃなくて build などなら public だけ合わせてね！

5) 手を動かす：キャッシュを“見える化”して安全確認🔎👀​

手順①：いまのヘッダーを確認する（変更前）🧪​

Verifying with DevTools

  1. 公開URLを Chrome で開く🌐
  2. DevTools（F12）→ Network タブ📡
  3. index.html（Doc）をクリック → Headers → Cache-Control を見る👀
  4. JSやCSSファイルも同じく Cache-Control を見る👀

ここで「今はこうなってる」をスクショ📸しておくと、あとで勝てます🏆

手順②：firebase.json に headers を入れる✍️​

上の“鉄板セット”を入れて保存🧾

手順③：Preview Channel にデプロイして試す（安全運転）🚦​

本番をいきなり触らず、プレビューで確認しよう🙂

firebase hosting:channel:deploy cache-lab

手順④：変更後のヘッダーを確認する✅​

  • index.html / SPAのURL（例 /about） → Cache-Control: no-cache になってる？🔁
  • JS/CSS/画像 → public, max-age=31536000, immutable になってる？🚀

手順⑤：更新がちゃんと反映されるかテストする🔁✨​

  1. CSSの色をちょっと変える🎨
  2. build → デプロイ
  3. シークレットモード禁止！ 普通のタブで更新して、反映されるか確認😆

6) ミニ課題✍️🎯（10分）​

Assignment Questions

次の3つを、自分の言葉で1行ずつ説明してね🙂

  1. HTMLを長期キャッシュすると何が起きる？😇
  2. ハッシュ付きJS/CSSを長期キャッシュしていい理由は？🧊
  3. no-cache と no-store の違いは？🧠

7) チェック✅（できたら勝ち！）​

Final Check

  • /about みたいな直叩きでも Cache-Control: no-cache が効いてる🔁
  • JS/CSS/画像が max-age=31536000 になってる🚀
  • 再デプロイ後、通常更新で変更が反映される✨
  • “真っ白”や “古いJS 404” が起きない🙂

8) よくある事故と回避術🧯​

事故①：更新したのに反映されない（HTMLが古い）😇​

→ HTMLは no-cache（再検証）にするのが安全🛡️

事故②：404 がしばらく直らない😵​

The 404 Cache Trap

Firebase Hosting は 存在しないURLの 404 をCDNが最大10分キャッシュすることがあります🕙 (Firebase) → 404作った/直した直後は「最大10分待つ」か「URL変えて確認」もあり

事故③：SPAなのに /about だけ挙動が違う🤔​

ヘッダーのマッチは rewrites より前なので、/index.html だけに設定しても /about には当たりません⚠️ (Firebase) → だからこの章の例は source: "**" を使ってるよ👍

9) AI活用コーナー🤖✨（キャッシュ事故を“AIレビュー”で減らす）​

9-1) Gemini CLI で「firebase.json のキャッシュ設計」をレビューしてもらう🧠​

AI Config Review

Firebase は Gemini CLI 向けの拡張も用意しています（Firebase専用の知識を足しやすい）(Firebase) たとえばこう聞く👇

  • 「React(Vite)の dist 構成で、壊れない Cache-Control を firebase.json の headers で提案して。SPAのルート直叩きも考慮してね」🤖
  • 「no-cache と no-store の違いを、Hosting運用の観点で説明して」🧠

9-2) MCP server で “Firebaseの状況込み” で相談しやすくする🧩​

Firebase には Firebase MCP server があって、AIツールが Firebase プロジェクトやコードベースと連携しやすくなります🧩 (Firebase) → “このプロジェクトの firebase.json を見た上で提案して” がやりやすくなるイメージ✨

さらに、公式の AI prompt catalog（定型プロンプト集）もあります📚 (Firebase) → キャッシュ方針のチェックリスト生成とか、相性いいです✅

9-3) Firebase AI Logic は「リリース前チェック自動化」にも繋がる🤖✅​

直接キャッシュを速くする機能ではないけど、“リリース前チェック”をAIで型化する流れに繋げられます🧾 なお、Firebase AI Logic のドキュメント上では Gemini 2.0 Flash / Flash-Lite が 2026-03-31 にretire予定という注意が出ています（モデル選びの更新が必要）(Firebase)

おまけ：Functions / Cloud Run を Hosting から呼ぶときのキャッシュ感覚🧠⚙️​

動的はデフォルトでCDNキャッシュされにくいけど、キャッシュしたいなら Cache-Control: public を返すのが基本です📌 (Firebase) また、キャッシュは GET/HEAD だけとか、Vary や __session cookie の扱いなど注意点もあります🍪🧠 (Firebase) （ここは第19章の “Functions/Cloud Run” でガッツリやると気持ちいいやつ！🔥）

次は、あなたの今の構成に合わせて public（dist/build）や assets のパスを微調整した“あなた専用 firebase.json”にして、Preview Channel で事故ゼロ確認まで一気にやろう😆🚀