【要約】防御ルールを足したら 100% reject になった日、効いてるのか壊れてるのか区別する話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、Raspberry Pi 5で稼働する自動売買システムに新しい防御ルールを導入した際、全件拒否が発生して正当性が判断できなくなる問題に直面した。具体的には以下の課題が生じた。
- ・拒否ログには「拒否した事実」しか残らず、「拒否されなかった場合の予測結果」が欠落している。
- ・「市場が悪条件で正しく弾いた」のか「計算式が誤っていて過剰に弾いた」のかの区別がつかない。
- ・ログの解釈が、後出しの主観や「都合の良い解釈」に流されるリスクがある。
// Approach
開発者は、判定の正当性を検証するため、本番の判定パイプラインとは分離した「仮想的な結果記録」と「シャドウモード」を採用した。
- ・Virtual PnL ledgerを構築し、拒否された候補が「もし実行されていたらどうなっていたか」を事後データ（当日終値）で記録する。
- ・「発火率」と「仮想的な勝率」を用いた2x2のマトリクスを事前に定義し、判断基準を客観化する。
- ・不具合の疑いがある場合でも即座にルールを削除せず、shadow_rejectフラグを用いて、本番への影響をゼロに抑えつつ分布データを収集する。
// Result
開発者は、防御ルールの品質を、本番の損益を毀損することなく定量的に評価できる体制を構築した。
- ・全件拒否が発生した際も、シャドウデータから「しきい値の妥当性」を統計的に導き出せるようになった。
- ・「RR < 1.0」を「RR < 0.6」へ調整するといった、データに基づいた具体的なパラメータ最適化が可能になった。
- ・この手法は、レートリミットやサーキットブレーカー等の汎用的な防御機構にも適用できることが示された。
Senior Engineer Insight
> 防御機構の設計において、最も危険なのは「発火した事実」のみを観測することだ。本番環境のメトリクスは、防御が「成功」したのか「過剰反応」したのかを区別できない。本記事が示す「反事実的な検証パイプライン」の構築は、運用コストを多少犠牲にしても、システムの信頼性を担保するために必須の投資である。特に、レートリミットやフィーチャーフラグの運用において、この「シャドウ化による分布収集」のプロセスを標準化すべきだ。