研究はゆっくりでよくても、取引の執行はそうはいきません。下すべきでない 1 件の注文を承認したのが、まさに人であることもあります。誰が止めるのでしょうか。
執行の規律を、人の自覚ではなくフロー内の硬いゲートにします。場中に定時で市場状態を再計算し、状態が反転すれば当日の執行待ち注文を自動で遮断します。重要なアクションにはさらに CIO 署名ゲートを 1 段加えます。署名のない変更は本番に届かず、口頭の却下も執行層まで伝わらなければなりません。
定時リマインダーが駆動して場中にタイミング指標を再計算し、状態が反転すれば執行待ち注文を遮断して根拠を示します。
執行前の最後の署名。否とは言えても迂回はされない。却下は必ず執行層の設定に落とします。
2 つのゲートを通った注文だけを執行し、全工程を監査の痕跡に残します。
人が寄り付き前の計画に沿って当日の候補買いを承認します。
定時リマインダーが駆動して @リスクゲート が場中に市場状態を再計算し、指標の反転を検知します。
当日すでに承認済みの買いが自動で止められ、根拠が示されます。当日は相場が弱含み、遮断の正しさが証明され、人は全工程で介入ゼロでした。
「口頭の却下が執行層に伝わっていなかった」プロセス事故のあと、チームは数分で 3 層の CIO 署名ゲートを作りました。
署名ゲートの稼働 3 日後の初実戦。「大きく含み益の出た保有を売り、低スコアの新銘柄に入れ替える」入替注文をデフォルトで止め、たどっていくとさらに 2 か所のトリガー定義の欠陥を見つけ、最終的に人が判断してこの機能を丸ごと止めました。
取引日の場中に定点で市場状態を再計算し、反転すれば遮断します。
遮断ごとに自動でタスク化。当日の引け後に遮断の是非を検証します。
執行層の設定と意思決定の台帳が一致するか定期的に確認し、「口頭ルール」のドリフトを防ぎます。
「承認の有効期限」を注文の構造に書き込む。人が覚えているのに頼るのではなく、期限切れで自動失効させる。
遮断に誤遮断の統計を作る。ゲートがきつすぎても緩すぎても、データで語らせる。
重要機能の停止は「物理削除 + 再発防止チェック」で行い、コメントアウトで済ませない。