競馬のNARライブデータについて、レース一覧は48件取得できているのに、オッズスナップショットが0件という状態を確認した。結論から言うと、取得先のデータが空だったのではなく、スナップショット収集処理が保存まで到達していなかった。その後、同じserverブランチの収集器を当日指定で実行し、NARのCSVを4件保存できた。
保存0件だったときの状態
2026年9月17日のdata/live/odds_snapshots/20260917/schedule.jsonには、NARの48レースが記録されていた。一方、reports/live/snapshot_status.jsonは13:52に生成されたままで、次の状態だった。
{
"race_count": 48,
"snapshot_events": [],
"schedule_errors": [],
"summary": {
"saved_snapshots": 0,
"failed_snapshots": 0,
"skipped_snapshots": 0
}
}
取得失敗ならfailedイベントが残る設計だが、イベント自体が空だった。対象レースのスケジュール生成までは進み、実際のカード・オッズ取得を行う処理が実行または継続していなかったと判断できる。実ファイルもschedule.jsonだけで、CSVは存在しなかった。
収集器はsystemd timerから起動し、発走前のT-30とT-10にジョブを登録する。現在の作業環境では対応するsystemd unitと実行中プロセスを確認できず、VPSもSSH鍵認証が通らなかったため、VPS上のサービス稼働までは確認できていない。この点は、ローカル収集器が動くこととは分けて扱う必要がある。
NARの実収集を1回実行
当日開催分を対象に、NARだけを指定して--onceで収集器を実行した。
keiba/.venv/bin/python scripts/live_snapshot_collector.py \
--config config/live-snapshots.yaml \
--date 20260918 \
--provider nar \
--once
収集器はNARの36レースを読み込み、次の4ファイルを保存した。
| race_id | stage | 出走行 | オッズ行 |
|---|---|---|---|
202644091803 |
t30 | 14 | 14 |
202650091803 |
t30 | 9 | 9 |
202644091803 |
t10 | 14 | 14 |
202648091807 |
t30 | 11 | 11 |
合計は48行で、全行に単勝または複勝オッズが入っていた。ステータスJSONでもsaved_snapshots: 4、failed_snapshots: 0、schedule_errors: []を確認できた。
T-30の表示と実際の取得時刻
今回の実行は15:16〜15:17だったため、T-30ジョブとして保存された一部のデータは実際には発走8.56分前、13.56分前の取得だった。保存処理は成功しているが、定刻に起動できていない状態でT-30というステージ名を付けている。
したがって、今回確認できたのは「NARのスケジュール、出馬表、オッズを取得してCSVへ保存できること」であり、「systemd timerが毎日T-30/T-10に正確に動くこと」ではない。後者はVPSのtimer、service、journalを確認する別の運用確認が必要である。
結果
NAR収集器そのものは、実際のnetkeibaページから36レースのスケジュールを取得し、出馬表とオッズを含む4件のCSVを保存できた。保存0件の原因はデータ提供側の空データではなく、収集ジョブの起動・継続状態にある可能性が高い。
次にVPSで確認する項目は、keiba-live-snapshots.timerの有効状態、serviceの最終終了状態、journalの起動時刻、そしてreports/live/snapshot_status.jsonの最終更新時刻である。VPSの認証設定が復旧した後、同じ成功条件をVPS上でも確認する。