各社で異なるWebスクレイピングの課金単位
Bright DataのWeb Unlockerは1,000リクエスト単位で価格設定されています。OxylabsのWeb Unblockerはギガバイト単位です。Firecrawlは1ページにつき1クレジットを消費します。Zyteは5段階の難易度ティアに分かれた1,000件の成功レスポンス単位で課金します。Apifyは、1GBのRAMを1時間保持することに相当するコンピュートユニット単位で請求します。
5社で5つの単位が存在します。各自でトラフィックを測定して得られる数値なしには、どの単位も相互に換算できません。そして各社ともその数値を公開していません。それはベンダーのプロダクトではなく、ユーザーのトラフィックに依存する数値だからです。
2026年9月8日に全5社の価格ページを確認しました。各社の提示内容と、それを計算した結果は以下のとおりです。
クイック比較
| ベンダー / プロダクト | 課金単位 | 公開価格 (2026年9月8日時点) |
|---|---|---|
| Bright Data Web Unlocker | 1,000リクエストあたり | 従量課金 $1.50/1K, $499プラン $1.30/1K |
| Bright Data Browser API | GBあたり | $5/GBから |
| Oxylabs Web Unblocker | GBあたり | 8GB時 $9.40/GB, 38GB時 $8.60/GB, 88GB時 $7.50/GB |
| Oxylabs Web Scraper API | 1,000結果あたり | $0.25/1Kから |
| Firecrawl | ページあたり (1クレジット) | 年払い10万クレジットで月額$83 (1,000ページあたり$0.83) |
| Zyte API | 成功レスポンス1,000件あたり (5サイトティア) | HTTP経由 $0.13〜$1.27/1K, レンダリング時 $1.01〜$16.08/1K |
| Apify | コンピュートユニット (1GB RAMを1時間) | $0.20/CU, $999プラン $0.13/CU |
この表から2つの点が浮き彫りになります。
Zyte自体の価格幅は124倍に及びます。同一ベンダー、同一単位、同一インボイスの項目でありながら、HTTP経由で取得する単純なサイトは1,000件あたり$0.13、ブラウザでレンダリングする高度なサイトは$16.08になります。「1,000リクエストあたり」を一律の比較数値として提示することは、それほど広い範囲の片端だけを引用しているにすぎません。
またBright Dataは、自社カタログの途中で課金単位を切り替えています。Web Unlockerはリクエスト単位で販売され、Browser APIはギガバイト単位で販売されています。これは不注意によるものではなく意図的な設計であり、本記事の残りの部分ではその意味について解説します。
1ギガバイトで実際に取得できるもの
換算の鍵を握る数値は平均ページサイズですが、その公開データは厳しい現実を示しています。
HTTP ArchiveのWeb Almanac 2025によると、2025年7月のクロール時点でモバイルホームページの中央値は2,559KBであり、1年間で8.4%増加しました。この中央値ページをコンテンツタイプ別に分解すると、画像911KB、JavaScript 632KB、フォント122KB、CSS 77KBとなります。
そしてHTMLは22KBです。
重要なのは最後の数値です。パースに必要な部分は通常HTMLドキュメントのみだからです。中央値のページにおいて、HTMLはブラウザの完全レンダリングで取得されるバイト数の0.86%にすぎません。残りの99%は、転送費用を払って取得した不要なデータです。
これをOxylabsの8GBプラン ($9.40/GB) で計算してみます。
- 1ページあたり22 KBのHTMLのみを取得する場合、1 GBは約45,000ページ分になります。これは1,000ページあたり約$0.21です。
- 1ページあたり2,559 KBでページ全体をレンダリングする場合、1 GBは約390ページ分になります。これは1,000ページあたり約$24です。
同じプラン、同じ提示価格でありながら、コード内の設定ひとつで116倍の差が生じます。
次にFirecrawlと比較してみましょう。年間プランで100,000クレジットが$83の場合、1ページ1クレジット換算で、ページサイズが20 KBでも4 MBでも1,000ページあたり$0.83を支払うことになります。HTMLのみの取得と比較すると、従量課金(GB単位)の方が約4倍安くなります。しかし完全なレンダリングと比較すると、GB単位の課金は約29倍高くなります。
分岐点は約100 KB付近
計算すると、2つの課金方式はある特定のページサイズで交差します。Firecrawlの1ページあたり$0.00083をOxylabsの1 GBあたり$9.40で割ると、88 KBになります。Firecrawlを年間契約ではなく月払い(同じ100,000クレジットで$99.50)にした場合、分岐点は106 KBへと移動します。この帯域を下回る場合はGB単位の課金が有利です。上回る場合は定額のページ単位課金が有利となり、ページサイズには上限がないためその差は急速に広がります。
興味深い点があります。Oxylabsはそれと明示せずに自社の換算値を公開しています。Web Unblockerの無料トライアルは「1GB (up to 10k results)」と説明されています。これは1結果あたり100 KBとなり、先ほど他の2社の価格表から算出した帯域内に収まります。彼ら自身の計算でも、ギャラリーをレンダリングするのではなく、ドキュメントを取得することが前提となっています。
したがって、バイト単位の課金でブラウザを操作している場合、最大の改善要因はベンダー選びではありません。ページ読み込み前に画像やフォントをブロックすることです。中央値となるページでは、2,559 KBのうち1,033 KBをこれらが占めているからです。請求書にあるロゴの選択でコストが決まるかのように見せかけるよりも、この事実をお伝えしたいと思います。
率直な注意点が2つあります。これらはウェブ全体の中央値であり、取得対象がウェブ全体と一致するわけではありません(ECサイトや旅行サイトはより重く、JSON endpointははるかに軽量です)。また、メディアをブロックしてレンダリングしたページは中央値を大きく下回る可能性があり、価格体系を変えなくても分岐点を有利にシフトさせることができます。同じ計算はLLMによる抽出処理の費用対効果が見合わなくなる境界を判断する際にも当てはまります。単価自体に意味はなく、最終的に保持した1レコードあたりのコストこそが重要です。
課金対象の定義という第2の軸
単位の選択は論点のひとつに過ぎません。何がメーターをトリガーするのかは別の問題であり、こちらの方が見落とされがちです。
Bright DataはWeb Unlockerで「成功分のみ課金」を謳っています。Zyteは「1,000成功レスポンスあたり」で価格を設定しています。FirecrawlはendpointごとのAPI requestあたり1クレジットを消費します。GB単位の従量課金では、成功条件は一切存在しません。バイトが転送された時点で課金されるため、破棄したチャレンジページも購入したページとしてカウントされます。
これは見た目以上に重要です。認証チャレンジやインタースティシャルページは通常、HTTP 200を伴って返されるためです。成功の定義をステータスコードに依存していると、リトライロジックや請求金額と、実際に取得できたデータセットとの間に乖離が生じます。この問題についてはValidate Rules Now Decide What Counts as Successで解説しましたが、部分的なブロックが時系列データにおけるサイレントな欠損に変わってしまうのも、全く同じ構造によるものです。
どの課金単位を選択すべきか
GB単位で購入すべきケース: ページのレンダリングを行わずにドキュメントを直接取得し、ターゲットがテキスト(検索結果、JSON endpoint、一覧ページ、サイトマップなど)である場合です。1ページあたり20〜50 KB程度であれば、従量バイト課金が市場で圧倒的に安価であり、他の追随を許しません。
ページ単位またはリクエスト単位で購入すべきケース: レンダリングを伴う場合、ターゲットにメディアが多く含まれる場合、またはロングテールの多様なサイトでページ容量が予測できない場合です。軽量なページでは割高になりますが、大容量ページにおけるコストの上限を固定できます。レンダリングを伴うワークロードでは、この上限設定に大きな価値があります。
ティア単位で購入すべきケース: Zyteなどが提供しているモデルで、ターゲット構成が安定しており、各サイトがどのティアに属するかを把握できている場合です。このモデルは、他社が平均化して隠してしまう「収集難易度が高いサイトほどコストがかかる」という現実を正確に反映しています。ただし、ターゲットリストが毎週のように変動する場合には適していません。
コンピュートユニットで購入すべきケース: プラットフォーム上で独自コードを用いて長時間のクロールを実行する場合です。この課金体系はデータ量ではなくマシンリソースに対して課金されるため、高速なパーサーはコスト削減につながり、低速なパーサーはコスト増につながります。コードの最適化が請求額に直結する唯一のモデルです。
これらの課金単位はいずれも意図的な罠ではありません。各ベンダーが自社の顧客ベースを理解した上で、標準的なトラフィックの特性に合わせて設計したものです。失敗の原因は課金単位の選択ミスではなく、前提となる単位が異なる2つの見積もりをそのまま比較し、表面上の数字だけで判断してしまうことにあります。
誰も値上げしなくても価格は上昇する
当社を含むあらゆるベンダーから見積もりを取る前に、自社の1週間分のトラフィックから2つの数値を測定してください。「1フェッチあたりのバイト数」と、「実際に保持・利用できたデータを返したフェッチの割合」です。この2つの数値が揃って初めて、本記事で取り上げたすべての見積もりを正しく換算・比較できるようになります。どちらかが欠けていれば比較は不可能です。
さらに、翌年以降の変化にも注意を払う必要があります。Webサイトのホームページ(トップページ)のサイズ中央値は直近12か月で7.8%増加しており、今後も増大する傾向にあります。バイト単位で課金されている場合、それは誰にも告知されず、誰も交渉していない項目で毎年自動的に値上げが発生していることを意味します。
FourAでは、各コールのコストをresponse自体に含めて返送するため、月末の請求書から逆算することなく、リアルタイムでコスト換算を把握できます。これにより、どの課金単位を選ぶべきかが直接わかるわけではありませんが、議論の核心である「最終的に保持したページごとに、実際にいくら支出しているか」を明確に把握できます。