こんにちは、ぼっちbotterよだかです。
前回までで、歪み回帰については「少なくとも今の定義では主戦場の収益構造になっていない」というところまで確認できたので、今回は研究対象をリードラグへ切り替えることにしました。ただ、いきなりシグナル化や執行判断に進むのではなく、まずは「リードラグは何を収益源とするのか」「そのために何を観測できるようにすべきか」を整理し、その入口となる最小構成の観測器を作るところまでを今回の到達点にしています。今回は、leadlag専用の導線と監視基盤を分離し、binance_perp → bf_fx の future fact を GOOD パネルで見られるようにするまでの開発ログです。
-
-
🛠️開発記録#492(2026/3/24)multi_market_probe開発ログ ― 歪み回帰をいったん凍結し、次の主戦場をリードラグへ移す判断をした話
続きを見る
1. リードラグ研究で本当に見たいものは何か
今回リードラグ研究に入るにあたって、最初に自分の中で整理しておきたかったのは、「そもそもリードラグとは何を収益源とする研究なのか」という点でした。ここが曖昧なままだと、どれだけダッシュボードやメトリクスを増やしても、結局は「それっぽい動き」を眺めるだけで終わってしまうからです。
自分はこれまで歪み回帰をかなり長く見てきました。歪み回帰で見ていたのは、二つの市場のあいだに生じたズレです。ズレが広がったあと、それが将来縮むのかどうか。その縮みが主戦場で取れるのかどうか。研究の中心にあったのは、あくまで「相対位置」の変化でした。つまり、二市場のあいだの関係を、ある時点での“離れ具合”として捉えていたわけです。
一方で、リードラグはそこが違います。ここで本質になるのは、ある時点でどれくらい離れているかではなく、どちらが先に動き、その動きがどのように後から伝わるのかです。つまり、リードラグ研究で見たいのは、相対価格の水準そのものではなく、情報や圧力が市場間を伝わる順序と時間差です。
この違いはかなり大きいと思っています。歪み回帰は「離れたものが戻るか」を見る研究です。リードラグは「先に起きた変化が、後から別の市場にどう現れるか」を見る研究です。前者は位置の話で、後者は時間の話です。同じ市場間研究でも、見ている軸が違う。ここを曖昧にしたまま進むと、たぶん途中で観測も判定も混ざります。
では、リードラグは何を収益源としているのか。自分の今の理解では、それは**遅れて反応する市場の“未反映部分”**です。
先に動く市場があり、あとから動く市場があるとき、両者のあいだには一瞬だけ「まだ後者に織り込まれていない情報」が残ります。リードラグが収益になるとしたら、それはまさにこの部分です。価格差が縮むことそれ自体ではなく、先に動いた側の情報が、まだ完全には反映されていない時間差の部分を取る。リードラグ研究の本質は、たぶんここにあります。
だから、リードラグは見た目の印象ほど単純ではありません。よくある説明では、「先に動く市場を見て、遅れて動く市場で先回りする」と言われます。もちろん間違いではないのですが、これだけだとかなり雑です。重要なのは、その“先回り”が何に対して成り立っているのかということです。ただ同時に上がりやすいとか、似た方向に動きやすいというだけなら、それは単なる市場連動かもしれない。地合いが良いときにみんな同方向へ動いているだけなら、そこにリードラグ固有の収益構造があるとはまだ言えません。
ここで自分が特に気をつけたいのは、「同時に動いていること」と「先に動いたものが後から伝わっていること」を混同しないことです。これはかなり重要です。二市場が似た方向に動くこと自体は、別に珍しくありません。共通の外部要因があれば、そもそもそうなりやすい。だから、単に方向が一致したというだけでは足りません。リードラグとして見たいのは、その一致の中に時間順序があること、しかもその順序が偶然ではなく、ある程度安定した形で現れていることです。
ここまで考えると、リードラグ研究で本当に見たいものはだいぶ絞られてきます。見たいのは、「何となく Binance が強そう」といった感覚ではありませんし、「二市場が似たようなチャートをしている」という印象でもありません。見たいのはもっと地味で、もっと厳密なものです。ある市場の変化を起点としたとき、別の市場の将来変化に方向性のある偏りが生まれるのか。その偏りには時間構造があるのか。その構造は繰り返し観測できるのか。まずはそこです。
逆に言えば、リードラグ研究でいきなり「勝てるか」を見に行くのは、少し順番が悪いとも思っています。もちろん最終的には収益に繋がらなければ意味がありません。ただ、収益というのは執行コストやスプレッドやスリッページや持ち時間など、色々なものが一気に混ざった結果です。そこを初手から見に行くと、「構造がない」のか、「構造はあるが主戦場では取れない」のかが分からなくなる。だから最初は、もう少し手前で止めておく必要があります。つまり、まずは構造候補としての時間差があるかどうかを見たいのです。
ここで大事なのは、リードラグ研究の目的を最初から大きくしすぎないことだと思っています。最初から「最適な tau を見つける」「判定器を返す」「売買シグナルに落とす」といったところまで欲張ると、観測すべき事実より先に解釈の装置を作ることになります。それは今の自分が避けたい流れです。今回は第1回なので、もっと手前に留まりたい。何が lead で、何が lag なのか。その関係に時間差があるのか。その時間差が将来変化として現れるのか。まずはそこを、できるだけ余計なものを混ぜずに見たいと思いました。
自分の中では、今回の研究テーマは「リードラグを使って儲ける方法を考える」よりも、もう少し前段にあります。もっと正確に言うなら、リードラグという言葉で呼びたくなる現象が、本当に市場間の観測対象として存在しているのかを確かめることです。ここが白にならなければ、その先の最適化もシグナル化も意味がありません。逆に、ここが白なら、そこから先に初めて「どの時間幅か」「どの市場ペアか」「主戦場で取れるのか」という問いに進めます。
つまり今回のリードラグ研究で本当に見たいのは、派手な結論ではありません。見たいのは、もっと地味なものです。市場Aの変化が、市場Bの将来変化として時間差をもって現れるのか。しかもそれが、ただの同時連動ではなく、順序を持った構造として観測できるのか。まずはそれだけです。
今回やろうとしているのは、その問いに対して、感覚ではなく事実で答えられる入口を作ることです。リードラグ研究という名前を付ける以上、最初に見るべきなのは、たぶんそこだと思っています。
2. 今回の目標は「研究を始められる状態」を作ることだった
今回の開発で最初にやったのは、いきなりリードラグの判定ロジックを詰めることではありませんでした。むしろ逆で、まずはリードラグ研究だけに集中できる状態を作ることを優先しました。
理由は単純です。前回まで使っていた multi_market_probe には、歪み回帰研究のために積み上げてきた実装やデータや監視系がかなり残っていました。もちろん、それ自体は無駄ではありません。実際、今回も基盤の多くはそのまま流用しています。ただ、そのままの状態でリードラグ研究を始めると、どうしても頭の中で「今見ているもの」が混ざります。歪み回帰のための state や reason、旧来の評価軸、既存のログや保存先などが同じ導線に乗っていると、研究テーマを切り替えたつもりでも、実際には前の研究の延長線上で物を見てしまいやすい。
今回はそれを避けたかったので、最初の目標をかなり明確に置きました。
それが、**「研究そのものを進める前に、研究を始められる状態を作る」**ことです。
この方針にしたことで、今回のタスクはかなりはっきりしました。やるべきことは大きく3つです。
ひとつ目は、leadlag専用の運用導線を作ることです。
今回はこのために、起動・停止・状態確認を ll-up / ll-down / ll-status に寄せる形にしました。ここでやりたかったのは、単に make コマンドを増やすことではありません。重要なのは、「今日からリードラグ研究を回す」と決めたときに、どのコマンドを叩けばいいのかが一意に決まる状態にすることでした。運用の入口が曖昧だと、研究の入口も曖昧になります。逆に、入口がはっきりしていれば、研究対象もだいぶはっきりしてきます。
ふたつ目は、監視と保存の流れを leadlag 用に分けることです。
ここでは Prometheus と Grafana の扱いをどうするかも整理しました。結果として今回は、Prometheus は leadlag 用を新しく分離し、Grafana は既存を共用する形にしています。これはかなり実務的な判断でした。Grafana まで完全分離してもよかったのですが、そこまでやると運用コストが上がります。一方で Prometheus の時系列は、研究対象が違うものを同じ箱に入れると読みづらくなりやすい。なので今回は、「時系列は分けるが、可視化の器は共用する」というところで落ち着きました。
あわせて、設定も overlay で分離する形にしました。今回作った leadlag 用 overlay では、j_reversion を止めたうえで、leadlag 研究に必要な設定だけを上から当てるようにしています。これによって、同じ基盤を使いながらも、「今は歪み回帰ではなく leadlag を見ている」という前提を実行時に固定できるようになりました。ここはかなり大きかったです。研究テーマを切り替えたと言いながら、実行時には旧来の判定が動いている、という状態は避けたかったので、ここで明示的に線を引きました。
三つ目は、リポジトリ内部を研究対象ごとに見分けやすくすることです。
今回かなり意識したのは、単にコードが動くことだけではなく、「今どこを触っているのか」がすぐ分かる状態にすることでした。そこで、凍結した OBI 系、凍結した歪み回帰系、現行の leadlag 研究系、という3区分を明示する形に整理を入れました。core、scripts、tests、docs、data の各レイヤで、少なくとも「何が現行で、何が凍結なのか」が追いやすいようにしています。
ここで大事だったのは、最初から全部を完全移設しないことでした。いきなり大規模な物理分離をやると、今度は整理そのものが主作業になります。今回はそこまでやりたかったわけではありません。欲しかったのは、leadlag 研究を進めるうえで、余計なものが目に入りにくい状態です。なので、互換リンクもかなり残していますし、基盤の再利用もそのまましています。見た目をきれいにすることよりも、「明日から迷わず研究を再開できること」を優先しました。
この段階で自分の中で意識していたのは、今回の開発を“整備タスク”として引っ張りすぎないことです。環境を整える作業は大事ですが、それ自体が目的になりやすい。make コマンドが整理され、保存先が分かれ、Grafana で別ダッシュボードが見えるようになると、それだけで仕事をした気になりやすいです。でも本当に欲しいのは、そこではありません。欲しいのは、その先の研究に入れることです。
だから今回の土台整備は、あくまで最短で一区切りをつける前提で進めました。
リードラグ研究用の導線が通る。
旧来の歪み回帰系は止まる。
出力先は leadlag 側にまとまる。
どこを触ればいいかが分かる。
ここまでできたら、環境整備としては十分です。
実際、この段階まで来た時点で、ようやく「では、何を最小実装として観測するか」という次の問いに進めるようになりました。つまり、この章で書いている作業は、それ自体が今回の主役ではないものの、今回の記事全体の土台ではあります。リードラグ研究を始める前に、まず研究対象の混線を減らし、leadlag だけに集中できる運用状態を作る。この整理を先に済ませたことで、次の実装ではかなり迷いが減りました。
今回の目標をあらためて言うなら、単に「環境をきれいにした」のではなく、リードラグ研究を、歪み回帰の続きではなく独立した研究テーマとして扱える状態にしたということになります。ここまでやって、ようやく実装の中身そのものに入れる準備が整いました。
3. 最小実装として、binance_perp → bf_fx の future fact を観測することにした
土台を分けたあと、次に決めたのは「では、何を最小実装として観測するのか」でした。ここで最初から複雑な判定器を作りにいくと、今回やりたかったことがまたぼやけます。自分が今回ほしかったのは、完成版の J-LeadLag ではありません。まずは、lead 側の変化を起点にしたとき、lag 側でどんな future fact が出るのかを、素朴に見られる一本でした。
そこで今回は、対象をかなり意識的に絞りました。
ペアは binance_perp -> bf_fx の1本だけ。設定側でも lead_market: binance_perp、lag_market: bf_fx を明示し、今回の研究対象を最初からこの1ペアに固定しています。さらに、歪み回帰判定は enabled: false にし、leadlag 側だけを有効にしました。つまりこの時点で、「今回の観測器はどの市場の何を見るのか」がかなりはっきりした状態になっています。
今回、anchor の定義として採用したのは lead_return です。
これは既存の diag_signal_pass を起点にするのではなく、lead 市場そのものの短期 return が一定閾値を超えた瞬間を anchor にするという方針です。_LeadLagForwardTracker の初期化でも、anchor_mode、anchor_return_window_sec、anchor_return_threshold_bps、anchor_return_cooldown_sec が引数として追加されていて、従来の診断イベント起点ではなく、lead 側価格変化起点でも動くようになっています。
この変更は、自分の中ではかなり重要でした。前章で書いた通り、今回見たいのは「判定器がそう言っている」ことではなく、先行市場の変化のあとに、遅行市場がどう動くのかという事実です。だから anchor も、できるだけ素朴なものに寄せたかった。lead_return にしたのは、そのためです。たとえば overlay 側では、anchor_return_window_sec: 1.0、anchor_return_threshold_bps: 2.0、anchor_return_cooldown_sec: 0.2 としていて、「1秒窓で2bps以上動いた lead 側変化」をひとまずの起点として置いています。
実装の中でも、その考え方はかなりそのまま入っています。_LeadLagForwardTracker では、lead 側の mid を履歴として持ち、一定時間前の価格を引いて短期 return を計算し、その return が閾値を超えたときにだけ anchor を作るようになっています。しかも、前の瞬間もすでに閾値超えだった場合には新しい anchor を作らず、閾値を跨いだ瞬間だけを拾うようにしてあります。さらに cooldown もかけて、同じ方向に連続して細かくアンカーを打ちすぎないようにしています。つまりここでは、単に「動いたら毎回イベント」ではなく、lead 側短期変化の立ち上がりだけを anchor として扱う設計になっています。
次に決めたのが、anchor のあとに lag 側で何を見るかです。
ここで今回は、最初から executable を見るのではなく、bf_fx の future mid return に限定することにしました。これもかなり意図的な選択です。最終的に収益化を考えるなら executable を見なければ意味がないのですが、今の段階でそこまで入れると、spread や滑りや entry/exit 仮定まで全部混ざってしまう。今回はまず「時間差としての構造候補があるか」を見たいので、最小構成として lag 側 future fact は mid ベースに寄せました。
horizon は 1 / 3 / 5 / 10 / 30 秒 にしました。
設定側でも future_horizons_sec: [1, 3, 5, 10, 30] を直接渡していて、サービス側では _coerce_horizons() でこれを読み取り、そのまま _LeadLagForwardTracker に食わせる形にしています。ここでわざわざ 1 秒や 3 秒を入れたのは、「30秒でなんとなく良い」では leadlag 研究として弱いからです。短い遅延帯にどんな反応が出るのかを見たいので、今回は最初から horizon を細かく刻んでおくことにしました。
future fact の集計自体は、かなり素朴です。
anchor 発生時点の lag 側価格を持っておき、その後の lag 側 mid との比較から return を計算し、horizon ごとに成熟したサンプルを集計していきます。ここで良かったのは、符号を direction に合わせてそろえていることです。long anchor なら上昇がプラス、short anchor なら下落がプラスになるように signed return に直しているので、mean や hit rate をそのまま「方向一致の強さ」として読める形になっています。short 側だけ mean がマイナスでも実は当たりだった、というような解釈事故を避けやすい作りです。
そして今回、最初に出す future fact もかなり限定しました。
出すのは samples / mean / win rate の3つだけです。最初は median も distribution も best tau も考えましたが、それをやり始めると一気に話が広がります。だから今回は、「サンプルがどれだけ溜まったか」「方向付き平均リターンがどうか」「方向一致率がどうか」だけに絞りました。この判断は、自分としてはかなり正しかったと思っています。研究初手では、解釈の装置を増やすより、まず観測できる事実を3つくらいに限定した方が読みやすいからです。
この3つを Prometheus に載せるために、exporter 側には leadlag future fact 専用のメトリクスを新しく切りました。追加したのは、obx_mmarb_leadlag_future_samples_total、obx_mmarb_leadlag_future_mean_return_bps、obx_mmarb_leadlag_future_win_rate_pct の3本で、ラベルは lead_market / lag_market / direction / horizon_sec にしています。既存の J-LeadLag メトリクス群はそのまま残しつつ、今回の観測対象だけを別名で独立させたのは、かなり大事なポイントでした。これによって、「既存の判定器の数字」と「今回の最小 fact 観測」を混ぜずに扱えるようになったからです。
実際の更新関数もかなり単純で、サービス側で mature した future fact を取り出し、lead_market / lag_market / direction / horizon_sec ごとに samples、mean、win rate を gauge として吐くようにしています。今回の実装でやりたかったのは、まさにこれでした。つまり、内部で複雑な state を組み立てる前に、anchor のあとに何が起きたかだけを、方向別・時間幅別のメトリクスとしてまず外に出すことです。
ここで面白いのは、既存の J-LeadLag 判定部自体はまだ 10/30/60s 前提で動いていることです。_build_j_leadlag_trackers() 側は引き続き h10/h30/h60 を使い、samples_30s や hit_rate_30s_pct を中心に state を更新しています。つまり今回の実装は、判定器全体を作り直したわけではありません。そうではなく、既存の J-LeadLag は残しつつ、その横に「今回ほんとうに見たい最小 fact」を追加したという構造になっています。これは自分にとってかなり重要でした。いきなり全部を置き換えるのではなく、まずは fact を追加して、それが本当に読む価値のあるものかを先に見る。今回はそこに徹しています。
やりたかったことを一言でまとめるなら、こうです。
今回は「リードラグ判定器を完成させる」ための実装ではなく、lead 側の短期変化を起点に、lag 側 future fact を方向別・時間幅別に観測する最小構成を一本通すための実装をした、ということです。対象市場も、anchor も、horizon も、出力メトリクスも、かなり意図的に絞りました。次の章では「では、その fact をどう可視化したのか」ということを書きます。
4. GOODパネルに samples / mean / win rate を出すまで実装した
最小実装として何を観測するかが決まったので、次にやったのは、その future fact を人間が読める形で GOOD パネルに載せることでした。今回ここで重視したのは、見た目の派手さではありません。むしろ逆で、最初はできるだけ素朴に、「サンプルがどれだけ積まれているか」「平均がどちらに寄っているか」「勝率がどのくらいあるか」だけを並べることにしました。
その結果として追加したのが、スクリーンショットに出ている3枚の GOOD パネルです。
左から順に、
- Future Samples
- Future Mean Return bps
- Future Win Rate %
を出しています。ここでやりたかったのは、lead 側の変化を anchor にしたあと、bf_fx 側でどんな future fact が出ているのかを、1/3/5/10/30秒という horizon ごとに、long / short を並べてそのまま読めるようにすることでした。
まず、左の Future Samples はかなり大事です。
最初にこれを置いたのは、どれだけ mean や win rate が良さそうに見えても、サンプルがほとんどなければ意味が薄いからです。実際、このパネルを見ると、少なくとも今回の設定では各 horizon でサンプルが着実に積み上がっており、しかも完全に片側だけという感じでもありません。これは初手としてかなり重要でした。今回の anchor 設定が極端に厳しすぎて「何も起きない」状態ではないし、逆に過剰に発火してノイズだらけになっているわけでもない。まずは観測器としてちゃんと回っていることを、このパネルで確認できるようにしました。
次に真ん中の Future Mean Return bps です。
ここは今回の GOOD パネルの中心でした。自分が今回最初に見たかったのは、lead 側の短期変化を起点にしたとき、bf_fx の future mid return が方向付きでどちらへ寄るのか、という事実です。そのため、このパネルでは long / short を direction に合わせて符号調整した signed return の平均値を horizon ごとに並べています。つまり、ここでプラスに寄っているということは、「その direction に沿って future return が出ている」という意味になります。
このパネルの良いところは、30秒だけではなく 1秒や3秒も含めて横並びで見られることです。もし30秒だけ見ていると、「何となく良さそう」で終わってしまいます。しかし、1/3/5/10/30秒を同時に見ると、短い時間帯からすでに方向一致が出ているのか、それとも長めの horizon でようやく平均がプラスに寄るのか、かなり印象が変わります。今回ここを並べたのは、後から「どの遅延帯に特徴があるのか」を見に行きやすくするためでもありました。
右の Future Win Rate % は、mean を補助するために入れたパネルです。
平均だけだと、一部の大きな値に引っ張られて良く見える可能性があります。逆に win rate だけだと、一回一回の値幅が小さくても高く見えてしまう。だから今回は、mean と win rate をセットで読む構成にしました。平均がプラスに寄っていて、かつ win rate も高いなら、その future fact はかなり素直です。片方だけが良いなら、まだ慎重に見た方がいい。今回の GOOD パネルでは、そういう読み方ができるようにしたかったわけです。
スクリーンショットを前提にすると、この3枚はかなり素直に役割分担しています。
まず Samples で「そもそも観測母数があるか」を見る。
次に Mean Return で「direction に沿った future return が平均的に出ているか」を見る。
最後に Win Rate で「その偏りが一発の外れ値ではなく、勝率としても出ているか」を見る。
かなり地味ですが、研究初手としてはこれくらいの素朴さでちょうど良かったと思っています。
ここで重要だったのは、既存の state や score を主役にしなかったことです。
もちろん、既存の J-LeadLag 系には state や reason や score のような指標がありますし、それらも今後まったく不要になるわけではありません。ただ、今回はそこに寄りすぎると、「判定器の内部状態」を先に読んでしまうことになります。自分が今回見たかったのは、あくまで判定器の手前にある future fact です。つまり、「この anchor のあとに実際に何が起きたのか」をまず見たかった。だから GOOD パネルでは、既存の state machine 由来の数字ではなく、新しく切った future fact 専用メトリクスを主役にしました。
実際、この切り方にしたことで、読み方もかなり単純になりました。
パネルを見て最初に考えることは、「この state は何を意味するのか」ではありません。そうではなくて、
- サンプルは積まれているか
- 平均はプラスか
- 勝率はどれくらいか
- それが horizon ごとにどう違うか
だけです。この単純さはかなり大きいです。研究初期に一番避けたかったのは、「色々出ているけれど、結局どこを見ればいいのか分からない」という状態でした。今回の GOOD パネルは、少なくともそこは避けられています。
もちろん、これで十分だとは思っていません。
まだ distribution の形も見ていませんし、median も見ていませんし、best tau もまだ分かりません。long / short の非対称性も、この3枚だけで完全に切り分けられるわけではないです。さらに言えば、これは mid ベースなので、収益化可能性をそのまま意味するものでもありません。ただ、今の段階でそこまで欲張ると、また観測と解釈が混ざり始めます。今回の目的は、まずlead 側変化のあとに lag 側 future fact がどう出るのかを、人間が低コストで読めるようにすることでした。その意味では、この3枚のパネルでかなり十分でした。
自分の中では、この GOOD パネルを出せたことで、ようやく「判定器の研究」ではなく「構造の研究」に戻れた感覚があります。スコアや state を見ていると、どうしてもロジックの正しさに目が向きます。でも Samples / Mean / Win Rate を見ていると、目線が素直に市場側へ戻る。つまり、「この anchor のあとに bf_fx は実際どうなっているのか」という問いに戻れるわけです。今回ここまでを実装できたことで、次の章では「それを2時間ほど回して何が見えたのか」という観測の話について書きます。
5. 2時間回して見えたことと、まだ言えないこと
最小実装が通ったので、ここからは実際にしばらく回してみて、何が見えるのかを確認しました。今回はおよそ2時間ほど稼働させ、そのあいだのダッシュボードを見ながら、まずは「観測器として成立しているか」「future fact に意味のある偏りが出ているか」を読むことにしました。
今回のパネルは大きく Q → S → E → GOOD の順で見ると、かなり読みやすかったです。
最初に観測の健全性を見て、その次に既存判定の揺れ方を見て、既存の30秒系メトリクスを確認し、最後に今回追加した GOOD パネルで新しい future fact を読む。少なくとも今回の段階では、この順番で見るのがいちばん素直でした。
まず Q：観測器としては素直に動いている
最初に見たのは Q です。ここでは Ready Flag と Quality Flag が long / short ともに 1 のまま維持されており、タイムラインでも大きく崩れていませんでした。ここはかなり重要です。今回の結果が多少良く見えたとしても、そもそも観測器の準備状態や品質フラグが不安定なら、まず疑うべきは構造ではなく配線やデータ品質になります。
今回はそうではなかった。少なくともスクリーンショットの範囲では、Q はかなり安定しています。つまり、「何か良さそうに見えるのは、たまたま欠損のない区間を切り取ったから」という状態ではなさそうです。この時点でようやく、次の S や E、GOOD を見にいく前提が整います。
今回自分がここで確認したかったのは、リードラグ研究用に切り出した導線が本当に独立して動いているかどうかでした。Q が long / short ともにずっと 1 を維持しているのを見る限り、少なくとも今回の最小観測器は「観測以前の段階」でつまずいてはいません。まずはそこが確認できた、というのが最初の収穫でした。
次に S：既存の state / reason はまだ結論の主役ではない
次に S を見ると、State Code 自体は一定の値を返しているものの、State/Reason Timeline では reason 側がかなり細かく動いています。現時点のスナップショットでは long が 2、short が 1 になっていますが、タイムラインを見ると 100 / 200 / 300 あたりを行き来しており、まだかなり落ち着きません。
ここは正直、今回の段階ではあまり深読みしない方がいいと思っています。理由は単純で、今回追加した GOOD パネルの future fact は、既存の J-LeadLag 判定ロジックとは少し違う軸を見ているからです。今回の実装では、lead 側の短期 return を anchor にして、その後の bf_fx future mid return を素朴に見にいきました。一方で S は、従来からの state / reason の文脈をまだかなり引きずっています。つまり、ここで reason の数字を追いかけ始めると、「新しく見たいもの」より先に「既存判定の内部都合」を読んでしまいやすい。
なので今回は、S は補助的な読み方に留めました。
Q が安定しているにもかかわらず S がかなり揺れている、ということ自体は意味があります。少なくとも「観測品質は悪くないが、既存判定はまだ安定していない」ことは分かる。ただ、その揺れをそのままリードラグの有無だと読む段階ではまだありません。今回の主役はここではなく、次の E と GOOD です。
E：既存30秒メトリクスでも、方向付きの偏り自体は見え始めている
その次に E を見ると、ここで少し面白いことが起きています。
まず 30s Samples は long / short ともに着実に積み上がっており、2時間時点でだいたい 90〜100 前後まで増えています。これはかなり大事です。どれだけ平均や勝率が良くても、サンプルがほとんどなければまだ話になりません。今回の設定では、少なくとも「ほとんど発火しない」状態にはなっていませんでした。
さらに 30s Hit Rate (%) を見ると、long / short ともに 70% 台前半で安定しています。long がだいたい 72〜74% 前後、short が 74〜76% 前後に見え、短い観測時間のわりにはかなり素直です。もちろん、これだけで構造ありと断定はできませんが、少なくとも「50% 近辺をうろうろしているだけ」ではない。
30s Delta Mean / Latest (bps) はもっと分かりやすいです。mean 側は long / short ともにおおむね +2〜3bps 台に位置している一方で、latest は普通に上下へ振れています。ここはかなりそれっぽい見え方でした。つまり、「イベントごとの最新値は荒れるが、平均としては方向付きでプラスに寄っている」ということです。個々のイベントが全部きれいに同じ方向へ進むわけではないが、平均すると方向一致のバイアスが出ている。これは、少なくとも leadlag 研究の入口としては悪くない形です。
一方で Core Metrics の score や stability はかなり低位で、pairs だけが高い位置で固定されています。ここも今の段階では自然だと思っています。今回の関心は完成版の判定器を立てることではなく、最小fact観測を通すことでした。したがって、score や stability が綺麗に立たないこと自体は、今すぐ致命的な問題ではありません。むしろ、既存の判定器側はまだ主役ではない、ということを裏から示しているようにも見えました。
最後に GOOD：今回本当に見たかった future fact は、かなり素直に出ている
そして今回いちばん見たかったのが GOOD パネルです。
ここでは Future Samples、Future Mean Return bps、Future Win Rate % を horizon 別に並べています。ここを見てまず安心したのは、Samples が 1/3/5/10/30 秒の各 horizon でちゃんと積み上がっていることでした。しかも片側だけが極端に少ないわけではなく、long / short の両方で母数が取れています。今回の anchor 条件が厳しすぎて何も起きない、ということは少なくとも避けられました。
次に Future Mean Return bps ですが、これがかなり素直でした。1秒から30秒まで、少なくとも今回のスクリーンショットではどの horizon もおおむねプラス圏にあります。ざっくり見ると +2.2〜+3.0bps くらいの帯に収まっており、完全にバラバラという感じではありません。方向別に符号を合わせた signed return を使っているので、ここでプラスに寄っているということは、「その direction に沿った future return が出ている」という意味になります。少なくとも初手の観測結果としては、かなり悪くない見え方でした。
Future Win Rate % も同様で、全体として 70% 台後半から 90% 台まで、かなり高めに見えます。特に horizon によっては 90% 近辺に張り付いており、Mean と合わせて見る限り、今の設定では「何もない」よりはずっと良い状態です。ここは今回いちばん収穫だった部分だと思います。少なくとも、lead 側の短期変化を anchor にしたとき、bf_fx 側の future mid return が方向一致でプラスに偏る、という事実自体は観測できています。
では、何が見えたのか
ここまでをまとめると、今回の2時間稼働で見えたのは次のようなことです。
まず、観測器は安定して動いている。Q は崩れていません。
次に、既存30秒系メトリクスでも、方向一致の平均と勝率がある程度出ている。
そして何より、今回追加した GOOD パネルでも、1/3/5/10/30 秒の future fact が long / short 両方でプラス寄りに出ている。
つまり、かなり控えめに言っても、「lead 側変化のあとに bf_fx が方向一致で動く」という構造候補は、少なくとも今の設定では観測できている、ということになります。ここはゼロではなかったし、少なくとも何も起きていないわけではありませんでした。
ただし、まだ言えないこともかなり多い
一方で、ここで浮かれすぎるのも違うと思っています。
まだ言えないことはかなり多いです。
まず、これはまだ mid ベース です。
したがって、この結果をそのまま「収益化できる」と読むことはできません。spread、slippage、entry/exit 仮定、holding の取り方を考えれば、+2〜3bps 程度の偏りは executable では簡単に消える可能性があります。したがって、今回見えたのはあくまで「構造候補としての future fact」であって、「利益が出る構造」ではまだありません。
次に、今回の GOOD が良く見えている理由が、本当に leadlag なのかもまだ切り分けきれていません。
ここはかなり重要です。たとえば今回の anchor は、lead 側の 1 秒 return が一定閾値を超えた瞬間です。これは見方によっては、「単に強い短期モメンタム局面を切っている」だけかもしれません。もしそうなら、今見えているのは純粋な leadlag というより、「同じ方向へ持続しやすい強い地合い」を拾っている可能性があります。つまり、先に動いたものが後から伝わっているのか、ただ同じ方向へしばらく動きやすい局面を切っているだけなのかは、まだ分かりません。
さらに、どの horizon が本当に効いているのかもまだ曖昧です。
今回は 1/3/5/10/30 秒を並べていますが、どれもそこそこ良く見える一方で、「ここが明確にピークだ」という感じはまだありません。もし本当に leadlag なら、より短い遅延帯に特徴が出る可能性がありますし、逆に全部同じように良いなら、持続モメンタム寄りの見え方かもしれません。ここも、次の観測で詰めていくべきポイントです。
要するに、今回の観測結果はかなり前向きではあるものの、その意味づけはまだ早い。
少なくとも今言えるのは、binance_perp の短期変化を起点にしたとき、bf_fx の future mid return に方向一致の偏りが出ること自体は観測できたということです。逆に言えば、そこから先――それが本当に leadlag なのか、どの時間帯が効いているのか、主戦場で取れるのか――は、まだこれからです。
今回の2時間稼働は、まさにその入口としては十分でした。
「何もない」ではなかった。
しかも、Q が安定した状態で、E と GOOD の両方にそれなりの偏りが出ている。
ここまで見えたことで、ようやく「では、この結果をどう受け取って、次に何をやるのか」を具体的に考える段階に入れたと思っています。
6. 今回の結論：リードラグ研究の入口を、ようやく作り終えた
今回の開発を一言でまとめるなら、やったことは「リードラグで勝つ方法を見つけた」ではありません。
もっと手前の、しかし自分にとってはかなり重要な段階として、リードラグ研究を事実ベースで始められる入口を、ようやく作り終えたというのが正確だと思っています。
これは地味な前進に見えるかもしれません。でも、自分の中ではかなり大きいです。なぜなら、ここ数週間ずっとやっていた歪み回帰研究では、「構造としてはありそうに見えるもの」と「主戦場で取れるもの」のあいだにかなり大きな隔たりがあることを、実際の観測と検証を通して確認してきたからです。あの流れを踏まえた今、次の研究テーマに入るなら、最初から同じ轍を踏まないことが重要になります。つまり、「何となくありそう」から入るのではなく、何を収益源候補として見にいくのかを先に定義し、その候補に対して最小限の fact を取りにいく必要がありました。
今回、その最初の形は作れました。
少なくとも今の時点で言えるのは、binance_perp の短期変化を anchor にしたとき、bf_fx の future mid return が方向一致でプラスに偏る、という事実自体は観測できたということです。しかも、サンプルがほとんどないまま偶然そう見えただけではなく、Q が安定し、サンプルも積み上がり、複数 horizon で mean / win rate が一応プラス寄りに見える状態まで来ています。これは、研究初日の成果としては悪くありません。
ただし、ここで重要なのは、この結果を過大評価しないことです。
今回見えたのは、あくまでfuture mid fact の偏りです。つまり、「lead 側の変化のあとに lag 側で方向付きの将来変化が見える」という段階であって、それがそのまま収益化可能性を意味するわけではありません。ここを混同すると、また研究が曖昧になります。
自分が最終的にやりたいのは、もちろん「リードラグっぽいものを観測すること」ではありません。
最終的な目的は、主戦場で取れる形にまで落ちる収益構造を見つけることです。
では、その目的に対して、これから何をやるべきなのか。
少なくとも次の4段階で詰めていく必要があると思っています。
1. まず切り分けるべきは、「leadlag」なのか「ただの持続モメンタム」なのか
今回の結果を見て最初に思ったのは、決して「お、もう勝てそうだ」ではありませんでした。むしろ、これが本当に leadlag なのかを切り分けないと危ないということでした。
今回の anchor は、lead 側の 1 秒 return が閾値を超えた瞬間です。これは見方によっては、「強い短期モメンタム局面」を切っているだけの可能性があります。もしそうなら、今見えているプラス偏りは、先行市場から遅行市場への情報伝播ではなく、単に「みんな同じ方向へしばらく動きやすい地合い」を拾っているだけかもしれません。
だから次にやるべき最初の仕事は、ここを切り分けることです。
たとえば、
- threshold を変えたときに結果がどう変わるか
- anchor window を変えたときに何が崩れるか
- 1/3/5/10/30 秒のどこに特徴があるか
- long / short で非対称性があるか
- lead の変化が弱いときにも同じ傾向が出るのか
といったところを見る必要があります。
本当に leadlag なら、単に「強いときほど全部良い」ではなく、もう少し時間差らしい構造が出てくるはずです。たとえば、特定の短い遅延帯で優位が強いとか、片方向だけ明確に偏るとか、あるいは threshold を上げたときにサンプルは減るが純度が上がるとか、そういう振る舞いです。逆に、どの条件でも似たように「なんとなく良い」なら、それは leadlag というよりモメンタム観測に近いかもしれません。
ここはかなり重要です。
収益化を考える以前に、いま見えているものの正体を言葉として確定させる必要があります。
2. 次に見るべきは、「どの時間幅で効いているのか」
リードラグ研究で収益化を考えるなら、時間幅は本質です。
今回 1/3/5/10/30 秒を並べたのは正解だったと思っていますが、まだ「どこが最適か」は見えていません。
ここから次にやるべきなのは、単に horizon を増やすことではなく、どの時間幅で反応が最大になり、どこから減衰し、どこから別物になるのかを観測することです。
自分が次に見たいのは、たとえばこんなことです。
- 1秒ですでに偏りが出ているのか
- 3〜5秒で strongest なのか
- 10秒や30秒まで良いのは、単なる持続なのか
- best tau の候補が本当に存在するのか
- その tau は日中で安定しているのか、それとも時間帯で飛ぶのか
もし本当にリードラグ由来の収益構造があるなら、「どこで入ってどこまで待つと一番素直か」という時間構造が見えてくるはずです。ここが見えないまま executable に進むと、結局 entry/exit の仮定で全部をごまかすことになります。だから、自分にとって次の大きなタスクは、時間差の存在を“何秒の構造か”まで言えるようにすることです。
3. その次に、ようやく executable へ降ろす
そしてここから先で初めて、主戦場としての現実が入ってきます。
今の good パネルは mid ベースです。これは研究初手として正しいですが、このままではまだ「収益」ではありません。
最終的にリードラグを収益化するということは、要するに
- lead 側を見た時点で
- lag 側にまだ未反映の部分があり
- その未反映部分が
- spread / slip / 遅延を超えて残る
ということです。
ここで初めて、「市場間構造の研究」が「実際の売買戦略の研究」に変わります。
したがって、その前にやるべきことは明確です。mid で構造候補が見えたあとに、同じ anchor に対して今度は bf_fx の executable ベースで future return を取り直すことです。entry をどこに置くか、exit をどう切るか、片側成行か両側想定か、holding を固定するのか first touch を見るのか。このあたりは後段でかなり詰める必要があります。
ただし、ここでも順番は守りたいです。
mid での構造確認が曖昧なまま executable に行くと、また「構造がない」のか「コストで死んでいる」のか分からなくなります。今回はその入口を作った段階なので、次にやるべきはすぐに収益化ではなく、executable に降ろしてよいだけの構造確認をもう一段進めることです。
4. 最後に、leadlag を「判定器」へ戻す
今回、意図的に state や score を主役から外しました。
でも最終的には、それらが不要だとは思っていません。むしろ逆で、収益化に近づくほど、最終的には「今この瞬間はやるべきか / やるべきでないか」を返す判定器が必要になります。
ただ、自分の中で順番ははっきりしています。
最初に判定器を作るのではなく、最初に事実を取る。
その fact から、どの条件で偏りが強いかを見つける。
そのうえで、ようやく state / score / stability を再設計する。
つまり、判定器は事実のあとに作るべきです。
今回の S パネルがまだ主役ではないと感じたのも、そこが理由です。今の S は既存ロジックの延長としては動いていますが、自分が本当に欲しい「leadlag 収益構造を判別する state machine」にはまだなっていない。だから次にやるべきは、既存の state を読み込むことではなく、GOOD パネルの fact から「どんな条件が良いのか」を逆算することです。その結果として、後から判定器へ戻していく。この順番なら、少なくとも“都合のよい判定器を先に作る”事故は減らせると思っています。
ここまでを踏まえると、今回の結論はかなりはっきりしています。
今回やったのは、リードラグ研究そのものの完成ではありません。
でも、単なる環境整備でもありません。
今回やったのは、リードラグで何を収益源候補として見にいくのかを定義し、その候補に対して最小限の fact を取り始める入口を作ったということです。
この「入口を作る」というのは、想像以上に大事でした。
研究テーマを変えるときに一番怖いのは、名前だけ変わって中身は前の研究の延長になることです。歪み回帰からリードラグへ移ると言いながら、実際には旧来のダッシュボードや旧来の state を見続けてしまう。そうなると、研究テーマを変えた意味がありません。今回はそこからきちんと抜けて、「何を見れば前進なのか」を先に定義し、そのための最小観測器を一本通せた。ここはかなり大きいです。
そのうえで、次回以降にやることもだいぶ明確になりました。
- threshold / window / cooldown を触って、今見えているものの正体を切り分ける
- horizon ごとの違いを読んで、どの時間幅が構造として効いていそうかを見る
- long / short の非対称性や時間帯依存を確認する
- mid の構造候補を executable に降ろして、主戦場で残るかを検証する
- その結果から、ようやく判定器を再構成する
要するに、次からは「整備」ではなく「白黒判定の研究」に入っていきます。
今日の開発の価値は、そこに入る前の最後の準備をきちんと終えたことにあります。
リードラグ研究を収益化するという目的に対して、今回の到達点はまだかなり手前です。
でも、その“かなり手前”を曖昧にせず、ちゃんと一段として踏めたのは大きい。
少なくとも、「何を見たいのか分からないままダッシュボードを眺める段階」ではなくなりました。
ここから先は、見えた fact をもとに、本当に市場間の時間差構造があるのか、それが主戦場で取れるのかを、順番に白黒つけていくフェーズです。