PerimeterX検知(現在はHUMAN Securityが提供)は、航空会社サイトやハイエンドECサイトで最もよく見かける高度なボット防御システムの一つです。単純なIPブロックやUser-Agentフィルタリングを遥かに超え、デバイスフィンガープリント、TLS指紋、行動分析を組み合わせて自動化トラフィックを識別します。本記事では、PerimeterXの検知メカニズムを技術的に分解し、レジデンシャルプロキシとブラウザステルスを組み合わせた正当なバイパス手法を解説します。
PerimeterX(HUMAN Security)の検知アーキテクチャ概要
PerimeterXは2016年に設立され、2022年にHUMAN Securityに買収・統合されました。現在はHUMANのBot Defender製品として、グローバル企業数千社に導入されています。中核となるのは、クライアントサイドJSセンサーとサーバーサイドリスクエンジンの組み合わせです。
アーキテクチャは大きく3層で構成されています:
- センサーレイヤー:ページに埋め込まれたJSスクリプト(通常
/px*.jsパスで配信)がブラウザ環境をスキャンし、デバイスフィンガープリントと行動データを収集 - リスクエンジン:収集したシグナルを機械学習モデルでスコアリングし、リスクスコア(0〜100)を算出
- チャレンジレイヤー:高リスクと判定された場合、CAPTCHAまたはJSチャレンジを表示
PerimeterX検知の特徴は、他のWAF/ボット防御製品と比較して行動シグナルの比重が高い点です。IPレピュテーションやTLS指紋だけでなく、マウスの動き、スクロールパターン、キーストロークのタイミングまで分析対象に含めます。
_px3 / _pxhd クッキーとJSチャレンジフロー
PerimeterXのセッション管理は2つの主要クッキーで行われます:
_pxクッキー群の役割
| クッキー名 | 目的 | 有効期限 |
|---|---|---|
_px3 |
メインセッショントークン。デバイスフィンガープリント、リスクスコア、タイムスタンプをエンコード | 通常30日〜60日 |
_pxhd |
デバイス識別ハッシュ。クロスセッションでデバイスを追跡 | 通常30日 |
_px2 |
(レガシー)初期リスク評価トークン | セッション |
_pxff |
フィルターフラグ。特定の検知ルールの結果を保持 | セッション |
JSチャレンジフロー
典型的なPerimeterXチャレンジフローは以下の通りです:
- ユーザーがページにアクセス → JSセンサーがロードされる
- センサーが環境データを収集(約200〜400ms)
- 収集したデータを難読化してPerimeterXサーバーに送信
- リスクエンジンがスコアリング → 低リスクなら
_px3を発行して通過 - 高リスクの場合 → JSチャレンジ(ブロックページ)またはCAPTCHAを表示
- チャレンジ成功 → 新しい
_px3を発行してアクセス許可
チャレンジページのHTMLには通常 "Press and Hold" ボタンまたは PX ロゴが含まれます。このチャレンジは、マウスの「プレス&ホールド」ジェスチャーを要求し、ボットが自動的に解決するのを防ぎます。
PerimeterX検知シグナルの技術的分解
PerimeterX検知は複数のシグナルレイヤーを組み合わせてリスクスコアを算出します。各シグナルを技術的に分解します。
デバイスフィンガープリント
PerimeterXのJSセンサーは、ブラウザ環境から以下のシグナルを収集します:
- Canvas指紋:非表示の
<canvas>要素に特定の文字列と図形を描画し、結果のピクセルデータをハッシュ化。GPU、ドライバー、フォントレンダリングエンジンの違いで一意なハッシュが生成される - WebGL指紋:
WEBGL_debug_renderer_info拡張からGPUベンダーとレンダラー名を取得。例:Google Inc. (NVIDIA)/ANGLE (NVIDIA, NVIDIA GeForce RTX 3060) - 画面メトリクス:
screen.width、screen.height、devicePixelRatio、availWidth、availHeightの組み合わせ - ナビゲーター プロパティ:
navigator.platform、navigator.hardwareConcurrency、navigator.deviceMemory、navigator.languages - フォント列挙:システムにインストールされているフォントのリストを間接的に検出
- AudioContext指紋:
OfflineAudioContextを使用してオーディオ処理パイプラインの特性をハッシュ化
これらのシグナルは、ヘッドレスブラウザや自動化ツールで不整合が生じやすい箇所です。例えば、Playwrightのデフォルトヘッドレスモードでは navigator.webdriver が true になり、Canvas指紋が通常のブラウザと異なる値を返します。
TLS / JA3 / JA4フィンガープリント
PerimeterXはTLS ClientHelloパケットからJA3/JA4ハッシュを計算し、既知のボットツールの指紋と照合します。JA3/JA4フィンガープリントは、暗号スイートの順序、拡張機能のリスト、楕円曲線パラメータを組み合わせてハッシュ化したものです。
主要な検知パターン:
- Python requests:JA3ハッシュ
5d39...— urllib3の固定TLSスタックが特徴的 - Go net/http:Goのデフォルト暗号スイート順序が一意なハッシュを生成
- curl:OpenSSL/LibreSSLのバージョンに応じたハッシュ
- 実際のChrome:ChromeのTLSスタックに固有のハッシュ(バージョンごとに変化)
重要なのは、JA3/JA4ハッシュがIPアドレスとは独立したシグナルである点です。レジデンシャルプロキシを使ってIPを変更しても、TLS指紋がPythonのものと一致すれば検知されます。これを回避するには、実際のブラウザ(Playwright/Puppeteer経由)を使用し、ブラウザのネイティブTLSスタックで通信する必要があります。
IPレピュテーション
PerimeterXはIPアドレスを以下の次元で評価します:
- ASN分類:データセンターIP(AWS、GCP、Azure等)は高リスク。ISP/レジデンシャルIPは低リスク
- 地理的一貫性:IPのGeoIP情報とブラウザの
navigator.language、timezoneの一致を確認 - 過去の行動:同じIPからの過去のブロック履歴、リクエスト頻度
- プロキシ検出: known proxy/VPN/TOR exit nodeリストとの照合
データセンターIPからのリクエストは、リスクスコアが初期段階で既に高く設定される傾向があります。これは、レジデンシャルプロキシがPerimeterX回避において重要な理由です。
行動分析(マウスムーブメント、タイミング)
PerimeterX検知の最も特徴的な部分が行動分析です。JSセンサーは以下のイベントを継続的に収集します:
- マウスムーブメント:座標、速度、加速度、軌跡の曲率。直線的な動きや瞬間移動はボットの兆候
- クリックパターン:クリック位置の分布、ダブルクリックの間隔
- スクロール:スクロール速度、方向の変化、ページのどの部分を閲覧したか
- キーストローク:キー入力の間隔、リズム(フォーム入力時)
- タイミング:ページロードから最初のインタラクションまでの時間、ページ間の遷移間隔
人間のマウスムーブメントは微小な揺らぎとベジェ曲線的な軌跡を持ちますが、ボットは通常、直線移動または完全にランダムな移動を生成します。PerimeterXの行動分析モデルは、この違いを高精度で識別します。
PerimeterX vs DataDome vs Akamai — 比較
主要なボット防御システムの比較表を以下に示します。各システムは異なる検知アプローチを採用しており、バイパス戦略も異なります。
| 特徴 | PerimeterX (HUMAN) | DataDome | Akamai Bot Manager |
|---|---|---|---|
| 主要検知シグナル | 行動分析(高比重)+ デバイスFP | IP/ヘッダー分析 + デバイスFP | センサーJS + TLS指紋 |
| チャレンジ方式 | Press & Hold / CAPTCHA | CAPTCHA / ブロック | ブロック / JSチャレンジ |
| JA3/JA4検知 | あり(中程度) | あり(高比重) | あり(高比重) |
| 行動分析の比重 | 非常に高い | 中程度 | 中〜高 |
| クッキー名 | _px3 / _pxhd |
datadome |
_abck / bm_sz |
| レジデンシャルIPの効果 | 高い | 高い | 高い |
| バイパス難易度 | 中〜高(行動シグナルが鍵) | 中(IP/ヘッダー中心) | 高(センサー逆解析が必要) |
PerimeterXとDataDomeの最大の違いは、行動シグナルの重み付けです。DataDomeはIPレピュテーションとHTTPヘッダーの整合性を重視しますが、PerimeterXはマウスムーブメントやタイミングパターンにより大きな重みを置きます。つまり、PerimeterXをバイパスするには、単にIPを変更するだけでなく、人間らしいブラウザ操作をシミュレートする必要があります。
PerimeterXを正当にバイパスする実装ガイド
ここでは、レジデンシャルプロキシ + Playwright Stealth + 行動シミュレーションを組み合わせた実装を解説します。すべての例は正当なデータ収集(TOS準拠、公開データのスクレイピング)を前提としています。
ステップ1:レジデンシャルプロキシの設定
PerimeterX検知を回避する第一歩は、データセンターIPではなくレジデンシャルIPを使用することです。ProxyHatのロケーション一覧から、ターゲットサイトの地域に合わせたIPを選択します。
curlでの基本接続例:
# 米国レジデンシャルIPでPerimeterX保護サイトにアクセス
curl -x http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080 \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
-H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
-H "Accept-Language: en-US,en;q=0.9" \
"https://example.com"
セッションID(session-abc123)を指定することで、同じIPを維持できます。PerimeterXは _px3 クッキーをIPアドレスと関連付けるため、セッション中は同じIPを使用し続けることが重要です。
ステップ2:Playwright Stealthの統合
curlだけではPerimeterXのJSチャレンジを通過できません。実際のブラウザエンジンを使用し、ステルスプラグインで自動化の痕跡を消す必要があります。
Python + Playwrightの実装例:
from playwright.sync_api import sync_playwright
import random
import time
# ProxyHat レジデンシャルプロキシ設定
PROXY_CONFIG = {
"server": "http://gate.proxyhat.com:8080",
"username": "user-country-US-session-flight001",
"password": "pass"
}
def human_mouse_move(page, target_x, target_y):
"""ベジェ曲線で人間らしいマウス移動をシミュレート"""
current = page.evaluate("() => [window.mouseX || 0, window.mouseY || 0]")
steps = random.randint(15, 30)
for i in range(steps):
t = i / steps
# 2次ベジェ曲線で中間点を生成
mid_x = (current[0] + target_x) / 2 + random.uniform(-50, 50)
mid_y = (current[1] + target_y) / 2 + random.uniform(-50, 50)
x = (1-t)**2 * current[0] + 2*(1-t)*t * mid_x + t**2 * target_x
y = (1-t)**2 * current[1] + 2*(1-t)*t * mid_y + t**2 * target_y
page.mouse.move(x, y)
time.sleep(random.uniform(0.005, 0.025))
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False, # ヘッドレスは検知されやすい
proxy=PROXY_CONFIG,
args=[
"--disable-blink-features=AutomationControlled",
"--no-sandbox",
"--disable-dev-shm-usage"
]
)
context = browser.new_context(
viewport={"width": 1920, "height": 1080},
locale="en-US",
timezone_id="America/New_York",
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/120.0.0.0 Safari/537.36"
)
# webdriverフラグを隠す
context.add_init_script("""
Object.defineProperty(navigator, 'webdriver', {get: () => undefined});
Object.defineProperty(navigator, 'plugins', {get: () => [1, 2, 3, 4, 5]});
Object.defineProperty(navigator, 'languages', {get: () => ['en-US', 'en']});
window.chrome = { runtime: {} };
""")
page = context.new_page()
# ページアクセス前にランダム待機
time.sleep(random.uniform(2, 5))
page.goto("https://example.com")
# 人間らしいスクロール
time.sleep(random.uniform(1, 3))
page.mouse.move(random.randint(100, 800), random.randint(100, 400))
page.evaluate("window.scrollBy(0, 300)")
time.sleep(random.uniform(0.5, 1.5))
# _px3 クッキーが発行されたか確認
cookies = context.cookies()
px3 = next((c for c in cookies if c['name'] == '_px3'), None)
if px3:
print(f"PerimeterX通過成功: _px3 = {px3['value'][:20]}...")
else:
print("PerimeterXチャレンジ発生の可能性")
browser.close()
重要なポイント:
headless=Falseまたはheadless="new"(Chrome新版ヘッドレス)を使用。従来のヘッドレスモードは複数のフィンガープリントで検知される--disable-blink-features=AutomationControlledでnavigator.webdriverフラグを無効化- ビューポート、ロケール、タイムゾーンをプロキシIPの地理情報と一致させる
- ページアクセス前に2〜5秒のランダム待機を入れる
ステップ3:ペースングと行動シミュレーション
PerimeterX検知を回避する上で、ペースングは技術的な設定と同等に重要です。以下のNode.js実装は、リクエスト間隔と行動シミュレーションを管理するラッパーを示しています。
const { chromium } = require('playwright');
const { randomInt } = require('crypto');
const sleep = (ms) => new Promise(r => setTimeout(r, ms + randomInt(0, 500)));
async function scrapeWithPacing(targetUrl, maxPages = 10) {
const browser = await chromium.launch({
headless: false,
proxy: {
server: 'http://gate.proxyhat.com:8080',
username: 'user-country-US-session-batch01',
password: 'pass'
},
args: ['--disable-blink-features=AutomationControlled']
});
const context = await browser.newContext({
viewport: { width: 1920, height: 1080 },
locale: 'en-US',
timezoneId: 'America/Chicago'
});
// ステルス注入
await context.addInitScript(() => {
Object.defineProperty(navigator, 'webdriver', { get: () => undefined });
delete navigator.__proto__.webdriver;
});
const page = await context.newPage();
for (let i = 0; i < maxPages; i++) {
// ページアクセス前の待機(3〜7秒)
await sleep(randomInt(3000, 7000));
await page.goto(targetUrl, { waitUntil: 'networkidle' });
// 人間らしいスクロール
await page.mouse.move(randomInt(200, 800), randomInt(200, 500));
await sleep(500);
await page.evaluate(() => window.scrollBy(0, 200));
await sleep(1000);
await page.evaluate(() => window.scrollBy(0, 400));
await sleep(2000);
// _px3 クッキー確認
const cookies = await context.cookies();
const hasPx3 = cookies.some(c => c.name === '_px3');
if (!hasPx3) {
console.log(`[ページ ${i+1}] PerimeterXチャレンジ検出 — 長待機`);
await sleep(30000); // ブロックされた場合は30秒待機
continue;
}
// データ抽出
const data = await page.evaluate(() => {
// 抽出ロジック
return document.title;
});
console.log(`[ページ ${i+1}] 取得成功: ${data}`);
// ページ間のペースング(5〜15秒)
await sleep(randomInt(5000, 15000));
}
await browser.close();
}
scrapeWithPacing('https://example.com', 10);
ペースングの目安:
- ページ間隔:5〜15秒のランダム間隔。固定間隔はボットの兆候
- 1セッションあたり:最大50〜100ページでセッションを切り替え
- 1IPあたり:1時間あたり100リクエスト以下を推奨
- 同時接続:同じIPで100 concurrent sessionsを超えない
詳細なプロキシ設定についてはProxyHat公式ドキュメントを参照してください。また、ProxyHatの料金プランでは、レジデンシャルプロキシの帯域幅と同時接続数に応じたプランを選択できます。
PerimeterXを導入している主要サイト
PerimeterX(HUMAN Security)は以下のような業界で広く導入されています:
航空会社
- United Airlines — 航空券検索・予約フロー
- American Airlines — 料金検索API
- Delta Air Lines — セッション管理
ハイエンドECサイト
- Neiman Marcus — 商品ページ、チェックアウト
- Saks Fifth Avenue — 限定商品の購入フロー
その他
- チケット販売サイト — 転売ボット対策
- 金融サービス — アカウント乗っ取り対策
- SaaSプラットフォーム — 不正アカウント作成対策
航空会社サイトは特にPerimeterXの行動分析が厳格です。これは、スケルパーボットが航空券を大量確保する問題に長年悩まされてきたためです。航空券の価格監視や競合分析を行う場合は、極めて慎重なペースングと人間らしいブラウジングパターンが求められます。
WebスクレイピングのユースケースやSERPトラッキングのページも参照して、ユースケース別のベストプラクティスを確認してください。
倫理的フレーミングとコンプライアンス
本記事の技術解説は、正当なデータ収集を前提としています。具体的には以下のシナリオが含まれます:
- 公開データのスクレイピング:robots.txtで許可されたページの収集
- 自社サイトのセキュリティテスト:PerimeterXを導入している自社サイトのペネトレーションテスト
- 価格モニタリング:競合の公開価格情報の定期収集(TOSで禁止されていない場合)
- SEOリサーチ:SERPの順位追跡と分析
以下の行為は避けてください:
- ログイン壁の背後にあるデータへの不正アクセス
- サイトのTOSで明示的に禁止されているスクレイピング
- スケルパーボットによる大量購入
- DDoS的な高頻度リクエスト
GDPR、CCPAなどのプライバシー規制にも注意が必要です。個人データを含むページのスクレイピングは、法的リスクを伴う可能性があります。スクレイピング前に必ず対象サイトのTOSとrobots.txtを確認し、法務チームと相談することを推奨します。
Key Takeaways
PerimeterX検知を回避するための重要ポイント:
- PerimeterXは行動分析の比重が高い — マウスムーブメント、スクロール、タイミングのシミュレーションが必須
- レジデンシャルプロキシは必須 — データセンターIPは初期リスクスコアが高い
- TLS/JA3指紋には実際のブラウザエンジンを使用 — Python requestsやcurl単体では検知される
_px3/_pxhdクッキーを維持 — セッション中は同じIPとブラウザコンテキストを保持- ペースングは5〜15秒のランダム間隔 — 固定間隔は即座に検知される
- ヘッドレスモードは避ける —
navigator.webdriver、Canvas指紋、WebGL指紋で検知される- 常にTOSとrobots.txtを遵守 — 正当なデータ収集のみを行う
FAQ
PerimeterX(HUMAN Security)とは何ですか?
PerimeterXは、現在HUMAN Securityが提供するボット防御・ボット管理製品です。2016年に設立され、2022年にHUMAN Securityに統合されました。デバイスフィンガープリント、TLS/JA3指紋、IPレピュテーション、行動分析を組み合わせて、自動化トラフィックを検知します。航空会社サイト(United、American、Delta)やハイエンドECサイト(Neiman Marcus、Saks)などで広く導入されています。
プロキシユーザーにとってPerimeterX検知はなぜ重要ですか?
PerimeterX検知は、データセンタープロキシを使用したリクエストを高い確率でブロックします。PerimeterXはASN分類でデータセンターIPを高リスクと判定し、初期リスクスコアを引き上げるためです。また、TLS指紋や行動シグナルもIPとは独立して評価されるため、プロキシの選択だけでなく、ブラウザエンジン、ステルス設定、ペースング戦略のすべてが重要になります。
PerimeterX回避にどのプロキシタイプが最適ですか?
レジデンシャルプロキシが最適です。PerimeterXはASN分類でISP/レジデンシャルIPを低リスクと評価するため、データセンタープロキシと比較して初期リスクスコアが大幅に低くなります。モバイルプロキシも有効ですが、コストが高くなる傾向があります。ProxyHatでは、gate.proxyhat.com:8080経由でレジデンシャルプロキシを提供しており、国・都市レベルのジオターゲティングが可能です。
PerimeterXのブロックを回避するにはどうすればよいですか?
レジデンシャルプロキシ、実際のブラウザエンジン(Playwright/Puppeteer)、ステルス設定(navigator.webdriverの隠蔽、Canvas/WebGL指紋の調整)、人間らしい行動シミュレーション(ベジェ曲線的なマウス移動、ランダムスクロール)、適切なペースング(5〜15秒のランダム間隔)を組み合わせる必要があります。また、セッション中は同じIPとブラウザコンテキストを維持し、_px3クッキーが発行されるのを確認してください。
PerimeterXとDataDomeの違いは何ですか?
最大の違いは検知シグナルの重み付けです。PerimeterXは行動分析(マウスムーブメント、タイミング、スクロールパターン)に高い重みを置くのに対し、DataDomeはIPレピュテーションとHTTPヘッダーの整合性を中心に評価します。そのため、PerimeterXのバイパスには行動シミュレーションがより重要になり、DataDomeのバイパスにはIP品質とヘッダーの整合性がより重要になります。






