Bright Data ジオターゲティング設定ガイド 2026 - 国・都市レベルの地域指定を実践解説

Bright Data で「特定の国や都市の IP からアクセスしたい」を実現するのがジオターゲティングです。結論から言うと、設定の大半はプロキシのユーザー名に -country-jp -city-tokyo のようなパラメータを足すだけで完結します。本稿では、国・州・都市・郵便番号・ASN という粒度別の指定方法を早見表で整理し、東京・大阪を例にした実践手順、価格調査やローカル SERP 検証での使いどころ、そしてつまずきやすい注意点までを実運用目線でまとめます。

なぜ地域別 IP が必要なのか

Web 上の情報は「どこからアクセスしたか」で変わります。価格・在庫・広告・検索結果は地域ごとに出し分けられており、東京の自宅回線から見える Amazon の価格と、ニューヨークから見える価格は別物です。自社のオフィス回線だけで調査すると、その 1 地点の見え方しか取れません。

そこで地域別の出口 IP を持つプロキシが必要になります。Bright Data は 195 か国・4 億超 (400M+) 規模の Residential IP プールを持ち、ユーザー名パラメータひとつで「ロンドンの家庭回線」「大阪の家庭回線」といった出口を選べます。地域別の見え方を機械的に集めたいときに、もっとも実装コストが低い選択肢のひとつです。

ジオターゲティングが効くプロキシタイプ

地域指定は主に Residential / Mobile / ISP プロキシで意味を持ちます。家庭回線やモバイル回線の実 IP を地域単位で割り当てられるためです。Datacenter プロキシでも国指定は可能ですが、都市レベルの精度や検知耐性は Residential に劣ります。

検知耐性・速度・コストのどのプロキシを選ぶかは、地域指定とは別軸の判断になります。Residential と ISP の使い分けは Residential と ISP プロキシの使い分けガイド で三軸整理しているので、地域調査の前段としてあわせて確認してください。

ビジネスでの価値

地域別 IP を「技術者の道具」と捉えると過小評価しがちですが、実態はマーケティングと事業判断の道具です。競合の地域別プライシング、ローカル広告の出稿状況、配送可否の地域差といった、現地に行かないと分からない情報を在宅で継続的に取得できます。海外進出前の市場調査や、国内でも地域キャンペーンの効果測定に直結します。

粒度別パラメータ早見表

Bright Data のジオターゲティングは、プロキシのユーザー名に粒度別のパラメータをハイフンで連結して指定します。専用の管理画面や API 呼び出しを覚える必要はなく、接続文字列に追記するだけで切り替わるのが扱いやすい点です。ベースとなるユーザー名は次の形式です。

brd-customer-<CUSTOMER_ID>-zone-<ZONE_NAME>

ここに地域パラメータを足していきます。粒度が細かいほど対象 IP プールは小さくなる点だけ先に押さえておいてください。

パラメータの連結ルール

複数の条件は単純にハイフンで連結します。たとえば「東京の家庭回線で、同一 IP を維持しながら巡回する」場合は次のようになります。

brd-customer-xxxxxxxx-zone-myzone-country-jp-city-tokyo-session-a1b2c3

-country- と -city- は組み合わせるのが基本です。都市だけを指定して国を省くと意図しない国の同名都市に当たることがあるため、-country-jp-city-osaka のように国とセットで書くのが安全です。

エンドポイントとポート

接続先ホストは brd.superproxy.io、ポートはダッシュボードの Access parameters タブに表示される値を使います。現行ドキュメントでは HTTP のポートとして 33335 が案内されています¹。なお、古い時期に作られたアカウントでは lum-customer- プレフィックスや別ポートが割り当てられている場合があるため、必ず自分のダッシュボードの表示値を正としてください。

東京・大阪で試す実践手順

ここでは日本国内の地域差を取る最小構成を示します。Zone がまだない場合は先に作成が必要です。用途別の Zone 分割や認証情報の取り回しは Proxy Zone の設計と作成ガイド に手順をまとめているので、初回はそちらを参照してください。

1. ダッシュボードで Residential ゾーンを 1 つ用意し、Access parameters でホスト・ポート・パスワードを控える
2. ユーザー名に -country-jp-city-tokyo を付けて東京の IP でリクエスト
3. 同じ URL を -country-jp-city-osaka に変えて再取得
4. 2 つのレスポンス (価格・表示・在庫) を突き合わせて差分を確認

curl で地域を切り替える

最小限の確認は curl 1 行で済みます。ユーザー名の都市部分を差し替えるだけで出口が変わります。

# 東京の IP で取得
curl --proxy brd.superproxy.io:33335 \
  --proxy-user "brd-customer-xxxxxxxx-zone-myzone-country-jp-city-tokyo:PASSWORD" \
  "https://example.com/product/123"

-city-tokyo を -city-osaka に変えれば大阪の IP になります。まずはこのレベルで「都市を変えるとレスポンスが変わるか」を体感するのが理解への近道です。

Python (requests) での例

繰り返し取得や差分比較を自動化するなら、requests で都市をループさせます。コードの詳細解説は本稿の範囲外ですが、骨子は「プロキシ URL の都市部分を差し替えて回す」だけです。

import requests

cities = ["tokyo", "osaka"]
for city in cities:
    user = f"brd-customer-xxxxxxxx-zone-myzone-country-jp-city-{city}"
    proxies = {
        "http":  f"http://{user}:PASSWORD@brd.superproxy.io:33335",
        "https": f"http://{user}:PASSWORD@brd.superproxy.io:33335",
    }
    r = requests.get("https://example.com/product/123", proxies=proxies, timeout=30)
    print(city, r.status_code, len(r.text))

ユースケース別の活用

地域指定が活きる代表的なシーンを整理します。いずれも「現地の見え方を機械的に集める」という共通点があります。

地域別の価格・在庫調査

同一商品の価格が地域や通貨でどう変わるかを継続的に追うのは、地域指定の王道用途です。東京と大阪、あるいは日本と米国で同じ商品ページを取得し、表示価格・送料・在庫表示の差分を蓄積します。為替や地域キャンペーンの影響を、自社の 1 地点だけでは見えない解像度で把握できます。

ローカル SERP・ローカル広告の検証

Google のローカルパックや地域ターゲティング広告は、検索した場所によって出し分けられます。地域指定プロキシで同じキーワードを東京・大阪から検索すれば、ローカル枠の順位や表示される店舗・広告の違いを取得できます。検索結果を構造化 JSON で安定取得したい場合は、生 HTML を自前で解析するより SERP API を Python で実装するガイド の方式が運用は楽です。地域指定と SERP API は組み合わせて使えます。

地域限定コンテンツ・到達性の確認

配送可否・在庫・地域限定ページの出し分けや、ジオブロックされたコンテンツへの到達性確認にも使えます。「東京では配送可能、地方では不可」といった地域差を、UI を目視するのではなくレスポンスから機械的に判定できます。

弊社では、Bright Data の Residential プロキシを使ったホテル価格追跡サービス Tra-bell を自社で運用しており、地域別の価格取得は日常的に扱っています。同様の地域別データ収集基盤の設計・PoC・運用までは要件次第でご相談可能です。

つまずきやすい注意点

最後に、運用に入ってから気づきがちな落とし穴をまとめます。

粒度を下げすぎると失敗率が上がる

都市・ASN・郵便番号まで絞ると、条件に合致する IP プールが小さくなります。プールが小さいほど同一 IP の再利用が増え、再試行や失敗が増えて結果的に転送量 (= コスト) が膨らむことがあります。ジオターゲティング自体に追加料金はかからず、課金は通常どおり転送量 (GB) ベースです²。国レベルで目的が達成できるなら都市指定は使わない、というのが無駄を抑える基本姿勢です。粒度はあくまで「必要最小限」で設計してください。コスト最適化の全体像は別途検討する価値があります。

指定どおりの地域か必ず検証する

パラメータを付けたつもりでも、対応外の都市名で国レベルにフォールバックしていることがあります。本番に乗せる前に、IP ジオロケーション判定ページへ数リクエスト投げ、返ってくる国・都市が指定どおりかを必ず確認してください。価格調査では、判定ページに加えて対象サイトの表示通貨・言語が地域に整合しているかも見ると取りこぼしを防げます。

スクレイピングの法務・倫理

地域別データの取得は、対象サイトの利用規約と各国の法令の範囲内で行うのが前提です。具体的には以下を守ってください。

• 対象サイトの利用規約・robots.txt を確認する
• レート制限を超える負荷をかけない
• 個人情報を扱う場合は個人情報保護法 / GDPR / CCPA に配慮する

地域をまたぐとデータ保護法制も変わるため、海外サイトを対象にする場合は特に慎重に範囲を定めてください。

まとめ

Bright Data のジオターゲティングは、プロキシのユーザー名に -country-jp -city-tokyo といったパラメータを足すだけで国・都市レベルの地域指定ができる、実装コストの低い機能です。粒度は country → state → city → zip → asn の順に細かくなり、細かくするほど対象 IP プールは小さくなります。まずは国 + 都市の組み合わせから始め、対応値はダッシュボードで確認し、指定どおりの地域かを検証してから本番に乗せる——この順序を守れば、地域別の価格・SERP・在庫の調査を低コストで仕組み化できます。

※情報は 2026-05-31 時点の内容です。最新情報は公式サイトをご確認ください。

※本記事には PR を含みます。