AI 実践

Lv4 は、Bright Data を AI ワークフローへ接続する段階です。ここで重要なのは、単に Web から取ることではありません。検索、抽出、ブラウザ操作、引用、評価を AI エージェントから呼べる形にすることです。MCP を入り口にすると、Claude や Cursor、社内エージェントから同じ取得基盤を使い回せます。

前提

• ロードマップ Lv3
• 基礎 / API グループ
• 基礎 / 運用
• Step 6 MCP + AI エージェント連携

達成基準

• MCP の役割を説明できる
• Agent Web Access と通常 API 呼び出しの違いを理解している
• エージェントから検索と抽出を呼び出せる
• 引用付き回答のために元データと回答を分離して扱える
• RAG で Markdown 出力を活用できる
• 取得品質と回答品質を別々に評価する観点を持てる
• LangChain、Haystack、Weaviate などの外部基盤に接続する設計を説明できる

代表ユースケース

• UC-AI-001 Agent Web Access
• UC-AI-003 Deep Research
• UC-AI-004 Answer Engine
• UC-DEV-003 MCP Server で AI クライアント接続

推奨ハンズオン

• Step 6 MCP + AI エージェント連携
• Step 3 Crawl API で RAG データ収集

MCP で接続し、Crawl API で集めた Markdown を下流に渡す流れまで見えると、Lv4 の全体像がはっきりします。

MCP をどう位置づけるか

MCP は、Bright Data の各 API を AI クライアントから扱うための接続面です。SERP、Unlocker、Browser、Crawl を、エージェントが必要に応じて使い分けるための橋渡しと考えるとわかりやすいです。

MCP が向く場面

• 人間が自然言語で調査を指示する
• AI エージェントに Web 検索や引用付き回答をさせる
• 取得ロジックをアプリ実装ではなくツール接続として持ちたい

MCP だけでは足りない場面

• 取得結果を厳密に ETL したい
• 大量ジョブをスケジュールで回したい
• コスト制御や SLA を API レベルで細かく組みたい

実装パターン 1: MCP の接続設定

Lv4 の最小構成は、AI クライアントに Bright Data MCP を登録することです。

{
  "mcpServers": {
    "brightdata": {
      "command": "npx",
      "args": ["@brightdata/mcp"]
    }
  }
}

実際の設定値は利用クライアントや実行環境で変わりますが、Lv4 では「MCP サーバーを 1 つ登録し、AI から呼べるようにする」という考え方を押さえれば十分です。

実装パターン 2: RAG 前提のデータ整形

AI 実践では、取得そのものより「LLM が読みやすい形」に整えることが重要です。Crawl API の Markdown 出力は、そのまま RAG に流しやすい形式です。

documents = [
    {
        "source": "https://example.com/docs/start",
        "content": markdown_text,
    }
]
 
for doc in documents:
    print(doc["source"])
    print(doc["content"][:500])

Lv4 では、完全なベクトル検索基盤を作る必要はありません。まずは「URL と本文をセットで保持し、回答時に引用できる形にする」ことが重要です。

評価の観点

AI 系の実装では、取得品質と回答品質を分けて見ます。

取得が成功しても、回答が引用を失えば品質は下がります。逆に、回答が自然でも根拠 URL がなければ運用しにくくなります。

フレームワークとのつなぎ方

Lv4 では、Bright Data 単体で完結するより、AI フレームワークの入力源として使うことが増えます。公式 Blog でも LangChain、Haystack、Weaviate との連携例が案内されています。

代表的な接続先

• LangChain: 検索と取得をツール化しやすい
• Haystack: 検索、抽出、回答のパイプラインに載せやすい
• Weaviate: Crawl で集めた文書をベクトル検索へ流しやすい

接続時の実務ルール

• 取得レイヤーと生成レイヤーを分ける
• 引用 URL を必ず保持する
• 同じ問い合わせで無駄に再取得しない

Lv4 で使う外部一次情報

実装時は、次の一次情報を併読すると理解が速いです。

• MCP overview
• Agent Web Access
• LLM Grounding
• LangChain 連携の公式 Blog
• Weaviate 連携の公式 Blog

Docs では概念、Blog では実装の勘所を見る、という分担で読むと効率的です。

Lv4 でよくある落とし穴

すべてをエージェント任せにする

MCP は便利ですが、取得基盤そのものを不要にするわけではありません。再利用するデータ、非同期で回すジョブ、定期供給データは引き続き設計が必要です。

HTML をそのまま大量投入する

RAG や評価系では、Markdown や構造化 JSON のほうが扱いやすい場面が多いです。データ形式の選択も品質に影響します。

回答だけ見て裏側の取得を見ない

エージェントの挙動評価では、どの API を使い、何回呼び、どの URL を引用したかを追えるようにする必要があります。

Lv4 の到達イメージ

Lv4 を終える頃には、Bright Data は「スクレイピング API」ではなく、「AI が現実世界の最新情報へ触れるための接続面」として見えてきます。SERP、Unlocker、Browser、Crawl を個別に覚えるだけでなく、質問内容に応じてどの取得手段を選ぶかまで設計できる状態が目標です。

Lv4 を終える判断

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

• AI クライアントから Bright Data を呼べる
• 検索、抽出、引用の流れを説明できる
• 取得品質と回答品質を分けて評価できる
• RAG や Deep Research の基礎構成を組める

次に学ぶこと

Lv5 では、ここまで作った仕組みを本番運用へ寄せます。権限分離、期限ローテーション、監査ログ、SLA、コスト監視を通じて、AI とデータ収集の両方を安全に回せる形へ仕上げます。

• Lv5 運用
• 認証ガイド
• UC-AI-005 LLM Grounding