【コード哲学エッセイ】 キャッシュは速くする魔法じゃなく鮮度の妥協だ —— いつ古くてもいいかを決める

更新したのに古いまま

七月の昼下がり、エアコンの風だけが静かに回っている。
Slack に一行届く。

「バナーを差し替えたのに、古い画像のままです」

僕はすぐに DB を開いた。
レコードは新しい。
管理画面も新しい。
壊れているのは、見えないところだけだった。

ブラウザのキャッシュ。
CDN のエッジ。
API のメモリ。

どれも、昨日の僕が「とりあえず速くしよう」と置いた魔法の残りだ。

速くする魔法だと思っていた頃

若い頃、キャッシュという言葉を聞くと、頭のなかではこう翻訳されていました。

遅いところを一瞬で直す呪文。

Cache-Control を足す。
Redis を挟む。
同じクエリを二度叩かない。

数字は下がる。
レスポンスは軽くなる。
胸のあたりも、少しだけ軽くなる。

「【コード哲学エッセイ】パフォーマンスは速さじゃなく体験だ」で書いた、緑の Lighthouse を思い出す。

あの夜もキャッシュのヘッダを整えた。
速さの勲章は手に入った。

けれど、鮮度の約束はどこにも書いていなかった。

鮮度の線を引かなかった日

フリーランスになって数年、個人開発のダッシュボードを直すたびに同じパターンを繰り返した。

集計 API が重い。
Redis に結果を入れる。
キーは stats:daily。
TTL は……とりあえず 3600。

最初は賢く見えた。
グラフが一瞬で出る。
「最適化した」と胸を張れる。

問題は、線を引かなかったことだ。

一時間古くてもいいのか。
一分でも古いと困るのか。
誰が、その古さを許すのか。

答えがないキャッシュは魔法だ。
設計じゃない。

ある日、クライアントが言った。

「今日の数字、おかしくないですか」

DB は合っていた。
画面だけが、一時間前の自分を抱えていた。
エラーは出ない。
ログも静かだ。
鮮度が更新されていない箱だけが、昨日の景色を返していた。

冷蔵庫と常温の棚は同じ箱じゃない

いまの僕は、キャッシュをこう捉えています。

データを止めておく冷蔵庫ではなく、鮮度を選んで置く棚だ。

牛乳と、乾麺を同じ日数で管理しない。
アイスの賞味期限と、醤油の賞味期限は違う。

コードでも同じだ。

人気記事の一覧は、十分古くても困らないことがある。
在庫数は、古いと困る。
自分が更新した直後のバナーは、一秒でも古いと不信になる。

「全部キャッシュすれば速い」は、全部冷凍すれば保存できるに似ている。
速い。楽だ。今日のタスクは減る。

その代わり、いつ解凍するかを決めていないと、誰かの昼下がりが壊れる。

古くてもいいデータと、 古くてはいけないデータ

キャッシュの本質は、正しさを保存することじゃない。
古さを、あらかじめ許すことに近い。

「【コード哲学エッセイ】公開 API は機能じゃなく約束の窓だ」で書いたように、外に渡すものには約束がある。

キャッシュにも、同じ構造がある。

このデータは、いつまで古くてよいか。
古くなったとき、誰が困るか。
新しくする手段は、何か。

三つ目が抜けると、TTL は数字の飾りになる。
max-age=31536000 を書いた瞬間、一年分の妥協を誰にも聞かずに署名したことになる。

僕が失敗したのは、速さのために鮮度を後回しにしたこと。
妥協を先に決めず、結果だけ借りたことだ。

キャッシュを足す前に僕が置く三つの問い

Redis の行を書く前に、HTTP ヘッダを足す前に、僕は三つだけ問います。

このデータは、何秒古くてもいいか。
古くなったとき、誰が最初に気づくか。
更新した瞬間に、どうやって古い箱を空にするか。

答えがはっきりしないなら、キャッシュは早いのかもしれない。
まだ足さない。
クエリを直す。
索引を張る。
それも立派な最適化だ。

答えがあるなら、名前と期限をセットで残す。
コメント一行でいい。

// 鮮度の妥協: 5 分まで古くてよい。更新時は invalidate する
const CACHE_TTL_SECONDS = 60 * 5;

async function getArticleList() {
  const cached = await redis.get('articles:list');
  if (cached) return JSON.parse(cached);

  const fresh = await db.article.findMany();
  await redis.set('articles:list', JSON.stringify(fresh), 'EX', CACHE_TTL_SECONDS);
  return fresh;
}

EX の前に、誰のための 300 秒かを書く。
それだけで、魔法は妥協に近づく。

無効化を忘れたとき、 箱は倉庫になる

キャッシュの仕事は、速く返すことで終わらない。
古い箱を、ちゃんと空にすることで成り立つ。

記事を更新した。
画像を差し替えた。
在庫を減らした。

その瞬間にキーを消す。
CDN にパージを飛ばす。
Cache-Control: no-cache を、本当に必要な場所だけに置く。

ここで手を抜くと、また倉庫ができる。

「いつか自然に切れるから」
「手動リロードすればいい」

手動リロードを要求する設計は、相手の時間を預かっているのに返していない。
「【コード哲学エッセイ】設定値は隠す場所じゃなく境界だ」で書いた、責任の切り方と同じ温度だ。

速さを借りたなら、鮮度の返済計画もセットで書く。
それが、魔法と設計の境目だと思う。

全部速くしようとしていた頃の自分へ

正直に言うと、鮮度を決める作業は遅い。
とりあえずキャッシュは、今日のタスクから消える。
会議でも、数字はきれいに見える。

それでも、境界を飛ばしたときの代償は、だいたい他人の昼下がりにやってくる。

自分の画面なら、強制リロードで済む。
クライアントの担当者は、僕の頭のなかにはいない。
彼らにとって、古いバナーは突然の天気の変化だ。
晴れたのか、曇ったのか、説明がなければ分からない。

「【コード哲学エッセイ】機能フラグは逃げ道じゃない」で書いた、期限のないスイッチ。

キャッシュにも、期限のない箱がある。
どちらも、未来の自分を迷子にする。

七月のエディタの前で

下半期に入り、触らないものを一つ決める週もあった。
そのとき、僕はもう一つ、手放したくなる衝動に気づく。

「全部、キャッシュすればいい」

——七月の空気は、そう囁く。

そのとき、昔の自分に声をかけます。

「これは速さの魔法か。それとも、鮮度の妥協か」

後者なら、古くてもいい秒数と、空にする手順をセットで足す。
前者に見えたら、まだクエリのほうを見る。

キャッシュは、正しさを複製する装置じゃない。
古さを選んで、速さと引き換える交渉だ。

同じように、TTL を決めずに Redis を足してしまった誰かに届けばうれしいです。

ひとりごと

速くなった数字だけを見ていた頃があった。
鮮度の線を引かなかった自分へ、いまは少しだけ厳しくなれる。

七月の昼下がり、古いバナーを報告する一行は、まだ届く。
それでも、秒数と無効化をセットで書ける日も、少しずつ増えてきた。

あわせて読みたい

▼ 速さの話の、隣の棚として

キャッシュを効かせすぎて体験が壊れる、という一文がある。
今回の鮮度の話は、その続きとして読めます。

▼ 外に渡す約束としてのデータ

七月のコード哲学エッセイの流れ。
キャッシュにも、約束の窓と同じ構造があります。

▼ 責任が切り替わる線の引き方として

TTL や無効化も、境界の一種です。

次の一歩を一緒に決める作戦会議室へ

キャッシュの付け方や、鮮度の線の引き方。
一人で抱えると、速さの数字だけが勝ちやすい。

作戦会議室では、現場で使える切り方を小さく分け合える場所にしたいです。
古くてもいい秒数を一緒に決めたい方は、のぞいてみてください。

参加する

Substack はじめました

ここまで読んでくださり、ありがとうございました。

X では短い言葉で、note では整理した文章で発信していますが、Substack では、もっと途中経過の思考や削りきらなかった葛藤、技術者として日々考えていることを書いています。

もし興味があれば、覗いてみてください。

会社員（元システムエンジニア）からフリーランスとなり、
15 年目に突入しました。

納期と障害対応に追われる毎日の中で、
「もっと自由に、もっと本質的にものづくりがしたい」
そう思ったのが独立のきっかけです。

現在は、技術と文章を軸に、
仕事がラクになる仕組みや続けられる働き方を発信しています。