VPS向け自ホストFirecrawl代替サービス比較
Draco、Hound、自ホスト型FirecrawlをRAM、ヘッドレスブラウザー、API互換性で比較します。固定バージョンのインストールとMCP接続方法も紹介します。
自ホスト型 Firecrawl 代替サービスに必要な機能
自ホスト型 Firecrawl 代替サービスの役割は、URL を受け取り、エージェントが読み取れるクリーンな markdown としてページを返すことです。ホスト型 API はページ単位で課金されるため、エージェントが調査するほど料金が増えます。一方、すでに料金を支払っている VPS でも同じ処理を実行できます。プロジェクトの違いを分けるのは、1 つの問題です。ヘッドレスブラウザー(ウィンドウを表示せずに動作する実際のブラウザーエンジン)を自分のサーバー上で起動する必要があるかどうかです。
この違いによって、メモリ使用量、ページごとのコスト、空の結果が返るページが決まります。このガイドでは、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 はデーモンとして動作し、Firecrawl が使用するポートである 127.0.0.1:3002 で応答します。コンテナイメージは提供されず、ブラウザーも起動しません。
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 サーバーであり、フェッチャーはその次です。通常の HTTP を試し、通常のフェッチがブロックされた場合にのみ Patchright ブラウザーを起動します。
Trawl は、他のプロジェクトを検索する際に見つかるものの、異なる役割を担うため、ここで扱います。フィンガープリントをパッチした Firefox を使用して JavaScript チャレンジと CAPTCHA を解決し、*arr メディアスタックで FlareSolverr の代替として動作します。markdown 抽出ツールではありません。以下のエチケットに関するセクションでは、この違いによって、そもそもエージェントスタックに含めるべきかどうかが決まる理由を説明します。
小規模 VPS がブラウザプールで停止する理由
開いているブラウザーの各タブは、独自の DOM(document object model)と JavaScript ヒープを保持する、個別の renderer プロセスです。そのため、メモリ使用量は 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 を超える上限を設定しても効果はありません。サーバーのメモリが不足すると、kernel の 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 は、ページ独自の JavaScript をプロセス内の V8 isolate で実行します。これは、ブラウザーを伴わない 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 フラグには 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 エージェントのどれからでも利用できる共有サービスになります。エージェント側の実装に最も不安がある場合は、まず 小さなエージェントループを手作業で実装すると、fetch ツールをどこに組み込むか、モデルが取得した Markdown をどう処理するかが明確になります。
FAQ
AI エージェントがページを取得するにはヘッドレスブラウザーが必要ですか?
ほとんどのページでは必要ありません。サーバーでレンダリングされるドキュメント、ブログ、ニュース記事は、通常の HTTP 取得と HTML から Markdown への変換だけで完全な内容を取得できます。これは Draco の下位ティアで行われており、プロジェクトの公称値では、ブラウザーを使わずに 1 ページあたりおよそ 300 ms です。クライアント側でレンダリングされ、取得した HTML が空のシェルになるアプリケーションでは、ブラウザーを使う価値があります。Draco の V8 isolate はブラウザープロセスなしでその中間部分の多くに対応します。対応できない場合は終了コード 3、needs_browser、で終了します。
VPS でセルフホストする Firecrawl には、どの程度の RAM が必要ですか?
compose ファイルでは、api コンテナの上限を 8 GB、Playwright コンテナの上限を 4 GB に設定しています。同じ構成で Redis、RabbitMQ、PostgreSQL、FoundationDB も起動します。8 GB を確保してください。2 GB のサーバーでは、負荷がかかると kernel の out-of-memory killer がコンテナを停止します。最初の兆候は、アプリケーションログに有用な情報がないまま docker compose ps でコンテナが再起動することです。dmesg -T | tail で確認してください。
Draco は Firecrawl API のドロップイン置換ですか?
v1 のエンドポイントについては、ほぼ置き換え可能です。/v1/scrape、/v1/map、/v1/crawl、/v1/batch/scrape、/v1/search を提供し、認識できないリクエストフィールドは無視します。そのため、Firecrawl v1 向けに作成したクライアントでは、通常はベース URL の変更だけで済みます。ただし、ホスト型の製品ではありません。背後に管理されたプロキシプールはなく、Firecrawl の新しい v2 ルートも対象外です。エージェントが行う各呼び出しを、まず curl で確認してください。
スクレーパーをセルフホストすれば、robots.txt を無視できますか?
いいえ。コードを実行する場所が変わっても、サイトが公開した内容や利用規約で許可される範囲は変わりません。Draco と Firecrawl はどちらもデフォルトで robots.txt を尊重します。上書きフラグは、自分が所有するサイトや、クロールの書面による許可を得たサイト向けです。相手側ではレート制限が常に適用されるため、低い並行度で控えめに --delay を実行すれば、IP アドレスを使い続けられます。チャレンジウォールを回避しなければ機能しない構成は、予告なく動作しなくなります。