304 Not Modifiedはエラー？ETagと再検証で保存済みの内容を使う仕組み

ブラウザの通信に304と出て、本文が返ってこなかった。通常の200とは違うけれど、保存済みの内容を使えると確認した応答かもしれないよ。

この記事ではGETの条件付き要求と、ETagによる再検証を整理する。実サイトのキャッシュ設定を変えず、ローカルの練習サーバーと架空の内容で比べる。

まず保存する応答

最初に内容を取得するとき、サーバーが200と本文、ETagという識別子を返す場合がある。ETagは表現を識別するための値で、必ずファイルのハッシュそのものとは限らないよ。

HTTP/1.1 200 OK
ETag: "practice-v1"

次に同じ対象を確認するとき、クライアントはIf-None-Matchへ、その値を入れられる。

If-None-Match: "practice-v1"

変わっていなければ本文を繰り返さない

GETなどの条件付き要求で、条件に合う場合は304 Not Modifiedを返す。304には本文を含めず、クライアントは保存してある表現を利用する。

編集部では、この三つをローカルHTTPサーバーで再現し、応答番号と本文の有無を確認した。すべての配信先が同じ条件を使うわけではなく、他のキャッシュ関連ヘッダーやメソッドも関係するよ。

no-cacheとの関係

no-cacheは、一般に「保存しない」ではなく、再利用する前の検証を求める指定として扱う。再検証で304を得れば、保存済みの本文を使う流れになる場合がある。

一方no-storeは保存を抑える指定。304があるかどうかだけで、個人情報の保存条件まで判断しないようにしよう。

画面が古いときに見ること

1. 対象のURLと応答ヘッダーを確認する。
2. 今の本文に対し、ETagなどが適切に更新されているかを見る。
3. ブラウザ、CDN、アプリなど、どこが再利用しているかを分ける。
4. 保存を消す前に、再現条件と確認した値を残す。

サーバーが更新後も同じ識別子で未変更と判定すれば、意図しない再利用につながる場合がある。番号だけを消す対処ではなく、条件の整合を確認したいね。

保存と再検証の違いはno-cacheとno-store、別の本文なし応答は204へ。

参照した公式資料

• MDN：304 Not Modified
• MDN：ETag

確認日：2026年10月25日。