firecrawl-search
作成者 firecrawlfirecrawl-search は、ソースの発見や構造化検索を行い、必要に応じて Firecrawl CLI でページ全文を JSON として取得できる、Web調査向けのスキルです。
このスキルの評価は 78/100 で、ディレクトリ掲載候補として十分に堅実です。エージェントにとって発動トリガーが明確で、CLI の具体例もあり、Web調査において汎用プロンプトより実運用上の利点が伝わります。Firecrawl ベースの検索に加えて必要に応じた全文抽出を求めるユーザーには導入判断しやすい一方、運用面の細かな前提は一部読み取る必要があります。
- 発動しやすさが高く、説明文の中で "search for," "find me," "look up," といった典型的な依頼や、調査・ニュース収集の意図に明確に対応づけられています。
- 運用面での実用性が高く、基本検索、検索+スクレイピング、最新ニュース取得それぞれの具体的なコマンド例に加え、JSON の出力先や主要フラグも示されています。
- ワークフローへの組み込み方に説得力があり、search → scrape → map → crawl → interact という拡張パターンの中での位置づけが説明されているため、エージェントが最初の一手として選びやすくなっています.
- パッケージングや補助ファイルが少ないため、導入時の分かりやすさには限界があります。SKILL.md にインストールコマンドがなく、補助スクリプト、参照情報、メタデータも付属していません。
- オプションに関する案内は一部ありますが、制約条件や使い分けの判断基準は薄めで、境界的なケースやパラメータ選択ではエージェント側である程度の手探りが必要です.
firecrawl-search スキルの概要
firecrawl-search でできること
firecrawl-search は、まずページを見つけ、そのまま同じ手順の中で必要に応じてページ本文まで取得できる Web リサーチ向けスキルです。検索スニペットだけでは足りない場面、たとえば情報源の発見、記事の収集、最新ニュースの確認、後続の要約や比較のための根拠集めに向いています。
firecrawl-search スキルを導入すべき人
firecrawl-search が最も合うのは、AI を使った Web リサーチをしたいものの、まだ対象 URL が決まっていない人です。作業の出発点が「X について情報源を探す」「最近の報道を調べる」「世の中でどう語られているかを見る」であれば、このスキルは汎用的なプロンプトより直接的です。理由は、そうした依頼を、再現しやすい CLI ワークフローと構造化 JSON 出力に落とし込めるからです。
firecrawl-search が実際に担う仕事
firecrawl-search を導入する人の多くが求めているのは、次の 3 点です。
- 関連ページを素早く見つける
- 必要ならスニペットではなくページ全文の markdown を取得する
- きれいな結果をエージェントに渡し、要約・絞り込み・追加スクレイピングにつなげる
そのため firecrawl-search for Web Research は、より大きな search → scrape → map → crawl ワークフローの最初の一歩として特に有効です。
通常のプロンプトではなく firecrawl-search が選ばれる理由
firecrawl-search の大きな違いは、実際の検索結果を機械処理しやすい JSON で返し、さらに --scrape でページ本文の抽出まで追加できる点です。モデルに「web を検索して」と頼むだけの場合と比べて、次の利点があります。
- クエリを明示的に制御できる
- web や news といったソース種別を指定できる
- 件数制限をかけられる
- 後続処理でパースしやすい
- 検索と分析の境界が明確になる
インストール前に見るべきポイント
このスキル自体のリポジトリ構成は軽量ですが、重要なのはドキュメント量ではなく、自分の作業にこのワークフローが合っているかです。検索による発見と、必要に応じた本文取得が必要なら firecrawl-search skill は有力です。一方で、これ単体をフル機能のサイトクローラ、ブラウザ自動化ツール、最終回答エンジンとして扱うべきではありません。
向いているケース・向いていないケース
firecrawl-search を使うべきなのは、次のような場面です。
- テーマに関する情報源が必要だが、URL はまだ分からない
- 最近のニュースや複数の視点を集めたい
- 検索結果をファイルに保存し、後で処理したい
逆に見送ったほうがよいのは、次のようなケースです。
- すでにスクレイプしたい正確なページが決まっている
- 1 つのサイトを深くたどる必要がある
- フォーム操作や動的な Web アプリとのリッチなやり取りが必要
firecrawl-search スキルの使い方
firecrawl-search の導入前提
リポジトリの抜粋から、このスキルは次の CLI アクセスを前提にしています。
firecrawl *npx firecrawl *
skills 対応環境での実用的な firecrawl-search install 手順は次のとおりです。
npx skills add https://github.com/firecrawl/cli --skill firecrawl-search
その後、環境で firecrawl または npx firecrawl コマンドを実行できることを確認してください。
最初に読むべきファイル
このスキルでは、まず次のファイルを確認してください。
skills/firecrawl-search/SKILL.md
ここでは有力な補助フォルダは見えておらず、導入判断の大半はこの 1 ファイルで行うことになります。想定されているトリガーフレーズ、コマンドのパターン、検索オプションを確認するためにも、最初に読む価値があります。
firecrawl-search の基本コマンド
上流のスキルは、主に次の 3 パターンを中心に構成されています。
firecrawl search "your query" -o .firecrawl/result.json --json
firecrawl search "your query" --scrape -o .firecrawl/scraped.json --json
firecrawl search "your query" --sources news --tbs qdr:d -o .firecrawl/news.json --json
これで主要な使い方をカバーできます。
- 基本的な検索
- 検索にページ本文抽出を加える使い方
- 新しさで絞ったニュース検索
firecrawl-search に必要な入力
良い firecrawl-search usage は、次の点が明確なクエリから始まります。
- テーマ
- 期間
- ソース種別
- 調べたい意図
弱い入力例: AI regulation
より強い入力例: EU AI Act enforcement guidance 2025 official commentary
検索フェーズはかなり素直にクエリへ反応するため、後者のようなクエリのほうが関連性を上げやすくなります。依頼が広ければ、出力も広くなります。
あいまいな目的を強いプロンプトに変える方法
ユーザーが「open-source AI security について企業が何を言っているか探して」と言った場合、次のように呼び出し計画へ落とし込めます。
- 対象の切り口を定める: ベンダー声明、ブログ記事、レポート、インタビュー
- 期間を定める: 直近 30 日、または過去 1 年
- ソースを定める: web か news
- すぐにページ本文抽出が必要かを決める
firecrawl-search 向けの、より良いエージェントプロンプトは次のようになります。
Use firecrawl-search to find recent web and news sources about open-source AI security from the last 30 days. Return 10 results in JSON, then scrape the top 5 pages with substantive content for comparison.
このプロンプトが優れているのは、検索対象、期間、出力形式、後続アクションまで指定しており、解釈の余地を減らせるからです。
すぐに --scrape を使うべきタイミング
スニペットだけでは足りず、次の用途でページ本文が必要だと分かっているなら --scrape を使う価値があります。
- 要約
- 引用抽出
- ポリシー比較
- コンテンツのクラスタリング
一方、まだノイズの多いテーマを探っている初回段階では、いきなり --scrape を使わないほうが得策です。クエリ調整は検索だけのほうが速く、適切な結果セットを確認してから本文取得に進むほうが効率的です。
ソース種別と新しさの選び方
見えている主なオプションは次のとおりです。
--sources <web,images,news>--limit <n>--tbs ...
多くのリサーチ作業では、次の使い分けが実用的です。
- 鮮度が重要なら
--sources newsを使う - より広く情報源を探したいなら
--sources webを使う - 最初の
--limitは控えめにしてノイズを減らす - 依頼が最近の話題を含むなら
--tbsを使う
よくある品質低下の原因は、ニュース寄りの検索を新しさ指定なしで行い、古い報道と最新報道を混在させてしまうことです。
Web リサーチ向けのおすすめ手順
実用的な firecrawl-search guide は次の流れです。
- まずは絞った検索クエリで始める
- JSON 出力を
.firecrawl/...に保存する - タイトルと URL を見て関連性を確認する
- 狙いが外れていればクエリを調整する
- 結果セットが良くなってから
--scrape付きで再実行する - 抽出した本文の要約や比較は別ステップで行う
この段階的なやり方は、広すぎる検索と全文抽出を一度に曖昧な依頼で行うより、たいてい良い結果につながります。
出力の扱い方とファイル運用
例では .firecrawl/result.json のようなパスに結果を保存しています。この運用はそのまま続けるのがおすすめです。理由は次のとおりです。
- 生の検索出力を確認できる
- 後続ステップでエージェントがファイルを再利用できる
- 発見フェーズと要約フェーズを分離できる
- チャットだけに残る一時的な出力より不具合を追いやすい
出力品質を左右する実践的なコツ
いくつかの習慣を取り入れるだけで、firecrawl-search usage の質はかなり変わります。
- クエリに固有名詞を入れる: 企業名、法律名、製品名
official、comparison、case study、announcementなどの意図語を足す- 探索フェーズと抽出フェーズを分ける
- むやみに大量取得せず、必要な件数を明示する
- ニュース向けのクエリは新しさ条件とセットで使う
依存しすぎる前に知っておくべき限界
スキル説明では、firecrawl-search は構造化出力と任意の本文抽出において組み込みの Web 検索より強い位置づけですが、それでも限界はあります。
- 結果の良し悪しはクエリ品質に依存する
- 広すぎる検索はノイズが多くなりやすい
- ページ全文の取得は便利でも、深いサイトクロールとは別物
- これはリサーチ素材の取得ステップであり、それ自体が検証を完了するわけではない
firecrawl-search スキル FAQ
firecrawl-search は普通の「web を検索して」プロンプトより優れていますか?
再現性のあるリサーチ作業なら、はい。firecrawl-search は、明示的なコマンド、JSON 出力、保存ファイル、必要に応じたページ抽出が必要な場合に強みがあります。単発のちょっとした調べものなら汎用プロンプトでも十分なことはありますが、追跡可能で多段のリサーチには向きません。
firecrawl-search スキルは初心者向けですか?
はい。CLI コマンドの実行と JSON 出力の確認に抵抗がなければ、初心者でも扱いやすい部類です。スキルで見えているコマンド面は小さく、初心者にとっての主な難所はインストールの複雑さより、むしろクエリ設計です。
URL を直接スクレイプする代わりに、いつ firecrawl-search を使うべきですか?
発見フェーズが先に来るときです。firecrawl-search skill は、まず候補ページを探す必要がある場合に向いています。すでに欲しいページが決まっているなら、通常は直接スクレイプしたほうがすっきりします。
firecrawl-search で最近のニュース調査はできますか?
できます。このスキルでは --sources news と、直近結果向けの --tbs qdr:d パターンが明示されています。期間をはっきり定義することが前提ですが、鮮度が重要な調査には適しています。
firecrawl-search だけで Web リサーチの全工程をまかなえますか?
通常は最初の一段であって、全工程ではありません。スキル自体も、search → scrape → map → crawl → interact という段階的な拡張を示しています。ボトルネックが情報源の発見なら導入価値は高く、サイト走査や操作が課題なら別スキルの追加を検討すべきです。
firecrawl-search が向かないのはどんなときですか?
次のような場合は適しません。
- Web サイトの自動操作が必要
- 認証付きブラウジングが必要
- ドメイン全体を網羅的にクロールしたい
- すでに対象 URL が分かっている
firecrawl-search スキルを改善するには
クエリを絞って firecrawl-search の結果を改善する
最大の改善レバーはクエリの具体性です。初回結果が弱いとき、単に件数を増やすのは得策ではありません。次の要素を加えてクエリを書き直してください。
- 明確な主題
- ソースの切り口
- 日付や時期のシグナル
- 必要なら地理条件やドメイン条件
多くの場合、件数を増やすよりクエリの書き換えのほうが効果的です。
一発で詰め込まず、2 パス調査にする
firecrawl-search のよくある失敗は、1 回の実行でやらせすぎることです。より良いパターンは次のとおりです。
- pass 1: 検索だけを行い、価値の高い URL を見つける
- pass 2: 選んだ結果だけをスクレイプして全文を取る
この方法なら、関係の薄いページを無駄にスクレイプせず、後続の要約精度も上げやすくなります。
本当に必要な出力形式を指定する
次のステップが分析なら、出力の扱い方を明示しておくと安定します。
- 生の JSON を保存する
- 上位結果を特定する
- 最終候補だけをスクレイプする
- 抽出後に要約する
これは、エージェントに一度で「全部調べて」と投げるより信頼しやすい進め方です。
ソース条件と時間条件でノイズを減らす
結果が散らかって見えるときは、量を増やす前に制約を足してください。
- 最新トピックなら
--sources newsに切り替える - 新しさが必要なら
--tbsを使う --limitを下げる、または上限を抑える- テーマの表現を狭める
これは firecrawl-search for Web Research を改善する最短ルートになりやすいです。
よくある失敗パターンを把握する
firecrawl-search で起きやすい問題は次のとおりです。
- クエリが広すぎる
- スクレイプが早すぎる
- 恒常的な情報探索と時事性の高い探索を混ぜている
- 抽出ページを読まずに、検索結果だけを最終的な根拠として扱ってしまう
品質が落ちたら、まずこの前提を疑うのが近道です。
エージェントへの指示を強くする
より良い呼び出しプロンプトには、通常次の要素が入ります。
- 調べたい問い
- 良い情報源の基準
- 欲しいソース種別
- 必要な新しさ
- 集める件数
- 結果ページをスクレイプするかどうか
例:
Use firecrawl-search to find 8 recent news and web sources on open-source AI model security benchmarks from the past 14 days. Save JSON results, then scrape the top 4 substantive sources for detailed comparison.
このような指示は曖昧さを減らすため、結果品質の向上につながります。
最初の出力のあとに改善をかける
広いクエリを 1 回流しただけで firecrawl-search skill を判断しないでください。最初の結果セットを見てから、次のように調整するのが基本です。
- 足りない固有名詞を加える
- あいまいな語を外す
- 1 つのクエリを 2 つの狭い検索に分ける
- 明らかに関連性の高いページだけに絞ってスクレイプし直す
このスキルは、一発回答ジェネレーターとしてよりも、反復しながら精度を上げるリサーチツールとして使うと真価を発揮します。
