当社は Geonode でプロキシを販売していますが、この記事は、皆さんが当初予定していたよりも少ない量を購入すべきだと主張するものです。 これがまさに私たちの立場です。過剰なプロキシプールはセキュリティを向上させるわけではなく、トラフィックベースの課金体系ではコストも増えないのです。つまり、人々はそれを正してくれる請求書を見ることもなく、誤った認識を抱き続けているのです。 重要なのは単一のターゲットに対する同時接続数であり、これは半日あれば測定可能です。 この記事から一つだけ覚えておくべきことがあるとすれば、それは私たちが提示するいかなる数値ではなく、次のセクションで説明する測定結果です。
唯一効果のある方法
3つのステップ、すべて実証に基づいています。
ステップ1：アドレスごとの上限を特定する。 単一のアドレスから実際のワークロードを実行し、リクエストレートを徐々に上げていき、ターゲットが反応し始めるポイント（429エラー、認証要求、応答の遅延、コンテンツの品質低下など）を特定します。 その閾値が、そのターゲットに対するアドレスごとの処理能力であり、この計算において推測ではない唯一の数値です。
ステップ2：必要なスループットを明確にする。 リクエスト数と処理期間を定めます。「処理期間」については正直に設定してください。この式において、この要素が他のどの要素よりも大きな影響を与えるからです。
ステップ3：割り算を行う。 必要なスループットをアドレスごとの処理能力で割ると、必要な同時接続アドレス数が得られます。再試行や変動の余地としてマージンを加えます。50％は余裕のある数値ですが、それ以上必要な場合は、ステップ1での測定値が楽観的すぎた可能性があります。
これがこの手法のすべてです。これが標準的なアドバイスとして広まっていない理由は、購入前にテストを実行する必要があるためであり、ベンダー側にはこれを提案するインセンティブがないからです。
ステップ1に関する注意点：試行されたリクエスト数ではなく、1秒あたりの完了した有効なレスポンス数を測定してください。コンテンツが削除された200ステータスを返すプールは正常に機能していませんが、総合的な成功率の指標では正常と報告されてしまいます。レスポンス内に既知の安定したマーカーが含まれているかを確認し、それを含むレスポンスのみをカウントしてください。
測定を適切に実行する
この手法全体はステップ1にかかっているため、自分自身を誤解させないよう、その実施方法を具体的に説明しておく価値があります。
テスト対象はテスト用エンドポイントではなく、実際のターゲットにしてください。 IPアドレスをエコーバックするサービスに対してテストを行っても、プロキシが機能していることは分かりますが、対象とするサイトがどのように反応するかについては何も分かりません。ターゲットごとに許容範囲が異なり、必要な数値もターゲットごとに異なります。
徐々に負荷を上げていき、すべてを記録してください。 予想される限界値を大幅に下回るレベルから始め、各レートでパターンが確認できるだけの十分な時間（少なくとも数分間）を維持しながら段階的に上げていきます。各ステップのレート、ステータスコード、レスポンスサイズ、および実時間を記録してください：
for rate in 0.2 0.5 1 2 5 10; do
echo "=== $rate req/s"
for i in $(seq 1 60); do
code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
echo "$rate $code $size"
sleep "$(echo "1/$rate" | bc -l)"
done
done | tee ramp.log
ステータスコードと同様に、レスポンスサイズも注意深く監視してください。 最も一般的な拒否反応は 429 ではなく、小さなページを伴う 200 です。特定のレートで平均レスポンスサイズが低下するのは、ターゲットが縮小された内容を返し始めていることを示しており、ステータスコードだけを数えていると見逃してしまいます。
1日の異なる時間帯で実行してください。 サイトのピーク時間帯には許容範囲が狭くなることが多く、午前3時に測定された制限値は正午には通用しません。最悪のケースを想定した数値を採用してください。
別のアドレスでも繰り返してください。 あるアドレスが 1 秒あたり 2 リクエストで限界に達し、別のアドレスも同時に同じ限界に達する場合、その制限はアドレスごとの問題ではなく、サブネットやリクエストのパターン、あるいはアドレスを増やしても解決できない他の要因によるものです。これは重要な否定的な結果であり、それを得るには 1 回分の追加実行が必要です。
そして、上限に達した時点で止めるのではなく、上限に達する手前で止めること。 ターゲットが許容する最大レートで動作させると、些細な変動でもその上限を超えてしまうことになります。測定された上限の60～70％を目安に規模を設定すれば、条件が良好な時にのみ完了するのではなく、確実に完了するジョブを実現できます。
実践例：毎日の価格監視
最も一般的なワークロードであり、その答えに人々が最も驚かされるケースです。
要件： 50,000件の商品ページを1日1回チェックする。
測定された上限値： レート制限がかかるまで、単一のアドレスから約2秒に1回のリクエストが許容されます。これは1時間あたり1,800リクエストに相当します。
24時間に換算すると： 50,000 ÷ 24 ≈ 1時間あたり2,100リクエスト。
必要なアドレス数： 2,100 ÷ 1,800 ≈ 1.2。切り上げて余裕を持たせると：2～4つのアドレス。
2つのアドレス。1日5万ページに対して、数百万と謳われているアドレスプールから。
ここで、仮定を一つ変えてみましょう。処理を1日を通して分散させるのではなく、2時間のウィンドウ内に完了させなければならないとします：
要件： 2時間で50,000ページ = 1時間あたり25,000ページ。 必要なアドレス数： 25,000 ÷ 1,800 ≈ 14、余裕分として：約20。
処理量も目標も同じなのに、アドレス数は10倍になる――これはスクレイピングの要件によるものではなく、スケジューリングの決定によるものだ。
これこそが、この記事で最も有用な洞察です。自分に許容する時間枠こそが、決定的な変数なのです。 アドレスを追加購入する前に、その作業を本当に迅速に完了させる必要があるのか、そしてそのスピードにどれほどの価値があるのかを自問してください。データは翌朝には消費されてしまうため、多くの場合、そのスピードに何の価値もないのです。
実践例：地域別チェック
形状はまったく異なり、計算の仕方も逆になります。
要件： 30の市場における地域別の価格と在庫状況を、1日4回、市場ごとに50ページずつ確認する。
処理量： 30 × 4 × 50 = 1日あたり6,000件のリクエスト。ごくわずかな量です。
スループットに必要なアドレス数： 実質的に1つ。1日あたり6,000件のリクエストは、14秒に1回のペースに相当します。
カバレッジに必要なアドレス数： 必要な瞬間に、30カ国それぞれに少なくとも1つの稼働中の出口が必要です。
ここでの制約は処理量ではなく、拠点の有無です。評価すべきは、プロバイダーが、必要な特定の市場において、運用時に実際に信頼できるカバレッジを持っているかどうかであり、プールにいくつのアドレスが含まれているかではありません。 3つの市場でのカバレッジが乏しい1,000万のアドレスプールは、30カ国すべてをカバーする1万のアドレスプールよりも劣ります。
だからこそ、地理的な業務において「いくつ必要か」という問いは誤りであり、「どこまで確実に到達できるか、そしてそれをテストできるか」という問いこそが正しいのです。
演習例：セッションベースの処理
並行性と同一性が同一のものとなるケース。
要件： 認証済みのセッションを10個並行して運用し、各セッションが複数ステップからなる一連の処理を実行する。
必要なアドレス数： 10個。これらはスティッキーでなければならない――各セッションの存続期間中、1つのアドレスが固定されること。
ここでは処理量は関係ありません。重要なのは、各セッションが一貫した識別情報（同一のアドレス、および一致するロケールとタイムゾーン）を持つことです。4カ国からリクエストが届くようなものは「セッション」ではなく、「パターン」です。
避けるべき間違いは、この用途にリクエストごとのローテーションエンドポイントを使用することです。これはほとんどのゲートウェイのデフォルト設定です。リクエストは成功しますが、セッション状態は失われ、誰かが送信元アドレスを確認するまでの間、その現象はアプリケーションのバグのように見えます。
また、10の同時セッションがあるからといって、10個のアドレスが永久に必要になるわけではありません。これは「一度に10個」という意味です。1日を通して200のセッションを順次実行するワークロードであっても、再利用される10個のスティッキーアドレスだけで十分です。
「多ければ多いほど安全」とは限らない理由
多くの場合、過剰な購入の背景にあるこの前提は、具体的には3つの点で誤りです。
ブロック処理はアドレス単位ではなく、サブネット単位で行われます。 サイトでは通常、/24 といった単位でブロック処理が行われます。 1つのブロックに含まれる50個のアドレスは、そのブロックがブロックされると1つのアドレスとして扱われるため、分散性の悪い大規模なアドレスプールは、重要な意味において「大規模なプール」とは言えません。数よりも分散性が重要であり、その仕組みについてはサブネットIDとは何かで解説しました。
重要なのは「信号」であり、「身元」ではありません。 タイミング、ヘッダー、またはTLSフィンガープリントによってリクエストが自動化されたものと見なされる場合、それらをより多くのアドレスに分散させても、信号そのものを除去することにはならず、単に信号を拡散させるだけです。結果として、フラグが立てられるアドレスは減るどころか、かえって増えることになります。
未使用のアドレスは陳腐化する。 ローテーション方式のプールでは、使用されていないアドレスはターゲットとの間に、良い意味でも悪い意味でも何の関係も持たない。「予備容量」を保持することは、何らかの備蓄を意味するものではない。
スループットに必要な数よりも多くのアドレスを保持する正当な理由は一つだけあります。それは**チャーン（顧客の入れ替わり）**です。ターゲットが時間の経過とともにアドレスをフラグ付けする場合、ローテーション用に代替アドレスが必要になります。これは現実的な要件であり、その規模は直感ではなく、観測されたフラグ付け率に基づいて決定されます。1日あたりにフラグ付けされるアドレスの数を測定し、数日分を確保しておきましょう。
実際に購入しているのは何か
これは明確に述べておく価値があります。なぜなら、答えは価格モデルによって異なり、その違いによって質問自体の意味さえ変わってくるからです。
ギガバイト単位の課金方式では（これは一般家庭向けや、多くの場合データセンターのトラフィック販売で採用されている方式です）、アドレスを購入しているわけではありません。 購入しているのはデータであり、アドレスの数はプランの特性ではなく、トラフィックプールの特性です。この文脈で「プロキシはいくつ必要か」と問うことはカテゴリーの誤りです。真に問うべきは、どれだけのトラフィックを転送するか、そしてそのトラフィックプールが、必要な場所でカバレッジを持っているかどうかです。 当社の一般家庭向けトラフィックは0.79ドル/GBから、データセンター向けは0.14ドル/GBからとなっています（2026年9月時点、価格ページで確認済み）。
IP単位の料金体系については、ISPや多くのデータセンター製品が採用している方式であり、文字通りIPの数に応じて課金されるため、この計算全体が予算の算定基準となります。当社の料金は1IPあたり1.25ドルです。ここでは前述の計算が直接費用に直結するため、20分かけて正確に計算する価値があります。
どちらのモデルが適しているかは、表面上の料金ではなくワークロードの特性によって決まり、両者を単純に比較することはできません。短期間で多くのアドレスを必要とするワークロードではトラフィック課金方式が有利ですが、少数のアドレスで済むワークロードではIP単位課金方式が圧倒的に有利です。この計算については、プロキシ料金ガイドで詳しく解説しています。
経験則とその限界
測定を行う前の出発点が必要な場合、これらは妥当な基準となります。これらは「答え」ではなく、後で置き換えるべき「最初の推測」として扱ってください。
| ワークロード | 出発点 | 実際の制約 |
|---|---|---|
| 毎日のクロール（許容範囲の目標） | 2～5 同時接続 | 時間枠 |
| 毎日のクロール（保護範囲の目標） | 10～30 同時接続 | アドレスごとのレート上限 |
| 地理的チェック | 1 場所あたり 1 回 | カバレッジ（範囲）、量ではない |
| 並列セッション | セッションあたり 1 スティッキー | セッション数 |
| 短時間ウィンドウ内のバーストジョブ | 処理量 ÷ アドレスごとのレート上限 | 選択したウィンドウ |
| 継続的モニタリング | 2～5 同時接続 | 負荷分散 |
心に留めておくべき2つの数値があります。数十の同時接続アドレスを超えるワークロードはほとんどありません。そして、実際にそれ以上の数が必要となるのは、地理的なもの（多くの場所があり、各場所のボリュームは少ない）か、自ら設定した期限がある場合に限られます。また、最も頻繁に変更が必要となるのはアドレス数ではなく、スケジュールです。
数値設定が間違っている兆候
少なすぎる場合：429エラーが増加する、課題が発生する、実行が進むにつれて成功率が低下する、ジョブが予定より遅れて完了する。解決策は、並行処理数を増やすか、実行期間を長くすることです。
多すぎる場合：何も起こりません。これが、この間違いが長引く理由です。 プールサイズが大きすぎても、トラフィック課金制では何の兆候も現れないため、誰も気づきません。IPごとの課金制では請求書が発行されるため、少なくとも疑問が湧くきっかけにはなります。
「少なすぎる」ように見えて実はそうではない2つのケース：
ブロックされたプール。 すべてのアドレスで同時に成功率が急落している場合、アドレスを追加しても効果はありません。ターゲット側で何かが変更されたか、アドレス以外のシグナルによってリクエストのパターンが特定されている可能性があります。
ターゲットの応答が遅い場合。 応答が遅くても成功している場合は、並行処理数を増やすことでスループットが一定点までは向上しますが、その後は頭打ちになります。 1秒あたりの完了リクエスト数を測定し、その数値が頭打ちになったら並行処理数の増加を停止してください。頭打ちになるのは、予想よりも早い時期です。
一般的な診断方法：並行処理数を段階的に増やし、1秒あたりの有効な完了レスポンス数を観察します。この数値は上昇し、頭打ちになり、その後低下します。最適値は頭打ちになった時点の数値であり、通常、誰もが予想するよりも少ない数値になります。
よくある質問
ウェブスクレイピングには何台のプロキシが必要ですか？
推測するのではなく、実際に測定しましょう。実際のターゲットサイトで、1つのアドレスが制限され始めるリクエストレートを特定し、必要なスループットをその数値で割り、余裕分を加算してください。 ほとんどのワークロードでは、同時接続アドレス数は1桁から2桁前半にとどまり、数千にはなりません。
プロキシの数を増やせば、ブロックされる可能性は低くなりますか？
ブロックがアドレス固有の場合に限ります。 リクエストがタイミング、ヘッダーの構成、またはTLSフィンガープリントによって自動化されたものと識別された場合、アドレス数を増やしても、そのシグナルを回避できるわけではなく、単にプロキシプール内のより多くのアドレスに分散させるだけです。数よりも、リクエストのレートや形状の方が重要です。
1日100万リクエストの場合、プロキシはいくつ必要ですか？
それは完全に期間によって異なります。 24時間に分散させる場合、1秒あたり約12リクエストとなります。アドレス1つあたり2秒に1回のリクエストとなると、同時接続アドレス数はおよそ25となります。これを2時間に圧縮すると、その12倍になります。変動要因となるのはボリュームではなく、スケジュールです。
アカウントごとに1つのプロキシが必要ですか？
セッションベースの処理であれば、アカウントごとではなく、同時セッションごとに1つのスティッキーアドレスが必要です。1日を通して順次運用される10のアカウントの場合、10個すべてが同時にアクティブである場合にのみ、10個のアドレスが必要となります。多くのプラットフォームではマルチアカウント運用が明示的に禁止されているため、その点を考慮した設計を行う前に利用規約を確認してください。
IPの数を増やすべきか、それとも質の高いIPを選ぶべきか？
「質が高い」とは、サブネット全体に適切に分散されており、ターゲットに適していることを意味します。ブロックは通常、/24の粒度で発生するため、1つのブロック内の50個のアドレスは1つのアドレスとして扱われます。規模は小さくても広く分散されたアドレスプールの方が、規模が大きく集中しているものよりもパフォーマンスが優れています。
プロキシが不足しているかどうかはどうやって判断すればよいですか？
429エラーの増加、認証要求ページの表示、およびリクエストの実行が進むにつれて成功率が低下することなどが挙げられます。すべてのアドレスで同時に成功率が急落する場合は、別の問題です。ターゲット側で何かが変更されたか、アドレス以外のシグナルによってリクエストが特定されている可能性があり、アドレスを増やしても解決しません。
プロキシの数は価格に影響しますか？
IP単位の料金体系では、直接影響します。購入するのはアドレス数そのものです。ギガバイト単位の料金体系では、まったく影響しません。データ量に対して支払うため、アドレス数はプールの特性に過ぎないからです。これが、2つの料金体系を表面上の単価だけで比較できない理由です。
ジオターゲティングには何台のプロキシが必要ですか？
必要な地域ごとに1つの信頼できるエグジットがあれば十分であり、通常、台数は関係ありません。プロバイダーに尋ねるべき質問は、アドレスをいくつ持っているかではなく、特定の市場で信頼できるカバレッジがあるかどうか、そして契約前にテストできるかどうかです。
まとめ
必要な数値は、1つの測定値と1つの割り算から導き出されます。実際のターゲットにおいて、単一のアドレスがレート制限を受け始める地点を見つけ、その値でスループット要件を割るのです。それ以外はすべて微調整に過ぎません。
結果に最も大きな影響を与える変数は、処理量ではなく、許容する時間枠です。1日5万ページを処理するには、24時間に分散させた数個のアドレスで十分ですが、2日間に分散させる場合は20個必要になります。処理速度を上げるために容量を購入する前に、そのジョブの早期完了に実際に依存しているものがあるかどうかを確認してください。多くの場合、そのようなものは存在せず、最も安価な最適化策は「忍耐」なのです。
また、地理的な業務の場合、問題は全く異なる形をとります。処理量は些細な問題であり、存在感こそがすべてです。有用な評価基準は、プロバイダーのサービス範囲がどれほど広いかではなく、特定の市場を確実にカバーしているかどうかです。これはトライアルで検証可能であり、午後1時間程度で済みます。そして、ベンダー（当社を含め）がランディングページに掲載するいかなる数値よりも、多くのことを教えてくれるでしょう。