「最適なプロキシAPI」をうたう比較記事には、よくある落とし穴があります。Bright Data、Thunderbit、Apify を、あたかも同じ用途を競う製品みたいに横並びで比べてしまうことです。でも実際は違います。ある製品はルーティング済みのIP接続を提供し、別の製品は構造化されたJSONを返し、さらに別の製品は定期実行のスクレイピングワークフローを動かします。これらを初期価格だけで比べるのは、庭用ホースと浄水プラントを値段で比べるようなものです。
このガイドでは、2026年8月10日時点で公式ドキュメントを確認した10製品を、プロキシ、マネージドスクレイピング、抽出、プラットフォームの観点から整理します。万能の勝者を決めたり、持ち回り可能な成功率の主張を繰り返したりはしません。その代わりに、「有効結果」をどう定義するかを決め、自分の用途に合うカテゴリで候補を絞り、許可された対象でパイロット検証を行うための考え方を提示します。
「プロキシAPI」が1つの意味ではない理由
「どのプロキシAPIを使うべきか」という話題で混乱が起きる根本原因は、少なくとも4種類のまったく異なる製品が同じ言葉で呼ばれていることです。
生のプロキシネットワーク は、IPとルーティング制御を提供します。リクエストのロジック、リトライ処理、必要ならJavaScriptのレンダリング、戻ってきた内容のパースは自分で実装します。RFC 9110では、プロキシはクライアントが使うメッセージ転送の中継役として説明されており、それ以上でもそれ以下でもありません。(RFC 9110)
マネージドのブロック回避／ブラウザAPI は、リクエストのライフサイクルをより広く引き受けます。URLを送ると、IPを選び、必要に応じてページをレンダリングし、失敗時は再試行し、HTMLやスクリーンショット、場合によってはMarkdownを返します。
抽出API はさらに上の層にあり、生のHTMLではなく、構造化JSONや整形済みテキストを返します。
スクレイピングプラットフォーム は、これらすべてに加えて、スケジューリング、保存、そして既製スクレイパーのマーケットプレイスまでまとめて提供します。
この区別が「どのプロキシAPIを選ぶべきか」という話で重要なのは、価格と「成功率」がカテゴリをまたいで単純比較できないからです。トラフィック課金の住宅向けネットワークと、リクエスト課金のマネージドAPIは、そもそも解いている問題が違います。分母も、含まれる作業範囲も、出力の意味も異なるため、単純な価格順ランキングは誤解を招きます。したがって、以下の各製品紹介はまず製品カテゴリから始めます。
先に一つ重要なことを言っておくと、プロキシを使えるからといって、何でも自由にスクレイピングしてよいわけではありません。許可、対象サイトの利用規約、データ保護上の義務は、「どのベンダーが最大のIPプールを持つか」とは別の話です。どれだけ優れたプロキシAPIでも、その問題を消してはくれません。
10製品をどう評価するか
すべてのチームに通用する、正直な固定ウェイトは存在しません。生HTMLの保存、位置依存の価格監視、構造化データの補完ワークフローでは、求める要件が異なるからです。以下の基準を起点に、合計100になるよう重みを割り当て、自分のパイロット結果か、文書化された要件だけを基準に評価してください。
| 評価項目 | 測るべき内容 |
|---|---|
| 有効結果率 | 単なるHTTP 200ではなく、独自の意味的バリデータを通過した割合 |
| 有効結果1件あたりのコスト | リクエスト、トラフィック、レンダリング、リトライ、パース、保存、運用コストをすべて含めて有効出力で割った値 |
| 出力の適合度 | 生レスポンス、レンダリング済みHTML、スクリーンショット、Markdown、スキーマ型データのどれか |
| 接続・地域制御 | 必要なリージョン、都市、ASN、セッション、ローテーション、ヘッダー、Cookie、プロトコル制御 |
| 可観測性と制限 | リクエストID、課金単位ヘッダー、ログ、再実行、同時実行制御、予算停止機能 |
| コンプライアンスの根拠 | 調達方針、契約、対象の適格性、監査可能性、サポート体制 |
| エンジニアリング負荷 | 統合、パーサー保守、監視、手動修復にかかる時間 |
未対応の項目は空欄のままにするか、「該当なし」としてください。目的は、見かけだけ精密な点数ではなく、ワークロード固有の判断を下すことです。
1. Thunderbit
Thunderbit はこの一覧の中でも少し特殊です。生のプロキシネットワークではなく、HTTPクライアントに差し込む抽出APIに近いからです。公開APIドキュメントでは、Markdown向けの Distill、スキーマ化されたJSON向けの Extract、非同期URLセット向けの Batch が案内されています。求める出力がコンテンツやレコードであって、プロキシ接続そのものではないなら、この境界によって後工程をいくつも省けます。
実際の違いは、リクエストを送った瞬間に分かります。従来のプロキシAPIでは、成功しても戻るのは生HTMLです。つまり仕事の半分だけ終わった状態です。Thunderbit の POST /extract では、対象URLと、欲しい項目を定義したJSON Schemaを送ると、返ってくるのはそのスキーマに沿った構造化済みJSONです。CSSセレクタを書く必要も、Q3にサイトが商品ページを刷新したときにパーサーを保守する必要もありません。
この製品境界こそが、実務上の魅力です。呼び出し側は、別途プロキシ・レンダラー・パーサーのスタックを維持する代わりに、出力スキーマを定義できます。ただし、それでも本番導入前に実パイロットは必要です。許可されたURLで、項目の完全性、対象サポート、レイテンシ、単位消費量、同時実行数、失敗時の挙動を確認してください。
主な機能:
- 構造化出力が標準 — 生HTMLではなく、自分で定義したスキーマに一致するJSON
- 文書化されたレンダリングとルーティング制御 — 生プロキシ製品ではなく、抽出エンドポイントの一部として扱われる
- HTTP APIとして完結 — Distill、Extract、BatchでMarkdown、構造化JSON、非同期URLセットをカバー
- Batchモード により、数ページを超えるような複数URLの非同期ジョブに対応
- スキーマ型抽出 により、項目単位の検証や保守の手間は減るが、完全にはなくならない
課金単位: Distill と Extract は、プロキシ帯域ではなく、文書化されたページ単位で課金されます。単位やプランは変更される可能性があるため、予算策定前に最新の Thunderbit料金ページ とAPIドキュメントを確認してください。
向いている用途: 検証済みの構造化データをすぐに使いたい開発者で、自前でプロキシローテーション＋パーサーのパイプラインを作りたくない場合。
従来型のプロキシAPIが有利な場面: カスタムパイプライン用の生HTML、バルクアーカイブ、HTTP以外のプロトコルが必要な場合。Thunderbit の構造化出力モデルはその用途には向きません。そうした場合は、次の9製品のいずれかが本命です。
プロキシを使わずAI駆動の抽出へ Thunderbit のエージェント型ウェブスクレイパーは、レンダリングやボット対策の壁も自分で処理するため、多くの作業で別のプロキシAPIが不要になります。 Get Started Free
2. Bright Data
Bright Data は、この業界で最も“既成の主流”に近い存在です。住宅向け、データセンター、ISP、モバイルの各プロキシネットワークに加え、Web Unlocker という別のマネージド製品もあります。この「別」という点が重要です。Bright Data は単一製品ではなく製品群であり、どれを買うかによって価格と挙動がかなり変わります。
Residentialネットワークのドキュメントには、国・地域・都市・ZIP・ASNによるターゲティングが記載されています。Web Unlocker は別のマネージド層で、成功課金と月額支出上限が用意されています。これらは便利な制御ですが、精度や適合性は購入者側のパイロットで検証する必要があります。このガイドでは、横断的なgeoベンチマークは実施していません。
主な機能:
- 住宅向け、データセンター、ISP、モバイルの各プロキシタイプと、細かい地域ターゲティング
- Web Unlocker のマネージドAPI、成功課金、支出上限
- 住宅IPのための、オプトインに基づく調達方針の文書化
- トラブルシュート用のデバッグ項目（リクエストID、課金状態、接続先国）
課金単位: 生のプロキシ製品と Web Unlocker では単位が異なります。予算を組む前に、正確な製品、契約条件、対象の適格性、最新料金を公式料金ページで確認してください。
向いている用途: すべてのプロキシタイプが必要で、規模拡大の代わりに少し複雑な製品構成を受け入れられるエンタープライズチーム。
3. Oxylabs
Oxylabs は Bright Data と同じ重量級に位置づけられます。住宅向け、データセンター、ISP、モバイルの各プロキシネットワークに加え、マネージドアクセス用の Web Unblocker も提供しています。セッション管理には専用の X-Oxylabs-Session-Id ヘッダーを使うため、ページ送りのある検索結果のような複数ステップのフローでもIP継続性を保てます。これはかなり便利です。
主な機能:
- ベンダーが文書化したgeo制御付きの複数プロキシタイプ
- JavaScriptレンダリングとマネージド解除用の Web Unblocker。現行料金ではGB課金
- ヘッダーベースのセッションIDによるセッション維持
- デバッグ用のジョブ／セッションヘッダーがサンプルレスポンスに含まれる
課金単位: 今回確認した Web Unblocker ページでは、プランごとのレート制限を伴うGBベースの料金体系でした。ほかの Oxylabs 製品は別単位です。選択した製品の最新ページを再確認してください。
向いている用途: geo分散が必要で、GB課金の製品群を横断して管理することを厭わない大規模運用。
4. ScrapingBee
ScrapingBee はマネージドHTML APIです。URLを送るとページ内容が返り、下流の検証とパースは基本的に利用者側の責任として残ります。ドキュメントでは、機能依存のクレジット制度、Auto-Mode、コストヘッダー、そして個々の Auto-Mode リクエストの上限を抑える max_cost パラメータが公開されています。
主な機能:
- 成功するまでプロキシ階層やレンダリング設定を自動で段階的に上げる Auto-Mode
- リクエストごとの支出を抑える
max_costパラメータ - すべての設定で失敗した Auto-Mode 試行はクレジット消費ゼロ
- すべてのレスポンスに使用量／コストヘッダーがあり、リアルタイム追跡が可能
課金単位: クレジット数は、レンダリング、プロキシ階層、その他有効化された機能によって変動します。ベースプランを1リクエストあたりの固定価格とみなすのではなく、現在のクレジット体系と同時実行上限を確認してください。
向いている用途: 素早い立ち上げを重視する小〜中規模案件。仕組みを理解すれば、クレジット体系はかなり予測しやすくなります。
5. ZenRows
ZenRows は、Universal Scraper API、Scraping Browser、住宅向けプロキシを一体で提供し、JavaScriptレンダリングやプレミアムプロキシ利用にはリクエスト倍率がかかります。はっきり注意しておきたい癖が一つあります。ZenRows は HTTP 404 と 410 を課金上は「成功」として数えるのです。これは、ベンダーの請求書における「成功」と、自分のバリデータにおける「成功」が同じではないことを思い出させてくれます。
主な機能:
- スクレイパーAPI、ブラウザ自動化、住宅向けプロキシを統合したツール群
- JSON、Markdown、スクリーンショット、プレーンテキストなど、複数の出力形式をうたう
- マネージドレンダリングとアクセス制御。実際の挙動は許可された対象で検証が必要
- URLベースの使用上限に達すると、追加容量を購入するまでリクエストが停止
課金単位: JavaScriptレンダリングやプレミアムプロキシなどの機能に応じた倍率付きのリクエストクレジット。現在のプランと倍率ルールを確認してください。
向いている用途: スクレイパーAPI、ブラウザ、プロキシ製品を1社で比較検討したいチーム。ただし、選んだ各製品は必ず許可済み対象でテストすること。
ここまでで見えてきた傾向
5製品を見ただけでも、製品の境界がマーケティング文句と完全には一致していないことが分かります。Bright Data と Oxylabs はどちらも「生のプロキシ」と「マネージド解除」を別製品・別料金に分けています。つまり、ベンダーのトップページを見ただけでは「結局いくらかかるのか」は分かりません。先に製品を選ぶ必要があります。ScrapingBee と ZenRows はどちらもクレジット課金で、機能に応じて倍率が上がる仕組みです。GB課金より透明ではありますが、何が倍率を発生させるのかを細部まで読む必要はあります。
もう一つの共通テーマは、「成功したリクエスト」の定義はベンダーが決める、ということです。ZenRows が 404 を課金上の成功として数えるのは悪意ではありません。単なる定義の不一致です。ただし、「成功課金」と書いてあるから「必要なデータがちゃんと取れた」という意味だと思い込むと痛い目にあいます。
6. Scrape.do
Scrape.do は、"Successful API Credits" という課金モデルのマネージド Web Scraping API を提供しています。課金対象は現在のコアエンドポイントのみです。なぜなら、同社の料金ナビゲーションでは、単独のプロキシ製品とスクレイピングブラウザ製品はどちらも「coming soon」と表示されているからです（Scrape.do が今すぐ生のプロキシを売っていると思い込む前に確認する価値があります）。APIの範囲には、geoターゲティング、セッション、ヘッダー、Cookie、ブラウザ／プロキシモード切替が含まれます。
主な機能:
- 月額上限に達するとリクエストが停止するクレジット課金（標準では想定外の超過請求なし）
- 対象条件を満たす場合に使えるプレミアムネットワーク切替
- 実際のワークロードで試すべきセッション／geo制御
- JavaScriptの多いページ向けのブラウザレンダリングモード
課金単位: 月額上限付きの成功APIクレジット。現在のプラン上限、同時実行、追加容量のルールを確認してください。
向いている用途: GB課金を避けつつ、マネージドAPIを使いたい予算重視のチーム。
7. Smartproxy / Decodo
Smartproxy は Decodo にブランド変更されました。現行の住宅向けプロキシ料金ページには、GB課金と従量課金プラン、ASNレベルのターゲティング、HTTP(S)/SOCKS5 上でのローテーティングセッションと固定セッションの両方が掲載されています。取得したページでは、表示性能の主張の出典として Proxyway の調査が引用されています。この出典は背景として有用ですが、同じ結果が別の対象、地域、時間帯、アカウント構成でも再現されることを示す証拠ではありません。
主な機能:
- 住宅向け、データセンター、ISP、モバイルの各プロキシタイプ
- ASNおよび位置レベルのターゲティング
- HTTP(S) と SOCKS5 によるローテーション／固定セッション対応
- 自社申告ではなく第三者調査に基づく性能主張
課金単位: 今回確認した住宅向けページでは、GB課金と従量課金の選択肢が示されていました。選択した製品ページで最新料金と含まれる制御項目を確認してください。
向いている用途: エンタープライズ価格までは不要で、EC監視や中規模運用のためにプロキシの選択肢を広く持ちたい場合。
8. Scrapfly
Scrapfly は、オプション機能として Anti Scraping Protection（ASP）を備えたマネージドスクレイピングAPIです。公式ドキュメントには、対象側の防御は変化し続けること、ブロック後の復旧にかかる時間は不確定であること、リソース関連のコストは変動しうることが明記されています。この注意書きは重要です。マネージドアクセスは、持続的なアクセスを保証するものではありません。
主な機能:
- 対象の難易度に応じてコストが動的に上がるASP
cost_budgetパラメータと、失敗スクレイプの公平性保護（除外ステータスコードはカウントされない）- レスポンス単位のコストヘッダーと、リクエスト再生／デバッグ用ダッシュボード
- オプションのブラウザレンダリングと住宅向けプロキシプール
課金単位: プロキシプール、レンダリング、ASP設定によって変動するクレジット。レスポンスヘッダー、cost_budget、プロジェクト制限でコストを測定・制御できます。
向いている用途: アンチ検知ツールを特に重視し、各リクエストの実際のクレジットコストを可視化したいチーム。
9. Zyte
Zyte（昔からこの分野を見てきた人には Scrapinghub のほうが通じるかもしれません）は、リクエストに応じて生のHTTPレスポンス、ブラウザレンダリング済みHTML、スクリーンショット、あるいは自動抽出された構造化オブジェクトを返せるAPIを提供しています。料金は一律ではなく、対象／リクエスト階層ごとに設定されます。ほかのいくつかのツールと同様、失敗レスポンスやレート制限されたリクエストには課金されません。
主な機能:
- HTTP、ブラウザ、スクリーンショット、自動抽出の複数出力モード
- Python 開発者向けの Scrapy とのネイティブ統合
- 事前に設定できる支出上限とブロック閾値
- サイト難易度に応じた対象／リクエスト階層ベースの課金
料金: 従量課金あり。正確な料金は対象階層によって異なります。
向いている用途: マネージドのHTTP／ブラウザ／抽出APIが必要で、特に Scrapy をすでに使っているチーム。対象との適合性と階層の安定性はパイロットで確認してください。
10. Apify
Apify は、厳密にはプロキシAPIというより、スクレイピングのフルプラットフォームです。計算資源、既製の「Actors」（同社のパッケージ済みスクレイパーの呼称）、スケジューリング、データセット保存、プロキシサービスがすべてまとまっており、それぞれが個別課金されます。よく使うサイト向けの既製スクレイパーのマーケットプレイスを求めているなら便利ですが、単にプロキシだけ欲しかった人にとっては、プラットフォームを渡される形になってしまい、やや複雑です。
主な機能:
- よくあるスクレイピング対象向けの既製Actorsのマーケットプレイス
- 住宅向け、データセンター、SERP向けプロキシサービスを1コンポーネントとして利用可能
- ワークフロー自動化向けのスケジューリング、データセット保存、Webhook対応
- 失敗リクエストのデバッグに使える詳細な診断用プロキシステータスコード
課金単位: 前払いのプラットフォーム利用料には、計算資源、Actor、プロキシ、データセット、保存容量の個別料金が含まれます。プロキシの項目だけでなく、ワークロード全体を見積もってください。
向いている用途: 生のプロキシ制御よりも、既製スクレイパーとワークフロー自動化を重視するチーム。
見えにくいコスト問題: 有効結果1件あたりのコストで見る
表示価格は、あくまで分子の一部にすぎません。本当に見るべき分母は、送信リクエスト数でも、転送バイト数でも、HTTP 200 の件数でもありません。自分の意味的バリデータを満たした出力件数です。
パイロットの前に、測定方法を決めておきましょう。
cost_per_1,000_valid = total_pilot_cost / valid_results * 1,000
total_pilot_cost には、候補ごとに実際に差が出るコストを含めます。つまり、リクエスト／ネットワーク単位、レンダリングやプレミアムルーティングの倍率、リトライ、パース、計算資源、保存、監視、運用時間です。valid_results には、必要な項目が揃っており、ロケールが正しく、鮮度も許容範囲で、チャレンジページや同意ページをコンテンツのふりをして返していないレスポンスだけを数えます。
あえて仮説的な例を考えてみましょう。Provider A はテストバッチに 3.00 ドルかかり、有効レコード600件を返しました。Provider B は 3.50 ドルで、有効レコード950件でした。正規化すると、それぞれ 1,000件あたり 5.00ドル と約 3.68ドル です。これは計算例にすぎず、どのベンダー、対象カテゴリ、防御システムについての主張でもありません。
Thunderbit のような抽出APIの場合は、生HTMLではなくスキーマ型データを受け取る価値とコストを含めて考えます。生のプロキシの場合は、下流のパーサー保守や運用工数も含めます。どちらの境界が普遍的に安いわけでもありません。答えは、そのワークロードが実際に必要とする出力次第です。
AIベースの抽出が、セレクタベースのスクレイピングとどう違うのかをもっと深く知りたいなら、AI web scraping の解説で仕組みを確認できます。
プロキシAPI vs. AIスクレイピングAPI：そもそもプロキシが必要ですか？
このテーマの上位記事はどれも、「読者はプロキシが必要だ」と前提しています。しかし、その前提自体を疑うものはありません。オンラインでは、そもそも生HTMLが必要なのか、それとも欲しいのはデータなのか、というもっと基本的な問いをしている人が増えているのに、少し不思議です。
| 観点 | 従来のプロキシAPI | AIスクレイピングAPI（例: Thunderbit） |
|---|---|---|
| 返ってくるもの | 自分でパースする生HTML | スキーマに一致した構造化JSON |
| マネージドアクセスの挙動 | プロキシ／クライアント構成、または別のマネージド製品が管理 | 抽出サービスの一部として、文書化された制限の対象 |
| パース／抽出 | 自分でパーサーを構築・保守する | AIがスキーマに従って項目を抽出する |
| レイアウト変更時の保守 | セレクタとパーサー変更を自分たちで担当 | 抽出ロジックの多くはサービス側だが、出力検証は自分たちで行う |
| 向いている用途 | 大量HTMLアーカイブ、カスタムパイプライン、特殊プロトコル | 構造化データ、RAG取り込み、リード一覧 |
| 統合の境界 | プロキシエンドポイントまたはプロバイダーAPI | Distill、Extract、Batch のようなHTTP抽出エンドポイント |
率直に言うと、もしパイプラインが本当に生HTML、プロキシレベルのセッション制御、あるいはカスタムのリクエストスタックを必要とするなら、従来型のプロキシAPIが適切な境界かもしれません。逆に、必要な成果物が構造化された商品データ、リードレコード、スプレッドシートや検索パイプラインにそのまま使える検索結果なら、抽出APIのほうが、ルーティング・レンダリング・抽出を1つのサービス境界にまとめてくれます。これは、どちらかが常に優れていると証明するものではなく、判断軸を整理し直すものです。
特にリード獲得や構造化レコードを求めるチームには、AI lead generation と AI for sales のガイドが、構造化行を自然な出力とするワークフロー例を示しています。
本当にプロキシが必要か確認する 無料プランでは月6ページまで使えます。プロキシ容量を買う前に、Thunderbit の組み込みレンダリングで対象サイトに対応できるか試してみてください。 Get Started Free
コンプライアンスと調達の確認も評価に含める
技術的にアクセスできることと、許可されていることは別問題です。パイロット前に、組織が収集を許可されているURL、必要なデータ項目、保持ルール、プライバシー上の義務、適用される対象サイトの利用規約、そしてエスカレーション責任者を文書化してください。プロキシの契約だけでは、その権限は広がりません。
住宅向けネットワークでは、ベンダーに現在の調達・同意文書、対象の適格性ルール、本人確認やKYC要件、監査証跡、IPレンジや対象が利用不可になった場合の対応手順を求めてください。ベンダー公式の説明は有用な証拠ですが、独立したサプライチェーン監査ではありません。
パイロット中は、必要に応じて地域やASNの観察結果を記録しますが、単一の確認でネットワーク全体の調達元を証明できるとは考えないでください。差異があれば、ベンダーと購買部門への確認事項として扱います。許可条件が変わる、ポリシー確認で失敗する、リトライ上限に達する、予算上限に触れるといった場合は、その時点で停止してください。
抽出サービスやプラットフォームサービスでも、調達とアクセスの責任が消えるわけではありません。別のサービス境界の向こう側に隠れるだけです。購入側は、契約、利用可能ポリシー、失敗時の挙動、データ取り扱いを依然として確認すべきです。このガイドは技術評価の指針であり、法的助言ではありません。
一覧で見る比較
| ツール | 製品境界 | 一般的な出力 | 確認すべき課金単位 | パイロットでの確認ポイント |
|---|---|---|---|---|
| Thunderbit | 抽出API | Markdown またはスキーマ型JSON | ページ単位 | 必要項目は対象テンプレートをまたいで有効か |
| Bright Data | 生プロキシ群＋マネージドUnlocker | 接続、生コンテンツ、またはマネージド出力 | 製品によりトラフィックまたは成功リクエスト | ワークロードに必要な正確な製品とgeo制御は何か |
| Oxylabs | プロキシ群＋Web Unblocker＋スクレイパーAPI | 接続またはマネージドコンテンツ | 製品ごと。確認時のUnlockerページはGBベース | レスポンスサイズとセッション継続性はコストにどう影響するか |
| ScrapingBee | マネージドHTML API | HTML | 機能依存クレジット | どの構成で成功し、有効ページ1件あたりのコストはいくらか |
| ZenRows | スクレイパーAPI、ブラウザ、住宅向けプロキシ | ベンダー定義の複数形式 | 機能倍率付きリクエスト | 404/410の課金定義はバリデータとどう噛み合うか |
| Scrape.do | マネージド Web Scraping API | ページ内容 | 成功APIクレジット | プレミアム、geo、セッション、ブラウザ制御はワークロードに合うか |
| Decodo | プロキシ／スクレイピング製品群 | 接続または製品固有の出力 | 確認時の住宅向けページではGBまたは従量課金 | 位置、ASN、プロトコル、固定セッション制御は十分に正確か |
| Scrapfly | マネージドスクレイピングAPI | ページ内容、ブラウザ出力、任意の抽出 | 機能依存クレジット | コスト予算、ログ、失敗保護は想定どおり動くか |
| Zyte | マネージドHTTP、ブラウザ、抽出、Scrapyインターフェース | HTTP、レンダリングHTML、スクリーンショット、オブジェクト | 対象／リクエスト階層＋オプション | 階層は安定しているか、リクエストモードの制限は実装に合うか |
| Apify | スクレイピングプラットフォーム＋マーケットプレイス＋プロキシ | Actor またはクローラーデータセット | 計算資源、Actor、プロキシ、保存、データセット料金 | ワークフロー上の価値は、プラットフォーム全体コストに見合うか |
上記のカテゴリと課金単位は、2026年8月10日に確認した公式ページに基づいています。プラン、上限、名称、機能倍率は変わる可能性があるため、予算化の前に必ず最新の製品を確認してください。
判断フロー：実際には何をスクレイピングするのか？
プロキシ関連のフォーラムで最も多い質問は、「どれが一番いいのか分からない。おすすめは？」というものです。そこにありがちな一般論の一覧が続いても、実際の答えにはなっていません。ここでは、もう少し実際の判断手順に近い形を試してみます。
必要な出力は何ですか？
- プロトコル制御、生レスポンス、カスタムヘッダー、自前パーサーが必要？ → 生プロキシ製品を候補に。
- ブラウザや再試行層を自分で運用せずにレンダリング済みHTMLが必要？ → マネージドスクレイピングAPIやブラウザAPIを候補に。
- 検証済み項目、レコード、Markdownが必要？ → Thunderbit の Distill と Extract を含む抽出APIを候補に。
- スケジューリング、保存、マーケットプレイスのジョブ、チーム運用が必要？ → スクレイピングプラットフォームを候補に。
譲れない制御項目は何ですか？ 必要な地域、セッション時間、ローテーション挙動、HTTPメソッド、Cookie、ヘッダー、レンダリング、スクリーンショット、データ形状、同時実行、ログ、支出停止条件を書き出してください。必須条件を満たせない候補は、好みを試す前に外します。
どれくらいのボリュームですか？ 一般的なページ数の目安でベンダーを選ばないでください。ボリュームは、レスポンスサイズ、同時実行、機能倍率、有効結果率、契約条件、エンジニアリング負荷と相互に影響します。対象テンプレートの組み合わせを見積もり、代表的な同時実行数でパイロットを回しましょう。
生HTMLか、構造化データか？ ここが最大の分かれ目です。カスタムパイプライン用に生HTMLが必要なら、プロキシ系またはマネージドHTML系を試します。納品物が検証済み行、JSON、Markdownなら、無理にプロキシ同士を比較せず、抽出境界を別カテゴリとして試してください。
独自の重み付きスコアカードを作る
機能一覧だけでは判断できません。性能とコストは対象セットと構成によって変わるからです。自分の要件とパイロット結果からスコアカードを作ってください。以下の重み欄はあえて空欄にしています。
| 評価項目 | あなたの重み | Provider A の点数 (1–5) | 根拠 | Provider B の点数 (1–5) | 根拠 |
|---|---|---|---|---|---|
| 有効結果率 | |||||
| 有効結果1件あたりのコスト | |||||
| 出力の適合度 | |||||
| geo／セッション／リクエスト制御 | |||||
| 可観測性と予算制御 | |||||
| コンプライアンスと調達根拠 | |||||
| サポートと運用面の適合 | |||||
| エンジニアリングと保守負荷 | |||||
| 合計 | 100 |
1〜5点のスコアは、根拠がある場合だけ使ってください。「該当なし」はゼロと区別しましょう。結果の横に重みを公開すると、どの前提が判断を左右したかを同僚が確認できます。
以下の短いPython例は、欠損や不正入力があれば安全側で失敗します。30回という最小試行数はチュートリアル上のガードレールであり、普遍的な統計的サンプルサイズの主張ではありません。
from dataclasses import dataclass
@dataclass(frozen=True)
class PilotResult:
attempts: int
valid_results: int
request_cost: float
engineering_cost: float = 0.0
def cost_per_1000_valid(self) -> float:
if self.attempts < 30:
raise ValueError("このチュートリアルでは、パイロットは最低30回の試行が必要です")
if not 0 < self.valid_results <= self.attempts:
raise ValueError("valid_results は 1 以上 attempts 以下である必要があります")
if self.request_cost < 0 or self.engineering_cost < 0:
raise ValueError("コストは負の値にできません")
total = self.request_cost + self.engineering_cost
return total / self.valid_results * 1000
def weighted_score(weights: dict[str, float], scores: dict[str, float]) -> float:
if set(weights) != set(scores):
raise ValueError("重み付き評価項目にはすべてスコアが必要です")
if abs(sum(weights.values()) - 100.0) > 1e-9:
raise ValueError("重みの合計は100でなければなりません")
if any(not 1 <= score <= 5 for score in scores.values()):
raise ValueError("スコアは1〜5の範囲でなければなりません")
return sum(weights[name] * scores[name] for name in weights) / 100
少なくとも2回、条件を固定したうえで、時間を変えて実施してください。各試行では、対象グループ、地域、設定、ステータス、意味的バリデータの結果、レイテンシ、リトライ回数、課金単位、バイト数、リクエストまたはジョブID、無効になった理由を記録します。大きな導入では、チームのリスク許容度と対象の多様性に見合うサンプルが必要です。チュートリアルの下限だけでは足りません。
スクレイピング全般が初めてで、ベンダー比較に入る前に基礎を押さえたいなら、web scrapingとは何か と ノーコードでのweb scraping の入門記事がおすすめです。
プロキシAPIを選ぶというのは、実は「どのベンダーが一番か」を決める話ではありません。自分の出力要件に合う製品境界はどれかを見極め、そのうえでベンダーの宣伝文句が実データで本当に通用するかをパイロットで確かめる話です。10社、4つの製品カテゴリ、そして1つの式（有効結果1件あたりのコスト）を使えば、かなりのところまでたどり着けます。最後の一歩は、他人のベンチマークを信じるのではなく、自分で試すことです。
もし本当の目的が、パース前提のHTMLの山ではなく構造化データなら、ThunderbitのChrome拡張 やAPIを候補に入れ、パイロット前に現在の試用条件やプラン上限を確認してください。ThunderbitのYouTubeチャンネル でも製品の使い方を紹介していますが、あくまでデモであり、独立したベンチマーク証拠ではありません。
Thunderbit のエージェント型ウェブスクレイパーを試す Get Started Free
さらに詳しく
FAQ
1. プロキシネットワークとスクレイピングAPIの本当の違いは何ですか？
生のプロキシネットワークは、IPとルーティング制御を提供しますが、レンダリング、リトライ、パースは自分で行う必要があります。スクレイピングAPI（マネージド型でもAI型でも）は、そのライフサイクルのより多くを引き受け、製品に応じてHTML、JSON、Markdownを返します。両者は互換ではなく、価格を直接比べても、たいてい誤解を招く結論になります。
2. 本当に意味のある「成功率」はどう測ればいいですか？
HTTP 200 を成功と数えないでください。成功の定義を「本当に必要なコンテンツや項目が正しく存在していたこと」にし、ベンダーのデモサイトではなく、自分の実対象の代表サンプルで試します。
3. 成功リクエストあたりのコストはどう計算しますか？
表示価格（1リクエストあたり、またはGBあたり）を、自分の対象で測った成功率で割ります。成功率が低い安価なベンダーは、リトライを含めると結果的に高くつくことがあります。プランに申し込む前に計算しましょう。
4. 生HTMLではなく構造化データが欲しいだけなら、プロキシAPIは必要ですか？
必ずしも必要ではありません。Thunderbit のような抽出APIは構造化JSONを返し、レンダリングやルーティングをサービス境界の内側に隠せるため、この用途では別途生プロキシを買わずに済むことがあります。対象サポートと項目の妥当性は必ずテストしてください。生レスポンスやプロキシレベルの制御が必要な場合は、従来型プロキシ製品が適切なカテゴリです。
5. 申し込み前に、IPの調達元についてベンダーに何を聞くべきですか？
住宅IPの同意と調達の文書、利用可能な用途の方針、コンプライアンス証跡、監査可能性、サブネットや対象が使えなくなった場合の対応手順を確認してください。リスクが高い場合は、一次情報を購買部門や法務に確認してもらうべきです。それは独立したサプライチェーン監査ではありません。
