こんにちは、よだかです。
ここ最近、CEXとDEXを横断した市場観測の研究を進めています。
もともとの出発点は、
「清算が起きた後を見るのではなく、清算が伝播しやすい市場の状態そのものを観測できないか」
というテーマでした。
そこからBinance、Bybit、OKXなどのCEXとHyperliquidを同じ時間軸上で観測する基盤を作り、価格・板・取引などを比較するようになりました。
-
-
🛠️開発記録#549(2026/8/7)清算カスケードの前兆は観測できるのか｜「清算脆弱性探知機」を作り始めた話
続きを見る
-
-
🛠️開発記録#550(2026/8/21)清算はどこから伝播するのか｜CEX・Hyperliquid・DeFiの横断観測を始めた話
続きを見る
研究を進める中では、CEXとHyperliquidの価格が一定以上離れたあと、再び近づいていくような現象も見えてきました。
そこで現在は、
「この現象は別の期間でも再現するのか」
を確認するため、開発時に使ったデータとは別のデータを使ったOOS（Out-of-Sample）検証を進めています。
ただ、今回はその研究結果の話が本題ではありません。
研究が進むにつれて、別の問題が気になり始めました。
そもそも自分は、この研究が何を計算しているのか、本当に説明できるのか？
今回は、一度研究を進める手を止めて、プロジェクトそのものを監査しました。
コードは動いている。でも、自分は理解しているのか
最近の開発では、ChatGPTやCodexをかなり深く使っています。
研究仮説を整理する。
必要なデータを決める。
収集基盤を作る。
テストを書く。
集計する。
結果を比較する。
次の検証方法を考える。
こうした作業をAIとかなり密に進めています。
これは非常に速いです。
以前なら何日もかかっていた実装や調査を、かなり短い周期で回せるようになりました。
一方で、速度が上がるほど、
AIが研究方法を提案する
↓
AIが実装する
↓
AIが結果をまとめる
↓
AIと次の研究を考える
というループも成立します。
ここで人間側が理解を追いつかせないと、
「数字は出ているけれど、なぜその数字を見ているのか分からない」
という状態になり得ます。
今回、自分の研究について説明しようとしたとき、まさにこれを感じました。
例えば、
「一定以上の価格乖離」
と言っているけれど、
その“一定以上”はどう決めているのか？
数分後に価格差が縮んだかを見ているけれど、
なぜその時間幅なのか？
複数の価格乖離を一つのイベントとしてまとめているけれど、
どこまでを同じイベントと定義しているのか？
コードは動いています。
OOS検証も進んでいます。
しかし、自分自身がこれらを全部説明できるかと言われると、怪しい。
そこで一度、研究を逆向きに辿ることにしました。
Codexには「研究が正しいか」ではなく「何をしているか」を調べさせた
今回の監査では、Codexに、
「この研究は妥当ですか？」
とは聞いていません。
自分で作ったコードをAI自身に評価させて、
「問題ありません」
と言われても、あまり意味がないからです。
代わりに、
コード、設定ファイル、保存データ、OOS結果から、確認できる事実だけを抽出する
ように指示しました。
具体的には、
「どの価格を比較しているのか」
「価格差はどんな式で計算しているのか」
「どのデータから閾値を作ったのか」
「時間windowの中でどの観測値を採用しているのか」
「何を1回のイベントとして数えているのか」
「何をもって収束と判定しているのか」
「baselineはどう作っているのか」
「OOS開始後に研究条件を書き換えていないか」
などを、コードや成果物まで遡って確認させました。
また、
- 明示的に仕様として書かれている
- コードから読み取れる
- テストされている
- 根拠が文書化されていない
- 現時点では不明
を分けて報告させました。
今回欲しかったのはAIによるお墨付きではなく、
自分が後から疑える材料
です。
実際に何を測っているのかは、かなり明確になった
監査をしたことで、現在の研究が何をしているのかはかなり整理できました。
かなり単純化すると、
HyperliquidのBTC価格と複数CEXのBTC perpetual価格を比較し、開発期間のデータから決めた基準以上に価格差が開いたイベントを抽出する。そこから一定時間後に、その価格差の絶対値が小さくなっているかを見る。
という研究です。
比較する価格には、売り板と買い板の中間であるmid priceを使っています。
データは短い固定windowにまとめ、そのwindow内で最後に観測できた価格を使っています。
また、開発データで決めた条件はOOSでは再計算せず、固定した状態で別期間へ適用しています。
ここまでは、コード・設定・成果物の間で大きな不一致は確認されませんでした。
つまり、
「何を計算しているのか分からないプログラムが、謎の収束率を吐いている」
という状態ではなかった。
これは一つ安心したところです。
一方で、ここから別の問題が見えてきました。
「どう計算しているか」と「なぜそう計算するか」は別である
今回一番大きかったのはこれです。
コードを追えば、
「どの閾値を使っているか」
「どの時間幅を使っているか」
「何window以内を同一イベントとするか」
は分かります。
でも、
なぜ、その値なのか？
は別問題です。
例えば価格乖離の閾値は、開発期間に観測した価格差の分布を使って作られていました。
これは理解できます。
一方で、
なぜその分位点なのか。
なぜその時間幅なのか。
なぜそのイベント結合条件なのか。
なぜその最低サンプル数なのか。
という部分については、研究上の根拠や意思決定履歴が十分残っていませんでした。
つまり、
実装は説明できるが、研究設計の理由までは説明できない部分が残っている
ということです。
これはバグとは違います。
コードは設計通り動いている。
でも、その設計を採用した理由が弱い。
今回の監査では、この2つを分けて考える必要があることがかなりよく分かりました。
baselineにもまだ弱点がある
もう一つ重要だったのが比較対象です。
現在の研究では、
「価格差が大きく開いたケースは、その後よく収束する」
だけを見るのではなく、
閾値未満のケースなどをbaselineとして比較しています。
これは、単純に、
「価格はだいたい戻るものだから収束して見えているだけでは？」
という可能性を減らすためです。
ただし現在のbaselineは、すべての市場状態を揃えているわけではありません。
例えば、
同じボラティリティだったか。
同じ流動性だったか。
同じ時間帯だったか。
同じmarket regimeだったか。
までは揃えていません。
そのため、
candidateだからその後の挙動が違ったのか
それとも、
candidateが多く発生するような市場状態そのものが、その後の挙動を変えていたのか
は、まだ完全には分離できていません。
実際、OOSを複数回取ると、価格乖離イベントの発生頻度や持続の仕方にはかなり違いがありました。
この辺りは、次に研究設計を見直すときの重要な論点になりそうです。
ただし、具体的な閾値や条件については、現在進行中の研究なのでここでは伏せます。
negative controlもまだない
今回もう一つ見つかった大きな穴が、negative controlです。
簡単に言えば、
本来意味がないデータを入れたときにも、この研究pipelineは「何か見つかった」と言ってしまわないか？
を確認するテストです。
例えば、時刻をランダムにずらす。
結果の対応関係をシャッフルする。
わざとvenue間の時間をずらす。
こうした処理をしたデータでも同じような「収束」が出るなら、今見ている現象の一部は市場構造ではなく、集計方法によって生まれている可能性があります。
現在の研究には、こうしたnegative controlがまだ十分ありません。
これは次に補う必要があります。
一番怖いのは、コードを書けないことではない
自分は金融やプログラミングのプロではありません。
そのためAIをかなり使っています。
これについて、
「ブラックボックスなのでは？」
と言われれば、正直、完全には否定できません。
ただ、今回監査して少し考え方が変わりました。
問題は、
コードを全行自分で書けるか
ではないのだと思います。
重要なのは、
何を入力しているのか
何を計算しているのか
何と何を比較しているのか
どんな条件なら仮説を捨てるのか
を自分で説明できることです。
逆に言えば、
コードが高度にテストされていても、
「なぜその時間幅なんですか？」
「なぜそのthresholdなんですか？」
と聞かれて、
「AIがそう決めたから」
しか答えられないなら、かなり危ない。
今回、自分の開発では、
実装速度に自分の研究理解が追いついていない
部分があることが分かりました。
今のボトルネックは、コードを書く速度ではなく、研究設計を自分の言葉で理解することなのかもしれません。
これは以前考えていた「代理変数」の話ともつながる
以前、
開発記録#538「代理変数について」
という記事を書きました。
そこでは、
観測できるもの
↓
そこから推測しているもの
↓
最後に自分の仮説として解釈しているもの
を分離して扱いたいと書いています。
今回もほぼ同じ問題です。
価格差が縮んだ。
これは観測できます。
でも、
清算が原因だった。
CEXが先導した。
Hyperliquidが遅れて追従した。
そこに売買可能なエッジがある。
ここから先は、まったく別の話です。
現在の研究では、まだそこまで言えません。
-
-
🛠️開発記録#538(2026/5/8) 代理変数について
続きを見る
また、
🛠️開発記録#491 multi_market_probe開発ログ ― 歪み回帰判定機を“事実ベース”へ寄せ直した話
でも、
「構造があると先に決めるのではなく、まず事実として何が起きているのかを見る」
という整理をしています。
振り返ってみると、今回の監査も同じ方向の作業だったと思います。
-
-
🛠️開発記録#491(2026/3/23)multi_market_probe開発ログ ― 歪み回帰判定機を“事実ベース”へ寄せ直した話
続きを見る
OOS検証自体は継続する
今回の監査をしたからといって、現在の研究を捨てるわけではありません。
監査範囲では、今までのFormalなOOS結果を即座に無効化するような重大な実装上の問題は確認されませんでした。
また、開発時に決めた研究条件をOOSの結果を見ながら都合よく書き換える、といったことも今のところ確認されていません。
そのため、現在進めている追加のOOS観測はそのまま続けます。
ただし、その結果が良かったとしても、
「CEXとHyperliquidの価格乖離から儲かるエッジを見つけた」
とは言いません。
今確認しているのは、あくまで、
定義した条件下で、価格乖離後の再同期という現象が別期間でも再現するのか
です。
市場現象が存在することと、
その現象をbotで利益に変換できることは別です。
ここは最近の研究全体でかなり意識するようになりました。
次は、研究を増やすより「なぜ？」を潰す
今回の監査を受けて、次にやるべきことも少し変わりました。
新しいfeatureを追加する。
新しい仮説を増やす。
新しいデータを収集する。
もちろん、そうした作業も今後必要になります。
ただ、その前に、
なぜこのthresholdなのか
なぜこの時間幅なのか
baselineは何を比較しているのか
どんなnull modelならこの仮説は崩れるのか
を自分で説明できる状態にしたいです。
AIを使って研究速度を上げること自体は、今後も続けると思います。
むしろ、この速度はかなり強力です。
ただし、
AIで速く進むこと
と、
自分が研究を理解すること
は別々に管理する必要がある。
今回の監査で、それがかなり明確になりました。
発信そのものも自己監査に使う
この記事を書いている理由も、その一つです。
自分の中だけで、
「まあ、だいたい分かった」
と済ませると、分かったつもりのまま研究を先へ進められます。
でも文章にしようとすると、
「この一定以上って何？」
「この収束って具体的に何？」
「なぜこの比較をしている？」
という穴が出てきます。
ラジオ発信でも同じです。
人に説明する形で話すと、自分が曖昧に理解しているところほど言葉に詰まります。
今後しばらくは、
研究する
↓
監査する
↓
文章にする
↓
話してみる
↓
理解できていないところを再び掘る
という流れを回してみようと思います。
公開することで他人から評価されたいというより、
自分の研究を、自分が理解しているか確認するための外部化
として使うイメージです。
もちろん、現在進行中のアルゴ研究なので、具体的なparameterや実装条件、売買へ接続できそうな部分については公開しません。
研究プロセスと、実際のalpha候補は分けます。
現時点での結論
今回、CEXとHyperliquidの横断研究プロジェクト全体を監査しました。
結果として、
コードやFormal Evaluatorが完全なブラックボックスだったわけではない。
何を入力し、何を計算し、どうOOS評価しているのかはかなり追跡できました。
一方で、
なぜその研究設計なのか説明できない部分が残っていた。
こちらの方が今の自分には重要な問題でした。
AIによって、実装できる範囲はかなり広がりました。
その一方で、
「作れること」
と、
「理解して研究できること」
の間にはまだ距離があります。
今後はこの距離を埋めます。
研究を先へ進めることだけを成果にするのではなく、
自分がその研究について、何を知っていて、何を知らないのか説明できる状態を作る。
しばらくはここも開発タスクの一部として扱ってみようと思います。
研究自体は継続します。
ただ、次のエッジを探す前に、まず自分が今立っている場所をきちんと理解する。
今回はそのための監査でした。
それでは、また。