Works

実績

どんな相談を受けて、何をしたか。事業領域ごとにまとめています。

守秘義務のため、社名と具体的な数値は伏せています。案件の性質上、規模や成果を数字で示すことはしていません。

データセンター
Financial Technology

金融テクノロジー開発/運用支援

要件定義から本番運用まで、同じチームで受け持ちます

この領域の詳細

国内の金融機関

クラウド移行に合わせた可用性設計の見直し

課題
可用性の目標値は決まっていたものの、何をもって停止とみなすかが定義されておらず、構成の選択肢を絞れない状態でした。
対応
  • 業務の成否で停止を定義し直し、機能ごとに整合性と可用性の優先順位を分けた
  • 依存関係を必須と縮退可能に切り分け、分散トレーシングで実際の呼び出し関係を確認した
  • 復旧手順を実際に動かして所要時間を測り、手順書と実態のずれを潰したうえで引き渡した
技術
クラウド基盤 ／ 分散トレーシング ／ SRE / エラーバジェット

資産運用会社

障害の切り分けを速くするための計測基盤

課題
障害のたびに原因の切り分けへ時間がかかり、どのログを見ればよいかが担当者の経験に依存していました。
対応
  • ログ・メトリクス・トレースを相関させ、1 つの障害を 1 本の線で追えるようにした
  • 検知から切り分けまでの導線を決め、当番が最初に見る画面を用意した
  • エラーバジェットの運用ルールを、リリース判断と結びつく形で設計した
技術
オブザーバビリティ ／ SRE ／ クラウド基盤
複数モニタに板情報とチャートを表示したトレーディングデスクの手元
Trading Systems

トレーディングシステム開発/自動売買ツール開発

接続先の差異を吸収し、本番運用に耐える構成で作ります

この領域の詳細

国内の証券会社

FIX 接続の発注基盤

課題
接続先ごとの差異が業務ロジックへ漏れており、接続先を増やすたびに既存の実装へ手が入る状態でした。
対応
  • 共通のドメインモデルを中央に置き、カウンターパーティ固有の仕様は接続アダプタへ閉じ込めた
  • 注文の冪等性、レート制限時の縮退、リスク限度の自動執行を実装した
  • 約定と残高の突合を、リアルタイム処理とは別の経路で日次に回す形にした
技術
FIX API ／ arrowhead ／ J-GATE（JPX 先物）

運用会社

実運用に接続できる検証基盤の整備

課題
バックテストでは良い成績が出るのに実運用では再現しない、という相談でした。検証の時点管理と執行可能性が織り込まれていませんでした。
対応
  • 時点管理されたデータを用意し、検証時に将来の情報が混入しない構成にした
  • 取引コストと市場インパクトを織り込んだ約定シミュレーションを組み込んだ
  • 同じ入力から同じ結果が出ることを、検証環境の要件として先に固めた
技術
市場データ基盤 ／ バックテスト ／ Bloomberg API

暗号資産の運用事業者

複数取引所への同時接続と縮退制御

課題
取引所ごとに API の仕様とレート制限が異なり、片方の障害が全体の停止につながる構成になっていました。
対応
  • 接続先ごとの差異をアダプタへ閉じ込め、業務ロジックからは同じ形で扱えるようにした
  • レート制限に達したときの縮退動作と、再接続時の状態復帰を設計した
  • 板情報と約定の取得経路を分け、片方の遅延がもう片方を巻き込まないようにした
技術
暗号資産取引所 API ／ Crypto DEX API ／ Hyperliquid API
複数のトレーダーが並ぶフロアで、実績ダッシュボードを確認する担当者
Prop Firm

プロップファーム事業支援

評価・監視・精算の基盤を、事業の設計段階から

この領域の詳細

プロップファーム運営事業者

トレーダー評価プログラムの基盤

課題
評価の合否と失格の条件が文章でしか決まっておらず、判定の根拠を後から示せない状態でした。
対応
  • 目標・期間・最大損失をルールの設定として持たせ、ルール変更を遡及させない構成にした
  • 判定に使った値と、その時点で参照していたルールの版を記録に残す形にした
  • トレーダー向けの進捗表示と、運営側が根拠を確認できる画面を用意した
技術
評価プログラム基盤 ／ ブローカー接続 ／ FIX API

プロップファーム運営事業者

ドローダウン監視を発注経路へ組み込む

課題
ドローダウンの判定が日次バッチで、限度を超えた取引がそのまま成立してしまう状態でした。
対応
  • 限度の判定を発注経路そのものへ組み込み、超過する注文を成立前に止めた
  • 建玉上限と損失限度の判定を、約定の反映遅延を考慮した形で設計した
  • 止めた注文の理由を記録し、後から説明できるようにした
技術
リスク管理 ／ ブローカー接続 ／ 約定・残高の突合

プロップファーム運営事業者

損益・報酬の計算と不正検知

課題
報酬計算の基準日と権利確定の関係が曖昧で、期中のルール変更をどう扱うかが決まっていませんでした。
対応
  • 計算基準日と権利確定の関係を整理し、計算ロジックの版を記録に残す実装にした
  • 訂正が必要になったときの手順を、実装より先に決めた
  • 複数口座間の相殺取引や、指標発表前後に集中する取引を検出の対象に載せた
技術
損益・報酬計算 ／ 不正検知 ／ Trading Technologies API

近い案件があればお話しできます

ここに載せていない領域でも、まず課題を伺ったうえで進め方を提案します。技術スタックは FTLの技術とは？ にまとめています。

お問い合わせ