小説で学ぶ自動車ソフトウェア開発 (その7) SDV・OTA

本エントリーは、小説で学ぶ自動車ソフトウェア開発（車載ソフトウェア開発）のシリーズものです。

その１、その２、その３、その４、その5、その６も是非ご覧ください。

その7は、Part 3のSOTIFから、Part 4のSDV・OTAへ移る回です。
「AIの性能限界を見つけても、出荷後にどう直し続けるのか」という流れでつなぐと自然です。

前回の「その6」では、Part 3としてSOTIF、すなわちISO 21448の世界を見てきた。

機能安全が「壊れたとき」の危険を扱うのに対して、SOTIFが扱うのは「壊れていないのに危ない」状況である。AIモデルは正常に動いている。センサーも壊れていない。ソフトウェアにも明確なバグはない。それでも、夕暮れの逆光、悪天候、想定外の道路環境といった条件の中で、システムの性能限界が露わになり、危険が生まれることがある。

では、その性能限界を見つけたあと、車はどう進化していくのか。

Part 4　SDV・OTA ―― ソフトウェアで動く車の時代

車は、売ってから始まる。

ここからPart 4として、SDV・OTA――ソフトウェアで動く車の時代 に入る。

かつて車は、工場を出た瞬間が完成品だった。しかしSDVの時代には、車は売られてからもソフトウェアによって変わり続ける。バグを直し、機能を追加し、AIモデルを改善し、安全性を高める。そのための仕組みがOTAである。

ただし、自動車のOTAは、スマートフォンのアップデートとは根本的に違う。更新に失敗すれば、車が動かなくなるかもしれない。安全機能を書き換えれば、機能安全やSOTIFの再検証が必要になる。さらに、型式認証や国連規制との整合性も問われる。

今回の「その7」では、主人公の成田剛志が、SDVとOTAの可能性、そしてその裏側にある安全・セキュリティ・規制の重さに向き合っていく。

量産後も、世界中の何百万台を安全に育て続けるための技術と、

その裏に潜む恐怖のすべて。

第27章　車は、もう「完成品」ではない

OTA.001：SDVとOTA ― なぜ車はアップデートが必要になったのか

カイトのプロジェクトが量産一年前のフェーズに差し掛かったある月曜の朝、和泉屋社長は全社朝礼でこんな話をした。

「Teslaが今週末、FSD v12.4をOTAで150万台に配信した。更新内容はE2Eモデルの改訂。交差点での判断精度が20%向上したと言っている。自動車の歴史のなかで、これはきわめて普通ではない出来事だ」

「なぜ普通ではないか。昔の車は、工場を出た瞬間が完成品だった。タイヤを換え、エンジンオイルを変え、ワイパーを変える。それが"メンテナンス"で、制御ソフトウェアが"進化"するということはなかった。でも今は違う」

「今の車は、売った後に成長する。これがSDV（Software Defined Vehicle）の本質だ。ハードウェアは同じでも、ソフトウェアが更新されることで、機能が増え、安全性が上がり、ユーザー体験が変わる。車は、もう"完成品"ではない。出荷したときが出発点で、そこから先はソフトウェアが続きを書く」

朝礼が終わった後、僕の席の隣でニックさんが呟いた。

「中国では、NIOもLi AutoもXpengも、OTAが当たり前になってます。2週間に1回くらい新機能が追加されることもある」

「それって、安全は大丈夫なんですか？」と僕は聞いた。

その質問が、この後のPart 4の全部だ。

「OTA（Over The Air）とは何か、基本を整理しよう」その日の研修で泉谷さんは言った。Part 4の講師は、泉谷さんと、新しい顔として登場した広井 智さん（コネクテッドソリューション部の38歳のエンジニア）が担当することになっていた。広井さんはセキュリティとOTAが専門で、ISO/SAE 21434とR155の両方に詳しい。

研修が始まる前、泉谷さんが全員に向けて説明した。「今日から数回、僕と広井さんの二人で担当する。僕がアーキテクチャとプロセスの側面を、広井さんがセキュリティと規制の側面を担当する。両方理解しないとOTAは設計できないから、必ずセットで聞いてほしい」

広井さんは小さく頷いた。それだけだった。

研修が始まる前、広井さんが黒板に書いた。「OTAをやる前に、まずセキュリティの話をしなければならない」

「セキュリティとOTAは、切り離せない。OTAは車載ソフトを無線で書き換える仕組みだが、その通信経路が攻撃されれば、悪意ある第三者が車のファームウェアを書き換えることになる。ここでUNECEの二つの規制を整理しておく。UN-R155が要求するのはCSMS（Cyber Security Management System）――車両のライフサイクル全般にわたるサイバーセキュリティ管理。UN-R156が要求するのはSUMS（Software Update Management System）――OTAを中心としたソフトウェア更新の管理。R155がサイバーセキュリティ全般、R156がOTAアップデート管理、と対で覚えるといい。セキュリティなしのOTAは、鍵のかかっていない家に宅配物を置いていくようなものだ」

部屋の空気が少し引き締まった気がした。僕の横で太田さんが「......セキュリティ、最初にやるんですね」と呟いた。広井さんは頷いた。

「そこから始める」と広井さんは言った。

「OTAは、物理ケーブルや整備工場なしに、無線通信でソフトウェアを更新する仕組み。スマートフォンのOSアップデートと原理は同じ。でも、車載では根本的に違う問題がある」

「三つの違いを言う」

「一つ目、リアルタイム性。スマホのアプリが更新中に落ちても、再起動すれば済む。車のブレーキECUが更新中にフリーズしたら、走行中の車が暴走する。更新は"安全な状態"でしか実行できない」

「二つ目、複雑性。スマホは一つのOSと数百のアプリ。車は100以上のECUが異なるOSで動き、それぞれに異なるソフトウェアが走る。どのECUをどの順番でアップデートするかが、システム全体の整合性に影響する」

「三つ目、規制。スマホアプリは更新しても認証は不要。でも車は型式認証を受けた製品。ソフトウェアを変えたら、その変更が型式認証の範囲内かどうかを確認する義務がある。これを管轄するのがUNECEのR155とR156という国連規制と、ISO 24089というOTAエンジニアリング規格だ」

用語
SDV（Software Defined Vehicle）：車の機能・性能・体験がソフトウェアで定義・制御・更新される車。対義語はHDV（Hardware Defined Vehicle）。

OTA（Over The Air）：無線通信によるソフトウェア更新。SOTA（Software Over The Air）はソフトウェア本体の更新、FOTA（Firmware Over The Air）はファームウェアの更新を指す。

その日のノート。

剛志のノート（27）
・SDV：ソフトウェアで車の機能・性能が定義・更新される。出荷が出発点。
・OTA＝無線でのソフトウェア更新。原理はスマホ同様。でも3つの大きな違い：
①リアルタイム性（更新中に失敗したら車が危ない）
②複雑性（100以上のECU、それぞれが違うOS）
③規制（型式認証との整合性が必要：R155/R156/ISO 24089）
・中国では2週間に1回アップデートも珍しくない。でも「安全は大丈夫か」がPart 4の全て。

第28章　安全とOTA ―― 二つはどこで衝突するか

OTA.002・OTA.003：ISO 26262と機能安全、そしてOTAが衝突する三つのポイント

「OTAとISO 26262（機能安全）はどこで衝突するか」と広井さんは言った。「三つある」

「第一の衝突点：ソフトウェア更新後の安全性」

「ISO 26262は、開発フェーズで安全分析をして、ASILを割り付けて、検証して、型式認証を受ける。これは開発段階の話。でも、OTAで更新したら"別のソフトウェア"だ。更新後のソフトウェアは、元の認証を引き継げるのか？　それとも再認証が必要なのか？」

「これが業界で論争になってる問題の一つで、ISO 24089（ソフトウェア更新エンジニアリング規格）が扱っている」

「第二の衝突点：更新中の安全」

「ASIL DのブレーキECUを更新中、システムはどういう状態にあるか。更新パッケージを受信中、古いソフトと新しいパッケージが共存する状態。インストール中、フラッシュを書き換え中。この間、ブレーキが効くか？　もし更新中にエラーが出てECUがブリックしたら？」

「答え：更新は必ず"パーク状態（駐車中、エンジン停止）"でしか実行しない。さらに、更新前に旧バージョンのバックアップを取り、失敗したら自動ロールバックする。これが"二重化ストレージ（デュアルバンク）"アーキテクチャだ」

「第三の衝突点：型式認証の継続性」

「UN-R156は、OTAによる更新を行うすべての車に対して、OTA管理システム（SUMS：Software Update Management System）を持つことを要求している。SUMSは更新の全履歴を管理し、更新内容が型式認証の範囲内であることを確認する。これが守られないと、法的に車を運行できない」

デュアルバンクアーキテクチャ

「デュアルバンクについて少し詳しく話す」と広井さんは続けた。「ストレージを二つのバンク（A/B）に分ける。現在動いているのがバンクA。新しいファームウェアをバンクBに書き込む。書き込み完了後、ハッシュ検証が通ったら、次回起動時にバンクBから起動する。起動に成功したら、バンクAが旧バージョンのバックアップになる」

「もし起動に失敗したら？」

「自動的にバンクAに戻る。これが"フェイルセーフロールバック"だ。人間が何もしなくても、車は自力で元の状態に戻る」

「Androidスマホも同じアーキテクチャですよね」と僕は言った。

「そう。発想は同じ。ただ、車の場合は対象が分散している。とはいえ"100個のECU全部にデュアルバンクを積む"わけじゃない。実際には、IVI、ADC（自動運転コンピュータ）、ゾーンコントローラといった重要かつ更新頻度の高い大容量ECUにデュアルバンクを実装する。一方で、メモリの限られたシンプルなECUは、Bootloader経由のフォールバック方式――更新失敗時にBootloaderが旧イメージで再書き込みする――など、別の仕組みでロールバック性を担保する。それでも、コストと設計の複雑さがスマホの比じゃない、というのは変わらない」

その日のノート。

剛志のノート（28）
・OTAとISO 26262の三つの衝突点：
①更新後の安全性（再認証が必要か）→ ISO 24089が規定
②更新中の安全（ブリックしたら？）→ パーク限定更新＋デュアルバンク＋ロールバック
③型式認証の継続性（UN-R156/SUMS）→ 更新履歴管理と認証範囲の確認義務
・デュアルバンク（A/Bバンク）：新版をBに書き込み、検証OK→Bで起動、失敗→Aに戻る。
・車載は対象が分散：重要・大容量ECU（IVI／ADC／ゾーン）にデュアルバンク、シンプルECUはBootloaderフォールバック等で代替。それでもコストと複雑さがスマホの比じゃない。

第29章　ISO 24089とUN-R156 ―― 規制の網をくぐる

OTA.004・OTA.005：法的フレームワーク ― ソフトウェア更新エンジニアリング規格と型式認証

「OTAに関する規制の話をしよう」と広井さんは言った。「二つが重要だ」

ISO 24089 ―― エンジニアリングの規格

「ISO 24089は2023年に発行された、ソフトウェア更新エンジニアリングの規格。開発者側が守るべきプロセスと技術要件を定義している」

「主要な要求事項を箇条書きで言う」

　・更新の安全性分析：更新がシステムの安全性に与える影響を事前に分析する

　・更新のトレーサビリティ：誰が、いつ、何を、どの車に更新したかを記録する

　・更新の検証：更新後のソフトウェアが要求を満たすことを検証する

　・ロールバック機能：更新失敗時に元に戻せる仕組みを持つ

　・更新の整合性確認：改竄されていないことを暗号的に確認する（署名・ハッシュ）

　・更新の認可：誰が更新を承認したかのプロセスを持つ

「このうち"更新の安全性分析"が、機能安全（ISO 26262）やSOTIF（ISO 21448）と直接リンクする。ASIL関連機能のソフトウェアを更新するなら、更新後も同じASILを維持しているか、または新たな安全分析をやり直す必要があるか、を判断する」

UN-R156 ―― 型式認証の規制

「UN-R156はUNECEの法規制。2022年から欧州・日本・韓国等で発効している。新型車には適用必須で、SUMS（Software Update Management System）の整備を義務づける」

「SUMSに要求されること――」

　・更新が型式認証の条件に影響するか否かを判断するプロセス

　・更新が型式認証の範囲内なら認証変更不要、範囲外なら再認証

　・全更新の履歴管理（どの車に、いつ、何が入ったか）

　・更新の完全性と真正性の保証（暗号署名）

「型式認証に"影響する変更"とは何か？」と僕は聞いた。

「例えば、ASIL D機能のコアロジックを変更したら影響する。逆に、UI画面のレイアウト変更や、ログの出力フォーマット変更は影響しない。この判断基準が、メーカーと認証機関の間で合意されている必要がある」

「つまり、更新ごとに"これは型式認証に影響するか？"というゲートチェックが入るわけですね」

「その通り。これが、スマホのアプリ更新と根本的に違うところだ。スマホはリリースしたら終わり。車は更新のたびに責任が伴う」

その日のノート。

剛志のノート（29）
・ISO 24089：OTAエンジニアリング規格。安全性分析・トレーサビリティ・検証・ロールバック・署名・承認プロセス。
・UN-R156：型式認証規制。SUMS整備を義務化。更新が認証範囲に影響するか否かを判断するプロセスが必須。
・更新ごとに「型式認証影響有無」のゲートチェックが入る。
・スマホ更新≠車載OTA：車は更新のたびに法的責任が伴う。

用語
Uptane：自動車向けセキュアOTAのためのオープンソースフレームワーク。米国SwRI（Southwest Research Institute）主導で開発され、汎用ソフトウェア更新の枠組み**TUF（The Update Framework）**を車両向けに拡張したもの。Director Repository／Image Repositoryといった複数の役割と多重署名を組み合わせて、攻撃者が単一のサーバーや鍵を奪っても車両が悪意ある更新を受け入れない設計になっている。ISO 24089の実装規範としてしばしば参照され、量産OEMのOTAバックエンドの基盤としても採用されつつある。

第30章　ASIL分解とOTA ―― 安全機能を分離する戦略

OTA.006：ASIL分解とOTA ― 安全機能を分離して更新する

「ASIL関連機能のOTA更新は、非ASIL機能の更新より格段に難しい」と広井さんは言った。

「なぜか。ASIL D機能のソフトウェアを更新するとき、更新後のソフトウェアが"以前と同じASIL D要件を満たしているか"を検証しなければならない。これには、更新前と同じレベルの安全分析・テストが必要になる場合がある」

「毎回フルの安全分析をやり直してたら、OTAの意味がないですよね」と僕は言った。

「そうだ。だから、アーキテクチャ設計の段階で"更新しやすいソフトウェアの分割"を考えておく必要がある」

安全関連機能と非安全関連機能の分離

「良い設計とは、ASIL関連のコアロジック（頻繁には更新しない）と、非ASIL機能のアプリケーション層（頻繁に更新する）を、明確に分離しておくことだ」

「カイトのADCでは、こんな設計にしている」

安全コア層（ASIL D / 年に0〜1回更新）:
・緊急ブレーキ判定ロジック
・フォールト検出と安全状態移行
・ASIL D要求のセンサー監視
アプリケーション層（QM〜ASIL B / 月に1〜数回更新可能）:
・ルート最適化アルゴリズム
・UI/HMI機能
・地図データ更新
・エネルギーマネジメント最適化
MLモデル層（別管理 / 頻繁更新）:
・NNモデルの重みファイル
・SOTIFの文脈での継続的改善対象

「アプリケーション層を更新するとき、安全コア層は変えない。だから安全コア層の再検証は不要。アプリ層のみの限定的なレグレッションテストで済む」

「これがASIL分解とOTAを組み合わせた設計戦略の核心だ」

「MLモデル層は別管理で、SOTIFの観点から独立して扱う。モデルを更新しても、安全コア層は変わらないので、コア層の再検証は不要。ただし、モデルの挙動変化によるシステム全体への影響は、SOTIFの手法で評価する」

その日のノート。

剛志のノート（30）
・ASIL関連機能のOTA更新＝高コスト（再安全分析が必要な場合あり）。
・解決策：ASIL機能（安全コア層）と非ASIL機能（アプリ層）を設計段階から明確に分離。
・アプリ層は頻繁更新可能。安全コア層は年0〜1回。
・MLモデル層は別管理。SOTIFの文脈で評価。
・アーキテクチャ設計時点でのOTA対応が、後の更新コストを大きく左右する。

第31章　更新後の再検証問題

OTA.007：更新後の再検証 ― どこまでテストをやり直すか

「更新後、どこまでテストをやり直すか。これがOTAプロジェクトで最もよく議論になる問題だ」と広井さんは言った。

「極端な話、毎回のOTA更新のたびに、開発時と同じフルセットのテストをやり直すことは不可能だ。テスト工数だけで数ヶ月かかる。でも、何もテストしないのは論外だ」

「答えは"インパクトベースのレグレッションテスト"だ」

「更新した部分、更新した部分に依存する部分、その範囲に絞ってテストをやり直す。これが"インパクト分析"だ。A-SPICEのSUP.10（変更管理）でやることと本質は同じで、"この変更が何に影響するか"を分析し、影響範囲のテストケースだけを選択する」

「具体的な例を見よう」

更新内容：エネルギーマネジメントSW-Cの回生ブレーキ最適化ロジックを修正
影響範囲の分析：
・回生ブレーキ指令の出力値が変わる可能性あり
・ブレーキECUとの通信に影響する可能性あり
・ASIL Dのフットブレーキ制御には直接影響しない（設計上分離済み）
やり直すテスト：
・回生ブレーキの単体テスト（SWE.4相当）
・ブレーキ統合テスト（SWE.5相当）
・エネルギー回収効率の検証
省略するテスト：
・ASIL D機能（AEBSなど）の再テスト（影響なしと判断）
・自動運転DNNモデルの再評価（変更なし）

「"影響なし"という判断は、どう担保するんですか？」と僕は聞いた。

「トレーサビリティだ。変更したコンポーネントから、すべての上位要求と下位実装へのリンクをたどる。リンクのない要求は影響なし。リンクのある要求にはテストケースがある。これを選択する」

「A-SPICEのトレーサビリティが、OTAの再検証にも効いてくるわけですね」

「その通り。プロセスは繋がっている。A-SPICEで地道に作ったトレーサビリティが、OTA更新のたびに効率的な再検証を可能にする。地道な作業が長期的に報われる典型例だ」

その日のノート。

剛志のノート（31）
・更新後は「インパクトベースのレグレッションテスト」。全部やり直しは不可能。
・インパクト分析：変更した部分＋依存する部分を特定し、その範囲のテストを選択。
・判断の根拠はトレーサビリティ。変更コンポーネントからリンクをたどる。
・A-SPICEで作ったトレーサビリティがOTAの再検証効率に直結する。
・Part 1（A-SPICE）→ Part 4（OTA）の具体的な連携がここ。

第32章　ロールバックの夜

OTA.008：ロールバックと機能安全 ― 失敗したとき何が起きるか

それは、カイトのOTA検証テスト中の出来事だった。

テストベンチの車両に、コネクテッドチームが新しいバージョンのパワートレインソフトウェアを送り込んだ。受信は完了、ハッシュ検証もOK。インストール開始。バンクBへの書き込みが始まった。

50%のところで、何かが起きた。

ストレージのフラッシュ書き込みエラー。インストールが中断した。

「こういうとき、どうなるか、見ておこう」と広井さんは落ち着いて言った。「実際の障害シナリオだ。ログを見ていて」

ECUのログには、こう記録されていた。

[OTA Manager] Flash write error at 50% of Bank B
[OTA Manager] Bank B installation aborted
[OTA Manager] Verifying Bank A integrity...
[OTA Manager] Bank A: OK (version 1.4.2, hash verified)
[OTA Manager] Rollback: Boot from Bank A on next restart
[Safety Monitor] No safety-critical function affected during rollback
[OTA Manager] Rollback complete. Vehicle operational on 1.4.2

「見ての通り、バンクBへの書き込みが50%で失敗した。ロールバックロジックが起動して、バンクAの整合性を確認し、バンクAから起動するよう設定した。再起動後、旧バージョン1.4.2で正常動作している」

「でも、バンクBの中身はどうなってますか？」と僕は聞いた。

「半分書かれた状態で残ってる。でも起動はバンクAからだから、バンクBの内容はシステムに影響しない。次の更新試行時にバンクBが上書きされる」

「更新中に電源が落ちたらどうなりますか？」

「デュアルバンクのポイントはここだ。書き込み中にどんな形で電源が落ちても、バンクAは触っていない。起動時にBootloaderがバンクBのハッシュを確認して、不正なら問答無用でバンクAから起動する。バンクAは常に最後に動作が確認されたバージョンだから、車は必ず動く状態に戻る」

「これが"機能安全的に設計されたロールバック"の本質だ。不確実な状態を許容しない。失敗は即座に検出し、既知の安全な状態に戻る」

「フェイルセーフの原則ですね」とニックさんが言った。

「その通り。OTAはソフトウェア技術だが、設計思想は機能安全と同じだ」

その日のノート。

剛志のノート（32）
・ロールバックのシナリオ：書き込み50%で失敗→バンクA整合性確認→バンクAから起動→旧版で安全動作。
・電源断でも安全：Bootloaderがバンクのハッシュを確認。不正なら自動的にバンクAへ。
・デュアルバンクの本質：「車は常に最後に動作確認されたバージョンで動ける」保証。
・OTAの設計思想＝機能安全の思想。「不確実な状態を許容しない。既知の安全状態に戻る」。

第33章　Adaptive AUTOSARとOTAアーキテクチャ

OTA.009：Adaptive AUTOSARとOTA ― 次世代車載ソフト基盤との関係

「OTAを実現するためのソフトウェア基盤、特に新世代の車載ECUでは何が使われているか。これはPart 5（AUTOSAR）と直接繋がる話だが、OTAの文脈で触れておく」と広井さんは言った。

「AUTOSAR（AUTomotive Open System ARchitecture）には二つの世代がある。Classic AUTOSARと、Adaptive AUTOSARだ。詳しくはPart 5でやるが、OTAとの関係でいうと、ここが重要だ」

　Classic AUTOSAR（古典型ECU向け）：

　　・固定されたRTE（Runtime Environment）

　　・ソフトウェアコンポーネントはコンパイル時に統合

　　・アップデート＝ECU全体の書き換え

　Adaptive AUTOSAR（高性能ECU向け）：

　　・POSIXベースのOS（AUTOSAR OS Adaptive）

　　・サービス指向アーキテクチャ（SOA）

　　・アプリケーションを動的に追加・更新可能

　　・UM（Update and Configuration Management）という専用のOTA管理機能あり

「Classic AUTOSARでのOTAは、ECU全体を丸ごと書き換える形が基本。100KBのパッチを当てたいだけでも、数MBのフルイメージを転送することがある」

「Adaptive AUTOSARでは、アプリケーション単位での更新が可能。機能Aだけ更新、機能Bは据え置き、みたいなことができる。これはOTAの効率と安全性を大きく改善する」

「カイトのADCはAdaptive AUTOSARベースで設計されている理由の一つがこれだ。自動運転機能は頻繁に改善されるから、細粒度のOTA更新が必要だ」

その日のノート。

剛志のノート（33）
・Classic AUTOSAR：固定統合。OTAはECU全体書き換え。大きいし非効率。
・Adaptive AUTOSAR：動的・SOA。アプリ単位で更新可能。OTAに向いている。
・Adaptive AUTOSARのUMはOTA管理専用機能。
・カイトのADCはAdaptive AUTOSAR：自動運転機能を細粒度で頻繁更新するため。
・Part 4（OTA）→ Part 5（AUTOSAR）の直接的な繋がりがここ。

第34章　OTAのまとめ ―― チェックリストと展望

OTA.010：まとめ ― OTAセーフティ設計のチェックリストと今後の展望

「Part 4の最後に、OTAセーフティ設計のチェックリストを渡す。これを全部クリアできる設計なら、車載OTAとして合格点だ」と広井さんは言った。

OTAセーフティ設計チェックリスト
【更新実行条件】
□ パーク状態（または安全な状態）でのみ更新を開始する
□ 更新中は安全機能を停止させない（または安全状態に移行させる）
【整合性保証】
□ 更新パッケージに暗号署名を付与し、ECU側で検証する
□ ハッシュによる完全性確認
□ 不正パッケージはインストール拒否
【ロールバック】
□ デュアルバンクアーキテクチャ（または同等の機構）を実装
□ インストール失敗時の自動ロールバック
□ 電源断でも安全な状態に戻れる
【安全性確認】
□ ASIL関連機能の更新には追加の安全分析を実施
□ インパクト分析に基づいたレグレッションテスト
□ 更新後の型式認証影響評価（SUMS）
【トレーサビリティ】
□ どの車両に、いつ、何が更新されたかを記録（ISO 24089/UN-R156準拠）
□ フリート全体のバージョン管理（車両ごとに何のバージョンが入っているか把握）
【フリート管理】
□ Canary Release戦略（少数台から段階的に展開）
□ 問題発生時の緊急停止と自動ロールバックの仕組み
□ 更新失敗率・介入率のモニタリング指標

「最後に展望を言う。これからのOTAで最大の課題は"MLモデルのOTA"だ」

「従来のソフトウェアOTAは、コードを書き換える。挙動は確定論的に変わる。でも、NNモデルのOTAは重みファイルを書き換える。挙動が確率的に変わる。"更新後のモデルが以前より良いことを、どう証明するか"という問いに、業界はまだ完全な答えを出せていない」

「これがSOTIF（Part 3）と直結する問題で、これからの5〜10年で業界が格闘し続けるテーマだ」と広井さんは結んだ。

その夜のノート。

剛志のノート（34・OTA まとめ）
① SDV：出荷が出発点。ソフトが車を進化させる。
② OTAの3つの挑戦：リアルタイム性、複雑性、規制（R155/R156/ISO 24089）。
③ OTA×機能安全の3衝突点：更新後安全性、更新中安全、型式認証継続性。
④ デュアルバンク：フェイルセーフロールバックの技術的基盤。
⑤ ASIL分離：安全コア層とアプリ層を分けて、頻繁更新を安全に実現。
⑥ レグレッションテスト：インパクト分析＋トレーサビリティで最小化。
⑦ SUMS/UN-R156：型式認証への影響評価が毎回必要。
⑧ Adaptive AUTOSAR：細粒度OTAを可能にするソフト基盤。Part 5へ続く。
⑨ 最大課題：MLモデルのOTA。挙動変化の確率的性質。SOTIFと不可分。