技術ロードマップ整理·WAYVE × NISSAN·2025–2027

ソフトウェア融合/ロードマップと課題

クルマを物流コンテナレゴブロックへ。規格化された箱に積み替え、開いた継ぎ手で組み替える ── 日産のSDV基盤に、Wayveの頭脳を載せるまでの道筋と、まだ嵌っていないブロック。

委託・ブラックボックス内製・標準・AI
00  前提 / なぜコンテナとレゴか

分離と規格化、ふたつの動き

SDVの本質は二つの分離に尽きる。ハードの量産サイクル(年単位)からソフトの更新サイクル(週単位)を切り離すこと。そして機能を規格ブロックに割り、誰が作っても噛み合うようにすること。

Container → 積み替え

OS・アプリを箱に詰める

コンテナ単位で機能を封入し、車種・SoC・リージョンをまたいで同じ箱を積み替える。FOTA(丸ごと書換え)から、アプリ単位の更新へ。

Lego → 組み替え

継ぎ手を規格化する

窓・ワイパーから操舵まで Vehicle API で抽象化し、SDKから触れる規格の凸凹に。JASPARで他社とも継ぎ手を共通化し、3rdパーティが嵌め込める。

01  ロードマップ / 四つの局面

基盤づくりから AI-DV まで

公開情報から再構成した時間軸。順序そのものが意味を持つ ── 下の層(クラウドCI・OS内製)が固まらないと、上の層(AIドライブ)は載らない。

0
2025 — NOW
基盤の公開

クラウドと汎化能力、それぞれの証明

  • Nissan Scalable Open Software PlatformをAWS re:Invent 2025で共同発表。SDK / Data / OS の三層構成。
  • クラウドCIでテスト時間を約75%削減、5,000人超のエンジニアが使う共通開発ポータル、コンテナ技術の量産車適用。
  • Wayve AI-500 Roadshow:6〜12月に500都市・145万km。うち219都市(43%)は現地データ無しのzero-shot走行。
re:Invent 2025AWSGAIA-3 / 15Bzero-shot
1
NEXT
内製化

Tier1依存から、標準OSへ寄せる

  • コックピット(CDC)にAndroid Automotive OSを採用。独自カスタマイズを減らし、System Image を GSI(Google標準)へ寄せてOS更新に追従。
  • HAL / VHAL・フレームワーク層のホワイトボックス化と手の内化。委託型から協業型へ。
  • Vehicle APIで車両制御を抽象化し、SDK経由でアプリから触れるように。
HAL / VHALGSI / vanilla大阪・梅田 拠点
2
AFTER NEXT
開いた基盤

所有権が日産+標準へ移る

  • Product Image まで日産自身が握り、Tier1ロックインから脱却。
  • JASPAR等で他社OEMともAPIを共通化(オープン化)し、3rdパーティが参入できるエコシステムへ。ホンダが日産の基盤を採用(2026)で、この「他社OEM」が具体化。
  • コンテナ単位OTAでアプリを迅速・安全に更新。CTS / VTS / XTS の認証を、クラウドCIとHILSで回す。
JASPARcontainer OTACTS / VTS / XTSHonda 合流
3
FY2027 目標
AI-DV

SDVの先、AI-Defined Vehicle

  • AIドライブ:End-to-End AIによる自動運転を2027年度中の搭載目標(ProPILOT強化、Wayveソフト採用)。
  • AIパートナー:ドライバーの意図を汲むエージェント機能。
  • 開発へのAI活用:Copilot / Cursor / ChatGPT で開発自体を高速化。「作るAI」と「載せるAI」を同じ射程に。
End-to-EndEV / PHEV / HV / ICEembodiment transfer
02  所有権の移動 / 誰がブロックを握るか

スタックの色が移っていく

日産の公開図(Current → Next → After Next)を、所有者で色分けして再構成。塗りが Tier1 から 日産・標準・AOSP へ移り、最上段に Wayve のAIが乗る。

Tier1(委託) 日産(内製) AOSP / 標準 Open API Wayve / AI
Current
独自カスタマイズ依存
AppsTier1
Android F/W独自
HAL / KernelTier1
Product ImageTier1
SoCHW
Next
標準へ寄せる
AppsAOSP
Android F/Wvanilla
HAL / Kernel日産
Product ImageTier1
SoCHW
After Next
内製+オープン
AI DriveWayve
Vehicle APIJASPAR
HAL / Kernel日産
Product Image日産
SoCHW
03  継ぎ手 / どこで噛み合うか

Vehicle API という凸凹

融合点は一箇所。Wayveの世界モデルが、日産の基盤に対して規格化された継ぎ手(API)越しに接続する。ここが開いていれば載り、閉じていれば載らない。

BRAIN

Wayve AI Driver / 世界モデル

カメラ入力から走行を直接出すEnd-to-End。GAIA-3で評価、車種をまたぐembodiment transfer。駆動方式に非依存。

Vehicle API / SDK
PLATFORM

Nissan Scalable Open Software Platform

SDK / Data / OS。Android Automotive、コンテナOTA、全センサーへの開放アクセス。EV・PHEV・HV・ICE 全車に同じ基盤。

テレメトリ / デジタルツイン
CLOUD

AWS / Engineering Cloud

クラウドCIでテスト75%減、5,000人ポータル、車両データの再学習ループ(収集→学習→OTA再配信)。

04  課題 / まだ嵌っていないブロック

残った賭けは二つに絞られた

「思想が正しいか」は、ほぼ決着した。工程表・API・認証・拠点・時間軸まで具体に降りている。残るのは「適用場面」と「中途半端な実装が生む負債」。

観念的 — ほぼ解消

構想ではなく移行プロジェクト。Current→After Next の工程と2027の時間軸が公式に存在。

適用場面 — 主戦場

実装はコックピット系が中心。安全クリティカル系への拡張がこれから。

有害 — トレードオフ

オープン化とコンテナOTAは、裏返せば攻撃面の拡大。安全・セキュリティ負債の管理が条件。

R-1

安全クリティカル系への跳躍

今の実装はコックピット(情報・エンタメ、Android)が中心。窓・ワイパーは Vehicle API で触れても、操舵・制動(ASIL-D)をコンテナ/APIの世界とどう安全に接続するかは別問題。2027年度のAIドライブ搭載は、この跳躍を前提にしている。

2027 AIドライブが、コックピット中心の基盤を安全系まで拡張できているか
R-2

二重の認証の壁

自動車側のR155(サイバーセキュリティ/CSMS)・R156(ソフト更新/SUMS)の型式認証と、Android側のCTS / VTS / XTS 数百万件を同時に通す必要がある。クラウドCIとHILSの検証体制が、この二正面をさばけるかが急所。

新基盤で型式認証とAndroid認証を通した量産実績が出るか
R-3

開放が招くセキュリティ負債

Vehicle APIのオープン化・3rdパーティ参入・コンテナOTAは、利便性と引き換えに攻撃面を広げる。ISO 21434 / R155 のもとで、中途半端な実装が長期の負債にならないか。便利さは常にこのコストと背中合わせ。

オープン化の範囲と、セキュリティ運用(CSMS)の成熟度が釣り合っているか
R-4

Tier1脱却の実行リスク(組織)

技術より組織が律速になりやすい。委託→協業、ホワイトボックス化、内製ソフト人材の確保(大阪拠点)。年単位のハード量産と週単位のソフトリリースを分離する経営へ移れるか。「Open」は思想であって、APIの成熟と全センサー開放が実装されて初めて意味を持つ。

内製比率とリリース頻度が、宣言通りに上がっているか
R-5

zero-shot ≠ driverless

Wayveの500都市・219 zero-shot は安全運転者が同乗した汎化能力の証明であり、無人運転の商用化ではない。完全driverlessにはセンサー追加と検証が要る。GAIA-3が「生成」から「評価・検証」へ軸足を移したのは、この保証の隙間を自ら埋めにいく動き。有望だが未証明の握りは変わらない。

安全運転者なしの運行と、第三者検証可能な安全指標が出るか
05  追記 / ホンダ合流 ―― 「Open」が意味を回収した瞬間

凸凹が規格化されたことで、二社の箱に同じブロックが嵌まる

日産のScalable Open Software Platformを、ホンダが採用する。「Open」は3rdパーティ(Wayve)に開くだけでなく、他のOEM(ホンダ)にも開く設計だった ── その答え合わせが、この一件で完了した。

Signal

過剰に開いていた設計の、正体

SDK / Data / OS を三層で切り出し、Vehicle APIをOEM横断で標準化し、コンテナで機能を規格箱に詰める ── 一社専用にしては「開きすぎ」だった設計。ホンダ採用で、その過剰さの理由が回収された。

Meaning

JASPAR API共通化の、着地点

「他社OEMともAPIを共通化」と抽象的に語られていた将来像に、具体名が入った。凸凹(Vehicle API)が規格化されたことで、日産の箱にもホンダの箱にも、同じブロックが嵌まる。

W-1

Wayveにとって、出口が二社連合の全車種へ倍化

WayveのAI Driverは駆動方式に非依存で、Vehicle API越しに接続する。OSが共通なら、その上に乗るAI Driverも共通になりうる。日産の全パワートレイン(EV/PHEV/HV/ICE)に加えて、ホンダの全パワートレインにも同じAPIで載る可能性が開いた。「Wayveが日産を選んだ理由」の一番目 ── 出口が広い ── が、一社の全車種から二社連合の全車種へ拡大した。

ホンダ側のAI Driver採用が、単なるOS共通化から、AI層まで揃うところまで進むか
W-2

「駆動方式は本質でない」が、業界構造として実装される

ホンダと日産は主力パワートレインの構成が違う ── ホンダはパラレルHVのe:HEVが強く、日産はシリーズのe-POWER。それでも同じOSで共通化するということは、OS層が駆動方式の差を吸収する設計になっていることの証明。駆動の差はVehicle APIの下に沈み、上のソフトからは見えない。「駆動方式でメーカーを分ける議論」がSDVの世界では意味を持たなくなる、その転換点。

Vehicle API の抽象化が、実車のECU / センサー配線レベルまで本当に吸収できるか
W-3

プラットフォーム戦略の、教科書的な着地

凸凹(Vehicle API)を作った側(日産)、その凸凹を採用した側(ホンダ)、凸凹に合わせてブロック(AI Driver)を作った側(Wayve)── レゴが機能する三者の役割分担が揃った。日産が単なる「OEM」ではなくプラットフォーマーとして立てるかどうか、という問いに対して、初めての具体的な"顧客OEM"が現れた。R-4(Tier1脱却)の実行リスクも、外部OEMが乗る前提で作った基盤なら、内製化の後戻りが極めて困難になる ── 「引き返せなくなる」意味で、開放が組織の意思決定を縛る効果もある。

ホンダ以外のOEM(三菱、ルノー、その先)が乗るか。一社限定なら「Open」の意味は半分に留まる