他の記事とも重複する。でも、ここは重要
DB作りというと、多くの方はまず、
「データを集めること」
を思い浮かべると思う。
もちろん、それは間違いではない。
出走表を集める。
直前情報を集める。
結果を集める。
オッズを集める。
これらを蓄積していけば、競艇ソフトの土台となるデータベースは少しずつ出来上がっていく。
しかし、本当に大事なのはその前である。
DB作りは、データを集め始める前からすでに始まっている。
ここを飛ばして、とにかく収集を始めてしまう。
私も含めて、たぶん多くの人が一度はやる。
画面が動く。
ファイルが増える。
数字が貯まる。
実に楽しい。
しかし数年後、
「ところで、このデータはどうやって結合するんだ？」
となる。
楽しかった思い出が、一気に宿題へ変わる。
何を集めるかより、どう使うか
最初に考えるべきことは、
「どのデータを集めるか」
だけではない。
それ以上に大切なのが、
「そのデータを、あとで何に使うのか」
である。
たとえば、
出走表だけで予想するのか。
直前情報まで使うのか。
結果と照合して予測精度を検証するのか。
オッズを組み合わせて、「当たりそうか」ではなく「買う価値があるか」まで判断するのか。
目的が違えば、必要なデータも保存方法も変わる。
単に記録として残すだけなら、HTMLを保存しておくだけでも構わない。
しかし、あとで分析するのであれば、
- 開催日
- 会場
- レース番号
- 艇番
- 選手情報
- 展示タイム
- 進入
- スタート
- オッズ
- 結果
といった情報を、あとから正しく結びつけられる形にしておく必要がある。
つまりDBとは、単なるデータ置き場ではない。
あとで使うための整理棚である。
私の生活の押し入れのように、とりあえず空いているところへ何でも放り込むのとは違う。
あれをDBと呼んでしまうと、数年後に必要なものを探しに行って遭難する。
検証済みである。
最初に「レースID」を決める
競艇データを扱ううえで、特に重要なのがレースIDである。
簡単に言えば、
このデータは、どのレースのものなのか
を一発で特定するための番号だ。
私は、
20230314_03_06
のような形にした。
意味は、
- 2023年3月14日
- 会場コード03
- 第6レース
である。
これなら、この文字列を見るだけで一つのレースを特定できる。
ちなみに今になって思えば、
「会場コード03は最後に置いた方が良かったかな」
という気もしている。
しかし、始めてしまったものは仕方がない。
後悔しても、決めたからには貫く覚悟が必要である。
重要なのは並び順ではない。
出走表でも、直前情報でも、結果でも、オッズでも、
同じレースには必ず同じIDを使うこと。
ここである。
出走表ではA方式。
直前情報ではB方式。
結果ではまた別方式。
そんなことを始めると、あとでデータを結合するときに大変なことになる。
苦労だけならまだいい。
もっと怖いのは、
別のレース同士を間違えて結合してしまうことだ。
予想ソフトを作っているつもりなのに、知らないうちに違うレースの結果を正解として学習させていた。
こうなると、モデルが当たらない理由さえ分からない。
数式を直す。
ロジックを直す。
パラメータを変える。
それでも当たらない。
原因はAIではなく、入口のレースIDだった。
笑えない。
だから、DBを作り始める前に、レースIDだけは決めておく。
地味だが、ここは絶対に手を抜いてはいけない。
保存ルールを決めてから集める
次に決めておきたいのが、保存ルールである。
どのフォルダへ保存するのか。
年ごとに分けるのか。
会場ごとに分けるのか。
ファイル名をどうするのか。
出走表、直前情報、結果、オッズをどのように分類するのか。
こうしたルールを決めずに収集を始めても、最初のうちは何とかなる。
数十レース。
数百レース。
この程度なら、人間の記憶でもどうにかなる。
しかし競艇は、1年間でおよそ5万レース規模になる。
8年分なら、約50万レース。
ここまで来ると、
「確かこの辺だったはず」
では管理できない。
「このファイル、何だったかな」
「同じレースを二重に取ってないか」
「2021年の大村だけ、どこへ行った？」
こうなった時点で危険信号である。
DB作りに必要なのは、根性ではなくルールである。
根性で50万レースを管理しようとすると、Excelより先に人間がフリーズする。
これは競艇に限った話でもない。
会社の共有フォルダなどでも、ときどき似た光景を見かける。
誰も消せない。
誰も場所を変えられない。
しかし、何のファイルなのか誰も知らない。
立派な文化財である。
Raw HTMLを残す――これは保険である
私が今、特に大事だと思っているのが、
加工後のデータだけでなく、元のHTMLも残しておくこと
である。
最初に作ったデータ収集ソフトが、最初から完璧に動く。
そんなことができれば理想だ。
しかし経験者として言わせてもらえば、
そんなことが出来るわけがない。
あとから必ず出てくる。
「この項目も欲しかった」
「風向の扱いを変えたい」
「展示タイムの取り方を見直したい」
「レースグレードの判定に漏れがあった」
「欠場の扱いを変えたい」
最初から全部分かっていれば苦労しない。
開発を続けていくからこそ、
「あれも必要だった」
と気づくのである。
そのとき、元のHTMLが残っていれば、もう一度そこからデータベースを作り直せる。
しかし加工後のExcelやCSVだけしか残していなければ、元サイトから再取得できないデータは取り返せない場合がある。
だから私は、Raw HTMLを単なる途中ファイルとは考えていない。
原本である。
DBは加工品。
Raw HTMLは原材料。
加工方法を間違えたなら、原材料からもう一度作ればいい。
この保険があるだけで、後から仕様を変える自由度が大きく違う。
集めたデータは必ず検証する
データは、集めれば完成ではない。
本当に正しく取れているのか。
抜けているレースはないか。
重複していないか。
出走表と結果は同じレースなのか。
オッズと結果は正しく結びついているか。
欠場、中止、不成立、発売中止などが、おかしな形で通常レースへ混ざっていないか。
こうした確認が必要になる。
ここを飛ばすと、見た目だけは立派なDBができる。
行数も多い。
列数も多い。
何十万行もある。
ファイルサイズも大きい。
実に頼もしく見える。
しかし中身が間違っていれば、その先の分析も全部怪しくなる。
たとえば1着を予測するモデルを作ったとしても、結果データとの結合がズレていれば、そのモデルの精度評価には意味がない。
オッズを使って期待値を計算する場合も同じである。
オッズは6R。
結果は7R。
計算式だけは完璧。
これではどうにもならない。
料理に例えるなら、
カレーを作るつもりで砂糖とワサビを煮込んでいるようなものだ。
火加減を調整しても解決しない。
まず材料を確認する必要がある。
最初から50万レースを集めなくていい
ここまで読むと、
「DB作りって、とんでもなく大変なのでは？」
と思うかもしれない。
その通り。
大変である。
ただし、最初から巨大なDBを作る必要はない。
まず1会場。
まず1か月。
まず1年。
最初は出走表と結果だけ。
それでも構わない。
重要なのは、あとから広げられる形にしておくことである。
たとえば、
- race_idを統一する
- 保存ルールを決める
- Raw HTMLを残す
- あとから検証できるようにする
この土台さえ作っておけば、その後に直前情報やオッズを追加することはできる。
反対に、土台を作らずにいきなり大量収集を始めると、あとで構造そのものを作り直すことになる。
これが一番つらい。
データを集め直すより、
間違った構造で集めた大量データを整理し直す方が、はるかに面倒である。
「あとで考えよう」
は、少量のうちは非常に便利な言葉だ。
50万レースになると、突然牙をむく。
DB構築前に最低限決めておきたいこと
データを取り始める前に、少なくとも次のことは考えておいた方がいい。
- 何のためにDBを作るのか
- どのデータを集めるのか
- 何年分を対象にするのか
- 年・会場・レースのどの単位で保存するのか
- race_idをどう作るのか
- Raw HTMLを残すのか
- 加工済みデータを何に保存するのか
- 欠場や中止をどう扱うのか
- 重複や欠損をどう検査するのか
- 後から作り直せる構造になっているのか
全部を最初から完璧に決める必要はない。
しかし、
あとから変更できるように作っておく。
これは重要である。
DB作りは、収集ボタンを押す前から始まっている
いきなりデータを集め始めると、作業している感じが出る。
画面が動く。
HTMLが増える。
Excelに数字が並ぶ。
なんとなく、競艇ソフト開発が前へ進んでいる気になる。
しかし本当に重要なのは、その前である。
何のために集めるのか。
どう結びつけるのか。
どこへ保存するのか。
間違ったときに元へ戻れるのか。
どうやって正しさを確認するのか。（検証）
ここを決めてから収集を始める。
遠回りに見えるが、結果的にはこちらの方が近道である。
DB作りは、データを集める前から始まっている。
このことを最初に知っておくだけでも、競艇ソフト作りの遠回りはかなり減らせる。
私自身、最初から全部分かっていたわけではない。
失敗して、
作り直して、
また失敗して、
ようやく今の形になった。
だから今後は、
「これからDBを作ってみたい」
という方が、私と同じ穴へ順番に落ちなくても済むように、
データの集め方。
Raw HTMLの残し方。
race_idの考え方。
保存方法。
Excelへの集積。
検証方法。
その先のPythonによる分析まで。
一つずつ記事にしていくつもりである。
先に落ちた人間が、
ここに穴がありますよ
と看板を立てるくらいの役には立てるだろう。
それも、このブログの役目の一つだと思っている。
コメント