Codex 競馬予想を作るデータ分析の進め方と検証手順入門

Codex競馬予想を「分析ツール」として考える

競馬の結果は、出走条件、過去の成績、距離、馬場、人気、開催日の状態など多くの要素が重なって決まります。しかも、同じ条件が二度とそのまま再現されるとは限りません。そのため「この馬が必ず勝つ」という答えを作るより、ある時点で入手できた情報から、どんな仮説を立て、どの程度の不確かさが残ったかを確認できる道具にする方が、ソフトウェアとして扱いやすくなります。Codexはリポジトリの構造を読み、データの読み込み、変換、可視化、テストまでを一つの作業として整理できますが、分析の問いそのものを曖昧にしたまま任せると、もっともらしい数字だけが増えてしまいます。

OpenAIの公式情報でも、Codexはコードを書く場面だけでなく、データ変換や構造化された分析のような作業へ利用範囲が広がっていると説明されています（How agents are transforming work）。この題材で大切なのは、競技結果を当てる機械を作ることではありません。入力データの時点を固定し、同じ条件なら同じ計算を再現でき、外れたときに原因を追跡できる分析プロジェクトを作ることです。

なぜ今、Codexで競馬予想を扱うのか

Codex CLI 0.149.1は2026年8月24日に公開され、GitHubの公式リリースページでは安定版として表示されています。さらに同日付のOpenAI公式リリースノートでは、codex mcp-server コマンドを非推奨とし、Codex app serverを利用する案内が出ています。今回のように手元のCSVを読み込んで分析する題材なら、外部接続に頼らず、CLIとPythonの小さなプロジェクトだけで始められます。新しい入口を次々に足すより、版番号、使用データ、評価結果をメモに残す方が、更新後の差を見つけやすい時期です。

予想とソフトウェアの責任を分ける

予測値は、過去のデータから作った仮説の出力です。確率が高い表示を勝敗の約束へ読み替えたり、少数の的中例だけを取り上げたりすると、分析の目的から外れます。記事で紹介する範囲では、利用者が持つデータを使って特徴量を計算し、基準値とモデルを比較し、結果を保存するところまでを対象にします。金額、購入、払戻を扱う機能は追加せず、出力画面にも「検証用の推定値」と表示しましょう。対象データの利用条件や掲載元の規約も、コードを書く前に確認する必要があります。

データ分析ツールの設計を先に決める

最初から大きなモデルや多くの画面を作ると、どこで数字が変わったのか追いにくくなります。まずは一つのCSVを読み、列の型をそろえ、単純な基準値を出し、結果を保存するところまでを完成させます。その後に特徴量やモデルを一つずつ追加し、追加前後の差を表に残します。Codexへ依頼するときも「すべて作って」ではなく、今あるファイル、追加するファイル、実行方法、完了条件を明示すると、変更範囲と確認範囲がそろいます。

プロジェクトの構成は、分析の段階を読み手に見せるために単純にします。たとえば次のように、元データ、変換処理、検証結果を分けて置きます。

keiba-analysis/
├─ data/
│  └─ races.csv
├─ src/
│  ├─ features.py
│  ├─ train.py
│  └─ evaluate.py
├─ tests/
│  └─ test_features.py
├─ reports/
│  └─ evaluation.md
├─ requirements.txt
└─ README.md

Step 1: 目的と評価指標を一文で固定する

最初の一文は「次のレースの勝ち馬を当てる」ではなく、「指定した日付までの情報から、上位3着以内になる確率を推定し、翌月の結果で評価する」のように書きます。ここには予測対象、利用できる時点、評価する期間の三つが含まれています。対象を1着だけにするか3着以内にするかで、ラベルの偏りも指標の読み方も変わります。Codexへ渡す要件には、予測対象を変えないこと、評価期間を学習へ戻さないこと、出力に対象日を残すことまで入れておくと、後から都合のよい条件へ変わりにくくなります。

的中数だけで評価するのも危険です。予測確率が高い順に並べるランキングの質、陽性をどれだけ拾えたか、確率と実際の割合が近いかを分けて見ます。基準値として「人気順をそのまま使う」「全件に同じ確率を出す」方法も残してください。複雑なモデルが基準値を安定して上回らないなら、特徴量を増やす前にデータの時点と評価方法を疑うべきです。

Step 2: 入力データの境界と保存形式を揃える

最初のCSVには、レースを識別するキー、開催日、競馬場、距離、馬番、馬名、事前に取得したオッズ、結果を入れます。馬名は表示用に使い、学習用の識別には一意なIDを持たせます。日付は文字列のまま比較せず、読み込み時に日付型へ変換し、欠損値の扱いを決めます。データを追加するたびに取得日時と対象期間を記録し、レース後に追加される情報が、レース前の入力へ紛れないようにします。

race_date,venue,race_id,horse_id,horse_name,horse_no,odds,finish_position,course,distance,weather
2026-07-05,東京,R001,H001,サンプルホース,3,4.8,2,芝,1600,晴

この例は形式を示すための架空データです。実際のデータを使うときは、提供元が許可している範囲で取得し、個人を識別できる情報を入れないでください。オッズの取得時点、結果の確定時点、欠損が発生した理由をREADMEへ書けば、Codexが列の意味を取り違えにくくなります。

Codexに小さく実装させる

Codexを使うときは、コードを出させる前に調査結果を返させるのが有効です。既存ファイルを読んだうえで、列の型、未確定の仕様、変更対象、実行する確認を列挙させます。次に一つのファイルを作らせ、テストを実行し、結果を確認してから次へ進みます。分析では「動くコード」と「正しい評価」が別物なので、エラーが消えたことだけを完了条件にしないようにします。

分析の出力を表計算の一枚の数字で終わらせず、入力データの範囲、実行したコード、評価期間、失敗例を同じ場所に残します。そうすればCodexの更新やモデルの変更があっても、前の結果との差分を追跡できます。

Step 3: 初回依頼は調査・提案・実装に分ける

最初の依頼文は、テーマ、入力、禁止事項、成果物、確認方法を一続きで書きます。以下のように、最初は構成案と不明点だけを返させ、その回答を読んでから実装へ進めます。

このフォルダを競馬結果の分析用Pythonプロジェクトとして調査してください。
まずファイル構成、CSVの列型、欠損値、日付の範囲、結果列の意味を確認し、変更はまだ行わずに報告してください。
目的は、レース開始前に得られる情報から「3着以内」の確率を推定し、後の期間で評価することです。
レース後に分かる着順や払戻を特徴量へ入れないでください。購入や勝敗を勧める画面も作らないでください。
次に作るファイル、テスト方法、未来情報の混入を確認する方法を提案してください。

この依頼のよい点は、Codexに分析上の判断を隠れて決めさせないことです。データの列が曖昧なら、勝手に補完せず質問として残させます。要件が固まった後も、変更したファイルと変更理由を返すように頼みます。公式の Codex CLIドキュメント にはCLIの入口や関連機能が整理されているため、利用している版と説明が一致するかを確認しながら依頼文を調整できます。

Step 4: ベースラインとテストを先に置く

最初の実装は、過去の平均や人気順のような単純な基準値で十分です。基準値を先に出すと、機械学習モデルを加えたときに何が改善したのか説明できます。たとえば、特徴量作成関数が入力行数を変えないこと、対象日より後の行を参照しないこと、欠損を決めた方法で扱うことをテストにします。Codexには実装と同じ依頼の中で、正常系だけでなく空のCSV、重複したレースID、日付が壊れた行のテストも作らせます。

import pandas as pd


def load_races(path: str) -> pd.DataFrame:
    df = pd.read_csv(path, parse_dates=["race_date"])
    required = {"race_date", "race_id", "horse_id", "odds", "finish_position"}
    missing = required.difference(df.columns)
    if missing:
        raise ValueError(f"missing columns: {sorted(missing)}")
    if df["race_id"].duplicated().any():
        raise ValueError("race_id must be unique")
    return df.sort_values(["race_date", "race_id"]).reset_index(drop=True)


def make_target(df: pd.DataFrame) -> pd.Series:
    return (df["finish_position"] <= 3).astype("int8")

このコードは予測器ではなく、入力を固定するための土台です。finish_position は結果が確定した後の列なので、学習の目的変数としては使えても、レース前の特徴量には使えません。Codexにコードを生成させるときは、この区別をREADMEにも書かせ、関数名と列名だけを見ても役割が分かる状態にします。

未来情報を混ぜない特徴量を作る

競馬予想のサンプルで最も起きやすい失敗は、計算式の難しさではなく情報の時点を間違えることです。全期間の平均着順を先に計算し、その値を過去のレースにも付けると、未来の結果を過去へ漏らすことになります。同じ馬の直近成績を使う場合も、対象レースより前の行だけを残してから移動平均を計算しなければなりません。Codexには特徴量の式だけでなく、「対象日より後の行が計算に入っていないことをどう確認するか」まで説明させます。

過去走から作る特徴量

安全に扱いやすいのは、対象レースの前日までに確定している情報です。直近3走の着順平均、過去の出走回数、同じ競馬場での出走回数、距離帯ごとの成績、前走からの日数などが候補になります。ただし、データが少ない馬に平均を無理に作ると、数字の揺れが大きくなります。出走数を別の列として持ち、少ない観測値と十分な観測値を同じ重みで読まない設計にします。馬名の文字列をそのまま強い特徴量にするより、識別ID、期間、条件を明確に分ける方が再現性を保ちやすくなります。

移動平均を作るときは、まず馬ごとに日付で並べ、対象行を除外してから過去だけを集計します。実装後には、あるレースの日付を一日進めたとき、追加される過去データがそのレースより前に限られることを小さなテストで確認します。Codexへは「処理前後のサンプル行を表示し、計算に使ったレースIDを追跡できるようにしてほしい」と頼むと、見えない漏れを発見しやすくなります。

オッズを使う場合の注意

オッズはレース前に取得した値なら特徴量にできますが、取得時点を必ず保存します。確定後の人気順位や払戻率へ置き換えられた列を混ぜると、結果を知った後の情報になり得ます。オッズを使わないモデルと使うモデルを並べ、改善が単なる市場情報の再現なのか、過去走や条件の特徴が寄与したのかを比較してください。欠損したオッズを平均で埋めるときも、全期間の平均ではなく学習期間だけで計算する必要があります。

リーク検査用の依頼文を作る

Codexには、完成した特徴量の一覧を読み、各列について「レース前に取得できるか」「対象日より後の行を参照していないか」「欠損処理が学習期間を越えていないか」を表にして報告させます。問題がないと断定させるのではなく、確認できない前提と追加テストを残させるのがポイントです。公式の Codexの安全な実行に関する説明 も参照し、作業場所と入力データの範囲を必要最小限にしてください。

時系列で精度を確かめる

過去のレースを無作為に混ぜて学習用と評価用へ分けると、未来の傾向が学習側に入り、実際の利用時よりよい数字が出ることがあります。競馬のように日付で状況が変わるデータでは、古い期間で学習し、その後の期間で評価する分け方が基本です。学習期間を広げる場合も、評価期間の情報を前処理へ使っていないかを確認します。モデルの種類を増やすより、分割が現実の利用順序を再現しているかを先に見てください。

短い評価期間だけで良い結果が出ても、偶然の影響を除いたとは言えません。複数の期間を同じルールで比べ、結果が崩れる条件も残すことで、数字を過大評価しにくくなります。

Step 5: 日付で学習・検証・テストを分ける

たとえば2025年までを学習、2026年の前半を検証、2026年の後半を最終テストとします。実際の期間はデータ量に合わせて決めますが、テスト期間を見ながら特徴量や閾値を何度も調整してはいけません。検証期間で候補を比べ、最後に一度だけテスト期間へ適用します。複数の期間を順番にずらして確かめたい場合は、scikit-learnのTimeSeriesSplit の考え方を参考にし、各分割の境界日と行数をレポートへ保存します。

結果には、期間、件数、陽性数、使った特徴量、モデル、閾値、指標を同時に書きます。日付の境界が分からないレポートは、数字が正しくても再現できません。Codexには評価関数を作るとき、「データを受け取った順番を保持する」「期間ごとの行数を表示する」「テスト期間から設定を学習しない」という条件をテストコードへ落とし込ませます。

Step 6: 指標を複数並べて読む

上位3着を陽性とした場合は、正解率だけでなく適合率、再現率、ROC-AUC、確率の校正を見ます。陽性が少ないデータでは、全件を陰性と予測しても正解率が高くなるためです。ランキングとして見るなら、予測確率の上位に実際の上位馬がどれだけ集まったかを期間別に示します。確率0.7と表示した集合が本当に約70％になるのかも確認し、外れているなら表示値を断定的に扱わないようにします。

評価の文章は、良かった数字だけでなく、基準値に負けた期間、欠損が多い条件、データが少ない競馬場も記録します。少数の期間だけ良い結果が出たなら、特徴量を増やして説明を難しくする前に、対象期間を変えて同じ傾向が続くかを確かめます。予測値を画面へ出す場合は、評価期間、モデル版、データ取得時点を近くに表示し、結果だけが切り取られないようにします。

Codexへレビューと改善を頼む

分析コードが動いた後こそ、Codexをレビュー役として使います。依頼には変更差分、実行したテスト、評価レポート、既知の制限を添え、「改善案を直接適用する前に、問題の重要度と根拠を報告して」と書きます。特に確認したいのは、日付順が崩れていないか、学習と評価の処理が同じ関数に混ざっていないか、乱数を固定しても結果が変わる箇所がないか、CSVの列追加で古いレポートが読めなくならないかです。

Codexには、次のようなレビュー観点を一つずつ渡せます。

1. 入力列のうち、レース前に確定していない列が特徴量へ入っていないか確認する。
2. 日付で並べた後に、対象期間より未来の行が前処理へ入っていないか確認する。
3. 基準値、モデル出力、最終評価の計算を分け、同じデータを二重利用していないか確認する。
4. 欠損、重複、未知の競馬場、極端なオッズを含むテストを追加する。
5. READMEにデータの出典、取得時点、評価期間、利用上の注意を追記する。

この順番なら、見た目の改善よりも再現性と説明可能性を先に整えられます。レビュー結果に「問題なし」と書かれていても、その根拠となるテスト名や確認した列を返させます。人が差分を読み、必要な修正だけを受け入れることが、AIコーディングエージェントを分析へ使うときの重要な確認点です。

結果を共有するときの注意

競馬予想の分析結果は、コードとデータの条件を離れると意味が変わります。記事や社内資料へ載せるときは、対象期間、入力の締切時点、欠損処理、評価指標、基準値との比較、外れた期間を併記してください。「的中率が高い」という一文だけでは、対象数や選び方が分からず、読者が再現できません。分析用のCSVを公開できない場合は、架空データでコードの動作だけを示し、実データの取得方法を推測させる書き方を避けます。

また、データ提供元の利用条件を守り、個人情報や非公開の会員情報を入力しないことも基本です。Codexへ渡すフォルダには、分析に不要なファイルを置かず、作業場所の権限を狭く保ちます。OpenAIの Codex CLI公式ドキュメント と サンドボックスの説明 を確認し、読み取りだけでよい検証と、ファイルへ書き込む作業を分けてください。外部接続を追加する場合は、接続先、送信する列、保存期間、停止方法を先に決めます。

予測値を断定しない表示にする

画面の見出しは「勝つ馬」ではなく「上位3着以内の推定確率」や「検証期間の結果」にします。確率の横には学習期間と評価期間を表示し、データが少ない場合は「参考値」と明示します。購入額や払戻を計算するボタンを追加しないだけでも、分析ツールと判断支援の境界が分かりやすくなります。Codexに画面を作らせるときは、これらの表示条件を受け入れ条件として書き、後から省かれないようにテストか画面確認の項目へ残します。

更新後の差を小さく確認する

Codex CLIを更新したら、いきなり全データを再計算せず、同じ入力の少量サンプルで読み込み、特徴量、評価レポートが以前と同じになるかを確認します。0.149.1のような版番号の更新と、公式リリースノートで案内されたコマンドの変更は別々に記録し、どちらが結果へ影響したかを切り分けます。版、Python、主要ライブラリ、データのハッシュ、実行日時をREADMEへ残せば、後で差分を追いやすくなります。

まとめ

Codex 競馬予想を実用的に扱う近道は、予測の断定を求めることではありません。まず分析の目的を上位3着以内など検証可能な問いへ変え、入力データの時点を固定し、単純な基準値を置きます。次にCodexへ調査、実装、テスト、レビューを小さく依頼し、未来情報の混入を避けた時系列評価を行います。最後に結果だけでなく、期間、条件、限界、版番号を保存します。2026年8月の公式更新を追いながらも、題材の派手さより、同じ入力から同じ説明を再現できる分析ツールを育てることが大切です。