🛠️開発記録#498(2026/3/31)LeadLagの主仮説を7.6bps込みで見直し、この線はいったん下ろすと決めた話

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

今回は、multi_market_probe の LeadLag 研究について、これまで主線として見ていた binance_perp → bf_fx / short@30s を、執行コスト 7.6bps 込みで改めて見直し、この線はいったん下ろすと判断した話を書きます。作業の前半では REJECTED reason の詳細を掘っていたのですが、途中で「いま本当に見たいのはそこではなく、コスト込みでこの仮説が残るかどうかだ」と気づき、判定軸そのものを引き直しました。そのうえで、Grafana の途中確認用パネルを整え、ACCEPTED 側も含めて research EV ベースで観測し直した結果、少なくとも現時点ではこの線を主戦場として続ける理由は弱いと判断しました。今回は、その判断に至るまでに何が見えたのか、何を決めたのか、そして次にどこを掘り直すかを整理します。

1. 今日の再開地点：何を白黒判定したいのかを引き直した

今日の作業は、LeadLag の実装をそのまま先へ進めるところから始まったわけではありませんでした。むしろ最初にやったのは、「自分はいま何を白黒判定したいのか」を引き直すこと。

前段では、ORDER_INTENT の REJECTED reason を分解し、その内訳を Grafana 上で見えるようにするところまで進めていました。そこまでは意味がありましたし、実際に COOLDOWN_ACTIVE や QUALITY_NG が reject の主因になっていることも見えてきていました。ただ、その流れのまま作業を続けているうちに、少しずつ違和感も強くなってきました。いま自分が本当に知りたいのは、「REJECTED の中から昇格候補を拾えるか」より先に、「そもそもこの主仮説が執行コスト込みで残るのかどうか」だったはずだ、という違和感です。

今回の主仮説は、binance_perp → bf_fx を先行市場とみなし、short @ 30s にリードラグっぽい優位性があるのではないか、というものです。しかもそれは、直近2日間の観測では、他市場や他条件より相対的に良く見えた線でもありました。だからこそ、ここで先にやるべきなのは reject の救済可能性を細かく掘ることではなく、この線自体が 7.6bps の執行コストを踏まえてもまだ残るのかを見直すことでした。

ここで私は、一度、問いの主従を戻す必要があると感じました。REJECTED の内訳を掘るのは、あくまでその主仮説が残ると分かったあとでもできる作業です。逆に、主仮説そのものがコスト込みで残らないなら、reject の昇格ロジックをどれだけ磨いても本質的ではありません。つまり今日は、改善や最適化へ進む日ではなく、「いま何を判定したいのか」をもう一度まっすぐにする日だったのだと思います。

その前提で、CODEX に投げる指示も引き直しました。REJECTED reason の詳細分類や ACCEPTED への昇格可能性は一旦後ろに置く。その代わり、research_ev_equivalent_bps を主軸にして、まず binance_perp → bf_fx / short@30s を 7.6bps 込みで見直せるようにする。今日の再開地点は、まさにそこでした。

要するに、今日やったことの出発点は「LeadLag をどう改善するか」ではありませんでした。そうではなく、「この主仮説を、いまの条件で続ける価値があるのか」をきちんと白黒判定できる位置まで、自分の視点を引き戻すことだったということです。

2. 今日の観測で見えたこと：runtime評価と執行コスト込み評価はズレていた

今日の観測で一番はっきりしたのは、これまで前面に置いて見ていた runtime 側の評価と、自分が本当に知りたかった「執行コスト込みでの評価」とのあいだに、やはりズレがあったということでした。

もともとダッシュボード上では expected_edge_bps を見ていました。これは runtime 上で signal の強さから expected slip や fee を引いた軽い推定値で、構造候補の勢いをざっくり見るには使えます。ただ、今回自分が知りたかったのは、それではありません。いま確認したいのは、binance_perp → bf_fx / short@30s という主仮説が、執行コスト 7.6bps を踏まえてもなお正の期待値を残すのかどうかです。ここを知りたいのに、runtime の軽い expected edge を主表示のまま見ていると、候補が「それっぽく」見えてしまう一方で、コスト込みでは負、というズレが起こりえます。

実際、今回そこにかなり強い違和感がありました。runtime の expected_edge_bps では ACCEPTED も出ていて、数字自体も一見すると悪くなさそうに見える。けれども、それは 7.6bps をきちんと差し引いた研究用の評価ではない。このままでは、「通っているから良さそう」という runtime 側の都合に、主仮説の評価そのものが引っ張られてしまいます。そこで今回は、評価軸を research_ev_equivalent_bps 側へ寄せ直すことにしました。

このとき意識したのは、runtime の指標を消すことではなく、役割を下げることでした。expected_edge_bps は補助線としては残してよい。ただし、週内の白黒判定に使う主KPIは research_ev_equivalent_bps に置く。つまり、構造を見るための軽い runtime 指標と、執行コスト込みで白黒を出すための研究EVを、主従をつけて見直したわけです。

その前提で、Grafana 側も途中確認用に整理し直しました。今回追加・修正したかったのは、単にパネルを増やすことではありません。必要だったのは、「今週中にこの線を続行 / 保留 / 切るのどれで判定するのか」がそのまま見えることでした。だから、見るものも research_ev_equivalent_bps の mean / median / positive share、サンプル数、そして short@30s の fact net of 7.6bps のように、かなり判断直結のものへ絞りました。実装面では CODEX にそれを伝え、6h / 12h / 24h / 48h の途中経過を Grafana 上でも追えるようにしました。

要するに、今日の観測で見えたことは、「LeadLag がダメだった」ではありません。まず見えたのは、自分が見たい問いと、前に出していた計器が少しずれていたということです。構造候補を観測するための runtime 評価と、執行コスト込みで主仮説を判定するための研究EVは、やはり別物でした。だから今回は、そこを曖昧なまま進めるのではなく、まず評価軸そのものを揃えるところからやり直しました。

3. 判断の根拠：ACCEPTED側ですらコスト込みでは正に届かなかった

評価軸を research_ev_equivalent_bps 側へ寄せて観測し直した結果、今回の主仮説に対する答えはかなりはっきりしました。binance_perp → bf_fx / short@30s は、少なくとも現時点では 7.6bps の執行コストを踏まえると、主線として残すには弱い。私は最終的にそう判断しました。

この判断の一番大きな根拠は、short@30s の fact net of 7.6bps が、24時間観測でもマイナス圏に留まっていたことです。瞬間的に悪いとか、一時的に崩れたという話ではなく、fact ベースでコストを差し引いた結果が継続的に負側へ寄っていた。まずこの時点で、主仮説にはかなり厳しい材料でした。

さらに重かったのが、research_ev_equivalent_bps を status 別に見たとき、ACCEPTED 側ですら mean / median ともにプラスへ届いていなかったことです。REJECTED より少しマシに見える場面があったとしても、「通した群はちゃんと勝ち筋だった」とは言えません。つまり、いまの accept 判定は、少なくとも 7.6bps を超えて残る群を十分に選別できていないということです。ここが今回の判断でかなり決定的でした。

加えて、positive share も低いままでした。平均や中央値だけなら、まだ「一部の極端な値に引っ張られている可能性」を考える余地がありますが、正値比率まで低いとなると話は違います。通した群の大半が、コスト込みではなお弱い。これでは「ACCEPTED だから主戦場候補」とは言いにくい。むしろ、いま通している群そのものが、執行コストを踏まえるとまだ主線には足りていない、と読むほうが自然でした。

一方で、runtime の expected_edge_bps は、相変わらずそれなりにプラスに見える時間帯がありました。ただ、今回それはむしろ確認材料にしかなりませんでした。つまり、runtime の軽い expected edge では「それっぽく」見えるのに、研究EVや fact net では負。やはりここにはズレがあったし、主仮説の白黒判定をするなら runtime 側を主表示にしてはいけなかった。今回その主従を切り替えたことで、ようやく判定の根拠がぶれずに揃った感覚がありました。

だから今回の判断は、「なんとなく弱そうだから切る」というものではありません。見えたことはかなり素直でした。short@30s net of 7.6bps は負、ACCEPTED 群の mean / median も負、positive share も低い。ここまで揃うなら、少なくとも現行の binance_perp → bf_fx / short@30s を主線として続ける理由はかなり弱い。私はそう受け取りました。

要するに、この章で言いたいのは、今回の結論は runtime の印象ではなく、コスト込みの事実に寄せて出したものだということです。構造候補としては見えていたし、直近2日では相対的に良く見えたのも事実です。けれども、それを執行コスト 7.6bps まで含めて見直したとき、少なくとも現時点では主戦場にはならなかった。今回の「いったん下ろす」は、まさにその観測結果に基づく判断でした。

4. 今日決めたこと：この線はいったん切る。ただしLeadLag全体を切るわけではない

ここまでの観測を踏まえて、今日ひとつ明確に決めたことがあります。
それは、binance_perp → bf_fx / short@30s という現行の主仮説はいったん下ろす、ということです。

この判断は、LeadLag 全体が無意味だったとか、これまでの観測が空振りだったという意味ではありません。実際、直近2日間の観測では、この線が他市場や他条件より相対的に良く見えたのは事実でしたし、構造候補として観測できていたこと自体にも意味はありました。けれども、今回あらためて 7.6bps の執行コスト込みで見直した結果、少なくとも現行条件の short@30s は主戦場として残せるほど強くはなかった。だから私は、この線をいったん切ると決めました。

ここで大事なのは、「何を切るのか」をはっきり分けることだと思っています。今回切る対象は、あくまで binance_perp → bf_fx / short@30s の現行主仮説 です。LeadLag 構造研究全体を、ここで丸ごと否定するわけではありません。もし今回の結果をもって「LeadLag は全部ダメだった」とまとめてしまうと、それは少し雑です。今回見えたのは、「この条件、この時間枠、この主仮説」は、執行コスト込みで主線としては弱かった、ということです。逆に言えば、LeadLag というテーマ全体については、まだ掘り直す余地が残っています。

この切り分けは、自分の中ではかなり重要でした。研究をしていると、ひとつの主仮説が崩れたときに、「テーマごと全部だめだった」と感じやすい。でも今回は、そこまで一気に飛ばさないようにしたいと思いました。観測結果として見えているのは、主線にしようとしていた short@30s が残らなかった、ということです。これは十分に切る理由になります。一方で、LeadLag のどこにも構造がないとまではまだ言えない。つまり、今回は「主仮説を切る」のであって、「研究テーマそのものを投げる」わけではない、ということです。

そのうえで、いま切った理由もかなり明確です。大きく言えば、理由は3つあります。
ひとつ目は、short@30s net of 7.6bps が事実ベースで負だったこと。
ふたつ目は、ACCEPTED 側ですら research_ev_equivalent_bps の mean / median が正に届かなかったこと。
三つ目は、positive share まで低く、通した群が「勝ち筋の濃い群」になっていなかったことです。
ここまで揃っているなら、今の線に執着してさらに細かく救済条件を足していくより、いったん下ろすほうが自然だと判断しました。

ただし同時に、「まだ残っている論点」もあります。それは、LeadLag というテーマの中で、何を変えれば地形が変わるのか という論点です。今回見ていたのはかなり限定的な一点でした。だからこそ、この線を切ることと、LeadLag を全部切ることは同じではありません。どこまでが現行仮説の失敗で、どこから先が次に広げて検証すべき余地なのか。そこを分けて考えるためにも、今日はまずこの一本を下ろすところまでを明確に決める必要がありました。

要するに、今日決めたことは「LeadLagはダメだった」ではありません。
この線はいったん切る。けれど、LeadLag 全体の可能性は次の掘り直し方次第でまだ残っている。
その位置づけをはっきりさせたことが、今日の判断の本質だったと思っています。

5. 次の方針：時間枠を先に広げる。その前に、やらないことを定義する

現行の binance_perp → bf_fx / short@30s をいったん下ろすと決めた以上、次に必要なのは「では何を掘り直すのか」をはっきりさせることでした。ここで私が選んだ方針は、ロングとショートの両方をすぐ広げることではなく、先に時間枠を広げるというものです。

今回切ったのは、かなり限定的な一点でした。binance_perp → bf_fx、short、30s という、かなり狭い局所仮説です。だから次にまず知りたいのは、「30秒だけが特異点だったのか」「近傍の時間枠にも似た地形があるのか」「そもそもこのあたり一帯が全部弱いのか」ということです。ここを見ないまま、いきなりロング/ショート両方へ広げると、方向軸の論点まで一気に増えてしまいます。そうなると、時間枠の問題なのか、方向性の問題なのか、ただのノイズなのかが分かりにくくなります。だから次は、まず時間軸のほうを先に広げることにしました。

具体的には、10 / 20 / 30 / 45 / 60s といった複数の horizon を、同じ条件のまま横並びで比較する方針です。ここで大事なのは、最初から時間枠ごとに別々の最適化をしないことでした。たとえば、10秒だけ閾値を変える、60秒だけ quality 条件を緩める、といったことを最初からやってしまうと、それはもはや「時間枠の比較」ではなく、「時間枠ごとに別の戦略を作って比較する」話になってしまいます。いま知りたいのはそこではなく、同じ物差しで horizon を変えたときに、どの帯域に山があるのか、あるいは山がないのかです。だから、まずは条件固定のまま horizon sweep をやる、という順番を守ることにしました。

ここで改めて大事だと感じたのが、やらないことを先に定義することでした。今回のようなフェーズでは、手を広げようと思えばいくらでも広げられます。方向軸も見たい、時間軸も見たい、cooldown も見たい、quality detail も見たい、というふうに、やれることはたくさんある。でも、それを全部同時にやると、結局また「何を見て何を判定したいのか」が濁ります。だから今回は、あえて最初に「やらないこと」を決めました。

今やらないことは、少なくとも次の3つです。
ひとつ目は、ロング/ショートの両方を本格的に同時拡張しないこと。方向軸の比較は大事ですが、いまはまず時間枠の地形を見るほうを先にやる。
ふたつ目は、horizon ごとに別々の最適化をしないこと。同じ条件のまま比較して、どこに山があるかだけをまず確認する。
三つ目は、いきなり救済ロジックや細かな昇格条件へ戻らないこと。今回切った主仮説のあとに必要なのは、次の局所仮説候補を雑に増やすことではなく、どの時間帯域に掘る価値があるかを先に見ることです。

要するに、次の方針はかなりシンプルです。
先に時間枠を広げる。
ただし、条件はまだ増やさない。
そして、その前に“いまはやらないこと”を先に決めておく。

今回の主仮説を下ろしたことで、何もなくなったわけではありません。むしろ逆で、次にどこを掘るかが少し見えやすくなったと思っています。だから次は、30秒という一点から少しだけ時間軸を広げて、同じ物差しのまま地形を見にいくつもりです。それが、今日の観測結果を次の一歩につなげる、いちばん自然な流れだと思っています。