レジデンシャルプロキシが商用製品として初めて登場した2012年頃、主流だった料金モデルは「ポート」または「チャネル」でした。たとえば100ポートを提供するプランを購入する形です。1ポートは1つの同時接続を意味しました。より高い同時接続数が必要であれば、より大きなプランを購入する仕組みでした。
このモデルはしばらくの間、市場に適合していました。当時の顧客がスケールをどう捉えていたかにも合致しており、請求額を予測しやすくしていました。十分に機能していたため、業界の大半は2010年代半ばまでこのモデルを維持しました。
しかし、徐々に、そして最終的には急速に、意味をなさなくなっていきました。
なぜ最初はポート制が理にかなっていたのか
レジデンシャルプロキシの初期のユースケースは限定的でした。スニーカーボット、チケットボット、ニッチなスクレイパーなどです。既知の数の並列セッションを実行し、各セッションが別々に見える必要があるワークロードです。ポート制のプランはこのメンタルモデルに直接対応していました。1ポート、1セッション、予測可能な動作です。
プロキシネットワーク自体も小規模でした。数十万件程度のIPプールで、多くは一握りの国に集中していました。事業者は現実的に無制限の同時接続をサポートできなかったため、同時接続数を課金対象の軸として提示していたのです。
そしてポート制は経済的にも説明がつきました。100ポートを持つ顧客は10ポートの顧客とは明らかに異なる規模でした。料金は顧客の見かけ上の規模に連動していました。
なぜポート制は崩れたのか
ほぼ同時に3つのことが起こり、ポート制プランは適切な基本単位ではなくなりました。
プールが桁違いに大きくなった。 レジデンシャルプロキシ市場は統合され、スケールしました。主要プロバイダーは数十万件のIPから1億件を超える規模へと移行しました。同時接続数はネットワークレベルではもはや意味のある制約ではなくなりました。1,000の同時接続を求める顧客は、ネットワークが容易に提供できないものを求めているわけではなくなったのです。
ワークロードがポートのメンタルモデルから乖離した。 現代のデータ収集は、1か月間安定して稼働する100個の並列スクレイパーではありません。バースト的なファンアウト、月曜午前9時に価格更新のために1,000件のリクエストが発生し、その後翌週の月曜までほぼゼロのトラフィックが続くといった形です。あるいはイベント駆動のスクレイピング、Webhookが発火し、90秒間50件の同時リクエストが必要になり、その後ゼロに戻るといった形です。静的なポート割り当てはどちらの形にもうまく合いませんでした。過剰にプロビジョニングして(アイドル容量に対して支払う)しまうか、スロットリングされるかのどちらかでした。
顧客がそれについて考えたくなくなった。 購入者が実際に気にする問いは「これでどれだけのデータを移動できるのか」です。帯域幅こそが自然な単位です。ワークロードに応じてスケールし、AWSのような請求書、つまり予測可能な単位あたりコストと、実際の使用量によって決まる総コストにつながります。
移行期
帯域幅ベースの料金体系への移行には、レジデンシャルプロキシ市場の大部分でおよそ5年(2019年から2024年)を要しました。誰かが隠していたわけではありません。純粋な慣性です。大口顧客はポートプランで複数年契約を結んでおり、移行計画の策定は困難で、ほとんどのプロバイダーは既存の購入者に移行の猶予を与えるため、両方のモデルをできるだけ長く維持したいと考えていました。
2024年までに、業界内のあらゆる主要なレジデンシャルネットワークが帯域幅ベースの料金体系をデフォルトとして提供するようになりました。Shifterも例外ではありません。既存のスタックをポートプランに合わせて構築していた顧客のために、レガシーのポートプランは引き続き提供していますし、そのレガシーへの約束は今も変わりません。ただし、新規のものはすべて帯域幅制です。
帯域幅制が実際に変えるもの
いくつかの点で簡単になり、1つの点で難しくなります。
簡単になる点、購入。 「月に約200GBのページをスクレイピングする必要がある」という文は、何かを構築する前に顧客が書ける文です。「80ポート必要だ」という文は、まずワークロードを実行してみないとわからない文です。
簡単になる点、予測。 帯域幅は移動させるデータ量に比例してスケールします。スクレイピング頻度を2倍にすれば帯域幅も2倍になります。3倍にすれば3倍です。閾値による急激な変化も、ピーク時の同時接続のボトルネックもありません。
簡単になる点、請求。 請求書上の数字は1つだけです。「同時接続数は110%使用したがトラフィックは40%しか使っていない、計算はこうなる」といった説明は不要です。顧客は自分が何に対して支払っているのかを把握できます。
難しくなる点、規律。 帯域幅は開けっぱなしの蛇口です。HTMLの本文だけが必要なのにページのアセット全体をダウンロードしてしまう設定ミスのあるスクレイパーは、追加の有用なデータを何も生み出さないまま帯域幅を4倍にしてしまう可能性があります。ポート制であれば、そのスクレイパーは同時接続数の壁に突き当たり、事業者が気づいたはずです。帯域幅制では、誰かがエグレスを監査するまで請求額が膨らみ続けるだけです。
対策としては、リクエストの形を意図的に設計することです。製品データだけが必要なのに画像を取得しないようにする。Accept-Encoding: gzip を使う(多くのクライアントはデフォルトでこれを行いますが、確認する価値はあります)。アセットバンドルを引き起こすクエリパラメータを除去する。レスポンスコードだけが必要な場合はGETの前にHEADを送る。
業界はこれからどこへ向かうのか
帯域幅制の料金体系はレジデンシャル市場で勝利を収めました。次の差別化の軸はもはや料金モデルではなく、何がバンドルされているか、どの機能が無料で付いてくるか、そして何が帯域幅メーターにカウントされるかです。
2026年時点でプロバイダーが差別化を図っている例をいくつか挙げます。
スティッキーセッションの料金設定。 一部のプロバイダーはスティッキーセッションの帯域幅を割増料金でカウントします。私たちはそうしません。スティッキーセッションはリクエストごとのローテーションと同じ料金で課金されます。
機能としてのジオターゲティング。 一部のプロバイダーは都市レベルやASNレベルのターゲティングをアップグレードとして課金します。私たちはそうしません。すべてのジオ精度はすべてのプランに含まれています。
同時接続数の上限。 一部のプロバイダーは帯域幅のクォータに加えて同時接続数の制限を課しています。私たちはそうしません。すべてのプランで無制限の同時接続を提供しています。
APIとダッシュボード。 帯域幅がメーターとなった今、顧客は可視性を求めています。エンドポイントごと、ジオごと、セッションごとに、時間単位の粒度で何GB使ったか。これはもはやプレミアム機能ではなく、当たり前の要件です。
購入者にとっての教訓は、これまでどのインフラ分野でも変わりません。何が課金対象で、何がバンドルされているかを細部まで読むことです。実際に使う機能の半分に追加料金が発生するのであれば、GBあたりの表示料金には意味がありません。
今後の展望
帯域幅制の料金体系は最終形ではありません。ワークロードが、数百万件の低価値なリクエストにファンアウトするスクレイパーから、少数の高価値なリクエストを行うAIエージェントへとシフトし続けるにつれ、特定の業種向けにリクエスト単位や成功率単位の料金モデルが再び現れる可能性があります。
とはいえ、現時点では帯域幅が正しい単位として定着しています。ポート単位の時代はその役目を果たし終え、今は終わりを迎えています。