覚醒と転換──文鎮化した陸奥が再び動き出す瞬間

FX自動売買基盤『The XVI Architecture』と陸奥(Mutsu)の開発秘話を象徴するコンセプトイメージ

前回:出航と潜伏──自動売買の夜明けと、封印された5年間

この記事は、シリーズ『陸奥 開発秘話』の第4回です。前回は、自動売買の原型が生まれ、しかし5年間の沈黙へと至った“潜伏の時代”を振り返りました。今回は、文鎮と化した陸奥が再び動き出し、AWS・Pythonとの邂逅によって“覚醒”へ向かう転換点を語ります。

目次

1. 覚醒:陸奥(Mutsu)の産声

2014年11月。ついに金融系案件を離脱しました。
多くの仲間たちとシステムを支えた記憶は、今でも鮮明に残っています。
※当時の仲間たちとは今でもたまに会って、酒を酌み交わす仲です。

しかしこれで、凍結していたFX自動売買システムの開発を再開できます。

1.1. 5年分の遺産との再会

開発を再開するため、まずは5年間貯め続けた相場データを丹念に分析しました。
分析に際しては、あらゆる相場や経済に関する文献を漁りました。

来る日も来る日も、1年近く相場の数字を睨みつけ、相場や経済だけに飽き足らず、数学や政治、気象に関する文献にも手を出しました。
そして様々な要素を盤面にちりばめ、そこから、ひとすくいの『煌めき』を見つけたのです。

1.2. 命名・陸奥

開発再開にあたり、NKTrading を捨て、フルスクラッチで開発することにしました。
そのため、まずはシステムに名前を付けることを考えました。絶対に成功させてみせるという想いとともに。

だから、このシステムには、最強の名が必要だったのです。
私が選んだのは、大好きなマンガ『修羅の門』の主人公・陸奥九十九が継ぐ幻の古武術『陸奥圓明流』から取った『陸奥(Mutsu)』という名です。

『絶対的な理(ことわり)』をコードに宿したいという、エンジニアとしての祈りに似た決意が、私にその名を付けさせました。

1.3 驚愕のバックテスト

新たに見つけた『煌めき』と共に、私はとうとう完成させました。
『FX自動売買システム・陸奥』を。

MetaTraderで過去9年間のデータを対象にバックテストを実行した結果、画面に踊るその勝率は80%。
その驚異的な数字を見て、一瞬フリーズしました。

あり得ない。そんな馬鹿な。
何度も反芻しました。人から言われて信じられるでしょうか。
勝率80%の自動売買システムなど。

勝率80%の自動売買システムが、例えば50万円で売っているとしましょう。
絶対に信じられないので買いません。どんなグラフや数字を提示されようとも、そんな訳があるかと。

しかし、自分で作り上げたシステムです。
当然、歓喜に震え成功を喜びたい。

だが、そんなに相場は甘くないことは良くわかっています。
きっと裏があるに違いない。病的なまでに、懐疑的かつネガティブに、その結果を眺めていました。

2. 葛藤:黄金の文鎮

勝率80%の好成績システムは完成しました。
しかし、投資について勉強すればわかると思いますが、こんなに簡単に勝率80%になる訳がありません。

自身で作ったシステムが叩き出した結果ですが、バックテストのやり方が悪いか、非常に限られた条件で出てきた結果でしょう。
もっと言えば、仮にこの勝率が真実だったとしても、過去のデータで検証した結果にしかすぎません。

未来も同じことが起こるとは限らないからです。
投資とは、これから起こる未来を予想し、それが現実と合致したときにだけ成果を得られます。

しかし、バックテストで叩き出した「勝率80%」という数字を前にして、私は言いようのない不安に駆られていました。
自ら書き上げたロジックを信じたい自分と、エンジニアとしての「こんなにうまく行く訳がない」と疑う自分が、脳内で激しく火花を散らします。

結局、自分の不安を鎮める方法はたった一つしかありません。
過去のデータという箱庭から、容赦のない現実のマーケットへシステムを解き放つ。
フォワードテスト1です。

2.1. 夢のハーベスト

フォワードテストをするべく、コード上にフォワードテストモードを設け、実際に取引はせず記録するだけの機能を追加しました。

バックテストでは、結果を示すグラフは右肩上がりの鮮やかな軌跡を描いていました。
だが、現実の相場を相手にした結果は、数週間経っても1行の注文ログも吐き出しません。

それでも諦めず、稼働させること数ヶ月。
半年、1年と実行した結果は、取引回数が数ヶ月に一度あるかないかという、あまりにも寂しいものでした。

陸奥の名に恥じない、最強の拳を持ってはいますが、その拳を振るうことはなかったのです。
そう。黄金ではありますが、まるで文鎮のように動きません。

とある本には「取引頻度はむやみに多いよりも少ないほうが良い」と書かれていました。
しかし、これはその次元の話ではありません。大海原で針の穴を通るような、奇跡の瞬間を待ち続けているかのようです。

多額の資金があれば、滅多に現れないその一撃にすべてを賭けて利益を残せるかもしれません。
しかし私には、そんな軍資金はありません。

こんなことでは「30歳までに生涯賃金の3億円を稼いで引退する」なんて夢のまた夢です。

その青写真と目の前の「動かない画面」との距離は、絶望的なまでに開いていました。
このロジックのどこに私の野心。否、夢を阻む「バグ」が潜んでいるのか。

私は自ら書き上げたコードの奥地へと潜入することにしました。

2.2. コードインスペクション

このコードは、Subversion(SVN)というバージョン管理システムで、リビジョン40を数えるまで磨き上げてきました。
MetaEditorが勝手に文字コードを書き換えてしまう癖に抗い、UTF-8を維持するための設定を施し、エラーログの微かな予兆を追い続ける日々。

しかし、どれほど緻密に、どれほど堅牢に「陸奥」を組み上げても、現実のマーケットは微笑みませんでした。

9年間で17回。

その沈黙の理由は、皮肉にも私が心血を注いだ「負けないためのロジック」そのものにありました。
負けを恐れ、条件を削ぎ落とし、純度を高めすぎた結果、私の「陸奥」は実戦の場を失ってしまったのです。

これではダメだ。最強を誇った陸奥圓明流も、戦う相手がいなければその理(ことわり)を証明できません。

私に必要なのは、この「理を分足やティックといったもっとミクロな視点、あるいは複数の通貨ペアをまたいだマクロな視点で、高速かつ柔軟に検証できる「全く新しい土俵」ではないか。

そんな、エンジニアとしての本能的な渇きを感じていた 2015年10月。
業務の現場に大きな地殻変動が起きました。

AWS。そしてPython。

私の物語は、ここから「投資」の枠を超え、現代のクラウドエンジニアリングの激流へと飲み込まれていくことになるのです。

3. 転換:AWSとPythonとの邂逅

30歳での引退という夢が遠のくなか、私の主戦場は「マーケット」から「クラウド」へと移り変わっていました。
この数年間の実務経験が、眠っていた「陸奥」に新たな命を吹き込むことになるとは、当時はまだ知る由もなかったのです。

3.1. 2018年:クラウドの洗礼

金融系の現場を離れ、インフラの主戦場がオンプレミスからAWSへシフトする激動の中にいました。
コードを書いたりブラウザからのポチポチで、サーバーが立ち上がりLambdaが動き出す。
「インフラを物理でなく論理で操る」AWSの圧倒的な利便性に魅了され、私は瞬く間にクラウドの深部へと潜り込んでいきました。

しかし、この時の私はまだ知りませんでした。このクラウドという広大な海で、私にとって本当に必要な真の泳ぎ方を。

3.2. 2019年:Pythonとの「真」の出会い

業務で本格的にPythonを使い込み始めたのが2019年です。
当初は単なるスクリプト言語だと思っていましたが、標準ライブラリの柔軟性、そしてデータ構造の扱いやすさに触れるうち、私の中に激震が走りました。

「待てよ。このPythonとAWSを組み合わせれば、あの『陸奥』を最強の姿で再定義できるんじゃないか?」

3.3. 2020年:すべてのピースが揃った瞬間

かつてMQL4という箱庭の中で、PCスペックの限界や言語の制約に四苦八苦しながら「9年間のデータ」を数時間かけて回していました。
あの日の苦闘が脳裏をよぎります。

Pythonのデータ解析能力。AWSの機動力。そして、手元にある「なでしこ」が貯め続けた膨大なデータ。

これらが一本の線で繋がりました。
「PythonとAWSで作り直せば良くね?」 あまりにも単純で、あまりにも強力な答え。
2015年に一度は「文鎮」として沈んだ陸奥が、再び、しかし全く別の生命体として胎動を始めた瞬間でした。

4. 再設計:理想と現実のデプロイ

まず初めに、そもそもPythonでMQL4を書き換えることができるのか。
そこの調査を開始しました。
すると、約束されていたかのように、すぐに情報へ辿り着きます。

MetaTrader 5 × Pythonであれば可能だと!

4.1. 誤ったピース

こうして意気揚々と、「Python × AWS」による新生・陸奥の設計図を引き始めました。
しかし、私を待っていたのは、あまりにも初歩的で、あまりにも高い「OS」という名の壁でした。

私が開発のプラットフォームとして選んだ PythonとAWS Lambdaは、モダンで、スマートで、サーバレスです。
しかし、肝心のマーケットとの接点である「MetaTrader 5」は、 Windows という大地に深く根を張ったアプリケーションだったのであります。

「Lambdaで動かそう」という私の目論見は、この一点において、早くも修正を余儀なくされます・・・。

4.2. 実利と虚栄心の天秤

最新技術でスマートに構築したいという、エンジニア特有の虚栄心がなかったと言えば嘘になります。
しかし、投資の世界で生き残るために必要なのは、技術的な美しさよりも、一貫した動作とラーニングコストの低さです。

この場合、ひとえにランニングコストと言ってもさまざまです。
このままAWSを採用した場合、開発時には、AWSならではの調整が必要なため余計なコストがかかります。
運用時もそうです。AWSはリソースを使った分だけお金がかかります。また、ログを保存するのにも、調査するのにもです。

そんな諸々を考慮して、私は、AWSという魔法の杖を一度置き、最も確実な『Windows VPS』という剣を手に取りました。

実は、この時すでにAWS向けの設計書は細部まで書き上げてしまっていました。
エンジニアにとって、一度完成させた設計図を白紙に戻すのは断腸の思いです。

しかし、私は迷わず筆を執り直し、VPSという新たな戦場に合わせた設計図を引き直しました。
すべては、「陸奥」を真に完成させるために。

次回は、18年の蓄積が結実し、不敗の理が形となった現在──そしてその“先”にある戦場を語ります。

次回:結実と未来──不敗の理が形になった日、そしてその先へ


  1. フォワードテスト
    バックテストが過去データでの検証であるなら、フォワードテストは実際のリアルタイムな相場(現在からみた未来)にシステムを接続し、その時点からの挙動を検証すること。理論ではなく現実の証明。↩︎

目次