Bright Dataレビューと代替案：スクレイパーの移行

TL;DR:

• Bright Dataは2つの異なる製品を1つのエンドポイントでルーティングします。 Web UnlockerとSERP APIは両方ともhttps://api.brightdata.com/requestにPOSTします；リクエストボディ内のzoneのみがどちらが応答するかを決定します。したがって、ポーティングはホスト名を入れ替えるのではなく、ゾーンのデマルチプレクシングから始まります。
• ナイーブなポートで壊れる3つのことがあり、どれも役立つエラーを引き上げません。 認証ヘッダーが名前を変更し、レスポンスが生のマークアップではなくJSONの封筒として到着し、2つのサーフェスが異なるAPIバージョンに存在します。
• ブラウザの自動化は簡単な部分です。 両方の製品はCDPを使用しているため、PlaywrightやPuppeteerのコードは変更された接続URLでも生き残ります。認証情報はURLのユーザー情報からクエリパラメーターに移動します。
• デッドラインが質問を強制しています。 Bright DataのFAQによると、プロキシポート22225と33335の証明書は2026年9月25日に期限が切れ、呼び出し元はポート44445に移行する必要があります。すべての統合はそれまでにオープンされます。
• 無料で始める: Scrapelessダッシュボードは、ここで説明されたすべてのサーフェスに対して機能するキーを発行します。

Bright Dataとは

Bright Dataは、1つのプロキシネットワーク上に配置された別々のブランドの製品群としてウェブデータ収集を販売しています。スクレイパーコードを移行する際に重要なのはその3つです：

• Web Unlocker API — URLを指定すると、プロキシローテーション、フィンガープリンティング、チャレンジを処理し、ページを返します。
• SERP API — 検索エンジン向けに完全に構築された検索URLを渡すための同じリクエストパイプライン。
• Browser API — Playwright、Puppeteer、Seleniumを使用してChrome DevToolsプロトコル経由で操作するホスティングされたChrome。

重要な構造的事実、すなわちすべての移行を形作る要点は、最初の2つが同じHTTPエンドポイントであるということです。 Bright DataのWeb UnlockerドキュメントとそのSERP APIドキュメントによると、両方の製品はhttps://api.brightdata.com/requestにPOSTを受け入れ、zone、url、formatを携えています。zoneの値がコールをルーティングします。

Bright Dataにいると便利ですが、出ると不便です。なぜなら、あなたのコードベースにはおそらく構成文字列に依存するリクエストヘルパーが1つあるからです。

主な特徴

これらの3製品全体で、リクエストサーフェスは小さく、一貫しています：

• 認証はAuthorization: Bearer <key>として送信される単一アカウントAPIキーです。
• ルーティングはzoneによって行われ、ダッシュボードで設定され、リクエスト内ではなくなります。
• format: "raw"はターゲットのレスポンスボディを直接返します。
• ジオターゲティング、セッションピニング、モバイルユーザーエージェントは、-country-<code>や-session-<id>のようなサフィックスを使用してプロキシユーザー名内に表現されます。
• Browser APIはwss://<username>:<password>@brd.superproxy.io:9222で接続されます。Bright DataのBrowser API構成リファレンスによります。

製品と価格

Bright Dataは製品ごと、ゾーンごとに価格が設定されているため、単一のアカウントは通常、異なる料金と制限を持つ複数のゾーンを持ちます。このモデルが、移行がめったに一行の変更で済まない理由です：ゾーンは請求および構成の境界としても機能するため、そこから移動することはコストの帰属やルーティングに影響を与えます。

Scrapelessは1つのキーに対してリクエストで価格が設定され、呼び出すエンドポイントによってサーフェスが選択されるため、ダッシュボードオブジェクトによってではありません。両側の現在の価格はそれぞれの価格ページにあり、このガイドは価格を引用するのではなく、メカニクスをマッピングすることを意図しています。

パフォーマンスと適合性

Bright Dataのプロキシネットワークは大規模であり、その難しいターゲットに対するアンロック成功率がほとんどのチームが最初に採用する理由です。このガイドのどこにも製品が機能しないという主張はありません。

チームを動かすのは通常、技術的ではなく構造的です：漂流するゾーンごとの構成、特定の仕事に戻して請求するのが難しい請求、そして複数のゾーンを整合させるための運用オーバーヘッドです。それらが「コードのポート」という真剣な問題になる条件です。

Scrapelessの代替手段

Scrapelessは構成によってではなく、URLによって選ばれたサーフェス間で同じジョブを分割します：

• Universal Scraping API — POST https://api.scrapeless.com/api/v2/unlocker/requestでブロックされていないページを取得します。
• Scraper API — POST https://api.scrapeless.com/api/v1/scraper/requestでactorがターゲットサーフェスを命名し、解析されたフィールドでインライン応答します。
• Scraping Browser — wss://browser.scrapeless.com/api/v2/browserでのCDPエンドポイントで、キーはtokenクエリパラメーターとして渡されます。
  1つのキーがすべてをカバーします。ゾーンオブジェクトは存在せず、ダッシュボードのラウンドトリップを排除しますが、ポート中にコード内でデマルチプレクシングを行う必要があります。

Bright Dataがまだ優位に立っている場所

ポート後よりもBright Dataで実際に簡単に行える3つのこと：

• ゾーンモデルは、多くのジョブが1つのコールサイトを共有しており、デプロイなしで挙動を変更したいときに便利です。
• SeleniumはブラウザAPIに対してサポートされています。Scrapeless Scraping BrowserはCDP専用のため、Seleniumベースのスイートは再指示するのではなく、PlaywrightまたはPuppeteerに書き換える必要があります。
• -country-や-session-のようなプロキシユーザーネーム修飾子は、リクエストボディに触れることなくジオおよびセッションピニングを表現し、一部のコードベースはこれに大きく依存しています。

モデルがコストをもたらす場所

• 1つのエンドポイント、2つの製品は、静的分析が特定のコールが実際に何を行っているかをゾーンを解決せずに判断できないことを意味します。
• 設定はリポジトリの外に存在します。そのため、ゾーンの変更はコードレビューやgit blameには見えません。
• ポートと証明書の循環はあなたにかかります。 Bright Dataの一般的なFAQによると、22225と33335のポートにある古い証明書は2026年9月25日00:00 UTCに期限切れとなり、これらのポートにまだいる呼び出し元はその日までに44445ポートへの移行を完了する必要があります。

実装：コードのポート

これは他の移行の記事では省略される部分です。以下の各サブセクションは、明確なエラーではなく間違った結果を生じる実際の違いです。

エンドポイントとパラメータマップ

破損1：Authヘッダーが名前を変更

最も一般的な失敗した最初の試みは、ホストとキーを入れ替えますが、ヘッダーは保持します。Bright DataはAuthorization: Bearerを使用し、Scrapelessはx-api-tokenを使用します。古いヘッダーだけを持つリクエストは認証されず、失敗は認証情報の問題のように見え、ヘッダー名の問題とは思われません。

# Bright Data — illustrative, from the vendor's published example
curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${BRIGHTDATA_API_KEY}" \
  -d '{"zone":"YOUR_ZONE_NAME","url":"https://example.com","format":"raw"}' \
  https://api.brightdata.com/request

# Scrapeless — the same intent
curl -sS -X POST "https://api.scrapeless.com/api/v2/unlocker/request" \
  -H "x-api-token: ${SCRAPELESS_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"actor":"unlocker.webunlocker","input":{"url":"https://example.com","js_render":false}}'

破損2：レスポンスはエンベロープ

format: "raw"を使用すると、Bright Dataはターゲットのボディを返します。そのため、呼び出し元は一般的にresponse.textを行ってこれを解析します。ScrapelessはJSONオブジェクトで応答し、マークアップをdataに配置します。

URLとヘッダーのみを変更するポートは、JSON文字列をHTMLのように解析します。セレクターは何も返さず、例外は発生せず、ジョブは空の結果を記録します。修正は1行ですが、修正を行う方法を知っている場合のみです。

import os
import requests

KEY = os.environ["SCRAPELESS_API_KEY"]

def fetch(url: str, js_render: bool = False) -> str:
    """Return page HTML. The envelope is unwrapped here, once."""
    response = requests.post(
        "https://api.scrapeless.com/api/v2/unlocker/request",
        headers={"x-api-token": KEY, "Content-Type": "application/json"},
        json={"actor": "unlocker.webunlocker", "input": {"url": url, "js_render": js_render}},
        timeout=90,
    )
    response.raise_for_status()
    body = response.json()
    # Bright Data with format:"raw" would have given you this directly as response.text
    return body["data"]

html = fetch("https://example.com")
print(f"chars={len(html)} starts_with_doctype={html.lstrip().lower().startswith('<!doctype')}")

アンラップは1つのヘルパーに保持します。response.json()["data"]をコールサイトに散らばらせることは、コードベースの半分がポートされ、もう半分が静かにJSONを返す原因になります。

破損3：2つのサーフェスは異なるAPIバージョンにあります

これは、プロバイダーに1つのAPIがあると思い込んでいる人を捕まえます。アンロッカーサーフェスは**/api/v2/上にあります。Google検索アクターは/api/v1/**上にあります。検索アクターをv2パスに投稿するとHTTP 400 {"message":"unknown task type"}が返されます — これは不正なボディのように見えるメッセージであり、inputフィールドを検査することになりますが、実際の問題はバージョンセグメントです。

検索呼び出し自体は同期的です。解析された結果で1回のラウンドトリップで応答しますので、タスク識別子はなく、ポーリングループもありません。

import os
import requests

KEY = os.environ["SCRAPELESS_API_KEY"]

def search(query: str, gl: str = "us", hl: str = "en") -> dict:
    """Google SERP as structured JSON. Note the v1 path — the unlocker is v2."""
    response = requests.post(
        "https://api.scrapeless.com/api/v1/scraper/request",
        headers={"x-api-token": KEY, "Content-Type": "application/json"},
        json={"actor": "scraper.google.search", "input": {"q": query, "gl": gl, "hl": hl}},
        timeout=120,
    )
    response.raise_for_status()
    return response.json()

data = search("web scraping api")
print("sections:", sorted(data))
for row in data.get("organic_results", [])[:3]:
    print(f"  {row['position']}. {row['title'][:60]}")
    print(f"     {row['link']}")

ここでの大きな変更は、返される内容です。Bright DataのSERP APIはformat: "raw"を使用して検索エンジンのHTMLを手渡し、自分で解析します。Scrapelessはすでに解析されたページを返します — web scraping apiのライブコールはorganic_results、pagination、related_searches、search_information、metadataと返し、各オーガニック行はposition、title、link、snippet、source、favicon、redirect_link、snippet_highlighted_wordsを持ちます。

ポートに対する2つの結果。あなたのSERP HTMLパーサーはデッドコードになります — ポートするのではなく削除してください。そして、自分が所有するクエリストリングの構築も死亡します。なぜなら、クエリとロケールはinputに移動し、q、gl、hlとしてURLに組み込まれるのではなくなるからです。

破損4：ブラウザの資格情報が位置を移動

両方の製品はCDPを公開しているため、自動化コード自体は引き継がれます。変わるのは認証情報の位置です — Bright DataはURLのuserinfoに置き、Scrapelessはクエリパラメータに置きます。

import os
from playwright.sync_api import sync_playwright

# Bright Data (illustrative):
#   wss://<username>:<password>@brd.superproxy.io:9222
endpoint = f"wss://browser.scrapeless.com/api/v2/browser?token={os.environ['SCRAPELESS_API_KEY']}"

with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(endpoint)
    page = browser.new_page()
    page.goto("https://quotes.toscrape.com/", wait_until="domcontentloaded")
    print("title:", page.title())
    print("quotes on page:", len(page.query_selector_all(".quote")))
    browser.close()

この位置変更には計画が必要な運用上の影響があります。多くのロギングおよびトレーシングライブラリはURLのuserinfoを自動的に削除しますが、クエリ文字列はそのまま残すため、以前はデフォルトで隠蔽されていた接続文字列がログに表示され始める可能性があります。出荷前にtokenパラメータでフィルタリングしてください。

始める前にサイズについての二つの制約: Scrapeless Scraping BrowserはCDPのみを話すため、Seleniumスイートはリポイントではなく書き直しとなり、connect_over_cdpはリモートブラウザに接続するため、現在のコード内のlaunch()引数には宛先がありません。

機能する移行順序

1. ゾーンを在庫し、それぞれをアンロッカー型またはSERP型とラベル付けします。これはデマルチプレクスステップであり、唯一の真に手動の部分です。
2. まずアンロッカーパスをポートします — これはヘッダーの変更とエンベロープのアンラップが同じヘルパーで行われます。
3. 次にSERPパスをポートし、v1パスに切り替え、URLアセンブリとHTMLパーサーの両方を削除します。
4. ブラウザ自動化は最後にリポイントします; これは最小の差です。
5. 両方のスタックを同じURLリストに対して実行し、抽出されたフィールドを比較します。生のバイトではなくなります。フェッチ間でマークアップは無害に異なります; 抽出された値はそうであってはいけません。

クリーンに移行するユースケース

• 価格とカタログの監視 — アンロッカー型、一つのヘルパー、最高のボリュームと最も簡単な部分。
• ランク追跡とSERP監視 — 構造化されたフィールドを獲得し、URLアセンブリを失います。
• エージェントとRAG取得パイプライン — パースされたSERP出力は直接取得ステップに入ります。一つの解析ステージを追加するのではなく、削除します。

クリーンに移行できないケースはSeleniumベースのブラウザスイートで、上述の理由によります。それは同じスプリントに織り込むのではなく、別々に予算を組んでください。

価格比較

正直な比較は数値的ではなく構造的です。Bright Dataはコストをゾーンに帰属させるため、支出は設定オブジェクトでグループ化され、二つのゾーンを跨ぐジョブは二か所に表示されます。Scrapelessは一つのキーに対するリクエストにコストを帰属させるため、帰属は呼び出しを行ったコードパスに従います。

コストの可視性のために部分的に移行する場合、その違いは見出しレートよりも重要です。モデル化する前に、Scrapelessの価格ページとBright Data独自の価格ページの現在の数字を確認してください。

関連リソース

• 今もポーティングではなく選定中ですか？ Bright Dataのプロキシの代替品比較はフィールドを外観でランク付けしています。
• ユニバーサルスクレイピングAPI製品ページはアンロッカーの表面を完全に文書化しています。
• Chrome DevToolsプロトコルリファレンスは、両方のブラウザ製品が話すワイヤフォーマットをカバーしています。

結論

Bright Dataの移行は差分サイズが小さく、微妙に間違えるのが容易です。エンドポイントとキーは可視部であり、デバッグサイクルがコストを発生させるのは、一つのBright Dataエンドポイントが二つのScrapelessサーフェスにマッピングされ、そのボディがラップされて到着し、それら二つのサーフェスが異なるAPIバージョンに存在するからです。まずアンロッカーパスをポートし、エンベロープのアンラップを一つのヘルパーに保ち、カットオーバー時には生のHTMLではなく抽出されたフィールドの差分を比較してください。

あなたの統合が依然として22225または33335のポート上にある場合、どのプロバイダに最終的に移行してもカレンダー上の期限があります。それは9月下旬の時間的プレッシャーの下ではなく、故意に決定するのに適した瞬間です。

スクレイパーを移動する準備はできましたか？

Scrapelessダッシュボードにキーを作成し、すでに収集している1つのURLに対して上記のアンロッカーコードを実行します。抽出されたフィールドを現在の出力と比較することは、移行のほとんどの質問に答える15分のテストです。

FAQ

Q: Bright Dataの移行にはどれくらいの時間がかかりますか？

アンロッカーのみの統合の場合、数時間です: ヘッダーの変更、1つのヘルパーでのエンベロープのアンラップ、そして差分の実行です。SERPパスは通常予想よりも早く、書くコードよりも削除するコードが多いためです — HTMLパーサーとURLアセンブリの両方が削除されます。Seleniumブラウザスイートは例外で、それ自体でスコープを設定する必要があります。

Q: ゾーンを再作成する必要がありますか？
いいえ — 再作成するゾーンオブジェクトはありません。一つのキーがすべてのサーフェスをカバーします。作業はあなたのコードに移ります：各ゾーンはアンロッカー型またはSERP型として分類する必要があり、呼び出し元がどのエンドポイントにアクセスすべきかを知ることができます。

Q: 私のPlaywrightまたはPuppeteerのコードはまだ動作しますか？

はい。両方のプロバイダーはCDP WebSocketを公開しているため、オートメーションボディは変更なく引き継がれ、接続文字列のみが異なります。Seleniumは例外です：Scrapeless Scraping BrowserはCDP専用です。

Q: 移植したコードがエラーを発生させずに空の結果を返すのはなぜですか？

ほぼ常にレスポンスの封筒が原因です。Bright Dataのformat: "raw"はページの本文を返しますが、Scrapelessはdata内のマークアップを含むJSONを返します。封筒をHTMLとして解析すると、マッチが見つからず例外も発生しません。response.textをresponse.json()["data"]に変更してください。

Q: 2026年9月25日に何が起こりますか？

Bright DataのFAQによれば、ポート22225と33335の証明書はその日00:00 UTCに期限切れとなり、トラフィックはポート44445に移行する必要があります。これはBright Dataに留まることにも、去ることにも当てはまるため、どちらにせよ議論としてではなく、スケジュールの制約として扱ってください。

Q: 切り替え中に両方のプロバイダーを同時に実行できますか？

はい、そしてそれが推奨されるアプローチです。両方のパスを一つのインターフェースの背後に保持し、それぞれにサンプルトラフィックを送信し、抽出したフィールドを比較します。すべてを一度にではなく、ジョブごとに切り替え、最大ボリュームのアンロッカー作業から始めます。