数か月に一度、チームの誰かが Slack で同じ質問をしてきます。「これ、素直に Scrapy の spider を書けばよくない？」と。で、そのたびに私の答えは、誰が聞いてきたのか、何を実現したいのかによってまったく変わります。——実はこの記事の要点はほぼそれで終わりなのですが、さすがに給料分は働かないといけないので、なぜそうなるのかをちゃんと説明します。
私は SaaS と自動化の世界でほぼ 10 年を過ごしてきました。最初は Automation Anywhere で、企業がほぼ何でも自動化する一方で、Web サイトからのコピペだけはまだ人間がやっている、という光景を見てきました。そして今は Thunderbit を作っています。ここでは「Web サイトからのコピペ」こそ、まさに潰したい問題です。一方の Scrapy は、まだ誰も「agentic AI」という言葉をディナーの席で使っていなかった頃から、静かにインターネットのデータパイプラインを支えてきました。両者の比較は、勝ち負けを決めるための Thunderbit vs Scrapy ではありません。むしろ、スイスアーミーナイフとフル装備の機械工場を比べるようなものです。どちらも金属を切ることはできますが、そこに至るまでの手順、必要なスキル、そして後片付けの手間はまるで違います。
まず結論
細かい話に入る前に短く言うと、Thunderbit は管理型のエージェント型ウェブスクレイパーです。ページを開いて 1 回クリックすれば、ブラウザ、Web App、Open API、MCP Server、あるいは CLI のどれを使っていても、構造を自動で読み取ってくれます。Scrapy は成熟したオープンソースの Python フレームワークで、spider を書き、セレクタを定義し、パイプラインを作り、データに触れるコードをすべて自分で管理します。
どちらが普遍的に「優れている」という話ではありません。解決したい課題も、使う人も違うからです。率直に言えば、競合記事がこの違いを一つの結論に押しつぶしてしまうことが多いので、きちんと整理して書きたかったのです。
一目でわかる比較
最初にこんな表が欲しかった、というものを作りました。私が見つけた「Thunderbit vs Scrapy」の記事は、Scrapy vs BeautifulSoup の大きな比較の一部に埋もれていたり、薄いディレクトリ風ウィジェットしかなかったりしました。なので、ちゃんと比較できる形にしました。
| 観点 | Scrapy | Thunderbit |
|---|---|---|
| 正体 | オープンソースの Python フレームワーク（spider、pipeline、middleware、非同期エンジン） | エージェント型のノーコードウェブスクレイパー — ブラウザ拡張、Web App、Open API、MCP Server、CLI |
| 初期設定 | Python 環境を入れ、spider を書き、セレクタを定義し、pipeline を構成する | 対象ページを開いて One Click Extract をクリックするだけ — 対応済み・許可済みのページでは自動で抽出が始まる（Run Now も可） |
| 必要スキル | Python、XPath/CSS セレクタ、非同期の概念 | ブラウザ操作ならコード不要。API/CLI/MCP は一般的な開発設定が必要 |
| JS / 動的コンテンツ | scrapy-playwright か Selenium 系の連携が必要 | ブラウザで表示済みのページをそのまま扱える。ログイン済みセッション対応のケースもあるが、すべてのサイトで保証されるわけではない |
| アンチボット対応 | 手動の middleware（プロキシローテーション、BAN 検知など）。回避の保証はない | 対応済み・許可済みのページで管理されたレンダリングを利用。回避の保証はない |
| 大規模・定期実行 | 大量・自動・定期クローリング向けに設計 | スケジューリングはプランや利用面による。ターゲットを絞った中規模までのジョブに向く |
| 出力 | カスタム実装（JSON、CSV、データベース、pipeline など） | Excel、Google Sheets、Airtable、Notion などの対応先へ出力可能。ダウンロード形式もあり |
| 保守 | レイアウト変更で spider が壊れやすく、修正に開発工数が必要 | AI 支援抽出で一部のレイアウト変更には追従できるが、構造変化に完全ではない |
| コストモデル | 無料 / オープンソース + 開発工数 + ホスティング + プロキシ費用 | サブスク / クレジット制 — 金額を見積もる前に料金ページを確認するのがおすすめ |
Thunderbit とは？
Thunderbit は、ひとつの厄介な現実から始まりました。Web 上のデータを欲しがる人の大半は開発者ではないのに、Web をスクレイピングするツールの多くは「あなたは開発者ですよね？」という前提で作られている、ということです。私たちが存在する理由は、ほぼこのギャップそのものです。
コアのブラウザワークフローは、いい意味でかなり地味です。データを取りたいページを開き、One Click Extract を押すだけ。あとはエージェントがページを読み取り、何を抽出できるかを判断し（商品一覧、求人情報、連絡先など、画面にあるものなら何でも）、項目を自動で準備します。すぐに開始したいなら Run Now を押せますが、コーヒーを飲みながら待っていれば、そのまま自動で抽出が始まります。セレクタも、スキーマ設計も、inspect element を使った調査も不要です。
ワンクリックのブラウザ操作以外にも、Thunderbit は用途に応じていくつかの面を持っています。
- Chrome Extension は、「今見ているページのデータを取りたい」というケースに向いています。
- Web App は、コードに触れたくない業務ユーザー向けのクラウド型・定期収集に対応します。
- Open API は、Distill と構造化 Extract のエンドポイントを提供し、バックエンドやアプリのワークフローに組み込めます。
- MCP Server は、Claude、Cursor、Windsurf などの AI エージェントが Thunderbit をツールとして直接呼び出せるようにします。
- CLI は、ターミナルで作業する開発者やコーディングエージェント向けです。
対応サイトではページネーションやサブページの情報補完にも対応し、正規表現ではなく自然な言葉で項目を調整することもできます。もちろん、地球上のすべての Web サイトで完璧に動くと約束するものではありません。そこは後ほど正直に触れます。ただ、営業担当や不動産アナリストがコードエディタを開かなくて済むように設計されています。
2026 年の Scrapy とは？
Scrapy は、もう古いだけのツールではありません。公式サイトでは現在の安定版が 2.17.0 とされており、今も継続的に更新されています。直近のリリースでは HTTP/2 と SOCKS プロキシ対応が download handler の経路に追加されました。これは「AI が古いフレームワークを葬った」という話ではありません。Scrapy は今も健在で、正直なところ、今でも非常に優秀です。
Scrapy の本質は、非同期クローリングエンジンを中心にした Python フレームワークです。Spider クラスを書き、start URLs（または start メソッド）を定義すると、Scrapy が callback 関数付きの Request を発行し、レスポンスを処理します。そこから CSS や XPath セレクタ（昔ながらに正規表現を使うことも可）でデータを取り出し、Item にまとめ、cleaning、validation、storage のために pipeline へ流します。公式の概要ドキュメントでは、この流れが一通り説明されていて、理解できれば本当に美しい仕組みです。
その学習コストの代わりに得られるのは、実際のコントロールです。cookie と session、認証フロー、キャッシュ、robots.txt の尊重、クロール深度の制御、そして怒ったサーバー管理者に IP を止められないための AutoThrottle。さらに、proxy rotation、カスタム download handler、監視フック、そして最近では Playwright ベースのレンダリング拡張や、spider の雛形を自動生成する AI コーディングエージェント向けの支援ツールまで、middleware と extension のエコシステムも非常に充実しています。
ひとつ正確にしておきたい点があります。Scrapy のコアエンジンは HTTP クローラーであって、ブラウザではありません。JavaScript を自力で描画することはできないので、必要であれば scrapy-playwright、Selenium 風の middleware、あるいは外部レンダリングサービスを使うことになります。これは欠点というより、コアを軽量かつ高速に保つための設計判断です。ただし、つまり「JS が多いサイトを扱う」というのは標準挙動ではなく、個別の実装判断になるということです。
根本的な違い: 管理されたエージェント型フロー vs コードを所有するフレームワーク
最初のデータが取れるまでの速さ
ここでストップウォッチの数字をでっち上げるつもりはありません。Scrapy は「学習コストが高い」と言われがちですが、その根拠を示さない記事を何度も見てきたからです。なので、実際の手順数だけ数えてみましょう。
たとえば商品一覧ページを Scrapy で取得する場合:
- Python の仮想環境を用意して Scrapy をインストールする。
- テンプレートから spider を生成する。
- ページの HTML を確認し、各項目の XPath/CSS セレクタを書く。
- クリーニングと出力のための item pipeline を設定する。
- spider を実行し、セレクタのズレをデバッグして再実行する。
同じ作業を Thunderbit でやる場合:
- ブラウザでページを開く。
- One Click Extract をクリックする。
- エージェントが抽出可能な項目を見つけて、そのまま実行を始める（または Run Now を押す）。
Python 環境つきで 5 ステップ、環境構築なしで 3 ステップです。もちろん、ステップ数だけが重要な指標ではありません。Scrapy の 5 ステップは、何が起きるかを細かく制御できるぶん強力です。ただ、今日中に「この表をスプレッドシートへ入れたい」という目的なら、この差こそが本質です。
制御性と拡張性
ここは Scrapy が優位です。ここを曖昧にするのは不誠実でしょう。ソースコードを自分で持っているので、カスタムの再試行ロジック、変則的なページネーション、多段認証、既存のデータウェアハウスとの連携など、アーキテクチャ次第で何でも作れます。Thunderbit のエージェント型アプローチは、「コードを書かずに構造化データを素早く取る」ことに最適化されています。つまり、細かなレバーをすべて見せるのではなく、こちらの代わりに判断してくれるということです。ビジネス向け抽出の 80% には最高のトレードオフです。ただし残り 20% の、かなり特殊で独自性の高いクロールロジックが必要な場面では、思い通りに曲げられるフレームワークが欲しくなります。
保守と運用の責任
spider は壊れます。これは Scrapy を責めているのではありません。エージェント型であれ手書きであれ、すべてのスクレイパーは対象サイトの変更に左右されるからです。ただ、Scrapy の spider がサイトの HTML 変更で壊れた場合、その検知、原因特定、修正はチーム内の誰かがやる必要があります。つまり、そのたびに本当に開発工数がかかります。
Thunderbit の AI 支援抽出は、固定セレクタに依存するのではなくページ構造を推論するため、一部のレイアウト変更には自動で適応できます。ただし、ここは正直に言います。無敵ではありません。十分大きな構造変更があれば、やはりつまずくことはあります。違いは、適応する主体が、ベストエフォートで推測するアルゴリズムなのか、深夜 11 時に XPath を書き直す開発者なのか、という点です。
実践シナリオ
単発のディレクトリや商品表
レストラン一覧、商品価格、イベント詳細のような表を 1 ページか少数ページから取りたいなら、Scrapy プロジェクトを立ち上げるのは明らかにやりすぎです。1 回しか使わない spider を書いて、その後二度と触らないことになるでしょう。ここはまさに Thunderbit のブラウザ拡張の出番です。開く、クリックする、抽出する、Google Sheets に出す、終わり。
大規模なカスタムクローリングと業務ルール
今度は、12 のドメインにまたがる 50,000 件の商品ページをクロールし、独自の重複排除ロジックを適用し、すべてを独自の価格モデルに流し込む必要があるとしましょう。ここは Scrapy の本領です。パイプライン構造、同時実行制御、middleware のエコシステム——こうしたものはすべて、この規模とカスタムロジックを前提に作られています。
動的で JavaScript が多いサイト
この場合、どちらのツールも追加対応が必要ですが、必要な種類が違います。Scrapy では scrapy-playwright のような明示的なレンダリング連携を後付けする必要があり、依存関係と保守範囲が増えます。Thunderbit のブラウザ拡張は、すでにブラウザで描画されたページをそのまま扱えます。ログイン済みセッションの一部にも対応しているので、そのぶん準備が軽くなります。ただし、強力なアンチボットや特殊な動的コンテンツのパターンに対して、どちらも必勝法ではありません。そう言い切る人がいたら、何か売りたいだけです。
AI エージェントやアプリへの組み込み
Claude や Cursor で AI エージェントのワークフローを作っていて、その推論ループの一部としてライブの Web データを取り込みたいなら、Scrapy を自前でつなぐのはかなり大変です。Thunderbit の MCP Server はまさにそのために作られていて、抽出機能をエージェントが直接呼べるツールとして公開します。
精度、スケール、保守性
Scrapy の精度は、良い意味で決定的です。正しく書かれたセレクタは、HTML が変わるまでは、指定した項目を毎回まったく同じように取ってきます。この予測可能性は、何が失敗したのかを正確に追いたい本番パイプラインでは非常に価値があります。
Thunderbit のエージェント型検出は少し違います。人間がページを見るように構造を解釈し、「たぶんこれが価格だな」「これがタイトルだな」「これが説明文だな」と判断します。これは速度と柔軟性の面で非常に強力ですが、精度の考え方としては別物です。つまり「だいたい合っていて、時々ちょっと補助が必要」寄りで、「セレクタが言っていることが常に完全に正しい」わけではありません。AI ベースの抽出が完璧だと装うより、こうしたトレードオフを率直に伝えたいです。
純粋なスループットでは、Scrapy の非同期エンジンは大量のリクエストを効率よく処理するために設計されています。これはまさに Scrapy の DNA の一部です。Thunderbit は、100 万ページを一晩で回すことよりも、必要な対象から素早くきれいな構造化結果を取る、という中規模・ターゲット型の作業に向いています。本当に巨大なクロール計画を立てているなら、どちらのツールも自分が必要とする規模にそのままスケールすると思い込まず、最新のプラン上限を確認してください。
もうひとつ、両方に共通する大事な点があります。許可された用途で使うことです。どちらを選んでも、robots.txt、サイトの利用規約、適用法令を守るのは必須です。責任ある使い方の基本です。
価格、ライセンス、総コスト
よくある落とし穴があります。「無料」と「コストゼロ」を同じものとして扱ってしまうことです。Scrapy にはライセンス費用がありません。オープンソース、その通りです。でも「無料」のソフトウェアにも動かす場所は必要で、その場所にはお金がかかります。ホスティング、量が多いならプロキシ、JS レンダリングが必要ならブラウザ自動化の仕組み、spider が静かに死んだことを知るための監視、そして最大のコストである、作る・試す・壊れたら直すための開発時間です。
Thunderbit はサブスク / クレジット型で動いており、ここで私が数字を断言するより、公式の料金ページを見てもらうのが一番です。価格体系は変わることがありますし、最新条件は直接確認した方が確実だからです。そのサブスクで買うのは、対応ワークフローにおける初期設定と保守の大部分をなくすことです。
本当に大事なのは、「紙の上でどちらが安いか」ではありません。「あなたのチームがより多く持っている通貨は何か、開発者時間か、サブスク予算か？」ということです。余力のある 5 人のデータエンジニアチームなら、既存スキルまで含めて考えると Scrapy の総コストが低くなるかもしれません。一方で、エンジニアがいない 3 人のオペレーションチームにとっては、「無料」のフレームワークが、最初の 1 行のデータを見るまでに、外注費と 3 週間の遅延を招くこともあります。
Thunderbit を選ぶべき人
Thunderbit は、営業、マーケティング、EC、不動産、採用など、技術者でなくても今すぐ構造化データが必要で、工程のたびにエンジニアチケットを切りたくない人に最適です。また、ゼロから抽出ロジックを作らずにプログラム的にアクセスしたい開発者にも向いています。Open API と CLI がその層を肩代わりしてくれるからです。リード獲得、EC モニタリング、採用調査のための LinkedIn スクレイピング が業務に入るなら、たいていはこちらの方が速いです。
Scrapy を選ぶべき人
Scrapy が向いているのは、Python 開発者が社内にいて、何年も動き続けるクローリング基盤を作りたい、そしてリクエストロジック、リトライ挙動、データパイプラインを完全に制御したい場合です。また、コンプライアンスやアーキテクチャ要件上、コードを完全に自分たちで持つ必要があり、監査可能で self-hosted、外部依存なしでなければならない場合にも適しています。
両方を使うチームはある？
かなり多くのチームが両方を使っていますし、それは逃げの答えだとは思いません。開発者は、長期的に必要な堅牢で大規模なクローリング基盤として Scrapy spider を運用し、組織の他のメンバーは、単発調査や一度きりのデータ取得、フルの開発スプリントを組むほどではない探索的作業に Thunderbit を使う、という形です。両者の公式な統合はありません——ここは明確にしておきます——ただ、運用上は、どの仕事にどちらのツールが合うかで並行利用することを何も妨げません。
結論
ひとつの直感的な問いにまとめるなら、「最適化したいのは制御か、スピードか？」です。Scrapy は、セットアップと継続的な保守のコストと引き換えに、完全な制御を与えてくれます。Thunderbit は、柔軟性の一部を差し出す代わりに、速さと使いやすさを与えてくれます。どちらが絶対的に正しいという話ではありません。スクレイピングする人が Python を知っているのか、それとも営業パイプラインを知っているのかで変わります。AI ベースの抽出が従来方式と比べてどうかをもっと広く知りたいなら、AI web scraping と web scraping without coding の解説もあわせてどうぞ。今回の比較を超えた全体像がわかります。
FAQ
Scrapy は無料ですか？ はい。Scrapy フレームワーク自体はオープンソースで、公式サイトによるとライセンス費用はかかりません。実際のコストは、ホスティング、プロキシ、JS 対応が必要な場合のレンダリングツール、そして spider の構築・保守にかかる開発時間です。
Scrapy は JavaScript を自動で描画しますか？ いいえ。Scrapy のコアはブラウザではなく HTTP クローラーなので、標準では JavaScript を実行しません。公式ドキュメントでも説明されているように、JS が多いサイトをスクレイピングする場合は、通常 scrapy-playwright か Selenium 系 middleware を追加します。
Thunderbit は API と MCP に対応していますか？ はい。Thunderbit にはプログラム利用向けの Open API があり、Distill と構造化 Extract のエンドポイントを提供しています。また、MCP Server もあり、Claude や Cursor のようなツール内の AI エージェントが Thunderbit を直接呼び出せます。
業務ユーザーにとって速いのはどちらですか？ 設計上は Thunderbit です。ブラウザ拡張の One Click Extract は、ページを分析したあと自動で抽出を開始し、セレクタやスキーマ設定は不要です。Python を入れて spider を書くより、はるかに短い道のりです。
深くカスタマイズしたクローリングにはどちらが向いていますか？ Scrapy です。middleware、pipeline 構造、ソースコードへの完全アクセスにより、高度に具体的なクロールロジック、大規模な定期ジョブ、そしてエージェント型ツールでは置き換える前提で作られていないカスタムデータパイプラインまで実現できます。
