AIモデルのトレーニングには、テキスト、画像、動画、ウェブサイトからの構造化データなど、膨大な量のデータが必要です。問題は、大量のパースを行うと、サイトがすぐにIPアドレスをブロックし、ボットの活動と見なされることです。この記事では、プロキシを介してデータ収集を正しく整理する方法、さまざまなタスクに対してどのIPタイプを選択するか、安定した動作のためのインフラストラクチャの設定方法を説明します。
なぜAIトレーニングにプロキシが必要なのか
現代の言語モデル(GPT、LLaMA、Claudeなど)は、数十億のトークンからなるテキストでトレーニングされています。コンピュータビジョンモデルは、数千万の画像を必要とします。レコメンデーションシステムは、数千のサイトでユーザーの行動を分析します。これらのデータはどこから得る必要があります。
主な問題は、サイトが大量のパースから積極的に保護されていることです。1つのIPから1分間に100件以上のリクエストを送信すると、5〜10分でブロックされます。ブロックの理由は以下の通りです:
- レート制限: 1つのIPからのリクエスト数の制限(通常は1分間に10〜60リクエスト)
- アンチボットシステム: Cloudflare、Akamai、PerimeterXは行動を分析し、疑わしい活動をブロックします
- 地理的制限: 一部のコンテンツは特定の国からのみアクセス可能です
- 競合からの保護: マーケットプレイスやアグリゲーターは、価格や商品の大量収集をブロックします
プロキシは、リクエストを数千の異なるIPアドレスに分散させることでこの問題を解決します。1つのIPから1000件のリクエストを送信する代わりに、500〜1000の異なるアドレスから1〜2件のリクエストを送信することで、通常のユーザーの活動として見えます。
データ収集のためにどのプロキシタイプを選ぶべきか
AIトレーニングには、各々の利点と制限を持つ3つのタイプのプロキシが使用されます。選択はデータソース、ボリューム、プロジェクトの予算によって異なります。
| プロキシの種類 | 速度 | サイトの信頼性 | コスト | 使用するタイミング |
|---|---|---|---|---|
| データセンター | 100-1000 Mbps | 低い | $0.5-2/IP | オープンAPI、保護のないシンプルなサイト |
| レジデンシャル | 10-50 Mbps | 高い | $5-15/GB | ソーシャルメディア、Cloudflareを使用しているサイト、eコマース |
| モバイル | 5-30 Mbps | 非常に高い | $10-30/GB | モバイルアプリ、厳しい保護 |
データセンターのプロキシ: 大量データ用の速度
データセンターのプロキシは、クラウドプロバイダー(AWS、Google Cloud、Hetzner)のサーバーのIPアドレスです。主な利点は速度と低コストです。1つのデータセンターIPは、秒間に数百のリクエストを処理できます。
攻撃的な保護を使用していないソースからのデータ収集に適しています: オープンAPI(GitHub、Wikipedia、Stack Overflow)、政府のデータベース、Cloudflareを使用していないニュースサイト、学術出版物。サイトがJavaScriptレンダリングなしでデータを提供し、ブラウザのフィンガープリントを確認しない場合、データセンターは機能します。
欠点は、多くのサイトがデータセンターのIPをブラックリストに登録していることです。Instagram、Facebook、Google検索、大型マーケットプレイスは、データセンターのIPをほぼ即座にブロックします。そのため、これらのソースにはレジデンシャルが必要です。
レジデンシャルプロキシ: どんな保護でも回避
レジデンシャルプロキシは、実際の家庭ユーザーのIPアドレスを使用します。サイトには、そのリクエストが自宅からの通常の訪問者のように見えます。これにより、Cloudflare、Akamaiを回避し、ソーシャルメディアや保護されたプラットフォームからデータを収集できます。
レジデンシャルは、Instagram、Facebook、Twitter/X(投稿、コメント、プロフィールの収集)、Google検索(NLPモデル用の検索結果のパース)、マーケットプレイス(Amazon、eBay、Wildberries — 商品、レビュー、価格)、地理的制限のあるサイト(特定の国からのみアクセス可能なコンテンツ)に必要です。
コストは高くなります — トラフィックに対する支払い($5-15/GB)。コストを抑えるために、レジデンシャルは重要なソースにのみ使用し、シンプルなサイトはデータセンターを介してパースしてください。
モバイルプロキシ: モバイルアプリ用
モバイルプロキシは、モバイルキャリア(4G/5G)のIPを使用します。必要な場合は少なく、主にモバイルアプリ(TikTok、Instagramアプリ、モバイルゲーム)からデータを収集するためや、サイトがモバイルトラフィックとデスクトップトラフィックを区別する場合に使用されます。
モバイルIPの利点は、キャリアがCGNATを使用しているため(1つのIPが数百のユーザーに共有される)、これらのアドレスをブロックすることが不利であることです。しかし、ほとんどのAIトレーニングのタスクにはレジデンシャルで十分です。
データソースの種類とプロキシの要件
異なるタイプのデータは、プロキシに対して異なるアプローチを必要とします。AIモデルのトレーニングのための人気のあるソースを見てみましょう。
NLPモデル用のテキストデータ
言語モデルのトレーニングには、ニュースサイト、フォーラム、ブログ、ソーシャルメディア、Wikipedia、専門リソースからのテキストが収集されます。ボリュームは数十テラバイトのテキストです。
プロキシに関する推奨: ニュースサイトやブログにはデータセンターを使用してください(速度が重要です)。RedditやQuoraのようなフォーラムにはレジデンシャルを使用してください(レート制限があります)。Twitter、Facebook、Instagramには、5〜10分ごとにローテーションするレジデンシャルのみを使用してください。
テキストパースの特徴は、構造(見出し、段落、メタデータ)を保持する必要があることです。JavaScriptサイトにはヘッドレスブラウザ(Puppeteer、Playwright)を使用し、静的ページにはシンプルなHTTPクライアント(requests、axios)を使用してください。
コンピュータビジョン用の画像
認識モデルのトレーニングには、アノテーション付きの数百万の画像が必要です。ソースには、Google Images、Pinterest、Instagram、専門のフォトストック、eコマースサイト(商品写真)があります。
問題は、画像のサイズが大きいことです(平均サイズは200〜500KB)、そのためトラフィックがすぐに消費されます。レジデンシャルプロキシを使用する場合(GBあたりの支払い)は、これは重要です。最適化戦略: 最初にレジデンシャルを介して画像のURLを収集し、その後データセンターまたは直接(CDNがリファラーをチェックしない場合)を介してファイルをダウンロードします。
eコマースからの構造化データ
商品、価格、レビューに関するデータは、レコメンデーションシステムや価格設定モデルのトレーニングに使用されます。ソースには、Amazon、eBay、Wildberries、Ozon、AliExpressがあります。
すべての大型マーケットプレイスはCloudflareまたは独自のアンチボットシステムを使用しています。必ずレジデンシャルプロキシとローテーションが必要です。さらに、正しいブラウザのフィンガープリントが重要です — 自動化を隠すためにpuppeteer-extra-plugin-stealthのようなツールを使用してください。
動画と音声データ
YouTube、TikTok、ポッドキャストプラットフォームは、音声と動画の認識モデルのトレーニングのためのソースです。問題は、膨大なトラフィックです(1つの動画 = 数百MB)。このようなタスクには、レジデンシャルプロキシは経済的ではありません。
解決策: レジデンシャルを使用してメタデータと動画のリンクを取得し、ダウンロードはデータセンターまたはYouTubeの制限を回避できる特別なツール(yt-dlpなど)を介して行ってください。
異なるボリュームのためのIPローテーション戦略
IPのローテーションは、安定したパースのための重要なポイントです。誤った設定は、ブロックまたはトラフィックの過剰支払いにつながります。
リクエストごとのローテーション(ローテーティングプロキシ)
各リクエストは新しいIPを介して行われます。これは、セッションを保持する必要がないさまざまなサイトの大量パースに適しています。たとえば、10000の異なるニュースサイトからテキストを収集する場合、各サイトは1〜2件のリクエストしか見ません。
import requests
# ローテーティングプロキシ - 各リクエストは新しいIP
proxies = {
'http': 'http://username:password@rotating.proxycove.com:12345',
'https': 'http://username:password@rotating.proxycove.com:12345'
}
urls = ['https://site1.com', 'https://site2.com', ...]
for url in urls:
response = requests.get(url, proxies=proxies)
# 各リクエストは新しいIPから行われます
parse_data(response.text)
利点は、ブロックからの最大限の保護です。欠点は、認証やクッキーの保存を必要とするサイトで作業できないことです。
時間によるローテーション(スティッキーセッション)
IPは5〜30分間保持され、その後変更されます。ページネーションのある1つのサイトのパースに適しており、セッションを保持しながらページ1、2、3...を通過する必要があります。
import requests
import time
# スティッキーセッション - IPは10分間保持されます
session_id = generate_random_string() # セッションのユニークID
proxies = {
'http': f'http://username-session-{session_id}:password@sticky.proxycove.com:12345'
}
# 10分間のすべてのリクエストは1つのIPから行われます
for page in range(1, 100):
url = f'https://site.com/catalog?page={page}'
response = requests.get(url, proxies=proxies)
parse_page(response.text)
time.sleep(2) # リクエスト間の遅延
サイトのレート制限に応じてセッションの時間を設定してください。制限が1分間に60リクエストの場合、セッションを1〜2分に設定し、50リクエストを超えないようにしてください。
静的IPプール
100〜1000のIPのリストを取得し、リクエストの分配を自分で管理します。完全な制御が必要な複雑なシナリオに適しています: サイトの異なるセクションの並行パース、負荷のバランス、カスタムロジックのローテーション。
import requests
from itertools import cycle
# 500の静的IPのプール
ip_pool = [
'http://user:pass@ip1.proxycove.com:12345',
'http://user:pass@ip2.proxycove.com:12345',
# ... 500アドレス
]
proxy_cycle = cycle(ip_pool)
for url in urls:
proxy = next(proxy_cycle) # プールから次のIPを取得
response = requests.get(url, proxies={'http': proxy, 'https': proxy})
parse_data(response.text)
このアプローチは最大の柔軟性を提供しますが、エラー処理のためにより多くのコードが必要です(IPがブロックされた場合、そのIPをプールから除外する必要があります)。
パース時のアンチボットシステムの回避
プロキシはIPブロックの問題を解決しますが、現代のサイトはボットを特定するために数十のパラメータを分析します。レジデンシャルIPを使用しても、ブラウザのフィンガープリントが自動化を示す場合、ブロックされる可能性があります。
アンチボットシステムが確認するもの
- User-Agent: 実際のブラウザ(Chrome、Firefox)に一致し、「headless」や「bot」という単語を含まない必要があります
- ヘッダー: ヘッダーのセットは、ブラウザにとって典型的である必要があります(Accept、Accept-Language、Accept-Encoding、Referer)
- TLSフィンガープリント: SSL接続のパラメータは、ブラウザとスクリプトで異なります
- JavaScriptフィンガープリント: WebGL、Canvas、AudioContext、フォント、プラグイン、画面解像度
- 行動: マウスの動き、スクロール速度、クリック(JavaScriptレンダリングのあるサイトの場合)
自動化を隠すためのツール
高度な保護を回避するために、マスキングプラグインを使用したヘッドレスブラウザを使用してください:
// Puppeteerとステルスプラグイン
const puppeteer = require('puppeteer-extra');
const StealthPlugin = require('puppeteer-extra-plugin-stealth');
puppeteer.use(StealthPlugin());
const browser = await puppeteer.launch({
headless: true,
args: [
'--proxy-server=http://username:password@residential.proxycove.com:12345',
'--disable-blink-features=AutomationControlled'
]
});
const page = await browser.newPage();
// 現実的なビューポートを設定
await page.setViewport({ width: 1920, height: 1080 });
// ランダムな遅延を追加
await page.goto('https://protected-site.com');
await page.waitForTimeout(2000 + Math.random() * 3000);
const data = await page.evaluate(() => {
return document.querySelector('.data').innerText;
});
await browser.close();
Pythonの場合は、同様の設定でPlaywrightを使用するか、検出を回避するために自動的にChromeDriverをパッチするundetected-chromedriverライブラリを使用してください。
Cloudflareや他のWAFの回避
Cloudflareは、ブラウザを確認するためにJavaScriptチャレンジを使用します。シンプルなHTTPクライアント(requests、axios)ではこれを通過できません。解決策は以下の通りです:
- ヘッドレスブラウザ: Puppeteer/Playwrightとステルスプラグインはほとんどのチャレンジを通過します
- 既製の解決策: cloudscraper(Python)やpuppeteer-extra-plugin-recaptchaのようなライブラリ
- 回避サービス: FlareSolverrやAnti-Captchaのような専門APIがチャレンジを解決します
重要: 正しいフィンガープリントを使用しても、リクエスト間に休止を取ってください。完璧なブラウザフィンガープリントで1秒間に100リクエストを送信することは、依然として疑わしく見えます。最適な速度は、1つのIPから1分間に10〜30リクエストです。
データ収集のためのインフラストラクチャのアーキテクチャ
AIトレーニングのためのデータ収集を大規模に行う場合、慎重に設計されたアーキテクチャが必要です。1つのサーバー上のシンプルなスクリプトでは、テラバイトのデータをパースすることはできません。
収集システムのコンポーネント
1. タスクキュー(Task Queue)
パースするURLのリストを保持します。Redis、RabbitMQ、またはAWS SQSを使用してください。タスクをワーカー間で分配し、失敗したタスクを再提出できます。
2. ワーカー(Workers)
キューからタスクを取得してパースを実行するプロセスです。10〜100のワーカーを異なるサーバーで並行して起動します。各ワーカーは独自のプロキシまたはプロキシプールを使用します。
3. データストレージ(Storage)
収集したデータが保存される場所です。テキスト用にはS3/MinIO(オブジェクトストレージ)を使用します。構造化データ用にはPostgreSQLまたはMongoDBを使用します。大規模なデータにはデータレイク(AWS S3 + Athena、Google Cloud Storage)を使用します。
4. モニタリング(Monitoring)
パース速度、エラー率、トラフィック消費を追跡します。Grafana + PrometheusまたはDatadogのような既製のソリューションを使用してください。重要なメトリックにアラートを設定します(エラー率 >10%、速度が2倍に低下)。
Pythonでのアーキテクチャの例
# worker.py - パースプロセス
import redis
import requests
import json
from datetime import datetime
# Redisへの接続(タスクキュー)
queue = redis.Redis(host='redis-server', port=6379)
# プロキシプール
proxies_pool = load_proxies_from_config()
while True:
# キューからタスクを取得
task = queue.blpop('parsing_queue', timeout=5)
if not task:
continue
url = task[1].decode('utf-8')
proxy = get_next_proxy(proxies_pool)
try:
response = requests.get(
url,
proxies={'http': proxy, 'https': proxy},
timeout=30,
headers={'User-Agent': get_random_user_agent()}
)
# データをパース
data = parse_html(response.text)
# S3に保存
save_to_s3(data, f'data/{datetime.now().isoformat()}/{hash(url)}.json')
# 成功をログに記録
log_success(url, proxy)
except Exception as e:
# エラーが発生した場合、タスクをキューに戻す
queue.rpush('parsing_queue', url)
log_error(url, proxy, str(e))
mark_proxy_as_failed(proxy)
このアーキテクチャは水平スケーラビリティを可能にします — 新しいワーカーを持つサーバーを追加するだけです。1つのワーカーがダウンしても、他のワーカーは作業を続けます。
収集の自動化ツール
大規模なパースには、一般的なタスクを即座に解決する専門のフレームワークが使用されます。
Scrapy — Python用のフレームワーク
Scrapyは、Pythonでのウェブスクレイピングのための最も人気のあるツールです。デフォルトでサポートされている機能: 並行パース(数百のリクエストを同時に)、エラー時の自動リトライ、プロキシとUser-Agentのローテーション用のミドルウェア、JSON、CSV、XML、データベースへのエクスポート。
# settings.py - プロキシを使用したScrapyの設定
ROTATING_PROXY_LIST = [
'http://user:pass@proxy1.proxycove.com:12345',
'http://user:pass@proxy2.proxycove.com:12345',
# ... プロキシのリスト
]
DOWNLOADER_MIDDLEWARES = {
'rotating_proxies.middlewares.RotatingProxyMiddleware': 610,
'rotating_proxies.middlewares.BanDetectionMiddleware': 620,
}
# 並行性
CONCURRENT_REQUESTS = 100
DOWNLOAD_DELAY = 0.5 # リクエスト間の遅延
Scrapyは静的サイト(JavaScriptなしのHTML)に適しています。動的サイトにはScrapy + Splash(ヘッドレスブラウザ)を使用するか、Playwrightに切り替えてください。
Crawlee — Node.js用のフレームワーク
Crawlee(以前のApify SDK)は、JavaScript用のScrapyの類似品です。利点は、PuppeteerとPlaywrightとのネイティブな統合、プロキシの自動ローテーション、タスクキューの自動管理、エラー時の適応的なパース速度(遅くなる)です。
import { PlaywrightCrawler, ProxyConfiguration } from 'crawlee';
const proxyConfiguration = new ProxyConfiguration({
proxyUrls: [
'http://user:pass@proxy1.proxycove.com:12345',
'http://user:pass@proxy2.proxycove.com:12345',
],
});
const crawler = new PlaywrightCrawler({
proxyConfiguration,
maxConcurrency: 50,
requestHandler: async ({ page, request }) => {
await page.waitForSelector('.data');
const data = await page.$$eval('.item', items =>
items.map(item => ({
title: item.querySelector('h2').innerText,
price: item.querySelector('.price').innerText
}))
);
await saveData(data);
},
});
await crawler.run(['https://site.com/catalog']);
Apache Nutch — 大規模クローリング用
インターネット全体からデータを収集する必要がある場合(検索エンジンのように)、Apache Nutchを使用してください。これは、Hadoopの上で動作する分散クローラーです。ペタバイトのデータを処理でき、新しいページをリンクから自動的に検出し、クローリングポリシー(robots.txt、sitemap.xml)をサポートします。
Nutchは設定が難しいですが、Common Crawlのようなデータセットを収集するためには不可欠です。プロキシを使用するには、proxy-rotatorプラグインを使用してください。
速度とコストの最適化
AIトレーニングのためのデータ収集は高価な作業です。テラバイトのトラフィックが発生する場合、プロキシのコストは月に数万ドルに達することがあります。品質を損なうことなくコストを最適化する方法を見てみましょう。
プロキシタイプを組み合わせる
すべてのタスクにレジデンシャルを使用しないでください。ソースを3つのカテゴリに分けてください:
- 保護なし: データセンタープロキシ($0.5-2/IP) — オープンAPI、シンプルなサイト、政府のデータベース
- 中程度の保護: レジデンシャルローテーティング($5-10/GB) — Cloudflareを使用しているニュースサイト、フォーラム
- 高い保護: レジデンシャルスティッキーセッション($10-15/GB) — ソーシャルメディア、マーケットプレイス
例: 100のニュースサイトをパースしています。70はCloudflareなしで動作しています — データセンターを使用してください。30は保護されています — レジデンシャルを使用してください。これにより、プロキシの予算が60〜70%節約できます。
リクエストをキャッシュする
同じサイトを何度もパースする場合(たとえば、毎日のニュース収集)、変更されないページをキャッシュしてください。HTMLキャッシュ用にRedisまたはローカルストレージを使用してください。
import hashlib
import redis
cache = redis.Redis(host='localhost', port=6379)
def fetch_with_cache(url, proxies):
# キャッシュを確認
cache_key = hashlib.md5(url.encode()).hexdigest()
cached = cache.get(cache_key)
if cached:
return cached.decode('utf-8')
# キャッシュにない場合 - リクエストを行う
response = requests.get(url, proxies=proxies)
html = response.text
# 24時間キャッシュに保存
cache.setex(cache_key, 86400, html)
return html
トラフィックを最適化する
レジデンシャルプロキシを使用する場合(GBあたりの支払い)は、トラフィックの量を減らすことが重要です:
- 画像、CSS、フォントの読み込みを必要ない場合はオフにしてください(Puppeteerでは: page.setRequestInterception)
- 圧縮を使用してください(gzip、brotli) — ほとんどのプロキシがサポートしています
- 必要な要素のみをパースしてください — 1つのブロックが必要な場合はページ全体をダウンロードしないでください
- APIにはHTMLの代わりにJSONを使用してください(トラフィックが5〜10倍少なくなります)
時間による負荷分散
多くのサイトは、24時間の間に異なる負荷を持っています。夜間(サイトのサーバーの時間)にパースしてください — レート制限に引っかかる可能性が低くなります。また、週末も考慮してください — 土曜日と日曜日は保護が弱くなることがあります。
メトリックを監視する
最適化のために重要な指標を追跡してください:
| メトリック | 基準 | 逸脱時の対処法 |
|---|---|---|
| 成功率 | >90% | 遅延を増やす、プロキシの種類を変更する |
| 平均速度 | ワーカーあたり50-200 req/min | ワーカーまたはプロキシを追加する |
| 1000レコードあたりのコスト | $0.5-5 | トラフィックを最適化する、データセンターを使用する |
| 重複率 | <5% | デデュプリケーションを改善する、クローリングのロジックを確認する |
結論
AIモデルのトレーニングのためのデータ収集は、プロキシの正しい選択、ローテーションの設定、保護の回避、コストの最適化を必要とする複雑なタスクです。重要なポイントは以下の通りです:
- シンプルなソース(API、保護のないサイト)にはデータセンタープロキシを使用してください — 速くて安価です
- 保護されたプラットフォーム(ソーシャルメディア、マーケットプレイス、Cloudflareを使用しているサイト)にはレジデンシャルプロキシが必須です
- タスクに応じてローテーションを設定してください: 大量パースにはリクエストごとのローテーション、1つのサイトで作業するにはスティッキーセッションを使用してください
- アンチボットシステムを回避するために、マスキングプラグインを使用したヘッドレスブラウザを使用してください
- タスクキューと並行ワーカーを持つスケーラブルなアーキテクチャを構築してください
- コストを最適化してください: プロキシタイプを組み合わせ、リクエストをキャッシュし、トラフィックを減らしてください
正しい設定を行えば、安定して経済的にテラバイトのデータを収集できます。最初は10〜20のソースで小規模なパイロットプロジェクトを開始し、プロセスを調整した後、産業規模にスケールアップしてください。
保護されたプラットフォーム(ソーシャルメディア、eコマース、アンチボットシステムを持つサイト)からデータを収集する予定がある場合は、レジデンシャルプロキシの使用をお勧めします — 高い信頼性と最小限のブロック率を提供します。シンプルなソースやAPIには、最大の速度と低コストを提供するデータセンタープロキシで十分です。