書いたきっかけ: 韓国の公共データを扱っていると、情報は公開されているのに、使いやすい API が用意されていないページに出会うことがあります。私はそういう場面で Firecrawl を使っています。似たような政策推薦サイトも見て、公式 API がない情報には、結局何らかの収集レイヤーが必要になるのだろうと感じました。
関連記事
要約
タイトルを Firecrawl・Crawl4AI・WaterCrawl の比較に変えたので、本文でも3つを同じ判断軸で見るようにしました。ただし、これは同じ URL セットを使った厳密なベンチマークではありません。API がない公共データページで Firecrawl を使ってみた感覚に、公開指標、self-hosted 対応、利用量が増えたときの運用目線を足したレビューです。
この記事の内容
この記事で扱う内容
Firecrawl を使い始めた理由
公共データを扱うときに困るのは、データが隠されていることだけではありません。むしろページ上には公開されているのに、開発者が使いやすい API がないケースがよくあります。検索画面の中に情報があったり、機関ページにだけ掲載されていたり、公式 API には必要な項目が入っていなかったりします。
きれいな API があるなら、もちろんそれを使うのが基本です。ただ、必要なデータに API がない場合は、ページを読み取り、LLM や小さなバックエンド処理で扱えるテキストに変換する方法が必要になります。そこで Firecrawl が役に立ちました。
Firecrawl・Crawl4AI・WaterCrawl の体感差
| 項目 | Firecrawl | Crawl4AI | WaterCrawl |
|---|---|---|---|
| 使い心地 | すぐ呼び出せる API に近い。 | 自分で動かして調整するクローラーに近い。 | self-hosted のクローリングサービスや内部 collector として育てる感覚に近い。 |
| 強み | JavaScript ページ、Markdown 変換、スクレイピング基盤まわりの面倒をかなり隠してくれる。 | ブラウザ設定、セッション、Cookie、抽出戦略、デプロイを細かく制御できる。 | 反復クローリング、queue、storage、monitoring のような運用型の収集フローを考えやすい。 |
| 体感性能 | 1ページまたは少数ページを素早く確認し、LLM 向けテキストを得るのに便利。 | 繰り返し大量に処理し、自分のパイプラインに組み込みたい場合に向きそう。 | 利用量が増え、self-hosted 運用を前提にすると改めて気になる候補になる。 |
| 費用と運用 | 無料プランで始めやすいが、利用量が増えるとクレジットと制限を見る必要がある。 | ソフトウェアとしては無料・オープンソースだが、サーバー、ブラウザ、メモリ、プロキシ、保守は自分の責任。 | 無料 credits で始められ、self-hosted 方向性もあるが、その場合の運用責任は自分が持つ。 |
他のレビューやプロジェクトの説明を見ても、Firecrawl は「Web を API のように扱える」点が評価されやすく、Crawl4AI は「自分で制御できる LLM-friendly crawler」に近い印象です。WaterCrawl はそこに self-hosted と反復クローリング運用の視点を足す候補です。つまり単純な速度勝負というより、管理型の手軽さ、直接制御できる自由度、反復収集の運用性の違いです。
公開されている数字で見ると
本当の速度比較をするなら、同じ URL セットを同じ条件で Firecrawl、Crawl4AI、WaterCrawl に流して測る必要があります。今回はそこまでの同条件ベンチマークはしていないため、公式ページや GitHub で確認できる数字と、自分の使用感を分けて整理しました。
| 項目 | Firecrawl | Crawl4AI | WaterCrawl |
|---|---|---|---|
| GitHub stars | 約 140.9k | 約 70.1k | 約 1.9k |
| GitHub forks | 約 8.1k | 約 7.2k | 約 235 |
| 公開 issue 数 | 約 367 | 約 115 | 約 6 |
| Self-hosted 対応 | 可能。ただし hosted service と open-source/self-host の扱いは分けて考える必要があり、運用負荷と AGPL 条件も確認したい。 | 可能。ローカル、サーバー、Docker API server として自分で動かせる点が大きな強み。 | 可能。README と公式ページのどちらも self-hosted & open source を強調している。 |
| ライセンス | AGPL-3.0 | Apache-2.0 | GitHub API では NOASSERTION/Other |
| 無料で始める条件 | 公式価格表では月 1,000 credits / 1,000 pages、同時リクエスト 2 | ライブラリ自体はオープンソース。費用は自分の実行環境次第 | 公式ページでは月 1,000 page credits、同時 crawl 1 |
| 性能に関する公式主張 | README では 96% web coverage、P95 latency 3.4s と説明 | async browser pool、caching、少ない hop を強調。ただし環境依存 | monitoring と crawl speed/depth 制御を強調。ただし公開ベンチマーク数値は限定的 |
この数字だけを見ると、Firecrawl は管理型サービスとしての規模が大きく、Crawl4AI はオープンソースのコミュニティがかなり大きい印象です。WaterCrawl は GitHub stars ではまだ小さいですが、無料 credits と self-hosted 方向性があるので、使用量が増えたときに改めて見たい候補です。
私にとって、この行はかなり重要です。使用量が増えると、API の手軽さよりも self-hosted で運用できるかどうかが効いてきます。だから今は Firecrawl をもう少し使いつつ、長期的には Crawl4AI や WaterCrawl のように自分で運用できる選択肢も見続けるつもりです。
公共データに API がないとき
私の使い方では、ここで Firecrawl が合いました。公共データポータルや機関サイトで、必要な情報に API が用意されていない場合、ページを Markdown や構造化テキストに変換してまず確認できます。この流れが思ったより楽でした。無料プランがあるので、小さく試しやすいのもよいところです。
もちろん、これは公式 API の代わりに何でもしてよいという意味ではありません。定期的に大量収集するなら、利用規約、robots.txt、リクエスト頻度、個人情報の有無を確認する必要があります。ただ「このページを LLM が読める形にできるか」を最初に試すには、Firecrawl はかなり敷居を下げてくれます。
似た政策推薦サイトを見て思ったこと
LifeReference の韓国政策推薦ページは、似た例として参考になりました。利用者が条件を入力すると、政府支援事業や政策資金に関する情報を推薦する構成です。ページには独自 REST endpoint があり、整理されたデータから推薦結果を返しているように見えます。
ただし、そのサイトの内部実装を外から見ることはできないため、「必ずクローリングしている」とは断定できません。とはいえ、この種のサービスは公式 API、自前 DB、手動整理、クローリングが組み合わさることが多く、対象データに公式 API がない場合は、何らかの収集パイプラインが必要になります。
私も似た問題に当たっているので、この点が気になりました。実際には、便利な公共ページはあるのに API はない、というケースが多いです。Firecrawl は、そのギャップを早く試すために役立ちます。
注意したい点
ベンチマーク数字だけで選ばない
Firecrawl は高速な応答や広いカバレッジを強調し、Crawl4AI は async browser pool、caching、細かなブラウザ制御を強調しています。ただし実際の性能は、対象サイトの構造、JavaScript rendering、ブロック方針、リクエスト量で変わります。
クローリングには運用責任がある
無料で便利だからといって、大量に取得してよいわけではありません。利用規約、robots.txt、頻度、著作権、プライバシーは確認が必要です。特に政策や支援金の情報は、読者が実際の判断に使う可能性があるため、最後は必ず原文を確認できるようにすべきです。
Crawl4AI は無料ソフトウェアだが、運用は無料ではない
Crawl4AI は Apache 2.0 ライセンスのオープンソースなので魅力的です。ただしブラウザ実行、デプロイ、メモリ、セッション、プロキシは自分で管理します。Firecrawl は始めやすく、Crawl4AI は本当に制御が必要になったときに強くなります。
結論
今の私の使い方では、まだ Firecrawl が先に手に取る選択肢です。必要な API がない公共ページを読み、LLM 向けのテキストに変換するまでの負担が小さいからです。利用量が増えれば、以前見た WaterCrawl にまた目が向きます。繰り返しクローリングする量が増えると、費用と運用の考え方が変わるからです。それでも今のところ Firecrawl で大きな問題はなく、無料で始めて結果を確認する流れが楽なので、もう少し Firecrawl を使ってみるつもりです。
実感としては、素早い実験と管理型の手軽さなら Firecrawl、直接運用と細かな制御なら Crawl4AIです。私の現在の利用量と目的では、Firecrawl をもう少し続けるのが自然です。
参考文献
- Firecrawl 公式サイト
- Firecrawl Scrape ドキュメント
- Firecrawl GitHub Repository
- Crawl4AI 公式ドキュメント
- Crawl4AI GitHub Repository
- LifeReference 韓国政策推薦ページ