Skip to main content
Firecrawl のモニタリングは定期的なチェックを実行し、何かが変化したり新たに現れたりしたときに、あなたまたは agent に通知します。/monitor を使うと、既知のページを監視したり、スケジュールに従って Web サイトをクロールしたり、ゴールに一致する新しい結果を見つけるために常時稼働の Web 検索を実行したりできます。 すべてのモニタータイプは同じワークフローを共有しています。1 つ以上の ターゲット を選択し、スケジュールを設定し、任意の自然言語のゴールを追加して、重要な変化があったときに webhook、メール、または Slack 通知を受け取ります。このページでは共通の構成について説明します。ターゲット 固有の設定と例については、PageWebsite、または Web 全体規模の監視 のモニタリングページを参照してください。

ページ監視

1 つ以上の既知の URL を監視し、各スクレイピング結果を前回のスナップショットと diff し、意味のあるページ変更があれば alert を送信します。

Web サイト監視

スケジュールに従ってサイトをクロールし、追加、変更、削除されたページを検出して、webhook または受信トレイに通知します。

Web 全体規模の監視

定期的に Web 検索を実行し、ゴールに一致する新しい結果が現れたときに alert を送信します。
各チェックでは、ページ単位の結果が samenewchangedremovederror として記録されます。監視対象の各ページの処理完了時に webhook を受け取ることも、チェックが完了するたびに webhook を受け取ることも、変更やエラーが発生した際にメールで要約を受け取ることも、チャンネルに Slack 通知を受け取ることもでき、これらを自由に組み合わせることもできます。

ターゲット

すべてのモニターには 1 つ以上の ターゲット があります。ターゲットの種類によって、各チェックで実行される内容が決まります: 各モニターは 1~50 個のターゲットを受け付け、1 つのモニター内で異なる種類のターゲットを組み合わせることもできます。retentionDays のデフォルトは 30 で、最大 365 まで設定できます。 create の各呼び出しでは、正規化された cron、計算済みの nextRunAt、および estimatedCreditsPerMonth を含む新しいモニターが返されます。判定が有効な場合、estimatedCreditsPerMonth は上限見積もりになります。これは、判定クレジットが実際に判定された変更ページに対してのみ課金されるためです:
Response

ゴールと判定

意味のある変更があったときだけ通知を受けたい場合は、平易な表現で goal を追加します。goal が指定されていて judgeEnabled が省略されている場合、Firecrawl は自動的に判定を有効にします。判定は変更のあったページで実行され、meaningfulconfidencereasonmeaningfulChanges を含む judgment を返します。 ゴールの適用方法は ターゲット によって異なります。pagewebsite のモニターでは変更されたページを判定し、entire web-scale monitors では新しい各 search result を判定します。 変更の判定はまだ行わず、ゴールだけを保存したい場合は、judgeEnabled: false を使用します。判定が実行されるのは、モニター に judgeEnabled と空でない goal の両方が設定されている場合だけです。
search ターゲット (entire web-scale monitoring) では、judgeEnabled: false を設定しない限り goal が必要です。scrapecrawl ターゲット では 任意 です。
各 チェック では、常に元となるスクレイピングまたはクロールの料金が発生します。判定が有効な場合、judge は検証した変更済みページごとに 1 クレジット を追加で消費します。変更されたページがない チェック では、judge クレジット は消費されません。
適切なゴールは、短く明確であることが重要です。何を alert のトリガーにするかを示し、top N、価格、役割の種類、会社、地域、トピック、status、またはエンティティなどの対象範囲も明記してください。除外条件は、意図に含まれる場合にのみ追加します。ゴールが広い場合は、その広さを保ってください。たとえば、“any change” の場合は、変更を見逃すようなノイズ除去の絞り込みを加えるべきではありません。 たとえば、次のような goal を持つ モニター では:
一致するストーリーが監視対象に入ると、このような monitor.page webhook が生成されることがあります:
monitor.page

スケジュール

スケジュールは、cron またはシンプルな自然言語テキストで指定できます。
サポートされている自然言語の例:
  • every 30 minutes
  • every 15 minutes starting at :07
  • hourly
  • every 2 hours
  • daily
  • daily at 9:00
  • daily at 9am
  • daily at 5:30 PM
  • weekly
最小間隔は 5 分です。API レスポンスでは常に正規化された cron 式が返されます。テキストによるスケジュールでは、timezonedaily at 9am のような表現の実行時刻を制御します。テキストによるスケジュールは、cron に変換される前にモニター ID ごとに分散されるため、多数のモニターがまったく同じタイミングで実行されることはありません。

変更追跡

PageWeb サイト のモニターでは、デフォルトで各ページの Markdown の差分を比較し、samechangednewremovederror のいずれかを返します。特定の構造化フィールド (価格、見出し、在庫フラグ、リスト内の項目など) の変更を検出したい場合は、対象の scrapeOptionsmodes: ["json"] を指定した changeTracking フォーマットを追加して、JSONモードの変更追跡を有効にします。
変更追跡は scrape ターゲットと crawl ターゲットに適用されます。Web スケール全体の (search) モニターは、既知のページの差分を比較するのではなく、新しい結果が見つかったときにアラートを送信します。詳しくは ステータスと重複排除 を参照してください。

Markdown モード (デフォルト)

scrapeOptions.formats["markdown"] のみの場合、チェック レスポンス内の変更された各ページには、unified 形式のテキスト差分と、parseDiff スタイルの AST が含まれます。
Markdown-mode diff

JSONモード

modes: ["json"] を指定した changeTracking フォーマットを、注目するフィールドを定義した JSON schema (または prompt) とあわせて渡します。Firecrawl はチェックのたびにその JSON を抽出し、フィールドパスをキーとするフィールド単位の差分を出力します。さらに、利用側で元のスクレイピング結果を再取得しなくて済むよう、現在の抽出結果全体を含む snapshot.json も出力します。
差分の ペイロード では、抽出結果内の JSON パスがキーとして使われます。各値は {previous, current} のペアです。
JSON-mode diff
追跡対象のフィールドに変更がなく、周囲の Markdown だけが変わった場合でも、git-diff も有効にしない限り (下記の mixed mode を参照) 、JSONモードのモニターは same を返します。この差分は、schema 内のフィールドだけに焦点を当てています。

Mixedモード (JSON + git-diff)

構造化されたフィールド単位の差分 生の markdown の unified diff の両方が必要な場合は、両方のモードを指定します。
Mixed target (JSON + git-diff)
すると、チェック レスポンスには snapshot.json の抽出結果に加えて、diff.text (markdown のサイドカー) と diff.json (フィールド単位の差分) の両方が含まれます。
Mixed-mode diff (JSON + git-diff)
mixed-mode のページでは、いずれか 一方でも変更があれば changed が報告されます。

通知

Webhooks

モニター に webhook が設定されている場合、Firecrawl は 2 つの モニター event を送信できます。
  • monitor.page: 監視対象の各ページのスクレイピングが scrape worker で完了するたびに送信されます。
  • monitor.check.completed: チェック全体の整合処理が完了した後に送信されます。チェック の status と集計数が含まれます。ページ単位の結果を確認するには、monitor.page event または モニター check API を使用してください。
monitor.page には、変更されたページに対して意味のある変更の判定が実行された場合、isMeaningfuljudgment が含まれます。
Webhook config
monitor.page の ペイロード:
monitor.page
monitor.check.completed の ペイロード:
monitor.check.completed
success は、ページエラーなしで チェック が完了した場合に true です。失敗した チェック または部分的な チェック の場合は false となり、利用可能であれば error に失敗理由が含まれます。

メール

メールの要約は、チェックで変更・新規追加・削除・エラーのいずれかに該当するページがあった場合にのみ送信されます。
Email config
モニターでゴールが設定され、判定が有効になっている場合、メールの要約では重要な変更ページが優先されます。変更されたすべてのページがノイズと判定され、新規追加・削除・エラーに該当するページもない場合、メールは送信されません。 recipients を省略すると、Firecrawl はシステムアラートメールの受信対象となるチームメンバーに送信します。 明示的な受信者は最大 25 件まで設定できます。

受信者の確認手順

新しい受信者がモニターに追加されると、Firecrawl は確認リンクを含むメールを送信します。これにより、その受信者がそのモニターの通知を受け取ることに明確に同意したことを確認できます。受信者がすでにチームのメンバーである場合は、確認は不要です。

Slack

モニター通知をSlackチャンネルに送信することもできます。
Slack通知はダッシュボード専用の機能です。設定できるのはmonitoring dashboardのみで、APIやSDKsからは設定できません。
Slack通知を設定するには:
  1. monitoring dashboardを開きます。新しいモニターの作成中にSlack通知を追加することも、すでに存在するモニターに追加することもできます。
  2. モニターの作成中、または既存のモニターを選択した後、NotificationsまでスクロールしてSlackを選択します。
  3. OAuthによる認証に進みます。フローを完了し、通知を受け取りたいワークスペースとチャンネルを選択します。

チェック結果

GET /v2/monitor/{monitorId}/checks でチェックの一覧を取得し、GET /v2/monitor/{monitorId}/checks/{checkId} で個別のチェック詳細を確認できます。SDKs はデフォルトで自動的にページネーションに対応しています。
チェック一覧は、チェックの status で絞り込めます: queuedrunningcompletedfailedpartialskipped_overlap チェック詳細のレスポンスには、estimatedCreditsactualCredits、集計件数、およびページネーションされた pages 配列が含まれます。estimatedCredits はそのチェックに対して上限として予約されるクレジット数で、actualCredits は Firecrawl が変更されたページ数と判定が必要なページ数を把握した後に確定する最終的な請求量です。結果の次のページを取得するには、トップレベルの next URL を使用します。これはクロールのページネーションと同じです。ページは status で絞り込めます: samenewchangedremovederror。変更された各ページにはインラインの diff データが含まれます。JSONモードのモニターによるページには、現在の抽出結果を含む snapshot も含まれます。
Markdown-mode response

料金

モニター にモニターごとの個別料金はありません。各チェックでは、実行されるスクレイピング、クロール、または検索の分のクレジットが消費され、さらに有意な変更の判定を有効にしている場合は、判定で有意な変更ありと認められたページごとに追加で 1 クレジットが消費されます。

API リファレンス