firecrawl-agent

firecrawl-agent skill の概要

firecrawl-agent でできること

firecrawl-agent skill は、通常の単一ページのスクレイプでは足りない場面向けの、自律的な Web データ抽出スキルです。サイト内をたどりながら、どこに必要な情報があるかを判断し、構造化された JSON を返すよう設計されています。特に、料金表、商品カタログ、ディレクトリエントリ、機能一覧のような取得に向いています。

向いているユーザー

この firecrawl-agent skill が最も適しているのは、生の HTML ではなく、そのまま使えるデータが必要な人です。たとえば、データセットを作る運用担当者、競合調査や市場調査を行うアナリスト、後続の自動化処理にデータを渡したい開発者、アドホックなコピペではなくスキーマ付きの複数ページ抽出を求める AI ユーザーに向いています。

firecrawl-agent が本当に解決する仕事

多くの人が求めているのは、抽象的な意味での「Web スクレイピング」ではありません。実際には、次のような具体的な問いに答えたいはずです。

• SaaS サイトから料金プランをすべて抽出したい
• 多数のページにまたがる商品名と価格を集めたい
• ディレクトリを JSON レコードに変換したい
• URL を1件ずつ手で対応付けずに、構造化された事実を集めたい

こうした用途でこそ、firecrawl-agent for Web Scraping は汎用的なプロンプトと明確に差が出ます。

通常のプロンプトではなく firecrawl-agent を選ぶ理由

一般的なモデルへのプロンプトでも、セレクタ候補を提案したり、見えている内容を要約したりはできます。ただし、複数ページをまたいで安定的に自律抽出するワークフローまでは、通常あまり提供できません。firecrawl-agent はまさにその用途のために作られており、抽出ゴールを渡し、必要ならスキーマも指定し、あとは巡回して機械利用しやすい出力を返させるのが基本です。

インストール前に知っておきたい主なトレードオフ

メリットは、ページごとに手で追いかける作業を大きく減らせることです。一方で、トレードオフとして実行時間は長めです。エージェントの処理には数分かかることがあり、出力品質も、対象フィールドと抽出範囲をどれだけ明確に定義できているかに大きく左右されます。必要なのが「1ページだけを素早く取りたい」というケースなら、これはオーバースペックかもしれません。

firecrawl-agent skill の使い方

firecrawl-agent のインストール前提

上流の skill は Bash 経由で firecrawl を利用でき、firecrawl agent や npx firecrawl を含みます。skills ベースの環境にインストールする場合は、次を使います。

npx skills add https://github.com/firecrawl/cli --skill firecrawl-agent

実運用では、環境内で Firecrawl CLI が使えることに加え、その CLI が必要とする認証やセットアップも済んでいる必要があります。

まず読むべきファイル

最初に確認したいのは skills/firecrawl-agent/SKILL.md です。このリポジトリでは、実用上のガイダンスのほぼすべてがそのファイルに入っています。この skill については、目立った rules/、resources/、補助スクリプトも見当たらないため、インストール判断の軸は主に、掲載されている例や CLI オプションが自分のワークフローに合うかどうかになります。

firecrawl-agent の基本的な実行パターンを理解する

中核となる firecrawl-agent usage パターンはシンプルです。

1. 抽出したいゴールを記述する
2. 必要ならスキーマを渡す
3. 必要なら開始 URL を絞る
4. ジョブ完了まで待つ
5. JSON 出力をファイルに保存する

skill にある代表的な例は次のとおりです。

firecrawl agent "extract all pricing tiers" --wait -o .firecrawl/pricing.json

firecrawl agent "extract products" --schema '{"type":"object","properties":{"name":{"type":"string"},"price":{"type":"number"}}}' --wait -o .firecrawl/products.json

firecrawl agent "get feature list" --urls "<url>" --wait -o .firecrawl/features.json

firecrawl-agent skill に必要な入力

firecrawl-agent skill は、次の3点を明確に渡したときに最も力を発揮します。

• 抽出の目的
• 対象サイトまたは開始 URL
• 欲しい出力の形

弱い入力例:

• “scrape this site”

より良い入力例:

• “Extract all pricing tiers from https://example.com/pricing and related plan pages. Return plan name, monthly price, annual price, included seats, and top features as JSON.”

最も良い入力例:

• “Starting from https://example.com/pricing, extract every current pricing tier visible on the site. Return JSON with plans[] containing name, billing_period, price, currency, seat_limit, features[], and source_url. Ignore blog pages, docs, and historical changelog content.”

スキーマを使うべき場面

出力をコード、スプレッドシート、バリデーション、再現性のあるワークフローに流し込みたいなら、--schema を使うべきです。スキーマが特に重要になるのは、次のようなケースです。

• フィールド名を安定させたい
• 数値や配列のように型付きの値が必要
• 曖昧な要約を減らしたい
• 実行ごと・サイトごとの結果を比較したい

スキーマなしでもうまく抽出できることはありますが、後続の自動化で使うには結果の予測可能性が下がりやすくなります。

あいまいな要件を良いプロンプトに変える方法

強い firecrawl-agent guide 用プロンプトには、通常次の要素が入っています。

• 対象エンティティの種類: plans, products, listings, locations
• 網羅条件: 例ではなく、現在公開されている全件
• 除外条件: docs, blog, careers, changelog は無視
• 正規化: 価格は数値で返す、1アイテム1レコードにする
• 出典情報: source_url を含める
• 例外時の方針: フィールドがなければ null を返す

例:

firecrawl agent "Extract all products from the site. Return JSON with products[] containing name, price, currency, short_description, category, availability, and source_url. Only include live product pages. Ignore blog, support, and policy pages. If price is missing, use null." --urls "https://example.com" --wait -o .firecrawl/products.json

開始 URL を与えて探索のブレを減らす

URL を指定しない場合、エージェントはどこを探索するかをより広く自分で判断できます。これは有効に働くこともありますが、無駄なナビゲーションが増える原因にもなります。精度を上げたいなら、次のような有力な入口ページを最初に与えるのが有効です。

• 料金ページ
• 商品カテゴリページ
• 企業ディレクトリ
• マーケットプレイスの一覧ページ

これは、実務で firecrawl-agent install の成功率を上げるうえで、特に効果の大きい改善ポイントのひとつです。

firecrawl-agent で安定抽出するための推奨ワークフロー

実践的な進め方は次のとおりです。

1. 有力な1ページを対象に、狭い範囲でテストする
2. JSON を見て、欠落フィールドや結合されてしまったフィールドを確認する
3. スキーマと除外条件を追加する
4. 開始 URL を広げて対象範囲を拡張する
5. .firecrawl/ のような専用フォルダに出力を保存する
6. 件数を検証し、元ページをいくつか目視確認する

最初から広く回してノイズの多い結果をデバッグするより、この流れのほうが速くて堅実です。

出力の扱い方とファイル戦略

-o を使って、結果を予測しやすいパスに書き出しましょう。自律抽出ジョブは、出力をバージョン管理したり、時系列で比較したりできる状態にしておくと評価しやすくなります。良い例:

• .firecrawl/pricing.json
• .firecrawl/products.json
• .firecrawl/directory.json

試行錯誤の最中は、毎回汎用的な output.json を上書きするのではなく、その実行の目的がファイル名でわかるようにしておくのがおすすめです。

実務でハマる用途: firecrawl-agent for Web Scraping が得意なケース

firecrawl-agent for Web Scraping が特に強いのは、次のようなケースです。

• 対象データが複数ページにまたがっている
• サイト構造を事前に完全には把握していない
• 欲しいのが文章ではなく構造化 JSON
• 手書きのスクレイピングルールを作る手間が、抽出タスクの価値に見合わない

実務で合わない用途: 使わないほうがよい場面

次のような場合は firecrawl-agent を見送るほうがよいでしょう。

• 1ページの要約だけで足りる
• コンプライアンス重視で、厳密に決定的なセレクタが必要
• 既に安定したスクレイパーがあり、対象ページ構造もよく分かっている
• 対象サイトが非常にインタラクティブ、認証付き、または環境で未対応のセッション依存フローに強く依存している

firecrawl-agent skill の FAQ

firecrawl-agent は初心者にも向いていますか？

はい。CLI の基本操作ができて、出力フィールドという発想で考えられるなら、初心者でも十分使えます。基本例も入りやすい内容です。初心者にとっての本当のハードルはインストール構文ではなく、あいまいな依頼ではなく、完全な抽出対象をどう指定するかにあります。

firecrawl-agent は普通の AI プロンプトと何が違いますか？

通常のプロンプトは、分析やその場限りのページ内容取得で終わりがちです。一方 firecrawl-agent usage は、自律的なサイト巡回と構造化抽出を前提に作られています。この組み合わせこそが、単なる「この Web サイトを要約して」ではなく、この skill を使う理由です。

JSON スキーマは毎回必要ですか？

いいえ。探索的な作業なら、プレーンな抽出依頼だけで十分なこともあります。ただし、実行ごとの一貫性、自動化、型の整ったきれいなフィールドが必要なら、たいていはスキーマを足す数分の手間に見合います。

firecrawl-agent の処理時間はどのくらいですか？

skill の説明では、自律抽出にはおおむね 2〜5 分ほどかかる可能性があります。単純な1ページスクレイプより長くなる前提で考えておくべきです。特に、関連ページ数が多いサイトではさらに長くなることがあります。

firecrawl-agent で料金、商品、ディレクトリを抽出できますか？

はい。まさにその用途が想定されています。料金プラン、商品一覧、ディレクトリ形式のエントリ、そのほかサイト全体に散らばった構造化レコードの抽出が代表例です。

firecrawl-agent はあらゆるスクレイピング作業に最適ですか？

いいえ。タスクが単純、決定的、あるいは既存の一般的なスクレイパーで十分まかなえるなら、この skill は不要な場合があります。本領を発揮するのは、「どこに情報があるか見つけること」と「そこを巡回すること」自体が課題に含まれているケースです。

firecrawl-agent skill を改善する方法

firecrawl-agent により明確な抽出契約を与える

品質を最も大きく押し上げるのは、多くの場合、プロンプトを「データを抽出して」から、次を明示した契約に変えることです。

• 正確なフィールド
• 含める条件
• 除外する条件
• null の扱い
• source URL の取得

これにより、根拠の薄い構造の作り込みを減らせて、結果の信頼性も上がります。

最初に範囲を絞り、あとから広げる

質の低い実行結果は、ドメイン直下から、ゆるい目標のまま始めてしまうことが原因になりがちです。まずはシグナルの強い URL を1〜2本に絞って始め、フィールド品質を確認し、スキーマとプロンプトが機能してから対象範囲を広げると、出力は大きく改善します。

すべてのレコードに出典情報を持たせる

結果をレビューしたりデバッグしたりしたいなら、各アイテムに source_url を含めるよう依頼してください。この1フィールドがあるだけで、firecrawl-agent guide のワークフローはかなり楽になります。どのレコードが本当に正しいページから来たのかを、すぐ検証できるからです。

ぶれやすいフィールドは最初から正規化を指示する

現実のサイトでは、次のような揺れが起きがちです。あらかじめ処理方針を明示しましょう。

• 価格が numbers か strings か
• 月額課金か年額課金か
• 機能一覧は配列で返すか
• 欠損値は null にするか
• 商品やプランは1件につき1レコードにするか

こうした指示は、機械処理しやすさを実質的に高めます。

よくある失敗パターンを把握する

典型的な問題は次のとおりです。

• 異なる種類のページが1つのデータセットに混ざる
• バリエーション違いのページから重複レコードが出る
• 機能要約が1つの塊に結合される
• 価格が数値ではなくテキスト断片として取られる
• 開始地点が広すぎる、または弱すぎて、サイトのカバー率が不完全になる

こうした問題の大半は、同じあいまいなコマンドを再実行するより、対象範囲とスキーマ設計を強めることで解決します。

件数不足だけでなく、出力の欠陥をもとに改善する

最初の実行結果がよくないとき、「もっと多くのページを見て」と言うだけでは不十分です。まず、どこが悪いのかを切り分けてください。

• フィールドが違う
• 対象ページの種類が違う
• 重複がある
• 正規化が足りない
• 網羅性が不足している

そのうえで、その欠陥に対して直接プロンプトを修正します。これが firecrawl-agent の結果を最短で改善する方法です。

firecrawl-agent 改善に効く、強い再設計パターン

2回目以降のプロンプトでは、次のパターンが有効です。

• ゴールは同じままにする
• 除外条件を追加する
• フィールド定義を厳密にする
• 出典情報を要求する
• 欠損値の扱いを定義する

修正版の例:

• first run: “extract all pricing tiers”
• second run: “Extract all current pricing tiers from pricing and plan pages only. Ignore docs, blog, changelog, and legacy pages. Return plans[] with name, price, currency, billing_period, features[], and source_url. Use null when a field is not present.”

まず1点だけ確認すると、インストール判断の精度が上がる

firecrawl-agent skill を採用する前に、自分の本当のボトルネックが「どこを辿るべきかの発見」なのか、それとも「抽出結果の整形」なのかを見極めてください。複数ページのサイトをまたいで、探索すべき場所を見つけることが課題なら、この skill は非常に相性がよいです。逆にそうでないなら、もっと単純なスクレイプや1ページ抽出ツールのほうが速く、保守もしやすい場合があります。