【入門編】 Varyヘッダーによるキャッシュキーの制御とコンテンツネゴシエーション – Web APIアーキテクチャ・データ連携実践ガイド

「えっ、なんで俺の画面だけ文字化けしてるの？」――Varyヘッダーが守るキャッシュの平和な世界

エンジニアの皆さん、こんにちは！ネットワークとWebの深淵を愛してやまないインフラアーキテクトです。

突然ですが、こんな経験はありませんか？
「ブラウザでアクセスしたら英語のページが表示されたのに、隣の席の同僚の画面では日本語で表示されている」「ログインしているのに、なぜかログアウト状態の画面が見えてしまう」。

実はこれ、「キャッシュの勘違い」が引き起こしている悲劇かもしれません。今日は、Web APIやWebサイトの裏側で、パケットが静かに、しかし激しく戦っている「キャッシュ戦略」の要、Varyヘッダーについてお話ししましょう。

—

郵便配達で例える「キャッシュの仕組み」

まず、キャッシュサーバーを「郵便局の仕分け係」だと想像してみてください。

皆さんがWebサイトにアクセスするのは、「手紙（リクエスト）」を出すことと同じです。郵便局（キャッシュサーバー）は、一度受け取った返事（レスポンス）をコピーして保管しておき、次に同じ手紙が来たら、わざわざ遠くのサーバーまで取りに行かずに、コピーをすぐに渡すという神対応をしてくれます。これがキャッシュです。

しかし、ここで問題が発生します。

Aさんが「日本語で読みたいよ！」と伝えた手紙
Bさんが「英語で読みたいよ！」と伝えた手紙

もし郵便局の仕分け係が、「手紙の中身（URL）さえ同じなら、とりあえず全部同じコピーを渡せばいいや！」と判断したらどうなるでしょう？ Aさんの元に英語の手紙が届いてしまい、大混乱ですよね。

この「仕分け係」に、「URLだけじゃなくて、このヘッダー（条件）もちゃんとチェックしてね！」と指示を出すための魔法のカード、それが Vary ヘッダーなんです。

—

Vary ヘッダーがやっていること

Vary ヘッダーは、サーバーからブラウザに対してこう告げます。
「このキャッシュは、特定のリクエストヘッダーが一致した時だけ有効だよ！」

例えば、Vary: Accept-Language というヘッダーを送ると、キャッシュサーバーは「URLが同じでも、言語設定が違えば別物として扱わなきゃ！」と理解してくれるようになります。

よくある指定例

Vary: Accept-Encoding: 圧縮形式（GzipやBrotliなど）が違う場合にキャッシュを分ける。
Vary: Accept-Language: 言語設定が違う場合にキャッシュを分ける。
Vary: Authorization: 認証情報が違う場合にキャッシュを分ける（※基本はキャッシュさせないのが鉄則ですが！）。

—

実践：NginxやWebサーバーでの設定例

では、実際に現場でどう書くのか見てみましょう。今回はWebサーバーの定番、Nginx を例にします。

# Nginxの設定ファイル例
location /api/data {
    # ユーザーの言語設定や圧縮形式が変わるたびにキャッシュを別々に作る
    add_header Vary "Accept-Language, Accept-Encoding";
    
    # 実際にキャッシュを有効にする設定
    proxy_cache my_cache;
}

この設定を入れるだけで、サーバーは「あ、Accept-Language が違うなら、別のキャッシュキーを作って保存しておこう」と賢い判断をしてくれるようになります。

Python (Flask) の場合

APIを開発していると、Pythonなどで動的にヘッダーを付与することもありますよね。

from flask import Flask, make_response

app = Flask(__name__)

@app.route('/api/profile')
def profile():
    response = make_response("ユーザープロフィールデータ")
    # このデータは言語によって変わるからキャッシュキーに含めてね！と指示
    response.headers['Vary'] = 'Accept-Language'
    return response

—

なぜこれが「美しいAPI設計」に繋がるのか？

REST APIを設計する際、エンドポイントのURL（例：/users/123）を綺麗に保つことは重要です。しかし、URLを複雑にしすぎると、クライアント側が使いにくいAPIになってしまいます。

URLはシンプルに保ちつつ、Vary ヘッダーを使って「リクエストヘッダーによる出し分け」を適切に行う。これこそが、ネットワークの挙動を理解した、「インフラに優しいAPI設計」と言えるでしょう。

注意点：やりすぎは禁物！

Vary ヘッダーに何でもかんでも詰め込みすぎると、キャッシュの効率がガタ落ちします。
例えば、User-Agent（ブラウザの種類）を Vary に指定してしまうと、Chrome用、Safari用、Firefox用と、数千通りのキャッシュが作られてしまい、サーバーのメモリがパンクしてしまいます。

「本当にキャッシュを分ける必要がある条件か？」を見極めるのが、スペシャリストへの第一歩です。

—

まとめ：ネットワークの裏側を覗くと、世界はもっと面白くなる

最初は難しく感じるヘッダーの世界も、「郵便物の仕分け」のような身近な仕組みに置き換えると、パケットがどう動いているのか想像しやすくなったのではないでしょうか。

Vary ヘッダーは、キャッシュサーバーへの「仕分け指示書」。
URLだけでなく、リクエストヘッダーの条件もキャッシュの識別子にする。
過度な設定はキャッシュ効率を下げるので、必要なものだけに絞る。

ネットワークプロトコルは、ただの「決まり事」ではなく、世界中の通信を円滑にするための「知恵の結晶」です。ぜひ皆さんの開発現場でも、ブラウザとサーバーの対話に耳を傾けてみてください。きっと、これまで見えなかったパケットの動きが見えてくるはずですよ！

それでは、また次回の深淵でお会いしましょう。ハッピー・コーディング！