Binance APIのレート制限（Rate Limit）対策：weightの意味と対処法
APIのレート制限によりリクエストが拒否される問題を解決します。weightとorderの2つの制限ルールと、適切なリトライ（退避）方法について解説します。
APIのレート制限（Rate Limit）は、自動売買戦略において最も陥りやすい罠です。まず Binance公式サイト でAPIキーを作成し、アプリでの監視には Binance公式アプリ を使用してください（iOSについては iOSインストールガイド を参照）。
2種類のレート制限
Binance APIには、独立した2つの制限軸があります：
1. Weight（ウェイト）
各APIエンドポイントには「weight」値が設定されています。1分間あたりの合計値が制限を超えてはいけません。
| アカウントレベル | 1分間あたりの合計Weight |
|---|---|
| 一般ユーザー | 1,200 |
| VIP 1 | 2,400 |
| VIP 2 | 3,600 |
| ... | レベルに応じて増加 |
2. Order（注文数）
注文関連エンドポイントには、追加の制限があります：
| 時間枠 | 最大注文数 |
|---|---|
| 10秒間 | 100件 |
| 24時間 | 200,000件 |
いずれかの制限を超えると、一時的にアクセスが禁止されます。
主要エンドポイントのWeight
よく使われるエンドポイントの例：
| エンドポイント | Weight |
|---|---|
| 相場スナップショット | 1 |
| オーダーブック (5档) | 1 |
| オーダーブック (100档) | 5 |
| オーダーブック (1000档) | 50 |
| K線（ローソク足） | 1 |
| 新規注文 | 1 |
| 注文キャンセル | 1 |
| 口座情報取得 | 10 |
深いオーダーブック（1,000档）を1回取得すると50のWeightを消費するため、1分間に24回までしかリクエストできません。
レスポンスヘッダー
APIからの各レスポンスヘッダーには以下の情報が含まれています：
X-MBX-USED-WEIGHT-1M：現時刻の1分間で使用済みの合計WeightX-MBX-ORDER-COUNT-10S：直近10秒間の注文数
これらの値を監視し、上限に近づいたらリクエスト速度を落とす必要があります。
制限を超えた場合の影響
- HTTP 429 エラー：一時的な禁止。数秒から数分待つ必要があります。
- HTTP 418 エラー：429を無視してリクエストを続けた場合に発生。より長期、あるいは永久的なIPBANの対象となります。
418エラーが発生すると、解除まで24時間以上かかることもあります。制限を無理に突破しようとしないでください。
エレガントな退避（バックオフ）の実装
import time
while True:
try:
result = api_call()
weight_used = int(headers.get('X-MBX-USED-WEIGHT-1M', 0))
if weight_used > 1000:
time.sleep(10) # 上限に近いので減速
return result
except RateLimitError:
# 429エラーが発生したら1分間待機
time.sleep(60)
Weightを節約するテクニック
1. 取得する深さを絞る
5档の板情報で十分な場合は、1,000档を取得しないでください。Weightに50倍の差があります。
2. WebSocketの活用
価格、オーダーブック、K線などはWebSocketでリアルタイム受信できます。WebSocket経由の受信はWeightを消費しません。
3. バッチ注文の利用
/api/v3/batchOrders を使うと1回のリクエストで5件の注文を出せます。個別に5回注文を出すよりもWeightを節約できます。
4. キャッシュの利用
毎秒確認する必要のないデータは、数秒間ローカルでキャッシュします。
WebSocketのメリット
| データ種別 | REST (Weight) | WebSocket |
|---|---|---|
| 相場 | 1リクエストごとに 1 | プッシュ配信、0 Weight |
| オーダーブック | 1〜50 | プッシュ配信 |
| K線 | 1 | プッシュ配信 |
理想的なフレームワーク構成：
- WebSocket：リアルタイムデータの受信（Weight消費なし）
- REST API：注文の発注・キャンセル時のみ使用
複数アカウントへの分散
複数のAPIキー（別アカウント）を使用すれば、当然Weight制限も分散されます。
戦略：
- メインアカウントのキー：注文用
- サブアカウントのキー：相場取得用
- これにより、利用可能なWeightプールが数倍に拡大します。
VIPランクによるWeight緩和
VIPレベルが上がると：
- 1分あたりのWeight上限が引き上げられる
- 一部エンドポイントの制限が緩和される
- 手数料の割引以上に大きなメリットになることがあります。
VIP 1 になるだけでWeight上限が倍増するため、検討の価値があります。
監視コードの例
class RateMonitor:
def __init__(self):
self.last_weight = 0
self.alert_threshold = 1000
def update(self, headers):
used = int(headers.get('X-MBX-USED-WEIGHT-1M', 0))
if used > self.alert_threshold:
print(f"WARN: レート制限が近づいています: {used} / 1200")
self.last_weight = used
よくある間違い
1. すべてREST APIでループ処理する
注文を出しながら毎秒残高確認とK線取得を行うと、Weightはあっという間に尽きます。WebSocketへの切り替えが必要です。
2. 例外処理を行わない
429エラーが出ているのに sleep せずにリクエストを続け、即座に418エラー（IPBAN）に繋げてしまうケースです。
3. 同一IPで複数のキーを使用する
キーを分けても、同じグローバルIPからのリクエストは同一として合算カウントされる場合があります。
4. ヘッダーを確認しない
Weightの消費状況を確認せず、壁にぶつかってから初めて制限に気づくパターンです。
実運用前のテスト
テストネット（testnet）で高頻度テストを行い、429エラーが発生しないか確認してから本番環境へ移行してください。 本番では監視アラートを設定し、上限に近づいたら自動的に減速または停止する仕組みを導入しましょう。
よくある質問
Q: 429エラーはどのくらいで解除されますか？ A: 通常は数秒から数分です。その間はリクエストを完全に停止してください。
Q: 418エラーはどのくらいで解除されますか？ A: 1時間から24時間、最悪の場合は7日間程度です。
Q: 制限の解除を申請できますか？ A: カスタマーサポートに連絡はできますが、通常は自動解除を待つしかありません。
Q: Weightはすべてのエンドポイントで共有されますか？ A: はい。すべて合算して1,200/分（一般ユーザーの場合）です。
Q: 注文制限（Order limit）はIP単位ですか、アカウント単位ですか？ A: アカウント単位です。IPを分散させても回避できません。
関連ガイド
制限があることを理解していれば恐れることはありません。Weightを適切に監視し、IPBANを回避しながら効率的な運用を行いましょう。