【BVE制作の救世主？】日本の鉄道知識に特化したAI「JapanRailwaySimLLM」を作った／A Lifesaver for BVE Development? Introducing JapanRailwaySimLLM, an AI Specialized in Japanese Railway Knowledge

-

【BVE制作の救世主？】日本の鉄道知識に特化したAI「JapanRailwaySimLLM」を作ってみた

突然ですが、鉄道運転シミュレータ「BVE Trainsim（作者：mackoy様）」の路線や車両を制作したことはありますか？

「構文が独特で覚えるのが大変」「数万行あるMapファイルのエラー原因が分からない」「技術資料や省令を読み解くのが面倒」……など、BVEのデータ制作は、界隈でも「圧倒的に骨の折れる作業」として知られています。

SNSや制作記を覗いてみても、作者の皆さんからはこんなリアルな苦労の声が絶えません。


  • 「数万行のMapファイルに200行の修正が必要で手作業は限界」
  • 「事前調査やGoogle Earthでの位置測定だけで半年かかった」
  • 「線路脇だけでなく、田畑に囲まれた遠景まで作り込まないと殺風景で誤魔化せない」
  • 「車両制作も運転台写真の合成、音源編集、TASCや保安装置プラグインの設定でやる事が山積み」

このように、1分の走行区間を作るのすら膨大な労力と専門知識が必要であり、挫折や制作中断の大きな原因となっています。

さらに、世の中には様々なAI（LLM）が存在しますが、ChatGPTやClaudeなどの汎用AIに質問しても、BVE独自の構文（BveText2.00 等）や、国土交通省が定める「鉄道に関する技術上の基準を定める省令」といった専門的な質問には正確に答えてくれません。

そこで今回、BVE制作者の負担を少しでも減らすべく、日本の鉄道の基礎知識とBVE制作に必要な情報を調べ上げ、信憑性のある情報を取りまとめた上でRAG学習を行ったAI「JapanRailwaySimLLM」を構築しました！

この記事では、開発の背景やRAG学習の仕組み、そして裏側での泥臭い試行錯誤についてご紹介します。

開発の背景：なぜ作ろうと思ったのか？

開発の動機は極めてシンプルです。

  1. BVE Trainsimのデータ制作が難易度高め

マップファイルの距離程指定や複雑な構文ルール、各種定義ファイル（Structure, Signal, Soundなど）の連携、車両の性能・パネル・音の設定など、挫折ポイントが山ほどあります。

 

  1. 一般的なAIは「日本の鉄道」や「BVE構文」に弱い

汎用AIは一般的なプログラミング言語（PythonやJavaScriptなど）には強いものの、BVE特有の構文や日本の鉄道技術基準などのマニアックな専門知識にはハルシネーション（嘘の回答）を起こしがちです。

 

「それなら、信頼できる情報を集めてAIに直接読み込ませ、正確に答えてくれる環境を作ればいいのでは？」と考えたのがスタートでした。

 

どうやって学習させた？（RAG構築の仕組み）

今回は、モデル自体のファインチューニングではなく、信頼性の高いドキュメントを外部知識として検索・参照させるRAG（Retrieval-Augmented Generation）という手法を採用しました。

（※実は最初にファインチューニングを試みたのですが、モデルが崩壊してクソほどきつい思いをしたため、RAGへ方向転換しました…）



1. 参照させた資料と前処理（データ整理の工夫）

情報の「信憑性」に徹底的にこだわり、必要な基礎知識や公式マニュアルなどの各種資料を一度Word等にきれいに取りまとめた上でテキスト抽出・ベクトル化を行い、データベース（ChromaDB）に組み込みました。

取りまとめた主な情報源

  • BVE5/6 制作等の資料
  • 鉄道に関する技術上の基準を定める省令（e-Gov法令検索）
  • 鉄道技術基準に関する解釈・解説資料

Web上の情報をそのまま読み込ませるのではなく、表記の揺れや不要なレイアウトを事前に整理・整形（前処理）してから学習データ化することで、AIがより正確かつノイズなしで情報を検索・参照できるように工夫しています。鉄道の基礎知識無い状態だと

2. 使用した技術スタック

  • ベースモデル: google/gemma-2-9b-it（日本語性能とロジックに優れたモデル）
  • 埋め込みモデル（Embedding）: intfloat/multilingual-e5-base
  • ベクトルデータベース: ChromaDB
  • フレームワーク: LangChain

ユーザーが「BVE5でマップを作成する際の基本構文は？」と質問すると、取りまとめたデータベースから該当するマニュアル情報を瞬時に検索し、正確な回答を生成してくれます。

開発裏話：Google Colabでのメモリと依存関係との戦い

開発環境には Google Colab を使用しましたが、一筋縄ではいきませんでした……。よく「AIを使えば開発が楽になる」と言われますが、実際に作ってみると泥臭い作業の連続です。

  • GPUのないパソコンでも動かせれるコンセプト

BVETrainsimのやる人の中でGPU搭載しない普通のノートパソコンで製作する人もいるので、ハイスペックじゃなくても動かせれるというのを念頭に置いて作成しました。

自分のメインPCみたいに構築する人自体マイノリティーだろう。

  • GPUメモリ不足（OOM）との戦い

当初は8Bクラスのモデル（Llama-3-ELYZA-JP-8B）などで試走したものの、T4 GPUのVRAM上限に達してしまいエラーを連発。モデルの変更や軽量化を余儀なくされました。

また、当初はファインチューニングというベースを弄ってしまうタイプだったので使い物にならなかった部分もあります。

Gemmaベースに変えてファインチューニングからRAGにしたらうまくいった形になります。

  • 依存ライブラリのバグ・バージョン競合

protobuf や transformers、torchvision などのライブラリ同士がバージョン互換エラーを起こし、何度もアンインストール＆再インストールを繰り返して環境を修復しました。

  • llama.cpp による GGUF 化と量子化

最終的に軽量かつ高速に動作させるため、llama.cppをCPUビルドし、モデルを GGUF (f16) 形式に変換後、Q4_K_M 形式へ量子化。約5.7GBまで軽量化して Hugging Face にアップロードすることに成功しました！

現在公開中のモデル・データセット

今回構築したベースモデルやベクトルデータセットは、すべて Hugging Face 上で公開しています。

期待する活用方法と今後の可能性

現在は基礎的な構文と省令データの取り込みが完了した状態です。自分自身でここからの機能拡張や継続的な開発を計画しているわけではありませんが、今回公開したモデルやデータセットをベースに、コミュニティや他の開発者の方々が自由に活用・応用していっていただければと思っています。

例えば、以下のようなツールや応用のアイデアが考えられます。

  • 構文エラー自動診断プラグイン

サウンド定義やストラクチャ定義、Mapファイルの記述ミスを自動検知して修正案を提示するエディタ拡張。

  • マップファイルのリファクタリング・自動生成ツール

冗長になった数万行のコードを最適化したり、記述補助を行うスクリプトの構築。

  • 拡張版RAGデータベースの構築

より広範な鉄道技術資料や私鉄独自の保安装置仕様などを追加インデックス化。

BVE制作者の皆さんが手作業の泥臭い構文エラーや座標計算に悩まされず、「面白い路線・リアルな景観づくり」というクリエイティブな作業に集中できる環境づくりの一助となれば幸いです。興味のある方はぜひモデルやデータセットをダウンロードして、実験やツール開発に活用してみてください！

使用に関してはgemmaと同様になるのでJapanRailwaySimLLMとしての利用制限は特にありません 。

※gemma利用規約についてかみ砕いた事が日本語で書かれている記事

A Lifesaver for BVE Development? Introducing JapanRailwaySimLLM, an AI Specialized in Japanese Railway Knowledge

 Have you ever created a route or rolling stock for the railway driving simulator BVE Trainsim (developed by Mackoy)?

BVE data development is widely known in the community as exceptionally painstaking work: its syntax is unusual and difficult to learn; tracing errors in a Map file with tens of thousands of lines can be daunting; and interpreting technical documents and ministerial regulations is time-consuming.

 A look at social media and development journals reveals a steady stream of candid comments from creators about the challenges they face.

·         “A Map file with tens of thousands of lines needs 200 lines corrected—manual work has reached its limit.”

·         “Preliminary research and location measurements in Google Earth alone took six months.”

·         “It is not enough to build only the area beside the tracks; without detailed distant scenery surrounded by fields, the result looks sparse and unconvincing.”

·         “Rolling-stock development also involves a mountain of work, including compositing cab photographs, editing audio, and configuring TASC and safety-system plug-ins.”

As these examples show, creating even a one-minute section of running time requires enormous effort and specialist knowledge, making frustration and abandoned projects all too common.

Many AI systems and large language models (LLMs) are available today, but general-purpose tools such as ChatGPT and Claude often cannot answer specialized questions accurately—whether about BVE-specific syntax such as BveText2.00 or Japan’s Ministerial Ordinance Providing for the Technical Standard for Railways, issued by the Ministry of Land, Infrastructure, Transport and Tourism.

To reduce the burden on BVE creators, I researched foundational knowledge of railways in Japan and the information needed for BVE development, compiled credible sources, and built an AI system called JapanRailwaySimLLM using retrieval-augmented generation (RAG).

This article explains the project’s background, how the RAG system works, and the unglamorous trial and error behind its development.

 Background: Why I Built It

The motivation was very simple.

1.       Creating data for BVE Trainsim is difficult

There are countless stumbling blocks: specifying chainage in Map files, following complex syntax rules, coordinating definition files such as Structure, Signal, and Sound, and configuring vehicle performance, cab panels, and audio.

2.       General-purpose AI struggles with Japanese railway knowledge and BVE syntax

General-purpose AI performs well with mainstream programming languages such as Python and JavaScript, but it is prone to hallucinations—plausible-sounding but false answers—when dealing with niche specialist knowledge such as BVE-specific syntax and Japanese railway technical standards.

That prompted a simple idea: why not collect reliable information, make it directly available to an AI system, and create an environment that can provide accurate answers?

 

How Was It Trained? Building the RAG System

Rather than fine-tuning the model itself, I used retrieval-augmented generation (RAG), which searches and references highly reliable documents as an external knowledge source.

(I initially tried fine-tuning, but the model collapsed and the process was extremely difficult, so I changed direction and moved to RAG.)

1. Reference Materials and Preprocessing

I placed the highest priority on credibility. I first organized the necessary foundational knowledge, official manuals, and other materials in Word and similar tools, then extracted and vectorized the text and integrated it into a ChromaDB database.

Main Sources Compiled

·         Documentation for BVE 5/6 development and related topics

·         Japan’s Ministerial Ordinance Providing for the Technical Standard for Railways (e-Gov Laws and Regulations Search)

·         Interpretive and explanatory materials on Japanese railway technical standards

Instead of ingesting web content as-is, I normalized inconsistent terminology and removed unnecessary layout elements during preprocessing before converting the material into training data. This helps the AI retrieve and reference information more accurately and with less noise. Without foundational railway knowledge, this preparation would be difficult.

 2. Technology Stack

·         Base model: google/gemma-2-9b-it (selected for its strong Japanese-language performance and reasoning ability)

·         Embedding model: intfloat/multilingual-e5-base

·         Vector database: ChromaDB

·         Framework: LangChain

When a user asks, “What is the basic syntax for creating a map in BVE 5?”, the system instantly retrieves the relevant manual content from the compiled database and generates an accurate answer.

Behind the Scenes: Battling Memory Limits and Dependency Conflicts in Google Colab

I used Google Colab as the development environment, but the process was far from straightforward. People often say that AI makes development easier; in practice, building the system involved one unglamorous task after another.

·         Designed to run even on computers without a GPU

Some BVE Trainsim creators work on ordinary laptops without dedicated GPUs, so I designed the system around the principle that it should run without high-end hardware.

·         Battling GPU out-of-memory (OOM) errors

I initially tested 8B-class models such as Llama-3-ELYZA-JP-8B, but repeatedly hit the VRAM limit of the T4 GPU. This forced me to change models and reduce resource requirements.

The initial approach also modified the base model through fine-tuning, and some results were not usable.

The project began working successfully after I switched to a Gemma base model and replaced fine-tuning with RAG.

·         Library bugs and version conflicts

Libraries such as protobuf, transformers, and torchvision produced version-compatibility errors, requiring repeated uninstallations and reinstallations to repair the environment.

·         GGUF conversion and quantization with llama.cpp

To achieve lightweight, fast operation, I ultimately built llama.cpp for CPU use, converted the model to GGUF (f16), and then quantized it to Q4_K_M. This reduced the model to approximately 5.7 GB, and I successfully uploaded it to Hugging Face.

Models and Datasets Now Available

The base model and vector dataset developed for this project are publicly available on Hugging Face.

·         Hugging Face repository: galakenya/JapanRailwaySimLLM

Potential Uses and Future Possibilities

At present, the system includes foundational syntax and data from Japanese railway regulations. I am not planning further feature expansion or continuous development myself, but I hope the community and other developers will freely use and adapt the released model and dataset as a foundation for future work.

Possible tools and applications include the following.

·         Automatic syntax-error diagnostic plug-in

An editor extension that automatically detects errors in Sound and Structure definitions and Map files, then suggests corrections.

·         Map-file refactoring and automatic-generation tools

Scripts that optimize redundant code spanning tens of thousands of lines and assist with authoring.

·         Expanded RAG database

Additional indexing of a wider range of Japanese railway engineering documents and proprietary safety-system specifications used by private railway operators.

I hope this project helps create an environment in which BVE developers no longer have to struggle with painstaking manual syntax debugging and coordinate calculations, and can instead focus on the creative work of building engaging routes and realistic scenery inspired by railways across Japan’s regions and prefectures.

If you are interested, please download the model and dataset and use them for your own experiments or tool development.

Since its usage is the same as Gemma, there are no specific usage restrictions for JapanRailwaySimLLM.


コメント

コメントを投稿

このブログの人気の投稿

名鉄の存廃問題と廃線の決まった路線(2025年2月時点)／Meitetsu's survival issues and the routes that were decided to be discontinued (as of February 2025)

-
イメージ
 名鉄広見線の一部区間（新可児～御嵩）と西尾・蒲郡線（西尾～吉良吉田～蒲郡）は、利用客減少と赤字により廃線の危機に瀕しています。また名鉄以外に2025年2月時点で廃線が決まっている路線をピックアップしました。 広見線（新可児～御嵩） 2025 年 6 月に存続か廃止かの判断が下される予定です。 沿線人口減少とコロナ禍により利用者が大幅に減少し、年間 2 億円前後の赤字が出ています。 名鉄は自治体に対し、路線の維持には 15 年で約 17 億 6000 万円の投資が必要だと伝えています。 自治体は、年間約 1 億 8000 万円の維持費を負担する「みなし上下分離方式」か、年間約 6400 万円のバス転換かの選択を迫られています。 住民からは、通学時間の増加や若者の地域離れを懸念する声が上がっています。 西尾 ・ 蒲郡線 （西尾～吉良吉田～蒲郡） 西尾市 と 蒲郡市 が名鉄に年間 2 億 5000 万円を支援することで、 2025 年度までの運行継続が決定しています。 2026 年度以降の運行は未定で、 2024 年度末までに検討会が方向性を示す予定です。 蒲郡線（吉良吉田～蒲郡）は輸送密度が低く、国の地域公共交通再構築事業の対象となっています。 西尾市は、名鉄西尾・蒲郡線の存続に全力を尽くすとしており、「上下分離方式」の導入も検討しています。 沿線自治体は、観光資源の活用や利用促進など、路線の維持に向けた取り組みを行っています。 IC カード非対応区間について 広見線の一部区間（新可児～御嵩）と蒲郡線全線（吉良吉田～蒲郡）は IC カード（ manaca ）が利用できません。 名鉄自身は、これらの区間の運営は困難としており、廃線を前提に IC カードを導入していないと考えられます。 ただし、廃線検討区間のうち西尾線全線は IC カードに対応しています。 路線の今後 名鉄広見線、西尾・蒲郡線ともに、沿線自治体や住民が協力して利用促進や地域活性化に取り組むことが、路線の存続には不可欠です。 廃線の決まった路線たち １．弘南鉄道大鰐線 区間 : 中央弘前駅～大鰐駅 ( ちゅうおうひろさきえき～おおわにえき ) 現状 : 沿線５市町村が、弘南鉄...
続きを読む

JR東日本の小規模駅で進む「簡易Suica改札機」導入とは？背景・現地の様子・今後の展望／What’s Behind JR East’s “Simplified Suica Gate” Rollout at Small Stations?

-
イメージ
JR 東日本の小規模駅で進む「簡易 Suica 改札機」導入とは？背景・現地の様子・今後の展望 相模線の現場から全国の鉄道の未来まで―キャッシュレス化で駅はどう変わる？ 最近、 JR 東日本の小規模駅で「簡易 Suica 改札機」への切り替えが急速に進んでいます。従来の自動改札機に代わり、 IC カード専用でゲートのない簡易型端末が登場し、特に相模線の上溝駅や南橋本駅、番田駅などでその動きが目立ちます。今回は、その背景や現地の様子、利用者の声、そして鉄道業界の最新トレンドまで、ブログ記事形式でわかりやすくまとめます。 なぜ「簡易 Suica 改札機」導入が進んでいるの？ l    経営の効率化とデジタル化：鉄道利用者の減少（少子高齢化、コロナ禍など）に対応するため、 JR 東日本はコスト削減と駅無人化を進めています。従来の自動改札機は高額な設備・維持費がかかりますが、簡易 Suica 改札機なら設置・運用・保守コストを大幅にカットできます。 l    IC カードの普及：首都圏ではほとんどの利用者が Suica など IC カードを使っており、キャッシュレス・スマートフォン決済が当たり前に。社会的にも非接触・タッチレスニーズが高まったことで、 IC 専用改札への移行が後押しされています。 簡易 Suica 改札機ってどんなもの？ l    ゲートや紙きっぷ投入口がなく、 IC カードリーダーとディスプレイのみのシンプルな端末 l    入場用・出場用で分かれていて、カードやスマホをタッチするだけ l    エラー時は音やランプで通知、複数枚カードの同時タッチは NG l    省スペース・低コストで無人駅や狭いスペースにも設置しやすい l    将来的には QR コードや顔認証にも対応可能 相模線の導入状況と現地の様子 上溝駅 導入済・中規模駅 南橋本駅 導入済・利用者多め 番田駅 導入済・無人駅 宮山駅・倉見駅・門沢橋駅・社家駅・入...
続きを読む

西鉄貝塚線、7050形が新造台車を履き転属搬入／Nishi-Tetsu Kaizuka Line Receives 7050 Series with Newly Built Bogies for Transfer

-
イメージ
西鉄貝塚線、 7050 形が新造台車を履き転属搬入 2025 年 8 月 21 日 、西日本鉄道貝塚線の後継車両として、天神大牟田線から転属する予定の 7050 形 7151 編成 が、多々良車両基地に陸送で搬入されたことが確認されました。 今回の転属に際し、 7050 形は貝塚線特有の黄色い塗装「オキサイドイエロー」に塗り替えられています。この鮮やかな黄色い車体は、これまで貝塚線を走ってきた 600 形の「アイスグリーン」とは大きく異なるもので、新旧車両が並んだ際には対照的な姿を見せました。 最も注目されるのは台車の変更です。これまで標準軌（ 1,435mm ）である天神大牟田線を走っていた 7050 形は、狭軌（ 1,067mm ） である貝塚線に合わせるため、台車を交換する必要がありました。これまでの貝塚線車両は、軌間の違いから他社の廃車発生品（主に西武鉄道）を流用していましたが、 7050 形は 川崎車両が 2025 年 6 月に製造したボルスタレス台車「 KW227 」を新たに装着しました。貝塚線に新造のボルスタレス台車が導入されるのは初めてのことです。 7050 形は、天神大牟田線で運行されている 7000 形の 3 扉バージョン として製造された車両で、ほぼ同じ性能を持っています。このほか、 VVVF インバータ制御や電気指令式ブレーキなど、貝塚線では初となる多くの最新機器を搭載しており、これにより貝塚線の技術が大きく進歩することになります。 現在、貝塚線で運行されている 600 形は 8 編成ですが、 7050 形は 9 編成すべてが貝塚線に転属する見込みです。これは、今後の混雑緩和を見越した増強とみられます。 多々良車両基地では、新旧車両である 600 形と 7050 形が並ぶ姿が確認され、西鉄の歴史の新たな 1 ページを刻む光景となりました。   西鉄に乗ってみたい。 ド素人なので、目下増備中の9000形が3ドアなことから貝塚線に行くのは4ドアの7000形かと思いきや3ドアの7050形なのね。 — MTTC@比較画像 (@MTTC16) August 21, 2025 アイスグリーンおるかなってって貝塚に見に来たら7050が貝塚線塗装で運び込まれてて3度見した件 pic.twitter.com/9It7RsB...
続きを読む