中級 11 分Stack

Firecrawl：ローカルRAGにページを取り込む web

端的な回答

Firecrawlは、ページやサイト全体をモデル向けに整えたMarkdownまたはJSONに変換するオープンソースのクローラーです（コアはAGPL-3.0ライセンス、2026年9月末時点でGitHubのスター数は186,000超）。Docker Composeでセルフホストできますが、デフォルトの構成には、スクリーンショット、ページ操作、マネージドサービスの高度なボット対策回避機能は含まれていません。これらの機能はFirecrawl Cloudでのみ利用できます。

Firecrawlは、ウェブアドレスから、モデルがそのまま読めるように整理されたテキストを生成します。メニュー、Cookieバナー、スクリプト、フッターは取り除かれ、記事が残ります。これはRAGパイプラインの最初の工程であり、その後のすべての品質を左右します。このプロジェクトはオープンソースで、自分の環境でホストできるため、完全にローカルな構成でも利用できます。ただし、同名のオンラインサービスと比べて、セルフホスト版では何ができないのかを正確に理解しておく必要があります。

著者 Mohamed Meguedmi·更新 2026-09-28·Windows・macOS・Linuxでテスト済み

#解決する問題

WebページのHTMLコードをそのまま貼り付けてローカルモデルに渡すと、コンテキストウィンドウの大部分がタグ、メニュー、スクリプトに浪費されます。さらに悪いことに、モデルはナビゲーション項目を本文として扱い、的外れな回答を返します。そのため、本格的な文書検索パイプラインはすべて、「このページのどの部分が記事なのか」という1つの問いに答える抽出工程から始まります。

Firecrawlはこの作業に加え、それに伴う巡回処理も行います。内部リンクをたどり、指定した上限で停止し、JavaScriptなしでは何も表示されないサイトのJavaScriptを実行して、ページごとに構造化された結果を返します。出力はMarkdownまたはJSONで、どちらもインデックス作成用のチャンクに分割しやすい形式です。このプロジェクトはGitHubでfirecrawl/firecrawlという名前で公開されており、作者は「the web data API to search, scrape, and interact at scale」と説明しています。2026年9月末時点のスター数は186,000を超えていました。これは、長期にわたって保守していく依存ソフトウェアを選ぶ際に重要な、普及の勢いを示す指標です。

#Scrape、crawl、map、extract：4つの異なる役割

ローカルRAGキット

あなたのドキュメント、あなたのAI：あなたのPDF、メモ、メールを扱う信頼性の高いローカルRAG。何もクラウドに送信しません。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 生涯アップデート
ローカルRAGキット →または すべてのキットを無期限で利用 — 49 € →
4つの操作と実際の用途
操作実際の機能使用タイミング
Scrape入力はアドレス、出力はクリーンなコンテンツ対象のページがすでに分かっている場合
Crawl開始URLから内部リンクをたどってサイトを巡回しますドキュメント一式を取り込む
Mapサイトのアドレス一覧を返すだけで、コンテンツの取得は行わない時間をかける前に、取り込む対象を決める
Extract指定したスキーマに従って構造化フィールドを抽出します文章ではなく、価格や仕様を表で取得したい場合

2 つの習慣が、ほとんどの予期せぬ問題を避けるのに役立ちます。1 つ目は、クロールを実行する前にマップを実行し、サイト全体の構造を確認することです。2 つ目は、各クロールに対して明示的なページ数制限を設定することです。ページネーションや言語バリエーションのあるドキュメントは、見た目よりも 10 倍も大きくなることがよくあるためです。

#自宅でホスティング

処理の一連の流れを手元のハードウェア上に保つことが目的なら、ここで注目するのはこの方法です。複数のサービスで構成される Docker Compose スタックを使います。構成要素は、API、デフォルトのキューとしての PostgreSQL（必要な用途がある場合には、オプションの FoundationDB エンジンも利用できます）、Redis、RabbitMQ、そして JavaScript の実行後に初めて存在するページを扱うための、画面を持たないブラウザサービスとしての Playwright です。公式ガイドでは、メインブランチではなくリポジトリの特定バージョンを指定しています。2026 年 9 月末時点では v2.11.162 で、別のバージョンでは Compose ファイルが異なる場合があると注意を促しています。スタックを起動する公式コマンドは docker compose up --build -d です。起動後、API はローカルのポート 3002 で応答し、オンライン版と同じリクエスト形式を使います。

#スタックを起動する前に必要な条件

公式ドキュメントによると、必要なものは4つです。リポジトリを取得するためのGit、Docker EngineまたはDocker Desktop、Docker Compose v2（ハイフンなしのdocker composeで呼び出します）、そしてスタック起動後にAPIが応答することを確認するためのcurlです。ポート3002は空いている必要があり、マシンには複数のコンテナを並列にビルドして実行できるだけのリソースが必要です。ただし、このプロジェクトではRAMやCPUの具体的な数値は保証されていません。

  1. 01
    まずプロジェクトのセルフホスティングに関するページを読む
    これが唯一の最新情報源です。また、信頼できるネットワーク内で使うクイックスタートではAPI認証が無効になり、本番環境向けの構成ではないことが明記されています。
  2. 02
    ブラウザーによるレンダリングが必要か判断する
    ブラウザによるレンダリングがなければ、静的HTMLが得られます：ドキュメントには最適ですが、JavaScriptでコンテンツを構築する単一ページアプリでは無意味です。
  3. 03
    ライセンスを自分の利用目的に照らして確認する
    プロジェクトの中核部分は、強いコピーレフトを持つ自由ソフトウェアライセンスであるAGPL-3.0で公開されています。一方、クライアントSDKはMITライセンスで配布されています。変更したコードを再配布する商用製品に使う場合は、ライセンスの内容を推測せず、実際に読んで確認してください。
  4. 04
    運用に必要な規模を見積もる
    このプロジェクトでは、このスタックの動作を保証する最低限のマシン構成は公表されていません。マネージドサービスとは異なり、更新、シークレットの管理、ストレージ、監視、障害復旧は利用者自身が担います。
  5. 05
    本格的に頼る前に永続ストレージを追加する
    クイックスタートでは、永続ボリュームは一切追加されません。ドキュメントによると、「永続ストレージ、TLS、高可用性を備えず、Firecrawl Cloudの全機能が揃っているわけでもない状態で起動する」とされています。PostgreSQL、Redis、RabbitMQ用のボリュームを手動で追加しなければ、コンテナを置き換えた際にデータは失われます。一度だけ取り込んだコーパスを頼りにする前に、この点に対処する必要があります。
!
セルフホスティングでも匿名にはならない
ロボットは、あなたのIPアドレスからページを取得し、識別可能なユーザーエージェントを使用して、対象サイトの利用規約およびrobots.txtファイルの条件に従って動作します。ソフトウェアをホスティングすることは、テキストが処理される場所を変えるだけで、テキストの収集権利には影響しません。
→
「正常」と判定されたサービスでも処理に失敗することがあります
APIの/v0/health/readinessエンドポイントは、サービスの生存確認用であり、エンドツーエンドのテストではありません。公式ドキュメントには、「Redis、PostgreSQL、RabbitMQ、Playwright、ワーカー、外部へのネットワークアクセスはいずれも確認しない」と明記されています。このチェックが正常でも/v2/scrapeの呼び出しに失敗する場合は、ヘルスチェックではなく、apiとplaywright-serviceのコンテナログを確認してください。

#エージェントからFirecrawlを制御する：公式MCPサーバー

MCP対応のエージェント（Claude Code、Cursor、または自作のクライアント）を、HTTPインテグレーションを書かずに、この自己ホストのインスタンスに接続するには、プロジェクトは公式なMCPサーバー「firecrawl-mcp-server」を公開しています。その完全プロファイルにより、デフォルトで最大26のツール（フィードバックを含む）が公開されます。環境変数FIRECRAWL_API_URLは、オンラインサービスではなく、あなたのローカルデプロイメントを指し示し、必要に応じてAPIキーをオプションで指定できます。これにより、エージェントがウェブを検索・探索・抽出できるようになり、データの流れが第三者を介さずに済みます。ただし、エージェント自体があなたのマシンまたは信頼できるネットワーク上で動作している必要があります。

#ローカル構成にないもの

多くの人がソフトウェア構成一式をデプロイする前ではなく、した後に気づく点があります。標準のセルフホスティング構成では、オンラインサービスの全機能を利用できるわけではありません。公式ドキュメントによると、スクリーンショットやページ操作（クリック、スクロール、フォームに入力してから結果を読み取ること）は、標準構成では利用できません。Agent機能とBrowser機能、「interact」オプション、利用状況の報告、一部の特殊な形式（メニュー、音声、動画）も同様で、これらは引き続きFirecrawl Cloud限定です。マネージドサービスの独自エンジンによる高度なボット対策の回避機能も、そのまま含まれているわけではありません。

始める前に知っておきたい注意点がもう一つあります。言語モデルを使った抽出支援、つまりスキーマではなく自然言語の指示で動かす「extract」モードを使うには、OpenAI API互換のプロバイダー、またはOllamaを自分で接続し、この方法を別途テストする必要があります。セルフホスト構成では、自動的に接続されるわけではありません。こうした点があっても、Firecrawlをローカルで使ってRAGにデータを供給することは可能です。それこそが本ガイドの中心的な用途ですが、チームにその機能を提供すると約束する前に、把握しておくとよいでしょう。

#ローカルRAGの中での位置づけ

機能するローカルの処理チェーンは4段階で構成され、Firecrawlが担うのは最初の段階だけです。取り込みではURLをドキュメントに変換し、チャンク分割とエンコーディングではローカルの埋め込みモデルを使ってドキュメントをベクトルに変換します。ベクトルデータベースはこれらのベクトルを保存し、質問に最も近い文章の抜粋を返します。最後に、ローカルモデルがこれらの抜粋に基づいて回答を作成します。

すでにディスク上にあるファイル（PDF、オフィス文書、プレゼンテーション）を扱う場合、必要なのはウェブクローラーではなく、Doclingのような文書変換ツールです。また、事前に取り込んだコーパスを使うのではなく、モデルに回答時点でウェブを参照させたい場合は、SearXNGのようなセルフホスト型のメタ検索エンジンが適しています。更新が必要なインデックスの代わりに、要求に応じて検索結果を返します。

#使用を避けるべき場合

ニーズに応じた最適なツール
あなたのニーズより適した選択肢
ときどきページを変換するスクリプト内で使う、HTML を Markdown に変換する小さなライブラリ
PDFやローカルの文書を取り込むウェブクローラーではなく、Doclingのようなドキュメント変換ツール
会話中にリアルタイムでウェブからの回答を提供モデルに接続したセルフホスト型検索エンジン
スクリーンショットまたは複雑なページ操作デフォルトのスタックには含まれないマネージドサービス Firecrawl Cloud
ドキュメント全体を、定期的かつ自動的に処理したい場合Firecrawlを自動ホスティング — これはまさにそのケースです

#法的注意点

ページの自動収集に伴う責任を負うのは、ツールではなく利用者自身です。対象サイトの利用規約、robots.txtの指示、適用される法律、収集したコンテンツの使い方は、採用する技術よりも重要です。企業内のコーパスでは、これに加えて、収集したページに含まれている可能性のある個人データの処理と、各情報源の出所を処理活動の記録簿に記載する必要性も問題になります。

#FAQ

Firecrawl は自己ホスティングでの利用が無料ですか？+
コアのコードはAGPL-3.0ライセンスで公開されており（クライアントSDKはMITライセンス）、ライセンス料なしでご自身のハードウェア上で実行できます。ただし、運用に時間を費やす必要があります。API、ワーカー、キュー、ヘッドレスブラウザという複数のコンテナからなる構成を、マネージドサービスのサポートなしでご自身で保守することになります。
セルフホスト版では、オンラインサービスのすべての機能を使えますか？+
いいえ。公式ドキュメントには、デフォルトのスタックにない機能が明記されています。スクリーンショット、ページ操作、AgentとBrowserの機能、高度なアンチボット対策の回避、一部の特殊な形式です。中核となる機能、つまりscrape、crawl、map、extractでページを取得して変換する機能は、完全に動作します。
FirecrawlにはGPUが必要ですか？+
いいえ。ウェブを巡回すること、PlaywrightサービスでJavaScriptによるレンダリングを実行すること、HTMLをMarkdownに変換することは、CPU、メモリ、ネットワークを使う処理であり、GPUによる計算ではありません。複数のコンテナを並列で動かすには、むしろCPUとRAMに余裕があることが大切です。GPUが関わるのは処理の後段だけで、埋め込みの生成と、抽出されたテキストを利用するローカルモデルによる回答生成を担います。
JavaScriptを必要とするサイトを読み取れますか？+
はい：デフォルトのスタックには、ブラウザレンダリングに特化したPlaywrightサービスが含まれており、ページのJavaScriptを実行した上で抽出を行います。このサービスがアクティブでない場合、Firecrawlはサーバーから提供される静的HTMLのみを取得し、初期ロード後にクライアント側でコンテンツを構築する単一ページアプリケーションでは失敗します。ページが空の場合、まずplaywright-serviceコンテナのログを確認してください。
crawlとmapの違いは？+
Mapは、サイト内で見つかったURLを、その内容を取得せずに一覧化します。高速で軽量なため、本格的に取りかかる前にサイトの規模を評価するのに最適です。Crawlは、巡回する各ページを実際に取得して変換します。まずサイトをマッピングし、その後、条件で絞り込んだ一部だけを巡回すれば、不要なページを何百件も取り込まずに済みます。
AIによる抽出（extractモード）はローカルで直接動作しますか？+
設定なしでは動作しません。自然言語の指示に基づく抽出を行うには、OpenAI API または Ollama に対応したプロバイダーを自分で接続し、その処理経路を別途テストする必要があります。オンラインサービスとは異なり、セルフホスト構成では、この接続は標準では設定されていません。
このガイドは役に立ちましたか？

ご意見、誤りのご指摘、補足はありますか？ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。