Bot CEX 思考ログ 開発ログ

🛠️開発記録#531(2026/5/2)Binance Japanリードラグ研究 ― 構造判定と執行判定を分け、観測の読み筋を整理した日

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

今日は、最近のメインテーマであるリードラグ研究とその内容についてまとめます。

前回の話
🛠️開発記録#530(2026/5/1)『市場と取引』を読みながら、スプレッドと大口取引を整理した日

続きを見る

1. 今日の目的

今日は、前回チューニング後に溜まったデータを確認し、各リード市場の構造判定が現状の定義でどこまで妥当なのかを見直すつもりでした。

対象は、主に global_fx、etf_spot、cme_spot の3つです。

ただし、実際に作業を進める中で、いきなり構造定義を掘るよりも先に、観測値・表示名・判定レイヤーの混線を整理する必要があると分かりました。

そのため、今日の作業は「新しい売買判断を作る日」ではなく、「今後の判断を誤読しないために、観測と判定の読み方を整える日」になりました。

2. まず前回までの確認リストを確認した

最初に、過去の研究メモやREADME、既存の日次レポートを確認しました。

これは、検証したい項目が不明なまま勝手に再検証を始めないためです。

確認対象は、NORTH_STAR_MEMO.md、README.md、既存の definition_daily_*.md などです。今回のレポートでも、前回までの資料を先に確認し、2026-04-26から2026-05-01までの日次定義レポートを再確認したことが整理されています。

2026-05-01の新定義確認では、以下のような結果でした。

scenarioevents_validstructure_onexecution_ready
global_fx57073.7%0.0%
etf_spot6639.4%0.0%
cme_spot8140.7%0.0%

ここから分かるのは、構造候補は出ているが、執行可能性までは出ていないということです。

つまり、「何かしらの構造らしきものは観測される」が、「それをそのまま取引候補として扱える状態ではない」という整理になります。

3. StructureとExecution Readinessを分ける必要があった

今日の大きな論点は、Structure判定とExecution Readiness判定を混ぜないことでした。

これまでの表示や命名では、Trade Candidate や EV という言葉があり、構造があることと取引に使えることが少し混ざって見えやすい状態でした。

しかし、実際にはこの2つは別物です。

Structureは、外部リード市場とBinance Japanの間に、研究上のリードラグ構造が観測されているかを見るものです。

Execution Readinessは、その構造を実際に取引へ使えるだけの余裕があるかを見るものです。

今回のレポートでも、fixed_horizon の primary net は取引コスト込みのproxyとして扱える一方で、follow_arrival、state_persistence、residual_decay は研究用の構造材料であり、PnL期待値として同列には扱えないと整理されています。特に residual_decay は「歪みがどれだけ縮んだか」であって、EVと呼ぶと誤読しやすい項目です。

そのため、今日の判断としては、

  • Structureは構造判定
  • Execution Readinessは執行可能性の診断
  • residual_decayはEVではなくresidual improvementとして扱う

という分離を進めることにしました。

4. EVは必要だが、構造ではなく売買行動に対して定義する

EVを見ること自体は必要です。

ただし、今日の議論で重要だったのは、EVは「構造そのもの」に対して定義するものではなく、「その構造を使った具体的な売買行動」に対して定義するものだという点です。

構造があるからEVがある、ではありません。

順番としては、

  1. 構造らしきものが観測される
  2. その構造がどの市場参加者・制約・伝播経路から生じているのかを考える
  3. その構造を使うなら、どの市場で、どちら向きに、どの注文方法で、いつ入って、いつ出るのかを定義する
  4. その具体的な売買行動に対して、手数料・スプレッド・スリッページ・遅延・約定失敗などを織り込んでEVを見る

という流れになります。

ここを曖昧にしたまま EV > 0 を使うと、構造判定と執行判定の境界が揺れます。

そのため、今後はEVという言葉をかなり狭く使うべきだと考えました。

  • residualが縮んだ量は residual_improvement_bps
  • lag側が同方向に動いた量は gross_follow_bps
  • 具体的な売買ルールに対するコスト後価値だけを execution_value_bps

のように分ける必要があります。

今回の実装でも、Execution Readiness に min_trade_ev_bps=5.0、min_valid_samples、min_cost_pass_rate、max_entry_spread_bps などのbufferを入れています。これは、net > 0 だけで執行可能と見なさないための暫定的な安全装置です。

5. ETFは「価格そのもののリード」ではなく、固有成分を見る必要がある

ETFについても整理しました。

最初は、ETFのhorizon設定がおかしく、構造抽出がうまくできていない可能性を考えました。

ただし、色々と調べたりAIと壁打ちしたりしていくと、本質は少し違うということが見えてきました。

たとえば、ETF価格がBinance Japan BTC/JPYをリードしているように見えても、それはETF固有の情報が伝播しているのではなく、global BTCという共通ドライバーを見ているだけかもしれません。

たとえば、Global BTC/USDが先に動き、その影響でETFもBinance Japanも動いたとします。このとき、データ更新のタイミングや市場時間の違いによって、ETFがBinance Japanより先に動いたように見える可能性があります。

この場合、見かけ上はETF → Binance Japanのリードラグに見えますが、本当にETFがリードしているわけではありません。

本当に見たいのは、ETF価格そのものではなく、

  • global BTC由来の動きを差し引いたETF固有の動き
  • global fair value由来の動きを差し引いたBinance Japan側の残差

の関係です。

つまり、ETF固有の動きが、Binance Japan側の残差に先行しているかを見る必要があります。

ただし、これは単なる閾値変更ではありません。lead系列とlag系列の意味を変える実装です。そのため、今回は、ETF residual再定義は実装せず、1週間分の regular-only + 60s/180s の観測結果を見てから再検討する扱いにしています。

6. ETFはregular-onlyと60s/180s追加に留めた

ETFについて今日行った軽いチューニングは、主に2つです。

1つ目は、regular sessionを主評価にすることです。

ETFは米株市場で取引される商品なので、regular、pre-market、after-hoursでは流動性や価格品質が違います。これらを同じ構造判定に混ぜると、時間外の薄い流動性による価格変化をリードラグ構造と誤認する可能性があります。

そのため、structure_candidate.allowed_session_labels に ["regular"] を設定し、ETFの構造判定ではregularを主評価に寄せました。

2つ目は、60s/180s horizonの追加です。

これは、短期edgeを期待するためではありません。

これまでETFは最短horizonが300sだったため、実際には60sや180sで反応が終わっているのに、300s時点だけを見て「5分後に反応した」と誤読している可能性がありました。

そのため、60s/180sを追加し、300s評価が反応位置を丸め込んでいないかを見ることにしました。

ただし、primary horizonは300sのままです。60s/180sは、あくまで反応位置を観測するための追加です。

7. CMEは保留だが、メイン監視には残す

CMEについては、今日の時点で大きく定義を変えませんでした。

理由は、CME市場構造への理解とsource品質の両方にまだ確認余地があるためです。

ただし、メインパネルから完全に外すこともしませんでした。

CMEは、現時点で主判断対象というより、「重要だが、構造定義をまだ正しくできていない監視対象」です。ここでメインパネルから外してしまうと、サブではあるが重要な対象であることを忘れやすくなります。

そのため、CMEはメインのStructure表示には残しつつ、定義の大幅変更は保留することにしました。レポートでも、CMEは知識面の保留対象だが、監視対象としては残すと整理されています。

8. ダッシュボードは増やすのではなく絞った

途中で、実装が過剰になりかけていることにも気づきました。

新しいメトリクスやパネルを増やしすぎると、解釈コストが上がります。今の目的は、見るものを増やすことではなく、見るべきものを絞ることです。

そのため、メインに残すパネルをStructure中心に絞りました。

メインに残したものは以下です。

  • Now | GlobalBTC Structure
  • Now | ETF Structure
  • Now | CME Structure
  • GlobalBTC / ETF / CME | Last sample age
  • Structure History | 3 Leads

一方で、Execution Readiness、Execution Value、Cost Pass Rate、Entry Spreadは折りたたみ診断へ降格しました。

これは、執行可能性を見ないという意味ではありません。

今の段階では、メイン画面で見るべきものを「構造が出ているか」「データが生きているか」「時間的に継続しているか」に絞り、執行系は診断として下に置く、という判断です。

9. global_fxとUSD/JPYパネルの違和感も整理した

今日は、接続障害まわりでも重要な発見がありました。地味ですが、結構重要な点なので、自分用メモとしても記録に残しておきます。

朝チェックでは、最初はFX取得障害のように見えました。しかし実際には、global_fxプローブ内でBinance BTCUSDTの取得中に ConnectionResetError が発生し、プローブ全体が停止したことが原因でした。

その結果、Global BTC/USD、USD/JPY、fair value JPY、Binance Japan BTC/JPYのglobal_fx系メトリクスがまとめて欠損しました。

ここで分かったのは、Input Tape: USD/JPY がUSD/JPY単体の取得状況を表すパネルではなかったということです。

実装上は、global_fx合成シナリオの内部コンポーネントとしてUSD/JPYが出ているため、Binance BTC/USD側でプローブが落ちると、USD/JPY表示も巻き込まれて欠損します。

これは監視設計として曖昧です。

今後は、以下のように読むべきだと整理しました。

  • Global BTC/USDはBinance BTCUSDTコンポーネント
  • USD/JPYはFXコンポーネント
  • Fair Value JPYはその合成値
  • global_fxという内部名は当面残しても、表示上は実体に寄せる

ここも、パネルをむやみに増やすのではなく、既存パネルの意味を正す方向で進めることにしました。

10. 今日あえて深掘りしなかったこと

本来は、各市場のリードラグ構造をどう定義するのか、その妥当性をもっと深く掘るつもりでした。

しかし、ETFやCMEについては、まだ市場構造の勉強中です。

ここで無理に仮説を組むと、価格系列だけを見て「先に動いたからリード」と判断してしまう危険があります。

そのため、今日は構造定義そのものを大きく作り替えるのではなく、まず観測・表示・判定の混線を減らすことにしました。

保留したものは以下です。

  • ETF residual lead-lagの本格再定義
  • CMEの構造定義の大幅変更
  • 閾値の本格最適化
  • 執行コスト前提の細分化
  • pre/after ETFを主評価へ戻すかどうか

これは判断の先送りというより、まだ判断材料が足りない部分を明示して保留した、という位置づけです。

11. 今日時点のまとめ

今日の作業は、新しい勝ち筋を見つける作業ではありませんでした。

むしろ、今後勝ち筋を探すときに、観測値やパネル名やEVという言葉に引っ張られて誤読しないように、判定経路を整理した日でした。

今日の時点で整理できたことは以下です。

  • StructureとExecution Readinessは別概念として扱う
  • EVは構造ではなく、具体的な売買行動に対して定義する
  • residual_decayはEVではなくresidual improvementとして読む
  • ETFは価格そのもののリードではなく、global BTC控除後の固有成分を見る必要がある
  • ただしETF residual再定義はまだ保留する
  • ETFはregular-onlyと60s/180s追加で、まず反応位置を確認する
  • CMEは重要だが未整理の監視対象として残す
  • メインパネルはStructure中心に絞る
  • global_fx / Global BTC / USDJPY / Fair Valueの表示上の意味を整理する必要がある

一番大きな学びは、リードラグ研究は単に「先に動いた市場」を探す作業ではないということです。

共通ドライバーを差し引いたうえで、各市場固有の制約・参加者・時間帯・流動性が、ラグ市場へどのように伝播しているかを見る必要があります。

そして、それを取引につなげるには、構造を見つけるだけでは足りません。

その構造を使って、どの条件で、どちら向きに、どの注文方法で、いつ入り、いつ出るのかを定義し、その具体的な売買行動に対してEVを計算する必要があります。

5月前半は、既存の観測機を軽く回しながら、『市場と取引』を読み進め、自分の中に市場構造の理解モデルを作ることを優先します。

5月中旬から6月にかけて、その理解をもとに、構造仮説、strategy spec、execution EVへ接続できる状態を目指します。

-Bot, CEX, 思考ログ, 開発ログ