プログラマー向けモードで表示中ビジネスユーザー向けへ →
Bright Data 学習ポータル
UC-WEB-002Web AccessLv2Lv3

JS-heavy サイトのブラウザ自動抽出

Browser API でリモートブラウザを実行し、SPA やレンダリング後 DOM からデータを抽出する。

Browser API

KPI 例

  • セッション成功率
  • 1 ページあたり実行時間
  • 同時セッション数

HTML を 1 回取るだけでは必要な情報が出そろわないサイトでは、Browser API を使って実ブラウザに近い形でページを開く必要があります。特に SPA、無限スクロール、クリック後に出る詳細パネルのような UI は、最初から Browser API を前提にしたほうが判断が早くなります。

このサイトではカテゴリ名を Browser API としていますが、一次情報のクイックスタートは Scraping Browser として案内されています。ここでは同じ系統の製品として扱います。

誰の課題か

  • Playwright や Puppeteer の知識はあるが、対象サイトの保護や実行環境の維持で詰まりやすい開発者
  • 静的 HTML では取れず、レンダリング後の DOM から抽出したいチーム
  • ログイン後画面やページ内遷移を含む検証を、ローカル環境だけに依存せず再現したい運用担当

要件が「検索結果を JSON で欲しい」なら SERP API のほうが軽く、要件が「保護ページの HTML を 1 回取りたい」なら Web Unlocker のほうが単純です。Browser API は、そのどちらでも足りないときに選びます。

推奨製品セット

製品役割このページでの使い方
Browser APIリモートブラウザ実行Playwright から CDP 接続する
Native Access接続認証brd-customer-<ACCOUNT_ID>-zone-<ZONE_NAME>:<PASSWORD> を使う
Playwrightブラウザ操作コードDOM 抽出、クリック、待機の実装を担当する
  • Browser API は、API Access の /request を叩く形ではなく、CDP エンドポイントへ接続して使う場面が中心です。
  • 認証情報は Native Access の書式で管理します。

最小実装イメージ

Node.js + Playwright で接続して DOM を読む

export BRIGHTDATA_BROWSER_AUTH="brd-customer-<ACCOUNT_ID>-zone-<ZONE_NAME>:<PASSWORD>"
import { chromium } from "playwright";
 
const auth = process.env.BRIGHTDATA_BROWSER_AUTH;
const cdpUrl = `wss://${auth}@brd.superproxy.io:9222`;
 
const browser = await chromium.connectOverCDP(cdpUrl);
const context = await browser.newContext();
const page = await context.newPage();
 
await page.goto("https://example.com/spa", { waitUntil: "networkidle" });
 
const items = await page.locator(".item").allTextContents();
console.log(items);
 
await context.close();
await browser.close();
  • BRIGHTDATA_BROWSER_AUTH には、Dashboard の Access Details で確認した認証文字列を入れます。
  • 最初の抽出は locator(...).allTextContents() くらいに留め、クリックや無限スクロールは後から追加するほうが切り分けしやすくなります。

運用ポイント

  • Browser API は Web Unlocker や SERP API より重い前提で扱います。静的 HTML で足りるページまで広げないことがコスト管理の第一歩です。
  • zone 名はブラウザ用途と明示的に分けます。browser_login_flow や browser_catalog のように、用途が読める名前にしておくと運用しやすくなります。
  • waitUntil: "networkidle" は便利ですが万能ではありません。対象サイトによっては locator(...).waitFor() のほうが安定します。
  • セッション維持、ログイン、CAPTCHA 回避を一度に実装せず、まずは未認証ページで再現性を確認してから段階的に広げます。
  • 認証情報は API キーではなく Native Access の接続情報なので、パスワード再生成時の影響範囲を Runbook に残しておきます。

関連リンク