Skip to main content
Firecrawl のモニタリングでは、Web サイト上のコンテンツが変更されたことを検出し、webhook またはメールで通知を受け取れます。定期的なスクレイピングまたはクロールを実行し、各結果を最後に保持されたスナップショットと比較します。モニターを使うと、商品ページ、ドキュメント、ブログ、変更履歴、競合サイトなど、変更の追跡が重要なページを監視できます。 各チェックでは、ページ単位の結果が samenewchangedremovederror として記録されます。監視対象の各ページの処理完了時に webhook を受け取ることも、チェックが完了するたびに webhook を受け取ることも、変更やエラーが発生した際にメールで要約を受け取ることもでき、これらを自由に組み合わせることもできます。

モニターを作成する

1 つ以上の明示的な URL を対象としたスクレイピングモニターを作成します:
各 チェック で、クロールによって検出されたすべてのページの差分を比較するクロールモニターを作成します:
create の各呼び出しでは、正規化された cron、計算済みの nextRunAt、および estimatedCreditsPerMonth を含む新しいモニターが返されます。判定が有効な場合、estimatedCreditsPerMonth は上限見積もりになります。これは、判定クレジットが実際に判定された変更ページに対してのみ課金されるためです:
Response
Firecrawl CLI からモニターを作成することもできます:
CLI

ゴールと判定

意味のある変更があったときだけ通知を受けたい場合は、平易な表現で goal を追加します。goal が指定されていて judgeEnabled が省略されている場合、Firecrawl は自動的に判定を有効にします。判定は変更のあったページで実行され、meaningfulconfidencereasonmeaningfulChanges を含む judgment を返します。 変更の判定はまだ行わず、ゴールだけを保存したい場合は、judgeEnabled: false を使用します。判定が実行されるのは、モニター に judgeEnabled と空でない goal の両方が設定されている場合だけです。
各 チェック では、常に元となるスクレイピングまたはクロールの料金が発生します。判定が有効な場合、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
最小間隔は 15 分です。API レスポンスでは常に正規化された cron 式が返されます。テキストによるスケジュールでは、timezonedaily at 9am のような表現の実行時刻を制御します。テキストによるスケジュールは、cron に変換される前にモニター ID ごとに分散されるため、多数のモニターがまったく同じタイミングで実行されることはありません。

ターゲット

モニターでは、2 種類のターゲットをサポートしています。
  • scrape: urls 内の各 URL に対して 1 回スクレイピングを実行します。
  • crawl: 各チェックで url に対して完全なクロールを実行し、検出されたすべてのページの差分を比較します。
各モニターには 1~50 個のターゲットを指定できます。retentionDays のデフォルトは 30 で、最大 365 まで設定できます。 ターゲットのスクレイピングのオプションは、そのまま基盤となるスクレイピング ジョブに渡されます。モニターによってトリガーされたスクレイピングでは、maxAge のデフォルトが 0 になるため、明示的に別の maxAge を設定しない限り、各チェックで毎回新しくスクレイピングが実行されます。
Scrape target
クロール ターゲットでは、クロールの動作には crawlOptions を、各ページのスクレイピングには scrapeOptions を使用します。
Crawl target

変更追跡

デフォルトでは、Firecrawl は各ページの Markdown の差分を比較し、samechangednewremovederror のいずれかを返します。特定の構造化フィールド (価格、見出し、在庫フラグ、リスト内の項目など) の変更を検出したい場合は、対象の scrapeOptionsmodes: ["json"] を指定した changeTracking フォーマットを追加して、JSON モードの変更追跡を有効にします。

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 は確認リンクを含むメールを送信します。これにより、その受信者がそのモニターの通知を受け取ることに明確に同意したことを確認できます。受信者がすでにチームのメンバーである場合は、確認は不要です。

チェック結果

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 リファレンス