前回は、自動売買システムを本番稼働させた後の「日次運用設計」について解説し、Windows Updateや停電などによる物理的な「PCの再起動」は避けられない実務上のリスクであるとお伝えしました。
今回は【システム運用検証】の総仕上げとして、PCが再起動してもシステムが壊れない「リスタート設計」と「状態管理」の概念について、システム設計の観点から深く掘り下げていきます。
なぜ「再起動」で自動売買は壊れるのか？
Pythonで書かれた自動売買プログラムを動かしているとき、変数値（現在の価格、買った価格、保有数量など）はすべてPCの「メモリ（RAM）」上に一時的に記憶されています。
メモリは処理が非常に高速な反面、プログラムが終了したりPCが再起動したりすると、記録されていたデータが完全に消滅してしまうという弱点があります。
これが実運用において、どのような惨劇を引き起こすかを想像してみてください。
- システムが「5,000円で買い注文」を出し、無事に約定した。
- システムはメモリ上に「5,000円の保有ポジションがある」と記憶し、利確のタイミングを待っている。
- 【ここで不意のWindows強制再起動が発生】
- PCが立ち上がり、自動売買プログラムが再スタートする。
- システムはメモリが初期化されているため「5,000円で買った記憶」を完全に喪失している。
記憶を失ったシステムは、実際の証券口座には「5,000円で買ったポジション」が残っているにも関わらず、「現在保有ポジションなし」と勘違いし、再び5,000円で重複して買い注文を出そうとするか、あるいは保有しているポジションの利確を永遠に行わず放置してしまいます。
これは、自動売買システムにおいて非常に典型的な障害パターンです。
「途中状態」をどう扱うか（ステータスの概念）
この惨劇を防ぐためには、プログラムのメモリに頼るのではなく、システム外部（ファイルやデータベースなど）に「今、システムがどういう状態にあるか」を永続的に記録し続ける仕組みが必要です。
これが、これまでの連載で何度も重要性を説いてきた「状態管理」の正体です。
現物グリッドトレードのようなシステムでは、一つの取引が完了するまでに複数の「状態（ステータス）」を遷移します。
- 未処理： まだ注文を出していない
- 買注文中： 買い指値を出して、市場で待機している
- 保有中： 買いが約定し、利確のタイミングを待っている
- 売注文中： 利確の売り指値を出して、約定を待っている
実運用に耐えうるシステムは、約定ごと（あるいは注文ごと）に一意のIDを発行し（どの注文がどのポジションに対応しているかを識別するためのキー）、このステータスを外部ファイル等で厳密に追跡・更新し続ける設計になっています。
“復元できる設計”が実運用を分ける
状態管理が正しく実装されているシステムでは、PCがクラッシュして再起動した際の「最初の行動」が全く異なります。
プロが設計したシステムは、起動後すぐに市場の価格を見に行くことはしません。まず最初に「自分がクラッシュする直前に外部へ保存したステータス記録」を読み込み、実際の証券口座の残高や注文状況と照合して、失われた記憶を「復元」することから始めます。
「あ、クラッシュする前に5,000円で買った保有ポジションが1口あるな。じゃあ、その利確監視から処理を再開しよう」
このようにシステム自身が判断し、シームレスに途中から取引を再開できる構造（リスタート設計）になって初めて、長時間の安定した連続運用が可能になります。
【免責事項】
自動売買およびシステムトレードは利益を保証するものではなく、相場の急変やシステム障害・ネットワーク不具合などにより想定外の損失が発生する可能性があります。本記事の内容は検証および設計思想の考察を目的としたものであり、最終的な運用と投資判断は必ずご自身の責任で行ってください。
ここまでで、本シリーズで扱ってきた自動売買システムの基本設計である「目（データ取得）」「手（注文発注）」「脳（ループ監視と状態管理）」の全体像について検証してきました。
次回は本連載の最終回として、これらの全体設計を振り返りつつ、「自動売買システムを自作すべき人と、そうでない人の違い」について総括します。