firecrawl-map

firecrawl-mapスキルの概要

firecrawl-mapでできること

firecrawl-map は、Webサイト上のURLを見つけることに特化したスキルです。ドメインは分かっているが目的のページURLまでは分からないときや、scrape・crawl・抽出に入る前にサイト構造を手早く棚卸ししたいときに最も力を発揮します。

firecrawl-mapスキルが向いている人

firecrawl-mapスキルが特に合うのは、Webリサーチ、サイト探索、スクレイピング前の設計を行う人です。

• 深い抽出に進む前に正しいページを見つけたいAIエージェント
• Webスクレイピングのワークフローを組む開発者
• 公開URLの露出範囲を監査したいリサーチャー
• フルクロールは回さず、まずURL一覧だけ素早く取りたい運用担当者

実際に解決したい仕事

多くのユーザーが本当に欲しいのは、単に「全ページの一覧」そのものではありません。答えたいのは、たとえば次のような問いです。

• 「このサイトの認証ドキュメントはどこにあるか？」
• 「scrapeする前に、このドメイン配下にどんなページが存在するか？」
• 「sitemapを使ってURLを素早く見つける近道はあるか？」
• 「まずmapすべきか、それとも最初からcrawlに進むべきか？」

この意味で、firecrawl-map for Web Scraping は最終的なデータ抽出ツールというより、発見フェーズの一手として特に有用です。

firecrawl-mapが選ばれる理由

大きな差別化ポイントは、速度とスコープの制御しやすさです。たとえば「docsページを探して」といった汎用プロンプトに比べて、firecrawl-mapスキルは URL一覧の取得、検索語での絞り込み、後続処理向けの出力保存までを、再現可能なCLI手順として実行できます。

リポジトリから読み取れる主な強みは以下のとおりです。

• firecrawl map による直接的なCLI利用
• 大規模サイト向けの任意の --search フィルタ
• テキストまたはJSONでのURL棚卸し出力
• sitemap戦略の選択に対応
• search と本格的な crawl/scrape の中間ステップとして使いやすい

向いていない用途

次のような要件がある場合、firecrawl-map は適切な選択ではありません。

• ページ本文の完全な抽出
• インタラクティブなブラウジング
• 各ページからの詳細な構造化スクレイピング
• URL発見を超えた高度なサイト巡回ロジック

このようなケースでは、mapはゴールではなく準備工程です。

firecrawl-mapスキルの使い方

firecrawl-mapスキルの導入前提

このスキルは firecrawl/cli リポジトリ内の skills/firecrawl-map にあります。実行環境としては、次のコマンドを動かせることが前提です。

• firecrawl *
• npx firecrawl *

エージェントやローカルのワークフローでBashコマンドを実行できるなら、通常は次の firecrawl-map 導入パスで十分です。

npx firecrawl map "<url>" --limit 100

すでに Firecrawl CLI をグローバルで使える環境なら、こちらを使います。

firecrawl map "<url>" --limit 100

使う前にまず読むべきファイル

最初に確認するのは次です。

• skills/firecrawl-map/SKILL.md

このリポジトリの該当部分は小さく、周辺資料も多くありません。導入しやすい反面、プロンプトではドメイン、目的、出力形式を明示したほうが結果が安定します。

firecrawl-mapの基本的な使い方

このスキルには、よく使われる2つの利用パターンがあります。

1. トピックから有力なページを探す

firecrawl map "https://example.com" --search "authentication" -o .firecrawl/filtered.txt

2. より広くURL一覧を取る

firecrawl map "https://example.com" --limit 500 --json -o .firecrawl/urls.json

これが firecrawl-map の中核的な使い方です。1ページを探したいなら --search で狭く始める、次のスクレイピング工程を設計したいなら上限付きの広いURL一覧から始める、という使い分けが基本です。

firecrawl-mapスキルに必要な入力

firecrawl-mapスキルをうまく使うには、次の入力をはっきり与えるのが重要です。

• ルートURLまたはドメイン
• 必要なのが1ページなのか、多数のURLなのか
• 話題が分かっているなら検索フレーズ
• 返すURL数の上限
• 出力形式: プレーンテキストかJSONか
• サブドメインを含めるべきか
• sitemapをどう扱うか

弱い入力:

• 「このサイトのdocsを探して」

強い入力:

• 「https://docs.example.com を map して、authentication を検索し、一致度の高いURLをJSONで返して。メインのdocsドメインだけでは結果が少ない場合に限ってサブドメインを含めて。」

後者のように具体化すると、推測の余地が減り、選ぶべきコマンドも明確になります。

曖昧な依頼を強いプロンプトに変える方法

firecrawl-map用の良いプロンプト指示は、1文の中で次の5点を明示することです。

• site
• intent
• scope
• filter
• output

例:

• 「https://example.com に対して firecrawl-map を使い、公開URLを最大200件まで列挙し、sitemap discovery を優先し、無関係なサブドメインは除外し、後続のscraping用にJSON出力を保存して。」

特定ページを探す例:

• 「firecrawl-map を使って https://example.com 上で pricing API limits に最も関連するページを見つけ、一致したURLをテキストファイルに書き出して。」

おすすめのワークフロー: scrapeやcrawlの前にまずmap

実務では、次の流れが扱いやすいです。

1. 1ページを探したいなら、--search 付きで firecrawl map を使う
2. 広めのURL集合が必要なら、--limit と --json 付きで firecrawl map を使う
3. 返ってきたURLを確認する
4. 関連性の高いページを選ぶ
5. サイト構造が十分つかめてから scrape または crawl に進む

やみくもにscrapeするより、時間もコストも抑えやすくなります。

出力品質に大きく効くオプション

特に重要なのは次のオプションです。

• --search <query>: 大規模サイトでトピックページを探すのに最適
• --limit <n>: 結果セットが大きくなりすぎるのを防ぐ
• --json: 後段のフィルタリングや自動化をしやすくする
• --sitemap <include|skip|only>: sitemapの網羅性を重視したいときに有効
• --include-subdomains: 範囲を広げられるが、ノイズも増えやすい
• -o, --output <path>: パイプライン内で結果を再利用しやすい

結果がノイジーなときは、まず検索語、ドメインの範囲、サブドメインの扱いを見直すのが近道です。

sitemap戦略の選び方

--sitemap オプションは、多くの人が思う以上に結果へ影響します。

• only: サイトのsitemapを信頼でき、よりクリーンなカバレッジを素早く得たいときに最速
• include: sitemapの助けを借りつつ、それだけに依存したくないときの無難な既定選択
• skip: sitemapの内容が古い、不完全、またはミスリードになりそうなときに有効

ドキュメントサイトでは、制約なしの探索よりも include または only のほうが、firecrawl-map for Web Scraping の結果が良くなることがよくあります。

サブドメインを含めるべきケース

--include-subdomains は、目的のコンテンツがメインホスト以外にある可能性がある場合にだけ使うのが基本です。たとえば次のようなケースです。

• docs.example.com
• developers.example.com
• support.example.com

企業サイトでは、本当に広い範囲を見たいのでない限り、最初から有効にしないほうが安全です。マーケティング、サポート、アプリ画面など、目的外のURLが大量に混ざる原因になります。

実際によく必要になる例

ログインや認証ドキュメントのページを探す:

firecrawl map "https://docs.example.com" --search "authentication" -o .firecrawl/auth-pages.txt

再利用しやすいJSONのURL一覧を取る:

firecrawl map "https://example.com" --limit 300 --json -o .firecrawl/site-map.json

docsサイトで sitemap のみを優先して探索する:

firecrawl map "https://docs.example.com" --sitemap only --limit 500 --json

docs の場所が不明なときにサブドメインまで広げる:

firecrawl map "https://example.com" --search "API reference" --include-subdomains

導入時につまずきやすいポイント

firecrawl-mapスキルで苦戦する主因は、インストールではなく依頼内容の粗さであることがほとんどです。

• 広すぎるドメインから始めてしまう
• 1ページを探したいのに --search を付け忘れる
• 上限なしでURLを取りすぎる
• 早い段階でサブドメインを含めてしまう
• mapをコンテンツ抽出ツールとして扱ってしまう

最初の結果が雑然としていたら、ツールを変える前に、対象サイトを絞り、トピック指定を鋭くするのが先です。

firecrawl-mapスキル FAQ

firecrawl-mapは普通のプロンプトより優れていますか？

URL発見を既知サイト上で行うタスクなら、はい。通常のプロンプトは「ありそうなページ」を推測するだけになりがちですが、firecrawl-map なら対象ドメインからURLを列挙し、絞り込むまでを具体的かつ再現可能な方法で実行できます。

firecrawl-mapスキルは初心者向きですか？

はい。コマンド面が小さく、覚えることが多すぎないためです。最初の一歩としては、次のどちらかが最も簡単です。

firecrawl map "https://example.com" --search "pricing"

firecrawl map "https://example.com" --limit 100 --json

初心者が最もやりがちなのは、ページ内容の抽出まで期待してしまうことですが、それはこのスキルの中核用途ではありません。

crawlの代わりに、いつfirecrawl-mapを使うべきですか？

サイト構造を把握したいときや、候補ページの当たりを付けたいときは、まず firecrawl-map を使うのが適しています。より広い巡回やページ単位の処理が必要になった段階で、発見後の次工程として crawling を使うとよいです。

firecrawl-mapを使わないほうがいいのはどんなときですか？

次の場合はスキップしてください。

• すでに正確なURLが分かっている
• ページ本文、メタデータ、構造化抽出が必要
• URL一覧ではなくブラウザ操作が必要
• タスクの主目的がサイト探索ではない

firecrawl-mapは大規模サイトでも有効ですか？

はい。ただし、スコープを制御できる場合に限ります。--search、--limit、sitemap戦略を意図的に使ってください。大規模サイトこそ firecrawl-map の価値が出やすい一方で、曖昧なプロンプトだとノイズも最大化しやすくなります。

どの出力形式を選ぶべきですか？

人がざっとページ一覧を確認するだけならプレーンテキストで十分です。別ツール、スクリプト、後続処理で結果を扱うなら --json を選ぶのが適しています。

firecrawl-mapスキルを改善する方法

思っている以上に、最初は狭い対象から始める

firecrawl-map の結果を改善する最も簡単な方法は、早い段階でスコープを絞ることです。目的の情報がdocs内にありそうなら、企業トップページではなく docs のホスト名を直接指定してください。

Better:

• https://docs.example.com

Worse:

• https://example.com

ページ意図に合う検索フレーズを使う

firecrawl-mapスキルでは、キーワード数より検索の質が重要です。長く詰め込んだクエリより、短い意図語のほうがうまくいくことが多いです。

Better:

• authentication
• rate limits
• API reference

Worse:

• where can I find complete developer authentication API reference and login documentation

より良いほうはURLフィルタリングにかけやすく、通常は一致結果もきれいになります。

次工程につなぐならJSONを選ぶ

次の工程が scrape、filter、classify、deduplicate のいずれかなら、次を使ってください。

--json

この小さな選択だけで、firecrawl-map の運用は自動化しやすくなり、手作業の後処理も減らせます。

mapは一度きりではなく、反復的に使う

強いワークフローは次の形です。

1. まず狭い --search を実行する
2. 有力なURLを確認する
3. 最も有望なサブドメインまたはセクションに対して2回目の map を実行する
4. 必要な場合だけ --limit を増やす
5. 発見結果が安定してから scrape/crawl に進む

巨大な1回の実行より、このやり方のほうがノイズを抑えやすく、信号が残ります。

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

firecrawl-map for Web Scraping で典型的な失敗パターンは次のとおりです。

• 広すぎるドメインから無関係なURLが大量に出る
• 検索語が曖昧で、目標ページを取りこぼす
• 合わないsitemap戦略に依存して、一覧が不完全になる
• 不要なサブドメイン有効化で結果がノイジーになる

対処はシンプルです。サイトを絞る、クエリを鋭くする、sitemapモードを変える、対象範囲を縮める。この4つで大半は改善します。

成功条件を明示してプロンプトを改善する

「すべてのURLを出して」とだけ頼むのは避け、何をもって成功とするかを明示してください。

例:

• 「firecrawl-map を使って https://docs.example.com 上の認証設定に関連するページを探し、関連度の高いURLから順に返して、最大50件に制限し、追跡scraping用にJSON出力を保存して。」

こうすると、ツール選択、パラメータ、どこで打ち切るかがずっと明確になります。

シンプルなエスカレーション経路を持つ

実務では、次の判断フローが有効です。

• 1ページの当たりを付けたい: map --search
• URL一覧が必要: map --limit --json
• ページ本文が必要: mapの後で scrape
• より広い巡回が必要: mapの後で crawl

ワークフローを複雑にしすぎずに firecrawl-map の成果を改善するなら、この使い分けが最も実用的です。