デロイト トーマツ サイバー 上原 茂が訊く Vol.12　SDV時代の到来：ビークルOSの進化とサイバーセキュリティの新たな課題【前編】

SDV（Software Defined Vehicle）の時代が到来し、自動車業界は大きな構造的変革の真っただ中にあります。従来の「ハードウェア中心」の車両開発から「ソフトウェア中心」の開発へと移行が加速するなか、その中核を担う「ビークルOS」の重要性がますます高まっています。 
 
こうした転換期において、世界の自動車メーカーは独自OSの開発、業界標準への準拠、さらにはITベンダーとの提携など、多様な戦略を模索しており、トヨタの「Arene」、ホンダの「ASIMO OS」等、日本の自動車メーカーも独自の取り組みを進めています。国際標準やエコシステムとの整合性が強く求められる時代において、日本の自動車産業はいかにしてその存在感を発揮すべきなのでしょうか。 
 
さらに、コネクテッド機能が当たり前となる現在、サイバーセキュリティ対策も新たな局面を迎えています。OTA（Over The Air）によるアップデート、ソフトウェアの多様化などの利便性が高まる一方で、脆弱性リスクも拡大しています。開放性と安全性のバランスをどう取るか……。この問いは、いまや業界共通の喫緊の課題です。 
 
本稿では、SDV時代におけるビークルOSの中核的役割と、それに伴って浮上するサイバーセキュリティの課題について、ソフトウェア開発と安全性確保の最前線に立つお二人の専門家にお話を伺いました。 

【登場者】

イーソル株式会社　代表取締役社長CEO 兼CTO
権藤 正樹 氏

1996年にイーソル入社。以来自社OS及びツール関連の開発、それらを用いた車載、産業機器、家電機器などの各種カスタムプラットフォーム開発に取組む。

近年はシングルコアからメニーコアまで対応したOSであるeMCOS、ドメイン知見と機械学習を組合せたドライバモデル eBRAD、AUTOSAR Adaptive Platform仕様策定アーキテクト、マルチコア向けアーキテクチャ記述仕様IEEE Std. 2804 SHIMのWG Chair、社内の開発プロセス含む技術インフラ、プロダクトマネージメントを推進、2022年に専務ソフトウェア事業部長、2025年より現職。

組込みマルチコアコンソーシアム副会長、IEC TC91/WG13メンバ、早稲田大学アドバンスドマルチコアプロセッサ研究所招聘研究員、COOLChips TPC。

一般社団法人WSN-ATEC 理事長
田丸 喜一郎 氏

1981年慶應義塾大学工学研究科博士課程修了。工学博士。株式会社東芝を経て、独立行政法人情報処理推進機構（IPA）に従事。一般社団法人ディペンダビリティ技術推進協会副理事長、一般社団法人人間中心社会共創機構副理事長、一般社団法人重要生活機器連携セキュリティ協議会フェロー、九州工業大学客員教授などを務める。

＜モデレーター＞
デロイト トーマツ サイバー合同会社 シニアフェロー
上原 茂

長年、国内大手自動車メーカーに勤務。電子制御システム、車両内LANなどの開発設計および実験評価業務に従事。近年は一般社団法人 J-Auto-ISACの立ち上げや内閣府の戦略的イノベーション創造プログラム（SIP）adus Cybersecurityの研究リーダーを務めるなど、日本の自動車業界におけるサイバーセキュリティ情報共有の枠組みを構築。

欧州駐在経験もあり、欧州自動車業界の動向などへの理解が深い。

(以下、敬称略)

ビークルOSは3億行のソースコードに、SDVが直面する複雑性の壁

上原：まず、“SDV”と“ビークルOS”という2つのキーワードからから議論を始めます。

2025年1月、米国ラスベガスで開催されたCES（Consumer Electronics Show）では、　自動運転やSDVに関連する展示が大いに注目を集めたように思います。そんな中でソニーと本田技研工業（以下、ホンダ）の合弁会社であるSony Honda Mobility of Americaが、BEVの「AFEELA（アフィーラ）」を発表しました。また、ホンダも独自のビークルOSを搭載したBEVの「Honda 0（ゼロ）シリーズ」最新版を初公開しました。

もともと家電製品のショーだったCESが、先進モビリティの情報発信元となったこと自体、時代の転換を象徴していると思われます。

そういった背景の下、世界的には「SDV」という言葉はすでに定着した感がありますが、その定義は一様ではありません。共通して語られるのは、通信とOTA（Over The Air）を前提に、車両性能が出荷後もソフトウェアで進化できる点です。従来のハードウェア中心の車両から、ITアーキテクチャを基盤とした構造へと移行が進んでおり、変革の中核をなすのが「ビークルOS」です。ビークルOSは車両全体をソフトウェアで統合制御するための土台であり、SDVを支える中枢技術といえるでしょう。まずはこの「ビークルOSとは何か」を明確にしたいと思います。権藤さん、ご説明いただけますか？

権藤：「ビークルOSとは何か」を議論する前に、SDVそのものを整理させてください。

SDVの本質は、ソフトウェアのプラットフォーム化にあります。PCやスマートフォンのOSと同様に、「アプリケーションやサービスを動かすための統合基盤として車を捉える」という視点です。

OSには、CPUやデバイスを制御する「狭義のOS」のほかに、アプリケーションを支えるミドルウェアやサービス層としての役割があります。実際の機能の多くは後者で構成されており、ビークルOSもこうした構造を持つ必要があります。

この構造を必要とする背景には、ソフトウェアの大規模化と複雑性の増大があります。例えばPCのOSであればソースコードは約1億行ですが、ある高級車のビークルOSは約3億行に達すると言われます。これはATMオンラインシステムの10倍以上です。加えて、車には80以上のECU（電子制御ユニット）が分散配置され、それぞれが車載ネットワークを介して連携します。これは極めて高度で複雑な分散コンピューティング環境です。

ソフトウェア開発には膨大なコストがかかりますが、量産はコピーするだけですので量産コストはほぼゼロです。通常量産というのは原価が必ず発生するものです。他にソフトウェアのような技術はありません。つまり、ソフトウェア技術を最大に価値化する原理はソフトウェアの再利用を最大化することになります。これを実現する論理的かつ実績の多い手法がプラットフォーム化なのです。よって、多くの車種での再利用性の高いプラットフォーム化が求められます。言い換えると、OEMとしては複数の車種間で、サプライヤとしては複数のOEM間で再利用できれば非常にありがたいわけです。これはスマートフォンやクラウドに関わる業界でも同様です。しかし、自動車業界はこれまで再利用性の高いソフトウェアを開発するという文化がありませんでした。

その理由として自動車業界では、従来ボトムアップで個別機能を積み重ねてきたため、「ソフトウェア全体を設計する」という文化が未成熟だったのですね。その結果、ソフトウェア開発のコスト増大や品質に関する問題が顕在化しています。実際に、自動車のリコール原因の約4割がソフトウェアに起因するとも言われています。つまりSDV化の本質はOTAやサブスク対応だけでなく、ソフトウェアの構造的複雑さに対処するためのプラットフォーム変革でもあるのです。

また、SDVではソフトウェアがコンピュータだけでなく、センサーやアクチュエーターといった機械的・物理的コンポーネントまで統合的に制御する必要があります。これは従来のITシステムにはない難しさです。

上原：つまり、システムの規模と複雑さが想定を大きく超え、従来の車両開発プロセスでの対応が限界を迎えており、業界全体が抜本的な変革を迫られているのですね。これは全世界の自動車メーカーが抱える共通の課題であり、「どのような戦略を取るべきか」が今まさに模索の真っ最中と言えますね。

権藤：さらに言えば、ソフトウェア開発経験が豊富でない自動車業界にとって、この変革には設計思想の転換と技術的ブレイクスルーが不可欠です。うまく乗り越えられれば、AppleやMicrosoftが実現したような「プラットフォームを制する者が市場を制する」構図が自動車にも当てはまるでしょう。

イーソル株式会社　代表取締役社長CEO 兼CTO　権藤 正樹 氏

SDVの三つの観点と統合的設計の必要性

上原：次に田丸さんに伺います。ビークルOSを考えるうえで、押さえておくべき基本的な観点とは何でしょうか。

田丸：私が「SDV」という言葉を聞いて最初に思い浮かべたのは、「Software Defined Network（SDN）」です。かつては、ネットワーク機器のハードウェア設計によってネットワーク構成や機能などが決定されていた時代があり、ネットワークの種類によってトポロジーや特性が固定されていました。しかし、これがソフトウェアで制御できるようになると、柔軟に構成や特性を変更できるようになりました。

これをSDVに当てはめてみると、「ソフトウェアを通じて車両の性能特性や機能を制御・変更できる」ということになります。実際、最近の自動車ではECUのパラメータ設定を変更すれば、一部の機能がカスタマイズできるようになっています。つまり、少し前の自動車からはすでにSDV的な側面があるのです。

ただし一般的に議論されているSDVはより広義で、次の3つの観点があると考えています。

•  ソフトウェアの大規模化への対応（技術基盤としての整備）
•  コネクテッド化（外部との連携による価値創出）
• アフターマーケット対応（出荷後の機能追加やサービス展開）

これらはどれも欠かせない観点であり、全てを統合的に支えるビークルOSを中核とするプラットフォームが必要です。このプラットフォームがいつごろ完成し、普及するのかに注目が集まっています。

上原：車両制御（自動運転を含む車両の運動制御）、コネクテッド（情報のやり取り）、インフォテイメントという三本柱の観点ですね。これらの要素を統合的に捉えて支えるビークルOSとAPI（Application Programming Interface）の設計が肝になるということですね。

田丸：はい。そして、最も重要なのは権藤さんが指摘した「ソフトウェアの大規模化への対応」です。これが実現できていなければ、ビークルOSとは呼べません。

一般社団法人WSN-ATEC 理事長　田丸 喜一郎 氏

ソフトウェアファーストと人間中心設計の融合

上原：次に自動車メーカーにおけるソフトウェアの開発アプローチについて伺います。先ほど「自動車の開発はボトムアップ型開発である」と指摘されました。この方式は今後のSDV開発にどのような影響を及ぼすと考えますか。

権藤：従来の車載機能であるACC（Adaptive Cruise Control）やLDWS（Lane Departure Warning System：車線逸脱警報システム）は現場からの要求に応じて個別に開発された、典型的なボトムアップ型開発の機能です。その結果、そうしたピンポイントな機能が増え、OEMはクルマ全体としての一貫性、整合性の確保に苦労する状況に陥ってしまいました。

それに対して今注目されているのが、「ソフトウェアファースト」という考え方です。これは、まずシステム全体の構造やふるまいをトップダウンで設計し、その上で個別機能を実装していくアプローチです。例えば銀行ATMは、ユーザーの操作性を第一に考えたUI（ユーザーインタフェース）や、入金／出金の機構といった全体像を設計してから、それに沿って各機能を実装します。同様の発想で自動車全体を設計するのです。

私たちイーソルが提案しているのは、「DVE+U」モデルのプラットフォームです。「DVE+U」とはドライバー（Driver）、車両（Vehicle）、環境（Environment）に加えてユーザー（User）との関係性を軸に、車両制御を設計していくフレームワークです。この考え方では単に車両の個別機能を開発するのではなく、ドライバーと車の関係性、周囲環境との相互作用、そしてユーザー体験を包括的に捉えたシステム設計を行います。これをSOA（サービス指向アーキテクチャ）で実装すれば、柔軟性のある機能提供が可能になります。

例えば、あるOEMは「人馬一体」という思想を基に、自動車を開発しています。これはドライバーと車両の一体感を重視し、ドライバーの状態や特性、能力をシステムが理解して自然に補完するという設計理念です。例えば、年齢とともに運動能力や認知能力は低下しますが、コンピュータがドライバーの状態を理解し、さりげなくサポートするといった具合です。具体的には、ステアリング操作が遅れていると車が判断した場合、ドライバーに気付かれないように適切にアシストする設計です。こうした高度な連携を実現するには、従来の分散型ECU構成だけでは限界があります。

田丸：ソフトウェアファーストの視点に立つと、自動車メーカーにはより統合的なアプローチが求められます。ただ、これまでの自動車開発は、そうした発想に慣れていないのが実情です。

かつての自動車は、アクセル、ブレーキ、ステアリングといった個別の機構をドライバーが統合的に操作しており、車両全体の制御は人間に委ねられていました。しかし、安全性向上と事故ゼロを目指す時代の要請の中で、運転支援技術が進化してきました。全てのドライバーが高度な運転スキルを持つわけではない以上、車側により高度な統合制御能力を持たせる必要が出てきたのです。

このとき最も重要なのは「ドライバーとの関係性」です。どれほどシステムが賢くなっても、人間との調和を前提としない設計では逆効果になります。

上原：確かに、従来はレーン キープ アシストのような運転支援が主流でしたが、最近では追突防止自動ブレーキのように、ドライバーの状態に応じて積極的に運転操作に介入するようなシステムに進化しており、今後さらに高度な制御となっていくことは明白で、従来の分散型ECUを車載LANで接続した協調制御ではもはや限界と言え、車両全体としてその時の状況に最適な制御が実行可能となる統合制御システム的な構成が求められています。だからこそ、ビークルOSの必要性が高まっているのだと思います。

田丸：おっしゃる通りです。現在の設計思想では、「システムのほうがドライバーより賢い」という前提で開発が進められがちですが、その介入のタイミングや手法によっては、ユーザー体験を損なうリスクがあります。例えば、突然の自動ブレーキのタイミングがドライバーの意図とズレると、かえって不快感や不信感につながります。つまり、ソフトウェアの設計品質が、ドライバーの信頼感を左右する要因になっているのです。

権藤：運転スタイルはドライバーごとに大きく異なります。加減速の感覚、車間距離、ブレーキの踏み方など、どれを取っても「唯一の正解」があるわけではありません。だからこそ、画一的な制御の押しつけは違和感を生むのです。パーソナライズが不可欠なのです。でも、これはタッチパネルでたくさんいろいろ設定してのパーソナライズではありません。自動でそれができる必要があるのです。根本に立ち返ると、自動車メーカーは「よい運転とは何か」「よい車とは何か」という問いから出発して設計する必要があります。

物理とソフトウェアの分離がもたらす開発効率化

上原：自動車の運転支援機能は、ユーザーのニーズから生まれ、発展してきました。ACC(Adaptive Cruise Control)、LKA(Lane Keeping Assist)、追突防止自動ブレーキ、駐車支援、障害物自動回避といった機能はその代表例です。

しかし、その開発の現場は、複数の制御ECUをそれぞれの担当部署が設計し、CANなどの車載LANで接続し、その制御の整合性を後追いで確保していくという、非常に複雑かつ非効率な開発体制だと言ってよいと思います。既に設計や評価試験の現場では時間や工数の制約により限界が来ており、これ以上の機能高度化はもはやアーキテクチャの抜本的な見直しなしには実現できません。この課題を解決するには、車両を一つの統合システムとして捉え、設計する発想が不可欠です。その中心にあるべきなのが、ビークルOSとセントラルECUによる統合制御だと考えています。これは技術的な進化というよりも、避けられない必然的な流れではないでしょうか。

権藤：その通りです。このハードウェアとソフトウェアを分離するアーキテクチャが不可欠です。ここで言うハードウェアとは、ライダー、レーダー、カメラなどの各センサーの入力情報を処理し、モーターやソレノイドなどで電子制御により動作するメカニカルなハードウェアです。一例を挙げると、異なるE/Eアーキテクチャを共通で扱えるプラットフォーム技術が必要です。

上原：メカとソフトウェアを分離した開発アプローチではどのようなことが実現できるのでしょうか。

権藤：ITプラットフォームを提供しているITベンダーは「サーバ仮想化」「ネットワーク仮想化」「データセンター仮想化」等、ソフトウェアでシステムを仮想化し、柔軟に拡張・更新する方向で進化してきました。しかし自動車の場合、エンジンやブレーキといった機械的な要素が存在するため、ITと同じアプローチで開発するには、最初に機械の振る舞いを正確に模擬するソフトウェアモデルを作成する必要があります。こうすることで物理的な機械部品がまだ開発中であっても、その機能を仮想環境で先行的に再現できます。これにより、機械とソフトウェアの開発を並行して進められるのです。

つまり物理的コンポーネントをデジタルモデルと並立させることで、従来のように「まず機械部品を完成させてからソフトウェア開発に着手する」という開発プロセスを見直し、ハードウェアもソフトウェアを用いて設計、シミュレーションし、それを制御するソフトウェア、さらにはそれを利用したアプリケーションも同時に開発できるようにすることで、全体の開発期間を短縮できます。特に、センサーなどの電子部品が急速に進化する現在は、新しいハードウェアが登場するたびにソフトウェアを後追いで対応させていては、市場投入のスピードが追いつきません。

上原：そういった設計を支えるのが、デジタルツインを活用した開発、評価技術ですね。仮にアクチュエーターやセンサーなどの物理的な仕様が変化しても、最終仕様が固まる前にソフトウェア開発を先行できるのは大きなメリットです。

デロイト トーマツ サイバー合同会社 シニアフェロー　上原 茂

抽象化のトレードオフ、性能と拡張性のバランスとは

上原：これまでお話を伺って、自動車開発は「車全体を統合的に設計・制御する」という考え方へのパラダイム転換が求められていると実感しました。これはまさに、SDV時代に不可欠な発想ですね。

権藤：ご指摘の通りです。そして「車全体を統合的に設計・制御するアーキテクチャ」への移行では特に重要になるのが、ソフトウェアインターフェース、つまりAPIの設計です。統合システムを担当するエンジニアが、ブレーキやステアリングといった全てのサブシステムの専門知識を持っているわけではありません。そのためにはAPIによって各サブシステムの機能を抽象化し、内部の実装詳細を隠蔽する必要があります。これによって専門知識がなくても、制御が可能になります。

しかし、この抽象化にはトレードオフもあります。抽象化レイヤーを複数挟むことで、処理にオーバーヘッドが生じ、性能に影響を与える可能性があるからです。そのため、コンピュータの性能と実装コストのバランスを慎重に考慮しなければなりません。

特に自動車業界では、これまでソフトウェアの重要性やコストを軽視し、ハードウェアのコスト削減に過度に注力する傾向がありました。こうした文化的背景を踏まえると、統合アーキテクチャへの移行を成功させるには、十分なハードウェアリソースを前提とした設計が求められます。ソフトウェアエンジニアリングの視点を重視し、将来の拡張性を見据えた設計が不可欠です。

上原：おっしゃる通りですね。単に技術的な統合構想があるだけでは不十分で、それを確実に実現できる設計思想と組織文化が伴わなければ意味がありません。現在はまさに、その「仕組みづくり」が問われている段階だと感じます。

先ほど、機能の抽象化のためのオーバーヘッドという言葉が出ましたが、ソフトウェア情報などのインテグリティ（完全性）を確保するため、ある程度の処理負荷増加を覚悟したオーバーヘッドも不可欠であり、統合アーキテクチャを本格的に進める上で、避けて通れないのがやはりサイバーセキュリティの視点です。後編ではこのあたりを取り上げます。

【後編に続く】