役員SNS
Turing TechTalk#44 車載の制約下で成立させる自動運転 ─ E/Eアーキと統合設計
はじめに
完全自動運転AIを開発することと、それを実際の市販車に載せて安全に走らせることの間には、大きな隔たりがあります。市販車にはすでに完成された通信規格や安全機構、電源システムが存在しており、そこに新しいシステムを違和感なく統合する電気・電子的な設計力が欠かせません。ベース車両が持つ物理的・電気的な制約をいかに乗り越えるかが、量産車を自動運転車に仕立てるうえで大きな技術的課題になっています。
今回のTech Talkでは、CTOの山口と、Driving System2チームでシニアエンジニアを務める山岡が登壇。CANバス解析、車検基準に適合させる物理実装、独立電源設計、フェールセーフ機構、車両適合の開発プロセスまで、市販車を自動運転車へと仕立て上げる技術を詳しく紹介しました。
※本記事は「Turing Tech Talk #44」の内容をもとに、一部編集のうえお届けします。
自動運転を車に載せるための「E/Eアーキテクチャ」とは
山口：そもそもこのE/Eアーキっていうのは、聞いたことのない人も多いかなと思うんですけれども、E/Eって何か教えてもらえますか。
山岡：Electrical/Electronicという意味で、略し方はいくつかあります。自動車を開発・設計するときには、たくさんのコンピューターが乗っていて、センサーや、椅子が動いたり、カーナビが動いたりする電気のものが車内にたくさん搭載されています。それらをどう繋いでいくかというところが、一般に「E/Eアーキ（電気/電子アーキテクチャ）」と呼ばれています。今、後ろに見えている車も自動運転にしているので、それに対してさらにチューリングとしての機構を上乗せしています。
山口：なるほど、よくわかりました。これ、日本語で言うと電気電子ですか。
山岡：電気電子ですかね。
山口：自動車や製造業にいないと、電気とは何か、電子とは何かというのはあまりピンとこないと思うんですが、これ電気と電子は、車の文脈としては違うものですよね。
山岡：そうですね。基本的には電気、バッテリーがあって、電源をつないで、スイッチが動く。それに対して電子というのは、マイコンが入ってきたり、ソフトウェアの話が入ってくる領域です。
山口：例えば自動運転の車両で言うと、車両とセンサーとで通信するような、信号のやり取りみたいなところですね。
山岡：そうですね。ただ、そこの境界は最近薄れてきていて、結局セットで論じる必要があります。
山口：なので、電気電子はセットという風にまとめられて、1つの単語として使われることが多いんですね。よくわかりました。
チューリングは、中古市場での流通量が豊富で状態の良い車両を安定的に調達できる「30系後期型アルファード ハイブリッド」（トヨタ自動車）をベース車両に採用しています。市販車は当然ながら自動運転を想定して設計されていないため、独自のカメラ（フロント3台・サイド4台・リア1台の計8台）や車載計算機「NVIDIA Jetson Orin」、ルーフのGNSS（Global Navigation Satellite System：全球測位衛星システム）などを追加し、既存の車両システムと安全に協調するようE/Eアーキテクチャを上乗せ・統合設計する必要があります。
自動車は1台で完結した完成度の高い工業製品であり、自動運転システムを追加するには、車両に存在する4つの強力な制約を乗り越えなければなりません。1個目が「バスは満員電車」というものです。
山口：バスは満員電車？
山岡：バスというのは、CANバスのことです。CANバスを略してみんなバス、バスと呼ぶので、少しややこしいんですが。
山口：なるほど、混乱しますね。バスなのに電車みたいで。
山口：ここでいうバスは、通信の流れる経路のことですね。
山岡：車の中ではさまざまなECU同士がすでに通信していますから、そこにチューリング側から追加・書き換えの形で信号を送ると、単純に割り込ませてしまうだけでは既存システムに悪影響を及ぼしかねません。そこをどう上手く繋ぎ込んでいくかが1つ目の制約です。
2つ目は「安全系ECUは縄張りを持つ」です。各自動車メーカーは車両の安全機能に相応のセーフティを設けており、外部から単純に信号を書き換えるだけでは、車はすぐに異常と判定してしまいます。手を加えても異常にならないように、エラーを起こさせない繋ぎ込みが必要になってきます。
3つ目は「電源・起動はライフサイクル支配」です。僕らが普段乗る車は、鍵を持って乗り込み、エンジンをかけて、使い終わったらまた鍵を閉めて車を離れます。計算機の電源をどのタイミングで切るかをしっかり考えないと、急にパソコンを切るわけにはいかないので、ログがぶつ切りになってしまいます。そこを車両側と連動させてあげる必要があります。
4つ目は「大きな電力が取り出せない」こと。シガーソケットや車内コンセントでスマートフォンなどは充電できますが、AI推論を担う計算機はそれなりに電気を消費します。制御中、自動運転として推論を動かしているとより電気を使ってしまいます。それを車の電力から賄うんですが、元々車にはそんなに余裕がないので、そこをしっかり手当てしなければいけません。
山口：結構仕組みがシンプルだという話もありますが、このシンプルな仕組みだけれど、車というのは1つの完成された工業製品として、そもそも存在しているから、それに手を加えるとなると、やっぱり難しいところもあります。ポンと乗せるだけで実現できるわけではありません。
Step 1：車両を知る（CANバス解析とDBC定義）
チューリングの開発拠点は、東京都大田区の平和島。物流センターの一角にある広大な拠点は、社内で「ラボ」と呼ばれ、常時30台を超える開発車両（開発フリート）が稼働しています。この場所で、車両をゼロから自動運転車に仕立て上げていくプロセスを、チューリングでは「車両適合（ビークル・アダプテーション）」と呼び、5つのステップに体系化しています。
山口：山岡さんは普段ここで作業されてたりするんですか。
山岡：そうですね。棚があって、工具類や予備部品をストックしています。ドライバーがデータ収集で走ってくれている分、定期的なメンテナンスも必要になるので、大きな2柱リフトも置いてあります。
山口：この赤い柱みたいなやつは一体何なんですか。
山岡：2柱リフトと呼ばれるもので、2つの柱で車を持ち上げる装置です。上が繋がっているので門型と呼んだりもします。
山口：自動車整備工場で車の下に入って作業するのと同じように、我々も車を釣り上げて下に入って作業する、そのための装置なんですね。新しい車に適用することも多いと思いますが、大体何台ぐらい今あるんですか。
山岡：今30台超です。そのくらいの車両を新しく仕立てたり、調子が悪くなったらメンテナンスしたりしています。
ベース車両にアクセスする最初の一歩は、情報の公開度が低い車内通信（CAN：Controller Area Network）の解読です。一般公開されている配線図や整備情報を読み解きながら、物理的にアクセス可能な通信ポートを探すところから始まります。
山岡：通信定義書（DBC：CANバスの通信定義ファイル）を自社で作成していくんですが、非公開の情報がほとんどなので、公開情報や実車のログを付き合わせて解析します。アクセルを踏んだ時にどういう信号が流れるか、ハンドルを切った時にどういう信号が流れるかを試すと、大体どういう時にどういう信号が流れるかは当たりがつきます。シートベルトを外す、ウインカーを出す、窓を開けるといった操作も一通り試して、そこから信号を推定していきます。ひたすら16進数のログを並べて、この辺りにきっとあるはず、と当たりをつけていくような作業で、一概にこういうセオリーがあるとは言えないんですが、経験でエスパーのようにできる人も世の中にはいます。
山口：このCANの信号の定義は、メーカーによっても車種によっても違いますし、同じ車種でもモデルチェンジがあるとまるで変わってしまう。1台1台違うけれど、同じメーカーや兄弟車種だと似ている傾向があるので、その辺りの経験がものを言うんですね。
国産車の多くはCANが使われていますが、車種によってはLIN（Local Interconnect Network）や車載イーサネットなど、別のプロトコルが使われる場合もあります。
Step 2-1：物理実装（車検・保安基準をクリアする構造設計）
山岡：車載計算機やカメラ、センサーなどの物理的な配置を設計します。アルファードの場合、3列目シートの後方に格納スペースを設け、計算機や冷却ファン、電源ユニットをインテグレーションしています。配線設計は、開けてすぐわかる、というのを今は大事にしています。正直、自分の中ではもっともっと隠したい、もっと綺麗に配線できたらと思っているんですが、開発スケジュールとの兼ね合いでそこまではできていません。
山口：え、そうなんですか。私はめちゃくちゃ隠れていると思っていたんですが。
山岡：いや、自分の中ではもっともっと隠したくて、パッと見は何もない、というのが理想です。
山口：今でもほとんど配線は気にならない、というかほとんど見えないところにあるので、うまく隠しているのかなと思っていました。まだ改善したい途中ということなんですね。
山岡：カメラの取り付けでは、必要な画角（FOV：Field of View）が取れるかが最も重要なポイントになります。ラピッドプロトタイピングで実物を作って確認することもあれば、シミュレーション上で検討することもあります。そして何より、ナンバープレートを取得して公道を走らなければならない以上、保安基準への適合が大前提です。
山口：車幅や高さの制限もありますし、フロントガラスにカメラをつける場合も「ガラス上部20%以内」というように、つけられる場所が決まっていますよね。意外と車は簡単に改造できるように見えて、実はがんじがらめの規制がある。
山岡：ギリギリのところで、そもそも車という製品自体がそう作られているので、そこにさらに手を加えるとなると、より気を配らないといけません。
山口：車のケーブルも、車って意外と広いから、普通のケーブルの長さだと足りませんよね。
山岡：そうですね。前から後ろに引き回すとなると5メートルは絶対に必要です。
山口：アルファードは全長がそもそも5メートルを超えるので、5〜10メートル級のケーブルを引き回すことになりますね。身近なUSBのような規格だと10メートルではかなり厳しくなってくるので、カメラの映像伝送には、比較的長距離でも遅延や帯域幅の制約が少ない「GMSL2（Gigabit Multimedia Serial Link 2）」という車載向けの規格を使っています。
Step 2-2：電源設計（車両電源に依存しない独立制御）
山岡：今の方針としては、車両の電源に依存しないようにしています。車によって取り出せる電気の余裕は本当にマチマチで、ギリギリの車もあるので、大電流はあまり取り出さず、サブバッテリーを乗せて、追加のシステムはそこから電力を賄うようにしています。走行中に車両側から少しずつ充電させてもらう形です。
山口：もう少しベースのところから聞きたいんですが、そもそも車の電気は、ガソリン車で言うとオルタネーター（発電機）で発電した電気を、鉛蓄電池に貯めていますよね。
山岡：そうですね、基本的には。
山口：鉛蓄電池の起電力は12V。これがハイブリッドやEVになると、また別の系統の電源がありますよね。この場合は大体何ボルトぐらいなんですか。
山岡：車両にもよりますが、600V程度になります。
山口：普通に触れるとかなり危険な電圧域で、12Vならちょっと感電するくらいで済みますが、車の動力そのものになる電力は非常に危ないので、そこは明確に分けられています。これ結構大事なポイントですよね。車の12V系にそのまま頼ると、バッテリー上がりの心配もありますし、電圧の変動も計算機にはあまり良くない。安定したサブバッテリーがあれば、そのあたりの問題もクリアできるということですね。
山岡：車両を使用していない間も消費される暗電流についてですが、チューリングのシステムを上乗せする分もこの暗電流のリスクになるため、専用の電源コントローラーで管理し、車両側に負担を持ち込まない設計にしています。この独立電源管理により、ドライバーは特別な操作を必要とせず、通常どおりキーをひねる（あるいはボタンを押す）だけで自動運転システムが安全に立ち上がり、キーを切れば自動で安全なシャットダウンが行われる運用を実現しています。
Step 3：繋ぎ込み（インテグレーションと純正状態への物理復帰）
山岡：概念としては、純正で元々流れているメッセージに対して、我々のインターフェースユニットを介して、計算機で計算した結果を合算する形で、他の純正システムに影響が出ないよう要求を伝えて、再送信しています。書き換えている、というのが正しい表現だと思います。新規のメッセージを純正側に追加することはしていないので、バスに負荷がかかることもありません。
万が一、計算機がハングアップした場合や、ドライバーが緊急停止ボタンを押した場合には、物理的・システム的に一瞬で純正状態の配線へ復帰させるフェールセーフの仕組みを設けており、安全性を最優先にした設計になっています。
山口：ハンドルをどのくらい切るか、アクセルやブレーキをどのくらい踏むか、指示しなければいけない項目はそんなに多くないけれど、そこはどうしても書き換えが必要になるんですね。
山岡：はい。ただ単純に書き換えてしまうと、純正のアーキテクチャが監視しているのでエラーになってしまいます。そこも不整合が出ないように、再計算した上で再送信しています。
山口：なるほど。だから車としては、自分はすごく正常だとずっと思っていて、元々設計された通りに動いていると認識しているけれど、実は裏では我々の計算機がちょっとだけ信号を書き換えている。車が元々持っている監視の仕組みにうまく乗っかっているから、異常な動きをしないというリミッターも、車が本来持っているものをそのまま活かせるわけですね。
Step 4：検証とトラブルシュート（内製ウェブ解析ツールの威力）
山岡：実車適合を施した車両の検証には、すべて内製で開発したブラウザベースのログ解析プラットフォームを活用しています。車載SSDに記録された大容量のCANデータ、時系列のカメラ映像、GNSSの位置ログが、クラウド経由で自動的にアップロードされる仕組みです。
山口：このデータを集める仕組みも解析ツールも、基本的に全部内製しています。見たい項目だけを抽出して、どのタイミングでログがおかしくなったとか、変な異常値やエラーが出ているかというところを時系列で確認しながら、大体ここがおかしかったんだな、と当たりがつきます。
このツール、私もあまり知らなかったんですが、どんどん洗練されていっているんですね。ハードウェアのところがソフトウェアでちゃんとサポートされているという。
山岡：ハードウェアエンジニアはブラウザ上でこれらのデータを1枚のタイムライン上で同期させて視覚的に比較できるため、どの瞬間に、どのECUから、どのような異常値が出たかを即座に特定・修正する高速なトラブルシュートが可能になっています。
検証を終えた車両は、最初の1台のプロトタイプから量産フェーズへと移っていきます。車両が30台規模になると、個体差や設定台帳・手順をある程度標準化する必要が生じるため、OTA（Over The Air：無線通信によるソフトウェアの遠隔更新）とフリート管理の仕組みも内製で運用しています。
山口：デモンストレーション用に配線まで綺麗に仕上げた車両では、自動運転モデルが計算した走行軌跡や、カーナビ上で指定した目的地まで車線変更・右左折を交えて自動走行する様子を、車内モニターでリアルタイムに確認できます。東京都内では、この仕組みによってすでに広い範囲を自動走行できる体制が整っていますね。
「Less is More」を貫くシンプルな設計思想
山口：結構このドライバーの方も、エンジニアも、立ち上げの手順を一つひとつ意識しなければいけないと、やっぱり運用が大変ですよね。今は一旦とりあえずイグニッションを入れて、ボタンをポチっとやったら後は勝手に動きます、という状態になっているので、それを意識せずに使えるようになっています。
山岡：ドライバーは運転に集中できますし、エンジニアも開発に集中できます。これができるのも、結局チューリングの基本概念である「Less is More」があって、サブシステムもセンサー構成も少なくしているからこそ成り立っている話ですよね。
山口：複雑さを排除する方が、結局は良くなるという考え方をチューリングはすごく取っています。センサーも少ないです。例えばLiDARセンサーをつけた方が自動運転には役立つでしょ、とよく言われますけど、なくてもできるんだったらそっちの方がいいですし、エンジニアとしてはいろんなコンポーネントを加えたくなりますが、できるだけシンプルに保つのが重要です。ハードウェアもソフトウェアも世の中どんどん進歩していきますし、AIも当然そうですが、そのシンプルな構成にうまく乗っていくには、シンプルである方が恩恵を受けやすい、という話もあります。この辺りの思想が徹底しているかなと思います。
山岡さんに聞きたいのは、車1台仕立てるのにどのくらいの時間がかかるか、ということです。このアルファードが全く新規の状態で来て、必要なパーツは揃っている場合、大体どのくらいで仕立て上がるんですか。
山岡：大体目標としては3ヶ月以内に運用に回るようにしています。解析などで1、2ヶ月、最後にログを回して解析して不具合を潰して運用に乗せるまでで1ヶ月、計3ヶ月で、大体今達成できているかなと思います。
山口：相当早いですね。これが例えば、今あるアルファードではなく、セダンタイプで、メーカーも違う車が来ました、という場合はどうですか。
山岡：車が来てから大体3ヶ月ぐらいで運用に回す、というのが今の目標というか実績としてはあります。
山口：そんなに早いんですか。このアルファードを仕立てるのは3ヶ月ではなくて？
山岡：そうです。このアルファードはもう物があって、繋ぐものの設計も終わっているので、1週間ぐらいで、全くゼロの状態から動く状態になります。
山口：設計をゼロから、今日のステップ1から5までいかないといけないところは大体3ヶ月あればできる、ということですね。
山岡：このハードウェア適合を担うチームは、ハードウェア専任のエンジニア2名と、整備士資格を持つメカニック2名という少数精鋭で運営されています。
山口：最後に聞きたいのは、自動運転のシステムを後付けして元の車両につけていく、という話をしてきましたが、将来的に我々のシステムがいろんな車に乗っていくとなった時、より統合されたE/Eアーキになっていくのかなと思っています。山岡さんが考える、自動運転に必要な機構のポイントはどのあたりですか。
山岡：業界的にトレンドがかなりあります。この後ろに映っているアルファードの世代は、アーキテクチャ的にCANなどの通信がようやく入り始めた頃で、まだまだアナログでやっていたところが多かったと思います。2026年現在の車は、ECUとしてコンピューターを分散しつつ通信で結ぶのが流行っていく中で、自動運転を最終的にやるなら、それをどこかで統合する、統合してまた枝を伸ばすというのが1つ必要になってくるのかなと思っています。カメラや電源のコントロールを外に置くことになるので、通信としては速い方ですが、そのラグでモデル制御の話が困ってしまうので、最終的にはそこは全て集約されてくるのかな、というのが今ありますね。
山口：車にはECUと呼ばれるマイコンが、普通の車でも数十、多いと100近くある車もあって、カメラを司るもの、パワーステアリングを司るもの、というように役割分担して全部分かれていて、それがお互いにCANなどで通信しているのが、いわゆる分散型のアーキテクチャです。最近はそれを集約していく、いわゆる『ゾーン型』のアーキテクチャにしていく、つまりある程度のまとまりを1つのコンポーネントとして扱い、その中で判断しつつ、バスのようなところで中央に集約していくという流れになってきています。これはSDV（Software Defined Vehicle：ソフトウェア定義車両）という言葉とも関係していて、ソフトウェアをうまく動かす、設計するというところを生かすなら、そういったアーキテクチャの方が便利ですし、自動運転という文脈でも計算パワーを多く使い、センサーの通信の遅延を抑えたい、素早くコントロールに回したい、ということを考えると、自動運転のAIもソフトウェアの一種なので、ソフトウェアデファインドビークルという考え方に近いところに自動運転の車両もなっていくのが、将来的には自然な流れかなという感じがしますね。
ということで山岡さん、今日はありがとうございます。
山岡：こちらこそ、ありがとうございました。
Q&A一覧（一部抜粋）
以降は視聴者のQ&Aに回答していきました。詳しくは動画をご覧ください。
- 自動運転はEV（電気自動車）でなければ実現できないのか
- 車検制度上、ソフトウェアによる信号書き換えへの対応はどうしているか
- サイドカメラを片側1台に減らすことはできないか
- テスラのフロントバンパー下カメラのような構成は必要か
▶ Turing Tech Talk #44 アーカイブ動画はこちら
チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししたDriving System2チームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。
