- NYSEとNASDAQに上場する5,500銘柄以上をリアルタイムで監視し、自動売買を行うリテール向けトレーディングボットをGo言語で構築した個人プロジェクトの事例
- 当初はすぐに損失を出すレベルだったが、長年の試行錯誤を経て損益分岐点レベルまで発展し、ときには利益を出せる段階にまで進化
- データプロバイダー、Goアプリケーション、ブローカーという3つの中核コンポーネントで構成され、市場のオープン・クローズ時には毎秒6万件以上のイベントをインメモリで処理
- ランダム買いによるシステムテスト、ティックバーベースの独自ローソク足生成、インメモリ化など、実運用から得た教訓が核心
- 金融・プログラミング・データ分析が交差する領域で、個人トレーディングプラットフォーム構築の現実的な複雑さと可能性を示す事例
プロジェクトの背景と動機
- 株式市場全体で約500件の短期トレードを自動実行・管理し、各取引から小さな利益を得るトレンドフォローのアイデアから出発
- 手動トレーディングの限界から自動化を開始
- 単一銘柄に全額投資するリスクは極めて高かった一方で、数十件の短期ベットを同時に監視するのは人間の能力を超えていた
- 流動性の高い銘柄でのみ素早いエントリーとイグジットが可能であり、高速約定のためには少量の買いが必要だった
- ポジション管理も大きな課題で、25件以上の同時ベットでエントリー・イグジットのタイミングを合わせるのは非常に複雑
- 資金規模が大きくなるほどベット数も増やす必要があるスケーラビリティの問題が存在
- スプレッド、手数料、スリッページ、API手数料、税金などの取引コストを素早く計算し、取引の妥当性を判断する必要があった
ソリューション構成
- NYSEとNASDAQの5,500銘柄以上をリアルタイムで監視し、高速なトレーディング判断を下す自動化ツールを長年にわたって開発
- Linux環境の高性能ゲーミングシステムで稼働: 16コア、128GB RAM、8TB NVMeストレージ、1Gbpsインターネット
-
3つの中核コンポーネント
- Data Provider (Massive.com): 市場全体の過去データとリアルタイムデータをカバーし、開発者フレンドリーで直感的なAPIとドキュメントを提供。人為的な制限なしに全市場データへアクセスできるシンプルな料金モデル
- Goアプリケーション: データフィードを収集・解釈し、算出したトレーディング判断に基づいて買い・売り注文をブローカーAPIへ送信する中核エンジン
- Broker (Interactive Brokers): シンプルなAPIを提供し、注文執行を担当
-
Go言語を選んだ理由
- ヘッジファンド業界はC++とPythonに依存しているが、長年Goを使ってきたことに加え、データストリーム処理とAPI連携に優れた適性を示したため採用
Goアプリケーションの主要機能
-
Data Ingestion Loop
- Massive.comを通じて5,500銘柄以上のリアルタイムデータを継続的に収集
- 当初はデータベースへの保存を試みたが、市場の寄り付き・引け時に毎秒6万件以上のイベントを処理できず、全面的にインメモリ方式へ移行
-
Build Our View Of The Stock Market
- 収集したデータで市場全体のリアルタイムなインメモリビューを構築（価格、スプレッド、取引活動などを追跡）
- 主要ニュースより先に機会を捉えて取引可能
- プレマーケット、通常市場、アフターアワーの取引活動にアクセス可能
-
BUY Signal Loop
- 機会を捉えるとブローカーAPIへ買い注文リクエストを送信
- 単純なトリガーではなく、スプレッドベースの利益推定、必要株数の決定、手数料・税金の反映などの事前計算を実施
- 価格変動、部分約定、注文キャンセルなどの状況ロジックを含む
-
Position Tracking System
- 保有ポジションを継続監視するループで、ポジションテーブルと現在価格をリアルタイム比較して損益を追跡
- GUIを通じて取引トリガーの理由、現在状態、売却タイミングを確認可能
- BUY・SELLロジックの洗練に重要な役割を果たした
-
SELL Signal Loop
- 十分な利益または過大な損失を検知すると、ブローカーAPIで売り注文を実行
- 高速に動く銘柄の価格更新、部分約定処理などの複雑なロジックを含む
Webインターフェースとスクリーンショット
- 組み込みWebインターフェースを通じて、すべてのデータ構造の探索、データ可視化、取引トリガーの理由や現在状態の確認が可能
- 5,500以上のティッカーの価格・スプレッドなどを表示する市場全体の概要画面
- 個別シンボルのページ（例: Tesla TSLA）でティックバーと関連情報を表示
- 勝率/敗率と現在のオープンポジションを示すインターフェース（例のセッションでは約**-$900の損失**を記録）
- リアルタイム取引のメタデータとチャートを表示する画面（買いポイントをオレンジのラインで表示）
- リアルタイムイベント（買い・売り注文）を記録するコンソールログ画面
戦略開発とバックテスト
- Goアプリケーション、戦略、バックテストを3つの別個の中核要素と見なす
- 議論の大半は戦略（平均回帰、トレンドフォロー、線形回帰など）とバックテストに集中するが、リアルタイムのイントラデイトレーディングにおける戦略実装の実務とロジスティクスは見落とされがち
- Massive.comの広範な過去約定・気配データを活用し、Pythonで戦略探索とバックテストを実施（8TB NVMeストレージを使う理由）
- バックテストは「バックミラーを見ながら前進運転すること」にたとえられるが、スプレッド・税金・手数料・エントリー・イグジット地点の判断根拠として有用な検証手段
- 戦略開発とバックテストで得たインサイトがBUY Signal Loopのロジックへ変換される
コード例
- 高水準の擬似コードと実際のGoコードサンプルを含む（実アプリは約7,000行規模）
- 主なデータ構造: TrackedSymbols（全シンボルマップ、取引有効化フラグ、グローバルロック）、Symbol（生の約定・気配データ、Aggregate、Positionなど）、TradeEvent、QuoteEvent、Aggregate、Position
- メインループ構成
- WebSocket接続で約定・気配データを収集しイベントをパース
- シンボルマップに保存後、約定+気配データをAggregateに統合
- Goチャネルを通じて買い・売りロジックへシグナルを伝達
- HTTPサーバーで全シンボル、ポジション、カスタムウォッチリストの照会機能を提供
主要な教訓 (Lessons Learned)
-
抽象化の理解
- NYSEとNASDAQは単一システムではなく、19以上の取引所で構成される大規模分散システム
- ローソク足データは生の約定（ティック）データから作られる巨大な抽象化であり、これを深く理解することが必須
- プレマーケット、通常市場、アフターアワーなど市場の時間帯ごとに異なるルールが適用される
-
注文管理
- 単純に買い・売り注文を送るだけでなく、事前のポジションサイジング、高速売買能力、25件以上のポジション同時管理、税金・手数料計算、スリッページ管理、注文状態の監視など、すべてが成功するトレーディングに寄与する
-
エッジケース
- 注文執行、追跡、修正、キャンセル、部分約定、市場取引停止など無数のエッジケースがあり、見落とすと金銭的損失が発生
- 実資金の代わりに**ペーパートレーディング（シミュレーション）**でテストすることが必須
- プレマーケットで40%急騰した銘柄を高値で買った直後に急落し、売り注文の調整失敗で数分以内に40%損失した経験。プレマーケット・アフターアワーは通常市場とルールが異なるため、極端な変動が素早く発生する
-
ランダム買いの活用
- 秘密の戦略を見つけることよりも、システムの中核機能テストが重要
- 1日1,000件のランダム銘柄買いを1週間実行すれば、買い・売りロジック、部分約定管理、キャンセルロジック、ポジション追跡システムを効果的に検証できる
- ペーパートレーディング口座でランダム買いをテストプロセスに統合し、複数のシステム側面を同時に検証する効率的な方法
-
ティックバー vs タイムバー
- ブローカー提供のローソク足バーは固定時間枠（例: 30秒）をカバーするが、市場急変時には同じ時間内で100件と数千件の取引が混在する問題がある
- 生のティック・気配データから取引数ベースの独自バーを構築し、市場の寄り付き・引けのような高活動時間帯で格段に高い解像度を提供、スプレッドなどのカスタム指標も追加可能
-
インメモリ化
- 初期のデータベース方式は市場の寄り付き・引け時の大量アクティビティスパイクに耐えられなかった
- ミューテックスロックを適用した大型マップを活用する全面インメモリ方式へ移行し、スケーラビリティ問題を解決
- すべてのデータを保持する構造体を圧縮gobファイルにダンプして保存し、再起動時に再ロード可能。1日で40GB以上に増大し、このサイズのgobダンプをサポートするためGoビルドのパッチが必要だった
- 停電でライブ状態の全状態データを喪失した経験から、無停電電源装置（UPS）の導入は必須
-
複雑さと孤独感
- 予想以上に困難で時間を要するプロジェクトで、小さな趣味から本格的な執着へと発展
- 口座残高を増やすことがすべてなので孤独になりがちで、激しい感情のジェットコースターを伴う
-
GoとPythonの併用
- トレーディングシステムはGoで書きつつ、データ探索にはPythonの広範なデータサイエンスライブラリを活用するハイブリッドアプローチ
-
個人PCの活用
- 現代のデスクトップPCは十分な最適化を施せば、株式市場全体のリアルタイム監視を処理できるほど強力
-
ChatGPTの活用
- 解決方法が分からない状態で検索や読書に頼るやり方から、ChatGPTに問題を説明し、解決方法を尋ね、コード生成まで依頼するやり方へ転換し、生産性が3倍向上したと実感
市場イベントの体験
- ミーム株騒動、大規模IPOイベント、市場の好況・暴落、FRB関連ニュースと利上げなど、さまざまな市場の異常現象を自作システムで検知し、ニュースより先に確認可能
- 市場イベントが目の前で展開するのを見る、最前線の観戦席のような体験
1件のコメント
Hacker Newsの意見
しばらくHFTで働いていたことがあるが、この分野全体は本当に興味深く、原文の筆者も同じような面白さを感じていたと知れてうれしい
プラットフォーム自体が議論でよく抜け落ちる理由は、トレーディングが 高度な技術・複雑性・強い規制・極端な競争 が一度に押し寄せる領域だから
注文入力システム、リスク管理システム、ポジション追跡システムを作ること自体も大きな達成だが、トレーディング会社の立場ではすでに 参入コスト に近い
だから人々は戦略を語る。基本プラットフォームはすでに揃っていて、今はそれでどう稼ぐかを探す段階だから
しかも市場参加者がみな同じゲームをしているわけでもない。HFTでは数秒しか持たないアルファをめぐってFPGAでナノ秒を削り、ニュージャージーの無線網でマイクロ秒を削る競争をしていたが、銀行はCarteretの天気より選挙や地政学のほうを気にする。雨が降るとその日はマイクロ波ネットワークが使えない
その中間には、数時間から数週間続くアルファを狙う無数の戦略があり、公開フォーラムで同じ言葉で語ることすら難しい。それでも面白い世界で、ときどき懐かしくなる
一方で 戦略 は発見が必要な領域だ。よく知られていて今でも収益性のある戦略もいくつかあるが、だいたいは最大手企業が押さえており、残りは探索の過程にある。戦略によっては、ごく短い市場局面でしか利益が出ない
私もときどき懐かしくなるが、統合が進みすぎて、今ではたいてい 大企業の世界 になってしまった
こうした内容の大半は各社の内部でサイロ化されていて、外では語られないのだと思う
HFTはまったく別のゲームをしている。取引所のアーキテクチャと実際の配線構造を読んだことがあるが、私はSIPからデータを受け取る一方、HFTは取引所に直接接続している [1]
私は秒単位で取引し、HFTは言うまでもなくマイクロ秒単位で取引するので、比べものにならない。ある意味では、彼らと直接競争していないのはむしろありがたい。あるいは競争していても、それでも少しは稼げているのかもしれない
[1] https://www.researchgate.net/figure/Latencies-in-the-Electro...
基本的には 中頻度トレーディングをより速くすること なのか、それとも注文キューで優先権を得るような具体的な利点があるのか気になっている
このプロジェクトについて質問があれば答えられる。サイドプロジェクトとして始めたが、完全にのめり込んでしまった
システム自体にはそれほど秘密めいた部分はなく、要は戦略を差し込める 堅牢なプラットフォーム を持つことにある
おそらくオープンソース化もできるが、その前に自分が入れたあれこれのハックをまず整理しないといけない
Tech Traderは、10年以上にわたり人の介入や更新なしで実運用されている 完全自律型トレーディングシステム と紹介されている
従来のアルゴリズムシステムと違う点は、クオンツ、統計アービトラージ、高頻度方式ではなく、人が株を見るやり方に似せつつ、機械の冷徹な規律と無限の集中力を活用するという説明だ
2012年12月の公開以来、実資本で完全自動売買を続けており、作者はpftqというゲーム名を使う独学の開発者1人だという
さまざまな戦略を差し込むアプローチを共有してもらえるか気になる。プラグイン式の戦略システムは複数の層にまたがるので、すぐに厄介になる
バックテストではすべての板情報・ティックデータを保存して再生しているのか、それとも過去の集計データだけを使っているのかも気になる
記事を見てPolygonでWebSocket構成を試してみようかと思ったが、WebSocket機能がある最初のパッケージが29ドルで、リアルタイムデータがあるAdvancedパッケージは月200ドルだと知った
API呼び出し無制限のリアルタイムデータはかなり良さそうだが、自分の戦略は一般的な資金規模では勝率がせいぜい78%程度なので、月200ドルを正当化するのは難しい
どのパッケージを使っているのか、そのパッケージの長所と短所は何か知りたい。メールで返信したいならプロフィールにある
IBが価格フィードをリアルタイムで送っているのかは分からない。TWS画面は継続的に更新されるので、データ自体はリアルタイムで送っているように見えるが、板情報もAPIで提供されているのか気になる
この記事がpolygon.ioのブログに載っているのは分かっているが、IB/TWS APIだけでも動作する構成なのか気になっている
アルゴリズムトレーディングで最も誤解されている概念の一つは、ほとんどのシステムで速度が決定的要素ではないということだ。
私のシステムである https://grizzlybulls.com/models/vix-ta-macro-mp-extreme のようなモデルは、3年以上にわたる実運用で市場を大きく上回ってきたが、平均すると取引は営業日18日に1回程度しか行わず、シグナルも時間単位の区切り付近でしか生成しない。
過去18か月は、高インフレと急速な金利上昇という大きな構造変化のため当初より弱かったが、2022年1月のサイト公開以降で +14.11% のリターンを上げ、SPX は -7.83% だった。
レバレッジなしでも達成しており、同期間の最大ドローダウンも -16.48% で、SPX の -27.57% より低かった。
モデルが実際に市場を大きく上回ったように見せる構成になっている。本当に未開拓の金鉱を持っているなら大したものだが、個人的にはいくつかの危険信号のせいで信じにくい。
アルゴリズムトレーディングに関心があるなら、Collective2 は見る価値がある。エンジニアたちが売買シグナルを購読料付きで提供している場だ。
アルゴリズムトレーディングのマイナーリーグのような感じで、かなり興味深い。
システムが損益を追跡するため、成績報告をごまかすのは難しく、Collective2 が Interactive Brokers のアカウントにアクセスすることを承認すれば、売買シグナルを代わりに執行できる。
少なくとも10年は続いているサービスなので長期成績も見られるが、ほとんどのシステムはそこまで長くは続かない。
https://collective2.com/leader-board
現在の上位勢も長く留まる例はほとんどなく、せいぜい1〜2年程度だ。これは、ほとんどのシステムのアルファがかなり早く消えることを示している。
収益曲線もでこぼこしており、少数の取引が利益の大半を占める構造だ。
自動売買システムを開発する際の重要な軸は、データフィードと収集、特徴量生成、シグナル生成、実際の取引と注文管理、そして全体のオーケストレーションだ。
生データがそのまま意思決定に使われることはまれで、優れた特徴量生成が成功の主因になることが多い。移動平均はその一例だが、最近ではその程度ではほとんど通用しない。
この記事はデータ処理と注文管理の技術的側面、および全体のパイプラインを示しているが、ソリューションの拡張や非同期実装に関する詳細がもっとあればよかった。
特に Go を使っているのだから、その目的に合った channel 構造があるはずで、そこがさらに気になる。
記事の焦点ではないのは理解しているが、取引ロジックや新しい戦略を差し込む方法、既存戦略をどうパラメータ化するかについての一般的な情報もあれば役立ったはずだ。
最後のリンクは興味深く、私は機械学習と特徴量エンジニアリングベースのインテリジェントなトレーディングボット（https://github.com/asavinov/intelligent-trading-bot）を開発中なので、こういう記事は重要かもしれない。
構造はシンプルで、goroutine と channel が互いに通信し、大きな mutex 一つでロックする方式だ。
新しいデータが入ると、必要な集計値、つまりティックベースのローソク足を作り、そのデータが BUY ロジックのループをトリガーする。何かを検知したら IB API の注文を発行する。
非常にシンプルで、複雑なものは何もない。100を超えるポジションを同時に追跡したこともあるが、普通に動いていたので複雑な非同期ロジックにはあまり手を入れなかった。
パラメータは実際には BUY ループの中にハードコードしている。奇妙に聞こえるかもしれないが、小規模な構成ではそれほど頻繁には変わらない。
何度か取引を回して、値を調整し、再起動してまたテストするというやり方だ。エンタープライズ環境なら正式な言語やホットローディングのようなものがあるのだろうが、私の場合はハードコードで十分うまくいっている。
Go自体や、どんな言語にも大きな利点があるわけではない。利点をもたらすのはトレーディングアルゴリズムであり、それは常に見つけるのが難しい
数か月かけて最適なパラメータを探したが、結局は過去データでしか機能せず、実際はまったく違っていた
アルゴリズムと戦略が完璧なら、Visual Basicを使ってもGoやRust、そのほかどんな言語よりもうまくいくかもしれない。言語は単なる道具にすぎない
Goを使ったのはよいことだが、タイトルは少し誤解を招くかもしれない。人々が何らかの利点として受け取る可能性があるが、そうではない
そしてHFTでは、ガベージコレクタのある言語はよい選択ではないと思う
そうしたロジック、つまり戦略を手動で開発するのは当然難しいので、私は過去データから取引戦略を導き出すインテリジェントなトレーディングボットを作った
https://github.com/asavinov/intelligent-trading-bot
現在は暗号資産で動作しているが、ほかの市場にも適用できる
https://t.me/intelligent_trading_signals
過去データでしかうまく機能せず実際とは異なる、というのは典型的な状況だ。重要なのは、将来の未見データでも機能する戦略を作ることだ
バックテストのアルゴリズムも、未来のデータが過去に漏れないように設計されるべきだ
業界ではC++やPythonが多く使われているので、むしろGoを使うことは不利かもしれないが、私が使える言語がそれだった
誤解を生む意図はなかった。Goはデータを受け取って処理し、リモートAPIを呼び出すのにかなり向いていて、実際うまく動作する
ただし、これをもとに就職しようとしてもあまり役には立たないだろう
Javaを使い、起動時に必要なメモリをすべて事前割り当てするところもある。Jane StreetがOCamlを使うことでも有名だ
こうすれば性能はかなりよく、メモリバグを心配しなくてよい
過去データでしばらく実験すると、そのデータの有用性は下がっていく
私は知っている言語だからTypeScriptで、ツールが豊富だからPythonでボットを作っている
あまりにも圧倒的で、孤独な作業だ。ほかのプロジェクトはいつもチームでやってきたし、とても小さなチームで業務が自律的だったとしても、たまには会議やスタンドアップがあった
これは6か月ずっと一人でやっているので、単に一人でいないために友人を加わってもらおうかと考えた
サイドプロジェクトなので大きな進展は出せないかもしれないが、いつでも話すつもりはある
私が思いつく唯一の方法は、彼らが持っていないデータを手に入れることだ
この記事は完全に無意味で、クリック誘導的だと思う。要するに「市場データにはpolygon.ioを使えるが、アルゴリズムトレーディングはどうせ難しいので、まだ共有できることはあまりない」という程度だ
個人的には、自分のシステムを作るときの上位構造を共有したかった。自分がこのウサギ穴に落ちたとき、こういう記事があればよかったと思っていた
何をもっと入れればよくなるか教えてくれれば、喜んで反映したい
トレーディングがもたらす、コード・戦略・お金の純粋なフィードバックループを楽しむ人たちを見つけるのがよい
私はアルファの源泉として、株式と指数の間のタイミングと相関を研究してきて、ある程度の成果がある
今はそのプロセスを自動化しようとしていて、作業そのものを本当に楽しんでいる
マーケットメイカーになろうとしているわけでも、銘柄を次々と渡り歩こうとしているわけでもない。いくつかの銘柄を非常にうまく収益化する精密なモデルを磨くことに集中している
役立つツールとしては、TradingViewとPinescriptの指標・戦略、バックテスト用にエクスポートしたデータを使うExcelモデル、バックエンドの機械学習向けのPythonとGo、新しいコードの反復を速めるためのChatGPTがある
興味があれば trading @ dianazink.com で話したい
よい記事で、具体的な説明と、特にスクリーンショットがよかった
戦略を詳しく話さないのは理解できるが、取引が全面的にテクニカル分析に基づいているのか、それとも外部データや代替データフィードを使っているのか説明してもらえるだろうか
つまり、Polygon入力とIB API出力だけのほぼ閉じたシステムなのか、それともニュースサイト、Twitter、Redditのようなカスタムデータフィードまで含む、より広い構成なのかが気になる
もし後者なら、一部データソースの過去カバレッジが部分的である場合に、それを過去のバックテストとどうバランスさせているのかも気になる
最近は、事前計算した過去値のルックアップテーブルを使って異常検知、たとえば「この銘柄でこの活動は正常か」を判断する方法を見ている
今日のBXRXがよい例だ [1]
オプション取引活動も見ながら、シグナルとして使えるか試している
[1] https://www.google.com/search?q=BXRX