はじめに
ひとことで言うと
Webサーバーのキャッシュは、一度作った応答（レスポンス）をサーバー側でしばらく保管し、同じ要求が来たときに保管したものを返す仕組みです。これにより応答が速くなり、サーバーの負荷を減らせます。身近な例では、よく見る商品ページや画像が速く表示される場面です。
なぜ知っておくとよいか
キャッシュを使うと表示速度が改善し、利用者の体験が良くなります。サーバー負荷が下がれば運用コストも抑えられます。一方で、古い情報を返してしまうリスクもあり、いつ更新するかを考える必要があります。具体的には在庫表示や価格表示など、最新性が重要な場面での扱いがポイントです。
この記事での扱い方
このシリーズでは、キャッシュの目的、どこに保存されるか、具体的な動き、制御のポイント、サーバーとブラウザの違いを順にわかりやすく説明します。専門用語はできるだけ減らし、具体例を交えて進めますので、初めての方でも読み進めやすい構成にしています。
何のための仕組みか
目的の要点
この仕組みは、毎回同じ処理を繰り返さずに済ませるためのものです。アプリやデータベースに毎回問い合わせてレスポンスを作る代わりに、一度作った結果を一時的に保存しておきます。結果としてサーバーの負荷を大きく下げ、表示速度を安定して向上させます。
具体例で見ると
例えば、商品一覧ページを考えてみてください。多くの人が同じページを短時間に何度も見るとします。保存がないと毎回データベースに問い合わせて処理を実行しますが、保存しておけばその場で渡せます。ニュースのトップページなども同じで、頻繁に変わらない部分は保存しておくとすぐ表示できます。
期待できる効果
サーバーのCPUやデータベースへのアクセスが減るため、同じサーバーでより多くのアクセスに耐えられます。表示速度が速くなることで利用者の満足度も上がり、結果として運用コストの削減にもつながります。
使う場面・避ける場面
共通して見る静的な内容や更新頻度が低い情報に向きます。一方、個別のログイン情報やカートの中身のように人ごとに異なる情報は、保存せずに毎回生成したほうが安全です。
イメージ
キャッシュは『一時保管庫』のようなものです。一度作った答えを短時間しまっておき、次に同じ質問が来たらすぐ取り出して渡すと考えてください。
どこにキャッシュされるか
サーバー側（Webサーバー）
Webサーバー自体がレスポンスを保存する場合があります。たとえばNginxのproxy_cacheのように、同じリクエストに対してすばやく応答するためにファイルやメモリに保持します。静的ファイル（画像やCSSなど）や頻繁に変わらないAPIレスポンスで使われます。
リバースプロキシや専用キャッシュサーバー
NginxやVarnishのようなリバースプロキシがオリジンサーバーの前に立ち、キャッシュを集中的に管理します。これによりオリジンの負荷を下げ、応答を高速化できます。専用サーバーはキャッシュ専用にチューニングされ、大量のリクエストに強くなります。
CDNや前段キャッシュ
CDN（例: 配信ネットワーク）は世界中のエッジサーバーにコンテンツを配置し、利用者に近い場所から配信します。オリジンサーバーを直接叩かずに配信できるため、遅延と負荷を大幅に減らします。
保管場所の違いと運用上のポイント
キャッシュはメモリ上（高速）やディスク上（大容量）に置かれます。メモリは速いですが容量が限られ、ディスクは遅めですが多く保存できます。実運用では、何をどこに置くか、いつ破棄・更新するか（パージや期限設定）を設計することが重要です。
具体的な動きのイメージ
1. 初回アクセス（キャッシュミス）
クライアントがページAにアクセスします。まずキャッシュにページAのデータがあるか確認します。ここに無ければ「キャッシュミス」です。サーバーはアプリやDBに処理を依頼して最新のページを作り、できあがった応答をクライアントへ返します。同時に、その応答を将来のためにキャッシュに保存します。
2. キャッシュ保存の仕組み
保存するときは「キャッシュキー」（通常はURLやクエリ、場合によっては特定のヘッダ）で管理します。保存期間（TTL）を設定して古くなったら自動で削除します。短いTTLは更新を反映しやすく、長いTTLは負荷を大きく下げます。
3. 再アクセス（キャッシュヒット）
再度ページAのリクエストが来たとき、同じキャッシュキーで確認して条件を満たせばキャッシュからそのまま返します。返す際はアプリやDBに触れないため応答が速くなり、処理回数も大幅に減ります。
4. 簡単な注意点
・ユーザーごとに内容が変わる場合はキャッシュ対象にしないか、別のキーで分けます。
・更新があったらキャッシュを消す（無効化）必要があります。
制御に関わるポイント
主要なHTTPヘッダーと意味
- Cache-Control: 現代の主要手段です。max-ageで有効期間（秒）を指定し、no-cacheは再検証を促します。public/privateで共有キャッシュの扱いを決めます。例: Cache-Control: public, max-age=31536000
- Expires: 古い方式で、有効期限日時を直接指定します。Cache-Controlが優先されます。
- ETag: 変更検出用の識別子です。ブラウザはIf-None-Matchでサーバーに確認し、未変更なら304を受け取ります。
- Last-Modified: 最終更新日時を示します。If-Modified-Sinceで確認します。
運用とパージ（古いキャッシュの破棄）
- 対象URLのみをパージする: 個別ページやファイルを即時更新したいときに有効です。影響範囲が小さい分、安全です。
- パス単位でバン（prefix purge）: 同じディレクトリ以下を一括で消すときに使います。大量のオブジェクトを更新した場合に便利です。
- タグベースのパージ: アプリ側でキャッシュにタグ付けし、関連するキャッシュを一括で消去します。
実践的な指針
- 静的ファイルは長い有効期間を付け、ファイル名にバージョンを入れて運用してください。これによりパージを最小化できます。
- HTMLや頻繁に変わるAPIは短めのmax-ageかno-cacheを使い、必要時にパージしてください。すると表示が古くなりにくくなります。
- ETagやLast-Modifiedを有効にすると、無駄なデータ転送を減らせます。ただし生成コストを考慮してください。
よくある落とし穴
- 長期間キャッシュしているのにファイルを上書きすると古い内容が残ります。したがって必ずバージョン管理やパージ手順を整えてください。
- 全件一括パージは負荷が高くリスクを伴います。可能な限り対象を絞って実行してください。
サーバーキャッシュとブラウザキャッシュの違い
概要
サーバーキャッシュはWebサーバーやCDNなどのサーバー側に保存します。全ユーザーに共通のデータを高速に返せるため、サーバー負荷を下げる効果があります。一方、ブラウザキャッシュは利用者の端末内のブラウザに保存します。個々のユーザーの再訪問時に読み込みが速くなります。
保存場所と影響範囲
- サーバーキャッシュ：サーバーや中継するキャッシュサーバー、CDNに保存。すべてのユーザーに同じキャッシュが使われます。
- ブラウザキャッシュ：ユーザーごとの端末内。端末単位で効果が現れます。
管理と制御
- サーバー側はサーバー設定やCDNの管理画面で一括制御できます。ファイルの差し替えやキャッシュ削除（パージ）で即時反映できます。
- ブラウザ側はサーバーが送るヘッダー（例: 有効期限やキャッシュ指示）で方針を指示しますが、最終的にはユーザーのブラウザ動作や手動削除に左右されます。
更新時の扱い
頻繁に更新する場合は、サーバーキャッシュは短めの有効期間やバージョン付きファイル名を使います。ブラウザキャッシュはファイル名にバージョンを付ける運用が有効で、確実に新しい資源を配るのに役立ちます。
実際の例
画像や共通の静的ファイルはサーバー（CDN）で長めにキャッシュし、ページ毎の動的な部分は短めにすることが多いです。ユーザーが「更新が反映されない」と言う場合は、まずサーバー側のパージとバージョン管理を確認します。
