キャッシュの「無駄な転送」を根絶せよ：ETagと条件付きGETで実現するネットワーク最適化の極意
ネットワークエンジニアとして現場を歩いていると、「なぜかAPIのレスポンスが重い」「CDNの効果がいまいち薄い」という相談をよく受ける。その原因の多くは、実はプロトコルの基本である「キャッシュの制御」にある。
Web APIの設計において、すべてのリクエストに対して毎回フルボディ（200 OK）を返していれば、当然ながら帯域は逼迫し、サーバーのCPUも無駄に消費する。ここで登場するのが、HTTP/1.1で標準化された強力な武器、`ETag`（Entity Tag）を用いた条件付きGETだ。
今日は、この「リソースの変更確認」という地味だが極めて重要なプロトコル挙動を、現場目線で解剖していこう。
—
1. なぜ「更新がないなら送るな」が重要なのか
想像してほしい。数メガバイトある巨大なJSONデータを、ユーザーが何度も読み込むシーンを。もしサーバー側でデータが更新されていないにもかかわらず、毎回その全データをパケットとして流し続けるとしたら、それはネットワークに対する冒涜に等しい。
`ETag`は、そのリソースの状態を表現する「一意の指紋」だ。ハッシュ値や最終更新時刻から生成されるこの文字列をサーバーが発行し、クライアントがそれを記憶する。そして次回以降、クライアントはその指紋を提示して「このデータ、まだこれと同じ？」と問う。
サーバーは「同じなら304を返すだけ」。この判断によって、データ本体の転送をスキップできる。これが条件付きGET（Conditional GET）の真髄だ。
—
2. 通信フロー：304 Not Modifiedが生まれる瞬間
まずは、実際のパケットのやり取りを追ってみよう。
最初のアクセス（フル転送）
1. クライアント: `GET /data.json`
2. サーバー: `200 OK`
- `ETag: “v1.0.0-abcd”` （この指紋を記憶する）
- `Content-Type: application/json`
- `{ … }` （データ本体）
2回目のアクセス（キャッシュ検証）
1. クライアント: `GET /data.json`
- `If-None-Match: “v1.0.0-abcd”` （記憶していた指紋を送る）
2. サーバー: `304 Not Modified`
- （データ本体の転送は無し。ヘッダーのみで終了）
この「304 Not Modified」を受け取ったクライアントは、自身のローカルキャッシュをそのまま利用する。これにより、レイテンシは最小化され、ネットワーク帯域は保護されるわけだ。
—
3. 実践：ETagを意識したWeb APIの挙動確認
理論はわかっても、手を動かさなければエンジニアとは言えない。まずは `curl` を使って、この挙動を自身の目で確かめてみよう。
1回目：ETagを取得する
curl -I https://api.example.com/resource
レスポンスヘッダーに ETag: “12345” があれば成功
2回目：If-None-Match を指定して条件付きGET
curl -I -H ‘If-None-Match: “12345”‘ https://api.example.com/resource
サーバーでデータが変わっていなければ、HTTP/1.1 304 Not Modified が返ってくるはずだ
フロントエンド（Fetch API）での実装例
ブラウザのFetch APIを使う場合、ブラウザが自動的にキャッシュ管理を行うケースが多いが、明示的に制御したい場合は以下のようにヘッダーを付与する。
const etag = “12345”; // 以前のレスポンスから保存しておいた値
fetch(‘/api/resource’, {
headers: {
// サーバーに「このETagじゃなければ送ってくれ」と伝える
‘If-None-Match’: etag
}
}).then(response => {
if (response.status === 304) {
console.log(“キャッシュが有効です！”);
return;
}
return response.json();
});
—
4. 現場のトラブルシューティングTips
最後に、インフラ運用でハマりやすいポイントを伝授しておく。
- ETagの生成アルゴリズムに注意:
ETagは「リソースの同一性」を保証するものだ。もしロードバランサーやアプリケーションサーバーが、タイムスタンプをそのままETagにしている場合、サーバーの時刻同期が甘いと、リソースが変わっていなくてもETagが変わってしまうことがある。可能な限り内容のハッシュ値（MD5やSHA-256）を計算してETagにするのがベストプラクティスだ。
- 強ETagと弱ETag:
`ETag: “v1″` は強（Strong）検証子、`ETag: W/”v1″` は弱（Weak）検証子と呼ばれる。弱検証子は「意味的に同じなら良しとする（バイト単位の完全一致は求めない）」という場合に使う。API用途なら、まずは強検証子で厳密に管理することをお勧めする。
- デバッグ時はキャッシュを疑え:
「コードを直したのに反映されない！」という時の原因は、往々にしてブラウザやCDNの強力なキャッシュだ。開発中は `Cache-Control: no-cache` を付与して、毎回 `If-None-Match` が飛んでいるか、Chrome DevToolsの「Network」タブで304の挙動をしっかり確認する癖をつけよう。
—
まとめ
HTTP/1.1の設計思想は、現代の複雑なクラウドネイティブ環境においても全く色褪せていない。`ETag` と `If-None-Match` を使いこなすことは、単なる最適化ではなく、ユーザー体験を向上させ、インフラコストを抑制するための「エンジニアとしてのマナー」だ。
次にAPIを設計するとき、あるいはネットワークが遅いと感じたときは、ぜひこの「指紋合わせ」の仕組みを思い出してほしい。泥臭いデバッグの先にこそ、洗練されたアーキテクチャが見えてくるはずだ。
コメント