TT の流量上限と再接続── REST の利用プランと FIX の自動回復を前提に設計する

Trading Technologies（TT）のプラットフォームに接続する処理は、REST API と FIX の 2 本立てになることが多くあります。照会や設定は REST、発注と約定の受け取りは FIX、という分け方です。この 2 本は、上限の決まり方も、切れたときの戻り方もまったく違います。片方の感覚でもう片方を組むと、REST は日中に上限で止まり、FIX は再接続のたびに同じ約定を二重に計上します。

本稿では、TT が公開している資料をもとに、REST API の流量の上限とトークンの扱い、FIX のセッションのリセットと再接続時の回復、切断時の自動取消の扱いを整理します。REST API のサービス構成は前稿で、FIX の再接続の一般論は別稿で扱っています。

REST の上限はアプリケーションキーの利用プランで決まる

TT REST API の流量の上限は、アプリケーションキーごとに契約する利用プランで決まります。2025 年 1 月に発効した TT の料金表の脚注には、次の上限が示されています。

• Low — 毎秒 5 リクエスト、1 日 15,000 リクエストまで
• Medium — 毎秒 10 リクエスト、1 日 30,000 リクエストまで
• High — 毎秒 25 リクエスト、1 日 75,000 リクエストまで

設計で効くのは、上限が毎秒と 1 日の 2 本立てで、単位がアプリケーションキーだという点です。毎秒の上限だけを見て並列度を決めると、1 日の上限に先に当たります。Low のプランで毎秒 5 件を休まず送り続ければ、1 時間足らずで 1 日分の 15,000 件を使い切ります。

対策は 3 つです。

• 送信側で毎秒の上限を守る仕組みを、キーごとに 1 か所に置く。処理ごとに個別に間隔を空ける作りは、合計で上限を超える
• 1 日の消費件数を数え、残りが少なくなったら優先度の低い照会から止める。日次の集計のような後回しにできる処理と、発注前のポジション確認のような止められない処理を分けておく
• 用途の違う処理には別のアプリケーションキーを使う。キーごとに上限が決まるので、夜間の一括取得が日中の照会の枠を食うことを避けられる

なお、料金表には上限を超えたときの応答の形は書かれていません。超過時の応答は検証環境で確かめ、どの応答でも送信を一時的に止めて待つ、という扱いにしておきます。

トークンは期限の前に取り直し、requestId を毎回付ける

REST のリクエストには、ヘッダにアプリケーションキー（x-api-key）を付け、多くの口では Authorization に Bearer と取得したトークンを付けます。トークンは、アプリケーションキーとシークレットを /token に送って取得し、応答の seconds_until_expiry が有効期間です。TT の説明は、期限が切れる前に新しいトークンを取得するよう求めています。期限切れの応答を受けてから取り直す作りは、その間の照会がすべて失敗に数えられます。

リスク・モニター・台帳（Risk、Monitor、Ledger）の口には、クエリパラメータの requestId が必須で、無いリクエストは拒否されます。形式は アプリ名-会社名-GUID で、GUID はリクエストごとに一意にします。空白や特殊文字は失敗の原因になるとされ、パラメータ名の大文字小文字も requestId のとおりに合わせます。

アプリケーションキーは、検証環境（UAT）と本番で別々に発行する必要があります。キーは、作成したログインの権限とデータへのアクセス範囲を引き継ぎます。強い権限を持つ管理者のログインでキーを作ると、そのキーも同じ範囲に届きます。用途に合った権限のログインで作成します。

FIX のセッションは週に 1 度リセットされる

TT の FIX の発注セッション（Order Routing）は、既定では接続を切っても状態が続く作りで、毎週土曜日 22:00（UTC）にリセットされます。日本時間では日曜日の朝 7 時です。管理画面（Setup）でセッションを設定するときに、毎日のリセット時刻を指定することもできます。リセットの時刻に接続したままだと、TT の FIX エンジンから Logout が送られてきます。

この Logout は障害ではなく予定された動作です。週末にも動かす処理や、暗号資産のように土日も取引がある市場へ発注する処理では、リセットの時刻に一度切られる前提で、再接続を自動にしておきます。逆に、リセットの時刻に監視が「切断」を障害として通知すると、毎週同じ時刻に誤報が出ます。予定された切断は、監視の側で時刻を指定して除外しておきます。

シーケンス番号は、このリセットで 1 に戻ります。任意の時点で戻したいときは、Logon で MsgSeqNum(34)=1 と ResetSeqNumFlag(141)=Y を送ります。

注文 ID の ClOrdID(11) は、前回のリセット以降に出した注文と、それより前のセッションから生きている GTC・期日指定の注文の範囲で、一意であることが求められます。リセットをまたいでも、生きている注文の ID とは重ねられないということです。日付を ID に含めて採番を日ごとに戻す作りは、長く生きる注文があると衝突します。

再接続すると未送信の約定が届く

TT の FIX で特徴的なのは、切断からの回復を TT 側が担う点です。再接続すると、TT の FIX エンジンはクラウド上の注文台帳を照会し、届けていなかった約定の通知を、切断前から続く番号で送ってきます。回復が終わったことは News（35=B）メッセージで知らされます。Logon で番号を 1 に戻した場合も、この回復は行われ、取りこぼした約定は続きの番号で届きます。

標準の再送要求（Resend Request）にも応じます。番号を戻したあとで再送要求が出せない場合は、REST API で約定を取得する方法が案内されています。

この動作を前提にすると、再接続後の手順は次のようになります。

• Logon のあと、News（35=B）を受け取るまで新規の発注判断を止める。回復中に届く約定は切断中に起きたもので、これを反映する前の建玉で判断すると誤る
• 約定の取り込みは、同じ約定が 2 度届いても 1 度しか計上しない作りにする。回復で届く分と、再送要求で届く分が重なることがある
• REST で約定を取得して補う場合も、同じ取り込みの処理を通す。経路ごとに別の計上処理を持つと、二重計上の原因になる

切断時の自動取消は取引所ごとに違う

FIX の接続が切れたとき、取引所に出ている注文が取り消されるかどうかは、TT ではなく取引所ごとの扱いで決まります。TT は取引所ごとの対応を一覧で公開しています。

• CME — 取引所側で設定する。All（当日・GTC・期日指定を取消）、Day（当日のみ）、None（無効）の 3 つ
• ICE — 選べない。切断すると期日指定の注文はすべて取り消される
• Eurex — TT 側で設定する。口座の設定で注文を持続型として出すと、切断しても注文は残る
• Cboe — 取引所の既定で有効。TT での設定は不要
• 大阪取引所 — 注文ごとの指定には対応しているが、TT はその指定に対応していない
• SGX — 取引所側で設定する。意図しない切断では心拍 2 回分の 90 秒後に注文が無効になる

このほか、自動取消に対応していない取引所もあります。同じ TT の接続でも、取引所によって切断後に板に残る注文が違うということです。複数の取引所に発注する処理では、取引所ごとの扱いを台帳にまとめ、再接続後の照合でどの注文が残っているはずかを判断する材料にします。

まとめ

TT REST API の上限は、アプリケーションキーごとの利用プランで毎秒と 1 日の 2 本立てで決まり、Low なら毎秒 5 件・1 日 15,000 件です。送信の制御はキーごとに 1 か所に置き、1 日の消費を数え、用途ごとにキーを分けます。トークンは期限の前に取り直し、requestId を毎回付けます。FIX のセッションは毎週土曜 22:00（UTC）にリセットされ、再接続すると未送信の約定が続きの番号で届き、News（35=B）で回復の完了が分かります。回復が終わるまで新規の判断を止め、約定の取り込みは重複に強くします。切断時の自動取消は取引所ごとに違うので、台帳で管理します。

金融テクノロジー総合研究所では、発注・執行基盤の設計と実装を受託しています。TT の REST と FIX を組み合わせた構成の設計や、既存の接続の切断時の挙動の点検からご相談いただけます。Trading Technologies API 対応の詳細もあわせてご覧ください。ご相談はお問い合わせよりご連絡ください。

参考資料

• Pricing Details 2025｜Trading Technologies（TT REST API の利用プランと、脚注の毎秒・1 日の上限。2025 年 1 月 1 日発効）
• TT REST API — Authentication and request IDs（ヘッダ、トークンの取得と seconds_until_expiry、requestId の形式、UAT と本番のキー）
• TT FIX — FIX Session Management（Order Routing のセッションのリセット、番号のリセット、再接続時の回復と News、再送要求）
• TT FIX — Operational Notes（ClOrdID の一意性の範囲、回復の流れ）
• TT Setup — Cancel on Disconnect Support（取引所ごとの切断時の自動取消の対応と設定の主体）

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