Mercedes-BenzとNVIDIAの自動運転提携、安全性に関する主張を検証へ
Mercedes-BenzとNVIDIAは2026年10月16日、安全性の検証、運転者の責任、実環境への導入をめぐる疑問が未解決のまま、自動運転分野での提携を拡大した。Mercedes-BenzとNVIDIAの自動運転提携は現在、通常のチップ供給契約をはるかに超える技術スタックを対象としている。
両社は、Mercedes-Benzの車両エンジニアリングとMB.OSを、NVIDIA Hyperionのハードウェア、Alpamayoの運転ソフトウェア、Halosの安全システムと組み合わせる計画だ。この組み合わせは、現在の運転支援、都市部での地点間走行、自動駐車、将来的なSAEレベル4の用途を支える。
今回の発表は、TeslaとWaymoへの戦略的な対抗策でもある。両社はいずれも、それぞれの運転システムをより多く内製している。Mercedes-Benzは、自動車メーカーとAIインフラ企業の組み合わせでも、車両、ブランド、顧客体験の主導権を手放さずに、同等の統合を実現できると賭けている。
このため、この提携は単なる自動車AIに関する新たな発表以上の意味を持つ。真の競争は、共有プラットフォームと独自の自律走行プログラムの間で繰り広げられている。Mercedes-BenzとNVIDIAは今後、分担された責任によっても、統一され検証可能な安全性の根拠を生み出せることを証明する必要がある。
Mercedes-BenzとNVIDIAの自動運転提携、1車種を超えて拡大
拡大された契約により、既存の量産関係は、複数レベルの車両自動化に向けた共同ロードマップへと変わる。
Mercedes-BenzとNVIDIAは、StuttgartとSanta Claraから発表した共同声明で、この提携拡大を説明した。両社は、契約額、独占期間、計画中の各機能に関する具体的な投入時期を明らかにしていない。
両社の自動運転契約では、4つの中核コンポーネントが挙げられている。Mercedes-Benzは、自動車エンジニアリングおよび安全プロセスとともに、車両用OSであるMB.OSを提供する。NVIDIAは、Hyperion、Alpamayo Stack、Halosを提供する。
MB.OSは、自動運転、インフォテインメント、快適機能、充電を含む車両の中核ドメインを統合する。また、承認済み機能をOTAアップデートで提供するためのソフトウェア層もMercedes-Benzに提供する。
NVIDIA Hyperionは、車両のコンピューターをカメラ、レーダー、LiDAR、その他のセンサーに接続するリファレンスアーキテクチャだ。リファレンスアーキテクチャは、互換性のあるハードウェアとソフトウェアのコンポーネントが量産車内でどのように連携すべきかを定義する。
Alpamayo Stackは、認識、計画、AI推論の機能を備えた運転ソフトウェアを提供する。NVIDIAによれば、このソフトウェアは複雑な交通状況を評価しながら、都市部での運転支援、能動安全、自動駐車を支援できる。
Halosは、AI搭載車両向けのNVIDIAの安全フレームワークだ。このシステムには、開発プロセス、検証ツール、ハードウェア保護機構、AIの挙動を制約するために設計された並列の安全スタックが含まれる。
この並列設計には重要な意味がある。AIモデルが通常と異なる場面を解釈して運転操作を提案する一方で、より予測可能なソフトウェア経路が、その操作が定義済みの安全境界内に収まるかを確認できる。
両社によれば、これらの技術は高度運転支援と将来のSAEレベル4車両を支援する。レベル4とは、人間による代替操作を期待せず、定義された運用エリア内で自動運転システムが運転タスク全体を担うことを意味する。
この説明は、NVIDIA技術を搭載するすべてのMercedesが自律走行車になることを意味しない。自動化のレベルは、車両、センサー、ソフトウェア承認、運用条件、地域の規制によって決まる。
Mercedes-Benzは、より広範な計画に向けた量産基盤をすでに持つ。同社のMB.DRIVE ASSIST PROシステムは、高度なSAEレベル2支援を提供しており、これは運転者が責任を負い、車両を監視し続けなければならないことを意味する。
Mercedes-Benzによると、このシステムは2025年末までに中国で提供されていた。同社は2026年中に米国へ導入する計画も示していた。
現在の構成では、10基のカメラ、5基のレーダーセンサー、12基の超音波センサーを含む約30個のセンサーを使用する。Mercedes-Benzは、最大508兆回/秒の演算性能を掲げている。
これらの数値は、現代の運転支援システムがどれほど多くのセンシングと処理を必要とするかを示す。しかし、監視なしでも安全に動作できることを立証するものではない。
したがって、拡大された契約は協業の規模を変えるものであり、現在の機能における法的な意味を変えるものではない。量産中のレベル2製品を、より自動化された自家用車やロボリムジンに向けた開発経路へと結び付ける。
また、ソフトウェアアップデート、AIトレーニング、シミュレーション、車両統合、量産検証も結び付ける。パートナーはもはや、一つの孤立した機能を共同で解決しているわけではない。複数の車両プログラムに再利用できる基盤を構築している。
この広範な範囲が中心的な緊張を生む。共通プラットフォームは開発サイクルを短縮できるが、ユースケースが増えるたびに、エンジニアが予測し封じ込めなければならない障害の種類も増える。
NVIDIA HyperionがMercedes-Benzにとって重要な理由
Mercedes-Benzは、MB.OSを技術サプライヤーと顧客の間に置きながら、NVIDIAのプラットフォームを利用して自律走行のコストを分散しようとしている。
自動運転を内製で開発するには、車両ソフトウェアを書く以上のことが必要となる。自動車メーカーには、専用コンピューター、センサーインターフェース、学習インフラ、シミュレーション環境、安全ツール、大規模なエンジニアリングチームが必要だ。
Teslaは、そのシステムの多くを自社車両、走行データ、ニューラルネットワーク、カスタムコンピューティングを中心に構築した。Waymoは、明確に定義されたレベル4の運用を軸に、統合型の自動運転システムを開発した。
Mercedes-Benzは第3の道を取る。車両挙動、統合、顧客体験への責任を維持する一方、NVIDIAがコンピューティングとAI基盤の大きな部分を提供する。
このアプローチにより、Mercedes-BenzはNVIDIAの自動車顧客全体で共有されるインフラを利用できる。NVIDIAは、研究開発費を自動車メーカー、モビリティ企業、ロボタクシープログラムに分散できる。
Mercedes-Benzにとって、この取り決めはすべてのレイヤーを独自に再現する必要性を減らす。また、車両プログラムが監視付き運転支援からより高度な自動化へ移行するにつれ、進化可能なソフトウェア基盤を提供する。
NVIDIAは、Hyperionを自動車業界の標準的な基盤にしたい考えだ。同社のプラットフォームは異なるセンサー構成をサポートし、顧客は選択したコンポーネントのみ、またはより包括的なNVIDIAソフトウェアスタックを利用できる。
この柔軟性は商業面で重要だ。ソフトウェアが製品の差別化と顧客データをますます形作る中、自動車メーカーがサプライヤーに車両の全要素を決定させることを望むケースは少ない。
この取り決めでMB.OSはMercedes-Benzの制御層として機能する。NVIDIAが重要な基盤技術を提供していても、Mercedes-Benzは機能、アップデート、運転者に提示されるインターフェースを管理できる。
このアーキテクチャは、他のプラットフォーム市場に似ている。サプライヤーが再利用可能なコンピューティングおよびソフトウェアコンポーネントを作り、メーカーがそれらを自社製品に適応させる。
ただし、車両ではパーソナルコンピューターやスマートフォンよりも厳しい結果が伴う。ソフトウェア障害は即座に物理的な危険を生み得るうえ、車両プラットフォームは長年にわたり保守可能でなければならない。
そのため、NVIDIAの自動車戦略はTeslaやWaymoと同程度にQualcommやMobileyeにも圧力をかける。Qualcommは車載コンピューティングプラットフォームを販売し、Mobileyeはチップ、地図、運転支援ソフトウェア、安全技術を組み合わせている。
業界プラットフォーム分析は、自動車メーカーにとってサプライチェーンへの依存が懸念事項だと指摘した。また、QualcommとMobileyeが競合するアプローチを提供していることにも触れた。
依存には複数の形態がある。車両プログラムがNVIDIAのツール、コンピューティングハードウェア、モデル形式、検証プロセスと密接に結び付く場合、Mercedes-Benzは切り替えコストに直面する可能性がある。
これは、Mercedes-Benzが自動的に主導権を失うことを意味しない。同社は車両要件を定義し、MB.OSを維持し、センサーを選定し、機能を検証し、承認済み機能が顧客に届く方法を管理できる。
共通のサプライヤーレイヤーを置き換えることが難しくなれば、リスクは高まる。プラットフォームは一つの製品サイクルでは開発を簡素化できる一方、次のサイクルではアーキテクチャ上の自由度を制限する可能性がある。
NVIDIAもフィードバックループから利益を得る。車両プログラムが増えるほど、統合経験、試験需要、開発ツールが増加する。こうした改善は追加のメーカーを引き付け得る。
これが、Mercedes-BenzとNVIDIAの自動運転提携が2社を超えて重要な理由だ。共有AIプラットフォームが、自動車メーカーを単なるハードウェア統合事業者へと縮小させることなく、個性ある車両を支えられるかを試している。
このモデルが機能すれば、他のメーカーは完全な自律走行プログラムへの資金投入に代わる選択肢を得る。失敗すれば、垂直統合型の競合企業は、重要な運転技術をパートナー間で明確に分割できないことの証拠を得る。
AlpamayoとHalos、AI推論に安全バックストップを組み合わせる
この技術的な賭けは、適応型AIと独立した安全経路を組み合わせるものだ。学習済みの挙動も固定ルールも、単独ではあらゆる走行条件に対応できないためである。
従来、運転ソフトウェアは、物体の検出、動きの予測、経路計画、車両制御を別々の段階に分けてきた。エンジニアはこれらの段階を検査できるが、硬直的な前提は未知の状況で破綻する可能性がある。
エンドツーエンドAIは異なるアプローチを取る。センサー入力と運転挙動の関係をより強く学習し、手書きのルールでは対応しにくい複雑な場面で性能を高める可能性がある。
Alpamayoは、推論志向のモデルによってこの考え方を拡張する。NVIDIAによれば、このソフトウェアは、通常と異なる状況で進路を選ぶ前に、複数の可能な行動を評価できる。
たとえば、配送トラックが都市部の車線の一部を塞いでいる状況を考えてみよう。車両は障害物を検知し、一時的な道路標示を解釈し、歩行者を予測し、車線境界を越えることが適切かどうかを判断しなければならない。
固定的なシステムは、その正確な組み合わせが予測されていなかった場合に苦戦する可能性がある。推論モデルは、より広い文脈を用いて利用可能な選択肢を評価できる。
しかし、モデルによるもっともらしい説明は、安全な操作を保証しない。AIシステムは、特にセンサーデータが学習分布と異なる場合、予測不能な形で失敗する可能性がある。
NVIDIAの答えは、アーキテクチャの多様性だ。AI経路が認識と複雑な計画を担う一方で、従来型の安全スタックが並行して動作する。
安全スタックは、速度、利用可能な空間、衝突リスク、車両安定性に関わる制約を適用できる。冗長化されたコンピューティングは、ハードウェア障害後も重要機能を動作させ続けられる。
センサーの多様性も別の層を提供する。カメラは色彩と視覚的な詳細を捉え、レーダーは距離と速度を推定し、LiDARは反射光を用いて三次元構造を測定する。
各センサーには異なる弱点がある。カメラは逆光や暗闇で性能が低下する可能性があり、レーダーは視覚的な詳細が少ない。LiDARの性能も、天候、反射率、汚れによって変化し得る。
S-Class向けに計画されたL4対応アーキテクチャは、カメラ、レーダー、LiDARを組み合わせる。NVIDIAは、冗長化コンピューティングと独立したソフトウェア経路についても説明している。
「L4対応」には慎重な解釈が必要だ。これは、基盤となるアーキテクチャがレベル4アプリケーションを支えられるよう設計されていることを意味する。車両があらゆる場所で自律走行する認可を受けたことを意味するわけではない。
レベル4システムには、定義された運行設計領域も必要となる。この領域は、自動化が機能できる場所、道路の種類、速度、気象条件、その他の状況を定める。
Mercedes-BenzとNVIDIAは、S-Classをベースにした将来のロボリムジンについて協議している。このような車両は、認可されたエリア内で、モビリティプラットフォームを通じてショーファーサービス型の自律移動を提供する可能性がある。
範囲を限定した商用サービスは、初期段階における合理的な用途だ。フリート運営者はルートを制限し、車両を監視し、センサーを保守し、詳細な性能データを収集できる。
個人所有車は、より難しい課題を生む。所有者は幅広い地理的カバレッジを期待し、「自動化」という表示を見た後に限界を誤解するおそれがある。
レベル2とレベル4の違いは特に重要だ。レベル2では、システムが操舵と速度を制御している場合でも、ドライバーによる継続的な監視が求められる。
レベル4では、認可された領域内で運転タスクがシステムに移る。車両は、人間による即時の介入に頼らず障害に対処しなければならない。
両者の隔たりは、単純なソフトウェアアップグレードではない。責任の所在、フォールバック要件、試験エビデンス、規制上の扱いを変える。
Mercedes-Benzは、DRIVE PILOTを通じてこの境界に関する直接的な経験を持つ。同社の条件付き自動運転レベル3システムは、限定的な条件下で承認されたハンズオフおよびアイズオフ走行への先行ルートを切り開いた。
今回の協業は、その実績を消し去るものではない。むしろ、正式な認可と安全責任に関するMercedes-Benzの既存経験に加え、より広範なAI中心のアーキテクチャを導入するものだ。
これが、この提携を支持する最も強い論拠である。NVIDIAは大規模AIインフラを提供し、Mercedes-Benzは実証を超えて進むために必要な車両エンジニアリングと規制対応の規律を提供する。
ただし、この組み合わせは説明責任という問題も生む。AIの挙動が失敗した場合、調査担当者は原因が学習データ、モデル設計、センサー、統合、車両制御のどこにあったのかを把握しなければならない。
並列した安全スタックはリスクを低減できるが、責任を消滅させることはできない。両社には、モデル開発を車両レベルの挙動へ結び付ける追跡可能なエビデンスが必要となる。
自動運転の安全性は依然として人間の行動に左右される
両社の安全アーキテクチャは技術的な故障に対処するが、監視付き運転は人々がシステムを誤解したり注意を失ったりした場合にも破綻する。
Mercedes-Benzによれば、Halosは安全基盤に冗長性とガードレールを加える。こうした保護策には意義があるものの、提携発表では公開の介入率や独立したレビューを受けた安全性比較は示されていない。
また、各国で新機能をどのように検証するのかについても具体化されていない。道路設計、標識、運転行動、天候、規制は市場ごとに大きく異なる。
最初の実践的な検証は、レベル2支援に関するものになる。MB.DRIVE ASSIST PROは都市部での地点間運転を支援できるが、走行中の責任は一貫してドライバーにある。
Mercedes-Benzは、ドライバーが支援を自動解除することなく進行方向を調整できる協調操舵を採用している。この設計により、人間と機械の引き継ぎはそれほど唐突に感じられない可能性がある。
このシステムは、環境を監視するためにカメラやその他のセンサーにも依存する。能力の高さが過信を招く可能性があるため、ドライバー監視機能は依然として不可欠だ。
独立した安全研究は、この問題を繰り返し指摘してきた。部分自動化システム14件を評価したある調査では、Insurance Institute for Highway Safetyから最高評価を得たものはなかった。
総合評価で「Acceptable」を獲得したのは1件だけだった。2件は「Marginal」、残りは「Poor」と評価された。
ドライバー監視に関する調査結果は、Mercedes-Benzを含む複数の自動車メーカーのシステムを対象とした。評価は、不注意や誤使用を防ぐための保護策に焦点を当てている。
この試験は完全に拡張されたスタックより前に行われたものであり、将来のMercedes-Benzシステムを直接測定したものではない。それでも、より強力な運転ソフトウェアだけでは安全性の問題を解決できない理由を示している。
ドライバーは、日常的な走行を通じて信頼の度合いを調整することが多い。支援機能が数週間にわたり良好に動作すると、システムが助けを必要とするまれな瞬間に備えなくなる可能性がある。
まさにそうしたまれな瞬間こそ、自動運転システムが最も困難な技術条件に直面する場面だ。通常と異なる工事、緊急車両、見えにくい区画線、不規則な道路利用者は、未知の組み合わせを生む可能性がある。
監視付き支援から条件付き、あるいは高度な自動化への移行も、一貫しない期待を生む。ドライバーは、似たインターフェースを持ちながら法的責任が異なる複数の車両を利用するかもしれない。
ここでは明確な製品名が重要になる。マーケティングは、細かな注記に頼ることなく、支援と自動化を区別しなければならない。
操作系も、システムの状態を明確に示すべきだ。ドライバーは、自動化がいつ利用できるのか、何をしているのか、責任がいつ変わったのかを知る必要がある。
Mercedes-BenzとNVIDIAの自動運転提携は、第二の種類の不確実性ももたらす。AIによる推論は車両の挙動をより柔軟にできる一方、その柔軟性は検証を複雑にする。
従来のソフトウェアは、明示的な要件に照らして試験できる。学習済みシステムは学習データと最適化の選択を反映しており、それらを常に単純なルールへ還元できるわけではない。
シミュレーションは、より多くの条件を網羅する助けとなる。NVIDIAは高忠実度の仮想環境を使用し、公道展開前にシナリオを生成して運転挙動を評価する。
合成試験は、危険またはまれな事象にとって有用だ。エンジニアは、速度、照明、視界、参加者の行動を変えながら、衝突寸前の状況を数千回繰り返せる。
それでもシミュレーションはモデルの忠実度に依存する。仮想環境は、設計者が正確に表現しなかった故障モードを明らかにできない。
公道試験には逆の限界がある。現実の複雑さを捉えられる一方、すべてのまれな事象を効率的に再現したり、未知の故障が存在しないことを証明したりはできない。
最も強力な検証プログラムは、シミュレーション、クローズドコース試験、公道走行、インシデントレビュー、継続的なフリート監視を組み合わせる。規制当局と独立研究者にも、主張を評価するための十分なエビデンスが必要となる。
Mercedes-Benzの安全性に関する評判は、基準を引き上げる。顧客はこのシステムを他の運転支援製品とだけ比較して判断するわけではない。制御され、予測可能なエンジニアリングというブランドのより広範な約束に照らして判断する。
NVIDIAは異なる信頼性の試練に直面する。再利用可能なプラットフォームが、異なる自動車メーカー、センサー、車両ダイナミクス、規制体制を満たせることを示さなければならない。
どちらの企業も、提携発表だけで評価されるべきではない。重要なエビデンスは、認可された運行設計領域、介入データ、インシデント報告、独立した評価から得られる。
したがって中心的なトレードオフは明確だ。共有AIプラットフォームは能力拡張を加速できるが、反復の高速化は透明性のある検証に対する負担も増大させる。
提携の成否を示す3つのシグナル
生産展開、信頼できる安全性エビデンス、レベル4運用が、この合意がインフラとなるのか、野心的なロードマップにとどまるのかを決める。
第一のシグナルは、MB.DRIVE ASSIST PROのより広範な展開だ。より多くの車両と市場で利用可能になれば、Mercedes-BenzがNVIDIAスタックを異なる交通規則や顧客期待に適応できることを示す。
実際の利用は、ローンチ発表より重要になる。ドライバーには、一貫した地点間支援、理解しやすい操作、慎重に演出されたデモの外でも信頼できる挙動が必要だ。
米国での展開には特に注目する必要がある。州ごとの規制、連邦政府の監督、多様な道路設計、訴訟リスクは、監視付き自動化にとって厳しい環境を作り出す。
Mercedes-Benzは、OTAアップデートがシステム挙動をどのように変えるのかも説明しなければならない。アップデートは問題を迅速に修正できるが、顧客が期待を形成した後に機能を変更する可能性もある。
第二のシグナルは、安全性開示の質だ。両社は冗長化されたハードウェア、多様なセンサー、AI推論、シミュレーション、並列ソフトウェアスタックを説明している。
これらの設計選択は、信頼できるエンジニアリング上の理論を確立する。しかし、ドライバーがどの程度の頻度で介入するのか、どの条件で故障が生じるのか、ソフトウェアのバージョン間で性能がどう変化するのかは明らかにしていない。
より具体的なエビデンスがあれば、提携の主張は強まる。有用な開示には、運行設計領域の制限、衝突報告、引き継ぎ時の挙動、故障復旧、独立試験の結果が含まれる。
規制当局による認可も、別の形のエビデンスを提供する。認可はリスクをなくすものではないが、特定の用途について定義された法的・技術的要件をシステムが満たしたことを示す。
第三のシグナルは、Mercedes-Benz車両とNVIDIA技術を用いる実際のレベル4サービスだ。商用ロボリムジンプログラムは、継続的な運用圧力の下で完全なシステムを試すことになる。
新しいS-Classは、意図された基盤の一つを提供する。Mercedes-BenzとNVIDIAは、将来のショーファーサービス型自律モビリティ向けにL4対応の車両アーキテクチャを説明している。
NVIDIAは、自社の自動車プラットフォームをライドヘイリング展開にも結び付けている。重要な節目は、装備された試作車ではない。認可された領域内で、想定される車内の人間によるフォールバックなしに有料乗客を運ぶサービスである。
このようなローンチは、複数の層を同時に検証する。車両は冗長化されたハードウェアを統合し、センサーを保守し、運転ソフトウェアを実行し、遠隔運用を管理し、地域の規則を満たさなければならない。
経済性も試される。技術的に有能な車両でも、許容可能な稼働率、保守費用、清掃、保険、フリート支援が必要となる。
Teslaは、車両製造、データ、ソフトウェア、自律性を一つの組織内で結び付けることを目指しているため、比較対象の一つとなる。Waymoは、専用の運転システムで範囲を限定したレベル4サービスを運営しているため、別の比較対象となる。
Mercedes-BenzとNVIDIAは、完全な垂直統合ではなく提携を選んでいる。この方針は各社に明確な強みをもたらすが、あらゆる重要な層に組織間の接点を加えることにもなる。
MB.DRIVE ASSIST PROが成功裏に拡大すれば、共有プラットフォームは量産面での信頼性を得る。安全性報告が具体的で独立検証可能になれば、両社の主張には重みが増す。
Mercedes-Benzベースのレベル4サービスが定常運用を始めれば、この提携は高度な支援プログラム以上のものになる。自動車メーカーとAIサプライヤーが、高度自動化スタックを共同運用できることの証拠となる。
いずれかのシグナルで失敗すれば、その結論は弱まる。利用可能性が限定的であれば、統合上の問題を示唆する。安全性エビデンスが乏しければ、中心的な約束は未検証のままとなる。
レベル4サービスの遅延は、L4対応アーキテクチャが実運用製品からまだ遠いことを示す。その違いは発表では曖昧にしやすいが、公道では隠しにくい。
Mercedes-BenzとNVIDIAの自動運転提携には、一貫した技術的な主張がある。すなわち、自動車工学、集中型コンピューティング、推論ベースAI、独立した安全制御を組み合わせることだ。
より難しい試練は制度面にある。Mercedes-Benz、NVIDIA、規制当局、フリート運営者、ドライバーは、明確な責任を維持しながら情報を共有しなければならない。
開発者や企業の導入担当者にとって、この教訓は自動車の領域にとどまりません。物理的な業務へ投入されるAIシステムには、高性能なモデルだけでは不十分です。明確な境界、監視、追跡可能な意思決定、そしてフォールバックの仕組みが必要です。
複雑なAIプログラムを評価するチームは、自らの調査にも同じ規律を適用できます。検索可能なエンジニアリング・ナレッジベースは、要件、テスト結果、インシデント報告、変化する前提条件を結び付けるのに役立ちます。
本番展開、安全性の根拠、そして最初の運用上のレベル4サービスに注目してください。これらのシグナルを総合することで、この拡大された提携が共有技術を説明責任のある自動化へと転換できるかどうかが明らかになるでしょう。
