ログインが必要なサイトをスクレイピングする方法：セッション、Cookie、そして大規模なスティッキープロキシ

収集する価値のあるデータの多くはログインの向こう側にあり、それをスクレイピングすることは公開ページのスクレイピングとは異なる分野です。認証した瞬間、あなたは匿名の訪問者ではなくなり、アカウントを操作する立場になります。そしてアカウントは、匿名のリクエストとは違ったやり方でレート制限され、チャレンジを受け、禁止されます。ゲーム全体が「単一のIDが目立たないよう自由にローテーションする」から「アカウントが本物の一貫したユーザーに見えるよう、一つのIDを安定させ続ける」へとシフトします。

方法の前に一つ注意点があります。アクセスを許可されているデータのみをスクレイピングしてください。自分自身のアカウント、パートナーから取得を許可されたデータ、利用権限のあるAPIなどです。ログイン後のデータは公開データとは法的・倫理的に異なる区分に属し、スクレイピングが合法かどうかはその境界線に大きく依存します。このガイドは、あなたがその正しい側にいることを前提としています。

公開スクレイピングはローテーションする。認証済みスクレイピングは一貫性を保つ。

公開スクレイピングから来る直感はすべてをローテーションすることです。リクエストごとに新しいIPを使えば、単一のIDが目立つことはありません。しかしログインの向こう側では、その直感は正反対になります。今あなたが持っているのは持続的なID、つまりアカウントであり、一貫性こそがそれを正当なものに見せます。1時間に50カ国からログインしたり、セッションの途中でIPを飛び回ったりするアカウントは、パワーユーザーには見えません。乗っ取られたように見え、それがロックアウトの引き金になります。

したがって、認証済みスクレイピングは次の二つをうまくやることに帰結します。効率的にログイン状態を維持するためのセッション管理、そしてテレポートしたように見えないよう、各アカウントを安定したクリーンなIDに固定することです。

セッションを管理する

ログインすると、サーバーはセッション状態を返します。通常はクッキー、時にはトークンです。最大の間違いは、リクエストごとに再ログインすることです。再認証は遅く、大量のログインはそれ自体がログインエンドポイントが厳しくレート制限をかけている赤信号となります。一度ログインしてセッションを取得し、それを再利用してください。

シンプルなHTTPクライアントの場合、これはクッキージャーを保持しプロキシに乗る、永続的なセッションオブジェクトを意味します。

import requests

proxies = {"https": "http://customer-USER-country-us-sid-acct42-ttl-600:PASS@p.shifter.io:443"}
s = requests.Session()
s.proxies.update(proxies)

# Log in once; the Set-Cookie response populates the jar.
s.post("https://example.com/login", data={"user": USER, "password": PW})

# Reuse the same session (and the same sticky IP) for every subsequent request.
r = s.get("https://example.com/account/data")

これに加えて重要な点が二つあります。多くのサイトはセッションごとのCSRFトークンや偽造防止トークンを要求し、それをフォームや前のページからスクレイピングして書き込み操作とともに送信する必要があるため、ハードコーディングするのではなくセッションから読み取ってください。そして多くのサイトはログイン後、サイト自身のフロントエンドが呼び出すクリーンなJSON APIを公開しています。ネットワークタブを観察するとそれがしばしば見つかり、キャプチャしたクッキーやトークンでその認証済みAPIを直接叩く方が、ページを再レンダリングするよりはるかに速く軽量です。

各アカウントを一つのクリーンで固定的なIPにピン留めする

これはプロキシ層がその存在意義を発揮する場所です。アカウントは一貫した位置を提示するべきなので、各アカウントはそれ専用のスティッキーセッションを持ちます。それは常に同じレジデンシャルIPを通じてそのセッションの間中出口となり、ここではユーザー名の中のsidとしてエンコードされています。ログイン済みアカウントでIPをローテーションすることは典型的な禁止のトリガーです。なぜならアカウントがセッションの途中で位置を飛び越えているように見えるためです。

IDを保持させるために重要なことが三つあります。

• 地理的一致。 IPはアカウントが通常操作している場所と一致すべきです。突然ドイツのIPに現れた米国のアカウントは乗っ取りのように見え、多くのサイトは再確認プロンプトやロックで応答します。
• クリーンな評価。 ログインエンドポイントは公開ページよりもIPのレピュテーションを厳しく調べます。なぜならそこがアカウント乗っ取りが起こる場所だからです。フラグの立ったアドレスは、データに到達する前に、2FAプロンプト、CAPTCHA、「本人確認」画面といった余分な摩擦を受けます。
• 一アカウント、一つのID。 複数のアカウントを運用する場合、それぞれが自分専用のスティッキーIPを必要とし、共有してはいけません。すべて一つのアドレスからログインするアカウントは、互いに紐付けられ、まとめてフラグを立てられます。これはアンチディテクトブラウザがデバイスレベルで処理する二層構造のIDのアカウント規模版です。異なるアカウント、異なるIP、そしてブラウザを使う場合は異なるフィンガープリントです。

多数のアカウントへのスケーリング

このパターンは、各アカウントを独自の安定したIDに対応付け、そのマッピングを保持することでスケールします。レジストリのように考えてください。アカウントとスティッキーなsid、アカウントとクッキージャー、そしてブラウザを操作する場合はアカウントとブラウザプロファイルです。

# One durable identity per account: same sid -> same exit IP, own cookie jar.
def session_for(account):
    s = requests.Session()
    sid = f"acct-{account['id']}"
    s.proxies.update({
        "https": f"http://{BASE_USER}-country-{account['geo']}-sid-{sid}-ttl-600:{PW}@p.shifter.io:443"
    })
    load_cookies(s, account)     # restore persisted jar, or log in if absent
    return s

そのうえで、一つのアカウントを激しく使い込むのではなく、負荷を複数のアカウントに分散させ、アカウントごとおよびターゲットごとに並行度の上限を設けてください。それぞれのアカウントには独自のレート制限があるためです。ロードバランシングの原則は適用されますが、分散させる単位は生のIPではなく、それぞれが固定されたIDを持つアカウントです。

失敗パターンに対処する

問題が発生するのは三つのケースで、それぞれに特有の対応があります。

セッションの期限切れ。 セッションはタイムアウトします。それを検出し、ログインページへのリダイレクトや401を見つけたら、同じIDで再認証し、その後再開してください。重要なルールは、再認証の際にIPを切り替えないことです。新しい場所からの再ログインは、期限切れ自体よりもはるかに疑わしく見えます。

サイレントログアウト。 時には200が返ってきても、実際にはページのログアウト版、つまり公開部分の見た目だけでアカウントデータが何もない場合があります。これはソフトブロックの認証版です。ステータスコードを信用するのではなく、ログイン済みユーザーだけが見る要素があるかどうかを確認して、まだログインしていることを検証してください。アカウント専用のマーカーが消えていたら、空の行を記録する前に再認証してください。

強制的な再確認。 2FAプロンプトや「本人確認」チャレンジは通常、IDがリスクありと見なされたことを意味し、多くの場合IPがフラグを立てられたか位置が変わったことが原因です。クリーンで安定した、地理的に一致したIPを使うことが、これを稀にする要因です。それが発生したときは、そのIDを疑いのある状態として扱い、突き進むのではなく引くようにしてください。

ログイン自体にはブラウザかHTTPか

ツールはスクレイピング全体ではなく、ログインに合わせて選んでください。クッキーを返す単純なフォームログインは、シンプルなHTTPクライアントで十分に機能します。クッキーを取得し、再利用し、軽量さを保ってください。しかしログインページは、まさに不正が起こる場所であるがゆえに、JSチャレンジ、SSOリダイレクト、動的トークン、積極的なフィンガープリンティングなど、サイトの中で最も厳しく防御されている部分であることが多いです。単純なクライアントがログインに対して通用しない場合は、実際のブラウザ(Playwright、Puppeteer、またはSelenium)でログインし、そのまま操作を続けるか、クッキーを軽量なクライアントにエクスポートして大量作業に使ってください。ここはTLSとHTTP/2フィンガープリンティングが最も強く影響する場所でもあり、スクレイピングの残りの部分が単純なクライアントで問題なく動く場合でも、ログインの段階では実際のブラウザのネットワークフィンガープリントが違いを生むことがよくあります。

実行を信頼する前に検証する

認証後、二つのことを確認してください。実際にログインしているかどうか(アカウント専用のエンドポイントを取得し、ログイン済みマーカーを確認する)、そして期待しているスティッキーIPを通じて出ているかどうか(IPエコーチェックはセッションの間中同じアドレスを返すべきです)。ログインが「成功」したのにアカウントマーカーが見当たらない場合や、出口IPがリクエストの間でドリフトしている場合は、何かを収集する前に修正してください。両方ともタイムアウトと検出のガイドで扱われています。

結論

ログインの向こう側でのスクレイピングは、ローテーションではなくIDの一貫性がすべてです。常に再認証するのではなく、一度ログインしてセッションを再利用してください。各アカウントを一つのクリーンで地理的に一致した、スティッキーなレジデンシャルIPに固定し、一つのアカウントには一つのIDを保ち、セッションが期限切れになったときは同じIDで再認証し、200を信用するのではなくまだログインしているかどうかを検証してください。単一のアカウントをアドレス間でローテーションするのではなく、それぞれが独自の安定したIDを持つアカウントを追加することでスケールしてください。

これを正しく行えば、認証済みの収集はロックアウトの連続ではなく、持続可能なものになります。アカウントごとのクリーンでスティッキーなレジデンシャルIPは、この全体が成り立つ基盤です。そしてGB単位の価格設定により、多数の安定したアカウントIDを運用しながら、それぞれが実際に取得したデータ分だけを支払うことができます。