前回の記事では、Pump.funという市場の仕組みを整理しました。今回から数回に分けて、この市場を相手に自動売買Bot「Phantom Hunter」を開発してきた経緯を書きます。
先に打ち明けておくと、私はエンジニアではありません。商社勤務の会社員で、コードはAIに書かせています。それでも半年あまりで数百回のバージョンアップを重ね、Botは1本のPythonスクリプトから、Rustの実行エンジンとPythonの頭脳を組み合わせた二層構成に育ちました。この記事は、その変遷の記録です。同じようにAIと組んで何かを作ろうとしている人の参考になれば幸いです。
出発点はトレードではなく、データ分析だった
最初にやったのは、Botを書くことではなく、Pump.funの生データを眺めることでした。発行直後のトークンの価格・ホルダー数・売買の時系列を大量に取り、分析スクリプトを何本も書いて（正確には、AIに書かせて）、勝ち銘柄と負け銘柄の違いを探しました。
そこで見つけたのが、後に入場ロジックの核になる観察です。伸びる銘柄は、価格とホルダー数が「同時に」伸び続ける。価格だけが吊り上がる銘柄は、買い手が増えていない——つまり誰かの一人芝居であることが多い。私たちはこれを、二本の線が絡み合って上がっていく様子から「二重螺旋（Double Helix）」と呼びました。
前回の記事で「チャートの形は参加者構成の署名」と書いたのは、この経験から来ています。ロジックはひらめきではなく、データを眺めた時間から生まれました。
バージョン名は、不具合の墓標である
開発記録を読み返すと、当時のバージョン名がそのまま苦闘の歴史になっています。実際の名前をいくつか並べます。
Stagnation Killer（停滞キラー）。Zombie Exorcist（ゾンビ退治）。Crash Reporter。Price & Logic Fix。Graph Resurrected（グラフ復活）。
売るに売れないまま残る「ゾンビポジション」の処理。取得価格のズレ。何度直しても壊れるチャート表示。派手なロジックの進化に見えて、実際の開発時間の大半は、この種の「地味に致命的な問題」との戦いに費やされました。V36系だけでマイナーバージョンは20を超えています。
ここで得た教訓はひとつです。戦略を磨く前に、まず「測る道具」と「確実に売買できる足回り」を直す。表示が間違っているBotの上でロジックを議論しても、砂上の楼閣にしかなりません。
「神速」の時代と、あとから分かったこと
V36.9系で、開発は攻めに転じます。銘柄の様子を30秒観察してから入る方式を捨て、発行から約2秒で入場する「God Speed」モードと、小さな利益を即座に確定する「Flash Profit」を同時に搭載しました。当時の成績は目に見えて良くなり、私たちはこの構成に手応えを感じていました。
ところが、これには後日談があります。数カ月後、過去の全バージョンを解剖する検証をやり直したところ、2つのことが分かりました。ひとつは、この時代の利益の大半を実際に稼いでいたのはGod Speedの入場ではなく、地味なFlash Profitの利確だったこと。もうひとつは、God Speedの好成績は特定の相場環境（レジーム）に依存していて、期間を広げて検証すると採算が取れなかったことです。
好成績は、戦略の実力ではなく相場のご褒美かもしれない——この疑いを常に持てるようになったのは、後に検証のやり方そのものを作り直してからです（検証手法の話は、別の記事で詳しく書く予定です）。
Python一本の限界
V39系まで、BotはPython一本で動いていました。開発が速く、分析と一体で回せる。しかしこの市場では、それが構造的な弱点になります。
Pump.funの初動は秒単位ではなく、ミリ秒単位の世界です。イベントを受け取ってから判断し、トランザクションを組んで送信するまでの遅れは、そのまま約定価格の劣化になります。さらに、混雑時に自分のトランザクションが「着地」しない問題は、言語の速さだけでなく、送信経路や確認方法の設計まで含めて作り込まないと解決しません。
Pythonで戦える領域と、戦えない領域がある。それがはっきりしたのが、V61として構想した「ハイブリッド構成」でした。
Rust＋Python、二層構成へ
現在のPhantom Hunterは、役割の異なる二層でできています。
下の層はRustの実行エンジンです。gRPCのストリームでPump.funのイベントを24時間監視し、入場・出口の判断から発注までを、人間には見えない速さで完結させます。ここは一度検証を通したら凍結し、原則手を入れません。
上の層はPythonの頭脳です。データの収集と分析、戦略の検証、レポート作成を受け持ちます。新しいアイデアはまずこの層で検証され、有効と確認されたものだけが、Rust側の設定として降りていきます。
この分業のいちばんの効用は、速度そのものより「壊しにくさ」でした。試行錯誤する場所（Python）と、正確に動き続ける場所（Rust）を分離したことで、思いつきの実験が本番の売買を壊す事故が構造的に起きにくくなりました。動いているものは触らない、変更は検証を通してから——という運用規律も、この構成だから守れています。
この半年の学びを3行で
第一に、ロジックはデータを眺めた時間から生まれる。ひらめきは検証の入口にすぎない。第二に、好成績を疑う。それは戦略の実力ではなく、相場のご褒美かもしれない。第三に、試す場所と動かし続ける場所を分ける。アーキテクチャは速度のためでなく、規律のためにある。
次回は、この開発史でもっとも高い授業料を払った問題——「シミュレーション（DryRun）では勝てるのに、実弾では勝てない」の原因究明について書きます。
本サイトはBot開発と検証手法の記録であり、投資助言ではありません。記事中の記述は特定期間の観測に基づくもので、将来の結果を保証しません。
コメント