こんにちは、ぼっちbotterよだかです。
今回は、ここしばらく進めていたリードラグ研究を、ひとまず最小構成の判定機としてまとめるところまで持っていけたので、その時点の整理を書いておきます。狙っていたのは、単に「構造がありそう」と眺めることではなく、執行コスト込みで白黒を見ながら、実際にトレードシグナル生成まで繋げることでした。まだ「これで稼げる」とは言えませんし、むしろ現時点ではそこは未確定です。ただ、自分の目で見て、部分的に肯定も否定もできる観測機にはなってきました。今日はその到達点と、あえてここで一旦止めると判断した理由をまとめます。
-
-
🛠️開発記録#500(2026/4/2)multi_market_probe開発ログ ― Lead-Lag観測機を、FACTとDECISIONで読める形に固定した話
続きを見る
今回のゴール：LeadLagを“トレードシグナル生成機”として一度つなぐ
今回の開発で狙っていたのは、LeadLag 構造を「なんとなくありそう」と眺める段階から、一度トレードシグナル生成までつないだ最小構成の判定機としてまとめることでした。ここで言う「つなぐ」は、実際に執行部まで完成させるという意味ではありません。まずは、構造判定を執行コスト込みで見られるようにしたうえで、その結果をもとに「この条件ならシグナルを出す」「この条件なら出さない」と言える形まで持っていくことが目標でした。
これまでの LeadLag 研究では、構造そのものがあるのか、あるとしてどの時間幅で見えるのか、という観測をかなり細かく進めてきました。その過程で、binance_perp をリード側に置いたときに、bf_fx 側へ何らかの反応が伝わっていそうな場面は見えてきました。ただし、それがそのまま「トレードして勝てる」という意味にはなりません。実際、観測上は反応らしきものがあっても、執行コストを差し引くと優位性が消える場面が何度もありました。つまり、構造の存在確認と、収益化可能性の確認は、最初から別物として扱う必要があったわけです。
そこで今回は、研究の焦点をかなり絞りました。やることは大きく二つです。ひとつは、過去一定期間においてその構造が執行コスト込みでどの程度成立していたかを見られるようにすること。もうひとつは、直近の運用状態の中で、機会が実際にどれくらい発生していて、シグナルとしてどれくらい通るのかを見られるようにすることです。前者は「そもそも地形があるのか」を見るための判定であり、後者は「いまその地形の上で何が起きているのか」を見るための判定です。この二つを分けないまま進めると、長期の構造評価と、目先の発生頻度や通過率がごちゃついてしまい、何を見ているのか自分でも曖昧になります。
今回わざわざ「最小構成」でここをつないだのは、研究と実装をこれ以上混ぜたくなかったからでもあります。LeadLag の研究はまだ白黒が完全についたわけではありませんし、今の段階で執行部まで厚く作り込むと、「実装したから前に進んだ気がする」だけで終わる危険があります。そうではなく、まずは観測機としての責務をはっきりさせ、自分の目で見て「この構造はある」「ただしまだ金になるとは言えない」「だから今はシグナル発生頻度を見る」と言える状態にしたかった。今回のゴールは、そのための一度目の着地でした。
要するに、今回やりたかったのは「稼ぐ bot を完成させること」ではなく、「LeadLag を、執行コスト込みで部分的に肯定も否定もできる判定機へ変えること」です。ここまで来れば、少なくとも次に何を見るべきかはかなり明確になります。シグナルが出るのか、どの方向で多いのか、出ても通らないのか、そもそも構造が薄いのか。そうした問いを、やっと観測機の画面を見ながら自分で判断できる段階に持ってこられた、というのが今回達成したことでした。
実装したこと：過去24Hの構造判定と、直近の機会発生を分けて見えるようにした
今回やったことを一言で言うと、LeadLag をひとつの曖昧な「良さそうな何か」として見るのではなく、時間軸と役割ごとに分けて読めるようにした、ということです。具体的には、過去24時間の固定窓で見た構造評価と、直近で実際にどれだけ機会が発生しているかという運用寄りの情報を、別の層として見えるように整理しました。
まず一つ目は、DECISION パネルです。ここで見ているのは、瞬間的な発生頻度ではなく、過去24時間の fixed window において、その方向・その horizon の LeadLag 構造が執行コスト込みでどの程度成立していたか、という事実です。要するに、「今たまたま出ているか」ではなく、「この地形は一定期間で見たときに本当にあったと言えるのか」を見るためのパネルです。これによって、10秒・20秒・30秒…といった複数の時間幅を横並びで比較しながら、どこにまだ見込みがあり、どこがすでに厳しいのかを、少なくとも過去24時間ベースでは判断できるようになりました。
ただ、これだけだと実運用には足りません。DECISION が教えてくれるのは「最近24時間ではどうだったか」であって、「じゃあ今その構造がどの程度出ているのか」までは分からないからです。そこで二つ目として、SIGNAL パネルと STAT パネルを整えました。こちらは、今この瞬間の運用条件の下で、機会がどれくらい発生していて、どれくらいブロックされていて、どれくらい実行候補として通っているのかを見るための層です。
SIGNAL パネルでは、long / short を分けたうえで、一定時間内に PASS した機会と BLOCKED になった機会の増分を見られるようにしました。これによって、「構造があるかもしれない」という話を、直近の発生頻度という形で捉え直せるようになります。たとえば、過去24時間ベースでは弱い構造でも、直近ではある程度まとまって発生している可能性がありますし、逆に DECISION 上はまだ完全否定できなくても、今はほとんど機会が出ていないということもあります。ここを分けて見られるようになったのは大きかったです。
さらに STAT パネルでは、accept rate や no accepted intent といった要約値も出すようにしました。これによって、「機会は出ているが実行候補としてはあまり通らない」のか、「そもそも十分に機会が出ていない」のか、といった違いを一目で見やすくなりました。特に今回のように、まだ実発注まではつながっていない段階では、この種の要約値はかなり重要です。今の段階で必要なのは、実際に儲かったかどうかを語ることではなく、どこで止まっているのかを切り分けることだからです。
この整理をしたことで、LeadLag 観測機の読み方もかなり明確になりました。DECISION は過去24時間の構造評価、SIGNAL は直近の機会発生状況、STAT はその機会がどこまで通過しているかの要約です。つまり、同じ LeadLag を見ているようでいて、実際には「長めの構造評価」と「短めの運用状態確認」を別々に読めるようにした、ということです。今回の実装で価値があったのは、単にパネルを増やしたことではなく、何をどの時間軸で見ているのかを、自分の中で取り違えずに済む形へ整理できたことだったと思います。
現時点の事実：シグナルは見えるが、まだ稼げるとは言えない
今回の実装まで進めて、見えるようになったものは確かにあります。少なくとも、LeadLag 構造らしきものが全くの幻ではなく、一定の条件下で機会として観測され、その発生状況を long / short 別・horizon 別に追えるところまでは来ました。これは大きな前進です。以前のように「ありそうだ」「なさそうだ」と感触で語るのではなく、過去24時間の構造評価と、直近の機会発生状況を見分けながら話せるようになったからです。
ただし、ここで同時に見えてきた事実もあります。それは、「シグナルが見えること」と「稼げること」は全く同じではない、ということです。これは頭では分かっていたつもりでしたが、実際にパネルを分けて見られるようになると、その差がよりはっきりしました。DECISION パネルでは、方向や horizon によっては LeadLag 構造が残っていそうに見える場面がありますし、SIGNAL / STAT 側では実際に機会の発生も見えます。けれど、それだけで「よし、執行すれば勝てる」とは言えません。現時点では、執行コスト込みで安定して正の期待値が出ていると断言できる状態には、まだなっていないからです。
この「まだ稼げるとは言えない」という結論は、別に悲観ではありません。むしろ、今回の観測機を通したことで、どこまでが肯定できて、どこから先が未確定なのかを切り分けられるようになった、という意味で前向きな事実です。今なら、「構造は一部ありそうだ」「シグナルも一定条件では出る」「しかし、そのまま収益化できるだけの厚みがあるかはまだ分からない」と言えます。これは、何も見えていない状態よりずっと良いです。少なくとも、今後検証すべき論点がかなり絞られます。
たとえば、今の段階で問題になっているのは、構造の有無そのものよりも、構造の薄さやコスト負けの可能性です。短い horizon では反応らしきものが見えても、その値幅が執行コストを十分に上回るほどではないかもしれない。あるいは、ある方向では多少残っていても、もう片方では弱いかもしれない。さらに言えば、過去24時間で構造があったとしても、直近ではその発生頻度が薄く、運用上は「ほとんど何も起きない」に近い可能性もあります。こうした論点は、以前なら全部まとめて「LeadLag は微妙かもしれない」で終わっていたところでしたが、今は少しずつ分けて見られるようになりました。
ここで大事なのは、「シグナルが見えた」という事実を過大評価しないことだと思っています。開発をしていると、何かが画面に出るようになっただけで前に進んだ気持ちになりやすいのですが、今回見るべきなのは達成感そのものではなく、その中身です。実際に見えているのは何か。過去24時間で一定の構造があったのか。直近で機会は発生しているのか。発生しているとして、どの程度の濃さなのか。そして、それは執行コスト込みで見ても意味のあるものなのか。こうした問いに対して、今の時点では「部分的には Yes、ただしまだ収益化までは言えない」というのが、一番正確な答えだと思います。
だからこそ、現時点の事実はシンプルです。LeadLag は完全否定されたわけではないし、何も見えていないわけでもない。でも、まだ「これで金になる」と言える段階でもない。今あるのは、構造らしきものと、その機会発生を観測できる最小構成の判定機です。そしてその判定機があるからこそ、これ以上希望や直感だけで話を盛らずに済むようになった。今回の実装で得た一番大きな収穫は、実はそこです。
今日の判断：執行部までは進めず、ここで一旦止める
今回、LeadLag をトレードシグナル生成までつなぐ最小構成の判定機としてまとめるところまでは到達できました。だからこそ、その勢いのまま執行部まで進めたくなる気持ちもありました。実際、「ここまで来たなら、そのまま発注までつなぎたい」と考えるのは自然だと思います。ただ、今回はそこで進めず、一旦ここで止めることにしました。これは消極的な判断ではなく、むしろ今の段階で最も筋の良い判断だったと思っています。
理由はシンプルで、まだ「執行してよい」と言えるだけの事実が揃っていないからです。今の観測機で見えるようになったのは、あくまで構造判定とシグナル生成の入口までです。過去24時間の fixed window で見た構造評価と、直近の機会発生や通過状況はかなり読めるようになりましたが、それでもなお「じゃあ今すぐ実際にトレードさせるべきか」という問いには、まだ確信を持って Yes と答えられません。執行コスト込みで見たときに、現時点では EV が十分に正だと言い切れない以上、ここで実発注の仕組みを厚く作り込んでも、研究として前に進んだことにはならないと考えました。
むしろ怖いのは、実装が進むことで「何かが完成した感じ」が先に立ってしまうことです。シグナルが出る、パネルが動く、ORDER_INTENT まで流れる、といった挙動が見えると、それだけでかなり前進した気分になります。でも、その達成感と「金になるかどうか」は別です。ここを混同すると、まだ白黒がついていない研究テーマに対して、実装の厚みだけが増えていく状態になります。そうなると、あとで見直したときに「これは何を確かめるための仕組みだったのか」がぼやけてしまう。今回そこを避けたかったので、いったん止めること自体を一つの判断として明確に採用しました。
今回の段階で必要なのは、執行部を完成させることではなく、観測機を少し回して事実を増やすことだと思っています。実際にトレードシグナルがどの程度出るのか。その頻度は long / short でどう違うのか。時間帯によって偏りがあるのか。DECISION 上では多少見込みがあるように見える horizon でも、直近の SIGNAL / STAT ではほとんど通らないのか。それとも、一定条件ではそれなりに発生するのか。こうしたことを、まずは1〜2日程度は落ち着いて見た方が良い。今はその前段のフェーズであって、執行部を急いで作る局面ではないと考えています。
それに、今の最小構成でも十分に価値はあります。構造があるかどうかを、執行コスト込みで一応見られる。シグナルがどの程度発生しているかも追える。トレードが発生しないなら発生しないで、その事実自体が判断材料になります。つまり、仮にこのまま「シグナルはほとんど出ない」「出ても通らない」「結局コスト負けする」という結論になったとしても、それは失敗ではなく、ちゃんと次に進めるための否定結果になります。今ほしいのは、曖昧な希望ではなく、そういう意味のある肯定・否定です。
だから、今日の判断は「ここで止める」でした。これは、開発を投げたということではなく、最小構成の責務を果たしたところで一度区切った、ということです。LeadLag 研究自体も、ここで完全終了とは限りません。むしろ今後、市場の差し替えや執行コスト構造の見直し、あるいは軽いアプリ化のような形で次に進む可能性は十分にあります。ただ、それは今日この瞬間に追加で進める話ではない。今は、見えるようになったものを少し眺めて、自分の目で確かめてから次を決める段階です。今回の判断は、その順番を守るためのものでした。
次の選択肢：市場差し替え・コスト見直し・軽いアプリ化
ここまで来ると、次にやることは無数に思いつきます。市場を差し替える、対象ペアを変える、執行コストのモデルを細かくする、シグナル生成のオンオフを切り替えられるようにする、軽くアプリ化して使いやすくする。どれも自然な発想です。ただ、全部を一度にやると、また研究と実装が混ざってしまいます。だから次の一手は、思いついたことを全部広げることではなく、「今ある EV 判定機能を他条件へ載せ替えやすい形に整える」ことに絞るのがよいと考えています。今日の到達点は、過去24時間の構造評価と、直近の機会発生・通過状況を分けて見られる最小構成の判定機です。つまり、すでに「構造があるか」「シグナルが出るか」「今は通るのか通らないのか」を分解して読める土台はできています。次はこの土台を、ひとつの LeadLag 専用機で終わらせず、他の条件にも流用しやすい形へ寄せていく段階です。
この方向性は、マーケット研究の蓄積とも相性が良いです。高頻度の lead-lag 自体は珍しい話ではなく、関連市場や連動資産のあいだで非対称な価格調整が観測されることは、株式・先物・FX などで以前から報告されています。Hasbrouck は複数市場にまたがる価格発見の分担を示し、Huth と Abergel も高頻度 lead-lag を実証していますし、Sapp はスポットFXでも price leadership を確認しています。つまり、「先行と追随の構造があるかもしれない」という出発点そのものは十分に妥当です。問題は、それが私の執行条件とコスト構造の下でも取れるかであって、そこを判定できる形へ寄せるのが次の合理的な手順です。
同時に、過去研究は「構造がある」と「利益が取れる」を安易に同一視していません。取引コスト、スプレッド、価格改善の有無、発注サイズ、情報の伝播速度の差などで、見えている反応がそのまま取引利益に変わらないことは繰り返し指摘されてきました。Hasbrouck のコスト測定研究や、スプレッドを往復コストの基礎として扱う Jones の整理、さらに高頻度戦略の収益性検証でも、コストを入れるだけで見かけの優位性がかなり削られることが示されています。あなたが今やっている「構造判定を執行コスト込みで見る」という作法は、まさにここに対応しています。
そのうえで、次にやることは大きく三段に分かれます。
1. まずは最小機能でアプリ化する
最初にやる価値が高いのは、いまのシグナル生成機を軽くアプリ化することです。ここで言うアプリ化は、大げさな製品化ではありません。ローカルで使う前提で、設定の変更、シグナル生成のオンオフ、対象市場の差し替え、コストパラメータの確認が、コードを直接触らなくてもできるようにする程度で十分です。狙いは見た目ではなく、研究装置としての可搬性と再利用性を上げることです。
具体的には、最低限ほしいのは次の5点です。
- 対象市場・対象ペアの切替UI
どの lead 市場と lag 市場を見るのかを外から切り替えられるようにする。 - 執行コスト設定の編集UI
手数料、想定スリッページ、追加安全マージンを個別にオンオフ・変更できるようにする。 - シグナル生成のオンオフ
観測だけしたい時と、シグナルまで出したい時を切り替えられるようにする。 - 現在の判定状態の要約表示
DECISION・SIGNAL・STAT のうち、何が良くて何が悪いのかを一画面で見られるようにする。 - 設定と結果の保存
後から「どの設定で見ていたか」を追えるようにする。
この段階では、執行はまだ要りません。むしろ要らないです。いま必要なのは「研究機として使いやすいこと」であって、「トレードボタンがあること」ではありません。今日の時点でも、DECISION は過去24時間の構造評価、SIGNAL/STAT は直近の機会発生と通過状況、INTENT は補助解釈という役割分担ができているので、この責務を崩さずに外側だけ整えるのが最小の前進になります。
2. EV 判定機能を“LeadLag 専用ロジック”から切り離す
次に重要なのは、今の EV 判定を「binance_perp → bf_fx の LeadLag 専用」ではなく、条件を差し替えられる判定部品として切り出すことです。これをやる理由は単純で、LeadLag 研究をいったん区切ったとしても、今後また別の条件系を試したくなる可能性が高いからです。市場差し替え、別ペア、別 horizon、別の発火条件を試したくなった時、毎回ダッシュボードもメトリクスもロジックも全部組み直すのは重い。今回の経験を「一回きりの研究」で終わらせないためには、判定部だけを再利用可能にするのが最も投資対効果が高いです。
ここで切り出すべき要素は、少なくとも次の通りです。
- anchor 定義
何を機会の起点とみなすのか。今は lead return ベースだが、別条件では premium でも volume shock でもよい。 - future horizon 群
10/20/30/40/50/60秒のような horizon 比較を、条件に依存せず差し替えられるようにする。 - cost model
手数料・スリッページ・安全マージンを分離して定義する。 - decision rule
EV>0、positive share、最低サンプル数など、採用条件を別設定として持つ。 - state / reason 出力
YES / HOLD / NO や ACCEPT / REJECT の理由を、条件系が変わっても同じ形式で出せるようにする。
この切り分けは、研究面でも意味があります。lead-lag の研究では、相場や市場ごとにタイムスケールや非対称性が異なることがよく報告されていますし、そもそも非同期観測やノイズの扱いが難しいため、判定器の一般化には構造的な配慮が要ります。Huth と Abergel は、high-frequency の lead-lag を tick-by-tick データでどう測るかという指標設計まで踏み込んでおり、さらに Hoffmann らや最近の Shiotani らの研究では、非同期観測されたデータから lead-lag をどう推定するか自体が理論的な論点として扱われています。だからこそ、ひとつの市場条件に密結合したままではなく、anchor・horizon・cost・decision rule を別レイヤーに分ける意義があります。
3. コスト構造を“ひと塊”ではなく部品として持つ
今後の改善候補として特に重要なのが、執行コストの構造を見直せるようにすることです。今の段階では、「コスト込みで見ている」という一点が重要でした。ただ、次に進むなら、そのコストをもう少し分解して扱えるようにしたほうがよいです。なぜなら、シグナルが弱いのか、構造はあるがコストが重すぎるのか、その区別が次の判断に直結するからです。
少なくとも、次の3つは分けて持ったほうがよいと思います。
- 取引所手数料
- スリッページ見積
- 安全マージン（保守的上乗せ）
この3つを分ける理由は、見直し方が違うからです。手数料は比較的固定ですが、スリッページは市場・時間帯・サイズで変わりますし、安全マージンは研究上の保守性の問題です。Budish らの研究が示したように、連続時間の高速市場では、公開情報への反応が latency arbitrage のレースになりやすいです。一方で Gerigの研究 は、関連資産間の価格同期それ自体には、価格精度の改善や取引コストの低下という効率面もありうると論じています。要するに、コストは単なる罰則ではなく、市場構造そのものの写像です。ひと塊の定数で握っていると、何が改善余地で何が構造的限界なのかが見えにくくなります。
なぜ「最小構成から始める」のか
ここまで読むと、やることが多く見えるかもしれません。ただ、順番を間違えなければ重くありません。今回の核は、最小構成から始めることです。最初からフロントエンドを凝る必要も、複数市場対応を完璧にする必要も、実執行まで載せる必要もありません。やるべき順番はかなり明確です。
- 今の判定機をそのまま動かせる薄いUIを作る
- 設定を外に出して、対象市場・コスト・signal on/off を切り替えられるようにする
- EV 判定部を汎用化して、他条件へ差し替えやすくする
- その後に必要なら市場差し替えやペア追加を試す
この順番なら、「使いやすくする」と「研究を広げる」がぶつかりません。まずは使える殻を作り、その中の判定部を再利用しやすくする。そのうえで、別市場や別条件を載せていく。今月半ばまでに一旦仕上げるなら、このくらいまでに絞ったほうが現実的です。
懸念点もある
もちろん懸念もあります。ここを楽観しすぎると危ないです。
- UI を作ることで“前に進んだ感”が出やすい
研究が進んだのではなく、見やすくなっただけ、という状態に陥る危険があります。 - 汎用化しすぎると抽象化コストが先に立つ
まだ本当に必要な可変軸が固まっていない段階で一般化しすぎると、かえって遅くなります。 - コストモデルを細かくしすぎると、推定誤差を精密化してしまう
分解は必要ですが、分解した値の根拠が弱いと“細かいけど信用できない”モデルになります。 - LeadLag の弱さを UI で覆い隠してしまう危険
これは一番避けたいです。見栄えがよくなっても EV が弱ければ弱いままです。
だから、今月半ばまでの目標は、「売り物みたいなアプリを作る」ではなく、今ある判定機を、他条件へ載せ替えやすい研究用アプリとして最小限整えることに置くのがよいと思います。そうすれば、LeadLag 研究をいったん区切って別テーマへ移るにしても、今回作ったものがそのまま次の研究の土台になります。
今回の LeadLag 研究で得た一番大きなものは、たぶん「この市場で勝てる」という結論ではありません。構造とコストを分けて見て、部分的に肯定も否定もできる判定の型を作れたことです。次にやるべきなのは、その型を使いやすくし、他条件にも載せ替えやすくすることです。そこまでできれば、今回の研究は単発で終わらず、次の研究テーマに持ち越せる資産になります。
まとめ：部分的に白黒をつけられる観測機になった
今回の開発で一番大きかったのは、LeadLag 研究を「ありそう」「なさそう」で語る段階から、一応は自分の目で白黒をつけられる観測機の形まで持っていけたことでした。過去24時間の構造評価と、直近の機会発生・通過状況を分けて見られるようになったことで、少なくとも何が見えていて、何がまだ未確定なのかはかなり整理しやすくなりました。
現時点では、シグナルは見えるが、まだそのまま稼げるとは言えません。ただ、それは後退ではなく、むしろ研究として健全な中間地点だと思っています。構造があるのか、機会が出るのか、コスト込みで見ると弱いのか、そうしたことを部分的に肯定・否定できるようになったからです。
今後は、この観測機を少し回して事実を増やしつつ、必要なら軽いアプリ化や市場差し替え、コスト構造の見直しへ進むことになると思います。ただ、今日はそこまで広げず、最小構成の判定機として一度閉じたこと自体に意味がありました。今回作れたのは完成品ではありませんが、少なくとも次に進むための土台にはなったと思います。