ほぼすべての「おすすめオープンソーススクレイパー」まとめ記事には、静かな欠点があります。どのツールも同じページで検証されていないことです。Scrapy はニュース記事、Playwright はどこかの EC デモ、Colly は筆者が手元にあったもの──そんなふうに別々の対象で試され、それを横並びで比較している。けれど、その数字が本当に同じ条件を意味することなどありません。その順位づけが教えてくれるのは、ツールではなくページの違いです。
そこで私は、一覧記事が省きがちな地味で当然のことをやりました。1 セットのフィクスチャを用意し、9 つのツールすべてに通したのです。静的な商品カタログ、JavaScript で描画されるカタログ、ナビゲーションとフッターのノイズに埋もれた記事、わざと壊した HTTP 500、小さな内部リンクのクロールグラフ、さらに 2 つの公開練習サイト。同じ正解データ、同じ計測方法、すべての実行を揃えました。スクリプトと生データは 公開ベンチマークリポジトリ に置いてあるので、誰でも再実行できます。返ってきた結果は、まとめ記事が約束するようなきれいなランキングではありません。単独の勝者は存在しないのです。仕事は 3 種類に分かれていて、9 つのツールは自然とそのどれかに振り分けられました。
ベンチマークの進め方と、先に言っておくべき 1 つの制約
すべてのツールに同じ形のフィクスチャを与えました。2 ページにまたがる 12 件の静的商品、遅延後に JavaScript で挿入される 8 件の商品、3 つの実データ段落をナビゲーションやフッターの定型文で囲んだ記事、意図的なサーバー 500、そして内部リンクのグラフです。この設計があるからこそ、結果を揃えて比較できます。「8/8 の動的商品」という数値は、Puppeteer でも Crawlee でも同じ意味になります。
ただし、ここで多くのまとめ記事が飛ばしている境界があります。各ツールのパックは、それぞれのフィクスチャのコピーを持っているため、文字数の絶対値はツール間で厳密に比較できません。これはツール内での傾向として読むべきで、ツール横断の得点ではありません。比較可能なのは、再現率（recall。率として扱うこと）、JavaScript の成功/失敗、そして構造的な挙動です。同じ考え方でもう 1 つ補足すると、Crawl4AI の静的カタログ実行は 1 ページ目のみを対象にしたため、その 6/6 は範囲が狭い中での完全再現です。一方、他のツールは 2 ページ分を巡回して 12/12 を取りました。これは「取りこぼし」ではなく、対象範囲の違いです。詳細な判断は、方法論の解説 にフィクスチャごとに載せています。
数値の前に、もう 1 つだけ注意を。各パックには暫定的な研究スコアも入れていますが、あえて順位表としては出していません。あれは各ツールの証拠を検証するための内部用の補助であって、ランキング表ではないからです。もし並べて公開してしまうと、この企画全体が避けたかった「見かけだけの精度」をそのまま再現してしまいます。ここで示しているのは、ベンチが見せたものの総合であって、スコアボードではありません。
9 つのツールを 1 つのベンチに並べると
この表の「JavaScript を描画できるか」と「内蔵クロールキューがあるか」を縦に読んでいくと、3 つの仕事が自然に浮かび上がります。
| ツール | 言語 | JS を描画? | 静的再現率 | 構造化出力 | 内蔵クロールキュー | セットアップ負荷 | ライセンス |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | はい（ブラウザ） | 6/6（1 ページ目） | CSS スキーマ | BFS/DFS を内蔵 | 重い（ブラウザスタック 2 種） | Apache-2.0 |
| Firecrawl | Self-hosted | はい（playwright-service） | Markdown 完全出力 | あり | /v1/crawl | 最重量（コンテナ 6 個） | AGPL-3.0 |
| trafilatura | Python | いいえ | 3/3 記事 | なし（テキストのみ） | なし | 軽量 | Apache-2.0 |
| Crawlee | Node/TS | エンジンを選択可 | 12/12 | 抽出機能経由 | あり（RequestQueue） | 中程度（+約 80 MiB） | Apache-2.0 |
| Playwright | Node/multi | はい | 12/12 | 手動 | なし（BFS を自前実装） | 中程度（ブラウザ） | Apache-2.0 |
| Puppeteer | Node | はい（Chrome） | 12/12 | 手動 | なし（BFS を自前実装） | 中程度（Chrome） | Apache-2.0 |
| Scrapy | Python | いいえ | 12/12 | Feed 出力（JSON/CSV/XML） | あり（標準搭載） | 中程度（Twisted 依存） | BSD-3 |
| Colly | Go | いいえ | 12/12 | コールバック経由 | 深さ制御 | 軽量（1 バイナリ + Go） | Apache-2.0 |
| Scrapling | Python | いいえ（HTTP フェッチャー） | 12/12 | あり | なし | 中程度（[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 深掘りクロールでは 5 ページを巡回し、JavaScript ページを描画してスクリーンショットまで取得しました。とはいえ弱点も 2 つあります。生の Markdown にはコンテンツフィルターを有効にしない限りページの定型文が混ざりますし、意図的な 500 は success=false で返りました。これは Crawl4AI が HTTP エラーをきれいに捕まえたからではなく、自身のコンテンツ判定が小さなエラーボディを見て minimal_text ... blocked とみなしたからです。そしてセットアップでは、2 つのブラウザスタックがディスク上に載ります。バージョンは 0.9.0、Apache-2.0、2026 年 7 月初旬時点でおよそ 7.1 万スターです。
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 不具合に引っかかったため、事前ビルド済みイメージに切り替えました。また colima の 198.18.x.x DNS 範囲が Firecrawl の SSRF ガードを発動させたので、ALLOW_LOCAL_WEBHOOKS=true で回避しました。これはローカル開発用の回避策であって、本番環境で無効化すべきものではありません。なお、セルフホスト版の中核にはクラウド側の anti-block レイヤーである Fire-engine がなく、クラウド API は未検証です。さらに大きな論点はライセンスです。セルフホスト版の中核は AGPL-3.0 で、商用利用前にきちんと法務確認すべき対象です。2026 年 7 月初旬時点で約 14.8 万スターでした。
trafilatura はこの中でいちばん逆張りの存在で、AI ブーム系の一覧がよく忘れているツールです。ブラウザなし。構造化行なし。あるのは、Python だけで軽快に動く、きれいな記事本文の抽出です。記事フィクスチャではタイトルに加えて 3 段落すべてを取り出し、定型文は完全に除去されました。「Login」「Subscribe」「Copyright」のような文言は一切漏れません。さらに著者名と日付も取得できました。公開商品ページでは 1,324 文字の整ったテキストを返しています。限界は、その設計から明らかです。カタログを与えると、12 件の商品名をテキストとして返すことはできても 構造化された行は 0 です。文字はあるが構造はない。JavaScript も描画しません。バージョン 2.1.0（現行リリース）、Apache-2.0、約 6,200 スターです。純粋な記事抽出なら、真っ先に候補に入れるでしょう。
この 2 つの Markdown 文字数、Crawl4AI の 13,476 と Firecrawl の 9,222 は同じ公開ページから出たものですが、品質差として読むべきではありません。これは各ツールがどれだけページの外枠を残すかという Markdown 変換戦略の違いであって、どちらが優れているかの判定ではないのです。先ほどの「ツール内の指標として読む」ルールが、ここではっきり見えています。
仕事 2: JavaScript を安定して描画する
データの中には、スクリプトが動くまで HTML には現れないものがあります。その瞬間、実ブラウザは「あれば便利」ではなく「必須」になります。この仕事を担うのは 3 つのツールですが、そのうち 2 つは驚くほど似ています。
Playwright と Puppeteer は、私が試したすべてのテストで引き分けでした。ローカルのフィクスチャではどちらも 8/8 の動的商品を描画し、公開の Quotes JS サイトでも 10 件を取得。静的ページの再現率もどちらも 12/12。500 エラーも両者ともきれいに処理しました（Puppeteer は例外を投げず、レスポンスオブジェクトを返します）。どちらにもクロールキューはないので、どちらも BFS を自前で書く必要があり、それで depth 0〜2 のクロールグラフでは 12 ページに到達しました。実際の違いは到達範囲だけです。Playwright は Chromium、Firefox、WebKit を駆動でき、Python と .NET でも使えます。一方 Puppeteer は Chrome 優先で Node 専用です。なお、ここはバージョンの変化が速いので 2 点だけ明記します。Playwright は 1.56.0 を current の 1.61.1 と比較し、Chromium のみを試しました。Puppeteer は 24.16.0 を current の 25.3.0 と比較しています。必要なら再実行するか、その差分を割り引いて読んでください。どちらも Apache-2.0 で、スター数はそれぞれ約 9.2 万、9.5 万です。
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、約 2.46 万スターです。
仕事 3: ブラウザなしで高速にクロールする
ページに JavaScript がないなら、ブラウザは高コストな大げさ仕様です。ここでは HTTP ファーストの 3 ツールが競合します。言語哲学も 1 つずつ違い、しかも面白い違い方をします。
Scrapy は、この中でもっともエンジニアリング色の強いフレームワークです。spider、JSON/CSV/XML への feed 出力、AutoThrottle など、必要なものが一通り揃っています。静的ページの再現率は 12/12、記事の 3/3 段落も取得、crawl グラフでは depth 0〜2 で 11 ページを巡回し、handle_httpstatus_list を使って 500 も捕捉しました。面白いのは、その考え方です。レンダリングはしません。リクエストを再現するのです。JavaScript ページを投げると 0 ノードでしたが、その裏側にある JSON API には 8/8 で届きました。これが Scrapy の思想を 1 点で表しています。ページが発行するリクエストを見つけて再生する。ブラウザを操作するのではありません。その代わり、Twisted、lxml、parsel などの依存が重くつきます。しかも今回の検証は小さなフィクスチャに限定しました。バージョン 2.17.0、BSD-3-Clause、約 6.3 万スターです。
Colly は Go 版の答えで、何をするツールかが驚くほど素直に表れています。1 つの静的バイナリ、OnHTML、OnResponse、OnError によるコールバック駆動、そして深さ制御。静的再現率は 12/12 で、OnResponse 経由で JSON API から 8/8 を取得、500 は OnError で捕捉し、depth-2 クロールでは 17 ページに到達しました。ここは正確に言っておきます。このページ数はハーネス側のカウンタであって、Colly が完全性を保証した数ではありません。JavaScript はどうかというと、動的フィクスチャも Quotes JS サイトも 0。これは設計どおりです。ビルドには Go ツールチェーンが必要で、現在のモジュール版（v2.3.0）はタグ付きリリース（v2.2.0）より先行しています。Apache-2.0、約 2.5 万スターです。
Scrapling は特化型で、その肩書きにふさわしい実力があります。適応型セレクターは、HTML の構造が変わったあとでも要素を再発見するためのものです。たとえば対象の HTML クラスを product-name から product-title に変えると、普通のセレクターは 0 件でしたが、適応型の再マッチで追跡中の要素はちゃんと復元されました。素の HTTP 抽出では静的 12/12、JSON API では 8/8 を取得しています。とはいえ、ドキュメントでも隠していない限界があります。合成した複数要素のテストでは 3 件中 1 件しか復元できませんでした。これは「壊れても追える」仕組みであって、「全部自動で復元する」ものではない、ということです。初期セットアップには pip install scrapling に加えて [fetchers] の extras が必要で、StealthyFetcher は機能というよりコンプライアンス上の注意点として見ておくべきです。バージョン 0.4.10（現行リリース）、BSD-3-Clause、約 6.87 万スターです。
3 つの仕事の下にある共通パターン
9 つを並べると、きれいな構図が見えてきます。静的ページの完全再現率、つまり 12/12 は HTTP ファースト勢にとっては前提条件です。どのツールも易しいケースでつまずかなかったので、そこは差別化ポイントではありません。ブラウザ系が余計な重さを払うのは、JavaScript が実際に混ざるときだけで、しかもその代償はセットアップに現れます。ブラウザスタック、追加インストール、あるいはコンテナ群です。そして「内蔵クロールキュー」の列は、実質的にフレームワークとエンジンの境界線です。Scrapy と Crawlee はオーケストレーションを提供し、Playwright と Puppeteer は BFS を自分で書かせます。これがこの分野の形です。誰も総合優勝しないのは、そもそも全員が同じ競技をしていないからです。
では、実際にはどれを選ぶべきか
このベンチマークが勝者を 1 つに決めないのは、正解がツール名ではなく問いだからです。あなたがやっているのは、3 つの仕事のうちどれでしょうか。
- LLM 向けの Markdown が必要？ きれいな記事本文なら trafilatura。CSS 抽出や JavaScript 描画も 1 つで済ませたいなら Crawl4AI。セルフホストのサービスとして使いたくて、AGPL-3.0 と 6 コンテナの重さを受け入れられるなら Firecrawl。
- JavaScript の描画が必要？ 素の描画なら Playwright か Puppeteer。選ぶ基準はエンジンと対応言語で、性能はほぼ互角です。クロールのオーケストレーションも任せたいなら Crawlee。
- 静的ページや再現可能な API を大規模にクロールしたい？ Python の本格フレームワークなら Scrapy。1 バイナリで Go の速度を取りたいなら Colly。マークアップの変化に耐えることが日常的な悩みなら Scrapling。
仕事に合わせてツールを選べば、どれも十分に正当な選択です。逆のカテゴリを持ってくると──静的ページにブラウザツール、JavaScript アプリに HTTP パーサー──ネットで最も評価の高いライブラリでも期待を裏切ります。
では、マネージドな AI API はどこで役立つのか
ここまでのツールはすべて無料で、オープンソースで、自分で動かせます。けれど、ベンチ全体を通して見えてくる共通のトレードオフもあります。ブラウザ環境、クロールのコード、ボット対策とのいたちごっこ、そして保守の全部を自分で持つことです。多くのチームにとって、そのコントロールこそが価値ですし、ライセンスの違いも重要になります。分野の大半は寛容なライセンスです（Crawl4AI、Crawlee、Playwright、Puppeteer、Colly は Apache-2.0、Scrapy と Scrapling は BSD-3）。その中で Firecrawl のセルフホスト中核だけが AGPL-3.0 で、商用利用前には本当に確認が必要です。
ただ、ベンチマークが同時に示したのは「これらのツールがやらないこと」でもあります。レンダリング、クロール、構造化、ブロック回避を一度に、しかも保守なしでやってくれるわけではありません。マネージドな AI スクレイピング API は、そのスタックを 1 回の呼び出しに畳み込みます。私たちの Thunderbit の開発者向け面もその 1 つで、技術者にとって重要なのはブラウザ拡張ではなく、API、MCP サーバー、CLI です。POST /distill はきれいな Markdown を返し、POST /extract はスキーマ定義済みの JSON を返します。JavaScript の描画や anti-bot 対策は自分のマシンではなくサーバー側で処理されます。エージェントやコーディングアシスタント向けの公式 MCP サーバーもあり、thunderbit_suggest_fields で抽出設計を無料で下書きし、thunderbit_distill（1 クレジット）と thunderbit_extract（20 クレジット）で実行します。さらにターミナル作業や cron ジョブ向けには npx @thunderbit/thunderbit-cli で使える CLI もあります。開発者以外のメンバー向けにはノーコードの Chrome 拡張機能 もあり、料金ページ では両方の使い方をカバーしています。
トレードオフは、このベンチ全体が示してきたものと同じです。自分で 9 つまでのライブラリを運用し、1 回あたりのコストをゼロにするか。あるいは配線や運用を任せて、リクエストごとに支払うか。どちらが間違いということはありません。どこまでのスタックを自分で持ちたいか、それだけです。実際の抽出の流れを見たいなら、Thunderbit の YouTube チャンネル で紹介しています。
結論
「これが一番のオープンソーススクレイパー」という単独の答えはありません。そう断言する記事があるなら、そこで本当に決まるはずの問いを静かに隠しています。あなたがやっているのは 3 つのうちどれなのか、という問いです。ページをテキストにするのか、JavaScript を描画するのか、ブラウザなしで高速にクロールするのか。分野はきれいにその 3 つに分かれていて、各カテゴリの中では、選ぶ基準は言語とセットアップ負荷です。万能の覇者などではありません。
1 つだけ持ち帰る習慣があるとすれば、それは自分のページで試してから決めることです。ここに載せた数値がすべて benchmark repo で再現できるのは、そのためです。一般的なまとめ記事で上位でも、あなたの実データに耐えるとは限らないからです。
Thunderbit で Web データ抽出を試す 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 ライセンスのリポジトリにあります。覚えておくべき注意点は 1 つだけです。再現率と構造的な結果はツール間で比較できますが、文字数の絶対値は各ツール内でのみ意味があります。各パックは 1 つの正本を共有するのではなく、フィクスチャをそれぞれ複製しているからです。比較すべきは率と成功/失敗であって、生の文字総数ではありません。
