著者 VPS向けFirecrawl代替ツール3選を比較
Draco、Hound、自己ホスト型FirecrawlをRAM、ヘッドレスブラウザーの要否、API互換性で比較します。固定バージョンのインストールとMCP接続も解説します。
自己ホスト型 Firecrawl 代替ツールに必要な機能
自己ホスト型の Firecrawl 代替ツールの役割は 1 つです。URL を受け取り、エージェントが読み取れるクリーンな markdown としてページを返します。ホスト型 API はページ単位で課金されるため、エージェントが多くのページを調べるほど料金が増えます。すでに料金を支払っている VPS で同じ処理を実行することもできます。プロジェクトの違いは、ヘッドレスブラウザー（ウィンドウを表示せずに動作する実際のブラウザーエンジン）を自分のサーバー上で起動する必要があるかどうかです。
この違いによって、メモリ使用量、ページごとのコスト、空の結果が返るページの種類が決まります。このガイドでは Draco、Hound、自己ホスト型 Firecrawl リリースを比較します。最も軽量なものを固定したバージョンでインストールし、MCP（model context protocol）経由でエージェントに接続します。
4 つのプロジェクトと、それぞれの実体
Draco は Rust で記述された単一バイナリで、MIT または Apache-2.0 ライセンスです。リリース v0.20.5 は 16 July 2026 に公開されました。draco scrape <url> は markdown を stdout に出力します。draco serve は 127.0.0.1:3002 で応答する daemon を実行します。これは Firecrawl が使用するポートです。コンテナイメージは提供されず、ブラウザーも起動しません。
Firecrawl self-hosted はホスト型製品の基盤となるエンジンで、AGPL-3.0 ライセンスです。その docker-compose.yaml では、playwright-service、api、redis、rabbitmq、nuq-postgres、foundationdb、foundationdb-init の 7 つのサービスを定義します。実際のクロールキューを利用できますが、小規模な分散システムを運用する必要があります。
Hound は master-fetch リポジトリにあり、hound-mcp として PyPI に公開されています。MIT ライセンスで、3 August 2026 時点のバージョンは 13.0.1 です。Python 3.11 以降が必要です。これはまず MCP server であり、fetcher はその次です。通常の HTTP を試し、通常の fetch が blocked になった場合に限り Patchright browser を起動します。
Trawl は、他のプロジェクトを検索する際に見つかるものの、役割が異なるためここで扱います。fingerprint-patched Firefox を使用して JavaScript challenge と CAPTCHA を解決し、*arr media stack では FlareSolverr の代替として機能します。markdown extractor ではありません。以下のエチケットに関するセクションでは、この違いによって、そもそも agent stack に組み込むべきかどうかが決まる理由を説明します。
小規模な VPS がブラウザプールで停止する理由
開いているブラウザータブは、それぞれ独立した renderer プロセスとして動作し、固有の DOM (document object model) と JavaScript ヒープを保持します。そのため、メモリ使用量は 1 日に取得したページ数ではなく、同時に開いているページ数に応じて増加します。これらのプロジェクトのうち 2 つは、このコストを独自の compose ファイルに記載しています。
The data behind this chart
[
{
"label": "Firecrawl api",
"memory_limit_gb": 8
},
{
"label": "Firecrawl playwright",
"memory_limit_gb": 4
},
{
"label": "Hound (browser included)",
"memory_limit_gb": 3
}
]Firecrawl の compose ファイルでは、api コンテナの上限を 8 GB、Playwright コンテナの上限を 4 GB に設定し、それぞれに対応する swap の上限も設定しています。Hound の compose では、Chromium を組み込んだ 1 つのコンテナに 3 GB を設定しています。これらは各プロジェクトが選択して公開している上限値であり、負荷のないシステムを測定した値ではありません。さらに、Firecrawl の数値とは別に Redis、RabbitMQ、PostgreSQL、FoundationDB もメモリを必要とします。
所有している RAM を超える上限を設定しても意味はありません。サーバーのメモリが枯渇すると、カーネルの out-of-memory killer がプロセスを終了させます。そのため、アプリケーションログにエラーが記録されないまま、コンテナが docker compose ps から消えることがあります。原因を説明できない再起動が発生した場合は、dmesg -T | tail を確認してください。Firecrawl スタック全体には 8 GB を割り当て、テスト用サーバーの最低ラインは 4 GB と考えてください。サービスごとの数値設定については、Docker Compose のメモリ制限で説明しています。
ブラウザーには、もう 1 つ見落としやすい点があります。Docker は /dev/shm でコンテナに 64 MB の共有メモリを割り当てます。Chromium はそこに renderer のバッファーを置くため、負荷の高いページでクラッシュします。どちらのブラウザースタックもこの値を増やしており、Hound の compose には shm_size: "1gb" が記載されています。Playwright を使用するイメージを構築する場合は、この行をコピーしてください。
JavaScript を多用するページでの抽出品質
静的 HTML、サーバーでレンダリングされたブログ、ドキュメントページ、ニュース記事では、いずれもほぼ同じ Markdown が返り、最も速いものが勝ちます。違いが現れるのはクライアントレンダリングのページです。この場合、配信される HTML は空のシェルで、読み込み後に JavaScript がテキストを取得します。
Draco は段階的に処理を強化します。Tier 0 と Tier 1 は、JavaScript をまったく実行せずに HTML を解析します。Tier 2 は、プロセス内の V8 isolate でページ独自の JavaScript を実行します。これは、ブラウザーを伴わない JavaScript エンジンです。README には、ここでページコードにホスト機能のバインディングは提供されないと記載されています。ブラウザーのメモリ使用量の一部で、多くのシングルページアプリケーションに対応できます。Draco が通過できない壁に遭遇すると、draco scrape はコード 3 で終了し、needs_browser。スクリプトではこの状態を確認してください。終了コードが 0 なのにファイルが空になると、エージェントのコンテキストを気付かないうちに汚染する障害になるためです。
draco scrape https://example.com > page.md
echo "exit=$?"Firecrawl の playwright-service は実際の Chromium を操作するため、ブラウザーと同じ内容をレンダリングします。ただし、セルフホスト版はホスト型製品と同じではありません。ドキュメントには、セルフホストインスタンスは Fire Engine にアクセスできないため、クラウドサービスのブロック回避機能と IP ローテーション機能を利用できず、/agent エンドポイントと /browser エンドポイントもサポートされないと記載されています。Hound は、意図的にその中間に位置します。HTTP で取得し、リクエストごとに処理を強化します。また、アイドルタイムアウト後にウォームブラウザーを終了するため、アイドル状態のホストではベースライン付近の状態を維持できます。
固定したバージョンで Draco をインストールする
README には 1 行のインストーラーが記載されています。シェルにパイプする前に、その動作を確認してください。$HOME/.draco/bin/draco にインストールし、常に latest リリースを取得します。また、署名もハッシュも検証しません。サーバーでは、バージョンを固定してダウンロードを検証してください。
cd /tmp
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/draco-linux-x86-64.tar.gz
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMSdraco-linux-x86-64.tar.gz: OK と表示されます。FAILED 行が表示された場合、手元のバイト列はプロジェクトが公開したものと一致しません。削除して、最初からやり直してください。
mkdir -p draco-v0.20.5
tar -xzf draco-linux-x86-64.tar.gz -C draco-v0.20.5
sudo install -m 755 "$(find draco-v0.20.5 -type f -name draco | head -n1)" /usr/local/bin/draco
draco scrape https://example.com最後のコマンドは、例のページを Markdown として 1 秒未満で出力します。find は飾りではありません。アーカイブの構成はプロジェクトの公開契約に含まれておらず、公式インストーラーも同じ方法でバイナリの場所を特定します。
ログインユーザーではなく、専用アカウントでデーモンを実行してください。/etc/systemd/system/draco.service を作成します。
[Unit]
Description=Draco fetch daemon
After=network-online.target
Wants=network-online.target
[Service]
User=draco
ExecStart=/usr/local/bin/draco serve --host 127.0.0.1 --port 3002 --max-concurrency 4
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
[Install]
WantedBy=multi-user.targetsudo useradd --system --no-create-home --shell /usr/sbin/nologin draco
sudo systemctl daemon-reload
sudo systemctl enable --now draco
curl -s http://127.0.0.1:3002/healthデーモンが待ち受けを開始すると、/health はすぐに応答します。Connection refused の場合は待ち受けていないため、journalctl -u draco -n 50 を確認してください。通常の原因は、別のプロセスがすでに 3002 を使用していることです。3002 は Firecrawl のデフォルトポートでもあります。--port により、どちらかのポートを変更できます。unit ファイルの詳細については、systemd の service unit と timer を参照してください。
エージェントが使用する方法で、次に取得します。
curl -X POST http://127.0.0.1:3002/v1/scrape \
-H 'content-type: application/json' \
-d '{"url": "https://example.com", "formats": ["markdown"]}'公開インターネットから fetch daemon を切り離す
認証のない fetch API はオープンプロキシです。ポートに到達できるユーザーは誰でも、あなたのサーバーにあなたの IP アドレスから任意の URL へリクエストさせられます。悪用の報告先はそのユーザーではなく、あなたのプロバイダーです。Draco が文書化している serve flags には API key が含まれていません。そのため、保護はネットワーク側で行う必要があります。agent が同じホスト上で動作する場合は、デフォルトの 127.0.0.1 bind を維持してください。agent が別の場所にある場合は、両端をプライベートトンネルに接続してください。通常は、自分でホストする WireGuard VPN が適しています。0.0.0.0 ではなく、トンネルのアドレスに bind してください。その後、別のマシンから確認し、public IP が何も応答しないことを確認します。ufw firewall の基本 と 最小権限のユーザーアカウント で、この2つの側面を扱います。
エージェントのコードは変更が必要ですか？実際の API 互換性
Draco は Firecrawl v1 のルートである /v1/scrape、/v1/map、/v1/crawl、/v1/batch/scrape、/v1/search に応答し、README には未知のフィールドを受け入れて無視すると記載されています。すでに /v1/scrape に POST しているエージェントは、ベース URL を変更するだけで済みます。相手側で何が移動したかを確認してください。Firecrawl 独自のセルフホスティングページは現在 /v2/crawl でテストしており、現行の SDK は v2 を使用しています。そのため、Draco を指す v2 クライアントは、Draco が公開していないルートを要求します。エージェントのコードを編集する前に、curl で各呼び出しをテストしてください。また、ステータスコードではなく JSON ボディを読み取ってください。実装間の差異は、フィールド名に現れるためです。
Robots.txt、レート制限、そして越えてはならない境界
Draco はデフォルトで robots.txt を読み取り、--ignore-robots でこれを無効にします。Firecrawl も同じデフォルトを採用しています。どちらも変更しないでください。次に、独自のペースを設定します。--delay はリクエスト間にミリ秒単位の間隔を設け、--max-concurrency は並列ジョブ数を制限します。デーモンのデフォルト値は 8 です。共有 VPS の回線では 2 ～ 4 にすると負荷を抑えられ、全体として遅くなることもほとんどありません。サイトからレート制限を受け始めると、並列処理で短縮できる時間よりも多くの時間を失うためです。取得した内容はキャッシュしてください。2 回目のエージェント実行で、取得元に負荷をかけずに済みます。これは AI エージェントのコストを管理するうえで、最も安価な項目でもあります。
チャレンジウォールは別の問題です。Trawl はまさにそのために作られており、Cloudflare Turnstile、reCAPTCHA、hCaptcha、GeeTest に対応します。チャレンジウォールとは、サイトが自動化されたトラフィックを明確に拒否する仕組みです。これを回避すると、サイトの利用規約に抵触し、地域によっては法律にも触れる可能性があります。そのため、このガイドでは取得基盤の説明にとどめます。チャレンジウォールを通過するための技術は、サイト運営者が監視してブロックする技術でもあります。そのため、それに依存するパイプラインは無礼なだけでなく、脆弱になります。重要な情報源であれば、RSS フィード、公開 API、または一括エクスポートを探してください。どれも運用コストが低く、チャレンジウォールが変更された週に動かなくなることもありません。
MCP 経由でエージェントに接続する
MCP (model context protocol) は、エージェントがツールを呼び出すためのインターフェースです。Draco は同じバイナリに MCP サーバーを組み込み、stdio 経由で提供します。
{ "mcpServers": { "draco": { "command": "draco", "args": ["mcp"] } } }ツールはエージェントから draco_scrape、draco_search、draco_interact_* セットとして利用できます。stdio は、エージェントのプロセスとバイナリが同じマシン上にある場合にのみ機能します。トランスポートが、そのプロセスの標準入力を使用するためです。別のホスト上のエージェントには、Hound が MCP を HTTP 経由で提供します。hound --http --host 127.0.0.1 --port 8765 により http://127.0.0.1:8765/mcp にエンドポイントが公開され、トンネル経由で接続できます。トランスポートの選択肢と公開する内容については、VPS 上で MCP サーバーを実行するを参照してください。
検索でペアを取得します。取得しかできないエージェントは、URL を指定するまで待機します。自己ホスト型 SearXNG 検索インスタンスを追加すると、エージェント自身で URL を検索できます。これは、SearXNG を基盤とするブラウザー検索スキルと同じ構成です。デーモンを起動すると、実行する 自己ホスト型 AI エージェントのいずれからでも利用できる共有サービスになります。
FAQ
AI エージェントがページを取得するためにヘッドレスブラウザーは必要ですか？
ほとんどのページでは必要ありません。サーバー側でレンダリングされるドキュメント、ブログ、ニュース記事は、通常の HTTP fetch と HTML-to-markdown 処理だけで完全な内容を取得できます。Draco は下位ティアでこの方式を採用しており、プロジェクトの公表値では、ブラウザーを使わず 1 ページあたり約 300 ms です。ブラウザーが必要になるのは、クライアント側でレンダリングされ、取得した HTML が空の外枠だけになるアプリケーションです。Draco の V8 isolate はブラウザープロセスなしで、その中間にある多くのケースを処理します。処理できない場合は終了コード 3、needs_browser で終了します。
VPS 上で self-hosted Firecrawl を動かすには、どの程度の RAM が必要ですか？
compose file では、api container の上限を 8 GB、Playwright container の上限を 4 GB に設定しています。同じ stack では Redis、RabbitMQ、PostgreSQL、FoundationDB も起動します。8 GB を見込んでください。2 GB のマシンでは、負荷がかかると kernel の out-of-memory killer が container を停止させます。最初の兆候は、application log に有用な情報がないまま docker compose ps で container が再起動することです。dmesg -T | tail で確認してください。
Draco は Firecrawl API の drop-in replacement ですか？
v1 endpoint については、ほぼ同等です。/v1/scrape、/v1/map、/v1/crawl、/v1/batch/scrape、/v1/search を提供し、認識できない request field は無視します。そのため、Firecrawl v1 向けに作成した client は、通常 base URL を変更するだけで済みます。ただし、hosted product ではありません。背後に managed proxy pool はなく、Firecrawl の新しい v2 route も対象外です。エージェントが実行する各 call は、まず curl で確認してください。
scraper を self-hosting すれば、robots.txt を無視できますか？
いいえ。コードを実行する場所が変わっても、サイトが公開した内容や利用規約で許可される範囲は変わりません。Draco と Firecrawl は、デフォルトで robots.txt を尊重します。override flag は、自分が所有するサイトや、crawl の書面による許可を得たサイト向けに用意されています。どのような場合でも、接続先では rate limit が適用されます。そのため、concurrency を低くした丁寧な --delay により、IP address を継続して利用しやすくなります。challenge wall を回避しなければ機能しない stack は、予告なく動かなくなります。