【要約】ATR 損切り幅が予算を超える注文を pre-trade で reject する設計 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
個人開発者が自作の自動売買ボットを運用する中で、ATRが極端に大きい銘柄に対し、リスク管理が機能しないリスクに直面した。既存のロジックでは、損切り幅が予算を大幅に超える場合、株数が0となり発注がスキップされるだけであった。これにより、以下の課題が生じていた。
- ・拒否理由がログに残らず、機会損失か防御かを判別できない。
- ・「なぜ買わなかったのか」の振り返りに、手動での板確認が必要となる。
- ・戦略の設計ミスか、リスク管理の実装ミスかの切り分けが困難である。
// Approach
発注直前のプロセスに、物理的な発注可否を判定する「pre-trade physical execution feasibility check」を導入した。単なる数値チェックではなく、後続の分析を容易にするための構造化がなされている。
- ・
FeasibilityResultクラスを用い、成否・理由・詳細指標を構造化する。 - ・「最小ロットでも予算超過」と「計算株数が予算超過」を理由別に分離する。
- ・ロット単位（100株等）の整合性チェックを発注ゲートに集約する。
- ・拒否理由とメトリクスを構造化ログとして出力し、事後集計を可能にする。
// Result
拒否理由が明確になったことで、運用データの分析精度が大幅に向上した。システムが「何もしなかった」理由をデータとして扱えるようになったため、以下の成果が得られた。
- ・「機会損失」と「リスク防御」を、理由別に集計・分類できる。
- ・ATRによる拒否銘柄の事後検証を通じ、戦略の妥当性を評価できる。
- ・サイザ（株数計算）の実装ミスや、予算設定の矛盾を早期に検知できる。
Senior Engineer Insight
> 本設計の真価は、単なるエラー防止ではなく、オブザーバビリティの向上にある。システムが「何もしなかった」理由を構造化データとして残すことで、戦略の改善サイクルを高速化している。これは、大規模システムにおける「サイレント・フェイailure」を防ぐ極めて重要なアプローチだ。ただし、ボラティリティを収益源とする戦略では、このガードが過剰なフィルタリングとなるため、戦略設計との整合性を常に意識すべきである。