自動車メーカーのソフトウェア競争は、すべてを自社で囲い込む形から、基礎部分を共同で作る形へ動き始めている。VDAとEclipse Foundationは、ソフトウェア定義車両向けのオープンソース基盤を作るMoUを拡大し、参加企業が2025年6月の11社から2026年1月時点で32社へ増えたと発表した。中心に置かれているのが、Eclipse SDV Working Group内のEclipse S-COREである。
S-COREが対象にするのは、各社の画面デザインやブランド体験を同じものにする「車載OS」ではない。組み込み高性能ECUで動く安全系のコアスタックを、オープンソースで共通化する取り組みだ。通信、永続化、ログ、ライフサイクル管理、時刻同期、テスト基盤といった、顧客からは見えにくいが車両全体の信頼性を左右する層が対象になる。
欧州発のこの枠組みは、ソフトウェアの競争領域を切り分け直している。車内UI、運転体験、サービス、データ活用は各社の差別化として残る。一方で、センサー、ECU、制御ソフト、更新機構をつなぐ土台を各社が個別に作り続ければ、同じ作業に人員と時間を使い続けることになる。VDAはこの共同化により、非差別化ソフトウェアの開発、統合、保守の工数を最大40%減らし、共有コンポーネントで市場投入を最大30%短縮する狙いを掲げている。
32社への拡大で「共通化してよい領域」が見え始めた
VDAとEclipse Foundationの発表では、このMoUは「Automotive-Grade Open Source Software Ecosystem」と位置づけられている。目的は、オープンで相互運用可能、かつ認証を見据えたソフトウェア基盤を、Eclipse SDV Working Groupの中で実装することにある。
参加企業の幅は広い。VDA発表は、42dot、Accenture、AVL、Capgemini、Coretura、Cummins、ECARX、Elektrobit、Infineon、LEAR、LG Electronics、Michelin、MOBIS、QNX、Qualcomm、Red Hat、Schaeffler、Stellantis、Traton、T-Systems、useblocksなどが新たに加わったと説明している。創設側にはAumovio、BMW、Bosch、ETAS、Hella、Mercedes-Benz、Qorix、Valeo、Vector、Volkswagen、ZFが並ぶ。
Eclipse SDVの会員一覧でも、BMW、Bosch、Cariad、Mercedes-Benz Tech Innovation、Traton、Vector、ZFなどが戦略メンバーとして掲載されている。委員会の構成を見ると、BMW、Mercedes-Benz Tech Innovation、Cariad、Traton、ETAS、ZF、Vectorなどの担当者が運営や技術助言に入っている。単発の共同声明ではなく、開発の優先順位と技術範囲を継続的に調整する体制を伴った取り組みだ。
この枠組みで各社が共有しようとしているのは、ブランドを直接表現する機能ではない。VDAは、共同開発の対象を「non-differentiating software」と表現している。顧客が車を選ぶ理由にはなりにくいが、安全性、更新性、保守性、開発速度には欠かせない領域である。ここを共同化できれば、メーカーやサプライヤーは限られた技術者を、運転支援、ユーザー体験、エネルギー管理、サービス連携といった表に出る機能へ回しやすくなる。
S-COREは高性能ECU向けの共通スタックを担う
Eclipse S-COREの正式名称はEclipse Safe Open Vehicle Coreである。プロジェクトページでは、Software Defined Vehicle向けのオープンソース・コアスタックを開発し、組み込み高性能ECUを主な対象にすると説明されている。現代の車両では一つのECUの中に複数のプロセッサが載る構成も増えており、S-COREはそれらのプロセッサ間の相互運用も対象に含めている。
一般的な「車載OS」という表現から受ける印象とは少し違う。車内のスクリーン表示やアプリ基盤ではなく、複数の制御コンポーネントが安全に連携し、状態を監視し、ログを残し、必要な更新や診断につなげる層が焦点になる。Eclipse SDVのサイトも、S-COREを「安全でモジュール化されたオープンソースのコアソフトウェアスタック」とし、組み込み高性能ECUとマルチプロセッサ相互運用に焦点を置くと説明している。
自動車向けでは、コード公開だけでは量産開発に届かない。S-COREは、機能安全のISO 26262、サイバーセキュリティのISO/SAE 21434、UNECE WP.29への対応を掲げている。量産車に近い場所で使うには、ソースコードと合わせて要件、設計、検証、脆弱性管理、変更履歴を追えることが必要になる。Eclipse S-COREがドキュメントやプロセス、テスト基盤をプロジェクトの一部として扱っているのはそのためだ。
0.7リリースで焦点は基礎作りから安定化へ移った
S-COREは2025年11月に初の公開リリースとなるバージョン0.5を出し、2026年にはフルリリースを予定している。VDA発表によれば、その対象は遅くとも2030年までに市場投入される車両プログラムだ。研究開発の概念実証にとどまらず、今後数年の量産計画に間に合わせる時間軸で動いている。
2026年5月12日に発表されたS-CORE 0.7.0は、その流れの中で見る必要がある。Eclipse SDVは、初期リリースが基礎アーキテクチャと中核機能の導入に重点を置いていたのに対し、0.7では既存機能の堅牢化、性能改善、開発者体験の向上に集中したと説明している。プロジェクトが「何を作るか」を示す段階から、「使える形に近づける」段階へ進んだ。
0.7では、基礎ライブラリのBaselibs、プロセス間通信のCommunication、データ保存を扱うPersistency、診断や監視につながるLogging、サービス管理やデプロイを扱うOrchestrator、分散システムで必要になる時刻同期のKyron、Lifecycle & Health Managementが更新された。さらにReference Integration、Process Description、Docs-as-Code、Tooling、Integration Testing Framework、Test Scenarios、Bazel C++ Toolchainも対象に入っている。
この一覧が示すのは、S-COREが単一の機能ではなく、車載ソフトを量産品質へ近づけるための周辺部までまとめようとしていることだ。通信や永続化だけがあっても、検証やドキュメント、ビルド、テストシナリオが弱ければ量産開発には乗せにくい。こうした周辺の整備が進めば、各社は共通基盤を自社の車両プラットフォームへ組み込む判断をしやすくなる。
非差別化領域の共同化が、開発速度の土台になる
VDAとEclipse Foundationの発表が前面に出しているのは、非差別化領域の重複を減らすことである。電動化とコネクテッド化が進む中で、車両の競争力はエンジンやシャシーだけでは決まらなくなった。OTA更新、運転支援、デジタルコックピット、エネルギー管理、車両データの活用は、ソフトウェアの開発速度と保守体制に左右される。
車載ソフトの複雑さが増した結果、どのメーカーも同じような基礎部品を何度も作る余裕を失いつつある。安全性やセキュリティの要件を満たしながら、複数世代の車両を更新し続けるには、共通化できる部分を共同で鍛えた方が合理的になる。VDAが掲げる最大40%の工数削減と最大30%の市場投入短縮は、この発想を数字で示したものだ。
各社にとって難しいのは、どこまでを共通化し、どこからを自社の差別化として残すかだ。通信、ログ、ライフサイクル管理、時刻同期、テスト基盤のような土台は共同化しやすい。運転体験、ブランド別のUI、サービス設計、顧客データの扱いは、メーカーごとの競争領域として残る。この線引きがうまくいけば、共通基盤は個性を消すものではなく、個性を作るための作業時間を確保するものになる。
発表から量産採用へ進めるかが鍵になる
現時点で公式情報から確認できるのは、S-COREが共同開発の中核として位置づけられ、公開リリースを重ね、2026年のフルリリースと2030年までの車両プログラムを狙っていることまでである。どのメーカーのどの車種が、どの範囲でS-COREを採用するかは、まだ確定情報としては出ていない。
今後見るべきは、参加企業数の多さよりも採用の深さである。参照スタックとして試すだけなのか、特定ECUや車両プラットフォームの量産開発に入るのか。安全認証やサイバーセキュリティ対応の成果物が、各社の開発プロセスにどこまで組み込まれるのか。サプライヤーが提供する商用ミドルウェアや既存AUTOSAR資産とどう住み分けるのか。ここが次の判断材料になる。
Eclipse S-COREは、自動車メーカーが同じ顔の車を作るための仕組みではない。競争力を生む機能の下にある車載ソフトの基礎層を共同化する試みである。32社への拡大と0.7リリースは、この試みが合意文書の段階を越え、量産車に届くかどうかを問われる段階へ入ったことを示している。