End-to-End自動運転AIをクルマに載せる現場の絶望｜実装エンジニアが直面する4つの壁

※本記事にはプロモーション（広告）が含まれています。

カメラとレーダーが捉えた周りの様子を入れると、AIがクルマの進む道を描いて返してきます。

End-to-End（エンドツーエンド）のAI自動運転を一言で表すと、そうなります。

これまで何人ものエンジニアが手分けして作ってきた仕組みが、一つのAIモデルにまとまっていきます。自動運転の作り方そのものが、大きく変わろうとしています。

でも、AIモデルが賢くなれば、そのままクルマに載せられるわけではありません。私はAIを実際の車両に載せる仕事をしていますが、本当の難しさはAIモデルの「外側」にあると感じています。

この記事では、End-to-EndのAI自動運転をクルマに載せるまでの壁を、AIを実際の車両に載せている現役エンジニアの視点で解説し、最終的にあなたが「AIモデルの外側」に何が求められるのかを理解できるようにします。

なお、ここに書くのは会社の見解ではなく、一人のエンジニアとしての私の考えです。業務上の機密にあたる内容は含めていません。

これまでの自動運転：認識・判断・操作の分業

これまでの自動運転は、人間の運転を三つの工程に分けて作られてきました。周りを見る「認識」、どう動くかを決める「判断」、ハンドルやアクセルを動かす「操作」です。

工程ごとに担当が分かれ、それぞれがルールを積み上げていきます。どこで何が起きたのかを追いかけやすいのが、この作り方の強みです。

End-to-End：三つの工程が、一つのAIモデルになる

End-to-EndのAI自動運転では、認識・判断・操作がまるごとAIモデルに置き換わります。カメラとレーダーの情報を入れると、AIモデルは途中の答えを外に見せず、最終的なアウトプットだけを返してきます。

そのアウトプットが、クルマが進む道（パス）と速度の情報です。方式によっては、ハンドルやアクセルの操作量を直接出すものもありますが、この記事ではパスと速度を出す形で話を進めます。

たとえるなら、細かく分かれていた工場の生産ラインが、一人の職人の手仕事に置き換わるようなものです。職人の腕は確かでも、頭の中で何を考えたのかは、外からは見えません。

このブログでも、カメラ映像だけで走るEnd-to-Endのミニカーを作ってみました。ミニカーなら、AIが動けばそれで完成です。でも、人が乗る本物のクルマでは、ここからが本番になります。

それでも、クルマに載せるには大きな壁がある

AIモデルの性能だけを見ていると、見落としてしまう壁があります。それは、AIモデルを「クルマ」という製品に組み込むための壁です。主なものを、四つに分けて書いていきます。

壁①：人の命を最終的に保証するのは、OEMだ

AIモデルがどれだけ優秀でも、事故が起きたときに責任を負うのはAIではありません。人の命を最終的に保証しなければならないのは、クルマを作って売るOEM（自動車メーカー）です。

だからOEMは、AIからどんな出力が出てきても、車両として異常な挙動になりそうなら即座に検知する必要があります。AIの答えを信じるかどうかを、最後に決めるのは車両側です。

センサーがおかしくなっても、AIは自分では気づけない

もう一つ厄介なのが、入力の異常です。End-to-EndのAIへのインプットは、カメラとレーダーの情報です。そのセンサーから異常な情報が届いても、AIはそれを「今の周りの様子」として受け取り、そのまま答えを出してしまいます。

目隠しをされたことに気づかないまま、運転を続けるようなものです。だから、「カメラやレーダーがおかしい」と手を挙げるフラグは、AIの外側、OEM側のルールベースの仕組みで立てる必要があります。

なぜ、AIに任せられないのか

理由は、「どこで止めるか」という線引きにあります。

たとえAIが「大丈夫だ」と判断していても、人をひいてしまう確率が1%でもあるなら、それは止める必要があります。

ところがAIは、そこに明確なクライテリア（判断の基準）を持ちません。どこからが危ないのかという線は、AIの中のどこにも書かれていません。

だからその線は、人間がルールベースで引きます。そして線を越えたら、ドライバーに運転を介入してもらいます。命に関わる最後の判断を、基準を持たないものに預けるわけにはいかないのです。

一つの仕組みだけでは足りません。入口と出口、そして異常が起きたあとの振る舞いまで、いくつものフェールセーフ設計を重ねていく必要があります。

壁②：膨大なデータを吸い上げる仕組みを、新しく作る

End-to-EndのAIは、データで育ちます。SDVの記事でも少し触れましたが、AIの学習は画像データと相性がいいのです。走行中の映像を含む膨大なデータを、クルマから集めて学習に回すことになります。

ところが、その画像データをアップロードするのは、一筋縄ではいきません。

通常の車両：ゲートウェイを通して、車載通信機からクラウドへ

通常の車両がクラウドに情報をアップロードするときは、まずゲートウェイを通します。ゲートウェイが車内の情報を整理して、車載通信機（TCU）に渡します。そこから、クラウドへ上げていきます。

ところが画像データは、数が膨大すぎて、ゲートウェイでは情報を整理しきれません。いつもの通り道に流し込めば、そこで渋滞が起きてしまいます。

画像データ：強力なドメインECUから、直接車載通信機へ

そこで、非常に高性能なドメインECUを置き、その中でAI処理を行います。そして、撮影した画像はゲートウェイを挟まずに、直接車載通信機へ渡します。そうしてオフボード（車外のクラウド）とのやり取りを行う必要があります。

つまり、データの通り道そのものを引き直すことになります。AIモデルを一つ載せるために、OEM側の車両のシステム構成を新しく組み立てる必要があるのです。

壁③：カメラやレーダーは、外乱の少ない場所に置く

AIが見る世界は、センサーが見た世界そのものです。だから、カメラやレーダーは、なるべく外乱が少なくなるようにレイアウトしなければなりません。

雨粒、汚れ、光の映り込み、振動。外乱になりうるものは、身の回りにいくらでもあります。センサーをどこに、どの向きで置くかは、AIの性能を左右する設計の一部です。

壁④：安全に寄せすぎると、クルマとしての魅力が削られる

ここまで読むと、「とにかく安全側に倒せばいい」と思うかもしれません。でも、そう単純ではありません。

ADAS（運転支援）の観点だけで、セーフティ側にばかり寄せると、今度は別のところにしわ寄せが来ます。

安全、乗り心地、デザイン、コスト。どれか一つを満点にすると、ほかのどれかが欠けていきます。考慮するべき点は、膨大です。そのつり合いを取ることこそ、クルマづくりの難しさなのだと思います。

クルマとソフトウェアの関係を、もっと知りたい人へ

AIやソフトウェアがクルマづくりをどう変えていくのか。その全体像をつかむなら、この本がわかりやすいです。

まとめ：AIモデルの外側に、クルマづくりがある

カメラとレーダーが捉えた周りの様子を入れると、AIがクルマの進む道を描いて返してきます。その一本の線を、人が安心して身を預けられる「クルマの動き」に変えること。そこに、OEMの仕事があります。

AIを実車に載せる現場の壁については、「AIを実車に載せる現場で味わう5つの絶望」の記事でも書いています。あわせて読んでもらえたらうれしいです。