Table of Contents
これまでの研究開発の結果、ひとつの到達点には到達できたと考えている。
それは、現モデルの 「Avg 2~ pips/trade」 というエッジだ。
これは、十分に良いパフォーマンスであり、これ以上の数値を無理に追い求める必要はないと考えている。
むしろ重要なのは、「このエッジを壊さずに、長期間維持できるか」である。
目標は、Avg 2~ pips/trade × 1000~ trades
短期的な上下ではなく、大数の中でエッジを再現し続けることだ。
研究フェーズから、運用フェーズへ移行する段階に来ている。
レジーム・データ分布の変質に対して
ライブ運用では、バックテスト通りに進まない可能性がある。
Validation（バックテスト）と、リアル Forward の結果には、一定の乖離が生じることを前提に考える。
短期的なノイズに惑わされず、長期で評価する。
運用基準
- Validationと、ライブのForwardの評価乖離率が 40~100% の範囲ならオントラック
- 1日・1週間単位では判断しない
- 200回、500回、1000回単位で評価する
監視する指標：
- Avg pips/trade
- TP rate
- トレード数
- Prediction出力のヒストグラム分布
対処
毎週末に、データ集計と評価を行う。
この1、2週の分布は、どのように違ったのか、同じだったのか。
- TP可能区間率、SL区間率
- ボラティリティー
- レジーム
- イベント有り無し
また、マーケット変化に緩く追従するため、毎週ローリングでモデル更新を行う。
- その週のデータを学習データへ追加
- モデル再学習
- 現行の15個モデルから、1つだけを入れ替える
モデルを急激に変えるのではなく、緩やかに追従させることを重視する。
異常時の対処
急変相場、異常相場では、ポジションを縮小する。
これは、自動ではなく手動運用としている。異常時は、機械ではなく人間が判断する。
スマホ・PCから、エントリーポジション数を即時変更できるようにしてある。
例えば、2026/05 の為替介入局面のように、明らかに危険な期間では、ドル円 1,000通貨 に落として稼働させていた。
Buyシグナルがどれぐらい発生するか、データ取りを行うためだ。
レアイベントは、ある意味では「無かったこと」にしても良い。
ただし、未来でも同じ原則で再現可能な運用であることが前提になる。
そして、その影響が最終損益に大きく効くのであれば、それはもはや例外ではなく、システム仕様に含めるべき事象になる。
システムの堅牢性
リアル運用で、ほぼ稼働率100%、システム執行率100%を維持する。
Websocket切断、通信エラー、処理エラー時の自動復旧
この領域は、しっかりとシステムを作り込めている。
モデル改良について
運用フェーズに入った今においても、モデル改良を試したくなるが、むやみに改良を行うべきではない。
大きな変更は、現行のエッジそのものを壊す可能性がある。
Avg 2~ pips/trade を達成できている以上、今の焦点は「改善」ではなく、長期間堅持すること