IPを変えてもPixelscanに見破られる理由。鍵は環境の一貫性

複数アカウント運用をしていると、誰もが同じ場面に直面します。プロキシを変えてCookieも消したのに、検出サイトを開くとまだ赤いフラグ。「変え方が足りない」のではなく、環境の内部で矛盾が起きているのが大半の原因です。プロキシはニューヨークと言っているのに、パソコンの時計はベルリン時間で動いている——。Pixelscanに代表される新世代の検出サービスが見ているのは、あなたが何を変えたかではなく、主張するアイデンティティとデバイスの実際の振る舞いが一致するかどうかです。本記事では最も多い4つの矛盾点を分解し、今日から使えるチェックリストをお届けします。

Pixelscanが実際に測っているもの：特徴から矛盾へ

Pixelscanの中核ロジックは一貫性の監査です。ブラウザ環境を相互に裏付け合うシグナルの集合と捉え、論理的に衝突する項目が一つでもあれば、アイデンティティ全体が偽装と判定されます。

初期の検出エンジンは「悪い特徴」を探す方式でした。既知の自動化スクリプトの特徴や古いパラメータの組み合わせをスキャンし、値を新しく差し替えればすり抜けられました。しかし今は違います。検出エンジンはネットワークのシグナル、ハードウェアの制約、レンダリングの振る舞いを一枚のマトリクスで相互検証します。単体ではどの値も普通に見えるのに、組み合わせると数学的に矛盾する——それが偽装の証明になります。

同系統のツールは役割分担が異なります。開発者向けのCreepJSはAPI改ざんの痕跡を深掘りし、Pixelscanは全体の一貫性スコアに重点を置き、多くのリスク対策チームが基準として参照しています。マルチアカウント運用者への示唆は単純明快です。パラメータには何でも入力できますが、パラメータ同士の関係は偽装できません。

IPを変えてもフラグが立つ：最も多い4つの矛盾点

この4点が「全部設定したのにフラグが立つ」ケースの大半をカバーします。順番に照らし合わせれば、たいてい原因を特定できます。

1. タイムゾーンと地理位置情報が一致しない。トラフィックはニューヨークのプロキシ（UTC-5）から出ているのに、マシンの時計はベルリン時間（UTC+1）。これは最も古典的で初歩的な破綻です。検出スクリプトはgetTimezoneOffset一発でシステムの実タイムゾーンを取得し、それをシステム言語、Geolocation API、プロキシの所属ネットワーク（ASN）と突き合わせます。主張する位置がハードウェアの実際の位置から遠すぎれば、フラグは即座に立ちます。

2. フォントのレンダリングがOSを暴く。macOSのUser-AgentをWindowsマシンに貼り付けるのは、最も多い手作業のミスです。検出エンジンはブラウザに画面外のCanvasで隠しテキストをレンダリングさせ、生成されたピクセルグリッドを分析します。WindowsはDirectWrite、AppleはCore Text、LinuxはFreeTypeを使い、それぞれのサブピクセル配列は各カーネルに組み込まれた数学的特徴です。文字列を変えても、C++レベルのフォント計測は欺けません。

3. WebGLが「偽物のノートPC」を露呈する。クラウドフォンやGPUなしの仮想サーバーは、多くの場合SwiftShaderのようなソフトウェアラスタライザで描画しています。環境がMacBook Airだと自称しているのに、診断ではソフトウェアレンダリングのベンダー情報が読み取れる——矛盾はその場で確定します。一般消費者向けのノートPCが、サーバー向けの代替手段で3Dインターフェースを描くことはないからです。

4. WebRTCがプロキシを迂回して実アドレスを漏らす。Webページの通信はプロキシのトンネルを通りますが、音声通話向けに設計されたピアツーピアプロトコルのWebRTCは別の経路を開きます。検出側がICE接続を一度要求するだけで、ローカルまたはISPの実IPが取れることがあり、Pixelscanはその漏れたアドレスをプロキシIPと照合します。2つのアドレスが食い違えば、プロキシは一枚貫ければ破れる障子にすぎません。一言でまとめるなら、環境の信頼性は、最も弱い矛盾シグナルの水準で決まるのです。

頻出の3つの落とし穴。多くの人が2番目でつまずく

どれも「手作業」に起因します。ツールの能力ではなく、組み立て方の問題です。

1. User-Agentのコピペ。チュートリアルから拾ったmacOSのUAをWindowsホストに貼る。文字列は変わってもレンダリングの振る舞いは変わらず、偽装を自ら申告しているのと同じです。

2. プロキシだけ管理してシステムを放置。プロキシはロサンゼルスを買ったのに、システムのタイムゾーン、言語、数値フォーマットはローカルのまま。どの項目もプロキシに反対票を投じています。

3. クラウドフォンやGPUなし環境で高価値アカウントを運用。ソフトウェアレンダリングの特徴はWebGLの読み取り値に書かれています。テストなら構いませんが、既知の矛盾を長期運用のアカウントに抱え続けるのは自損行為です。

一貫性チェックリスト：実投入前にこの5項目を通す

試行錯誤を繰り返すより、このリストを環境の本番投入前の固定ステップにしましょう。

1. プロキシの地理的位置がシステムのタイムゾーンと一致。都市レベルの整合が国レベルより優れます。
2. システム言語と地域フォーマットがプロキシの所在地と整合。「英語OS＋ブラジルプロキシ」のような組み合わせを残さない。
3. User-Agentが宣言するOSと、Canvas・WebGLの実際のレンダリング出力が同源。理想は環境全体がそのOS上で動いていること。
4. WebRTCを完全に無効化するか、プロキシの出口を通ることを確認。2つのIPが一致しなければレッドライト。
5. 設定完了後、検出ページで全体スコアを一度実測し、矛盾フラグがないことを確認してから本番運用へ。

一貫性を手作業ではなくデフォルトの状態に

数十個のパラメータを手作業で調整すれば、ほぼ確実にどこかを見落とします。だからこそフィンガープリントの一貫性は、アンチディテクトブラウザの中核機能になりました。MakoBrowserの考え方は、整合性を環境そのものに組み込むことです。各アカウントは独立したプロファイルで動作し、フィンガープリント、Cookie、プロキシ、タイムゾーン、言語を個別管理します。公式ドキュメントによれば、プロキシ設定時には環境パラメータがプロキシのメタデータを基準にまとめて整合します。こうした主張は、試用期間に上記のチェックリストで一つずつ検証し、最終判断はご自身の検出結果を基準にしてください。

「IPを変えてもフラグが立つ」に悩んでいるなら、MakoBrowserクライアントをダウンロードし、既存環境をチェックリストで点検したうえで、新環境の設定手順を標準化作業として定着させましょう。

よくある質問

住宅用IPに変えてもPixelscanにフラグが立つのはなぜですか？

住宅用IPが解決するのはアドレスの品質であって、環境の矛盾ではありません。タイムゾーン、システム言語、フォントレンダリング、WebRTCリークのどれか一つでもプロキシの所在地と衝突すれば、一貫性の監査で暴かれます。まず5項目のチェックリストを実行すれば、大抵は具体的な矛盾点を特定できます。

クラウドフォンでアカウント運用するのは本当に安全ですか？

クラウドフォンはローカル設定の手間を省きますが、多くはソフトウェアレンダリングに依存しており、WebGLの読み取り値が「実GPUなし」という事実を露呈します。一貫性監査では明確な減点対象です。軽量用途なら許容範囲ですが、長期運用の高価値アカウントには実ハードウェアレンダリングを持つデスクトップ環境を推奨します。

Pixelscanで何度も自己チェックするとスコアに悪影響がありますか？

検出ページが読み取るのは、ブラウザが元々送信しているシグナルです。チェックという行為自体が減点を生むことはありません。結果に影響するのは、各チェックで露呈する矛盾のほうです。設定済みの固定プロファイルで検出し、スコアを環境の健康指標として追跡することをおすすめします。