🛠️開発記録#500(2026/4/2)multi_market_probe開発ログ ― Lead-Lag観測機を、FACTとDECISIONで読める形に固定した話

こんにちは、ぼっちbotterよだかです。

前回までで、binance_perp をリード、bf_fx をラグとした単一の Lead-Lag 構造については、short 側の 10〜60 秒 horizon を執行コスト込みで観測できるところまで進めていました。ただ、この状態では long 側との比較ができず、構造が方向非対称なのか、それとも単に short 側だけを見ていただけなのかが分かりませんでした。そこで今回は、long 側の EV 込み Decision 表示を追加したうえで、Grafana ダッシュボード自体も研究判断に必要な最小構成へ整理しました。FACT で構造の濃さを見て、DECISION で執行コスト込みの EV を見る。この役割分担を固定したことで、単一の Lead-Lag 構造を観測する機械としては一旦区切りをつけられる形になりました。

1. 今日の目的：Lead-Lag構造を long / short 両側で同じ土俵に乗せる

前回までで、binance_perp をリード、bf_fx をラグとする単一の Lead-Lag 構造については、short 側の 10〜60 秒 horizon を執行コスト込みで継続監視できるところまで進めていました。FACT 系のパネルで future return のサンプル数、平均リターン、勝率を見て、DECISION 系のパネルで 7.6bps の roundtrip cost を差し引いた net return を見る。少なくとも short 側については、この流れで「構造がありそうか」と「執行コスト込みで残るか」をある程度分けて読める状態にはなっていました。

ただ、この時点ではまだひとつ大きな欠けがありました。見ていたのが short 側だけだったことです。short 側で薄く構造らしきものが見えていたとしても、それが本当に short 側に特有の偏りなのか、それとも long 側にも同じようなものがあるのにまだ可視化していないだけなのかは、このままでは判別できません。つまり、今の観測は「構造があるかどうか」を見ているようでいて、実際には「short 側だけを見た世界」を観測しているに過ぎない可能性が残っていました。

今回の目的は、その欠けを埋めることでした。やりたかったのは、long 側にも short 側と同じ定義・同じ horizon・同じコスト前提を適用し、両者を同じ画面で比較できるようにすることです。10 秒から 60 秒までの各 horizon について、FACT 側では方向付き future return の平均や win rate を見て、DECISION 側ではそこから roundtrip cost を差し引いた net return を見る。これを long / short の両側で同じ形に揃えることで、はじめて「構造が方向非対称なのか」「gross では見えているのに net では死んでいるのか」といったことを事実ベースで判断できるようになります。

要するに今回は、新しい戦略を足したかったわけではありません。単一の Lead-Lag 構造そのものを、方向差まで含めて観測できる形へ持っていくことが目的でした。short 側だけで見えていたものを long 側にも広げることで、この観測機が「特定方向だけを見る試作機」ではなく、「単一構造を long / short 両面から読む観測機」として成立するかどうかを確認したかった、というのが今日の出発点です。

2. 今日やったこと：long側のEV込みDecision表示を追加し、ダッシュボードを最小構成へ整理した

今回の作業は、大きく分けると二つでした。ひとつは long 側の EV 込み Decision をちゃんと見えるようにすること。もうひとつは、その比較に必要な情報だけが残るように Grafana ダッシュボード自体を整理することです。どちらも派手な変更ではありませんが、「読める観測機」にするうえではかなり重要な作業でした。

まず確認したのは、long 側の判定ロジックそのものが未実装なのか、それとも可視化だけが不足しているのかという点です。コードを追ってみると、long / short 両方向の future fact と window_incremental net は、すでに同じ経路で集計される構造になっていました。方向付き future return は signed_delta_bps として計算され、long の場合は lag 側が上がれば正、下がれば負になります。勝率も signed_delta_bps > 0 で加算されるので、long は上昇で勝ち、short は下落で勝ちという対称な定義になっていました。さらに Decision に使っている net 化も、方向付き mean return に対して単純に roundtrip cost を差し引いているだけで、long 側だけ逆符号にするような処理は入っていませんでした。つまり、問題は long 側のロジック不足ではなく、Grafana 上で short しか表示していなかったことだったわけです。

そこで実装としては、既存の [DECISION] short@10..60s window_incremental net return bps パネルに対応する long 版を追加しました。やったこと自体は単純で、short 側パネルのクエリを複製し、direction="short" を direction="long" に切り替えた形です。ただし今回は、ただ 1 枚増やしただけでは終わらせませんでした。むしろ主眼は、今の研究判断に不要なパネルを削って、観測の読み口を固定することにありました。

実際、これまでのダッシュボードには SIGNAL 系や他の DECISION 系も残っていましたが、現段階の研究判断に必要なのはそこではありませんでした。いま知りたいのは、単一の Lead-Lag 構造について「サンプルが積まれているか」「gross の平均リターンや勝率に偏りがあるか」「執行コスト込みで net が残るか」の三点です。ならば、まず残すべきなのは FACT 系の三枚、つまり Future Samples、Future Mean Return bps、Future Win Rate % です。そしてそれに加えて、short と long の EV 込み Decision を各 1 枚ずつ置けば、今回の研究目的には十分です。逆に、それ以外の情報はこの時点では解釈コストを増やすだけで、判断を助けるよりもノイズになりやすいと考えました。

その結果、今回のダッシュボードは以下の最小構成に整理しました。FACT 側は [FACT] Future Samples、[FACT] Future Mean Return bps、[FACT] Future Win Rate % の三枚。DECISION 側は [DECISION] short@10..60s window_incremental net return bps と、新たに追加した [DECISION] long@10..60s window_incremental net return bps の二枚です。これで、上段の FACT で構造の濃さとサンプル状況を見て、下段の DECISION で EV 込みの実行可能性を見る、という読み方が固定できるようになりました。

今回は新しいアルゴリズムを足したというより、すでにある集計を「研究者である自分が迷わず読める形」に整えた作業だったと思っています。こういう整理は地味ですが、研究を続けるうえではかなり重要です。情報を増やすことよりも、今何を判断したいのかに合わせて観測インターフェースを削ること。その意味で今回やったことは、Lead-Lag 観測機の機能追加というより、「読むための形を固定した」作業だったと言った方が近いかもしれません。

3. 今見えていること：long側にも構造はあるが、執行コスト込みではまだ残っていない

今回 long 側の表示を追加して分かったのは、まず「long 側には何もない」という見方は少し雑だった、ということです。FACT 側の三枚を見る限り、long 側も samples は積み上がっており、future mean return もゼロ近辺に貼り付いているわけではなく、win rate も 50% を明確に下回っているわけではありません。少なくとも観測上は、lag 側が一定方向へ動く偏りが long 側にも存在していることは確認できます。つまり、long 側については「構造そのものがゼロ」なのではなく、「構造は薄くある」という読み方の方が実態に近そうです。

ただし、その一方で DECISION 側を重ねて見ると、話はそこで終わりません。今回の net return は、方向付き future mean return に 7.6bps の roundtrip cost を差し引いたものです。この前提で見ると、long 側の window_incremental net return は 10〜60 秒の各 horizon で明確なプラス帯を維持できておらず、少なくとも現時点では執行コスト込みの EV が残っているとは言いにくい状態でした。つまり long 側で起きているのは、「方向性が全くない」ことではなく、「観測上の方向偏りはあるが、その厚みがコストを超えるほどではない」ということです。

これは short 側との比較でも意味があります。前回まで見ていた short 側も、執行コスト込みで強いエッジが確認できたわけではありませんが、それでも long 側よりはまだ相対的にましな挙動を示していました。今回 long を並べて見たことで、Lead-Lag 構造は long / short で対称ではない可能性が高い、ということがはっきりしてきました。もし本当に完全対称な構造なら、同じ定義・同じ horizon・同じコスト前提で見たときに、long 側にももう少し近い形が出てもよいはずです。しかし実際には、long 側は gross の時点で short より薄く、net ではさらに弱い。ここには方向差があると考える方が自然です。

もちろん、この時点で「long 側は完全にダメ」と断定するにはまだ早いです。samples は積み始めていますが、長い horizon まで含めて十分な母数があるとはまだ言い切れませんし、時間帯によって見え方が変わる余地もあります。ただ、少なくとも現段階で言えるのは、long 側について「見えていなかっただけ」で済ませるのは難しい、ということです。見えるようにしてみた結果、確かに構造はある。しかしその構造は厚くない。そして、少なくとも今の 7.6bps 前提では実行可能な EV としてはまだ残っていない。これが今の一番素直な読みです。

今回の観測で重要だったのは、構造の有無と執行可能性を分けて読めたことでした。long 側にも future mean return や win rate の偏りはあるので、「lead-lag らしきもの」は存在しています。しかし、DECISION で net 化すると消える。ここでようやく、「構造がない」のではなく「構造はあるが執行コストで死んでいる」という層の違いが見えました。これは単に long 側を追加できたという以上に大きな収穫だったと思います。今後ほかの lead source や cost model を試すとしても、この区別ができること自体が観測機の価値になります。

4. 今日の結論：単一のLead-Lag構造を観測する機械としては一旦完成でよい

今日の作業を終えて思ったのは、この観測機は少なくとも「単一の Lead-Lag 構造を観測する」という目的に対しては、もう一旦完成扱いでよいということです。もちろん、将来的に情報源を差し替えたり、コストモデルを調整したり、より細かい条件分岐を足したりする余地はあります。ただ、それはこの観測機が未完成だからではなく、次の研究問いに合わせて派生させるための拡張です。今回の時点で必要だった役割、つまり「構造があるか」「どれくらい濃いか」「執行コスト込みで残るか」を long / short 両側で同じ土俵に乗せて継続監視する、という役割については、もう十分果たせる形になりました。

今回その判断ができた一番大きな理由は、読む順番が固定できたことです。まず FACT の三枚で、サンプル数が積み上がっているか、future mean return に偏りがあるか、win rate が 50% を超えているかを確認する。ここで構造の濃さを見る。そのうえで DECISION の二枚に下りて、同じ horizon 群について roundtrip cost を差し引いた net return が残るかを確認する。これで、「構造そのものの有無」と「執行可能な EV の有無」を意識的に分けて読めるようになりました。観測機として大事なのは、この読み口が毎回ぶれないことだと思っています。今回の最小構成ダッシュボードは、その意味でかなり安定しています。

しかも今回は、単に情報が増えただけではありませんでした。long 側を追加したことで、short 側だけを見ていたときには曖昧だったことがかなり明確になりました。Lead-Lag 構造は long / short で完全対称とは限らないこと、gross では見えている偏りが net では消えること、そして「構造がある」と「執行できる」がまったく同じ意味ではないこと。このあたりが一枚の画面の中で読めるようになったことで、この観測機は試作品から一段進んで、少なくとも研究判断の起点として使える道具になったと思います。

重要なのは、ここで無理に作り込みを続けないことでもあります。こういう段階で機能を足し続けると、観測機だったものがいつの間にか最適化機になってしまい、何を観測して何を判断したいのかがぼやけやすくなります。今回は逆に、使っていないパネルを落とし、必要な読み口だけを残したことで、「何のための機械か」がかなりはっきりしました。これは完成度の問題というより、責務の問題です。単一の Lead-Lag 構造を long / short、gross / net で読む。その責務が固定できたので、ここで一旦完成とみなしてよいと判断しました。

言い換えると、今回できたのは「Lead-Lag のエッジが見つかった」ということではありません。そうではなく、「Lead-Lag のどの層までが見えていて、どの層で死んでいるのかを見分ける観測機」ができた、ということです。構造がゼロなのか、構造はあるが薄いのか、執行コスト込みで残らないのか。その切り分けができるなら、研究の次の一歩もかなり踏み出しやすくなります。そういう意味で、この観測機は今後の派生研究の土台としても使えるし、今日の時点ではここで一旦区切ってよい、というのが今回の結論です。

5. これからやること：研究対象を分離しつつ、観測機の出力形は次の用途へ広げていく

今回の区切りで終わりにしたいのは、Lead-Lag 研究そのものではありません。ここで一区切りにしたいのは、あくまで binance_perp -> bf_fx という単一構造を、FACT と DECISION の役割分担で読める形にしたフェーズです。ここから先は、この観測機をそのまま肥大化させるのではなく、研究対象を分離しながら次の段階へ進めていきます。

ひとつは、次の Lead-Lag 研究です。こちらについては、Binance をベースにしつつ、リード対象を取引所以外に置いた最小構成の観測プロジェクトを、すでに別系統で立ち上げ始めています。今回の観測機をそのまま土台にせず、あえて最低限の雛形から別に作っているのは、研究が混ざるのを避けるためです。いま完成させた観測機は binance_perp -> bf_fx を読むためのものとして固定し、次に見る対象は別プロジェクトで観測する。この切り分けをしておいた方が、「どの仮説を、どの観測機で見ているのか」がぶれにくいと考えています。

もうひとつは、今回の観測機のアプリ化です。ここで言うアプリ化は、いきなり多機能な売り物を作るという意味ではなく、まずは今回固定できた読み方を、そのまま別の出力形へ持っていけるようにすることです。今回の成果として大きかったのは、上段の FACT 三枚で構造の濃さを見る、下段の DECISION 二枚で執行コスト込みの EV を見る、という画面の役割分担がかなり明確になったことでした。この構成は Grafana 上でも十分機能していますが、将来的に自分用の観測アプリとして整理していくなら、まず移植したいのはこの「読み方」そのものです。

つまり次のフェーズでは、研究対象については別プロジェクトで最小構成から観測を始めつつ、出力形については今回の FACT / DECISION というインターフェースを保ったまま、アプリとして再利用できる形を考えていくことになります。新しい仮説は新しい観測機で見る。一方で、観測結果をどう読むかという型は今回の成果として残す。この二つを分けて進めることで、研究も実装も散らかりにくくなるはずです。

今回の観測機は、単一の Lead-Lag 構造を読む装置としては一旦ここで固定してよいと思っています。そのうえで次は、研究対象は横に広げ、出力形は別用途へ展開していく。ここから先は、そういう進み方になるはずです。