【予想システム開発メモ #4】データの傷を治す〜大規模再スクレイピングで品質を取り戻した話

開発を進めていると、ある日突然「あれ、このデータ、おかしくないか」と気づく瞬間がある。

ORACLE PROの場合、それは5月中旬のことだった。

ORACLE PRO（AI競馬予想システム）には、過去レースのデータを機械学習モデルに学習させるという根本設計がある。「良馬場と重馬場では走り方が違う」「雨の日は先行有利になりやすい」といった傾向を、データから自動的に抽出させるのが狙いだ。

ところが、初期に取り込んだデータを詳しく検証したところ、天候・馬場状態の列が大量にnullになっていることが判明した。

一部のデータソースでは、馬場状態（良・稍重・重・不良）と天候（晴・曇・雨・小雨）が、フォーマットの都合上うまく取り込めていなかった。影響を受けたのはある期間のレースデータ全体で、スコープは小さくない。

「学習データに穴が開いている」というのは、モデルの判断精度を根本から揺るがす問題だ。

データのバリデーションが甘かった、というのが正直なところだ。

最初のスクレイピング工程では「レース結果（着順・タイム・騎手・馬体重）」が取れているかどうかを主にチェックしていた。天候・馬場状態は「補助情報」として扱っていたため、欠損を深刻なバグとして検出する仕組みがなかった。

機械学習のパイプラインでは、こうした欠損は「0で埋める」「最頻値で補完する」といった処理で学習が進んでしまうことがある。エラーが出ないから、一見問題なく動いているように見えてしまうのだ。

これは個人開発あるあるの罠だと思う。データが取れていることと、正しいデータが取れていることは別物なのに、前者だけ確認して安心してしまう。

問題が確認できたのは5月中旬。対応の選択肢はいくつかあった。

結論は③だった。

理由は明快で、「補完した値で学習したモデルが、本当に正しい傾向を学んでいるか確信が持てない」から。統計的補完はデータが少量欠損している場合には有効だが、今回は構造的に一定期間のデータが根こそぎ抜けていた。そのまま使うのはリスクが高い。

5月20日より、対象期間のレースデータを全件再スクレイピングすることに決めた。アクセス間隔を守りながら、丁寧に取り直す作業を開始した。

実際に再取得を進めてみると、天候・馬場状態だけでなく、コース情報（内回り・外回りの区分）にも一部ズレがあることがわかった。

最初から完璧なデータを取り込むのは難しい。ソースのHTMLフォーマットは頻繁に変わるし、ページによって同じ情報が違う場所に置かれていることもある。

ただし、今回の経験から「定期的にデータの分布を確認する」という習慣の大切さを痛感した。具体的には、

これらを継続的に行う仕組みを組み込む必要がある。「一度作ったら終わり」ではなく、データパイプラインは継続的なメンテナンスが必要だということだ。

AI・機械学習を使ったシステムを個人で開発していると、「モデルの精度が上がらない」という悩みに直面することが多い。

その原因を探ると、「ハイパーパラメータの調整」や「特徴量の追加」よりも前に、「データ自体に問題がある」というケースが意外に多い。

「Garbage in, garbage out」という言葉があるが、これは的を射ている。どんなに洗練されたアルゴリズムを使っても、入力データが歪んでいれば出力も歪む。

ORACLE PROの場合、今回の修正によって学習データの信頼性が大きく向上した。再スクレイピング完了後のモデル評価では、天候・馬場状態の違いによる傾向の差がより明確に反映されるようになっている。

再スクレイピングが完了したら、次のフェーズに進む。

「傷を治す」だけでなく、「同じ傷ができないようにする」ところまで持っていくのが今フェーズのゴールだ。

データ品質の問題は、発覚が遅れるほど影響範囲が広がる。今回は幸い、本番運用前の段階で気づくことができた。

個人開発でAI系のシステムを作っている方には、「データが取れているかどうか」だけでなく「データが正しいかどうか」を定期的に確認する習慣を強くおすすめしたい。

次回の開発記録では、データ品質修正後の評価結果と、次のフェーズについて書く予定です。