- 単一の既知のURLに対しては、
/scrapeのJSONモード の方が低コストで、同期的に実行できます。 - 詳しい比較: Data Extractor の選び方。
/agent は、検索・ナビゲーション・データ収集を自動で行い、最も幅広い種類の Web サイトからでも、通常はアクセスしづらい場所のデータを見つけ出し、他のどの API にもできない方法でデータを発見する魔法のような API です。人間なら何時間もかかるエンドツーエンドのデータ収集を、スクリプトや手作業なしで数分で完了させます。
単一のデータポイントが欲しい場合でも、大規模なデータセット全体が必要な場合でも、Firecrawl の /agent がデータ取得を代わりに行います。
/agent は、あらゆる場所にあるデータに対する「ディープリサーチ」と考えてください!
Research Preview: Agent はアーリーアクセス段階です。動作が荒削りな部分がありますが、今後大きく改善されていきます。
報奨金:5,000クレジット — /agentに関する有益なフィードバックに対して
対象となるには、Firecrawl Feedback Assistantとの内容の濃いインタビュー (よく考えられた具体的なユースケースなど) を完了してください。所要時間は数分で、いつでも中断でき、人間にもエージェントにも対応しています (リンクをエージェント用harnessに貼り付けるだけです!) 。/agentを使ったことがない方のご意見も歓迎します。
インタビューを開始報奨の対象となるにはメールアドレスを入力してください。インタビューは毎週末に品質を確認します。
/extract の優れた点をすべて引き継ぎつつ、さらに強化しています:
- URL 不要: 必要な内容を
promptパラメータで記述するだけでよく、URL は任意です - ディープ Web 検索: サイト内を自律的に検索・巡回し、必要なデータを深部まで探索
- 高い信頼性と正確性: 幅広い種類のクエリやユースケースで安定して動作
- 高速: 複数ソースを並列処理して結果を素早く取得
Playground で試す
コードは不要で、インタラクティブな Playground 上でエージェントを試せます。
/agent の使用
prompt のみです。どのようなデータを抽出したいかを記述してください。構造化された出力を得るには、JSON スキーマを指定してください。各 SDK は、型安全なスキーマ定義のために Pydantic (Python) と Zod (Node) をサポートしています:
レスポンス
JSON
URL を指定する場合 (任意)
ジョブのステータスと完了
- デフォルトの方法:
agent()が完了まで待機し、最終結果を返します - 開始してポーリング:
start_agent(Python) またはstartAgent(Node) で即座に Job ID を取得し、その後get_agent_status/getAgentStatusでポーリングします - ポーリングの代わりにプッシュ: ジョブの開始時に
webhookを渡すと、実行の進行中から完了まで agent events を受信できます
ジョブ結果は完了後 24 時間のあいだ API 経由で取得できます。この期間を過ぎても、activity logs から Agent の履歴と結果を参照できます。
考えられるステータス
キャンセルは協調的に処理されます。 cancel エンドポイントを呼び出すと、リクエストはただちに受け付けられますが、すでに進行中のステップ (LLM の推論ステップ、ツール呼び出し、またはブラウザ操作) は、ジョブが停止する前に、正常に停止できる区切りまで実行されます。その短い間もクレジットが引き続き加算される可能性があるため、最終的な
creditsUsed は、キャンセルをクリックした時点で表示されていた値より大きくなる場合があります。キャンセルされたジョブは、ポーリング時にステータス failed を報告し、agent.cancelled webhook イベントを発行します。保留状態の例
JSON
完成例
JSON
エージェント実行の一覧取得
GET /agent は、Playground または API から開始されたものを含む、チームのすべてのエージェント実行を新しい順に一覧表示します。各エントリには、実行 ID、作成時刻、ステータス、対象を示す簡単なヒント、開始時に指定されたオプションが含まれます。
結果は 20 件ずつ固定サイズでページネーションされます。次のページがある場合、レスポンスには next URL が含まれます。その before タイムスタンプを渡すと、次のページを取得できます。SDK メソッドは自動ページネーションを行わないため、どこまで遡るかを制御できます。
実行中の 実行 を追跡する
トレースイベントを独自に並べ替える場合は、まず
agent.id ごとにグループ化してください。producerSequence はイベントを出力するエージェントごとに単調増加するため、単一のグローバルソートではオーケストレーターのイベントとサブエージェントのイベントが誤って交互に並びます。また、終了イベント run.finished の後もしばらくイベントが到着することがあるため、最終状態を表示する前に短いテールウィンドウの間はポーリングを続けてください。
実行トレースとスナップショット
artifact.updated トレースイベントは、snapshotId を通じてエージェントの作業中の出力を参照します。スナップショットの完全な内容は、snapshotsエンドポイントで取得できます。
トレースとスナップショットは、すべての新規実行で使用されるSpark 2で記録されます。廃止前にSpark 1モデルで開始されたジョブには、これらはありません。完全なイベントスキーマについては、trace および snapshot のAPIリファレンスを参照し、これらのエンドポイントが返す失敗については Agent errors カタログを参照してください。
agent のソースデータを取得する
artifact.updated イベントは、1 つの アーティファクト に対する 1 つの変更を表します。artifact.kind は json、markdown、html、screenshot、または text、artifact.path は 実行 が保存した場所、artifact.snapshotId は GET /agent/{jobId}/snapshots/{snapshotId} でコンテンツを取得する際に使用するハンドルです。スナップショット endpoint は、そのコンテンツを string 型の snapshot フィールドで返します。json アーティファクト の場合、この string は JSON エンコードされているためデコードが必要です。一方、markdown、html、text アーティファクト の場合はコンテンツそのものです。
実行 が生成したページコンテンツを取得するには、トレース を取得し、必要な kind の artifact.updated イベントを抽出してから、各 スナップショット を取得します。
- アーティファクト は 実行 の出力であり、ページごとのアーカイブではありません。 実行 が アーティファクト に書き込む内容は、prompt をどのように処理するかによって異なります。そのため、アーティファクト セットは、開いたすべてのページの記録として保証されるものではなく、その特定の 実行 が生成した出力として扱ってください。
- 残りの情報は tool result に含まれます。 各
tool_call.finishedイベントには、その tool が返した内容を保持するresultフィールドが含まれます。アーティファクト にならなかったコンテンツはここに含まれます。
モデルの選択
model パラメータを設定したかどうかにかかわらず、すべての実行で spark-2 が使用されます。
Spark 1 モデルは非推奨です。 Spark 1 のモデル名は後方互換性のため引き続き使用できますが、これらを指定したリクエストは
spark-2 にルーティングされます。Spark 2
spark-2 は、従来は Mini と Pro の選択が必要だった幅広いタスクに対応するため、精度とコストのトレードオフを考える必要はありません。
ハイライト:
- 実行あたりのコストを最小限に抑える
- 最速の実行時間
- 旧 Spark 1 フラッグシップに匹敵する精度
- 推論予算を備えた唯一のモデル:
effort(low、medium、またはhigh) を渡して、どの程度深く考えるかを制御できます
モデルの指定
model パラメータは任意です。すべてのリクエストで spark-2 が実行されます。
パラメータ
Agent と Extract:何が改善されたか
利用例
- リサーチ: 「有望なAIスタートアップ上位5社とその資金調達額を調べる」
- 競合分析: 「SlackとMicrosoft Teamsの料金プランを比較する」
- データ収集: 「企業のWebサイトから連絡先情報を抽出する」
- コンテンツ要約: 「Webスクレイピングに関する最新のブログ記事を要約する」
Agent Playground での CSV アップロード
Ask を使ったトラブルシューティング
APIリファレンス
料金
Agentの料金の仕組み
- シンプルな抽出 (1ページからの連絡先情報など) は、通常必要なクレジット数が少なく、コストも低くなります
- 複雑なリサーチタスク (複数ドメインにわたる競合分析など) は、より多くのクレジットを使用しますが、必要な総工数を反映します
- 透明な利用状況により、各リクエストで消費されたクレジット数を正確に確認できます
- クレジット変換により、Agentのクレジット使用量が自動的にクレジットへ変換され、請求処理が容易になります
クレジット使用量は、プロンプトの複雑さ、処理されるデータ量、および要求された出力構造に応じて変動します。目安として、ほとんどのAgent実行では数百クレジットが消費されますが、よりシンプルな単一ページのタスクでは少なく、複数ドメインにまたがる複雑なリサーチでは多くなる場合があります。
Parallel Agents の料金
はじめに
コスト管理
- 無料実行から始める: 毎日 5 回の無料リクエストを使って料金感をつかむ
maxCreditsパラメータを設定する: 消費してもよいクレジットの最大数を設定して支出を制限します。ダッシュボードでは上限は 2,500 クレジットです。より高い上限を設定するには、API 経由でmaxCreditsパラメータを直接使用してください (注: 2,500 を超える値は常に有料リクエストとして課金されます)- プロンプトを最適化する: より具体的なプロンプトほど、使用するクレジットが少なくなることが多い
- 大きなタスクを小さな実行に分割する: 1 回の エージェント 実行では、構造化データが約 150〜200 行返されます。大規模な抽出ジョブでは、カテゴリ、地域、または URL バッチ (1 回の実行あたり 3〜5 URL) ごとに分割し、結果を結合してください。これにより、各実行を
maxCreditsの上限より十分低く保つこともできます。 - 利用状況を監視する: ダッシュボードを通じて消費量を追跡する
- 期待値を設定する: 複数ドメインにわたる複雑なリサーチは、単純な単一ページの抽出よりも多くのクレジットを使用します
料金は Research Preview から一般提供へ移行する際に変更される可能性があります。現在のユーザーには、料金変更がある場合は事前に通知されます。
Firecrawl API キーが必要な AI エージェント ですか? 自動オンボーディング手順については firecrawl.dev/agent-onboarding/SKILL.md を参照してください。

