「おすすめオープンソーススクレイパー」の比較記事には、ほとんど共通する見落としがあります。それは、どのツールも同じページでは試されていないことです。Scrapy はニュース記事、Playwright はECデモ、Colly は著者の手元にあった適当なページ……そんなふうに、バラバラの条件で検証されて、あたかも同じ土俵で優劣を比べたかのように並べられます。でも、その順位づけが示しているのはツールの実力ではなく、ページの違いにすぎません。
そこで私は、比較記事が省きがちな地味で当然のことをやりました。1つの共通ベンチマークを用意し、9つのツールすべてをそこに通したのです。静的な商品一覧、JavaScriptで描画される商品一覧、ナビゲーションとフッターのゴミに埋もれた記事、わざと壊した HTTP 500、内部リンクをたどる小さなクロールグラフ、そして公開されている2つの練習用サイト。条件は完全に同じ、計測方法も同じ、しかも毎回同じやり方です。スクリプトと生の出力は公開ベンチマークリポジトリに置いてあるので、誰でも再実行できます。そこから見えてきたのは、比較記事が約束するようなきれいなランキングではありません。単一の勝者など存在しないのです。あるのは3つの用途で、9つのツールはほとんど自然にそこへ振り分けられました。
ベンチマークの仕組みと、あえて先に言っておく1つの制約
すべてのツールに同じ形のフィクスチャを当てました。2ページに分かれた12個の静的商品、一定時間後にJavaScriptで差し込まれる8個の商品、3つの本物の段落をナビゲーションとフッターの定型文で囲んだ記事、意図的に返す500エラー、そして内部リンクのグラフです。この設計があるからこそ、結果がきれいに揃います。たとえば「8/8 の動的商品」を取得できた、という結果は、Puppeteer でも Crawlee でもまったく同じ意味になります。
ただし、ここで多くの比較記事が飛ばす境界線があります。各ツールのベンチマークパックは、それぞれ自分用にこれらのフィクスチャを複製しているため、文字数の絶対値はツール間で厳密には比較できません。読むときは「同じツール内での指標」として見てください。ツールをまたいで比べてよいのは、再現率（率として扱う）、JavaScript の成功/失敗、構造的な挙動です。なお、同じ意味でのスコープ注記も1つ。Crawl4AI の静的カタログの計測は1ページ目のみを対象としていたので、6/6 は狭い範囲での完全取得を意味します。一方、他のツールは2ページ分をクロールして 12/12 でした。つまり、これは「欠落」ではなく「対象範囲の違い」です。判断の根拠は、フィクスチャごとの詳細をまとめた方法論ページにあります。
数値を見る前に、もう1点だけ。各パックには暫定の研究スコアも含めていますが、意図的にランキング表としては出していません。これは各ツールが自分の証拠と一致しているかを確認するための内部用メモであって、順位表ではないからです。これをそのまま公開すると、このベンチマークが避けたかった「根拠の薄い精密さ」を再び生んでしまいます。ここで示すのはスコア表ではなく、ベンチマークから見えた全体像です。
9ツールをひとつのベンチに並べると
この表の「Renders JS?」と「Built-in crawl queue」の2列を見れば、3つの用途がほぼ自動的に浮かび上がります。
| Tool | Language | Renders JS? | Static recall | Structured output | Built-in crawl queue | Setup weight | License |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Yes (browser) | 6/6 (page 1) | CSS schema | BFS/DFS built-in | Heavy (2 browser stacks) | Apache-2.0 |
| Firecrawl | Self-hosted | Yes (playwright-service) | Full Markdown | Yes | /v1/crawl | Heaviest (6 containers) | AGPL-3.0 |
| trafilatura | Python | No | 3/3 article | No (text only) | No | Light | Apache-2.0 |
| Crawlee | Node/TS | Engine-optional | 12/12 | Via extraction | Yes (RequestQueue) | Medium (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Yes | 12/12 | Manual | No (hand-written BFS) | Medium (browser) | Apache-2.0 |
| Puppeteer | Node | Yes (Chrome) | 12/12 | Manual | No (hand-written BFS) | Medium (Chrome) | Apache-2.0 |
| Scrapy | Python | No | 12/12 | Feed export (JSON/CSV/XML) | Yes (built-in) | Medium (Twisted deps) | BSD-3 |
| Colly | Go | No | 12/12 | Via callbacks | Depth control | Light (1 binary + Go) | Apache-2.0 |
| Scrapling | Python | No (HTTP fetcher) | 12/12 | Yes | No | Medium ([fetchers]) | BSD-3 |
この表と、この下で触れるすべてのメタデータについて1つ注意です。スター数とバージョン番号は2026年7月上旬時点のスナップショットであり、どちらもすぐに変わります。最新情報として扱う前に、各プロジェクトの GitHub とパッケージページで必ず再確認してください。
各ツールの個別レビュー一覧
この比較に登場する各プロジェクトには、対応する詳細レビューがあります。
- Crawl4AI review
- Firecrawl review
- trafilatura review
- Playwright vs Puppeteer comparison
- Crawlee review
- Scrapy review
- Colly review
- Scrapling review
以下はそれぞれの表紙と、JavaScript描画テストの実際のスクリーンショット2枚です。つまり、「8/8 の動的取得」は単なる数字ではありません。
仕事1: ページをLLM向けテキストに変換する
求めているのが、RAG パイプラインに渡せるきれいな Markdown なら、競合するのは3ツールです。しかも、それぞれの設計思想はかなり違います。
Crawl4AI は、マーケティング文句の裏側ではブラウザ駆動の Markdown 生成ツールです。検索結果でよく見かける「adaptive intelligence self-learning selector」という話は切り離して考えたほうがよいでしょう。そんな機能はありません。それは別のライブラリの仕組みです（後で Scrapling のところで触れます）。では実際に何ができるのかというと、かなり優秀です。Books to Scrape の練習サイトでは 13,476文字 の Markdown を出力し、構造化取得用の CSS スキーマ抽出にも対応しています。さらに内蔵の BFS 深層クロールでは、JavaScript ページを描画しスクリーンショットを取りながら、クロールグラフのフィクスチャ上で 5ページ を巡回しました。ただし、弱点も2つあります。生の Markdown には内容フィルタを有効にしない限りページの定型文がそのまま残り、意図的な500エラーは success=false で返ってきました。これはHTTPエラーをきれいに捕捉したのではなく、Crawl4AI 自身の内容ヒューリスティックが小さなエラー本文を見て minimal_text ... blocked と判定したためです。さらに、セットアップでは2つのブラウザスタックがディスク上に載ります。バージョンは 0.9.0、Apache-2.0、2026年7月上旬時点で約71kスターです。
Firecrawl はこの中でも最重量級で、しかもセルフホストが本当に動きます。あえて「本当に」と言うのは、6コンテナ構成（api、playwright-service、redis、rabbitmq、nuq-postgres、foundationdb）が実際に立ち上がり、同じ Books to Scrape ページから 9,222文字 のLLM向け Markdown を生成できたからです。組み込みの playwright-service 経由で JavaScript ページを描画し、スクリプト後に表示される Einstein の引用文が出力に入っていたので、描画が本物だったことも確認できました。私が遭遇した2つのつまずきは Firecrawl 自体の欠陥ではなく環境側の問題です。正確に書いておきたいのは、ソースからのビルドで colima 上の containerd snapshotter に起因する不安定さに当たり（そのため prebuilt image に切り替えました）、さらに colima の 198.18.x.x DNS 範囲が Firecrawl の SSRF ガードに引っかかりました。これは ALLOW_LOCAL_WEBHOOKS=true で回避しましたが、あくまでローカル開発用の対処であり、本番環境で無効化すべきものではありません。なお、セルフホスト版のコアにはクラウド版のアンチブロック層である Fire-engine は含まれていないため、クラウドAPIはテストしていません。さらに大きな注意点はライセンスです。Firecrawl のセルフホストコアは AGPL-3.0 であり、商用利用の前には脚注ではなく、きちんと法務確認が必要です。2026年7月上旬時点で約148kスターでした。
trafilatura はこのグループの中でも異端児で、AIブーム系の一覧では見落とされがちです。ブラウザなし。構造化行なし。ただ純粋な Python で、速くてきれいな記事本文を抜き出します。記事フィクスチャではタイトルと 本物の3段落すべて を取得し、定型文を完全に除去しました。「Login」「Subscribe」「Copyright」のような余計な文字は一切混ざりません。さらに著者名と日付も回収しました。公開商品ページでは、1,324文字のクリーンなテキストを返しています。一方で、設計がそのまま限界にもなっています。カタログを渡すと 12個の商品名をテキストとして返す ものの、構造化行は0 です。テキストは取れても構造は取れませんし、JavaScript も描画しません。バージョンは 2.1.0（現行版）、Apache-2.0、約6.2kスター。純粋な記事抽出なら、私が最初に手を伸ばすのはこれです。
先ほどの Markdown 文字数、Crawl4AI の 13,476 と Firecrawl の 9,222 は、どちらも同じ公開ページから出ています。ですが、これを品質差として読むのは間違いです。これはそれぞれの Markdown 戦略、つまりページの装飾をどこまで残すかの違いを示しているだけで、出力の優劣を示すものではありません。先に述べた「同じツール内での指標として見る」というルールが、ここでそのまま現れています。
仕事2: JavaScript を確実に描画する
データがHTMLにはなく、スクリプト実行後に初めて現れることがあります。その瞬間、実ブラウザは「あると便利」ではなく「必須」になります。この仕事を担うのは3ツールですが、そのうち2つは驚くほど似ています。
Playwright と Puppeteer は、私が試したすべての項目で引き分けでした。どちらもローカルのフィクスチャで 8/8 の動的商品を描画し、公開された Quotes JS サイトでも 10件 を取得しました。静的ページの再現率もどちらも 12/12、500エラーも問題なく処理します（Puppeteer は例外ではなくレスポンスオブジェクトを返します）。どちらにもクロールキューは付属しないため、12ページのリンクグラフを回るには手書きの BFS が必要でした。実際の違いは対応範囲です。Playwright は Chromium、Firefox、WebKit を操作でき、Python と .NET に対応しています。一方 Puppeteer は Chrome 第一主義で Node 専用です。バージョンの扱いについて2点だけ補足すると、私は Playwright 1.56.0 を現在の 1.61.1 と比較し、しかも Chromium のみを使用しました。Puppeteer は 24.16.0 を現在の 25.3.0 と比較しています。必要なら再実行するか、その点を差し引いて読んでください。どちらも Apache-2.0 で、スター数はおよそ 92k と 95k です。
Crawlee は、他の2つが残したキュー問題を解決するツールです。Cheerio（HTTP）エンジンと Playwright（ブラウザ）エンジンを1つのAPIの下にまとめており、1ページでの違いがそのまま強みです。Cheerio エンジンは JavaScript で差し込まれた要素を 0 件しか見つけられませんでしたが、Playwright エンジンはローカルで 8/8、公開サイトでは 10件を取得しました。しかも、切り替えは1行変えるだけです。さらに、ちゃんとした RequestQueue も付いているので、この仕事に入る資格があります。逆に、見出しでは誰も書かない落とし穴は、ブラウザエンジンが別途 npx playwright install を必要とし、npm install crawlee だけでは約80 MiBの追加要素が入ってこないことです。バージョン 3.17.0、TypeScript、Apache-2.0、約24.6kスター。
仕事3: ブラウザなしで高速にクロールする
ページにJavaScriptがないなら、ブラウザは高くつくだけの過剰装備です。ここでは3つのHTTPファーストなツールが競合します。考え方も言語哲学もバラバラで、その違いが面白いところです。
Scrapy は、この中ではいちばんエンジニアリング寄りのフレームワークです。spider、JSON/CSV/XML への feed export、AutoThrottle など、ひと通り揃っています。静的ページでは 12/12 を取り、記事の3段落も 3/3 で取得し、クロールグラフでは深さ0〜2で 11ページ をたどり、handle_httpstatus_list で500エラーも捕捉しました。面白いのはその思想です。Scrapy は描画しません。リクエストを再現します。JavaScript ページに向けると 0 件でしたが、そのページの裏にある JSON API には 8/8 で到達しました。これが Scrapy の哲学を1つのデータ点にしたものです。つまり、ページが内部で呼んでいるリクエストを見つけて再送し、ブラウザを操作しないということです。代償として、Twisted、lxml、parsel など依存関係はかなり大きめですし、私は小規模なフィクスチャでしか試していません。バージョン 2.17.0、BSD-3-Clause、約63kスターです。
Colly は Go の答えで、何をして何をしないかを非常に率直に示します。静的バイナリひとつで動き、OnHTML、OnResponse、OnError のコールバック駆動、そして深さ制御つきです。静的ページでは 12/12 を取り、OnResponse 経由で JSON API から 8/8 を取得し、OnError で500を捕捉し、深さ2のクロールでは 17ページ に到達しました。ここは正確に言っておきます。というのも、このページ数は Colly 自体が保証する完全性ではなく、ハーネス側のカウンタだからです。JavaScript については何もしてくれません。動的フィクスチャも Quotes JS サイトも、意図どおり 0 のままでした。ビルドには Go のツールチェーンが必要で、モジュール版（v2.3.0）は現在タグ付きリリース（v2.2.0）より先行しています。Apache-2.0、約25kスターです。
Scrapling は専門特化型で、その肩書きにふさわしい動きをします。適応型セレクターは、マークアップが変わっても要素を再発見するためのものです。実際、ターゲットの HTML クラスを product-name から product-title に変えたところ、通常のセレクターは 0 件でしたが、適応的な再マッチが追跡中の要素を復元しました。単純なHTTP抽出では、静的ページで 12/12、JSON API で 8/8 を記録しています。ただし、ドキュメントが隠していない制約もあります。合成した複数要素テストでは 3つ中1つ しか復元できませんでした。これは「壊れても追従できる」のであって、「全部回復できる」わけではありません。過大評価しないことが大事です。さらに、基本の pip install scrapling に加えて [fetchers] の追加オプションが必要で、StealthyFetcher は機能というより、コンプライアンス上の注意点として見るべきです。バージョン 0.4.10（現行版）、BSD-3-Clause、約68.7kスター。
3つの仕事の下にある共通パターン
9つを横に並べると、きれいな構図が見えてきます。静的ページでの完全取得、つまり 12/12 は、HTTPファーストなツールにとっては最低限の前提です。簡単なケースで失敗したツールはひとつもなく、ここは差別化要因ではありません。ブラウザ系ツールが重さに見合うのは、JavaScript が本当に必要なときだけです。そしてその代償は、セットアップの重さとして確実に支払います。ブラウザスタック、追加インストール、あるいはコンテナ群です。「Built-in crawl queue」の列は、実際にはフレームワークとエンジンの境界線を示しています。Scrapy と Crawlee はオーケストレーションを持ち込み、Playwright と Puppeteer は BFS を自前で書かせます。これがこの分野の形です。全体の勝者がいないのは、そもそも全員が同じゲームをしていないからです。
では、実際には何を選ぶべきか
このベンチマークが勝者を決めないのは、正解がツール名ではなく「何をしたいか」という質問だからです。つまり、あなたは3つの仕事のどれをやるのでしょうか。
- LLM向けのMarkdownが必要ですか？ きれいな記事本文だけなら trafilatura、CSS抽出とJavaScript描画も1つで欲しいなら Crawl4AI、セルフホスト型サービスで使いたくて AGPL-3.0 と6コンテナの重さを受け入れられるなら Firecrawl です。
- JavaScript の描画が必要ですか？ 生の描画だけなら Playwright か Puppeteer。エンジンと対応言語で選べばよく、実質引き分けです。クロールのオーケストレーションまで任せたいなら Crawlee です。
- 静的ページや再現可能なAPIを大規模に高速クロールしたいですか？ フル機能の Python フレームワークなら Scrapy、単一バイナリでGoの速度を取りたいなら Colly、マークアップの変化に耐えることが最重要なら Scrapling です。
用途に合うカテゴリを選べば、どれも十分に筋の通った選択です。逆に、静的ページにブラウザ系ツールを使ったり、JavaScriptアプリにHTTPパーサーを使ったりすると、ネット上で最高評価のライブラリでも期待外れになります。
代わりにマネージドAI APIを使うという選択肢
ここまでのツールはすべて無料のオープンソースで、自分で運用できます。ですが、ベンチマークを通して何度も浮かび上がった共通のトレードオフもあります。ブラウザ環境、クロールコード、アンチボットとのいたちごっこ、そして保守のすべてを自分で抱えることです。多くのチームにとっては、その制御こそが目的ですし、採用するならライセンスの確認も重要です。対象の大半は寛容なライセンスで、Crawl4AI、Crawlee、Playwright、Puppeteer、Colly は Apache-2.0、Scrapy と Scrapling は BSD-3-Clause。例外は Firecrawl のセルフホストコアで、これは AGPL-3.0 なので、商用利用の前にきちんと見直す必要があります。
ただし、ベンチマークが示したのは「何ができるか」だけではなく、「何ができないか」でもあります。描画、クロール、構造化、ブロック回避を、たいていは全部まとめて、しかも保守なしでやれるツールはありません。マネージドなAIスクレイピングAPIなら、その層を1回の呼び出しにまとめられます。Thunderbit の開発者向け機能もその選択肢の1つです。技術者向けに重要なのはブラウザ拡張ではなく、API、MCPサーバー、CLI です。POST /distill はきれいな Markdown を返し、POST /extract はスキーマ定義済みの JSON を返します。JavaScript の描画とアンチボット対策は、あなたのマシンではなくサーバー側で処理されます。エージェントやコーディングアシスタント向けには公式MCPサーバーもあり、thunderbit_suggest_fields で抽出設計を無料で下書きし、thunderbit_distill（1クレジット）と thunderbit_extract（20クレジット）が実作業を担当します。ターミナルや cron ジョブ用には npx @thunderbit/thunderbit-cli で使えるCLIもあります。非エンジニア向けにはノーコードのChrome拡張もあり、料金ページ では両方の使い方をカバーしています。
結局のところ、ここでのトレードオフは最初から最後まで同じです。9つのライブラリを自分で運用し、1回あたりのコストをゼロにするか、配管を手放してリクエスト単位で支払うか。どちらも間違いではありません。重要なのは、どこまでのスタックを自分で持ちたいかです。実際の抽出イメージを見たいなら、Thunderbit の YouTube チャンネル で流れを確認できます。
{{INTERNAL_BLOG_LINKS}}
結論
「一番のオープンソーススクレイパー」は1つではありません。そして、それを断言するランキング記事は、実は本当に決め手になる質問を隠しています。つまり、あなたがやっているのは3つの仕事のどれなのか、です。ページをテキスト化するのか、JavaScript を描画するのか、ブラウザなしで高速クロールするのか。分野はこの3つにきれいに分かれていて、その中では言語とセットアップの重さが選定基準になります。万能の覇者などいません。
ここから1つだけ持ち帰るなら、これです。導入を決める前に、自分のページで必ず試してください。ここに載せた数値は、まさにそのためにベンチマークリポジトリ で再現できるようにしてあります。一般的な比較記事で1位だったツールと、あなたの実サイトで最後まで動くツールは、必ずしも同じではないからです。
Webデータ抽出で Thunderbit を試す Get Started Free
よくある質問
いちばん優れたオープンソースのWebスクレイパーはどれですか？ 1つには絞れません。用途次第です。LLM向けのテキストなら trafilatura か Crawl4AI、JavaScript描画なら Playwright、Puppeteer、Crawlee、高速なHTTPクロールなら Scrapy か Colly です。共通ベンチマークでは、各ツールは自分のカテゴリ内で最も強く、カテゴリ外では明らかに弱かったため、万能ランキングはかえって誤解を招きます。
JavaScriptを描画できるオープンソーススクレイパーはどれですか？ Crawl4AI、Firecrawl、Playwright、Puppeteer、そして Crawlee の Playwright エンジンは JavaScript を描画できます。Scrapy、Colly、trafilatura、そして Scrapling のデフォルトHTTPフェッチャーはできません。ページの裏にある再現可能なAPIを使うか（Scrapy の考え方で、JSONエンドポイントから 8/8 を取得できました）、別のブラウザモードが必要です。
サイトをスクレイピングするのにヘッドレスブラウザは必要ですか？ JavaScript 実行後にデータが出てくる場合だけ必要です。普通のHTTPリクエストとパーサーで届くなら、ブラウザは高コストな過剰装備です。その場合は Scrapy、Colly、Scrapling のほうがずっと軽くて速いでしょう。
商用利用でいちばん扱いやすいライセンスはどれですか？ 多くは寛容なライセンスです。Apache-2.0（Crawl4AI、Crawlee、Playwright、Puppeteer、Colly）または BSD-3-Clause（Scrapy、Scrapling）です。例外は Firecrawl のセルフホストコアで、これは AGPL-3.0 なので、商用プロダクトに組み込む前に法務レビューが必要です。
このベンチマーク数値は再現できますか？ はい。すべてのランナー、フィクスチャ、生データは公開MITライセンスのリポジトリにあります。ひとつだけ覚えておくべき注意点があります。再現率と構造的な結果はツール間で比較できますが、文字数の絶対値は各ツール内の指標としてのみ有効です。各パックが同じ正規コピーではなくフィクスチャを複製しているためです。比較すべきなのは率と成功/失敗であって、生の文字数合計ではありません。
