Lv3

応用

Scraper API・Data Feeds・非同期ジョブ・Webhook を取り入れる。

目安 8–16 時間／前提: Lv2 修了、非同期処理とキューの概念理解

Lv3 は、Bright Data を単発呼び出しの道具ではなく、継続的なデータ供給基盤として扱う段階です。ここでは Scrapers と Data Feeds を理解し、同期リクエストから非同期ジョブへ移り、Webhook や外部ストレージとつなぎます。Lv2 の「1 本の API を選べる」状態から、Lv3 では「件数が増えても壊れにくい流れを設計できる」状態を目指します。

前提

達成基準

Scrapers と Data Feeds の違いを説明できる
同期取得ではなく非同期ジョブに切り替える判断ができる
Webhook の役割と冪等処理の必要性を理解している
snapshot やジョブ ID を保存して後続処理につなげられる
外部ストレージ連携を前提に結果保存の流れを設計できる
parsing drift を検知する観点を持てる
Data Feeds を「収集の代替」ではなく「供給モデル」として理解している

代表ユースケース

推奨ハンズオン

Step 3 で広域収集、Step 4 で既製データ活用を触ると、Lv3 の輪郭がつかみやすくなります。

Scrapers と Data Feeds の違い

項目	Scrapers	Data Feeds
主眼	特定サイトの構造化抽出	整備済みデータの継続供給
使い方	API を呼んで対象を指定する	配信モデルに乗せる
向く場面	Amazon、YouTube など個別サイト	定期配信、下流パイプライン連携
出力	構造化 JSON	JSON / NDJSON / CSV

この違いを言い換えると、Scrapers は「対象サイトがはっきりしている収集」、Data Feeds は「必要なデータを供給として受ける運用」です。

実装パターン 1: 非同期ジョブ起動

Lv3 では、ジョブを起動して完了を待つのではなく、後で受け取る形に慣れることが重要です。

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/a"},
    {"url":"https://example.com/b"}
  ]'

この時点での実務ポイントは次のとおりです。

ジョブ起動レスポンスから ID を保存する
その場で全文結果を待たない
後続処理は Webhook かポーリングで拾う

実装パターン 2: Webhook 受信の最小形

非同期ジョブを使うなら、受信側を最小でも用意します。

export async function POST(request) {
  const payload = await request.json();
  console.log("bright-data-webhook", payload);
  return new Response("ok", { status: 200 });
}

Lv3 では、まずこの程度で十分です。次に足すべきは次の 3 点です。

重複受信を弾く idempotency key
署名検証
payload をそのままログ保存しない運用方針

外部ストレージ連携の考え方

ジョブ件数が増えると、アプリケーションメモリやローカルファイルだけでは回りません。Lv3 では、最低でも「どこに保存するか」を決めます。

典型パターン

Bright Data でジョブを起動
完了通知を受ける
結果をストレージへ保存
DB やベクトル DB、検索インデックスへ流す

保存時の観点

生データを残すか
正規化後データだけ残すか
Markdown と JSON のどちらを主にするか
同一対象の世代管理をどうするか

RAG 用なら Markdown が扱いやすいことが多く、分析パイプラインなら JSON / NDJSON が扱いやすいです。

parsing drift を前提にする

Lv3 では、取得成功率だけでは不十分です。HTML は取れていても、欲しいフィールドが欠けることがあります。これが parsing drift です。

最低限の検知方法

商品名や価格の欠損率を見る
取得件数の急減を見る
前日との差分が不自然に大きい時に通知する

対策

自前パーサを使う対象は、サンプルを保存して比較する
既製 Scrapers がある対象は、なるべくそちらを使う
変更頻度の高いサイトは Browser API か Scrapers に寄せる

Lv3 の判断基準

API を増やすより、流れを整える

Lv2 までは API 選定が中心でした。Lv3 では、どの API を選んだかより、「ジョブ起動から保存、再処理までの流れ」が重要になります。

1 件処理と 10,000 件処理は別物

単発の成功例をそのまま拡大しないことが重要です。レート制御、保存、冪等、再試行の設計が必要になります。

Lv3 を終える判断

次の状態なら Lv4 に進めます。

非同期ジョブを前提に設計できる
Webhook と保存処理の責務を分けられる
Scrapers、Data Feeds、Crawl の使い分けができる
データ取得後の後処理を考えられる

次に学ぶこと

Lv4 では、ここまでの取得基盤を AI 実践へつなぎます。MCP、Agent Web Access、RAG、評価系ユースケースを通じて、「取る」から「引用付きで答える」へ進みます。