条件付きリクエスト（Conditional Requests）は、HTTPでクライアントが「リソースが変わっていれば取得、変わっていなければ何もしない」という条件付きで要求を出す仕組みです。HTTP/1.1で導入され、現在はRFC 9110（2022年、旧RFC 7232）で定義されています。代表的なヘッダはIf-None-Match（保存中のETagと比較）とIf-Modified-Since（最終更新時刻と比較）で、サーバは変更がなければ304 Not Modifiedを返して本文を省略し、変更があれば通常通り200 OKで新しい内容を返します。ブラウザキャッシュ・CDN・ETag運用の根幹を成し、Webパフォーマンスを大きく左右する仕組みです。
この記事の目次
- 4種類の条件付きヘッダの役割
- HTTP/1.1での標準化と現代運用
- 実装現場でよく見る使い方
- 条件付き取得 vs 通常GET vs WebSocket
- まとめ
4種類の条件付きヘッダの役割
条件付きリクエスト用のヘッダは大きく4種類あります。If-None-Matchは「指定ETagと一致しないなら取得」で、GET時に主に使い、最新版なら304で本文省略を狙います。If-Modified-Sinceは「指定時刻より新しければ取得」で、Last-Modifiedとセットで使う伝統的な仕組みです。GETリクエストとともに送られ、変更がなければ304が返ります。
更新系（PUT・PATCH・DELETE）では役割が逆転します。If-Matchは「指定ETagと一致するなら更新を実行、不一致なら412」で、楽観的排他制御に使います。あるリソースを編集中、他者の更新で値が変わっていたら自分の上書きを拒否させる仕組みです。If-Unmodified-Sinceは同様に「指定時刻以降に更新されていなければ実行」というロジックで、同じく排他制御に使われます。サーバ側はこれら4種類を解釈し、200/304/412などのステータスコードでクライアントに状況を伝えるのが基本動作です。
HTTP/1.1での標準化と現代運用
条件付きリクエストはHTTP/1.0時代のIf-Modified-Sinceを起点とし、1997年のRFC 2068で本格的に整備され、1999年のRFC 2616でHTTP/1.1の標準として確立しました。当初はLast-Modifiedベースの仕組みが中心でしたが、1秒粒度の制約や動的生成リソースとの相性問題から、ETagベースのIf-None-Match/If-Matchが加わり、より精密な条件指定が可能になりました。
2014年のRFC 7232は条件付きリクエストの仕様を独立文書として再整理し、ステータスコードや評価順序、強弱ETagとの組み合わせを明確化しました。現代仕様は2022年のRFC 9110で統合され、HTTP/2・HTTP/3でも同じ仕組みが受け継がれています。実装としてはNginx・Apache・IISなどの主要Webサーバが自動で対応し、CDNのCloudFront・Fastly・Cloudflareもエッジで条件付きリクエストの判定を行うため、Webリクエストが通る全レイヤーで透過的に効く設計になっています。
実装現場でよく見る使い方
ブラウザは2回目以降のリソース取得で自動的にIf-None-MatchやIf-Modified-Sinceを付与し、サーバが304を返せば本文がほぼゼロのレスポンスで済むため、画像やCSS・JSの再取得を高速化できます。DevToolsのNetworkタブで「304 Not Modified」と表示されているのがこの動作です。REST APIでも、変更頻度の低いマスターデータを取得する際にIf-None-Matchで差分のみを取りに行く設計が一般的で、レイテンシと帯域の両方が改善します。
PUT/PATCH系のAPIではIf-Matchで楽観的排他制御を実装する例が多く、AWS S3のPUT Object、Stripe APIのidempotency、GitHub APIのWiki更新などで採用されています。「最初にGETでETagを取得→編集→If-Match付きのPUT」という流れで、複数クライアントの競合を検出できます。CDNとオリジン間でも条件付きリクエストが効き、CDNエッジが古くなったキャッシュをIf-None-Matchでオリジンに問い合わせて304が返れば、オリジン側のCPUと帯域が節約されます。RSSフィードの巡回もこの仕組みで効率化されており、サブスクライブ側が頻繁にチェックしてもサーバ負荷が抑えられる設計が主流です。
条件付き取得 vs 通常GET vs WebSocket
通常GETでは毎回全ボディが返ってくるため、変更がなくても無駄な転送が発生します。条件付きリクエストはこの無駄を304返却によって省く仕組みで、HTTPプロトコルに既に組み込まれているため、追加実装なしに効果が得られる強力なツールです。中継するCDN・プロキシ・ブラウザ全てが透過的に対応しているため、サービス全体の改善が一度に効きます。
「変更があったときだけ知らせてほしい」という別のアプローチとしては、WebSocketやServer-Sent Events、GraphQL Subscriptionsなどのサーバープッシュ系技術があります。これらは双方向または片方向の常時接続を維持して、サーバ側からプッシュする方式で、リアルタイム性が必要なチャットやライブ更新では条件付きリクエストよりも適切です。ただし接続維持コスト・接続数制限・スケール時の状態管理コストがかかります。ポーリング頻度がそれほど高くない（数秒〜数分間隔）リソースに対しては、条件付きリクエストの組み合わせの方が運用がシンプルでステートレスを維持できる利点があります。用途に応じて使い分けるのが現代の定石です。
まとめ
条件付きリクエストはHTTP/1.1で導入されRFC 9110（2022年）に統合された、差分取得と楽観的排他制御の仕組みです。If-None-Match・If-Modified-Sinceで取得側の効率化を、If-Match・If-Unmodified-Sinceで更新側の安全性を実現し、304 Not Modifiedや412 Precondition Failedで応答します。ブラウザ・CDN・REST APIなど全レイヤーで透過的に効くため、現代Webの帯域節約と整合性確保の根幹を成す仕組みとして広く活用されています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント