エージェントの「知らないことを調べる力」を外注する──Firecrawlが、コード専用の検索窓を70万件超の一次情報につないだ

コーディングエージェントに任せた作業が、存在しないAPIを呼んだり、二年前のドキュメントを根拠に書いたりして詰まる──そんな経験をした開発者は少なくないはずです。原因の多くは、モデルの賢さではなく「調べる材料」の質にあります。エージェントが自力で投げる一般的なWeb検索は、ブログの二次情報やSEO記事を上位に返しがちで、GitHubのイシューや実際のドキュメントといった一次情報にたどり着けないことがあるからです。

この「調べる力」の部分を専用の道具に置き換えようとするのが、Firecrawlが公開したDeveloper Indexです。コーディングエージェント向けに設計された検索APIで、リポジトリのREADME・イシュー・マージ済みプルリクエスト・公式ドキュメントといった一次情報だけを対象に、自然言語の質問で引けるようにしています。同社はXでの告知で「コーディングエージェントを強化するために作った」と位置づけており、公開は2026年8月下旬です。

「二次情報を避けて一次情報だけを引く」という設計

Developer Indexが索引しているのは70,000,000件を超える成果物です。内訳として挙げられているのは、公開リポジトリのREADME・GitHubのイシュー・マージ済みプルリクエスト、そして整備されたドキュメントサイトやOpenAPI仕様です。多くのソースは日次で更新され、公開から24時間以内に取り込まれるとしています。

ねらいは明快で、エージェントが「このライブラリの挙動」「このAPIの契約」「このエラーメッセージの意味」「既知のバグ」といった疑問を、ブログのまとめ記事ではなく発生源そのものに当たって答えられるようにすることです。従来の汎用Web検索が拾いにくかった領域を、あえて対象を絞ることで拾いにいく発想です。

自社ベンチマークが示した「上位に正解が入る確率」

Firecrawlは、実際の開発者の質問1,179件を集めた「DevDex」という評価セットで、検索結果の上位10件に正解の一次情報が含まれる割合（recall@10）を比較しています。数字は次のとおりです。

外部の次点プロバイダにおよそ1割の差をつけた、というのが同社の主張です。ただし内訳を見ると得手不得手がはっきり分かれます。

• リポジトリ探索: 0.76（最も得意）
• イシュー・PR: 0.66
• ドキュメント参照: 0.47（最も苦手）

「どのリポジトリを見ればよいか」を当てるのは強い一方、ドキュメントの該当箇所を引く精度は半分弱にとどまります。ここは割り引いて捉えるべき点です。

手元のエージェントにどうつなぐか

導入経路は複数用意されています。CLIなら npx firecrawl-cli@latest setup developer-index の一行で設定でき、Model Context Protocol（MCP）経由でも利用できます。Python／Node.jsのSDKもあり、Claude Code・Cursor・Windsurf・Codexといった主要なエージェントからそのまま検索できる作りです。ホスト型のMCPサーバーは認証なしで、専用の開発者検索ツールと汎用検索の両方を公開しています。

APIを直接叩く場合は、開発者向けの検索エンドポイント（/v2/search/developer）に自然言語の query と件数 k を渡します。types で doc／issue／pull_request／readme を絞り込んだり、repos や min_stars・language・license といった条件で対象を狭めたりもできます。返ってくるのは安定したID、URL、そしてマッチした本文の抜粋（Markdown）です。利用開始にAPIキーは不要で、無料枠が用意されています。料金は「10件あたり2クレジット（切り上げ）」で、11〜20件なら4クレジットという従量制です。

エージェント時代に生まれた「検索を売る」レイヤー

この動きが示すのは、コーディングエージェントの実力が、モデル本体だけでなく「文脈をどう供給するか」で決まる段階に入ったことです。retrieval（検索・取得）の質が最終的なコードの正しさを左右するなら、そこを専業で最適化したサービスに価値が生まれます。実際、Claude CodeのSkillやMCPが整い、エージェントが外部ツールを自律的に呼べるようになったことで、こうした「検索を売る」レイヤーが成立しやすくなっています。自社でドキュメントのインデックスを組む代わりに、月々のクレジットで一次情報への検索窓を借りる、という選択肢が増えるわけです。

一方で、割り引いて見るべき点もあります。第一に、上に挙げた採点表はFirecrawl自身が用意した評価セット（DevDex）による自己申告であり、独立した第三者検証はまだ揃っていません。recall@10はあくまで「正解の情報源が上位10件に入るか」を測る指標で、エージェントが最終的に正しいコードを書けたかどうかとは別物です。第二に、質問文を外部のインデックスに送る以上、社内コードや未公開の文脈をどう扱うかというデータガバナンスの観点は避けられません。第三に、従量課金は「エージェントを回し続けるほど検索コストも積み上がる」構造で、トークン代と同じく無人運用のランニングコストとして効いてきます。「便利な検索窓を借りる」ことと「特定ベンダーへの依存が増える」ことは表裏一体だ、という見方も出ています。

とはいえ、エージェントが自力で正しい一次情報にたどり着けるかどうかは、そのまま生成物の質に直結します。モデルの乗り換えが日常になった今、検索・取得の層を差し替え可能な部品として持っておく発想は、エージェント運用の実務で覚えておく価値がありそうです。

参照: Developer Index: Code & Docs Search API for Coding Agents（Firecrawl） ／ Developer Index ドキュメント（Firecrawl Docs） ／ Firecrawl 公式X（告知）