デバイスフィンガープリントとは｜不正検知SaaSの比較とDBSC・クロスデバイスの可否

01.結論：推定で識別するSaaSと、鍵で証明するDBSC

「デバイス認証のフィンガープリントで、最近よく聞くもの」を整理すると、性格の違う2つが混ざっています。ひとつは、Cookieに頼らず端末を見分けるためのデバイスフィンガープリントと、それをSaaSにした製品群（Fingerprint、Stytch、SEON、DataDomeなど）。もうひとつは、ブラウザ側でセッションを端末に縛りつける新しい標準DBSCです。

この2つは「端末を手がかりにする」点は同じでも、やっていることは正反対です。フィンガープリントは、送られてくる特徴から「たぶん同じ端末だ」と推定します。DBSCは、端末内の秘密鍵で署名させて「確かにこの端末だ」と証明します。推定は匿名のまま使えて広く効く代わりに外れることがあり、証明は確実な代わりにログイン後の正規セッションが前提です。だから競合ではなく、守る場所が違う道具として併用するのが筋になります。

02.デバイスフィンガープリントとは

デバイスフィンガープリント（端末の指紋）とは、ブラウザ・OS・ハードウェア・ネットワークなどから得られる多数の属性を組み合わせて、端末ごとに固有の識別子を作る技術です。集める属性には、画面解像度、インストール済みフォント、タイムゾーン、言語設定、描画結果（Canvas/WebGL）、TLSの構成、IPやリクエストヘッダーなどが含まれます。これらを束ねてハッシュ化すると、Cookieを使わなくても「同じ端末らしさ」を表す値が得られます。

IP・ブラウザ・OS・画面解像度・タイムゾーンなど、自分の端末がどんな属性を出しているかは、当サイトの無料ツールでその場で確認できます。

Cookieとの一番の違いは、利用者側で消しにくい点です。Cookieは削除でき、シークレットウィンドウでは共有されませんが、フィンガープリントは端末の特徴そのものから計算するため、シークレットモードやCookie削除、VPN経由でも比較的安定します。この「消されても追える」性質が、不正検知で重宝される理由です。

ただし万能ではありません。ブラウザやOSのアップデート、端末設定の変更で属性が変わると、同じ端末でも識別子がずれて精度が落ちます。逆に、同一機種で初期設定のままの端末同士は似たフィンガープリントになり、別端末を取り違えることもあります。プライバシー規制やブラウザ側の対策（属性のランダム化など）とのいたちごっこもあり、「確実なID」ではなく「確からしさの高い手がかり」として扱うのが前提です。

03.何に使うのか

フィンガープリントは、ログインの前後どちらでも「端末を手がかりにしたリスク判定」に使われます。代表的な用途は次の4つです。

いずれも「端末が信用できるか」を、パスワードや本人確認とは別の角度から補う使い方です。特にATO対策では、正しいパスワードでログインしてきても端末が初見なら追加認証を挟む、といった出し分けに使えます。

ただし、多重登録・リセマラやアフィリエイト不正で攻撃者が複数の実機を使う場合は、端末の識別だけでは防ぎきれません。再インストールやエミュレータといった安価な手口は端末識別で多くを止められますが、実機を並べる手口には、電話番号認証や本人確認のような1人あたり量を増やしにくい手段と組み合わせる前提で設計します。フィンガープリントは「安い不正を刈り取る一層」と位置づけるのが現実的です。

04.主要SaaSの比較

フィンガープリントは自前実装もできますが、精度の維持・不正端末リストの更新・ボット判定までを内製し続けるのは負担が大きく、専用SaaSに任せる構成が多くなります。主要な4サービスを、狙いと識別の考え方で並べます。

立ち位置を言葉にすると、純粋な端末識別の精度を求めるならFingerprint、ログイン基盤ごと不正対策を入れたいならStytch、申込・取引のリスクを人物単位で広く見たいならSEON、ボットやスクレイピングの遮断が主目的ならDataDome、という整理になります。このほか、端末識別に特化したTrustDevice（TrustDecision）などの選択肢もあります。

05.OSSのFingerprintJSと商用版の違い

「Fingerprint」をSaaSとして思い出す人が多い一方で、入り口になっているのはオープンソースの FingerprintJS です。両者は名前が近いので混同しやすいですが、できることが違います。

まず手元で試すなら OSS版で十分です。ただし、ブラウザ内だけで完結する分、なりすましや偽装に弱く、精度も商用版に届きません。本番の不正検知に乗せる段階では、サーバ側で精度を担保する商用版やSmart Signalsが必要になる、と考えておくと判断を誤りません。Fingerprintは月10億件超のデバイス識別を扱う規模に達したと公表しており、エンタープライズでの採用が広がっています。

06.最新標準DBSCとの対比

「最新のデバイス認証っぽい機能」としてもうひとつ外せないのが、DBSC（Device Bound Session Credentials）です。Googleが進める標準で、ログイン時に端末ごとの鍵ペアを生成し、秘密鍵をTPM（Windows）やSecure Enclave（macOS）などのセキュアなハードウェアに保存します。以降のセッションは、その鍵で署名できることを条件にするため、セッションCookieを盗まれても別の端末では使えなくなります。

2026年4月以降、Chromeのバージョン146でWindows向けに一般提供（GA）が始まり、Origin Trial（試験提供）の段階を終えました。macOSはSecure Enclaveを使った対応が予定されています。仕様自体は W3C WebAppSec でドラフトが進んでおり、今後はフェデレーテッドID（クロスオリジンの紐付け）や、mTLS証明書・セキュリティキーとの結合、TPM非搭載端末向けのソフトウェア鍵への拡張がロードマップに挙がっています。

フィンガープリントとの違いははっきりしています。フィンガープリントは匿名のまま推定で端末を見分けるのに対し、DBSCはログイン済みの正規セッションを鍵で証明して守る。前者は「怪しい端末を見つける」攻めの側、後者は「正規セッションを盗ませない」守りの側です。どちらか一方ではなく、両方を別レイヤーで持つのが、いまの乗っ取り対策の形になりつつあります。

07.クロスデバイスはできるのか

ここがよくある誤解です。「1つのIDで、同じ人のスマホとPCをまたいで同一人物だと自動判定する」という意味でのクロスデバイスは、フィンガープリントSaaS単体ではできません。フィンガープリントが返すのは、あくまで端末1台ごとの識別子だからです。同じ人がスマホとPCで来れば、別々の識別子になります。

得意なのは縦方向、つまり「同じ1台」をセッションやIP変更、VPN、シークレットモードをまたいで安定して追うことです。逆に横方向、「別々の端末を同一人物に束ねる」名寄せは設計上の範囲外です。では、クロスデバイス的なことをやりたい場合はどうするか。答えは「自分側で束ねる」です。

つまり、ログインを前提に、アカウントへ端末を紐付けてリスク判定する形なら可能です。一方で、ログインなしで匿名のまま複数端末を同一人物として横断追跡したい場合は、フィンガープリントだけでは足りず、アイデンティティグラフ系の別の仕組みが必要になります。SEONのようにメールや電話のデジタルフットプリントを併用する製品は、この横方向の補強に寄っています。

08.導入時に注意すること

フィンガープリントは強力な分、扱いに注意が要ります。PoCで検知できたことを、そのまま本番の安全性の根拠にはできません。導入前に次の点を決めておくと、後の事故を防げます。

09.FAQ

10.まとめ

「デバイス認証のフィンガープリントで最新のもの」は、性格の違う2つに分かれます。推定で端末を識別するフィンガープリントSaaS（Fingerprint、Stytch、SEON、DataDomeなど）と、鍵でセッションを証明する新標準DBSCです。両者は競合ではなく、守る場所が違う道具として併用するのが基本になります。クロスデバイスは、ログイン前提でアカウントに端末を紐付ければ擬似的に実現でき、匿名横断には別の仕組みが要ります。まずは自社のトラフィックで誤検知と検知率を測り、止め方と救済の設計を固めてから道具を選ぶ順序をおすすめします。

とはいえ、フィンガープリント・DBSC・パスキーをどう組み合わせ、どこに人の確認を挟むかは、自社の業務やリスク許容度によって変わります。判断軸の整理から実装方針までを、現場で動く形に落とし込むところでつまずきやすいポイントです。