スクレイピングのプロキシ選び【2026年】データセンター/住宅用/モバイルの使い分け
本記事はアフィリエイト/プロモーションを含みます。価格・仕様は2026年6月時点の目安です。最新は各公式サイトでご確認ください。
TL;DR
スクレイピングで弾かれる原因の多くはコードではなくIPの素性にあります。送信元IPの評判(reputation)が低ければ、ヘッダやTLSをどれだけ整えても入口で落とされます。
プロキシは大きくデータセンター・住宅用(Residential)・モバイルの3種。信頼度はこの順に上がり、価格も同じ順に上がります。低防御サイトはデータセンターで十分、Cloudflare等の高防御サイトは住宅用、最高難度はモバイル、というのが基本の使い分けです。自前でプール品質やローテーションを抱えたくない場合は、プロキシを内包したマネージドのスクレイピング基盤でAPI完結させる選択肢もあります。
本記事は技術解説です。スクレイピング対象の利用規約・robots.txt・著作権・個人情報保護法を遵守し、自社サイトの検証や許諾済みデータ取得など適法な範囲で利用してください。攻撃的・規約違反の用途は想定していません。Cloudflare等の検知レイヤー全体の突破設計はCloudflare防御を突破するスクレイピング環境の構築を参照してください。
なぜプロキシの「種類」で結果が変わるのか
アンチBot側は、リクエストの中身を見る前に送信元IPの素性でふるいにかけます。判断材料になるのは主に次の2つです。
- IPの所有者種別(ASN): そのIPがクラウド事業者・データセンター事業者のものか、ISP(家庭回線)のものか、モバイルキャリアのものか
- IP評判の履歴: 過去にそのIP(やレンジ)から不審なトラフィックが出ていないか
クラウドやデータセンターのIPは「人間が日常的にブラウジングする回線ではない」と既知レンジとして把握されており、それだけで信頼スコアが下がります。逆に家庭回線やキャリアのIPは、実在ユーザーと区別しにくいため信頼されやすい。プロキシの種類選びは、このIPの素性をどこまで本物の利用者に近づけるかの選択です。
プロキシ3種の違い
| 種別 | IPの出所 | IP評判 | 価格感 | 主な課金 | 向く対象 |
|---|---|---|---|---|---|
| データセンター(DC) | クラウド/DC事業者 | 低い(既知レンジ) | 安い | IP数/帯域 | 防御の薄い公開サイト・APIライクなページ |
| 住宅用(Residential) | 実在の家庭回線(ISP) | 高い | 高い | 帯域(GB)が主流 | Cloudflare等の高防御サイト |
| モバイル | キャリア回線(4G/5G) | 最も高い | 最も高い | 帯域(GB)が主流 | 最高難度・モバイル限定UI |
具体的なGB単価やプール内のIP数は各社・プランで大きく変動します。数値は必ず各社の公式ページで確認してください(本記事では断定しません)。
データセンタープロキシ
クラウドやデータセンターのサーバーに割り当てられたIPです。速くて安く、帯域も太いのが利点。一方でアンチBotにレンジを把握されやすく、高防御サイトでは入口で弾かれがちです。
向くのは、Bot対策が薄い公開ページ、社内システム、ステージング検証など。「まずDCで叩いて、弾かれたら上位種別に上げる」のがコストを抑える定石です。サブカテゴリとして、共有IP(複数ユーザーで共用・安いが汚れやすい)と専用IP(自分専用・評判を管理しやすい)があります。
住宅用(Residential)プロキシ
実在する家庭のインターネット回線(ISP割当IP)を経由します。アンチBotから見ると一般ユーザーのアクセスと区別しにくいため、信頼スコアが高い。Cloudflareやその他の商用Bot対策が入ったサイトでは、ここが現実的な主力になります。
代表的なプロバイダとしては Bright Data・Decodo・IPRoyal などの名前が挙がります(本記事では各社へのリンクは掲載していません。選定は各社の公式情報・規約・料金を直接確認してください)。住宅用は帯域(GB)課金が主流で、後述のとおり運用設計でコストが大きく動きます。
モバイルプロキシ
モバイルキャリア(4G/5G)のIPを経由します。キャリアは多数の実ユーザーを少数のIPでまとめる(CGNAT)構造のため、1つのIPの背後に大量の正規ユーザーが共存します。結果としてアンチBotはモバイルIPを安易にブロックしづらく、最も信頼度が高い。
その代わり最も高価で、帯域も住宅用より細い傾向があります。最高難度のサイトや、モバイル限定で出し分けされるコンテンツに絞って使うのが合理的です。
用途別の選び方
防御の強さに対して過剰な種別を使うと無駄に高くつき、不足すると弾かれます。対象サイトの防御レベルから逆算するのが基本です。
| 対象の防御レベル | 推奨種別 | 理由 |
|---|---|---|
| 防御なし〜薄い(素のサイト・公開API的ページ) | データセンター | 速く安い。弾かれにくい対象に高価な種別は不要 |
| 中〜高(Cloudflare等の商用Bot対策) | 住宅用 | DCレンジは弾かれる。実ユーザーに近いIPが必要 |
| 最高(住宅用でも落ちる・モバイル限定) | モバイル | CGNAT背景で最もブロックしづらい。コストは最後の手段 |
迷ったら安い種別から始めて、弾かれた段階で1つ上げる。最初からモバイルを全件に使うのは、ほぼ確実にコストの払い過ぎです。
ローテーション方式:ロータリーとスティッキー
同じIPで連続アクセスすると、頻度の異常から行動分析で捕まります。そこでIPを切り替える「ローテーション」を使いますが、方式は用途で選びます。
- ロータリー(rotating): リクエストごと、または短い周期でIPを変える。セッションが不要な一覧取得・大量並列向き。1つのIPに負荷を集中させない
- スティッキー(sticky): 一定時間(例:数分〜十数分)同一IPを維持する。ログイン状態・カート・多段フォームなどCookieとIPの一貫性が要る処理向き
実装上の目安です。
- セッション維持が不要ならロータリーで分散させる
- ログインや段階遷移が必要ならスティッキーでIPを固定し、Cookie・セッションを紐付ける
- どちらでも、リクエスト間に2〜5秒程度のランダム遅延を入れる。等間隔は機械的でかえって目立ちます
セッションの途中でIPが変わると、サイト側に「別人が同じセッションを使っている」異常として検知される点に注意してください。
実運用で踏みやすい落とし穴を3つ挙げます。
- 地域(ジオ)指定を忘れると、海外IPで日本向けサイトが言語・通貨を切り替えてしまう。プールの出口国を対象サイトの想定国に固定する
- スティッキーの保持時間とCookieの有効期間がズレると、処理の途中でIPだけ変わって「別人」と判定される。セッション保持時間はワークフローの所要時間以上に取り、IPとCookieの寿命を揃える
- 住宅用でも同一サブネットに偏ると、レンジ単位でまとめて弾かれる。プールの分散とBAN済みIPの混入具合はプロバイダの質に直結する(後述の選定基準)
課金モデルの落とし穴:GB課金は「読み込んだ全部」に乗る
住宅用・モバイルは帯域(GB)課金が主流です。ここで効いてくるのが、プロキシ経由で取得したデータ量すべてが課金対象という点です。
ブラウザを起動してページを開くと、HTMLだけでなくCSS・JavaScript・フォント・画像・トラッキングタグまで全部取得します。1ページが数MBに達することは珍しくなく、これがそのままGB課金に積み上がります。「HTMLのテキストだけ欲しいのに、画像とフォントで課金が膨らむ」という事故が典型です。
コストを抑える設計の勘所です。
- 不要リソースの読込を切る: 画像・フォント・解析タグなど、抽出に不要なリクエストはブロックする
- HTTPで済むならブラウザを使わない: JSチャレンジが不要な対象なら、ブラウザを起動せずHTTPクライアントで取得すれば転送量が激減します
- キャッシュ可能な静的アセットを毎回取らない: 同じCSS/JSを何百回も取りに行かない
なお具体的なGB単価は各社で変動するため、月の想定転送量 × 公式の単価で必ず試算してから契約してください。
転送量を絞る実装:リソース遮断とHTTP優先
「不要リソースを切る」は概念で終わらせず、コードで効かせます。ブラウザ自動化(Playwright)なら、リクエスト単位で画像・フォント・メディア・スタイルを中断できます。
# Playwright: 画像・フォント・メディア・CSSを遮断し、HTMLと必要なJSだけ通す
BLOCK = {"image", "font", "media", "stylesheet"}
async def route_filter(route):
if route.request.resource_type in BLOCK:
await route.abort()
else:
await route.continue_()
await page.route("**/*", route_filter)
どれだけ効くかは転送量で試算すると分かります(単価は仮定値・各社で変わります)。
- 遮断なし:1ページ約3MB(HTML+CSS+JS+画像+フォント)
- 遮断あり:1ページ約0.3MB(HTML+必要なJSのみ)
- 10万ページ取得、住宅用GB単価を仮に $8/GB とすると
- 遮断なし:300GB × $8 ≈ $2,400
- 遮断あり:30GB × $8 ≈ $240
桁が変わります。さらに、JSチャレンジが不要な対象はブラウザを起動せず curl_cffi 等のHTTPクライアントで取得すれば、JS実行も付随リソースも発生せず転送量は最小です。「ブラウザは最後の手段」という原則が、そのままGB課金の最小化になります。
マネージドスクレイピング基盤という選択肢
ここまでは「プロキシを自分で契約して運用する」前提でした。もう一つの方向として、プロキシ・ブラウザ・ローテーションを内包したマネージド基盤に任せ、自前でプール品質を抱えない選択肢があります。
この方式の利点です。
- プロキシの種別選択・ローテーション・IP評判の管理を基盤側に委譲できる
- ブロック検知時のリトライや、住宅用プロキシへのフォールバックが組み込まれていることが多い
- スケール時のインスタンス管理(メモリ・並列)を自前で持たずに済む
一方で、基盤の料金体系(リクエスト課金/計算ユニット課金など)が自前プロキシのGB課金と異なるため、ボリュームによってはどちらが安いかが逆転します。少量・単発なら自前のDCプロキシが安く、継続・大規模で運用負荷を下げたいならマネージド、という比較になります。具体的なマネージド基盤の例は本記事末尾の「関連サービス」に挙げます。
プロバイダの選定基準
種別を決めたら、次はどのプロバイダを使うかです。価格だけで選ぶと、安いプールが汚れていて結局弾かれる、という失敗に繋がります。
- プールの質と規模: IPの出所(正規に取得した回線か)、レンジの分散、すでにBANされたIPが混ざっていないか
- 価格の透明性: GB単価・最低利用額・超過課金が明示されているか。「要問い合わせ」だけの料金は試算しづらい
- ローテーション制御: ロータリー/スティッキーの切替、セッション保持時間、地域(ジオ)指定の粒度
- サポートと検証導線: 小額トライアルや従量での検証ができるか、ブロック時に相談できる窓口があるか
- コンプライアンス: IP提供者の同意取得など、調達経路が説明されているか(評判リスクと法的リスクの両面)
まとめ
| 観点 | データセンター | 住宅用 | モバイル |
|---|---|---|---|
| IP評判 | 低い | 高い | 最も高い |
| 価格 | 安い | 高い | 最も高い |
| 主な課金 | IP数/帯域 | 帯域(GB) | 帯域(GB) |
| 向く対象 | 防御の薄いサイト | Cloudflare等の高防御 | 最高難度・モバイル限定 |
| 使う場面 | まず最初に試す | DCで弾かれたら | 住宅用でも落ちたら |
要点は3つです。①IPの素性が入口の合否を決める ②防御レベルに対して種別を過不足なく合わせる ③住宅用以上はGB課金なので「読み込む量」を設計で絞る。自前運用が重ければマネージド基盤に寄せる。安い種別から積み上げるのは、検知突破全体(Cloudflare突破環境の構築)と同じ考え方です。
すべての取得は、対象の利用規約・robots.txt・個人情報保護法・著作権法を遵守し、サーバーに過負荷をかけない適法な範囲で行ってください。
関連サービス
プロキシのプール品質やローテーションを自前で抱えず、API/Actorでスクレイピングを完結させたい場合は、住宅用プロキシを内包したマネージド基盤を使う選択肢があります。
- Apify(スクレイピング基盤) — プロキシ・ブラウザ・ローテーションを内包し、Actorで取得処理を組める実行基盤。自前でプロキシを契約せずに完結させたいケース向け。
- Bright Data(住宅用プロキシ) — 上記「住宅用(Residential)プロキシ」の代表的プロバイダの一つ。プール規模・ジオ指定・ロータリー/スティッキー切替など、本記事で挙げた選定基準に沿って公式ページで料金・プール仕様を確認してください。
Decodo・IPRoyal など他の住宅用プロキシ各社を直接契約する場合も、各社公式の料金・プール仕様・調達経路を確認のうえ選定してください。