数週間前、チームの誰かから GitHub の issue スレッドが回ってきました。金曜の夜11時に、ある開発者が PlaywrightCrawler の3回目のリトライ処理をデバッグしているという話です。そのすぐ下で、別の人が「これなら Thunderbit を使えばいい」と返し、投稿者は「そういう話じゃない、これは自分のパイプラインに組み込みたいんだ」と反論していました。どちらも正しい。要するに、Thunderbit vs Crawlee の議論は GitHub スレッド1本でほぼ説明できてしまう、ということです。
私は SaaS と自動化ツールの世界を何年も行き来してきたので（Automation Anywhere 時代は特に）、『どのスクレイパーが優れているか』という聞き方が、たいていは間違った問いだと分かっています。本当に考えるべきなのは、『誰がスクレイピングをするのか、そしてその後に何が必要なのか』です。では、見ていきましょう。
本当に問うべきなのは「どちらが優秀か」ではなく「誰がスクレイピングするのか」
Google で「Crawlee vs 〇〇」と検索したときに多くの人がハマるのがここです。まるでコーヒーメーカー2台を比較するように、機能の優劣を見比べることを期待してしまう。でも、Crawlee と Thunderbit は同じ仕事を奪い合っているわけではありません。まったく異なる課題を前にした、まったく別の人向けに作られています。
Crawlee は Apify チームが開発しているオープンソースのクロールライブラリで、JavaScript、TypeScript、Python でコードを書くことに慣れた開発者を前提にしています。インストールして、リクエストハンドラを書き、セレクタを定義し、コードをデプロイする。Thunderbit が想定しているのはまったく違う人物です。営業、マーケ、オペレーションの担当者で、今すぐ Web ページから構造化データが欲しい、でもターミナルは一切触りたくない、という人です。
| 観点 | Crawlee | Thunderbit |
|---|---|---|
| 想定ユーザー | 独自クローラーを作る開発者 | 非エンジニア、オペレーション/営業/マーケチーム |
| 導入条件 | Node.js または Python の導入、スクレイパーコードの作成 | ブラウザ拡張を入れて One Click Extract を押すだけ |
| コーディングの必要性 | あり（JS/TS または Python） | なし |
| 最適な用途 | 本番パイプライン、複雑な独自ロジック | 単発または定期的なページからの構造化抽出 |
この最初の比較を持ち出すのは、多くの比較記事がこの分岐点を丸ごと飛ばしてしまうからです。でも実際には、ここがどのツールを検討すべきかを決める一番重要なポイントです。リトライ、プロキシ、ブラウザプールまで細かく制御したい開発者なら、ワンクリックの手軽さでは満足できません。逆に開発者でないなら、Crawlee の柔軟性がどれだけ高くても意味はなく、使わないからです。
Thunderbit とは？
Thunderbit は、私ならエージェント型ウェブスクレイパーと呼びます。つまり、セレクタを手で書く代わりに、AI レイヤーがページの内容を読み取り、何を抽出すべきかを判断してくれる仕組みです。Thunderbit Chrome Extension の基本的な流れはこうです。データを取りたいページを開き、One Click Extract を押す。するとエージェントがページを読み解き、有用な項目を見つけて、実行準備を整えます。Run Now も表示されるので、すぐに開始することもできますが、必須ではありません。何もしなくても自動で抽出が始まります。
本当に、セットアップはこれで終わりです。スキーマ設計や項目マッピングの作業は不要で、エージェントがページを解析し、そのまま自動で抽出を走らせます。
ブラウザ拡張に加えて、Thunderbit には Web App、プログラムから使える Open API、AI エージェントがツールとして使える MCP Server、ターミナルベースの作業向け CLI もあります。最後の部分は意外と重要です。あとで触れますが、これがあるからこそ、この話が単なる「ノーコードが勝つ」で終わらないのです。
対応ページであれば、Thunderbit はページ送りやサブページの情報補完にも対応できます。取得したデータはスプレッドシートや対応先へエクスポート可能です。ただし、「AI がページを読める」と聞くと何でもできるように思われがちなので、そこは一言添えておきます。実際には、対応している許可済みページでよく動く、という話であって、世の中のどんな JavaScript フレームワークや bot 対策にも必ず勝てる、という約束ではありません。
Crawlee とは？
Crawlee はホスト型の製品ではなく、JavaScript/TypeScript または Python で Web クローラーやスクレイパーを作るためのオープンソースライブラリです。Apify が保守していますが、ここは正確に分けて理解する必要があります。多くの人が混同しがちですが、Crawlee はライブラリ、Apify はそれとは別のクラウドプラットフォームで、Crawlee ベースのプロジェクトをホスト・実行できます。似た関係ではありますが、同じものではありません。
Crawlee で手に入るのは、いわば道具箱です。JavaScript が少ない軽量スクレイピング向けの HTTP ベースのクローラーと、Playwright や Puppeteer を使ったブラウザクローラーの両方が使えます。どの URL をすでに巡回したかを手動で管理しなくても済むように、リクエストキューを処理してくれます。抽出データの保存も扱います。さらに、オートスケーリングやセッションプールも内蔵されているので、何千ページものクロールを回すときでも、並列処理のロジックをゼロから作り直す必要がありません。
ただし、ボタンを押せば全部終わる、という話ではありません。コードを書く必要があります。リクエストハンドラを定義し、クローラーのインスタンスを立ち上げ、ページに到達したときに何をするかを指示する。Crawlee は足場を提供してくれますが、家を建てるのはあなたです。
根本的な違い：管理された抽出プロダクトか、コードライブラリか
構造化テーブルができるまでの速さ
ここが最も差が出るポイントです。Thunderbit なら、ページを開いてから使えるテーブルができるまで、対応ページであれば数秒から数分です。クリックして、エージェントに検出と実行を任せる。それで完了です。
一方 Crawlee では、最初の簡単なクローラーでも、ちゃんとした初期設定に時間がかかります。Node.js か Python のインストール、Crawlee パッケージの追加、リクエストハンドラの作成、セレクタの特定（ページを見ながら手作業）、そのうえで実行して壊れた箇所をデバッグ、という流れです。初めての人なら、1回動く抽出を作るだけでも 30〜60 分くらいは見ておいたほうがいいでしょう。しかも、JavaScript か Python を多少は分かっている前提です。
ブラウザ／クローラーロジックの制御性
ここは Crawlee の完全勝利です。議論の余地はありません。どのブラウザエンジンを使うか、セッションをどう管理するか、プロキシをどうローテーションするか、リクエスト失敗時にどうするか、リンクの探索をどこまで深くやるか、並列数をどう制御するか――すべてを自分で決められます。多段ログインの処理や、標準的なパターンでは対応できない妙なページ送りを持つサイトを巡回したいなら、Crawlee はそのための部品を提供してくれます。
Thunderbit のエージェント型アプローチは、その細かい制御を速度と使いやすさと引き換えにしています。ロジックを自分で書くのではなく、AI がページを見て推測します。うまくハマれば非常に便利ですが、かなり特殊で明示的な抽出パターンを強制したい場面では、やや不向きです。
デプロイと保守の責任
Crawlee ではデプロイを自分で管理します。つまり、ホスティング先（自前サーバーでも Apify でも、他の選択肢でも）を自分で用意し、セレクタを壊すサイト側のマークアップ変更に対応し、依存関係も更新し続ける必要があります。継続的な手間はありますが、そのぶん継続的なコントロールも得られます。
Thunderbit は管理されたインフラ上で動きます。ブラウザ拡張は自分のセッション内、あるいは定期ジョブではクラウド上で実行され、抽出ロジックの更新は Thunderbit 側で行われます。あなたがコードを保守する必要はありません。
実践シナリオ
1回きりのページ抽出
たとえば、14時の会議前に競合他社の製品一覧ページをスプレッドシートへ取り込みたいとします。Thunderbit はまさにこういう用途のために作られています。ページを開いて One Click Extract を押し、エクスポートするだけ。Crawlee で本当に単発の作業をやるのは大げさで、スクリプトを書く時間のほうが節約できる時間より長くなりがちです。
カスタムな Playwright/Puppeteer クロール
次に、認証済みダッシュボードにログインし、3階層深く移動し、独特な DOM のタイミングで全部を描画するサイトからデータを抜きたい監視パイプラインを作るケースを考えましょう。これは Crawlee の得意分野です。PlaywrightCrawler には、こうしたカスタムな移動ロジックに対応するためのブラウザ自動化の部品があります。
リトライと保存を伴う大規模キュークロール
何万 URL ものクロールを回し、リトライの自動処理、リクエストキューの永続化、構造化された保存出力が必要なら、Crawlee の標準機能はまさにその規模を想定して設計されています。これは Thunderbit のブラウザ拡張の用途とは少し違います。Thunderbit は1ページずつ、あるいは対応サブページを扱うツールであって、キュー管理システムではありません。
AI エージェントから抽出を呼び出す
この比較で人がよく誤解するのがこのシナリオです。AI エージェントのワークフローを作る開発者は、「AI エージェントがデータを必要としているなら、Crawlee を使って自作ツールとして包めばいい」と考えがちです。それも有効な方法です。ただ、Thunderbit の MCP Server はまさにそのために存在していて、Claude や Cursor のような対応クライアントが、カスタムクローラーを誰も書かなくても Thunderbit の抽出機能をツールとして呼び出せます。これはワンクリックのブラウザ操作とは別の入り口で、設定は必要ですし、「押せば終わり」ではありません。でも、Crawlee ベースのツールをゼロから作るのとは、かかる労力がまったく違います。
動的サイト、規模、信頼性
ここは慎重に扱いたいところです。というのも、マーケティング文句はここで過剰になりがちだからです（昔の私も含めて）。Crawlee のブラウザクローラーは JavaScript を実行し、動的コンテンツを待ち、実ユーザーのようにページとやり取りできます。レンダリング負荷の高いサイトには本当に役立ちます。Thunderbit のブラウザ拡張も同様に、実際のブラウザ環境で動き、開いている JavaScript 描画ページに対応できます。
でも、どちらのツールも万能ではありません。Crawlee は開発者がプロキシローテーションやセッションプールを自分で設定できるようにするツールであって、自動で壁を突破する仕組みではありません。Thunderbit は対応済みの許可ページに対して、管理されたレンダリングと bot 対策への対応を行いますが、これも「どこでも必ず動く」という意味ではありません。世の中のあらゆる bot 対策を100%突破できると断言する比較記事があったら、それは平気で嘘をついています。はっきり言っておきます。
価格、ライセンス、総コスト
Crawlee 自体は無料のオープンソースです。たとえば Python 版は Apache License 2.0 で提供されています。ただし、「無料」は「コストゼロ」ではありません。クローラーを開発・保守するための開発時間、自前サーバーや Apify のようなホスティング費用、そして対象サイトで IP ローテーションが必要ならプロキシ代がかかります。なお、Apify はライブラリ本体とは別の有料製品です。
Thunderbit はサブスクリプション／プラン型で、クレジットベースの利用モデルです。料金は変わることがあるので、ここでは数値は書かず、直接 Thunderbit Pricing を見てもらうのが正確です。
保守コストを率直に比べると、Crawlee のクローラーは、対象サイトのマークアップが変わると壊れます。セレクタが特定の DOM 構造に依存しているからです。誰かが失敗を見つけて、コードを直さなければなりません。Thunderbit のエージェント型抽出は、実行のたびにページを再解析するので、この種の壊れ方はかなり減ります（ゼロにはなりません）。対象サイトが大きくレイアウト変更したら影響は受けますが、ハードコードされたセレクタを同じように保守し続ける必要はありません。
Thunderbit を選ぶべき人
コードを書かずに Web ページから構造化データを取りたい人、たとえばリードリスト、競合価格、市場調査などが目的なら、Thunderbit はそのために作られています。あるいは、非エンジニアのチームにセルフサービスの抽出ツールを渡したい開発者や、クローラーを一から作らずに Open API でプログラム的に使いたい場合にも向いています。
Crawlee を選ぶべき人
コードベースの中で動かす必要がある、何千ページにもスケールさせたい、あるいは本当に独自の移動ロジックが必要なデータパイプラインを作っているなら、Crawlee は適切な土台です。リクエストキュー管理を伴う何万ページ規模の本格的なクロールにも向いています。これはブラウザ拡張のワークフローが解くために作られた問題ではありません。
両方を使うことはできる？
現実的には、できます。しかも、それは言い逃れではありません。私が関わってきた多くの会社でも、同じような構図を見てきました。エンジニアリング部門は、データウェアハウスに流し込むための、反復的で大規模な構造化クロール処理を Crawlee ベースのパイプラインで担当する。一方で営業、マーケ、オペレーションのチームは、エンジニアのバックログにチケットとして積まれがちな「この1ページのデータを今すぐ取りたい」という案件に、Thunderbit のブラウザ拡張や Web App を使う。公式な統合機能でこの2つが結びついているわけではありません。そこは誇張しません。ただ、アーキテクチャ的には隣接する課題をうまく解けるので、結果として両方を使うチームはかなりあります。
結論
コードベースの中で生きるものを作る必要がある、何千ページにもスケールさせたい、本格的に複雑な移動ロジックを扱いたい――そんな開発者なら、Crawlee はそれを可能にするコントロールを与えてくれます。その代わり、時間と継続的な保守は自分で負うことになります。いっぽう、Web ページからコードなしでデータを取りたい人、あるいはクローラーを一から作らずに AI エージェントへ抽出機能をツールとして公開したい開発者なら、Thunderbit のほうが早い道です。抽象的に見れば、どちらが「優れている」とは言えません。解いている問題も、使う人も違うからです。この比較で本当に避けるべき失敗は、状況に合わないほうを選んでしまうこと、それだけです。
FAQ
Crawlee は Apify と同じものですか？ いいえ。Crawlee は Apify チームが保守しているオープンソースのクロールライブラリです。Apify はそれとは別のクラウドプラットフォームで、Crawlee ベースのプロジェクトをホスト・実行できるほか、プロキシやスケジューリングなどのサービスも提供しています。関連はありますが、料金体系も含めて別製品です。
Crawlee は無料ですか？ ライブラリ自体は無料のオープンソースです（Python 版は Apache License 2.0）。実際のコストは、開発時間、ホスティング基盤、必要に応じたプロキシサービスで発生します。ライセンス料金ではありません。
Thunderbit は開発者向けに API や MCP で使えますか？ はい。ブラウザ拡張に加えて、Thunderbit にはプログラムから使える Open API と、対応 AI ホストが Thunderbit の抽出ツールを直接呼び出せる MCP Server があります。
コーディング経験がない人にとって、どちらが簡単ですか？ 迷わず Thunderbit です。ブラウザ拡張の One Click Extract は、コード不要、セレクタ作成不要、スキーマ設定不要です。Crawlee は最初から JavaScript/TypeScript か Python の知識を前提にしています。
リトライやプロキシなど、クローラーの挙動を細かく制御できるのはどちらですか？ 圧倒的に Crawlee です。セッションプール、プロキシローテーション、リクエストキュー管理、リトライロジックを、開発者が設定可能な部品として公開しています。Thunderbit はそれを裏側で管理し、そのぶん手動制御をシンプルさと速さに置き換えています。
