Last-Modifiedは、HTTPレスポンスでリソースの最終更新時刻を示すヘッダです。Last-Modified: Wed, 14 May 2026 10:30:00 GMTのようにRFC 7231規定のHTTP-date形式で日時を返し、クライアントはこの値を保存しておきます。次回同じリソースを要求するとき、If-Modified-Since: Wed, 14 May 2026 10:30:00 GMTヘッダで時刻を送り返し、サーバはその時刻以降に更新されていなければ304 Not Modifiedを返す仕組みです。現在の仕様はRFC 9110（2022年、旧RFC 7232）で定義され、HTTP/1.0時代から使われてきた最も古典的なキャッシュ検証ヘッダで、現在もETagと並んでWebキャッシュ運用の中核を担っています。
この記事の目次
- 時刻形式と取得の仕組み
- HTTP/1.0時代からの長寿命ヘッダ
- 現場での実装パターン
- ETag・Cache-Controlとの関係
- まとめ
時刻形式と取得の仕組み
Last-Modifiedの値はRFC 7231（現RFC 9110）で規定されたHTTP-date形式で記述されます。推奨形式はIMF-fixdate（Internet Message Format固定形式）で、Wed, 14 May 2026 10:30:00 GMTのように曜日略号・日・月略号・年・時刻・GMTを並べた英語表記です。歴史的経緯から、RFC 850形式やasctime形式も解釈すべきとされていますが、生成側はIMF-fixdateを使うのが現代仕様です。
サーバは静的ファイルならファイルシステムのmtime（最終変更時刻）、動的コンテンツならデータベースのupdated_at列やキャッシュキーから生成された時刻を、Last-Modifiedヘッダとしてレスポンスに乗せます。クライアントはこの値を保存し、次回同じリソースを要求するときにIf-Modified-Sinceヘッダで送り返します。サーバ側はリソースの現在の最終更新時刻と受信時刻を比較し、変更がなければ304 Not Modifiedで本文を省略、変更があれば通常の200 OKで新しい内容と新しいLast-Modifiedを返します。1秒粒度の時刻情報で動作するシンプルな仕組みです。
HTTP/1.0時代からの長寿命ヘッダ
Last-Modifiedは1996年5月のHTTP/1.0仕様（RFC 1945）で既に定義されていた、HTTP最古参のヘッダの一つです。Webが急速に拡大していた1990年代後半、再アクセス時の帯域節約が大きな課題だったため、ファイルの更新時刻を使った条件付き取得が標準化されました。1999年6月のRFC 2616（HTTP/1.1）でIf-Modified-Sinceと組み合わせた条件付きリクエストの仕様が明確化され、ブラウザ・サーバ双方で広く実装されました。
2014年6月のRFC 7232ではHTTP/1.1の条件付きリクエスト部分を独立した文書として再整理し、Last-Modifiedの取り扱い・1秒粒度の制約・ETagとの併用ルールが整理されました。2022年6月のRFC 9110でHTTPセマンティクス全体の統合改訂の一環として現代仕様となり、HTTP/2・HTTP/3でも同じ仕組みが受け継がれています。30年近くにわたって基本構造を保ち続けてきた長寿ヘッダで、現代Webの全レイヤー（ブラウザ・CDN・プロキシ・Webサーバ）で透過的にサポートされ続けています。
現場での実装パターン
ApacheやNginxなどの主要Webサーバは、静的ファイルに対してファイルシステムのmtimeから自動的にLast-Modifiedヘッダを生成します。ブラウザは2回目以降の取得でIf-Modified-Sinceを付け、変更なしなら304が返り、本文ゼロのレスポンスで再利用が完了する仕組みが、設定なしで透過的に効きます。DevToolsのNetworkタブで「304 Not Modified」と表示されているリソースの多くはこのLast-Modifiedベースの判定で動いています。
REST APIでは、データベースのupdated_at列をLast-Modifiedとして返す実装が一般的です。GETレスポンスでLast-Modifiedを返し、クライアントがIf-Modified-Sinceで再問い合わせしたら、サーバ側はupdated_atとの比較で更新有無を判定して304か200かを返します。ただし1秒粒度しかない制約があるため、ETagとの併用が現代のベストプラクティスで、サーバはETagとLast-Modifiedの両方を返し、クライアントはIf-None-MatchとIf-Modified-Sinceの両方を送る運用が定着しています。CDN（CloudFront、Fastly、Cloudflare）でも、オリジンへの再検証時にIf-Modified-Sinceが使われ、304が返ればCDN側のキャッシュをそのまま延命できる仕組みになっています。
ETag・Cache-Controlとの関係
ETagは「リソースの内容から導出した指紋」で、より精密な判定が可能ですが、Last-Modifiedは「ファイルの最終更新時刻」というシンプルな概念で、人間が読んで状況を理解しやすい利点があります。1秒粒度で精度が落ちる弱点はあるものの、ファイル系コンテンツでは「いつ更新されたか」が直感的にわかるため、ログ解析やデバッグでも便利です。現代の運用ではETagとLast-Modifiedの両方を返すのが定石で、サーバ側はまずETagの一致をチェックし、不一致または未対応なら次にLast-Modifiedを比較する評価順序になっています。
Cache-Controlは「いつまで再検証なしで使ってよいか」という鮮度指定を行うヘッダで、Last-Modifiedとは役割が異なります。Cache-Control: max-age=3600で1時間キャッシュとし、過ぎたらIf-Modified-Sinceで再検証する、というのが典型的な組み合わせ方です。Dateヘッダはレスポンスを生成した日時で、Last-Modifiedとは別の役割。Expiresは古いHTTP/1.0時代のキャッシュ期限指定ヘッダで、Cache-Controlに置き換えられたため新規採用は減っています。Last-ModifiedはETag・Cache-Controlと役割分担して併用する位置付けで、現代Webキャッシュの安定運用に不可欠な要素として今も使われ続けています。
まとめ
Last-ModifiedはHTTP/1.0（1996年）からある最古参のキャッシュ検証ヘッダで、現在はRFC 9110（2022年、旧RFC 7232）で定義されています。IMF-fixdate形式の時刻を返し、クライアントがIf-Modified-Sinceで再検証することで304 Not Modifiedによる帯域節約を実現します。ETagと併用することで1秒粒度の制約を補い、Cache-Controlと組み合わせて鮮度管理を完成させる、Webキャッシュ設計の根幹を成すヘッダとして30年以上使われ続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント