ローテーティングプロキシとは、作業中にIPアドレスが変わるプロキシサービスのことで、リクエストごとに変わる場合も、設定した時間ごとに変わる場合もあります。1つのゲートウェイに接続すると、プロバイダが大規模なプールから出口IPを選択するため、トラフィックが1つのIPに集中することなく、多数のアドレスに分散されます。
最も一般的なのはローテーティングレジデンシャルプロキシで、すべての出口IPが実際の家庭用回線に属しています。ウェブサイトからは、何千ものリクエストを送る1台の多忙なサーバーではなく、選んだ地域にいる普通の訪問者の流れとして見えます。
このガイドでは、ローテーションの仕組み、スティッキーセッションがどう組み込まれるか、バックコネクトゲートウェイとは何か、そしてローテーションがビジネスに適したツールとなる場面について説明します。
ローテーティングプロキシの仕組み
ローテーティングプロキシでは、IPアドレスのリストを自分で管理する必要はありません。スクレイパー、ブラウザ、HTTPクライアントを1つのホストとポートに向けるだけです。リクエストが届くたびに、プロバイダのゲートウェイがプールからIPを選び、そのIPを通してリクエストを転送し、レスポンスを返します。
コードの観点からは、リクエスト間で何も変わりません。ウェブサイトの観点からは、各リクエストが異なる訪問者から来ているように見えます。
このシンプルな仕組みは、公開されているウェブデータを大規模に収集する際の主な問題、すなわちIPごとの制限を解決します。ほとんどのウェブサイトは、一定時間内に各IPが送るリクエスト数をカウントしています。昼夜を問わず数秒ごとにリクエストを送る1つのアドレスは、機械のように見えます。同じ量を何千ものアドレスに分散させれば、通常のトラフィックのように見えます。
ローテーション vs. スティッキーセッション
ローテーティングプロキシは通常、2つのセッションモードをサポートしています。どちらを選ぶかが、最も重要な設定になります。
リクエストごとのローテーション
リクエストごとに新しいIPを取得します。これにより最大限の分散が得られますが、連続性は一切ありません。各リクエストがそれぞれ独立している作業に向いています。
- 商品ページやカテゴリーページ
- 検索結果ページ
- ディレクトリや一覧ページ
- 在庫や在庫状況の確認
リクエストごとに何も引き継がれないため、IPが変わっても何も壊れません。
スティッキーセッション
スティッキーセッションは、選択した期間だけ同じIPを維持します。リクエストが互いに依存する場合は常にこれを使用します。
- ログインしてアカウント内で作業する
- 商品をカートに入れてチェックアウトする
- カーソルやセッションクッキーで結果をページ送りする
- 複数ステップのフォーム
スティッキーの期間は、一連の流れ全体をカバーできる最短の時間に設定します。短すぎるとタスクの途中でIPが変わってしまいます。長すぎると、必要以上に多くのトラフィックが1つのアドレスに集中してしまいます。
IPが変わるとセッションが壊れる理由
これはローテーションにまつわる問題のほとんどの原因であり、見落としやすい点です。
ログインすると、ウェブサイトはそのアクセスに紐づいたセッションクッキーをブラウザに与えます。次のリクエストが同じクッキーを持ちながら別の都市や国から届くと、サイトからは利用者の位置が一瞬で飛んだように見えます。サイトによっては、再ログインを求められたり、セキュリティチェックに引っかかったり、セッションを完全に失ったりします。
プロキシ側は、あなたがログイン中であることを知りません。セッションが必要とする間、同じIPを維持するのはあなた次第です。フローが4分かかるなら、それより数分長いスティッキー期間を設定すれば余裕を持ってカバーできます。同じアカウントで何日も作業が続く場合、ローテーションは適切なツールではありません。その場合はISPプロキシの方が適しています。課金期間中、選んだ都市と選んだISP(ASN)に留まるためです。
Shifterでのローテーション設定
Shifterは、p.shifter.io:443という1つのゲートウェイを通じて、HTTP(S)またはSOCKS5経由のユーザー名とパスワード認証で両方のモードを提供します。ローテーション、スティッキーセッション、ターゲティングはコードではなくユーザー名で制御します。
# Per-request rotation: a new US residential IP on every request
curl -x http://p.shifter.io:443 \
-U "customer-USERNAME-country-us:PASSWORD" \
http://ip-info.com/json
# Sticky session: keep the same IP for session abc123 for 600 seconds
curl -x http://p.shifter.io:443 \
-U "customer-USERNAME-country-us-sid-abc123-ttl-600:PASSWORD" \
http://ip-info.com/json
# City targeting with a sticky session
curl -x http://p.shifter.io:443 \
-U "customer-USERNAME-country-us-city-new_york-sid-abc123-ttl-600:PASSWORD" \
http://ip-info.com/json最初のコマンドを数回実行すると、レスポンス内のIPが毎回変わります。セッションIDがなければ、IPはリクエストごとにローテーションします。sid-<id>を追加するとIPを保持でき、ttl-<seconds>でセッションの持続時間を設定できます。セッションIDを変更すると、新しいIPが割り当てられます。
ターゲティングも同様の仕組みです。国を指定するにはcountry-us、地域にはregion-california、都市にはcity-new_york、特定のインターネットプロバイダネットワークにはasn-7922を追加します。
Shifterは3つのレジデンシャルプールを提供しているため、作業内容に合わせてプールを選べます。
- Full Geo: 国、地域、都市、ASNによるターゲティング。
- Country Geo: 国によるターゲティングのみ。
- Non-Geo: ターゲティングなし。場所が関係ない作業向け。
バックコネクトプロキシとは
上述の単一ゲートウェイは、バックコネクトプロキシと呼ばれることがよくあります。アドレスのリストを渡す代わりに、プロバイダはプールへ自動的に接続し直す1つのエンドポイントを提供します。
バックコネクトはレジデンシャルの別の言い方ではありません。バックコネクトはIPがどう提供されるかを表し、レジデンシャルはIPがどこから来るかを表します。両者は独立しており、データセンターやモバイルプール向けのバックコネクトゲートウェイも存在します。
実際のところ、バックコネクトゲートウェイは以下を提供します。
- 設定するエンドポイントは1つだけ。 プロジェクトが続く間、ツールは同じホストとポートに向け続けます。
- 自動的な入れ替え。 オフラインになったIPは、コードに気づかれることなくローテーションから外れます。
- パラメータによるターゲティング。 国、都市、プロバイダの選択は認証情報の中で行います。
- リスト管理が不要。 プロキシリストを自分で作成・テスト・更新する必要はありません。
ビジネスにおけるローテーティングプロキシの利点
ここで挙げるのはローテーション自体の利点であり、レジデンシャルIP全般の利点とは別のものです。
- IPごとのレート制限を回避できる。 1アドレスあたり1時間に数十リクエストという制限も、大規模なプールにリクエストを分散させれば問題になりません。
- 大規模な収集作業を実行できる。 1つのアドレスならブロックされてしまう量でも、何千ものアドレスに分散すれば目立たなくなります。
- ブロックからの回復が手間いらず。 あるIPがブロックされても、次のリクエストは単に別のIPを使うだけです。
- 多数の地域を確認できる。 多くの国にわたる価格、広告、検索結果の比較は、市場ごとに別の設定を用意するのではなく、ユーザー名の変更だけで済みます。
- パターンのシグナルが減る。 多数の訪問者に分散したトラフィックは、単一のボットのような一定のリズムを示しません。
ここではプール規模が重要ですが、必要なときにオンラインになっているプールの部分だけが重要です。Shifterのレジデンシャルネットワークは195か国以上で2億500万以上のIPをカバーしており、2026年10月7日のベンチマークでは、測定した16のネットワークの中で最大のライブ米国レジデンシャルプールを保持しており、250,000リクエスト中212,212件のライブ米国IPが確認されました。
ローテーションには限界があります。トラフィックを分散させるだけであり、信頼されていないIPを信頼されるものに変えるわけではありません。サーバーの範囲をブロックするサイトに対してローテーティングデータセンターIPを使っても、プール内のすべてのIPで失敗します。リクエストのパターン、ヘッダー、ブラウザのフィンガープリントも依然として重要です。ローテーションはネットワーク面を改善するものであり、残りは優れたスクレイピングの実践でカバーする必要があります。
ローテーティングプロキシを使うべき場面、使うべきでない場面
ローテーティングプロキシを使うべき場面:
- ウェブスクレイピングや大規模な公開データ収集
- 小売業者やマーケットプレイス間での価格・在庫モニタリング
- 国や都市ごとのSERPおよびランキング追跡
- 地域をまたいだ広告の検証
- AIシステム向けのトレーニングデータやグラウンディングデータの収集
スティッキーセッションまたはISPプロキシを使うべき場面:
- アカウント管理や長時間のログイン作業
- ソーシャルメディアや広告プラットフォームのアカウント
- 同一の訪問者として認識されること自体が目的となるタスク
この選択についてより詳しく知りたい場合は、スティッキー vs. ローテーティングレジデンシャルプロキシの比較記事をお読みください。
まとめ
ローテーティングプロキシは、1つのゲートウェイを通じて、リクエストごとに、あるいは設定した時間ごとに、リクエストの背後にあるIPを変更します。独立したリクエストにはリクエストごとのローテーションを、1つのIPに依存するフローにはスティッキーセッションを使用してください。バックコネクトは、1つのエンドポイントから両方を提供するゲートウェイのモデルです。
作業内容に合わせてセッション設定を正しく行えば、ブロックの問題の多くは解消します。どちらかの方向で設定を誤ると、セッションが壊れるか、ウェブサイトに気づかれる形でトラフィックが集中するかのどちらかになります。
適切な設定を見つける最も手っ取り早い方法は、自分のターゲットでテストしてみることです。