> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# ブラウザフィンガープリンティング

> Bot対策システムは、canvas・WebGL・フォント・UA、その他数十の信号の組み合わせからスクレイパーを識別する。何が追跡され、スクレイパーが何を漏らし、どう管理するかを解説します。

どのブラウザセッションも、識別可能な署名を漏らします — user-agent、canvasの描画出力、WebGLレンダラ文字列、フォントリスト、画面解像度、インストールされたプラグイン、タイムゾーン、言語ヘッダ、オーディオコンテキストの出力など、その組み合わせです。最近のBot対策システムは、これらの信号を**ブラウザフィンガープリント**にまとめ上げ、IPアドレスより遥かに確実にセッションを識別します。指紋を管理しないスクレイパーは、検知層にきれいなIDバッジをリクエストのたびに渡しているのと同じです。

指紋の層は[行動](/docs/jp/academy/human-like-scraping)の下にあります — セッションが*何をするか*ではなく、*何であるか*です。本気のBot対策に対しては、スクレイパーは両方の層を通過する必要があります — 綺麗な指紋*かつ*人間らしい振る舞い。

## 追跡される信号

最近の指紋は通常、次のような信号を組み合わせます:

* **User-agentとaccept系ヘッダ**。最も分かりやすい出発点。UAに`HeadlessChrome`が入っていれば一発でバレます。
* **Canvasフィンガープリント**。サイトはブラウザに隠しcanvas要素を描画させ、その出力をハッシュ化します;GPU・ドライバ・OSの組み合わせによる微細な描画差が、マシンごとに安定した署名を生み出します。
* **WebGLフィンガープリント**。レンダラ文字列、ベンダー文字列、サポート拡張機能 — まとめてGPUとドライバスタックの強力な指紋になります。
* **フォントリスト**。ブラウザがレンダリングできるフォントとその順序 — それだけでセッションを識別できることも多いです。
* **画面とビューポート**。解像度、色深度、デバイスピクセル比。200%スケールの`1366×768`デスクトップと`2560×1440`のRetinaディスプレイは、別の指紋です。
* **タイムゾーンと言語**。`Intl.DateTimeFormat`と`navigator.languages`から取得されます。
* **オーディオコンテキスト**。オーディオのレンダリングはcanvasと同様、デバイス固有の指紋化可能な出力を生み出します。
* **プラグイン、navigatorのプロパティ、ハードウェア並列度**。単体では小さいが、組み合わせで効く信号。
* **`navigator.webdriver`**。管理されていない自動化に対する決定的な手がかり。

これらの小さな信号が掛け算で効きます。サイトはそれぞれが一意である必要はなく、*組み合わせ*が追跡できる程度に一意であれば充分です。

## なぜスクレイパーは指紋を漏らすのか

支配的な3つの失敗パターン:

* **同じ既定アイデンティティを繰り返す**。素のPuppeteerインスタンスが1万セッション動けば、1万の「異なるユーザー」が同じcanvasハッシュ・同じWebGL文字列・同じフォントリストを共有します。簡単に検知されます。
* **どんな実際のユーザーも生み出さない一般的すぎる値**。空の`navigator.plugins`、Linux/Chromeの標準レンダリングそのままのビット単位で同一のcanvas出力、よくあるシステムフォントが欠けたフォントリスト — これらは実際のChromeユーザーが生み出さない異常値です。
* **信号間の矛盾**。`en-US`と`America/New_York`を主張する指紋がロシアのIPとペア。iPhoneのUAがデスクトップのビューポートと組み合わさる。WindowsのフィンガープリントにmacOS専用フォント。検知層は内部矛盾を探します。

## 指紋を管理する

対策は失敗パターンと一対一で対応します:

* **セッションごとの一意性**。各タスクのインスタンスは異なる指紋を提示する必要があります — 異なるcanvasハッシュ、異なるWebGLレンダラ、異なるフォントリスト — そうしないと、サイトから見て「異なるユーザー数千人」が同じブラウザ指紋を共有しているように映ります。
* **セッション内の一貫性**。1つのセッションの中では指紋は安定していなければなりません;セッションの途中で切り替わることそれ自体がしるしになります。
* **IPとの地理的整合性**。指紋のタイムゾーン、言語、accept-languageヘッダは[プロキシIPの](/docs/jp/academy/rotating-proxies)地理と合っているべきです。東欧のIPには東欧の指紋を、`en-US`の既定値をペアにしないこと。
* **ランダムではなく、リアル**。純粋なランダム値から組み立てた指紋は、それ自体が異常です。正しいやり方は、実在の指紋の分布から引く — よくあるGPU文字列、もっともらしいフォントリスト、普通の画面サイズ — 誰も使っていない奇異な値ではなく。

これらの原則をまとめたものが、実行環境が出荷時に持っている既定値に頼るのではなく**主動的に指紋を管理する**というアプローチです。

## Octoparseのアプローチ

[設計としてヘッド付きの実行環境](/docs/jp/academy/headed-vs-headless-browsers)がヘッドレスツールより漏らす信号が少ないという既定の優位性に加えて、Octoparseはブラウザ指紋を主動的に管理します。タスクごとに同じ既定アイデンティティを繰り返すのではなく、セッションは個別のリアルな指紋プロファイルを持って提示されます — 固定の指紋設定では満たせない「セッションごとの一意性」の要件に対応します。実行環境は、ヘッド付きから得られる「受動的な」ステルスと、指紋の多様性から得られる「主動的な」ステルスの両方を扱い、ユーザーが外部の指紋サービスを配線する必要はありません。

指紋管理はOctoparseの[行動シミュレーション](/docs/jp/academy/human-like-scraping)と組み合わさります — 実行環境はセッションごとに異なるリアルなユーザーに見え、ページ上では実際にそのように振る舞います。

## いつ効くのか

主動的な指紋管理は静的サイトや基本的なBot検知に対してはやりすぎです。本領を発揮するのは重い防御に対してです:

* **軽い防御**。ヘッド付き既定でカバーできます。
* **中程度の防御(レート制限 + 基本検知)**。他の層が綺麗なら、既定でだいたい足ります。
* **重い防御(Cloudflare、DataDome、HUMAN、Akamai Bot Manager)**。必須。セッションごとに区別された現実的な指紋がなければ、「異なるユーザー数千人」に同じアイデンティティが繰り返されることで、他のすべてが綺麗でもスクレイパーはBANされます。

指紋ステルスの行動側のもう一方については[人間らしいスクレイピング](/docs/jp/academy/human-like-scraping)、指紋管理が突破しようとする具体的な防御システムについては[CAPTCHAとCloudflareの突破](/docs/jp/academy/captcha-and-cloudflare)を参照してください。