AIを実車に載せる現場で味わう「5つの絶望」｜自動運転エンジニアが見た開発のリアル

雨の降る夜、仕事を終えてクルマで帰路につく。ワイパーが規則正しくフロントガラスを拭うたび、対向車のヘッドライトが水滴ににじんでは消えていく。

こんな夜は、昼間に実験車両で見たセンサーのログを思い出してしまいます。人間の目なら気にも留めない雨粒ひとつで、AIの「目」は簡単に曇ります。そして頭に浮かぶのは、その日の会議でも決着しなかった、込み入った調整ごとです。

家に着いてスマートフォンでニュースを開くと、華々しい見出しが並んでいます。

「End-to-End AIが自動運転のすべてを解決する」「SDV（Software Defined Vehicle）が自動車産業を根本から変える」。

世の中は、ソフトウェアがすぐにでもモビリティを変えるという熱狂に包まれています。

しかし、先行開発の現場でAIを実車に載せ、システムとして動かすところまでを担う私たちの現実は、はるかに泥臭いものです。

この記事では、AIを実車に載せる現場でぶつかる「5つの壁」を、AI自動運転を実際の車両へ適用している現役エンジニアの視点で解説し、最終的にあなたが「技術だけでは解けない課題」とどう向き合うべきかを提示します。

書いているのは、国内の自動車メーカーで、AI自動運転を実際の車両へ適用する役割を担っているエンジニアです。

普段は、クラウドで学習したAIモデルを実車のECUに載せ、センサーや車載ネットワークと組み合わせて「実際に走る」状態にしています。大学院で航空宇宙工学を学び、宇宙からクルマの世界へ来た経歴は、プロフィールにまとめました。

AIを実車に載せるときにぶつかる「5つの壁」

どれほどクラウド上で優秀なAIモデルを学習させても、実車に載せた途端、いくつもの壁が容赦なく立ちはだかります。大きく分けると、モノの壁（①〜③）、ルールの壁（④）、人の壁（⑤）です。

ひとつずつ見ていきましょう。

壁①　雨粒ひとつで狂うセンサー

冒頭の雨の夜のように、雨粒ひとつでカメラやLiDARの出力にはノイズが乗り、学習時には見えなかった「現実」がモデルを揺さぶります。

自動車メーカー（OEM）の仕事は、ソフトウェアを車両に実装することだけではありません。こうした外乱に強い（ロバストな）センサー配置を設計することも、重要な仕事なのです。

壁②　AIのデータを流すには細すぎる車載ネットワーク

カメラの映像はLVDS系の特殊ケーブルで特定のECUに直結し、ECU同士は帯域の細いCANの束でつながっています。

機能ごとにECUを分けてきた、分散型の配線です。この形は、車両全体のデータを集めて一つのAIで判断するEnd-to-Endの発想と、そもそも相性が悪いのです。

壁③　刷新を拒む既存プラットフォーム

そこで、大容量の通信線（車載Ethernet）を幹線にして、ゾーンECUへとアーキテクチャを刷新しようとします。すると今度は、既存の車両プラットフォームと真正面からぶつかります。

ワイヤーハーネス、電源、ECUの配置、そして過去の車種で積み上げてきた検証資産。そのすべてが「大きく変えないこと」を前提に最適化されているからです。

壁④　誰も「正解の物差し」を持っていない

さらに厄介なのが、評価の基準そのものが存在しないことです。End-to-EndのAIを量産車に本格的に展開しているのは、テスラなどごく一部に限られます。

サプライヤーにも経験がほとんどなく、「何をもって合格とするか」という基準（クライテリア）を、まだ誰も持っていません。

具体例を挙げます。レーダーが捉えた生のデータ（点群データ）を、車両の判断を担うコンピューター（ドメインECU）に直接取り込み、AIで処理する場合を考えてみます。

これまでのレーダーは、センサーの中で「前方30mに車が1台」といった物体の情報にまとめ、細かな揺らぎをならしてから出力していました。ノイズは、出力の段階で吸収されていたわけです。

ところが、生データをそのままAIに入力すると、事情が変わります。

1. レーダーの電波は、バンパーを透過して出入りする。
2. そのとき、バンパーの素材や形状、塗装によって、わずかな乱れ（外乱）が生じる。
3. この乱れが、AIの頭の中にある「世界の質感（テクスチャ）」にどう影響するのか。それが、まだ解明されていない。

そして、この「わからない」が、次の問題を生みます。

影響がわからなければ、基準は決められません。基準が決められなければ、サプライヤーとも合意できず、安全性を説明することもできません。これが、いま現場が直面している大きな問題です。

壁⑤　「100％の安全」を求める文化とAIのあいだ

そして、技術以上に骨が折れるのが社内の調整です。

ブレーキやステアリングを長年担ってきたハードウェアの部署と、AIとでは、「安全」の考え方がそもそも違います。

この違いが、そのまま社内の摩擦になります。

だから、AIを車両に載せようとすると、ハードウェアの部署からは厳しい目が向けられます。

「その判断が絶対に間違わないと、どうやって保証するのか」。クルマの安全を守り続けてきた誇りがあるからこその問いであり、その気持ちはよくわかります。

それでも、AIを使う以上、この問いに「はい」とは答えられません。だから、次のような手を重ねていきます。

• AIに任せる範囲を絞る
• 従来型の制御で、常に見張る
• 万一のときは安全に止まる仕組みを、二重三重に用意する

理想と安全のあいだで現実解を探り、関係部署と一つずつ合意をとっていく作業は、正直なところ、相当な根気がいります。

理想のソフトウェアと、物理的なハードウェアの「狭間」。既存のプラットフォームに最新AIをただ“後乗せ”するだけでは、システムは必ずどこかで破綻します。これが、モビリティ開発の最前線で起きているリアルです。

本当の壁は「技術」より「組織」にある

東野圭吾の『容疑者Xの献身』のようなミステリー小説を読んでいると、バラバラに見えていた手がかりが、最後に一本の線でつながる瞬間があります。あの「そういうことだったのか」という感覚がたまりません。

クルマづくりも、本来はそうあるべきです。センサー、コンピューター（ECU）、配線、ソフトウェア。別々に作られた部品が、最後に一台のクルマとしてピタリと噛み合う。

ところが現実は、そう簡単にはいきません。

家づくりにたとえると、わかりやすいでしょう。

クルマの開発でも、同じことが起きています。

部品ごとに担当する会社（サプライヤー）や社内の部署が分かれ、それぞれの都合や立場がぶつかり合います。その結果、クルマ全体として最適な設計にたどり着けないのです。

エンジニアの世界では、後回しにした問題が借金のようにたまっていく状態を「負債」と呼びます。そして、この負債には大きく2種類あります。

私が日々向き合っているのは、技術的負債よりも、むしろ「組織的負債」の方です。どれだけ優れたコードを書いても、組織の仕組みは変えられません。現場からの積み上げ（ボトムアップ）だけでこの構造を覆すのは、ほぼ不可能です。

だから私は、自分のキャリアを見つめ直した

目の前のパラメータをいくら磨き上げても、モビリティの構造的な課題は解けません。必要なのは、ビジネスと組織の全体設計、つまり上流からアーキテクチャ全体を設計し直す視点です。

だからこそ私は、会社の外から、組織の枠を越えて提案できるコンサルティングファームやITベンダーへの転職を検討しました。

AIを実車に適用する現場で、実装とインテグレーションに向き合うなかで、見えてきたものがあります。

雨粒ひとつに揺らぐセンサーにも、会議室で決着しない調整ごとにも、現場で向き合ってきました。その経験を、今度は上流から構造を変える側で活かしたいと考えています。

このブログで書いていくこと

このブログは、一人の自動運転エンジニアのリアルな備忘録です。最先端AIの理想とレガシーな自動車開発の「境界線」でもがきながら、自分のキャリアを組み立て直していく過程を残していきます。

ワイパーが雨を拭っても、フロントガラスの向こうの道はすぐには晴れません。それでも、走り続けることはできます。

理想と現実のギャップにもがきながらも、本質的な課題に向き合おうとしている誰かにとって、この記録が少しでも参考になれば嬉しいです。

自動車メーカーへの転職を考えている人は、入ってから「思っていたのと違う」とならないよう、自動車メーカーに転職して後悔する人の3つの特徴も読んでみてください。