はじめに
こんにちは、しおぴーです。
前回 (#2 データ収集とスクレイピング設計) では、netkeiba からデータを取得する基本設計について書きました。
今回は 「貯めたデータを丸ごと取り直すことになった話」 について書きます。
ある日、ふと思ったんです。
「このデータ、本当に信用できるんだっけ?」
そして気づけば、PC を 14時間ぶっ通しで動かして、8年分のデータを取り直していました。
発端: データの不整合に気づいた瞬間
最初の違和感は、ある特定のレースの予想精度が異常に悪いことでした。
「同じ条件なのに、なぜここだけ外れるんだろう?」
DB を見てみると、馬体重が抜けていたり、上がりタイムが入っていなかったり、過去の取得時の不具合の名残が点在していました。
1件、2件なら問題ない。でも 100件以上見つかった瞬間、決断しました。
「全部取り直そう。」
データ規模
ORACLE PRO の競馬 DB は、2018年〜2026年の8年5ヶ月分。
レコード数にして約 134万件。
馬1頭1レースで1レコード。
これを丸ごと、netkeiba から再取得する作業に挑むことになりました。
設計: 「old」 と「new」 に分けた理由
まず最初に決めたのが、バッチを 2つに分けたこと でした。
- old バッチ: 2021年1月 〜 2023年9月 (古い順、forward)
- new バッチ: 2023年10月 〜 2026年3月 (新しい順、reverse)
なぜ分けたのか?
理由1: リスク分散
もし途中で 1つのバッチが止まっても、もう片方は生きている。
完全に止まるリスクを減らせる。
理由2: 復旧優先順位
直近データの方が予想に効く。
「new」 を先に動かせば、止まっても直近データは揃う。
理由3: 取得方向の違い
- old は forward (古い順) → 抜けを発見しやすい
- new は reverse (新しい順) → 直近の重要データから埋まる
これは設計したというより、手動運用しながら自然に出てきた知恵 でした。
実行: 14時間ぶっ通しの戦い
5/14 (木) の朝6時31分。
2026-05-14 06:31:09 [INFO] scraper 起動
ここから、14時間にわたる長い旅が始まりました。
中盤の不安
数時間経って、進捗ログを見にいくと:
[1500/3055 49%] 取得中: 20220314
まだ半分。
このペースなら、完走まであと7時間。
寝ても起きても、まだ続いてる。
PC のファンの音が、ずっと一定のリズムを刻んでいたのを覚えています。
終盤の景色
夜8時を回った頃、ログにこんな行が流れました:
[3055/3055 100%] 取得中: 20180101
2026-05-14 20:20:12 [INFO] 20180101: 471頭 取得完了
2026-05-14 20:20:27 [INFO] scraper 完了
14時間。3,055日分。完走。
その瞬間、ようやくキッチンに行って、ビールを開けました。
結果と教訓
数字で見る成果
| 項目 | 値 |
|---|---|
| 取得対象期間 | 2018/01/01 〜 2026/05/14 |
| 処理日数 | 3,055日 |
| 取得レコード | 約 134万件 |
| 所要時間 | 約 14時間 |
| 失敗日数 | 0日 |
教訓1: バッチは小分けにする
大きな処理を「えいやっ」 で1本にすると、止まったときに困る。
小分けにすれば、リトライが楽。
教訓2: 進捗ログは「日付」 単位
「何件目」 でなく「何月何日」 のログにすると、人間が見て安心する。
「あ、もうすぐ 2020年に入る」 と分かれば、感覚的に残り時間が掴める。
教訓3: progress.json は神
中断時に「どこまでやったか」 を JSON で残しておけば、再開コマンドで即復帰できる。
{
"version": 1,
"last_run_started_at": "2026-05-14T06:31:09",
"completed_dates": [...],
"failed_dates": [],
"current_position": "20180101"
}
これがないと、毎回最初からやり直しになっていました。
教訓4: データ品質は「取得時」 にしか担保できない
「あとで直せばいい」 と思ったデータは、永遠に直されません。
取得時のバリデーション、メタデータ、ログ、全部大事。
このあと
134万件のデータが揃ったところで、ORACLE PRO の予測精度がどう変わったか?
実は、ある指標で 目に見えた改善 が起きました。
その話は #4 で書きます。
おわりに
「14時間ぶっ通しでスクレイピング」 と書くと格好いいですが、実際は PC の前に座って Slack を見ながら待っていただけです。
でも、データ基盤に向き合った14時間は、その後の予想精度に確実に効いてきました。
データに正直に向き合う、というのは地味で根気のいる仕事ですが、これがないとAIは成立しないんだなと改めて感じます。
次回: #4 — 大規模再取得で見えた、予測精度の意外な変化
ORACLE PRO 個人開発記録シリーズ:
– #1 個人で AI 競馬予想システムを作り始めた話
– #2 データ収集とスクレイピング設計
– #3 14時間の大規模 rescrape (本記事)
– #4 大規模再取得で見えた、予測精度の意外な変化 (近日公開)
コメント