メインコンテンツへスキップ
Web 全体規模のモニタリングは、Web 全体を見張り、何かが公開された瞬間にあなたやあなたの agent に知らせる常時稼働の検索です。 ページモニターや Web サイトのモニターは、指定した URL を監視します。Web 全体規模のモニターは、Web 全体を監視します。既知のページの差分を取るのではなく、実行する queries と goal を指定します。すると Firecrawl が各チェックでそのクエリを実行し、judge がゴールに関連すると判断した新しい結果についてアラートを送信します。つまり、差分検出ではなくディスカバリーです。 各チェックでは毎回同じサイクルが実行されます。ゴールとその queries を受け取り、鮮度の対象期間を適用し、検索を実行し、結果を正規 URL で重複排除し、任意の AI judge がどの新しい結果にゴールにとって意味があるかを判定し、スクレイピングモニターやクロールモニターと同じ webhook と email のチャネルを通じてアラートを送信します。スケジュール設定、ゴール、judging、通知はすべて、モニタリングの概要 で説明されているとおりに機能します。
ページモニターとクロールモニターは、指定した URL 上の content の差分を取ります。一方、Web 全体規模のモニターは、Web 全体から新しい結果を見つけます。基盤となるスケジュール設定、judge、通知は同じです。

​
検索ターゲット

検索ターゲットでは type: "search" を使用し、urls の代わりに、実行するクエリと結果のスコア付け方法を指定します。
Search target
{
  "type": "search",
  "queries": ["open source AI coding assistant launch"],
  "searchWindow": "24h",
  "maxResults": 10,
  "includeDomains": ["news.ycombinator.com"]
}
FieldTypeDescription
type"search"検索対象を選択します。
queriesstring[]各チェックで実行する検索クエリです。1～12 個指定でき、各クエリは最大 256 文字です。必須です。
searchWindow"5m" | "15m" | "1h" | "6h" | "24h" | "7d"新しさの絞り込みです。この期間内に公開された結果のみを対象にします。デフォルトは 24h です。
maxResultsnumber各チェックで評価する結果の合計数です。1～50 を指定できます。デフォルトは 10 です。これは各 queries 全体での合計上限であり (結果は先にマージ・重複排除されます) 、クエリごとの上限ではありません。他のクエリで先に上限に達した場合、個々のクエリの結果数は少なくなるか、0 件になることがあります。
includeDomainsstring[]任意です。結果をこれらのドメインに制限します (最大 50 件) 。excludeDomains とは同時に使用できません。
excludeDomainsstring[]任意です。これらのドメインの結果を除外します (最大 50 件) 。includeDomains とは同時に使用できません。
検索対象では、judgeEnabled: false を設定しない限り、空でないモニターレベルの goal が必要です。queries は必須で、goal は judge が各新規結果をどのように判定するかの基準になります。クエリ自体を生成するものではありません。ゴールと判定を参照してください。
クレジットはクエリ数に応じて増加します。 各クエリは最大 maxResults 件の結果を取得し、検索呼び出しのクレジットは、マージ・重複排除前の全クエリの生の結果数に基づいて課金されます。クエリを追加すると、事前見積もりだけでなく実際の検索コストも増加します。マージ・重複排除後に Firecrawl が評価する候補は最大 maxResults 件までのため、judge のクレジットは選択・判定された結果数の範囲内に収まります。

​
Webスケールのモニターを作成する

Webスケールのモニターは、ページモニターと同じ方法で作成します。違うのは、ターゲット (type: "search" を使用し、queries、searchWindow、maxResults、および任意のドメインフィルターを指定) と、URLがない点だけです: 
from firecrawl import Firecrawl

firecrawl = Firecrawl(
  # モニター エンドポイントには API key が必要です:
  api_key="fc-YOUR-API-KEY",
)

monitor = firecrawl.create_monitor(
    name="AI coding assistant launches",
    schedule={"text": "every 30 minutes", "timezone": "UTC"},
    goal="Alert when a new open-source AI coding assistant is announced. Ignore funding rounds and unrelated AI news.",
    targets=[
        {
            "type": "search",
            "queries": ["open source AI coding assistant launch"],
            "searchWindow": "24h",
            "maxResults": 10,
        }
    ],
    notification={
        "email": {
            "enabled": True,
            "recipients": ["alerts@example.com"],
            "includeDiffs": True,
        }
    },
)

print(monitor.id)
一致する新しい結果が見つかると、monitor.page webhook はそれを status new で報告し、judging が実行された場合は、なぜ重要なのかを示す judgment も返します:
monitor.page
{
  "success": true,
  "type": "monitor.page",
  "id": "019df960-5f2a-75fb-a98b-bd2d32ca67d4",
  "webhookId": "f1e2d3c4-0000-0000-0000-000000000000",
  "data": [
    {
      "monitorId": "019df960-06e7-7383-9d89-82c0113dc31a",
      "checkId": "019df960-5f2a-75fb-a98b-bd2d32ca67d4",
      "url": "https://news.ycombinator.com/item?id=40000000",
      "status": "new",
      "error": null,
      "isMeaningful": true,
      "judgment": {
        "meaningful": true,
        "confidence": "high",
        "reason": "A new open-source AI coding assistant was announced, which matches the monitor goal."
      }
    }
  ],
  "metadata": {
    "environment": "production"
  }
}

​
良いゴールとクエリの書き方

Webスケールのモニターの品質は、役割の異なる2つの要素で決まります。
  • queries は再現率を左右します: 各検索で何を拾うかを決めます。狭すぎると本当に重要な出来事を取り逃し、広すぎると judge がノイズの絞り込みに クレジット を使うことになります。
  • goal は適合率を左右します: 取得した結果のうち、実際にどれをアラートにするかを決めます。judge は新しい結果をすべてゴールに照らして評価するため、本当に一致するものと、話題は合っているが重要ではないものを分けるのはゴールです。
両方を調整してください。どれほど完璧なゴールでも、queries が取得しなかった結果にはアラートできません。また、広すぎる queries に曖昧なゴールを組み合わせると、価値の低いアラートが絶えず発生します。 良いクエリは、文章ではなく検索語のように書きます:
  • 文章ではなくキーワードを使います: OpenAI new model release とし、tell me when OpenAI releases a new model にはしません。
  • 複数語の固有表現は引用符で囲み (\"Llama 4\") 、同義語は OR でまとめます (launch OR release OR announcement) 。
  • 各クエリは簡潔に保ちます (2〜6語程度) 。通常は、狭いクエリをいくつも作るより、少し広めのクエリを1つ使うほうが効果的です。クエリを増やしてもカバレッジが広がらないまま、maxResults の枠だけが分散されることが多いためです。
  • 異なる 主題ごとに1つのクエリを使います。1つの主題に複数の側面 (「発表、ベンチマーク、ドキュメント」) があっても、クエリは1つです。分けるのは、ゴールが本当に別々の対象を挙げている場合だけです (たとえば「OpenAI、Anthropic、Google」) 。
  • site: / -site: 演算子はクエリに入れないでください。代わりに includeDomains / excludeDomains を使ってください。
良いゴールは、一致条件を平易な言葉で示し、除外は意図の一部である場合にだけ追加します:
  • 対象と、一致と見なす条件を明示します: “OpenAI がまったく新しいモデルを発表したときにアラートする。”
  • 多義語は明確にします: “Firecrawl (the web scraping API)” と書けば、judge が消火機器の話題を拾わずに済みます。
  • Ignore ... は、意図に照らして除外すべきものにだけ追加します: “Ignore opinion pieces, tutorials, and unrelated AI news.” 一般的なノイズをわざわざ書き直す必要はありません。書式の違い、追跡用パラメータ、再インデックスによる揺れは、judge がすでに処理します。
  • 意図が広いなら、そのまま広く保ちます。ゴールを厳しく絞りすぎると、本来一致すべきものまで抑えてしまいます。
健全なモニターの状態。 うまく調整された Webスケールのモニターは、ほとんど何も報告しません。大半のチェックは new: 0 を返し、本当に新しく、かつゴールに合致するものが現れたときだけアラートが発生します。適切に調整できているかどうかは、チェックの要約と各結果の searchStatus を見れば判断できます (ステータスと重複排除 を参照) 。
  • ignored の結果がコンスタントに出るなら、queries がノイズを拾い、それをゴールが後から弾いている状態です。queries を絞るか searchWindow を狭めて、どうせアラートにならない結果の判定にコストを払わないようにしてください。
  • watching が頻繁に出るなら、ゴールが曖昧です。一致条件をもっと明確にして、judge が判断を確定できるようにしてください。
  • 活発な話題なのに結果ゼロの状態が長く続くなら、queries が狭すぎるか searchWindow が短すぎます。語句を広げるか、ウィンドウを広げてください。
  • ユーザーが却下するアラートが出るなら、ゴールが広すぎます。意図に応じた Ignore ... を追加してください。
目指すべきは、十分な再現率を確保しつつ高い適合率を実現することです。つまり、すべてのアラートに対応する価値があり、本当に重要なものは見逃さない状態です。

​
判定

各チェックが結果ごとにどこまで処理を行うかは、モニター の judgeEnabled で制御されます。これは、ゴールと判定 で説明されているものと同じフラグです。判定を有効にすると、Firecrawl は一致した各結果をスクレイピングし、その内容をゴールに照らして評価します。この場合、search 呼び出しに加えて、判定対象の結果 1 件ごとに 1 クレジット が課金されます。judgeEnabled: false の場合、Webスケールのモニター は AI による判定を行わず、重複を除いた 検索結果 を返します。つまり、新しい SERP ヒットのみを返し、課金されるのは search-call クレジット のみです (10 件ごとに 2 クレジット) 。

​
ステータスと重複排除

検索結果では、スクレイピングモニターやクロールモニターと同じページレベルのstatus列挙値を使用するため、既存のwebhookやcheck-resultのコンシューマーは変更なしでそのまま動作します。検索結果は次のいずれかに対応します。
  • new: 初めてゴールに一致した結果です。これがアラート対象になります。
  • same: 以前のcheckですでに確認された結果です (新しいアラートはありません) 。
  • error: 評価できなかった結果です (たとえば、judging用のスクレイピングがスキップされた場合) 。
より細かな検索結果の判定は、各ページのmetadata.searchStatusで公開され、次のいずれかになります。
searchStatusPage statusMeaning
alertnewjudgeが意味のあると判断した新しい結果です。通知を送信します。
already_seensameフィンガープリントが以前のcheckの結果と一致しました。
watchingsamejudgeがまだ十分な確信を持てていない新しい結果です。追跡はされますが、アラートは送られません。
ignoredsamejudgeがゴールにとって意味がないと判断した新しい結果です。
skippederrorこのcheckではjudgeできなかった結果です (たとえば、スクレイピングの失敗やjudging機能の低下) 。
結果は、初めてnewとして現れたときに一度だけアラートされます。重複排除のキーは正規URLのみです (titleとsnippetは意図的にフィンガープリントに含まれていないため、title/snippetが変わっても再通知はされません) 。キーがURLであるため、現実世界の1つの出来事が複数の記事URLで報じられた場合、アラートは出来事ごとに1回ではなく、URLごとに1回発生します。 モニターのgoalまたはqueriesを編集すると、goalVersionが更新され、以前のjudgeの判定は無効になります。再評価は一括で再judgeするのではなく、遅延的に行われます。既存の結果が一度にまとめて再judgeされることはありません。代わりに、各結果は次回のcheckで再び現れたときに再judgeされ、その時点で新しいgoalVersionが適用されます。再浮上しない結果は、再び現れるまで古い判定とgoalVersionを保持します。

​
共通の構成

  • スケジュール: cron または自然言語で指定する間隔。最短 5 分です。
  • ゴールと判定: judgeEnabled: false でない限り、検索ターゲットでは必須です。
  • 通知: webhook とメールで配信します。
  • チェック結果: 各チェックとその結果を確認します。
  • 料金: チェックごとに結果 10 件あたり 2 クレジット、加えて判定済みの結果 1 件あたり 1 クレジット。