🗄️ 歴史的文書(アーカイブ) — この文書は過去の研究フェーズの記録であり、現在の結論・手法を反映していません。現在の研究状況は解説セクションを参照してください。

このシリーズは未完の下書き(draft)のまま凍結されています。

03. Strategy Design

本ページは Phase 3 の戦略設計レポート research_reports/phase3_strategy_design.md を整理したもの。 コストモデル前提は 00-introduction.md、利用可能なデータは 01-data-landscape.md、既存戦略の現状性能と見つかったギャップは 02-baseline-audit.md を参照。

設計のみのフェーズ。コード変更なし。各仕様は src/atc/strategies/base.py / src/atc/execution/execution_manager.py / src/atc/cli/backtest.py（limit プレースメント、セッション・クローズ、06:00 carry）/ src/atc/features/feature_engine.py を前提として記述。

1. 設計原則（要約）

1. デフォルトは passive maker（コードベースが強制）。_build_limit_price は BUY を bid、SELL を ask に置く。各戦略の指値位置と「フィルが起きる前提」を明記する。
2. Aggressive fill は mid-offset limit で実現。マーケット注文を導入せずに、mid ± k·tick を指値にすることで実質マーケッタブルにする。
3. 零手数料の活用。fee_bps=0 下では turnover はほぼフリー。摩擦は adverse selection と 保有コスト に集約される。
4. Carry-awareness は設計パラメータ。各仕様で「期待ホールド時間」「5 ETH × 500k mid での 1 trade carry」「requires_session_close」を明示。
5. 長短対称をデフォルト。非対称は明示的に正当化する。
6. Deterministic & testable。各シグナル経路を擬似コードで書き、ユニット・テスタブルな不変量をリスト化。
7. min_order_interval_sec は 300s がデフォルト。サブミニッツ戦略は CLI で下げる必要あり（PM 注意点）。

2. 優先度ランキング（PM ビルド・オーダー）

「コストモデル下での勝ちやすさ」=（期待エッジ）×（既存インフラの準備度）×（実装コストの逆数）で序列化。トップ 3 は近期実装、残りはフェーズ 2。

#	Registry key	ファミリ	一文要約
1	sweep_counter_fade	short-horizon fade	既存 baseline_sweep_follow の対称版。エンジン既出特徴量のみ使用、サブミニッツ・ホールド（carry ゼロ）+ 零手数料 → 最速の credible alpha。
2	imbalance_momentum_micro	medium-horizon	既存 ob_imbalance_top5 + trade_imbalance_1s + logret_Ns を timed-stop と組み合わせ。baseline_queue_imbalance_breakout の失敗モード（single-event、no exit、qty=0.02）を直接修正、flat-by-06:00 で carry ≈ 0。
3	mm_zero_fee_inside_spread	short-horizon MM	零手数料下で両建て quoting は adverse selection を抑えれば構造的にプラス。データは揃っているが quoter シェル（新しい注文タイプ動作）が必要なため複雑性で 3 位。期待値は最大級。
4	latency_arb_ticker_trade	short-horizon HFT	Ticker と trade の recv_ts_utc vs exchange_ts_utc を利用。理論エッジは高いが Postgres ストリーム・テーブルの recv 精度に依存（PM 確認事項）。
5	multiday_trend_carry_aware	long-horizon	唯一 carry を受け入れる戦略。ETH ボラ > 年率 carry を根拠にする。日次/時次バー（既に ingest_binance_klines.py / ingest_multi_exchange_jpy_prices.py で取得）と「entry 時に edge > carry を確認するゲート」が必須。
6	queue_position_mm_joining	short-horizon MM	MM ファミリで理論エッジ最大（零手数料下で純粋に P(fill) × edge の数学）。ただしスナップショットでなく book diff が必要 — データ・パイプライン・ギャップ。設計のみ収録、ビルドはブロック中。

3. 戦略別 3 行スペック

各戦略のフルスペック（state 変数、擬似コード、パラメータ、WF グリッド、テスト計画、PM 決定事項）は元レポートを参照。ここでは要約のみ。

3.1 sweep_counter_fade

• タグライン: 大口の片側アグレッサ・パルスを検知し、反対側に passive limit を置いて数秒〜1 分で fade。零手数料がキャンセル・コストをほぼゼロにする。
• ホールド時間: 10〜45 秒（FADE_HOLD_MAX_SEC デフォルト 45s）。1 trade あたりの carry ≈ ¥0.52。
• requires_session_close: False（intra-minute で常時フラット）。

3.2 imbalance_momentum_micro

• タグライン: マルチスケール OB imbalance と直近アグレッサ・フローが方向で一致したとき、timed stop と reversal cut を備えて分単位ホールド。Carry は日次フラット・クローズで制御。
• ホールド時間: 1〜6 分（MAX_HOLD_SEC デフォルト 360s）。1 セッション 10 trade で carry ≈ ¥417。
• requires_session_close: True（稀に late-session entry が 06:00 を跨ぐ可能性、フラット・クローズが安価な保険）。

3.3 mm_zero_fee_inside_spread

• タグライン: スプレッドが 2·tick を超えるとき、top-of-book の 1 ティック内側で連続両建て quoting。在庫スキューと pull-on-flow による adverse-selection ガード付き。零手数料下では uncontested fill すべてが正期待値。
• ホールド時間: 在庫の turnover は秒スケール。在庫平均は 0 近辺、最悪でも ±5 ETH 上限。
• requires_session_close: True（衛生のため。cancel_both + target=0 が既存ラダーと整合）。

3.4 latency_arb_ticker_trade

• タグライン: Trade が quoted bid-ask の内側にプリントされた瞬間（ticker が book に追いついていない）、stale 側に limit を置いて次の trade で fill する。
• ホールド時間: 0.5〜2 秒。1 trade あたりの carry ≈ ¥0.02。
• requires_session_close: False（決して保有しない）。

3.5 multiday_trend_carry_aware

• タグライン: 1h/4h バー上の長期方向性トレンド・フォロー。「edge が carry を超える」エントリー・ゲートを明示。1〜5 日保有、シグナル信頼度に応じてサイジング。
• ホールド時間: 期待 3 日（EXPECTED_HOLD_DAYS=3）。フル・サイズで 1 trade あたり carry ≈ ¥3,000。Entry エッジを ≥ 4 × carry_bps に設定し ~3 倍の安全率を確保。
• requires_session_close: False（carry を意図的に受け入れる戦略。flat-by-06:00 はこの戦略の前提を破壊する）。

3.6 queue_position_mm_joining

• タグライン: 「真の passive」MM。深い側のキュー末尾に並び、stochastic に fill されるのを待ち、imbalance reversal で exit。零手数料下でキャンセルは無料。
• ホールド時間: 10〜120 秒（JOIN_MAX_HOLD_SEC デフォルト 120s）。Carry は無視可能。
• requires_session_close: True。ただしビルドはブロック中（per-message book diff が必要、現状はスナップショットのみ）。

4. 特徴量カタログ（トップ）

凡例: [E] = FeatureEngine ですでに emit。[R] = rolling-window 派生、追加容易。[O] = ≥ top-10 オーダーブック・スナップショット必要。[D] = book diff 必要。[B] = bar 集計（hourly/daily）。[X] = 外部データ。

Feature	Status	説明	利用戦略
mid / bid / ask / last / spread / spread_bps	[E]	基本 book 状態	全戦略
logret_1s / logret_5s / logret_30s	[E]	3 スケールの log return	short / medium
rv_5s / rv_30s	[E]	2 スケールの実現ボラ	short / medium
trade_count_1s / trade_vol_1s	[E]	Trade 強度（1s）	sweep_counter_fade、mm、imbalance_momentum_micro
trade_imbalance_1s	[E]	Signed aggressor flow（1s）	全 short / medium
ob_imbalance_top1 / ob_imbalance_top5	[E]	L1 / L5 board imbalance	imbalance_momentum_micro、mm、queue_position_mm
depth_bid_top5 / depth_ask_top5	[E]	top-5 累積デプス	queue_position_mm、mm
microprice	[E]	size-weighted top-1	mm_zero_fee_inside_spread
logret_1h / logret_4h / logret_24h	[B]	時間/4 時間/日次 return	multiday_trend_carry_aware
rv_1h / rv_24h	[B]	バー単位の実現ボラ	multiday_trend_carry_aware
ema_24h_mid / ema_96h_mid	[B]	長期 EMA	multiday_trend_carry_aware
funding_rate_1h	[X]	パペチュアル funding rate	multiday_trend_carry_aware
ob_imbalance_top10	[O]	L10 board imbalance	imbalance_momentum_micro
trade_imbalance_5s / trade_imbalance_30s	[R]	より長い窓の signed flow	imbalance_momentum_micro
trade_vol_signed_1s	[R]	Signed size（buy_vol − sell_vol）	sweep_counter_fade
aggressor_vol_burst_5s_z	[R]	5s signed vol の z-score	sweep_counter_fade
ob_imbalance_ema_5s	[R]	EMA-smoothed top-5 imbalance	imbalance_momentum_micro
ticker_age_ms	[R]	直近 TICKER からの ms	latency_arb_ticker_trade
trade_inside_spread_flag	[R]	trade が ticker bid-ask の内側に出たか	latency_arb_ticker_trade
signed_aggressor_vol_500ms	[R]	直近 500ms の signed trade volume	mm_zero_fee_inside_spread
quote_update_rate_1s	[R]	直近 1s の TICKER events/sec	mm_zero_fee_inside_spread
queue_position_estimate_{bid,ask}	[D]	top-of-book でのキュー内位置	queue_position_mm_joining
queue_depletion_rate_{bid,ask}	[D]	top-of-book で消費される ETH/sec	queue_position_mm_joining

特徴量作業の優先順序（戦略アンロック数の多い順）:

1. trade_imbalance_5s、trade_imbalance_30s、trade_vol_signed_1s（[R]）→ unlock imbalance_momentum_micro、sweep_counter_fade。~0.5 日。
2. ob_imbalance_top10、ob_imbalance_ema_5s（[O]、[R]）→ unlock imbalance_momentum_micro。~0.5 日。
3. ticker_age_ms、trade_inside_spread_flag（[R]）→ unlock latency_arb_ticker_trade。~0.5 日。recv_ts_utc 精度確認が必須。
4. signed_aggressor_vol_500ms、quote_update_rate_1s（[R]）→ unlock mm_zero_fee_inside_spread。~0.5 日。
5. Hourly bar 特徴量 + funding-rate join（[B]、[X]）→ unlock multiday_trend_carry_aware。~1 日（インフラ作業）。
6. Book-diff queue-position 特徴量（[D]）→ unlock queue_position_mm_joining。ブロック中、見積もり 1〜2 週間。

5. ポジション・サイジング・モード・マトリクス

ベースラインは 5 ETH、ハード・キャップは ±7.5 ETH（src/atc/risk/ のリスク・ポリシー）。

Strategy	モード	根拠
sweep_counter_fade	(a) Fixed 5 ETH	トリガが二値、信頼度の信頼できる尺度なし
imbalance_momentum_micro	(b) Signal-confidence × max 5 ETH	スケール 0.4→1.0、confidence_scale(imb5, imb_tr_5s) 由来。imbalance 強度は期待移動幅と相関
mm_zero_fee_inside_spread	(c) Scale-in / inventory-skewed ladder	サイズは `
latency_arb_ticker_trade	(a) Fixed 5 ETH	トリガが二値（stale ticker present / not）
multiday_trend_carry_aware	(b) Signal-confidence × max 5 ETH、floor 1 ETH + (c) 2-bar ladder（50/50）	Carry コストはサイズに線形なので、エッジ弱いときは縮める。Ladder は single-bar false-start 防止
queue_position_mm_joining	(a) Fixed 5 ETH	Join-the-queue は二値

6. PM 解決事項（コンフリクト・確認事項リスト）

オリジナル・レポート §5 より。実装着手前に PM の判断が必要な項目。

1. Multi-leg intent schema: mm_zero_fee_inside_spread は 1 イベントで 2 つの limit（bid + ask）を出す必要がある。TargetPositionIntent を list[IntentLeg] に拡張するか、片側交互で代替するか。
2. Limit-price プレースメント・フック: _build_limit_price（cli/backtest.py:1048）は戦略不可知（BUY-at-bid、SELL-at-ask）。sweep_counter_fade / imbalance_momentum_micro / latency_arb_ticker_trade は mid-offset aggressive プレースメントを欲する。limit_offset_bps フィールドの追加提案。
3. min_order_interval_sec のデフォルト 300s: サブミニッツ戦略を全滅させる。Per-strategy 属性化（最善）か、新戦略実行時に常に --min-order-interval-sec 5 を渡すか。新 6 戦略はすべて per-strategy オーバーライド前提。
4. market_stream_* の recv_ts_utc 精度: latency_arb_ticker_trade は recv_ts が WS 受信時に取られていることが前提。src/atc/data/stream_service.py の確認、必要なら WS 側のタイムスタンプ列追加。
5. market_stream_orderbooks の ≥10 レベル・スナップショット: ob_imbalance_top10 必須。bids_jsonb / asks_jsonb が 2026-02-17 以降を通じて 10 レベル以上を捕捉していることを検証（01-data-landscape.md では 30 レベル捕捉が確認済み — OK）。
6. Book-diff パイプライン: queue_position_mm_joining は per-message book diff がないとブロック。フェーズ 3 のスコープ内か、フェーズ 4 に持ち越すか。
7. mm_zero_fee_inside_spread の carry 計上粒度: 06:00 JST 時点の position に対してのみ課金。境界で在庫ゼロ・残り 90% は +2 ETH のような場合 carry ゼロでよいか（仕様としては Yes だが MM の会計として要確認）。
8. Funding-rate データの利用可否: multiday_trend_carry_aware は funding_rate_close を任意ガードとして使う。experimental_funding_rate のみでなく、特徴量スナップショットから露出しているかを確認。
9. 3 日ホライズンのエッジ・キャリブレーション: MIN_TREND_SCORE_FOR_ENTRY = 0.75 のデフォルトはベスト推測。2021〜2024 のバックテストで carry 控除後 > 0 を確認。NG なら閾値引き上げ。
10. Registry-key 命名: mm_zero_fee_inside_spread と queue_position_mm_joining は baseline_inventory_mm と機能領域が重複。src/atc/strategies/registry.py での命名と baseline_inventory_mm を deprecate するかを確認。

関連ページ

• 00-introduction.md — プロジェクト前提・コストモデル
• 01-data-landscape.md — データ在庫・期間カバレッジ
• 02-baseline-audit.md — 既存戦略の現状性能・ギャップ分析