HTML・API・静的アセットでの no-store / no-cache / max-age の使い分け

1 人のユーザーに紐づく HTML や機密性の高いレスポンスでは、まず再利用可能なコピーを残さないこと自体が重要になります。そういう場面では no-store が自然です。ここで重視しているのは鮮度よりも、ブラウザや中間キャッシュに再利用可能な状態で残さないことです。

そのため no-store は、個人ダッシュボードやセンシティブな API 応答に向いています。主なリスクが“古くなること”ではなく“残り続けること”なら、複数の弱い directive を重ねるより最初から no-store の方が明快です。

多くのチームは no-cache を“キャッシュしない”と読んでしまいますが、実際には“再利用前に確認する”に近い意味です。この違いは、短時間保存してよいが、次回利用前には鮮度を確認したい HTML や API レスポンスで重要になります。

この戦略は ETag や Last-Modified のような validator があると特に理解しやすくなります。保存済みのコピーを即座に捨てるのではなく、再利用前に「まだ有効か」を確認させる設計です。

max-age と immutable の組み合わせは、内容が変われば URL も変わるファイルに最適です。通常はハッシュ付きの JS、CSS、画像、フォントなどが該当します。この場合は URL 自体が更新境界を表すため、強い再利用がむしろ望ましいです。

問題は、このレシピを HTML や API に流用してしまうことです。これらは同じ URL で内容だけが変わることが多く、再検証や no-store が必要になるケースもあります。header 自体が悪いのではなく、誤ったレスポンス種別に持ち込まれることで破綻します。