第9章キャッシュ — 速さの工夫と、その落とし穴

📖 この章のゴール：アプリが「速い」のはなぜか、その正体である キャッシュ（控え） の考え方をつかみます。そして、便利なキャッシュが 個人データで重大な事故を起こすこと、それをどう防ぐか（Cache-Control の public と private）を、たとえ話で理解します。

← 目次・はじめにへもどる

📱 Twitterではこう見える

Twitterを2回目に開いたとき、「あれ、さっきより表示が速いな」と感じたことはありませんか。

プロフィール画像（アイコン）が、待たずにパッと出る
1回目はくるくる読み込み中だったのに、2回目はほぼ一瞬

これは魔法ではありません。1回目に取り寄せたものを、あなたのスマホやパソコンの近くに「控え」を置いておいたからです。2回目は遠くの倉庫まで取りに行かず、手元の控えをそのまま見せている。だから速いのです。

この「近くに置いておく控え」のことを、Web開発では キャッシュ と呼びます。便利なしくみですが、使い方を間違えると 他人のデータが見えてしまうという、とても怖い事故につながります。この章はその「速さ」と「落とし穴」の両方を学びます。

🤔 キャッシュって何？（🟢 基礎）

キャッシュをひとことで言うと、こうです。

近くに「控え」を置いておき、毎回倉庫（データベース）まで取りに行かないでよくする工夫。

毎回はるばる倉庫（DB）まで往復すると、時間もかかるし、倉庫も忙しくなります。そこで、よく使うものは手元に控えを置く。すると2回目以降が速くなり、倉庫の負担も減ります。

たとえ話：付箋とコンビニの棚

付箋：よく使う電話番号を、いちいち住所録（倉庫）で探さず、机に付箋で貼っておく。すぐ見られて便利。でも相手が引っ越して番号が変わったら、付箋は古いままです。
コンビニの棚：本社の大きな倉庫まで行かなくても、近所の棚から商品を取れる。でも、棚に補充（＝更新）をしないと、品切れや古い商品が並んだままになります。

キャッシュも同じで、速い代わりに 「控えはほうっておくと古くなる」 という宿命があります。

キャッシュの2つのリスク

便利なキャッシュには、初心者がつまずく落とし穴がちょうど2つあります。

古くなる 元（倉庫の中身）が変わっても、控えは前のまま。だから「もう直したはずなのに、古い表示が出続ける」ことが起きます。付箋に書いた古い電話番号と同じです。
他人の分が残る（いちばん危険） みんなで使う共有の棚に、ある人だけの個人データを置いてしまうと、次に来た別の人にそれが見えてしまう。これは「速さ」より「安全」を壊す、重大な事故です。

リスク①は不便なだけですが、リスク②は事故です。この章では②を特に重く扱います。

🛠 実際どうする（🟢 基礎 → 🔧 応用）

キャッシュは「どこに、何を、どれくらい」置くかを決めるのが仕事です。順に見ていきます。

どこに控えを置く？（🟢 基礎）

控えを置ける場所はいくつかあります。

ブラウザの中（メモリや localStorage）…あなたのスマホ・パソコンの中。あなただけのもの。
CDN（シーディーエヌ）…画像などを、世界中の「あなたの近く」にコピーして配る配送網。たくさんの人で共有する。
サーバーの中…重い計算の結果などを、サーバー側でとっておく。

ポイントは、ブラウザの控えは「その人だけのもの」ですが、CDN の控えは「みんなで共有するもの」だということです。ここが事故の分かれ道になります。

公開データか、個人データか（🟢 基礎）

この教材の背骨は「そのデータは誰のものか？」でした。キャッシュでも同じ問いが効きます。

公開データ（誰が見ても中身が同じ）…第6章（06-public-timeline）の 公開ツイートや画像。これは共有の棚（CDN）に置いてOK。みんなに同じものを速く配れます。
個人データ（人ごとに中身が違う）…第8章（08-home-timeline）の ホームタイムライン。これは 共有キャッシュ厳禁。あなた専用の並びを共有の棚に置いたら、他人にあなたのタイムラインが見えてしまいます。

🔑 合言葉：「みんな同じ＝共有OK」「人ごとに違う＝その人のブラウザだけ」

Cache-Control で「共有OK」か「本人だけ」かを伝える（🟢 基礎）

ブラウザや CDN は、勝手に判断できません。サーバーが 「これは共有していい／いけない」を、Cache-Control という合図（HTTPヘッダ）で伝えます。

# 公開データ（みんな同じ）→ 共有の棚に置いてOK
Cache-Control: public, max-age=3600

# 個人データ（人ごとに違う）→ 本人のブラウザだけ・控えない
Cache-Control: private, max-age=0

1行ずつ読むと：

public … 「共有キャッシュ（CDN など）に置いてよい」という許可。公開データに使う。
private … 「その人のブラウザの中だけに留める。共有の棚には絶対置くな」という指示。個人データに使う。
max-age=3600 … 控えの有効期限は3600秒（＝1時間）。1時間は倉庫に行かず控えを使ってよい、という意味。
max-age=0 … 期限ゼロ。事実上「毎回確かめ直す」。個人データは古さも危ないので短くします。

迷ったときの覚え方はシンプルです。個人データは private。 ホームタイムラインや下書きのような「その人だけのもの」には、必ず private を付けます。

古い控えを捨てる「無効化（invalidation）」（🔧 応用）

リスク①「古くなる」への対策が 無効化（invalidation） です。元が変わったら、控えを 捨てる/新しくすること。

やり方は大きく2つあります。

期限で捨てる（TTL）…TTL（有効期限）を決め、「○分たったら自動で捨てる」。max-age がこれにあたります。たとえば公開ツイート一覧を「1分だけ控える」なら、最大1分遅れますが、ほぼ最新を保てます。
変わった瞬間に捨てる…投稿が編集された瞬間に、その控えを消すよう指示する。新鮮さは最高ですが、しくみは少し複雑です。

初心者のうちは、まず TTL（期限で自動的に捨てる） から始めるのが安全で簡単です。「どれくらい古くても許せるか」を分単位で決める、と考えるとイメージしやすいです。

⚠️ ハマりどころ

個人データを共有キャッシュ（CDN）に置いてしまう＝重大事故 ホームタイムラインのような個人データに public を付けて CDN に流すと、Aさんの画面が、次に来たBさんに丸見えになります。実際に大手サービスでも起きた事故です。個人データは必ず private。 これは第10章でも改めて警告します。
古いデータを出し続ける TTL を長くしすぎたり、無効化を忘れたりすると、「もう変えたはずなのに古い表示のまま」になります。バグではなく、控えが残っているだけ、ということがよくあります。
ログアウトしたのにブラウザに残る ブラウザのキャッシュは、ログアウトしても自動では消えません。共有パソコンだと、次の人に前の人のデータが残って見えることがあります。個人データを max-age=0（控えさせない）にする、ログアウト時に控えを消す、などの対策が要ります。
「キャッシュが原因」のバグは気づきにくい コードは直したのに直らない——こういうときは まずキャッシュを疑うのが鉄則です。ブラウザの「スーパーリロード（強制再読み込み）」で直れば、犯人は控えだった、と分かります。

🤖 AIに頼むなら（Vibe codingのコツ）

キャッシュは「公開か個人か」をAIにきちんと伝えるのが何より大事です。ここを曖昧にすると、AIが気をきかせて public を付け、事故につながることがあります。

🗣 プロンプト例「このデータが 公開データか 個人データかを踏まえて Cache-Control を設定して。公開ツイートのような公開データは共有キャッシュOK、ホームタイムラインのような 個人データは必ず private。あわせて 無効化（TTL）の方針も提案して（何分で控えを捨てるか）。」

チェックリスト（AIの答えを確認するポイント）:

個人データを共有キャッシュ（CDN／public）に入れていないか（最重要）
個人データに private が付いているか
TTL（max-age）は妥当か。長すぎて古さが問題にならないか
ログアウト後にブラウザの控えが残らない設計になっているか

📝 ことばメモ

キャッシュ…近くに置いておく「控え」。倉庫（DB）まで毎回取りに行かずに済ませ、速くする工夫。
無効化（invalidation）…古くなった控えを捨てる/新しくすること。
CDN…画像などを世界中の「近い場所」にコピーして配る配送網。みんなで共有する。
public / private…Cache-Control の指定。public は共有OK（公開データ向け）、private はその人のブラウザだけ（個人データ向け）。
TTL（有効期限）…控えを何分・何秒で捨てるかの期限。max-age で指定する。

➡️ 次の章へ

これで「速くするキャッシュ」と「個人データで起きる事故」の両方が見えました。次の第10章では、この章の「個人データを共有キャッシュに入れる」事故も含め、初心者がやりがちな セキュリティの落とし穴をまとめて点検し、直し方を学びます。

➡️ 第10章ありがちな失敗と直し方（10-pitfalls）へ