役員SNS
TuringTechTalk #35「E2E自動運転を支える車両システム — Less is Moreの設計思想」
この記事に登場する人
はじめに
E2E自動運転は「モデルが賢くなれば走れる」という話に見えがちです。でも実際は、カメラや測位、車両制御、デプロイ、フリート運用まで“走らせ続ける仕組み”が揃って初めて、改善が加速します。
今回のテックトークでは、CTOの山口と、車両・車載ソフトウェア・運用基盤まで幅広く担う渡邉が登壇。アルファードをどう調達し、どう自動運転車両に仕立て、どう安全に制御し、どうCI/CDやOTAで「更新できる車」を作っているのか。さらに、LiDARを外した背景なども含めて、Less is Moreの思想でつながる現場の設計判断を掘り下げます。
※本記事はTuringTechTalk#35の内容を元に一部編集してお届けします。
今日はAIではなく、AIを支える“車両システム”の話
山口： 皆さん、こんにちは。チューリングテックトーク第35回「E2E自動運転を支える車両システムの設計思想」を始めます。私はCTOの山口です。本日は自動運転第2グループのマネージャー、渡邉礁太郎さんに来てもらっています。
チューリングの自動運転は大きく3つのグループで進めています。私が全体を見つつ、第1グループが自動運転AI（走りの中核のモデル）、第2グループが車載システムと車両、第3グループが大規模モデルやリサーチに近い領域。今日はその第2グループの話です。それでは渡邉さん、よろしくお願いします。
渡邉： よろしくお願いします。
アルファードをどう手に入れ、どう“自動運転車両”に仕立てるのか
山口： まず、チューリングはどこまでやっているか。車両は「購入から」ですか？
渡邉： はい、購入からです。ただし新車というより、30系アルファードなので中古市場から調達することが多いです。状態の良い個体を選んで集めています。
山口： で、買ってきたアルファードは普通の車ですよね。そこから「自動運転車両に仕立てる」。具体的には？
渡邉： センサー、計算機、その上のソフトウェアを搭載します。電源まわりも含めて、買ってきた車を“自動運転が動かせる状態”に持っていく。OSやアプリケーションも含めて全部セットアップして、実験に耐える状態にします。
山口： ここって外からは見えないけど全車両でやっていて、これを経て自動運転車両を制御できていると言うことですね。
山口： よく聞かれるのが「市販車をソフトでいじれるの？」という点です。チューリングはどうやって車両制御しているんですか？
渡邉： 30系アルファードはADAS（運転支援）が載っている世代です。ACC（アダプティブクルーズコントロール）やLKAS（レーンキープアシスト）がある。車の中では既に制御が行われているので、その信号を利用して、自動運転しています。ゼロからアクセルやブレーキ、ハンドル角を直接制御するというより、車両が持つプラットフォームの上に乗せる形です。
山口： つまり、物理的な制約や安全側の枠組みは車両のレギュレーションに乗りつつ、上に自動運転の意思決定を載せるイメージですね。
渡邉： はい。
山口： 一般の方でも、もしACCやLKASが付いているなら高速道路などで使ってみると便利です。ただ、市街地は別の難しさがあるので、そこは私たちが開発している領域ですね。
なぜアルファードなのか：入手性＋“ハンドルを切れる”条件
山口： で、そもそも、なぜアルファードを使っているのか。歴史的経緯もありますよね。
渡邉： 諸説ある前提で話すと（笑）、最初期にアルファードを一台確保したことが起点になっているのは大きいと思います。加えて、ADASの標準状態だと制約が強くて、市街地で必要な右左折やUターンのような操舵が難しい。そこでステアリング（EPS）周りのカスタム品を入手できた背景があって、アルファードと条件が噛み合った、というのが大きいです。
山口： たまたま「車両」と「EPSのカスタム周り」の両方が揃って、自動運転車両として成立しやすかった。もちろん中古市場の在庫やグレードの幅、運用面での快適さもある。実験は10時間単位になることもあるので、乗り心地が良いのは現場では効きますよね。
渡邉： はい。実験しやすいです。
山口： 次にハード構成。車両のセンサーと計算機はどうなっていますか？
渡邉： カメラは7〜8台。フロントが3カメラのパターンもありますが、最近はフロント2カメラで合計7台がスタンダードになってきています。あと測位センサーとしてGNSSとIMUを積んで、天井に1つ載せています。車内にはAGX Orinが載っていて、あとは配線、という構成ですね。
山口： 自動運転車ってもっとゴツいセンサー盛り盛りのイメージがあるけど、意外とコンパクト。で、ここで気付く人がいる。「LiDARないの？」と。
渡邉： はい、気づいてしまいましたね（笑）。
「さよなLiDAR」：外した理由は“カメラで代替できた”＋“運用負債を減らす”
山口： 実はAI Dayのスライドから唯一変わったのがここで、LiDARを外しました。社内では「さよなLiDAR」って呼んでましたね。
渡邉： そうですね。最後のLiDARも外して、今はLiDAR無しです。
山口： 理由を整理すると、カメラだけで物体検出やデプス推定の精度が上がってきた。LiDARはレーザーで距離を点群で取れる一方、データ量が大きいし、雨など環境条件の影響もある。カメラのビジョンモデルで3Dボックスや点群相当を推定できるなら、運用上のメリットも大きい。
渡邉： 車両はデータ収集と自動運転の兼用ですが、LiDARは基本的に収集目的で、走行制御には直接使っていなかった。なので外しやすかったです。外すとデータ量・処理量も減るし、活用していないなら負債になりやすい。
山口： ソフト側も、センサーが減るとパイプラインもシンプルになる。これが今日のテーマの「Less is More」に直結します。
ソフトウェアアーキテクチャ：モジュール分割で変更に強くする
山口： 車載ソフトのアーキテクチャは見通しが良い設計になっていると思うんですが、どうですか？
渡邉： ロボティクスや自動運転のシステムって、センサー処理、推論、制御など専門領域が同時に動くので複雑です。ただ、各モジュールを独立させてプロセス間をつなぐ形にすると、変更しやすいし見通しも良くなる。例えばLiDARを外すなら、そのモジュールを消すだけで済む、といった具合です。
山口： このソフトウェアアーキテクチャは内部でいじり始めてかなり経ってますよね。
渡邉： そうですね。2年以上は経ってると思います。
山口： チューリングはソフトウェアの設計や要件を出して作り込んでいくというよりは、その時の要求に応じてアジャイルで作り替えていくことが多いので、その点のやりやすさもこのアーキテクチャが役立っているのかなと思いますね。
渡邉： そうですね。そういうサイクルを回しやすいアーキテクチャになってると思います。
大きなモデルへの対応：リモート推論とeGPU
山口： 次は「様々な自動運転モデルへの対応」。チームが複数あると、モデルのサイズや要求が違う。車両は同じ基本セット。どう吸収していますか？
渡邉： そうですね。アルファードに載っている基本構成はJetson AGX Orin 1台です。この構成だけでTokyo30も達成していますが、研究用途では「もっと大きいモデルを試したい」という要求が出てくる。そのたびに車載計算機そのものを載せ替えるのは、運用的にも開発的にも現実的ではありません。
山口： そこで採っているのが、「推論だけを車外（あるいは別デバイス）にオフロードする」という設計ですよね。
渡邉：社内では「リモート推論」と呼んでいて、カメラ入力やセンサー処理、車両とのインターフェースといったリアルタイム性と安定性が求められる部分はOrin側で担当する。一方で、ニューラルネットワークの推論だけを別の計算リソースに切り出す、という構成です。
山口： 実装としては大きく2パターンありますね。
渡邉： 1つ目がワークステーション型です。Orinと外部のワークステーションをEthernetで接続し、カメラ画像を送って推論し、結果（軌跡や制御指示）だけを戻す。VLAモデルの実車走行デモでは、RTX 4090を積んだワークステーションでこの構成を使っていました。
山口： 「LANで繋ぐだけでしょ」と思われがちですが、実際はここが一番難しい。
渡邉： そうですね。特にネックになるのは画像データの転送です。
複数台のカメラ映像を、1GbEという制約のある帯域で送りつつ、レイテンシを数十ミリ秒に抑えなければならない。なので、単にソケットで投げるのではなく、プロトコル設計やデータ圧縮、転送単位の最適化をかなり細かくやっています。
山口： もう1つがeGPU型ですね。
渡邉： はい。こちらはワークステーションを丸ごと積むのではなく、GPU単体をOrinに接続して推論をオフロードする方式です。最近はUSB4やThunderbolt 4によるPCIトンネリングが使えるようになってきて、USB経由でもPCIデバイスのようにGPUを扱える。現在はAMDのRadeon系GPUで実験・検証が進んでいて、研究用途では十分に使えるレベルまで来ています。
CI/CD：ロボティクスで“実機込みの自動テスト”を回す
山口： ここからソフトウェア開発の話。CI/CDにかなり力を入れていると。
渡邉： 自動運転システムは複雑で、コード変更の影響範囲が読みにくい。速度は落としたくない。だから自動テストが重要なんですが、ハード依存があるのでクラウドだけでは完結しない部分もあります。そこでチューリングではCI/CDのパイプライン自体を強くして、変更を素早く安全に流せる形を作っています。
ユニットテストのようにクラウドで十分回せるものはGitHub Actionsなどの通常ランナーで回す。一方で、CUDAやNVIDIA系API、Arm環境など“車載に近い前提”が必要な部分は、Orin実機をCI用に並べて自動テストを回す。さらに、CPU/アーキテクチャのバリエーションが必要なところは、Namespaceのような外部ランナーも使っていて、クラウド／外部ランナー／Orin実機を“同じCIの中で同列に扱える”ように統合しています。
山口： クラウドでできるものはクラウド、CUDAやNVIDIA APIなど実機が必要なものはOrinで、という切り分け。
渡邉： そうです。さらにテスト時間もモニタリングして、長くなったら改善する。カバレッジもCodecovで可視化していて、以前は取りにくかった領域も、Orin実機テストを組み込むことで段階的にカバレッジを上げてきた、という流れです。
山口： ロボティクスの分野でここまでCI/CDを整えている会社は、まだ多くない。ここはチューリング独自の頑張っているところですね。将来的には、引退した車両そのものをCIのテスト環境として組み込む、みたいな発想もあり得ますね。
渡邉： はい、そうですね（笑）。
フリート管理とOTA：台数が増えるほど“人手管理”が破綻する
山口： 次はフリート管理。車が増えると、デプロイが大変になりますよね。
渡邉： はい。Webのように100台へ一気にばらまく、ができない。車ごとに用途やセンサー構成が違うし、チームが使っていて「今は無理」もある。最初はExcelやNotionで管理しましたが、いろんなデータベースを紐づけると重くて破綻する。だから、車両や機材、ソフトの状態を自動取得して、Webで見えるフリート管理システムを作りました。
山口： 開発期間は3ヶ月程度。内製でクイックに立ち上げた。
渡邉： はい。最後に残っていた“自動化できてない部分”を自動化した感じです。OTAもここに統合していて、更新状況が見えます。
山口： OSレイヤーまで更新できる、というのは攻めてますね。失敗すると起動しなくなるリスクがある。
渡邉： そこでA/Bアップデート方式です。スマートフォンでも同様の形式がとられてたりしますが、A領域が現行、B領域に新しいイメージを書いて、起動確認できたら次回からBで起動という形になっています。失敗したらAに戻れるので安全性が高いですね。
Less is More：コードもハードも手順も“削る”ほど強くなる
山口： いよいよ本題。「Less is Moreの設計思想」。渡邉さんの言う“削る”は、具体的に何を指します？
渡邉： ソースコード削減、ハードウェア削減、手順簡略化の3つです。
例えば同じことができるなら、より少ないコードで実現できる方を選ぶ。使われていないコードや、歴史的に残っているだけの処理は積極的に消す。結果としてテストカバレッジも上がるし、新しく入ってきたエンジニアが全体像を掴むスピードも早くなります。
山口： 次がハードウェア。LiDARを外したのは象徴的な判断でしたが、「性能が足りるか」だけでなく、データ量・計算資源・運用負荷・故障点まで含めて見た結果ですよね。
渡邉： はい。センサーが1つ増えると、それに対応するドライバ、データパイプライン、監視、トラブル対応が全部増える。もし同等以上の情報がカメラ＋ソフトウェアで得られるなら、ハードは減らした方が全体として強くなる。これはLiDARに限らず、測位センサー（GNSS/IMU融合ユニット）についても同じ考え方です。
山口： 天井に載っているデバイスが減ると、車高制限や駐車場制約といった運用上の摩擦も減る。Less is Moreは、性能だけでなく「現場で使い続けられるか」という観点でも効いてきますね。
渡邉： そして3つ目が手順です。自動運転システムは放っておくと、「この順番でスイッチを入れて、ここを確認して…」という暗黙知だらけの操作になりがちです。でもそれは再現性がなく、チームがスケールした瞬間に破綻します。
山口： 実験できる人が限られる、という状態は開発速度のボトルネックになりますよね。
渡邉：はい。なので、誰が触っても同じように立ち上がることを最優先にしています。ソフトウェアの起動順、デバイスの初期化、ログ取得まで含めて、「考えなくていい状態」を作る。これもLess is Moreの一部です。
山口： E2Eの思想も「シンプルにしてスケールで勝つ」。車載システムでも同じ思想で、ブラックボックスや依存が増えるほど運用と改善が遅くなる。ここまでソフトウェアの話が中心でしたけど、これはチューリング全体の思想でもありますよね。
今後の展望：車種対応、次世代SoC、ベンダー多様性へ
山口： 最後、今後の展望。渡邉さんのチームとして何をやっていきますか？
渡邉： 大きく3つです。1つはアルファード以外の車種への対応。2つ目は次世代SoCへの対応で、Orinの次のThorなども見据える。3つ目はNVIDIAだけでなく、他ベンダーSoCも含めて対応していくこと。量産を考えると、SoCがNVIDIAとは限らないので、ここは避けて通れません。
山口： つまり“走れるAI”を“どの車でも動く”に持っていく。これは単なる技術対応というより、事業としてスケールするための前提条件ですよね。今は自分たちの開発車両を中心に取り組んでいますが、今後はより多くの車両、より多様な計算機やSoCに対応していくことになります。アーキテクチャの工夫で吸収できる部分は最大限共通化していくとしても、やはりチームや組織の規模そのものを段階的に広げていくことは避けられないですよね。
渡邉：はい。実際にシステムを前に進め、運用まで含めて支えていくためには、エンジニアの人数をきちんとスケールさせていくことも必要だと考えています。Less is Moreは「削ること」そのものが目的ではなく、やりたいことを実現するために、できるだけ余計なものを増やさないという考え方です。たとえば、NVIDIAのSoCで動かすケースもあれば、Snapdragonなど他ベンダーのSoCで動かすケースも出てきます。そうした状況でも、それぞれにきちんと対応しつつ、共通化できる部分は極力共通化していく、という進め方になると思います。
山口：そうしたシステムを一緒に作っていく人材としては、どんなバックグラウンドの方がフィットしそうでしょうか。
渡邉：第2グループでいうと、Linuxを中心にシステム全体を見ながら開発してきた方は特に相性がいいと思います。車載や組み込みに近い領域を触ってきた方や、車のECUアーキテクチャに詳しく、その上で動くソフトウェアを書いてきた方もフィットします。
また、ソフトウェアが主軸だけれど車両やデバイスにも関わっていきたい、ソフトとハードの境界をまたいで考えることを楽しめる方には、かなり手触りのある環境だと思います。
山口：純粋なソフトウェアエンジニアであっても、車や計算機、デバイスといったハードウェアとの関わりが大きいのが、この車両システム開発の特徴ですよね。
渡邉：はい。ソフトだけ、ハードだけ、という分業ではなく、その両方を行き来しながら考えられる人にとっては、今まさに面白いフェーズだと思います。
山口：そうした仲間を増やしながら、車両システムやソフトウェアスタックそのものも、これからさらに成長させていきたいと考えています。
Q&A一覧
以降は視聴者のQAに回答していきました。詳しくは動画をご覧ください。
- どんなセンサー構成でしょうか？（LiDAR／カメラ／ミリ波レーダー等、取得情報について）
- LiDARなしだと雨や物影に誤認識するのでは？（センサー特性について）
- 市販アルファードを自動運転車に改修する際、1台あたりハード追加費はどのくらい？
- 車体ごとにインストールが異なる場合、テスト結果も異なるが統一的に管理している？
チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししE2Eスケールアップチームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。
