ブローカー取引プラットフォームと API
本記事ではクオンツ取引で一般的に使用されるブローカープラットフォームと API インターフェースを紹介します。機関レベルの Prime Broker からリテールレベルの取引 API まで。
一、Prime Broker(プライムブローカー)
どのブローカーのプラットフォームを使用するか?
Renaissance 等のトップクオンツヘッジファンドはリテールブローカープラットフォーム(IBKR リテール版や富途など)を使用せず、Prime Brokers(プライムブローカー) を通じて取引を執行しています。
主な Prime Brokers:
- Goldman Sachs
- Morgan Stanley
- JPMorgan Chase
- IBKR Prime Services(中小規模ファンド向け。注意:これは IBKR の機関向けサービスで、リテール版 TWS とは異なります)
これらの Prime Brokers はファイナンス、証券貸借、清算、報告等のサービスを提供し、高頻度/アルゴリズム取引の低レイテンシー執行に対応しています。Renaissance は複数の Prime Brokers を使用してリスクを分散し、取引所へのカスタム接続(コロケーション、低レイテンシー回線)を構築している可能性があります。
二、リテールレベルのクオンツ API
富途牛牛(Futu NiuNiu)にはこのような API サポートがあるか?
はい、富途牛牛は強力な OpenAPI を提供し、プログラムトレーディングと自動発注に対応しています。
Futu OpenAPI はクオンツ投資向けに設計されており、以下を含みます:
- 相場インターフェース(リアルタイムクオート、ローソク足、tick データ等)
- 取引インターフェース(発注、取消、変更、注文/ポジション照会等)
対応市場:香港株式、米国株式、A株通、先物、オプション等。
対応言語:Python、Java、C#、C++、JavaScript 等(公式 SDK あり)。
アーキテクチャ:ローカル/クラウドでゲートウェイプログラム Futu OpenD を実行し、API 経由で接続。実取引とシミュレーション取引に対応。
2025年の重要な変化:中国の域外投資規制強化を受け、富途・Tiger Brokers は2025年9月から中国本土居住者の新規口座開設を大幅に制限した——富途は現時点で香港・マカオの身分証でのみ開設可能、Tiger は海外就労・居住証明での開設を停止。既存口座の OpenAPI はそのまま使えるが、口座を持たず海外身分もない場合、この「個人で香港・米国株クオンツ」ルートは事実上閉じている。
日本の証券会社 API(2026年時点)
日本株を API で取引するなら実質三択:
| 証券会社 | インターフェース | 費用 | 制約 |
|---|---|---|---|
| 三菱UFJ eスマート証券(旧 auカブコム) | kabuステーション API(REST + WebSocket、板・歩み値 PUSH、発注可) | Professional プラン適用で無料 | Windows アプリ「kabuステーション」の常時起動、同一 IP からのみ |
| 楽天証券 | マーケットスピード II RSS(Excel アドイン、発注関数あり) | 無料 | Windows + Excel 限定。REST API ではない |
| IB 証券(日本法人) | TWS API(Python/Java/C++)で日本株・225先物・TOPIX 先物 | マーケットデータは取引所別課金 | 日本居住者は IBKR Pro のみ |
SBI 証券に個人向け REST API はない(先物・オプションの API 接続は認定業者のみ)。データ側は J-Quants API(JPX 公式)と組み合わせるのが2026年時点の定石。
多くの個人クオンツや開発者がこれを使用してアルゴリズム取引システム(ダブル移動平均戦略、高頻度フレームワーク等)を構築しており、コミュニティには多数のオープンソースプロジェクト(futu-api Python パッケージ、futu_algo フレームワーク等)があります。
制約:リテール/個人クオンツに適しており、機関レベルの超高頻度には不向き(レイテンシーが高く、コロケーション不可)ですが、中低頻度戦略には非常に使いやすく、無料/低コストです。
三、Interactive Brokers:イベント駆動型執行のケーススタディ
3.1 アーキテクチャとインターフェース境界
IBKR は複数の独立したインターフェースを提供する。TWS API は TCP socket 上のメッセージプロトコルで、クライアントは Trader Workstation または IB Gateway に接続し、そこからブローカーセッションを維持する。FIX 接続ではない。Client Portal と機関向け FIX は認証、セッション、権限、運用契約が異なるため、曖昧な「IB API」アダプターではなく、対象を明示して設計する。
この構造から2つの原則が導かれる:
- 応答を同期関数の戻り値ではなく、非同期イベントとして扱う。
- クライアント送信、ゲートウェイ受信、ブローカー確認、約定、クライアント・コールバックを別々に計測し、普遍的な往復レイテンシーを掲げない。
ネットワーク配置が変えるのは遅延の一部だけであり、ブローカーのルーティング、市場状態、キュー、スロットリング、取引所遅延は残る。VPS の利用だけでは HFT 適性の証拠にならない。
3.2 注文ライフサイクルと冪等性
再試行をまたいで安定する内部 intent ID を発行し、orderId や permId などのブローカー識別子へ対応付け、送信前に永続化する。状態は少なくとも、作成、送信、受付、部分約定、全約定、取消待ち、取消済み、拒否、未知/照合中を持つ。
orderStatus だけから約定を推測しない。IBKR は execDetails も監視するよう案内しており、部分約定ごとに別の execId がある。手数料は別の commissionReport メッセージで届き、execId で約定と関連付けられるが、固定遅延は保証されない。重複・再生イベントがポジション、現金、費用、P&L を二重計上しないよう、更新は冪等にする。
3.3 再接続は照合であり、「接続済み=正常」ではない
接続メッセージは、接続喪失、復旧したが市場データ購読が失われた状態、購読が維持された復旧を区別する。切断またはプロセス再起動後は:
- セッションを分類するまで新しいリスクを作らない;
- 購読喪失を示すコードなら市場データを再要求する;
- 未約定注文、最近の約定、ポジション/口座値、現金を問い合わせる;
- 永続化した意図と既知の約定に照合する;
- 一致しない記録を黙って採用・削除せず分類する;
- 明示的な不変条件が通った後にだけ再開する。
ローカル状態が権威を持つのはプログラムの意図であり、ブローカー報告の注文、約定、ポジション、現金が権威を持つのは外部口座で実際に起きた事実である。安全なシステムには両方が必要だ。
3.4 ペーシングと市場データ上限
TWS API には pacing 制限がある。IBKR は一般リクエスト上限を口座の市場データライン数の関数として説明し、デフォルト100ラインの例では毎秒50リクエストとなる。履歴データ要求とアクティブ ticker 購読には追加制限がある。これらを戦略コードに散在する定数にせず、現在の権限を読み、集中スロットリング、有界バックオフ、キュー深度と拒否数の監視を行う。
3.5 ペーパー取引は必要だが、約定モデルではない
IBKR はペーパー環境がライブより多くのシミュレーション技術を使い、注文執行動作が異なりうると説明している。ペーパー取引は API 接続、銘柄解決、状態遷移、権限、復旧訓練に有用だが、キュー位置、インパクト、流動性、借株、ライブ約定品質を証明しない。履歴リプレイ、ペーパー、シャドー観測を経て、別途承認された小さなライブ上限で検証する。
3.6 安全運用チェックリスト
- 一意で永続化された intent ID とブローカー ID の対応
- 注文、約定、手数料、口座イベントの冪等処理
- 部分約定、取消/変更、拒否、未知状態のテスト
- 再接続時の注文、約定、ポジション、現金照合訓練
- 集中したリクエスト制御と市場データ権限確認
- 版管理された契約定義、取引カレンダー、通貨、手数料規則
- 照合完了まで読み取り専用の復旧モード
- 外部口座の収束を証明する独立した kill/flatten 手順
- ペーパーとライブの差を文書化し、小さな上限で確認
- 日次ブローカー明細照合と未解消差異アラート