【実務・中級編】HTTP/1.1のキャッシュ制御ヘッダー(Cache-Control, Expires) – HTTPプロトコル・通信規格実践ガイド

HTTP/1.1 キャッシュ制御ヘッダー徹底解説：Web API設計とインフラ運用の「あるある」を解決する

おい、君たち。Web APIの設計にインフラ運用、日々お疲れ様だ。今回は、HTTP/1.1のキャッシュ制御ヘッダー、特に `Cache-Control` と `Expires` について、教科書的な説明だけじゃなく、現場で「そうそう、これこれ！」ってなるような、実践的な話をしようじゃないか。

キャッシュってのは、うまく使えばパフォーマンスを劇的に改善してくれる頼もしい味方だ。でも、間違った使い方をすると、ユーザーを混乱させたり、データの鮮度を失わせたり、思わぬトラブルの元にもなる。特に、Web APIを設計する立場なら、クライアント（ブラウザやモバイルアプリ）がどうキャッシュを扱うのか、しっかり理解しておかないと、後で泣きを見る羽目になるぞ。

今回は、HTTP/0.9からHTTP/1.1へと進化してきた中で、キャッシュ周りがどう変わってきたのか、そして、現場でよく使う `Cache-Control` ディレクティブの各パラメータが、一体どういう挙動をするのかを、具体的なシーケンス図やコード例を交えながら、じっくり紐解いていこう。

HTTPキャッシュの変遷：なぜ`Cache-Control`が重要になったのか

HTTPの歴史を振り返ると、初期のHTTP/0.9やHTTP/1.0では、キャッシュに関する標準的な制御メカニズムがほとんどなかった。ブラウザは、やみくもにリソースをキャッシュしたり、更新をチェックしたりしていたんだ。

これが、HTTP/1.1で大きく変わった。RFC 2616（後にRFC 7234で更新）によって、キャッシュの挙動を細かく制御するためのヘッダーが標準化されたんだ。その中でも、最も強力で汎用的なのが `Cache-Control` ヘッダーだ。

`Expires` ヘッダーもキャッシュ制御に使われるが、こちらは「絶対的な期限」を指定するシンプルなもの。しかし、クライアントとサーバーの時計がずれていると、意図しない挙動になる可能性がある。`Cache-Control` は、それよりも柔軟で、より多くの制御オプションを提供してくれる。だからこそ、現代のWeb API設計においては、`Cache-Control` を使いこなすことが必須と言えるんだ。

HTTPキャッシュの基本：リクエストとレスポンスのやり取り

キャッシュの挙動を理解するには、まず、クライアントとサーバーの間で、リクエストとレスポンスがどのようにやり取りされるのかを、パケットレベルでイメージすることが重要だ。

簡単な例で見てみよう。クライアント（ブラウザ）が `https://example.com/data.json` というURLにアクセスするシナリオだ。

sequenceDiagram
participant Client as ブラウザ/アプリ
participant Server as Webサーバー/APIサーバー

Client->>Server: GET /data.json HTTP/1.1
Note over Client: 初回リクエスト (キャッシュなし)
Server–>>Client: HTTP/1.1 200 OK\nContent-Type: application/json\nCache-Control: public, max-age=3600\n\n{ “message”: “Hello, world!” }
Note over Client: レスポンスを受け取り、キャッシュする

この後、クライアントが再度 `https://example.com/data.json` にアクセスする時、キャッシュが有効であれば、サーバーにリクエストを送らず、ローカルのキャッシュからデータを返せる。これがキャッシュのメリットだ。

sequenceDiagram
participant Client as ブラウザ/アプリ
participant Server as Webサーバー/APIサーバー

Client->>Client: GET /data.json HTTP/1.1 (キャッシュから応答)
Note over Client: キャッシュが有効なので、サーバーにリクエストしない
Note over Client: ローカルキャッシュからデータを返却

もし、キャッシュの有効期限が切れたり、サーバー側でデータが更新されたりした場合は、クライアントはサーバーに「このデータ、まだ使えますか？」と問い合わせる（条件付きリクエスト）。

sequenceDiagram
participant Client as ブラウザ/アプリ
participant Server as Webサーバー/APIサーバー

Client->>Server: GET /data.json HTTP/1.1\nIf-None-Match: “etag-value” (If-Modified-Since: …)
Note over Client: キャッシュの有効性を確認するリクエスト
Server–>>Client: HTTP/1.1 304 Not Modified
Note over Client: キャッシュはまだ有効。サーバーからのデータは不要。
Note over Client: ローカルキャッシュからデータを返却

逆に、サーバー側でデータが更新されていれば、新しいデータを返してくれる。

sequenceDiagram
participant Client as ブラウザ/アプリ
participant Server as Webサーバー/APIサーバー

Client->>Server: GET /data.json HTTP/1.1\nIf-None-Match: “etag-value”
Note over Client: キャッシュの有効性を確認するリクエスト
Server–>>Client: HTTP/1.1 200 OK\nContent-Type: application/json\nCache-Control: public, max-age=3600\n\n{ “message”: “Hello, updated world!” }
Note over Client: データが更新されている。新しいデータをキャッシュする。

このように、キャッシュは「リソースの鮮度」と「通信コスト」のバランスを取るための重要な仕組みなんだ。

`Expires` ヘッダー：シンプルだけど、注意が必要

まずは、比較的分かりやすい `Expires` ヘッダーから見ていこう。これは、レスポンスがいつまで有効かを、具体的に指定するヘッダーだ。

サーバーからのレスポンス例:

HTTP/1.1 200 OK
Content-Type: application/json
Expires: Tue, 15 Nov 2023 10:30:00 GMT <-- この日時まで有効 Cache-Control: max-age=3600 <-- ExpiresよりもCache-Controlが優先されることが多い { "message": "This data is valid until the specified expiry time." } ポイント:

  • 絶対日時指定: GMT（グリニッジ標準時）で、具体的な日時を指定する。
  • `Cache-Control` より優先される場合も: 多くのキャッシュ実装では、`Cache-Control` ヘッダーが存在する場合、`Expires` ヘッダーよりも `Cache-Control` の指定を優先する。
  • 時計のずれに注意: クライアントとサーバーのシステム時刻がずれていると、キャッシュの有効期限の判断がおかしくなる可能性がある。これが `Expires` の弱点だ。

`Cache-Control` ヘッダー：キャッシュ挙動を自在に操る魔法の杖

ここからが本番だ。`Cache-Control` ヘッダーは、HTTP/1.1のキャッシュ制御における主役と言える。様々な「ディレクティブ（指示）」を組み合わせて、キャッシュの挙動を細かく制御できる。

`Cache-Control` の主要なディレクティブ

これらのディレクティブは、リクエストヘッダーにもレスポンスヘッダーにも指定できる。それぞれ、どういう意味で、どういう場面で使うのか、具体例を交えて見ていこう。

1. `public` / `private`

  • `public`: ユーザーエージェント（ブラウザ）だけでなく、中間キャッシュ（CDN、プロキシサーバーなど）もキャッシュできることを示す。
  • `private`: ユーザーエージェント（ブラウザ）のみがキャッシュでき、中間キャッシュはキャッシュできないことを示す。ユーザー固有の情報を含むレスポンス（例: ログイン後のユーザー情報）などに使う。

サーバーからのレスポンス例 (APIレスポンス):

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=600 <-- ユーザー固有情報なので、ブラウザのみキャッシュ

2. `max-age=`

  • 意味: レスポンスの新鮮さを、サーバーからのレスポンス受信時刻から指定された秒数だけ維持することを示す。`Expires` よりも柔軟で、相対的な時間を指定できるため、より一般的によく使われる。
  • 実務での使いどころ: ほとんどの静的リソース（CSS, JS, 画像）や、更新頻度が低いAPIレスポンスに。

サーバーからのレスポンス例 (画像ファイル):

HTTP/1.1 200 OK
Content-Type: image/jpeg
Cache-Control: public, max-age=86400 <-- 1日間（24時間）キャッシュ

3. `no-cache`

  • 意味: キャッシュはするが、利用する前に必ずオリジンサーバー（元のサーバー）に「このキャッシュはまだ使えますか？」と確認（再検証）を求めることを示す。
  • 注意点: 名前が紛らわしいが、「キャッシュしない」という意味ではない。あくまで「再検証を必須とする」という意味だ。
  • 実務での使いどころ: 頻繁に更新される可能性のあるデータや、常に最新の状態を確認したいが、毎回全データを取得するのは避けたい場合。

サーバーからのレスポンス例 (最新ニュースAPI):

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache <-- 利用前に必ずサーバーに確認させる

4. `no-store`

  • 意味: キャッシュを一切行わないことを示す。クライアント、中間キャッシュ、どちらもキャッシュしてはならない。
  • 実務での使いどころ: 機密性の高い情報（例: ユーザーの個人情報、認証トークン、決済情報）や、一時的な情報（例: ログインセッション情報）など、絶対にキャッシュを残したくない場合に使う。

サーバーからのレスポンス例 (認証トークン):

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store <-- 絶対にキャッシュさせない

5. `must-revalidate` / `proxy-revalidate`

  • 意味: キャッシュが古くなった（stale）場合、必ずオリジンサーバーに再検証を求めることを示す。`must-revalidate` はクライアント、`proxy-revalidate` は中間キャッシュに対しても適用される。
  • `no-cache` との違い: `no-cache` は、キャッシュが新鮮な間は再検証を求めないが、`must-revalidate` は、新鮮さが失われた（`max-age` が切れた）時点で再検証を求める。
  • 実務での使いどころ: データの整合性が非常に重要な場合に、キャッシュの鮮度を厳密に管理したいとき。

6. `s-maxage=`

  • 意味: `max-age` と似ているが、共有キャッシュ（CDNやプロキシサーバー）にのみ適用される。
  • 実務での使いどころ: CDNなどのエッジキャッシュには長めにキャッシュさせたいが、ブラウザには短めにキャッシュさせたい、といった場合に `max-age` と組み合わせて使う。

`Cache-Control` の組み合わせ例

これらのディレクティブは、カンマ区切りで複数指定できる。

  • 例1: 公開リソースで、1時間キャッシュする

Cache-Control: public, max-age=3600

  • 例2: ユーザー固有情報で、5分キャッシュするが、利用前に必ず確認する

Cache-Control: private, max-age=300, must-revalidate

  • 例3: 機密情報なので、一切キャッシュしない

Cache-Control: no-store

`ETag` と `Last-Modified`：キャッシュの再検証を効率化する仕組み

`Cache-Control` だけでは、キャッシュが古くなったかどうかを判断するために、毎回サーバーに全データを送る必要が出てくる場合がある。そこで活躍するのが、キャッシュの再検証を効率化するためのヘッダーだ。

`ETag` (Entity Tag)

  • 意味: リソースの特定のバージョンを一意に識別するための識別子。リソースの内容が変わると、`ETag` も変更される。ファイルハッシュやバージョン番号のようなものだと考えれば良い。
  • 再検証時のリクエスト: クライアントは、ローカルに保存している `ETag` 値を `If-None-Match` ヘッダーに含めてサーバーに送信する。
  • サーバーの応答: サーバーは、リクエストされたリソースの現在の `ETag` と比較し、一致すれば `304 Not Modified` を返す。一致しなければ、新しいリソースと `200 OK` を返す。

サーバーからのレスポンス例 (初回):

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600
ETag: “abcdef12345” <-- ETag値 { "data": "some value" } クライアントからのリクエスト例 (再検証):

GET /data.json HTTP/1.1
Host: example.com
If-None-Match: “abcdef12345” <-- 前回のETag値を送信 サーバーからの応答例 (キャッシュ有効):

HTTP/1.1 304 Not Modified
ETag: “abcdef12345”

`Last-Modified`

  • 意味: リソースが最後に変更された日時を示す。
  • 再検証時のリクエスト: クライアントは、ローカルに保存している `Last-Modified` 日時を `If-Modified-Since` ヘッダーに含めてサーバーに送信する。
  • サーバーの応答: サーバーは、リクエストされたリソースの最終更新日時とリクエストされた日時を比較し、変更がなければ `304 Not Modified` を返す。

サーバーからのレスポンス例 (初回):

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600
Last-Modified: Tue, 14 Nov 2023 15:00:00 GMT <-- 最終更新日時 { "data": "some value" } クライアントからのリクエスト例 (再検証):

GET /data.json HTTP/1.1
Host: example.com
If-Modified-Since: Tue, 14 Nov 2023 15:00:00 GMT <-- 前回の最終更新日時を送信 サーバーからの応答例 (キャッシュ有効):

HTTP/1.1 304 Not Modified
Last-Modified: Tue, 14 Nov 2023 15:00:00 GMT

`ETag` と `Last-Modified` の使い分け:

  • `ETag` は、リソースの変更をより正確に検知できるため、一般的には `ETag` と `If-None-Match` の組み合わせが推奨される。
  • `Last-Modified` は、ファイルシステムのタイムスタンプなどに依存するため、`ETag` よりも精度が劣る場合がある。しかし、実装が容易な場合もある。
  • 両方指定されている場合、多くのキャッシュ実装では `ETag` を優先する。

実践：コード例で見るキャッシュ制御

ここからは、実際にコードでどのようにキャッシュ制御ヘッダーを設定・確認するかを見ていこう。

1. JavaScript (Fetch API) でのキャッシュ制御

Fetch API では、`Cache-Control` ヘッダーはデフォルトでリクエストに付与されることがある。それを制御するには、`cache` オプションを使用する。

// 例1: デフォルトのキャッシュ挙動（ブラウザのデフォルト設定に従う）
fetch(‘https://api.example.com/items’)
.then(response => response.json())
.then(data => console.log(data));

// 例2: キャッシュを一切使用しない（no-store に相当）
fetch(‘https://api.example.com/items’, {
cache: ‘no-store’
})
.then(response => response.json())
.then(data => console.log(data));

// 例3: キャッシュのみを使用し、サーバーに確認しない（max-ageなどが有効な場合）
fetch(‘https://api.example.com/items’, {
cache: ‘only-if-cached’ // キャッシュがない場合はエラーになる
})
.then(response => response.json())
.then(data => console.log(data));

// 例4: キャッシュを無視して常にサーバーに確認する（no-cacheに相当）
fetch(‘https://api.example.com/items’, {
cache: ‘reload’ // 常にサーバーにリクエストする
})
.then(response => response.json())
.then(data => console.log(data));

// 例5: キャッシュがある場合はそれを利用し、なければサーバーから取得する（デフォルトの挙動）
fetch(‘https://api.example.com/items’, {
cache: ‘default’ // または ‘force-cache’ (常にキャッシュを使う)
})
.then(response => response.json())
.then(data => console.log(data));

ブラウザの開発者ツールの活用:
ChromeやFirefoxなどのブラウザ開発者ツールを開き、「Network」タブでリクエストの詳細を確認しよう。
「Headers」タブで、リクエストヘッダーに `Cache-Control: no-cache` などが付与されているか、レスポンスヘッダーに `Cache-Control` や `ETag` が返ってきているかを確認できる。
「Memory」タブや「Application」タブの「Cache Storage」や「Local Storage」なども、キャッシュの状況を把握するのに役立つ。

2. curl でのキャッシュ制御と確認

`curl` コマンドは、HTTPリクエストを直接送信できる強力なツールだ。キャッシュヘッダーの送受信をテストするのに最適だ。

例1: `Cache-Control` ヘッダーを付けてリクエストを送信

Cache-Control: no-cache をリクエストヘッダーに付けて送信
curl -v -H “Cache-Control: no-cache” https://api.example.com/data.json

Cache-Control: only-if-cached をリクエストヘッダーに付けて送信
curl -v -H “Cache-Control: only-if-cached” https://api.example.com/data.json

  • `-v`: 詳細な情報を表示する（リクエストヘッダー、レスポンスヘッダーなど）。
  • `-H “Header-Name: Header-Value”`: カスタムヘッダーを指定する。

例2: `ETag` や `Last-Modified` を使った再検証をシミュレーション

まず、初回のリクエストで `ETag` や `Last-Modified` を取得する。

初回リクエストで ETag と Last-Modified を取得
curl -v https://api.example.com/data.json > response.json

上記コマンドの出力（`-v` オプションによるもの）から、`ETag` や `Last-Modified` の値を確認する。例えば、`ETag: “xyz789″` や `Last-Modified: Wed, 15 Nov 2023 12:00:00 GMT` のような値だ。

次に、取得した値を使って `If-None-Match` や `If-Modified-Since` ヘッダーを付けて再リクエストする。

ETag を使った再検証
curl -v -H “If-None-Match: \”xyz789\”” https://api.example.com/data.json

Last-Modified を使った再検証
curl -v -H “If-Modified-Since: Wed, 15 Nov 2023 12:00:00 GMT” https://api.example.com/data.json

  • `ETag` の値はダブルクォートで囲まれていることが多いので、エスケープが必要な場合がある。

例3: サーバーからのキャッシュ制御ヘッダーを確認

サーバーが返した Cache-Control, Expires, ETag, Last-Modified を確認
curl -v https://api.example.com/static/style.css

レスポンスヘッダーに `Cache-Control` や `Expires` が含まれているかを確認する。

3. Python (requests) でのキャッシュ制御

Python の `requests` ライブラリでは、標準ではキャッシュ機能は提供されていない。しかし、`requests-cache` のようなライブラリを使えば、簡単にキャッシュ機能を実装できる。

`requests-cache` を使った例:

まず、ライブラリをインストールする。

pip install requests-cache

そして、以下のようにコードを書く。

import requests
import requests_cache

キャッシュを有効にする (ファイルに保存される)
expire_after=3600 は max-age=3600 に相当 (秒単位)
requests_cache.install_cache(‘my_api_cache’, expire_after=3600)

最初のGETリクエスト (サーバーから取得し、キャッシュされる)
try:
response1 = requests.get(‘https://api.example.com/users/123’)
print(“Response 1 (from server):”, response1.json())
print(“From cache:”, response1.from_cache) # False になるはず
except requests.exceptions.RequestException as e:
print(f”Error fetching data: {e}”)

2回目のGETリクエスト (キャッシュがあれば、サーバーに問い合わせずレスポンスが返る)
try:
response2 = requests.get(‘https://api.example.com/users/123’)
print(“Response 2 (from cache):”, response2.json())
print(“From cache:”, response2.from_cache) # True になるはず
except requests.exceptions.RequestException as e:
print(f”Error fetching data: {e}”)

キャッシュを無効にする場合 (no-cache に近い挙動)
no_store=True でキャッシュしない
only_cache=True でキャッシュのみ利用
response3 = requests.get(‘https://api.example.com/users/123’,
headers={‘Cache-Control’: ‘no-cache’}) # リクエストヘッダーで制御
print(“Response 3 (no-cache header):”, response3.json())
print(“From cache:”, response3.from_cache) # False になるはず

キャッシュをアンインストールする
requests_cache.uninstall_cache()

`requests-cache` は、`Cache-Control` ヘッダーの `max-age` や `Expires` を解釈してキャッシュの有効期限を管理してくれる。また、`no-cache` や `no-store` といったディレクティブも、リクエストヘッダーで指定することで、キャッシュ挙動を制御できる。

4. Webサーバー/APIゲートウェイの設定例 (Nginx)

WebサーバーやAPIゲートウェイでも、キャッシュ制御ヘッダーを設定できる。ここでは、Nginx の設定例を挙げる。

Nginx 設定例 (`nginx.conf` またはサイト設定ファイル):

server {
listen 80;
server_name api.example.com;

location / {
# バックエンドAPIへのプロキシ設定
proxy_pass http://backend_api_server;

# レスポンスヘッダーに Cache-Control を追加する例
# 認証が必要なAPIなど、ユーザー固有情報の場合
add_header Cache-Control “private, max-age=600”; # 10分間、ブラウザのみキャッシュ

# 静的ファイル (画像など) の場合
# location ~ \.(jpg|jpeg|png|gif|ico|css|js)$ {
# expires 1y; # 1年間キャッシュ (ExpiresヘッダーとCache-Control: max-ageを設定)
# add_header Cache-Control “public”; # 公開キャッシュを許可
# # または、より詳細に
# # add_header Cache-Control “public, max-age=31536000”; # 1年 = 31536000秒
# }

# 機密情報などでキャッシュさせたくない場合
# add_header Cache-Control “no-store”;
}

# 特定のパスで no-cache を指定する例
location /latest_news {
proxy_pass http://backend_api_server/latest_news;
add_header Cache-Control “no-cache”; # 利用前に必ずサーバーに確認させる
}
}

ポイント:

  • `add_header`: レスポンスヘッダーを追加するディレクティブ。
  • `expires`: `expires` ディレクティブは、`Expires` ヘッダーと `Cache-Control: max-age` ヘッダーの両方を自動的に生成してくれる。`1y` は1年、`30m` は30分、`max` はキャッシュしない（`no-store` に近い）などを指定できる。
  • `proxy_cache`: Nginx自体をリバースプロキシキャッシュとして機能させることも可能。その場合、`proxy_cache_valid` ディレクティブなどでキャッシュ期間を制御できる。

現場でのデバッグTipsと注意点

  • キャッシュが効かない！と思ったら:

1. ブラウザの開発者ツールでヘッダーを確認: 自分の意図した `Cache-Control` ヘッダーがレスポンスで返ってきているか？ `ETag` や `Last-Modified` はあるか？
2. リクエストヘッダーを確認: `Cache-Control: no-cache` や `If-None-Match` などが正しく送られているか？
3. 中間キャッシュの存在: CDNやプロキシサーバーがキャッシュしていないか？ CDNの場合は、キャッシュクリアの操作が必要になる場合がある。
4. Cookieの存在: Cookieが付与されているリクエストは、`private` キャッシュとして扱われ、中間キャッシュではキャッシュされないことが多い。
5. HTTPメソッド: `GET` メソッド以外のリクエスト（`POST`, `PUT` など）は、一般的にキャッシュされない。

  • キャッシュが効きすぎる！と思ったら:

1. `Cache-Control` の指定を見直す: `max-age` が長すぎないか？ `no-cache` や `no-store` を指定すべき箇所で指定できていないのではないか？
2. `Expires` ヘッダーの確認: `Expires` ヘッダーが指定されている場合、その値が意図せず未来の日時になっていないか？
3. サーバー側の設定: WebサーバーやAPIゲートウェイの設定で、意図せずキャッシュヘッダーが上書きされていないか？

  • API設計で考慮すべきこと:
  • リソースの更新頻度: どれくらいの頻度でデータが更新されるか？ それに応じて `max-age` や `no-cache` を使い分ける。
  • データの機密性: ユーザー固有の情報や機密情報には、必ず `private` や `no-store` を指定する。
  • APIのバージョン管理: APIのバージョンが変わる場合は、キャッシュを無効にする（`Cache-Control: no-cache` や `no-store`、またはURLのパスを変えるなど）ことを検討する。
  • ETag/Last-Modified の実装: 可能な限り、`ETag` や `Last-Modified` を実装して、再検証を効率化できるようにする。
  • ブラウザキャッシュのクリア: どうしてもキャッシュが原因で問題が解決しない場合、ブラウザのキャッシュをクリアしてみるのも手だ。ただし、これは一時的な対応であり、根本的な解決ではない。

まとめ：キャッシュ制御はWebパフォーマンスの要

`Cache-Control` ヘッダーは、HTTP/1.1におけるキャッシュ制御の要だ。`max-age`, `no-cache`, `no-store`, `public`, `private` といったディレクティブを理解し、適切に使い分けることで、Webアプリケーションのパフォーマンスを劇的に向上させることができる。

特に、Web APIを設計するエンジニアにとっては、クライアント側でのキャッシュ挙動を予測し、制御することが、ユーザー体験の向上とサーバー負荷の軽減に直結する。

今回解説した内容を参考に、日々の開発や運用でキャッシュヘッダーを意識し、デバッグやチューニングに役立ててほしい。キャッシュは諸刃の剣だが、その特性を理解し、正しく使えば、これほど頼りになる味方はない。

さあ、君たちの手で、より高速で快適なWeb体験を築き上げてくれ！

スポンサーリンク

コメント

タイトルとURLをコピーしました