昨年、組織の96%がオープンソースの利用を増やした、または維持したと、2025 State of Open Source report は報告しています。理由として最も多かったのは、やはり「ライセンス費用がかからない」ことでした。ただし、GitHubでスクレイパーを拾ってくるときに見落としがちな点があります。「オープンソース」であることと、「商用プロダクトで安全に使える」ことは、まったく同じ意味ではありません。
私は今年のかなりの時間を、Scrapy、Playwright、Puppeteer、そして Crawl4AI や ScrapeGraphAI のような新しいAIネイティブのクローラーまで、定番どころを整理しながら費やしてきました。その中で、ビジネス判断に本当に効くポイントは、よくある「おすすめスクレイパー一覧」ではほとんど触れられません。それがライセンス種別です。多くのリストはGitHubスター数で順位をつけますが、私は法務チームに「これ、AGPLですか？」と聞かれたときに何が起きるかを基準にしています。このリストでは、まず用途との相性（パーサー、ブラウザ自動化、AIネイティブ、クロールフレームワーク、ノーコード拡張機能）を優先し、次にライセンスで並べています。なぜなら、実際の意思決定はその順番で進むからです。
オープンソースWebスクレイパーで最初に見るべきなのはライセンス種別
「オープンソース」だからといって、「好き勝手に使っていい」という意味ではありません。Open Source Definition では商用利用への差別が明確に禁じられています。つまり、このリストに載っているツールはすべてビジネス利用が可能です。ただし、どう使えるのか、そして実際に組み込んだときにどんな義務が発生するのかは、それぞれのライセンス次第です。
MIT、BSD-3-Clause、Apache-2.0 のような寛容的ライセンスは、著作権表示を残しておけば、ほぼ何でもできます。とくに Apache-2.0 には明示的な特許許諾があり、法務担当が好むことの多いライセンスです。これら3つはいずれも、自分のソースコードを公開する義務はありません。
一方、コピーレフト系は別物です。とくに人を悩ませやすいのが AGPL-3.0 で、Firecrawl の self-hosted core はまさにこのライセンスです（SDK は MIT ですが、コアのスクレイピングエンジンは AGPL です）。AGPL-3.0 の第13条では、対象プログラムを改変し、その改変版をネットワーク経由でユーザーに使わせる場合、対応するソースコードを提供しなければなりません。これはネット掲示板で言われがちな「SaaS全体がオープンソース化する」という話ではありません。義務の対象は、あくまで改変した対象プログラムを遠隔利用させる場合です。ただし、クローズドソース製品の土台にする前には、Stack Overflow の書き込みではなく、実際に法務へ相談すべき論点です。
さらに、より曖昧な「オープンコア」もあります。Web Scraper のChrome拡張は、GitHub上に LGPL-3.0 の履歴リポジトリがありますが、その最終コード更新は2017年で、現行の Chrome Web Store 版（本稿執筆時点で version 1.111.13）とその古いソースが同一であることを示す検証済みの対応関係はありません。正直に言えば、ローカル拡張は無料で使えますが、スケジューリングやプロキシローテーションを含むCloudプランは別の独自製品です。これをまとめて「オープンソース」と呼ぶと、その分かれ目がぼやけてしまいます。
この12個のオープンソースWebスクレイパーをどう比較したか
各ツールは、7つの観点で評価しました。ライセンス種別と商用利用時の摩擦、言語・実行環境、JavaScript描画のネイティブ対応（プラグイン併用が必要かどうか）、学習コスト、見落としやすい計算資源・プロキシコスト、コミュニティの健全性（未解決Issue、リリース頻度、最終コミット）、そして最適な用途です。
一覧はスター数順ではなく、静的パーサー、ブラウザ自動化フレームワーク、AIネイティブスクレイパー、クロールフレームワーク、最後にノーコードのブラウザ拡張というカテゴリ別に並べています。これは意図的です。Beautiful Soup と Scrapy はどちらも人気ですが、解く問題がまったく違います。同じ軸で順位をつけても、ツール選びの助けにはなりません。
| 評価項目 | 確認した内容 |
|---|---|
| ライセンスと商用適性 | リポジトリの正確なライセンス、帰属表示要件、コピーレフトやネットワーク条項 |
| 実行環境とチーム適性 | Python、Node/TypeScript、Java、またはマルチ言語対応か |
| JS描画 | ネイティブのブラウザ対応、プラグイン併用、または非対応か |
| フレームワーク範囲 | パーサー専用、ブラウザドライバ、フルクロール基盤、管理型プロダクトか |
| コミュニティ健全性 | GitHubスター数、最新リリース日、未解決Issue、最終push |
| 見えにくいコスト | ブラウザのメモリ使用、プロキシ要件、モデルAPI依存、保守負荷 |
| 最適用途 | 具体的なチーム／タスクとの一致、公式ドキュメントやIssueで裏付けられた機能 |
コミュニティ健全性の数値について、ひとつ正直に補足しておきます。Beautiful Soup の本来の開発基盤は Launchpad であり、GitHubではありません。そのため、GitHubスター数（2022年以降更新のない非公式ミラーで223スター）は、他の10ツールと単純比較できません。ここではその点を明示したうえで扱っています。
静的サイト向けの最有力オープンソース解析ライブラリ: BeautifulSoup
BeautifulSoup は、HTML/XML のパースツリーをたどったり検索したりするための Python ライブラリです。ページ取得も、JavaScript実行も、クロールキューの管理も行いません。すでに手元にあるマークアップを、扱いやすいAPIで掘り出すだけのツールです。この用途の狭さこそがポイントで、HTML はもう取得済みで、そこからデータを抜き出したいときに使う定番です。
- ライセンス: MIT — 表示を残せばよく、義務はほぼありません
- 学習コスト: かなり初心者向け。オブジェクトモデルが柔軟です
- JS描画: ネイティブ対応なし。先に描画済みHTMLを取得する別ツールと組み合わせます
- 既知の制約: 公式ドキュメントでも「下層のパーサーより速くなることはない」と明言されています。また、lxml、html5lib、html.parser などのバックエンド差で、壊れたHTMLのツリー構造がかなり変わることがあります
向いている用途: 静的HTMLや取得済みHTMLからの、社内向けの短いスクリプトや単発抽出。大規模処理やJS主体のサイトには向きません。
レガシーなクロスブラウザテスト向けの最有力ブラウザ自動化フレームワーク: Selenium
Selenium はこのリストで最も歴史の長い名前です。もともとはブラウザテストのために作られ、その後スクレイピング用途にも広く転用されました。強みは速度ではなく対応範囲です。公式の Selenium 4 バインディングは Java、Python、C#、Ruby、JavaScript をカバーし、W3C WebDriver 標準を通じて Chrome、Edge、Firefox、Safari を操作できます。
- ライセンス: Apache-2.0
- GitHubの健全性: 34,366スター、未解決Issue 98件、過去1年で安定版12回リリース（最新: 4.47.0）
- JS描画: 実ブラウザ経由でネイティブ対応
- 公開されている摩擦点: Selenium自身のドキュメントでは、同期処理を「最も一般的な課題のひとつ」と説明しています。文書が読み込まれても、JavaScriptで追加された要素まで準備完了とは限らず、動的DOMの更新で
StaleElementReferenceExceptionが出ることがあります
向いている用途: 複数ブラウザや複数言語をまたぐ対応が必要なチーム、あるいはすでにQAでSeleniumを使っていて、その知識をスクレイピングにも流用したいチーム。
現代的なJS主体サイト向けの最有力オープンソースブラウザ自動化フレームワーク: Playwright
Microsoftが保守する Playwright は、「Selenium は遅くて面倒」という不満に対する現代的な答えです。Chromium、Firefox、WebKit をネイティブで操作でき、要素が実際に使える状態になるまで自動で待つ actionability check を備えています。表示可、安定、操作可能になるまで待機するため、その自動待機だけで、Selenium ユーザーが手書きで書いてきた WebDriverWait の定型コードの多くが不要になります。
「Scrapy vs. Playwright vs. Selenium」の議論でよく抜け落ちる点を補足すると、Scrapy は単独では JavaScript を描画しません。ブラウザ描画を得るには、scrapy-playwright を別途組み込む必要があります。Playwright と Puppeteer は、描画そのものが製品の中心なので、ネイティブに描画できます。
- ライセンス: Apache-2.0
- GitHubの健全性: 94,443スター、過去1年で安定版15回リリース（最新: 1.62.1）
- 見えにくいコスト: ブラウザバイナリだけで Chromium 約281 MB、Firefox 約187 MB、WebKit 約180 MB かかります。さらに 1.38 の破壊的変更でブラウザの自動ダウンロードが止まったため、Dockerイメージのバージョン固定が重要です
向いている用途: React/Vue のSPAを扱うチームで、手書きの待機ロジックなしに安定したクロスブラウザ動作が必要な場合。
Chrome中心プロジェクト向けの最有力オープンソースブラウザ自動化ツール: Puppeteer
Google自身の自動化ライブラリである Puppeteer は、設計思想からしてChrome中心です。Chrome DevTools Protocol との深い統合、スクリーンショットやPDF生成の標準搭載など、機能は充実しています。ここで古い認識を修正しておくと、現在の Puppeteer は安定版Firefoxも公式対応しています。とはいえ、主用途がChromeである点は今も変わりません。
- ライセンス: Apache-2.0
- GitHubの健全性: 95,458スター、未解決Issue 249件。Playwrightより未解決Issueがかなり多く、レスポンス性を重視するなら判断材料になります
- アンチボットの現実: Puppeteer issue #7006 には、ごく普通の遷移がCloudflareのチャレンジに引っかかった例が記録されています。ページを描画できるからといって、アンチボット対策をすり抜けられるわけではありません
向いている用途: Chromeに標準化した Node.js チーム、とくにスクレイピングと合わせてPDFやスクリーンショットも生成したい場合。
LLMとRAGパイプライン向けの最有力AIネイティブスクレイパー: Crawl4AI
Crawl4AI は内部で Playwright を使い、LLMやRAGパイプライン向けに、素のHTMLのごちゃつきではなく整理されたMarkdownを出力することに特化しています。クリーンなMarkdownを出すモードと、コンテキストウィンドウ向けに調整された Fit Markdown モードの両方があり、必要ならLLM抽出も使えます。CSS/XPathやBM25による絞り込みは、モデルAPIに触れずに動かせます。
ここで明確に注意しておくべき点があります。GitHub上では Apache-2.0 と表示されていますが、実際のライセンスファイル には、公開利用や配布に対する帰属表示の必須条件が追加されています。標準の Apache-2.0 ではなく、Apache-2.0 にプロジェクト独自条件が加わったものです。見るべきなのはGitHubのバッジではなく、実際のライセンスファイルです。
- GitHubの健全性: 77,959スター、最新リリース v0.9.2（2026年7月）
- 必要リソース: self-hostingガイド では、コンテナに少なくとも4GBの空きRAMを推奨しています
- 公開されている不安定要素: v0.9.0 の変更履歴では、Dockerサーバーの認証デフォルト変更やモジュール移動などの破壊的変更が記録されています。動きの速いプロジェクトなので、バージョン固定が必須です
向いている用途: 新しいWebデータをLLMエージェントやRAGパイプラインに流したい Python チームで、ブラウザ基盤を自分たちで管理できる場合。
ライセンス上の注意点はあるが、self-hosted 展開に強いAIネイティブスクレイパー: Firecrawl
Firecrawl の self-hosted core は、AGPLの話を具体化する存在です。Fetch と Playwright を基盤にした APIファーストのクローラーで、Markdown、HTML、スクリーンショット、構造化データを返せます。確かに高機能です。ただし、人々が「Firecrawl」と聞いて思い浮かべる洗練された部分――アンチボット処理、プロキシローテーション、Fire-engine のステルス層――は Firecrawl Cloud 側の機能であり、self-hosted リポジトリには含まれていません。Firecrawl の self-host ドキュメント でも、Fire-engine と高度なアンチボット挙動はデフォルトの self-hosted 構成には含まれないと明記されており、スクリーンショット取得やページ操作にはそれが必要です。
- ライセンス: コアは主に AGPL-3.0-or-later、SDK は MIT
- GitHubの健全性: 166,527スター。このカテゴリでは非常に大きな数字です
- 導入の現実: self-hosting には Redis、RabbitMQ、PostgreSQL、必要に応じて FoundationDB を立てる必要があります。単一コンテナではなく、複数サービスを運用する構成です
向いている用途: AGPLのソース提供義務を受け入れられる社内ツールやオープンソースプロジェクト。クローズドソースの商用製品を self-hosted core の上に直接構築する場合は、法務確認なしに進めないでください。
自然言語で抽出できる最有力AIネイティブスクレイパー: ScrapeGraphAI
ScrapeGraphAI は、セレクタを書かずに、欲しい内容を自然言語で指示できます。LLM呼び出しがフィールド対応付けを担当する、グラフベースのパイプラインです。MITライセンスのこのライブラリは自前のインフラで動かします。LLM APIキーを使うか、トークン代を避けたいならローカルの Ollama モデルも使えます。Playwright のインスタンスも自分で用意します。
ここで明示しておきたいのは、「オープンソース」だからといって「継続コストゼロ」ではない、という点です。抽出のたびに、接続しているモデルに対してトークンを消費します。また、プロンプト駆動の抽出には、セレクタ型ツールにはない特有の失敗モードがあります。ある未解決Issue では、処理自体はすべて成功しているのに、ページ上に明らかに存在していたデータが空欄や NA として返るケースが報告されています。決定的に動く CSS/XPath では起きにくい、静かな失敗です。
- ライセンス: MIT
- GitHubの健全性: 29,447スター、最新安定版 v2.1.6
向いている用途: たまに発生する不定形な抽出タスクで、プロンプトの柔軟性がモデルコストや検証コストに見合う場合。
軽量かつモデル不要の抽出に強いAIネイティブスクレイパー: AutoScraper
AutoScraper はLLMを完全に使いません。URLと、抽出したいサンプル値を渡すと、ページの構造ルールを推測し、似たページに再利用します。モデルAPIキーもトークン料金も不要で、内部では requests と BeautifulSoup を使っています。
フォーラムでこのツールに「放棄された」といったラベルを貼る人がいますが、それは正確ではありません。2025年半ばには実際にコミットがあり、リポジトリの最終pushは2026年7月です。ただし、実際に pip install されるパッケージ版は、いまだに2022年の v1.1.14 のままです。正しい言い方は「リリースの更新頻度がかなり遅い」であって、「死んだプロジェクト」ではありません。
- ライセンス: MIT
- GitHubの健全性: 7,844スター
- 明確な制限: ネイティブのJS描画はありません。
requests.get()で取得したHTMLをそのまま解析するだけです
向いている用途: 構造が安定した静的ページでの、小規模かつ反復的な抽出。レイアウト変更のたびに再学習する程度なら許容できるケース。
大規模なPythonプロジェクト向けの最有力クロールフレームワーク: Scrapy
Scrapy は、本番運用向けのPythonクロールフレームワークです。エンジン、スケジューラ、ダウンローダー、アイテムパイプラインなど、必要なものが一通り揃っています。Beautiful Soup がメスなら、Scrapy は手術室そのものです。非同期ネットワーク、ドメインごとの同時実行制御、AutoThrottle、CSV、JSON、JSON Lines、XML、クラウドストレージへの直接出力まで備えています。
先ほど触れた点は、Scrapy で最も誤解されやすい部分なので、ここでもう一度強調します。Scrapy にはネイティブのJavaScript描画がありません。Scrapyの公式ドキュメント でも、まずは裏側のデータ要求を見つけて再現することを勧めています。なぜなら、そのほうがブラウザ全体を描画するより速く、しかも完全なことが多いからです。JSが本当に避けられない場合にだけ scrapy-playwright を使います。
- ライセンス: BSD-3-Clause
- GitHubの健全性: 63,830スター、未解決Issue 304件、過去1年で安定版9回リリース（最新: 2.17.0）
- レート制限の穴: 公開されている改善要望 では、AutoThrottle はHTTP 429ではなくレイテンシに基づいて調整するため、レスポンスを見たバックオフは自前で実装する必要があると指摘されています
向いている用途: JS描画が不要な大規模静的サイトのクロールで、構造化パイプラインと出力の柔軟性を重視する場合。
Node.jsの本番環境向けクロールフレームワークの最有力候補: Crawlee
Apify チームの Crawlee は、Node/TypeScript 版の Scrapy に最も近い存在です。ただし、JavaScript描画を後から足すのではなく、Playwright と Puppeteer を使ったクローラークラスが、共通のキュー、ストレージ、プロキシローテーション層の上に最初から組み込まれています。
- ライセンス: Apache-2.0
- GitHubの健全性: 25,364スター、過去1年で安定版8回リリース（最新: 3.18.1）
- 注目ポイント:
AutoscaledPoolは、CPU、メモリ、イベントループの負荷に応じて 同時実行数を動的に調整 します。しかも、最小同時実行数を高くしすぎるとクロール全体が落ちると明記されています
向いている用途: 自前でScrapy相当の部品を組み合わせることなく、JS描画と本番向けのキュー管理を両立したい Node.js/TypeScript チーム。
エンタープライズ向けJavaインデックス処理の最有力クロールフレームワーク: Apache Nutch
Apache Nutch はこのリストの中でも異色です。大規模なWebインデックス構築のために作られた Java 製クローラーで、通常は Solr、Elasticsearch、OpenSearch にデータを流し込みます。競合サイトの価格を拾うためのツールではありません。検索インデックスの下支えとなるクロール層を作るときに、エンタープライズ検索チームが選ぶツールです。
- ライセンス: Apache-2.0
- GitHubの健全性: スター数は3,276と少なめですが、最終pushは2026年8月と最近です。低スター数は放置ではなく、特化ニッチを反映しています
- JS対応: 別途
protocol-seleniumプラグインが必要です。JIRAチケット では、その経路でのHTTPSプロキシ失敗が報告されています
向いている用途: Java/Hadoop 基盤をすでに運用していて、アドホックなデータ抽出ではなく、エンタープライズ規模のWebインデックスが必要なチーム。
最有力のノーコードブラウザ拡張: Web Scraper
Web Scraper は、クリック操作で使える選択肢です。Chrome DevTools 内で動くサイトマップ／セレクタツリーの作成ツールで、ページネーションの追跡、ボタン操作、無限スクロールのページ処理、CSV/XLSX へのローカル出力まで、コード不要でこなせます。
この一覧の中でも、ここではオープンコアの分かれ目が特に重要です。ローカル抽出は本当に無料です。ただし、定期実行、自動クラウド実行、APIアクセス、プロキシ管理はすべて Web Scraper Cloud の向こう側にあり、別料金です。そして前述のとおり、一般公開されている LGPL-3.0 のソースリポジトリは2017年以降コード更新がありません。したがって、「オープンソース」はローカル拡張の歴史的な系譜を指すものとして受け止め、現在の Chrome Web Store 版の透明性を保証するものだとは考えないでください。
向いている用途: コードを書かずに、たまにローカルで抽出したい個人や小規模チーム。スケールは不要なケース。
静的パーサーとヘッドレスブラウザ: JS主体サイトでどちらを選ぶべきか
まず、この議論の前提になる数字があります。98.9%のWebサイトがJavaScriptをクライアント側言語として使っている というものです。ただし、この数字はよく「98.9%のサイトをスクレイピングするにはヘッドレスブラウザが必要」と言い換えられますが、それは誤りです。これはJavaScriptの存在を示す指標であって、目的のデータが初期HTMLにあるのか、スクリプト実行後にしか出てこないのかまでは示していません。
本当に見るべきなのはその違いです。この12個のツールは、素直に2つの箱に分けられます。
静的パーサー — BeautifulSoup、AutoScraper — は高速で安価ですが、クライアント側で描画された内容には完全に目が見えません。欲しいデータが初期HTMLレスポンスに入っている、あるいは直接叩けるJSONエンドポイントにあるなら、速度と単純さでこれらが常に勝ちます。
ヘッドレスブラウザ系 — Playwright、Puppeteer、Selenium、Crawlee のブラウザクローラ — は実際にJavaScriptを実行します。そのぶん、実際の計算資源を消費します。HTTP Archive の2024年データ では、モバイルでのページ中央値のJavaScript容量は558KB、JSリクエスト数は22件でした。これは各ページ読み込みごとにヘッドレスブラウザが処理する負荷です。静的パーサーが生HTMLを拾うだけなのと比べると、かなり重い作業です。
そして Scrapy は少し特殊で、もう一度言っておく価値があります。Scrapy はどちらでもありません。完全なクロールフレームワークですが、ネイティブ描画はゼロです。JSが必要なら scrapy-playwright を足す必要があります。
「無料」の隠れコスト: プロキシ、計算資源、保守工数
ライセンス費用ゼロは、総コストの一部にすぎません。実際のコストは、私は次のような具体的な要素に分けて考えます。
計算資源。 ヘッドレスブラウザを大規模に動かすというのは、サーバー時間だけでなく、ブラウザ秒数に対してお金を払うということです。AWS Fargate では、Linux/x86 の場合、およそ vCPU秒あたり $0.000011244、GB秒あたり $0.000001235 です。これに同時実行中の Playwright インスタンス数を掛けると、思った以上に早く積み上がります。
プロキシ。 Bright Data の公開料金 では、住宅プロキシは約 $5/GB から、データセンタープロキシは $0.9/IP からでした。しかも、この種の料金体系でいう「帯域幅」には、ダウンロード分だけでなく、リクエストとレスポンスの両方が含まれます。レート制限やブロック回避は無料ではなく、インフラ予算の継続費用です。
保守。 この一覧にある静的パーサーや構造ルール系ツールはすべて、サイトのデザイン変更でセレクタが壊れるリスクがあります。AutoScraper のREADMEの例ですら、対象サイトの変更後に価格更新が必要でした。これが、$0 のライセンス表示には一切出てこない「見えない計算資源／プロキシコスト」です。つまり、対象サイト側の開発チームがリニューアルを出したあとに、壊れた抽出を直すためのエンジニア工数です。
この壁に何度もぶつかっているチーム、つまりセレクタの壊れやすさ、プロキシアカウント管理、終わりの見えないDevOps負荷に悩んでいるなら、self-hosted なオープンソース基盤が、エンジニア工数まで含めると必ずしも安いとは限りません。Thunderbit の Chrome拡張 は、開発者以外向けに別のやり方を取っています。許可されたページを開き、One Click Extract を押すだけで、何を抜くべきかページを解析します。セレクタも、レイアウト変更時の保守スクリプトも不要です。Scrapy の代わりになるものではありませんが、壊れやすい AutoScraper のルールを手作業で保守してきた業務ユーザーにとっては、次の一歩として十分現実的です。
判断フレームワーク: チームの制約に合うツールを選ぶ
多くの比較記事は「この用途にはこれが最適」で終わります。しかし、それは変数が1つしかない場合の話です。実際のチームは少なくとも4つを同時に見ています。JS描画の必要性 × チームの言語 × 必要な出力形式 × ライセンス制約 です。
| チームの状況 | 最適なツール | 理由 |
|---|---|---|
| Python、静的HTML、簡単なスクリプト | BeautifulSoup、AutoScraper | JS不要、MITライセンス、最小限のセットアップ |
| Python、大規模な構造化クロール | Scrapy | BSD-3-Clause、組み込みパイプライン、JSが本当に必要な場合だけ scrapy-playwright を併用 |
| Node/TypeScript、本番クロール＋JS | Crawlee | Apache-2.0、キュー機構にネイティブブラウザ対応が組み込み済み |
| 多言語対応、広いブラウザマトリクス | Selenium | Apache-2.0、最も広い言語／ブラウザカバー範囲 |
| モダンSPAの自動化、クロスブラウザ | Playwright | Apache-2.0、ネイティブ描画、自動待機を標準搭載 |
| Chrome特化の自動化、スクリーンショット／PDF | Puppeteer | Apache-2.0、CDPとの深い統合 |
| LLM/RAG向けMarkdownパイプライン | Crawl4AI | Apache-2.0 + 帰属表示条項。追加条件を法務が許容できるか確認 |
| プロンプト主導の不定形抽出 | ScrapeGraphAI | MIT、ただしLLMトークンコストを見込むこと |
| API連携型のself-hostedクローラー、AGPL許容 | Firecrawl | AGPL-3.0-or-later。クローズドソースSaaSの上に載せる前に法務承認が必要 |
| エンタープライズJava/Hadoopインデックス | Apache Nutch | Apache-2.0、検索基盤向けに特化 |
| ノーコード、たまに使う非開発者向け | Web Scraper拡張 | ローカルは無料。完全に透明だと決めつける前にオープンコアの分かれ目を理解すること |
12個のオープンソースWebスクレイパーを一覧で比較
| ツール | 言語 | ライセンス | 商用利用は安全？ | JS描画 | 学習コスト | 向いている用途 |
|---|---|---|---|---|---|---|
| BeautifulSoup | Python | MIT | ✅ はい | なし（併用が必要） | 低 | 静的HTMLの解析 |
| Selenium | マルチ言語 | Apache-2.0 | ✅ はい | ネイティブ | 中 | マルチブラウザ／多言語のテスト兼スクレイピング |
| Playwright | JS/TS/Python/Java/.NET | Apache-2.0 | ✅ はい | ネイティブ | 中 | 現代的なJS主体サイト |
| Puppeteer | Node.js/TS | Apache-2.0 | ✅ はい | ネイティブ | 中 | Chrome中心の自動化 |
| Crawl4AI | Python | Apache-2.0 + 帰属表示条項 | ⚠️ 条項確認が必要 | ネイティブ（Playwright経由） | 中 | LLM/RAG向けMarkdownパイプライン |
| Firecrawl（self-hosted） | TypeScript | AGPL-3.0-or-later（コア） | ⚠️ 条件付き | ネイティブ（Playwright経由） | 高（複数サービス） | self-hosted AIクロール、AGPL許容環境 |
| ScrapeGraphAI | Python | MIT | ✅ はい | ネイティブ（Playwright経由） | 中 | 自然言語による抽出 |
| AutoScraper | Python | MIT | ✅ はい | なし | 低 | 軽量な反復静的タスク |
| Scrapy | Python | BSD-3-Clause | ✅ はい | 併用が必要 | 高 | 大規模静的サイトのクロール |
| Crawlee | Node.js/TS | Apache-2.0 | ✅ はい | ネイティブ | 中 | Node.js の本番クローラー |
| Apache Nutch | Java | Apache-2.0 | ✅ はい | プラグインが必要 | 高 | エンタープライズ検索インデックス |
| Web Scraper（拡張機能） | なし（ノーコード） | オープンコア | ⚠️ プラン次第 | ネイティブ（実ブラウザ） | 低 | 非開発者のたまの利用 |
結論: どのオープンソースWebスクレイパーを使うべきか？
ここに「唯一の最適解」はありません。正解は、ライセンス制約、チームの言語、そして対象データが静的HTMLにあるのか、それともJavaScriptの壁の向こうにあるのかで変わります。大規模な静的Pythonクロールなら Scrapy が有力です。JS描画が必須なら Playwright か Crawlee が勝ちます。LLMパイプラインに流すなら Crawl4AI が合っていますが、ライセンスファイルに追加の帰属表示条項がある点は一読に値します。Firecrawl の self-hosted core は強力ですが、AGPLの論点があり、そこには法務チームが最初から関わるべきです。
そして、セ
