Trading Technologies（TT）REST API の組み立て方── サービスが分かれている前提で設計する

Trading Technologies（TT）の REST API を使いたい、という相談で最初に確認するのは「何をしたいか」です。当たり前に聞こえますが、TT の API は用途ごとにサービスが分かれているため、この確認を飛ばすと必要のないサービスまで権限を取りに行ったり、逆に途中で足りないことに気づいたりします。

単一のエンドポイントに何でも投げる形の API とは組み立て方が違います。本稿では、サービスの分かれ方、認証と環境の扱い、設計上つまずきやすい箇所を整理します。参照した一次資料は末尾に挙げています。

サービスは用途で分かれている

TT REST API は、次のような単位でサービスが分かれています。

• ttid ── アプリケーションを認証し、TT プラットフォームの資源へのアクセスを認可する
• ttpds ── 取引所・商品・銘柄に関する情報を取得する
• ttledger ── 注文の詳細と取引履歴を参照する
• ttmonitor ── ポジション、与信枠と使用状況、日中始値（SOD）の記録を参照する
• ttaccount ── 口座単位のリスク限度、取引権限、ユーザーを扱う
• ttuser ── リスク限度、相場情報のアクセス権、銘柄・商品設定を扱う
• ttgroup ── リスクグループ・リスク口座・ユーザーグループの限度を扱う
• ttsetup ── 会社単位の証拠金、注文タグの既定値、取引所接続、組織を扱う
• ttbacktest ── ADL アルゴのバックテストを開始・停止し、結果を取得する

この分かれ方は、そのまま権限と責務の境界になっています。相場と銘柄マスタが欲しいだけなら ttpds で足り、約定の照合をしたいなら ttledger、リスク管理の画面を作るなら ttmonitor と ttaccount が要る、という具合です。

設計の最初にやるべきことは、作りたい機能をこのサービス単位へ割り付けることです。ここが決まれば、必要な権限の申請も、実装の分割も、その線に沿って進められます。逆に「とりあえず全部」と進めると、権限の手配が重くなるうえ、実装も責務が混ざります。

認証は ttid を通す

認証は ttid が担います。アプリケーション用の秘密情報は 00000000-0000-0000-0000-000000000000:11111111-1111-1111-1111-111111111111 のようにコロンで区切られた形で、前半がアプリケーションキーです。この秘密情報を使ってトークンを取得し、以降のリクエストに添えます。

実際のリクエストでは、アプリケーションキーとトークンの両方をヘッダに載せます。ttmonitor のドキュメントには、トークンを入れる際に Bearer と半角スペースを手で連結する必要があると明記されています。SDK が面倒を見てくれる前提で書くと、ここで 401 が返り続けます。

実装上の注意は 2 点です。ひとつは、トークンの取得を毎回行わないこと。有効期間のあいだは再利用し、期限が近づいたら取り直す作りにします。もうひとつは、秘密情報をコードに置かないこと。コロン区切りの文字列全体が資格情報なので、前半だけならログに出してよい、という扱いにはできません。

環境を最初から分ける

TT はテスト用と本番用でベース URL が分かれています。ttledger であれば、開発・テスト用が https://ttrestapi.trade.tt/ttledger/ext_uat_cert、 本番用が https://ttrestapi.trade.tt/ttledger/ext_prod_live です。 ttmonitor も同じ形で .../ttmonitor/ext_uat_cert と .../ttmonitor/ext_prod_live に分かれます。

つまり、サービス名と環境名がパスに入る構造です。ここを文字列連結で組み立てる実装をすると、環境の切り替えが漏れる箇所が必ず出ます。ベース URL の組み立てを 1 か所に閉じ、環境は設定として外から与える形にしておきます。

公式ドキュメントは開発・テストには UAT 環境を使うよう案内しています。本番の資格情報で検証を始めると、うまくいかなかったときの切り分けが難しくなります。

設計で効いてくるところ

銘柄マスタの取り扱い。ttpds から取れる取引所・商品・銘柄の情報は、毎回取りに行くものではありません。日次で取得してこちらで保持し、差分を見る形にします。発注のたびにマスタを引きに行く作りは、遅いうえに相手側への負荷にもなります。

約定照合の突き合わせ単位。ttledger から取る履歴を自社の記録と突き合わせるとき、何をキーにするかを先に決めます。ここが曖昧なまま作ると、再取得したときに二重計上が起きます。取得は冪等に、突き合わせは一意なキーで、という原則を最初から通しておきます。

レート制限の扱い。公開ドキュメントに明示された数値がある種類の API ではないため、実測して決めることになります。並列度と間隔を設定値にしておき、様子を見ながら詰められる形にしておくのが安全です。最初から並列度を上げて走らせ、詰まってから直すのは順序が逆です。

部分実装のライブラリに注意。コミュニティ製のクライアントはサービスごとに実装状況が異なります。参照実装として読むには有用ですが、必要なサービスが未実装であることは珍しくありません。採用の前に、使いたいサービスが実装されているかを確認します。

まとめ

TT の REST API は、単一の窓口に何でも投げる形ではなく、用途ごとに分かれたサービスの集合です。したがって設計の出発点は「どのサービスを使うか」の割り付けであり、そこが決まれば権限の手配も実装の分割も素直に進みます。認証は ttid を通し、トークンは使い回す。環境はパスに含まれるので組み立てを 1 か所に閉じる。マスタは持つ、照合は冪等に、レート制限は実測で決める。この順で進めれば、接続後に作り直す範囲はかなり小さくできます。

金融テクノロジー総合研究所では、発注・執行基盤の設計と実装を受託しています。既存構成の点検や、複数ベンダーをまとめる基盤の設計からご相談いただけます。Trading Technologies API 対応の詳細もあわせてご覧ください。ご相談はお問い合わせよりご連絡ください。

参考資料

• Introduction to TT REST API｜TT Help Library（サービス構成の出典）
• ttledger Documentation（ext_uat_cert / ext_prod_live のベース URL）
• ttmonitor Documentation（アプリケーションキーとトークンのヘッダ指定、Bearer の連結）
• ttpds Documentation（取引所・商品・銘柄の情報）
• isaaclm/tt-rest-api（コミュニティ製クライアント。各サービスの用途と実装状況、秘密情報の形式）

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