【初投稿】自動運転エンジニアがキャリアを「リファクタリング」する理由｜End-to-End AIの夢と車載ネットワークの現実

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

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

家に着いてスマートフォンでニュースを開けば、「End-to-End AIが自動運転のすべてを解決する」「SDV（Software Defined Vehicle）が自動車産業を根本から変える」といった華々しい見出しが並ぶ。世の中は、ソフトウェアがすぐにでもモビリティを変えるという熱狂に包まれている。

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

書いているのは、神奈川に開発拠点を構える国内の自動車メーカーで、AI自動運転を実際の車両へ適用する役割を担っているエンジニアだ。普段は、クラウドで学習したAIモデルを実車のECUに載せ、センサーや車載ネットワークと組み合わせて「実際に走る」状態にしている。大学院で航空宇宙工学を学び、宇宙からクルマの世界へ来た経歴は、プロフィールにまとめた。

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

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

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

冒頭の雨の夜のように、雨粒ひとつでカメラやLiDARの出力にはノイズが乗り、学習時には見えなかった「現実」がモデルを揺さぶる。自動車メーカー（OEM）にとっては、ソフトウェアを車両に実装するだけでなく、こうした外乱に強い（ロバストな）センサー配置を設計することも重要な仕事なのだ。

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

カメラの映像はLVDS系の特殊ケーブルで特定のECUに直結し、ECU同士は帯域の細いCANの束でつながっている。機能ごとにECUを分けてきたこの分散型の配線は、車両全体のデータを集めて一つのAIで判断するEnd-to-Endの発想と、そもそも相性が悪い。

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

そこで大容量の通信線（車載Ethernet）を幹線にし、ゾーンECUへとアーキテクチャを刷新しようとすると、今度は既存の車両プラットフォームとの強烈なコンフリクトが起きる。ワイヤーハーネス、電源、ECUの配置、そして過去の車種で積み上げてきた検証資産。そのすべてが「大きく変えないこと」を前提に最適化されているからだ。

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

さらに厄介なのが、評価の基準そのものが存在しないことだ。AIを使った自動運転を量産車で本格的に実用化できているのは、テスラなどごく一部の企業に限られる。部品を供給するサプライヤーにも経験がほとんどなく、「何をもって合格とするか」という評価の基準（クライテリア）を、まだ誰も持っていない。

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

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

ところが、AIに生データをそのまま食わせるとなると話が変わる。レーダーの電波はバンパーを透過して出入りするが、そのときバンパーの素材や形状、塗装によって、わずかな乱れ（外乱）が生じる。この乱れが、AIが頭の中で組み立てる周囲の空間、いわば「AIが見ている世界の質感（テクスチャ）」にどう影響するのか。それが、まだよくわかっていないのだ。

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

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

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

ブレーキやステアリング、車体などを長年担ってきた歴史あるハードウェアの部署は、「壊れないこと」「誤作動しないこと」を、膨大な試験で一つひとつ証明してきた。そこでは、安全とは「保証するもの」だ。

一方で、AIはデータから学んだ確率で判断する。どれだけ学習させても、「どんな状況でも100％正しく動く」と言い切ることはできない。

だから、AIを車両に載せようとすると、ハードウェアの部署からの当たりは強い。「その判断が絶対に間違わないと、どうやって保証するのか」。クルマの安全を守り続けてきた誇りがあるからこその問いであり、その気持ちはよくわかる。

それでも、AIを使う以上、この問いに「はい」とは答えられない。AIに任せる範囲を絞る、従来型の制御で常に見張る、万一のときは安全に止まる仕組みを二重三重に用意する——。理想と安全のあいだで現実解を探り、関係部署と一つずつ合意をとっていく作業は、正直なところ、とても骨が折れる。

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

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

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

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

ところが現実は、そう簡単にはいかない。家づくりに例えるとわかりやすい。

一軒の家を建てるのに、キッチンはA社、お風呂はB社、電気工事はC社と、別々の業者に任せたとする。各社は自分の担当部分を完璧に仕上げる。ところが、業者同士がほとんど相談しないまま進めた結果、「キッチンの換気扇を付けたい場所に、電気の配線が来ていない」といったことが起きる。しかも、どこを直すにも各社の都合や契約がからみ、誰も家全体を直そうとはしない。

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

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

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

だから私は、自らのキャリアを「リファクタリング」する

目の前のパラメータを調整するだけでは、モビリティの構造的な課題は解決できない。必要なのは、ビジネスと組織の全体設計、つまり上流からアーキテクチャ全体をリファクタリングする視点だ。

だからこそ私は、一つのメーカーの枠を出て、業界全体の最適化に関われるコンサルティングファームやITベンダーへの転職を検討している。

AIを実車に適用する現場で、実装とインテグレーションに向き合ってきたからこそ見える課題がある。その経験を、今度は上流から構造を変える側で活かしたい。

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

このブログは、最先端AIの理想とレガシーな自動車開発の「境界線」でもがく一人の自動運転エンジニアが、自らのキャリアを再構築（リファクタリング）していくための、リアルな備忘録だ。

同じように、巷の理想と現実のギャップに苦しみながらも、本質的な課題解決に向き合おうとしている誰かの参考になれば嬉しい。