コンテンツネゴシエーションとVaryによるキャッシュ分割

コンテンツネゴシエーションとは何か

**コンテンツネゴシエーション（content negotiation）**は、1つのURLが指す1つのリソースに対し、**複数の表現（representation）**を用意しておき、クライアントとサーバーの合意で最適な1つを選んで返す仕組みです。表現が分かれる軸は主に3つあります。言語（日本語版・英語版）、メディアタイプ（text/html と application/json）、コンテンツ符号化（Brotli圧縮版・無圧縮版）です。同じ https://example.com/article でも、受け手の事情に応じて中身を出し分けられます。

ここで核心になるのが、URLは同じまま中身が変わるという点です。URLが違えばキャッシュも別エントリになるので問題は起きません。やっかいなのは「同一URLで複数の答えがある」状態で、これをキャッシュへ正しく教えないと、英語版を要求した利用者へ日本語版が返る、といった**表現の取り違え（キャッシュ汚染）**が発生します。これを防ぐのが後述のVaryです。

ネゴシエーションには2方式あります。サーバーが選ぶサーバー駆動型（Accept系ヘッダを見てサーバーが決定）と、サーバーが選択肢の一覧（300 Multiple Choices）を返してクライアントが選ぶエージェント駆動型です。実運用のほぼ全てはサーバー駆動型なので、本記事もこれを中心に扱います。

Accept系ヘッダによる表現選択

クライアントは、自分が受理できる表現の好みをリクエストヘッダで申告します。代表的なのが4つのAccept系です。

GET /article HTTP/1.1
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
Accept-Language: ja, en-US;q=0.8, en;q=0.5
Accept-Encoding: br, gzip
Accept-Charset: utf-8

末尾の;q=は**品質値（q値、0〜1）**で、各候補への相対的な好みを表します。省略時はq=1です。サーバーは「自分が生成できる表現の集合」と「クライアントが受理可能な集合」を突き合わせ、q値の高いものを優先して1つを選びます。Accept-Language: ja, en-US;q=0.8なら、日本語版があれば日本語、無ければ米国英語、という優先順になります。

選択アルゴリズムは概ね次の擬似コードです。

candidates = サーバーが提供できる表現の一覧
for each ヘッダ軸 in [メディアタイプ, 言語, 符号化]:
    クライアントの受理集合とのマッチングでスコア付け（q値を反映）
最終スコアが最大の表現を選択
選択に使った軸を Vary に列挙して応答

重要なのは、サーバーが選択に使った軸を、後で必ずVaryに申告する責任を負う点です。Accept-Languageを見て言語を切り替えたなら、応答にVary: Accept-Languageを付けなければなりません。これを怠ると、キャッシュは言語差を区別できなくなります。

Varyがキャッシュキーを分割する仕組み

キャッシュ（ブラウザ、CDN、リバースプロキシ）は通常、リクエストのメソッドとURLを主キーとして応答を格納します。しかしコンテンツネゴシエーションが絡むと、同じURLでも返すべき中身がリクエストヘッダによって変わります。そこでVaryの出番です。

Vary応答ヘッダは「この応答の選択に影響したリクエストヘッダ名」を列挙します。キャッシュはこれを読み、実効キャッシュキーを次のように拡張します。

キャッシュキー = (メソッド, URL)                         ← Vary なし
キャッシュキー = (メソッド, URL, Vary に挙げた各リクエストヘッダの値)  ← Vary あり

たとえば応答にVary: Accept-Languageがあれば、キャッシュは「URL＋Accept-Languageの値」の組み合わせごとに別エントリを保持します。Accept-Language: jaで来た要求には日本語版エントリを、Accept-Language: enには英語版エントリを返し、両者が衝突しません。

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Language: ja
Vary: Accept-Language, Accept-Encoding

この応答に対し、キャッシュは「URL ＋ 要求のAccept-Language ＋ 要求のAccept-Encoding」をキーにします。言語が2種・符号化が2種なら、最大で 2 × 2 = 4 通りのエントリに分割されます。ここにVaryの本質的なトレードオフがあります。Vary対象の軸が増えるほど、キャッシュは細かく分割され、同じ表現を再利用できる確率（ヒット率）が下がります。

Varyの落とし穴と「*」

Varyにはもう1つ特別な値があります。Vary: *です。これは「この応答は何らかの未宣言の要因で変わり得るため、いかなるリクエストにも再利用してはならない」という意味で、実質的にキャッシュを無効化します。CDNやプロキシはVary: *を見たら、その応答を共有キャッシュとして保存・再利用しません。意図せず付与すると配信が全てオリジンに戻り、性能を大きく損ないます。

もう1つの典型的な事故が、符号化のVary漏れです。Content-Encodingで圧縮を有効にしながらVary: Accept-Encodingを付け忘れると、CDNは圧縮版と無圧縮版を同一キーで扱い、Brotli非対応のクライアントへBrotli応答を返してしまいます。圧縮の交渉とVaryの関係はBrotli/gzipによるコンテンツ符号化と転送圧縮の原理で詳述しています。

なお、キャッシュ側のVaryの扱いは「正規化（normalization）」の有無で結果が変わります。素朴な実装はAccept-Encodingの値を文字列としてそのまま比較するため、gzip, brとbr, gzipを別物と見なしエントリが無駄に増えます。CDNの多くはAccept-Encodingをbr／gzip／identityの少数の正規形へ畳んでからキーにし、分割数を抑えています。自前のキャッシュ層を実装するなら、この正規化を入れるかどうかでヒット率が大きく変わります。

Client Hintsへの移行と注意点

User-Agentを端末判定や画像出し分けに使う慣習は、上記のとおりキャッシュと相性が最悪です。これを置き換えるのがClient Hints（クライアントヒント）です。サーバーが「欲しい情報の種類」を宣言し、ブラウザがそれに応じて必要な軸だけを専用ヘッダで送る、という協調モデルになっています。

仕組みは2段階です。まずサーバーが応答でAccept-CHを送り、受け取りたいヒントを宣言します。

HTTP/1.1 200 OK
Accept-CH: Sec-CH-DPR, Sec-CH-Viewport-Width, Sec-CH-Width
Vary: Sec-CH-DPR, Sec-CH-Viewport-Width

次回以降、ブラウザは宣言されたヒントだけをリクエストに付けます（例: Sec-CH-DPR: 2 でデバイスピクセル比、Sec-CH-Viewport-Width: 1280 でビューポート幅）。サーバーはこれを見て、たとえば高解像度端末には2倍密度の画像を返す、といった出し分けができます。出し分けに使ったヒントは、やはりVaryに列挙してキャッシュへ伝えます。

この方式の利点は、キャッシュ分割の軸を粗い離散値に保てることです。User-Agentの無限のバリエーションと違い、DPRは実質1・2・3程度、ビューポート幅もサーバー側でブレークポイント単位に丸めれば数通りに収まります。必要な軸だけをVaryに入れられるので、ヒット率を保ったまま端末適応ができます。

まとめ

コンテンツネゴシエーションは、同一URLで言語・形式・符号化などの表現を出し分ける仕組みで、サーバーはAccept系ヘッダとq値を突き合わせて1つを選びます。その選択をキャッシュへ正しく伝える要がVaryで、Varyに挙げた軸は実効キャッシュキーへ織り込まれ、表現の取り違えを防ぎます。代償としてVary対象が増えるほどキャッシュは分割されヒット率が落ちるため、User-Agentでの分岐は避け、Client HintsとAccept-CHで必要な軸だけを離散値で宣言するのが現代の定石です。キャッシュキー分割の全体像はブラウザキャッシュの階層と判定アルゴリズムを、鮮度と再検証の基礎はHTTP キャッシュを、ヘッダ自体を圧縮して送る仕組みはHTTP/2の多重化とHPACKヘッダ圧縮の原理を併読すると、配信最適化の判断軸がつながります。