User-Agentの「嘘」と「歴史」：なぜ現代のWebはこんなにも混沌としているのか
ネットワークエンジニアとして現場を歩いていると、パケットキャプチャの海の中でふと奇妙な文字列に出くわすことがある。
`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36`
これを見て「ああ、これはMozillaブラウザだな」と即断する若手はいないと思うが、もしそう思っているなら要注意だ。この文字列は、Webの歴史が積み上げてきた「互換性という名の呪い」そのものだからだ。
今日は、HTTP/1.1においてクライアントの識別を担う最も重要で、かつ最も信用ならないヘッダー、`User-Agent`について、現場の視点から紐解いていこう。
—
User-Agentが辿った「互換性の迷宮」
User-Agent（UA）の歴史は、そのままWebブラウザ戦争の歴史だ。
HTTP/0.9や1.0の時代、UAはシンプルに「どのブラウザを使っているか」をサーバーに教えるためのものだった。しかし、Netscape Navigatorが覇権を握り、続いてInternet Explorer（IE）が登場した際、サーバー側が「IEには新しいレイアウトを送るが、Netscapeには古いレイアウトを送る」といった判定を行っていたことが悲劇の始まりだった。
IEは、自身がWebサーバーから正しくコンテンツを受け取れることを証明するために、UA文字列の中に「Mozilla」という単語を忍び込ませた。これがすべての始まりだ。以降、新しいブラウザが登場するたびに、Webサイト側の判定ロジックを突破するために、競合ブラウザのUAを模倣し、結果として現代のUAは「Mozilla/5.0 (……) AppleWebKit/… (KHTML, like Gecko) …」という、カオスな継ぎ接ぎだらけの文字列に成り果ててしまった。
—
現場で役立つUser-Agentの構造分解
実務において、API設計やWAF（Web Application Firewall）のルール設定を行う際、この文字列をどう扱うべきか。まずは基本となる構造を理解しよう。
GET /api/v1/resource HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
この文字列は、以下の要素で構成されていることが多い。
1. Mozilla/5.0: 互換性のためのレガシーな接頭辞（ほぼ全ブラウザがこれ）。
2. プラットフォーム: `(Macintosh; Intel Mac OS X 10_15_7)` 等、OSのバージョンやアーキテクチャ。
3. レンダリングエンジン: `AppleWebKit/537.36`。Webサイトの描画エンジンを示す重要な指標。
4. ブラウザ識別子: `Chrome/123.0.0.0 Safari/537.36`。最終的に実行されているブラウザ名とバージョン。
—
実践：UAを操作してデバッグする
インフラ運用やAPI開発において、特定デバイスからのアクセスをシミュレートしたり、逆に不正なUAを弾いたりする必要があるはずだ。以下に、現場ですぐに使えるコード例を挙げる。
1. curl で特定のUAを偽装してテストする
APIがUAベースでフィルタリングを行っている場合、まずは`curl`で検証するのが定石だ。
特定のデバイスを装ってAPIを叩く
curl -v -H “User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1” \
https://api.example.com/v1/data
-v オプションを付けることで、リクエストヘッダーが正しく送られているか確認できる
2. Python (requests) での動的なUA設定
スクレイピングや自動テストでUAを設定する場合、毎回ハードコードするのではなく、定数として管理するのがベストプラクティスだ。
import requests
信頼されるべきUAを定義（定数化しておく）
USER_AGENT = “MyApp/1.0 (Integration-Test; +https://my-service.com)”
headers = {
“User-Agent”: USER_AGENT,
“Accept”: “application/json”
}
response = requests.get(“https://api.example.com/status”, headers=headers)
print(f”ステータスコード: {response.status_code}”)
—
運用上の注意点：UAを「信頼」してはいけない
最後に、シニアエンジニアとして一つだけ忠告をしたい。
「User-Agentは、あくまで自己申告である」
クライアントは、クライアント側のコードで自由にUAを書き換えることができる。UAをセキュリティの要（たとえば「このUA以外からのアクセスは許さない」といった認証など）にするのは、鍵のかかっていない玄関に「ここは関係者以外立ち入り禁止」という張り紙をするのと同じだ。
- アクセス解析: UAの統計を取ることは有効だが、正確性は100%ではないことを前提にすること。
- WAFの除外設定: UAに基づいたルール設定は便利だが、正規表現が甘いと簡単に突破される。
- 将来性: ブラウザ側は現在、プライバシー保護の観点からUA文字列を固定化（Reduce）する方向に動いている。`User-Agent Client Hints` という新しい規格が主流になりつつあることを、頭の片隅に置いておこう。
HTTP/1.1が支えてきたこの古き良きUAという仕組みは、今のWebを動かす「しきたり」そのものだ。その複雑さを嘆くのではなく、その歴史的背景を理解した上で、いかに堅牢なインフラとAPIを設計するか。それこそが、我々ネットワークエンジニアの腕の見せ所だ。
現場からは以上だ。何か詰まったら、まずはパケットを覗いてみよう。そこには必ず真実が記されている。
コメント