OS のシステム：E/E アーキテクチャ、車両 OS、そして AI 定義車両

要旨

「車両 OS」は、ソフトウェア定義と呼ばれたいすべての自動車メーカーが持たねばならない言葉となった。しかし「OS」と呼ばれるものは、まったく同じ種類のものではない。本稿はオントロジーの整理から始める：コックピット OS は車両 OS ではなく、ドメイン OS は車両 OS ではなく、ランタイムは OS ではない。今日量産されているすべての車両 OS——MB.OS、NIO SkyOS、Li Auto HaloOS、Pleos Vehicle OS——は、単一の車両全体コントロールプレーンに統治されたマルチカーネルの集合体である。我々はこのコントロールプレーンを3つの観察可能な部分——コントラクト、オーケストレーション、ライフサイクル——に分解し、そこから6次元の車両 OS 能力マトリクス（Vehicle OS Capability Matrix, VOCM）を導出する。これを用いて15の自動車メーカーに初期評価を与え、D2 の AR スコアと対置する。

本稿の核心は1つの因果構造である。E/E アーキテクチャは車両 OS がなりうるものの境界を定める；しかし機能がソフトウェアになると、因果は逆転する——ソフトウェアのワークロードが次の E/E アーキテクチャを設計し始める（アーキテクチャ–OS 共進化ループ）。その上で我々は次のように論じる：自動運転は車両 OS が本物かどうかのストレステストである；AI は OS の上半分を薄くし、下半分を厚くする；そして業界が実際に標準化しているのは車両 API、データモデル、ランタイムコントラクトであって、「1つの自動車 OS」ではない。結論は3つの判断と1つの警告を提示し、5つの改訂トリガーを付す。

---

体裁に関する注記

本稿は Deep Dive に属し、Working Paper には属さない。両者の境界は長さではなく、コミットメントの水準にある：

• Working Paper（D1–D4、Zenodo DOI）＝確定した主張。黙って改訂されることはなく、5年の引用に耐えるよう構築される。
• Deep Dive（本欄）＝規律ある観察。改訂可能・反証可能であり、「これは我々がいま見ているもの」と明示され、DOI 体系の外にある。

本稿は Working Paper の認識的規律——出典の階層化、追跡可能な証拠、反論と失敗モードの必須記載——を継承するが、その終局性は継承しない。本稿は D1–D4 のいかなる公表済み結論も改訂しない；本稿が引用する D2 のスコアは公表版のものである。証拠の等級は本文中で [T1]、[T2]、[T3]、[推論] と表記する；付録 A を参照。本稿の結論は自らの改訂トリガーを備える（第10章）；いずれかのトリガーが作動すれば、変更を明示した改訂版を公表する。

---

序論：誰もが使い、誰も定義しない言葉

2025年6月、MB.OS を搭載した最初の CLA が Mercedes-Benz の Rastatt 工場でラインオフした [T1]。同じ時期に NIO は自社の SkyOS を「全ドメイン車両オペレーティングシステム」と呼び、Li Auto は HaloOS を Apache 2.0 でオープンソース化し、Toyota は新型 RAV4 とともに Arene を投入し、Hyundai は Pleos を「Vehicle OS」と「Connect」の2つのブランドに分けた。2026年までに、「車両 OS」はソフトウェア定義と呼ばれたいすべての自動車メーカーが持たねばならない言葉となっていた。

問題は、「OS」と呼ばれるものがまったく同じ種類のものではないことである。

Android Automotive は OS である。BMW Operating System X は OS と呼ばれる。NVIDIA DriveOS は OS と呼ばれる。AUTOSAR はときに誤って OS と呼ばれる。MB.OS、SkyOS、HaloOS、Pleos Vehicle OS もすべて OS である。これらを1つの表に並べて順位をつければ、リンゴとオレンジと果樹園を比べることになる。

本研究シリーズはこの言葉に3度触れながら、立ち止まって定義することはなかった。D1 は OS を7つのアーキテクチャ上の制御点のうち C3 として挙げ、RTOS、AUTOSAR、ミドルウェアを E/E アーキテクチャのソフトウェア層に書き込み、§3.4 でハイパーバイザーがオープンなエコシステムとハードリアルタイムの間の橋であると論じた。D2 は Mercedes のプロファイルで MMA（ハードウェアプラットフォーム）と MB.OS（ソフトウェアのオペレーティングシステム）を明示的に分け、両者を混同しないよう読者に警告した。DD-08『ドライバーの退場』は、人間のドライバーがフォールバック連鎖から去れば、fail-operational はプレミアムなオプションから参入条件へと変わると論じた。

3つはいずれも同じ空白を指している：「電気・電子トポロジー」と「インテリジェンス」の間で、どの層が一山のコントローラーを、プログラム可能で、進化し続けることができ、最終的に自動運転と AI を担える機械へと変えるのか？

それが本稿の答える問いである。主問いは1つだけである：

どのような条件の下で、E/E アーキテクチャは単なる電子トポロジーであることをやめ、「プログラム可能な車」のプラットフォームとなるのか？

我々の答えは4つの文に圧縮され、それがそのまま本稿の骨格をなす：

E/E は基盤である。コントロールプレーンが OS である。AI は適応的インテリジェンスである。自動運転はストレステストである。

展開すると、6つの判断になる：

• T1 | 定義： 車両 OS は1つのオペレーティングシステムではなく、車両全体コントロールプレーンに統治された「OS のシステム」である。コントロールプレーン＝コントラクト＋オーケストレーション＋ライフサイクル。
• T2 | 前提条件： 十分に分離された E/E アーキテクチャなしに車両 OS はない。ソフトウェア抽象化の天井は物理アーキテクチャによって定められる。
• T3 | 逆転： 機能がソフトウェアになると、因果は逆転する——ソフトウェアのワークロードが次の E/E アーキテクチャを設計し始める。これが本稿の中核的な独自貢献である：アーキテクチャ–OS 共進化ループ。
• T4 | ストレステスト： 自動運転は車両 OS ではない；それは「車両 OS」がその名に値するかどうかを試すワークロードである。
• T5 | ガバナンス： AI は OS を消し去らない。それは OS の上半分を薄くし、下半分を厚くする——確率的インテリジェンスは決定論的ガバナンスの内側で動かねばならない。
• T6 | 収束点： 業界が実際に標準化しているのは「1つの自動車 OS」ではなく、「車両 API＋データモデル＋ランタイムコントラクト」である。カーネルはコモディティ化しつつあり、制御点 C3 は C2（シリコン）と C4（ミドルウェア）の両側から締めつけられている。

最も基本的な作業——言葉の整理——から始めよう。

---

1. 命名の問題：「OS」と呼ばれるものがすべて OS ではない

1.1 オントロジーの整理

計算機科学において、「オペレーティングシステム」はかなり明確な意味を持つ：ハードウェア資源を管理し、その上のプログラムに抽象化と隔離を与えるソフトウェアの層である。Linux、QNX、各種 RTOS はすべてこれに当てはまる。厄介なのは、自動車産業が同じ言葉を少なくとも4つの異なる水準に当てはめていることである：

• カーネル水準の OS：QNX、Linux、Classic AUTOSAR OS、RTOS、マイクロカーネル。1つのチップまたは1つの ECU を管理する。
• ランタイムとミドルウェア：AUTOSAR Adaptive Platform、SOME/IP、DDS、ROS 2。通信、サービスディスカバリ、実行管理を定義するが、それ自体はカーネルの上で動く——Adaptive Platform のターゲットハードウェアは POSIX PSE51 準拠のオペレーティングシステムを動かし、AP はその上に構築される [T2]。
• ドメイン OS：Android Automotive、BMW OS X、NVIDIA DriveOS、HarmonyOS コックピット。コックピットや運転用コンピューターなど、1つの機能ドメインを管理する。
• OEM が「車両 OS」と呼ぶもの：MB.OS、SkyOS、HaloOS、Pleos Vehicle OS。車全体を管理すると主張する。

最初の3つの水準には明確な工学的境界がある。4つ目にはない。それはブランド名であり、組織的コミットメントであり、複数のカーネル、ドメイン、チップにまたがるソフトウェアの総体である。本稿全体は、この4つ目の水準に検証可能な定義を与える試みである。

1.2 3つの判別規則

定義する前に、3つの否定的規則を示す。その役割は、車両 OS に数えられないものを除外することである。

規則1：コックピット OS ≠ 車両 OS。

BMW Operating System X は AOSP ベースで、Panoramic iDrive の表示、インタラクション、デジタル体験を担う [T2]；Neue Klasse の実際の車両アーキテクチャは、インフォテインメント、自動運転、走行ダイナミクス、基本機能のための4つの「スーパーブレイン」にゾーンコントローラーを加えたものである [T1–T2]。Hyundai の分け方はさらに明快である：Pleos Connect は Android Automotive ベースのインフォテインメントシステムで、2026年 Q2 に投入予定；Pleos Vehicle OS は高性能車両コンピューターとゾーンコントローラーの上に構築された車両制御 OS である [T2–T3]。1つの企業が両者を別々のブランドに分けること自体が最良の証拠である：コックピットの画面で最も見栄えのするシステムは、車を制御できるシステムではない。

規則2：ドメイン OS ≠ 車両 OS。

NVIDIA DriveOS は、アクセラレーテッドコンピューティング、センサー統合、自動運転、AI コックピットのためのオペレーティングシステムおよびランタイムである；DriveOS 6.0 は TÜV SÜD により ISO 26262 ASIL D の認証を受けている [T2]。その分野で最も強力な製品の1つである。しかしそれが管理するのは DRIVE 演算ドメインであり、ボディ、熱、エネルギー、シャシーを含む車両全体の機能ではない。

規則3：ランタイム ≠ OS。

AUTOSAR Adaptive は振る舞い——実行管理、通信、ストレージ、セキュリティ——を定義する。下には POSIX カーネルに、上には OEM の統合に依存する。それを「OS」と呼ぶのは、TCP/IP をネットワークそのものと呼ぶようなものである。

3つの規則は1つの含意を共有する：名前は判定基準ではない。 OS と呼ばれるものが車両 OS であるとは限らない（BMW OS X はそうではない）；OS と呼ばれないものが、実は車両全体のプラットフォームであることもある（Tesla は自社のソフトウェアスタックに OS のブランドを与えたことがなく、Rivian も同様である）。Toyota の揺れる語彙はこの点をさらに鋭くする：2023年4月、Toyota は Arene を「包括的なソフトウェアプラットフォームであり車両オペレーティングシステム」と公式に説明した [T1]；2025年に新型 RAV4 で量産に至った時点では、Toyota と報道はより頻繁にそれを「ソフトウェア開発プラットフォーム」と呼んだ [T2]。これは言葉遊びではない。それは第4章で立ち戻る問いを提起する：車両 OS の制御点はランタイムにあるのか、それともソフトウェアのライフサイクルにあるのか？

1.3 中国の分類法：国家標準に裏打ちされた答え

定義の問題において、中国は他のどの地域よりも先へ進んだ。答えを国家標準に書き込んだからである。

2019年、全国自動車標準化技術委員会は『車用オペレーティングシステム標準体系』を公表し、車用オペレーティングシステムを2つの類型——車両制御オペレーティングシステムと車載オペレーティングシステム——に分けた [T1]。車両制御 OS はさらに、安全車両制御 OS（パワートレイン、シャシー、ボディ——最も厳しいリアルタイム性と安全要件を持つ）と、インテリジェント運転 OS（運転ドメインコントローラー向け）に分かれる；車載 OS はセンターコンソール、インストルメントクラスター、T-box に奉仕する。

2026年3月31日、この分類法は2つの推奨国家標準となり、同年7月1日に施行された [T1]：

• GB/T 47351-2026：車両制御オペレーティングシステム。Type I（インテリジェント運転 OS）と Type II（安全車両制御 OS）を定義する。
• GB/T 47341-2026：車載オペレーティングシステムの技術要件と試験方法。商用翻訳の抜粋によれば、車載 OS を「インテリジェントコネクテッドビークルに対し、運転自動化機能の実装以外のサービスを提供するソフトウェアの集合」と定義し、クラスター警告のような高リアルタイム性のシナリオを支える車載 OS には ASIL B 以上を推奨する [T3：商用翻訳であり、標準の本文ではない]。

公開報道によれば、起草組織の一覧そのものが産業地図である：Huawei（Yinwang）、Horizon Robotics、Qualcomm、NIO、BYD、Li Auto、Mercedes-Benz 中国、Volkswagen 中国がその中に含まれる [T2]。

国家標準の価値は、オペレーティングシステムをブランドではなく機能安全の属性によって分けた点にある。しかしそれは1つの空隙も残す：車両制御 OS と車載 OS はあるが、「車両 OS」はない。学界と産業界で一般的な4分類——安全車両制御 OS、インテリジェント運転 OS、インテリジェントコックピット OS、そしてドメイン横断の「中央計算 OS」——のうち、4つ目は標準の中に対応物を持たない。[推論] その空隙こそが、「車両 OS」というマーケティング概念の棲む場所であり、本稿がコントロールプレーンという考えで突き止めようとするものにほかならない。

1.4 では車両 OS は偽の命題なのか？

最も鋭い反論をまず机上に置こう：ブランドの層を剥ぎ取れば、いわゆる車両 OS は QNX＋Linux＋AUTOSAR＋ハイパーバイザー＋一山のミドルウェアにすぎない——そのすべては10年前から存在していた。何が残るのか？

我々の答え：ブランドとしては誇張されている；工学的実体としては実在する。 残るのはいかなる単一のカーネルでもなく、複数のカーネル、ドメイン、チップを1台の車へと組織するもの——統一されたサービスコントラクト、クリティカリティ水準をまたぐオーケストレーション、そして車両の全生涯にわたる更新と検証の体系——である。次章でそれを分解する。

---

2. OS のシステム：「車両 OS」を分解する

2.1 量産車両 OS はすべてマルチカーネルの集合体である

量産されているどの車両 OS を開けても、見つかるのは1つのカーネルではなく、一族である。

NIO SkyOS は「1+4+N」構造をとる [T2]：「1」は SkyOS-H、異種演算を管理するハイパーバイザー；「4」は異なるシナリオのための4つのカーネル——車両制御カーネルは形式検証された seL4 マイクロカーネルに基づき、コックピットカーネルは深くカスタマイズされた Android に基づく；「N」はドメイン横断の協調とライフサイクル更新のための自社製ミドルウェア部品群である。[T3：残りのサブカーネルの正確な分担については出典により異なる；ここでは立ち入らない。] SkyOS は2024年7月27日に全面リリースされ、NT3 プラットフォームの車種でフルスコープで稼働している [T2]。

Li Auto HaloOS は3点セットである：車両制御 OS、インテリジェント運転 OS、通信ミドルウェア [T2]。2025年3月27日、Li Auto はこのシステムのオープンソース化を発表した；4月に 0.1.0（安全リアルタイム RTOS と軽量通信バス）を、6月30日に 1.0.0 をリリースし、続いて仮想化エンジンを公開した [T2]。Li Auto は200人超と10億元超を投じ、2024年に最初の量産版を出荷し、チップ適合を3–6か月から4週間に短縮したと述べる [T2、企業の主張]。

Hyundai Pleos は車両制御 OS とコックピット OS を2つのブランドに分ける（1.2 参照）。GB/T 47351 は車両制御 OS そのものを Type I と Type II に分ける。

結論は1つしかなく、それが本稿の第一テーゼである：

T1 | 車両 OS は1つのオペレーティングシステムではなく、車両全体コントロールプレーンに統治された「OS のシステム」である。

2.2 6層スタックモデル：S0–S5

異なるベンダーの製品を1枚の絵に収めるため、我々は6層スタックモデルを提案する（図 2.1）。

その周りには、車上にはないが車が何をできるかを決める外環がある：クラウド、OTA、データループ、DevSecOps、そして新たに現れつつあるモデルのライフサイクル。

図 2.1 — OS のシステム：S0–S5 スタックと外環。読み方：車両 OS は図中のいかなる単一の層でもなく、S4 による S1–S3 の統一的ガバナンスである；S0 は S4 がどれだけ統治できるかを決める；外環は車が売られた後も S4 が進化し続けられるかを決める。

2.3 コントロールプレーンの3つの部分：コントラクト、オーケストレーション、ライフサイクル

「コントロールプレーン」はネットワーク工学からの借用である：データプレーンは個々のパケットを転送し、コントロールプレーンはパケットがどこへ行くべきかを決める。車においては、データプレーンは S1–S3 で実際に動いているプロセス、タスク、信号である；コントロールプレーンは、誰がどこで、どの優先度で、どのインターフェースを通じて動いてよいか、そしてどの条件の下で置き換えられてよいかを決める層である。

我々は車両コントロールプレーンを3つの部分に分解する：

1. コントラクト：サービスインターフェース、車両 API、信号とデータのセマンティクス。それは「機能は ECU の物理的位置から切り離される」ことを約束する——HVAC 制御サービスは、自らが最終的にどのチップ上で動くかを気にする必要がない。
2. オーケストレーション：混合クリティカリティのスケジューリング、隔離の証明（freedom from interference）、機能のマイグレーション、資源の調停。ASIL D のブレーキ機能と QM 水準の音楽再生が、干渉することなく1つのチップをどう共有するかを決める。
3. ライフサイクル：OTA、ロールバック、診断、DevSecOps、そしていまやモデルのライフサイクル。車が工場を出た後、どれだけ、どれほど速く、どの安全論証の下で変更できるかを決める。

この3つの部分を通して見ると、1.2 の規則ははるかに明瞭になる：コックピット OS はコックピットドメインについてのみコントラクトを持つ；ドメイン OS は強力なオーケストレーションを持つが、1つのドメインの内部に限られる；ランタイムはコントラクトを規定するが、車両全体のオーケストレーションやライフサイクルには責任を負わない。コントラクト、オーケストレーション、ライフサイクルが揃って車両の主要ドメインを覆うときにのみ、我々はそれを車両 OS と呼ぶ。

この定義には1つの直接的な利点がある：観察可能であることだ。ある自動車メーカーが車両 OS を持つと主張するなら、我々は3つの問いを発すれば足りる——その車両 API はどのドメインを覆うか？ その混合クリティカリティ統合はどの認証水準に達しているか？ その OTA はどのドメインを更新できるか？ 第5章の VOCM 採点は、この3つの問いを6つの次元に展開する。

2.4 過小評価された事実：底部の極端な集中、頂部の極端な分断

各ベンダーの製品を S0–S5 に射影すると、鮮烈な構図が浮かび上がる：

• S1 では、市場は極端に集中している。 BlackBerry の FY2026 年次報告は、QNX が2億7500万台超の車両に組み込まれ、前年比2000万台増、45社超の自動車メーカーと協業し、上位10 OEM と上位25 EV OEM のうち24社を覆うと開示している [T1]。QNX OS for Safety と QNX Hypervisor for Safety はいずれも ISO 26262 ASIL D の認証を受けている [T1]。
• S4 では、市場は極端に分断されている。 10社を超える自動車メーカーがそれぞれ独自の車両 OS を主張し、相互の互換性はない。

これはソフトウェア層に再出現した D1 の2層収束–発散モデルである：インフラは底部で収束し、制御セマンティクスは頂部で発散する。 それはまた第7章が論じる争奪を予告する——S1 と S2 がコモディティ化を免れないなら、価値はどこへ行くのか？

---

3. 車より先に道：E/E は OS がなりうるものの境界を定める

3.1 なぜ分散アーキテクチャの上に車両 OS は育たないのか

100個の ECU を持つ従来型の車を思い浮かべてほしい。それぞれが独自の OSEK または Classic AUTOSAR を動かし、それぞれが異なる Tier 1 から来て、それぞれが独自のソフトウェアバージョン、キャリブレーションデータ、書き込み手順を持つ。そのような車では車両 OS は物理的に不可能である——統一されたランタイムが棲む場所はなく、サービスコントラクトが ECU の境界を越えるのに十分な幅の経路もない。

これが本稿の第二テーゼである：

T2 | 十分に分離された E/E アーキテクチャなしに車両 OS はない。ソフトウェア抽象化の天井は物理アーキテクチャによって定められる。

3.2 5つのイネーブラー

E/E アーキテクチャが分散型からドメイン型へ、さらにゾーン＋中央演算へと移るにつれ、5つのものが車両コントロールプレーンを工学的に可能にした（D1 第2章の Bosch 6段階フレームワークに対応する）：

5つのうち、最初の4つはコントロールプレーンが統一されうるかを決め；5つ目はそれが信頼されうるかを決める。最初の4つなしに車両 OS はない；5つ目なしには、車両 OS は fail-soft の世界にとどまる——第6章が展開する論点である。

3.3 世代マトリクス：各 E/E 世代はどの層を宿せるか

S0–S5 を E/E 世代と交差させると（図 3.1）、単純なパターンが現れる：

• 分散型：S1 のみ（各 ECU の独自 RTOS）。
• ドメイン型：S2 と S3 が現れる——コックピットには Android、運転には Linux / QNX、ドメイン内 SOA。しかし各ドメインはそれぞれ独自に動き；この世代の「車両 OS」の主張の大半はマーケティングだった。
• ドメイン横断融合：部分的な S4 が現れる——2つか3つのドメインがコントラクトを共有し始め；コックピットと運転の統合が試みられる。
• ゾーン＋中央演算：S4 が真に工学的現実となる。
• 中央＋AI ネイティブ：S5 が現れ始める。

図 3.1 — 各 E/E 世代が宿せるもの。X 軸は E/E 世代（分散型 → ドメイン型 → ドメイン横断融合 → ゾーン＋中央 → 中央＋AI ネイティブ）；Y 軸は S1–S5。各セルは「実現不可 / 部分的 / 量産中 / 萌芽」と記される。読み方：S4 の「量産中」のセルはゾーン＋中央の列以降にのみ現れる；それ以前に「車両 OS」と銘打たれた製品の大半は、実際には S3 に位置する。

このマトリクスは反証可能な系を生む：誰かが E/E 世代を変えずに車両の主要ドメインを覆うコントロールプレーンを構築したなら、T2 は改訂されねばならない。 我々はこれを改訂トリガーの1つとして掲げる（第10章）。

---

4. 因果の逆転：ソフトウェアがハードウェアを設計し始めるとき

4.1 「E/E が OS を支える」から「OS が E/E を設計する」へ

第3章は一方向を記述した：E/E が先、OS が後。それは産業が最も頻繁に語る物語であり——そして不完全なほうの半分である。

もう半分：ある自動車メーカーが真に車両コントロールプレーンを構築したとき、それは逆に次の E/E アーキテクチャを決め始める。

GM は、自動車メーカー自身が公表した稀な事例を提供している。同社は、2028年の中央演算プラットフォームが10倍の OTA 能力、1000倍の帯域、35倍の AI 演算をもたらすと述べる [T1、企業の主張]。この3つの数字のいずれも「より良いハードウェア」から定義されたものではない；すべてソフトウェアが行わねばならないことから逆算されたハードウェア仕様である。

2026年9月の Leapmotor のテックデーは、2つ目の、より詳細な事例を提供した。Leapmotor は自社の E/E の進化を明確な世代の系譜として示す：

• LEAP 3.0：「四つ葉のクローバー」中央統合アーキテクチャ、2023年投入。
• LEAP 4.0：D プラットフォーム上のシングルチップによるコックピット–運転統合 [T3]。
• LEAP 5.0：来たる「四つ葉のクローバー 5.0」、3つの変化を伴う [T2–T3]：
  • 制御：中央統合制御。
  • 電源：車両全体 48V 給電、総配線長500メートル未満、ハーネス重量最大50%削減、そして——同社によれば——配線の熱損失を1/16に低減。
  • ネットワーク：非対称帯域方式の車両全体 Ethernet——下り 10G、上り 100M。
• 量産：最初の車種は2027年 [T2]。

最後のネットワーク項目には立ち止まる価値がある。対称帯域は汎用ネットワークの論理である；非対称帯域は、ネットワークがデータの実際の流れ方——どちらの方向が重いトラフィックを運び、どちらが制御と状態だけを運ぶか——を中心に設計されていることを意味する。[推論] これはソフトウェアとデータフローによって定義されたネットワークトポロジーである：まずコントロールプレーンがどのようにデータを動かさねばならないかを知り、それから配線の仕方を決める。48V 給電と短いハーネスも同じ論理に従う——中央制御によって、配電と配線を「機能ごとに1つの箱」ではなく「1つの頭脳と少数のゾーン」を中心に再編できる。

これが本稿の中核テーゼである：

T3 | 機能がソフトウェアになると、因果は逆転する：ソフトウェアのワークロードが次の E/E アーキテクチャを設計し始める。

2つの方向を合わせると、閉じたループが得られる（図 4.1）：

E/E アーキテクチャ → 車両コントロールプレーン → ワークロード / データ / AI → 次世代 E/E アーキテクチャ

我々はこれをアーキテクチャ–OS 共進化ループと呼ぶ。

図 4.1 — アーキテクチャ–OS 共進化ループ。読み方：ループの上半分（E/E → OS）は「可能性の境界」であり、第3章の5つのイネーブラーからなる；下半分（OS → E/E）は「逆設計」であり、上の表の6類の要件からなる。ある自動車メーカーがソフトウェア定義の段階に入ったかどうかは、OS のブランドを持つかどうかではなく、下半分が回り始めたかどうかで判断される。

明確にしておくと、このループはもう1つの成熟度ラダーではない。本シリーズにはすでに AR0–AR5（設計されたシステムの能力閾値）と AI²-ML（ツールチェーンの成熟度）がある。共進化ループは因果構造を記述するものであり、等級ではない。

4.2 脱知能化スペクトラム：信頼をめぐる意見の相違

ループの下半分の最も目に見える表れは、ゾーンコントローラーがどこまで「脱知能化」されるか——クリティカルな制御ロジックがゾーンにとどまるか、中央へ移るか——である。

一方の端には GM がいる。 そのゾーン「アグリゲーター」は明示的に「制御ロジックを実行しない」；すべてのインテリジェンス——センサーフュージョン、制御の調停、機械学習の推論——は中央コンピューターにある [T1]。これは完全に脱知能化されたルートである。

もう一方の端には BMW がいる。 Neue Klasse は走行ダイナミクスを「Heart of Joy」と呼ばれる専用の高性能コンピューターに置き、それは従来型 ECU の10倍速い [T2]；インフォテインメント、自動運転、基本機能はそれぞれ独自のスーパーブレインを持つ。これは「クリティカルな制御は中央の外にとどまる」ルートである。

さらにその外側には、制御ロジックが多数の ECU に分散した従来型アーキテクチャがある。

図 4.2 — ゾーンコントローラーの脱知能化スペクトラム。左から右へ：分散 ECU → BMW 型「クリティカルな制御は独立した演算上に」→ GM 型「アグリゲーターは転送のみ；すべてのインテリジェンスは中央に」。読み方：X 軸は「どれだけ先進的か」ではなく、「ASIL D の実行チェーンを担うことについて、中央コントロールプレーンにどれだけの信頼が置かれているか」である。

[推論] この意見の相違はハードウェアトポロジーをめぐる論争に見える；実質的には信頼の問題である：中央コントロールプレーンの決定論性は、ASIL D の実行チェーンを託せるほどすでに十分か？ GM の答えは「はい」、BMW の答えは「完全にではない」。標準的な答えはないが、因果の方向は明確である——E/E トポロジーを決めているのは、OS の能力についての判断である。

4.3 観察可能な代理指標：OTA の粒度

コントロールプレーンのカバー範囲は外部から観察しにくい——自動車メーカーは自社の車両 API カタログを公表しない。しかし1つのことは観察可能である：OTA がどのドメインを更新できるか。

新型 Toyota RAV4 は明快な例である：Arene により、コックピットと ADAS は無線で更新できるが、ボディとダイナミクスの機能はまだできない [T2]。[推論] これは Arene のコントラクトがまだ車両制御ドメインを覆っていないことを示す。逆に、ブレーキやパワートレインのキャリブレーションを無線で更新できる自動車メーカーは、安全クリティカルな実行チェーンをライフサイクル管理の下に置いたことになる。

したがって我々は OTA の粒度を「コントロールプレーンのコントラクトのカバー範囲」の外部代理指標として用い、VOCM の次元 V5（第5章）で使う。それは完全ではない——OTA 対応であることは、よく設計されていることと同じではない——が、公開情報から検証できる数少ない指標の1つである。

4.4 コンウェイの法則のもう1つの顔：1つの組織が届ける E/E と OS

D3 は Tesla による FSD チームと Optimus チームの統合を論じ、組織構造を用いて技術アーキテクチャを形づくることを扱った。E/E と OS の関係については、より新しく、より直接的な公開証拠がある。

2026年の委任状説明書（proxy statement）において、Rivian は Volkswagen Group との合弁会社 RV Tech を「ソフトウェア、電子制御ユニット、関連するネットワークアーキテクチャに重点を置く電気アーキテクチャ技術企業」と定義している [T1]。言い換えれば、この会社では E/E トポロジー、ECU、ソフトウェアが1つの成果物である。

Rivian の FY2025 の数字は、その成果物の経済的重みを示す：ソフトウェア・サービスの売上総利益は2024年の700万ドルから5億7600万ドルへ増加し、主に合弁会社に関連する「車両電気アーキテクチャとソフトウェア開発サービス」がそれを牽引した [T1]。

[推論] これらの数字の意義は金額ではなく、値づけの単位にある：「E/E＋OS」はいまや一体として値づけされ、取引されうる。 アーキテクチャが単独で売れるようになれば、それはもはや車の付属物ではなく資産である。ここで共進化ループは貸借対照表上の対応物を得る。

Volkswagen Group はさらに先へ進む：異なる組織によって届けられる2つの E/E アーキテクチャ——西半球では RV Tech、中国では CEA——を同時に走らせている。5.5 節でこれに立ち戻る。

4.5 後方互換性：ループの代償、そしてコントラクトの試金石

共進化ループには見落とされやすい副作用がある：次の E/E がソフトウェアの必要によって設計し直されている間も、前世代の車はまだ路上にある。 それらは新しいソフトウェアを受け取り続けられるのか？ これは「OTA ができるか？」よりも厳しい問いへとつながる：

車両 OS は後方互換でありうるか——前世代、あるいは前々世代のハードウェアの車に、新世代のソフトウェア能力を無線で獲得し続けさせられるか？

我々の答え：後方互換性は、ハードウェアとソフトウェアの分離が本物かどうかを外部から試す最も厳しいテストである；ただしそれは機能が同等かどうかではなく、コントラクトが安定しているかどうかで判断されるべきである。 理由は4つある。

第一に、それは外部から検証できる唯一の分離の形である。 どの自動車メーカーもハードウェアとソフトウェアを分離したと言う。しかし新しいソフトウェアが新しいハードウェアでしか動かないなら、その「分離」は実際には「世代ごとの再統合」である。分離が証明されるのは、新世代のソフトウェアが同じコントラクトを通じて古いハードウェアに展開できるときだけである。

第二に、既存フリートはソフトウェア経済の分母である。 ソフトウェアのサブスクリプション、有料機能、データループはすべて、更新を受け取れる車両の数に比例して拡大する。世代ごとに古い車を切り捨てれば、ソフトウェア収益の分母は周期的にゼロへリセットされる。

第三に、規制はすでに互換性を更新プロセスに書き込んでいる。 UN R156 の 7.1.1 項は、製造者のソフトウェア更新管理システムが一連のプロセスを含むことを要求する。その中には次のものがある：更新の対象車両を特定すること（7.1.1.6）、更新を発行する前に対象車両の構成との互換性を確認すること（7.1.1.7）、更新されるシステムと他のシステムとの相互依存関係を特定すること（7.1.1.5）、そして更新の前後で RXSWIN ソフトウェア識別を維持すること（7.1.1.3）[T1]。後方互換性はユーザー体験の問題にとどまらない；それは更新管理システムが答えねばならない項目である。

第四に、それはループの中の緊張を露わにする。 次の E/E が古い車のために同じコントラクトを保たねばならないなら、コントラクトは E/E の進化経路をロックインする——まさにコントロールプレーンの価値とコストが同時に現れる場所である。コントラクトを捨てれば既存フリートを手放し；保てば新しいアーキテクチャが古いインターフェースを背負う。

しかし後方互換性は機能の同等性を意味しえない。演算、センサー構成、冗長は OTA が変えられない物理的事実である。D3 はすでに Tesla の HW3 と新しい FSD バージョンの間の世代的断絶を論じた：ハードウェアの差が大きすぎれば、最も積極的なソフトウェア定義のプレイヤーでさえ、古いハードウェアにすべての新しい能力を動かさせることはできない。

より良い判断の仕方はスマートフォン産業から借りられる——能力の階層化の下でのコントラクトの安定性：

Leapmotor のテックデーはレベル3の公開事例を示した：その LWM 世界モデル運転支援は、報じられるところコード量を90%削減し、200、640、1,280 TOPS の演算階層に展開でき、LiDAR 搭載の全車両——報道によれば既存車約35万台——に対する無償アップグレードと生涯無償利用の約束を伴う [T3、企業の主張]。[推論]「1つのモデル、複数の演算階層」はそれ自体が後方互換性のための設計である——能力の差を「あるかないか」から「多いか少ないか」へと変える。

したがって我々は後方互換性を VOCM の V2（ハードウェアとソフトウェアの分離；付録 B）の採点基準に組み込む：V2 が4以上を得られるのは、ソフトウェアの能力がハードウェア世代をまたいで届けられることが示された場合のみである。それが7つ目の次元でないのは、本質的に独立した能力ではなく分離のテストだからである。

4.6 まとめ：自動車メーカーが車両 OS を持つかを見分けるには、下半分を見よ

本章の結論は、そのまま実践的なテストとなる：

ある自動車メーカーが「車両 OS を持つか」を問うな。その下半分が回り始めたか——次の E/E 仕様が、現世代のソフトウェアの必要によって定義されているか——を問え。

答えが「はい」なら、それはソフトウェア定義の時代に入っている。「いいえ」なら、その OS ブランドが何と呼ばれていようと、それはまだ「ハードウェア定義、ソフトウェア充填」の段階にある。

第二の問いがある：前世代の車はまだ同じコントラクトの上にあるか？ 下半分が速く回るほど、この問いは鋭くなる。

---

5. 2026年のテーブル：誰が何をしており、どこまで来たのか

5.1 「成熟しているか？」ではなく「どの層が成熟しているか？」を問え

「車両 OS は成熟しているか？」には答えがない。層ごとに時代が違うからである。

全体的な判断：

2026年は、車両 OS が「アーキテクチャ上の野心」から「初期の量産上の現実」へ移った年である。 それはもはやスライドではないが、Android / iOS のような安定した産業パラダイムからはほど遠い。

量産状況によって、主要プレイヤーは4つの階層に分かれる。これは記述的な階層分けであって、新しい成熟度ラダーではないことに注意されたい：

• M1 スケールしたインフラ（数億台 / 数百万台）：QNX、Classic AUTOSAR、HarmonyOS コックピット、Android Automotive。
• M2 量産中の OEM 全ドメインコントロールプレーン：MB.OS（CLA）、SkyOS（NT3 プラットフォーム）、HaloOS、BMW Neue Klasse、Tesla。
• M3 初投入または部分ドメインでの量産：Toyota Arene（RAV4；ボディとダイナミクスはまだ OTA 更新不可）[T2]；Hyundai Pleos Connect（2026年 Q2 初投入、インフォテインメントのみ）[T2–T3]；Rivian の第2世代プラットフォーム。
• M4 ロードマップ上または再編中：GM の中央演算プラットフォーム（2028年、Cadillac Escalade IQ でデビュー）[T1]；Stellantis STLA Brain（当初は2024年末までに統合予定、現在は2027年に STLA One プラットフォームと初めて統合）[T1–T2]；Volkswagen Group × Rivian の RV Tech アーキテクチャ（2026年 Q1 に冬季試験完了、2027年に ID.EVERY1 でデビュー）[T1]；Hyundai Pleos Vehicle OS とその中央集権化ゾーンアーキテクチャ（2030年目標）[T3]。

Volkswagen Group の中国向けアーキテクチャ CEA はすでにこの階層を越えている：2025年末に安徽で量産に入り、2026年1月に ID. UNYX 07 とともに投入され、同社によれば車両全体 OTA に対応する [T1]——M3 の事例である。

繰り返し現れるパターンに注目する価値がある：M4 のほぼすべての自動車メーカーが、自らの当初のスケジュールより遅れている。 Volkswagen Group のソフトウェア子会社 CARIAD は最も注視されてきた例である：それが届けるはずだった統一ソフトウェアプラットフォームは繰り返し遅延し、同社は2025年から大規模な再編と人員削減を経験し [T3]、次世代の西側アーキテクチャはいまや RV Tech によって届けられる。[推論] 遅延の原因がカーネルやチップであることは稀である；たいていは組織である——数十の機能別サイロを1つのプラットフォーム組織に変えることは、ハイパーバイザーを書くよりはるかに難しい。第9章でこれに立ち戻る。

5.2 ブランドではなく役割で：9種類のプレイヤー

車両 OS のテーブルには、まったく異なる役割を持つプレイヤーが座っている。ブランドで順位をつけると彼らを混同してしまう；アーキテクチャ上の役割で分類すると、誰が実際に誰と競争しているのかが見える。

5.3 VOCM：車両コントロールプレーンを6次元で採点する

役割①から④のプレイヤーを1つの物差しで測るため、我々は**車両 OS 能力マトリクス（Vehicle OS Capability Matrix, VOCM）**を提案する。それは 2.3 節の「コントラクト＋オーケストレーション＋ライフサイクル」を6つの次元に展開し、各次元を0–5で採点し、満点は30である。採点基準は付録 B にある。

VOCM と本シリーズの既存フレームワークとの関係——二重計上を避けるため、これは明確に述べておかねばならない：

• AR0–AR5 は設計されたシステム（車両）のアーキテクチャ上の能力閾値、主にハードウェアトポロジーとシステム統合を測る；VOCM はソフトウェアのコントロールプレーンのみを測る。両者は直交する：ある自動車メーカーが AR で高く VOCM で低い、あるいはその逆であることはありうる——そしてその不一致こそが分析上の価値のありかである。
• AI²-ML はアーキテクチャツールチェーンの成熟度を測る——まったく別の対象である。VOCM の V2 と V5 は名前の上では AI²-ML の D2（HW/SW 分離）と D3（OTA）に似ているが、前者は車の中のソフトウェアを見、後者は車を設計するために使われるツールを見る。
• VOCM は成熟度ラダーではなく、「VOCM レベル」を定義しない。それは6次元の能力プロファイルである。

5.4 初期評価

下表は VOCM の初期評価を示し、D2 の AR スナップショットスコア（Snapshot 2026.1.31、5次元合計25点満点、ここでは引用であり再採点ではない）と対置する。

スコアは公開情報のみに基づく。信頼度 H / M / L は証拠の強さを反映する：H＝大半の次元が Tier 1–2 の証拠で直接裏づけられる；M＝一部の次元が企業の主張に依拠する；L＝大半の次元が二次情報または推論に依拠する。D2 と同様、旗艦アーキテクチャは量産中だがフリートの大半がまだ切り替わっていない自動車メーカーについては、表は最新の量産アーキテクチャを採点し、注記でその旨を述べる。

未採点（今回は証拠不十分）：Ford、Lucid、Geely、GWM、SAIC、Stellantis、Renault、Kia。

Leapmotor は D2 の22 OEM に含まれないため、VOCM スコアはあるが AR スコアはなく、図 5.1 の散布図には現れない。そのスコアの根拠：

• V1、V3：LEAP 3.0 以来の中央統合アーキテクチャ；LEAP 4.0 でのシングルチップによるコックピット–運転統合 [T3]。
• V2：その世界モデルは3つの演算階層にまたがって展開でき、LiDAR 搭載の既存車両への無償提供が約束されている [T3、企業の主張]。
• V6：車両–クラウド AgentOS [T3]。
• 残りの次元は二次報道に依拠する；信頼度は低い。

スコアは LEAP 5.0 が2027年に量産に至った時点で更新する。

注記：

• Mercedes は CLA で初投入された MB.OS に基づいて採点している。
• Volkswagen Group は中国の CEA アーキテクチャ（ID. UNYX 07）に基づいて採点している。公開情報上の根拠：準中央演算を伴うゾーン制御、制御ユニット約30%削減、車両全体 OTA 対応、すべてのパワートレイン——バッテリー EV、ハイブリッド、内燃機関——をカバー [T1]；2年ごとに新世代の CEA を投入（2027年の 2.0 は A〜D セグメントの車種にまたがる）、運転用演算は XPeng の Turing チップと CARIZON（Volkswagen と Horizon Robotics の合弁会社）のソリューションの両方で計画されている [T3]。CEA は XPeng と共同開発され、そのアーキテクチャ系譜を受け継いでいるため、V1、V3、V4、V5 について公開情報が乏しい箇所では XPeng のスコアを参照している [推論]——付録 B の「証拠がなければ2を超えない」規則に対する同系譜の例外である。V6 は XPeng より1点低い：運転用演算は2社のサプライヤーから供給され、公開情報からは、XPeng のようなエンドツーエンド / VLA と OS の共同スケジューリングが CEA 上で動いていることは確認できない。
• RV Tech アーキテクチャはまだ量産されておらず（2027年）、今回は採点しない；投入後に更新する。同社は「強力なモジュール式中央コンピューターがすべての車両機能を制御する」と述べる [T1]。それが量産で成り立てば、その V1 は直ちに4–5に達するだろう。

図 5.1 — E/E アーキテクチャ × 車両 OS 能力。X 軸：D2 の AR スナップショット合計（/25）；Y 軸：VOCM 合計（/30）。自動車メーカーごとに1点；白抜きの点は信頼度が低いことを示す。破線は等比対角線（各尺度の最大値に対して同じ比率）；網掛けの帯はサンプルのトレンド線 ±2.5点（VW CEA を除いてフィット）。読み方：トレンド帯の内側にある自動車メーカーは、コントロールプレーンが E/E と歩調を合わせて進化している；帯から明らかに外れた点こそ、問い直す価値のある点である。

5.5 図を読む：4つの発見

発見1：AR と VOCM は密接に連動するが、コントロールプレーンは半歩遅れている。 VW CEA を除くと、図 5.1 の13点はほぼ一直線に並ぶ：フィットした傾きは約1.2——ちょうど2つの尺度の最大値の比（30/25）——であり、すべての点がトレンドから3点以内にある。これ自体が T2 の証拠である——E/E が到達した地点に、コントロールプレーンもおおむね到達している。しかしトレンド線は全体として等比対角線より約3点下にある：各尺度の最大値で正規化すると、業界のコントロールプレーンは総じて E/E より約1割遅れている。[推論] これは共進化ループと整合する：その上半分（E/E が可能性の境界を定める）は何年も回り続けてきたが、下半分（ソフトウェアが E/E を逆方向に設計する）は回り始めたばかりである。AR スコアが15未満の自動車メーカーのうち、VOCM が15を超えるのは VW CEA だけである；その理由は発見4で説明する。

トレンド帯の下にいるのは、「E/E がコントロールプレーンに先行する」自動車メーカーである： 最も明確なのは Toyota で、Rivian は帯の下端に位置する。[推論] Toyota にとって、これはハードウェアアーキテクチャが先に動き、Arene のコントラクトがまだ追いついていないことを意味する——4.3 の OTA 粒度の観察と整合的である。Rivian は異なる：その E/E はサンプルの中で最も積極的なものの1つだが、ソフトウェアスタックの公開開示は最も乏しい；その低めのスコアは、能力の欠如よりも証拠の欠如（低い信頼度）を反映している。

発見2：中国の新興勢力は V4 と V2 で総じて高得点である。 Li Auto による HaloOS のオープンソース化、Huawei のブランド横断エコシステム、Xiaomi の「人・車・家」エコシステムは、いずれも開放性を戦略として扱う。[推論] これは標準先行・サプライチェーン共同構築という中国の環境に合致する——インターフェースが標準化されると、開放のコストは下がり、便益は上がる。

発見3：同じ AR 階層の中で、Mercedes のコントロールプレーンのスコアが最も高い。 Mercedes と BYD は D2 ではどちらも AR2.5（17点）だが、MB.OS の初期 VOCM（20）は BYD（17）より3点高く、トレンド帯の上端に位置する。これは慎重な読みを要する：D2 の AR スナップショットはグループ全体を採点するが、MB.OS は単一車種である CLA に最初に搭載された。[推論] より可能性の高い説明は、Mercedes がまず旗艦車種でコントロールプレーンを構築し、後続車種で E/E を追いつかせているということである——まさに共進化ループの下半分が回り始めたときの姿である。これが正しければ、その次世代車種は明らかに高い AR を示すだろう；正しくなければ、MB.OS のコントラクトのカバー範囲は過大評価されている（どの安全クリティカルなアクチュエーターが実際に MB.OS の下にあるかは公表されていない）。

発見4：Volkswagen Group は車両 OS の問いに「1社、2つのアーキテクチャ、2つの外部パートナー」で答えた。 これはサンプルの中で最も異例の点であり、個別に論じる価値がある。

• 中国の CEA：Volkswagen Group China Technology Company、CARIAD China、XPeng による共同開発で、コンセプトから量産までわずか18か月——同社によれば、Volkswagen Group が全く新しい電子アーキテクチャで達成した過去最速のタイムライン；選ばれた主要プロジェクトでは新車種の開発コストが最大50%低下する [T1、企業の主張]。
• 西側の RV Tech：Rivian との合弁会社で、米国、カナダ、スウェーデン、セルビア、ベルリンにまたがり1,500人超の従業員を擁する [T1]。

2つのルートには1つの共通点がある：Volkswagen Group の新世代車両コントロールプレーンは、どちらもグループ自身のソフトウェア子会社が独自に届けたものではない；どちらもコントロールプレーンですでに先行する新興勢力と共同構築された。

[推論] その意義は Volkswagen にとどまらない。それは車両コントロールプレーンがいまや企業をまたいで「輸入」されうることを示す——カーネルやミドルウェアを買うことによってではなく、完全な E/E トポロジー、ソフトウェアスタック、開発手法を取り込むことによって。CEA の18か月は、ループの下半分を「借りて」回し始めることのできる速度である。代償も同様に明確である：1つのグループが、異なるインターフェース体制（中国国家標準と西側の標準エコシステム）に向き合う2つのアーキテクチャ、2つのパートナー、2つのソフトウェア総体を維持しなければならない。それぞれの尺度の最大値で正規化すると、CEA の初期 VOCM（20/30）はグループ全体の AR スナップショット（13/25）より明らかに高く、図 5.1 でトレンド帯のはるか上にある唯一の点となっている。その一部は対象範囲の問題である——Mercedes と同様、AR はグループ全体を採点し、VOCM は最新のアーキテクチャを採点する；[推論] しかし主な理由は、コントロールプレーンが同系譜のアーキテクチャとともに丸ごと輸入され、グループ全体の E/E より先に到達したことにある。CEA は中国向けの1つの新アーキテクチャにすぎず、それと欧州のグループ既存プラットフォームとの差こそ、追跡すべきより重要な事柄である。RV Tech が量産に至れば、Volkswagen Group は、2つの市場それぞれに別個のゾーン＋中央演算コントロールプレーンを持つ、サンプル中唯一のレガシー自動車メーカーとなる。それが過渡的な形態なのか、多国籍自動車メーカーの常態となるのかは、7.6 節の問いである。

---

6. ストレステスト：コックピットは OS がアプリを動かせるかを試し、自動運転は車を動かせるかを試す

6.1 自動運転は OS ではない

これは冗長に聞こえるが、産業はしばしば両者を混同する——ある企業の運転ソフトウェアスタックを、その企業の「OS」と呼ぶのである。

T4 | 自動運転は車両 OS ではない。それはコントロールプレーン上で動く最も要求の厳しいワークロードであり——「車両 OS」がその名に値するかどうかを試す最良のストレステストである。

一文で言えば：

コックピットは OS がアプリケーションを動かせるかを試し；自動運転は車両 OS が車両を動かせるかを試す。

6.2 故障の帰結のラダー

なぜ自動運転がストレステストなのか？ それは故障のコストを段階的に引き上げ、ついにはそれを受け止める人間が誰も残らなくなるからである。

図 6.1 — 車両 OS のストレステストとしての自動運転。読み方：左から右へ、故障のコストは「不便」から「車両レベルのフォールバック」へと上がり、コントロールプレーンへの要求は「再起動できる」から「部分的な故障の下でもなお安全に動作していることを証明できる」へと上がる。L3 と L4 の間の段差が最も高い——そこで人間がフォールバック連鎖から去るのである。

これは DD-08『ドライバーの退場』が論じた分水嶺である：ドライバーが退場すれば、冗長ハードウェア、safety case、ランタイム監視、OTA 検証はもはや付加物ではなく、システムの能力そのものとなる。本稿は DD-08 に1つの視点を加える：これらの要件はすべて、最終的にコントロールプレーンに降りてくる。 冗長な演算ユニットは、それらの間を切り替えられるオーケストレーション層を要する；OTA は「この更新は safety case を壊さない」ことを証明できるライフサイクル体系を要する；ランタイム監視は、AI ワークロードを隔離し、観察し、必要なときにはそれから制御を引き継げる決定論的な基盤を要する。

[推論] ゆえに、L3 以上の責任を担ったことのない「車両 OS」は、その車両全体としての性格をまだ試されていない。 それはコックピット、ボディ、エネルギーで優れているかもしれないが、安全クリティカルな実行チェーンが同じコントロールプレーンに取り込まれ、fail-operational のテストにかけられたときにのみ、「車両」という言葉が真に当てはまる。

6.3 OS の新しい仕事：「資源の管理」から「隔離の証明」へ

伝統的なオペレーティングシステムの中核の仕事は資源の管理である：CPU、メモリ、I/O の割り当て。混合クリティカリティの自動車用演算プラットフォームでは、この仕事は質的に変わる——OS は、異なるクリティカリティのワークロードが互いに干渉しないことを証明しなければならない。

2026年、これはすでに量産上の現実である：

• Qualcomm は Snapdragon Ride Flex を「業界初の商用化された混合クリティカリティプラットフォーム」と呼び、QM、ASIL B、ASIL D のワークロードを単一の SoC 上で動かし、世界8プログラムで量産中である [T2、企業の主張]。
• NVIDIA Halos OS はハイパーバイザーを用いて安全クリティカルな機能を AI ワークロードから隔離し、安全認証された CUDA と TensorRT を提供する [T2]。

工学的に言えば、「隔離の証明」とは、ハイパーバイザーにおける空間的・時間的・メモリ帯域のパーティショニングと、それらのパーティションについての形式的または認証水準の論証を意味する。NIO が車両制御カーネルに形式検証された seL4 マイクロカーネルを用いていること [T3] は、「証明」を数学にまで押し進める試みである。

6.4 エンドツーエンドモデルが OS に要求するもの

エンドツーエンドの運転モデルと VLA（vision–language–action）モデルの普及は、コントロールプレーンに3種類の新たな圧力をかける：

1. メモリ帯域の競合：大規模モデルの推論は大量の DDR 帯域を消費し、同じチップ上のリアルタイムタスクを圧迫しうる。
2. 遅延のジッター：GPU 推論時間の不確実性は、制御ループの決定論性と本質的に衝突する。
3. アクセラレーターのプリエンプション：運転モデルとコックピットの大規模モデルがアクセラレーターを共有するとき、誰が優先するのか？

NVIDIA の Halos SDK は「決定論的スケジューリング、ゼロコピーのプロセス間通信」を明示的に売りにしている [T2]——これらの問題が研究テーマから製品要件へ移ったことの表れである。

6.5 コックピット–運転統合：隔離はオプションから前提条件へ変わる

コックピットと運転の機能が同じチップまたは同じ中央コンピューターに置かれると、それらは同じハードウェア故障ドメインに入る。分散アーキテクチャでは、コックピットのクラッシュがブレーキに影響することはありえない。両者は物理的に分かれているからである；統合アーキテクチャではその「自然な隔離」が消え、コントロールプレーンによってソフトウェアで再構築されねばならない。

[推論] コックピット–運転統合は、隔離を「任意の最適化」から「安全の前提条件」へと変える。 だからこそ混合クリティカリティ統合（V3）は VOCM において独立した次元なのである。

6.6 ロボタクシー：二重チャネル構造

L4 ドライバーレスフリートにおいて、[推論：Waymo、Baidu Apollo、Pony.ai、WeRide などによる、自社ソフトウェアスタックの実装方法についての公開開示は限られている] 一般的な構造は「AI メインスタック＋独立した安全モニターと冗長演算」である——メインスタックが運転し、第2のチャネルがそれを継続的に監督し、異常時には車両を最小リスク状態へ導く。この二重チャネル構造はソフトウェアで表現された fail-operational コントラクトであり、コントロールプレーンのオーケストレーション責務の最も極端な形である。

---

7. 門前の水平プラットフォーム：Google、チップメーカー、そしてインターフェースをめぐる争い

7.1 新しい戦場

スマートフォンの時代、Apple と Google がオペレーティングシステムを呑み込み、端末メーカーはハードウェアとブランドへ退いた。過去10年、自動車産業の合意はこうだった：自動車メーカーは車でそれが起きることを決して許さない。

2026年、その合意は初めて実質的な挑戦に直面している。

T6 | 業界が実際に標準化しているのは「1つの自動車 OS」ではなく、車両 API、データモデル、ランタイムコントラクトである。カーネルはコモディティ化しつつあり、制御点 C3（OS）は C2（シリコン）と C4（ミドルウェア）の両側から締めつけられている。

7.2 Google：Android がコックピットから歩み出る

2026年3月24日、Google は Android Developers Blog で Android Automotive OS の SDV 拡張（AAOS SDV）を、Beyond Infotainment という率直な題で公表した [T2]。検証済みの事実：

• 形態：「軽量で高速起動のヘッドレス Android 基盤（SDV Core、Microdroid に類似）」で、VirtIO 対応のハイパーバイザー上で仮想マシンとして動く；サービスインターフェースは Google の VSIDL と protobuf で定義され、SOME/IP、VirtIO ソケット、Ethernet などを通じて外部 ECU に接続する；SDV Gateway はコックピット側に置かれる [T1：source.android.com、ドキュメント最終更新 2026-09-24、Android 17 以降向け]。
• カバーするドメイン：Google は「Core Compute、Body Controls、Cluster の各ドメイン」を挙げ、機能例としてシートアクチュエーター、インストルメントクラスター、空調制御、照明、カメラ、ミラー、テレメトリーを含める [T2]。公式資料はシャシーにも ADAS にも言及していない。
• 安全の境界：ドキュメントもブログもいかなる ASIL の主張もしていない。安全に関連する唯一の内容は Display Safety（速度やテルテールなどのクラスター表示）と、安全設計ツールチェーンおよびリファレンスの Safety Monitor である [T1–T2]。
• 採用者：Qualcomm は CES 2026 で Snapdragon Digital Chassis 上の事前統合済み AAOS SDV スタックを発表した；最初の量産プログラムは Renault の小型商用車で、2026年末に量産予定である [T2]。Google は AAOS SDV が2026年中に AOSP に入ると述べる。

[推論] これらの事実は明確な境界線を引く：水平プラットフォームはコックピットを越えてボディ快適性とクラスターのドメインに入ったが、なお QM から低 ASIL の領域にとどまり、シャシー、ブレーキ、ステアリング、自動運転の安全クリティカルな実行チェーンにはまだ触れていない。 この線が下へ動き続けるかどうかは、今後5年間に注視すべき最も重要な産業シグナルの1つである（第10章、改訂トリガー4）。

7.3 チップメーカー：C2 が C3 を吸収する

Google が上から押し下げるなら、チップメーカーは下から包み込む。

• NVIDIA：DriveOS（ASIL D 認証）＋Halos OS（AI ワークロードを安全機能から隔離するハイパーバイザー）＋Halos SDK（決定論的スケジューリング、ゼロコピー IPC）[T2]。GM の2028年の中央演算プラットフォームは NVIDIA Thor に基づく [T1]。
• Qualcomm：Ride Flex 混合クリティカリティプラットフォーム＋事前統合済み AAOS SDV スタック [T2]。

[推論] チップメーカーが届けるものはもはやチップではなく、「チップ＋ハイパーバイザー＋安全認証済みランタイム＋ミドルウェアの一部」というパッケージである。自動車メーカーにとって、チップを選ぶことはますます、S1 と S2——さらに S3 の一部——を同時に選ぶことを意味する。D1 の7つの制御点の中で、これは C2（SoC）が C3（OS）を吸収することである。

7.4 ミドルウェアと「Vehicle OS ベンダー」：C4 が拡大する

もう1つの力は、ミドルウェアとサードパーティの Vehicle OS ベンダーから来る。

• Applied Intuition は自動車メーカーに Vehicle OS を供給する。2026年5月、Stellantis は STLA Brain に関する同社との協業拡大を発表した [T1]；同社は世界の上位20自動車メーカーのうち18社が自社のソリューションを使っていると述べる [T2、企業の主張]。
• Eclipse S-CORE：2025年6月、11社がオープンソース SDV 協業に関する VDA の覚書に署名した（BMW、Continental、ETAS、HELLA、Mercedes-Benz、Qorix、Bosch、Valeo、Vector、Porsche、ZF）[T1]；2026年1月7日の VDA プレスリリースによれば、署名者は32社に拡大した [T1–T2]。S-CORE 0.5 は2025年11月にリリースされ、リファレンスプラットフォームは QNX と Qualcomm のハードウェア上で初めてデモされた [T2]。

[推論] 欧州の自動車メーカーが S2 にオープンソースの S-CORE を、S1 に QNX を、隔離にチップメーカーのハイパーバイザーを使い、S4 の一部にサードパーティの Vehicle OS を買うとき、それは実際に何をまだ所有しているのか？ 答え：車両のセマンティクス、安全責任、そして統合・検証・データループ運用の能力。

7.5 争いはカーネルではなくインターフェースをめぐるもの

3つの力を合わせると、過小評価された事実が浮かび上がる：すべての当事者が本当に争っている——そして本当に標準化している——のは、インターフェース層である。

[推論] これらの取り組みは合わせて1つの結論を指し示す：標準化へ向かっているのは「1つの自動車 OS」ではなく、「車両 API＋データモデル＋ランタイムコントラクト」である。 それは 2.3 節のコントロールプレーンの3つの部分の1つ目——コントラクト——にぴたりと対応する。

これは価値のありかについての系を生む：

コントラクト層は収束しつつある；オーケストレーションとライフサイクルが、自動車メーカーの差別化に残された空間である。

7.6 水平プラットフォーム 対 OEM コントロールプレーン：終局は何か？

では、産業は水平的な車両 OS に収束するのか、それとも自動車メーカーが車両コントロールプレーンを保持し続けるのか？

[推論] 我々の判断：二者択一ではない。 底部のインフラ（S1、S2、コントラクト層の標準）は収束し続ける；車両のセマンティクス、安全責任の所有、ブランドの差別化（オーケストレーション、ライフサイクル、データループ）は発散し続ける。これは D1 の2層収束–発散モデルのソフトウェア層における2度目の再出現である。

4種類の自動車メーカーが4つの異なる終局に至るだろう：

1. 垂直統合者（Tesla、Huawei、NIO）：C2、C3、C4 をまとめて所有する；コントロールプレーンは完全に自前である。彼らは T6 に対する最強の反例である——彼らにとって OS はコモディティ化されるものではなく、堀の一部である。
2. 連邦型コントロールプレーン：地域別、さらにはパートナー別に構築された複数のコントロールプレーンが、ブランド、サプライチェーン、基盤の一部を共有するが、単一のグローバルなソフトウェアスタックは追求しない。今日、Volkswagen Group が最も明確な例である：中国では XPeng と共同構築した CEA、西側では Rivian と共同構築した RV Tech（5.5 の発見4参照）。利点はスピードと現地適合性——量産まで18か月、中国国家標準と現地の運転エコシステムへの直接的な整合。リスクは規模の経済が分断されることである：2つのアーキテクチャは、2つの検証体制、2つの OTA 運用、2つの人材パイプライン、そして長期的な統合コストを意味する。[推論] 車両 OS の終局は「すべてを統べる1つのカーネル」である必要はない；連邦型コントロールプレーンは、中国と西側で分岐する標準に直面する多国籍企業にとって合理的な選択かもしれない——しかし連邦が次世代で1つに収束できるかどうかが、このルートが最終的に「過渡」となるか「負債」となるかを決める。
3. プラットフォーム消費者：S4 においてさえサードパーティのソリューション（Applied Intuition、Google、チップメーカーのパッケージ）を買い、差別化をブランド、デザイン、チャネルに集中させる。
4. コントロールプレーン輸出者：自社の車両コントロールプレーンを——E/E トポロジーと開発手法とともに——製品として他の自動車メーカーへ輸出する。これは2025–2026年に現れた最も新しい形態であり、その主役はほぼすべて中国の自動車メーカーである：
   • XPeng は Volkswagen と CEA を共同構築した（5.5）；
   • 2026年のテックデーで、Leapmotor は自社の電子システムがいまや5社のパートナーと協業しており、FAW、Stellantis などに車両レベルの技術支援を提供していると述べた [T3]；
   • Huawei の HarmonyOS コックピットと Qiankun は25ブランドをカバーする [T2]。

[推論] 4つ目の形態は T6 が描く構図を変える。制御点 C3 は、チップメーカー（C2）とミドルウェア / 水平プラットフォーム（C4）によって上下から締めつけられるだけではない；それは別の種類の自動車メーカーによって横からも争われている。輸入者にとって、コントロールプレーンを取り込むことは自ら構築するよりはるかに速い：CEA はコンセプトから量産まで18か月だった。輸出者にとって、コントロールプレーンは第2の収益曲線となり、規模の増幅器となる——Leapmotor が主張する90%のプラットフォーム共通化率は、まさにコントロールプレーンを輸出のために複製可能にするものである [T3、企業の主張]。Stellantis が Applied Intuition（サードパーティの Vehicle OS）と Leapmotor（車両レベル技術）の両方と協業していることは、1つの自動車メーカーが異なる市場と車種において、「プラットフォーム消費者」と「コントロールプレーン輸入者」を同時に兼ねうることを示している。

4つの形態のいずれも優劣はない；それぞれが、制御点がどこにあるべきかについての異なる賭けである。

---

8. AI がオペレーティングシステムに入るとき：砂時計と決定論的ガバナンス

8.1 車に大規模モデルを載せることは、AI が OS に入ることではない

「AI と車両 OS」について最もよく見られ——そして最も浅い——議論は、どの大規模モデルが車に載るかについてのものである：Gemini、GPT、DeepSeek、Pangu、Grok。それはアプリケーションとしての AI である。本当の変化はより深いところで起こり、3つの段階を経る。

段階 B には、見落とされやすいが影響の大きい系が伴う：モデルが第一級のソフトウェア成果物になる。 今日、OTA 更新は「ソフトウェアパッケージ v3.7」を届ける；明日は「ソフトウェア＋モデル＋ポリシー＋エージェントグラフ＋安全エンベロープ」の束を届けるだろう。ライフサイクル管理の対象は、コードから確率的な成果物へと拡大する。

産業はすでに段階 B へ向かっている：

• Mercedes の MBUX Virtual Assistant は Microsoft と Google の両方の AI を統合し、Gemini 上に自動車用 AI エージェントを構築している [T2]。
• Hyundai の Gleo AI エージェントは Pleos Connect とともに到来する；Hyundai はこの転換を SDV から「AIDV」（AI 定義車両）への移行と位置づける [T2]。
• NIO は SkyOS を「AI のための全ドメイン車両オペレーティングシステム」と呼ぶ [T2]。
• 2026年のテックデーで、Leapmotor は「車両–クラウド AgentOS」を発表した：車両上のコアエージェントが低遅延でプライバシーに敏感なタスクを扱い；クラウドのエージェントが複雑な推論と長期記憶を扱う [T3]。[推論] これは「信頼と遅延によってインテリジェンスを分割する」設計であり——コントロールプレーンの外環（クラウド、OTA、データループ）にきれいに対応する：エージェントそのものが「車内の決定論的な部分」と「クラウドの拡張部分」に分けられている。
• 2025年10月、中国の自動車基盤ソフトウェアのエコシステム委員会（AUTOSEMO）は『中国自動車基盤ソフトウェア発展報告 6.0』を公表し、AIOS に焦点を当て、「演算の抽象化——データの融合——機能のサービス化」というアーキテクチャを提案した [T2]。

8.2 OS は薄くなるのか、厚くなるのか？

AI はオペレーティングシステムを吸収するのか？ どちらの見方にも一理ある。

薄くなる側： インタラクション、アプリケーションのオーケストレーション、機能ロジックは、大規模モデルとエージェントに吸収されつつある。かつてハードコードせねばならなかった HMI フロー、メニュー階層、ルールエンジンは、意図を理解するモデルに置き換えられつつある。エンドツーエンドの運転モデルもまた、かつて知覚・予測・計画の別々のモジュールに分かれていたミドルウェアを吸収した。この見方では、OS の上半分は薄くなりつつある。

厚くなる側： モデルが不確実であればあるほど、決定論的な骨格を必要とする。資源の隔離、時間的決定論性、安全監視、証明可能なフォールバック経路、そして ISO/PAS 8800 が要求する AI ライフサイクルの証拠連鎖は、すべて OS 層へ沈み込まねばならない。NVIDIA は「安全クリティカルな機能を AI ワークロードから隔離するハイパーバイザー」を Halos OS の中核的な売りにしている [T2]。この見方では、OS の下半分は厚くなりつつある。

我々の答え：両方が同時に起きている。

T5 | AI は車両 OS を消し去らない；それを両極化させる：上半分（インタラクション、オーケストレーション）は薄くなり、下半分（決定論性、隔離、証明）は厚くなり、その間のサービスコントラクトがナローウエストとなる。確率的インテリジェンスは決定論的ガバナンスの内側で動かねばならない。

図 8.1 — 砂時計：AI は車両 OS をどう作り変えるか。広い上部：モデルに吸収されるインタラクション、オーケストレーション、機能ロジック。狭いくびれ：コントロールプレーンのサービスコントラクト。広い底部：厚みを増す決定論的層（隔離、スケジューリング、安全監視、フォールバック、証拠連鎖）。右側はソフトウェア成果物の進化を示す：「コード」→「コード＋モデル＋ポリシー＋エージェントグラフ＋安全エンベロープ」。

これは「AI は言語能力であって脳ではない」という D3 の判断と完全に整合する：言語能力はモデルへと上がっていく；安全の「脳幹」——決定論的な骨格——は OS にとどまる。両者は矛盾しない；同じものの2つの面である。

8.3 反証可能な予測

「両極化」は「どちらの側も正しい」という逃げ口上として批判されやすい。それを避けるため、事実によって覆されうる明確な予測を示す：

[推論] 2030年より前に、大規模言語モデルまたは汎用エージェントが ASIL D アクチュエーターの制御権を直接獲得する量産乗用車は現れない。 エージェントは提案し、要求し、許可された車両サービスを呼び出すことはできるが、ブレーキやステアリングのような安全クリティカルなアクチュエーターに対する最終的な制御は、なお決定論的なコントロールプレーンによって裁定される。

この予測が覆されれば、T5 は改訂されねばならない（第10章、改訂トリガー3）。

8.4 標準と規制：OS における AI への制約はすでに形をなした

AI が車両 OS に入るかどうかは、技術だけでは決まらない。それを制約するルール体系はすでに形をなしている：

• ISO 26262（機能安全）と ISO 21448（SOTIF、意図した機能の安全性）[T1]。
• ISO/PAS 8800:2024（Road vehicles — Safety and artificial intelligence）。2024年12月に公表され、ISO 26262 の Part 4、6、8 の関連条項を調整している [T1]。2025年8月、SGS-TÜV Saar は Geely に世界初の ISO/PAS 8800 プロセス認証を授与した [T2]。
• UN R155 / R156（サイバーセキュリティ管理システム / ソフトウェア更新管理システム）、および中国の対応する強制標準 GB 44495 / 44496 / 44497、2026年1月1日施行 [T1]。

[推論] これらの標準の複合的な効果：AI が増えるほど、ライフサイクル管理は重くなる。 モデルの更新のたびに safety case の更新が必要になるかもしれない；車両アクションの権限を与えられたエージェントはどれも、監査可能な権限モデルを必要とする。これらの負担はモデル自身には担えない；担えるのはコントロールプレーンだけである。

1つの問いが未回答のまま残る：AI が生成した OS のコードは、どのように ISO 26262 の安全論証に入るのか？ D4 はすでに、アーキテクチャツールチェーンにおいて「AI 生成」の能力が「推論の自律性」から分離していることを示した。車両 OS の水準では、本稿のデータ基準日の時点で、AI 生成コードが ASIL の論証に入った公開の量産事例を我々は見つけていない。注視に値する空隙である。

---

9. ロードマップ 2026–2035：ソフトウェア定義から AI 定義へ

9.1 5つの段階

この表は観察された状態と研究上の仮説を区別する。最初の3段階は観察されたもの；最後の2段階は仮説である。

注： 段階 V は、本シリーズの8段階 EEA 進化分類における L8「AI-Defined Vehicle」と名称を共有するが、両者は異なる対象を記述する：8段階分類は車両の EEA の形態を記述する；この表はソフトウェアのコントロールプレーンの形態を記述する。2つの次元は直交しており、混同してはならない。

9.2 段階 III、IV、V を実際に分けるもの

最後の3段階は最も混同されやすい。一文で言えば：段階 III は機能をソフトウェアに変え、段階 IV はソフトウェアをスケジューリング可能な資源に変え、段階 V はモデルに何がスケジューリングされるかの決定に参加させる。

データセンターの進化はうってつけの類比を提供する：

• 段階 III は仮想マシンの時代に似ている：サーバーは仮想化されているが、各 VM が何を動かし、どこに置かれるかは、運用によって事前に設定される。
• 段階 IV は Kubernetes の時代に似ている：ワークロードは標準単位にパッケージされ、スケジューラーによってルールに従って資源プールに配置される；マイグレーション、スケール、置き換えが可能である。
• 段階 V は AI ネイティブの時代に似ている：スケジューラーの上に意図を理解するモデルの層があり、システムは誰も事前に書かなかったフローをその場で組み立てることができる。

段階 IV の6つの特徴は、それぞれ具体的な形をとる：

1. 動的な機能配置。 主演算ユニットが故障すると、オーケストレーターは安全クリティカルでない機能をバックアップユニットへマイグレーションする；あるいは同じ機能が車両構成に応じて異なるノードにデプロイされる。
   • 1つの限界を強調しておかねばならない：ASIL D の機能は、予見可能な将来において「動的に」スケジューリングされることはない。そのマイグレーション経路は、事前に設計され認証された冗長切り替えである。真に動的なのは主に QM と低 ASIL のワークロードである。
2. 共有演算。 車が駐車しているとき、運転チップの演算の大半は遊休状態にある。段階 IV のプラットフォームはそれをコックピットの大規模モデル、セントリーモードでの映像解析、車載データの前処理に貸し出し、車が動き出せば優先度に従って取り戻すことができる。段階 III ではこれができない。コックピットと運転は2つのドメインに属し、2つのソフトウェアスタックを持つからである。
3. ドメイン横断サービス。 段階 III では、「キャンプモード」は専用に作られた機能であり、HVAC、ディスプレイ、バッテリー管理、ドアロックのコードの変更を要する。段階 IV では、それは既存のサービスの組み合わせにすぎない。中国の自動車メーカーの「シーンオーケストレーション」機能はすでにこの方向へ向かっているが、大半はなおコックピット水準にとどまり、車両制御の深部には達していない [推論]。
4. クラウド–車両の開発パリティ。 同じソフトウェアコンテナが、実車にデプロイされる前にクラウドの仮想車両で回帰試験を終える。Google の AAOS SDV ドキュメントは、仮想マシンで動かすことが「クラウドでの試験と統合を容易にする」と明記している [T1]。
5. 常態としての混合クリティカリティ統合。 今日、Ride Flex は8つの量産プログラムで ASIL D と QM のワークロードにチップを共有させている [T2]——なお「第一波」である；段階 IV では、それはセールスポイントではなく新しいプラットフォームのデフォルト構成となる。
6. 標準化されたモデルのライフサイクル。 運転モデルのバージョン管理、検証、ロールバックは、各社独自のツールから、ISO/PAS 8800 と R156 に制約されるソフトウェアと同じパイプラインへ移る。Leapmotor の「1つのモデルを3つの演算階層にまたがって展開する」[T3] は、ハードウェア階層によってデプロイを決定する初期の例である。

段階 IV と V の境界は、誰がルールを書くかにある。 段階 IV のオーケストレーターがどれほど賢くても、それはエンジニアが書いたルールを実行する。段階 V では、モデルとエージェントが決定に参加し始める。比べてみよう：

• 段階 IV：ユーザーが「キャンプモードをオンにして」と言い、システムは事前に構築されたサービスの組み合わせを実行する。
• 段階 V：ユーザーが「今夜は山で過ごして、明朝は街まで運転して戻る必要がある」と言う。エージェントは残量を帰路の距離と照合し、HVAC が使えるエネルギー量を算出し、バッテリーの予備下限を設定し、画面を暗くし、明日のルート沿いの充電ステーションを見つける。この組み合わせをどのエンジニアも書いたことはない；それは権限モデルと安全エンベロープの範囲内でその場で生成される。

Leapmotor の AgentOS、Hyundai の Gleo AI、Mercedes の Gemini ベースのエージェントは、いずれも第8章で述べた「AI が OS のサービスになる」段階にまだある：それらは意図を理解するが、呼び出せる車両サービスの範囲とその権限は、なお限られている。

産業が段階 IV に入ったことを、我々はどう知るのか？ 4つの観察可能なシグナルを見よ：

1. 新たなソフトウェアリリースなしに演算ユニット間でマイグレーションする機能を持つ量産車；
2. クラウドで検証された同じソフトウェアコンテナが、複数のハードウェア階層にまたがってデプロイされること；
3. デフォルトで ASIL D と QM のワークロードに SoC を共有させる新しいプラットフォーム；
4. モデルの更新が、ロールバックを伴う統一的で規制されたパイプラインに入ること。

段階 V のシグナルは、権限モデルを通じて車両サービスを呼び出すエージェントを持つ量産車と、事前にコード化されたのではなくユーザーの意図から生成された機能の組み合わせである。

[推論] 3つの段階の境界はぼやけている；同じ自動車メーカーがしばしば2つの段階にまたがる。この表が記述するのは重心の移動であって、きれいな切れ目ではない。

9.3 制御点の移動

[推論] 現在から2030年までの間に、D1 の7つの制御点のうちここに関係する3つは次のように変化するだろう：

• C2（SoC）：上方への吸収を続け、「チップ＋ハイパーバイザー＋認証済みランタイム＋ミドルウェアの一部」のフルスタックを届ける。
• C3（OS）：カーネルと基盤ランタイムはコモディティ化する；独立した価値はコントロールプレーンのオーケストレーションとライフサイクルへ移る。
• C4（ミドルウェア）：オープンソース（S-CORE、HaloOS）と標準（VSS、中国国家標準）が収束を加速する；コントラクト層は次第に共有財（コモンズ）となる。

図 9.1 — C3 への圧迫：車両 OS の価値はどこへ移るか。読み方：C3 は上下からの力に締めつけられる；自動車メーカー自身のものとして残るのは、オーケストレーション、ライフサイクル、そしてデータループ（C5）である。

9.4 中国のルート：自社開発、オープンソース、国家標準の並進

中国の車両 OS の進化は特徴的な構造を持つ：自社開発、オープンソース、国家標準が並行して進み、互いに補強し合う。

• 自社開発：NIO SkyOS、Huawei の HarmonyOS コックピットと Qiankun、XPeng、Xiaomi などが独自のソフトウェアスタックを構築している [T2]。
• オープンソース：Li Auto は HaloOS を Apache 2.0 でオープンソース化し（2025年）、自社の成果を産業の共有財へと変えた [T2]。
• 国家標準：GB/T 47351 / 47341-2026 は2026年7月1日に施行された；3つの強制標準 GB 44495 / 44496 / 44497 は2026年1月1日に施行され、UN R155 / R156 と調和している [T1]。

[推論] 国家標準の重要な帰結の1つ：それは中国で販売するすべての自動車メーカー——外資系自動車メーカーを含む——が整合せねばならないインターフェースとなる。 起草組織の中に Mercedes-Benz 中国と Volkswagen 中国が名を連ねていることは、外資系自動車メーカーがこれを認識していることを示す。それはまた、「連邦型コントロールプレーン」が世界的に現れつつある構造的理由の1つかもしれない：同じ自動車メーカーが、中国とそれ以外の地域で異なるインターフェース体制に向き合うソフトウェアスタックを維持する必要があるかもしれないのである。

9.5 経済と組織：本当のボトルネック

経済的には、車両 OS は4つの形で元が取れる：ECU と配線の部品コストの低減、車種をまたぐソフトウェアの再利用、プラットフォームコストの償却、そして車が売られた後のソフトウェア収益。Rivian のソフトウェア・サービスの売上総利益が FY2025 に700万ドルから5億7600万ドルへ跳ね上がったこと [T1] は、資産としての「E/E＋OS」の価値がすでに財務諸表に現れうることを示している。

組織的には、そのコストはしばしば過小評価される。5.1 節では、ロードマップ階層（M4）のほぼすべての自動車メーカーが遅延していることを指摘した。[推論] 原因が技術であることは稀で、たいていは組織である：

• 数十の機能別部門を1つのプラットフォーム組織に変えること；
• Tier 1 との契約を「ブラックボックス ECU」単位から「ソフトウェアモジュール＋統合責任」単位へ変えること；
• 現行車種の出荷を続けながら次世代プラットフォームを構築すること。

これは車両 OS に適用されたコンウェイの法則である：あなたのコントロールプレーンは、あなたの組織に似る。 なお「ボディ、シャシー、パワートレイン、コックピット」の部門に分かれている自動車メーカーは、4つのドメインすべてにまたがるコントロールプレーンを構築するのに苦労するだろう。

本章を一文でまとめれば：

集中化は、システムの複雑性を生み出すことによって局所の複雑性を取り除く。 それは100個の ECU の間の分断を解消するが、より大きな影響範囲（ブラスト半径）、より集中した攻撃面、より複雑な検証——そして車を再編する前に自らを再編せねばならない組織——をもたらす。

---

10. 自らの喉元に刃を当てる：反論と改訂トリガー

10.1 7つの反論

反論1：車両 OS は単なるマーケティング概念である。 ブランドの層を剥ぎ取れば、残るのは QNX＋Linux＋AUTOSAR＋ハイパーバイザーである。 応答： これはまさに T1 の出発点である。我々は車両 OS が新しいカーネルだと主張しているのではない；それが複数のカーネルを統治するコントロールプレーンだと主張している。ブランドは確かに誇張されているが、その3つの部分——コントラクト、オーケストレーション、ライフサイクル——は実在し、観察可能で、採点可能である。

反論2：中央演算は元が取れないかもしれない。 仮想化、冗長、液冷のオーバーヘッドが、ECU 削減による節約を相殺するかもしれない。 応答： ここでは結論を下さない。経済性は車両の台数とソフトウェア収益に依存し、公開データは判断に不十分である。我々は「集中化は局所の複雑性をシステムの複雑性と引き換える」ことを指摘するにとどめる——その取引が引き合うかどうかは自動車メーカー次第である。

反論3：車両 OS はむしろシステム的リスクを高める。 応答： 同意する。これはまさに第6章の論点である：集中化は隔離を自然な性質から、証明されねばならない性質へと変える。リスクが制御されるかどうかは、V3（混合クリティカリティ）がどれだけうまく行われるかにかかっている。

反論4：標準化された API は自動車メーカーの差別化を消し去る。 応答： コントラクト層での差別化は確かに縮小する（T6）が、オーケストレーション、ライフサイクル、データループは差別化の空間として残る。差別化は消えない；移動するのである。

反論5：AI エージェントは決して安全クリティカルな制御経路に入るべきではない。 応答： 我々の立場はより具体的である：エージェントはコントロールプレーンに入ってよいが、決定論的ガバナンスの下でのみである；ASIL D アクチュエーターに対する最終的な制御は、予見可能な将来においてエージェントに委ねられない（8.3 の予測）。

反論6：地域化されたソフトウェアスタックはグローバルな車両 OS を妨げる。 応答： 同意する——そしてこれは問題ではなく終局なのかもしれない。7.6 で論じた「連邦型コントロールプレーン」はまさにこの判断を展開したものである。

反論7：L4 は最終的に車両 OS の一部ではなく、独自の OS を必要とする。 応答： これは未解決の問いである。二重チャネル構造（6.6）は、L4 の安全監視チャネルが論理的に車両コントロールプレーンから独立していることを意味するかもしれない。L4 フリートが乗用車の車両 OS とは完全に分離されたソフトウェアスタックを広く採用するなら、T4 は「自動運転は車両 OS と安全チャネルの間のコントラクトを試す」と言い直されるべきである。

10.2 5つの改訂トリガー

以下のいずれかが起これば、対応するテーゼは改訂されねばならない：

---

11. 結論：3つの判断と1つの警告

題名に戻ろう。「OS のシステム」は比喩ではない——それはすべてのソフトウェア定義車におけるあの層の、最も正確な記述である。それはあまりに多くの「OS」の名で呼ばれてきたため、それが実際に何であるかを立ち止まって問う者がいなかった。

我々の答え：それはコントラクト、オーケストレーション、ライフサイクルからなるコントロールプレーンであり、一群のオペレーティングシステムを統治する——いずれか1つのオペレーティングシステムそのものではない。

判断1：車両 OS は OS のシステムであり、その境界は E/E アーキテクチャによって引かれる。 OS と呼ばれるものが車両 OS であるとは限らず、そう呼ばれないものがそうであることもある。テストはブランド名ではなく、コントラクトがどのドメインを覆うか、オーケストレーションが隔離を証明できるか、ライフサイクルがどの層を更新できるかである。この3つがどこまで行けるかは、まず E/E アーキテクチャがどの世代に達したかに依存する。

判断2：本当の分水嶺は因果の逆転である。 自動車メーカーがソフトウェア定義の時代に入ったことの印は、OS ブランドを持つかどうかではなく、共進化ループの下半分が回り始めたかどうか——次の E/E 仕様が現世代のソフトウェアの必要によって定義されているか——である。GM の「10倍 / 1000倍 / 35倍」、ゾーンコントローラーをどこまで脱知能化するかをめぐる BMW と GM の分岐、そして Rivian が「E/E＋OS」を一体として売っていることは、いずれもループが回り始めた兆しである。

判断3：AI はオペレーティングシステムの重要性を下げるのではなく、高める。 AI は OS の上半分を吸収するが、その下半分をより厚くする。確率が増えるほど、決定論性は貴重になる。自動運転はそのストレステストである：コックピットは OS がアプリケーションを動かせるかを試すにすぎないが、ドライバーのいない車は車両 OS が車両を動かせるかを試す。

1つの警告：「OS を持つこと」をゴールと見なすな。 カーネルはコモディティ化し、コントラクトは標準化し、チップメーカーと水平プラットフォームが両端から締めつけている。大半の自動車メーカーにとって本当の問いは「自前の OS を構築すべきか？」ではなく、「コントロールプレーンのどの部分で、我々は最終決定権を持たねばならないか？」である。オーケストレーション、ライフサイクル、データループ、そして安全責任の最終的な所有——これらこそが、標準化の波の後にもなお自動車メーカーに属するものである。

車両 OS をめぐる争いは、1つのシステムが勝つことでは終わらない。それはより素朴な問いで終わるだろう：車のあらゆる層が買えるようになったとき、買えない層はどれなのか？ 本稿は座標系を机上に置いた；どこに賭けるかは、常に読者自身の決定であった。

---

付録 A | 証拠の等級と主要な出典

A.1 証拠の等級

注： すべての将来の日付（GM 2028、STLA One 2027、Hyundai 2030 など）は企業の計画または目標であって事実ではなく、遅延の前例がある。

A.2 主要な出典（トピック別、抜粋）

• QNX の搭載基盤：BlackBerry FY2026 10-K — https://www.sec.gov/Archives/edgar/data/1070235/000107023526000039/bbry-20260228.htm
• MB.OS の量産開始：Mercedes-Benz Group、Rastatt での CLA 量産開始 — https://group.mercedes-benz.com/company/production/production-network/start-of-production-cla-rastatt.html
• NIO SkyOS：NIO 公式（フルスタック技術：全ドメイン車両 OS）— https://www.nio.cn/smart-technology/20251215002 ; IT Home — https://www.ithome.com/0/720/560.htm
• Li Auto HaloOS のオープンソース化：TechNode — https://cn.technode.com/post/2025-03-29/lixiang-xinghuan-os/
• 中国国家標準：全国標準情報公共サービスプラットフォーム — https://std.samr.gov.cn/gb/search/gbDetailed?id=0BBF0FBBBE1AE46FE06397BE0A0AD1FD ; https://std.samr.gov.cn/gb/search/gbDetailed?id=D33BADAFBDDF2CD0E05397BE0A0A113C
• GB/T 47341-2026 の商用翻訳（T3）— https://www.chinaautoregs.com/archives/7587
• GM の中央演算プラットフォーム：GM プレスリリース、2025-10-22 — https://news.gm.com/home.detail.html/Pages/news/us/en/2025/oct/1022-SDV-GM-centralized-vehicle-computer-platform-electric-gas-vehicles.html
• BMW Neue Klasse のスーパーブレイン：https://www.bmwgroup.com/en/news/general/2025/superbrains.html
• Toyota Arene / RAV4：https://pressroom.toyota.com/three-two-one-toyota-debuts-amazing-all-new-rav4/ ; https://insideevs.com/news/775729/2026-toyota-rav4-phev-arene-software-ev/
• Toyota Arene（2023年の表現）：Toyota プレスリリース、2023-04-11 — https://global.toyota/en/newsroom/corporate/39070846.html
• Hyundai Pleos：https://www.hyundainews.com/releases/4774 ; S&P Global Mobility — https://www.mobilityglobal.com/en-us/automotive-insights/blog/hyundai-pleos-software-launch-shifts-mobility-game
• Rivian / RV Tech：Rivian FY2025 8-K — https://www.sec.gov/Archives/edgar/data/1874178/000187417826000007/ex-991pressrelease4q25earn.htm ; DEF 14A — https://www.sec.gov/Archives/edgar/data/0001874178/000187417826000023/rivn-20260427.htm
• RV Tech の進捗：Volkswagen Group プレスリリース、2025-11-12 — https://www.volkswagen-group.com/en/press-releases/one-year-after-its-founding-joint-venture-between-volkswagen-group-and-rivian-shows-strong-progress-19980 ; 冬季試験 — https://www.electrive.com/2026/03/27/vw-and-rivian-conclude-winter-testing-programme/
• Volkswagen Group CEA：Volkswagen Group プレスリリース、2026-01-28 — https://www.volkswagen-group.com/en/press-releases/volkswagen-group-china-starts-production-of-its-first-locally-developed-zonal-electronic-architecture-20144 ; CarNewsChina — https://carnewschina.com/2026/01/29/volkswagen-starts-production-of-xpeng-co-developed-cea-architecture-five-new-models-due-in-2026/ ; CarNewsChina、2025-12-10 — https://carnewschina.com/2025/12/10/volkswagen-and-xpengs-first-joint-vehicle-id-unyx-07-nears-production-after-just-18-month-chinese-led-development/ ; IT Home — https://www.ithome.com/0/903/897.htm
• CARIAD の再編（T3）：https://allthingstalent.org/volkswagen-to-cut-1600-jobs-at-cariad-software-division-in-major-restructuring-move/2025/03/13/
• Leapmotor LEAP 5.0：Stellantis Media（Leapmotor Tech Day 2026、2026-09-30）— https://www.media.stellantis.com/uk-en/leapmotor/press/leapmotor-unveils-next-generation-vehicle-architecture-battery-technology-at-tech-day-2026 ; Gasgoo — https://autonews.gasgoo.com/articles/ev/leapmotor-counters-tech-peak-theory-with-one-architecture-and-three-systems-2101156419729817601 ; Sina Auto、2026-09-16 — https://auto.sina.cn/news/2026-09-16/detail-inirzwqt4627345.d.html
• Qualcomm Ride Flex：TechInsights — https://www.techinsights.com/blog/qualcomm-integrates-cockpit-adas
• NVIDIA Halos：https://www.nvidia.com/en-us/ai-trust-center/halos/autonomous-vehicles/
• Google AAOS SDV：Android Developers Blog、2026-03-24 — https://android-developers.googleblog.com/2026/03/Beyond-Infotainment-Extending-Android-Automotive-OS-for-Software-defined-Vehicles.html ; AAOS SDV システムアーキテクチャ — https://source.android.com/docs/automotive/sdv/sdv-system-architecture
• Stellantis × Applied Intuition：https://www.stellantis.com/en/news/press-releases/2026/may/stellantis-and-applied-intuition-expand-collaboration-with-stla-brain-to-advance-vehicle-software-and-enhance-customer-experience
• VDA / Eclipse S-CORE：https://blogs.eclipse.org/post/sara-gallian/eclipse-sdv-2025-all-roads-lead-open-source ; https://www.adt.media/software-defined-vehicles/vda-and-eclipse-foundation-expand-sdv-software-ecosystem/2587652
• SOAFEE：https://www.globenewswire.com/news-release/2026/04/22/3279060/0/en/here-joins-soafee-to-bring-expertise-in-ai-powered-mapmaking-into-open-software-defined-vehicle-platforms.html ; Open AD Kit — https://autoware.org/open-ad-kit-the-first-soafee-blueprint-powering-open-collaboration-in-autonomous-driving/
• Eclipse Open Vehicle API：https://projects.eclipse.org/projects/automotive.openvehicle-api/reviews/eclipse-open-vehicle-api-2026.08-progress-review
• AUTOSAR Adaptive と POSIX：UL Solutions — https://www.ul.com/sis/blog/autosar-part-2-adaptive-platform
• UN R156（7.1.1 項の本文）：EUR-Lex — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:42021X0388
• ISO/PAS 8800：UL — https://www.ul.com/sis/blog/safety-related-systems-road-vehicles-artificial-intelligence-are-addressed-isopas-88002024 ; Geely の認証（SGS）— https://www.sgs.com/en-hk/news/2025/08/geely-auto-awarded-first-global-ai-safety-certification-for-road-vehicles
• Huawei HarmonyOS コックピット / Qiankun の搭載基盤：https://news.qq.com/rain/a/20260908A0664N00
• AUTOSEMO 報告 6.0：Reach Auto（Neusoft）プレスリリース、2025年10月、AUTOSEMO に代わって報告を公表 — https://www.reachauto.com/en/2025/10/

---

付録 B | VOCM 採点基準

各次元は0–5で採点する。スコアは公開情報のみに基づく；証拠が不十分な次元は2を超えて採点できず、または n.a. と記す。

信頼度： H＝Tier 1–2 の証拠が大半の次元を直接裏づける；M＝一部の次元が企業の主張に依拠する；L＝大半の次元が二次情報または推論に依拠する。

同系譜の例外： すでに採点済みの自動車メーカーと共同開発され、同じアーキテクチャ系譜を受け継ぐプラットフォーム（VW CEA と XPeng など）は、自社の公開情報が乏しい次元について、そのメーカーのスコアを参照してよい。そうした次元はそれぞれ注記で明示しなければならず、信頼度の上限は L とする。

---

付録 C | 略語