WaterCrawl vs Firecrawl：LLM向けクローリングとサイドプロジェクトでの使い分け

要約

この記事の内容

WaterCrawl に注目した理由

LLM や RAG のために Web ページを使う場合、HTML をそのまま取得するだけでは不十分です。ナビゲーション、広告、フッター、サイドバー、スクリプトが混ざり、必要な本文だけを取り出す必要があります。

Firecrawl のような API は、この作業をすばやく試すにはとても便利です。ただし、クローリングがサイドプロジェクトの継続機能になるなら、収集結果、キュー、再試行、保存先を自分で制御できる構成も検討したくなります。WaterCrawl はその点で興味深い候補です。

WaterCrawl とは

WaterCrawl は Python、Django、Scrapy、Celery をベースにした Web クローリング、検索、サイトマップ生成、LLM-ready データ抽出のためのプラットフォームです。Docker Compose でセルフホストでき、REST API、SDK、非同期処理、Dify や N8N 連携を提供します。

• Docker Compose によるセルフホスト
• クロール深度、範囲、速度、対象パスの制御
• RAG に使いやすい Markdown/text 出力
• REST API と OpenAPI
• Python、Node.js、Go、PHP などの SDK
• Dify、N8N などのワークフロー連携

Firecrawl とは

Firecrawl は管理型 Web コンテキスト API に近いツールです。Search、Scrape、Crawl、Map、Batch Scrape、Interact などを提供し、SDK、CLI、MCP、AI agent 連携のドキュメントも整っています。

• URL を Markdown、HTML、スクリーンショット、構造化 JSON に変換
• Search API で検索結果と本文取得を接続
• Crawl API でサイト内ページを再帰的に収集
• JavaScript rendering、sitemap、path filter、rate limit 対応
• agent 連携がしやすい SDK、CLI、MCP

WaterCrawl vs Firecrawl

項目	WaterCrawl	Firecrawl
基本性格	セルフホスト可能なクローリング基盤	管理型 Web コンテキスト API
向いている用途	反復クロール、内部パイプライン、データ制御	高速な実験、agent 用 Web コンテキスト、運用負荷削減
実行方式	Docker Compose で自分で運用	API key で管理型サービスを利用
データ制御	保存先、再処理、保持方針を自分で決めやすい	URL と抽出結果が外部 API を通る
運用負荷	キュー、保存、失敗、更新を自分で見る	スクレイピング基盤の多くをサービス側に任せられる
サイドプロジェクト適性	反復クローリングがバックエンド機能になる場合に強い	インフラ構築前の検証に強い

長所と短所

WaterCrawl の長所

• セルフホスト: 対象、結果、保存場所、保持方針を制御しやすい。
• 反復クローリング: 同じ情報源を継続的に監視する用途に向く。
• パイプライン所有: キュー、再試行、再クロール方針をプロジェクトに合わせられる。
• コスト予測: 外部 API 使用量だけでなく、自前インフラ費用として考えやすい。

WaterCrawl の短所

• Docker、DB、キューワーカー、ストレージ、更新を運用する必要がある。
• 失敗、ブロック、再試行、対象サイトごとの調整を自分で見る必要がある。
• 管理型 API より初期設定に時間がかかる。

Firecrawl の長所

• API key だけですぐ試せる。
• JavaScript rendering、proxy、信頼性まわりの運用負担が少ない。
• agent 向けのドキュメントと連携が整っている。
• Search、Scrape、Crawl、Interact、Batch Scrape など機能が広い。

Firecrawl の短所

• 外部サービスへの依存がある。
• 利用量が増えると API 費用と制限管理が重要になる。
• 内部キュー、保存、再クロール方針までは完全に自分の設計にしづらい。

実際の使い分け

この2つを単純な勝ち負けで見る必要はありません。短時間の調査や一回限りの収集なら Firecrawl から始めます。ただし現在のサイドプロジェクトでは、既知の情報源を監視し、変更を比較し、失敗を再試行し、きれいな本文を RAG や要約に流す反復クローリングが重要になりそうです。

1. 最初の検証は Firecrawl

候補サイトの品質を確認し、抽出された Markdown が使えるかを見る段階では Firecrawl が便利です。インフラを作る前に素早く試せます。

2. 繰り返し見る情報源は WaterCrawl へ

技術ブログ、ドキュメントサイト、コミュニティ投稿、リリースノートのように継続的に確認したい情報源は、WaterCrawl を内部 collector として置くと扱いやすくなります。最初に sitemap を作り、その後は変更されやすい URL だけ再収集します。失敗 URL は retry queue に残し、成功した結果は Markdown/text として保存して embedding、indexing、summarization に渡します。

1. WaterCrawl を Docker Compose で起動する。
2. 情報源ごとに crawl depth、include/exclude path、rate limit を決める。
3. URL、title、crawl timestamp と一緒に Markdown/text を保存する。
4. きれいにした本文を embedding/RAG index に送る。
5. 毎回全部ではなく、変更 URL と失敗 URL を中心に再収集する。

判断に迷うポイント

セルフホストなら必ず安い？

必ずしもそうではありません。サーバー費用は予測しやすいですが、運用時間もコストです。小さな単発作業なら管理型 API の方が現実的に安く感じることがあります。

LLM-ready Markdown はそのまま RAG に入れてよい？

そのまま信じるのは危険です。title、URL、収集時刻、本文長、重複、抽出失敗を最低限記録した方がよいです。LLM-ready は raw HTML より扱いやすいという意味であり、常に正しい知識片という意味ではありません。

クローラーがあれば法的・倫理的問題は解決する？

いいえ。robots.txt、利用規約、著作権、個人情報、過度なリクエスト負荷は別に確認が必要です。ツールで簡単にできることと、してよいことは同じではありません。

結論

Firecrawl は、今すぐ Web を検索・スクレイピングして LLM や agent に渡したい場合に強い選択肢です。WaterCrawl は、クローリングが単発作業ではなく、サイドプロジェクトの継続的な機能になる場合により魅力的です。

私なら、まず Firecrawl で情報源と抽出品質を確認し、繰り返し収集する価値がある情報源を WaterCrawl に移します。これなら素早い実験と長期運用のバランスを取りやすくなります。

参考文献

• 🔗 PyTorchKR: WaterCrawl 紹介
• 🔗 WaterCrawl GitHub Repository
• 🔗 WaterCrawl 公式サイト
• 🔗 Firecrawl GitHub Repository
• 🔗 Firecrawl Docs: Introduction
• 🔗 Firecrawl Docs: Crawl
• 🔗 Firecrawl Docs: Search
• 🔗 Firecrawl Docs: Scrape