こんにちは、ぼっちbotterよだかです。
今日は、Binance Japan向けのリードラグ観測機について、市場別チューニングをさらに進めるというより、その前提になる状態判定・品質ゲート・監視の信用性を整える作業を進めました。前回は global_fv / CME / ETF を同じ雑な器で見ないように、市場ごとの差を前提にした観測機へ寄せましたが、今日はその器を「本当に信頼して回せるのか」を詰めた形です。具体的には、休開場判定の整理、Grafana の見直し、そして quality NG のデータが有効サンプル扱いされうるロジック不整合の修正などを行いました。まだこの段階で勝ち筋や EV>0 の結論を出すつもりはありません。今回はむしろ、修正後データを育てるための運用段階に入ったという整理の方がしっくりきています。
-
-
🛠️開発記録#517(2026/4/17)BinanceJapanリードラグ研究DAY11「観測・判定機を各市場ごとに本格的にチューニングし始めた話」
続きを見る
1. 今日の狙い
今日は、リードラグ構造そのものをさらに掘るというより、その前に観測機の信用性を一段上げることを主目的にしました。
前回は、global_fv、CME、米スポットBTC ETF を「全部 BTC 関連市場だから同じようなもの」と雑に並べるのをやめて、市場ごとの差を前提にした観測機へ寄せました。あの日のテーマは、言ってしまえば市場別の器を作ることでした。そこまではかなり前進したと思っています。ただ、器を作っただけで、その器をそのまま信じて良いかというと、まだそこは別問題なんですよね。ここをすっ飛ばして threshold をいじったり、どの定義が強そうかを語り始めたりすると、たぶんまた足元から崩れます。なので今日は、まずそこを止めました。
もう少し固く言うと、今日の論点は3つありました。
ひとつ目は、休開場判定や接続状態の見方が、実運用の中で信用できるか。
ふたつ目は、quality が悪いデータが、誤って有効サンプルとして混ざっていないか。
そして三つ目は、Grafana 上で人間が見るべきものが絞れているか、です。
特に二つ目は地味ですが、かなり大事でした。今回の確認では、source_quality_flag=0 のデータが event 化され、条件によっては sample_valid=true として保存されうる経路が見つかっています。これは要するに、機械の中では「品質NG」と分かっているデータが、別の経路では「有効サンプル」として扱われる余地があった、ということです。こういう穴が残ったまま市場別チューニングを進めると、後で threshold や定義を見直すときに、市場構造の弱さとデータ品質の悪さが混ざってしまいます。さすがにそれは嫌でした。今日はそこを塞ぎ、今後溜めるデータの土台を少しでもマシにすることを優先しました。
なので、今日は「勝てる条件を見つけた日」ではありません。そこははっきり書いておきます。むしろ今回は、今はまだ触るべきではないものを切り分けた日でした。具体的には、threshold や horizon、4定義の優先順位、市場ごとの主判定・補助判定の本実装にはまだ入らない、と整理しています。先に器の状態判定と品質ゲートを整え、そのうえで修正後データを数営業日単位で育てる。その順番を崩さないことの方が、今日の時点ではずっと重要でした。
言い換えると、今日は研究を止めた日ではなく、研究を雑に進めないために、いったん運用側の信用性を整えた日です。派手さはないですし、正直やっている最中は「またこういう整備か」と思う瞬間もありました。ただ、再読する未来の自分向けにあえて言うなら、ここを飛ばして先へ進んでも、あとで判定の根拠ごと疑う羽目になります。今日はそこを避けるための一日でした。今はエッジを断言する段階ではなく、修正後データを育てる運用フェーズに入ったと理解するのがいちばん自然だと思っています。
2. まず、観測機の安定稼働と状態判定を見直した
今日まずやったのは、「この観測機、そもそも安定して回ってると言っていいのか？」をちゃんと見直すことでした。
前回までで、global_fv、CME、ETF を同じ雑な器で見ないようにして、市場ごとの差を前提にした観測機へかなり寄せるところまでは進んでいました。そこ自体は前進でしたし、実際、見えるものも前より整理されてきていました。ただ、そこでひとつ嫌な感覚が残っていたんですよね。器の意味は整ってきたけど、その器の状態判定や運用自体をどこまで信用していいのかは、まだ別問題だなと。ここを曖昧にしたまま次へ行くのは、さすがに危ないと思いました。
実際、4/17〜4/19 のログを見直すと、休場判定だけでは済まない問題がありました。いちばん分かりやすかったのは ETF 側で、4/17 に ConnectionResetError 由来の未捕捉例外で一度プロセスが落ちています。CME や Global でも接続リセットやタイムアウト系の警告は散発していて、「外部通信が荒れること自体」は起きていた。ただ、その中で ETF だけはクラッシュまで行っていた。ここは、ただの“ネットワークあるある”で流していい話ではなく、観測機の安定稼働としては要修正の事実でした。さらに、落ちた後の復帰も即時ではなく、数時間の観測ギャップが発生していたので、もしこの状態のまま「ETF は弱い」とか「ETF は何も出ない」とか言い始めたら、かなり危なかったと思います。
この確認を通して、今日は少なくとも「市場が閉まっていて見えない」のか、「source が死んでいて見えない」のか、「プロセスが落ちていてそもそも観測していない」のかを混同しないことを強く意識しました。ここ、地味なんですけど結構大事なんですよね。特に ETF や CME みたいに取引時間が限られる市場を相手にすると、ちょっとログが静かになっただけで「この市場は弱いのかな」とか「反応が消えたな」とか考えたくなってしまう。でも実際には、休場・通信異常・停止・弱い構造は全部別物です。ここを分けないと、観測機をいくら market-aware にしても、読み手の頭の中でまた全部混ざります。
そこで今回は、状態判定まわりをかなり整理しました。
方針としては、「公式カレンダーやレスポンス由来の状態を使いつつ、最終判定の流れは一本化する」です。すでに一部のソースでは、Yahoo 系の marketState や Twelve Data の is_market_open のように、相手側レスポンスから市場状態を読む実装は入っていました。ただ、全市場で“公式一次情報由来の状態区分を主判定にしている”ところまでは行っておらず、時刻ベースや freshness ベースの推定も混ざっていた。そこで今回は、calendar と response の二系統を並行評価しつつ、session 判定をより一貫して扱う方向へ寄せました。実装としては、calendar / response / final session_open / mismatch を個別に見えるようにして、少なくとも「どこで食い違っているのか」は追える状態にしています。
この修正が効いているかは、再起動後の確認でもかなり見えました。
実際に確認した時点では、3市場とも source_alive=1 が立ち、global_fv は calendar=1 / response=1 / open=1 / mismatch=0、ETF は calendar=0 / response=0 / open=0 / mismatch=0、CME も calendar=1 / response=1 / open=1 / mismatch=0 という形で、少なくとも休開場判定と接続状態の整合はかなり良くなっています。以前のように「見えていないのは弱いからなのか、休場だからなのか、設定ズレなのか」が曖昧な感じではなくなってきました。ここは見た目以上に大きな改善です。今はまだ勝ち筋を語る段階ではありませんが、少なくとも“何が起きていないのか”を、前よりまともに切り分けられるようになったとは言ってよさそうです。
あと、Grafana の主画面を整理したのも、この文脈ではかなり意味がありました。
最初は availability や session や computable 系をいろいろ重ねて表示していたんですが、正直かなり見づらかったんですよね。情報量は多いけど、じゃあ今この市場は「つながっているのか」「開いているのか」がパッと分かるかというと、そこは怪しかった。なので途中でかなり割り切って、接続状態と開場状態を中心に読む最小表示へ寄せました。要するに、運用でまず知りたいことだけを残した感じです。今の段階ではこの方がずっと良いと思っています。少なくとも、日々の確認で無駄に頭を使わなくて済む。将来また診断用の情報を増やすにしても、それは“必要になってから”で十分です。
ここまでをまとめると、この章でやったことは単なるバグ修正ではありません。
もっと正確に言うと、市場別に意味を持たせた観測機を、実際に信頼して回すための運用土台を整えた、というのが今日の一歩でした。観測機を作るだけなら、AIがいればかなり速く進みます。でも、それを「信用して観測を積み上げていい装置」にするには、やっぱり安定稼働と状態判定の確認が必要です。今日はそこの地味で重い部分を、ちゃんと現実に引き戻した日だったと思っています。
3. quality NG のデータが有効サンプル化しうる穴を塞いだ
今日やったことの中で、たぶんいちばん地味で、でも研究的にはかなり大きかったのがここです。
一言で言うと、quality が悪いと分かっているデータが、別経路で有効サンプル扱いされうる穴を塞ぎました。
これだけ書くとちょっと分かりにくいですよね。自分でも最初、CODEX 側の説明を読んだだけでは「つまり何が起きていたの？」となりました。なので、ここでは未来の自分向けに、できるだけ平たく整理しておきます。
本来、lead 側の source が stale していたり、品質的に ready ではなかったりする場合、そのデータは「今回は比較に使わない」で落ちる方が自然です。少なくとも、自分があとで市場別の threshold や構造判定を見直すときに、そういうデータまで母集団に入っていたら嫌なんですよね。ところが今回の確認では、source_quality_flag=0、つまり機械の中では「品質NG」と分かっているデータなのに、条件によっては event 化され、そのまま sample_valid=true として保存されうる経路が見つかりました。要するに、quality gate が入口で完全には閉じていなかったわけです。
ここでまずかったのは、単に実装が美しくないとか、コードが気持ち悪いとか、そういう話ではありません。もっと直接的に、あとで市場を評価する時に、見るべきでないデータが混ざるのがまずかった。たとえば、本当は「source が stale していただけ」「quality が落ちていただけ」で follow が立たなかったケースまで、あとから集計すると「この市場は弱い」「この定義は微妙」「threshold を変えた方がいいかも」と見えてしまう可能性がある。つまり、市場構造の弱さとデータ品質の悪さが混ざるんですよね。これ、かなり危ないです。特に今みたいに、市場別の器をようやく通して、これから数営業日データを育てていこうという段階では、こういう混ざり方はできるだけ避けたい。
今回の確認では、この不整合が実データ上でも見えていました。
説明としては、
- quality 非依存で検出が走りうる
- stale な tick でも return series に積まれうる
- その結果として
sample_valid=trueの保存経路まで行けてしまう
という流れです。これ、未来の自分が読み返すときに「結局どこが悪かったの？」となりそうなので、かなり雑に言い換えると、**“quality NG と知っているデータに、途中で valid 扱いの抜け道があった”**という理解でだいたい合っています。
なので今回の修正では、そこを3段くらいで塞ぎました。
まず、source_quality=1 を event 検出の必須条件にしました。品質NGなら、そもそも event 候補として立てない。次に、source_quality=0 の tick は return series に入れないようにして、後段の集計にも混ざらないようにしました。さらに、防御として reject reason に source_quality_not_ready を追加して、「なぜ落ちたのか」を後からちゃんと追えるようにしています。ここまでやって、ようやく quality NG データが“うっかり有効サンプル化する経路”をかなり潰せた という状態です。
この修正のポイントは、ここを直したからといって、急に勝てるようになるわけではないことです。そこは勘違いしないようにしておきたいです。これは「勝ち筋を見つけた修正」ではありません。むしろ意味としては逆で、今後の threshold 調整や市場比較を、少なくとも品質NGデータで歪めにくくした修正です。つまり、今日から先に溜まるデータを、前より少し信じやすくした。ここが本質です。
あと、これは再読する自分向けに書いておきたいんですが、今日こういう修正を入れたからこそ、今はまだ threshold や horizon を触らない方がいい という判断にもちゃんと意味があります。もしここでまた設定をいじり始めると、せっかく quality 汚染を減らした後の観測期間が、すぐに別条件のデータで分断されます。そうなると、また「この反応って修正の効果なのか、設定変更の効果なのか」が曖昧になります。今日の修正は、研究を前に進めるための土台づくりであって、ここから先はその土台の上で修正後データを育てるフェーズに入るのが自然です。
まとめると、この章でやったことはかなりシンプルです。
quality NG と分かっていたデータが、別経路で valid 扱いされる穴を見つけて塞いだ。
それだけです。
でも、その「それだけ」が今の段階ではかなり重い。ここを放置したまま市場別チューニングを進めるより、ずっとマシです。派手さはないけれど、少なくとも今日以降に溜まるデータについては、前より少し安心して見ることができるようになりました。
5. 今日わかったのは、「今はまだ触らない方がいいもの」だった
今日の作業を通して整理できたのは、どの市場が強そうかとか、どの定義が主線になりそうかといった話ではなく、今の段階で触るべきものと、まだ触るべきではないものの境界でした。
まず、今回手を入れたのは、観測機の安定稼働、休開場判定、quality gate、監視パネルの見せ方といった、運用の土台に近い部分です。逆に言えば、市場別の threshold や horizon、4定義の優先順位、市場ごとの主判定・補助判定の本実装には入っていません。ここは「後回しにした」というより、まだその順番ではないという整理です。今回の修正でようやく、修正後データを一つの母集団として育てられる条件が整い始めたところなので、その前に研究判断を入れると、また比較条件が崩れます。
今回の確認の中で、特にその判断を強くしたのが、quality 周りの不整合でした。source_quality_flag=0 のデータが event 化され、条件によっては sample_valid=true として保存されうる経路があった以上、少なくとも修正前の状態では、評価母集団に品質NGデータが混ざる余地がありました。この状態で「Global は弱い」「ETF は反応しない」「この定義はダメそう」といった話をしても、そこに入っているのが市場構造の差なのか、データ品質の差なのかが分かりません。今回の修正で見たかったのは、まずそこを分離することでした。なので、今やるべきなのはチューニングではなく、修正後データで同じ観測をしばらく続けることです。
状態判定まわりも同じです。
接続状態と開場状態を分けて見えるようにしたことで、少なくとも「見えていない」の理由は以前より切り分けやすくなりました。実際、3市場とも接続状態は維持されている一方で、開場状態は市場ごとに分かれており、ETF は休場、Global と CME は開場という形で読める状態になっています。ただ、この段階で言えるのはそこまでです。これをもって「ETF は弱い」とか「Global と CME にはすでに構造がある」といった判断には進まない。今はまだ、開場・接続・品質の切り分けができる状態になったという確認が先にあります。
この整理を踏まえて、当面触らないものもかなりはっきりしました。
具体的には、
- 市場別 shock threshold の再調整
- horizon の再設定
- 4定義の採否や優先順位の変更
- 市場ごとの主判定 / 補助判定の本実装
- 新しい市場や feature の追加
- EV>0 の最終結論
あたりです。今回の修正後データを一定期間溜める前にここを動かすと、結局また「修正の効果」と「設定変更の効果」が混ざります。少なくとも今の段階では、その混ざり方を増やす理由がありません。
逆に、今やることはかなり限定されています。
朝夕の接続・開場・mismatch・例外再発・quality reject の確認、修正後データの蓄積状況の記録、ETF の主確認時間帯での状態チェック、それから日次メモの更新です。ここで見るのは研究結論ではなく、運用が壊れていないか、修正後データが予定どおり育っているかです。この区別を崩さないことが、いま一番大事な運用ルールになります。
要するに、今日は「何が見えたか」を増やした日ではなく、何をまだ判断材料にしてはいけないかを切り分けた日でした。今回の段階で必要なのは、新しい解釈や新しい調整ではなく、条件を固定したまま観測を続けることです。次の判断は、修正後データが一定量溜まってから行います。そこまでは、観測を維持すること自体が作業になります。
6. これからは修正後データを育てる期間に入る
今日の作業が終わった時点で、次にやることはかなり限定されました。
市場別の threshold を詰めることでも、4定義の優先順位を並べ替えることでもなく、修正後データを一定期間、同じ条件で溜めることです。
今回の修正では、状態判定まわりの見直しと、quality NG データの混入経路の遮断を進めました。ここで条件を固定せずにまた設定を動かすと、次に溜まるデータは「修正の影響」と「設定変更の影響」が混ざったものになります。そうなると、後で見返したときに、何が効いて何が効いていないのかがまた曖昧になります。なので当面は、設定を足さない、判定を増やさない、観測を崩さないという方針で進めます。
この期間にやることは、研究調整ではなく運用確認です。
具体的には、朝夕の接続・開場・mismatch・例外再発・quality reject の確認、それから ETF の主確認時間帯での状態チェック、修正後データの蓄積状況の記録です。ここで見るのは「この市場は強そうか」ではなく、「観測機が予定どおり回っているか」「修正後データが同じ条件で増えているか」の二点です。つまり、今の主語は市場構造ではなく、観測条件の維持にあります。
この運用ルールも、今回かなり絞りました。
チェック回数は朝夕の一回ずつに固定し、必要なら朝だけでもよい形にしています。日中に何度も見に行くと、確認が監視に変わり、監視が不安に変わり、不安が設定変更に繋がりやすいからです。ETF の確認についても、主確認は 22:30 以降、17:00 以降は補助確認としました。プレ・本線・アフターという頭の中での区別は持ちつつ、今はロジックや画面側には増やしません。ここでさらに分類や条件を足す理由はありません。
修正後データの起点日時は、すでにノートと実行ログの両方で追える状態にしてあります。
ここも今後の確認では重要です。後から「どこからが修正後か」が曖昧になると、結局また同じところで止まります。なので、今後の確認や集計では、修正後データだけを見るという線を崩さないようにします。日次メモも最大5行までにして、長い振り返りや評価はここではやりません。書く内容は、接続・開場・例外・quality・一言メモ程度で十分です。今の段階で必要なのは、きれいな感想ではなく、後から見返せる最低限の記録です。
この5営業日で見たいのは、主に次の3点です。
ひとつ目は、ETF を含めて例外再発がないか。
ふたつ目は、3市場の接続状態と開場状態が、想定どおりに推移するか。
三つ目は、source_quality_flag=0 なのに sample_valid=true になるような再発がないか。
この3つが安定しているなら、ようやく「修正後データを評価に使ってよいか」を考え始められます。逆に、ここで再発があるなら、研究調整ではなく運用修正に戻ります。判断の順番はここで固定しておきます。
そのうえで、次の評価タイミングもすでに置いてあります。
中間確認は5営業日後、最低限の再評価は10営業日後、推奨の判定タイミングは15営業日後です。ここまでの間に、threshold や horizon をいじる予定はありません。市場別の主判定 / 補助判定の本実装もまだやりません。今は「何を見ているのか」を増やす段階ではなく、同じ条件でどれだけ観測を積めるかを見る段階です。
この期間の空き時間は、別テーマに使います。
すでに進めている DeFi の利回り付きステーブルコイン研究と、『市場と取引』を使った市場構造の勉強です。ここでは新しい観測機を増やしたり、本線に似たテーマを横に広げたりはしません。本線は本線で固定して回し、別の時間は別の勉強に使う。この切り分けで進めます。今の段階で必要なのは、観測待ちの時間を設計変更で埋めることではなく、別軸で地力を積むことです。
まとめると、これからしばらくの主作業は、研究調整ではなく修正後データの育成と運用確認です。
見る回数を絞る。条件は固定する。再発だけを拾う。評価は決めたタイミングまで持ち越す。今後しばらくは、この形で進めます。
7. 今日の整理と、次の進め方
今日やったことをまとめると、観測機の役割を増やしたというより、今の観測機を同じ条件で回し続けられる状態へ寄せたという整理になります。
前回までで、global_fv、CME、ETF を同じ雑な器で見ないようにし、市場ごとの差を前提にした観測機へ寄せるところまでは進めていました。今回はその次として、接続・開場判定・quality gate・監視パネルを見直し、修正後データを一つの母集団として扱える条件を整えました。ここで進んだのは、観測機の信用性であって、市場別の優位性そのものではありません。
現時点で言えるのは、3市場の接続状態と開場状態を前より分けて読めること、quality NG データが valid 扱いされうる経路を修正したこと、そして今後しばらくは threshold や horizon を触らずに修正後データを育てる方針が固まったことです。逆に、どの市場が主線か、どの定義を残すか、EV>0 をどう評価するかといった話はまだここでは扱いません。そこは、修正後データが一定期間溜まってから見ます。
次にやることもすでに絞っています。
朝夕の接続・開場・mismatch・例外再発・quality reject の確認、ETF の主確認時間帯での状態チェック、修正後データの蓄積状況の記録です。評価は5営業日・10営業日・15営業日を節目にして行い、その間は設定を固定したまま観測を続けます。研究調整ではなく、まずは同じ条件で観測を積むことを優先します。
今回の整理を一文で書くなら、
市場別の器を作った次に、その器を条件固定で回せる状態へ寄せた
ということになります。
ここから先は、修正後データを増やしながら、運用の再発がないかを見る段階に入ります。次の判断は、そのデータが揃ってから行います。