こんにちは、よだかです。
今日は、研究仮説そのものではなく、研究基盤の構成を整理していました。
きっかけは、最近進めているxStocksの研究です。
Solana上のxStocksについて観測を続けているのですが、その延長で、
Hyperliquid側のxStocksと価格差や時間差があるのか。
どちらかが先に動き、もう一方へ価格変化が伝わることはあるのか。
という方向を調べたくなりました。
そこでHyperliquid側の観測を追加しようとしたところ、一つ気になることが出てきました。
Hyperliquidのcollector自体は、すでに別の研究で作っています。
では、
xStocks研究のために、またHyperliquid collectorを作るのか。
という話です。
今回はここから、研究用のリポジトリ群を一度棚卸しすることになりました。
結果として、
特定の研究に埋め込んでいたHyperliquid観測機を、複数研究から使える独立したobserverとして切り出す
ところまで進めています。
今回はその開発ログです。
これまでは、仮説ごとにプロジェクトを作る方が速かった
これまでの研究では、基本的に、
仮説を立てる
↓
その仮説専用のprojectを作る
↓
必要なcollectorを作る
↓
データを取る
↓
仮説を検証する
という形をかなり多く使ってきました。
このやり方は、今でもかなり合理的だと思っています。
研究初期では、
- その仮説が生き残るか分からない
- 必要なデータもまだ確定していない
- どこまで実装する価値があるか分からない
からです。
この段階で、
将来いろいろな研究から使うかもしれないから、最初から汎用的な観測基盤を作ろう
とすると、必要以上の設計になりやすいです。
仮説が翌日に死ぬかもしれないのに、そのための立派な共通基盤を先に作っても仕方がありません。
だから、まずは小さく作る。
観測する。
使えるか確かめる。
必要なら捨てる。
この方が速い。
実際、これまでの開発でも、研究対象を混ぜないために別projectへ分離したり、最小構成の観測機を別系統で立てたりしてきました。
以前のLead-Lag研究でも、既存の観測機をそのまま肥大化させるのではなく、新しい研究対象は別系統で立ち上げる方針を取っています。
-
-
🛠️開発記録#500(2026/4/2)multi_market_probe開発ログ ― Lead-Lag観測機を、FACTとDECISIONで読める形に固定した話
続きを見る
ここまでは、
研究ごとに分ける方が速い
という判断でした。
ところが、研究が並列化すると事情が変わってくる
最近は、複数の研究テーマを並行して動かすことが増えています。
例えば、
- CEXとHyperliquidの価格形成
- 清算やdeleveraging周辺の市場構造
- DeFiのライフサイクル転換
- tokenized equity
- cross-chain / cross-venueの価格差
などです。
ここで、同じ観測対象が別々の研究に何度も登場するようになってきました。
今回の場合、それがHyperliquidでした。
以前からHyperliquidは、CEX・DeFiを横断して市場構造を見るための観測点として使っています。
-
-
🛠️開発記録#550(2026/8/21)清算はどこから伝播するのか｜CEX・Hyperliquid・DeFiの横断観測を始めた話
続きを見る
さらに、CEXとHyperliquidのどちらが先に動いたのかを見るために、timestampの扱いもかなり詰めてきました。
この部分は直近の記事で書いたので、今回は繰り返しません。
-
-
🛠️開発記録#556(2026/8/29)botの精度は高ければ高いほどいい？｜CEX–DEXのtimestamp同期で「必要十分」を考えた話
続きを見る
そして今回は、xStocksを調べている途中でまたHyperliquidが出てきました。
ここで、
これはもう特定の研究だけに属するcollectorではないのではないか。
と考えるようになりました。
「研究の部品」から「研究設備」へ変わる瞬間
今回一番大きかったのは、この認識の変化です。
最初にcollectorを作ったときは、
この研究で必要だから作る
という位置づけでした。
しかし別の仮説でも使う。
さらに別の仮説でも使いそうになる。
そうなると、collectorの寿命が研究仮説の寿命より長くなります。
仮説Aは捨てるかもしれない。
仮説Bも半年後には終わっているかもしれない。
でも、
Hyperliquidからpublic market dataを取得する
という能力自体は、その後も使います。
ここまで来ると、
研究repoがcollectorを所有する
よりも、
共通observerを各研究が利用する
方が自然です。
イメージとしては、こんな感じです。
以前
研究A
├─ collector
├─ DB
└─ analysis研究B
├─ collector
├─ DB
└─ analysis
これを、
Hyperliquid Observer
↓
canonical observation
↓
┌──────┼──────┐
↓ ↓ ↓
研究A 研究B 研究C
へ変える。
今回やったのは、この切り替えです。
以前から「データ基盤は共有し、研究エンジンは分離する」と考えていた
実は、この考え方自体が今日突然出てきたわけではありません。
少し前に清算脆弱性を調べ始めたときも、
既存のデータ基盤は共有する。
ただし、新しい研究ロジックは既存システムへ直接混ぜない。
という方針を取っています。
-
-
🛠️開発記録#549(2026/8/7)清算カスケードの前兆は観測できるのか｜「清算脆弱性探知機」を作り始めた話
続きを見る
今回やったことは、その考え方をもう一段上へ進めたものだと思います。
以前は、
既存観測機
↓
保存データ
↓
別の研究エンジン
という分離でした。
今回は、
そもそも複数研究から利用する観測機そのものを、個別研究から独立させる
ところまで進めました。
似ていますが、少し違います。
研究ロジックだけでなく、
どこが市場を観測する責任を持つのか
まで整理した形です。
今回はHyperliquid observerを独立させた
そこで、Hyperliquidのpublic market dataだけを扱う独立observerを作りました。
役割はかなり限定しています。
取得するのは、
- BBO(Best Bid and Offer)
- trades
- 必要になった場合の限定的なmarket data
など。
一方で、
- 売買判断
- 注文
- wallet
- private API
- 個別の研究仮説
- arbitrage判定
- PnL計算
などは持たせません。
observerが知るのは、
市場で何が起きたか
までです。
それが、
清算の伝播なのか。
xStocksの価格形成なのか。
cross-venueの歪みなのか。
を判断するのは、それぞれの研究側です。
ストレージ問題も、今回の整理を後押しした
今日は同時に、別の観測runでストレージがかなり肥大化している問題も見つかりました。
原因を追うと、
同じ情報を加工段階ごとに複数世代保存していた
ことが大きな要因でした。
raw。
normalized。
途中の派生データ。
並べ替えたデータ。
最終データ。
こうしたものを全部残していけば、当然ストレージは膨らみます。
(この話自体は別のテーマとして一本書けそうなので、今回は深掘りしません)
ただ、今回Hyperliquid observerを独立させる際には、この反省をかなり反映しました。
例えば、
- raw保存はdefault off
- run時間をboundedにする
- DB容量に上限を置く
- logをrotationする
- 研究固有の巨大なderived dataをobserver側で作らない
などです。
つまり、
観測する場所と、研究のために加工する場所を分ける
ことには、コード構造だけでなくデータ管理上のメリットもあります。
共通化は、早ければ早いほどいいわけではない
ここは今回かなり意識したところです。
今日の結果だけを見ると、
最初からHyperliquid observerを独立させておけばよかったのでは？
とも見えます。
でも、今のところそうは考えていません。
最初にHyperliquidを触った時点では、
- 今後どれだけ使うか分からない
- 必要なchannelも分からない
- timestampの扱いも固まっていない
- どこまで保存する必要があるかも分からない
状態でした。
その段階で汎用基盤を作っても、おそらく必要以上に複雑になっていたと思います。
実際に何度も使った。
別の研究にも登場した。
既存のcollectorを流用するか考える回数が増えた。
そこで初めて、
共通化するコストより、共通化しないコストの方が大きくなってきた
と判断できました。
だから今後も、
一回使ったから共通化する
とはしないつもりです。
ただし、
独立した複数の研究で、同じ観測能力を二度、三度と必要とする
ようになったら、その時点で一度立ち止まります。
研究固有の部品なのか。
それとも今後も使う研究設備なのか。
この判断を以前より少し早めに入れてもよさそうです。
DeFi側でも、共通観測基盤が必要になってきた
CEXについては、以前から比較的この感覚がありました。
Binanceなど主要な取引所のデータ取得処理は、一つの戦略だけのために毎回作るものではありません。
market dataを取る。
正規化する。
保存する。
その上で複数の研究やbotから使う。
こういう構造は比較的自然です。
一方、DeFiではこれまで、
プロトコルごとにかなり違う
という感覚が強く、研究ごとに必要なcollectorを作ることが多くなっていました。
でも研究を続けていると、
Hyperliquid。
Solana。
EVM。
あるいは特定のDEXやlending protocol。
こうしたものが複数の仮説で繰り返し登場します。
そのとき、
どの粒度までを共通研究基盤として持つべきなのか
を考える必要が出てきます。
今回、Hyperliquid観測をどう置くかを考えることが、その最初の分かりやすい例になりました。
何を共通化するかは、まだ決めすぎない
とはいえ、
ではSolanaもEVMも全部共通化しよう
とまでは考えていません。
それをやると、今度は共通基盤を作ること自体が目的になってしまいます。
今のところの基準はかなり単純です。
実際に複数の独立研究で繰り返し必要になったものを、必要になった時点で切り出す。
Hyperliquidは今回その条件を満たしました。
今後、Solanaの同じ観測処理を何度も書くようになれば、そのとき考える。
EVMでも同じです。
先回りしすぎない。
しかし、同じものを何度も作り始めたら放置しない。
このくらいが今の研究スタイルには合っている気がします。
研究が速くなったからこそ、整理する周期も必要になる
今回の整理をしていて、
最近こういう大掃除が必要になるのは、研究の進め方が悪いからなのか。
ということも少し考えました。
ただ、現時点では必ずしもそうではないと思っています。
最近は、
仮説を作る
↓
まずread-onlyで観測する
↓
短いbounded runを回す
↓
面白ければ掘る
↓
ダメなら捨てる
という形で、かなり並列に研究を進めています。
このやり方を続ければ、局所的な実装が増えるのはある程度避けられません。
最初から、
半年後にも残るコードはどれか
を正確に予測することはできません。
だから、
散らからないこと
そのものを目標にするより、
散らかりが一定水準を超えたときに気づき、整理できること
の方が大事なのだと思います。
探索。
局所実装。
再利用パターンの発見。
共通化。
そしてまた探索。
今回の整理も、そのサイクルの一部として考えています。
現時点では、観測基盤まで
独立させたHyperliquid observerについては、まずBTCで短いsmoke testを行いました。
その後、今回のxStocks研究で使いたい、
- NVIDIA株系
- S&P500連動ETF系
- Nasdaq-100連動ETF系
についても短時間のpublic observationを通しています。
現時点では、
observerとしてpublic market dataを取得し、独立したstorageへ保存できる
ところまで確認しました。
現在は、もう少し長いbounded runで、
- reconnect
- duplicate
- timestamp
- storage growth
などを確認しています。
その後、xStocks 3銘柄と比較用市場を対象に、1時間のbounded runを実施しました。約1万件のイベントを取得し、再接続・重複・timestamp欠損・normalization errorはいずれも0件でした。
rawデータは保存せず、ストレージ増加も実測で約4MB/時に収まりました。ひとまず共通observer v1として継続利用できる状態と判断し、現在は24時間のbounded runに乗せています。
重要なのは、
まだxStocksに価格伝播のedgeを見つけたわけではない
ということです。
今回できたのは、その仮説を調べるための観測設備を整理したところまで。
研究そのものはここからです。
現時点での結論
今回の開発を通して、今のところこう考えています。
仮説探索の初期では、研究ごとに小さく作る方が速い。
しかし、
同じ観測対象が複数の独立研究で繰り返し登場するようになったら、その観測能力を研究固有の部品から共通基盤へ昇格させることを検討する。
最初から全部共通化する必要はありません。
逆に、何度も同じcollectorを書き続ける必要もありません。
今回のHyperliquidは、ちょうどその境界を越えたのだと思います。
以前は、
この仮説を検証するために、何を作るか。
を中心に考えていました。
最近はそこに、
この観測能力は、この仮説が終わったあとにも残るのか。
という問いが一つ増えてきました。
残るのであれば、それはもう個別研究の部品ではなく、研究基盤なのかもしれません。
複数の仮説を並行して回すようになったことで、ようやく見えてきた境界でした。
次は、この共通observerで取得したHyperliquid側のデータと、現在観測しているxStocks側のデータを比較し、
本当にvenue間で価格差や時間差があるのか。
を見ていきます。
今回は、そのための地面を整えた開発ログでした。
それでは、また。