初回ACTIVE runを正式完走｜ボートレースAIは継続検証の段階へ｜開発日記⑨

前回は、ボートレースAIをSHADOW運用から正式なACTIVE運用へ移すまでに、何度もNO-GO判断を重ねた経緯を書きました。

今回は、その後に行われた初回ACTIVE runについてです。

結論からいうと、AIの予想処理だけではなく、判定後の記録・結果確認・払戻確認・評価・KPI反映までを、正式な運用経路で完走できました。

ただし、これは「AIの性能が証明された」という話ではありません。予想モデルの検証は、まだ継続中です。

今回確認できたのは、決めた時刻に処理し、後から都合よく結果を追加せず、その時点の判断と結果を残せる運用になったことです。

ACTIVE運用とは何か

このブログでいうACTIVE運用は、単にAIを動かすことではありません。

あらかじめ決めた条件に従って、対象レースを選び、正式な判定時刻に情報を取得し、PURCHASEまたはSKIPを記録します。そして処理内容を保存し、レース後に結果と払戻を確認したうえで、評価結果をKPIへ反映します。

以前の段階では、処理が動いても「その判断は本当に締切前の情報だけで行われたのか」「記録は残ったのか」「失敗時に安全に止まれるのか」といった確認が必要でした。

そのため、いきなり正式運用へ進めず、SHADOW運用で自然起動と監査を繰り返してきました。

初回ACTIVE runでは、登録済みのLaunchAgentによる自然起動を正式経路として使用しました。

手動でexecutorを起動したり、後からAgentを動かしたり、レース結果を見てからproduction decisionを書き込んだりはしていません。

確認できた流れは次のとおりです。

ここで大切なのは、途中のどこかだけが成功したのではなく、判定から評価までの記録がつながったことです。

AI予想では、予想そのものに目が向きがちです。ですが、運用面が曖昧なままでは、あとから検証できません。

「いつ」「どの情報で」「どう判断したか」を残せることが、継続して検証するための前提になります。

初回ACTIVE runを完走できたからといって、短期間の結果だけでAIの精度を判断することはできません。

ボートレースは1レースごとの結果の振れ幅が大きく、少数の的中・不的中だけで結論を出すと、実力以上にも以下にも見えてしまいます。

そのため現在は、判定と結果を継続して蓄積し、未評価のrunを残したままにしないことを優先しています。PURCHASEだけでなくSKIPも同じように記録し、後付けの判断を混ぜません。

まずは同じ条件で運用を続け、結果がそろった時点であらためて検証します。

現在は、正式campaignをACTIVEとして運用しています。

一方で、正式判定直前の安全性を高めるためのprelaunch改善は、source側で受け入れ済みでも、本番runtimeにはまだ反映していません。

改善内容があるからといって、ACTIVE運用中のruntimeをすぐ差し替えるのは危険です。本番処理では、動作中のものを変えること自体が新しい不確実性になります。

そのため、runtimeへの反映は本番run当日を避け、manifest確認や事前検証を済ませたうえで、別工程として進めます。

少し遠回りに見えるかもしれませんが、「改善したい」と「今動いている処理を安全に守る」は分けて考えるようにしています。

ACTIVE運用に移行したことで、開発は終わりではありません。

これからは、自然runを積み重ねながら、結果・払戻・評価を正しくそろえ、Forward実績として検証できる状態を作っていきます。

次の課題は、未評価runの処理、自然run後のREAD ONLY監査、prelaunch改善の正式反映、古いrace-specific Agentの整理です。

どれも派手な機能追加ではありません。でも、AIを「たまたま動いた仕組み」で終わらせず、あとから検証できる運用にするためには欠かせない作業です。

引き続き、後付けでごまかさず、安全に停止しながら原因を確認し、少しずつ改善を続けます。