ほとんどの人はFirecrawlを、pip installしてスクリプトを書けば終わり、というスクレイピングライブラリの一種だと分類するはずです。でもこの認識は間違いで、コマンドを一つ打つ前にその違いを理解しておくことが大事です。Firecrawlのセルフホスト版は取ってきて使うライブラリではなく、自分で運用するサービスであり、立ち上げるには互いに通信する6つのDockerコンテナを動かす必要があります。
私はMac（arm64、colima経由のDocker）でクラウドキーなしにセルフホストのスタックを動かし、その/v1/scrapeエンドポイントをスクレイピング向けのデモサイトいくつかにつないで結果を観察しました。結論から言うと、主要な約束は守られていました。ページを入力すれば、きれいなLLMフレンドリーなマークダウンが出力されます。ただし、この検証基盤で試したどのツールよりもセットアップが重かったです。これは暫定的な評価であって、最終評価ではありません。何を確認して、何を確認していないのかははっきり書きます。
Firecrawlはサービスであって、ライブラリではない
まず、考え方を少し切り替えましょう。多くの開発者が使うスクレイピングツールはライブラリです。依存関係を追加し、関数を呼び、自分のプロセスの中でHTMLやパース済みのデータを受け取ります。Firecrawlのセルフホスト版は違います。独自のAPIを持つ稼働中のプラットフォームであり、HTTP経由でやり取りします。
公式のポジショニングは「Webを大規模に検索・スクレイピング・操作するためのAPI」であり、製品の形はまさにその言葉どおりです。ページを入力すればきれいなマークダウンや構造化データが出力されます。セルフホストする場合、Firecrawlにリンクするのではありません。docker composeスタックを立ち上げ、内部マイクロサービスを呼ぶのと同じようにエンドポイントを叩くことになります。
私が動かしたスタックは、6つのサービスで構成されていました。
- api — 実際に呼び出すHTTPインターフェース
- playwright-service — JavaScriptレンダリング用のヘッドレスブラウザ
- redis — キューおよびキャッシュ
- rabbitmq — メッセージブローカー
- nuq-postgres — ジョブ状態管理用のPostgres派生
- foundationdb — 分散キーバリューストレージ
これはヘルパースクリプトではなく、れっきとしたバックエンドです。Redis、RabbitMQ、Postgres、FoundationDBはそれぞれ産業グレードのインフラです。その代わりにFirecrawlは、スクレイピングの面倒な部分（キューイング、レンダリング、リトライ）を1回のAPI呼び出しの裏側で処理してくれます。対価は、この6つのコンテナを運用しなければならないこと。このトレードオフを頭に置いておいてください。これがこのレビュー全体のテーマです。
参考までに、私はfirecrawl-py 4.32.0およびfirecrawl-js 4.30.0のSDKでテストし、2026年7月9日時点の公式ビルド済みイメージghcr.io/firecrawl/firecrawl:latestを使いました。このリポジトリはその時点で約14万8千のスターを集めており（品質スコアというよりメタデータとして）、AGPL-3.0ライセンスの下にあります。この点は後で扱いますが、商用利用の計算を変えうる部分です。
中核テスト：ページがきれいなマークダウンに変換される
Firecrawlが存在する唯一の理由は、WebページをLLMが実際に読めるマークダウンへ変換することです。なのでまずはここを確認しました。
/v1/scrapeを、スクレイピング練習用に作られた静的カタログbooks.toscrape.comにつなぎました。結果は9,222文字のきれいでLLMフレンドリーなマークダウンで、ページタイトルAll products | Books to Scrapeも正確にパースされていました。文字列としてダンプされた生HTMLではなく、見出し、リンク、画像参照がそのまま構造化されたマークダウンです。これは検索パイプラインにそのまま流し込んだり、二度目の整形なしでモデルに直接食わせたりできる種類の出力です。
これがFirecrawlの最大の強みで、セルフホスト版もそれを問題なくこなしました。もしあなたの仕事が「このページの読める内容をマークダウンで出す」ことなら、静的ページは宣伝どおりに返ってきます。これは本当に有用な基本機能であり、このツールが支持される理由です。
範囲についてははっきり書いておきます。私が動かしたのは単一ページの/v1/scrapeの経路です。サイト全体を巡回するマルチページクローラーの/v1/crawlはテストしていません。これは独自の失敗モードを持つ別機能であり、動かしていないものを「動く」と主張するつもりはありません。
JavaScriptページ：同梱ブラウザがコンテナの価値を証明する
静的ページは簡単なケースです。スクレイパーにとって難しいのは、JavaScriptが実行されたあとにしかコンテンツが表示されない場合、つまり現代のWebではほぼ大半のケースで何が起きるか、という問題です。
ここでplaywright-serviceコンテナが、オーバーヘッドではなく真価を発揮します。私はスクレイパーをquotes.toscrape.com/js/につなぎました。これは引用をクライアント側でレンダリングするデモサイト版です。Firecrawlが生HTMLしか取得しないなら、引用は表示されないはずです。ブラウザがページのスクリプトを実行するまで存在しないからです。
スクレイピングの結果、1,574文字のマークダウンが返り、アインシュタインの引用が含まれていました。この引用はJavaScript実行後のコンテンツです。その存在は、playwright-serviceがテキスト抽出の前に実際のブラウザエンジンでページをレンダリングした証拠であり、レンダリング前の空の器を取得したのではないということです。
つまり、6つのコンテナのうち1つはヘッドレスブラウザであり、その役割をきちんと果たしているということです。これがより重いアーキテクチャの具体的な正当化になります。コンテナのコストを払っているだけでなく、自前のブラウザ自動化を構築せずにJSの多いページをレンダリングできる能力に対して払っているわけです。多くの実際のターゲットにとって、これは使える出力と空のdivとの差になります。
ターゲットが不正なとき：構造化されたエラー、クラッシュなし
スクレイパーは、その生涯の驚くほど多くの時間を、動かないもの（死んだホスト、タイプミスのあるURL、止まるサーバー）に費やします。ツールがどう失敗するかは、どう成功するかと同じくらい重要です。
私は意図的に無効なホストをAPIに渡しました。すると構造化されたHTTP 500が返り、実行はそのまま継続しました。クライアントにスタックトレースが降ってくることもなく、コンテナが倒れることもなく、プロセスが止まることもありませんでした。エラーは、呼び出し側で分岐できるきれいなレスポンスとして返ってきました。
これはパイプラインに組み込むうえで期待される、地味で正しい挙動です。不正なターゲットでパニックになるスクレイパーは、自動化できないスクレイパーです。このスクレイパーは、キャッチして次へ進めるエラーを返しました。私は単一のエラーケースしか試していないので、これは「投げた1つの失敗を正しく処理した」と解釈してください。網羅的な耐障害性の監査というより、1つのデータポイントが正しい結果だった、ということです。
セットアップの現実：検証基盤の中でもっとも重い作業
さて、誰もローンチのツイートにスクリーンショットを載せない部分です。Firecrawlのセルフホスト版は誇張抜きで、この検証基盤のどのツールよりも複雑なセットアップでした。しかも私は、かなりの数のツールを立ち上げてきています。
6つのコンテナが基本コストです。ただ立ち上げの途中で2つの問題にぶつかりました。そしてそれが誰の責任だったのかも、はっきり書いておきたいと思います。結論から言うと、Firecrawlの落ち度ではありませんでした。
問題1：ソースからのビルド。 ソースからのイメージビルドは、colima VM内のcontainerdスナップショットのエラーで失敗しました。これはビルドとcolimaのストレージ層のあいだで知られている不安定な相互作用であり、Firecrawlのバグではなく私の環境側のインフラ問題です。composeファイルには代替手段が明記されています。ローカルでビルドする代わりに、公式のビルド済みイメージghcr.io/firecrawl/*を使うというものです。これに切り替えたところ、スタック全体がきれいに立ち上がりました。colimaではなく標準のDockerデーモンを使っているなら、この問題には当たらないかもしれません。これは環境上の注意点として挙げておきます。クリーンなデーモンでコントリビューター向けビルドを検証するのは、私の未検証リストに入っています。
問題2：SSRFガード。 最初のスクレイピングは、Firecrawlのプライベートアドレス／SSRF保護によってブロックされました。なぜか？colimaのネットワークは公開ホスト名を198.18.x.xのアドレスにマッピングします。これはFirecrawlが正しくプライベートとして扱う予約済み範囲に含まれるため、そのセキュリティ層が働き、内部ターゲットに見えるものの取得を拒否したわけです。ローカルテストのためだけにこれを回避するにはALLOW_LOCAL_WEBHOOKS=trueを設定しました。
このフラグは本番環境にコピペされてインシデントを引き起こしかねないので、それが何なのかを正確に理解してください。SSRFガードは機能であって、欠陥ではありません。スクレイピングサービスが内部ネットワークへアクセスするよう騙されるのを防ぐものです。私が無効化したのは、colimaのDNSの特性のせいで、正当な公開ターゲットがVM内ではプライベートに見えてしまったからです。実際のデプロイではSSRF保護を切らないでください。このレビューから運用上の注意点を1つ持ち帰るなら、それです。
どちらの問題も正直に言えば、私のノートPCでcolima経由でDockerを動かしたことに起因するもので、ソフトウェアの欠陥ではありませんでした。とはいえ同時に、セットアップの重さそのものは現実であり、Firecrawlの設計に由来するものです。これは簡単なローカルスクリプトが欲しいときに使うツールではなく、レンダリング可能なスクレイピングサービスが必要で、そのためにインフラを運用する覚悟があるときに使うツールです。
テストしていないこと、そしてできないこと
ここでは、私が扱わなかったことと、このツールが提供しないことについて説明します。
セルフホスト版にはFire-engineがありません。 Firecrawlのクラウド製品には、ボット対策を回避するための独自のアンチブロック層であるFire-engineが含まれています。プロジェクト自身のSELF_HOST.mdによれば、セルフホストのインスタンスにはそれがありません。したがって、セルフホスト版Firecrawlが積極的なアンチボットシステムをそのまま突破できると思っているなら、その認識は修正してください。その機能はクラウド層にあり、私が動かした部分には含まれていませんでした。
クラウドAPIはここではテストしていません。 クラウドキーがなかったため、上の内容はすべてセルフホストのスタックにのみ当てはまります。Fire-engine、ホスティングされたスケーリング、AI機能を含むマネージドのクラウドサービスは別製品であり、外から性能を評価するつもりはありません。クラウドに関する主張は、このレビューの範囲外だと考えてください。
AI機能にはキーが必要です。 jsonの構造化出力フォーマットと/extractエンドポイントはLLMに依存しており、OpenAIのキーを用意するかOllamaをつなぐ必要があります。これによりモデル選択が原価に含まれてきます。設定を決める前に、利用できるプロバイダーの現在のAPI価格を比較してください。私はこれらの経路を動かしていないので、/extractと構造化json出力も未テスト項目に含まれます。
プロキシは注意点であって、主要機能ではない。 Firecrawlはプロキシ設定に対応していますが、意図的に脚注として触れています。これは調整できる部分であって、このツールを選ぶ理由ではありません。セルフホスト版には、依然としてクラウドのアンチブロック層がありません。
AGPL-3.0は実際に判断が要る準拠事項です。 これは独立した節を割く価値があります。
ライセンス：出荷する前にAGPL-3.0を読んでおく
FirecrawlはAGPL-3.0の下でライセンスされています。これはREADMEの末尾に付け足された注記ではなく、ネットワーク利用条項を含む強いコピーレフトであり、セルフホストのインスタンスの上に商用製品を構築できるかどうかに直接影響しうるものです。
簡単に言うと、標準のGPLの義務は配布時に発生します。AGPLはさらに踏み込み、ネットワーク利用条項によって、ネットワーク越しにユーザーへソフトウェアの機能を提供することが、ソース公開義務を伴う利用とみなされうることを意味します。顧客がインターネット経由でアクセスするサービスの中にセルフホスト版Firecrawlを組み込む場合、この条項ははっきり適用され、「バイナリを出荷したことはない」という言い分は、多くの人が思っているような抜け道にはなりません。
私はあなたの弁護士ではありませんし、ライセンスの解釈は配布のかたちによって変わります。ただ商用利用を勧めるかどうかという点で、AGPL-3.0は重要な検討事項であり、小さな注意書きではありません。作り始める前に社内のライセンス担当と相談してください。これを指摘するのはFirecrawlを非難することではありません。多くの優れたツールがAGPLを採用しています。早い段階で考慮すべき事実だ、というだけです。
Thunderbitの開発者スタックが向いている場面
もしあなたの実際の目的が「ページ → LLMフレンドリーなマークダウン」または「ページ → 構造化データ」であって、6つのコンテナの運用コストとAGPLの問題を自分で抱え込みたくないなら、まさにThunderbitの開発者スタックがその隙間を埋めるために作られています。10万人以上の拡張機能ユーザーが使っているのと同じAIエンジンが、技術寄りの作業向けに3つの形で公開されています。インフラはこちらで管理します。
- Open API（REST）。
POST /distillはページをきれいなLLMフレンドリーなマークダウンに変換し、POST /extractは定義したJSON Schemaに従って構造化データを返します。JSレンダリング、アンチボット対応、動的コンテンツはサーバー側で処理されます。ブラウザコンテナを自分で動かす必要はありません。renderModeフラグ（none/basic/full）でレンダリング強度を制御でき、バッチエンドポイントは最大100件のURLを抽出できます。 - MCPサーバー。 公式のModel Context Protocolサーバー経由で、ClaudeやCursor内のAIエージェントが作業中にスクレイピングできます。抽出計画には
thunderbit_suggest_fields（無料）、マークダウンにはthunderbit_distill、構造化データにはthunderbit_extract。エージェントは環境を離れずに、いつデータを取りに行くかを判断します。 - CLI。
npx -y @thunderbit/thunderbit-cliは、ターミナル、スクリプト、CI、cronからスクレイピングを実行します。ブラウザも、管理するスタックも不要です。他のツールへ直接パイプできます。thunderbit distill "$URL" -f markdown | claude -p "summarise"
セルフホスト版Firecrawlとの対比は明確です。Firecrawlのセルフホスト版は完全な制御と、完全な運用責任を与えてくれます。6つのコンテナ、セットアップの重さ、AGPLの条件、そしてアンチブロック用のFire-engineは無し。ThunderbitのAPI/MCP/CLIは、その制御と引き換えに、スキーマに沿った構造化JSON（生のマークダウンだけでなく）を返すホスティング済みエンジンを提供します。コンテナ、アンチボット層、コピーレフト義務はあなたの負担から外れます。インフラに対する望みが異なる人のための、異なるツールです。
トレードオフを一覧にしてみます。
| 検討事項 | Firecrawl セルフホスト版 | Thunderbit 開発者スタック（API・MCP・CLI） |
|---|---|---|
| 提供形態 | 自分で運用するサービス（6コンテナ） | 呼び出すだけのホスティング済みAPI |
| 動かし始めるまで | 6サービスのスタックをdocker composeで起動 | APIキー、そのあとリクエスト |
| JSレンダリング | 同梱のplaywright-service（自分で実行） | サーバー側、renderModeフラグ |
| 構造化出力 | LLMキーが必要（/extract、json） | JSON Schemaを使うPOST /extract |
| アンチボット層 | セルフホスト版には無し（Fire-engineはクラウド専用） | サーバー側で処理 |
| ライセンス | AGPL-3.0（ネットワーク利用コピーレフト） | 商用API、自分のコードにコピーレフトなし |
| 向いているケース | 完全な制御が欲しく、インフラを運用する場合 | 運用なしでマークダウン／構造化データが欲しい場合 |
どちらが一律に「優れている」とは言えません。プラットフォームの運用そのものが目的なら、つまり完全なデータ制御、外部依存なし、AGPLが状況に合うなら、セルフホスト版Firecrawlは有能で活発にメンテナンスされている選択肢です。APIを叩いて6つのコンテナ運用を省きたいなら、それがThunderbitスタックの提案です。
実際にFirecrawlをセルフホストすべき人
誇大な宣伝を取り払うと、必要に応じてはっきり切り分けられます。
スクレイピングのインフラを完全に制御したく、Redis / RabbitMQ / Postgres / FoundationDBを本番で運用することに慣れていて、レンダリング要件がplaywright-serviceコンテナを正当化し、AGPL-3.0が配布のかたちに合うなら、Firecrawlをセルフホストしてください。中核の機能は本物です。静的ページとJSレンダリングのページのどちらからも、きれいで構造化されたLLMフレンドリーなマークダウンが得られますし、スタック全体がビルド済みイメージで動きました。
簡単なローカルスクリプトが欲しい場合（これは検証基盤の中でもっとも重いセットアップです）、自分で運用せずにクラウド級のアンチブロックが必要な場合（セルフホスト版にFire-engineはありません）、あるいはAGPLのネットワーク利用条項が商用の計画と衝突する場合は、別の選択肢を検討してください。「URLからマークダウンか構造化データが欲しい、運用は不要」というケースなら、Thunderbitの/distillや/extractのようなホスティング済みAPIが、コンテナなしで同じ領域をカバーします。
私の暫定的な見解：強力な中核、重い運用上のコミットメント、そして商用利用を組み立てる前に片付けるべきライセンス。パイプライン全体を自分で持ちたいチームには確固たる居場所があります。そしてそれ以外のすべての人には、要求が多いツールです。/v1/crawlを動かし、LLMキーで/extractを動かし、colima以外のデーモンでソースビルドを検証したら、また見直します。これらが、このレビューと最終判断のあいだに残っている未解決の問いです。
ThunderbitでWebデータ抽出を試す Get Started Free
よくある質問
セルフホスト版Firecrawlはクラウド版と同じですか？
いいえ。セルフホスト版は中核のスクレイピング→マークダウンのエンジンと、同梱のplaywright-serviceによるJavaScriptレンダリングを提供しますが、クラウド製品固有のアンチブロック層であるFire-engineは含みません。/extractエンドポイントやjson出力といったAI機能も、自前のLLMキー（OpenAIまたはOllama）が必要です。このレビューではセルフホストのスタックだけをテストしました。クラウドAPIは範囲外です。
セルフホスト版Firecrawlには実際に何個のコンテナが必要ですか？ 6個です。api、playwright-service、redis、rabbitmq、nuq-postgres、foundationdb。これは単一バイナリではなく、完全なサービススタックです。だからこそ、この検証基盤のどのツールよりも重いセットアップでした。スクリプトだけでなく、メッセージブローカー、キャッシュ、データベースのインフラ運用オーバーヘッドも見込んでおく必要があります。
Firecrawlはセルフホスト版でもJavaScriptの多いページを処理できますか？ はい、私のテストでは可能でした。同梱のplaywright-serviceが、抽出の前に実際のブラウザエンジンでページをレンダリングします。quotes.toscrape.com/js/でこれを検証しました。JavaScriptが実行されたあとにしか存在しないコンテンツであるアインシュタインの引用が、返ってきたマークダウンに現れました。このレンダリング機能こそが、6つのコンテナのうち1つがヘッドレスブラウザである理由です。
AGPL-3.0ライセンスは商用利用に影響しますか？ 影響しうるので、最優先事項として扱うべきです。AGPL-3.0はネットワーク利用条項を含む強いコピーレフトであり、ネットワーク越しにユーザーへソフトウェアの機能を提供することが、ソース公開義務を伴う利用とみなされうます。バイナリを配布しない場合でも同じです。セルフホストのインスタンスで商用製品を作る計画があるなら、始める前に社内のライセンス担当と相談してください。このレビューはライセンスを指摘するものであって、法的助言ではありません。
FirecrawlとThunderbitの開発者向けツールの違いは何ですか？
Firecrawlのセルフホスト版は、自分で運用するサービスです。6つのコンテナを自分で動かし、AGPL-3.0の条件が適用され、組み込みのアンチブロック層はありません。Thunderbitの開発者スタック（Open API、MCPサーバー、CLI）は、呼び出すだけのホスティング済みエンジンです。マークダウンにはPOST /distill、JSON Schemaによる構造化データにはPOST /extractを使い、JSレンダリングとアンチボット対応はサーバー側で実行され、自分のコードにコピーレフト義務はありません。Firecrawlは完全なインフラ制御を求めるチームに向き、Thunderbitは運用負担なしで出力が欲しいチームに向いています。
