【公式データに無いなら逆算しろ】通過順位と着差から49万頭分の「個別ハロンラップ」を物理復元した狂気のアルゴリズム!Alma Core Pro開発記 #7

どうも、アルマコアです！

本業は工場の自動化機械やシーケンサー（PLC・制御盤）の設計に向き合っている、現役の機械エンジニアです。

前回の第6回では、オッズ36万行の雪崩に悲鳴を上げたSQLiteを「WALモード×同期緩和×5,000件バッチインサート」の三種の神器でねじ伏せ、数年分のデータをカップラーメンの待ち時間で吸い込ませる限界突破劇をお話ししました。

データベースの土台は完全に整いました。

何百万件という過去データが、コンマ数秒で手元に呼び出せる。

「よっしゃ！ これで市販のTARGETにも負けない最強のラップ分析画面が作れるぞ！」

……と、深夜のデスクで喜び勇んで『競走成績テーブル（kol_sei1, kol_sei2）』の生データを覗き込んだ瞬間、私はディスプレイの前で頭を抱えて完全に凍りつきました。

「……待てよ。公式データに『各馬の道中ラップ』がどこにも載ってへんやないか！！」

今回は、競馬界のデータの壁にぶち当たった機械屋が、「データが無いなら工学の物理モデルで逆算して復元したるわ！」と狂気のアルゴリズム（lap_reconstructor.py）を組み上げた執念の開発記録をお届けします！

1. 競馬データ最大の盲点「公式には先頭のラップしか存在しない」

競馬ファンなら誰しも一度は見覚えがあるはずです。

競馬新聞やJRAの公式結果に載っている、こういうラップタイム。

これを見て、私たちは「あ、中盤で緩んで後半のロングスパート戦になったんだな」と把握します。

しかし、ここで冷静に考えてみてください。

「このラップを走ったのって、一体誰ですか？」

答えは「その瞬間、たまたま先頭を走っていた馬（逃げ馬）」です。

そう、JRA公式データであれ、競馬ブックのKD3バイナリであれ、記録されている道中ラップはすべて「レース全体の先頭通過タイム」だけ。

中団（8番手）にいた馬が2ハロン目を何秒で通過したのか。

後方（15番手）で死んだふりをしていた差し馬が、3〜4コーナーでどれだけ脚を使って押し上げたのか。

そんなデータは、地球上の競馬データベースのどこを探しても1行たりとも存在しないのです！

公式データが各馬について提供してくれるのは、以下のわずかな情報だけでした。

• 各馬のゴールタイム（走破時計）

• 各馬の上がり3F（ラスト600mのタイム）

• （競馬ブック独自データとしての）各馬の前3Fタイム

• 各コーナーの通過順位（例：8-8-6-4）

• 1着馬とのゴール着差（例：0.3秒）

2. 上がり3Fだけでは「前傾ラップで力尽きた馬」を救えない

「いやいや君、上がり3Fと走破タイムがあるんやから十分ちゃいますの？」

と思われるかもしれません。

ですが、機械エンジニアとして断言します。

まったく不十分です。

工場のサーボモーターの性能評価で、「最初の始動トルク」と「最後の減速トルク」の2点だけを見て、中間工程の負荷グラフを見ないエンジニアはいません。

例えば、芝2000mのレースで同じ「上がり3F 35.0秒」で5着に負けた馬が2頭いたとします。

• A馬：前半激流のハイペースを2番手で追走し、ラスト1Fまで先頭で踏ん張って力尽きた。

• B馬：後方14番手でノロノロと脚を溜め、直線でバテた馬を交わしただけ。

この2頭の上がり3Fは同じ「35.0秒」です。

しかし、「馬の本来の巡航力・持久力」が上なのはどちらか？

言うまでもなくA馬です。

中間の個別ラップ（各ハロンごとの実走速度）が分からなければ、

• 「展開のアヤで負けただけで、次走絶対に狙うべき強い先行馬」

• 「単に展開が向いて追い込んできただけの過剰人気馬」

の区別が物理的に絶対にできないのです。

「市販のソフトに無いなら、自分で削り出すしかないやろ！」

ここから、私の眠れない夜が始まりました（笑）。

3. 工場のエンコーダーと同じ！通過順位と着差から通過時刻を割り出せ

無いものをどうやって作るのか？

工場の自動機械には、コンベア上を流れるワーク（製品）のミリ単位の位置をパルス信号で検知する「ロータリーエンコーダー」というセンサーがあります。

深夜の部屋で、私は閃きました。

「競馬場には、1コーナー、2コーナー、3コーナー、4コーナーという固定の計測ポイントがあるやないか！」

1. 先頭馬の基準通過タイム：公式のレースラップ（kol_sei1）を累積加算していけば、200m刻みで100%正確に割り出せる。

2. 各コーナーにおける遅れ時間（タイムラグ）：コーナー通過順位の隊列の長さと、前後の馬との車間距離（馬身差）から幾何学的に逆算できる。

3. ゴールの通過タイム：走破タイムと着差（time_difference）でミリ秒単位で完全に確定している。

つまり、「各コーナー地点をその馬が何分何秒何で通過したか」という通過タイム（チェックポイント）は、工学的に極めて高い精度で復元可能なのです！

4. スプライン曲線と物理運動方程式で「各馬の個別ハロンラップ」を完全逆算

チェックポイントの通過時刻が分かれば、あとはその間を結ぶ「区間ハロン（200mごとのタイム）」の算出です。

しかし、単純に直線で割り算（等速直線運動）をしてしまうと、馬の急激な加減速（コーナーの遠心力や坂での失速）が無視されてしまい、不自然なギザギザの数値になってしまいます。サラブレッドは機械の等速モーターではなく、生身の生き物ですからね。

そこで組み上げたのが、自作モジュール lap_reconstructor.py による「物理運動補間アルゴリズム」です。

Python

# lap_reconstructor.py のアルゴリズム概念（抜粋）
def reconstruct_horse_laps(race_laps, corner_positions, first_3f, last_3f, total_time):
    """
    先頭レースラップと各コーナー通過順位・馬身差、
    そして前3F・後3Fの実測値から、各馬の「個別ハロンラップ」を逆算・復元する
    """
    # ① レース全体の先頭ハロン積算タイムラインを構築
    leader_timeline = calculate_leader_timeline(race_laps)
    
    # ② 各コーナー地点における当該馬の「遅れマージン（秒）」を幾何学的に算出
    # （コーナー通過順位と内外の頭数密度から物理位置を特定）
    horse_checkpoints = estimate_corner_timestamps(leader_timeline, corner_positions)
    
    # ③ 確定している実測値「前3F」「後3F」「走破タイム」で境界条件を固定
    boundary_conditions = lock_boundaries(first_3f, last_3f, total_time)
    
    # ④ 物理運動方程式（三次スプライン平滑化）を適用し、
    # 各ハロンごとのエネルギー保存則と加速度上限を満たす「個別ハロンラップ」を復元！
    individual_200m_laps = solve_physical_lap_trajectory(horse_checkpoints, boundary_conditions)
    
    return individual_200m_laps

前3F（最初の600m）の実測値と、後3F（最後の600m）の実測値という「絶対に動かない両端のアンカー」で挟み込み、中間部分をコーナー通過順位のタイムスタンプと加速度推移で滑らかにフィッティングする。

この物理逆算アルゴリズムを回した瞬間、モニター上に、

「これまで地球上に存在しなかった、出走全頭の個別ハロンラップ（200mごとの推移）」

が、まるで全頭にGPSロガーを取り付けて計測したかのような滑らかな曲線を描いて出現したのです！

5. 『Alma MDI Pro』の波形解析エンジンへ――49万頭の走破ログが覚醒した瞬間

完成した復元アルゴリズムを、過去データを取り込むバッチ処理（test_data.py）の後段に組み込みました。

Python

# test_data.py より抜粋
# 新着成績のインポートが完了した直後、全自動で個別ラップを復元！
self.log("\n🏇 成績更新に伴う「各馬ハロンラップ＆隊列」の自動物理復元を実行中...")
rec_count = lap_reconstructor.run_diff_reconstruction(DB_PATH, log_func=self.log)
self.log(f"✨ 物理復元完了：新たに {rec_count:,} 頭の個別ハロンラップを生成・格納しました！")

過去10年分、延べ49万頭以上の全レース・全出走馬の走破ログから、個別ハロンラップがSQLiteデータベースへと一気に復元・格納されました。

このデータを、解析ビューアー『Alma MDI Pro』に流し込んだことで生まれたのが――あの「各馬の物理復元ハロン波形グラフ」です！

• 「この馬は、過去にラスト3Fが11.7秒連続の持続戦になった時、道中を12秒台前半で追走できているか？」

• 「スローからの瞬発力戦でしか勝てないキレ味特化型か？ それとも淀みないラップをバテずに刻む巡航型か？」

これまで「レース全体のラップ」や「単なる上がり3F」という粗い解像度でしか見えなかった各馬のフィジカルが、1ハロン単位の波形として丸裸になりました。

オッズに左右されず、人気馬の過大評価を見抜き、隠れた強い先行馬やステイヤーを機械的にあぶり出す。

町工場の機械エンジニアが意地で作り上げた「物理復元エンジン」が、ついに本格稼働した瞬間でした。

6. 次回予告：黒い画面はもう卒業！Tkinter自作MDIコックピットへ

「各馬の道中ラップ」という、市販ソフトでは絶対に手に入らない最強の武器を手に入れた私。

……だが、当時の私が週末の競馬に向き合っていた姿はこれでした。

PowerShell

PS C:\KeibaDB> python query_race.py --date 20261101 --venue 04 --race 11

……いや、発走3分前の緊迫した現場で、黒い画面（CUI）にコマンドカタカタ叩いてられるかーーーッッ（笑）！！

締め切りベルが鳴り響く中、引数を打ち間違えてエラーを吐かれ、オッズの歪みを見つける前にゲートが開いて撃沈……。

「現場に必要なのは、コマンド入力やない。直感でパッと状況が俯瞰できて、指先ひとつで瞬時に戦況を把握できる『自分専用の操作盤（HMI・計器盤）』や！」

次回、

【Alma MDI Pro開発記 NO.8】黒い画面はもう卒業！Tkinterで自作MDIと「開催一覧・レース選択」コックピットを削り出した執念。

Python標準のGUI「Tkinter」を極限まで使い倒し、Windowsネイティブの爆速コックピットをゼロから削り出すまでの泥臭い開発ドラマをお届けします！

どうぞお楽しみに！

☕ 最後まで読んでいただき、ホンマにありがとうございました！

「公式データに各馬の道中ラップが無いなんて知らなかった！」「通過順位と物理モデルから逆算する発想が完全に機械屋（笑）」と感じていただけたら、ぜひ画面下の「スキ（ハートマーク）」や「フォロー」をポチッと押していただけると、開発と執筆を続ける最高のガソリンになります！

◀️ 前の記事はこちら

👉 【第6回：10万行を瞬殺！三連単オッズでフリーズするSQLiteを覚醒させたバルクインサートの限界突破】

📚 【全話イッキ読み】自作競馬ソフト開発記マガジン

👉 [Alma Core Pro / MDI Pro 開発マガジンを開く]

💡 「なぜExcelでもサーバー型DBでもなくSQLiteなのか？」原点の第1回はこちら

👉 [開発記 第1回を読む]

⏩ 次のお話はこちら

👉 【第8回：黒い画面はもう卒業！Tkinterで自作MDIと開催一覧コックピットを削り出した執念】

🤖 工場のPLC屋が本気で書く！痛快＆重厚な自作Web小説も連載中

👉 [『転生したらイーロン・マスクが大統領だった件（笑）』第1話へ]

👉 [本格クライムSFサスペンス『アブダクション・プロトコル』第1話へ]