【東京11Rが新潟に化けた！？】競馬ブックKD3の独自コード地獄をSQLiteマスタ統合でねじ伏せた執念!Alma Core Pro開発記 #3

アルマコア

2026年10月15日 19:24

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

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

前回の第2回にも、たくさんの「スキ」やフォローをいただき本当にありがとうございます！

「1バイトズレたらイクイノ号が58.5キロ着になる」という固定長バイナリの恐怖に、多くのエンジニアやデータ派の方から熱い共感をいただき感無量です（笑）。

さて、前回お話しした通り、マトリョーシカのような二重圧縮ファイル（.zip → .lzh）を剥き、公差±0の精密加工さながらに .kd3 のバイナリ切り出しとSQLiteへのインポートに成功した私。

「よっしゃ！全データ、SQLiteのテーブルに収まったで！」

「競馬ブックデータしか勝たん！」

「最強の自作分析環境の完成や！」

時計の針は深夜2時。

勝利を確信し、脳汁が出まくった変なテンションのまま（笑）、私は記念すべき最初のテスト検索（SQLクエリ）を叩きました。

狙うは、週末のメインレース「東京11R」。

ところが、画面に返ってきた結果を見た瞬間、私の指がピタッと止まります。

「……あっれ〜？おっかしい〜なぁ〜？（深夜2時のおかしなテンション）」

「俺、東京競馬場（11R）を選んだよな？なんで新潟競馬場（11R）のレースが堂々と出てきとるん……？？？」

「？？？」の乱れ打ちですわ！（笑）

1バイトのズレも許されないバイナリ解析の壁をせっかく乗り越えたのに、その先に待っていたのは、さらにタチの悪い「独自コード体系の深い沼」でした。

1. JIS規格のボルト穴に「独自ピッチのネジ」を突っ込んでいた

深夜2時のモニターの前で頭を抱えながら、私は再び競馬ブック（KD3）の仕様書をひっくり返しました。

そして数分後、衝撃の事実に気づきます。

競馬データを少しでも触ったことがある人なら、JRA標準の「場所コード（競馬場コード）」はなんとなく頭に入っていますよね。

一般的なJRA（JRA-VAN等）のコード体系は、北から南へ綺麗に並んでいます。

01：札幌 / 02：函館 / 03：福島 / 04：新潟 / 05：東京 / 06：中山 / 07：中京……

だから私は当然のように、「東京は『05』、新潟は『04』やろ！」という世間の常識でクエリを組んでいたんです。

ところが、競馬ブック（KD3）の仕様書に書かれていた場所コードは、まったくの別物でした。

00：京都
01：阪神
02：中京
03：小倉
04：東京
05：中山
06：福島
07：新潟
08：札幌
09：函館

「京都が『00』始まり！？東京が『04』で、新潟が『07』やと……！？」

さすが関西発祥の老舗・競馬ブックさんですわ（笑）。

京都・阪神が先頭（00・01）に来る独自のコード体系になっていたんです！

これを知らずに一般的なJRAコードの感覚でクエリを叩けば、番号が全部玉突きでズレてしまいます。

頭の中のJRAコード（東京＝05）で引いたら、KD3の世界では「05＝中山」やし、KD3の東京（04）をJRA感覚で見たら「新潟」に見える。

深夜2時の寝不足な頭は、完全にパニックです。

機械設計の世界で例えるなら、「JIS規格のM8ボルト穴に、海外メーカー独自のインチネジを無理やりねじ込もうとして、ネジ山が全部バカになる」ようなものです。

規格（コード体系）がズレているのに、そのままつなごうとしたら機械が正常に動くわけがありません！

2. 場所だけじゃなかった！「独自コード」の百鬼夜行

「なるほど、場所コードだけ気をつければええんやな！」

と一瞬ホッとしたのも束の間、仕様書を読み進めるうちに背筋が凍りつきました。

独自コードの罠は、競馬場だけではなかったのです。

条件コード：新馬＝00001、未勝利＝00003、オープン＝00004……かと思いきや、なぜかGⅠ＝ -0051、GⅡ＝ -0052 とマイナス記号つきのコードが混在！
馬記号コード：○父＝03、○市＝04、○地＝05、○外＝06……さらには「○父○市□地」＝25 といった複合記号まで細かく番号化！
毛色・血種・産地コード：栗毛＝01、鹿毛＝03、黒鹿毛＝04（なぜか 20 や 24〜35 にも黒鹿毛が割り当てられている謎仕様！）、浦河＝003、静内＝005、新冠＝006……。

画面に出てくるのは、04 とか -0051 とか 006 といった無機質な数字と記号の羅列ばかり。

せっかく固定長バイナリをデコードして文字として読めるようになったのに、データ同士の意味がまったく繋がらない状態でした。

3. Pythonの「if文」で逃げるな！DB内に「規格変換アダプタ」を削り出せ

さて、この大量の独自コードをどうやって「東京」「GⅠ」「黒鹿毛」といった正しい意味に翻訳するか。

プログラミング初心者がやりがちなのが、Pythonコードの中に直接 if code == '04': venue = '東京' と何百行もの条件分岐（if文）を書き連ねてしまうことです。

ダメなんです。

機械エンジニアとして、「その場しのぎの配線ツギハギ」だけは絶対に許せませんでした。

プログラムのあちこちに翻訳用のif文が散らばっていたら、あとで仕様変更や不具合が出たときにどこを直せばいいか分からなくなる（スパゲッティコード化する）からです。

「プログラム側で無理やり力業で変換したらアカン。データベースの内部に、どんな独自コードも美しく吸収する『規格変換アダプタ（治具）』を組み込まんかい！」

深夜2時、自分にそう言い聞かせました（笑）。

そこで私が採ったアプローチが、SQLite内に正規化のための「マスタテーブル群（辞書テーブル）」を徹底的に設計することでした。

SQL

-- 1. 場所コードマスタ (mst_venue)
CREATE TABLE IF NOT EXISTS mst_venue (
    venue_code TEXT PRIMARY KEY NOT NULL,
    venue_name TEXT NOT NULL
);

INSERT INTO mst_venue (venue_code, venue_name) VALUES
('00', '京都'), ('01', '阪神'), ('02', '中京'), ('03', '小倉'), ('04', '東京'),
('05', '中山'), ('06', '福島'), ('07', '新潟'), ('08', '札幌'), ('09', '函館'),
('10', '大井'), ('11', '川崎'), ('12', '船橋'), ('13', '浦和'), ('14', '盛岡'),
('94', '南ア'), ('99', '北海');

このように、場所コード（mst_venue）をはじめ、

条件表（mst_condition）
条件付加（mst_condition_addition）
馬記号（mst_horse_mark）
毛色（mst_coat_color）
血種（mst_breed）
産地（mst_birthplace）
予想ペース（mst_expected_pace）
脚質（mst_running_style）

に至るまで、すべてをSQLite内の独立したマスタテーブルとして完全に定義しました。

こうしておけば、出馬表テーブル（kol_den1）やオッズテーブルを呼び出すときに、SQLの LEFT JOIN を1発かますだけで、コンマ数秒で美しい日本語へと自動変換されます。

変換ロジックをすべてデータベース側のマスタに閉じ込めたことで、アプリ本体（Python）のコードは驚くほどシンプルで高剛性な状態を保つことができました。

まさに、異種規格のパーツ同士をピタリと繋ぎ合わせる「専用設計の変換フランジ」がピシャリとハマった瞬間です！

4. 個人開発者が必ず挫折する「翻訳地獄」をすべて過去にするために

ハッキリ言います。

競馬ブック（KD3）の生データを個人で扱おうとすると、第2回でお話しした「固定長バイナリの1バイト切り出し地獄」でまず9割の人が心を折られます。

そして、奇跡的にそこを突破した残りの1割の人も、この「JRA標準と異なる独自コードとの泥沼の付き合い」で完全にKOされます。

週末の予想がしたいだけなのに、マイナス記号つきの条件コードや何十種類もある毛色コードの辞書作りで何週間も徹夜するなんて、普通の人間なら発狂しますわ（笑）。

だからこそ、私が開発している『Alma Core Pro』には、絶大な価値があると自負しています。

『Alma Core Pro』では、この気の遠くなるような「全コード変換・マスタテーブル統合」が、最初からすべてシステム内部に組み込まれています。

京都が 00 だろうが東京が 04 だろうが、ユーザーはコードの違いを1ミリも気にする必要はありません。
アプリを開けば、すべての出馬表、過去成績、調教データ、そして予想オッズまでが、完全に正規化・結合された美しい状態で手元に展開されます。

泥臭いバイナリ解析も、ややこしい規格変換の配線作業も、すべて私が裏側で終わらせておきました（笑）。

皆さんは、完成されたコックピットに座って「勝つためのデータ分析」だけに100%脳みそを使えるというわけです！

5. 次回予告：バラバラの29テーブルに「命」を吹き込む

こうして「固定長パースの壁」と「独自コードの沼」を突破し、すべてのデータが正しい意味を持ってSQLiteの中に並びました。

しかし、まだ終わりではありません。

今の状態は、工場の中に「精密に加工された29種類の部品（テーブル）」がバラバラに置かれているだけです。

出馬表（kol_den1）
過去成績（kol_sei1）
トラックマンの現場メモ（kol_com1）や調教気配（kol_den2）
単勝予想オッズ（kol_ods_detail）
そして今回作ったマスタ群（mst_venue 等）

これら全29テーブルをいかにして繋ぎ合わせ、コンマ数秒で連動する「1つの生き物（システム）」へと昇華させたのか？

次回、

【Alma Core Pro開発記 NO.4】全29テーブルの全体配線図！バラバラの生データを「1つの生き物」に繋いだリレーション設計の極意。

機械エンジニアが心血を注いだ、データベースの「全体配線図（ER図・リレーション）」の核心に迫ります！

どうぞお楽しみに！

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

「京都00始まり、老舗の癖が強すぎる（笑）」「規格変換アダプタの発想、現場感あって好き！」と思っていただけたら、ぜひ画面下の「スキ（ハートマーク）」や「フォロー」をポチッと押していただけると、開発の最高のガソリンになります！

◀️ 前の記事はこちら

👉 【第2回：1バイトのズレで即死！固定長データKD3を自作パーサーでねじ伏せた夜】

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

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

⏩ 次のお話はこちら

👉 【第4回：全29テーブルの全体配線図！バラバラの生データを繋いだリレーション設計】

🤖 工場のPLC屋が本気で書く！痛快＆重厚な自作Web小説も連載中

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

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