JPX への接続は回線から始まる── arrownet と、注文・相場のインターフェース選択

取引所への接続は、API の話から始まりません。回線の話から始まります。東証の現物売買システム arrowhead も、大阪取引所のデリバティブ売買システム J-GATE も、JPX が提供するネットワーク基盤 arrownet を経由して接続します。ここを前提に置かずに「API をどう叩くか」から検討を始めると、実装が終わってから接続できないことに気づきます。

本稿では、arrownet を起点に、注文と相場情報それぞれのインターフェース選択をどう考えるかを整理します。参照した一次資料は末尾に挙げています。

まず arrownet

arrownet は、JPX の売買システムと相場情報システムを市場利用者と結ぶ高信頼のネットワークです。高速大容量の通信に加え、複数のアクセスポイントとセカンダリセンターへの接続によって、業務継続性が確保される構成になっています。

設計上、ここで決まることが 3 つあります。

どこから繋ぐか。アクセスポイントの選択は、レイテンシと費用の両方に効きます。速度が要件になる用途ではコロケーションを検討することになり、そうでなければアクセスポイント経由で足ります。この判断は業務要件から降りてくるもので、実装側で後から変えられるものではありません。

冗長構成をどう取るか。セカンダリセンターへの接続を含めるかどうかは、止まったときに何が起きるかで決めます。回線の冗長化は手配に時間がかかるため、要否の判断は最初に済ませます。

いつ手配するか。これが実務では最も効きます。回線の手配と接続試験には日程がかかり、コードの完成を待ってから動き始めると、そこから数か月が必要になります。設計と並行して手配を始めるのが前提です。

JPX が公開している構成図を見ると、この 3 点がそのまま図の要素として現れています。左からの発注がアクセスポイントを通って入り、10G の基幹リング網でプライマリセンタとセカンダリセンタが結ばれる。凡例では、通常の発注の流れとは別に、コロケーションサービスを使う場合とプロキシミティサービスを使う場合の流れが分けて描かれています。速度が要件になるかどうかで、図の中のどの線を通ることになるかが変わる、という話です。

注文と相場は別々に選ぶ

J-GATE を例にとると、接続方式は注文用と相場情報用で分かれています。

注文用は 2 種類です。API 接続は、新規注文と訂正・取消注文のほか、相場情報等も取得できます。OUCH 接続は、新規注文と訂正・取消注文の送信等に特化した接続方式です。

相場情報用も 2 種類です。API 接続で受信する方法と、ITCH 接続を使う方法があります。ITCH 接続は API との併用を前提とした、相場情報の受信に特化した接続方式です。

ここから読み取れる構造は単純です。API 接続だけで注文も相場も賄える。ただし特化した方式を併用すれば、それぞれの用途で有利になる。特化型の方式を選ぶかどうかは、性能要件と実装コストの釣り合いで決まります。

判断の目安としては、注文の応答時間が業務上の競争力に直結する用途なら特化型を検討し、そうでなければ API 接続で始めるのが素直です。両方を同時に組むと、実装量も試験の量も増えます。後から特化型を足せる構造にしておくほうが、最初から全部を組むより現実的です。

現物側の構成

東証の現物取引では、売買システムとして arrowhead と ToSTNeT があり、相場情報は FLEX が担います。arrowhead は 2010 年 1 月に稼働を開始し、第 4 世代にあたる arrowhead4.0 が 2024 年 11 月に稼働しています。

相場情報については、配信の粒度が選べます。従来の配信は値段ごとの板情報ですが、注文ごとの情報を配信する方式もあります。後者のほうが細かい情報を得られる一方、当然ながら流量が大きくなります。

ここでの判断も性能と費用の釣り合いです。注文ごとの情報が業務上必要かを先に確認します。「細かいほうがよい」という理由で選ぶと、受け側の処理能力と回線容量の両方で無理が出ます。流量の想定は、選択する前に見積もっておく項目です。

設計で先に決めておくこと

接続仕様書の入手。実装の根拠になるのは接続仕様書です。JPX のサービスデスクから入手する手続きがあり、これも日程に含まれます。仕様書を見ずに一般論で設計を進めると、後から作り直す範囲が広くなります。

試験の枠。接続試験には日程と枠の確保が要ります。実装が終わってから枠を取ろうとすると待ちが発生します。回線の手配と同様、早い段階で日程を押さえます。

相場情報の受け側。マルチキャストで流れてくる相場情報を取りこぼさずに処理できるかは、受け側の作りで決まります。処理が追いつかないときに何を捨てるか、遅れをどう検知するかを、実装前に決めておきます。ここを決めずに作ると、混雑時に静かにデータが欠けます。

システム更改の追随。arrowhead も J-GATE も定期的に更改されます。更改のたびに仕様の変更が入り、対応の日程が外から降ってきます。更改への追随を運用の定常業務として組み込んでおく必要があります。一度作って終わりにできる接続ではありません。

まとめ

JPX への接続は、arrownet の手配が起点です。どこから繋ぐか、冗長をどう取るか、いつ手配するか。この 3 点が実装より先に決まっている必要があります。注文と相場情報はそれぞれ方式が分かれており、API 接続だけでも成立する一方、特化型の方式を併用すれば用途ごとに有利になります。最初から全部を組むより、後から足せる構造にしておくのが現実的です。相場情報の粒度は流量と直結するので、選ぶ前に見積もる。そして更改への追随は定常業務として抱える。この前提を共有できていれば、日程の見通しは大きく変わります。

金融テクノロジー総合研究所では、取引所接続の設計・実装・接続試験の支援を受託しています。方式選定と日程の組み立てからご相談いただけます。arrowhead 対応とJ-GATE 対応の詳細もあわせてご覧ください。ご相談はお問い合わせよりご連絡ください。

参考資料

• JPX, ネットワーク — 概要（arrownet の位置づけ、複数アクセスポイントとセカンダリセンター）
• JPX サービスデスク FAQ — 【J-GATE3.0】J-GATE との接続方式（注文用の API 接続 / OUCH 接続、相場情報用の API 接続 / ITCH 接続。本稿の方式の説明はここが出典）
• JPX, システム — 現物取引 サービス概要（arrowhead / ToSTNeT / FLEX）
• JPX, システム — デリバティブ取引 サービス概要（J-GATE の基盤と対象商品）
• JPX, システム — コネクティビティサービス（コロケーション、アクセスポイント）

FTL の技術スタックと受託開発の進め方は FTLの技術とは？ にまとめています。