UC-FEED-001Data FeedsLv3

660+ プリビルトスクレイパー活用

用意済みのスクレイパーを活用し、ゼロから実装せずに構造化データを得る。

Scraper APIData Feeds

KPI 例

対象ドメイン数
更新頻度
工数削減

対象サイトごとに HTML 解析やブロック対策を自前で抱えると、最初の取得より保守のほうが重くなりがちです。このユースケースでは、Bright Data が提供する 660+ のプリビルトスクレイパー を入口にして、必要なフィールドを構造化データとして受け取る前提に切り替えます。単発の取得確認は Scrapers、継続供給まで含めるなら Data Feeds を組み合わせるのが基本です。

誰の課題か

特定ドメインの価格、商品属性、レビュー、動画情報を継続取得したいデータエンジニア
スクレイパーの新規開発ではなく、分析用データを早く揃えたいアナリスト
HTML 変更のたびに抽出コードが壊れる運用から抜けたいチーム

典型的な痛みは、「対象ごとに別実装が必要」「自前パーサの修正が続く」「取得はできても下流に流し込みにくい」の 3 点です。既製 Scrapers を使うと、取得対象と出力スキーマを先に固定しやすくなります。

推奨製品セット

製品	役割	このユースケースでの位置づけ
Scrapers	特定サイト向けの既製抽出 API	まずここで対象サイトがカバーされているか確認する
Data Feeds	継続的なデータ供給	単発取得で要件が固まった後に接続する
API Access	サーバー実装向け認証	`Authorization: Bearer <API_KEY>` で呼び出す

「取得対象が既に Scrapers にある」なら、Unlocker や Crawl より先に検討します。
「毎回自分でジョブを起動したくない」なら、Data Feeds まで含めて設計します。
認証方式は API Access を前提にすると、アプリやバッチへ組み込みやすくなります。

最小実装イメージ

まずは 1 件だけ非同期ジョブを起動し、返ってきた snapshot_id を保存して後段処理につなぎます。ジョブ起動自体は、この学習サイト内の Lv3 コンテンツでも使っている datasets 系の流れに寄せると理解しやすくなります。

curl -X POST https://api.brightdata.com/datasets/v3/trigger \
  -H "Authorization: Bearer $BRIGHTDATA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '[
    {"url":"https://example.com/product/123"}
  ]'

実際にどの Scraper を使うか、どの dataset_id が割り当たるかは、対象ごとの設定画面で確認します。
最初から大量投入せず、1 件でレスポンス形式と snapshot_id の扱いを確認してから件数を増やします。
継続供給に進む場合は、同じ取得結果を Data Feeds 側の運用に載せる構成を取ります。

運用ポイント

既製 Scrapers がある対象に対して、先に自前 HTML 解析を書かないことが重要です。保守コストの主因がそこにあるためです。
API キーは USER か OPS を使い、ADMIN をジョブ実行に使わないようにします。
snapshot_id は結果取得の基点なので、ジョブ起動直後に保存します。再実行時に前回結果と混同しないことが重要です。
Data Feeds に進む前に、必要なフィールド、更新頻度、保存先、欠損時の扱いを決めます。ここが曖昧だと継続供給に移した後で設計をやり直すことになります。
robots.txt や利用規約の確認は取得後ではなく、対象ドメインを採用する時点で行います。

誰の課題か

推奨製品セット

最小実装イメージ

運用ポイント

関連リンク