この回の結論は一行で書けます。
当てる力があることと、儲かることは、別物でした。
何を測ったか
地方競馬の 6,624頭 / 642レース（2026年7月28日〜8月18日）を対象に、ある指標の値が低い順に10等分しました。指標そのものの中身は、他社サービスの再現に関わる部分があるのでここでは書きません。「複数の馬券市場の間の評価のズレを1つの数に直したもの」とだけご理解ください。値が大きいほど「一方の市場が、他方より高く評価している馬」です。
見たのは2つだけです。
- 複勝の的中率（3着以内に入った割合）
- 複勝の回収率（全頭に100円ずつ賭けたときの払戻）
回収率にはレース単位のブートストラップで95%区間を付けました。1レース内の複数頭は当たり外れが連動するので、頭ごとにバラして数えるとブレを実際より小さく見積もってしまいます。レースごと丸ごと抜き直す方法にしています。
結果
| 帯 | n | 複勝的中率 | 複勝回収率 | 95%区間 |
|---|---|---|---|---|
| 1（最も低い） | 663 | 40.4% | 72.6% | [64.9, 80.6] |
| 2 | 662 | 29.6% | 70.3% | [61.1, 80.9] |
| 3 | 662 | 26.0% | 73.0% | [60.5, 85.7] |
| 4 | 663 | 21.4% | 64.1% | [51.8, 76.5] |
| 5 | 662 | 19.9% | 76.9% | [58.3, 99.4] |
| 6 | 662 | 17.7% | 65.5% | [50.5, 81.6] |
| 7 | 663 | 21.9% | 62.2% | [47.8, 78.6] |
| 8 | 662 | 26.0% | 71.5% | [57.1, 87.5] |
| 9 | 662 | 34.1% | 70.0% | [58.4, 84.8] |
| 10（最も高い） | 663 | 53.7% | 79.2% | [72.2, 86.1] |
的中率は 17.7% から 53.7% へ、3倍動きます。しかも U 字にきれいに並びます。指標が極端な馬（両端）はよく来て、真ん中の馬は来ない。指標には予測力があります。
それなのに、回収率は 62〜79% の帯から一度も出ません。10帯すべてで「100%を超えている確率」はほぼ 0% でした。
これが意味すること
当たる馬は、その分だけオッズが低くなっています。
的中率が3倍になれば、素朴には3倍儲かりそうに思えます。実際には、市場がその情報をすでに価格に入れているので、当たりやすさはそのままオッズの安さとして返ってきます。残るのは控除率だけです。回収率が 70% 前後に張り付いているのは、まさにその水準です。
これは競馬に限った話ではありません。「予測精度が上がった」と「儲かるようになった」は、まったく違う主張です。前者は後者を意味しません。予測モデルの精度を自慢する記事を読むときは、回収率が示されているかを見てください。示されていないなら、たいてい理由があります。
「まだ見ていない領域」を先に潰す
正直に書くと、私はこの測定をする前、指標が高い側しか見ていませんでした。閾値を超えた馬だけを集めて「回収率 78.9%、上限 85.9%、届かない」と結論しかけたのです。
しかしそれは右端しか見ていないということです。指標が負に大きい側、ゼロ付近──そこに回収率が持ち上がる帯があるかもしれません。だから10等分して全域を見ました。
ありませんでした。平らでした。
この順番は大事だと思っています。「一部を見て閉じる」と「全部を見て閉じる」では、次に何を試すかが変わります。前者だと「閾値をいじればいい」に見えますが、後者だと「この軸そのものが平ら」だと分かります。閾値をいじる時間を丸ごと節約できます。
⚠️ ひとつ注意を。単勝で見ると、10帯のうち1つだけ 123.5% という数字が出ました。追いません。区間が [54.7, 203.9] と150pt幅で、10帯から拾った最良の1つだからです。10回引いて一番良かったくじを「当たりやすいくじ」と呼ぶのは、統計ではありません。
同じ日に、自分の作った道具が2つ嘘をついていました
同じ日の記録なので、あわせて残します。どちらも、私が書いたコードです。
1. 上限の門が6つ、空振りしていた
自動投票には、暴走を止めるための上限がいくつも掛けてあります。累計の点数、累計の金額、1日の金額、1日の件数、同じ馬への二重投票の禁止。
そのすべてが、台帳を数える1行のせいで機能していませんでした。
台帳に書かれる状態は sent（過去形）なのに、数える側は send（原形）を探していたのです。一致しないので、投票が成立しても1件も数えられず、累計はいつも「0点 / 0円」と表示されていました。
さらに悪いことに、この門にはテストがあり、通っていました。理由は単純で、テストも send（原形）を書いていたからです。コードとテストが同じ間違いをしていたので、仲良く緑だったわけです。
テストが緑であることは、テストが正しい形のデータを使っていることを保証しません。
実際に動いているシステムが吐いた本物の記録に当ててみたら、一発で分かりました。
2. 監視が「全滅した日」を緑と報告した
別の日、判定プロセスが昼過ぎに落ちて、その日は1件も判定できませんでした。候補は8レースありました。
私の作った健全性チェックは、こう表示しました。
候補レース 8
判定できた 0
オッズが取れず 0
🟢 候補 8 レースすべてに判定が届いている
判定0件なのに緑です。原因は判定の順序でした。「オッズ取得に失敗した件数がゼロなら健全」という条件を、「判定が0件かどうか」より先に置いていたのです。1件も試していない日は、当然、失敗も0件になります。
「落ちた件数」だけを見て、「やるべきだった件数」を見ていませんでした。
いまは予定表から「その時点で判定期限を過ぎている件数」を数え、プロセスの終了コードも読むようにしています。既知の失敗日4日ぶんに当てて、鳴ることを確認済みです。
監視は、既知の失敗に当てて鳴ることを確かめて、はじめて監視です。
鳴らない監視は、無いより悪い。 「異常なし」という嘘をつくからです。
次にやること
指標の水準は、市場に織り込まれていました。これは確定です。
ただ、ここまで見ていたのはいつもある1点の値でした。手元の記録には、締切の120秒前から20秒前まで、複数の時点が残っています。「最後の100秒で、その指標がどちらへ動いたか」は、まだ一度も測っていません。
水準が織り込まれていても、変化──終盤に入ってくるお金の向き──は別の情報かもしれません。次はそこを測ります。
この記事の数字について: いずれも事後の集計であり、事前に登録した仮説の検証ではありません。良い数字が出ていないので実害はありませんが、もしここから何かを使うなら、改めて前向きに登録してから測り直します。当ブログは、うまくいかなかった記録もそのまま残す方針です。
的が近くなっても、払いが渋ければ同じことか。
