前回の記事では、
「Ver.1.0が得意なレースを判別したい。」
という考えにたどり着きました。
ロジックを改善する前に、まずはロジックを理解する。
そんな視点で検証を続ける中で、一つのことに気付きます。
「そもそも、何を予測すればいいんだろう。」
今回は、その答えが少しずつ見えてきた頃の話です。
Ver.1.0の前提を見直す
Ver.1.0は、選手ごとの**コース別平均スタート（平均ST）**をもとに予想するロジックでした。
つまり、各選手が平均スタートのデータどおりにスタートを切ることを前提に、スリット隊形を想定して組み立てていました。
しかし検証を続けると、その前提が何度も崩れます。
特に印象に残っているのが、大村での検証でした。
徳山と同じようなイン逃げ水面だと思っていました。
でも実際には、平均STから想定したスリット隊形とは大きく違う形になり、Ver.1.0は思うように機能しませんでした。
その時、ふと思いました。
「ロジックを直す前に、前提を見直す必要があるんじゃないか。」
この時から、ロジックを改善するのではなく、前提そのものを見直す方向へ考え方が変わっていきました。
Ver.1.0を活かす方法を考えた
最初に考えたのは、Ver.1.0を作り直すことではありませんでした。
「このロジックを活かす方法はないだろうか。」
Ver.1.0が苦手なのは、スリット隊形が大きく乱れるレースです。
逆に言えば、
Ver.1.0が得意なスリット隊形だけを判別できれば、ロジックはもっと活かせるかもしれない。
そう考えるようになりました。
問題を分解して考える
最初に作ろうとしていたのは、
出走表から、そのまま買い目を予想するAIでした。
でも検証を続けるうちに、
それでは問題が大きすぎることに気付きます。
私の中では、
スリット隊形
↓
レース展開
↓
レース結果（着順）
という流れでレースが進んでいるように思えました。
そして、その時ふと考えました。
「レース結果を予想する前に、その結果が生まれる原因を予測した方がいいんじゃないか。」
ここで初めて、
問題を一つにまとめて考えるのではなく、
順番に分解して考えるようになりました。
結果として着目したのがスリットでした。
でも、最初から
「スリットしかない。」
と思っていたわけではありません。
ロジックの弱点を補える指標なら、別のものでも構いませんでした。
検証を続けた結果、
私の場合は、それがスリットだったのです。
スリットだけを予測できないだろうか
そう考え始めたものの、
次の問題がありました。
「どうやってスリットを予測するんだろう。」
正直、この時は全く分かりませんでした。
そんな時、ふと昔YouTubeで見た
「12種類のスリットパターン」
を思い出しました。
「あの考え方を使えないだろうか。」
そう思った瞬間、止まっていたアイデアが少しずつ動き始めました。
まずはスリットをパターン分けする。
そして、出走メンバーから、どのスリットパターンになるか予測できれば、その後のレース展開も考えやすくなるかもしれない。
少しずつ、構想が形になり始めました。
機械学習という選択肢
スリットパターンを予測する方法を考える中で、壁打ちを続けていると、
「機械学習ならできるかもしれない。」
という話になりました。
最初から機械学習をやりたかったわけではありません。
目的は、
予想精度を上げること。
その方法を考えていく中で、自然と機械学習という手段につながっただけでした。
ちょうどこの頃は、Python学習も少し停滞していました。
「このままだと次に進めない。」
そんな感覚もあったので、機械学習という新しい学習テーマが見えたことは、純粋にワクワクしました。
AI開発とPython学習が、ここで初めて一つにつながったような感覚でした。
「試してみよう。」
スリットAIを思い付いた時、
「これなら絶対に成功する。」
そんな確信があったわけではありません。
むしろ、
「試してみよう。」
そのくらいの気持ちでした。
でも、
Ver.1.0を改善するのではなく、
Ver.1.0を活かすための新しい方法が見えたこと。
そして、
ロジックを直す前に、前提を見直したことで、次に進む道が見えたこと。
それは、私にとって大きな前進だったと思います。
次回予告
スリットAIを作る。
そう決めたものの、一つ大きな問題がありました。
AIに学習させるための教師データが、一つもなかったのです。
AIを作る前に、まずはAIに教えるための教材を作る必要がありました。
次回は、現在も続いている教師データ作成が始まった頃の話を書こうと思います。
あわせて読みたい
ボートレースAI開発シリーズは、前後の記事とあわせて読むことで、試行錯誤や考え方の変化をより分かりやすく追うことができます。
競艇AI開発日記 第5話｜ロジックを直す前に、理解することが必要だった
Ver.1.0の検証を通して、「当たった・外れた」ではなく、「どう外れたのか」を見るという考え方に変わった経緯を書いています。
