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

認証（ビジネス向け）

Bright Data をビジネス用途で安全に使い始めるために、API キー、利用窓口、権限分離の考え方を平易に整理したガイド。

Bright Data を業務で使い始めるとき、最初に押さえるべきことは 3 つだけです。誰が使うのか、どの用途で使うのか、どこまでの権限を渡すのかです。ここを最初に整理しておくと、あとで「請求が見えない」「本番と検証が混ざった」「強すぎる権限を配ってしまった」を避けやすくなります。

ビジネスユーザーの感覚で言えば、Bright Data の認証は「AI ツールや自動化ツールに渡すログイン情報の管理」です。個人の試用なら 1 本で始められますが、チーム運用では用途ごとに分けるほうが安全です。

一次情報: Authentication | Bright Data Docs

まず知っておきたい全体像

API Access と Native Access の認証フロー比較 — 同じ料金で用途別に使い分ける

認証の考え方ビジネス向けに言うと主な使いどころ
API AccessAI ツールや自動化ツールに渡す API キー（パスワード相当）Claude Desktop、Dify、n8n、社内ワークフロー
Native Access代理アクセス用の 接続情報一式プロキシ対応ツール、既存の収集基盤、外部ベンダー連携
  • どちらを選んでも、基本の課金レートは同じです。
  • ビジネス用途では、まず API Access を選ぶと迷いにくいです。
  • 既存のツールや委託先が「プロキシ接続前提」なら Native Access も使います。

API Access

API Access は、Bright Data を AI やノーコード自動化から呼び出すための標準的な入口です。技術用語では Bearer トークンですが、このサイトでは API キー と考えてください。

どんな場面で使うか

  • Claude Desktop に Bright Data を接続するとき
  • Dify の HTTP リクエストノードから呼ぶとき
  • n8n で定期実行フローを組むとき
  • 社内の AI アシスタントに Web 調査機能を持たせるとき

業務でのメリット

メリット現場での意味
AI ツールとの相性がよい自然言語の指示で調査や要約までつなげやすい
期限や権限を分けやすい部門別、用途別に安全に配布できる
失効や入れ替えを管理しやすい退職・異動・外注切替時の事故を減らせる

最初の設定イメージ

技術的にはヘッダーに認証情報を付けますが、ビジネスユーザーは次の理解で十分です。

  1. Bright Data で API キーを発行する
  2. Claude Desktop や Dify の設定画面にそのキーを登録する
  3. 「この用途専用の利用窓口」を指定して使う

たとえば Claude Desktop なら、Claude Desktop で Bright Data を AI に持たせる の設定で API キーを 1 回登録すれば、その後はチャットだけで使えます。

API キーの発行と運用

  • アカウント作成時に デフォルトの API キー が発行されます。
  • 追加キーは管理画面の API tokens から作成します。
  • キーは 生成直後に一度だけ表示されます。社内の安全な保管先に残してください。
  • Refresh を使うと新しいキーに切り替わり、古いキーはすぐ無効になります。
  • API キーを作成できるのは 管理者アカウント です。

権限モデル

Bright Data の API キーには権限の強さがあります。考え方は「誰にどこまで操作させるか」です。ビジネス用途では、強い権限を日常運用に使わないことが重要です。

API キー権限モデル ピラミッド — ADMIN / FINANCE / OPS / LIMIT / USER の責任範囲と日常運用での使われ方

権限できること向いている人
ADMIN請求、設定、利用のすべて管理者。日常運用では使わない
FINANCE請求や残高の確認経理、管理部門
OPS設定変更と利用運用担当、AI 推進担当
LIMIT一部の接続制御接続ルールだけを触る担当
USER日常的な API 利用現場の自動化、AI ツール接続

ビジネス部門向けのおすすめ

  • 個人の試用: USER
  • チームの Dify や n8n 運用: USER または OPS
  • 経理確認専用: FINANCE
  • 最高権限の保管: ADMIN

ADMIN は「金庫の鍵」です。Claude や n8n に直接入れず、人間の管理者だけが保管する前提で考えてください。

有効期限とローテーション

API キーには期限を付けられます。無期限にもできますが、ビジネス運用では 期限あり を勧めます。

なぜ期限を付けるか

  • 退職や異動があっても放置されにくい
  • 使われていない古いキーを整理しやすい
  • 万一の漏えい時に被害期間を短くできる

実務の目安

  • 個人 PoC: 30 日から 90 日
  • チーム本番運用: 90 日で定期見直し
  • 外部パートナー向け: 期限を短めに設定

Native Access

Native Access は、Bright Data を 代理アクセス用の接続先 として扱う方式です。プログラマー向けにはプロキシ認証と呼ばれますが、ビジネス向けには「既存ツールに接続情報を渡して別の IP からアクセスさせる仕組み」と考えるとわかりやすいです。

どんなときに必要か

  • 既存ベンダーが「プロキシ情報をください」と言っている
  • すでに動いている収集ツールの設定だけ差し替えたい
  • ブラウザを遠隔で動かす系の外部ツールを使う

知っておくべき要素

項目ビジネス向けに言うと
ACCOUNT_ID自社アカウントの識別番号
PRODUCT_NAME利用窓口の名前。作成後は変えにくい
PROXY_PASSWORD接続用パスワード

この方式は、AI ツールより 既存の技術運用 に向いています。新しく始めるなら、まず API キー方式で十分です。

どちらを使うかの判断フロー

以下に当てはまるなら API Access を優先してください。

  • Claude、ChatGPT、Dify、n8n から使いたい
  • 週次レポートや定期調査を自動化したい
  • 部門ごとにキーを分けて管理したい
  • 将来、完了通知や「投げて待つ」処理に広げたい

以下に当てはまるなら Native Access を検討してください。

  • 既存ツールが代理アクセス前提でできている
  • 外部の開発会社や運用会社に接続情報を渡す
  • HTML の取得部分だけ Bright Data に置き換えたい

セキュリティ運用の 5 原則

  1. 最小権限: ふだん使いは USER か OPS に絞ります。
  2. 期限を付ける: 無期限運用を前提にしません。
  3. 職務を分ける: 経理と運用と管理者でキーを共有しません。
  4. 安全な保管: Notion の公開ページやメール本文に貼りません。
  5. 用途ごとに分ける: 検証用、本番用、外部委託用を分けます。

よくある業務パターン

個人でまず試す

  • 認証: API Access
  • 権限: USER
  • 予算感: 数百円から数千円の PoC で開始
  • 使い方: Claude Desktop か Dify に 1 本登録

チームで共有運用する

  • 認証: API Access
  • 権限: 現場用は USER、管理側は OPS
  • 予算感: 月数千円から数万円を目安に利用窓口ごとに管理
  • 使い方: Dify や n8n でワークフロー化

既存の技術基盤に載せる

  • 認証: Native Access または併用
  • 権限: 運用担当が集中管理
  • 予算感: 件数と対象サイト数で変動
  • 使い方: 外部ベンダーや情報システム部門と連携

セルフチェックリスト

  • API キー方式で始めるか、接続情報方式で始めるか決めた
  • 本番と検証で分ける前提を決めた
  • 最高権限を日常運用に使わない方針にした
  • キーの保管場所を決めた
  • 期限と更新ルールを決めた

次に読む

プログラマー向けの詳細