スクレイピングで403やCAPTCHAにぶつかったとき、「UA回転」「Cookie維持」「セッション再現」が効く場面があります。一方で、やみくもに回しても改善しないケースも少なくありません。鍵は、サイト側が「状態（state）」を使って不正アクセスを見分けている点にあります。 セッション・Cookie・UA回転が効くのは、サイト側のBot判定が「単発リクエストの見た目」ではなく「一連のアクセスの整合性」を見ていることが多いからです。つまり、正しい状態遷移（同じ利用者として見える状態）を再現できると、ブロックされにくくなります。 押さえておきたい要点 Bot対策の多くは「このアクセスは人間か？」よりも、「このアクセスは正規のクライアントの状態遷移を踏んでいるか？」を見ます。ここで言う状態とは、Cookieやサーバ側セッション、CSRFトークン、リダイレクトの踏み方、要求ヘッダの整合などの総体です。 Webは本来ステートレスですが、Cookieにより状態を持ち込めます。サーバはレスポンスでCookieを発行し（ サーバはレスポンスで セッション・Cookie・UA回転はなぜ効く？状態管理で行うBot判定の仕組み
結論：効く理由
Set-Cookieで状態を発行し、クライアントは以後のリクエストでそれを返します。状態管理での判定
Cookieとセッション
Set-Cookie）、ブラウザは以後それを送ります。属性（Secure / HttpOnly / SameSite など）も挙動に影響します。MDNの説明どおり、CookieはHTTPの状態管理の基本要素です。
Set-Cookieヘッダを返し、クライアントはそのCookieを保存し、以後のリクエストで返すことで状態管理が成立します。
UAとClient Hints
従来のUser-Agentだけでなく、近年はUser-Agent Client Hints（例：Sec-CH-UA）も利用されます。MDNでも、初回はUser-Agentが送られ、必要に応じてClient Hintsの仕組みが使われることが説明されています。Bot判定では「ヘッダ一式の整合性」として使われやすいポイントです。
なぜ回転が効く？
「回転」は万能薬ではありません。効くケースは主に次の2つです。
短期レート制限の回避
IPやセッション単位での短期レート制限（一定時間の要求数上限）に当たっている場合、セッションの作り直しや分散が効くことがあります。ただし、これは対症療法で、根本は速度制御・キャッシュ・差分取得の設計です。
状態破綻のリセット
Cookieの欠落、途中リダイレクト未追従、トークン更新漏れなどで「不正な状態」になっていると、サーバはBot/不正と判断しやすくなります。この場合、Cookie jarを消して最初から正しい遷移を踏むことで改善します。
注意
UAだけを頻繁に回すと、同一IP・同一CookieなのにUAが変わるなど、むしろ「整合性がないクライアント」としてスコアが悪化することがあります。回転するなら「Cookie・ヘッダ・TLS指紋・画面サイズ等の整合」もセットで考える必要があります。
典型的な判定パターン
サイト側の実装は多様ですが、状態管理の観点ではパターン化できます。
セッション固定の検知
同じセッションIDで不自然なアクセス（短時間・大量・地域ブレ・ヘッダ不一致）が続くと、セッション単位でブロックされます。セッション管理のベストプラクティスとしても、推測困難なセッションIDやタイムアウト設計などが推奨されています。
Cookieの段階発行
初回アクセスで仮Cookieを発行し、JS実行や特定ページ遷移後に本Cookieへ昇格させる方式です。HTTPクライアントが「HTMLを取るだけ」だと昇格が起きず、以後のAPIが403になることがあります。
トークン更新の追跡
CSRFトークンや、ページ内に埋め込まれた一時トークンを要求し、古いトークンの再利用を弾く方式です。Cookie維持だけでは足りず、「HTML→トークン抽出→POST」という一連の状態遷移が必要になります。
ヘッダ整合の評価
UA・Client Hints・Accept-Language・Accept-Encoding・Refererなどの組み合わせが「ブラウザらしいか」を見ます。例えばSec-CH-UAを送るのに他が不自然、順序や値が極端などは疑われやすいポイントです。
実務での設計手順
対策は「回転すること」ではなく「再現すべき状態を定義すること」です。ここからが本題です。
まず観測する
- ブラウザ（DevTools）で正常系の通信を確認
- 初回〜目的APIまでのリクエスト列を並べる
- Cookieの増減、リダイレクト、トークンの更新点を特定
状態の最小セット化
「全部真似る」より「必要最小限の状態」を切り出します。例えば次のように整理します。
| 要素 | 役割 | 失敗時の症状 | 対処 |
|---|---|---|---|
| Cookie jar | 同一利用者の継続 | ログイン不可/403 | 永続化・ドメイン一致 |
| リダイレクト追従 | 遷移の整合 | 途中で403/ループ | 3xxの自動追従 |
| トークン | 再利用防止 | POSTが弾かれる | 毎回HTMLから抽出 |
| UA/CH | クライアントらしさ | 不審スコア上昇 | 整合セットで固定 |
回転の適用範囲
回転は「単位」を決めて使います。推奨は次の考え方です。
- UA：リクエストごとに回さず、「セッション単位」で固定
- Cookie：同一タスク内は維持。失敗時のみ破棄して再初期化
- プロキシ：ブロック兆候が出たセッションだけを切り替える
Pythonの最小例
以下は「Cookie維持（セッション）」と「UA固定」を守る最小例です。実際はリトライ、スロットリング、robots.txtや利用規約の確認なども組み合わせてください。
import requests
session = requests.Session()
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
"Accept-Language": "ja,en-US;q=0.9,en;q=0.8",
}
# 1) まず初回ページを踏んでCookieを受け取る
r1 = session.get("https://example.com/", headers=headers, timeout=30)
r1.raise_for_status()
# 2) 次のAPIに同一セッションでアクセス（Cookieが自動送信される）
r2 = session.get("https://example.com/api/items", headers=headers, timeout=30)
r2.raise_for_status()
print(r2.json())ポイント
- セッション（Cookie jar）を維持し、初回アクセスで配布されるCookieを取りこぼさない。
- UAを頻繁に変えない（状態の整合性を優先）。
効かない典型例
次のケースでは、UA/Cookieの小手先では突破できないことが多いです。
- 高度なフィンガープリント：TLS指紋、Canvas/WebGL、フォントなど、ブラウザ実行環境が必要
- 挙動ベース：スクロール、クリック、滞在時間などのイベント整合を要求
- アカウント保護：ログイン周りでMFA、デバイス認証、リスクベース認証
この場合は、ヘッドレスブラウザ運用（Playwright等）や取得頻度の見直し、データ提供APIの検討が現実的です。
運用上の注意
スクレイピングは技術課題だけでなく、規約・法務・運用リスクも含みます。アクセス制御を無理に回避する設計は、規約違反や業務リスクに直結し得ます。対象サイトの利用規約、robots.txt、提供APIの有無、取得頻度を必ず確認してください。
スクレイピングを安定化しませんか？
ブロック要因の切り分けから状態遷移の再現設計まで、実運用を前提に支援します。再現性の高い構成で取得失敗と保守コストを下げましょう。
まとめ
- セッション・Cookie・UA回転が効く本質は「状態遷移の整合性」を満たすことです。
- UAは回すより、セッション単位で固定して整合を保つ方が安定しやすいです。
- 最短ルートは「正常系の通信を観測→必要な状態を最小化→回転は単位を決める」です。
参考情報：
