UserAgentの一貫性チェック方法と、UA不一致で見える4つの破綻ポイント

検出サイトでUAの欄が正常に見えても、アカウントはログインから数日で認証を求められます。多くの人はまず、UAをもう一度変えるか、変更プラグインをもう一つ追加することを考えます。結果は逆です。異常はむしろ頻発します。

こうした現象の原因は、たいてい一貫性にあります。UAは1つの値です。しかし読み取る位置は複数あります。1か所だけ直しても、残りには元の値が残ります。対照すれば矛盾が出ます。

UAチェックの第一歩は、このフィールドがすべての露出面で同じ内容を語しているかを見ることです。順番が大切です。次に、デバイスや地域などのパラメータと一致するかを確認します。本稿ではまずプラットフォームがUAを読む3つの経路を分解し、不一致で見える4種類のシグナルを挙げます。最後に5つの確認ポイントのチェックリストと、指紋ブラウザでの設定方法を示します。

プラットフォームがUAを読む3つの経路

同じUAの値でも、プラットフォームは実際に3か所から読みます。HTTPリクエストヘッダー、Client Hintsヘッダー、ページスクリプトです。3経路は独立しています。それぞれ単独に照合できます。

リクエスト時、ヘッダー内のUA文字列は最も早い経路です。サイトはページを受け取る前に読み終えています。Chromeはバージョン89以降、デバイス情報をSec-CH-UA系列のヘッダーに分けて報告します。ブラウザブランド、プラットフォーム、プラットフォームバージョンがそれぞれ1つのヘッダーを占め、サイトが必要に応じて問い合わせます。MDNのClient Hintsドキュメントはこれらのヘッダーの構造を明確に一覧化しています。

3つ目の経路はページスクリプトの中にあります。navigator.userAgentとnavigator.userAgentDataは、ページ内部からブラウザとプラットフォームの情報を再度報告します。理論上、3つの読み取り値は一字一句一致します。どれか1か所を変えても、他の2か所は追従しません。

UA変更プラグインはまさにこの点で引っかかります。多くのプラグインはヘッダー内のUA文字列だけを差し替えます。ページスクリプトが読むと元の値のままで、2つの経路がその場で食い違います。この矛盾を検出するのに高度な技術は不要です。リスク管理スクリプトは2か所の値を読みます。比較するだけで十分です。

前提も一つ確認しておきます。Chromeは旧UA文字列の情報を段階的に凍結しており、バージョン番号の後半はすでに固定されています。より細かい情報はClient Hintsへ移りつつあります。細工の余地は減っています。だからこそ、経路同士を揃えられるかがますます重要になっています。

UAの不一致で何が見えるか：4種類のシグナル

UA単体では真偽は分からず、シグナルの組み合わせに戻して初めて破綻が見えます。環境に問題があるときの不一致は、ほぼ次の4類型に収まります。

第1類、経路同士の矛盾です。ヘッダーはChrome 126と報告しているのに、ページスクリプトの読み取りはChrome 118のまま。あるいはSec-CH-UAで宣言したブランドが、navigator.userAgentDataの返す値と合わない。この読み取りの解釈は1つしかありません。UAが単独で改変され、その変更が全経路を覆っていないのです。

第2類、宣言とハードウェアの矛盾です。UAはiPhoneと書いているのに、画面は1920×1080のデスクトップ解像度でタッチ点数はゼロ。UAはWindowsと宣言しているのに、GPUレンダラーはApple製チップを報告する。ハードウェアパラメータは実環境から読み取った測定値であり、UAは自由に書き込める宣言値です。両者を突き合わせると、破綻はUA本体よりずっと目立ちます。この種の矛盾の原因については、指紋のランダム化がなぜ安全でないのかがパラメータ別に解説しています。

第3類、環境との組み合わせの矛盾です。出口IPは米国なのに、UAは中国語版ブラウザ。言語リストもタイムゾーンも別の地域に偏っている。UA、OS、言語、タイムゾーン、IPは本来、同じ地域プロフィールを描くはずです。1項目でもずれると、プロフィール全体が怪しくなります。この矛盾はUAの変更では解決できません。直すべきは環境設定です。

第4類、伝送層の特徴との不一致です。TLSハンドシェイクが残す特徴がスクリプトツール風、あるいはかなり古いブラウザ風なのに、リクエストヘッダーは新しいChromeを報告している。伝送層の特徴はUAより偽装が難しく、プラットフォームが両者の釣り合いを確認するコストは高くありません。

4類型のうち、最初の3つは環境設定の段階で回避できます。第4類は接続方式次第です。まずは3類からです。日頃の自己点検では最初の3類に注目し、読み取りの矛盾を見つけたら設定を遡って確認します。

一貫性チェックのやり方：5つの確認ポイント

点検は検出サイト任せにせず、5項目を順に通します。

1. 経路の照合：環境から検出ページを開き、開発者ツールのNetworkパネルでヘッダー内のUAとSec-CH-UAを確認します。次にコンソールのnavigator.userAgentの読み取り値と突き合わせ、3か所を一致させます。

2. ハードウェアの照合：UAが宣言するデバイス種別を、画面解像度、タッチ能力、GPUレンダラー、コア数、メモリと1項目ずつ照合します。宣言がどのデバイスなら、測定値もそのデバイスらしく見えることです。

3. 地域の照合：UAの言語、ブラウザの言語リスト、タイムゾーン、出口IPが同じ地域プロフィールの中に収まっているかを見ます。モバイルの宣言は、モバイルネットワークの特徴とも釣り合わせます。

4. バージョンの照合：UAのブラウザバージョンが対象市場の主流帯に収まっているかを確認します。最新すぎても数年前の旧版でも異常シグナルです。同時に、カーネルの挙動とも一致させます。

5. 再検査の記録：設定を変更したら検出ページをもう一度通し、毎回の読み取り値を記録として残します。環境に異常が出たとき、この記録が調査の出発点になります。

ツール面では、CreepJSがページスクリプトの読み取り値とブラウザの申告値の矛盾を集中的に収集します。UAを改変した環境で測ると、経路の矛盾をそのまま表示します。Browserscanのような総合検出サイトは、5項目のパラメータの全体読み取りに向いています。2種類のツールを組み合わせて使うのが得策です。UAは環境一貫性の中の1つのシグナルにすぎません。環境全体の点検順序については、アカウント関連付け防止の一貫性チェックの記事に6項目のチェック表があり、ここの5つの確認ポイントと併用できます。

指紋ブラウザでUAを揃える

5つの確認ポイントに沿って直すなら、最も効率が良いのはUAと関連パラメータをまとめて生成させる方法です。鍵は同時生成です。それぞれ手入力で埋める方式ではありません。MostMateは初心者に優しいAI指紋ブラウザで、アカウントごとに独立したブラウザ環境を用意します。UAの一貫性はまさにその環境設定フローの中に収まっています。作業の前に、MostMate製品紹介ページで作成フロー全体を一通り確認しておけます。

環境作成時はまずOSとブラウザバージョンを選び、User-Agentがそれに応じて生成されます。必要であれば編集も可能です。言語設定、タイムゾーン設定、地理位置情報の3項目は、初期値が「IPに基づく設定」になっています。出口プロキシを選ぶと、これらの項目とUAの地域の組み合わせは自動的に揃います。指紋プレビューパネルはUser-Agentと他のパラメータの現在値をリアルタイムで一覧表示します。環境を作る段階で設定全体の整合性を確認でき、稼働後に戻って直す手間がありません。

設定の粒度は自分で決めることもできます。手動の指紋設定では、UA、画面、タイムゾーン、言語など11項目を1つずつ選びます。一方、公式サイトトップのおすすめ設定は、デバイスの論理に沿って一貫した環境をまとめて生成します。2つの方法にはそれぞれ向き不向きがあります。

境界線について触れておきます。UAと環境設定の一貫性は、露出シグナルの1類を減らせるだけです。効果には限りがあります。アカウントがプラットフォームに関連付けられるかは、プラットフォームの規則、アカウント間の関係、利用行為にも左右されます。環境設定が解決するのは、そのうち環境という1層です。

よくある質問

UA変更プラグインを入れたのに、かえって識別されやすくなるのはなぜか？

プラグインは通常、リクエストヘッダーという1つの経路しか変えません。ページスクリプトとClient Hintsが読むのは元の値のままです。経路間に矛盾が生じると、「UAを変えた」という事実を読み取り値に書き込んでいるのと同じです。矛盾自体が異常シグナルであり、変えない場合より目立ちます。

UAのバージョン番号は新しければ新しいほど良いのか？

対象市場の主流バージョン帯に収まれば十分です。答えはシンプルです。最新版より新しくても、数年前の旧版のままでも異常シグナルです。バージョンはカーネルの挙動とも釣り合う必要があります。追新だけを狙う意味はありません。

デスクトップ環境でモバイルUAは使えるのか？

使えます。ただし画面解像度、タッチ能力、デバイスメモリなどのパラメータも、まとめてモバイルデバイスとして設定します。パラメータの連動については、画面解像度とウィンドウサイズの指紋で具体的な対応関係を解説しています。

検出サイトでUAが一致と出れば問題ないのか？

検出サイトの読み取りは、主にページスクリプトで読めるパラメータをカバーします。伝送層の特徴や一部のClient Hintsの細部は、読み取りに含まれない場合があります。5つの確認ポイントを通してから結論を出す方が確実です。

まとめ

UAチェックの着地点は、3つの経路と環境全体を互いに辻褄が合う状態にすることです。経路同士が矛盾せず、宣言とハードウェアの測定値が一致する。地域の組み合わせに筋が通る。バージョン帯も常識の範囲内にある。5つの確認ポイントを順に通せば、UA層の破綻の多くは環境公開前に潰せます。点検は公開前が最安です。

新しい環境では、アカウントを投入する前にこの点検を一通り済ませておく方が、認証が出てからUAを付け直すよりずっと手間がかかりません。この流れで環境を管理したい場合は、MostMateをダウンロードしてください。OSの選択、プロキシの設定から指紋プレビューの確認まで、UAと環境全体を一度で揃えられます。