前回は、エラーを直すのではなく「異常シグナルとして検知する」ための監視設計について解説しました。インフラも監視も整い、これでついに完全放置のシステムが完成した…と思いたいところですが、現実はそう甘くありません。
ここから先の領域は、Pythonのコードが正しいかどうかという次元の話ではなくなります。システムがどれほど完璧に動こうとも、「市場のルール（制約条件）」に反する注文を出せば、取引所や証券会社から容赦なく弾かれます。
今回は、実運用で避けては通れない「市場制約との戦い（注文制御）」について解説します。
第1の壁：値幅制限（ストップ高・ストップ安）の罠
日本株や国内ETFには、1日の価格変動を制限する「値幅制限（制限値幅）」が存在します。システムトレードにおいて、この制約は非常に厄介な罠となります。
例えば、事前に設定したグリッド（網目）に沿ってシステムが機械的に買い注文を並べるロジックを組んでいたとします。もし相場が急変動し、計算上の注文価格がその日の「ストップ高」や「ストップ安」の範囲を1円でも超えてしまった場合、その注文は市場ルールおよび証券会社APIの両方で拒否されます。
特にストップ高張り付きなどで価格レンジが極端に拘束された場合、システムが「本来出すべき売り注文」を出せずにエラーを連発し続けるループに陥る危険性があります。
これを防ぐためには、単に現在値を見るだけでなく、「毎朝APIからその日の基準値と値幅制限の上限・下限を取得し、計算された注文価格がレンジ内に収まっているかを出発前にフィルターする（事前制御する）」という高度なロジック設計が不可欠です。
第2の壁：口座凍結リスク「クロス取引」の回避
現物グリッドトレードのような「買い」と「売り」を同時に市場にばらまくシステムにおいて、絶対に回避しなければならないのが「クロス取引（自己売買）」です。
例えば、相場が上下に激しく動く追従型のレンジ相場において、以下のような事象が発生する可能性があります。
- 過去に下値で買った保有ポジションに対して「〇〇円での利確売り注文」を市場に出している。
- 同時に、現在の価格帯に基づくグリッドロジックが「〇〇円での新規買い注文」を算出した。
もし、自分のシステムが出した売り注文と買い注文が結果的に市場で対当可能な状態になった場合、これは意図しない自己売買リスク（仮装売買と誤認されうる状態：意図の有無に関わらず規制対象となり得る）を生む可能性があります。
これは相場操縦行為として金融商品取引法で厳しく規制されており、最悪の場合、証券口座を強制凍結される致命的なコンプライアンス違反となります。
「たまたま重なってしまった」という言い訳は通用しません。システムである以上、「新たに注文を出す前に、自分の現在の有効注文と保有ポジションの価格帯をすべて走査し、売りと買いが交錯（二重注文）する可能性があれば、その発注を意図的にスキップする」という自己防衛ロジックを必ず組み込む必要があります。
第3の壁：「約定前提」設計の否定
そして最後に、多くの開発者が陥るのが「注文を出せば、いずれ約定するはずだ」という思い込みです。
実際の市場では、板（オーダーブック）が薄くて注文の一部しか約定しない「部分約定」や、価格が飛んで不利な位置で成立する「スリッページ」、あるいは「板不在」による未約定の放置など、想定外の事態が常に発生します。
システムは「注文を出したこと」をゴールにするのではなく、「本当に約定したのか、何口約定したのか」をAPI経由で執拗に確認し、その事実を元に次の行動を決める「実態ベースの設計」でなければなりません。
ロジックの優位性より「防御力」が運用を決める
いかがでしたでしょうか。ストップ高の回避、クロス取引の防止、未約定のハンドリング。これらは利益を生み出すための「攻めのロジック」ではありません。しかし、この「守りの注文制御」が完璧に実装されていなければ、システムは数日と持たずに破綻します。
市場の制約を理解し、システムを堅守する設計思想。これが、真の自動売買システム構築における最大の壁と言えます。
さて、ここまで技術的・アーキテクチャ的な観点からシステムを強固にする方法を語り尽くしてきました。
しかし、どれだけ完璧なシステムを作り上げても、最後に残る「絶対に対策できないリスク」が一つだけ存在します。
次回は、自動売買における「属人性リスク」と、システムが止まったとき“誰が”止めるのかという緊急停止設計についてお話しします。