アービトラージのための仮想通貨取引所API：REST vs WebSocket、レート制限、安全なAPIキー 2026年10月01日 – Posted in: Arbitrage Software, cryptoarbitrage software
アービトラージのための仮想通貨取引所API接続：REST、WebSocket、レート制限、レイテンシ
アービトラージの機会が存在するのは、ボットがそれを検知して行動できる間だけです。そしてその両方が、各取引所への接続方法に左右されます。このガイドでは、価格差が約定につながるか、取引を逃すかを分ける選択について解説します。どのAPIタイプを使うべきか、Binance・Bybit・OKX・MEXC・Gate.ioのレート制限はどう機能するか、安全なAPIキーの作り方、そしてミリ秒単位の遅延がどこで生じるのかを見ていきましょう。
API接続がアービトラージの成果を左右する理由
取引所間アービトラージは、理屈の上では単純です。価格が安い取引所で買い、高い取引所で売り、手数料を差し引いた差額を利益にします。しかし実際には、価格差が続くのは通常数百ミリ秒から数分程度で、取引はすべて取引所のAPIを通じて行われます。実際にどれだけ利益を取れるかは、次の3つの技術的要因で決まります。
- 価格をどれだけ速く把握できるか。気配値の受信が遅れていれば、計算した価格差はすでに消えているかもしれません。
- 注文がどれだけ速く届くか。2つの取引所で2つのレッグを約定させる必要があり、遅い方のレッグが実際のエントリー価格を決めます。
- どれだけ頻繁にリクエストを送れるか。レート制限はリクエスト数に上限を設けます。制限に達したボットは、市場が最も活発で価格差が最も広がっているまさにその瞬間にブロックされてしまいます。
こうした要素はバックテストでは見えません。同じ戦略を動かす2つのボットがまったく異なる結果を出すのはそのためです。まだ利用する取引所間の価格差を測定していない場合は、まず無料の仮想通貨アービトラージスキャナーから始めてください。手数料をカバーできるだけの価格差が生じる通貨ペアと取引所を確認できます。
REST vs WebSocket：それぞれの得意分野
主要な取引所はいずれも、2種類の通信方法を提供しています。
REST APIはリクエストとレスポンスの形で動作します。ボットが署名付きのHTTPリクエスト（例えば「オーダーブックを取得する」「この注文を発注する」など）を送り、応答を待ちます。各リクエストは独立しており、デバッグが簡単で、レート制限にカウントされます。
WebSocket APIは1本の接続を開いたまま維持します。チャンネルを購読すると、取引所はあらゆる更新（オーダーブックの変化、約定、自分の注文ステータス）を発生と同時にプッシュ配信します。ポーリングは不要で、チェックとチェックの間に情報が見えない空白もありません。
| REST | WebSocket | |
|---|---|---|
| マーケットデータ | リクエスト時点のスナップショット。ポーリング間の変化は取りこぼす | オーダーブックと約定の更新を継続的にストリーミング |
| アービトラージでの主な用途 | 価格差が数秒以上続くヘッジ（取引所間）アービトラージ、残高照会、出金 | レイテンシアービトラージや、価格差が1秒未満しか続かないあらゆる戦略 |
| レート制限への負荷 | 高い：価格チェックのたびにウェイトを消費 | データ取得では低い：数千回のリクエストの代わりに1回の購読で済む |
| 実装の複雑さ | 低い | 高め：再接続、シーケンス番号、ローカルのオーダーブック管理が必要 |
プロ向けの構成の多くは両方を組み合わせています。マーケットデータと注文の更新にはWebSocket、発注にはREST（または利用可能であれば取引所のWebSocket取引エンドポイント）、残高や送金といった速度を問わない管理系の呼び出しにはRESTを使います。
これは当社の2つの仮想通貨ボットの実際的な違いでもあります。VIP Crypto ArbitrageはRESTで35以上の取引所に接続し、価格差が十分に長く続く取引所間ヘッジアービトラージ向けに設計されています。SharpTrader Proは40以上の取引所のWebSocketフィードを使用しており、チャンスの窓が100–500 msしかないレイテンシアービトラージにはこれが不可欠です。
主要取引所のレート制限
レート制限は、アービトラージボットが実運用で動かなくなる最も一般的な原因です。各取引所はIPアドレスごと、アカウント（UID）ごと、またはAPIキーごとにリクエストをカウントし、上限を超えるとブロックやBANを行います。下の表は、執筆時点（2026年9月）で公開されているルールをまとめたものです。制限は定期的に変更されるため、必ず取引所のドキュメントを確認し、実際のレスポンスに含まれる制限ヘッダーを読み取るようにしてください。
| 取引所 | 主なRESTの制限 | 超過した場合 | 役立つ詳細情報 |
|---|---|---|---|
| Binance（現物） | IPごとに1分あたりリクエストウェイト6,000。注文数には別の制限あり。エンドポイントごとに固有のウェイトが設定されている | HTTP 429。429の後もリクエストを続けるとHTTP 418となり、IPが自動的にBANされる（2分から、違反を繰り返す場合は最長3日） | X-MBX-USED-WEIGHT-*およびX-MBX-ORDER-COUNT-*ヘッダーで現在の使用量を確認でき、Retry-Afterで待機時間がわかる |
| Bybit（V5） | IPごとに5秒あたり600リクエスト。取引にはUIDごとの制限があり、例えば注文作成は現物で20/s、リニア契約で10/s | IP制限：HTTP 403「access too frequent」、約10分後に解除。UID制限：retCode 10006 | ヘッダーX-Bapi-Limit、X-Bapi-Limit-Status、X-Bapi-Limit-Reset-Timestamp |
| OKX（V5） | 制限はエンドポイントごと・銘柄ごとに設定され、VIPティアが高いほど上限が増える | 該当エンドポイントでエラーレスポンス。悪用を繰り返すとキーが制限される場合がある | オーダーブックのチャンネル：bbo-tbt（最良気配、10 msごと）、books5（100 msごと）、books（差分、100 ms）。ティック単位のL2チャンネルには高いVIPレベルが必要 |
| MEXC（Spot v3） | IPウェイト型のエンドポイントは10秒あたり300ウェイトを共有。UIDウェイト型のエンドポイントは10秒あたり500ウェイト | Retry-After付きのHTTP 429。違反を繰り返すと2分から3日間のIP BAN |
WebSocket：1接続あたり最大30ストリーム、毎秒100メッセージ。通信がないまま60 s経過すると切断される（pingに応答すること） |
| Gate.io（API v4） | 現物のパブリック／プライベートエンドポイントについてキーごとの制限が公開されており、注文キャンセルにはかなり高い上限が設定されている | バースト閾値に近いリクエストは遅延処理され、超えたリクエストは拒否される | WebSocket：IPごとに最大300接続 |
ボットを制限内に収めるための3つのルールがあります。
- マーケットデータはRESTではなくWebSocketで取得する。5つの取引所で20ペアのオーダーブックを200 msごとにポーリングするボットは、毎秒500リクエストを送ることになります。同じデータをWebSocketで取得すれば、数件の購読で済みます。
- 制限ヘッダーを読み取り、取引所に止められる前に自ら減速する。上限の80%に達した時点でペースを落とすボットは、BANされることがありません。
- トラフィックを分離する。ボットごとに別々のAPIキー（またはサブアカウント）を使えば、暴走したスクリプトが取引用のキーをブロックさせることはありません。
APIキーを安全に作成する
アービトラージボットに必要なのは、残高の読み取りと発注の権限です。出金権限は一切必要ありません。出金権限のないキーが漏洩した場合でも、不利な取引による損失は起こりえますが、口座を空にされることはありません。
- 取引所ごと・ボットごとに1つのキーを作成し、ボット名とサーバー名をキーの名前にしましょう。
- 有効にするのは読み取りと現物／先物取引のみです。出金は無効のままにしてください。
- キーをVPSのIPアドレスに制限します。ほとんどの取引所はIPホワイトリストに対応しており、1つのIPに制限されたキーは他のマシンでは役に立ちません。
- シークレットはサーバー上で暗号化して保管し、スクリーンショット、チャット、共有ドキュメントには決して残さないでください。
- 担当者の変更、サーバーの移行、漏洩の疑いがあった場合はキーをローテーションし、使わなくなったキーは削除しましょう。
- 戦略を分ける場合はサブアカウントを使いましょう。残高とレート制限を分離できます。
レイテンシの発生源と短縮方法
取引所で価格が変わってから注文が約定するまでに、時間は5つの段階で消費されます。マーケットの更新がサーバーに届く、ボットが価格差を検知する、署名済みの注文が送り返される、取引所がマッチングする、そして約定確認が戻ってくる、の5つです。よく作られたボットであれば、処理にかかる時間は数ミリ秒です。大半を占めるのは通常ネットワークです。
- ボットを取引所の近くでホストする。大手取引所の多くは、マッチングエンジンを特定のクラウドリージョン（東京、シンガポール、香港が多い）で運用しています。同じリージョンのVPSを使えば、ラウンドトリップ時間を数十ミリ秒から数ミリ秒に短縮できます。測定方法は当社のVPS速度ガイドで解説しています。
- 複数の取引所を使う戦略では、平均ではなく遅い方のレッグを最小化できる場所を選びましょう。取引の速さは、最も遅い約定で決まるからです。
- 接続を温めておく。HTTPS接続を再利用（keep-alive）し、事前に署名できるものは済ませておきましょう。注文ごとに新しいTLS接続を開くと、ラウンドトリップが丸ごと1回分増えます。
- 継続的に測定する。すべての更新について取引所のタイムスタンプをローカル時計（NTPで同期）と比較して記録し、ボットが取引に使う気配値の鮮度を追跡しましょう。
接続の信頼性を保つ
WebSocket接続は切れるものです。取引所はアイドル状態のストリームを閉じ、サーバーを再起動し、接続の存続時間を制限します。堅牢なボットはこれを前提に設計されています。
- ハートビート：pingに応答し（MEXCは通信がないまま60秒経過すると接続を閉じます）、取引所が求める場合は自分からも送信します。
- シーケンスチェック：差分型のオーダーブックストリームには更新IDが付いています。欠落があれば、壊れたオーダーブックで取引するのではなく、ローカルのオーダーブックを破棄して新しいスナップショットから再同期します。
- バックオフ付きの自動再接続：素早く再接続しつつも、短いループで繰り返さないようにします。例えばBybitは、5分間の枠内での新規接続数を制限しています。
- 古いデータへのガード：一定時間内にある通貨ペアの更新が届かなければ、ストリームが復旧するまでそのペアの取引を停止します。
- 注文状態の照合：再接続後は、新たに発注する前にRESTで未約定注文とポジションを照会し、一部だけ約定したヘッジが放置されないようにします。
- API変更の告知を追う。取引所は年に何度もエンドポイントを廃止し、制限を変更します。当社の仮想通貨取引所API変更トラッカーでは、こうした告知を1か所にまとめています。
稼働前チェックリスト
- スキャナーで、手数料控除後も利用する通貨ペアに価格差があることを確認済み。
- 取引所ごとにAPIキー1つ：取引権限のみ、出金はオフ、IPホワイトリスト設定済み。
- マーケットデータはWebSocketで取得し、REST呼び出しは注文と口座データに限定。
- レート制限ヘッダーを記録し、上限の80%に達する前にボットが減速する。
- 最も遅いレッグを最小化できるリージョンにVPSを設置し、ラウンドトリップ時間を測定済み。
- 意図的にネットワークを切断して、再接続・再同期・古いデータへのガードをテスト済み。
- 最初の実運用は最小ロットで行い、約定価格とボットが認識した価格を比較する。
接続まわりの面倒な処理はソフトウェアにお任せください
接続管理、リクエストの署名、レート制限、再接続は当社のボットに組み込まれています。まずは無料のスキャナーから始めて、戦略に合ったボットをお選びください。
よくある質問
仮想通貨アービトラージにWebSocketは必要ですか？
レイテンシアービトラージには必要です。チャンスは1秒未満しか続かず、ポーリングでは間に合いません。価格差が数秒から数分続くヘッジ（取引所間）アービトラージであればRESTで十分ですが、それでもWebSocketを使えばレート制限の消費を抑えられます。
BinanceでボットがHTTP 429や418エラーを受けるのはなぜですか？
429はリクエスト制限を超えたことを意味し、418は429の後もリクエストを続けたためにIPがBANされたことを意味します。マーケットデータの取得をWebSocketに移し、Retry-Afterヘッダーに従い、制限に達する前にペースを落としてください。
アービトラージ用のAPIキーで出金を許可すべきですか？
いいえ。取引と読み取りの権限で十分です。取引所間の資金の再配分は、手動で行うか、厳しく制限された別のプロセスで行えます。
複数の取引所間でアービトラージを行う場合、最適なサーバーの場所はどこですか？
取引の中で最も遅いレッグを最小化できる場所です。決定する前に、候補となる各リージョンから各取引所のAPIまでのラウンドトリップ時間を測定してください。
取引所のAPIはどのくらいの頻度で変更されますか？
取引所ごとに年に数回です。新しいエンドポイントの追加、旧バージョンの廃止、制限の変更などがあります。各取引所のAPI告知を購読し、当社のAPI変更トラッカーもあわせてご確認ください。
