PT/WFT Rust Migration Plan¶

Background¶

AEGIS のBTエンジンはRust化済みだが、PT(Paper Trading)/WFT(Walk-Forward Test)実行層はPythonのまま。将来的にRust化することで、実行速度・メモリ効率・戦略コードの一元管理が実現する。

タイミング¶

今ではない。 現在の優先事項: 1. 高VIX戦略の検証（Phase 3） 2. LT_RCの実資金運用安定化 3. 資本成長（$50K+でPT速度がボトルネックになった時）

移行アーキテクチャ: Record-Replay Shadow Mode¶

設計原則¶

API消費を二重化しない — Saxo/Polygon APIは1回だけ呼ぶ
並行検証期間を設ける — Python版が本番、Rust版がshadow（注文しない）
差分ゼロを確認してから切り替え

データフロー¶

Saxo API / Polygon API
       ↓
  Python PT（現行本番）
  ├─ 注文実行（Saxo multileg order）
  └─ データログ記録（JSONL/Parquet）
            ↓
       MarketSnapshot JSONL
            ↓
       Rust PT（shadow mode）
       ├─ entry/exit判定のみ
       └─ 判定結果をJSONL出力
            ↓
       差分レポート
       (Python判定 vs Rust判定)

実装ステップ¶

Phase A: データログ計装¶

Python PT の毎スキャンで MarketSnapshot 全体をJSONL記録
記録先: data/pt_replay_log/YYYY-MM-DD/scan_{N}.jsonl
LQS（Live Quote Sampler）が近い仕組みを持つ — 拡張して利用

Phase B: Rust Replay Engine¶

aegis-bt-rs の DayContext 構造にreplayデータを流し込むアダプタ
propose_entries() / check_exits() を呼び出し、結果をJSONL出力
BT engineの戦略コードをそのまま再利用（Rustの強み）

Phase C: 差分検証ツール¶

Python判定JSONL vs Rust判定JSONL を比較
差分項目: entry銘柄、exitタイミング、sizing、close_reason
許容差: 価格丸め誤差は±0.01まで許容。判定の一致/不一致は厳密

Phase D: Shadow並行稼働¶

Synology上でPython PT + Rust shadow を同時稼働
Rust版はDayContextをJSONLから読み、判定を記録
1週間差分ゼロを確認 → 本番切り替え

Phase E: 本番切り替え¶

Rust PT がSaxo APIを直接呼ぶ（Rust Saxo adapter実装）
Python PT を停止
Fallback: Rust版に問題があれば即Python版に戻せる（コンテナ切替のみ）

Codex/AI の活用¶

Golden Output Test生成: Codexに「Python PTのこのスキャン結果に対して、Rust版が同じ判定を返すテストを書け」と依頼
Saxo API adapter: Codexに既存Python adapter → Rust移植を依頼
差分検出: AIに差分レポートを分析させ、根本原因を特定

リスク¶

Saxo API adapter のRust実装が最も工数大（OAuth2, WebSocket, multileg order）
Python↔Rust間の浮動小数点精度差で偽陽性が出る
決算カレンダー等のPython依存データソースのRust対応

前提条件¶

BT Rustエンジンの戦略パリティが完了していること（現在進行中）
PT固有の機能（broker quality gate, drift detection, order management）の仕様が安定していること

参考¶

BT Python↔Rust パリティ: memory/project_rust_bt_parity.md
Saxo adapter: aegis_v3/aegis/broker/saxo/
LQS: aegis_v3/aegis/engine/live_quote_collector.py