こんにちは、ぼっちbotterよだかです。
昨日の記事でも書いた通り、『市場と取引』を読み終えて、頭の中に大まかな地図を作ったので、今日から少しずつ開発フェーズに戻っています。
ただ、いきなり売買ロジックを作るというよりは、まずは読書で整理した市場構造の見方を、既存の観測機や研究テーマに戻していく作業から始めています。
今日やっていたのは、「見えるもの・見えないもの・代理変数」を分けて考えることです。
市場には、価格、出来高、板、スプレッド、OI、funding、basis、premium、residual のように、データとして直接見えるものがあります。
一方で、大口顧客のポジション変更、マーケットメーカーの在庫調整、裁定参加者の判断、ヘッジャーのリスク移転、APの裁定判断のように、重要そうではあるものの、外側からは直接見えないものもあります。
では、直接見えないものをどう扱うのか。
そこで必要になるのが、今回整理した「代理変数」です。
-
-
🛠️開発記録#537(2026/5/7)『市場と取引』を読み終えて、市場構造の理解をbot開発へ戻す準備をした話
続きを見る
1. そもそも「代理変数」とは？
bot開発やシステムトレードの文脈でいう「代理変数」とは、ざっくり言うと、
直接は見えないものに近づくために使う、観測可能な代替指標
です。
ただし、ここで気をつけたいのは、代理変数は「見えない原因を断定するための道具」ではないということです。
たとえば、リードラグ研究の文脈で考えると、「リード市場で大口顧客がポジションを変更し、その影響がラグ市場に遅れて伝播する」という仮説を持つことはできます。
しかし、実際のデータから直接見えるのは「大口顧客がポジションを変えた」という事実ではありません。
見えるのは、せいぜい次のような変化です。
- リード市場の価格が短時間で大きく動いた
- 出来高が通常より増えた
- OIが変化した
- fundingやbasisが変化した
- スプレッドが広がった
- 板が薄くなった
- ラグ市場側のresidualやpremiumが変化した
これらは、何かしらの市場変化の足跡ではあります。
しかし、それが大口顧客のポジション変更なのか、清算なのか、ヘッジなのか、裁定なのか、マーケットメーカーの在庫調整なのか、ニュース反応なのかは、この時点では分かりません。
だからこそ、実装上は「大口が動いた」「MMが引いた」「裁定が失敗した」といった原因ラベルをいきなり使うのではなく、まずは観測可能な変化そのものを定義します。
たとえば、
lead_return_eventlead_volume_spike_eventlead_oi_change_eventlead_basis_shift_eventlead_spread_widening_eventlead_depth_thinning_eventlag_residual_decay_event
のような形です。
これなら、原因を決め打ちせずに、実際に観測された市場の変化だけを扱うことができます。
今回の整理で一番大事だと思ったのはここです。
代理変数は、直接見えない原因を当てるためのものではなく、観測可能な市場の変化を分類し、仮説検証に接続するためのものとして扱う。
リードラグ研究であれば、リード市場側の価格変化、出来高変化、OI変化、basis変化、spread変化、depth変化などをまず事実ベースで定義する。
そのうえで、その変化の後に、ラグ市場側で follow、residual decay、net EV が発生するかを見る。
この順番で考えると、代理変数を「それっぽい原因ラベル」としてではなく、実務で検証可能な観測ラベルとして扱いやすくなります。
要するに、代理変数とは、
見えない本体を直接言い当てるものではなく、見える変化から仮説検証に進むための足場
です。
2. 代理変数は「原因」ではなく「変化」から作る
今回考えていて、一番重要だと思ったのはここです。
代理変数を作るときに、最初から原因を名前に入れない。
たとえば、リード市場で価格が大きく動き、出来高が増え、OIも変化したとします。
このとき、つい、
「大口が動いたのでは？」
「機関投資家のフローでは？」
「マーケットメーカーが引いたのでは？」
「裁定参加者が何かしたのでは？」
と考えたくなります。
実際、その可能性はあります。
ただし、外側から見えているデータだけでは、それを直接確認することはできません。
見えているのは、あくまで
- 価格が動いた
- 出来高が増えた
- OIが変化した
- fundingが変化した
- basisが変化した
- スプレッドが広がった
- 板が薄くなった
といった市場上の変化です。
ここでいきなり、
large_customer_position_change institutional_flow market_maker_withdrawal arbitrage_failure
のような名前をつけてしまうと、まだ確認できていない原因を、あたかも観測できた事実のように扱ってしまいます。
これはかなり危ないです。
なので、まずは原因ではなく、観測可能な変化そのものを定義します。
たとえば、
lead_return_event lead_volume_spike_event lead_oi_change_event lead_basis_shift_event lead_spread_widening_event lead_depth_thinning_event
のような形です。
この名前であれば、少なくとも「何を観測したのか」が明確です。
lead_return_event なら、リード市場の価格が一定以上動いたイベント。lead_volume_spike_event なら、リード市場の出来高が通常より増えたイベント。lead_oi_change_event なら、リード市場の建玉が一定以上変化したイベント。lead_spread_widening_event なら、リード市場のスプレッドが広がったイベント。
ここには、原因の断定は入っていません。
大口なのか、清算なのか、ヘッジなのか、裁定なのか、ニュース反応なのかは、まだ分かりません。
ただし、「市場にこういう変化が出た」という事実は残せます。
この分け方は、bot開発ではかなり大事だと思っています。
なぜなら、研究を進めていると、いつの間にか自分の仮説に都合のいい名前をデータに貼ってしまうことがあるからです。
たとえば、出来高急増を見て institutional_flow と呼んでしまう。
スプレッド拡大を見て mm_withdrawal と呼んでしまう。
ETFのpremium/discountが広がっただけで ap_arbitrage_failed と呼んでしまう。
こういう命名をしてしまうと、後から検証結果を見返したときに、自分で自分を騙しやすくなります。
本当は「出来高が増えた」だけなのに、「機関投資家が動いた」と読んでしまう。
本当は「スプレッドが広がった」だけなのに、「MMが撤退した」と読んでしまう。
本当は「premium/discountが広がった」だけなのに、「AP裁定が失敗した」と読んでしまう。
このズレが積み重なると、観測機が出している事実と、自分が頭の中で読んでいるストーリーがだんだん乖離していきます。
なので、今回の整理では、代理変数を作るときの原則をかなりシンプルに置きました。
原因ラベルではなく、観測ラベルから始める。
これは、今後の実装でもかなり重要なルールになりそうです。
原因について考えること自体は悪くありません。
むしろ、なぜその変化が起きたのかを考えないと、仮説は深まりません。
ただし、その原因解釈は、観測値や変化ラベルとは別のレイヤーに置く必要があります。
順番としては、
観測値 ↓ 変化ラベル ↓ 代理変数 ↓ 解釈候補 ↓ ラグ市場への反応検証 ↓ EV・執行可能性評価
くらいが良さそうです。
たとえば、リード市場で5分間に価格が大きく動き、出来高も増え、OIも変化したとします。
このとき、まず記録するのは、
lead_return_event = true lead_volume_spike_event = true lead_oi_change_event = true
です。
その上で、
lead_activity_proxy_event lead_positioning_proxy_event
のように、少しだけ意味づけしたproxyラベルを作ることはできます。
ただし、それでもまだ「大口が動いた」とは言わない。
言えるのは、
リード市場で、価格・出来高・建玉の面から通常より大きな変化が観測された
くらいです。
そのあとに見るべきなのは、その変化がラグ市場にどう出るかです。
具体的には、
lag_follow_60s lag_follow_180slag_follow_300s lag_residual_change lag_residual_decaynet_after_cost_bps
のようなものを見ます。
つまり、リード側で何かが起きたように見えるイベントの後に、ラグ側で追随があるのか。
ラグ側のresidualやpremiumは変化するのか。
その変化はコスト控除後に残るのか。
ここまで見て、ようやくbot開発上の検証になります。
今日の整理で、自分の中ではかなりはっきりしました。
代理変数は、原因を言い当てるための道具ではありません。
むしろ、
原因を決め打ちせずに、市場に表れた変化を検証可能な形に変換するための道具
です。
この理解を持っておかないと、リードラグ研究でもDeFi研究でも、観測値に対して強すぎる意味を乗せてしまいます。
今後は、コード上の命名でも
何が観測されたのか そこから何を代理的に見ているのか どこから先は解釈なのか
を分けるようにしたいです。
3. リードラグ研究では、何を代理変数として見るのか
では、実際にリードラグ研究の中で代理変数をどう使うのか。
ここは、かなり実務に近い話になります。
私がいま見ているリードラグ研究では、ラグ側は主に Binance Japan の BTC/JPY です。
一方で、リード市場候補としては、Binance Global、CME、ETF、USD/JPY、場合によってはDeFi側の状態など、複数の市場やデータソースを見ています。
ここでやりたいのは、単純に
リード市場の価格が動いた ↓ ラグ市場も遅れて動いた
を見ることだけではありません。
もう少し分解すると、
リード市場で、どの種類の変化が起きたのか その変化は、ラグ市場のどの反応に接続しているのか その反応は、コスト控除後に取れる可能性があるのか
を見たいわけです。
そのためには、リード市場側の変化を、ある程度分類しておく必要があります。
現時点では、まず次のような分類で考えるのが良さそうです。
price_change activity_change positioning_change liquidity_change distortion_change time_structure_change
日本語で書くと、
- 価格変化
- 活動量の変化
- ポジション・建玉まわりの変化
- 流動性の変化
- 歪み・基準線からの乖離
- 時間構造の変化
です。
この分類は、まだ完璧なものではありません。
ただ、少なくとも「市場で何かが変化した」と雑にひとまとめにするよりは、かなり扱いやすくなります。
価格変化を見る代理変数
まず一番基本になるのは、価格変化です。
これはリードラグ研究では当然のように見ているものですが、ここでも注意が必要です。
たとえば、リード市場でBTC価格が短時間に大きく動いたとしても、それだけで「大口が動いた」とは言えません。
言えるのは、
リード市場で一定以上の価格変化が観測された
ということだけです。
実装上は、たとえば次のような変数になります。
lead_return_bps_60s lead_return_bps_300s lead_abs_return_bps_300s lead_direction
これらは、リード市場の価格変化を測るための代理変数です。
たとえば、今のリードラグ観測では「リード側のfair valueが一定bps以上動いたか」をイベント条件に使っています。
これは、リード市場側で価格形成上の変化が起きたかを見るための入口になります。
ただし、価格変化だけでは、ニュースなのか、大口なのか、清算なのか、裁定なのか、単なる薄板ノイズなのかは分かりません。
なので、価格変化はあくまで最初の入口です。
活動量の変化を見る代理変数
次に見るのが、出来高や約定数です。
価格だけが動いていても、出来高が伴っていない場合、その変化は薄い板を突いただけのノイズかもしれません。
逆に、価格変化と同時に出来高や約定数が大きく増えているなら、少なくともその市場で取引活動が集中したとは言えます。
代理変数としては、たとえば次のようなものです。
lead_volume_zscore_5m lead_trade_count_zscore_5m lead_quote_volume_zscore_5m lead_large_trade_count
これらで見ているのは、
リード市場で通常より取引活動が増えたか
です。
ここでも、出来高急増を見て「機関投資家が買った」とは言いません。
安全に言えるのは、
リード市場で通常より大きな取引活動が観測された
までです。
そのうえで、価格変化と活動量変化が同時に起きている場合、単なる価格ノイズよりは、少し意味のあるイベントとして扱いやすくなります。
ポジション・建玉の変化を見る代理変数
perpや先物をリード市場候補として見る場合、OIやfunding、basisは重要になります。
ここで見たいのは、大口がロングしたかショートしたかを直接当てることではありません。
まず見るべきなのは、
市場全体のポジション総量や、レバレッジ需要、保有コストに変化が出たか
です。
代理変数としては、次のようなものが考えられます。
lead_oi_change_5m lead_oi_change_zscore_5m lead_funding_rate_level lead_funding_rate_change lead_basis_bps lead_basis_change_bps
OIが増えたからといって、ロングが増えたとは限りません。
OIはロングとショートが同時に存在する市場の建玉総量なので、方向を単体で断定することはできません。
ただし、価格変化と組み合わせることで、解釈候補は少し分けられます。
たとえば、
- 価格上昇 + OI増加
- 価格下落 + OI増加
- 価格上昇 + OI減少
- 価格下落 + OI減少
では、それぞれ意味合いが変わります。
それでも、ここで言えるのはあくまで、
ポジション総量の変化を伴う価格変化が観測された
というところまでです。
大口の新規ロングなのか、ショートカバーなのか、ロング解消なのか、清算なのかは、追加のデータや文脈を見ないと分かりません。
流動性の変化を見る代理変数
次に、流動性です。
これはリードラグ研究ではかなり重要だと思っています。
なぜなら、リード市場で価格が動いたとしても、それが「情報を伴う価格変化」なのか、「板が薄かっただけの価格変化」なのかで意味が変わるからです。
また、ラグ市場側でいくら追随が見えても、スプレッドが広すぎたり、板が薄すぎたりすれば、自分の注文では取れません。
流動性を見る代理変数としては、たとえば次のようなものがあります。
spread_bps spread_widening_flag top_depthdepth_thinning_flag orderbook_imbalance slippage_estimate price_impact_estimate
ここで見ているのは、
その市場で注文を通しやすい状態か
板やスプレッドに異常が出ていないか
流動性提供が弱まっているような足跡があるか
です。
ただし、スプレッドが広がったからといって、すぐに「マーケットメーカーが撤退した」とは言いません。
言えるのは、
スプレッド拡大や板厚低下が観測され、流動性状態が悪化している可能性がある
までです。
これは原因判定というより、まずはリスクフィルターや執行可能性の確認に使うのが安全です。
歪み・基準線からの乖離を見る代理変数
私の研究文脈で特に重要なのが、residualやpremiumです。
たとえば、Binance Japan の BTC/JPY を見る場合、単純な価格変化だけでなく、
Global BTC/USD × USD/JPY
のような基準線を作り、そこからどれだけズレているかを見ることができます。
このズレが、premiumやresidualです。
代理変数としては、次のようなものになります。
bj_premium_bps bj_residual_bps residual_change_bps residual_decay_60s residual_decay_300s reversion_within_60s_flag
ここで見たいのは、
ラグ市場がグローバル基準線に対して割高・割安になっているか
そのズレが戻るのか
戻るなら、どれくらいの時間で戻るのか
です。
これは単なる価格追随とは少し違います。
たとえば、BTC全体が上がって、Binance Japanも一緒に上がっただけなら、それは普通の価格変化です。
一方で、グローバル価格と為替から作った基準線に対して、Binance Japanだけが遅れている、または一時的にズレているなら、ラグ市場固有の歪みとして見られる可能性があります。
ただし、ここでも
residualが広がったから必ず裁定で戻る
とは言いません。
戻す主体がいるのか。
戻すためのコストはどれくらいか。
戻るまでの時間はどれくらいか。
自分のbotがその間に注文を通せるのか。
ここまで見て、ようやく実務上の検討になります。
時間構造を見る代理変数
最後に、時間構造です。
リードラグ研究では、「反応があるか」だけでなく、「どれくらい遅れて反応するか」が重要です。
たとえば、ラグ市場がリード市場に20秒で追随するなら、構造としては存在していても、個人botterが取るにはかなり厳しいかもしれません。
逆に、3分から10分かけてじわじわ追随するなら、研究対象として残す価値があります。
代理変数としては、次のようなものです。
time_to_follow_sec first_cross_time_sec max_response_horizon_sec residual_decay_speed response_half_life
ここで見たいのは、
変化がどの時間幅で伝播するのか
自分の執行速度とコストで間に合うのか
速すぎる構造なのか、遅すぎて別要因と混ざる構造なのか
です。
これは、単なる分析指標ではなく、実装可能性に直結します。
構造があっても、速すぎれば取れません。
遅すぎれば、他の要因が混ざりすぎます。
だから、時間構造は代理変数というより、リードラグ研究そのものの中核に近いです。
ここまでをまとめると、リードラグ研究で見る代理変数は、単に「リード価格が動いたか」だけでは足りません。
少なくとも、
| 分類 | 見るもの | 役割 |
|---|---|---|
| price_change | return, abs_return, direction | リード市場の価格変化 |
| activity_change | volume, trade count | 取引活動の集中 |
| positioning_change | OI, funding, basis | 建玉・レバレッジ需要・保有コスト |
| liquidity_change | spread, depth, slippage | 流動性・執行可能性 |
| distortion_change | residual, premium | 基準線からの乖離 |
| time_structure_change | time_to_follow, decay speed | 伝播速度・回帰速度 |
くらいには分けた方が良さそうです。
ただし、ここで大事なのは、この分類を最初から高精度に完成させることではありません。
最初は粗くていい。
むしろ、最初から「これは大口フロー」「これはMM撤退」「これはAP裁定失敗」といった高解像度の原因分類をしようとすると、かえって危ないです。
まずは、観測可能な変化を分ける。
そのうえで、どの種類の変化の後に、ラグ市場でfollowやresidual decayが出るのかを見る。
さらに、最終的にnet EVが残るのかを見る。
この順番であれば、代理変数をそれっぽい物語ではなく、実務の検証に接続しやすくなります。
4. 一次情報ベースで、どのデータを取得できるのか
代理変数について考えるときに、もうひとつ重要なのは、
そもそも、その代理変数の元になるデータをどこから取得できるのか
です。
ここを曖昧にしたまま進めると、かなり危ないです。
たとえば、ブログや解説記事で「OIを見る」「fundingを見る」「板厚を見る」「ETFのpremiumを見る」と書くことは簡単です。
ただ、実際にbotや観測機に組み込むなら、
- どのAPIから取れるのか
- どのエンドポイントを使うのか
- どの頻度で取れるのか
- リアルタイムなのか遅延なのか
- timestampは何を意味しているのか
- そのデータは公式に提供されているものなのか
- 自分の現在の実装で本当に取得できているのか
まで分けて考える必要があります。
代理変数は、頭の中で作る概念ではなく、最終的にはデータから作るものです。
なので、この章では、現時点で自分の研究に関係するデータソースについて、一次情報ベースで取得できるものと、まだ慎重に扱うべきものを分けて整理しておきます。
Binance / Binance Japan 系で見ているもの
まず、Binance系のデータです。
リードラグ研究では、Binance Global側のBTC価格や、Binance Japan側のBTC/JPY価格を見ています。
Binance Spot API系では、公式ドキュメント上、少なくとも次のような市場データを取得できます。
order book trades aggregate trades klines 24hr ticker
実務上、代理変数に落としやすいのはこのあたりです。
| 取得データ | 代理変数として使えるもの |
|---|---|
| order book | spread, top depth, depth imbalance |
| trades / aggTrades | trade count, volume spike, aggressive trade proxy |
| klines | return, volume, quote volume, taker buy volume |
| ticker | price change, volume, high/low, last price |
ここから作れる代理変数は、たとえば次のようなものです。
return_bps abs_return_bps volume_zscore trade_count_zscore spread_bps depth_topN taker_buy_ratio
ただし、ここで気をつけたいのは、Binance GlobalのSpot APIで取得できるものと、Binance Japanで実際に取得できるものを混同しないことです。
現在の自分の実装で Binance Japan 側の価格や板情報を取得できているなら、それは自分の観測機における事実です。
一方で、公式ドキュメント上で確認できるBinance Spot APIの仕様を、そのままBinance Japan専用仕様として断定するのは避けた方がよさそうです。
なので、記事上では、
Binance Spot API系では、板・約定・ローソク足・tickerなどの市場データを取得できる。
ただし、Binance Japan側については、現在の自分の実装で取得できている項目と、公式仕様として確認できる項目を分けて扱う。
くらいに書くのが安全だと思っています。
Hyperliquidで見ているもの
DeFi側、特にHyperliquidについては、すでに自分の観測機で mark_px、open_interest_usd、funding_rate、volume_24h_usd を見ています。
これは代理変数の文脈でもかなり扱いやすいです。
Hyperliquidでは、public APIの info endpoint から、typeを指定して各種情報を取得する形になっています。
現時点で研究に関係するのは、主に次のようなデータです。
| 取得データ | 代理変数として使えるもの |
|---|---|
| mark price | price_change, return |
| open interest | positioning_change |
| funding | funding_level, funding_change |
| volume | activity_change |
| L2 book | spread, depth, liquidity proxy |
| candle | return, volume, volatility |
これを自分の研究文脈に落とすと、次のようになります。
mark_px → Hyperliquid側の価格水準・価格変化 open_interest_usd → ポジション総量の変化を見るproxy funding_rate → レバレッジ需要・保有コストのproxy volume_24h_usd → 活動量の補助proxy L2 book → spread / depth / liquidity proxy
ただし、ここでも解釈は慎重にする必要があります。
open_interest_usd が増えたからといって、ロングが増えたとは言えません。
funding_rate が高いからといって、価格が上がるとも言えません。
volume_24h_usd が増えたからといって、大口が入ったとも言えません。
言えるのは、あくまで、
Hyperliquid上で、価格・建玉・funding・出来高に変化が出た
ということです。
現在のDeFi観測機では、Ethena側の状態ラベルとHyperliquid側の open_interest_usd、funding_rate、volume_24h_usd、mark_px を組み合わせて見ています。
今後、実務に寄せるなら、Hyperliquid側では open_interest_usd を activity / positioning proxy の中心に置き、funding_rate を risk / cost context として扱うのが自然そうです。
volume_24h_usd は単独シグナルではなく、補助的な活動量proxyとして扱う方が安全だと思っています。
Ethenaで見ているもの
Ethenaについては、現在の観測機で以下のようなデータを取得しています。
USDe supply protocol / staking yield collateral backing snapshot
ここから作っているのが、USDe supplyの変化、coverage proxy、backing/supply、そして supply_state × coverage_state によるEthena側のregime labelです。
整理すると、こうなります。
| 取得データ | 加工後のproxy | 見ているもの |
|---|---|---|
| USDe supply | supply_diff, supply_state | USDe供給量の変化方向 |
| collateral backing | coverage_proxy_ratio | backing/supplyの代理的な状態 |
| yield | yield_level, yield_diff | 利回り環境の変化 |
| supply × coverage | ethena_regime | Ethena側の観測状態ラベル |
ここでかなり重要なのは、Ethena側のregime labelを「真のリスク状態」と呼ばないことです。
現在作っているのは、
supply_expanding supply_contracting coverage_improving coverage_deteriorating expansion_coverage_improving expansion_coverage_deteriorating contraction_coverage_improving contraction_coverage_deteriorating
のような観測ラベルです。
これは、USDe supply と collateral backing から作ったcoverage proxyの変化方向を組み合わせたものです。
つまり、
Ethenaの発行体意図を読んでいるわけではない
Ethenaの真の健全性を判定しているわけでもない
USDe supplyからBTCやETHの価格方向を当てようとしているわけでもない
ということです。
あくまで、
Ethena側で観測可能な supply / coverage / yield の変化を状態ラベルとして整理し、その後のHyperliquid側の activity / risk proxy と接続する
という扱いです。
ここは、今日の代理変数の整理とかなり相性が良いです。
Ethena regimeは「原因ラベル」ではなく、「観測状態ラベル」として扱うべきものです。
CMEで見ているもの
CMEについては、BTC先物市場として、制度金融側のリード候補として見ています。
ここで重要なのは、CMEを単なるBTC価格の一種として扱わないことです。
CMEには、
- 取引時間
- 休場時間
- 限月
- roll
- basis
- OI
- volume
- session
- clearing / margin
- block / EFP / BTIC / TAS などの制度的な仕組み
があります。
自分の観測機で今すぐ全部を見る必要はありませんが、代理変数として見るなら、最低限このあたりです。
| 取得・加工対象 | 代理変数として使えるもの |
|---|---|
| futures price | CME return |
| spotとの差 | CME basis |
| volume | CME activity proxy |
| OI | positioning proxy |
| session | session tag |
| roll proximity | 限月・roll影響の補助ラベル |
CMEをリード市場として使うなら、価格変化だけではなく、
CME session CME basis CME volume CME OI roll proximity
のような情報を持っておいた方が、あとで解釈しやすくなります。
ただし、CMEの詳細データはライセンスや取得経路の制約が強いはずなので、ここは「理論上見るべきもの」と「今の自分の観測機で取得できているもの」を分ける必要があります。
現時点では、CMEはリード候補であると同時に、制度金融側のsession / regime tagとしての役割も大きいと見ています。
ETF / Nasdaq系で見ているもの
ETFについては、米国spot BTC ETFをリード候補のひとつとして見ています。
ETFで見たいものは、単純な価格変化だけではありません。
ETFには、
- pre market
- regular session
- after hours
- ETF価格
- 出来高
- spread
- premium / discount
- NAV
- AP / market maker
- creation / redemption
のような要素があります。
ただし、外側から直接見えるものと見えないものを分ける必要があります。
直接見えやすいものは、たとえば次のようなものです。
| 見えるもの | 代理変数 |
|---|---|
| ETF価格 | ETF return |
| 出来高 | ETF volume spike |
| BBO / quote | ETF spread |
| NAVとの差 | premium / discount |
| session | pre / regular / after |
一方で、直接見えにくいものは、
APの裁定判断 market makerの在庫 creation / redemption の実務判断 ETF裏側のヘッジフロー
です。
なので、ETFでpremiumやdiscountが広がったとしても、
AP裁定が失敗した
とは言いません。
安全に言うなら、
ETF価格がNAVまたは基準線に対してズレた
regular session中に出来高やspreadが変化した
その変化が、他市場やBinance Japan側にどう接続するかを見る
くらいです。
ETFは特にsessionの扱いが重要です。
pre / regular / after を混ぜると、出来高、spread、反応速度、情報の意味が変わります。
今の観測機でも、ETF regular session外の挙動は区別して扱う必要があります。
ここで分けるべきこと
ここまで整理して、改めて思ったのは、データ取得まわりでは次の3つを必ず分ける必要があるということです。
1. 一次情報としてAPIや公式仕様で確認できるもの 2. 自分の現在の観測機で実際に取得できているもの 3. そのデータから自分が解釈しているもの
たとえば、Hyperliquidの open_interest_usd を取得できることと、それを「大口ロングが増えた」と解釈することは別です。
EthenaのUSDe supplyを取得できることと、それを「市場のリスクオン/リスクオフ」と読むことも別です。
ETFのpremium/discountを取得できることと、「AP裁定が機能していない」と言うことも別です。
CME basisを取得できることと、「制度資金が動いた」と言うことも別です。
まずは、取得できるデータを確認する。
次に、そのデータから機械的に作れる代理変数を定義する。
最後に、その代理変数をどう解釈するかを、自分の仮説として別レイヤーで扱う。
この順番を崩さないようにしたいです。
現時点で、明日以降の実務にそのまま接続できそうなのは、
Binance系: price / volume / trades / orderbook から price・activity・liquidity proxy を作る Hyperliquid: mark_px / open_interest_usd / funding_rate / volume_24h_usd から activity・positioning・risk proxy を作る Ethena: USDe supply / coverage proxy / yield から state・regime label を作る CME: price / basis / session / volume / OI を制度金融側のlead・regime proxyとして扱う ETF: price / volume / spread / premium_discount / session をlead・distortion・session proxyとして扱う
あたりです。
一方で、自分で仮説として組む必要があるのは、
どの市場をリード候補として重視するか どのproxyの組み合わせをイベント条件にするか どの時間窓でラグ側の反応を見るか どのproxyをrisk filterとして扱うか どこから先を売買候補に進めるか どの条件なら仮説を切るか
です。
この区別を曖昧にしないこと。
今日の代理変数の整理は、最終的にはここに繋がると思っています。
5. 明日以降、コードに落とせる部分
ここまで整理してきた内容は、概念整理だけで終わらせるつもりはありません。
むしろ、今日の目的はかなり実務寄りで、
代理変数という考え方を、明日以降の観測機やbot開発にどう接続するか
を整理することでした。
その意味では、いきなり売買ロジックを書くよりも、まずは既存の観測機に対して「どの変化をどういう名前で記録するか」を揃えるのが先だと思っています。
具体的には、次の順番です。
観測値 ↓ 変化ラベル ↓ proxy event ↓ event study ↓ net EV / 執行可能性
この流れを、できるだけコード上でも崩さないようにしたいです。
まずは観測値を整理する
最初にやるべきなのは、各市場で取得できている観測値を整理することです。
たとえば、Binance Japan や Binance Global であれば、価格、出来高、約定、板、スプレッドなど。
Hyperliquidであれば、mark_px、open_interest_usd、funding_rate、volume_24h_usd など。
Ethenaであれば、USDe supply、coverage proxy、yield など。
CMEやETFであれば、価格、session、basis、volume、spread、premium / discount など。
ここで大事なのは、まず生データや一次加工データを、原因解釈なしで置くことです。
price return volume trade_count open_interest funding_rate basis spread depth premium residual session
この段階では、まだ「大口」「機関」「MM」「裁定」といった言葉は使いません。
ただ、データとして何が取れているのかを確認するだけです。
次に、変化ラベルを作る
その次にやるのが、観測値から変化ラベルを作ることです。
たとえば、価格からは価格変化イベントを作れます。
lead_return_bps_60s lead_return_bps_300s lead_abs_return_bps_300s lead_return_event
出来高からは活動量の変化を作れます。
lead_volume_zscore_5m lead_trade_count_zscore_5m lead_volume_spike_event
OIやfunding、basisからは、ポジション・保有コスト・リスク移転まわりの変化を作れます。
lead_oi_change_5m lead_oi_change_zscore_5m lead_funding_change lead_basis_shift_event
板やスプレッドからは、流動性の変化を作れます。
lead_spread_bps lead_spread_widening_event lead_depth_change lead_depth_thinning_event
ラグ市場側では、followやresidual変化を作ります。
lag_follow_60s lag_follow_180s lag_follow_300s lag_residual_change lag_residual_decay_300s
ここでやりたいのは、まず「市場にどういう変化が出たか」を、機械的に記録できる形にすることです。
proxy eventは、原因ではなく組み合わせとして扱う
変化ラベルを作ったら、次に proxy event を作ります。
ただし、ここでも原因ラベルにはしません。
たとえば、
lead_price_move_event lead_activity_event lead_positioning_proxy_event lead_liquidity_stress_event lead_distortion_event
のようにします。
lead_positioning_proxy_event と呼ぶことはできますが、これを large_customer_position_change_event とは呼ばない。
ここはかなり重要です。
なぜなら、OIやbasisが動いていても、それが大口顧客のポジション変更なのか、清算なのか、ヘッジなのか、裁定なのかは分からないからです。
なので、実装上は、
lead_oi_change_event lead_basis_shift_event lead_funding_change_event
のような事実ベースの変化ラベルを作り、それらを組み合わせたものを、
lead_positioning_proxy_event
くらいに留めるのがよさそうです。
これは「ポジション変化そのものを観測した」という意味ではなく、
ポジション・建玉・保有コストまわりに変化が出ている可能性を見るためのproxy event
という意味です。
リード側だけで完結させない
もうひとつ大事なのは、リード側のproxy eventを作って終わりにしないことです。
リードラグ研究で知りたいのは、リード市場で何かが起きたかだけではありません。
その後、ラグ市場側にどう出るかです。
なので、proxy event の後には必ずラグ側の反応を見る必要があります。
たとえば、
lead_activity_event = true ↓ lag_follow_60s はどうか lag_follow_300s はどうか lag_residual_change はどうか lag_residual_decay はどうか net_after_cost_bps はどうか
を見る。
この形にしておけば、リード側の変化が本当にラグ側に接続しているのかを確認できます。
逆に、リード側だけ見て、
これは強い変化だから使えそう
と判断するのは危ないです。
リード側でどれだけ綺麗なproxy eventが作れても、ラグ側でfollowが出ないなら、リードラグ研究としては弱い。
followが出ても、コスト控除後に残らないなら、売買候補としては弱い。
followが出ても、spreadやslippageで消えるなら、執行可能性は低い。
なので、必ずラグ側の反応とセットで見ます。
event studyとして見る
実装としては、まず event study に落とすのが良さそうです。
たとえば、
lead_price_move_event 後の lag_return_60s lead_activity_event 後の lag_return_300s lead_positioning_proxy_event 後の lag_residual_decay_300s lead_liquidity_stress_event 後の cost_pass_flag
のように、イベントごとにラグ側の反応を集計します。
見るべき指標は、少なくとも次のあたりです。
sample_count follow_ratemean_follow_bps median_follow_bps net_after_cost_bps time_to_follow_sec max_adverse_excursion_bps cost_pass_flag
ここでは、平均だけを見るのは危険です。
少数の大きな勝ちイベントだけで平均が押し上げられている可能性があるからです。
なので、中央値、sample count、hit rate、最大逆行幅、コスト控除後の値を一緒に見る必要があります。
また、リードラグ研究では、grossではなくnetを見るのが前提です。
自分の文脈では、少なくとも既存のroundtrip costである 7.6bps を控除して見る必要があります。
つまり、
followがあるか
だけではなく、
7.6bpsを引いても残るか
まで見ます。
ここを抜かすと、観測機としては面白いけど、bot開発としては実務に繋がりません。
最初から大量に作りすぎない
一方で、明日からproxyを大量に増やすのは危ないです。
できることはたくさんあります。
価格、出来高、約定数、OI、funding、basis、spread、depth、premium、residual、session、volatility、CVD、trade direction proxy、slippage estimate など、作ろうと思えばいくらでも作れます。
ただ、最初から全部を入れると、たぶん見通しが悪くなります。
なので、まずは各分類から1〜3個くらいに絞るのがよさそうです。
最小セットとしては、このくらいです。
| 分類 | 最初に見るproxy |
|---|---|
| price_change | lead_return_bps_300s, lead_abs_return_bps_300s |
| activity_change | lead_volume_zscore_5m |
| positioning_change | lead_oi_change_zscore_5m, lead_funding_change |
| liquidity_change | lead_spread_bps, lead_depth_change |
| distortion_change | lag_residual_bps, lag_residual_decay_300s |
| time_structure_change | time_to_follow_sec, follow_horizon |
これくらいなら、増やしすぎずに全体像を見られます。
反応がありそうな分類だけ、後から細かく分解すればいい。
最初から高解像度の分類を作るのではなく、まずは粗い分類で観測し、その結果を見て深掘りする。
この方が、今のフェーズには合っていると思います。
実装時に必ず持たせたいメタ情報
代理変数そのものとは少し違いますが、実装するならメタ情報もかなり大事です。
特にリードラグでは、timestampの扱いを間違えると、それだけで偽のリードラグができます。
最低限、次のような情報は持たせたいです。
source_event_tsreceive_tsnormalize_tsfeature_tssource_nameendpointsymbolsession_typestale_source_flag
source_event_ts は、そのデータが市場で発生した時刻。
receive_ts は、自分の観測機が受け取った時刻。
この2つがズレている場合、リードラグの検証ではかなり危険です。
以前のFXデータでも、source timestamp と receive timestamp の扱いで注意が必要でした。
なので、代理変数を作る前に、timestampの意味を確認する必要があります。
また、ETFやCMEではsession tagも重要です。
pre_marketregularafter_hourscme_opencme_breakholiday
のようなラベルを持たせないと、同じproxyでも意味が変わります。
regular session中のETF出来高と、after hoursのETF出来高は同じ意味ではありません。
CMEが開いている時間と、休場中の時間も同じではありません。
このあたりは、proxyの定義そのものと同じくらい重要です。
明日以降の最小実装イメージ
明日以降、実際にコードを書くなら、いきなり複雑なモデルにする必要はありません。
まずは、既存の観測機に対して、次のような軽い追加で十分だと思っています。
1. 市場ごとに取得済み観測値を棚卸しする 2. price / activity / positioning / liquidity / distortion / time_structure に分類する 3. 各分類につき最小限のproxyを1〜3個だけ作る 4. proxy event名には原因を入れない 5. event studyでlag側のfollow / residual / net EVを見る 6. sample不足なら判断しない 7. 反応がありそうな分類だけ後で深掘りする
このくらいであれば、今日の概念整理を実務に戻せます。
逆に、明日やらなくてよいこともあります。
大口フロー判定を作る MM撤退判定を作る AP裁定失敗判定を作る 最適閾値を探す 売買シグナルに直結させる
これらは、今やると早すぎると思っています。
まずは観測ラベルを作る。
次に、それがラグ側の反応に接続するかを見る。
それから、必要なら解像度を上げる。
この順番で十分です。
今日の整理を実装に落とすなら、最初のゴールはかなり明確です。
原因ラベルを作るのではなく、観測可能な変化ラベルを作る。
その変化ラベルの後に、ラグ市場でfollow、residual decay、net EVが出るかを見る。
これなら、代理変数を単なる概念整理で終わらせず、明日以降のbot開発に接続できます。
6. 自分で仮説を組む必要がある部分
ここまで整理してきた内容は、かなりコードに落とせます。
価格変化、出来高変化、OI変化、funding変化、basis変化、spread変化、depth変化、residual変化。
これらは、データさえ取得できていれば、ある程度は機械的に作れます。
ただし、ここで勘違いしてはいけないのは、
代理変数を作っただけでは、仮説を作ったことにはならない
ということです。
代理変数は、あくまで観測可能な市場の変化を整理するための道具です。
そこから先に、
なぜその変化を見るのか その変化がどの市場に伝播すると考えるのか どの時間窓で反応を見るのか その反応がなぜ自分のbotで取れる可能性があるのか どの条件なら仮説を切るのか
を決めるのは、自分の仕事です。
ここをAIやコードに丸投げすると、かなり危ないです。
代理変数は、仮説の材料であって仮説そのものではない
たとえば、リード市場で次のようなproxyを作ったとします。
lead_return_bps_300s lead_volume_zscore_5m lead_oi_change_zscore_5m lead_spread_bps lead_basis_bps
これらは、それぞれ市場の変化を表しています。
ただし、この時点ではまだ、
この変化がなぜラグ市場に伝わるのか どのラグ市場に伝わるのか どのくらい遅れて伝わるのか その間に自分が注文を出せるのか
は何も説明していません。
たとえば、リード市場の価格が5分で大きく動いたとしても、それがBinance Japanに遅れて伝わるとは限りません。
HyperliquidのOIが増えたとしても、それがEthena側の状態と意味のある関係を持つとは限りません。
ETFのpremium/discountが広がったとしても、それがAP裁定の失敗を意味するとは限りません。
CME basisが動いたとしても、それが国内BTC/JPYに取れる形で伝播するとは限りません。
つまり、proxyは「変化が起きた」という入口です。
そこから、
その変化が、なぜ、どこへ、どの時間軸で、どういう形で出るはずなのか
を組むのが仮説です。
自分で決めるべきこと
今後の実装や検証で、自分で決める必要があるものはかなりはっきりしています。
まず、どの市場をリード候補として見るのか。
Binance Globalなのか、CMEなのか、ETFなのか、USD/JPYなのか、Hyperliquidなのか、Ethenaなのか。
それぞれ市場構造が違います。
Binance Globalは暗号資産市場の中心的な流動性を持つ場所として見ています。
CMEは制度金融側のBTCリスク移転・ヘッジ市場として見ています。
ETFは米国株式市場セッションを通じてBTCリスクが取引される場所として見ています。
USD/JPYはBTC/JPYの基準線を作るうえで重要な為替要素です。
Hyperliquidはperp側の建玉・funding・活動量を見る場所です。
EthenaはUSDe supplyやcoverage proxyを通じて、DeFi側の資本状態を観測する場所です。
同じ「リード候補」と言っても、意味が違います。
なので、
この市場は何を代表しているのか どの制約を持っているのか どの時間帯に意味が強いのか どのラグ市場に接続しうるのか
は、自分で考える必要があります。
どのproxyを組み合わせるかも仮説である
次に、どのproxyを組み合わせるか。
これも自分で決めるべき部分です。
たとえば、リード市場で価格が動いたことだけを見るなら、
lead_abs_return_bps_300s >= 4bps
のようなイベントになります。
しかし、価格変化だけでは薄板ノイズや全市場共通ショックと区別しにくい。
そこで、出来高やOIを組み合わせると、
lead_abs_return_bps_300s >= 4bps AND lead_volume_zscore_5m >= 2 AND lead_oi_change_zscore_5m >= 2
のようなイベントになります。
これは、単なる価格変化ではなく、
価格変化に加えて、活動量や建玉の変化を伴うイベント
として扱うことになります。
ただし、この組み合わせを作ること自体が、すでに仮説です。
「価格だけでなく出来高も必要」と考えるのか。
「OI変化を伴う方が意味がある」と考えるのか。
「spreadが広すぎるイベントは除外する」と考えるのか。
「ETF regular session中だけ見る」と考えるのか。
「CME休場中はCME leadを使わない」と考えるのか。
これは、データから自動で決まるものではありません。
市場構造への理解と、自分のbotで取れる可能性を踏まえて、自分で決める必要があります。
時間窓も仮説である
時間窓もかなり重要です。
リードラグ研究では、どの時間軸で見るかによって、ほとんど別の研究になります。
10秒 30秒 60秒 180秒 300秒 1時間 6時間 24時間
これらは同じ「リードラグ」ではありません。
10秒〜60秒の反応を見るなら、かなり短期の価格追随や取引所間の反応速度を見ています。
180秒〜300秒を見るなら、少し遅れた価格調整や国内市場側の反応を見ています。
1時間〜6時間を見るなら、単純な価格追随というより、資本配分、建玉変化、funding、ポジション調整、DeFi側の状態変化などが絡んできます。
なので、時間窓は適当に置くものではありません。
もちろん、最初は複数のhorizonを並べて見るのはありです。
ただし、最終的には、
なぜこのhorizonを見るのか このhorizonで取れる可能性があるのか このhorizonだと別要因が混ざりすぎないか 自分の注文速度・コスト・運用負荷に合っているか
を説明する必要があります。
これは、proxyの計算ではなく、研究判断です。
閾値も仮説である
閾値も同じです。
たとえば、
lead_abs_return_bps_300s >= 4bps volume_zscore >= 2 oi_change_zscore >= 2 spread_bps <= threshold
のような条件を置くとします。
コード上は簡単です。
しかし、
なぜ4bpsなのか なぜzscore 2なのか なぜ300秒なのか なぜspreadの閾値をここに置くのか
は、自分で説明する必要があります。
もちろん、最初から完璧に説明できなくてもいいです。
探索段階なら、暫定閾値で構いません。
ただし、その場合は、
これは探索用の仮定であり、最適化済みの閾値ではない
と明記しておく必要があります。
ここを曖昧にすると、あとで過去データにだけ合った閾値を「構造」と勘違いしやすくなります。
仮説として組むべき問い
明日以降、実装や検証に戻るときは、次のような問いを自分で組む必要があります。
1. どのリード市場の変化を見るのか 2. その市場の変化は、何を代表していると考えるのか 3. その変化は、どのラグ市場に伝播すると考えるのか 4. どの時間窓で反応を見るのか 5. 反応は価格追随なのか、residual decayなのか、activity responseなのか 6. その反応は、コスト控除後に取れる可能性があるのか7. どの条件なら、その仮説を弱める・保留する・切るのか
これは、単に「proxyを作る」よりも一段上の作業です。
代理変数をいくら増やしても、この問いがなければ研究にはなりません。
逆に、この問いがはっきりしていれば、最初のproxyは粗くてもいい。
必要なものだけを追加すればよくなります。
AIやコードに任せてよい部分と、任せすぎてはいけない部分
今回の整理で、ここもかなり明確になりました。
AIやコードに任せてよいのは、主に次の部分です。
取得できているデータの棚卸し proxy候補の列挙 特徴量計算の実装案 event studyの集計 可視化 異常値チェック 表現の整理
一方で、任せすぎてはいけないのは、次の部分です。
どの市場構造を見に行くのか どのproxyを主軸に置くのか なぜその時間軸を見るのか 何を反証条件にするのか どこから売買候補に進めるのか どこで切るのか
ここは、自分の判断として握る必要があります。
特に、AIはそれっぽい原因ラベルや、それっぽい仮説名を作るのが得意です。
だからこそ、今回のように、
原因ラベルではなく、観測ラベルから始める
というルールを持っておくことが大事になります。
実務に戻すなら、最初は小さくていい
明日以降に実装へ戻すなら、いきなり大きな仮説を立てなくてもいいと思っています。
たとえば、まずはかなり小さく、
Binance Global側で一定以上の価格変化が起きたとき、 Binance Japan側の60秒・180秒・300秒後のfollowとnet EVを見る
でもいい。
あるいは、
Hyperliquid側でOIが大きく変化したとき、 Ethena regime別にactivity / funding / volumeの反応が変わるかを見る
でもいい。
または、
ETF regular session中だけ、 ETF価格変化やpremium変化とBinance Japan側のresidual変化を見る
でもいい。
大事なのは、問いを小さくして、
何を見たのか 何が出たのか 何は出なかったのか 次に何を変えるのか
を記録できる形にすることです。
仮説を大きくしすぎると、代理変数も増えすぎます。
最初は、小さい問いに対して、少数のproxyを当てる。
その結果を見て、必要ならproxyを増やす。
この順番が、今の自分には合っていると思います。
今回の整理で見えてきたのは、代理変数は「判断を自動化する道具」ではないということです。
むしろ、
自分が組んだ仮説を、観測可能な変化に分解し、検証可能な形にするための道具
です。
だからこそ、最後に残るのは、自分で問いを立てる力です。
どの市場を見るのか。
何を変化と呼ぶのか。
どの時間軸で見るのか。
何が出たら進めるのか。
何が出なければ切るのか。
ここはコードではなく、自分の研究判断として持つ必要があります。
7. 今日時点のまとめ：代理変数は、見えないものを決め打ちしないための道具
今日の整理で一番大きかったのは、代理変数を「見えない原因を当てるためのもの」としてではなく、「観測可能な変化を検証可能な形にするためのもの」として捉え直したことです。
市場には、見えるものと見えないものがあります。
価格、出来高、板、スプレッド、OI、funding、basis、premium、residual などは、データとして取得できる可能性があります。
一方で、大口顧客のポジション変更、マーケットメーカーの在庫、裁定参加者の判断、APの裁定判断、ヘッジャーのリスク移転、制度参加者の意図などは、外側から直接見ることはできません。
だからこそ、見えないものをいきなり原因ラベルとして扱わない。
まずは、見えている変化を定義する。
価格が動いた出来高が増えた OIが変化した basisが動いた spreadが広がった depthが薄くなった residualが変化した
このような観測可能な変化を、事実ベースでラベル化する。
そのうえで、その変化がラグ市場の follow、residual decay、net EV にどう接続するかを見る。
これが、今日時点での一番大事な整理です。
今後の実装では、large_customer_flow や mm_withdrawal や ap_arbitrage_failed のような原因ラベルを先に作るのではなく、lead_return_event、lead_volume_spike_event、lead_oi_change_event、lead_spread_widening_event、lag_residual_decay_event のような観測ラベルから始める。
その方が、観測機が出している事実と、自分の解釈を分けやすくなります。
もちろん、原因について考えないわけではありません。
むしろ、なぜその変化が起きたのか、誰がどの制約の中で動いたのか、どの市場にどう伝播するのかを考えることは重要です。
ただし、それは観測ラベルとは別のレイヤーに置く。
まずはデータとして見える変化を定義する。
次に、その変化のあとに何が起きるかを見る。
最後に、その結果をもとに、原因仮説や市場構造の解釈を深める。
この順番を守ることで、代理変数をそれっぽい物語ではなく、実務の検証に接続しやすくなると思っています。
明日以降やることは、そこまで大きくありません。
まずは、既存の観測機で取得できているデータを棚卸しする。
次に、それらを
price_change activity_change positioning_change liquidity_change distortion_change time_structure_change
に分ける。
そして、各分類につき少数のproxyを作り、リード側の変化がラグ側の follow / residual decay / net EV に接続するかを見る。
最初から高解像度の原因分類を作る必要はありません。
むしろ、最初は粗くていい。
ただし、粗いまま原因を決め打ちしない。
見えている変化を丁寧に名前にして、それが本当にラグ市場の反応や執行可能性に繋がっているかを確認する。
今日の整理は、開発フェーズに戻るための最初の足場としては、かなり良い位置にあると思います。
それでは、また。