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

MSS54HP CSL CONVERT /// TUNERを、大幅にアップデートしました。

今回は、アップデートの内容と今後の開発の展望、そして開発の軸になっている考え方を言語化しました。

また、前回のサイト刷新の記事の最後に、「作りたいものは、この次のコンテンツで書きます」と書いたので、その約束も果たします。

ただ、今回伝えたいのは、機能の説明ではなく機能という素材をどう料理して、満足を得るか、の話です。

日本のソフトウェア開発で、僕がいまだに解消できない業界の大きな課題だと考えていることを、このツールをサンプルに解消するアプローチを書いてみました。

僕がこだわるのは、機能ではなく「手順の流れ」です

この手のツールは、いつも機能表で語られます。あれができる、これもできる、と。

でも実際に作業をしていてストレスに感じるのは、機能が足りないことより、作業手順の引っかかりだと思うんです。

いまどのボタンを押せばいいのか分からない。押してもいいのか自信が持てない。画面が動いて押し損ねる。同じことをするのに毎回違う場所を探す。

機能そのものは、車とプロトコルが決めてしまうので、あまり僕たちは選べません。

でも、その機能をどういう順番で、どこに置いて、どう見せるかは、僕たちが設計できます。

そして、そこが一番作業に効きます。見た目や手触りの一貫性は、そのままツールの印象——ブランドイメージにもなります。

昔からエンジニアリングのツールは、機能に寄って作られてきました。動けば正解、という世界だったので、それはそれで正しかったのだと思います。ただ、手順の流れのほうは後回しにされがちでした。

だから、機能分だけボタンがあり、機能が増えた分だけボタン数が肥大化していくので、結局そのツールでなにができるのかわからなくなり、使われなくなるのです。

僕は元々、業務プロセスを設計する仕事をしていました。だからこのツールの最初のバージョンから、ずっとここにこだわってきました。

だから、ボタンを1つにしました

これまでこのツールは、ファイルを受け取ってファイルを返すアプリでした。

パーシャルBINと走行ログのCSVをアップロードして、チューニング済みのBINをダウンロードする。それだけです。

つまり、BINを読み出すツールと、ログを録るツールと、書き込むツールは、別に用意する必要がありました。

今回、そこを全部このアプリの中に入れました。K+DCANケーブルを繋いで、ブラウザから直接DMEと会話します。

機能が増えると、普通はボタンも増えます。読み出し、書き込み、ログ開始、ログ停止、学習リセット。並べれば5つ以上です。

そうはしませんでした。画面の中心にあるボタンは、最初から最後までずっと1つです。

そのボタンの表示だけが変わります。

CONNECTION → READ →（必要なら RESET ADAPT）→ START TUNE → STOP → WRITE

CONNECTIONで繋いでVIN・AIF・ソフトウェア番号を確認し、READでDMEからパーシャルBINをそのまま吸い出す。

START TUNEを押すとライブロギングが始まり、走りながらVE計算がリアルタイムで更新されていきます。

STOPしてWRITEを押せば、チューニング済みのデータがDMEに書き戻ります。

大事なのは、このボタンが画面の状態を『記憶』して進むのではないことです。

「次はWRITEのはずだ」とアプリが思い込むのではなく、手元にどのデータが揃っているかを毎回その場で確認して、ボタンの言葉を決めています。

記憶させると、操作が途中で狂ったときにズレが出ます。新しいセッションなのにWRITEのままだったり、繋ぎ直したときにデータの読み込みを飛ばしてしまったり。実際、以前はその手のバグをいくつも出しました。

手元のデータから毎回判断していれば、ボタンが嘘をつくことはありません。

BMWのDS2プロトコルをブラウザのWeb Serial APIで喋らせています。ですのでChrome・Edge・Operaのデスクトップ版が必要です。（Safariは非対応、Firefoxは既定では動きません）

もちろん、これまで通りファイルのアップロード／ダウンロードだけで使うこともできます。ケーブルがなくても、これまで通り使えます。

チェックサム補正が要らなくなりました

引っかかりを消す、という意味では、これが一番効いたかもしれません。

これまでは、BINを編集したら外部のチェックサムツールで補正をかける必要がありました。

今回、CRC-16/ARCの再計算をアプリに実装したので、BINをダウンロードするときも、DMEに書き込むときも、自動で補正されます。

アルゴリズムは、正常な純正パーシャルBINと1バイトずつ突き合わせて、完全に一致することを確認しました。

学習値のリセットをどこに置くか

再チューニングのとき、地味に困るのが「前のマップで学習した値がまだ残っている」という状態です。

その状態でログを録っても、それは前のマップが作った癖を含んだログになってしまいます。

なので、学習値をクリアできるようにしました。

消す前に、DMEが今どんな値を学習しているのかを読み出して表示します。

ラムダ学習の係数2つとオフセット2つ、吸気・排気のVANOS学習、そして6気筒分のノック学習。合計12項目です。

ここで考えたのは、この機能をどこに置くかでした。

学習リセットが意味を持つのは、ログを録り始める直前だけです。走り終わったあとに押しても遅いし、繋いだ直後に押しても早すぎます。

なので、ハブが「START TUNE」と言っている、まさにその瞬間にだけ画面に出るようにしました。それ以外のときは存在しません。

押せるけど押しても意味がないボタン、というのを画面に置きたくなかったんです。

ただ、これは絞りすぎでした。

書き込みが終わった直後。操作を途中でやめたあと。そして、学習を消すためだけにケーブルを挿したとき。どれもマップとセッションが手元にない状態なので、押したい瞬間にちょうどボタンが消えているということが起きていました。

いまはSTARTUPタブで繋がってさえいれば出るようにしています。セッションとECUを扱うのはあのタブなので、作業用のタブのほうは今まで通りです。

もうひとつ気を付けたのは、診断ツールにあるような「全消去」にしなかったことです。

DS2のコマンドで消す範囲を指定して、この12項目だけを狙って消しています。

理由は、スロットル／ペダル、SMGのクラッチ学習、装備検出、クランク角センサーの学習は消したくないからです。

特にCSLコンバート車のSMG-IIは、クラッチ学習を飛ばしてしまうと、ちゃんとした再学習手順を踏まないと戻ってきません。

チューニングをやり直したいだけなのに、SMGの再学習まで巻き込まれるのは理不尽ですよね。

コマンドのバイト列とフィールドの並びは、既存ツールを解析して答え合わせしてあります。

フラッシュカウントリセットも置き場に悩む

MSS54には、あと何回プログラミングできるかという上限があります。プロセッサあたり30回。書き込むたびに1つ消費して、使い切るとDMEはプログラミングを受け付けなくなります。

このアプリは書き込みを繰り返して使うツールです。その残り回数が分かり、下限にせまっていることに気付いたら、その時にリセットできないと引っかかりを感じてしまいます。

なので、ヘッダーに出し、そこからリセットできるようにしました。

VIN、AIF、ソフトウェア番号と並べて、いちばん右に FLASH 12/30。残りが5回を切ると色が変わります。

そして、この数字そのものがボタンです。クリックすると詳細が開きます。

ここは置き場所をかなり迷いました。

ハブの下のサブアクション行——学習リセットが出るあの場所——に置くこともできました。でも、あの行は「いま作業しているセッション」のための場所です。このログを捨てる、録る前に学習を消す、といった今この瞬間の話。

一方フラッシュカウントは、セッションとは関係ありません。ヘッダーがすでにその数字を出しているなら、その数字を変える操作は、その数字の上に置くのが素直だと思いました。

リセットは1.5〜2分かかり、途中で止められません。なので、中断してしまったときの対応手順を、実行ボタンを押す前の画面に書いてあります。起きてしまってからでは調べられないので。

消す前には、消える範囲をブラウザ内にバックアップします。保存に失敗したときは実行しません。

（リセット後の表示は 1/30 になります。0/30 ではありません。先頭の1つは「消費済み」の目印として残る仕様です。）

エラーコメントにはこだわりました。万が一のことが起きた場合の復旧手順が具体的に書いていないツールは多いですよね。AIも最初はそうでした。

AIに、書くならユーザーが実行できる手順を書いてほしいと指示を出しました。その後、実機で書き込みエラーが出たときに同じ手順で復旧できたので、ひとまず正解だと思います。

言語も揃えました。ブラウザ標準の確認ダイアログが21箇所あったのですが、書いたときの気分で日本語だったり英語だったりバラバラでした。しかも危ない操作ほど日本語、セッションの操作は英語、という妙な分かれ方をしていました。いまは全部、同じ仕組みから出しています。

チューニング履歴を残す

DMEと直接やり取りできるようになったことで、扱うものが増えました。

元のBIN、録ったログ、書き込んだBIN。この3つは本来セットのはずです。

なので、この3点を1つの「セッション」としてブラウザに保存するようにしました。

ここでも同じことを考えました。ダウンロードボタンを1つ置いて「BINをダウンロード」と書くと、どっちのBINが落ちてくるのか分かりません。

なので、ダウンロードのアイコンは、それぞれの数字の隣に置いてあります。元のBINはセッション名の下のVINの横、ログは「LOG」の列、書き込んだデータは「FLASHED」の列。その場所がそのまま「何が落ちてくるか」の答えになります。

ログはTesto形式のCSVで出るので、そのまま読み込み直せます。

上の画面だと、Session #2が「#1から派生（BASE = #1で書き込んだTUNED）」になっているのが分かると思います。書き込んだあと、そのチューンを土台にして次のセッションを始められます。チューニングって1回で終わらないですからね。

FLASHEDから落ちてくるのは「WRITEが送った、あるいは送るはずのバイト列そのもの」です。書き込む前にTunerProで中身を確かめたいときも、ここから取れます。

それと、走ってきたログが消えない仕組みを入れました。

これまでログは、SAVEを押すまでブラウザのメモリの中にしかありませんでした。その間にページが再読み込みされると、走ってきた分がまるごと消えます。

普通の「保存し忘れ」とは意味が違うと思うんです。入力が走行そのものなので、燃料と時間と、同じ条件がもう一度揃うとは限らない天気と路面が一緒に消えます。実際に僕も30分ぶんを飛ばしました。

いまはサンプルが届くたびに書き出していて、途中で切れた場合は、次に開いたときにそのとき使っていたBINとセットで戻せます。

あわせて、書き込み中・リセット中・ロギング中にページを閉じたり再読み込みしようとすると、ブラウザの確認が出るようにしました。止められるわけではありませんが、うっかりのCtrl+Rが「本当に閉じますか」という一手間になるだけでも違います。

車がなくても全部試せます

ECUに書き込むツールって、いきなり本番はさすがに怖いですよね。

なので、PRACTICEというチェックボックスを付けました。

これをオンにすると、DMEの代わりにアプリの中の模擬DMEが応答します。

（開発用のMockモードを、オーナーの練習に使えると思い、リネームして残しました。）

ケーブルも車も要りません。接続から読み出し、ライブロギング、書き込みまで、一連の流れをそのまま体験できます。

ちなみに、この記事に載せているチューナーの画面は、全部このPRACTICEモードで撮ったものです。

なのでVINが「MOCKVIN…」だったり、マップの数字がやけに整っていたりします。実車のデータではありません。

初めて触る方は、まずこれで一周流れを掴んでから、車に繋いでみてください。

ズレないUIを作るのに一番こだわりました

流れの設計、と書いてきましたが、実装でいちばん時間を使ったのは、地味に画面を動かさないことでした。

始めて使うツールで流れ作業を行う中、用語も分からない中で次のステップに進んだ時に文字の位置やボタンがズレると何が起きたのか不安になり、一瞬次の操作進めてよいのか不安になりませんか？

この引っかかりこそ最もストレスフルなので、これを避ける実装に気を使いました。

たとえばPRACTICEのチェックボックスの隣には、通信速度を選ぶ欄があります。PRACTICEをオンにすると実機ではないので、この欄は不要になります。

最初は消していました。そうしたら、消えた分だけ行が縮んで、押そうとしていたチェックボックスが指の下から横に逃げるようになってしまいました。

いまは、消さずに見えなくしています。場所は取ったままです。

同じ理由で、エラーや警告を出す行は、何も出ていないときも高さを確保してあります。以前は文言が出るたびに下のパネルが広がって、そのたびに3Dマップがリサイズされていました。

ハブの下のボタン行も高さ固定です。ボタンが1つのときも2つのときも、行の高さは変わりません。この高さは、実際にブラウザで測って決めました。

書き込み中の進捗リングにも1つ小細工があります。

このリング、なめらかに動かすためのアニメーションをあえて付けていません。付けたほうが綺麗に見えるのですが、実際に試すと描画が最初の値で固まってしまい、4%くらいのまま最後まで動かないように見えました。

こういうのは考えても分からないので、都度ブラウザで測って決めています。

つい最近も1つ直しました。学習リセットとフラッシュリセットのダイアログは、中身の量に合わせて箱の大きさが変わる作りでした。フラッシュのほうを測ってみると、確認画面に進むたびに高さが234→412→261px、上端も333→244→319pxと動いていました。

車の識別情報を消している最中に箱がぴょこぴょこ動くと、何かまずいことが起きたように見えます。

いまは両方とも同じ固定の枠に収めて、中身が変わっても箱は1ミリも動きません。

枠を固定しても、まだボタンが動いていました。それぞれの画面が、自分の文章のすぐ下にボタンを置いていたからです。文章が短い画面ではボタンが上に、長い画面では下に来ます。

測ってみると、リセットを押して確認画面に進んだ瞬間に、ボタンが178px下に移動していました。押した指のすぐ下ではなく、だいぶ下です。復旧の画面にいたっては、他の画面より227px上にありました。

車の識別情報が消えたまま止まっている画面で、ボタンを探させるわけにはいきません。いまはどの画面でも、ボタンは枠の同じ高さに並びます。

実車が教えてくれたこと

書き込み機能は、実車で検証済みです。

そして実車に繋いでみて初めて分かったことが、やっぱりありました。

一番厄介だったのは、K-lineの通信が実車で一度こけると、そのあとアプリ側が延々とリトライして復帰できなくなる問題でした。

こういうのは、机上では絶対に出ません。

いまは、通信が切れたときはちゃんと黙って待ってから復帰するようにしてあります。

通信速度は限界まで詰めた

もうひとつ、実車でしか答えが出なかったのが通信速度です。

64KBの読み出しに約123秒かかります。2分です。毎回これを待つので、速くできるものなら速くしたい。

DMEは9600のほかに38400と125000も受け付けることになっています。なので、ブラウザのWeb Serialでどこまで上げられるのか、実車で試してみました。

38400は、切り替え自体は通ります。配線も本当に38400で走ります。ところが、538個に分けて読んでいくうちの最初の17個目までに、DMEが必ず黙りました。通信の間隔を40msまで広げても変わりませんでした。

125000は、DMEが返事はするのですが、そのあとのやり取りが全部タイムアウトします。既存のツールがこの速度を使うときは、フラッシュを消す特殊な手順を先に踏んでいるようでした。読み出しのために踏む手順ではありません。

結局、9600が上限でした。123秒が下限です。

ブラウザからだと、シリアル通信の細かいタイミング制御はWindowsのネイティブアプリほど自由が利きません。ネイティブなら通る可能性は残っていますが、そのためにインストールの要るアプリに戻すのか、と考えました。

インストール不要で、OSを選ばず、更新も勝手に届く。その代わり2分待つ。今回はこのトレードオフでいい、と判断しています。

書き込みは4分かかる

書き込みは9600bpsなので、全部終わるのに約4分かかります。（書き込み2分半＋読み戻し検証70秒）

その間ずっと無反応だと、失敗したのか動いているのか分かりません。だから進捗をリングと％で出しています。消去中・書き込み中・検証中がそれぞれ分かります。

書き込んだあとは、必ず全領域を読み戻して1バイトずつ比較します。そこまで一致して初めて「成功」と表示します。

なお、書き込みは途中で止められません。イグニッションはON・エンジンは停止、電源も安定させてから実行してください。アプリからも同じ内容を確認するようにしてあります。

AIがなければそもそも中身が読めませんでした

ここまで設計の話ばかりしてきましたが、その前提の話もしておきます。

こういうツールを作るとき、一番の壁は「作る」ことではありません。

仕様が分からないことです。

E46M3は2001年の車です。DS2というプロトコルも、EDIABASという診断の仕組みも、公式な仕様書が世に出ているわけではありません。

どのアドレスに何が入っているのか。どのコマンドがどのバイト列なのか。学習値がどの順番で並んでいるのか。

これを知るには、既存のツールの中身を読むしかありません。

以前ならこれは、限られた人しかできない作業でした。僕には無理でした。

でも今は、既存ツールを逆コンパイルして、その中身をAIと一緒に読み解けます。

実際、今回のアダプテーションリセットのコマンドとフィールドの並びは、そうやって既存ツールから読み取った内容と突き合わせて、答え合わせをしています。

つまり順番はこうです。

解析できるようになった → だから作り直せるようになった。

モダナイズの前提条件が、AIによって外れたんです。

AIが進歩する前までは、解析できるようになるのに何年も勉強する必要があると考えてました。 （家に解析の本が積まれています..）

前回のOpenWAMの記事でも「AIがいなかったら数十年かかっていたと思います」と書きましたが、あれは誇張ではありません。

中身が読めるようになって、ようやく「どう並べるか」を考える時間が生まれました。

（ちなみにこのアプリは、コードそのものもほぼ全部AIに書いてもらっています。人の手によるコードレビューは一度も入っていません。）

それでもV2改修はV1新規開発の何倍も時間がかかりました

最初のバージョンは、正直あっという間にできました。

ファイルを受け取って、計算して、ファイルを返す。全部パソコンの中で完結するので、AIと一緒に作ればどんどん進みます。

V2は勝手が違いました。

相手が車になった途端、書いたコードが正しいかどうかが、机上では分からなくなります。確かめるにはガレージに行って、ケーブルを挿して、イグニッションを回すしかありません。

特に、誤ってデータを消してしまったり、壊れたデータを戻す作業はとても手間がかかります。

分かってる面倒はできるだけ避けたいですよね。

なので、机上でできることは徹底的にやりました。DS2で応答を返す模擬ECUを作って、消去も書き込みも本当に起きる状態で、危ない操作を一通り自動で通しています。書き込みの順序、バックアップが消去より先に取れているか、リセット後のカウンターが1/30になるか。そのあたりは機械が毎回検査します。

それでも、足りません。

模擬ECUは結局「僕がそう思っているECU」でしかないからです。実車が違う振る舞いをしたら、間違っているのは模擬のほうです。K-lineが途中でこけることも、速度を上げると黙り込むことも、模擬では一度も起きませんでした。

実車を使った検証は、今のAIにはまだ任せられない部分だと思っています。

コードを書くのも、古いツールを解析するのも、机の上の検証を組むのも、いまはAIのほうが速くて正確です。でも、ケーブルを挿して、キーを回して、画面と車の様子を見比べて「これは大丈夫そうだ」と判断するところは、人がやるしかありません。

そして、人がやるべきところだとも思っています。

車に触る道具である以上、最後に責任を持つのは作った人間です。「AIが動くはずだと言ったので書き込みました」では通りません。

つい先日も、計測用のスイッチを入れ忘れたまま車まで走って、1回分の確認を無駄にしかけました。結局そのスイッチは廃止しました。忘れたら1回分が飛ぶようなものを、そもそも選択肢として置いておくべきではなかったからです。

V2に時間がかかったのは、ほとんどこの往復の分です。

同じ設計思想で診断ツールも作っています

もう一つ、並行して作っているものがあります。

以前、Toolset32のSMGⅡジョブ一覧の記事で、「ジョブがドイツ語で何を意味するか分からない、でもAIのおかげで理解が簡単になった」と書きました。

あれの続きです。ツールの仕様が理解できるようになったので、作り直すことにしました。

INPA（診断）、NCS Expert（コーディング）、WinKFP（プログラミング）。この20年もののツール群を、ブラウザで動くアプリとして作り直しています。

いま動いているのは、診断・データログ・キャリブレーション・アクチュエータテストの4つです。

対応モジュールは、MSS54（エンジン）、SMG II、DSC。

こちらも同じ考え方で作っています。

見ての通り、ボタンが同じです。似せたのではなく、同じ設計から作っているので同じになります。

色の指定も、余白の取り方も、機械が出した数字は等幅で出すという決めごとも、2つのアプリで共通のルールにまとめてあります。片方は最新のフレームワーク、もう片方は素のJavaScriptという全然違う作りなのですが、出てくる画面は同じ言語で喋ります。

こちらのハブも、次にやること1つだけを出します。接続 → 識別情報を読取 → 故障コード読取 → 再読取。

そして、危ない操作（故障消去）はハブに載せていません。丸いボタンの下に、赤い文字で別に置いてあります。これも「押していいものと、よく考えて押すものを混ぜない」という同じ判断です。

「必要十分な機能だけ」という話も、ここでは分かりやすい形になっています。

ECUから取り出せたジョブは、3モジュール合計で323個ありました。そのうちアプリに載せたのは131個です。

残りを載せなかったのは、手が回らなかったからではありません。フラッシュ書き込みやメモリ書き込みといった、WinKFPの領分にあたる危険なジョブは、データを作る段階で正規表現ではじいてあります。アプリに渡るファイルの中に、最初から入っていません。

UIで隠すのではなく、そもそも届かないようにする。うっかり表に出る余地を消しておきたかったからです。

ジョブの一覧そのものも、推測では作っていません。最初はSGBDファイルを力技で解析していたのですが、その方法では80個くらいしか見つけられませんでした。その後EDIABASに正攻法で問い合わせる方法が見つかり、MSS54だけで223個が正しく取れました。Toolset32が表示しているのと同じ、正解のデータです。

日本語の名前の横に、元のジョブ名（STEUERN_EVANOS1_SPAET_VENTILみたいなやつ）をそのまま残してあります。翻訳を信じきらずに、原文も見えるようにしておきたかったからです。

2026年7月18日に、実車との接続にも成功しました。油温87℃、水温62℃、吸気温72℃、吸気VANOS 60°KW。しかも単位はECU自身が持っている定義から読んでいるので、勝手な解釈が入りません。

安全面については、実機モードでは書き込みとアクチュエータ実行がすべてブロックされます。実車で1つ1つ検証が取れるまでは解除しません。デモモードでだけ一通り動かせます。

（この記事の画面も、すべてデモモードのものです。）

まだコーディング（NCS Expert相当）とプログラミング（WinKFP相当）には手が付いていません。公開もまだ先です。

でも、20年前のツールが手放せないままなのは、そろそろどうにかしたいですよね。

近いうちに、VANOSチューニングを統合します

1Dエンジンモデルのシミュレーターの記事で、「何れこのチューナーに統合する予定です」と書きました。

その進捗も書いておきます。

いま躓いているのは、ベースVEマップへのフィッティングです。

シミュレーターの正解データは、DMEが持っているベースのVEマップです。そこにシミュレーション結果を合わせ込めて初めて、「このモデルは僕の車を再現できている」と言えます。

ところが、実車には3900〜4600回転あたりに大きな充填の山があるのに、1Dのモデルではこれがどうしても出せませんでした。

原因は、この山がエアボックスの3次元的な共鳴で起きているからです。1次元の計算では、原理的に出せないものだったんです。

谷の位置も、実車より200〜400回転ほど手前に出てしまう。

ここでずっと止まっていました。

壁を越えたのがデータログの統合でした

前進のきっかけは、まさに今回のチューナーで作ったのと同じ仕組みです。

シミュレーターの側にも、実車からDS2でライブログを取る機能を載せました。

そして、実測したログをVEマップと同じ軸・同じ単位に整えて、シミュレーション結果と直接並べて比べられるようにしました。

これが効きました。

実車が、こちらの思い込みを次々に否定してくれたんです。

まず、ログの数値のスケールが、資料に書かれていたものと違っていました。実車の値と突き合わせて初めて気づきました。

次に、大気圧の設定がシミュレーションの気体の流れに反映されていない、というバグが見つかりました。これは机上では絶対に気づけません。

さらに、VANOSのマップ上の値と実測値の変換関係も分かりました。排気側は符号が反転していたんです。

そして極めつけが、排気側の計算の刻みを半分に細かくしたら、VEが4〜11ポイントも動いたことでした。

それまでは「谷の底を合わせると山が出ない、山を合わせると谷が浅くなる」という、どちらか一方しか取れない状態でした。

それが、いま初めて両方同時に成立しています。

順番は崩しません。まずモデルが実車に追いつくこと。その先にVANOS値の探索があります。

もう少しお待ちください。

機能はそのまま、UIこそチューニングの価値がある

ここまで書いてきた通り、僕がやっているのは、機能を発明することではありません。

車が持っている機能を、どういう順番で、どこに置いて、どう見せるかを決めているだけです。

ということは、同じ部品のまま、別の並べ方もできるということでもあります。

たとえば、ご自身の作業手順に合わせてボタンの順番を組み替える。ショップのブランドカラーに合わせて配色を変える。よく使う3つだけを前に出して、残りを奥に隠す。

中身のコンポーネントはそのままに、そういう作り替えができます。

これまでのシステム開発でも、UIへの投資に対して僕はさんざん説いてきましたが、首を縦に振る経営層はいませんでした。

UIのチューニングこそ、現場の目に見えない負担感を下げ、モチベーションを上げ、結果、因果関係では表せない数値的成果に反映されるものだと思います。

もしご自身の作業や、お店のツールでこういうことをしてみたい方がいらっしゃれば、MESHからご相談ください。

後記

ここまでAIのおかげだと何度も書きましたが、少し補足させてください。

AIが急に賢くなったから作れた、という話ではないと思っています。

AIが読めるのは、誰かが書いて残したものだけだからです。

DS2のやり取りを解読できたのは、二十年前にBMWがその診断の仕組みを作って、ツールとして形に残していたからです。そしてそれを解析して、自作のツールにまとめた先人がいたからです。

CSLコンバートのチューニング手順が分かるのも、フォーラムのオーナーさんたちが何年もかけて試して、失敗も含めて書き残してくれたからです。シミュレーションの土台にしているOpenWAMも、スペインの研究所が公開してくれたものです。

先人が積み上げたノウハウと、先人が実際に作ったモノ。その両方があって、はじめてAIはそれを読むことができます。

だから僕がやっているのは、ゼロから何かを生み出すことではなくて、受け取ったものを次に渡せる形にしているだけなんだと思います。

そして、受け取ったものをどうするかは、僕たちが選べます。

そのまま残すのか。作り直して先に進めるのか。役目を終えたものとして手放すのか。

二十年前のツールをそのまま使い続けるのも、ひとつの選択です。でも使える人が減っていく一方なら、誰かが今の形に置き換えないと、そこで途切れます。

その選択をしていくことが、次の世代に繋ぐ側に回った僕たちの役目なんじゃないかと考えています。

MSS54HP CSL CONVERT /// TUNER はこちらから、無料で使えます。ソースコードもGitHubで公開しています。

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

追伸

作りたいものは、減るどころかどんどん湧いて、正直まったくお金と時間が足りていません。もし投資したいと思ってくださる方がいたら、会社にして、一緒に手を動かしてくれる人を集め、開発を加速させることができます。