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

ドメイン全体クロールと LLM 向け整形

Crawl API で Markdown / HTML / JSON を横断出力し、LLM 学習・RAG の前処理に使う。

Crawl API

KPI 例

  • 対象 URL 数
  • 抽出成功率
  • トークン効率

LLM や RAG に渡す前提のデータ収集では、1 ページずつ手で URL を並べるより、サイトやドメイン単位でクロールする設計に寄せたほうが管理しやすくなります。Crawl API は、広く巡回したうえで Markdown / HTML / JSON の出力を選べる点が、通常の単発取得 API と違います。

誰の課題か

  • ドキュメントサイトやメディアサイトをまとめて収集し、RAG の元データにしたい AI エンジニア
  • サイト構造や公開範囲を俯瞰したい SEO 担当や監査担当
  • URL 単位の取得ではなく、クロールジョブとして管理したいデータ基盤チーム

単発の HTML 取得で足りるなら Web Unlocker で十分です。Crawl API は、対象が複数ページに広がり、ジョブ管理や後処理まで見据える段階で選びます。

推奨製品セット

製品役割このページでの使い方
Crawl APIドメイン単位のクロールURL 群または起点 URL からジョブを作る
API Access認証方式Bearer トークンでジョブ起動・状態確認を行う
  • 出力は Markdown を第一候補にし、HTML や JSON は必要になったときだけ追加します。
  • クロール結果は即時レスポンスに閉じず、ジョブ単位で追跡する前提で設計します。

最小実装イメージ

ジョブを作成して Markdown 出力を指定する

curl -X POST https://api.brightdata.com/v1/crawl/jobs \
  -H "Authorization: Bearer $BRIGHTDATA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "urls": [
      "https://example.com/docs/getting-started",
      "https://example.com/docs/authentication"
    ],
    "output": "markdown"
  }'

ジョブ ID を受け取ったら、状態確認と結果取得を分けます。クロール系では、呼び出し直後に全結果を待ちきる設計より、この形のほうが安定します。

Python でジョブ完了を待って結果を保存する

import os
import time
import requests
 
API_KEY = os.getenv("BRIGHTDATA_API_KEY")
BASE_URL = "https://api.brightdata.com/v1/crawl/jobs"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}
 
create = requests.post(
    BASE_URL,
    headers={**HEADERS, "Content-Type": "application/json"},
    json={
        "urls": [
            "https://example.com/docs/getting-started",
            "https://example.com/docs/authentication",
        ],
        "output": "markdown",
    },
    timeout=60,
)
create.raise_for_status()
job_id = create.json()["job_id"]
 
while True:
    status = requests.get(f"{BASE_URL}/{job_id}/status", headers=HEADERS, timeout=60)
    status.raise_for_status()
    state = status.json()["status"]
    if state == "completed":
        break
    if state == "failed":
        raise RuntimeError(f"crawl job failed: {job_id}")
    time.sleep(10)
 
result = requests.get(
    f"{BASE_URL}/{job_id}/result?format=markdown",
    headers=HEADERS,
    timeout=120,
)
result.raise_for_status()
 
with open("crawl_results.md", "w", encoding="utf-8") as f:
    f.write(result.text)

まずは Markdown だけで下流の評価を回し、必要になったら HTML や JSON を追加する順番が安全です。

運用ポイント

  • クロール対象の範囲は、起点 URL と保存単位を最初に決めます。対象が曖昧なまま広げると、コストもノイズも増えます。
  • ジョブ ID、実行時刻、出力形式を必ず残します。RAG の品質差分を後から追うには、この単位が必要です。
  • LLM 向け用途では Markdown が扱いやすい一方、監査や再解析では HTML が必要になることがあります。出力形式は用途で分けます。
  • 大量ジョブを同期的に待ち続けず、状態確認や後続処理を非同期に寄せたほうが安定します。
  • 取得範囲、保持期間、削除条件はクロール前に決めます。広く集められる API ほど、運用ルールを先に固める必要があります。

関連リンク