Kasada Anti-Bot 解説：2026年の検出メカニズムと正攻法
Kasada（旧PoW Shield）は、2026年時点で最も検出精度が高いクライアントサイド型アンチボットプラットフォームの一つである。本記事では「Kasada Anti-Bot 解説」として、ips.jsバイトコードVMの内部構造、x-kpsdk-ctヘッダーの意味、TLS/IPレピュテーション層の連動、そしてレジデンシャルプロキシを用いた正当な自動化の通し方を技術的に掘り下げる。対象読者はシニアスクレイピングエンジニアおよびアンチボット研究者である。
Kasadaの特徴は、単一の検出レイヤーではなく、ネットワーク層（TLS/HTTP/2フィンガープリント＋IPレピュテーション）とアプリケーション層（カスタムバイトコードVMによるブラウザフィンガープリント）を組み合わせた多層防御にある。Webスクレイピングの文脈では、この多層構造を理解せずに単一の回避手法（例：ヘッダーの偽装のみ）を試すと確実に失敗する。
Kasadaのアーキテクチャ概要
Kasadaの検出パイプラインは、大きく3つのレイヤーで構成される：
- ネットワーク事前スクリーニング — TLSハンドシェイク（JA3/JA4）、HTTP/2フレームフィンガープリント、IPレピュテーションスコアリング
- クライアントサイドチャレンジ — ips.jsによるバイトコードVM実行、デバイスフィンガープリント収集、暗号化ペイロード生成
- サーバーサイド検証 — x-kpsdk-ct / x-kpsdk-cd / x-kpsdk-dvヘッダーの復号・検証、KP_UIDz Cookieの発行・更新
ips.js — 449KBのカスタムバイトコードVM
Kasadaのコアは ips.js というチャレンジスクリプトである。ファイルサイズは約449KBで、標準的なJavaScriptとして記述されておらず、独自のバイトコードVM上で実行される。このVMは以下の要素で構成される：
- エンコードされた文字列テーブル — VM命令列内で使用される文字列は暗号化・難読化されており、実行時に動的に復号される。これにより、静的解析によるロジック抽出を困難にしている。
- 時間ベースのシード — チャレンジペイロードの生成には現在時刻がシードとして組み込まれる。サーバー側は受信時刻との差分を検証し、リプレイ攻撃を排除する。
- 整合性チェックサム — VM自身のコード整合性を検証するセルフチェック機構を内蔵し、デバッガーやフックによる改ざんを検出する。
VMは実行中にブラウザの各種APIを呼び出し、デバイスフィンガープリントを収集する。具体的には、navigator.userAgent、navigator.platform、screen.width/height、Canvas APIのレンダリング結果、WebGL拡張機能リスト、navigator.hardwareConcurrency、navigator.deviceMemory、タイムゾーン、言語設定など数十のシグナルを組み合わせる。これらのシグナルは相互に整合性が検証される — 例えば、User-AgentがChromeを主張しているのにCanvas APIの挙動がChromiumと一致しない場合、即座にフラグが立つ。
収集されたフィンガープリントは暗号化され、ローテーションするペイロードとしてサーバーに送信される。ペイロードは毎回異なる値を取るため、単純なキャプチャ・リプレイは通用しない。
KP_UIDz Cookieとx-kpsdk-* ヘッダー群
Kasadaのチャレンジ成功後、ブラウザには KP_UIDz というCookieがセットされる。このCookieはセッション識別子として機能し、後続リクエストでKasadaのエッジノードがクライアントを追跡するために使用される。
後続リクエストには以下のヘッダーが付与される：
| ヘッダー | 役割 | 失敗時の挙動 |
|---|---|---|
x-kpsdk-ct | チャレンジトークン — VMが生成した暗号化ペイロード | 429 Too Many Requests が返される |
x-kpsdk-cd | チャレンジデータ — デバイスフィンガープリントのハッシュ | トークン再生成が要求される |
x-kpsdk-dv | デバイス検証値 — VM実行環境の整合性シグナル | セッション無効化＋再チャレンジ |
429レスポンスに x-kpsdk-ct ヘッダーが含まれている場合、それはトークン検証が失敗したことを意味する。具体的には、トークンの期限切れ、フィンガープリントの不整合、またはリプレイ検出のいずれかが発生している。この場合、ips.jsを再実行して新しいKP_UIDzを発行する必要がある。
検出レイヤーの分解
TLS（JA3/JA4）フィンガープリンティング
KasadaはJavaScriptチャレンジを配信する前に、TLSハンドシェイクの段階でクライアントを評価する。TLSハンドシェイクでクライアントが送信するClientHelloメッセージには、暗号スイートのリスト、拡張機能の順序、楕円曲線パラメータなどが含まれ、これらの組み合わせはクライアント実装（Chrome、Firefox、curl、Python requests等）ごとに固有のパターンを持つ。
JA3はClientHelloの暗号スイート・拡張機能・楕円曲線をMD5ハッシュ化したフィンガープリントである。JA4はより構造化されたフォーマットで、プロトコルバージョン、暗号スイート数、拡張機能数を含む。Kasadaはこれらのフィンガープリントを既知のブラウザパターンと照合し、不一致（例：User-AgentはChromeだがJA3はPython requestsのパターン）を即座にブロックする。
重要な点は、KasadaがTLS層で弾いたリクエストに対してはips.jsすら配信しないことである。つまり、TLSフィンガープリントが不正の場合、チャレンジの機会すら与えられない。
HTTP/2フィンガープリンティング
TLS層を通過しても、HTTP/2のフレームレベルでも検証が行われる。HTTP/2では、SETTINGSフレームのパラメータ順序、WINDOW_UPDATEの値、HEADERテーブルサイズ、優先度フレームの構造などがクライアント実装ごとに異なる。Kasadaはこれらを指纹化し、TLS層のフィンガープリントとクロスチェックする。
例えば、ChromeはSETTINGS_INITIAL_WINDOW_SIZEに4194304を指定し、特定の順序でSETTINGSパラメータを送信する。一方、requestsライブラリのHTTP/2実装やhttpxのデフォルト設定はこの順序と一致しない。この不整合は、User-Agent偽装だけでは絶対に埋められない。
IPレピュテーションスコアリング
KasadaはIPアドレスのASN（自律システム番号）をリアルタイムでルックアップし、データセンターIP、VPN出口、既知のプロキシネットワークをスコアリングする。このスコアリングはTLS/HTTPフィンガープリントの評価と並行して実行される。
具体的な重み付けは非公開だが、観察から以下のパターンが確認されている：
- データセンターASN（AWS、GCP、Azure、DigitalOcean等）からのリクエストは、TLS/HTTPフィンガープリントが完璧でもスコアが大幅に減点される
- 住宅ISPのASNは高スコアを得るが、同一IPからの異常なリクエスト頻度は即座にスコアを下げる
- モバイルキャリアのASNは中程度のスコアだが、地理的一貫性（IP地理 vs タイムゾーン vs 言語設定）が検査される
なぜデータセンタープロキシでは不十分なのか
KasadaのIPレピュテーション層は、データセンターASNを実質的に事前ブロックする。これは「kasada bypass」を試みるエンジニアが最初に直面する壁である。
| プロキシタイプ | Kasada通過率（観察ベース） | 理由 |
|---|---|---|
| データセンター | ≈0% | ASNが事前ブロックリストに含まれる |
| モバイル | 中〜高 | キャリアASNは許容されるが、頻度制限が厳しい |
| レジデンシャル | 高 | 住宅ISP ASNが高スコアを得る |
データセンタープロキシを使用した場合、TLSフィンガープリントを本物のブラウザと完全に一致させても、IPレピュテーション層で弾かれる。これはKasadaが「IP信頼度」に極めて大きい重みを置いていることを示している。
レジデンシャルプロキシが必須な理由はここにある。住宅ISPのIPアドレスは、Kasadaのスコアリングモデルにおいて「人間のユーザーが使用するIP」として高信頼度を得る。ただし、レジデンシャルプロキシを使用するだけでは不十分であり、以下の条件を全て満たす必要がある：
- TLSフィンガープリントが実ブラウザと一致する（実ブラウザを使用するか、TLSスタックを精密にエミュレートする）
- HTTP/2フレームフィンガープリントが実ブラウザと一致する
- ips.jsが実際のブラウザランタイム上で実行され、有効なKP_UIDzが発行される
- IPの地理情報とブラウザのタイムゾーン・言語設定が一致する
ProxyHatレジデンシャルプロキシとの正攻法
ここでは、ProxyHatのレジデンシャルプロキシ出口と実ブラウザランタイムを組み合わせ、Kasadaのチャレンジを正攻法で通過するアプローチを示す。この方法は、ips.jsを実際のブラウザ上で実行し、正当なKP_UIDzを発行させるものである。
SOCKS5プロキシ設定
ProxyHatのレジデンシャルプロキシはSOCKS5プロトコルをサポートしており、ブラウザランタイムとの統合に適している。接続フォーマットは以下の通り：
socks5://USERNAME:PASSWORD@gate.proxyhat.com:1080地理的ターゲティングを指定する場合、ユーザー名にフラグを追加する：
socks5://user-country-US:pass@gate.proxyhat.com:1080
socks5://user-country-DE-city-berlin:pass@gate.proxyhat.com:1080スティッキーセッション（同一IPを維持）を使用する場合：
socks5://user-session-abc123:pass@gate.proxyhat.com:1080Kasadaのチャレンジでは、チャレンジ実行から後続リクエストまで同一IPを維持する必要があるため、スティッキーセッションが必須である。セッションIDを固定しないと、チャレンジ成功後のリクエストでIPが変わり、KP_UIDzが無効化される。
Playwright + SOCKS5の統合例
以下はPython + Playwrightを使用して、ProxyHatのレジデンシャルプロキシ経由で実ブラウザを起動し、Kasadaで保護されたページにアクセスする例である：
from playwright.sync_api import sync_playwright
proxy_config = {
"server": "socks5://gate.proxyhat.com:1080",
"username": "user-country-US-session-kasada01",
"password": "YOUR_PASSWORD"
}
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False, # Kasadaの一部チェックはheadless検出を行う
proxy=proxy_config
)
context = browser.new_context(
viewport={"width": 1920, "height": 1080},
locale="en-US",
timezone_id="America/New_York"
)
page = context.new_page()
# Kasadaで保護されたページにアクセス
page.goto("https://example-protected.com", timeout=60000)
# ips.jsの実行完了を待機
# KP_UIDz Cookieがセットされるまで待つ
page.wait_for_function(
"() => document.cookie.includes('KP_UIDz')",
timeout=30000
)
# チャレンジ通過後のコンテンツにアクセス
content = page.content()
print(f"Page length: {len(content)} chars")
browser.close()このアプローチの要点：
- Headless=False推奨 — Kasadaのips.jsは
navigator.webdriver、画面解像度の整合性、レンダリング挙動などでheadless検出を行う。デバッグ用途でheadless=Trueを使用する場合は、stealthプラグインの適用を検討する。 - タイムゾーンとIP地理の一致 — 米国IPを使用する場合、
timezone_idをAmerica/New_York等に設定する。不一致は即座にフラグされる。 - スティッキーセッション —
session-kasada01フラグでIPを固定する。チャレンジ〜後続リクエストの間でIPが変わると失敗する。
curlを使用した接続確認
ブラウザ統合の前に、プロキシ接続自体が正常に機能することを確認する：
curl -x socks5://user-country-US-session-test01:pass@gate.proxyhat.com:1080 \
https://httpbin.org/ipこれで住宅IPの出口アドレスが確認できる。次に、対象サイトのTLSフィンガープリントを確認するために、ProxyHatドキュメントを参照しつつ、JA3/JA4の一致を検証ツールで確認するとよい。
よくある失敗とエッジケース
1. HTTPライブラリ単体でのアクセス試行
requestsやhttpx単体でKasada保護ページにアクセスすると、TLSフィンガープリントがPythonのデフォルトパターンとなるため、ips.js配信前にブロックされる。レジデンシャルプロキシを使用していても同じである。これが「ips.js kasada」のチャレンジに到達すらしない最も一般的な原因である。
2. スティッキーセッション未使用によるIPローテーション
ローテーションプロキシモード（セッションID未指定）でチャレンジを通過した後、後続リクエストでIPが変わると、KP_UIDzとIPの対応が崩れ、x-kpsdk-ct検証が失敗して429が返る。Kasada対策では常にスティッキーセッションを使用する。
3. タイムゾーン/言語とIP地理の不整合
日本のレジデンシャルIPを使用しているのにブラウザのタイムゾーンがAmerica/Los_Angelesに設定されている場合、ips.jsのフィンガープリント収集で不整合が検出される。IPの地理情報に合わせてブラウザ設定を調整する必要がある。ProxyHatのロケーション一覧を参照して、適切な国・都市を指定する。
4. Headlessブラウザの検出
Chromiumのheadlessモードは、navigator.webdriverフラグ、window.chromeオブジェクトの有無、Canvas描画の微妙な差異などで検出される。Kasadaはこれらのシグナルを組み合わせてheadless実行を特定する。可能な限りheadedモードを使用するか、高度なstealthプラグインを適用する。
5. チャレンジ実行のタイムアウト
ips.jsの実行には通常2〜5秒を要するが、レイテンシの高いプロキシ経由では10秒を超えることがある。タイムアウトを短く設定しすぎると、チャレンジ完了前にリクエストが中断される。60秒のタイムアウトを推奨する。
適切な利用範囲と法的留意点
Kasadaの回避技術は、正当な目的にのみ使用すべきである。具体的には：
- セキュリティ研究 — 自社または委託されたクライアントのサイトに対するペネトレーションテスト（書面での明示的許可がある場合）
- 公開データの監視 — robots.txtで許可され、利用規約で禁止されていない公開データの収集
- QA自動化 — 自社アプリケーションのE2Eテスト
米国のComputer Fraud and Abuse Act (CFAA)は、不正アクセスを犯罪とする。利用規約違反のスクレイピングがCFAA違反とみなされるかは判例により異なるが、2022年のVan Buren判決以降は「アクセス権限を超える行為」が焦点となっている。EUではGDPRが個人データの収集・処理に適用される。Kasadaのチャレンジメカニズム自体がデバイスフィンガープリントを収集している点にも留意が必要である — 収集するデータの性質によっては、GDPR下での法的根拠が必要となる。
絶対にやってはいけないこと：他人のアカウントへの不正アクセス、クレジットカード詐欺、チケット・スニーカーの不正購入、競合価格の窃盗。これらは犯罪であり、本記事の対象外である。
プロキシタイプ比較：Kasada対策の観点から
| 項目 | データセンター | モバイル | レジデンシャル |
|---|---|---|---|
| Kasada通過可能性 | 極低（ASNブロック） | 中（キャリアASN許容） | 高（住宅ISP高信頼） |
| レイテンシ | 低（≈50ms） | 中〜高（≈200ms） | 中（≈100ms） |
| 同時セッション | 高 | 低 | 中〜高 |
| コスト | 低 | 高 | 中 |
| Kasada推奨度 | ✗ | △ | ✓ |
Key Takeaways
Kasada Anti-Bot 解説の要点：
- KasadaはTLS/HTTP/2フィンガープリント、IPレピュテーション、バイトコードVM（ips.js）の3層で検出する
- 429レスポンスに
x-kpsdk-ctが含まれる場合、チャレンジトークンが無効 — ips.jsを再実行する必要がある- データセンターASNは事前ブロックされるため、レジデンシャルプロキシが必須
- レジデンシャルプロキシ単体では不十分 — 実ブラウザランタイム上でips.jsを実行し、正当なKP_UIDzを発行させる
- スティッキーセッションでIPを固定し、タイムゾーン/言語をIP地理に一致させる
- 利用は正当な目的（セキュリティ研究、公開データ監視、QA）に限定する
Kasadaの多層防御に対する正攻法は、「実ブラウザ + レジデンシャルプロキシ + 地理的一貫性」の組み合わせである。ショートカット（ヘッダー偽装、TLSエミュレーション単体）は2026年の時点では通用しない。SERPトラッキングや公開データの監視など正当な用途では、このアプローチが最も信頼性が高く、長期的にも保守しやすい。
ProxyHatのレジデンシャルプロキシは、gate.proxyhat.com:1080（SOCKS5）経由で利用可能。スティッキーセッションと地理的ターゲティングを組み合わせることで、Kasada保護下のサイトに対しても安定したアクセスが可能となる。プランと料金を確認し、ユースケースに合わせて選択していただきたい。
