稼働中のシステムをどう育てるか——競馬AI V3全記録
対象期間：2026年4月1日〜5月18日 制作者：yuji
「競馬予測AIが完成した」——そう思っていた。
前回の記事では、ゼロから半年で17本のPythonスクリプト・4系統の並列アーキテクチャ・複勝3着内率51%を達成するまでの全記録を書いた。それが「完成」だと思っていた。
甘かった。
稼働を続けるシステムには、新たな問いが次々と生まれる。「どの補正が効いていて、どれがノイズか」「改善しようとすると別の場所が壊れる」「同じアルゴリズムのコピーが、なぜ違う精度を出すのか」——。
V3期間（2026年4/1〜5/18）の403レース・5,483頭が証明したのは、**「設計とは削除の連続である」**という事実だった。
V3期間サマリー
| 指標 | 値 |
|---|---|
| 新規・大幅改版スクリプト | 12本 |
| 検証レース数 | 403R（2/28〜5/17確定版） |
| V5 3着内率（最終） | 45.8%（ローテーション補正削除後） |
| 両者一致シグナル | 53.8%（V3最大の実践的発見） |
| 最重要アーキテクチャ変革 | 補正管理層（hosei_mixer）の誕生 |
1. V3最大の変革——「補正管理層」の誕生
問題：予想エンジンを触るたびに壊れるリスク
V3期間、seiki_keibayosou_app_v5.py（V5）はNo.19〜65と47回の変更を重ねた。開発初期の「改善したいときはV5本体を直接修正する」スタイルが、何度も問題を引き起こした。
- 補正係数を変えたら別の場所に波及した
- バグを直したら別の機能が壊れた
- 「どこを変えたら何が変わるか」の追跡が不可能になった
そこで4/22に設計した解決策が hosei_mixer_v1.py（補正管理層） だ。
┌────────────────────────────────────────┐
│ seiki_keibayosou_app_v5.py │
│ （予想エンジン層） │
│ ← 基本的に触らない・壊さない ← │
└────────────────────────────────────────┘
↑ CSV連携
tekisei_hoseichi.csv
basho_correction.csv
↑
┌────────────────────────────────────────┐
│ hosei_mixer_v1.py │
│ （補正管理層） │
│ ← ここで実験する・ここで育てる ← │
└────────────────────────────────────────┘
設計原則：V5予想エンジンは絶対に触らない。補正は外部から制御する。
失敗しても補正管理層だけをロールバックすれば済む。この2層分離設計により、「観測→補正値調整→再検証」サイクルが初めて安定して回るようになった。
# V5予想エンジンを一切変更せず、外部CSVから補正値を注入する
def save_tekisei_csv(horse_corrections: dict, mode: str = "seiki"):
"""
mode="seiki" → 本番用 tekisei_hoseichi_seiki.csv
mode="kensyou" → 検証用 tekisei_hoseichi_kensyou.csv
"""
path = TEKISEI_CSV_SEIKI if mode == "seiki" else TEKISEI_CSV_KENSYOU
with open(path, 'w', newline='', encoding='utf-8') as f:
writer = csv.DictWriter(f, fieldnames=['horse_id', 'correction'])
writer.writeheader()
for hid, val in horse_corrections.items():
writer.writerow({'horse_id': hid, 'correction': val})
hosei_mixerはV3期間でNo.01〜24と24回の変革を経て、5/18時点でv1.6として本格稼働。補正履歴はhosei_history.csvに自動蓄積され、「どの補正が効いたか」を振り返れるようになった。
2. ローテーション補正の「追加→検証→削除」
V3期間で最も学びが大きかった失敗
5/10〜11に実装したローテーション補正（V5 No.48〜54）は、「前走間隔と前走成績の組み合わせで精度が上がるのでは」という仮説から生まれた。V5初の「時系列要素」として、満を持して投入した。
# ローテーション補正の実装（V5 No.49〜54）
ROTATION_TABLE = {
(1, 'win'): +0.08, # 連勝狙いの中1週
(2, 'place'): +0.05, # 好調維持の中2週
(8, 'none'): -0.10, # 長休明け（8週以上）
# ...
}
def calc_rotation_bonus(weeks_since_last: int, last_result: str) -> float:
key = (weeks_since_last, last_result)
return ROTATION_TABLE.get(key, 0.0)
403R同条件比較——結果は明快だった
| 条件 | 1着率 | 3着内率 |
|---|---|---|
| ローテーション補正あり（旧） | 15.4% | 44.0% |
| ローテーション補正削除（現行） | 17.4%（+2.0pt ✅） | 45.8%（+1.8pt ✅） |
| V58（元からローテなし） | 20.6% | 46.1%（残差0.3pt） |
削除した方が精度が上がった。ローテーション補正はノイズだった。
なぜノイズになったか
競馬の「前走間隔」は単独では信号にならない。「中2週で前走1着」でも馬によって意味が全く異なる。適切にモデル化するには馬ごとの体質・厩舎方針・距離変化を複合的に考慮する必要があり、シンプルなルールテーブルでは逆効果になった。
時系列要素はV4期間で改めて設計し直す——これがV3の結論だ。「実装→検証→削除」というサイクルが完結した。
3. 同じアルゴリズムのコピーがなぜ違う精度を出したか
V3期間で最も知的に面白かった問題
V5（本番・正規系）とV58（検証用クローン）は同じアルゴリズムを持つ「twins」として設計した。しかし4/17〜21の59R比較検証で、V58がV5を約2pt上回るという事実が判明した。
「同じアルゴリズムなのになぜ差が出るのか」——これを体系的に追究した。
| 項目 | V5（正規） | V58（検証） |
|---|---|---|
| 3着内率 | 44.0%（旧）→ 45.8%（削除後） | 46.1% |
| 1着率 | 17.4% | 20.6% |
| 残差 | ← 3着内0.3pt / 1着3.2pt → |
差異の特定——2つの要因に絞られた
① ローテーション補正（V5のみ存在）
→ 削除により+1.8pt改善。V58との3着内残差は0.3ptに縮小。✅ 解決済み
② trainer_b 閾値設計の差
# V5（旧設計）：シンプルだが甘い
def calc_trainer_b_bonus_v5(trainer_g1_wins: int) -> float:
if trainer_g1_wins >= 10:
return +1.0
else:
return 0.0 # ← ゼロ止め。実績薄調教師を「普通」と評価してしまう
# V58（厳格設計）：実績薄にペナルティを課す
def calc_trainer_b_bonus_v58(trainer_g1_wins: int) -> float:
if trainer_g1_wins >= 10: return +1.5
elif trainer_g1_wins >= 5: return +1.0
else: return -0.5 # ← これが差を生んでいた
「シンプルで厳格な評価軸がシステムを精緻にする」——これがtwins問題の結論だ。
実績のない調教師を「ゼロ評価（普通）」するのか「マイナス評価（弱い）」するのか。この設計の差が、1着率3.2ptという数値の差になって現れていた。V4期間のtrainer_b逆移植として引き継がれる。
4. twins問題が生んだ副産物——V3最大の発見
追究の過程で、想定外の発見があった。「V5とV58の予測が一致したときだけ購入する」というフィルターを検証したところ——
🏆 両者一致シグナル：3着内率 53.8%
| 評価区分 | R数 | 3着内率 | 1着率 |
|---|---|---|---|
| ➡ 両者一致（V5 = V58） | 171R | 53.8% 🏆 | 21.1% |
| ⬆ UP（V5 > V58） | 129R | 42.6% | 11.6% |
| ⬆⬆ 大幅UP（V5が大幅上回る） | 82R | 25.6% ⚠️ | 9.8% |
ランダム期待値の約3倍。V3期間最大の実践的発見。
「大幅UP（正規が非正規を大きく上回る）」は3着内率25.6%と最低水準。V5が単独で高評価しているケースは「過剰補正の疑い」として割引くのが正解。2つのアルゴリズムの不一致の大きさが、不確実性の指標になる。
5. ローテーション削除後に顕在化した新問題
全体精度は改善した。しかし詳細検証で新たな問題が浮上した。「会場別・ランク別の分岐」だ。
競馬場別：V5（ローテ無し）vs V58 の3着内率
| 競馬場 | V5（A） | V58（B） | 差（A−B） | 推奨 |
|---|---|---|---|---|
| 🏇 中山 | 54.7% | 46.5% | +8.2pt ✅✅ | A主軸 |
| 🏇 阪神 | 54.4% | 52.2% | +2.2pt ✅ | A優位 |
| 🏇 新潟 | 44.4% | 47.2% | −2.8pt ⚠️ | B参照 |
| 🏇 東京 | 37.0% | 40.0% | −3.0pt ⚠️ | B参照 |
| 🏇 中京 | 34.4% | 41.9% | −7.5pt ⚠️⚠️ | B優先 |
| 🏇 福島 | 34.3% | 28.6% | +5.7pt | 要注意 |
騎手ランク別：逆転現象
| ランク | V5（A）3着内率 | V58（B）3着内率 | 差 |
|---|---|---|---|
| ランクB | 58.0%（69R） | 52.1%（73R） | +5.9pt ✅✅ |
| ランクA | 42.9%（112R） | 41.4%（99R） | +1.5pt |
| ランクC | 26.7%（90R） | 32.1%（134R） | −5.4pt ⚠️ |
ランクC騎手でV58が逆転優位に。ローテーション補正が「ランクCの下方抑制として機能していた部分」があり、削除によってその抑制が失われた可能性がある。
「ローテーション補正はノイズだった」は全体の話。条件によっては補正として機能していた部分もある。設計の削除はシンプルでも、その影響は複雑だ。
6. 403R確定版——最終成績表
■ 競馬場別 予想1位の3着内率（2/28〜5/17）
| 競馬場 | 3着内率 | 1着率 | R数 |
|---|---|---|---|
| 🏇 阪神 | 52.2% | 22.2% | 90R |
| 🏇 新潟 | 47.2% | 25.0% | 36R |
| 🏇 中山 | 46.5% | 15.1% | 86R |
| 🏇 中京 | 41.9% | 9.7% | 31R |
| 🏇 東京 | 40.0% | 11.1% | 45R |
| 🏇 福島 | 28.6% ⚠️ | 8.6% | 35R |
| ◎ 総合 | 45.8% | 17.4% | 403R |
総合45.8%はランダム期待値（約17〜20%）の約2.2倍を403Rの大サンプルで継続維持。
7. 実践的活用ガイド（V3確定版）
① 第一フィルター：両者一致を確認
→ 3着内53.8%・1着率21.1%の最強シグナル。これだけで買うレースを約40%絞れる。
② 得意会場を優先
→ 阪神・新潟・中山（47〜54%の高精度ゾーン）。中京・東京・ランクCはV58を参照。
③ 騎手ランクBに注目
→ V5使用時にランクAより**+5.9pt高い58.0%**。ランクA騎手は人気先行で過剰評価されやすい。
④ 大幅UPは割引
→ 正規が非正規を大きく上回る時は過剰補正の疑い（25.6%）。見送りが正解。
⑤ 福島は要注意
→ 全競馬場最低28.6%。可能なら見送り推奨。
8. V3から得た設計哲学
半年の構築期（V1〜V2）を経て、V3期間で学んだことを一言で言うと：
「削除は追加より難しく、価値がある」
ローテーション補正を追加するのは簡単だった。しかし403Rのデータが「これはノイズだ」と告げるまで検証し、削除を決断し、そして削除後に新たな問題が顕在化することを受け入れる——このサイクルこそがシステムを本当に育てる過程だ。
補正管理層（hosei_mixer）の誕生も、「追加の失敗を安全に試せる設計」があって初めて意味を持つ。2層分離アーキテクチャは**「失敗コスト」を下げるための構造的な解答**だった。
V3期間確定コーディングルール
① 修正のたびNo.XX採番・省略禁止
② コメント変更はgrepで実コード照合
（コメントと実コードの不一致バグを2回踏んだ）
③ py修正後はscan_dependencies.py実行
（全22ファイルの依存関係を自動スキャン）
④ バッチフォルダ更新時は_batch_dirs同時更新（絶対ルール）
ルールはすべて「実際に踏んだバグ」から生まれている。理論ではなく実データが設計を変える——第一弾で書いた哲学は、ルール管理にも貫かれている。
おわりに——V4期間へ
| 課題 | 内容 |
|---|---|
| 🔜 trainer_b逆移植 | V58のペナルティ設計をV5に逆移植。1着率+3.2ptを目指す |
| 🔜 会場×アルゴリズム戦略 | 中山・阪神はV5主軸、中京・東京はV58参照を実運用検証 |
| 🔜 宝塚記念（6月） | G1騎手補正confidence=1.0到達。初の満信頼度G1検証 |
| 🔜 時系列要素の再設計 | ローテーション補正の失敗を踏まえ、複合設計で再実装 |
V3最大の発見は数値ではなく設計思想だった。
「実験できる構造が、学習できるシステムを作る」
次回（第3弾）：V4期間 trainer_b逆移植・会場×アルゴリズム戦略の実証結果を予定。
seiki_keibayosou_app_v5.py v5.6(No.65) ／ hosei_mixer_v1.py v1.6(No.24)
403R / 5,483 horses / 2026-02-28〜2026-05-17