【Excelは今すぐ捨てろ】30万馬券を逃した現役エンジニアが、競馬専用SQLiteデータベースをゼロから削り出した執念!Alma Core Pro開発記 #1

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

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

突然ですが、皆さんは競馬でこんな経験はありませんか？

とある日曜日の最終レース。

競馬ブックの印◎を軸に、JRA-VANアプリのタイム型・対戦型上位馬へ三連複フォーメーションを組む。

お気に入りの騎手が跨る勝負馬に厚い印が集まり、 「よし！ 単勝2.0倍、展開もドンピシャや！」 「これはもらったやろ！」

……自信は、満ち溢れていました。

しかし数分後。冷めきった缶コーヒーを片手に、私はPCの前で頭を抱えて絶望していました。

画面の向こうで激走したのは、単勝50倍を超す大穴。

確定したオッズは、三連複30万馬券。

悔しくてたまらず、レース後にTARGETを開いてその穴馬のデータを血眼で洗い直したんです。すると――。

中間の坂路で自己ベストを叩き出し、前走は極悪ハイペースを前目でただ1頭粘り倒している。

「買えたやん！ データを物理的に見たら、完全に買えた馬やんけ！！」

「なんでこの馬の『前走個別ラップ』と『坂路時計』がここまで優秀やのに、市販の指数やオッズは無印のゴミ扱いなんや！？」

叫んでも、失った30万馬券は返ってきません。

なぜTARGETやExcelでは「勝てるデータ」に届かないのか？

TARGETには、数十万件ものデータが腐るほど詰まっています。

ZI指数、マイニング、外部指数の取り込み……機能も豊富です。

でも、「自分が本当に欲しい形での物理解析」ができないんです。

悔しさのあまり、データをExcelにコピペしてクロス集計し、GEOMEAN（相乗平均）関数を走らせて簡単なCSVデータベースを作ろうとしました。

しかし、立ちはだかったのは「圧倒的な手間の壁」でした。

• 毎週、何十レース分も手作業でコピペする不毛な時間

• レースごとに計算式や条件式をあぁでもない、こうでもないと書き直すストレス

• データ量が増えるたびにカクつき、フリーズする緑の画面（Excel）

締め切り5分前の殺気立った現場で、そんな悠長な作業ができるわけがありません。

思うような解析結果も出ず、イライラが募るばかり。

そんなある夜、作業画面を見つめながら、ふと我に返ったんです。

「待てよ……。俺、工場の自動化機械や制御盤を設計しとるエンジニアやぞ？」

工場のタッチパネル（HMI）なら、現場の作業員がパニックを起こさないよう、必要なスイッチやリアルタイムの計測値をミリ単位で1画面に美しく配置する。異常があれば瞬時にインターロックをかけ、コンマ数秒でトラブルを知らせる。

それなのに……。

「なんで命金を張る競馬の現場で、他人が作った不便なソフトに文句を言いながら、締め切り前にエクセルカタカタ叩いとんねん！」

しかも、しっかり負けとるやないかい（笑）！

「他人のツールに文句を垂れる暇があったら、現場のエンジニアとして、自分が100%勝ち切るための『最強の兵器』をゼロから削り出したったらええやん！」

この猛烈な悔しさと技術屋のプライドが、すべての始まりでした。

こうして、完全自作の競馬データ解析エンジン『Alma Core Pro』、そして専用操作盤GUI『Alma MDI Pro』を削り出す、狂気の開発プロジェクトが幕を開けたのです。

予想ロジックから入る奴は、100%挫折する

競馬ソフトを自作しようと思い立った人の9割は、いきなり「最強のAI機械学習モデル」や「見栄えのいいリッチな画面」から手をつけて、数ヶ月後に音もなく挫折します。

機械設計をやっていれば、理由は一発で分かります。

基礎フレーム（土台）の剛性が狂っているのに、その上にいくら1000馬力のモーターを載せたところで、共振して一瞬でバラバラに壊れるに決まっているからです。

競馬データは、JRA数十年の歴史の塊です。

1レースごとに18頭の馬体重、オッズ、ラップ、通過順、ミリ単位の調教時計……膨大なパラメータがぶら下がっている。

この生データをミリ秒単位で引き抜き、物理シミュレーションにかけるためには、何よりもまず「数十年分の負荷がかかっても絶対に歪まない、強固な器（データベース）」を削り出すのが絶対条件でした。

Excelは論外。サーバー型も却下。なぜ「SQLite」なのか？

データの置き場所を決めるにあたり、まず検討したのがデータベースの選定でした。

1. Excel / CSV：論外。数十万件のレコードを突っ込んだ瞬間にメモリを食い尽くして即死します。

2. MySQL / PostgreSQL：性能は本物ですが、個人開発には重すぎる。ポートを開けて常駐させ、PCを買い換えるたびに環境構築で丸一日潰す……そんなメンテナンスの無駄に週末の時間を奪われたくありません。

そこで私が導き出した結論が、「SQLite」でした。

「えっ、SQLite？ スマホの電話帳アプリに使うような軽量DBやろ？」とナメてかかる人がいます。

……君、この怪物を完全に舐めてますよ（笑）。

• .dbファイル1個で完結する（バックアップもファイルをUSBにコピペするだけで0.5秒で完了）

• Python標準ライブラリで動き、外部依存が極小（環境構築が一瞬で終わる）

• ローカル動作のため、ネットワーク通信の遅延（レイテンシ）が完全ゼロ

• 適切なインデックスさえ張れば、数百万行のレコードから目的のラップデータをコンマ数秒でぶち抜く

外部依存がなく、シンプルで頑丈、かつ高剛性。

まさに工場の過酷な現場で24時間365日、何十年もノーメンテナンスで動き続ける「三菱電機やオムロンのシーケンサー（PLC）」のような圧倒的信頼感です。

競馬ブックの生データを飲み込む「29テーブルの骨格」

器が決まれば、次は中身です。

私が解析の心臓部に選んだのは、万人向けに丸められたJRA-VANのデータではなく、トラックマンの泥臭い取材メモや精密な調教時計が詰まった「競馬ブック（KD3）」の生データでした。

この膨大な生データを迎え撃つため、SQLiteの中に専用の正規化テーブル構造をガチガチに設計しました。

• 出馬表（kol_den1）：枠順や当日の出走情報

• 成績（kol_sei1）：確定着順、走破タイム、通過順

• 特別登録（kol_tok1）：週前半の登録馬解析

• 各種マスタ（mst_venue など）：競馬場コードや条件の辞書 ……その数、実に全29テーブル。

日付・場所・レース番号をガチッと結合したキー（例：20261012_04_11）を主キー（プライマリキー）に据え、検索頻度の高いカラムにインデックスを極限まで研ぎ澄ます。

「型は間違いの元、現場のトラブルをゼロにする」という鉄則のもと、カラムの型は無駄な装飾を排して徹底的にシンプルに設計。

これで、過去走のラップも、坂路の調教タイムも、瞬時に手元へ引き抜く「最強の心臓部」が整いました。

「よし！ これで完璧や。あとは提供されているデータを流し込むだけやな！」

……そう確信した次の瞬間。

私は、競馬ソフト開発史上、最大の地獄の門を開けてしまうことになります。

「おい……なんやこのデータ構造……化け物かよ……！？」

画面に映し出された競馬ブックの生データファイル（KOLデータ .lzh）の中身は、現代のプログラマーなら卒倒するような、恐るべき姿をしていたのです。

次回予告

器（SQLite）は完成した。

だが、そこに流し込むべきデータは、カンマで綺麗に区切られた親切なCSVなどではありませんでした。

「1バイトのズレで全てが崩壊する、昭和〜平成初期の遺産・固定長バイナリ」の洗礼。

次回、【Alma Core Pro開発記 NO.2】1バイトのズレで即死！昭和の遺産「固定長データ」競馬ブックKD3を自作パーサーでねじ伏せた夜。

現役エンジニアの泥臭い逆リバースエンジニアリング劇をお届けします。お楽しみに！

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

「30万馬券逃した悔しさ、めちゃくちゃ分かる（笑）」「エンジニアが本気で作る競馬ソフト、続きが気になる！」と思っていただけたら、ぜひ画面下の「スキ（ハートマーク）」や「フォロー」をポチッと押していただけると、毎晩の開発の最高のガソリンになります！

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

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

⏩ 次のお話はこちら

👉 【第2回：昭和〜平成初期の遺産「固定長データ」 競馬ブックKD3の洗礼。】

🤖 こちらの自作Web小説もあわせてどうぞ！

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

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