ETag（Entity Tag）は、HTTP/1.1で導入されたレスポンスヘッダで、リソースの特定バージョンを識別する「指紋」のような短い文字列を表します。サーバはETag: "33a64df551425fcc55e"のような値をレスポンスに付け、クライアントはこれを保存しておきます。次回同じリソースを要求するとき、クライアントはIf-None-Matchヘッダで保存済みのETagを送り、サーバは値が一致すれば304 Not Modifiedを返してボディを省略でき、帯域と時間を節約できます。現在の仕様はRFC 9110（2022年、旧RFC 7232）で定義され、Webキャッシュとパフォーマンス最適化の中核を担う仕組みです。
この記事の目次
- 強いETagと弱いETagの違い
- HTTP/1.1での導入と現代仕様への変遷
- 実装現場でのETag活用パターン
- Last-Modifiedとの使い分け
- まとめ
強いETagと弱いETagの違い
ETagには「強いETag」と「弱いETag」の2種類があり、表記で区別します。強いETagは"abc123"のように単純に引用符で囲まれた文字列で、リソースのバイト単位で完全一致することを保証します。範囲リクエスト（Rangeヘッダ）でも安全に再開でき、キャッシュ判定として最も厳格な意味を持ちます。
弱いETagはW/"abc123"のようにW/プレフィックスを付けて表記し、「リソースは意味的には同等だが、バイト単位では異なるかもしれない」ことを示します。たとえば動的に生成されるJSONで、空白の量だけが違うようなレスポンスや、Gzip圧縮版と非圧縮版を同じETagで扱いたい場合に弱いETagが使われます。弱いETagはRangeリクエストとの組み合わせには使えませんが、キャッシュ判定としては十分機能します。サーバはETagの中身としてMD5/SHA1ハッシュ、ファイルiノードと更新時刻の組み合わせ、リソースのバージョン番号など、衝突しない値であれば任意の形式を選べます。
HTTP/1.1での導入と現代仕様への変遷
ETagは1997年1月のRFC 2068（HTTP/1.1の最初の仕様）で導入されました。HTTP/1.0時代にはLast-Modifiedヘッダによる「最終更新時刻」での条件付きリクエストのみが使われていましたが、1秒単位の精度しかなく、動的生成リソースや高頻度更新リソースでは判定が難しい問題がありました。そこで「内容そのものから導出できる任意の識別子」として、ETagが追加された経緯があります。
1999年6月のRFC 2616でHTTP/1.1仕様が確定し、ETagの取り扱いがより明確化されました。2014年6月にはRFC 7232がHTTP/1.1の条件付きリクエスト部分を独立して扱う形で改訂し、強いETagと弱いETagの定義が再整理されました。2022年6月のRFC 9110ではHTTPセマンティクス全体を統合する形で再編されており、ETagの仕様はこちらに収まっています。現代でもHTTP/2・HTTP/3で同じ仕組みが受け継がれており、25年以上にわたってWeb高速化の基本パーツとして使われ続けている長寿の仕組みです。
実装現場でのETag活用パターン
静的ファイル（HTML・CSS・JS・画像）に対しては、ApacheやNginxがファイルiノード・サイズ・mtimeを組み合わせてETagを自動生成します。ブラウザは2回目以降のアクセスでIf-None-Matchを付けて取得し、変更がなければ304で本文ゼロのレスポンスが返るため、帯域がほぼゼロで再利用できます。APIレスポンスでも同じパターンが使え、JSONボディのSHA-1や論理的なバージョン番号をETagに入れることで、変更がない時はサーバが304だけ返してCPU・帯域を節約できる構成が一般的です。
ETagは「楽観的排他制御」にも活用されます。クライアントがPUT/PATCHを送るときにIf-Match: "前回取得時のETag"を付け、サーバ側でリソースが既に他者により更新されていれば412 Precondition Failedを返す仕組みで、ロストアップデート問題を防げます。AWS S3やAtlassianのREST APIなど、多くの主要なクラウドAPIがこのパターンを採用しています。CDN（CloudFront、Fastly、Cloudflare）でもETagはキャッシュキーや304返却判定の中核として使われ、ブラウザだけでなくCDNエッジサーバとの間でも同様の条件付き取得が成立する仕組みです。
Last-Modifiedとの使い分け
Last-Modifiedはリソースの最終更新時刻（RFC 7231日時形式）を返すヘッダで、クライアントはIf-Modified-Sinceで条件付き取得を行います。1秒単位の粒度しかないため、同一秒内に複数回更新されると変化を検知できない弱点があり、また動的生成コンテンツでは「真の最終更新時刻」が定義しにくい問題があります。ETagはこれらの弱点を回避でき、ハッシュベースなら衝突確率も極めて低く抑えられます。
とはいえLast-Modifiedは時刻として人間が読みやすく、ログやデバッグで「いつ更新されたか」を直感的に確認できる利点があります。そのため両ヘッダを併用するのが現代的な定石で、サーバはETagとLast-Modifiedの両方を返し、クライアントはIf-None-MatchとIf-Modified-Sinceの両方を送る運用が一般的です。サーバ側はまずETagの一致をチェックし、不一致なら次にLast-Modifiedの新旧を比較するという順序で評価します。古いHTTP/1.0クライアントとの互換性も保てるため、両方の併用がベストプラクティスとして広く採用されています。
まとめ
ETagはHTTP/1.1（1997年RFC 2068）で導入されたリソース版指紋ヘッダで、現在はRFC 9110（2022年）に統合されています。強いETagと弱いETagを使い分け、If-None-Matchによる条件付きGETやIf-Matchによる楽観的排他制御を可能にします。Last-Modifiedと併用することで動的・静的問わずWebキャッシュの効率を最大化でき、CDN・ブラウザ・APIサーバを横断する高速化基盤として現代Webに不可欠な仕組みです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント