前回の開発日記では、SHADOW運用で3回連続の正常runを確認し、正式Forward再開の最終段階まで進んだところまで紹介しました。
前回の記事：SHADOW安定運用3/3を達成｜ボートレースAIは正式Forward再開の最終確認へ｜開発日記⑦
ここまで来れば、あとはACTIVEへ切り替えるだけ。
そう思っていました。
でも実際には、ここからがかなり長かったです。
SAFE MISSING、古いAgentの整理、実行スケジュールの競合、KPI履歴の問題、正式entryの安全確認、承認条件の見直し、そしてMacのスリープによるSYSTEM_FAILURE。
何度も「今回は進めない」というNO-GO判定になりました。
それでも今回は、後から判定を作り直したり、都合よく本番扱いにしたりせず、安全停止して原因を確認し、問題を潰してから次へ進むという方針を最後まで崩しませんでした。
そして2026年9月10日、ようやく正式ForwardをSHADOWからACTIVEへ移行しました。
SHADOW 3/3を達成しても、すぐACTIVEには進めなかった
SHADOWでは、自然起動から判定、保存、バックアップ、保存後の監査までを含めて3回連続で正常に完了することを確認しました。
これでSHADOW安定運用としては一区切りです。
ただし、SHADOWが安定したからといって、そのままACTIVEへ移行できるわけではありません。
ACTIVEになると、そのrunは正式ForwardのKPI対象になります。
そのため切り替え前には、過去のSHADOW結果が誤ってKPIへ混ざらないこと、ACTIVEの実績がrollback後も履歴として残ること、状態変更が正式な経路だけで行われることなどを確認する必要がありました。
予想できない日は、後から作らない
SHADOW運用中には、正式な判定時刻までに必要な直前情報が揃わない日もありました。
この場合、後からデータを取り直して予想を作ることはしません。
その時点で必要な情報がなければ、そのrunは成立させない。
この扱いをSAFE MISSINGとして整理しました。
SKIPは予想を作ったうえで購入条件に届かなかったケースですが、SAFE MISSINGは予想に必要な情報自体が揃っていない状態です。
この2つを混ぜず、後付け判定もしないことを正式運用のルールにしました。
古い自動実行設定を整理
過去の検証で生成したrace-specific Agentの中には、すでに役目を終えているものも残っていました。
将来、同じ条件で誤って起動する可能性を残したままACTIVEへ進むのは避けたいところです。
そこで、停止状態の確認、個別停止、未登録状態の確認、設定ファイルのハッシュ確認、archiveへの退避までを順番に実施しました。
単純に削除するのではなく、後から監査できるように証跡を残したまま、将来誤って起動しない状態へ整理しています。
Stage 5.6とStage 5.7が同じ時刻に起動
9月9日には、Stage 5.6 Dry-RunとStage 5.7が同じ06:30に起動する競合も見つかりました。
先にStage 5.6がlockを取得したため、Stage 5.7は安全停止。その結果、続くStage 5.8も停止しました。
データベースやForwardデータへの影響はありませんでした。
調査すると、すでに不要となっていたStage 5.6 Dry-Runの自動実行設定が残っていたことが原因でした。
対象を安全に停止・archiveし、次回以降の競合要因を解消しました。
ACTIVEの実績を正しく残すため、KPI履歴も修正
ACTIVE移行の隔離テストでは、別の問題も見つかりました。
ACTIVEで保存した実績が、campaignをCLOSEDにした後に既存KPI集計から見えなくなるケースです。
保存データそのものは残っていましたが、集計条件に現在のcampaign状態を見ている部分がありました。
これではrollbackした後に、過去の正式ACTIVE実績まで消えて見えてしまいます。
そこで、保存された時点でACTIVEだった正式runは、campaignをCLOSEDにした後もKPI履歴として残すように修正しました。
これにより、SHADOWはKPI対象外、ACTIVEはKPI対象、rollback後も過去ACTIVE実績は保持、後継SHADOWは再びKPI対象外、という境界を保てるようになりました。
SHADOWからACTIVEへ切り替える正式な入口も作った
もう一つ大きかったのが、SHADOWからACTIVEへ切り替えるための正式な入口です。
単純にデータベースの状態を書き換えるのではなく、人の承認、事前確認、バックアップ、transition履歴、切替後の検証までを一つの正式な操作として扱えるようにしました。
隔離環境では、SHADOWからACTIVEへ移行し、ACTIVE runを通し、必要ならCLOSEDへ戻して後継SHADOWへ移るところまで確認しました。
ここまで確認して、ようやく本番のACTIVE切り替えを行える状態になりました。
最後に起きたのは、MacのIdle Sleep
ACTIVE移行直前には、コードやデータベースではなく、運用環境側の問題も起きました。
9月6日の蒲郡12Rでは、自動実行そのものは正常に始まりました。
ところが、その後MacがIdle Sleepへ入り、予定していた処理開始時刻を超過。
システムは時間条件を満たさないと判断し、安全停止しました。
分類はSYSTEM_FAILUREです。
原因を調べると、Macを持ち出したことで普段と電源・スリープ条件が変わっていました。
そこでAC電源時のsleep設定を0へ変更。
その後の自然runでIdle Sleepが再発せず、予定どおりformal処理まで進むことを確認しました。
AIのロジックだけではなく、実際に動かすPCの電源管理まで本番運用の一部だと実感した出来事でした。
何度もNO-GOになったからこそ、そのまま進まなかった
SHADOW 3/3を達成してからACTIVEへ移るまでにも、かなり多くの問題が出ました。
- 必要な情報が揃わないSAFE MISSING
- 古いAgentの残存
- Stage 5.6 / 5.7の実行競合
- KPI履歴の集計問題
- ACTIVE切替用の正式entry整備
- 承認条件の再確認
- Idle SleepによるSYSTEM_FAILURE
そのたびに、条件を満たしていなければNO-GO。
原因が分からなければNO-GO。
対策後の確認ができていなければNO-GO。
このルールを崩さず、一つずつ原因を潰していきました。
2026年9月10日、正式ForwardをACTIVEへ
9月10日、ACTIVE移行前の最終確認を実施しました。
当日の自動処理がまだ始まっていないこと、不要なAgentやprocessが存在しないこと、データベースが正常であること、runtimeと管理情報が一致していること、MacがAC電源でスリープしない設定になっていることなどを確認しました。
すべての条件を満たしたため、最終判定はGO。
本番SHADOW→ACTIVE専用entryを一度だけ実行し、campaignはSHADOWからACTIVEへ正式に移行しました。
これで正式Forward ACTIVE運用を再開しました。
ACTIVEになったこと以上に、そこまでの過程が大きかった
結果だけを見れば、「SHADOWからACTIVEへ切り替えた」という話です。
でも実際には、その切り替えまでに多くの問題が見つかりました。
そのたびに無理に進めず、止める。確認する。原因を直す。そして、もう一度自然運用で確認する。
この繰り返しでした。
AI開発というと、予想精度やモデルの話に目が行きがちです。
しかし本番運用では、スケジュール、OSのスリープ、自動実行設定、lock、campaign状態、KPI、バックアップ、rollbackといった周辺の仕組みも同じくらい重要です。
今回のACTIVE移行は、そのことを強く実感した期間でした。
次回は、初回ACTIVE runの完走へ
ACTIVEへの切り替えは完了しました。
ただし、これで終わりではありません。
次に必要なのは、実際のnatural runで正式decisionが保存され、その後、公式result、payout、evaluation、KPI反映まで一連の本番経路が成立することです。
そして初回ACTIVE runでも、また新しい課題が見つかりました。
その続きは、次回の開発日記⑨でまとめます。
コメント