取引所 API 連携でよくある落とし穴、いくつ経験しましたか

クオンツ取引システムの開発において、取引所APIとの連携は避けて通れない工程であり、同時に工数が最も過小評価されやすい部分でもあります。表面的には注文・照会用のRESTエンドポイントがいくつかと、相場購読用のWebSocketがあるだけに見えますが、実際に手を動かすと細部の課題が非常に多いことに気づきます。 1つ目の落とし穴はレート制限です。ほぼすべての取引所がAPI呼び出し頻度を制限しており、多くの場合エンドポイントごとに重みが異なります。発注、キャンセル、照会それぞれが別枠の配分を消費します。リクエストのスロットリングやキューイング機構を整備していないと、高頻度呼び出し時にレート制限に引っかかったり、IPやAPIキーが一時的にブロックされたりします。これは負荷テストの段階で事前に検証しておくべきです。 2つ目は注文状態の結果整合性です。発注リクエストが成功を返しても、それは約定エンジンでの処理が完了したことを意味しません。取引所に受理されてから実際の約定・拒否までにはタイムラグがあり、さらにREST照会とWebSocketプッシュの状態更新が同期していない場合があります。システム設計上は、いずれかのデータソースを正とする統一的な注文ステートマシンを用意し、状態の巻き戻りや重複プッシュにも対処する必要があります。 3つ目は切断・再接続です。WebSocket接続はネットワークの揺らぎや取引所側の切断により途切れることがあります。再接続後は再購読が必要なだけでなく、切断中に取りこぼした可能性のある相場や注文更新を補完する仕組みが必要です。そうしないと、古い、あるいは不完全なデータに基づいて意思決定してしまいます。 4つ目は冪等性です。ネットワークタイムアウト後に発注をリトライすべきかどうかは、非常にミスが起きやすいポイントです。元のリクエストが実は成功していた場合、リトライは重複発注につながります。クライアント側でユニークな注文IDを生成し、取引所側でそのIDによる重複排除をサポートしてもらうのが標準的な対処法です。 5つ目は価格精度と最小単位ルールです。取引ペアごとに価格の精度、数量の精度、最小想定元本額が異なるため、発注前に取引所のルールに従って価格と数量を丸める必要があります。これを怠ると注文はそのまま拒否されます。 6つ目は時刻同期です。多くの取引所の署名方式は、リクエストのタイムスタンプが一定の許容範囲内であることを要求しており、サーバー時刻のずれはリクエスト拒否につながるため、定期的なNTP補正が必要です。 これらの問題は単体で見ればどれも複雑ではありませんが、積み重なると連携の安定性を左右する主要因になります。システム設計の初期段階から十分なテストとフォールトトレランス設計に投資する価値があります。