2026年版・スティッキーセッション vs ローテーション — どちらが勝つ場面とプール戦略の選び方

お客様側で最も頻繁に見かける設定ミスは、IP品質の低さでも国選択の間違いでもありません。セッション戦略です。住宅プロキシのプールを契約し、デフォルトのローテーションモードのままスクレイパーやエージェントに接続して、なぜチェックアウトのフローが毎回フラグを立てられるのか首をかしげる。あるいは、攻めたスクレイピングジョブにスティッキーセッションを設定してしまい、30秒間に1つのIPへ1,200リクエストを叩き込んで、対象サイトのあらゆるレートリミットに引っかかってしまう。

この記事は、新規のお客様と少なくとも週に一度は交わしている会話を文章にしたものです。それぞれのモードが実際に何をしているのか、どんなワークロードでどちらが有利になるのか、人がはまりがちな失敗パターン、そして新しいプールを組むときに2分で通せるフローチャートを取り上げます。内容のほとんどは、裏側でどのブランドを使っていても当てはまります。スティッキーとローテーションはサプライヤー固有の概念ではなく、プールの上に乗るルーティング戦略だからです。

スティッキーとローテーションが実際に意味するもの

住宅プロキシのプールとは、ゲートウェイのエンドポイントを正面に置いた上流IPの集合です。数は通常、サプライヤーによって数万から数千万に及びます。ゲートウェイに認証してHTTPSリクエストを送ると、ゲートウェイは転送に使う上流IPを1つ選びます。2つのモードは、同じ認証済みセッションからの後続リクエストで、この選び方がどう変わるかを表しています。

ローテーションモード: リクエストごとに別の上流IPを経由できます。ゲートウェイは転送のたびに新しいIPを選びます。国や都市に限定する場合もあれば、完全に開放する場合もあります。あなたのスクレイパーがページAにアクセスすると 24.x.x.x 経由でルーティングされ、ページBにアクセスすると 67.x.x.x 経由になる。対象サイトから見ると、リクエストの流れは、それぞれが1回だけリクエストを送る何千人もの別々の住宅ユーザーのように見えます。

スティッキーモード: セッショントークン（通常はユーザー名のサフィックスやヘッダー）をバインドすると、ゲートウェイはそのセッションに対して上流IPを一定時間1つに固定します。当社ではほとんどのプールでデフォルト10分とし、ダッシュボードで最大30分まで設定可能です。セッションがスティッキーである間、そのセッションへのクライアントからのリクエストはすべて同じ上流IPを通ります。対象サイトから見ると、リクエストの流れは、サイト内をクリックして回る1人の住宅ユーザーのように見えます。

サプライヤーによっては、これらを「high rotation」/「session-based」、あるいは「endpoint-mode」/「session-mode」と呼んだりします。挙動は同一で、違うのはマーケティング上の呼び方だけです。Bright Data、Oxylabs、Smartproxy、Iproyal、そして当社が集約している14の住宅プロキシブランドは、いずれもゲートウェイのパラメータを通じてほぼ同じ2つのモードを提供しています。

スティッキーが勝つとき

スティッキーセッションが存在するのは、フローの途中でIPが変わった瞬間に壊れてしまうワークロードがあるからです。よくある3つのパターンを挙げます。

複数ステップのチェックアウトやアカウントフロー。 IP X からカートに商品を追加し、IP Y でチェックアウトに進み、IP Z で決済を送信するユーザーは、現代のあらゆる不正検知システムから見ればセッションを乗っ取られたように映ります。Stripe Radar、PayPal Risk、Shopify Capital Bot Score、Klarna、Affirm — どれもセッション内のIP不連続を強い不正シグナルとして扱います。チェックアウトでのスティッキーは譲れません。

これはエージェント型のショッピングボットで絶えず失敗するのを目にします。お客様がデフォルトのローテーション住宅プロキシでbrowser-useを組み、エージェントが商品ページへ問題なく遷移し、カートに追加し、チェックアウトに進む — そこでチャレンジを出されるか、完全にブロックされる。お客様はプールのせいにします。スティッキーに切り替えると、同じプール、同じ対象、同じスクリプトで、一発で通る。

ログイン＋認証済みブラウジング。 主要サイトのほとんどはセッションクッキーをIPフィンガープリントに紐づけています。IP X でログインし、IP Y で保護されたページをリクエストすると、ログアウトさせられるか401を返されます。Twitter、Instagram、LinkedIn、Reddit、そして本気で不正対策をしているほぼすべてのサイトがこれをやっています。認証が必要なフローではスティッキーは必須です。

アンチボットのチャレンジ突破。 Cloudflare Turnstile、hCaptcha、DataDome のチャレンジ、PerimeterX のインタースティシャル — いずれもあなたのIPに紐づいたトークンを発行する仕組みです。IP X でチャレンジを解いて、IP Y でそのトークンを提示すれば、トークンは拒否されます。スティッキーの持続時間は、解くまでの時間と有効期限ウィンドウを十分に上回る必要があります。10分でほとんどのフローをカバーでき、より遅いキャプチャファームには30分です。

IPベースの状態を持つ地域ロックコンテンツ。 「昨日マドリードのIPからスペイン語版を見た」と覚えていて、そのシグナルを使って再訪時に言語選択画面を飛ばす対象サイトもあります。ローテーションしていると毎回その選択画面が出てしまい、実ユーザーは毎回それを見ることがないため、行動検知に引っかかります。

IP単位でレートリミットするAPI認証フロー。 OpenAI の API、AWS の署名付きリクエスト、多くの SaaS API — これらはIPごとにレートリミットをかけます。ローテーションしていると、IPあたりの「使用量」はわずかなのに、すべてのIPでレートリミットに触れることになります。スティッキーは使用量を集中させ、IPに評判を積ませ、IPをまたいだレートリミットの干渉を避けられます。

ローテーションが勝つとき

裏返しの話です。ローテーションが勝つのは、対象がレートリミットを意識していて負荷を分散させる必要があるとき、あるいは継続性よりも新鮮さが重要なときです。

ページが互いに独立した大量スクレイピング。 100万件の商品ページをスクレイピングする? 各ページはそれ自体が1つのトランザクションです。リクエストごとにIPをローテーションすれば、負荷がプール全体に分散され、どのIPもスクレイパーらしく見えません。代償はセッション状態を保持できないことですが、ステートレスなスクレイプならそもそも必要ありません。

検索エンジンのスクレイピング。 Google、Bing、Baidu はIP単位で激しくレートリミットをかけます。ここでスティッキーは自殺行為です。10分であっても、50〜100件の SERP でIPを焼き切ってしまいます。住宅プールでクエリごとに1IP（または結果ページごとに1IP）でローテーションするのが標準パターンです。十分なクエリ間隔と適切なユーザーエージェントのバリエーションと組み合わせてください。

広告検証。 地域をまたいで広告が正しく配信されているかを検証するとき、各チェックは独立したユーザーのように見えるべきです。チェックごとにローテーションするのがまさに望むものです。さらに、一部のキャンペーンは都市圏単位でターゲティングするため、通常は国より細かい地域制御（都市や郵便番号）も欲しくなります。

小売・航空・ホテルの価格スクレイピング。 対象は IP＋ブラウザのフィンガープリント相関に対して攻撃的です。同じIPが5分で2回価格をスクレイプ＝ボット。同じIPが1回だけ価格を確認して二度と戻らない＝ノイズ。ローテーションが勝ちます。旅行メタ検索のスクレイピングでF-Geofastのような高速プールを1リクエスト1IPで回すお客様を見かけますが、それが標準構成です。

SEO／ブランドモニタリング。 順位、コンテンツ、リンク切れを確認するために自社サイトや競合サイトをクロールする用途です。ローテーション住宅プロキシを使えば、あなたのスクレイパーが、全ページを叩き続ける単一の怪しいIPとして対象の解析に現れるのを防げます。

スニーカー・ゲーム・チケットの発売フロー。 直感に反しますが、純粋な発売の瞬間はローテーションです。サイトには保持すべき状態がゼロ（あなたは以前来たことがない）であり、1リクエストごとにIPを焼き捨てることで、1枠を成功させる確率が最大化します。カートに入れられたら、チェックアウト用にスティッキーへ切り替えます。このパターンはスニーカープロキシガイドで詳しく解説しています。

人がはまる失敗パターン

明示的に取り上げる価値があるほど頻繁に見かけるパターンをいくつか挙げます。

スティッキーが長すぎる。 4分で終わるチェックアウトフローに30分のスティッキーをかけると、セッションごとに26分ぶんのIPを無駄にします。これに同時実行数を掛けると、プールで利用可能なユニークIPの予算を一気に使い果たします。スティッキーの持続時間は、想定される最長セッション長のおおよそ1.5倍に調整してください。

スティッキーが短すぎる。 逆のケースです。4分のチェックアウトフローに1分のスティッキーをかけると、決済の途中でIPがローテーションし、まさに避けようとしていた不正シグナルを発火させてしまいます。実際のセッション中に curl --proxy your_gateway:port https://ipinfo.io/ip を30秒ごとに繰り返して、チェックアウト完了前にIPが本当に変わらないことを必ず検証してください。

地域の多様性が足りないままローテーションする。 ターゲット国にユニークIPが5,000個しかないプールで毎秒50リクエストを送ると、プールは100秒で全セットを使い切ります。対象サイトから見れば、100秒経つと「新しい」IPに当たり始めますが、それは実は100秒前に見たIPです。現代のアンチボットはこれを追跡します。プールのサイズはリクエストレートに見合わせてください。

1つのスクリプト内でうっかりモードを混在させる。 ライブラリにスレッド間で変動するデフォルトのセッションIDがあると、1つのセッションを共有する2つのスレッドが、同時リクエストで同じスティッキーIPを使い回してしまい、奇妙に見えます（1つのIPが同時に5つのことをやっている）。スティッキーなら各並列ワーカーが自分のセッショントークンを持つようにし、各ワーカーの内側からIPをログ出力して検証してください。

スティッキー持続時間のドキュメントを鵜呑みにする。 一部の上流サプライヤーは公称を下回ります。10分と言いながら、上流ピアが落ちたために4分でIPが変わる、といった具合です。必ず実測してください。当社では自社プールでこれを監視し、ブランドが公称のスティッキーウィンドウを維持できないときはトラフィックを再配分しています。多くのサプライヤー連携については、住宅プロキシダッシュボードにブランド固有のメモを記載しています。

手早い意思決定ツリー

新しいプールを設定するときは、これに沿って進めてください。

1. ワークフローは、1人のユーザーのように見える必要がある複数リクエストにまたがっていますか? はい → スティッキー。いいえ → ローテーション。
2. スティッキーなら、ワークフロー内で想定される最長の単一セッションはどれくらいですか? スティッキーの持続時間をその1.5倍に設定し、ブランドの上限で頭打ちにします。
3. ローテーションなら、持続的に毎秒約5リクエストを超えて送りますか? はい → リクエストレートの少なくとも5倍のユニークアクティブIPを持つプールを選びます。
4. 対象は Cloudflare／DataDome／PerimeterX でチャレンジを出しますか? はい、かつチャレンジ解決に1分以上かかるなら、ワークフローの種類に関わらずスティッキーを強制します。IPローテーションをまたぐチャレンジは必ず失敗します。
5. 検索エンジンや広告配信の対象をスクレイピングしていますか? ローテーションを強制し、最低でもクエリごとに1IPにします。
6. ログインしていますか? スティッキー、以上です。

これは理論ではありません。毎週解決しているチケットを煮詰めたものです。お客様からの「プールが動かない」という報告のほとんどは、IPが悪いのではなく、モードの選択ミスだと判明します。

実装パターン

モードを切り替えるゲートウェイのパラメータはサプライヤーごとに異なりますが、いくつかの共通形に収まります。当社が集約しているほとんどのブランドでの慣例は、ユーザー名にセッションIDを埋め込む方式です。

# Rotating (no session ID)
curl -x http://USERNAME:PASS@gateway:port https://ipinfo.io/ip

# Sticky 10-minute session
curl -x http://USERNAME-session-abc123:PASS@gateway:port https://ipinfo.io/ip

ユーザー名のサフィックスではなくヘッダー（X-Proxy-Session: abc123）を使うブランドもあります。ローテーション間隔をユーザー名に入れるもの（-rotate-30m）もあります。ダッシュボードでは、各ブランドの正しいフォーマットをMy Proxiesに表示しています。そこで生成されたURLをコピーすれば、モードはデフォルトで正しく設定されます。

エージェント型のワークロードには、エージェントのタスクごとに新しいセッションIDを使い、タスクの境界でローテーションすることを推奨します。こうすると各タスクが1人の人間のセッションのように振る舞いつつ、連続するタスクがIPフィンガープリントを共有しなくなります。browser-use、Playwright、Selenium はいずれもコンテキスト単位のプロキシ設定に対応しています。新しいブラウザコンテキストを生成するときに、新しいセッションIDを設定してください。

お客様に実際にデフォルトで案内しているもの

お客様がどちらを選ぶべきか分からないときは、こう案内します。

• スクレイピング（最も多いリクエスト）: ローテーション、住宅プール。
• エージェント型ブラウジング／チェックアウト／ログインフロー: スティッキー、住宅プール、10分セッション。
• 1つのジョブで多数のサイトをまたぐ一括価格比較: ローテーション、住宅、高速ブランド。
• 地域精度を要する広告／SEO検証: ローテーション、都市／郵便番号ターゲティングの住宅。
• スニーカー／チケット発売: 発売中はローテーション、カート確保後はスティッキー。
• 自社の正当な業務向けのAPIレートリミット回避: スティッキー、ISP固定 — ローテーションよりIPの評判が重要。

これを読んで、自分のやっていることに対して間違ったモードを使っていたと気づいたなら、切り替えはパラメータ1つです。プール自体が問題だと決めつける前に、まず同じプールでテストしてください。10回のうち8回は、プールは問題なく、モードが間違っていただけです。

—

Sara は Hell World の初期からアンチボット研究とプールエンジニアリングに携わっています。あなたのスタックで悩ましいセッション戦略の相談をしたい場合は、Discord サーバーの #engineering-help チャンネルが、彼女やチームのメンバーに最も早く連絡できる手段です。