このテーマに引き込まれたのは、同じ週に3人からまったく同じ質問をされたからです。「ScrapeGraphAI を Thunderbit の代わりに使えばいいの？」と。1人は、競合の価格表を作ろうとしていた個人マーケター。1人は、RAG パイプラインを構築していたバックエンドエンジニア。さらに不思議なことに、もう1人はその両方で、「1つのツールで足りるのか、それとも2つ必要なのか」を判断しようとしていました。
この組み合わせのややこしさは、まさにそこにあります。Thunderbit と ScrapeGraphAI は、実は同じ仕事を取り合っているわけではありません。Thunderbit は、非エンジニアでもボタンを押すだけでクリーンな表を取れるように設計された、マネージド型のエージェントスクレイパーです。一方の ScrapeGraphAI は、プロンプト、スキーマ、クロール、監視機能を組み合わせて自分のパイプラインを組めるように作られた、AI ネイティブな抽出 API（その下にオープンソースのコアを持つ）です。この記事では、両者が実際に重なる部分、重ならない部分、そして — どちらの販売側もあまり表に出したがらないであろう — マーケティングページの先にある本当のコストと制約を整理していきます。
先に結論
細かく入る前に、要点だけ知りたい方へ：
- Thunderbit は、ビジネスユーザーと開発者向けのマネージドなエージェント型スクレイパーで、Chrome 拡張機能、Web アプリ、Open API、MCP Server、CLI として使えます。
- ScrapeGraphAI は、オープンソースのグラフベース抽出エンジンと、Scrape、Extract、Search、Crawl、Monitor、Schema、History を提供するホスト型 API を組み合わせたもので、独自の MCP 対応も備えています。
- 本当の比較軸は「ノーコードかコードか」ではありません。マネージドでワンクリックのブラウザワークフローと、開発者が自分で組み上げる API ファーストの抽出基盤の違いです。
どちらが一方的に優れている、という話ではありません。想定している使い手が違うだけです。
一目で分かる比較
| 項目 | Thunderbit | ScrapeGraphAI |
|---|---|---|
| 主な利用者 | ビジネスユーザー、マーケター、営業/オペレーション、開発者 | AI/データパイプラインを構築する開発者 |
| セットアップ | 拡張機能をクリック、ページを自動検出 | API キー、またはオープンソースパッケージをセルフホスト |
| プロンプト/スキーマモデル | エージェントによる項目検出、必要に応じて項目単位の指示 | 自然言語プロンプト + 任意の JSON スキーマ |
| ブラウザ/クロール層 | 対応済み・許可されたページでのマネージドブラウザレンダリング | マネージド取得/レンダリング + 非同期 Crawl サービス |
| ホスティング | マネージドクラウド製品（拡張機能、Web アプリ、API） | ホスト型 API、またはオープンソースのコアをセルフホスト |
| API/MCP | Open API、MCP Server | v2 API（Scrape/Extract/Search/Crawl/Monitor/Schema/History）、MCP |
| モデル選択 | 製品側で管理 | オープンソースエンジンをセルフホストする場合は設定可能 |
| 出力 | 構造化テーブル、Sheets/Airtable/Excel/Notion へエクスポート | Markdown、HTML、スクリーンショット、JSON、リンク、画像、要約 |
| 保守 | ベンダー管理 | ベンダー管理（ホスト型）または自主管理（オープンソース） |
| プライバシー | 標準的なマネージド製品の取り扱い | 無料プランでは学習利用の可能性あり。有料プランは異なる — 最新規約を要確認 |
| 料金 | サブスクリプション/クレジット制 — Thunderbit Pricing を参照 | クレジット制プラン、ScrapeGraphAI の最新料金ページを参照 |
| 向いている用途 | 高速・ノーコードの抽出 + 業務ワークフロー | プログラマブルな抽出/検索/クロール/監視基盤 |
Thunderbit とは？
Thunderbit の考え方はとてもシンプルです。Web ページからデータ表を取り出すために、セレクタもスキーマもプロンプトも書かなくてよいようにすること。ここでいう今の実際の操作フローは、どこかのスクリーンショットで見た昔のものではありません。
アクセス権のあるページを開き、Chrome 拡張機能 の One Click Extract を押すと、エージェントがページを検出・読み取り・解析します。商品一覧、連絡先、求人情報など、そのページにあるデータ構造を判断し、Run Now を表示します。クリックしてすぐ開始してもいいですし、何もしなくても自動で始まります。必要なのはこれだけ。意図的な1クリックで、セレクタもスキーマ作成も不要です。
そこから、検出された構造が少し違うときは項目を調整でき、対応サイトではページネーションやサブページ処理も行えます。さらに、Google Sheets、Airtable、Excel、Notion に直接エクスポート可能です。ブラウザ上のクリック以上のものが必要なチーム向けには、クラウド実行用の Web App、バックエンド統合向けの Open API、Claude や Cursor などの互換 AI エージェントが抽出をツールとして呼び出せるようにする MCP Server、ターミナルやコーディングエージェントのワークフロー向けの CLI があります。
設計思想は明快です。非技術者が使えるデータセットにたどり着くまでの手間を、できるだけ減らすことです。
ScrapeGraphAI とは？
ScrapeGraphAI はまったく別のタイプの製品です。そして実は、1つの名前を2つのものに使っています。ひとつは オープンソースの Python パッケージ（scrapegraphai）で、自分の LLM とインフラ上でセルフホストできるモジュール型の AI 抽出エンジンです。もうひとつは ホスト型 API で、そのエンジンに加えて、管理された取得処理、プロキシローテーション、クレジット課金をまとめ、開発者が利用料を払う製品として提供しています。
執筆時点での最新 v2 API には、次の機能があります。
- Scrape — ページを取得し、Markdown、HTML、スクリーンショット、リンク、画像、要約、JSON、ブランド情報を返す
- Extract — 自然言語プロンプトと任意の JSON スキーマを使い、URL・生 HTML・Markdown から構造化データを抽出する
- Search — 任意でページ抽出や構造化出力を伴う Web 検索を実行する
- Crawl — 開始/停止/再開を制御できる非同期の複数ページ巡回
- Monitor — Cron ベースの変更検知と Webhook 通知
- Schema — 再利用可能な JSON スキーマを生成する
- History — 過去のリクエストと結果を確認する
なお、ScrapeGraphAI の 旧 v1 エンドポイント名 である smartscraper、searchscraper、smartcrawler は、現在は非推奨で、これらの v2 用語に置き換えられています。古いブログ記事（競合比較記事を含む）でまだこれらの名称が使われている場合、それは古いドキュメントを参照しているということです。
ScrapeGraphAI には 公式 MCP サポート もあり、scrape、extract、search、crawl、schema、credits、history、monitor を、AI エージェントが呼び出せるツールとして公開しています。つまり、MCP は Thunderbit だけのものではありません。両方のツールが今はこの言語を話しており、正直それ自体が業界全体の流れをよく表しています。
中核の違い：マネージドな製品体験 vs 設定可能な AI スタック
最初の結果までの速さ
ここが最もはっきりした分かれ目でしょう。Thunderbit なら、最初の結果までにかかる時間は、ボタンを1回クリックしてページの処理を待つ程度です。ページの複雑さにもよりますが、数秒から数分ほど。ScrapeGraphAI では、API キーの登録（またはオープンソースパッケージと自分のモデルアクセスの準備）、プロンプトかスキーマの作成、適切なエンドポイントの選択、そしてレスポンス処理を自分のコードで行う必要があります。これは欠点ではなく、設計上そうなっています。より柔軟なものを作るため、着手から完成までの距離が長いだけです。
モデルとパイプラインの制御
ScrapeGraphAI のオープンソースコアをセルフホストするなら、LLM を自分で選び、抽出ロジックを調整し、パイプライン全体を自分で管理できます。特定のモデル要件がある場合や、データが外部 API に触れる場所についてコンプライアンス上の制約がある場合、あるいはスクレイプから抽出の間に独自ロジックが必要な新しい仕組みを作る場合には、これは強力です。
Thunderbit はそのレバーをユーザーに渡しません。モデルもパイプラインも製品側で管理されます。制御を手放す代わりに、それについて考えなくて済む。これはまさに、マーケターや営業オペレーション担当が望むトレードオフです。
ホスティング、プライバシー、保守の責任
ここははっきり伝えておく価値があります。ScrapeGraphAI の 利用規約（2026年中頃更新時点）では、Free Plan に送信されたデータは、研究、モデル評価、学習、ファインチューニング、製品改善に使われる可能性があるとされています。有料プランは、別途オプトインしない限り学習には使われないと説明されています。無料プランで少し試すだけ、という使い方でも、機微な情報を通すなら事前確認は必要です。ScrapeGraphAI が怪しいことをしているという意味ではなく、これはよくあるフリーミアムのトレードオフだからです。ただし、「まずは無料プランで試せばいい」と考えると、一般的に想定される以上の意味を持つ場合があります。
Thunderbit はマネージド製品として、独自の標準規約に従ってデータを扱います。どちらにせよ、決めつけずに公式の利用条件を確認するのが大切です。機密情報に向ける前には、どのツールでも最新規約を読むべきです。
実践シナリオ
ビジネスユーザー向けの「ページから表へ」抽出
たとえば、ディレクトリサイトからリード一覧を作る場合や、サプライヤーのカタログページから製品仕様を集める場合を考えてみてください。プロンプトを書きたくない、JSON スキーマも考えたくない、ページのレイアウトが少し変わっただけで Python スクリプトをデバッグしたくもない。こうした用途は Thunderbit の得意分野です。クリックして、確認して、スプレッドシートにエクスポートして、そのまま次へ進めます。
開発者が定義するプロンプト/スキーマ抽出
次に、40個の競合サイトから構造化された価格データを取り出すスクレイパーを作る場面を想像してください。各サイトのレイアウトはバラバラで、それでも全体で一貫した JSON スキーマと独自の検証ロジックが必要だとします。ScrapeGraphAI の Extract エンドポイントは、まさにそのために作られています。どのみちコードを書くなら、サイトごとにセレクタを手作業で組む代わりに、AI ネイティブな抽出レイヤーを使える、ということです。
RAG やエージェントとの統合
この点では両方に使い道があります。Markdown や構造化 JSON として最新の Web コンテンツを取り込む必要がある RAG パイプラインを作るなら、ScrapeGraphAI の Scrape と Search、あるいは MCP サーバーは、エージェントフレームワークにかなり素直に接続できます。ここは本当に強みのひとつです。Thunderbit の MCP Server と Open API も、プログラムによる抽出やエージェント経由の呼び出しに対応しているので、すでにブラウザワークフローで Thunderbit を標準化しているチームなら、API 層のためだけに別ベンダーを増やす必要は必ずしもありません。とはいえ、判断前には両者の最新ドキュメントを見比べる価値があります。
セルフホスティングと独自モデル要件
抽出処理を完全に自社インフラ内で完結させることが絶対条件である場合 — たとえばコンプライアンス要件、あるいは単純にサードパーティ API に一切データを送らない方針 — このリストの中でそれに対応できるのは ScrapeGraphAI のオープンソースコアだけです。Thunderbit はセルフホスト版を提供しておらず、すべての提供形態がマネージドです。
精度、信頼性、コスト管理
ここは慎重に扱いたいところです。比較記事は「うちのツールは絶対失敗しません」という方向に流れがちですが、それはどちらの製品に対しても誠実ではありません。LLM ベースの抽出 — 両者の本質はこれです — には、もともとばらつきがあります。ページのリデザイン、特殊なレイアウト、あるいは重い JavaScript の背後で読み込まれるページは、どのツールでも自動抽出を難しくします。
どちらかを使ってワークフローを組む前に、知っておきたい点をいくつか挙げます。
- 両者とも、ボット対策や動的サイトの制約は現実にあります。 Thunderbit のマネージドレンダリングとボット対策は、対応済みかつ許可されたページに対して有効ですが、インターネット上のあらゆるスクレイピング対策を回避できるわけではありません。ScrapeGraphAI の基盤となる取得/レンダリング層も、現実世界では同様の制約を受けます。どちらのツールも、すべての CAPTCHA やレート制限を突破できるとは約束していません。
- 構造化スキーマはばらつきを減らしますが、完全には消せません。 ScrapeGraphAI の JSON スキーマオプションでも、Thunderbit の項目レベルの抽出指示でも、AI に埋める枠をより明確に与えるほど、一般的には安定した結果が得られます。
- クレジット/コストはワークフローの効率に比例します。 ScrapeGraphAI はエンドポイントごとの課金で、Scrape、Crawl、Monitor では消費が異なります。つまり、処理に対して最適なエンドポイントをどれだけ正確に使えるかで、クレジットの伸び方が変わります。これは利用量ベース課金全般にも当てはまる話で、雑なワークフローはベンダーに関係なく高くつきます。
価格、オープンソース、総コスト
料金の話は特に慎重にしたいところです。どちらの製品も価格が変わる可能性があり、今日書いた内容が読んでいる頃には古くなっているかもしれません。ここでは、執筆時点（2026-08-14）で確認できた最新の数字を含めて整理します。予算を決める前に、必ず現在の料金ページで再確認してください。
ScrapeGraphAI のプランは、公開料金ページによると次の通りです。
- Free — $0、500 の一回限りクレジット、10 リクエスト/分、Monitor 1 件、同時 Crawl 1 件
- Starter — 月額 $20、10,000 クレジット、100 リクエスト/分、Monitor 5 件、Crawl 3 件
- Growth — 月額 $100、100,000 クレジット、500 リクエスト/分、Monitor 25 件、Crawl 15 件、基本的なプロキシローテーション
- Pro — 月額 $500、750,000 クレジット、5,000 リクエスト/分、Monitor 100 件、Crawl 50 件、高度なプロキシローテーション
- Enterprise — 個別見積もり
そして、あまり明確に説明されない重要な点があります。クレジット消費はエンドポイントごとに違います。基本の Scrape 呼び出し（Markdown/HTML）はおおむね1クレジットから。スクリーンショットは約2、ブランド抽出は約25です。Extract は約5クレジットに加えて、より取得しにくいページが必要な場合は「stealth」オプションの加算があります。Search は、プロンプトなしなら結果1件あたり2クレジット、ありなら1件あたり5クレジットです。Crawl は開始時に2クレジット、その後は巡回した各ページの Scrape コストが加算されます。Monitor はチェックごとにフォーマットコストがかかり、実際に変更が検出された場合はさらに5クレジットがかかります。
パイプライン最適化の観点ではとても有用な設計ですが、その反面、「結局いくらかかるのか」に単一の答えはありません。どのエンドポイントをどれだけ使うか次第だからです。オープンソースコアをセルフホストする場合は、クレジット課金の代わりに自分たちの LLM API 料金とインフラ/エンジニアリング工数を負担することになります。規模が大きくなると安くなる可能性はありますが、その責任をチーム内で持つ人が必要です。
Thunderbit の現在の料金は、公式料金ページ を直接確認してください。サブスクリプション階層やクレジット上限は変わることがあるので、来四半期には古い数字を引用したくありません。
正直な結論としては、どちらの料金体系も相互に直接比較できる単位ではありません。ScrapeGraphAI の「クレジット」と Thunderbit の「行」や「タスク」クレジットは、同じ通貨ではないのです。費用が決め手なら、月あたりのページ数、週あたりの抽出件数など、実際の想定ボリュームを両社の最新料金ページに当てはめて比較してください。
Thunderbit を選ぶべき人
マーケター、営業オペレーション担当、リサーチャー、小規模チームの担当者で、Web ページから構造化データを取り出したいけれど、コードも API もインフラ管理もしたくないなら、Thunderbit はまさにそのための製品です。ブラウザ抽出、クラウド実行、API アクセス、MCP 連携をひとつの製品でまとめたい場合も同様です。
ScrapeGraphAI を選ぶべき人
データパイプライン、RAG システム、あるいは抽出ロジックをプログラムで細かく制御したいエージェントワークフローを構築する開発者なら、ScrapeGraphAI の API ファースト設計とオープンソース版は、より理にかなっています。自分でモデルを選びたい、必要ならセルフホストしたい、scrape/search/crawl/monitor を別々の組み立て可能なステップとして運用したい、という場合に向いています。
両方を使うチームはある？
正直に言うと、あります。しかもそれほど珍しくありません。マーケティング/オペレーション側は Thunderbit で手早くブラウザ抽出を行い、リード一覧作成や競合価格取得などをこなし、エンジニアリング側は ScrapeGraphAI の API を使って RAG システムや社内ツール向けのバックエンドデータパイプラインを構築する、というチームを見たことがあります。両者の公式連携はなく、計画されているとも聞いていませんが、技術的には、会社がそれぞれの用途に合う方を使い分けることを妨げるものはありません。
結論
ひと言にまとめるなら、誰が作業するのか、そしてパイプラインにどれだけの制御が必要なのかで選ぶべきです。
Thunderbit は、コードを書かずにきれいな表を手に入れたい人にとって、データ取得までの速さで優位です。それが One Click Extract の目的そのものだからです。ScrapeGraphAI は、scrape、search、crawl、monitor を自分好みのパイプラインに組み合わせたい開発者にとって、柔軟性と深さで優位です。特に、セルフホストやモデル選択が重要な構成ではなおさらです。
どちらのツールも、すべてのサイトで成功を保証するわけではありません。ボット対策やページの複雑さは、両者に共通する現実的な制約です。したがって、どちらを選ぶにしても、本命の対象サイトで先にテストしてから予算を投じてください。
FAQ
ScrapeGraphAI は完全なオープンソースですか？
一部はそうです。中核となる抽出エンジン（scrapegraphai）は、セルフホスト可能なオープンソースの Python パッケージです。管理された取得処理、プロキシローテーション、Crawl、Monitor、クレジット課金を含むホスト型 API は、その上に構築された別の商用製品です。
ScrapeGraphAI は API と MCP を提供していますか？ はい。v2 API には Scrape、Extract、Search、Crawl、Monitor、Schema、History の各エンドポイントが含まれ、公式 MCP サーバー もあり、同じ機能を互換 AI エージェント向けのツールとして公開しています。
Thunderbit にコードは必要ですか？ いいえ、コアのワークフローでは不要です。Chrome 拡張機能 はワンクリックのエージェント型フローを使うため、セレクタ、プロンプト、スキーマは必要ありません。プログラムから使いたい開発者は、代わりに Open API、MCP Server、CLI を利用できます。
セルフホストに対応しているのはどちらですか？ 自分のインフラと自分のモデルアクセスで抽出エンジンを動かしたいなら、ScrapeGraphAI です。Thunderbit はすべての提供形態がマネージドで、セルフホスト版はありません。
ビジネスユーザーにとって速いのはどちらですか？ 実用上はほぼ Thunderbit です。非技術者が公開ページから構造化エクスポートまでを1クリックで進められるように設計されており、プロンプトやスキーマに触れる必要がありません。ScrapeGraphAI は API とコードを扱える開発者向けなので、そこでの「速さ」は最初のクリックまでの時間というより、パイプラインの柔軟性にあります。
