小説で学ぶ自動車ソフトウェア開発 (その6) SOTIF

本エントリーは、小説で学ぶ自動車ソフトウェア開発（車載ソフトウェア開発）のシリーズものです。その１、その２、その３、その４も是非ご覧ください。

前回の「その5」では、Part 2として機能安全、すなわちISO 26262とASILの世界を見てきた。

機能安全が扱うのは、「故障したときに、人を傷つけないためにはどうするか」という問いである。ECUは壊れる。センサーは故障する。メモリは化ける。だからこそ、故障を前提に、HARAで危険を洗い出し、ASILで安全度を決め、フェイルセーフやフォールトトレランスで安全な振る舞いを設計する。それがPart 2で見てきた世界だった。

しかし、自動運転やAIが車に入り始めると、それだけでは説明できない危険が現れる。

ハードウェアは壊れていない。ソフトウェアにもバグはない。仕様通りに動いている。それなのに、特定の天候、照明、道路環境、センサー条件のもとで、システムが危険な判断をしてしまうことがある。

今回の「その6」では、Part 3として SOTIF――ISO 21448 の世界に入る。

SOTIFが扱うのは、「壊れていないのに、なぜ危ないのか」という問いである。これはAIと自動運転の時代に、自動車ソフトウェア開発が直面している、最も新しく、最も難しいテーマの一つでもある。

Part 3　SOTIF ―― 壊れていないのに危険な話

Part 2が「壊れたとき」を扱うなら、

Part 3は「壊れていないのに、危ない」を扱う。

これは、AIが自動運転に入ってきたことで生まれた、

人類がまだ解決策を探している新しい問いだ。

第26章　正常なのに、なぜ危ない？ ―― SOTIFという新しい恐怖

SOTIF.001：ISO 21448 ― 機能不十分による危険とその対処

カイトプロジェクトが機能安全フェーズを一通り終えたある夜、僕はオフィスの小会議室でニックさんと残業していた。彼女は自動運転チームのコード──センサーフュージョンのニューラルネットワーク推論エンジン──を見ていた。

「成田さん」とニックさんは言った。彼女はいつも「成田くん」じゃなくて「成田さん」と呼ぶ。「ちょっと見てほしいんですけど、このシナリオ、ISO 26262のどのASILに当てはまると思います？」

彼女が見せたのは、テスト結果のログだった。夕暮れ時、逆光の条件で撮影した高速道路の映像を、カメラ系のNNモデルに入力すると、前方車両の検出スコアが0.4まで落ちていた（通常0.8以上）。ただし、モデルは壊れていない。ハードウェアも正常。ソフトウェアもバグなし。ただ、特定の照明条件下で、AIの性能が著しく低下していた。

「これ、ISO 26262のFMEAに載せると思いますか？」とニックさんは聞いた。

僕は考えた。FMEAは"故障モード"を列挙する。でも、これはモデルの故障じゃない。正常に動いているモデルが、性能限界に当たっているだけだ。

「これは......FMEAには乗らないですよね。故障してないから」

「そうなんです」とニックさんは言った。「でも、このまま量産に出たら、夕暮れ時の逆光で前の車を認識できなくて事故が起きます。どこに書けばいい話なんですか？」

翌朝、僕は中月さんにその話を持っていった。中月さんは静かに聞いて、それから「それがSOTIFだ」と言った。

「SOTIF、ISO 21448。Safety Of The Intended Functionality。日本語で言えば "意図した機能の安全性"。歴史的には、2019年に ISO/PAS 21448（PAS：Publicly Available Specification、暫定仕様書）として初版が発行され、2022年に ISO 21448:2022 として正式な国際規格に格上げされた。これが扱うのは、機能安全（ISO 26262）が扱えない領域、"故障ではない性能限界"による危険だ」

「つまり、"正常に動いているのに危ない" という状況ですね」

「そうだ。ISO 26262は"壊れたとき"の話。SOTIFは"壊れていないのに危ないとき"の話。補完的に機能する」

中月さんはホワイトボードに四つの象限を描いた。

SOTIFの4象限
│ 既知　　　│ 未知
─────────────────────
安全でない　│ 領域①　　│ 領域②
安全　　　　│ 領域③　　│ 領域④
領域①：既知の安全でないシナリオ（識別済みの性能限界）
領域②：未知の安全でないシナリオ（まだ識別されていない性能限界）
領域③：既知の安全なシナリオ（検証済みの正常動作域）
領域④：未知の安全なシナリオ（検証はしてないが安全と思われる域）

「ニックさんが見つけたのは、まさに"領域①"だ。夕暮れ時の逆光での性能低下、というシナリオは"既知の安全でないシナリオ"に分類される。SOTIFでは、このシナリオを識別して、対策を設計する」

「対策は？」と僕は聞いた。

「いくつかある。一つ目はODD（Operational Design Domain）の制限。"夕暮れ時・逆光条件ではこの機能を作動させない"と、動作条件を絞る。AEBSの場合、特定条件で機能を停止させ、ドライバーに警告する」

「二つ目はデータ収集と再学習。"その条件のデータを大量に集めてNNを再学習する"。これにより、性能限界のシナリオをカバレッジに取り込む。ただし、どれだけデータを集めても、領域②（未知の安全でないシナリオ）をゼロにはできない」

「三つ目はセンサー多様化。カメラ系が弱い条件でLiDARやレーダーで補完する。マルチモーダルで冗長性を持たせることで、単一センサーの性能限界の影響を緩和する」

SOTIFとE2Eの関係

「SOTIFが特に問題になるのはE2E自動運転だ」と中月さんは続けた。「従来型のルールベースシステムなら、"逆光条件での検出基準"をルールとして書ける。でも、E2EのNNは中がブラックボックスだ。"なぜこの条件で性能が落ちるか"の根本的な説明が難しい」

「これがE2Eの安全認証において最も難しい問題の一つだ。ISO 26262のFMEA/FTAは"壊れた原因"を追う。SOTIFは"性能限界のシナリオ"を追う。でも、E2EのNNは、なぜ特定のシナリオで性能が落ちるかを、明確に説明できない」

「だからSOTIFでは"Statistical Validation（統計的検証）"という概念を重視する。何万シナリオも走らせて、統計的に十分な信頼性を確認する。また"Shadow Modeテスト"、つまり人間ドライバーの運転に並行してE2Eモデルを動かし、人間との乖離を記録する手法も有効だ」

「でも、統計的に十分、って、どれくらいで十分なんですか？」とニックさんが聞いた（話しているうちに彼女も合流していた）。

「そこが業界の未解決問題だ」と中月さんは正直に言った。「現時点では明確な基準がない。SOTIFはガイダンスを与えるが、"何件テストすれば十分か"という定量的な基準はまだ確立されていない。それが、E2E自動運転の型式認証が難しい理由の一つだ」

ODD ―― 動かしていい場所を決める

「SOTIFの対策の中で、最も実践的なのがODDの定義だ」

「ODD、Operational Design Domain。この機能がサポートする動作条件の範囲。たとえばカイトのL3自動運転のODDは――」

　道路種別：高速道路および自動車専用道路のみ

　速度範囲：30km/h〜130km/h

　天候：晴天・曇天（雨天・雪・濃霧は対象外）

　照明：昼間および照明付き夜間（夕暮れ時の逆光は要検討）

　地理：HD地図カバレッジ地域のみ

　交通：特殊車両（緊急車両の逆走、工事中のイレギュラー）は対象外

「このODDの外側に出たら、システムはドライバーに制御を引き継ぐか、最小リスク機動に移行する。SOTIFの観点では、ODDを"既知の安全なシナリオ（領域③）"として定義して、その内側での安全を統計的に検証する」

「ODD外のシナリオが領域①（既知の安全でない）と領域②（未知の安全でない）に当たる。領域①は見つけたら対策する。領域②を如何に減らすか、が開発の継続課題だ」

そのとき、廊下から渡会さんが入ってきた。いつもと同じく、無言でホワイトボードの前に立ち、マーカーを手に取った。中月さんが「渡会さん、SOTIFのシナリオ分析の表、見せてもらえますか」と言った。

渡会さんは頷かずに、ただ表を描き始めた。HARAで使ったフォームによく似た表が、数十秒で埋まっていった。列見出しは「シナリオ」「センサー性能条件」「ODD内/外」「SOTIF領域（①〜④）」「対策」----中月さんの4象限が、実務のフォームとして結晶化していた。

「渡会さんは、どんな分析も必ず表にする」と中月さんは僕に言った。「図で語る人だ」

「つまり」とニックさんが整理するように言った。「私が見つけた夕暮れの逆光問題は、SOTIFの文脈では"既知の安全でないシナリオ（領域①）"として記録して、ODDに"夕暮れ時逆光は対象外"と明記して、将来的にデータを集めてNNを改善してカバレッジを広げていく、という流れになるわけですね」

「その通りだ」と中月さんは頷いた。「そしてこれは、Part 4のOTAの話と直結する。NNモデルを継続的に改善してOTAで更新する。そのモデル更新のたびに、SOTIFの観点で再検証する必要がある。どこまでテストすれば再認証が不要か、という問題はまだ解決途上だが」

「だから Part 3 と Part 4 は繋がってるんですね」と僕は言った。

「そうだ。壊れていないのに危ない問題（SOTIF）は、AIモデルを継続更新するOTAと不可分だ。それは、この本の地図の章で藤谷さんが言っていた通り、6つの世界は互いに繋がっているということだ」

その夜のノート。

剛志のノート（26・SOTIF まとめ）
・SOTIF（ISO 21448）＝「故障ではない性能限界」による危険を扱う規格。
・ISO 26262は「壊れたとき」。SOTIFは「壊れていないのに危ないとき」。補完関係。
・4象限：①既知の安全でないシナリオ、②未知の安全でないシナリオ、③既知の安全、④未知の安全。
・SOTIFの対策：① ODD制限（"夕暮れ逆光は対象外"）、②データ収集と再学習、③センサー多様化。
・E2EとSOTIF：NNがなぜ性能低下するかを明確に説明できない＝認証の難所。
・Statistical Validation + Shadow Mode Testが主な検証手法。
・ODD＝システムが動作保証する条件の範囲。外側でドライバー引き継ぎまたは最小リスク機動。
・SOTIFはOTAと不可分。モデル更新のたびに再検証が必要。Part 4へ続く。

（Part 2・Part 3 完）