デバイスフィンガープリントと IP インテリジェンス：両方が必要な理由

不正対策やトラストチームは、同じ議論を繰り返しています。デバイスフィンガープリントと IP インテリジェンス、どちらを導入すべきか、というものです。これは問いの立て方が間違っています。ある大規模サイトの実トラフィックでは、一意だったフィンガープリントは約 3 分の 1 にすぎず、数日のうちに変化し、アンチディテクトブラウザはそれを丸ごと偽装します。一方 IP は、サーバー側で最初のパケットとともに届き、API やボットのトラフィックを含むすべてのリクエストで取得でき、0〜100 の IP 不正スコアに集約されます。以下では、それぞれの層が何を見るのか、どこで失敗するのか、どう組み合わせるのかを説明します。

デバイスフィンガープリントとは実際には何か

デバイスフィンガープリントは、ブラウザが公開してもよいとする属性のハッシュです。スクリプトは、User-Agent、画面、インストール済みフォント、言語、タイムゾーン、ハードウェアのヒントに加えて、特定の GPU とドライバーが非表示の Canvas、WebGL シーン、オーディオバッファーを描画するときの微妙な違いを読み取ります。これらをまとめてハッシュ化すると、Cookie を消去してもプライベートウィンドウを使っても残る識別子が得られます。マシンに保存されているのではなく、マシンから導き出されているからです。

これにより、フィンガープリントには本物の強みが 3 つあります。

• 再訪したブラウザの認識。 セッション、ログイン、Cookie の消去をまたいで認識できます。
• 共有デバイスへのアカウントの紐付け。 これはマルチアカウント検出の中心的なキーです。
• 自動化を露呈する内部的な矛盾の発見。 iPhone を名乗る User-Agent にデスクトップ GPU の文字列がある、ヘッドレスブラウザの画面サイズがあり得ない値になっている、リクエストのたびにフィンガープリントが変わる、といったものです。

こうした用途であれば、強力なシグナルです。問題が起きるのは、チームがフィンガープリントを確率ではなく ID として扱ったときです。

フィンガープリントの正直な限界 3 つ

フィンガープリントは 3 つの点で失敗します。規模が大きくなると衝突し、時間とともに変化し、不正ツール、ブラウザ、規制当局から攻撃を受けています。

規模が大きくなると、有名な研究が示唆したほど一意ではありません。 プライバシーを重視するボランティアを対象にした初期の研究では、80% を超えるブラウザが一意に識別できると報告されました。ところが、研究者がフランスの上位 15 サイトの 1 つから得た 2,067,942 件のフィンガープリント、つまりプライバシーテストを自ら求めた人ではなく通常のトラフィックを分析したところ、一意だったのは 33.6% のみで、モバイルでは 18.5% にまで下がりました（Hiding in the Crowd, WWW 2018）。同じ機種のスマートフォンを同じデフォルトのフォントで使っている人が何百万人もいるので、実トラフィックではほとんどのフィンガープリントが衝突します。

時間とともに変化します。 ブラウザは自動更新され、フォントはインストールされ、ディスプレイは接続されます。1,905 個のブラウザインスタンスから得た 98,598 件のフィンガープリントに基づく FP-STALKER の研究では、フィンガープリントが「数時間から数日ごとに」頻繁に変わることがわかりました（FP-STALKER, IEEE S&P 2018）。著者らの紐付け手法でも、ブラウザを平均 54.48 日間追跡でき、26% は 100 日超追跡できました。これは印象的な研究であると同時に警告でもあります。単純なハッシュ比較のシステムは、数日のうちに同じ顧客を他人として扱ってしまいます。

3 つの方向から攻撃を受けています。 不正グループは意図的に偽装します。アカウント量産業者の標準的な道具であるアンチディテクトブラウザは、プロファイルごとに内部的に一貫した新しいフィンガープリントを生成します。ブラウザは意図的に精度を落とします。Safari は Canvas やウェブオーディオなどの API から、既知のフィンガープリント用スクリプトが読み取れる内容を制限しており、Firefox も同じシグナルの多くをぼかすフィンガープリント保護を搭載しています。そして規制当局はそれをトラッキングとして扱います。EU の第 29 条作業部会は意見書 9/2014 で、e プライバシーの同意要件がデバイスフィンガープリントにも適用されると結論づけました。2024 年 12 月 19 日には、英国 ICO が、広告目的でフィンガープリントを許可する Google の動きを「無責任」と呼びました。セキュリティと不正防止は広告より法的根拠が強固ですが、論点は現実に存在します。

こうした事情があっても、フィンガープリントが無用になるわけではありません。確率的な入力の 1 つであり、それを裏付けたり否定したりする、独立した 2 つ目の層が必要だということです。

フィンガープリントには見えず、IP インテリジェンスには見えるもの

IP インテリジェンスは、リクエストが通ってきたネットワークを記述するもので、JavaScript が実行される前に動作します。アドレスは、API 呼び出し、Webhook、フィンガープリント用コードを実行しないヘッドレススクリプトを含むすべてのリクエストの最初のパケットとともに届きます。付加情報で補完すると、ブラウザが自分自身については決して答えられない問いに答えられます（フィールドごとの詳細はIP インテリジェンスとはにあります）。

• これはどんな種類のネットワークか。 asn.connection_type は、住宅用やモバイルのアクセスをデータセンターやホスティングから区別します。クラウドインスタンスからの一般消費者向けチェックアウトは、そうでないと証明されるまではスクリプトであり、フィンガープリントにはそれを知る術がありません。
• 接続は匿名化されているか。 detection.is_vpn、is_proxy、is_tor、is_relay と、anonymity_level です。その仕組みはVPN とプロキシの検出の仕組みで解説しています。
• 誰がそのネットワークを運用しているか。 ASN と組織です。「1 つのホスティングプロバイダーから新規アカウントが 40 件」が見えるようになるのは、これのおかげです。
• どこにあり、それは他のすべてと一致しているか。 geo_confidence 付きの国と都市、わかっている場合は IANA の timezone です。
• このアドレスに履歴はあるか。 スパム、スキャン、ボットネットのフラグと、threat.dnsbl_sources にある DNS ブロックリストへの掲載です。
• 共有されているか。 threat.is_cgnat は、1 つのアドレスが実際には数千人である、キャリアグレード NAT を示します。こうしたアドレスのスコアには上限 50 が設けられています。

特に重要な性質が 2 つあります。IP インテリジェンスはサーバー側で普遍的であり、フィンガープリントが見えないトラフィックまで網羅します。そしてクライアントからは偽装しにくいものです。リクエストはどこかから来なければならず、データセンターや既知の VPN サーバーはそのようなものとして現れます。注意点が 1 つ、あなた側にあります。偽装可能な転送ヘッダーではなく、信頼できるプロキシチェーンから得た実際のクライアント IP をスコア化してください。

IP インテリジェンス単独でできないこと

IP アドレスでは、同じ CGNAT アドレス、オフィスのゲートウェイ、キャンパスネットワークの背後にいる 2 人の顧客を区別できません。同じノート PC が自宅の Wi-Fi からスマートフォンのテザリングに移っても、それを認識できず、モバイルのアドレスは絶えず入れ替わります。

最も難しいギャップはレジデンシャルプロキシです。実際の家庭の回線に出口を借りる不正グループは、普通の家庭のユーザーに見えるトラフィックを送り、IP データではほとんど見えません。当社はレジデンシャルプロキシを検出しておらず、IP ルックアップだけをそれに対する唯一の防御にすべきではありません。ここでこそフィンガープリントの出番です。同じアンチディテクトのプロファイルが多数の「家庭」のアドレスにまたがって再び現れるのは、ネットワーク層ではなくデバイス層のパターンです。つまり、IP インテリジェンスだけでは「これは先週信頼したデバイスか」という問いに答えられず、これこそフィンガープリントが答えるために存在する問いです。

問いごとに見る：どの層が答えるか

それぞれの層は、もう一方が答えられない問いに答えます。次の表で、その分担を明確にします。

列を並べて読むと、片方の層が「いいえ」であるほぼすべての行で、もう片方が「はい」になっています。

同じ信頼済みフィンガープリント、2 つのネットワーク：2026 年 10 月 20 日に確認したこと

ネットワーク層は、1 つの信頼済みフィンガープリントを、どこから到達するかに応じて block にも allow にも変えます。数か月にわたって信頼してきたブラウザが、以下のそれぞれのアドレスから 1 回ずつ到達する場面を想像してください。2026 年 10 月 20 日の UTC 04:34 に iCloud Private Relay の出口 104.28.46.99 を、04:35 に Mullvad サーバー 185.213.155.73 を、API キーなしでルックアップしました。結果は範囲の変化に応じて変わります。

フランクフルトの Mullvad サーバーは次のように返ってきました。省略していますが、値は変更していません。

Cloudflare のネットワーク上にあるリレーの出口は、次のように返ってきました。

Mullvad のアドレスは最大値の 100 で、detection_methods がその理由を示しています。このアドレスは Mullvad 自身が公開しているサーバーリストに載っており、vpn_provider: "Mullvad" と vpn_confidence: 95 はそこから来ています。そのリストでは WireGuard サーバーとしてタグ付けされています。そこから信頼済みのフィンガープリントが到達するのは、「匿名化されたネットワーク上の既知のデバイス」という矛盾にあたるので、デバイスの履歴がクリーンでも追加の認証を求めてください。Private Relay のアドレスは 9 で、方法は relay_ip だけです。Apple のリレーはプロキシではなく一般消費者向けのプライバシー機能であり、スコアはリレーのアドレスに上限 60 を設けているため、Private Relay の IP が block に達することはありません。その背後に長く信頼されてきたフィンガープリントがあるなら、トラフィックとしてはほぼ最も安全な部類です。

同じ実行から得た 2 件のルックアップを加えると、全体像が完成します。

スコア 10 のごく普通のクラウドサーバーは、よい注意喚起になります。ホスティングであること自体は不正ではありません。信頼済みのフィンガープリントがクラウドのボックスから到達した場合は、ブロックではなく、確認に値します。

タイムゾーンの確認では、2 つの点が重要です。Mullvad サーバーは Europe/Berlin を報告するので、そのアドレスでブラウザの時計がニューヨークに設定されていれば、明白な矛盾です。Linode サーバーの geo.timezone は "none" で返ってきたため、そのアドレスではタイムゾーンの比較に使える相手がありません。さらにリレーの出口はアンゴラのルアンダにジオロケーションされていますが、10 月 12 日に確認した時点では、Apple 自身の出口リストはその範囲をザンビアのルサカとしていました。ブラウザの時計がリレーの位置と一致しないのは想定内であり、プロキシの兆候として数えるべきではありません。

ネットワークの判定は期限切れになるため、ルックアップ時刻を保存する

IP の判定は、ある瞬間に取った読み取り値であり、当社自身のサンプルがそれを証明しました。この記事の以前のバージョンでは、VPN の例として 102.129.235.17 を使っていました。2026 年 10 月 5 日にも 16 日にも、fraud_score 92、block で、known_vpn_server、openvpn_open、ipsec_open が返りました。ところが 10 月 20 日の UTC 04:34 と 04:35 には、fraud_score 0、allow、is_vpn: false、空の detection_methods が返りました。このアドレスが VPN ネットワークから外れたのか、当社のスキャンがそれを検出しなくなったのかは、確認できていません。

いずれにしても、ルックアップの時刻、スコア、方法をフィンガープリント ID と並べて保存し、先月の判定を信頼するのではなく、次の重要な操作で IP を再スコアしてください。フィンガープリントは数日のうちに変化しますが、この IP の判定も 4 日のうちに block から allow に変わりました。

組み合わせの効果：両方を使うには

2 つの層を併用すると、両者が食い違うところで効果を発揮します。それを判断に変える 6 つのルールがあります。

矛盾を探す。 数か月信頼してきたフィンガープリントが、突然別の大陸のデータセンター VPN から到達するのは、セッションの乗っ取り、アカウントの共有、あるいはボットの前段にあるプロキシです。前日に信頼済みのデバイスが使った同じ住宅用 IP に、まったく新しいフィンガープリントが現れるのは、ほぼ間違いなく世帯内の新しいスマートフォンです。同じフィンガープリントで、1 時間のうちに 2 つの IP 間を移動するのが不可能な場合は、盗まれたセッションか、借りた出口です。

ブラウザの時計とネットワークの時計を比較する。 フィンガープリントはブラウザのタイムゾーンを、IP インテリジェンスはネットワークのタイムゾーンを報告します。Europe/Berlin の IP にニューヨーク時間があるのは、最も古いプロキシの兆候の 1 つで、必要なのは文字列を 1 回比較することだけです。timezone が "none" の場合や、アドレスがリレーの場合は、このチェックを省きます。

ネットワークでフィンガープリントの衝突を解消する。 同一の 2 つのフィンガープリント（同じ機種、同じ OS、同じデフォルト設定）は、IP が別々の都市の異なる住宅用ネットワークにあるなら、別々の 2 人です。「変わった」フィンガープリントが同じ IPv6 /64 と ASN から到達し続けているなら、おそらくブラウザ更新後の同一人物です。

それぞれの層が、もう一方の見えないトラフィックを補う。 JavaScript が動くブラウザセッションではフィンガープリントを取得し、IP はすべてのトラフィックでスコア化します。

両方で独立にクラスタリングする。 マルチアカウントやプロモーション悪用では、共有されたフィンガープリントと共有されたネットワークは、独立した 2 系統の証拠です。共有キーが 1 つなら世帯か CGNAT のブロックですが、独立した共有キーが 2 つあれば、レビューに値する不正グループの仮説です。

スコア化してから、追加認証に進む。 フィンガープリントは継続性として（「既知のデバイス」はリスクを下げ、「既知の不正デバイス」は上げる）、IP はコンテキストとして取り込みます。そのうえで、スコアがすでに使っている 4 つの帯に従って対応します。アクション別の不正スコアしきい値にあるとおり、25 以下が allow、50 までが review、75 までが step_up、75 超が block です。矛盾が review に入り、アナリストが手作業で確認する必要がある場合は、IP アドレスの調査方法にあるインシデントごとの手順に従ってください。

実装チェックリスト

次の 6 つの構築ステップで、これらのルールを実際に動く結合処理にできます。

1. ログイン、サインアップ、チェックアウト、出金の時点でフィンガープリントを取得し、その ID をリクエストとともに記録する。
2. 実際のクライアント IP をサーバー側でルックアップし、detection フラグ、ASN、geo.timezone、is_cgnat、fraud_score、detection_methods を保持する。
3. 両方をタイムスタンプ付きでセッションとアカウントに紐付けて保存し、今日の組み合わせを先月のものと比較できるようにする。
4. まず矛盾のルールを書く：VPN、Tor、データセンターのネットワーク上の既知のデバイス、タイムゾーンの不一致、あり得ない移動、信頼済みネットワーク上の新しいデバイス。
5. CGNAT とモバイルキャリアのアドレスでは重みを弱める。見慣れたネットワーク上でフィンガープリントが変わっただけでは、それ自体は危険信号ではない。
6. フィンガープリントを取得する理由を文書化し、対象地域における同意の扱いを確認する。

1 回のルックアップで得られる IP 側の情報

IP 側に必要なものはすべて 1 回の GET リクエストで返ってきます。説明可能な 0〜100 の不正スコアには、recommended_action と作動した方法が付属します。さらに免責シグナルも適用され、住宅用 ISP は 17 点、検証済みクローラーは 28.5 点を差し引きます。すべてのフィールドは、1 日 1,500 回のルックアップまでの無料プランで利用できます。フィンガープリントのテーブルとの結合を書く前に、API キーなしで任意の IP をルックアップすることもできます。

どの層を買うか、という問いはやめる

この組み合わせは、マルチアカウントのグループからクーポンの悪用まで、このクラスター全体に現れます。そして、実在の顧客をブロックせずに匿名化トラフィックを検出するための方法でもあります。スコア 9 の Private Relay の背後にある信頼済みフィンガープリントは、スコア 100 の VPN 上の新規のものよりも、軽い対応で済ませるべきだからです。各スコアの背後にある理由を見れば、どのネットワークシグナルがスコアを動かしたかがわかります。ですから、層を選ぶのではなく、どの問いに答えを出したいのかを考えてください。そうすれば、両方が必要だとわかるはずです。

よくある質問

デバイスフィンガープリントとは何ですか？

デバイスフィンガープリント（ブラウザフィンガープリントとも）は、ブラウザが公開する数十の属性を収集し、ハッシュ化して識別子にします。属性には、User-Agent、画面サイズ、インストール済みフォント、タイムゾーン、言語、ハードウェアの詳細、そしてデバイスが Canvas、WebGL、音声をどう描画・処理するかなどがあります。Cookie を必要としないため、セッションをまたいで再訪したブラウザを認識し、複数のアカウントを 1 台のデバイスに結び付けられます。クライアント側で動作するので、スクリプトが実行されるトラフィックしか見えません。

デバイスフィンガープリントは正確ですか？

初期の研究が示唆したほどではありません。フランスの上位 15 サイトの 1 つから得た 2,067,942 件のフィンガープリントを分析した 2018 年の研究では、一意だったのは 33.6%（モバイルでは 18.5%）にとどまりました。プライバシーを重視するボランティアを対象にした以前の研究では 80% 超でした。フィンガープリントは時間とともに変化もします。FP-STALKER の研究では、数時間から数日ごとに変わることがわかりましたが、その紐付け手法でも平均 54.48 日間ブラウザを追跡できました。フィンガープリントは、安定した ID ではなく、確率的な認識シグナルとして扱ってください。

IP インテリジェンスはデバイスフィンガープリントの代わりになりますか？

なりません。逆もまた同じです。IP インテリジェンスが見るのはネットワークです。接続タイプ、ホスティングか住宅用かという出所、VPN、プロキシ、Tor、リレーの利用、ASN、ジオロケーション、悪用の履歴などです。サーバー側で最初のリクエストから動作し、スクリプトが動かない API トラフィックにも使えます。しかし、1 つのキャリアグレード NAT アドレスの背後にいる 2 つの世帯は区別できず、レジデンシャルプロキシ経由のトラフィックは普通の家庭のユーザーに見えます。フィンガープリントがそのギャップを埋め、IP インテリジェンスがフィンガープリントの死角を埋めます。

デバイスフィンガープリントと IP シグナルを組み合わせる最良の方法は何ですか？

フィンガープリントは継続性のシグナル（このブラウザを見たことがあるか）、IP はコンテキストとリスクのシグナル（どのネットワークにいて、匿名化されているか）として扱い、そのうえで矛盾を探します。既知のフィンガープリントが別の大陸のデータセンター VPN から到達するのは、乗っ取りまたはプロキシのパターンです。信頼済みの同じ住宅用 IP に新しいフィンガープリントが現れるのは、たいてい世帯内の新しいデバイスです。ブラウザが報告するタイムゾーンと IP のタイムゾーンを比較し、マルチアカウントを追う際には、両方を独立したクラスタリングキーとして使います。

デバイスフィンガープリントは合法ですか？

EU と英国では、トラッキングとして規制されています。第 29 条作業部会は意見書 9/2014 で、ユーザーのデバイス上の情報にアクセスする際の e プライバシー指令の同意ルールがフィンガープリントにも適用されると結論づけました。例外は、ユーザーが要求したサービスの提供に厳密に必要なものに限られます。不正防止は広告よりも根拠が強固ですが、コンプライアンス上の論点は現実にあります。2024 年 12 月 19 日、英国 ICO は、広告目的でのフィンガープリントを許可する Google の決定を「無責任」と呼びました。目的を明確にしてフィンガープリントを行い、その目的を文書化し、対象地域については法務の助言を受けてください。