数週間おきに、サポートチームの誰かが見込み客からの同じ質問を私に転送してきます。"ThunderbitはScraperAPIと何が違うの？" その気持ちはよく分かります。どちらも Google で "web scraping tool" と検索すると同じあたりに出てきて、トップページには "scrape" や "scraper" の文字が並び、どちらもインターネット上のデータを取ってこれると約束しているからです。でも、Automation Anywhere でごちゃごちゃしたデータパイプラインを整理していた時期も含めて、長年自動化と AI 製品を作ってきた私からすると、この2つはまったく別の問いに答えているツールだと言えます。
これは実際のところ、"どちらが優れているか" を比べる話ではありません。引っ越し業者と秘書を比べるようなものです。どちらも仕事を助けてくれますが、片方にもう片方の仕事を任せることはないはずです。そこでここでは、ScraperAPI が実際に何なのか、Thunderbit が実際に何なのか、それぞれのリアルな費用感はどうなのか（こういう比較表が横並びで整理されているのを私はほとんど見たことがありません）、そしてどちらを選ぶべきなのかを、順番に整理していきます。曖昧な言い方や、できるだけ避けられるなら "場合による" で逃げるようなことはしません。
Thunderbit vs ScraperAPI：まずは結論をひとことで
昼休みにざっと読みたい方のために、まずは一文でまとめます。ScraperAPI は、API 経由で大規模スクレイピングを行うための開発者向けインフラです。プロキシ、CAPTCHA 対応、レンダリングを API で提供します。Thunderbit は、見ているそのページを構造化データに変換する、エージェント型のノーコード抽出レイヤーです。背後には ブラウザ拡張、Web App、Open API、MCP Server があります。
最初にこの比較表が欲しかった、という内容をまとめるとこうなります。
| ScraperAPI | Thunderbit | |
|---|---|---|
| 向いている用途 | スクレイピング基盤を構築するエンジニアリングチーム | すばやく構造化データが欲しいビジネスユーザー、マーケター、オペレーション担当、開発者 |
| 必要なセットアップ | API キー + リクエストパラメータ + 自前のパース処理 | ページ上で One Click Extract を押すだけ（ブラウザ拡張）、または Open API/MCP で自動化 |
| 出力形式 | 生の HTML/JSON、対応サイト向けの構造化パーサー | 構造化された、エクスポート可能な表 |
| コーディングの必要性 | 多くの実運用では必要 | ブラウザ操作では不要、API/CLI/MCP を使うなら必要 |
| 理想的なユーザー | 開発者または技術系オペレーションチーム | 非技術系の担当者、そしてより高速な構造化レイヤーが欲しい開発者 |
自分がどちらの立場かすでに分かっているなら、下の該当セクションに飛んでください。ScraperAPI の詳説、Thunderbit の詳説、さらに下には本当の価格比較と、"自分にはどっちが合うのか" を2分以内で判断できる決定フレームワークがあります。
ScraperAPI とは？ 開発者向けのスクレイピング基盤
ScraperAPI を一言でいうと、URL を送るとページ内容を返してくれるサービスです。その際に、スクレイピングで面倒な部分——プロキシのローテーション、失敗したリクエストの再試行、CAPTCHA やボット検知システムの回避、必要に応じた JavaScript 多用ページのブラウザ風レンダリング——を裏で処理してくれます。とはいえ、API を呼び出すコードを書いて、返ってきた内容を解析するのはあなたの役目です。
ここはとても大事な違いです。ScraperAPI は今や単なる "生 HTML しか返さない" ツールではありません。最新の機能 には、JSON の自動パースや対応サイト向けの構造化データエンドポイント、さらに大きめの作業向けの DataPipeline 製品やフルクローラー機能が含まれます。つまり、2018年のまま止まっているわけではありません。ただし、製品の根本にある前提は変わりません。つまり、あなたがその上にエンジニアリングのワークフローを組んでいる、あるいは組む予定があることです。リクエストを送り、レスポンスを確認し、再試行をアプリケーション側で処理し、結果をどこかに保存する——そんな仕組みです。
ScraperAPI が本当に強いのは、月に数十万から数百万件のリクエストを扱い、しかもボット検知で積極的に対抗してくるサイトを相手にするような、インフラ規模の仕事です。これは難しい問題ですし、プロキシ管理を本業にしている会社にそこを任せるのは、多くのエンジニアリングチームにとって賢い判断です。比較記事の中には両方向に大げさなことを書きがちなものもあるので、ここははっきり言っておきます。ScraperAPI が世界中のあらゆるアンチボットを必ず突破できるわけではありませんし、稼働率のような宣伝値もベンダー公表値であって、第三者ベンチマークではありません。まずの目安として見て、神託のように扱わないでください。
どんな人が ScraperAPI を検討すべきか？
次のような人なら、かなり相性が良いはずです。
- API リクエストを送り、レスポンスを解析するコードを書くのに抵抗がない
- 月間数万〜数百万ページ規模で本気でスクレイピングしたい
- プロキシローテーション、地域指定、アンチボット対応をリクエストパイプラインに直接組み込みたい
- ScraperAPI を "アクセス層" として組み込めるデータパイプラインをすでに持っている、または作りたい
この説明を読んでうなずけたなら、ScraperAPI は候補に残しておく価値があります。逆に、目が遠くなったなら、次の章のほうがきっと向いています。
Thunderbit とは？ エージェント型のノーコード抽出レイヤー
Thunderbit は出発点がまったく違います。抽出ロジックを自分で書く前提ではなく、抽出ロジックを Thunderbit 側が見つけます。One Click Extract を押すだけで、Thunderbit の AI が適切な項目と抽出方法を提案し、そのページを構造化データに変換してくれます。商品名、価格、連絡先、求人情報、あるいはページの主題が何であれ、それに合わせて取り出します。
このシンプルさは、Thunderbit が想定する非技術系ユーザーにとってとても大切です。Web ページからそのまま使えるスプレッドシートにするまで、クリック1回。セレクタも、スキーマ設計も、スクレイピングコードもいりません。スプレッドシートを手に入れる前に宿題を出されたい人なんて、普通いません。
Thunderbit はブラウザだけに閉じた製品でもありません。クラウド実行用の Web App、プログラムから呼び出せる Open API、Claude や Cursor のような AI エージェントに組み込むための MCP Server、ターミナルから使うための CLI もあります。つまり、主役はノーコード体験ですが、ノーコード専用ツールというわけではありません。むしろ、同じ基盤機能に入るための複数の入口を持つ構造化抽出レイヤーと呼ぶほうが正確です。
そして後でまた触れますが、Thunderbit はプロキシローテーションやアンチボット突破を目的とした製品ではありません。すでにアクセスできるページから構造化データを取り出すためのものであって、CAPTCHA の壁を大規模に突破するためのものではないのです。役割がまったく違います。
どんな人が Thunderbit を検討すべきか？
次のような人なら、かなり合っています。
- 営業、マーケティング、オペレーション、リサーチ担当で、2週間のエンジニアリングスプリントを待たずに今日中にデータが必要
- パーサーを書かずに、Excel、Google Sheets、Airtable、Notion など使える場所へデータをそのまま入れたい
- スクレイパーを書くよりボタンを押したい。これは性格の問題ではなく、単に効率の話
- コーディングはできるが、社内ツール用にもっと速い構造化出力レイヤーが欲しい開発者
仕組みの違い：アーキテクチャとワークフローを並べて比較
違いを一番わかりやすく言うなら、ScraperAPI は素材を渡してくれるが家具作りはあなた次第、Thunderbit は最初から組み立て済みの家具を渡してくれる、ということです。
内部構造を見ると、ScraperAPI はまずプロキシとレンダリングが中心です。あなたのリクエストはそのネットワークを通り、必要に応じて住宅用またはモバイルの IP に振り分けられ、JavaScript 実行が必要ならヘッドレスブラウザでレンダリングされ、HTML、JSON、または対応ドメイン向けのパース済み構造として返ってきます。その後のスキーマ設計、保存、重複排除、スケジューリングは、DataPipeline やクローラー製品を使わない限り、あなたの責任です。
Thunderbit のアーキテクチャは分析ファーストです。エージェントがページの構造と内容を読み取ってから、何を抽出するかを決めます。つまり、開発者なら通常は手で書く "スキーマ" の工程が自動で処理されます。出力は生素材ではなく、営業マネージャーにそのまま渡しても書式について謝らなくて済む表です。
比較表：コアとなる仕組み
| ScraperAPI | Thunderbit | |
|---|---|---|
| 基本モデル | API 経由のプロキシローテーション + 生 HTML/JS レンダリング | エージェントによるページ解析 → 拡張機能、Web App、API、MCP Server で構造化抽出 |
| セットアップ | エンドポイントにパラメータ付きでリクエストを送る | One Click Extract を押すだけ。AI が項目と抽出戦略を提案し、そのまま実行 |
| 出力 | 生 HTML/JSON、対応サイト向けの構造化パーサー | 構造化された、エクスポート可能なデータ |
| 最適な用途 | インフラ規模のスクレイピングパイプライン | アクセス可能なページからの、すばやく構造化されたノーコード抽出 |
どちらのモデルが絶対に優れている、という話ではありません。解決しようとしているボトルネックが違うだけです。ScraperAPI のボトルネックはアクセスです（ブロックを突破すること）。Thunderbit のボトルネックは理解です（ごちゃついたページを使える行データに変えること）。
Thunderbit vs ScraperAPI の価格：1,000ページあたりの実コスト
正直に言うと、この部分を書きたくてこの記事全体を書きました。ScraperAPI の価格を深掘りする記事は、クレジット倍率の仕組みを延々と説明し、Thunderbit の価格ページは Thunderbit のプランを説明するのですが、それを横に並べて "じゃあ、実際にやりたいことにいくらかかるの？" と言ってくれるものはほとんどありません。
では、ScraperAPI の公式ドキュメントで計算できる数字を使って見てみましょう。クレジット制では、対象によって基本単価が変わります。通常ページは1クレジット、Amazon は5クレジット、Google や Bing の検索結果は25クレジット、LinkedIn は30クレジットです。さらに、Cloudflare や DataDome のようなボット対策を回避する場合は追加で10クレジットかかることがあり、JavaScript レンダリングやプレミアムプロキシ機能が入るとさらに増えます。正確な追加額は対象次第なので、契約前に頼れるのはダッシュボードの ScraperAPI 公式コスト見積もりだけです。
Hobby プラン（100,000 クレジットで $49、1クレジットあたり約 $0.00049）を基準にして、1,000ページあたりの費用をざっくり出すとこうなります。
| シナリオ | ScraperAPI の 1,000ページあたりの費用（Hobby プラン単価） | ScraperAPI の 1,000ページあたりの費用（Business プラン単価） |
|---|---|---|
| 単純な静的ページ（1クレジット/ページ） | 約 $0.49 | 約 $0.10 |
| Amazon 型の EC ページ（5クレジット/ページ） | 約 $2.45 | 約 $0.50 |
| Google/Bing の SERP スクレイピング（25クレジット/ページ） | 約 $12.25 | 約 $2.49 |
| LinkedIn ページ（30クレジット/ページ） | 約 $14.70 | 約 $2.99 |
JavaScript レンダリングやボット回避の追加料金を加えると、この差はさらに広がります。一方で、プランが上がるほど1クレジットあたりの単価は下がるので、Hobby から Business、Scaling、Professional へ進むにつれて、かなり縮まっていきます。比較記事の多くがここを飛ばしますが、ScraperAPI の実効的なページ単価は、対象サイトと契約プランの両方に強く依存します。
Thunderbit の価格モデルは仕組みとして少し違います。LinkedIn をスクレイピングすると静的ブログより30倍高い、といったドメイン別倍率ではなく、月間のクレジット配分をベースにしていて、抽出する行数やページ数に応じてプランが決まります。ここで勝手にクレジット単価を作るつもりはありません。価格ページは変わるものですし、3か月後に古くなった数字を引用させるより、Thunderbit の最新価格ページ を見てもらう方が正確だからです。方向性として言えるのは、たとえばディレクトリサイトから 500 件の見込み客を抜く、あるいはクライアント監査用に数百件の商品一覧をスクレイピングするといった一回限りの作業なら、実行前にクレジット倍率を計算して立ち止まる必要はないということです。とにかく抽出して、月あたり何回その実行ができるかは、契約プランが決めます。
要点: さまざまなドメインをまたいでインフラ規模のスクレイピングを回し、クレジット倍率を事前に見積もれるなら、ScraperAPI の料金体系は計画性と大量利用に向いています。構造化された、都度発生型の、またはビジネス用途の抽出で、価値が生のリクエスト数ではなく完成した表にあるなら、Thunderbit の料金モデルはまさにその用途向けです。
どちらを選ぶべきか？ ペルソナ別の判断フレームワーク
この比較記事の上位表示ページを見ていていつも思うのは、人が本当に知りたいことを答えていない、ということです。要するに "自分はインフラが必要な開発者なのか、それとも単にデータが欲しいビジネス担当なのか" です。では、直接答えます。
ScraperAPI を選ぶべき人
- 大規模なスクレイピング基盤を作っている開発者またはエンジニアリングチーム
- API 呼び出しにプロキシローテーションや CAPTCHA 対応を直接組み込みたい
- リクエストロジックを書き、生の HTML や JSON レスポンスを解析することに抵抗がない
- 月間数百万件のリクエストを、さまざまなドメインにまたがって扱う用途
Thunderbit を選ぶべき人
- すでに見ているページから、構造化データをすぐに取り出したいビジネスユーザー、マーケター、オペレーター
- スクレイピングコードを1行も書くより、One Click Extract を押してエージェントに項目を決めさせたい
- 出力を Excel、Google Sheets、Airtable、Notion に直接入れたい
- ゼロから抽出ロジックを作らずに、内部ツール用の高速な構造化レイヤーが欲しい開発者
ここは正直に言うと、すべての人に二択ではありません。両方を使っているチームも見てきました。エンジニアリングは大規模インフラ用に ScraperAPI のパイプラインを担当し、営業やマーケティングは、エンジニアのバックログで2週間待ちになりそうな "この見込み客リスト、木曜までに欲しい" という依頼に Thunderbit を使っています。片方にもう片方の仕事をさせようとしなくなれば、この組み合わせはかなり理にかなっています。
Thunderbit は ScraperAPI の代わりになるのか？ 混乱を整理する
ここが一番混同されやすいところなので、SEO 的な遠回し表現はせず、はっきり言います。人は "AI scraper tool" と検索し、Thunderbit を含めた結果を全部まとめて "スクレイピングインフラ" だと頭の中で扱いがちです。でも、その2つは同じ箱ではありません。
Thunderbit は構造化抽出レイヤーです。すでにアクセスできるページを、使えるエクスポート可能なデータに変えるためのものです。AI を使って項目を見つけるのであって、手作業でスキーマを定義する必要はありません。ScraperAPI のようなプロキシローテーションやアンチボット突破のためのインフラ製品ではないのです。もし1日あたり1万ドメインに対して Cloudflare の壁を突破したいなら、それは ScraperAPI の得意分野であって、Thunderbit の担当ではありません。
逆に言えば、ScraperAPI にはノーコードの AI 項目検出機能はありません。強力なボット対策で保護されたページの HTML を持ってきてくれることはできますが、その HTML の中で "price" や "job title" が何を指すのかを決め、抽出コードを書くのはあなたです。どちらのツールも相手の代わりを目指しているわけではありません。プロジェクト開始から3週間後に気づいて困るより、先にそう伝えたいのです。
大規模でブロックされやすいクローリングなら、ScraperAPI のプロキシプールとアンチボット処理のほうがその用途に直結します。すでにあなたやチームがアクセスできるページから、すばやく構造化抽出したいなら、Thunderbit のエージェント型アプローチがまさにそのために作られています。両製品に公平であるために補足すると、どちらも言い過ぎは禁物です。Thunderbit はあらゆるアンチボットを突破すると約束しているわけではありませんし、ScraperAPI の稼働率や成功率の主張も独自検証ではなく自己申告です。
機能比較表：Thunderbit vs ScraperAPI
アーキテクチャや価格の違いに加えて、チームが日々の運用で本当に気にする点を並べるとこうなります。
| 機能 | ScraperAPI | Thunderbit |
|---|---|---|
| コーディングの必要性 | 実運用の多くで必要 | ブラウザ拡張の流れでは不要 |
| 出力形式 | 生 HTML/JSON、対応サイト向けの構造化パーサー | エクスポートしやすい構造化テーブル |
| エクスポート先 | 開発者が自前で保存・配信を実装 | Excel、Google Sheets、Airtable、Notion に出力可能 |
| スケジューリング | 対応ワークフローでは DataPipeline 経由で利用可能 | 対応プランおよび製品面で利用可能 |
| プロキシ/アンチボット対応 | 各リクエストに組み込み済みの中核機能 | 中核機能ではない。アクセス可能で許可されたページの抽出が対象 |
| 自動化の入口 | REST API、DataPipeline、クローラーアクセス | ブラウザ拡張、Web App、Open API、MCP Server、CLI |
| 最適なチーム | エンジニアリング/技術系オペレーション | 営業、マーケティング、オペレーション、リサーチ、そして開発ワークフロー |
最後の行が、この話のほぼすべてです。チームの Slack がエンジニアで埋まっているなら、ScraperAPI はすでに納得しやすいはずです。逆に、"このリストをスプレッドシートに入れてくれる人いない？" という依頼で埋まっているなら、それが Thunderbit の存在理由そのものです。
データアクセス、コンプライアンス、責任ある利用
ここは短くします。どちらの会社にも、そして私自身にも、法的アドバイスを配るべきではないと思うからです。どちらのツールも、公開データまたは明確に許可されたデータを扱い、取得先サイトのアクセス制御を尊重し、適用されるプライバシー法を守り、対象サイトの利用規約に従う必要があります。ScraperAPI のプロキシネットワークも、Thunderbit の AI 抽出も、あるスクレイピング作業を自動的に合法にしたり、コンプライアンスを保証したりはしません。その責任は、抽出を実行するツールではなく、実行する人にあります。個人データ、ログインセッション、あるいは利用規約に明確な "スクレイピング禁止" 条項があるサイトを扱うなら、それは機能のチェックボックスではなく、法務チームとの相談事項です。
FAQ：Thunderbit vs ScraperAPI
Thunderbit には ScraperAPI のような API はありますか？ はい。Thunderbit の Open API は、プログラムから使える Distill と構造化 Extract をサポートしています。ノーコードのブラウザ拡張とは別の体験で、自社アプリやバックエンドのパイプラインから抽出を呼び出したいチーム向けです。
Thunderbit は ScraperAPI のように CAPTCHA や IP ブロックに対応できますか？ いいえ。Thunderbit には、ScraperAPI のようなプロキシローテーションや CAPTCHA 回避のインフラはありません。アクセス可能で許可されたページから構造化抽出するためのもので、アンチボットシステムを大規模に回避するための製品ではありません。
10,000ページや100,000ページでは、どちらが安いですか？ これは本当にシナリオ次第です。単純な静的ページを大量に扱うなら、高いプランに入った ScraperAPI のインフラ価格のほうが有利になりやすいです。構造化された都度発生型の抽出で、価値が完成した表にあるなら、Thunderbit のほうが有利になりやすいです。どちらが自動的に安いと思い込む前に、上のシナリオ別比較を確認してください。
Thunderbit は ScraperAPI の良い代替ですか？ 構造化されたノーコード抽出が必要な場合に限ります。大規模なプロキシローテーションやアンチボット基盤の代替としてはそのまま置き換えられません。その点は、プロジェクト途中で気づくより最初にお伝えしたいです。
Thunderbit と ScraperAPI は併用できますか？ 多くのチームがまさにそうしています。エンジニアリングは大規模なインフラレベルのアクセスに ScraperAPI を使い、ビジネス部門はフルスプリントを必要としない構造化・単発・定期抽出に Thunderbit を使います。片方だけ選ばなければならない、というルールはありません。
この2つのどちらを選ぶかは、結局のところひとつの正直な問いに行き着きます。インフラを作っているのか、それとも今日中にデータ表が欲しいだけなのか、ということです。ScraperAPI は開発者向けのスクレイピング基盤です。プロキシ、CAPTCHA 対応、レンダリングがあり、リクエストロジックを大規模に書くことに慣れたチーム向けです。Thunderbit は、ビジネスユーザー、マーケター、リサーチャーがページから素早く構造化データを取り出すための、エージェント型ノーコード抽出レイヤーです。さらに、同じ速さをプログラムから使いたい開発者向けの API と MCP 層もあります。派手なランディングページではなく、目の前の実際の仕事に合うツールを選んでください。もし今日はスクレイパーを書くよりボタンを押したいタイプなら、Thunderbit Chrome 拡張機能 を試して、1クリックでどこまで行けるか確かめてみてください。
