Firecrawlとは？料金・無料枠・使い方を実例で解説

公開: 2026年4月9日更新: 2026年10月26日約15分で読めます

Firecrawl（ファイアクロール）は、WebサイトのURLを渡すと、ページの本文をAIが扱いやすいMarkdownやJSONに変換して取ってくるツールだ。JavaScriptで描画されるページにも対応し、サイト全体をまとめて取得することもできる。料金はクレジット制で、2026年10月時点の公式料金ページでは、無料プランで月1,000クレジット（通常のスクレイプは1ページ1クレジット。機能によって追加で消費する）まで使え、有料はHobbyが年払いで月16ドルから。OSS版を自分のサーバーで動かす方法もある。

競合30社のサービスページを全部集めてくれ、と頼まれたことがある。手作業なら、1社ずつ開いてコピーして、表に貼って、を数日かけて繰り返す仕事だ。Firecrawlを使ったら、その日の午後には終わっていた。

Webサイトのデータをまとめて欲しくなる場面は、経営の現場に意外と多い。競合の価格やサービス内容の一覧化。旧サイトから新サイトへの記事移行。自社の問い合わせ対応をAIに任せるための、社内マニュアルのデータ化。どれも「人間が1ページずつ開いてコピーする」とキリがない。Firecrawlは、この「1ページずつ」を丸ごと肩代わりするツールだ。

私はAIエージェント組織を自分の業務で毎日動かしている。その中でWebからデータを集める作業は日常的に発生する。この記事は、実際にFirecrawlを触った記録をもとに、何ができて、いくらかかって、自社に入れる価値があるかを判断できるところまで書く。コードも載せるので、手を動かす人はそのまま試せる。

Firecrawlとは。Webサイトを丸ごとデータ化するツール

一言でいうと、任意のWebサイトを開いて、中身をAIが読みやすい形（Markdown）に整えて返してくれるツールだ。OSSとして公開されていて、自前サーバーで無料運用もできるし、登録するだけで使えるSaaS版もある（Firecrawl公式）。

技術的なポイントは、JavaScriptで描画される最近のサイトにも対応していること。昔ながらのデータ収集ツールは、ブラウザで見たときの画面と、プログラムが取得する中身が食い違うサイトでよく壊れた。Firecrawlはブラウザで実際に描画した後の状態を取りに行くので、人間が見ている画面とほぼ同じ情報が取れる。

できることを整理すると、こうなる。

URLのリストや sitemap.xml から、サイトの全ページを一括取得
ページの中の必要な部分だけを抜き出す
ログインや動的な読み込みが必要なページも、描画後の中身を取得
取得結果を、そのままAI（LLM）に渡せる形で出力

最後の「そのままAIに渡せる形」が、他のツールとの一番の違いになる。従来はデータを取った後に、AIが読める形へ整える前処理がひと仕事だった。そこがほぼ要らなくなる。

Firecrawlの料金。無料枠は月1,000クレジットから

先に料金の全体像を出す。以下は2026年10月26日に公式料金ページで確認したプランだ（米ドル表示。公式ページの記載では2026年9月4日から適用）。

プラン	年払い（月あたり）	月払い	クレジット/月	同時リクエスト数
Free	$0	$0	1,000	2
Hobby	$16	$19	5,000	5
Standard	$83	$99	100,000	25
Growth	$333	$399	500,000	50
Scale	$599	$749	1,000,000	100
Enterprise	要問合せ	要問合せ	カスタム	カスタム

課金の単位は「クレジット」で、1ページ取得するごとに1クレジット消費する。無料プランの1,000クレジットは、通常の取得なら1,000ページ分だ。機能によっては1ページで複数クレジットを使う。

まず試すだけなら無料枠で十分足りる。1ページの取得結果を見れば、自社の用途に合うかどうかはすぐ判断がつく。個人プロジェクトや小規模な業務ならHobby（$16）で足りることが多い。月5,000ページあれば、中規模のサイトを数回まるごとクロールできる。継続的に大量のページを集める運用に育ったら、Standard以上を検討する流れになる。

料金を気にせず、データを外に出したくない事情がある場合は、OSS版を自前サーバーで動かす選択肢もある。この場合クラウド版のクレジット課金はかからない。ただし、bot対策（Fire-engine）やスクリーンショット・ページ操作は標準構成に含まれず、AIでの抽出を使うにはOpenAI互換のAPIかOllamaを自分でつなぐ必要がある。必要なマシンの大きさは公式も示していないので、Dockerで複数のサービスが動く余裕を見て、実際に動かして確かめる。運用の手間とサーバー代を、SaaSの月額と天秤にかける判断になる。

実際に使ってみる。5分で動く

ここからは手を動かす人向け。経営判断だけ知りたい方は「自社でやるか、外部に頼むか」まで飛ばして構わない。

Python SDKを入れて、APIキーを渡すだけで始まる。以下のコードは、2026年10月時点の最新版（firecrawl-py 4.54.0）の書き方に合わせている。古い記事でよく見る FirecrawlApp や scrape_url は旧版の書き方だ。

pip install firecrawl-py

APIキーはFirecrawlのダッシュボードで取得する。

from firecrawl import Firecrawl

fc = Firecrawl(api_key='fc-xxxxxxxxxxxxxxxx')

環境変数 FIRECRAWL_API_KEY を設定しておけば、引数なしで初期化できる。

export FIRECRAWL_API_KEY=fc-xxxxxxxxxxxxxxxx

# 環境変数から自動で読み込む
fc = Firecrawl()

単一ページの取得（scrape）

まず1ページだけ。scrape にURLを渡すだけでいい。

doc = fc.scrape(
    'https://example.com/pricing',
    formats=['markdown', 'html'],
)

print(doc.markdown[:500])

返り値は、取得形式ごとの中身とページ情報を持つオブジェクトになる（Python SDKでは項目名が source_url のようなスネークケースになる）。

doc.markdown        # '# Pricing\n\nOur plans start at...'
doc.html            # '<h1>Pricing</h1><p>Our plans start at...</p>'
doc.metadata.title  # 'Pricing - Example'
doc.metadata.source_url  # 'https://example.com/pricing'
doc.metadata.status_code # 200

formats で取得形式を指定する。Markdownだけで足りるケースがほとんどだ。DOM構造まで必要ならhtmlも併せて取る。

JavaScriptで描画されるページも、デフォルトでブラウザ描画されるので特別な設定は要らない。ログインが必要なページは、headers でCookieを渡す。

doc = fc.scrape(
    'https://app.example.com/dashboard',
    formats=['markdown'],
    headers={'Cookie': 'session_id=abc123def456'},
)

サイト全体のクロール（crawl）

本題はここ。サイトを丸ごと取る。crawl を使う。終わるまで待って結果をまとめて返してくれる。

job = fc.crawl(
    'https://docs.example.com',
    limit=100,
    scrape_options={'formats': ['markdown']},
    poll_interval=5,
)

print(f"取得ページ数: {len(job.data)}")
for page in job.data[:3]:
    print(f"  - {page.metadata.source_url}")

出力例。

取得ページ数: 87
  - https://docs.example.com/
  - https://docs.example.com/getting-started
  - https://docs.example.com/api-reference

クロールの範囲は細かく制御できる。

job = fc.crawl(
    'https://example.com',
    limit=200,
    max_discovery_depth=3,
    include_paths=['/blog/*', '/docs/*'],
    exclude_paths=['/admin/*', '/tag/*'],
    crawl_entire_domain=False,
    scrape_options={
        'formats': ['markdown'],
        'only_main_content': True,
    },
)

only_main_content（APIでは onlyMainContent）は地味だが効く。これを入れないと、全ページにヘッダーやフッター、サイドバーが重複して混ざる。AIに渡すデータが無駄にふくらむ原因になるので、最初から入れておくのがいい。

100ページを超えるサイトでは、完了まで待ち続けるとタイムアウトの危険がある。start_crawl でジョブだけ始めて、get_crawl_status で進み具合を見るほうが安全だ。

import time

started = fc.start_crawl('https://large-site.example.com', limit=500)
print(f"ジョブID: {started.id}")

while True:
    status = fc.get_crawl_status(started.id)
    print(f"進捗: {status.completed}/{status.total}")
    if status.status == 'completed':
        break
    if status.status in ('failed', 'cancelled'):
        raise RuntimeError(f"クロールが終了しました: {status.status}")
    time.sleep(10)

pages = status.data
print(f"取得完了: {len(pages)}ページ")

AIで構造化データを抜き出す（JSON抽出）

取得形式に json を指定すると、ページから必要な項目だけを構造化して取り出せる。取りたい形をスキーマで定義して渡す。この抽出は、通常の1クレジットに加えて1ページあたり4クレジットかかる。無料枠の1,000クレジットなら約200ページ分だ。

from pydantic import BaseModel
from typing import List, Optional

class Product(BaseModel):
    name: str
    price: Optional[str]
    description: str
    features: List[str]

doc = fc.scrape(
    'https://example.com/product/widget-pro',
    formats=[{'type': 'json', 'schema': Product.model_json_schema()}],
)

product = doc.json
print(f"商品名: {product['name']}")
print(f"価格: {product['price']}")
print(f"特徴: {', '.join(product['features'])}")

出力例。

商品名: Widget Pro
価格: $49/month
特徴: リアルタイム同期, APIアクセス, カスタムダッシュボード

スキーマを渡さず、プロンプトで指示することもできる。

doc = fc.scrape(
    'https://example.com/about',
    formats=[{'type': 'json', 'prompt': '会社の設立年、従業員数、所在地を抽出してください'}],
)

競合30社の会社概要から、設立年と従業員数と所在地だけを一覧化する。そういう仕事が、これで一気に片づく。

自社でやるか、外部に頼むか

ここが経営判断の分かれ目になる。Firecrawlは登録すれば触れるが、「触れる」と「業務として回る」の間には距離がある。判断軸を3つに絞る。

社内にPythonを書ける人がいて、しかもその人の時間が空いているか。ここが一番大きい。上のコードを見て「これなら書ける」と思う人が社内にいるなら、無料枠で試して、そのまま内製に進むのが一番安い。逆に、コードを書ける人が本業で手一杯なら、片手間の内製は途中で止まる。止まった自動化は誰も直さないまま放置される。

一度きりか、繰り返すか。競合を一回だけ調べたいなら、内製でも外注でも大差ない。むしろ外注のほうが早い。毎週・毎月データを取り続けて、AIに食わせて、業務に組み込む。そこまで育てるなら、誰かが継続的に面倒を見る前提の設計が要る。この設計を最初に間違えると、後で作り直しになる。

取るデータに個人情報や機微な情報が混ざるか。顧客データや社内の非公開情報を扱うなら、データをどこに置くか、誰がアクセスできるかの設計が先に必要になる。ここは「動けばいい」で進めると事故る領域だ。SaaS版に外部送信していいのか、OSS版を自社内で閉じて動かすべきか、の判断が絡む。

ざっくり言うと、社内に手の空いたエンジニアがいる一度きりの調査なら内製。継続運用や、機微なデータや、業務への組み込みが絡むなら、設計だけでも外部の目を入れたほうが結局は安い。

導入の費用と期間の目安

金額と期間の感覚を持っておくと、社内で話が進めやすい。

ツール自体の費用は、上の料金表のとおり。試すだけなら無料、小規模運用でHobbyの$16、本格運用でStandardの$83が目安になる。ここは大きな金額ではない。効いてくるのは、動かす人の時間のほうだ。

期間の目安は用途で変わる。1ページ試して手応えを確かめるだけなら、その日のうち。競合サイトを丸ごと取ってデータにするような一回きりの調査なら、数時間から1日。毎週データを取り続けて業務に組み込む仕組みまで作るなら、設計とテストを含めて数日から数週間を見ておく。

注意したいのは、一番時間を食うのが「Firecrawlを動かす部分」ではないことだ。取ったデータをどう使うか、どこに貯めるか、誰がメンテナンスするか。この周辺設計のほうが手間になる。ツールが安く動くからといって、プロジェクト全体が安く済むわけではない。この見誤りが、次の失敗パターンにつながる。

よくある失敗パターン

私が実際にぶつかった、あるいは踏みかけたものを挙げる。

無料枠を初日で使い切る。limit を設定せずにクロールを走らせると、リンクをたどれるだけたどってしまう。テスト段階で無料枠のクレジットが一瞬で溶ける。最初は limit: 10 で動作確認して、様子を見ながら増やすのが無難だ。

取れると思ったページが取れない。Firecrawlはデフォルトで robots.txt に従う。相手サイトが robots.txt でブロックしているパスは取得できない。自社サイトのデータ移行で使うなら、一時的に自社の robots.txt を調整する必要が出ることもある。

レート制限で詰まる。無料プランでは、scrapeが1分あたり10リクエスト、crawlのジョブ開始が1分あたり2回、同時に動かせるブラウザが2つまでだ。大量のページを取るときは、scrape をループで回すより、crawl で一括取得したほうがいい。クロール機能は内部でレート制限をうまく管理してくれる。

法的な確認を飛ばす。ここが一番痛い失敗になりうる。robots.txt を無視する設定にしたり、商用サイトを利用規約を確認せずにスクレイピングしたりすると、法的リスクを負う。競合分析でよそのサイトを取る前に、そのサイトの利用規約を必ず確認する。この確認を「たぶん大丈夫」で飛ばさない。

作ったが誰も使わない。技術的に動くものを作っても、業務のどこで誰がその出力を使うかが決まっていないと、そのまま放置される。ツールを動かす前に、取ったデータを何の判断に使うのかを先に決めておく。

Scrapy・Playwrightとの使い分け

Firecrawlが常に最適というわけではない。用途で使い分ける。

要件	向いているツール
細かいパーサーのカスタマイズが必要	Scrapy
ブラウザ操作（ログイン、クリック等）が必要	Playwright
サイト全体をMarkdownで一括取得したい	Firecrawl
AIに渡す構造化データが欲しい	Firecrawl（Extract）
無料で大量ページを取得したい	Scrapy（自己管理）

Firecrawlの強みは「とにかく早く、きれいなデータが欲しい」場面にある。パーサーを書かなくていいぶん、試作や検証のスピードが上がる。本番のデータパイプラインに組み込むなら、コストとレート制限を見て判断する。

これを自社に入れるとどうなるか

冒頭の話に戻る。競合30社のサービスページを集める仕事が、数日から数時間になった。この「時間の縮み方」が、Firecrawlが自社にもたらす一番わかりやすい変化だ。

具体的には、こういう場面で効く。

競合の価格やサービス内容を定期的に一覧化して、自社の立ち位置を把握する
旧サイトから新サイトへ、数百ページの記事をまとめて移す
社内マニュアルや過去資料をデータ化して、問い合わせ対応AIの土台にする

どれも「人手でやると数日、放置すると誰もやらない」タイプの仕事だ。そこを仕組みで片づけると、担当者はもっと判断が要る仕事に時間を回せる。

ただし、ここまで読んでわかるとおり、ツールが動くことと業務が回ることは別だ。何のデータを、どう使い、誰が維持するのか。この設計を外すと、せっかく作った仕組みが止まる。

自社のどの業務にこれが効きそうか、内製と外注どちらで進めるのが現実的か。そのあたりを一度整理したいなら、まず無料の現在地診断（6問・約1分）をどうぞ（f2t.jp/diagnosis）。売り込みではなく、「そもそも自動化すべき業務か」の当たりを付けるところから。今のやり方のまま人手で続けるほうが安い、という結論になることもある。

この記事を書いた人

Tomo（F2T）

AIエージェント組織を自分の業務で毎日動かしている実装者。このブログの記事は、すべてその実作業の記録から生まれています。