Akamai Bot Manager は、他のどの anti-bot システムよりも高価値なターゲットを守っています——航空会社、スニーカーのドロップ、チケッティング、大手リテール。この分野で最も古参のプレイヤーでもあり、それは 2 つのことを意味します：検知が最も成熟しており、ブロックの仕方が最も特徴的だということです。Akamai が captcha を見せることはめったにありません。返ってくるのは、エッジでのサイレントな 403、終わりのないリダイレクトループ、あるいは——その十八番である——正常に読み込めるのに汚染されたデータを返すページです。
本ガイドは、Akamai が 2026 年に実際に何をチェックしているのか、そして有効な四層アプローチを、当社のDataDome/PerimeterX ガイドやCloudflare ガイドと同じ精神で扱います。同じ免責事項が適用されます：これは公開データを妥当なレートでスクレイピングするためのものであり、悪用のためのものではありません。
Akamai はすべてのリクエストを 3 つの層にわたってスコアリングし、そのスコアは _abck cookie を通じてセッションに付随します：
python-requests や Go-http の ClientHello は最初のパケットでフラグが立ちます。仕組みは当社の JA3/JA4 解説を参照してください。:method :path :authority :scheme vs Chrome の :method :authority :scheme :path）が、たとえ TLS をなりすましても、あなたのクライアントを特定します。Akamai サイトでの「JA3 は完璧なのにまだブロックされる」ケースのほとんどは、HTTP/2 フィンガープリントの不一致です。Akamai の JavaScript は、大きな暗号化された「sensor_data」ペイロードを収集します：マウスの軌跡、キーストロークのタイミング、デバイスの向き、canvas/WebGL ハッシュ、自動化のアーティファクト。それを保護対象ドメインに POST し、そのレスポンスがあなたの _abck cookie をアップグレード（または汚染）します。有効な _abck は特定の位置に ~0~ を含み、フラグの立ったものは ~-1~ を含みます。センサーのフォーマットは数週間ごとに変わります——だからこそ、捕捉して再送したセンサーはすぐに死ぬのです。
リクエストのペース配分、ナビゲーション順序（商品ページを一度も読み込まずに商品 API を叩かなかったか？）、そしてセッション年齢。Akamai は忍耐強い：最初の数リクエストは通しておいて、スコアが蓄積するとセッションの途中でブロックすることがあります。
Akamai で保護されたサイトでは datacenter IP は死んでいます——ASN チェックだけでも息の根を止めます。residential プロキシを使い、_abck cookie がセッションに紐付いているため、sticky セッションを使ってください：1 つの IP を 1 つのアイデンティティの寿命のあいだ保持し、cookie と IP を 1 つの単位としてまとめてローテーションします。セッション途中で IP を変えると、それまで築いたセンサーの信頼が無効になります。（完全な戦略：sticky vs rotating セッション。）
# One sticky identity = one session id, held ~10 min
socks5h://USERNAME:[email protected]:913HTTP のみのスクレイピングでは、あなたのクライアントは TLS と HTTP/2 の両方をなりすます必要があります。curl_cffi はその両方を正しくこなします：
from curl_cffi import requests
r = requests.get(
"https://www.target-site.com/api/inventory",
impersonate="chrome", # TLS + HTTP/2 fingerprint together
proxies={"https": "socks5h://USERNAME:[email protected]:913"},
)HTTP/2 を有効にしただけの素の httpx では不十分です——httpx の h2 フィンガープリントは独自のものであり、Chrome のものではありません。クリーンな TLS フィンガープリントで 403 が返ってくるなら、ほぼ間違いなくこれが理由です。（背景：curl_cffi & tls-client ガイド。）
静的ページを超える何かについては、セッションのハンドシェイクのために本物のブラウザを走らせてください：ランディングページを読み込み、センサースクリプトを走らせ、人間らしい操作を少し（スクロール、マウス移動）行い、それから HTTP クライアント用に cookie を抽出します——同じプロキシ経由で：
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(proxy={
"server": "us.jibaoproxy.com:913",
"username": "USERNAME", "password": "PASSWORD",
})
page = browser.new_page()
page.goto("https://www.target-site.com/")
page.mouse.move(300, 400); page.mouse.wheel(0, 600)
page.wait_for_timeout(3000) # sensor POST happens here
cookies = page.context.cookies()
abck = next(c["value"] for c in cookies if c["name"] == "_abck")
# "~0~" in abck -> valid; "~-1~" -> flagged, restart with new identity| 症状 | 疑わしい層 | 修正 |
|---|---|---|
| 最初のリクエストで 403、cookie は関係なし | TLS / HTTP/2 フィンガープリント | 素の httpx ではなく curl_cffi のなりすまし |
| 最初のリクエストは OK、5–10 回後にブロック | IP レピュテーションまたはペース配分 | residential sticky セッション、ペースを落とす |
_abck に ~-1~ が含まれる | センサー / 自動化のアーティファクト | 本物のブラウザのハンドシェイク、まず人間らしい操作を |
| 200 OK だがデータがおかしく見える | 汚染されたレスポンス | フラグが立っています——アイデンティティを完全リセット |
| 入口で終わりのないリダイレクトループ | IP に対するエッジレベルのブロック | 新しい residential IP、ASN にフラグが立っていないか確認 |
_abck）、そして忍耐強い行動スコアリング。_abck を獲得する；~0~ を確認する。新規ユーザーは登録時に500MBを獲得、さらに初回チャージにボーナスが付きます。期間限定オファーです。