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

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

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

前回の第1回では、「なぜExcelでもサーバー型DBでもなくSQLiteなのか？」というデータベース選定のこだわりをお話ししました。

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

さて、「SQLiteで全29テーブルの強固なデータベースを作るぞ！」と決意した私ですが、最初から都合よく綺麗なテーブルが用意されているわけがありません。

まずは敵を知ることから始まる……！

鼻息荒く、競馬ブックの生データ（競馬道OnLine / KD3形式）をダウンロードしてきたのですが……。

ここで私を待っていたのは、機械エンジニア人生でも指折りの至難。

「目をそむけたくなる数字の羅列」と、気が遠くなるような「設計地獄」でした（笑）。

今回は、昭和〜平成初期の遺産とも言える「固定長データ」の洗礼と、最大の難所だったSQL定義書・自作パーサー構築までの泥臭い格闘劇をお届けします！

1. 解凍しても解凍しても終わらない「マトリョーシカ」の罠

手元にあるのは、競馬ブック（競馬道OnLine）からダウンロードしてきたデータファイル。

最初は普通に「.zip」形式で落ちてきました。

「おっ、普通にZIPファイルやん。これならPythonの標準機能でサクッと扱えるな」

と、この時の私は完全に油断していました。

さっそくZIPを解凍してみると……中から出てきたファイルを見て、思わず画面にツッコミを入れます。

そこに並んでいたのは、平成初期の化石のような拡張子……「.lzh」。

「おまえなぁ！ なんでZIPの中に入っとんねん！ 着ぐるみか！（笑）」

PCの前で一人ツッコミに苦笑いしつつ、さらに専用アーカイバを使ってその .lzh を解凍します。

すると、中からついに本丸となる拡張子……「.kd3」のファイルたちが姿を現しました。

「.zip」をむいたら「.lzh」が出てきて、それをむいたら「.kd3」が出てくる。

まるでロシアのマトリョーシカ人形です。

「あぁしんど、やっと本丸にたどり着いたわ。中はCSVかぁ？ タブ区切りかぁ？」

そうワクワクしながら、出てきた .kd3 ファイルをテキストエディタで開いた瞬間……。

画面いっぱいに広がった光景に、思考が完全に停止しました。

0520260208111124001000010101・ｽ・ｶ・ｽm・ｽ・ｽE・ｽ・ｽ@・ｽ・ｽ・ｽ・ｽ00580132433501010498+02
0520260208111124001000020102・ｽh・ｽE・ｽf・ｽ・ｽ・ｽ[・ｽX・ｽ@・ｽ@・ｽ・ｽ・ｽL00580132533202020506-04
0520260208111124001000030203・ｽ・ｽ・ｽx・ｽ・ｽ・ｽe・ｽB・ｽA・ｽC・ｽ・ｽ・ｽ・ｽ00560132633805040472000

……。

「おいおいおいおい、なんじゃこれーーーッッ！！！」

カンマもタブも、区切り文字が一切見当たらん！

画面を埋め尽くす謎の文字列の羅列と、容赦ない文字化けの嵐。

それどころか、どこで改行されているのかすら怪しい。

「え、これどうやってデータベースに流し込んだらええの……？」

意気揚々と開いたエディタの前で、私の視界は完全に真っ白になりました。

2. 最大の難所：「日本語カラム→英語物理名」の孤独な設計

WebAPIやCSVに慣れた人なら、「カンマで区切って split(',') 1発で終わり！」と思うじゃないですか。

そんな親切な世界、ここには1ミリも存在しませんでした。

この .kd3 ファイルの正体は、カンマのような区切り文字を一切使わず、「1行の何バイト目から何バイト目がどの項目か」が決め打ちされた「固定長（Fixed-width）フォーマット」だったのです。

つまり、仕様書（設計図）がなければ1文字たりとも解読できません。

ところが、競馬道OnLineのサイトがこれまた不親切で、肝心のデータ仕様書がどこにあるのかすら分からず！ サイトの奥底を這いずり回って、ようやく仕様書を探し出しました。

しかし、仕様書を開いてからが今回の開発で一番の難所でした。

テーブル名こそ kol_den1（出馬表）や kol_sei1（成績）のように英語表記なのですが、その中にぶら下がっている膨大な数のデータ項目は、すべて「日本語」で書かれているのです！

ここで、少しデータベースをかじった方ならこう思うかもしれません。

「君、SQLiteって日本語のカラム名でそのままテーブル作れるんとちゃうん？」

「仕様書通り日本語のまま作ればラクやと思うで！ 知らんけど！」（笑）と。

ダメなんです。

機械エンジニアとして、そこだけは絶対に妥協できませんでした。

データベースの物理カラム名に日本語（マルチバイト文字）を使うと、後でPythonからSQLクエリを組むときに地獄を見ます。

コードを書くたびに半角・全角を切り替えるストレス、うっかり紛れ込む「全角スペース」による謎のシンタックスエラー。さらには記号を含む項目名によるバグの温床……。

機械設計で言えば、ミリ規格の図面の中にインチ規格のネジを混ぜるようなものです。後工程のメンテナンス性が最悪になります。

「DB内部の骨格（物理カラム名）は、バグが起きない堅牢な『半角英数』で統一する。日本語ラベルが必要なら、SQLの AS "馬名" で後から貼ればいい！」

そう腹を括った私は、果てしない作業に突入しました。

1. 全29テーブル・何百項目にも及ぶ「日本語の項目名」を、1つずつ意味の通る「英語のカラム名」に翻訳・命名する。

2. 仕様書と睨めっこしながら、「開始アドレス（何バイト目から）」と「オフセット（何バイト長か）」を1項目ずつ拾い出す。

3. それを「SQLのテーブル定義書（CREATE TABLE文）」と「Pythonの切り出し定義」へ同時に落とし込んでいく。

工場の制御盤で言えば、何千本もある無印の配線コードを1本ずつテスターで当たって、英語のラベルを貼り直しながら回路図を一から引き直すような作業です。

派手さなんて一切ない、ただひたすら地味で、一番しんどい設計作業でした。

3. 恐怖の「1バイトズレ」地獄（公差±0の精密加工）

しかも、このアドレスとオフセットの計算には、恐ろしい罠が潜んでいました。

「全角日本語（2バイト：Shift_JIS / CP932）と半角英数（1バイト）の混在」です。

もし、仕様書のオフセット計算やバイト数の解釈を、途中で「たった1バイト」でもミスしたらどうなるか？

その行の後ろに続く全カラムが、横に1マスずつ雪崩のようにズレていきます（笑）。

苦労して作った定義書でテスト実行し、画面に出力されたデータを見たとき、思わず深夜の部屋で叫びました。

• 馬名欄：「イクイノ」（「ックス」が画面外へ蒸発）

• 走破タイム欄：「ックス」（なぜか馬名のケツが侵入）

• 着順欄：「58.5kg」（着順に斤量が乱入）

• 斤量欄：「1:32.4」（斤量が走破タイムに化ける怪奇現象）

「全部ズレとるやないか〜〜〜い！！！」（笑）

ドミノ倒しのように全データが壊滅していく様は、まさに玉突き事故。

鉄パーツの切削加工で刃物の原点が0.01mmズレて、後工程の全ネジ穴が不良品になったときと全く同じ寒気が背筋を走りました。

「むず過ぎるやろ！」

「公差±0の精密部品削り出しやんか！」

深夜に頭を抱えながら、バイナリダンプ画面と仕様書を交互に睨みつけ、アドレスとオフセットを1バイト単位で修正し続けました。

4. 泥臭いパース処理を「全自動エンジン」へ封じ込める

さらにPythonの実装でも、普通のテキストとしてスライスしようとすると全角・半角の混在箇所で文字数が狂い、お決まりの UnicodeDecodeError で即死します。

固定長データを狂いなく切り出すための鉄則は、「一旦バイナリ（bytes）のまま受け止め、正確なアドレスとオフセットで切り出してから後追いでデコードすること」でした。

Python

# 一旦バイナリ（bytes）として開き、正確なアドレス・オフセットで切り出してからデコードする
# ※下記は概念を示すサンプル構造です
with open("SAMPLE.KD3", "rb") as f:
    for line in f:
        # 1. アドレスとオフセット（バイト単位）で厳密にスライス（公差±0）
        col1_bytes = line[start1:end1]
        col2_bytes = line[start2:end2]
        
        # 2. 後追いで文字列（CP932）にデコードし、英語カラムへ格納
        col1 = col1_bytes.decode('cp932', errors='replace').strip()
        col2 = col2_bytes.decode('cp932', errors='replace').strip()

膨大な日本語項目をすべて英語カラムに定義し直し、全29テーブルのSQL定義書とアドレス・オフセットの辞書を完成させるまで、どれだけの週末を溶かしたか分かりません。

正直に言います。

競馬ブックデータ（KD3形式）は、普通の競馬ファンや個人開発者が週末に手を出したらアカンレベルです（笑）。

二重に圧縮されたZIPとLZHを解凍し、不親切な仕様書を探し出し、何百もの日本語項目を英語に直して1バイト単位の計算をするなんて、時間と気力の無駄遣いです。

しかし、私が開発している『Alma Core Pro』では、このマトリョーシカのような圧縮ファイルの解凍から、KD3の1バイト単位のバイナリ切り出し、文字コード変換、そして英語物理名で設計されたSQLiteへの高速インポートまでを、「完全自動のバックグラウンド処理」として裏側に丸ごと封じ込めることに成功しました。

ユーザーが使う時は、ややこしい仕様書も、バイナリの知識も、面倒なExcelの関数も一切不要。

ただボタンをポチッと押すだけで、あの化け物のような生データが、数秒後には美しく整列した「勝つための武器」として手元のデータベースに格納されます。

初めてこの自作インポートエンジンがエラーゼロで完走し、SQLiteのテーブルへ美しいデータが一気に流れ込んだ瞬間は、図面通りの寸法でピタリと機械部品が削り上がったときのような、エンジニア冥利に尽きる瞬間でした。

5. 次回予告：パースできても、まだ終わらない

暗号のようなKD3のバイナリデータが、ついに頑丈なSQLiteのテーブルとして生まれ変わりました。

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

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

深夜2時、勝利を確信して自作SQLクエリを叩いた私。

……しかし、画面に返ってきた結果を見て、再び私の動きがピタッと止まります。

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

「東京競馬場（11R）を選んだはずやのに、なんで新潟競馬場（11R）が引っ張られてくるん……？」

パースの壁を越えた先に待っていたのは、JRA標準とは微妙に食い違う「独自コード体系の深い沼」でした。

次回、

【Alma Core Pro開発記 NO.3】東京11Rが新潟に化ける！？競馬ブックKD3「独自コードの沼」とマスタ統合（mst_venue）の戦い。

データは読めた。だが、意味が繋がらない。

機械エンジニアは、この「コード体系のズレ」をいかにして正規化し、完全自動結合させたのか？

どうぞお楽しみに！

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

「1バイトズレの玉突き事故、笑った！」「マトリョーシカ解凍、めちゃくちゃ共感する」と思っていただけたら、ぜひ画面下の「スキ（ハートマーク）」や「フォロー」をポチッと押していただけると、開発の最高のガソリンになります！

◀️ 前の記事はこちら

👉 【第1回：30万馬券を逃した現役エンジニアが、競馬専用SQLiteデータベースをゼロから削り出した執念】

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

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

⏩ 次のお話はこちら

👉 【第3回：東京11Rが新潟に化ける！？独自コードの沼とマスタ統合】

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

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

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