SDVの次に来るのは、AIDVなのか

SDVの次、AIDV時代にITの知見は何を持ち込めるのか

AIが車に入る時代に、変わるのは機能だけではない。
開発、評価、責任分界、そして"AIを運営する力"を考える。

新卒でAccentureに入社して、今年で21年目になります。
この10年は、自動車OEMを主要なクライアントとして仕事をしてきました。

もともと私は、大学院で電気電子工学を専攻していました。学生の頃は、このまま研究や開発の道に進むのだろうと、何となく思っていました。けれど新卒でACNに入ってからは、そのルートとは別の道を歩いてきました。

その感覚が変わったのは2016年頃です。Connected Vehicle基盤の支援に関わるようになって、「一度諦めたキャリアを、別の形で追体験できるかもしれない」と本気で思ったのを今でも覚えています。

それ以来、自動車OEMのR&DやIT変革の近くで仕事をしてきました。
クラウドインフラ、AMO（Application Modernization & Optimization。アプリケーションの刷新と最適化）、エンタープライズIT近代化といったテーマを軸にしながら、Connected Vehicle Platformのような領域にも関わってきました。その中で、日本の自動車業界への思い入れは、仕事上の関心を超えてかなり強くなったと思っています。

だからこそ、この数年の変化にはいろいろ考えさせられます。
Teslaの台頭はもはや一過性の話ではありませんし、中国系の新興OEMも、ソフトウェア、UX、スピードの面で存在感を一気に高めています。日本の自動車OEMが積み上げてきた強みが消えたとは、まったく思っていません。
一方で、何で勝つのか、どこで差がつくのか、その前提は確実に変わってきているとも感じています。

そこに、今度はAIが本格的に入ってきました。

この10年、自動車OEMの近くで仕事をしてきた中で、業界への理解は自分なりに深まってきたつもりです。
ただ、車両開発やR&Dの最前線に立つ技術者の方々と同じ意味で、自分を自動車技術の専門家と名乗ることは、正直、失礼にあたると感じています。
今回は、あくまでその少し外側にいる立場だからこそ見える論点を書いてみたいと思っています。

もし車がSDV（Software-Defined Vehicle。ソフトウェア更新を前提に機能を進化させる車両）からAIDV（AI-Defined Vehicle。AIとデータによって挙動や体験が形作られる車両）へ進んでいくのだとしたら、変わるのは機能だけではありません。
開発手法も、テスト手法も、品質保証も、責任の持ち方も変わるはずです。そこには、IT業界と共通する論点もあれば、物理世界を扱う自動車業界ならではの難しさもあります。

本稿では、そのあたりを現時点での自分なりの理解として整理してみます。
答えを提示するというより、これから何を論点として持つべきかを考えるためのメモに近い内容です。

SDVの次に見えてきた、AIDVという論点

ここ最近、「SDVの次」をどう捉えるかという議論が少しずつ具体化してきました。
その中で印象的なのが、AIDVという考え方です。

この違いは、言葉以上に大きい気がしています。

SDVで中心にあったのは、ソフトウェアをどう分離し、どう更新可能にし、どう継続的に進化させるか、という論点だったと思います。
もちろんそれ自体が今なお大きなテーマですし、簡単に片付いた話でもありません。

ただ、AIDVになると、焦点はもう一段変わります。
問われるのは、機能をソフトウェアで実現できるかどうかではなく、どんなデータを集め、どんなモデルを使い、どこで推論させ、どう評価し、どう安全に改善し続けるかです。

要するに、車が「ソフトウェアで定義されるもの」から、「AIとデータによって挙動や体験が形作られるもの」へと寄っていきます。
ここまで来ると、論点は車載ソフトだけでは閉じません。クラウド、学習基盤、推論基盤、更新管理、検証、監査可能性まで含めて見ないと、全体像をつかみにくくなります。

この構図には、IT業界で先に起きている変化と重なる部分があるように思います。

自動車業界におけるAIの波は、もう一部の機能の話ではありません

自動車におけるAI活用というと、まずAD/ADAS（Autonomous Driving / Advanced Driver Assistance Systems。自動運転／先進運転支援システム）が思い浮かびます。もちろんそこは中心的な領域です。
ただ、実際には自動車業界に入ってきているAIの波は、もう少し広く捉えた方が実態に近いと感じています。

まず全体像を整理すると、いま自動車業界に入ってきているAIの波は、大きく3つのレイヤーで捉えると見通しがよくなります。

少なくとも今は、次の3つのレイヤーで見た方が整理しやすいと思っています。
① 運転知能としてのAI
② 車内体験・サービスとしてのAI
③ 開発・検証・運用を変えるAI
です。

１．運転知能としてのAI

ひとつ目は、AD/ADASそのものの変化です。
ここでは、従来のように認識、予測、計画、制御を比較的分けて構成する考え方に対して、入力から運転行動までをより大きなモデルで扱うEnd-to-End（認識・判断・制御を個別に分けず、一体として学習・推論する考え方）的な方向が、少なくとも研究・先行開発のレベルでは急速に存在感を増しています。

その流れの中で、World Model（現実世界の振る舞いや変化を学習・再現し、予測や評価に活用する考え方）の重要性も上がっています。
現実ではなかなか遭遇しないが、安全上は無視できないシナリオをどう扱うか。この問題に対して、World Modelや合成データはかなり現実的な意味を持ち始めています。

加えて、Embodied AI や Physical AI といった言葉も出てきています。
表現は違っても、共通しているのは、車両知能を単なるルール集合としてではなく、物理世界の中で汎化する知能として扱おうとしている点です。

つまりこの領域では、AIは"機能を賢くするもの"というより、"運転そのものの知能化を進めるもの"として位置づけられ始めています。

２．車内体験・サービスとしてのAI

ふたつ目は、車内体験やサービスの領域です。
ここでは、車載AIとクラウドAIを組み合わせたハイブリッドな構成が現実味を帯びています。デバイス、車載エッジ、クラウド、アプリケーションを分けて考えるのではなく、ひとつの体験としてどう設計するかが前提になっています。

この領域で起きている変化は、単なる音声UIの高度化だけではありません。
ユーザー理解、文脈理解、提案、継続対話などを含めて、車が"反応する機械"から"意図を汲みながら支援する存在"に近づいていく流れだと見ています。

３．開発・検証・運用を変えるAI

そして3つ目が、開発・検証・運用そのもののAI化です。
個人的には、ここが特に重要だと思っています。理由は、AIが車に載るだけでなく、AIによって車の作り方そのものが変わるからです。

単発のモデル開発ではなく、データ処理、学習、検証、リリース、運用監視までを回すための構造が必要になります。
これはかなりIT的な論点でもありますし、AIDV時代に入るほど、むしろ競争力の源泉はこちらに移っていく可能性もあると感じています。

つまり、自動車業界におけるAIは、もはや「新しい機能」の話ではありません。
運転を変えるAI、体験を変えるAI、開発と運用を変えるAIが同時に進んでいます。
だからこそ、議論も個別機能単位では済まなくなっているのだと思います。

IT業界でも、AIによって"作り方"が変わり始めています

ここは、自分がいま日々感じていることでもあります。

最近、AIを仕事に本気で組み込み始めてから、強く感じることがあります。
AIが強くなるほど、人間の仕事は減るというより、むしろ雑に考えることが許されなくなるということです。

仕様が曖昧だと、AIはそれっぽいものを返します。
意図が曖昧だと、出力は整っていても芯を外します。
文脈が不足すると、局所最適な答えは出せても、全体として筋が悪いものになります。

だから今、IT業界ではコードを書く以前に、何を作るのか、どこまでを意図として固定するのか、そのためにどんなコンテキストを渡すのかが重要になっています。
まだ用語は流動的ですが、少なくとも問題意識はかなり共通しているように思います。

この構図は、自動車でも無関係ではないように見えます。
AIDVが進むほど、コードや機能の前にある前提、つまりODD（Operational Design Domain。システムが安全に機能する前提条件の範囲）、データ分布、学習条件、許容する挙動、許容しない挙動、説明責任の範囲をどう定義するかが重要になります。

言い換えると、AIが強くなるほど、実装の前に設計すべきものが増えます。
少なくともIT側から見ると、ここにはかなり大きな共通点があります。

ただし、自動車は物理世界で動きます

一方で、この話をそのままITの延長として扱うのは危ないとも思っています。

自動車の難しさは、当然ながら、現実の道路で動くことにあります。
しかも、人の命と安全に直結します。アプリケーション開発なら、バグは修正すればいい、ロールバックすればいい、で済む場面も多いです。だが自動車では、その一回が重大事故につながり得ます。

だから、AIの導入に伴って変わるのは開発効率だけではありません。
評価の考え方そのものが変わります。

ここで重要なのは、モデルの内部をどこまで説明できるかという問いだけではありません。
それ以上に、外から見た振る舞いとして、何をもって安全と判断するのかを設計しなければいけないということだと思っています。

World Model や合成データは、間違いなく強力な武器になります。
ただ、それだけで現実の不確実性を置き換えられるわけではありません。結局は、シミュレーション、テストコース、実路、運用監視をどう組み合わせて、どの段階で何を確認するか、という地味だが重い設計に戻ってきます。

このあたりは、物理世界を相手にする産業の宿命でもあると感じています。

AIDV時代は、モデルだけでなく「AIが動く基盤」も設計対象になります

最近、社内でも、AIの品質や安全性をモデル単体で論じるのではなく、それを支える実行基盤まで含めて設計・統制すべきだという認識が明確になってきており、具体的な検討も進みつつあります。

これは、いわば"ハーネス・インフラ・エンジニアリング"とでも呼びたくなる視点で、AIに何を言わせるかだけでなく、どこで動かし、どの権限を与え、何を実行させ、どう監査可能にするかまでを設計対象として捉える考え方です。

この補助線は、AIDVを考えるうえでも示唆が大きいと思っています。
車にAIが載る世界では、重要なのはモデルの精度だけではありません。どのAIが、どのデータに、どの権限でアクセスし、どこまで実行し、その結果をどう監査可能にするかまで含めて設計しないと、安全も説明責任も担保しにくくなります。

少なくともIT側から見ると、AIDV時代にはモデル中心の議論だけでなく、"AIが動く基盤そのもの"を設計対象として捉える必要があるように思えます。

自分自身、AIを日常業務にかなり深く組み込み始めてから、モデルが賢くなるほど、最後に効いてくるのはプロンプトの巧拙だけではなく、権限、実行環境、ログ、監査、つまり"AIが置かれる土台"だと感じる場面が増えました。
AIDVでも同じことが起きるのではないかと考えています。

車に載るAIが強くなるほど、問われるのは何を認識し判断するかだけでなく、そのAIに何をさせてよいのか、その行動をどう制御し、どう証跡化するのか、という実行基盤の設計になります。

AIDVで変わるのは、機能よりもむしろ開発と検証の前提ではないでしょうか

ここで変わるのは、単なるテスト工程ではありません。学習から評価、承認、更新、監視までをひとつの運用ループとして設計する必要があります。

現時点で自分がいちばん大きいと思っているのは、まさにこの点です。AIDVが進むと、何ができるようになるかも重要ですが、それ以上に、どう作るか、どう確かめるか、どう運用するかの前提そのものが変わってきます。

モジュール型の世界では、まだ責任の切り方が比較的見えやすかったです。
もちろん実際には複雑ですが、それでも認識系、制御系、HMI（Human Machine Interface。ドライバーと車の接点となる画面や音声UI）、クラウド、OTA（Over-the-Air。無線経由でのソフトウェア更新）のように役割を分け、仕様とテストを対応させる基本線は引きやすかったと思います。

しかし、モデルが横断的に振る舞いを規定し、データが挙動を支配し、車載とクラウドが連動しながら改善サイクルを回すようになると、その整理が崩れてきます。

何をもって完成とするのか。
何をもって合格とするのか。
どの変更を軽微と見なし、どの変更を再評価対象とするのか。
このあたりが一気に難しくなります。

そのときに必要なのは、モデル精度の数字だけではありません。
ODDごとのカバレッジ。
レアケースへの到達度。
快適性や交通流との整合性。
フェイルセーフやドライバーモニタリングを含めた全体安全。
更新前後で何が変わったかの追跡可能性。
そういった複数の観点を束ねて判断する枠組みだと思っています。

IT業界の言葉でいえば、これは単なるテスト工程の強化ではありません。
ValidationOps（学習、評価、承認、運用監視をつなげて回す運用の考え方）やAIガバナンスに近い話です。
学習、評価、承認、リリース、監視を分断せず、一つの運用系として扱う必要があります。

規制、説明責任、責任分界も前に出てきます

この論点を難しくしているのは、AIでは"何を納めたか"だけでなく、"何を根拠に安全と判断したか"まで共有対象になることです。

特に厄介なのが、サプライヤーとOEMの責任分界だと思っています。
誰がどのデータを使ったのか。
どの条件で学習したのか。
どこまでを保証範囲としていたのか。
更新時に何が変わりうるのか。
誰が最終的なGo/No-Goを持つのか。
こうした問いは、AI化が進むほど曖昧にはできなくなります。

このテーマを考えるとき、技術だけ見ていても足りません。

AIは、もはや"便利な機能"として載せればいい段階ではなくなってきています。
安全、更新、説明責任、監査可能性を含めて、管理対象として扱う必要があります。

だとすると、今後必要になるのは、部品や成果物を納めて終わりという関係ではなく、学習条件、データ来歴、既知の限界、評価結果、変更履歴といった"証拠"を受け渡しながら責任を分ける設計だと思います。

これはかなりしんどい話ですが、避けて通れない気がしています。

では、ITの知見は何に使えるのでしょうか

ここまで書いてきて、自分の考えは割とはっきりしています。

IT業界の知見は、自動車業界にそのまま輸入できる答えではありません。
ただ、論点を構造化し、仕組みに落とし、運用可能な形にするという意味では、かなり役に立つ余地があると思っています。

たとえば、車載AIとクラウドAIを分けて議論するのではなく、全体アーキテクチャとして捉える視点。
モデルだけでなく、学習データ、評価データ、シナリオ、メタデータを資産として扱う視点。
学習、評価、承認、OTA更新、監視をつないで運用する視点。
サプライヤー連携を、成果物受け渡しではなく証拠連携として設計する視点。
そして、AIの挙動だけでなく、その実行基盤まで含めて統制対象として捉える視点です。

このあたりは、少なくともITやクラウドの世界では、近い問いに向き合ってきた蓄積があります。

もちろん、自動車はそんなに単純ではありません。
安全の重みが違いますし、物理世界の複雑さもあります。
だからこそ、ITの知見は"正解"として持ち込むのではなく、"考え方の型"として持ち込む方が健全だと思っています。

現時点で自分がいちばん大きいと感じているのは、競争力の重心そのものが少しずつ移っていることです。

いま自分が持っている仮説

まだ整理の途中ではありますが、現時点での仮説をひとことで言えばこうなります。

AIDV時代に問われるのは、AIを載せる力より、AIを安全に運営する力ではないか。

どのモデルを選ぶか。
どの機能から始めるか。
どのパートナーと組むか。
それらはもちろん重要です。

ただ、それ以上に重要になるのは、
何を学習させるのか。
どこまでを安全と見なすのか。
どう評価するのか。
どう更新するのか。
更新後に何を監視するのか。
サプライヤーとOEMの間で、何を証拠として受け渡すのか。
そして、その判断をどのガバナンスのもとで下すのか。

そうした問いに、組織として答えられるかどうかではないかと思っています。

この意味で、AIDVは"新しい車載機能"の話ではありません。
開発、検証、品質保証、責任分界、運用の持ち方を、もう一度組み直す話に見えます。
そしてそこには、自動車業界の深い現場知と、IT業界で蓄積してきたAI/ソフトウェア運営の知見とを、どう接続するかという余地があります。

おわりに

自分は、自動車OEMの近くで仕事をしてきた立場から、このテーマを考えています。
その中で業界への理解は深まってきたつもりですし、日本の自動車業界に対する敬意も、何か役に立ちたいという気持ちも、かなり強くなりました。

だからこそ、AIの波が本格化するこのタイミングで、一度ちゃんと考えておきたかったのです。
AIDVが本当にどの形で立ち上がるのか。
E2E化はどこまで進むのか。
規制や責任分界はどう落ち着くのか。
まだ見えていないことは多くあります。

ただ少なくとも、AIが車の価値や挙動に深く入り込むほど、問われるのは"AIを積んだかどうか"ではなく、"AIをどう安全に、継続的に、説明可能な形で運営するか"になります。
今のところ、自分はそう見ています。

そして、もし自分のようなIT側の人間に貢献余地があるとすれば、それは自動車業界を外から語ることではありません。
AI時代に必要になる論点を整理し、構造を描き、実行可能な形に落とすこと。
そのあたりに、まだやれることはある気がしています。

日本の自動車業界には、長い時間をかけて積み上げてきた強みがあります。
AIの時代にその強みをどう更新し、どう次の競争力につなげていくのか。
その問いに対して、自分なりの立場から考え続けていきたいと思っています。

用語メモ

SDV | Software-Defined Vehicle。ソフトウェア更新を前提に機能を進化させる車両。
AIDV | AI-Defined Vehicle。AIモデルとデータによって車両の挙動や体験が形作られる車両。
AD/ADAS | 自動運転／先進運転支援システム。
ODD | Operational Design Domain。システムが安全に機能する前提条件の範囲。天候、道路、速度域などを含む。
End-to-End | 認識・判断・制御を個別に分けず、一体として学習・推論するアプローチ。
World Model | 現実世界の振る舞いや変化をモデル化し、学習・予測・評価に活用する考え方。
HMI | Human Machine Interface。ドライバーと車の接点となる画面や音声UI。
OTA | Over-the-Air。無線ネットワーク経由でソフトウェアを更新する仕組み。
ValidationOps | 学習、評価、承認、運用監視をつなげて回す運用の考え方。

参考にしたもの

• Qualcomm, From Software-Defined to AI-Defined Vehicle: Snapdragon Chassis Agents

• Wayve, Wayve launches GAIA-3

• Wayve, The Road to Embodied AI

• AWS, Guidance for In-Vehicle AI Assistant

[参考リンク]
Accenture Technology(アクセンチュア テクノロジー) 記事一覧
Accenture Technology(アクセンチュア テクノロジー)｜note

アクセンチュア テクノロジーコンサルティング本部
テクノロジー コンサルティング本部採用情報 | アクセンチュア

アクセンチュアへのお問い合わせ
お問い合わせ | アクセンチュア