M/MAPPING

DMEチューニングも、AIで次のステージへ

2026年10月13日

自動チューニングの構成図。車・端末・クラウド・開発機・一次資料の5層が横帯で並び、車から出ていくデータの経路と、直したコードが車へ戻ってくる経路が矢印で描かれている

TUNERの開発にはAIを活用していますが、アプリのコーディングだけでなく、DMEロジックの解析や解釈、データログの分析も、AIと対話しながら進めています。

僕の夢は、車と対話しながら、車の状態と自分の好みに合わせて自動でチューニングされていくUXです。それが、ほぼできてしまう感触があります。

それを示すために、仕組みのアーキテクチャ図(フロー図)を紹介します。

現在のアーキテクチャ

LOADING INTERACTIVE WIDGET...

この仕組みを、ざっくり言葉で表現してみます。

  1. 僕が作ったTUNERアプリでデータログを取ります。
  2. データを取ったら、ログをクラウドサーバーへアップロードします。
  3. 普段使っているAIに、改善したいことを可能な限り具体的に伝えます。
  4. AIが走行ログを分析して、チューニングファイルを書き換え、クラウドサーバーへアップロードします。
  5. チューニングデータをTUNERアプリで受け取って、車に書き込みます。

※データを読み書きするときは、人間がイグニッションキーをオンオフし、車両との接続確立をボタンで行います。

現在は、このアーキテクチャでTUNERアプリの改良を進めています。

こう書くと、まだまだ人間の手作業が多く感じるかもしれません。

しかし開発の感触としては、AIエージェントとの会話だけで、チューニングもツールの改良も進められてしまうイメージが鮮明です。

なぜ、わざわざアプリを作るのか

ここまで読んでくださったオーナーさんは、「AIでなんでもできるのに、なぜアプリを開発するのか」と疑問に思うかもしれません。

理由はいくつかあります。

  1. データ処理の正確性と安定性の確保
  2. セキュリティ
  3. AIコストの節約(トークン費用と使用エネルギー)

しかし、最も大きい理由は、書き込む内容を人間が最終判断するための補助UIだからです。

平たく言うと、AIに丸投げせず、人間が見て判断できるようにするためです。

まだ改良できること

まだ自動化できる余地は、たくさん残されています。

特にもどかしいのは、イグニッションキーのオンオフとデータのリード&ライトを、車を停めて行わないといけない点です。

ですが、これを解決するアイデアがあります。

それは、DMEメモリの空き容量を使うことです。

過去の記事で、MSS Mapperで複数のマップを書き込み、切り替えられる機能を紹介しました。これを応用します。

また、OpenWAMのプロジェクトでは、VANOSテーブルを走りながら変更できるロジックも試しています。どちらを使うか、合わせ技でいくかは、実験が必要です。

うまくいけば、走りながらAIと会話し、いくつものチューニングデータを走りながら書き込んで試行錯誤できる体験を実現できます。

これを形にしたくてしょうがないのですが、いろいろやりすぎて集中できていません。僕の脳の特性上、一つのことに集中し続けられないもどかしさがあります。

現在の工夫ポイント

現在の仕組みのポイントは、手持ちのありもの技術を組み合わせている点です。

アプリをAIで作るのは、今や当たり前で、新鮮味はひとつもありません。

面白さと新鮮味があるのは、チューニングそのものをAIにサポートしてもらうことです。

アプリ開発は、AIのサブスク料金の範囲で行えます。

でも、AIをオリジナルアプリに組み込んで使おうとすると、APIという仕組みをサブスクとは別に使う必要があり、使った分だけコストが嵩んでいきます。

開発者の心理としては、普段使っているAIのサブスク料金の中で収めたいところです。

それを実現するために、アプリにはAIを組み込まず、アプリのコードフォルダそのものを自分のPCに置いておきます。

あえて開発環境の状態にしておくことで、サブスク料金の範囲内でAIを活用できます。

(後記:MCPサーバーという仕組みを使えば、開発環境に置かなくてもアプリとAIを繋ぐことができます。実は、もうリリース済みです。)

具体的な設定

  • コード操作とPC操作ができる Claude Desktop(Claude Code):無料
  • アプリのデプロイ先として Cloudflare:無料

アプリはスマホでURLからアクセスし、ダウンロードしておきます。

Claude Desktopには、スマホ版からデスクトップにリモートアクセスして操作できる機能があります。

繋がりを簡単に書くと、こんな感じです。

人 ⇄ スマホ1(AI) ⇄ PC(AI) ⇄ Cloudflare(データ) ⇄ スマホ2(アプリ) ⇄ 車

スマホ2が車載Android端末なら、わざわざアプリを切り替えなくても、ハンズフリーで音声だけでやり取りできます。

流れはこうです。スマホでデータログを取ったら、スマホからAIに「データ取ったから分析して〜」とお願いします。するとAIは、Cloudflareにアップロードされたデータを自分で取りに行き、分析し終えたらデータをCloudflareに返してくれます。それをTUNERアプリで取得して、車に書き込むわけです。

そして、AIとの対話で見つけたチューニングメソドロジーを再現できるように、TUNERアプリにプログラムとして組み込んでいきます。

すると次回からは、AIなしでチューニングしていくことができます。

AIが進化しても、言うよりやる方が難しい感覚は何も変わっていない

もちろん、ただAIを繋ぐだけでは、AIは仕事をしてくれません。

サブスクには使用制限もありますよね。

AIを繋ぐだけだと推測ばかりで、決定打になる案は一つも出してもらえません。

なので、チューニングコミュニティの努力の結晶を、アプリと同じフォルダにセットしておきます。

  • ECUデータの逆アセンブルコード
  • パラメータを説明する定義ファイル
  • 実際の車のECUバイナリファイル

さらに事前に、次のようなことを整理してドキュメント化しておきます。

  • これらのドキュメントの読み方
  • ECUのバイナリアドレスとパラメータ定義の紐づけ
  • 逆アセンブルデータとの紐づけ

そして、次のような手順をSkill化しておきます。

  • TUNERアプリからのデータの受け取り方
  • チューニング後のファイルの配置の仕方
  • データログファイルの読み方
  • 分析の方法

ここまで設定しておくことで、非ジョーに爽快なAI ECUチューニング体験が得られますが、ここまで準備してツールをチューニングするのが大変なんです。

公開するのは、実現したい夢がある人の為

ここまで読んでくださったオーナーさんの関心は、「これが誰でもできることなのか」、あるいは「自分にもできるのか」という判断基準ではないでしょうか。

正直に言うと、長い間ITに関わっている僕でも、この仕組みの構築は容易ではありません。

AIの急速な進化によって、「IT屋の仕事はなくなるのでは?」と心配する声もありました。ですが僕の実感は逆で、エンジニアに期待される成果のレベルが、かつてなく超高度化されたと感じています。

頼まれたコードを書けるだけのエンジニアはもう不要ですし、やりたいことを言葉にしてAIに指示を出すことすら、近い将来には誰もができるようになります。

いま本当に求められているのは、AIが作ったモノを、安全性・人の倫理観・社会性を考慮した上で正しく評価し、実用レベルまで修正・統合できる技術力です。

  • それが本当に機能しているのか
  • 不具合が起きたときに、どう原因を判断するか
  • 不具合が起きる前に、どのように多層の安全対策をとっておくか
  • 不具合が発生したとき、代わりの対策をどうするか

車やハードウェアのように「一歩間違えれば物理的に壊れる」現場では、ITの根本的な基礎体力がなければ、こうした問いをAIに投げかけることすらできません。

AIとの対話でロジックを詰め、安全対策を何重にも施し、実際に機能するシステムへと組み上げる。ここには膨大な時間と試行錯誤、そして固有のノウハウが必要です。

だからこそ、このサイトで僕が言い続けてきた「誰でも」の意味を、ここで訂正したいと思います。

何もしなくてもボタン一つでできる、という意味ではありません。 「自分でやってみたい、という強い意欲や夢がある人であれば」誰でもできる、という意味です。

ITの経験がなかったとしても、強い熱意や「車をこう進化させたい」という想いがあれば、どこまでリスクヘッジしなければならないか、どうすれば本当に役立つのかという発想は、自然と内側から湧き出てくるはずです。

そのようなオーナーさんの参考になるように、オープンソースとして公開しています。

AIの危険性と可能性

AIをゴリゴリ使っておきながら言うのもなんですが、AIの動きの中身を知らないことは怖い、ということも書いておきます。

いずれこんなことを気にしなくて済む時代が来るとは思いますが、少なくとも今のAIの動きに対しては、人間が注意深く見てあげる必要があります。

とはいえ、AIの力によって、今までできなかったことができるようになりました。

車の趣味を始めた二十歳頃、ECUチューニングに興味を持って少し勉強したとき、感想を一言にまとめるなら「めんどくさ」でした。

めんどくさいというか、何もわからない、情報がない、という感じでした。 (今になって思うのは、情報の取り方を分かっていなかったんですね。)

当時はIT屋でもなんでもない、ただのクソガキでしたが、ブラックボックス化するエンジニアの気が知れませんでした。 (もちろん、IT屋となった今では理解できますよ。IT屋じゃなくても、大人になれば理解できることですね。)

それと同時に、車に長く乗りたいと思ったとき、チューニングの情報が残らないのはめっちゃもったいないと思ったんです。

ほぼ勘と経験の世界。ここまで色濃い業界も珍しいのではと思いました。

今でこそ、動画で方法論を解説してくれる方が多いですが、玉石混交で、何が玉で何が石なんだかさっぱりです。 (情報がないって言ったり、多すぎるって言ったり、わがままかって。笑)

蛇足が増えてしまいましたが、当時思ったことは、

「走行ログを取り、分析し、チューニングするサイクルは自動化できるはずだ。」

でした。

当時は思っただけで、自分がやることになるとは一ミリも思っていませんでした。

しかし、人生何が起こるか分からないものですね。

20年経った今、こうして自分で構築することができました。

TUNERアプリについて

TUNERアプリは無料で使えます。ソースコードもGitHubで公開しています。

https://mss54hp-csl-convert-tuner.tsunagi.app/

アプリそのものの機能は、こちらの記事で紹介しています。

追伸

この仕組みは、MSS54HPに固有のものではありません。ECUのバイナリと定義ファイル、逆アセンブルなどの読める材料、そして車と実際に会話できる線。これが揃っていれば、車種やECUが違っても同じ組み方ができます。

実際、同じ考え方で診断ツールも作っています。

ご自身の車やお店の作業で、こういう仕組みが欲しいという方がいらっしゃれば、MESHからご相談ください。

More 関連記事

MSS54HP CSL CONVERT /// TUNER V2.2.0 をリリース
MAPPING2026.09.09

MSS54HP CSL CONVERT /// TUNER V2.2.0 をリリース

MSS54HP CSL CONVERT /// TUNER 2.2.0 を少し前から公開しています。(NAM3フォーラムへの投稿が最初です。) https://mss54hpcslconverttuner.tsunagi.app/ なお、アプリのヘッダには V2.2.0 β と出ます。この記事の最後...

続きを読む →
E46M3 DIYでCSLスタイルカーボンエアボックスに交換する場合に考慮が必要なこと1
MAPPING2026.08.15 更新2023.07.14

E46M3 DIYでCSLスタイルカーボンエアボックスに交換する場合に考慮が必要なこと1

念願叶って、CSLスタイルカーボンエアボックスをDIYで交換できました。 エンジンレスポンスが上がってとにかく気持ちがいいです。 フロントからのエンジンサウンドが増大し、気分を高めてくれます。 既に贅沢なNA6連独立スロットルエンジンに、サウンドとレスポンスの贅沢が積み増しされました。 このせいでS...

続きを読む →
E46M3 DIYでCSLスタイルカーボンエアボックスに交換する場合に考慮が必要なこと2
MAPPING2026.08.15 更新2023.11.02

E46M3 DIYでCSLスタイルカーボンエアボックスに交換する場合に考慮が必要なこと2

前回のコンテンツで、ターナーのCSLスタイル カーボンエアボックスに交換した時に出た3500rpm以下のフルスロットル領域のガクガク(以降、ジャーキングと呼びます。)は、オープンループマップのみを調整すれば概ね解消できることに触れました。 しかし日常で乗っているとアクセルのパーシャル(中間)領域のジ...

続きを読む →
E46M3 DIYでCSLスタイルカーボンエアボックスに交換する場合に考慮が必要なこと3
MAPPING2026.08.15 更新2024.03.18

E46M3 DIYでCSLスタイルカーボンエアボックスに交換する場合に考慮が必要なこと3

Turner製 CSLスタイル カーボンエアボックスに交換したときの2000〜3000rpmの乗りにくさが、ベースマップのチューニングによってやっと解消できたので、そのアプローチをシェアしたいと思います。 データロガーで容積効率とエンジン回転数、ナローバンドO2センサーのラムダの値を15分ほど取りま...

続きを読む →
MAPPING 一覧に戻る →