OTA更新とSUMS実装を阻む5つの壁

1．OTAソフトウェア更新のはじまりと「SUMS時代」の本格到来

2010年代前半には、一部の新興自動車メーカーが、無線通信を用いたソフトウェア更新（OTA更新）を本格的に打ち出しました。それ以前は、販売後の車載ソフトウェアを変更するには、基本的にはディーラーへの入庫を前提とし、また車両とソフトウェア書き込み装置を有線接続してソフトウェアを更新していました。以降、OTA更新は、入庫対応に伴う負荷やコストを抑えながら、市場投入後の車両に広くソフトウェア更新を適用する手段として注目されるようになりました。

一方、2020年6月に採択され、2022年から車両への適用が順次開始されたUN Regulation No. 156（プログラム等改変システムに係る協定規則 第156号、以下「UN-R156」）においては、自動車メーカーに、ソフトウェア更新を安全かつ確実に実行するための管理体制（Software Update Management System: SUMS）を保有し、またその確実な運用を求めることとなりました。その背景としては、次の点が挙げられます。

• 車載機能の高度化によって、パソコンやスマートフォン同様に、その搭載ソフトウェアの性能やセキュリティを維持向上させるために、定期的なソフトウェア更新が必要になったこと
• 車両が工場出荷時点で備えていた安全性等の性能に対して、ソフトウェア更新の影響を確認し基準を下回ることがないよう確実に対応する必要があること
• ソフトウェア更新機能自体がセキュリティリスクを高めることがないようにすること

このような背景から、2020年代に入り、自動車業界ではOTA更新への対応が、実務レベルの経営課題として急速に重要性を増しています。特にSUMSへの対応は、UN-R156を通じて型式認証制度と結びついているため、対象市場や車種によっては、製造・販売の前提条件となるなど、重要な課題となっています。

2．OTA更新は「修正手段」から「継続的価値提供の基盤」へ

ここで、OTA更新の目的に目を向けてみましょう。まず先述の通り、車載ソフトウェアの高度化から、セキュリティをはじめとする性能・品質の維持を目的とした、「修正」の意味合いの強いソフトウェア更新が挙げられるでしょう。またそれとは別に、工場出荷時点で備わっていない「新機能の追加」や「性能向上」をソフトウェア更新によって達成することも、主要な目的の一つとなっています。特に後者については、「既販車に新しい価値を届ける」という点で、いわゆるSoftware Defined Vehicle（SDV）であることの基本的な要件とみなすことができます。

このように、OTA更新は単なる是正措置の手段にとどまらず、販売後にクルマの価値を高め続けるための中核機能となりつつあります。ここでいう価値とは、単なる画面デザインの変更だけではありません。HMIの改善、ナビやコネクテッドサービスの強化、電費や充電制御の最適化、熱管理の改良、ADASの改善、車両診断や保守支援の高度化、個別ユーザーへの機能提供など、販売後も車両を進化させる余地は広く存在します。車両はもはや、工場出荷時点で価値が固定される完成品ではなく、使用期間中に機能や体験を改善しつづけるプロダクトへと変わりつつあります。

3．新興／既存メーカーのOTA更新

一部の新興メーカーでは、このようなソフトウェア更新の実績が蓄積されつつあります。販売後にソフトウェア更新を重ねることで、ソフトウェアのみならず、ユーザー体験そのものを更新していると言えるでしょう。その結果、市場の一部では「車両は購入後にも進化する」という期待が高まりつつあります。つまりOTA更新は、便利な付加機能ではなく、商品競争力そのものになります。車両販売後に、どれだけスムーズに、どれだけ価値のある更新を届けられるかが、ブランド評価や顧客ロイヤルティに直結する時代が到来したとも言えるでしょう。

乗用車のユースケース

例えば、米国系OEMでは、不具合を把握した当日に該当ソフトウェアの追加配信を停止し、翌日から修正版の展開を開始した事例があります。また、中国系OEMは、2025年に「海洋」と「王朝」の両シリーズを対象として、合計約200件のソフトウェア更新を実施したと報じられています。これは複数車種・仕様を含む合計件数ですが、年間を通じた更新規模の頻度とスピードを端的に表しています。北欧系OEMも、購入後の車両にOTAで新機能や改善を提供しています。これらは、不具合への迅速な対応から新たな機能・価値の提供まで、OTAを販売後の顧客体験と車両価値を継続的に更新する仕組みとして活用する動きと言えます。

商用車・フリートのユースケース

乗用車よりも商用車の方が、OTA更新の価値はさらに明確です。トラック、バス、配送車両などでは、車両停止がそのまま事業損失につながるため、遠隔診断、ログ取得、故障予測、予防保全との組み合わせが重要になります。市場から得られた車両データをもとに診断ロジックや制御ソフトウェアを改善し、必要な更新を非稼働時間帯に安全に配信できれば、突発故障の抑制、計画整備の高度化、稼働率向上につながります。

一部の新興メーカーが着実に実績を積み上げている一方で、既存メーカーのOTA更新の取り組みは、新興メーカーに比べると、実装範囲や運用実績にばらつきがあるように見えます。この状況の背景には、既存メーカーの抱える次のような課題があると考えられます。

4．既存メーカーが直面する5つの壁

車両アーキテクチャ関連

• 【アーキテクチャ】日系OEMも含めた従来型の車両の多くは、OTAに適しているとは言い難いE/Eアーキテクチャを抱えています。多数のECUが機能ごとに分散し、それぞれが個別最適で進化してきたため、ソフトウェアの依存関係が複雑になり、一部のECUだけを更新すると、他の機能やECUとの整合性に影響が生じるおそれがあります。
• 【更新負荷】更新単位が大きいと通信量や更新時間が増え、細かいと依存関係や互換性の管理が複雑になります。また、ECUのメモリや演算資源が限られ、更新前後のソフトウェアを保持する二重化領域や、更新失敗時のロールバック機能を確保しにくい場合もあります。
• 【ECUの影響範囲の把握】OTA／SUMSへの対応には、更新単位に加え、ECU間の依存関係、更新順序、互換条件、復旧方法を事前に明確化する必要があります。E/Eアーキテクチャは、OTA更新の安全性、成功率、復旧性とSUMS運用の難易度を左右する重要な基盤です。

ソフトウェアバリエーション

• 【車両構成情報の把握】既存メーカーは、これまでの車両展開によって膨大な製品資産を抱えています。多車種・多地域への展開に加え、年式、グレード、オプション、法規、工場、搭載部品、サプライヤーなどの違いが積み重なり、同じ車名でも搭載されているハードウェアやソフトウェアの構成が細かく分岐していることは珍しくありません。
• 【組合せ爆発への対応】構成差分が増えるほど評価パターンも膨大になります。適用条件を正確に管理できなければ、対象外車両への誤配信、配信漏れ、ECU間の非互換、法規不適合を招くおそれがあります。そのため、車両型式やVINを起点に、ECU、ハードウェア、ソフトウェア、キャリブレーション、依存関係、RXSWIN、型式認証情報、配信履歴を追跡し、変更・不具合・試験データと紐づけ、影響と同時更新対象を車両・機能単位で特定したうえで、配信まで漕ぎつける仕組みを構築する必要があります。

サプライチェーン

• 【多層的構造】既存メーカーの多層的なサプライチェーンは、販売後の継続更新を難しくする要因です。従来は量産開始までに品質を作り込み、納入後は限定的な改修を行う形が一般的でした。しかし、OTAでは販売後もソフトウェアを継続的に開発、検証、リリースする必要があります。
• 【責任分界点の再整理】そのため、不具合や脆弱性の検知、改修判断、更新パッケージの作成・検証、リリース・配信判定を誰が担うのか、責任分担を明確にしなければなりません。また、電子署名鍵の管理、承認・実行権限、漏えい時の失効・再発行手順も重要です。メーカーとサプライヤー間の契約も、部品納入までではなく、販売後の保守期間、脆弱性対応、変更通知、構成情報の提供、緊急改修、費用負担、サービス終了まで含めて見直す必要が求められるでしょう。

開発プロセス

• 【開発プロセスの共有言語化】従来の車両開発プロセスは、量産開始前に完成度を高める思想で設計されています。しかし、OTAで継続的に価値を提供するには、出荷後も市場情報を収集し、ソフトウェアを改善する開発・運用プロセスへの転換が必要です。OEMはサプライヤーにもAutomotive SPICEに基づく要求、設計、変更、構成、検証、品質保証等の管理を求め、その実施状況と成果物を確認できる体制を整える必要があります。加えて、OEMへ提供する構成情報の粒度・形式、識別方法、変更通知のタイミングを共通化し、車両全体の構成と変更影響を把握できるようにします。
• 【継続的改善への転換】影響分析、構成管理、自動ビルド、自動・回帰試験、更新パッケージ検証、リリース承認を一貫して管理し、限定車両から開始して結果を確認しながら対象を広げる段階配信も必要です。さらに、異常時の配信停止、対象車両の特定、切り戻しまたは安全な復旧、修正版の再配信を事前に設計し、市場で監視・改善を続ける運営へ移行することが求められます。

組織

• 【OEM内の組織設計】組織が縦割りのままでは、販売後のOTA更新を継続的かつ安全に運営することは困難です。企画、開発、品質、認証、サイバーセキュリティ、IT、アフターサービスなどの関係部門が分断されると、対象車両、配信時期、停止判断、ユーザー案内に関する意思決定が滞ります。このため、関係部門を横断するSUMS運用体制を構築し、更新責任者、リリース・配信承認者、緊急停止権限者を明確にする必要があります。
• 【外部関係者との協力関係】OTA配信基盤の監視結果、車両ログ、販売店の修理情報、問い合わせ、市場不具合を統合し、インシデント管理、原因分析、是正処置、開発へのフィードバックにつなげる必要があります。OTAシステムだけでなく、組織、権限、プロセス、情報連携を一体で整備することが重要です。

5．終わりに：OTA更新を「当たり前」にするために

特に既存メーカーがOTA更新を車両および事業運営の標準機能として定着させ、安定的に運用するためには、先に挙げた課題のひとつひとつに向き合い、解決していく必要があるでしょう。ただし、レガシーの全てを捨て去り、車載アーキテクチャからアフターサービスまで、すべてを刷新することは現実的ではありません。変化させる対象を効果的に絞り、抜本的なアプローチを限定された範囲から段階的に進めていく方法が現実的でしょう。

E/Eアーキテクチャを採用するモデルでは、車載プラットフォームの企画段階からOTA更新機能を前提条件として織り込むなどの技術的な側面での対応が要されることに加えて、海外の競合他社にも遜色ない配信頻度やスピードを実現しつつも、OTAに伴うリスクを着実に対処するためには下記が解決のヒントになると考えます。

• 法規であるUN-R156とISO 24089に基づくソフトウェア更新エンジニアリングプロセス
  • 更新の影響評価から実行・結果確認までのソフトウェア更新プロセスと責任を明確化し、安全かつ確実な更新を継続的に実施できる体制の構築
• Automotive SPICEに基づく開発・変更・構成・検証管理、サービスマネジメントに基づく配信後の監視・障害対応の連接
  • サプライヤーの開発からOEMの車両統合、配信承認、段階展開、市場監視、切り戻し、開発へのフィードバックまでを、共通の構成情報と責任体系によって一貫して管理する体制の確立

このような標準化され、再現可能で監査可能なプロセスは、更新の安全性、継続性、法規適合性を確保するための基盤です。同時に、ソフトウェアを迅速かつ繰り返し市場へ届ける能力を高め、OTAを法規対応の手段から、顧客体験と車両価値を継続的に向上させる競争力へ転換します。SUMSへの対応はゴールではなく、SDV時代の価値創出に向けた出発点と捉えるべきでしょう。

また、日本で開発された車両が世界各国の市場を走ることが当たり前である現実も織り込む必要があります。上記の体制構築を検討する場合、どこまでを日本本社が担い、どこまでを市場の特性に応じて現地の拠点が担当・関与するのかも、関連する法規などを念頭に設計することが求められます。日本で開発された車両がグローバル市場で展開されることを前提とすれば、OTA更新とSUMS対応は、そもそものソフトウェア開発における品質管理の強化や日本本社と各地域拠点の役割分担まで含めて設計すべきテーマです。今後は、こうした観点から、実装・運用の論点をさらに掘り下げていきます。