月間レジデンシャルプロキシの帯域幅ニーズを見積もる方法

GB単位のレジデンシャルプロキシプランでは、購入する単位は帯域幅なので、適切なプランを選ぶことは1つの問いに集約されます。実際に月にどれだけのギガバイトを使うのか、ということです。少なく見積もりすぎると月の途中で超過やスロットリングに直面し、多く見積もりすぎると使わない余裕分に払いすぎることになります。良いニュースは、帯域幅は謎ではなく推定可能だということです。1つの式と現実的なページごとのサイズ、そして5分の計測があれば、自信を持ってプランを選べます。

このガイドはプロキシ利用を計画しているチームのためのものです。見積もりを段階的に組み立て、実際の計測に基づかせ、よくあるワークロードでの実例を見ていきます。

計算式

すべてはこの式に集約されます。

Monthly GB  ≈  (requests per month  ×  avg response size  ×  overhead factor)  /  bytes per GB

4つの入力値があり、そのうち1つが支配的です。影響の大きい順に見ていきましょう。

ステップ1: 平均レスポンスサイズ（最大の要因）

1リクエストあたり何バイト返ってくるかが見積もりの成否を分ける部分であり、どのように取得するかによって10倍以上の差が出ます。典型的な範囲は以下の通りです。

請求額に最も影響する単一の要因は、フルブラウザをレンダリングするか、HTML/JSONを直接取得するかです。ブラウザはページ上のすべてをダウンロードしますが、単純なHTTPリクエストはその一部しか取得しません。HTMLやAPIからデータを取得できるなら、1リクエストあたりのサイズと帯域幅は桁違いに減少します（これとアセットのブロックがプロキシの帯域幅コストを削減する方法の核心です）。

この数値は、測定できるなら推測すべきではありません。ステップ4を参照してください。

ステップ2: 月あたりのリクエスト数

これは通常、ページ（またはレコード）数に頻度を掛けたものです。

requests per month  =  items  ×  checks per day  ×  30

10,000商品を1日1回追跡する価格モニターは10,000 × 1 × 30 = 300,000リクエスト/月です。一度限りのデータセット構築では、頻度の乗数なしで単純にページ総数となります。ページネーションも含めてください。各「アイテム」が結果の3ページにわたる場合は、それに応じて乗算します。

ステップ3: オーバーヘッド係数

実際のクロールは100%効率的ではありません。リトライ、リダイレクト、失敗した試行はすべてプロキシを経由し、すべて帯域幅を消費します。ブロックされたリクエストやタイムアウトしたリクエストも、それでもバイトは消費しています。クリーンな見積もりの上にオーバーヘッド係数を加算してください。

• 簡単でオープンなターゲット: 約1.1（10%のオーバーヘッド）
• 典型的なサイト: 約1.2（20%）
• 防御が強いターゲット（頻繁なブロック/リトライ）: 約1.3以上

ターゲットが難しいほどリトライが増え、係数も高くなります。ブロック率を下げること（IP品質の向上、適切なペーシング）は、これを直接縮小します。詳しくはブロックを回避する方法を参照してください。

ステップ4: 実際のページごとのサイズを測定する（推測しない）

信頼できる見積もりへの最短ルートは、実際のターゲットの代表的なサンプルをプロキシ経由で取得し、バイト数を測定することです。レスポンスサイズ（バイト単位）はlen(response.content)です。

import os, requests, statistics

USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]
proxy_url = f"http://{USER}-country-us:{PASS}@p.shifter.io:443"
proxies = {"http": proxy_url, "https": proxy_url}

sample_urls = [ ... ]   # 20-50 representative target URLs
sizes_kb = []
for url in sample_urls:
    r = requests.get(url, proxies=proxies, timeout=30)
    sizes_kb.append(len(r.content) / 1024)

avg_kb = statistics.mean(sizes_kb)
print(f"avg {avg_kb:.0f} KB/request  (n={len(sizes_kb)})")

これを20〜50個の実際のURLに対して実行すれば、推測ではなく根拠のある平均サイズが得られます。これが測定するのは、実際にプロキシを通過する圧縮後のバイト数であり（Accept-Encodingを有効にしておくこと）、それが課金対象になることに注意してください。クライアントの完全なセットアップはPythonでのレジデンシャルプロキシPythonにあります。

実例

Monthly GB = requests × avg_size × overhead / 1,000,000（KBからGBへ、10進法）を使用します。

価格モニタリング、HTMLのみ。 10,000商品、毎日、約200 KB/ページ、オーバーヘッド1.15。 300,000 × 200 KB × 1.15 = 69,000,000 KB ≈ 69 GB/月。

同じ作業だが、フルブラウザレンダリング。 200 KBの代わりに約2 MB/ページ。 300,000 × 2,000 KB × 1.15 = 690,000,000 KB ≈ 690 GB/月。 同じデータで帯域幅は10倍、これが必要のないレンダリングのコストです（レンダリングが必須な場合のアセットブロックについてはPlaywrightでの利用を参照）。

検索/ランク監視、軽量レスポンス。 500クエリ、1日4回、それぞれ約30 KB、オーバーヘッド1.2。 500 × 4 × 30 × 30 KB × 1.2 = 2,160,000 KB ≈ 2.2 GB/月。 小規模で安価です。

一度限りのデータセット構築。 2,000,000ページ、約300 KBのHTML、オーバーヘッド1.2。 2,000,000 × 300 KB × 1.2 = 720,000,000 KB ≈ 720 GB、これは1回限りで、月あたりではありません。

パターンは明確です。レスポンスサイズとレンダリングの選択が支配的であり、リクエスト数は線形にスケールし、オーバーヘッドは中程度の乗数です。

見積もりからプランへ

数値をプランに変換するには、少し規律が必要です。

• バッファを追加する。 プランのサイズは見積もりに20〜30%を加えたものにし、月内の成長と見積もり誤差に備えます。サイクルの途中で使い切ることは、少しの余裕を持つことよりも大きな支障になります。
• 超過条件を把握する。 プロバイダーが超過をどう扱うか、GBあたりの追加料金、スロットリング、あるいは強制停止かを確認しておき、忙しい月に驚かされないようにします。
• 毎週照合する。 サイクルの早い段階で実際の使用量を見積もりと比較し、調整します。実際の使用量は、どんな推測よりも早く実際の1ページあたりのサイズとブロック率を教えてくれます。
• 買い増す前に数値を縮小する。 多くの場合、最も安いギガバイトは使わなかったギガバイトです。プランを増量する前に、レンダリングを省略し、アセットをブロックし、変更されていないページを再取得しないようにしましょう（プロキシの帯域幅コストを削減する）。これが効率が報われるGB単位モデルです（ポート単位の時代は終わった）。

よくある質問

そのジョブを実行したことがない場合、どうやって帯域幅を見積もればよいですか？ ターゲットページの代表的なサンプルをプロキシ経由で測定し（ステップ4）、実際の1リクエストあたりのサイズを取得します。それをリクエスト数とオーバーヘッド係数とともに式に当てはめます。測定されたサンプルは、どんな一般的な見積もりにも勝ります。

最も帯域幅を消費するのは何ですか？ フルブラウザレンダリングが圧倒的です。あらゆる画像、フォント、スクリプトをダウンロードします。HTMLやJSON APIを直接取得すれば、1リクエストあたりのサイズを10倍削減できます。レンダリングの選択は、請求額に対する最大のレバーです。

失敗したリクエストやリトライされたリクエストは帯域幅にカウントされますか？ はい。プロキシを通過するあらゆるリクエストは帯域幅を使用します。ブロック、リダイレクト、リトライも含まれます。だからこそ見積もりにはオーバーヘッド係数が含まれ、ブロック率を下げることがコスト削減につながるのです。

1 GBは1,000 MBですか、それとも1,024 MBですか？ これはプロバイダーの課金定義によります。10進法（1,000）か2進法（1,024）かです。差は約7%で、見積もり上は問題ありませんが、プラン境界に近いサイズを決める際にはプロバイダーがどちらを使っているか確認してください。

バッファはどれくらい追加すべきですか？ 見積もりに20〜30%を加えたものを計画し、月内の成長と見積もり誤差を吸収してください。その後は事前に多く買うのではなく、実際の使用量と照合して調整します。

結論

レジデンシャルプロキシの帯域幅を見積もることは推測ではありません。リクエスト数に、測定された平均レスポンスサイズとオーバーヘッド係数を掛け、GBに変換し、バッファを加えるだけです。この数値を最も動かす2つの要素は、どう取得するか（HTML/JSONはフルブラウザよりおおよそ10倍優れています）と、どれくらいリトライするか（IP品質が良ければ無駄なバイトが減ります）です。だからこそ、コミットする前に実際のサンプルを測定し、買い増す前に数値を削減してください。

見積もりができたら、料金ページにGB単位のプランが掲載されているので、あなたの数値にバッファを加えたものに合うティアを選べます。そして、うまく調整されたスクレイパーをレジデンシャルゲートウェイに向けることで、実際の使用量をプランに近づけておけます。