売買ロジックより先に停止条件を設計する、という方針について整理する。
問題意識
自動売買システムの設計では、エントリー条件（いつ買うか・売るか）から考え始めるのが自然に見える。しかし、この順序には問題があると考えている。
エントリーロジックは、失敗しても機会損失で済む。一方、停止の仕組みが欠けたシステムは、想定外の状況で損失を拡大し続ける。被害の非対称性を考えると、先に設計すべきは「動かし方」ではなく「止め方」である。
停止条件の分類
現時点では、停止条件を次の3層に分けて考えている。
層1: 技術的停止（システム異常）
- API エラーが一定回数連続した場合
- 取引所との接続が一定時間回復しない場合
- システムが把握するポジション・残高と取引所側の値の不整合を検出した場合
- 想定しない例外が発生した場合
この層の停止は「何かがおかしい。原因が分かるまで動かさない」という判断であり、無条件・即時であるべきだと考えている。
層2: 損失ベースの停止（リスク限界）
- 最大ドローダウンが事前に定めた閾値に達した場合
- 連敗数が事前に定めた閾値に達した場合
- 単一日の損失が事前に定めた閾値に達した場合
閾値は稼働開始前に固定し、稼働中に緩める変更は行わない。稼働中の閾値緩和は、損失を正当化したいという心理の現れである可能性が高いため、手続きとして禁止しておく。
層3: 前提崩壊による停止（環境変化）
- バックテスト時の前提（ボラティリティの範囲、スプレッドの水準など）から市場環境が大きく外れた場合
- 取引所の仕様変更、規制の変更があった場合
この層は自動検出が難しい項目を含むため、定期的な手動レビューと組み合わせる。
「停止」の定義
停止条件と同じくらい重要なのが、「停止」が具体的に何を指すかの定義である。少なくとも次を区別する必要がある。
- 新規停止 — 新規注文を止める。既存ポジションは維持。
- クローズ停止 — 新規を止め、既存ポジションを解消してフラットにする。
- 完全停止 — 未約定注文をすべてキャンセルし、プロセス自体を終了する。
どの停止条件がどの停止動作に対応するかを、実装前に表として固定しておく。これを曖昧にしたまま実装すると、「止まったはずなのにポジションが残っていた」という事故につながる。
検証方法
停止条件は、発火しないことを祈る仕組みではなく、発火することを確認済みの仕組みでなければならない。テストネット上で、各停止条件を意図的に発火させる試験を行う予定である。
- 異常系（層1）: API エラーの注入、接続の強制切断
- 損失系（層2）: 閾値を極端に低く設定し、通常の値動きで発火させる
この試験の結果は、実施後に別記事として記録する。
現時点の結論
停止条件・停止動作・その検証記録の3点が揃っていない状態を、このシステムの「未完成」と定義する。エントリーロジックの精度は、その後の課題である。