0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

PR: Disnana
Disnana公式サイト
About Promotions
@harupython
in

スクレイピングは「取れた」で終わらない。Bright Dataの料金と保護機能を調べてみた

0
Posted at

こんにちは、PythonHaruです。

Webページを取得して、必要な情報を抜き出す。スクレイピングの処理を一言で説明すると、これだけです。

ところが、継続して動かす前提で考えると、話が変わってきます。JavaScriptで後から表示される情報をどう扱うか。アクセスが失敗したら何回まで再試行するか。取得先の構造が変わって、必要な項目だけ欠けたときに気付けるか。こうした問題は、HTTP通信が成功することとは別に残ります。1

欲しいのはデータなのに、気付けば収集基盤の保守が仕事になっている。

しかも、安定して取得できれば終わりではありません。取得先への負荷や、集める情報の扱いまで考える必要があります。

そこで今回は、Bright Dataを「どれだけ取れるサービスなのか」だけでなく、どこまで運用を任せられるのか、いくらから試せるのか、どんな保護機能があるのかという視点で調べました。

初めて名前を聞いた人にも、「名前は知っているけど、自分には大げさでは？」と思っていた人にも、選択肢を整理する材料になればうれしいです。

Bright Dataは、何を代わりにやってくれるのか

Bright Dataは、公開Webデータの取得に使うAPIや、クラウド上のブラウザ、プロキシなどを提供しています。単一のスクレイピングツールというより、取得処理のどの部分を任せたいかに応じて選ぶサービス群です。2

代表的な製品を、開発者側に残る作業と一緒に並べると分かりやすくなります。

やりたいこと 製品 自分で担当する主な部分
ページを取得し、必要な項目は自分で抜き出す Web Unlocker API HTMLなどの解析、抽出項目の設計、保存処理
クリックやスクロールを含む取得処理を動かす Browser API Playwrightなどを使う操作・抽出ロジック
対応サイトのデータを決まった項目で受け取る Web Scraper API 対応項目の確認、受け取ったデータの検証・活用
検索エンジンの結果を取得する SERP API 検索条件の設計、結果の整理・活用

この整理は、各製品の公式説明に基づきます。Browser APIはPlaywright・Puppeteer・Seleniumとの連携が案内されており、Web Scraper APIは対応サイト向けの抽出処理をサービス側で保守する位置付けです。3456

例えばWeb Unlocker APIは、プロキシの切り替え、CAPTCHA対応、取得時の再試行などを引き受けます。一方、取得したHTMLから独自の項目を抜き出す処理は、利用者側に残ります。35

ここは大事な違いです。

「ページ取得を任せる」と「抽出処理の保守まで任せる」は、同じではありません。

個人開発で気になる料金。まずは月5,000クレジットから

2026年10月1日の公式案内では、新規アカウントに毎月5,000クレジットの無料枠があり、開始時のクレジットカード登録は不要です。7

ただし、ここは「各製品で5,000回ずつ無料」と読み違えやすいポイントです。

無料枠は対象製品で共有します。Web Unlocker APIとSERP APIは1リクエスト＝1クレジットですが、Web Scraper APIはレコード単位、Scraper Studioはページロード単位、Browser APIは通信量に応じて消費します。MCP経由の対象利用も別枠ではなく、同じ無料枠を使います。プロキシ製品自体は、この月次無料枠の対象外です。8

無料枠を超えたら、どのくらいかかる？

Web Unlocker APIとSERP APIの標準的なPay as you goの公開単価は、どちらも1,000リクエストあたり1.50米ドルです。96

以下は、月5,000クレジットをこの2製品だけに使い、標準単価で利用する場合の試算です。「リクエスト数」は、無料・有料の利用量に計上される回数として計算しています。

月間リクエスト数 無料枠を超える分 従量利用料の試算
5,000回 0回 0米ドル
10,000回 5,000回 7.50米ドル
30,000回 25,000回 37.50米ドル
100,000回 95,000回 142.50米ドル

計算式は max(0, 月間リクエスト数 - 5,000) × 1.50 / 1,000 です。

税、為替・決済手数料、他製品の利用料などは含めていません。また、これは利用料の計算であり、アカウントへの入金額そのものではありません。無料枠には適用条件があり、個別単価のPAYGプランや月額コミット型プランは対象外とされています。8

料金表では成功リクエストへの課金が案内されていますが、設定による例外もあります。例えばSERP APIでは、カスタムヘッダー・Cookieを選択すると失敗リクエストも課金対象になるため、単価だけでなく課金条件の確認も必要です。910

この金額なら、少なくとも「最初から高額な月額契約をしないと触れないサービス」と考える必要はありません。一方、件数が増えれば利用料も増えるので、どの用途でも安いとまでは言えません。

無料で試すときも、課金の境目は見ておく

公式説明では、入金していないアカウントは無料枠を使い切るとリクエストが停止します。入金済みなら、その残高を使う従量利用に移ります。8

有料利用に進むなら、自動チャージの設定も確認が必要です。PAYGでは、自動チャージを使わない設定も案内されています。11

私なら最初は、コード側にも取得件数の上限を置きます。無料枠や料金設定とは別に、「この処理は何件で止まるのか」を自分で説明できる状態にしておくためです。

無料枠で試すなら、このくらいのコードから始められる

Web Unlocker APIは通常のHTTP APIなので、Pythonならrequestsだけでも呼び出せます。公式のAPI仕様では、https://api.brightdata.com/requestへAPIキーとZone名、対象URLを送ります。12

import os
import requests

API_URL = "https://api.brightdata.com/request"
API_KEY = os.environ["BRIGHTDATA_API_KEY"]
ZONE = os.environ["BRIGHTDATA_WEB_UNLOCKER_ZONE"]

# 自分で取得条件を確認できるURLに置き換える
targets = [
    "https://example.com/",
    "https://www.iana.org/help/example-domains",
]

for url in targets:
    response = requests.post(
        API_URL,
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "zone": ZONE,
            "url": url,
            "format": "raw",
        },
        timeout=60,
    )

    print(url, response.status_code, len(response.content))
    response.raise_for_status()

これだけなら、Bright Data側に任せているのはページ取得までです。返ってきたHTMLからタイトルや価格を抜き出す処理、保存先、重複排除などは別に書きます。だからこそ「どこまで任せる製品なのか」がコードでも分かりやすいです。

試すときは、ローカル側でも「何URL投げたか」を数えておきます。そのうえでControl Panelの対象Zoneに表示される利用量・コストも確認します。Bright DataはZone単位の利用状況を管理画面で確認でき、現在は公式CLIからbrightdata budgetやbrightdata budget zonesで残高・Zone別消費を見る方法も案内しています。13

コード側の回数と管理画面側の消費が想定どおり動くかを、最初の数リクエストで確認してから件数を増やす。この一手間だけでも、「気付いたら想定以上に使っていた」はかなり防ぎやすくなります。

「安いか」は、API料金だけでは決まらない

自前実装とサービス利用を比べるなら、次のように分けて考えると整理しやすくなります。

自前運用：実行基盤の費用 ＋ 実装・保守・障害調査に使う時間
サービス利用：APIなどの利用料 ＋ 連携実装 ＋ 自分に残る運用

これは比較の考え方であって、Bright Dataを入れれば何時間減る、という実測結果ではありません。

例えば、週に数ページだけ確認する社内ツールで、対象が静的HTML・構造もほぼ変わらないなら、requestsとBeautiful Soupで十分です。公式APIやRSSが用意されているなら、なおさらスクレイピングサービスを挟む理由は薄くなります。

逆に、毎日多数のURLを見る、JavaScriptの描画が必要、CAPTCHAやブロックへの対応が頻繁に発生する、失敗時の再試行やプロキシの状態確認に時間を使っている――このあたりから「自前の方が無料」という見方が怪しくなります。サーバー代が安くても、毎月人間が障害調査に時間を使えば、その時間も運用コストだからです。

もう一つ分かりやすいのが、個人開発の価格監視です。10商品を1日1回見るだけなら、自前で十分なケースが多い。一方、数百〜数千URLを継続的に監視し、取得失敗も自動で吸収したいとなると、取得基盤そのものが一つのシステムになります。そこで初めて、API料金と保守時間を並べて比較する意味が出ます。

APIの1回が安いかだけでなく、何を自分の担当から外せるのかを見る。

ただし、抽出・保存・データ品質の確認まで全部なくなるわけではありません。前の製品表で「自分に残る部分」を分けたのは、このためです。5

「取れる」だけでなく、「止める」仕組みも見る

今回、料金と同じくらい気になったのが、この部分です。

技術者倫理というと少し大きな話に聞こえますが、ここでは「取得先に無理をさせない」「非公開情報を取りに行かない」「他人の通信資源を勝手に使わない」といった、設計上の具体的な配慮として考えます。

以下はBright Dataが公開している仕様・運用方針の整理であり、私が保護機能の効果を独立に検証した結果ではありません。

禁止用途があり、利用目的の確認もある

Bright DataのAcceptable Use Policyでは、ログインの裏側にある非公開情報の収集、DDoS、スパム、広告・クリック詐欺、偽アカウント作成などが禁止されています。一部のコンテンツをサービス側で遮断する方針も明記されています。14

また、Residential Proxiesでは、企業情報や利用目的を確認する、人によるKYC審査が必要とされています。Web Unlocker APIなどとは開始条件が異なるので、「登録すれば全製品を同じ条件で使える」というわけではありません。15

同社は、申告された用途と実際の利用のずれを監視し、必要に応じて調査する運用も説明しています。16

「何でも自由に取得できること」だけを売りにしているわけではなく、用途を制限する方針がある。この点は、サービス選定で確認したい材料です。

取得先への負荷を検知し、アクセスを抑える

Bright Dataの公開説明には、取得先の応答状況と自社ネットワークからのトラフィックを監視し、両者に応答悪化との関連が見られた場合、レート制限を適用する仕組みが記載されています。17

私が面白いと思ったのは、ここが「アクセスを通す技術」だけの話ではないことです。取得先への影響を見て、アクセスを抑える側にも自動化を使っている。

もちろん、これを理由に利用者側で無制限に並列化してよいわけではありません。取得頻度を抑え、重複取得を減らす設計と、サービス側の保護を重ねて使うべきです。

また、Browser APIのエラー一覧には、robots.txtによる制限を示す brob、Bright Data側の制限を示す brul が掲載されています。18

こうしたエラーが出たら、単に回数を増やして再試行するのではなく、まず取得対象や利用条件を見直します。制限の適用範囲は製品や審査状態などによるため、全製品が一律に同じ動作をするとまでは言えません。1815

通信を中継する人の同意も、選定材料になる

Residential Proxyを評価するなら、通信の中継元がどう集められているかは外せない確認項目です。

これはBright Dataに限った話ではありません。FBIは2026年3月の注意喚起で、住宅プロキシのIPには、端末所有者が同意して提供しているものと、本人が把握しないまま利用されているものの両方があると説明しています。無料VPNなどの規約に分かりにくく組み込まれるケースも例示されています。19

つまり「住宅IPだから危険」「大手サービスだから全部安心」と単純化するのではなく、IPがどのような同意プロセスで集められているかを確認すること自体が重要です。

Bright Dataは、SDKを通じたネットワーク参加について、明示的な同意後の有効化、参加をやめる手段、参加条件の説明などを公開しています。20

これは同社の説明に基づく評価材料であり、私が全ての参加アプリを監査したという意味ではありません。それでも、価格やIP数だけでなく、その通信資源を使う前提が説明されているかは重要な選定材料です。

ただし、「使えば自動的に合法」ではない

保護機能を評価することと、法的な判断を丸ごと任せることは、分けて考える必要があります。

Bright Data自身の利用規約でも、適用法令や第三者の権利に反する利用は禁止されています。サービスを利用できることは、対象データの取得・保存・再配布について、必要な権利や許可がすべてそろっていることを意味しません。14

特に、公開されている情報なら、何に使ってもよいわけではありません。

日本の個人情報保護委員会は、インターネットなどで既に公表されている個人情報も、他の個人情報と区別せず保護の対象とすると説明しています。21

robots.txtについても、RFC 9309は、そこで示されるルールがアクセスの認可そのものではないと明記しています。したがって、robots.txtの記載だけを、取得や再利用に関する判断のすべてにはできません。22

私なら、対象サイトの規約・提供API、必要な取得範囲、個人情報を含むか、保存後に誰が何に使うかを、利用前に整理します。権利関係や法的判断が難しい用途は、対象サイトへの確認や専門家への相談も検討します。

Bright Dataの保護機能は、こうした判断を不要にするものではなく、運用上の制限や監視を追加するものとして捉えるのが適切です。

使うべきかどうかは、「自前で困っている場所」で決める

ここまで調べると、最初から全面移行を考えるより、今の構成で負担になっている場所を探す方が自然です。

公式APIやデータ配布があり、必要な条件を満たせるなら、まずそれを検討する。小規模な自前処理で十分なら、無理に新しいサービスを増やさない。

一方、ブラウザ基盤の管理や取得失敗への対応が重くなっているなら、その部分だけを任せる構成を考える。必要な項目を返す既製スクレイパーがあるなら、抽出処理の保守も含めて比較する。製品ごとの役割分担を見ると、こうした選び方ができます。45

実際に試すなら、自分が管理するページや取得条件を確認できた対象を選び、少数のURLと低い並列数から始めます。そのうえで、通信の成功だけでなく、必要項目の欠損、重複、取得時刻、消費量まで確認します。

エラー時に止められるか、想定外のデータを保存しないか、無料枠をどれだけ使ったか。そこまで見て、初めて自分の用途に合うか判断できます。

なお、無料枠のアカウントでも、管理画面からサポートチケットを作成できると案内されています。仕様が判断しにくいときに、問い合わせ先がある点も確認できました。8

まとめ：全部自前で抱える前に、任せる範囲を考える

Bright Dataを調べてみると、単に「スクレイピングできるサービス」と見るだけでは、選定材料を拾いきれません。

取得処理のどこを任せるのか。自分の件数ではいくらになるのか。取得先や通信の中継元を守るために、どんな制限や運用が説明されているのか。その一方で、利用者側に何が残るのか。

自分で実装できることと、自分で運用し続けるべきことは、同じではありません。

データを取る仕組みそのものが目的でないなら、全部を自前で抱える前に、どこまで任せられるかを一度調べる価値があります。

引用元

以下はいずれも2026年10月1日確認。製品・価格・制限は変更される可能性があるため、利用時には最新の公式案内とアカウントの適用条件を確認してください。

  1. Bright Data Docs, Modern scraping operations. 自前運用の作業範囲を整理する参考として使用。ベンダーによる性能・費用の比較値は本稿には採用していません。 ↩

  2. Bright Data Docs, Bright Data documentation. ↩

  3. Bright Data Docs, Web Unlocker API overview. ↩ ↩2

  4. Bright Data Docs, Introduction to Bright Data's Browser API. ↩ ↩2

  5. Bright Data Docs, Scraper API vs DIY scraping. 製品の分担・制約を参照。比較の成功率や所要時間は採用していません。 ↩ ↩2 ↩3 ↩4

  6. Bright Data, SERP API Pricing. ↩ ↩2

  7. Bright Data Docs, Create your first Web Unlocker API. ↩

  8. Bright Data Docs, Free tier. ↩ ↩2 ↩3 ↩4

  9. Bright Data, Web Unlocker API Pricing. ↩ ↩2

  10. Bright Data Docs, SERP pricing & billing. ↩

  11. Bright Data Docs, Payment. ↩

  12. Bright Data, OpenAPI Specs: AI Integration with SERP & Unlocker APIs. POST https://api.brightdata.com/request、Bearer認証、zone・url・formatの指定を確認。 ↩

  13. Bright Data, Bright Data CLI: Extract Web Data from Your Terminal. Control PanelのZone管理と、brightdata budget / brightdata budget zonesによる利用状況確認を参照。 ↩

  14. Bright Data, Acceptable Use Policy. ↩ ↩2

  15. Bright Data Docs, Residential network access policy. ↩ ↩2

  16. Bright Data, Know Your Customer Compliance. ↩

  17. Bright Data, Bright Data Brightbot Crawler — Protective Tech. ↩

  18. Bright Data Docs, Browser API error codes. ↩ ↩2

  19. Federal Bureau of Investigation, Evading Residential Proxy Networks: Protecting Your Devices from Becoming a Tool for Criminals, 2026-03-12. ↩

  20. Bright Data, A transparent view of Residential IP sourcing. ↩

  21. 個人情報保護委員会, Q1-5：新聞やインターネットなどで既に公表されている個人情報は、個人情報保護法で保護されるのですか。. ↩

  22. RFC Editor, RFC 9309: Robots Exclusion Protocol, Section 1. ↩

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?