「おすすめProxy API」系のまとめ記事には、毎回同じ落とし穴があります。Bright Data、Thunderbit、Apify を、まるでまったく同じ仕事を争っているかのように並べてしまうことです。でも、実際はそうじゃありません。ある製品はルーティング済みのIP接続を提供し、別の製品は構造化JSONを返し、さらに別の製品は定期実行のスクレイピングワークフローを回します。これらを単一の初期価格で比べるのは、庭用ホースと浄水施設を値札だけで比べるようなものです。
このガイドでは、2026年8月10日に取得した公式ドキュメントをもとに、Proxy、マネージドスクレイピング、抽出、プラットフォーム系の10製品を整理します。万能の勝者を決めたり、他社でも使い回せる成功率の主張を繰り返したりはしません。代わりに、「有効結果」をどう定義するかを決め、カテゴリごとに候補を絞り、あなた自身の対象サイトで許可されたパイロットテストを行うための考え方を示します。
「Proxy API」がひとつの意味を持つとは限らない
「どのProxy APIを使うべきか」という議論が噛み合わない最大の理由は、この言葉が少なくとも4種類のまったく違う製品を指しているからです。
生のProxy ネットワーク は、IPとルーティング制御だけを提供します。実際のリクエスト処理、リトライ、必要ならJavaScriptのレンダリング、返ってきた内容のパースは、すべて自分で実装します。これはProxyの教科書的な定義に最も近いものです。RFC 9110 では、Proxyはクライアントが利用を選ぶメッセージ中継の仲介者にすぎないと説明されています。
マネージドのブロック回避／ブラウザAPI は、リクエストのライフサイクルをより多く引き受けます。URLを送ると、どのIPを使うかを選び、必要に応じてページをレンダリングし、失敗時には再試行し、HTML・スクリーンショット、場合によってはMarkdownを返します。
抽出API は、さらに一段上の層です。自分でパースする生のHTMLではなく、構造化されたJSONや整形済みテキストを受け取ります。
スクレイピングプラットフォーム は、これらすべてに加え、スケジューリング、保存機能、そして多くの場合は既製スクレイパーのマーケットプレイスまで備えています。
「Proxy APIを選ぶ」という記事でこの違いが重要なのは明快です。価格も「成功率」も、これらのカテゴリ間ではそのまま比較できません。トラフィック課金の住宅向けネットワークと、リクエスト課金のマネージドAPIは、そもそも解いている課題が違います。分母も、含まれる作業範囲も、出力の意味も異なるため、表面上の価格ランキングは誤解を招きます。そこで、以下の各プロファイルではまず製品カテゴリを明示します。
先にもう1つ大事なことを言っておくと、Proxyにアクセスできるからといって、何でも好きにスクレイピングできるわけではありません。許可、対象サイトの利用規約、データプライバシー上の義務は、「どのベンダーが最大のIPプールを持つか」とは別の話です。どれほど優れたProxy APIでも、その前提を消してはくれません。
10の選択肢をどう評価するか
すべてのチームに通用する固定の重み付けなど、正直ありません。生HTMLのアーカイブ、地域依存の価格監視、構造化データの補完ワークフローでは、必要な条件が違います。まずは次の評価軸を使い、合計が100になるように重みを設定し、自分のパイロット結果または文書化された要件だけを基準に採点してください。
| 評価軸 | 測るべき内容 |
|---|---|
| 有効結果率 | HTTP 200 ではなく、意味的バリデーターを通過した試行の割合 |
| 有効結果あたりのコスト | リクエスト、トラフィック、レンダリング、リトライ、パース、保存、運用コストを有効出力数で割った値 |
| 出力の適合性 | 生レスポンス、レンダリング済みHTML、スクリーンショット、Markdown、スキーマ形状のデータ |
| 接続・地域制御 | 実際に必要なリージョン、都市、ASN、セッション、ローテーション、ヘッダー、Cookie、プロトコルの制御 |
| 可観測性と制限 | リクエストID、課金単位ヘッダー、ログ、再生、同時実行制御、予算停止 |
| コンプライアンスの証拠 | ソーシングに関する説明、契約、対象適格性、監査可能性、サポート手順 |
| 実装負荷 | 統合、パーサー保守、監視、手動修復にかかる時間 |
サポートされていない項目は空欄のままにするか、「該当なし」と記入してください。目的は、ワークロード固有の判断を下すことです。見せかけの精度を作ることではありません。
1. Thunderbit
Thunderbit は、この一覧の中では少し異色です。HTTPクライアントに差し込む生のProxyネットワークではなく、抽出に近いAPIだからです。公開APIドキュメントでは、Markdown向けのDistill、スキーマ形JSONを返すExtract、URLセットを非同期で処理するBatchが案内されています。欲しい出力がコンテンツやレコードであれば、この境界設計によって下流の工程をいくつも省けます。
実際の違いは、リクエストを投げた瞬間にわかります。従来のProxy APIでは、成功しても返るのは生のHTMLです。仕事の半分が終わっただけです。一方、Thunderbit の POST /extract エンドポイントでは、対象URLと、欲しい項目を定義したJSON Schemaを送ると、返却されるのはそのスキーマに一致した構造化済みJSONです。CSSセレクターを書く必要もなく、Q3に商品ページのデザインが変わったときにパーサーを保守し続ける必要もありません。
この製品境界こそが、実務上の強みです。呼び出し側は、別途Proxy・レンダラー・パーサーのスタックを維持するのではなく、出力スキーマを指定するだけで済みます。ただし、実運用前には必ずパイロットが必要です。許可されたURLに対して、項目の充足率、対象サイト対応、レイテンシ、現在のユニット消費、同時実行数、失敗時の挙動を検証してください。
主な特徴:
- 最初から構造化出力 — 自分で定義したスキーマに一致するJSONを返し、生HTMLではない
- 文書化されたレンダリングとルーティング制御 — 生Proxy製品ではなく、抽出エンドポイントの一部として評価できる
- HTTP APIの境界 — Distill、Extract、Batch が Markdown、構造化JSON、非同期URLセットをカバー
- 非同期の複数URL処理に対応するBatchモード — 数ページを超える処理に便利
- スキーマ形抽出 により、項目単位の検証や保守の手間を減らせるが、完全にはなくならない
課金単位: Distill と Extract は、Proxy帯域ではなく、文書化されたページ単位のユニットを使います。ユニットやプランは変わる可能性があるため、予算を組む前に最新の Thunderbit pricing とAPIドキュメントを確認してください。
向いている用途: 検証済みの構造化データをすぐに使いたい開発者、そしてProxyローテーション＋パーサーのパイプラインを自前で作りたくない人。
従来のProxy APIのほうが有利な場面: カスタムパイプライン用の生HTML、バルクアーカイブ、非HTTPプロトコルが必要な場合。Thunderbit の構造化出力モデルはその用途には合いません。そういう場合は、次の9製品のどれかが本命です。
2. Bright Data
Bright Data は、この業界で最も「既存勢」に近い存在です。住宅向け、データセンター、ISP、モバイルの各Proxyネットワークに加え、Web Unlocker という別のマネージド製品を持っています。ここでの「別」は重要です。Bright Data は1つの製品ではなく複数の製品群であり、どれを買うかで価格も挙動も大きく変わります。
住宅向けネットワークのドキュメントには、国・地域・都市・ZIP・ASN のターゲティングが記載されています。Web Unlocker は別のマネージド層で、成功時課金と月間支出上限が用意されています。これらの制御は便利ですが、精度や適合性は購入者側のパイロットで必ず確認すべきです。このガイドでは、プロバイダー横断の地理ベンチマークは実施していません。
主な特徴:
- 住宅向け、データセンター、ISP、モバイルのProxy種類と細かな地理ターゲティング
- 成功時課金と支出上限を備えた Web Unlocker のマネージドAPI
- 住宅IP向けのオプトイン型ソーシング説明を文書化
- トラブルシュート用のデバッグ項目（リクエストID、課金状態、接続先国）
課金単位: 生Proxy製品と Web Unlocker では単位が異なります。予算化する前に、正確な製品、契約条件、対象適格性、最新レートを公式価格ページで確認してください。
向いている用途: すべてのProxy種別が必要で、規模と引き換えに少し複雑な製品ラインでも運用できるエンタープライズチーム。
3. Oxylabs
Oxylabs は Bright Data と同じ重量級です。住宅向け、データセンター、ISP、モバイルのProxyネットワークに加え、マネージドアクセス用の Web Unblocker という別製品を提供しています。セッション管理では専用の X-Oxylabs-Session-Id ヘッダーを使うため、一定時間IPを維持できます。これはページネーションのある検索結果のような複数ステップ処理でとても便利です。
主な特徴:
- ベンダー文書で地理制御が案内された複数のProxy種類
- JavaScriptレンダリングとマネージドブロック回避のための Web Unblocker。現行価格はGB課金
- ヘッダーベースのセッションIDによる継続性
- デバッグ用のジョブ／セッションヘッダーをサンプルレスポンスに含める
課金単位: 今回調査時に取得した Web Unblocker のページではGBベースのプランが使われており、プランごとのレート制限もありました。他の Oxylabs 製品は別の単位です。選んだ製品の最新ページを再確認してください。
向いている用途: 地理的な多様性が必要で、製品をまたいだGB課金の管理を厭わない大容量運用。
4. ScrapingBee
ScrapingBee はマネージドHTML APIです。URLを送るとページ内容が返り、下流の検証とパースは基本的に自分で行います。ドキュメントでは、機能依存のクレジット体系、Auto-Mode、コストヘッダー、そして個々の Auto-Mode リクエストの上限を決められる max_cost パラメータが公開されています。
主な特徴:
- 設定を自動的に段階的に上げて成功まで試す Auto-Mode（Proxy階層やレンダリングを自動調整）
- 1回のリクエストごとの支出を抑える
max_costパラメータ - すべての構成で失敗した Auto-Mode 試行はクレジット消費ゼロ
- リアルタイム把握のための利用量／コストヘッダー
課金単位: クレジットは、レンダリング、Proxy階層、その他有効化した機能で変わります。ベースプランを単なる1リクエスト単価として扱うのではなく、現行のクレジット階段と同時実行制限を確認してください。
向いている用途: 細かなカスタマイズよりも、素早いセットアップを重視する小〜中規模プロジェクト。仕組みを理解すれば、クレジット体系によりコスト予測はかなりしやすくなります。
5. ZenRows
ZenRows は、Universal Scraper API、Scraping Browser、住宅向けProxyを1つにまとめています。JavaScriptレンダリングやプレミアムProxy利用にはリクエスト倍率がかかります。ここで明確にしておきたい注意点が1つあります。ZenRows は HTTP 404 と 410 を課金上「成功」として扱います。つまり、ベンダーの請求書上の「成功」と、あなたのバリデーター上の「成功」は同じではない、という重要な教訓です。
主な特徴:
- スクレイパーAPI、ブラウザ自動化、住宅向けProxyをまとめた構成
- JSON、Markdown、スクリーンショット、プレーンテキストなどの出力形式をうたう
- マネージドレンダリングとアクセス制御。実際の挙動は許可済み対象で確認が必要
- URLベースの利用上限により、追加容量の購入までリクエストが停止される
課金単位: JavaScriptレンダリングやプレミアムProxyなどの機能に対して倍率がかかるリクエストクレジット。現在のプランと倍率ルールを必ず確認してください。
向いている用途: 1社のベンダーでスクレイパーAPI、ブラウザ、Proxy製品を比較評価したいチーム。ただし、選んだ各製品は許可済みの対象でテストしてください。
ここまでで見えてきたパターン
5製品を見ただけで、もう傾向は明らかです。ほとんどの製品は、マーケティングコピーと製品境界が完全には一致していません。Bright Data と Oxylabs はどちらも「生Proxy」と「マネージドブロック回避」を別製品・別課金モデルに分けています。つまり、ベンダーのトップページだけでは「いくらかかるか」はわからず、まずどの製品かを決める必要があります。ScrapingBee と ZenRows はどちらもクレジット制で倍率が上がる仕組みを採用しています。GB課金よりはわかりやすいものの、何が倍率を発生させるのかは細かく読む必要があります。
もう1つの共通点は、「成功したリクエスト」の定義がベンダー側にあることです。ZenRows が 404 を課金上の成功に含めるのは悪意ではありません。単なる定義のずれです。ただ、「課金上成功」と「必要なデータが実際に取れている」は別物だと理解していないと痛い目を見る、というだけです。
6. Scrape.do
Scrape.do は、"Successful API Credits" という課金モデルを持つマネージド Web Scraping API を提供しています。現在のコアAPIに対してのみ課金され、同社の価格ナビゲーションでは、単独のProxy製品やスクレイピングブラウザ製品は「coming soon」とされています（Scrape.do が今日すでに生Proxyを売っていると考える前に確認する価値があります）。APIの範囲には、地理ターゲティング、セッション、ヘッダー、Cookie、ブラウザ／Proxyモードの切り替えが含まれます。
主な特徴:
- 月間上限に達するとリクエストが止まるクレジット課金（デフォルトで想定外の超過請求なし）
- 条件を満たす対象向けのプレミアムネットワーク切り替え
- 実際のワークロードで検証すべきセッションと地理制御
- JavaScriptの多いページ向けのブラウザレンダリングモード
課金単位: パッケージ化された成功APIクレジットと月間上限。現在のプラン上限、同時実行数、追加容量のルールを確認してください。
向いている用途: GB課金に縛られず、マネージドAPIを使いたい予算重視のチーム。
7. Smartproxy / Decodo
Smartproxy は Decodo にブランド変更しました。現在の住宅向けProxy価格ページでは、ASNレベルのターゲティング、HTTP(S)/SOCKS5 でのローテーションセッションと固定セッションを備えた、GB課金および従量課金のプランが案内されています。取得したページでは、表示されている性能主張の出典として Proxyway の調査が引用されています。これは参考情報として有用ですが、同じ結果が別の対象、地域、時間帯、アカウント設定でも再現される証拠ではありません。
主な特徴:
- 住宅向け、データセンター、ISP、モバイルのProxy種類
- ASNおよび地域レベルのターゲティング
- HTTP(S) と SOCKS5 でのローテーション／固定セッション対応
- 自社申告ではなく、第三者調査に基づく性能主張
課金単位: 今回取得した住宅向けページでは、GB課金と従量課金の選択肢が案内されています。選ぶ製品ページで最新レートと含まれる制御を確認してください。
向いている用途: エンタープライズ価格までは要らないが、Proxyの選択肢はほしいEC監視や中規模運用。
8. Scrapfly
Scrapfly は、オプションの Anti Scraping Protection（ASP）機能を持つマネージドスクレイピングAPIです。公式ドキュメントでは、対象側の防御は変化し続けること、ブロック解除後の復旧にかかる時間は不確実であること、リソース関連コストは変わりうることが明記されています。この注意書きは重要です。マネージドアクセスは、長期的なアクセス保証ではありません。
主な特徴:
- 対象の難易度に応じてコストが動的に上がる ASP
cost_budgetパラメータと、失敗したスクレイプに対する公平性保護（除外ステータスコードは課金対象外）- レスポンス単位のコストヘッダーと、リクエスト再生／デバッグ用ダッシュボード
- オプションのブラウザレンダリングと住宅向けProxyプール
課金単位: Proxyプール、レンダリング、ASP構成で変動するクレジット。レスポンスヘッダー、cost_budget、プロジェクト制限で、そのコストを測定・抑制できます。
向いている用途: 対検出回避ツールを重視し、各リクエストの実コストをクレジット単位で把握したいチーム。
9. Zyte
Zyte（この分野が長い人には Scrapinghub のほうが馴染みがあるかもしれません）は、リクエスト内容に応じて、生のHTTPレスポンス、ブラウザレンダリング済みHTML、スクリーンショット、自動抽出された構造化オブジェクトを返せるAPIを提供しています。価格は一律ではなく対象／リクエスト階層ごとに設定されます。また、ここまでいくつかのツールと同様、失敗レスポンスやレート制限されたリクエストは課金されません。
主な特徴:
- HTTP、ブラウザ、スクリーンショット、自動抽出など複数の出力モード
- 既にそのエコシステムを使っているPython開発者向けの Scrapy 連携
- 事前に設定できる支出上限とブロックしきい値
- サイトの難易度に応じて変わる対象／リクエスト階層課金
価格: 従量課金あり。正確なレートは対象階層によって異なる。
向いている用途: マネージドなHTTP／ブラウザ／抽出APIが必要なチーム、特に Scrapy をすでに使っているチーム。対象への適合性と階層の安定性は、パイロットで確認する必要があります。
10. Apify
Apify は、もはや単なるProxy APIではなく、フル機能のスクレイピングプラットフォームに近い存在です。計算資源、既製の「Actors」（同社のパッケージ化スクレイパーの呼称）、スケジューリング、データセット保存、Proxyサービスがすべてまとめられており、しかも各項目が個別課金です。一般的なサイト向けの既製スクレイパーのマーケットプレイスを使いたいなら強みですが、単にProxyが欲しかっただけなら、プラットフォームまで渡されてしまうのは少し面倒です。
主な特徴:
- 主要スクレイピング対象向けの既製Actorsマーケットプレイス
- コンポーネントの1つとして利用できる住宅向け、データセンター、SERP Proxyサービス
- ワークフロー自動化のためのスケジューリング、データセット保存、Webhook対応
- 失敗リクエストのデバッグに役立つ詳細な診断用Proxyステータスコード
課金単位: 前払いのプラットフォーム利用料には、計算資源、Actor、Proxy、データセット、保存容量の個別料金が含まれることがあります。Proxyの項目だけでなく、ワークロード全体を見積もってください。
向いている用途: 生のProxy制御よりも、既製スクレイパーとワークフロー自動化を重視するチーム。
見えにくいコストの問題：有効結果あたりのコストで考える
表示価格は、あくまで分子のひとつにすぎません。実際に意味のある分母は、送信リクエスト数でも、転送バイト数でも、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ではなくスキーマ形データを受け取る価値とコストを含めて考えます。生Proxyでは、その後ろにあるパーサーや保守作業も含めます。どちらの境界が常に安いということはありません。答えは、ワークロードが実際に必要とする出力次第です。
AIベースの抽出がセレクター依存のスクレイピングとどう違うのか、もっと詳しく知りたい方は、AI web scraping の解説で仕組みを整理しています。
Proxy API vs. AIスクレイピングAPI：本当にProxyが必要ですか？
このテーマの上位記事は、たいてい読者がProxyを必要としている前提で話を進めます。でも、その前提自体を疑ってはいません。最近はオンラインで「生HTMLが本当に必要なのか、それともデータだけあればいいのか」と考える人が増えているのに、少し不思議な話です。
| 観点 | 従来のProxy API | AIスクレイピングAPI（例：Thunderbit） |
|---|---|---|
| 返ってくるもの | 自分でパースする生HTML | スキーマに一致した構造化JSON |
| マネージドアクセスの扱い | 自分のProxy／クライアントスタック、または別のマネージド製品が担当 | 抽出サービスの一部として提供され、文書化された制限の対象になる |
| パース／抽出 | パーサーを自作・保守する | AIがスキーマごとに項目を抽出する |
| レイアウト変更時の保守 | セレクターやパーサー修正は自社責任 | 抽出ロジックの多くはサービス側が持つが、出力検証は自社責任 |
| 向いている用途 | 大量HTMLのアーカイブ、カスタムパイプライン、ニッチなプロトコル | 構造化データ、RAG投入、リード一覧 |
| 統合の境界 | ProxyエンドポイントまたはベンダーAPI | Distill、Extract、Batch のようなHTTP抽出エンドポイント |
正直な結論はこうです。パイプラインが本当に生HTML、Proxyレベルのセッション制御、またはカスタムリクエストスタックを必要とするなら、従来のProxy APIが適切な境界かもしれません。必要な成果物が構造化された商品データ、リード情報、スプレッドシートや検索パイプラインにそのまま載せられる検索結果であれば、抽出APIにより、ルーティング・レンダリング・抽出を1つのサービス境界の内側に押し込めます。これは、どちらか一方が普遍的に優れていると証明するものではなく、判断の切り口を変えるためのものです。
特にリード獲得や構造化レコードが欲しいチームには、AI lead generation と AI for sales のガイドが、構造化行が自然な出力になるワークフローの例を示しています。
コンプライアンスとソーシングの確認も評価項目に入れる
技術的なアクセスと許可は別問題です。パイロットの前に、組織として収集してよいURL、必要なデータ項目、保持ルール、プライバシー義務、対象サイトの規約、エスカレーション責任者を文書化してください。Proxyを契約しただけでは、許可が広がるわけではありません。
住宅向けネットワークでは、ベンダーに最新のソーシングと同意に関する文書、対象適格性ルール、本人確認やKYC要件、監査証跡、IPレンジや対象が利用不可になった際の対応手順を確認してください。ベンダーの公式声明は有用な証拠ですが、独立したサプライチェーン監査ではありません。
パイロット中は、必要に応じてリージョンやASNの観測を記録してください。ただし、1回の確認でネットワーク全体のソーシングが証明されたと考えてはいけません。矛盾があれば、ベンダーと調達担当への確認事項として扱ってください。許可条件が変わった、ポリシーチェックに失敗した、リトライ上限に達した、予算上限が発動した、という場合は実行を止めてください。
抽出サービスやプラットフォームサービスでも、ソーシングとアクセス責任が消えるわけではありません。単に別のサービス境界の向こう側に移るだけです。購入者は、契約、利用条件、失敗時の挙動、データ取り扱いを引き続き確認すべきです。このガイドは技術評価の指針であり、法的助言ではありません。
一目でわかる比較表
| ツール | 製品境界 | 代表的な出力 | 確認すべき課金単位 | パイロットでの確認ポイント |
|---|---|---|---|---|
| Thunderbit | 抽出API | Markdown またはスキーマ形JSON | ページ単位ユニット | 必要項目は対象テンプレート全体で有効か？ |
| Bright Data | 生Proxy群＋マネージド Unlocker | 接続、生コンテンツ、またはマネージド出力 | 製品によりトラフィックまたは成功リクエスト | ワークロードに必要な正確な製品と地理制御はどれか？ |
| Oxylabs | Proxy群＋Web Unblocker＋スクレイパーAPI | 接続またはマネージドコンテンツ | 製品ごと。取得時の Unlocker ページはGBベース | レスポンスサイズとセッション継続性はコストにどう影響するか？ |
| ScrapingBee | マネージドHTML API | HTML | 機能依存のクレジット | どの構成で成功し、それは有効ページあたりいくらか？ |
| ZenRows | スクレイパーAPI、ブラウザ、住宅向けProxy | ベンダー文書にある複数形式 | 機能倍率付きのリクエスト | 404/410 の課金仕様は自分のバリデーターとどう噛み合うか？ |
| Scrape.do | マネージド Web Scraping API | ページ内容 | 成功APIクレジット | プレミアム、地理、セッション、ブラウザ制御はワークロードに合うか？ |
| Decodo | Proxyとスクレイピング製品群 | 接続または製品固有の出力 | 取得した住宅向けページではGBまたはPAYG | 位置、ASN、プロトコル、固定セッションの制御は十分に正確か？ |
| Scrapfly | マネージドスクレイピングAPI | ページ内容、ブラウザ出力、オプションの抽出 | 機能依存のクレジット | コスト予算、ログ、失敗保護は期待どおり機能するか？ |
| Zyte | マネージドHTTP、ブラウザ、抽出、Scrapy向けインターフェース | HTTP、レンダリング済みHTML、スクリーンショット、オブジェクト | 対象／リクエスト階層＋オプション | 階層は安定しているか、リクエストモード制限は実装に合うか？ |
| Apify | スクレイピングプラットフォーム、マーケットプレイス、Proxy | Actorまたはクローラーデータセット | 計算資源、Actor、Proxy、保存、データセット課金 | ワークフロー上のメリットは、プラットフォーム全体のコストに見合うか？ |
上記のカテゴリと課金単位は、2026年8月10日に取得した公式ページに基づいています。プラン、制限、名称、機能倍率は変わる可能性があるため、予算を立てる前に必ず対象製品を再確認してください。
判断フローチャート：実際に何をスクレイピングするのか
Proxy関連のフォーラムで最もよくある質問は、「どれが一番いいかわからない。おすすめは？」というものです。そして、その後に返ってくるのは、肝心の答えになっていない一般論のリストだったりします。以下は、実際の判断フローに少し近づけた試みです。
どんな出力が必要ですか？
- Proxyプロトコル制御、生レスポンス、自前ヘッダー、自作パーサーが必要ですか？ 生Proxy製品を候補に。
- ブラウザを自分で運用せず、レンダリング済みHTMLだけほしいですか？ マネージドスクレイピングAPIやブラウザAPIを候補に。
- 検証済みの項目、レコード、Markdown が必要ですか？ Thunderbit の Distill と Extract を含む抽出APIを候補に。
- スケジューリング、保存、マーケットプレイスのジョブ、チーム運用が必要ですか？ スクレイピングプラットフォームを候補に。
絶対に譲れない制御は何ですか？ 必要なリージョン、セッション継続時間、ローテーションの挙動、HTTPメソッド、Cookie、ヘッダー、レンダリング、スクリーンショット、データ形状、同時実行数、ログ、予算上限を書き出してください。テストする前に、必須条件を満たせない候補は外します。
どのくらいの量ですか？ 単純なページ数だけでベンダーを選んではいけません。ボリュームは、レスポンスサイズ、同時実行数、機能倍率、有効結果率、契約条件、実装負荷と相互作用します。対象テンプレートの構成比を見積もり、代表的な同時実行数でパイロットを回してください。
生HTMLか構造化データか？ ここが最大の分岐です。カスタムパイプライン用に生HTMLが必要なら、Proxy製品かマネージドHTML製品を試してください。成果物が検証済みの行、JSON、Markdownなら、Proxyと同列に無理やり比較せず、抽出境界という別カテゴリとして試してください。
自分用の重み付きスコアカードを作る
機能一覧だけでは決め手になりません。性能とコストは、対象セットと構成によって変わるからです。自分の要件とパイロット結果からスコアカードを作ってください。以下の重みは、あえて空欄にしてあります。
| 評価軸 | あなたの重み | Provider A の点数（1–5） | 根拠 | Provider B の点数（1–5） | 根拠 |
|---|---|---|---|---|---|
| 有効結果率 | |||||
| 有効結果あたりのコスト | |||||
| 出力の適合性 | |||||
| 地理／セッション／リクエスト制御 | |||||
| 可観測性と予算制御 | |||||
| コンプライアンスとソーシングの証拠 | |||||
| サポートと運用面の適合性 | |||||
| 実装と保守の負荷 | |||||
| 合計 | 100 |
根拠がある場合だけ、1〜5で採点してください。「該当なし」は0と区別しましょう。結果の横に重みも公開すると、どの前提が結論を左右したのかを同僚が確認できます。
以下の簡潔な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またはジョブID、無効だった理由を記録します。大きな導入では、チームのリスクと対象の多様性に応じたサンプルが必要です。チュートリアルの最低ラインでは、その設計は置き換えられません。
スクレイピング全般が初めてで、ベンダー比較に入る前に基礎を押さえたいなら、web scraping actually is の入門記事と、web scraping without coding のガイドがよい出発点です。
Proxy API選びは、本質的には「どのベンダーが一番いいか」という話ではありません。むしろ「どの製品境界が自分の出力要件に合っているか」という問題であり、そのあとに、ベンダーの宣伝文句が実際の対象で本当に通用するかをパイロットで確かめる、という流れです。10社、4つの製品カテゴリ、そして1つの式（有効結果あたりのコスト）で、だいたい必要十分な判断材料はそろいます。最後の一歩は、他人のベンチマークを信じるのではなく、自分でテストを回すことです。
もし本当に欲しいのが、パース前提のHTMLの山ではなく構造化データなら、Thunderbit の Chrome 拡張機能 かAPIを候補に入れ、パイロット前に現在のトライアルやプランの制限を確認してください。Thunderbit YouTube チャンネル でも製品の使い方を紹介していますが、あくまでデモであり、独立したベンチマーク証拠ではありません。
さらに詳しく
よくある質問
1. ProxyネットワークとスクレイピングAPIの本当の違いは何ですか？
生Proxyネットワークは、IPとルーティング制御を提供するだけです。レンダリング、リトライ、パースは自分で担当します。スクレイピングAPI（マネージド型またはAI型）は、そのライフサイクルの多くを引き受け、製品に応じてHTML、JSON、Markdownを返します。両者は交換可能ではなく、価格だけを直接比べると誤解を招きやすい結果になります。
2. 本当に意味のある「成功率」はどう測ればいいですか？
HTTP 200 を成功と数えてはいけません。成功の定義は「必要なコンテンツまたは項目があり、正しく取得できたこと」とし、ベンダーのデモサイトではなく、実際の対象群の代表サンプルでテストしてください。
3. 成功リクエストあたりのコストはどう計算しますか？
表示価格（1リクエストあたり、またはGBあたり）を、自分の対象で測った成功率で割ります。見かけ上安いベンダーでも、成功率が低ければリトライ込みでは高くつくことがあります。契約前に計算してください。
4. 生HTMLではなく構造化データだけ欲しい場合でも、Proxy APIは必要ですか？
必ずしも必要ではありません。Thunderbit のような抽出APIは構造化JSONを返し、レンダリングやルーティングをサービス境界の内側にまとめるため、そのワークフロー専用に別途生Proxyを購入する必要がなくなる場合があります。対象対応と項目の妥当性はテストしてください。生レスポンスやProxyレベルの制御が必要な場合は、従来型のProxy製品が引き続き該当カテゴリです。
5. 申し込み前に、IPのソーシングについてベンダーに何を確認すべきですか？
住宅IPの同意とソーシングに関する最新文書、利用許可ポリシー、コンプライアンス証拠、監査可能性、サブネットや対象が使えなくなった場合の対応手順を確認してください。リスクが高い場合は、一次情報を調達部門や法務で確認すべきです。独立したサプライチェーン監査ではありません。
