🛠️開発記録#510(2026/4/12)リードラグ研究メモDAY7 ― mempoolを補助軸として試しつつ、本筋の問いに立ち返った日

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

今日はBitcoinのmempoolを観測機に補助軸として最小構成で追加し、値が取れて状態タグとして並置観測できるところまで進めました。ただ、作業を進める中で「これは本筋ではなく、脇道の進捗で満足しているだけではないか」という違和感も強くなりました。そこで、途中からは実装そのものよりも、「そもそも自分が狙うべきリードラグ構造とは何か」を改めて考え直す時間に切り替えました。

1. mempoolを補助状態タグとして最小実装した

今日はBitcoinのmempoolを、観測機の補助軸として最小構成で追加していました。

ここで言うmempoolは、ざっくり言えば「まだブロックに入っていない未承認トランザクションの待機列」のことです。今回見たかったのは、その情報自体で短期の価格方向を直接当てることではありません。そうではなく、Bitcoinまわりの混雑状況をざっくりと状態として切れないか、という方向で試してみました。

実装としては、mempool由来の特徴量を3つだけに絞っています。未承認 backlog の総量、高 fee 側の積み上がり比率、そして短期的な backlog の増減です。要するに、「今どれくらい混んでいるのか」「高い手数料を払ってでも早く通したい人が増えているのか」「その混雑が増えているのか解消しているのか」を、なるべく素朴な形で見られるようにしたかったわけです。

今回はこのあたりをいきなり大きく配線するのではなく、かなり慎重に進めました。collector だけ追加して、実データが本当に取れているかを確認し、その後に特徴量を露出し、最後に low / mid / high の簡単な regime として可視化する、という順番です。保存量が膨らみすぎないようにも気をつけつつ、過剰な quality gate を積んで最初から観測を歪めることも避けました。

最終的には、Grafana 上で backlog 系の専用パネルまで表示できるところまで進みました。少なくとも「値が取れているかどうか」「状態タグとして最低限回るかどうか」という意味では、一旦の形にはなったと思います。

ここだけ切り取ると、今日はそれなりに進んだ日です。実際、最小構成で観測線を通して、ダッシュボードで見える状態まで持っていけたのは素直に前進だと思います。問題は、その先でした。

2. ただし、これが主線かどうかには違和感が残った

一方で、作業を進めながらずっと引っかかっていたこともありました。
それは、「これ、本当に今の自分の主線なんだっけ？」という違和感です。

mempoolを補助状態タグとして観測機に追加すること自体には、それなりに意味があると思います。少なくとも、何も考えずに値を増やしているわけではなく、「市場の背景状態を粗く切る材料になるかもしれない」という仮説は一応あります。最小構成で実装して、過剰に作り込まず、まずは値が取れて並置観測できるところまで持っていく、という進め方も悪くなかったはずです。

でも、途中からどうしても気になってきたんですよね。
これって結局、「本筋の問いに向かうのがしんどいから、周辺の実装で進んだ感じを得ているだけなんじゃないか？」と。

こういう作業は、わりと危ない。
手を動かせるし、前に進んだ感じもあるし、ダッシュボードに新しいパネルが出れば達成感もある。しかも、完全に無意味というわけでもないから厄介です。無駄じゃない。無駄じゃないからこそ、つい「ちゃんと研究している」と思いやすい。

ただ、金の匂いを追うという観点で見ると、やっぱり少し遠い。
mempoolを補助軸として眺めることは、背景状態の理解にはつながるかもしれません。でも、それだけで「誰のどんな遅れから金を抜くのか」という核心に近づいている感じはあまりしませんでした。要するに、研究としては成立していても、収益構造の探索としては脇道っぽいのです。

もちろん、こういう脇道が全部悪いわけではありません。
問題なのは、それを主線だと錯覚し始めることです。実際には補助線にすぎないのに、作業した満足感のせいで「今日もちゃんと前に進んだ」と思ってしまう。これ、かなり危ないパターンだと思います。自分はこういうのにハマりやすいので、なおさら気をつけないといけない。

今回、mempoolの実装そのものを全否定したいわけではありません。
最小構成で止めている限りは、まだ損失限定できているとも言えます。けれど、「これは本当に主線か？」と疑い直せたことの方が、たぶん今日の進捗としては大きかったです。

手を動かしたことより、その手つき自体を疑えたことの方が重要だった。
今日はそんな日でした。

3. 超短期リードラグは技術勝負の戦場かもしれない

こうした違和感から、途中で一度、リードラグ構造そのものの基本に立ち返って考え直してみました。

そもそも、超短期のリードラグがなぜ生じるのか。
ここを曖昧にしたまま「何か先行するソースはないかな」と探し続けても、たぶんあまり意味がありません。まずは、どういう仕組みでズレが生まれ、誰がそれを埋めているのかを考えないといけない。

今の自分の理解では、ミリ秒〜数秒台の短期リードラグって、かなりの部分が市場間の価格同期や裁定、マーケットメイカーのクオート更新、システマチックな追随によって説明できそうです。要するに、関連する市場で価格が少しズレたときに、その差分を素早く見つけて埋める主体がいる。その過程で「一方が先に動き、もう一方が少し遅れて追随する」という形が観測されるわけです。

こうして書くと当たり前の話なのですが、改めて整理するとかなり重い。
なぜなら、この領域は結局「わずかな歪みをいかに早く取りにいくか」という戦場になりやすいからです。つまり、そこでは構造の理解だけでなく、システムの反応速度、データ取得の速さ、実装の軽さ、執行品質といった要素がかなり強く効いてくる。見えているものがそのまま取れるとは限らないし、むしろ見えていても取れない可能性の方が高い。

観測できることと、拾えることは別。
これは以前から頭ではわかっていたつもりですが、今日はそこをもう一度、自分の言葉で認め直すような感覚がありました。

特に自分のような個人botterにとっては、この差はかなり大きいと思います。超短期のリードラグをそのまま主戦場にすると、どうしても技術勝負の比重が高くなる。もちろん、工夫や軽量化で多少は改善できるでしょう。でも、それが本当に自分の勝ち筋なのかと言われると、かなり怪しい。少なくとも、「そこをまともに殴り合うのはしんどい戦場っぽいな」という感覚は、かなり強くなりました。

ここで大事なのは、「じゃあリードラグ研究そのものがダメだ」と雑に結論づけないことです。
そうではなく、まず切り分けるべきなのは、超短期のリードラグがどの程度まで“技術的な遅れ”の話なのか、ということだと思います。システムや執行性能の差でほぼ埋められてしまうズレなのか。それとも、もう少し遅い参加者や異なる市場構造のせいで、数分以上残るような遅れなのか。この違いを曖昧にしたままでは、同じ「リードラグ」という言葉で全く違う戦場を一緒くたにしてしまう。

今日あらためて見えてきたのは、少なくともミリ秒〜数秒台の世界は、短期歪み回帰ともかなり重なっていて、個人が後追いで抜きにいくには厳しい可能性が高い、ということでした。
この認識は、たぶん逃げではなく、むしろ必要な現実確認だと思っています。

4. 本当に狙うべきは誰のどんな遅れなのか

そう考えていくと、次に問うべきことはかなりはっきりしています。
自分が狙うべきなのは、いったい誰の、どんな遅れなのか。

リードラグという言葉は便利ですが、便利すぎるがゆえに雑に使うと危ない。
一口に「遅れ」と言っても、その中には色々なものが混ざっています。単なるシステムの反応遅れ、板や注文の更新遅れのような技術的なものもあれば、情報の解釈や資金の再配分、ヘッジの実行といった判断・行動の遅れもある。前者は速い人間やシステムが先に刈り取りやすく、後者は参加者層や市場構造の違いによって、もう少し長く残る可能性がある。

ここをちゃんと分けないといけない。

たとえば、市場間でズレが生じているとして、その理由が単に「片方の更新が少し遅いから」なのだとしたら、それはかなり技術勝負の世界です。自分より速い主体がいれば、取り分はほとんど残らない。逆に、そのズレが「ある市場の参加者はこの情報をすぐ価格に織り込むが、別の市場では解釈や資金移動が遅れる」といった構造から生じているのなら、少なくとも観測しにいく価値はある。重要なのは、見えているズレの背後で、誰がどう反応しているのかを具体的に言葉にできるかどうかです。

結局のところ、勝ち筋があるかどうかはここに尽きる気がしています。
誰が金を落とすのか。
何が遅れるのか。
なぜその遅れが繰り返し発生するのか。
そして、その取り分は自分の執行可能な時間軸まで本当に残るのか。

この問いにまともに答えられないまま、「先行っぽいもの」を観測しても、多分だいぶ危うい。偶然の相関や一時的なズレを眺めて、それっぽいストーリーを後付けするだけになりやすいからです。botにするということは、そこに再現性を期待するということです。再現性があるなら、それを生む構造があるはずで、その構造はある程度言語化できないとおかしい。

今日はここまで考えて、ようやく少し整理できてきました。
自分が狙うべきなのは、単に「先に動くもの」ではない。
むしろ、「なぜそこに遅れが残るのか」を説明できるものの方です。

たぶん今の自分に必要なのは、新しいソースを増やすことよりも、まずこの問いに対して真正面から答えにいくことなのでしょう。誰が、何を見て、どう遅れ、その遅れがどこにどう現れるのか。次にやるべきなのは、その仮説を自分の言葉で書き出すことだと思います。

5. 次は仮説を自分の言葉で言語化する

そんなわけで、今日はmempoolを補助軸として最小構成で実装し、観測線を通すところまでは進めることができました。ここだけ見れば、一応ちゃんと前には進んでいます。実データを取って、特徴量を出して、ダッシュボードで見えるところまで持っていったのだから、それ自体は別に悪くない。

でも、今日の本当の収穫はそこではありませんでした。

むしろ大きかったのは、「これは本筋ではないかもしれない」と途中で自分にツッコミを入れられたことです。周辺の実装を進めることで、進捗感や満足感を得ることはできる。しかも、それが完全に無意味な作業ではないからこそ厄介です。だからこそ、そこで気持ちよくなって止まらず、「で、結局誰のどんな遅れから金を抜くつもりなんだ？」という問いに戻れたのは、それなりに大事な進捗だったと思います。

結局、次にやるべきことはかなり明確です。
これ以上周辺実装を増やすことではなく、自分が狙うべきリードラグ構造について、質問に答える形で仮説を自分の言葉で整理すること。誰が遅れるのか。何が遅れるのか。なぜその遅れが繰り返し発生するのか。そして、その取り分は自分の執行可能な時間軸まで本当に残るのか。このへんを曖昧なままにしていたら、観測機を何台立てても多分ダメです。

要するに、ここから先は実装の量ではなく、仮説の解像度の勝負なんだと思います。
見たいものを増やす前に、何を見れば金に近づくのかをちゃんと言葉にする。
そして、取れそうな構造と、観測できるだけで取れない構造を分ける。
そのあたりを、自分の中でごまかさずに整理していきたい。

今日は、実装が一区切りついた日でもあり、同時に「本当に考えるべき問い」にようやく戻ってきた日でもありました。