Web情報の収集ツールを出力から選ぶFirecrawl・Apify・Browse AIの比較

ここで想定するのは、競合の料金ページ20件を集め、毎週プラン名と価格の変更を確認する仕事です。最初に決めるのは、AIへ本文を読ませてメモを作るのか、表計算の価格欄を自動更新するのかです。

本文取得なら、見出しや注記を含むMarkdownなどが役立ちます。一方、表の更新には、価格、通貨、支払い周期が決まった欄に入る必要があります。ページ全体を取得できたことは、正しい行を取り出せたことと同じではありません。

以下は公開ページを対象にした選び方です。ログインが必要なサイト、個人情報、アクセス制限の回避は比較の前提にしません。対象サイトの利用条件や取得頻度を確認し、必要な情報だけを扱います。

比較表は2026年9月5日に確認した公式情報に基づきます。Firecrawlの短い公開試用は次の節に分け、三製品の成功率や速度を同条件で測った比較とは区別します。

2026年9月5日、FirecrawlのPlaygroundでScrapeを選び、公開サンプルのexample.comを入力しました。出力形式はMarkdownです。実行後は履歴にSuccessと表示され、見出しの「Example Domain」、説明文、Learn moreのリンクが返りました。元のページを別タブで開いて照合すると、表示された本文とリンク先は一致していました。

未登録の画面では、出力の下に全文の閲覧にはアカウント作成が必要という案内も出ました。今回確認したのは画面に表示された短い出力です。三製品の同条件比較、表の抽出、日本語の動的ページ、繰り返し取得の安定性は試していません。画面に表示されたトークン削減率も独自には検算していないため、採用理由には使いません。

この試用からは、本文をAIへ渡す入口としての出力を確認できました。料金一覧を集めたい場合は、次にプラン名、通貨、月額、年払い条件を必須列として同じページを三製品へ渡し、空欄や取り違えを比べる必要があります。

各社とも機能が広がっているため、「Firecrawlは本文だけ」「Browse AIはコードを使えない人だけ」と固定すると、実際の選定を狭めます。比較するのは、公式機能と導入後に自分が管理する部分です。

Actorは、サイトや用途ごとの取得処理を実行する単位です。Apifyという基盤の料金と、選んだActor固有の料金・保守状況は分けて確認します。人気のActorでも、自分が必要とする項目、地域、ログイン条件に対応しているとは限りません。

Firecrawlにも構造化抽出や変更検出があり、Browse AIにもAPIがあります。選定で効くのはAPIの有無だけではなく、対象のページから必要な形へ変換するまで、誰が設定し、失敗時に誰が直すかです。

料金ページの「19ドル/月」が、月払い料金か年払いの月額換算かで比較結果は変わります。無料期間の価格や、最低人数を条件にした単価もあります。価格だけを抜くのではなく、適用条件を別の欄に残します。

次の表は架空の料金表示を使った出力設計の例です。三製品の実際の取得結果ではありません。

Browse AIのJSONでは、価格なども文字列として返る場合があります。JSONで出力されることと、数値や日付の型まで揃っていることは別です。ApifyもActorごとに出力形式が異なるため、後段の表に入れる前に確認します。

Firecrawlの構造化抽出を使う場合も、指定した形で返ったことだけを正解の証拠にはしません。元の表示と照らし、通貨と契約期間が正しいか、存在しない項目を推測で埋めていないかを確かめてください。

変更監視では、取得できた本文が最新かどうかも重要です。FirecrawlのScrapeにはキャッシュの利用期間を指定するmaxAgeがあり、公式APIの既定値は2日です。新しい表示を取りに行く用途なら、キャッシュの条件を明示して設計します。変更検出のChange Trackingが保存する比較用スナップショットは、このレスポンスキャッシュとは別です。

次に、取得した値を前回と比較する前に、必須項目を確認します。価格が取れなかった場合に空欄を0へ変換すれば、「値下げしました」と誤通知するおそれがあります。最後に確認できた値はそのまま残し、取得失敗の通知を別に出す方が原因を追いやすくなります。

これは編集部が提案する安全側の更新ルールで、各製品が自動で同じ処理をするという意味ではありません。既存の監視機能やWebhookの通知を使う場合も、通知内容が「取得に失敗した」のか「値が変わった」のかを確認します。

20ページ×4回なら、予定する確認は80回です。ただし、ページを取得する回数と、表の行数、AI抽出、再試行の費用は同じではありません。次は通常の公開ページを一回ずつ取得する単純な机上計算です。Firecrawlは通常のScrapeのみ、Browse AIは1ページを1タスクとして最低1クレジットで実行する条件に限定します。PDF分割、追加のAI抽出、画像取得、追加料金の生じる再試行は含めません。

Apifyの計算単位CUは、割り当てたメモリ量と実行時間から決まります。1GBを1時間使えば1CUです。コードが同じでも、ページの待ち時間やメモリ設定で消費が変わるので、対象Actorの小さな試用結果を見積もりの起点にします。

Browse AIは標準サイトで10行につき1クレジット、タスクの最低消費は1クレジットという説明です。Premiumサイトには倍率があり、少ない行でも消費が増えます。取得できた行数だけでなく、実行履歴の消費を記録してください。

2026年9月5日に確認した米ドルの表示です。年払いの月額換算と月払い、月次クレジットと年次クレジットを区別しています。税や地域、追加利用分は契約画面で確認します。

Browse AIの年払い月額換算19ドルと月払い48ドルは、付与される量も異なる契約です。単に「年払いなら同じ内容が安い」とは扱えません。年次クレジットをいつ使えるか、更新時や解約時の扱いも確認します。

今回の80回をBrowse AIの最低単価で扱っても、無料50クレジットでは足りません。さらに20ページが三つ以上のサイトに分かれるなら、無料の対象サイト数も制約になります。Firecrawlで通常の取得80クレジットが無料枠に収まっても、必要な抽出や連携まで無料とは限らない点は同じです。

保存も料金とは別の確認項目です。Apifyの名前を付けていないデータセットは通常7日で失効するため、長期の比較履歴を残したいなら、名前付きの保存先や自分の管理する表への転記を設計します。

最初は対象を二ページに絞り、本文と構造化データを保存します。プラン名、価格、通貨、支払い周期を人が読み、出力と一致するか確認してください。正常な一回だけでは、継続収集の可否は分かりません。

1. 同じページを再取得し、重複行を作らないかを確認します。
2. 自分が管理するテストページで料金を変え、変更が検出されるかを見ます。
3. 価格欄を消し、0円への更新ではなく欠損として扱われるかを確かめます。
4. 表示順を変え、別のプランの価格を拾わないかを試します。
5. エラー通知を受けた担当者が、元の表示と取得履歴から原因を追えるかを確認します。

他社のサイトを変更して試すのではなく、自分のテストページか保存したサンプルで失敗を再現します。再試行回数にも上限を置き、取れないページを繰り返し要求し続けない設計にします。

取得できた項目、欠損時の扱い、消費、修正担当は、Web収集の比較・運用シートへ記入してください。3サービスの比較表も、候補を並べる際に使えます。最初に取れたかだけでなく、来月ページが変わったときに直せるかまでを採用条件にしてください。