はじめに
近年、AIを活用したソフトウェア開発の方法は大きく変化しています。
特に、Cursor、Claude Code、OpenAI CodexといったAIコーディングツールの登場によって、従来であれば複数人のエンジニアが担当していた設計・実装・テスト・修正といった作業を、AIエージェントと協力しながら進められるようになりました。
その中でも、今回取り上げたいテーマは「競馬AIの予測モデル構築」です。
競馬AIは、単純に過去のレース結果を分析して勝ち馬を予測するだけのシステムではありません。
馬の能力、騎手、調教師、競馬場、距離、馬場状態、枠順、過去の成績、オッズなど、複数の要素を組み合わせて確率的に予測する必要があります。
さらに、モデルの予測精度だけでなく、実際の馬券購入を想定したバックテストや回収率の検証も必要です。
このような開発では、AIコーディングツールの選択が開発効率や品質に影響します。
私はこれまで約8年間のエンジニアリング経験があり、そのうち約3年間はAI開発にも携わってきました。
実際に、Next.js、React、TypeScript、Python、データベース、外部API連携などを利用したシステム開発を経験しています。
例えば、オンラインサービスの開発では、約22,000行のコード、196ファイル、54コミット規模のシステムを19日間で納品した経験があります。
また、Claude Codeを利用したAndroid自動化ブラウザの試作では、約7.5時間で動作するプロトタイプを構築しました。
こうした開発経験を踏まえ、今回は競馬AIのモデル構築という観点から、3つのツールの特徴と実務での使い分けを考察します。
なお、上記は実際のシステム開発実績であり、競馬AIの的中率や回収率の実測結果ではありません。本記事では競馬モデルの未検証の数値を実績として扱わず、評価方法も含めて解説します。
1. まず理解したいCursor・Claude Code・Codexの違い
最初に理解しておきたいのは、この3つは完全に同じカテゴリーの製品ではないということです。
| ツール | 主な役割 | 得意な作業 |
|---|---|---|
| Cursor | AI統合型コードエディタ | コード編集、実装、デバッグ |
| Claude Code | AIコーディングエージェント | 設計、複数ファイルの実装、リファクタリング |
| OpenAI Codex | AIコーディングエージェント | 実装、テスト、コードレビュー、並列作業 |
Cursorはエディタとしての使いやすさとAIエージェント機能を組み合わせています。
Claude CodeはターミナルやIDEから利用し、既存のコードベースを理解しながら複数のファイルを変更できます。
Codexはローカル環境、IDE拡張機能、デスクトップアプリ、クラウドなど複数の形態で開発作業を進められます。
つまり、Cursorは開発環境としての役割も大きく、Claude CodeとCodexは開発作業を自律的に進めるエージェントとしての性格が強いと考えられます。
この違いを理解せずに比較すると、適切な選択ができません。
2. Cursorは競馬AIの開発環境として優れているのか？
Cursorの大きなメリットは、開発中のコードを確認しながらAIに修正や実装を依頼できることです。
競馬AIの開発では、Pythonを利用したデータ分析や機械学習だけでなく、学習結果の可視化、管理画面、予測結果の表示なども必要になります。
例えば、次のような開発です。
- Pythonによる競馬データの前処理
- PandasやPolarsを利用したデータ分析
- LightGBMやXGBoostによる予測モデルの実装
- PostgreSQLを利用した競馬データの管理
- APIによる予測結果の提供
- Next.jsによる予測結果のダッシュボード構築
これらを1つの開発環境で管理できることは大きなメリットです。
CursorのAgent機能は、複数ファイルの編集、ターミナルコマンドの実行、テストや修正などにも対応しています。
また、Ask、Plan、Debugといったモードを使い分けられるため、調査と実装を分離しやすい点も評価できます。
私がCursorを評価するポイント
競馬AIは、モデル構築だけで開発が完了するわけではありません。
データ取得、前処理、モデル学習、予測API、管理画面まで一貫して構築する必要があります。
そのため、コード全体を見渡しながら作業できるCursorは、日常的な開発環境として有力な選択肢です。
3. Claude Codeは複雑な競馬AIのモデル構築に向いているのか？
私が実際の開発で特に注目しているのがClaude Codeです。
Claude Codeの強みは、単純なコード生成だけではなく、既存システムの構造を把握しながら、複数のファイルにまたがる開発作業を進められる点です。
競馬AIの開発では、次のような処理を分離して管理する必要があります。
- 競馬データの取得
- データのクリーニング
- 特徴量エンジニアリング
- 学習データの生成
- モデルの学習
- モデルの評価
- バックテスト
- 予測結果のAPI化
例えば、予測精度が低下した場合、単純にモデルのパラメータだけを変更すればよいとは限りません。
データの欠損、特徴量の設計、学習期間、データリーク、予測時点のオッズなど、複数の原因を調査する必要があります。
このような場合、Claude Codeにプロジェクト全体を調査させ、問題の原因を特定したうえで修正計画を作成させる使い方が有効です。
私自身、Claude Codeを利用した試作開発で約7.5時間という短時間でプロトタイプを構築した経験があります。
ただし、短時間で実装できることと、機械学習モデルの予測精度が高いことは別問題です。
競馬AIでは、生成されたコードが正しく動くことだけでなく、統計的に妥当な評価ができているかを確認する必要があります。
私がClaude Codeを評価するポイント
複雑なシステムの設計、複数ファイルにまたがる実装、既存コードの分析、テストの追加など、開発全体を進める場面で活用したいツールです。
4. OpenAI Codexはどのような場面で活用できるのか？
Codexの特徴は、開発タスクをエージェントに任せ、実装や検証を進められることです。
競馬AIの開発で考えると、例えば次のようなタスクが考えられます。
- 既存の学習コードのレビュー
- データ前処理のバグ調査
- 特徴量生成処理のテスト作成
- モデル評価プログラムの実装
- バックテスト処理の修正
- Gitの変更内容の確認
- 複数の開発タスクの並列処理
特に注目したいのが、Git worktreeなどを利用した作業分離です。
例えば、メインの開発環境では予測モデルを改善しながら、別の作業環境でバックテストの実装を進めることができます。
これによって、同じファイルを複数のエージェントが同時に変更するリスクを抑えながら、開発を並行して進められます。
ただし、並列化すれば必ず開発時間が短縮されるわけではありません。
各エージェントの担当範囲、ファイルの競合、依存関係を明確にする必要があります。
私がCodexを評価するポイント
実装だけでなく、独立した視点からコードを検証する役割として活用することに価値があると考えています。
5. 競馬AIのモデル構築では何を実装するべきなのか？
ここからは、実際に競馬AIを構築する場合の技術的な設計について説明します。
私が最初に取り組むべきだと考えるのは、ディープラーニングを導入することではありません。
まずは、競馬データを正しく整理し、予測に必要な特徴量を設計することです。
5-1. 競馬データの構造
例えば、以下のデータを利用します。
| データ項目 | 特徴量としての役割 |
|---|---|
| 馬の過去成績 | 馬の能力・安定性 |
| 騎手 | 騎手ごとの成績 |
| 調教師 | 調教師ごとの成績 |
| 競馬場 | コース適性 |
| 距離 | 距離適性 |
| 馬場状態 | 良・稍重・重・不良 |
| 枠順 | 枠順による影響 |
| 馬体重 | 馬体の変化 |
| 過去の上がり3F | 終盤の走力 |
| オッズ | 市場の評価 |
重要なのは、予測を実行する時点で取得できるデータだけを特徴量に利用することです。
例えば、レース終了後に確定する着順や払戻金を学習時の特徴量に混入させてしまうと、実際の予測では再現できない情報をモデルが学習してしまいます。
これがデータリークです。
競馬AIでは、この問題を特に注意する必要があります。
5-2. 最初に採用したい機械学習モデル
私なら、最初から複雑なニューラルネットワークを採用するのではなく、以下のモデルから検証を開始します。
| モデル | 主な用途 |
|---|---|
| Logistic Regression | 基準となる勝率予測 |
| Random Forest | 非線形な特徴量の分析 |
| XGBoost | 高精度な分類・予測 |
| LightGBM | 大規模な表形式データの学習 |
| CatBoost | カテゴリ特徴量の活用 |
| Neural Network | 複雑な関係性の学習 |
特にLightGBMやXGBoostは、競馬のような表形式データを扱う際の比較対象として有力です。
最初にシンプルなモデルを作り、その後に高度なモデルと比較する方が、改善の効果を判断しやすくなります。
5-3. 予測対象を明確にする
競馬AIでは、何を予測するかによってモデルの設計が変わります。
例えば、
- 1着になる確率
- 3着以内に入る確率
- 各馬の着順
- 特定の馬券が的中する確率
- オッズに対する期待値
これらは同じ問題ではありません。
個人的には、最初に1着確率の予測モデルを構築し、その後に複勝圏の確率予測や馬券ごとの期待値計算へ拡張する方法が分かりやすいと考えています。
6. 競馬AIで本当に重要なのは的中率ではなく回収率
ここは競馬AIの開発で特に重要なポイントです。
例えば、予測モデルの的中率が高くても、人気馬ばかりを選択している場合、必ずしも利益につながるとは限りません。
競馬AIでは、以下の指標を分けて評価する必要があります。
| 評価指標 | 意味 |
|---|---|
| Accuracy | 分類の正解率 |
| Precision | 予測した対象のうち正解した割合 |
| Recall | 実際の対象をどれだけ検出できたか |
| Log Loss | 予測確率の品質 |
| Brier Score | 予測確率と実際の結果の誤差 |
| ROI | 投資金額に対する払戻金の割合 |
特に、確率予測を行う場合はLog LossやBrier Score、予測確率のキャリブレーションも重要です。
回収率は次の式で計算できます。
回収率（%）＝総払戻金 ÷ 総購入金額 × 100
例えば、10万円を購入して12万円の払戻金があれば、回収率は120%です。
ただし、1回や数十回の結果だけでモデルの優秀さを判断することはできません。
実際には、一定期間のアウト・オブ・サンプルデータを使って、継続的なバックテストを実施する必要があります。
期待値の計算
例えば、ある馬の予測勝率が35%、単勝オッズが3.2倍だったとします。
期待回収率は次のようになります。
0.35 × 3.2 = 1.12
理論上の期待回収率は112%です。
ただし、これは予測確率が正しく校正されており、購入時点のオッズを正しく取得できていることが前提です。
また、実際の競馬ではオッズ変動や控除率なども考慮しなければなりません。
AIが予測した確率と市場のオッズを比較することで、単純な的中予測とは異なる判断が可能になります。
7. Cursor・Claude Code・Codexを組み合わせた開発方法
私なら、競馬AIの開発では3つのツールを競合させるのではなく、役割を分担させます。
例えば、以下のような構成です。
| 開発工程 | 使用するツール | 担当内容 |
|---|---|---|
| システム設計 | Claude Code | アーキテクチャ・処理設計 |
| データ分析 | Cursor | Pythonコードの編集・確認 |
| 特徴量生成 | Claude Code | 特徴量設計と実装 |
| モデル学習 | Cursor | 学習コード・実験管理 |
| バックテスト | Codex | 検証コードの実装・レビュー |
| バグ調査 | Codex | 独立した観点からの調査 |
| 最終統合 | Cursor | コードの確認と統合 |
これは各ツールの能力を固定的に順位付けしたものではなく、開発工程に応じた私の推奨ワークフローです。
特に重要なのは、同じAIに実装と検証をすべて任せないことです。
例えば、Claude Codeがモデルを実装した場合、Codexに以下の内容を確認させます。
- 学習データとテストデータが混在していないか
- 未来の情報を特徴量に使用していないか
- オッズの取得時点は正しいか
- 回収率の計算に誤りがないか
- 過去のレース結果を不適切に再利用していないか
- テストケースが十分に用意されているか
こうすることで、単なるコード生成から、検証可能なAI開発へと進められます。
8. 開発で採用したい数値ベースの検証方法
AI開発ツールの比較でも、感覚だけで優劣を判断するべきではありません。
私なら、同じ競馬AIプロジェクトを使って、以下のような比較実験を設計します。
AI開発ツールの比較実験
| 評価項目 | 検証方法 |
|---|---|
| 実装時間 | 同一タスクの完了時間 |
| テスト成功率 | 自動テストの成功数 |
| バグ発生数 | 実装後に発見された不具合数 |
| 修正回数 | 人間による修正・再指示の回数 |
| コード品質 | 保守性・可読性・設計の妥当性 |
| 開発コスト | API利用料・サブスクリプション費用 |
| 再現性 | 同一条件での結果の安定性 |
実験するなら、例えば10種類の共通タスクを用意し、各ツールで3回ずつ実施します。
合計30回の実行結果を比較することで、単発の成功例に左右されにくくなります。
ただし、これは今後実施するための比較実験の設計であり、現時点で私が測定した30回の実測結果ではありません。
また、競馬AI自体の検証では、例えば以下のような時系列分割を採用できます。
- 2018〜2023年：学習データ
- 2024年：検証データ
- 2025年：最終テストデータ
これはデータが確保できた場合の設計例です。
ランダムにデータを分割するのではなく、過去から未来に向かって検証することが重要です。
さらに、ローリング方式で学習期間を更新しながら複数期間の成績を確認することで、特定の年だけに依存したモデルになっていないかも判断できます。
最終的には、的中率だけでなく、購入件数、回収率、Log Loss、Brier Score、条件別の成績を記録するべきです。
9. 結論：結局、どれを選ぶべきなのか？
私の結論は、3つのツールの中から必ず1つだけを選ぶ必要はないということです。
それぞれに得意な領域があります。
Cursor
日常的な開発環境としておすすめです。
Python、TypeScript、SQLなど複数の言語を扱いながら、コードの確認や修正を効率的に進めたい場合に適しています。
Claude Code
複雑なシステム設計や大規模なコードベースの変更に活用したいツールです。
競馬AIのデータ処理からモデル構築まで、一連の開発工程を進める際に有力です。
OpenAI Codex
独立した実装やコードレビュー、テスト、並列タスクなどに活用したいツールです。
既存のコードに対して別の視点から検証を行うことで、品質向上につなげられます。
私なら、Cursorを中心的な開発環境として利用し、Claude Codeを設計・実装のパートナー、Codexを検証・レビューのパートナーとして組み合わせます。
ただし、予算や開発規模によっては、まず1つを選んで開発を始める方法でも十分です。
10. 最後に：AI開発で最も重要なのはツールではなく設計力
競馬AIを構築する場合、最新のAIコーディングツールを導入したからといって、予測精度が自動的に向上するわけではありません。
重要なのは、どのデータを取得し、どの特徴量を設計し、どのモデルを採用し、どのような方法で検証するかです。
AIコーディングツールは、その開発工程を効率化するための手段です。
私自身、実際のWebシステムやAI関連システムの開発を通じて感じているのは、AIにすべてを任せる開発よりも、エンジニアが適切な設計と検証の基準を持ち、AIエージェントを使い分ける開発の方が重要だということです。
今後、競馬AIを本格的に開発するのであれば、まずは過去のレースデータを整理し、LightGBMなどの基準モデルを構築し、時系列バックテストによって予測確率と回収率を検証するところから始めたいと考えています。
そして、Cursor・Claude Code・Codexを適切に組み合わせることで、データ分析からモデル構築、API化、運用までを一貫して開発できる体制を作ることが重要だと思います。
AI時代のエンジニアに必要なのは、AIにコードを書かせる能力だけではありません。AIが生成した結果を技術的・統計的に正しく評価できる能力です。
これこそが、競馬AIのようなデータ依存型システムを開発するうえで、最も重要なポイントだと考えています。
参考資料
- Cursor公式ドキュメント：https://docs.cursor.com/
- Claude Code公式ドキュメント：https://code.claude.com/docs/
- OpenAI Codex：https://developers.openai.com/codex/
- LightGBM：https://lightgbm.readthedocs.io/
- XGBoost：https://xgboost.readthedocs.io/
- Scikit-learn：https://scikit-learn.org/stable/