Webスクレイピング 12 分で読めます

暗号通貨マーケットデータ用プロキシ完全ガイド：取引所スクレイピングからオンチェーン収集まで

暗号通貨マーケットデータ用プロキシの選定・実装を実践的に解説。Binance等の取引所APIレート制限・ジブロック回避、オンチェーンRPCとの違い、レイテンシ最適化まで網羅。

ProxyHat Team
Proxies for Cryptocurrency Market Data: A Practical Guide

暗号通貨マーケットデータ用プロキシがなぜ必要なのか

暗号通貨マーケットデータ用プロキシは、Binance、Coinbase、OKX、Bybitなどの中央集権型取引所（CEX）から価格フィード、オーダーブックスナップショット、ファンディングレート、清算データを安定して取得するために不可欠です。取引所のパブリックエンドポイントはIPベースのレート制限を課しており、データセンターブロックやジブロック（地理的制限）を併用するケースが増えています。

一方、オンチェーンデータの収集は性質が異なります。Alchemy、Infura、QuickNodeなどのRPCプロバイダーを通じてブロックチェーンノードに直接クエリを発行する場合、プロキシはスループット向上やジオルーティングに使えるものの、取引所スクレイピングほどの依存度はありません。このガイドでは、両者の違いを明確にした上で、crypto market data scrapingの実践的なアーキテクチャとProxyHatを使った具体的なセットアップを解説します。

なぜこの問題が存在するのか：技術的背景

取引所APIは、サーバー負荷を防ぐためにIPあたりのリクエスト数を制限しています。BinanceのREST APIでは、エンドポイントごとにウェイト制限が設けられており、1分間あたりの累積ウェイトが1200を超えるとHTTP 429 Too Many Requestsが返ります（Binance API Documentation）。コインベースやOKXも同様に、IP単位でリクエスト上限を管理しています。

さらに深刻なのは、レート制限違反が繰り返されると429から451 Unavailable For Legal Reasonsへエスカレーションする点です。HTTP 451は、コンテンツへのアクセスが法的理由により拒否されたことを示すステータスコードで、RFC 7725で標準化されています。Binanceは米国IPからのアクセスをブロックしており、データセンターIPからの大量リクエストも迅速にフラグ付けされます。

ジブロックとデータセンターブロックの違い

  • ジブロック：Binance（米国）、OKX（一部地域）、Bybit（特定国）などが、IPの地理的情報に基づいてアクセスを拒否
  • データセンターブロック：AWS、GCP、AzureなどのクラウドIPレンジからのリクエストを、ボットと判定して制限
  • レート制限エスカレーション：429 → IP一時禁止 → 451（永続的ジブロックの可能性）

オンチェーンデータと取引所データの違い

暗号通貨のデータ収集には、大きく分けて2つの経路があります。それぞれアプローチが異なるため、プロキシの必要性も変わってきます。

観点 オンチェーンデータ（RPC / インデクサー） 取引所データ（CEX API / Web）
データソース ブロックチェーンノード（Ethereum、Solana等） Binance、Coinbase、OKX、Bybit等のAPI
アクセス方法 RPCプロバイダー（Alchemy、Infura、QuickNode） REST API、WebSocket、Webスクレイピング
プロキシの必要性 低〜中（スループット・ジオルーティング目的） 高（レート制限回避・ジブロック回避必須）
レート制限 プロバイダーのプランに依存（秒あたりのCU） IP単位のウェイト制限（1200 weight/min等）
ジブロック ほぼなし あり（Binance米国ブロック等）
データ種別 トランザクション、イベントログ、ステート 価格、オーダーブック、ファンディングレート、清算

オンチェーン：RPCプロバイダーで十分なケースが多い

オンチェーンデータの収集では、AlchemyやInfura、QuickNodeなどのマネージドRPCプロバイダーがAPIキーベースの認証を提供しており、IPベースの制限はプロキシほど厳しくありません。これらのプロバイダーは、1秒あたりのコンピュートユニット（CU）でリクエスト容量を管理しています。例えばQuickNodeの無料プランでは1秒あたり15リクエストが上限ですが、有料プランに移行すればスループットを大幅に引き上げられます。

ただし、複数リージョンからの並列リクエストでスループットを最大化したい場合や、特定ジオロケーションからのRPCエンドポイントへの接続が必要な場合には、プロキシが有効です。

取引所データ：プロキシが必須レベル

これに対し、CEXのパブリックAPIやWebインターフェースからのデータ収集では、プロキシはほぼ必須です。理由は3つ：

  1. IPベースのレート制限：単一IPからのリクエストが制限を超えると429が返る
  2. ジブロック：Binanceは米国IPをブロックし、Bybitはカナダ・英国IPを制限
  3. データセンターブロック：クラウドIPからのリクエストがボット判定されやすく、より厳しい制限がかかる

レジデンシャルプロキシを使えば、実際のISP IPからリクエストを送信できるため、データセンターブロックを回避しつつ、IPローテーションでレート制限を分散できます。

取引所スクレイピングにレジデンシャルプロキシが重要な理由

データセンタープロキシは、取引所のセキュリティシステムによって比較的容易に識別されます。BinanceやCoinbaseは、ASN（自律システム番号）データベースと照合して、リクエスト元がデータセンターかレジデンシャルかを判定しています。

レジデンシャルプロキシは、実際のISPに割り当てられたIPアドレスを使用するため、取引所からは一般ユーザーと区別がつきません。これにより：

  • データセンターブロックの回避：ASNベースのフィルタリングを通過
  • レート制限の分散：複数のレジデンシャルIPでローテーションし、単一IPあたりのリクエストを抑制
  • ジブロックの回避：ターゲット国のIPを使用してアクセス制限をバイパス

ただし、ジブロックの回避は規約違反や現地法に抵触する可能性があるため、後述の規制セクションを必ず参照してください。

アーキテクチャ設計：WebSocketファースト＋RESTフォールバック

リアルタイムデータが必要な場合、取引所がパブリックWebSocketストリームを提供していれば、それを優先して使うべきです。WebSocketは持続的接続のため、プロキシのIPローテーションとは相性が異なります。

リアルタイム：WebSocketストリーム

BinanceのWebSocketは、接続あたり5メッセージ/秒の送信制限と、接続あたり200サブスクリプションの上限があります。WebSocket接続ではスティッキーセッション（同一IPを維持）が必要なため、プロキシのセッション維持機能を使います。

import asyncio
import websockets
import json

# ProxyHat SOCKS5 for sticky WebSocket session
# Replace USERNAME:PASSWORD with your ProxyHat credentials
PROXY = "socks5://user-country-US-session-ws1:pass@gate.proxyhat.com:1080"

async def binance_orderbook(symbol: str = "btcusdt"):
    uri = f"wss://stream.binance.com:9443/ws/{symbol}@depth20@100ms"
    async with websockets.connect(uri) as ws:
        while True:
            msg = await ws.recv()
            data = json.loads(msg)
            # Process orderbook snapshot
            print(f"Bids: {data.get('bids', [])[:3]}")
            print(f"Asks: {data.get('asks', [])[:3]}")

asyncio.run(binance_orderbook())

RESTフォールバック：プロキシローテーション

WebSocketが利用できないエンドポイントや、過去データのバルク取得ではREST APIにフォールバックします。ここでIPローテーションが重要になります。

import requests
from itertools import cycle

# ProxyHat residential proxies with country targeting
PROXY_LIST = [
    "http://user-country-US:pass@gate.proxyhat.com:8080",
    "http://user-country-DE:pass@gate.proxyhat.com:8080",
    "http://user-country-JP:pass@gate.proxyhat.com:8080",
]
proxy_pool = cycle(PROXY_LIST)

def fetch_funding_rate(symbol: str = "BTCUSDT"):
    url = f"https://fapi.binance.com/fapi/v1/fundingRate?symbol={symbol}&limit=100"
    proxy = next(proxy_pool)
    try:
        resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
        resp.raise_for_status()
        return resp.json()
    except requests.exceptions.HTTPError as e:
        if resp.status_code == 429:
            print("Rate limited — rotating proxy")
        elif resp.status_code == 451:
            print("Geo-blocked — switching region")
        raise

funding_data = fetch_funding_rate()

マルチ取引所オーダーブック取得

複数取引所から同時にオーダーブックスナップショットを取得するパターンです。各取引所に最適なジオロケーションからアクセスします。

import aiohttp
import asyncio

EXCHANGES = {
    "binance": {
        "url": "https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=20",
        "proxy": "http://user-country-US:pass@gate.proxyhat.com:8080",
    },
    "okx": {
        "url": "https://www.okx.com/api/v5/market/books?instId=BTC-USDT&sz=20",
        "proxy": "http://user-country-SG:pass@gate.proxyhat.com:8080",
    },
    "bybit": {
        "url": "https://api.bybit.com/v5/market/orderbook?category=linear&symbol=BTCUSDT&limit=20",
        "proxy": "http://user-country-SG:pass@gate.proxyhat.com:8080",
    },
}

async def fetch_orderbook(session, name, config):
    async with session.get(config["url"], proxy=config["proxy"]) as resp:
        data = await resp.json()
        return {name: data}

async def fetch_all():
    async with aiohttp.ClientSession() as session:
        tasks = [
            fetch_orderbook(session, name, cfg)
            for name, cfg in EXCHANGES.items()
        ]
        return await asyncio.gather(*tasks)

results = asyncio.run(fetch_all())

レイテンシの考慮事項

暗号通貨のアービトラージや高頻度取引では、レイテンシが利益を直撃します。プロキシの物理的距離と取引所サーバーの距離を最小化することが重要です。

取引所別の最適リージョン

取引所 サーバー推定リージョン 推奨プロキシジオ ProxyHat設定例
Binance アジア（シンガポール・東京） SG、JP、HK user-country-SG
Coinbase 米国 US user-country-US
OKX アジア（香港・シンガポール） SG、HK、JP user-country-HK
Bybit アジア（シンガポール） SG、JP user-country-SG

Binanceプロキシを構成する際、シンガポールや日本のレジデンシャルIPを使うことで、APIサーバーとの物理距離を短縮し、往復レイテンシを50ms以下に抑えられます。米国のIPを使うと、Binanceのジブロックに加えて物理的距離による遅延も発生します。

逆にCoinbaseには米国IPからのアクセスが最適です。ProxyHatのジオターゲティング機能を使えば、取引所ごとに最適な国を指定できます。

# Low-latency Binance proxy (Singapore)
curl -x "http://user-country-SG:pass@gate.proxyhat.com:8080" \
  "https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT"

# Low-latency Coinbase proxy (US)
curl -x "http://user-country-US:pass@gate.proxyhat.com:8080" \
  "https://api.exchange.coinbase.com/products/BTC-USD/ticker"

規制とコンプライアンス

プロキシを使ったジブロック回避は技術的には可能でも、規約や法律に抵触する可能性があります。以下の点を必ず確認してください。

取引所の利用規約

Binanceの利用規約では、制限対象地域からのアクセスを明示的に禁止しています。Coinbaseの規約も同様に、APIの不正利用や規制回避を禁じています。スクレイピングが規約違反にあたるかはグレーゾーンですが、ジブロックを意図的に回避することは多くの場合、規約違反です。

法的要件

  • SEC規制：米国証券取引委員会は、未登録証券の取引データを米国居住者が取得することを制限する場合がある
  • MiFID II：EU圏では、金融商品のマーケットデータライセンスが義務付けられている場合がある。取引所のデータを再配信する場合はライセンスが必要
  • GDPR / CCPA：収集したデータに個人データが含まれる場合、プライバシー規制が適用される

重要：ジブロックの回避は、現地法に違反する可能性があります。規制地域からのアクセスは、その地域の法律を遵守した上で行ってください。この記事は技術的な解説であり、法的助言ではありません。

ProxyHatを使ったセットアップガイド

ProxyHatのレジデンシャルプロキシを使えば、取引所スクレイピングに必要なIPローテーションとジオターゲティングを簡単に設定できます。

基本的な設定

ProxyHatのHTTPプロキシはgate.proxyhat.com:8080、SOCKS5プロキシはgate.proxyhat.com:1080で利用可能です。ユーザー名にジオターゲティングフラグを含めることで、特定国のIPを指定できます。

  • 米国IP：user-country-US:pass@gate.proxyhat.com:8080
  • ドイツIP：user-country-DE-city-berlin:pass@gate.proxyhat.com:8080
  • シンガポールIP：user-country-SG:pass@gate.proxyhat.com:8080
  • スティッキーセッション：user-session-abc123:pass@gate.proxyhat.com:8080

実践的な構成パターン

パターン1：REST API用IPローテーション — リクエストごとに異なるIPを使い、レート制限を分散。各リクエストで新しいセッションIDを生成することで、ProxyHatが自動的に新しいレジデンシャルIPを割り当てます。

パターン2：WebSocket用スティッキーセッション — 接続維持中は同一IPを保持。SOCKS5プロキシ（ポート1080）とセッション固定フラグを組み合わせます。

パターン3：マルチリージョン並列取得 — 取引所ごとに最適なジオロケーションを指定し、並列でデータを取得。

詳細な設定と料金についてはProxyHat料金プランを、対応ロケーションの一覧はプロキシロケーション一覧を参照してください。Webスクレイピング全般のベストプラクティスはWebスクレイピングのユースケース、SERPデータの取得についてはSERPトラッキングのページもご覧ください。技術的な詳細はProxyHat公式ドキュメントを参照してください。

よくある間違いとエッジケース

1. WebSocketでIPをローテーションしてしまう

WebSocket接続中にIPが変わると接続が切断されます。WebSocketにはスティッキーセッションを使い、REST APIにのみIPローテーションを適用してください。

2. データセンターIPでレート制限を突破しようとする

データセンタープロキシは取引所に検出されやすく、レート制限のしきい値がレジデンシャルIPよりも厳しく設定されていることが多いです。長期的にはレジデンシャルプロキシの方が成功率が高くなります。

3> 429を無視してリトライし続ける

429が返った場合は、即座にリクエストを停止し、指数バックオフで再試行してください。429を無視し続けると、IPのブラックリスト登録や451へのエスカレーションを招きます。

4. オーダーブックのスナップショットと差分を混同する

BinanceのWebSocketは差分（partial book）を配信します。初期スナップショットはREST APIで取得し、その後WebSocketで差分を適用するアプローチが正しいです。これを間違えると、古いデータに基づいて取引判断を下すリスクがあります。

5. タイムスタンプの整合性を確認しない

複数取引所のデータを統合する場合、各取引所のサーバー時刻とローカル時刻のズレを記録し、データのシーケンス保証を検証してください。ミリ秒単位のズレがアービトラージ判定に影響する可能性があります。

Key Takeaways

  • オンチェーンと取引所データはアプローチが異なる：RPCプロバイダーはAPIキーで管理されるためプロキシの必要性は低いが、取引所APIはIPベースの制限が厳しくプロキシがほぼ必須
  • レジデンシャルプロキシが取引所スクレイピングに最適：データセンターIPは検出されやすく、レジデンシャルIPの方が成功率と持続性が高い
  • WebSocketにはスティッキーセッション、RESTにはIPローテーション：接続タイプに応じてプロキシ戦略を使い分ける
  • レイテンシ最適化にはジオターゲティングが不可欠：取引所のサーバーに近いリージョンのIPを使う
  • 429は即座に対応、451はジブロックの兆候：エラーハンドリングを適切に実装し、指数バックオフを使用
  • 規制と規約を必ず確認：ジブロック回避は技術的には可能でも法的リスクがある

暗号通貨マーケットデータ用プロキシの導入を検討している方は、ProxyHatの料金プランから始めるか、公式ドキュメントで詳細な設定方法を確認してください。

始める準備はできましたか？

AIフィルタリングで148か国以上、5,000万以上のレジデンシャルIPにアクセス。

料金を見るレジデンシャルプロキシ
Proxies for Cryptocurrency Market Data: CEX Scraping vs On-Chain Collection
Webスクレイピング

暗号通貨市場データ用プロキシ：CEXスクレイピング実装とベストプラクティス

暗号通貨市場データのスクレイピングにおいて、CEX APIのレート制限・ジオ制限を回避し、高信頼性のデータ収集を実現するプロキシ実装ガイド。オンチェーンデータと取引所データの違いから、WebSocket優先アーキテクチャ、レイテンシ最適化、規制対応まで詳解。

11 分で読めます続きを読む →
← ブログに戻る