SUMS
2026年5月1日
自動車産業のパラダイムがハードウェア中心からソフトウェア中心の車両、すなわちSDV（Software Defined Vehicle）へと急激にシフトする中で、メーカーのリスク管理戦略にも抜本的な変革が求められています。かつてのリコールが、膨大なコストとブランドイメージの低下を伴う「物理的な部品交換」を意味していたとすれば、これからはSDVとOTA（Over-the-Air）技術を活用し、欠陥を先制的に防御してコストを最適化する「デジタルガバナンス」の時代へと突入しています。 SDVにおけるRxSWINと車両ソフトウェア構成の管理 SDV時代における車両のアイデンティティは、もはや出荷時のハードウェアスペックではなく、搭載されているソフトウェアのバージョンによって定義されます。その中核をなす概念が、ソフトウェア識別番号である「RxSWIN」です。RxSWINは、車両に搭載されている機能や安全に関わる仕様、自動運転機能の作動条件などを示す、いわば「デジタル指紋」のような役割を果たします。そのため、特定のソフトウェアモジュールに不具合が見つかった場合でも、RxSWINをもとに影響を受ける車両を速やかに特定できます。これにより、従来のように対象を広く見積もって全車両を確認する必要がなくなり、リコールの対象範囲を最小限に抑えられる点は、次世代の車両設計における大きなメリットといえるでしょう。 RxSWINとは？ RxSWIN（Rx Software Identification Number）は、国連規則UN-R156で定義される、型式認証に関連するソフトウェアを識別するための番号です。 従来は、ECUごとの部品番号やソフトウェア番号を中心に管理されてきましたが、SDVでは多数のソフトウェアが車両全体の機能や安全性に関わるため、個別管理だけでは、どのソフトウェア構成が認証済みの状態なのかを把握しにくくなります。RxSWINを用いることで、メーカーは車両に搭載されたソフトウェア構成と、型式認証上承認された構成との対応関係を管理しやすくなります。また、不具合が見つかった場合には、対象となるソフトウェア構成をもつ車両を絞り込みやすくなるため、不要な調査やリコール範囲の拡大を抑えるうえでも重要な役割を果たします。 【最新事例】テスラの後方視界不適合リコール（NHTSA 26V283） 先述したソフトウェア修正の失敗パターンを克服し、SUMSという「地図」を活用してリコールの矛盾を解決した最新事例が、テスラの安全リコール報告書（NHTSA 26V283）です。この不具合は、特定のソフトウェアバージョン（develop/2026.8.6）が実行されている車両において、起動時にバックカメラの映像ストリームがMCU（メディアコントロールユニット）へ正常に送信されず、バックギアに変速した際に最大11秒間バックモニターがブラックアウトするという事象でした。これは米国連邦自動車安全基準である「FMVSS 111（後方視界）」の規定に準拠しない安全規制違反にあたり、ハードウェア3を搭載したModel 3、Y、S、Xなど、実に合計218,868台におよぶ大規模な車両がリコールの対象となりました。 しかし、ここで注目すべきポイントは、テスラがこの危機を処理したタイムラインです。テスラのエンジニアリングチームは、4月10日にこの問題を検知すると直ちに既存ソフトウェアの配信を停止しました。そして翌日の4月11日には修正パッチをOTAで一斉配信し始めました。その結果、当局へ公式にリコール報告書を提出した5月4日の時点では、すでに対象車両の99.92%以上が修正プログラムの適用を完了させていました。法的な手続きが進む前に、技術的にはリコールがほぼ終結していたことになります。 テスラがわずか1日でピンポイントの修正パッチを安全に配信できたのは、今回の欠陥が「ハードウェア3搭載車両」かつ「特定の開発ビルド」の組み合わせでのみ発生することを特定できたからです。出荷後の車両であっても、ハードウェアの構成とソフトウェアのバージョンがどう紐付いているかを正確に管理・追跡（トレーサビリティ）できるSUMS（ソフトウェアアップデート管理システム）が機能していたためだと考えられます。つまり、OTAの普及によってリコールの頻度が高まるという「矛盾」の時代において、SUMSとは単なる規制対応の足かせではなく、リコール費用とブランド価値を守り抜くための必須インフラであるということを、このテスラのケースは見事に証明しています。 UN-R156／SUMS準拠を考慮した論理アーキテクチャ設計 第24回UN自動運転専門分科会（GRVA）などの国際社会は、ソフトウェアアップデートの安全性を確保するため、UN-R156（ソフトウェアアップデート管理システム）の規定を強化しています。OEMはソフトウェアによるリスクを最小化するために、以下の法的・技術的要件をアーキテクチャの設計段階から反映しなければなりません。 【主要な技術的必須要件】 SUMSに基づく更新管理 […]
2026年4月10日
グローバル自動車市場において、SDV（ソフトウェア定義車両）への転換はもはや未来のビジョンではなく、目の前の現実になりつつあります。日本の自動車業界でも、次世代モビリティの主導権を握るべくソフトウェア開発への巨額の投資が行われています。しかし、この華々しい進化の裏で、見過ごされがちな問いがあります。「何百万行ものコードで動く安全重視の機械（クルマ）は、出荷後も本当に安全に管理されているのか？」電気自動車（EV）をはじめとする現代の車両は、車輪のついたスマートフォンではありません。人命を預かる複雑なシステムです。 ソフトウェアの影、便利さが招く「リコールの急増」 従来の自動車は、工場を出荷された時点で「完成品」でした。しかしSDVは違います。OTA（Over-the-Air）アップデートを通じて、購入後も性能や機能が変化し続けます。リコールのために販売店へ車を持ち込む手間が省けるため、OTAは「画期的な解決策」としてもてはやされています。 しかし現実には、OTAの普及と比例するようにグローバル市場でのソフトウェア起因のリコールが急増しています。ある機能のバグを修正するためのアップデートが、部品を共有する別システムに予期せぬ不具合を引き起こし、結果として二次・三次の連鎖的なリコールを引き起こす「リコールのパラドックス」が発生しているのです。 「手戻り」の危機：なぜソフトウェアの修正は失敗するのか ソフトウェアリコールがもたらす最も深刻な経営リスクは「再作業（手戻り）の繰り返し」です。グローバル市場における大規模な統合充電制御装置（ICCU）の不具合事例などを見ても、ソフトウェアアップデートによる一時しのぎの対応では根本原因を解決できず、最終的に巨額のコストを伴う部品交換（ハードウェア保証の延長）に追い込まれるケースが散見されます。米国の自動車業界レポート（AutoSoftToday, 2025）によると、ソフトウェアの修正が失敗する原因は、主に以下の5つのパターンに分類されます。これは特定の企業の失敗ではなく、SDV転換期における構造的な問題です。 不完全な修正 (42%) : 複雑なモジュール間の依存関係を考慮せず、根本原因を解決できていない状態での配信 OTA配信の失敗 (18%) : アップデート自体のインストール失敗や、新たなバグの誘発 ハードウェア交換の必要性 (15%) : ソフトウェアだけでは解決できず、結局部品交換のキャンペーンが必要となるケース 検証のギャップ (13%) : ラボ環境では正常でも、実際の走行パターンや温度など、現場の変数が検証に反映されていないケース 影響範囲の拡大 […]
2025年7月24日
日本の自動車業界は品質を最優先にして、信頼性の高いモノづくりに長年取り組んできました。新しい技術を導入する際にも、安全性や安定性を十分に確認しながら、一歩一歩着実に実装を進める姿勢が根付いています。こうした中、ソフトウェア定義車両（SDV: Software Defined Vehicle）への移行が加速する現在、無線通信によるソフトウェア更新（OTA: Over‑the‑Air）のセキュリティについても、これまで以上に真剣な対応が求められています。 2024年7月から国連規則UN-R155（サイバーセキュリティ管理システム）およびUN-R156（ソフトウェアアップデート管理システム）が義務化されたことで、OTAセキュリティは選択ではなく、事業継続のための必須要件となりました。特に、日本自動車工業会（JAMA）と日本自動車部品工業会（JAPIA）が共同で発行した「サイバーセキュリティガイドラインv2.2」は、業界の実質的な標準として機能し、完成車メーカーから部品サプライヤーに至るまで、サプライチェーン全体に高いレベルのセキュリティを求めています。 OTAは何か？その仕組みと役割 OTA（Over-the-Air）とは車両に搭載されたECU（電子制御ユニット）や車載ソフトウェアを無線通信を通じて遠隔から更新・修正・機能追加する技術です。従来のようにディーラーや整備工場に持ち込む必要がなく、ユーザーの利便性を高めるとともに、メーカーにとっても運用コストの削減と不具合に対する迅速な対応が可能になるという大きなメリットがあります。 SDV（ソフトウェア定義車両）の普及により、車両の機能がソフトウェアで制御されるようになった今、OTAは単なるアップデート手段ではなく、「サービスとしての機能（Function as a Service）」を提供する中核インフラとなりつつあります。しかし、OTAの導入が進むほど、サイバー攻撃のリスクも増大しています。OTAによって車両が常時インターネットに接続されることで、攻撃者にとってアクセスしうる入口が増えることになり、結果としてセキュリティ対策がより重要になると考えられます。 OTAを介したサイバー攻撃の脅威と実例 このように大きなメリットをもたらすOTAですが、その利便性の裏には深刻なセキュリティリスクが潜んでいます。 ジープ・チェロキーのハッキング事例 OTAシステムを狙ったサイバー攻撃は、すでに現実の脅威として世界で確認されています。中でも有名なのが、2015年に米国で発生したジープ・チェロキーのハッキング事件です。この事件では、セキュリティ研究者が16km以上離れた場所から、走行中の車両のエアコンやラジオを遠隔操作し、最終的にはエンジンを停止させることにも成功しました。OTA通信経路を乗っ取ることで、車両制御に深刻な影響を与えることが可能であることが実証されたのです。この事態を受け、約140万台がリコール対象となり、自動車業界に大きな衝撃を与えました。 このような事例は、OTA機能が便利である一方で、それ自体が新たな攻撃経路にもなりうることを示しています。車両が常時インターネットと接続されることで、攻撃者にとっての“入口”が増えるため、OTA導入が進むほど高度なセキュリティ対策が求められます。 OTAに限らない、サプライチェーン全体への脅威 日本国内でも、サイバー攻撃の脅威は現実のものとなっています。2022年には、トヨタ自動車の主要サプライヤーである小島プレス工業がランサムウェア攻撃を受け、トヨタの国内全工場が一時的に稼働停止となりました。また2020年には、ホンダが海外工場でサイバー攻撃を受け、生産に支障をきたした事例も報告されています。 これらの攻撃はOTAを直接的に狙ったものではありませんが、共通しているのは「セキュリティの弱いサプライチェーンが狙われ、結果として完成車メーカー全体に影響している」という点です。つまり、車両本体だけでなく、サプライチェーン全体を見据えたセキュリティ対策が不可欠になりつつあります。 OTAにおける技術的リスク OTAセキュリティが脆弱な場合、車両の制御やデータを乗っ取られる深刻なリスクが存在します。たとえば「遠隔での車両制御奪取」は、外部の攻撃者がブレーキ、ステアリング、アクセルなどのECU（電子制御ユニット）に不正アクセスし、物理的に乗車していないにもかかわらず、車両を意のままに操ることを可能にします。これは人命に直結する安全上の脅威です。「悪意のあるソフトウェアの注入」は、正規のOTAアップデートを装ってマルウェアを車両システムに送り込む手法です。これにより車両の機能停止、ユーザーの位置情報や運転履歴などの個人情報漏えいにつながる恐れがあります。「中間者攻撃（MITM）」では、OTAの通信経路に割り込み、アップデートファイルの改ざんや偽データの注入が可能になります。暗号化や認証が不十分な場合、攻撃者は更新の整合性を破壊し、深刻なシステム障害を引き起こします。さらに、「CANインベーダー攻撃」は、物理的に車両にアクセスし、CAN（Controller Area […]
2024年7月31日
現代の自動車技術の進化に伴い、インターネット接続機能をもつコネクテッドカーが急速に普及しています。これにより、ドライビングの利便性が向上すると同時に、サイバーセキュリティリスクも増大しています。特に、2015年に発生したジープ・チェロキーのリモートハッキング事件では、ハッカーが遠隔操作で車両の制御を奪うという衝撃的な事例がありました。 こうした背景もあり、自動車のサイバーセキュリティ対策が急務であることが明確になりました。そこで、型式認証（VTA：Vehicle Type Approval）の条件にサイバーセキュリティ対策が追加されました。本記事では、自動車サイバーセキュリティの重要性と、それに密接に関連する型式認証（VTA）の仕組みについて分かりやすく説明します。 弊社は技術機関として指定され、VTA（車両型式認証）制度に基づき、中立な立場でサイバーセキュリティに関する審査を行っています。詳しくはこちらをご覧ください。 型式認証（VTA）とは何か 型式認証（VTA：Vehicle Type Approval）とは、製造された新型車両が各国の法的基準を満たしていることを証明するための制度です。この認証を受けることで、車両は合法的に市場にリリースされます。VTAの主な役割は、車両の安全性、環境性能、およびその他の法的要件を確認し、消費者に安心して利用してもらうことです。VTAの対象となる自動車は、乗用車、商用車、二輪車、トラック、バスなど多岐にわたります。各国の規制に応じて、これらの車両が市場に投入される前に、必要な認証を取得する必要があります。 VTA取得のプロセス VTAの取得プロセスにはいくつかのステップがあります。まず、製造者は車両が規制基準を満たしていることを確認するために必要な書類や試験データを準備します。次に、認定された技術機関が提出された書類や試験データを審査し、必要に応じて車両の実物試験を行います。すべての基準を満たしていると確認されれば、型式認証が発行されます。 CSMSとSUMSの重要性 VTA取得には、CSMS（Cyber Security Management System）とSUMS（Software Update Management System）の導入が必須です。 これらのシステムの法的根拠として、2019年に施行されたUNECEの新規則があります。この規則により、車両メーカーはサイバーセキュリティリスクを評価し、適切な対策を講じることが義務付けられています。 CSMSの認証を受けるために必要なサイバーセキュリティ CSMSには、車両の設計から運用までのサイバーセキュリティリスクを管理するシステムです。以下の要素があります。 1. […]
2023年10月18日
自動車のサイバーセキュリティに関するソフトウェアは、開発の段階だけでなく、その後安全に更新していくことも重要な課題となります。では自動車のサイバーセキュリティとしてはどのような基準に沿ってソフトウェアの更新を考える必要があるのでしょうか。本記事ではSUMSの重要性について紹介していきます。 ソフトウェアアップデートを行うためには、ソフトウェアアップデートの管理体制を構築して、安全性をテストする必要があります。弊社はSUMS（ソフトウェアアップデートマネジメントシステム）をテストできるプラットフォームを開発・提供しています。詳しくはこちらをご覧ください。 SUMS (Software Update Management System）とは何か？ SUMS（Software Update Management System）とは、World Forum for the harmonization of vehicle regulations（WP.29）にて策定されたUN-R156に含まれる国際的な法規となります。SUMSでは自動車のソフトウェア更新をセキュアに実施するための要件が仕様として提示されています。内容としてはソフトウェアの更新が失敗した際の車両の安全性や、法規に関連した文書の管理、エビデンスの作成など様々です。スマートフォンやパソコンではソフトウェアやシステムの更新が失敗した場合、そのことが影響してデバイスそのものが動作しなくなる場合があります。同じことが自動車の車載ソフトウェアで起きた場合、大きな事故につながってしまうリスクがあります。このため自動車ではスマートフォンやパソコン以上にソフトウェアの更新が失敗した場合の安全を確保することは重要です。ソフトウェア更新は大まかにプログラムの入手（ダウンロード）、展開、インストールのどこで失敗しているのかによって、車両そのものに与える影響が異なります。単純にプログラムの入手の問題であれば車両への影響はそこまで大きくはないことが予想できます。しかしインストールの処理の途中で起きた問題なら、車両などシステムへの動作も懸念しなければなりません。トラブルシューティングも複雑になりがちです。このためソフトウェアの更新についてはある程度どこでどのような失敗があれば、どのような影響があるのかを評価し、安全性を確保することが必要となります。このような安全な更新のプロセス、エビデンスを残すことも求められているのです。 ソフトウェア更新が安全に行われないことで起きる問題 ではSUMSで要求されているような事項を満たすことができず、ソフトウェアが安全に更新されなければどのような問題が起きるのでしょうか。このことを理解するためにはアップデートシステムへの攻撃にはどのようなものがあるのかを知る必要があります。それは通信やソフトウェアの脆弱性をつく攻撃や、悪意のあるアップデートのインストールなどです。このような攻撃が成功したら、遠隔操作によるロック解除や個人情報の流出など、ビジネスインパクトが大きな出来事に結びついてしまう可能性があります。通常ソフトウェアのバージョンアップ/更新では、機能の追加/更新だけでなく、発見された脆弱性や既知となった問題への修正が含まれます。仮に既知の問題や脆弱性の対策ができなければ、そういった状態は攻撃者にとって恰好の的となります。 次に近年の車載ソフトウェアには、オープンソースソフトウェア（OSS)が利用されていることが少なくありません。オープンソースソフトウェアは無償で利用できるため、コストを抑えながら開発効率を高めるメリットはあります。しかしソースコードが公開された状態であるため、攻撃コードが開発されて実際に攻撃されてしまうリスクがあります。そしてオープンソースソフトウェア自体の脆弱性が公開されることもあるため、脆弱性情報の収集と影響評価を正しく行わなければ、ソフトウェアの安全性を脅かす要因にもなりかねません。 またソフトウェアを正常に更新することができず、追加機能をユーザに提供できなければ、品質低下や機会損失につながるリスクがあります。このためSUMSに従いソフトウェアを安全に更新するための体制を整えることは、自動車メーカーや関連する企業にとっても重要度が高いテーマだといえるでしょう。 SUMSで要求されている内容 では次にSUMS（Software […]
