Cache-Controlのno-cacheとno-storeの違いと正しい設定

Cache-Controlの「no-cache」は「キャッシュしない」という意味ではありません。「保存してよいが、使う前に毎回サーバーに確認する」という意味です。キャッシュに保存させたくない場合に指定するのは「no-store」です。名前から受ける印象と実際の動きが違うため、HTTPで最も誤解されやすい指定の1つです。

この記事では、no-cacheとno-storeの違いを中心に、主要な指定の意味、用途別の推奨設定、そして「更新したのに画面が変わらない」ときの原因の切り分け方までを解説します。

no-cacheとno-storeの違い

no-cacheの動き

1. ブラウザはレスポンスを保存する
2. 次に使うとき、サーバーに「この版はまだ最新？」と確認する（条件付きリクエスト）
3. 変わっていなければ、サーバーは 304 Not Modified を返し、中身を送らない
4. ブラウザは保存しておいた分を使う

確認のための通信は発生しますが、中身の転送は省略できるので、常に最新を保ちながら通信量を抑えられます。

no-storeの動き

レスポンスをどこにも保存しません。毎回、全部をサーバーから取得します。機密情報を端末やプロキシに残したくない場合に使います。

確認の仕組み：ETagとLast-Modified

no-cacheの「確認」は、サーバーが最初のレスポンスに付けた目印を使って行います。

• ETag — コンテンツのバージョンを表す識別子。ブラウザは次回 If-None-Match で送り返す
• Last-Modified — 最終更新日時。ブラウザは次回 If-Modified-Since で送り返す

サーバーは目印を比較し、変わっていなければ304を返します。ETagもLast-Modifiedも付いていないと、確認ができず毎回全体を転送することになるので、no-cacheを使うときはセットで設定されているか確認します。

主要な指定の意味

用途別の推奨設定

HTML（ページ本体）

Cache-Control: no-cache

HTMLは更新をすぐ反映させたいので、毎回確認させます。ETagと組み合わせれば、変更がなければ304で軽く済みます。

ファイル名にハッシュを含む静的ファイル（CSS・JS・画像）

Cache-Control: public, max-age=31536000, immutable

app.3f9a2c.js のように、内容が変わるとファイル名が変わるビルド構成なら、1年キャッシュしても問題ありません。更新時はファイル名が変わるので、HTML側が新しい名前を参照した時点で新しいファイルが取得されます。

ファイル名が固定の静的ファイル

Cache-Control: public, max-age=3600

名前が変わらないファイルを長期キャッシュすると、更新が反映されません。短めのmax-ageにするか、no-cacheで確認させます。

ログイン後の個人情報を含むページ・API

Cache-Control: private, no-store

端末や共有キャッシュに残したくない情報は、no-storeにします。

「更新したのに反映されない」ときの切り分け

キャッシュが原因で更新が反映されないとき、キャッシュは複数の場所にあり得ます。順番に確認します。

1. ブラウザのキャッシュ

開発者ツールのネットワークタブで、該当ファイルのステータスを確認します。

• (disk cache) や (memory cache) → ブラウザのキャッシュから読まれている
• 304 → サーバーに確認し、「変わっていない」と返されている

ハード再読み込み（Windows: Ctrl+Shift+R／Mac: Cmd+Shift+R）で反映されるなら、ブラウザキャッシュが原因です。レスポンスの Cache-Control の値を見直します。

2. CDN・リバースプロキシのキャッシュ

レスポンスヘッダに Age（キャッシュされてからの秒数）や、CDN固有のヒット判定ヘッダ（例：X-Cache: HIT）があれば、CDNのキャッシュから返されています。CDNの管理画面でキャッシュを削除（パージ）するか、s-maxageを見直します。

3. Service Worker

PWAなどでService Workerを使っている場合、Service Workerが独自にキャッシュを返していることがあります。開発者ツールの「Application」タブで登録状況を確認します。

4. サーバー側・アプリ側のキャッシュ

HTTPのキャッシュ以外に、アプリケーション側でデータをキャッシュしている場合（Redisやメモリ内キャッシュ）は、そちらの更新順序や有効期限も確認が必要です。

よくある誤解

「no-cacheを付けたからキャッシュされない」 → 保存はされます。保存させたくないならno-storeです。

「Pragma: no-cacheを付ければいい」 → Pragmaは古いHTTP/1.0向けの指定です。現在はCache-Controlで指定します（互換のために併記されることはあります）。

「max-age=0とno-cacheは同じ」 → ほぼ同じ動きになりますが、max-age=0は「すぐ期限切れ」、no-cacheは「毎回確認」という意味の違いがあり、期限切れキャッシュの扱いが実装によって異なる場合があります。確認を必須にしたい意図なら、no-cacheと明示するのが確実です。

よくある質問

Q. HTMLにmax-ageを付けてはいけませんか？ A. 付けると、その時間内は更新が反映されません。すぐ反映させたいHTMLは、no-cacheとETagの組み合わせが一般的です。

Q. APIのレスポンスにもCache-Controlは必要ですか？ A. 必要です。明示しないと、ブラウザや中間のキャッシュが独自の判断で保存する場合があります。個人情報を含むAPIはno-store、共通データのAPIは適切なmax-ageを指定します。

Q. immutableは全ブラウザで効きますか？ A. 対応状況はブラウザによって異なります。対応していないブラウザでもmax-ageは有効なので、併記しておいて問題ありません。

Q. no-storeにすると表示が遅くなりますか？ A. 毎回全体を取得するので、キャッシュがある場合より遅くなります。機密情報を含むものだけに使い、それ以外はno-cacheやmax-ageで調整します。

まとめ

• no-cacheは「毎回確認」、no-storeは「保存しない」
• no-cacheは、ETag・Last-Modifiedとセットで304を使い、通信量を抑える
• HTMLはno-cache、ハッシュ付き静的ファイルは長期キャッシュ＋immutable、個人情報はprivate, no-store
• 「反映されない」ときは、ブラウザ→CDN→Service Worker→アプリ側の順に切り分ける

株式会社RJCでは、決済や交通などピーク時の負荷が大きいシステムの開発にも携わっています。キャッシュの設計は、表示速度だけでなくシステム全体の安定性に直結する知識として、チームで共有しています。

▶ RJC丸わかり https://www.r-jc.jp/guide/?mediacode=02-00001-003

▶ エントリーはこちら（1〜2分で完了します） https://www.r-jc.jp/recruitment/?mediacode=02-00001-003

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。