ISO 21448（SOTIF）とは — 「故障なき不具合」と想定外動作の安全
ISO 21448（SOTIF）は、自動車の安全関連システムが「故障していないにもかかわらず」危険な状態を引き起こすリスクを扱う国際規格である。機能安全のISO 26262が「故障」に起因するハザードを対象とするのに対し、SOTIFは「仕様の不十分さ」や「性能限界」に起因するハザードを対象とする。本記事は、SOTIFが何を扱う規格か、ISO 26262とどう役割が違うのか、AI時代になぜ重要性が増すのか、SDV（ソフトウェア・デファインドな車）の設計にどう効くのかを整理する。結論を先に言えば、SOTIFは「完璧なシステムは存在しない」という前提から出発し、性能限界が安全に管理されていることを体系的に論証する規格である。
ISO 21448とは何か
ISO 21448:2022とは、意図した機能の性能限界や仕様の不足に起因するハザードを管理するための国際規格であり、2022年に発行された（出典：ISO 21448:2022）。機能安全（ISO 26262）が「壊れたときの安全」を、SOTIFが「壊れていないのに想定外に振る舞うときの安全」を担う。両者は補完関係にある。
「故障なき不具合」——SOTIFが扱う領域
SOTIFの概念を端的に表すのが「故障なき不具合」である。たとえば、カメラベースの歩行者検出が逆光で歩行者を検出できなかった場合——これはハードの故障でもソフトのバグでもない。システムは設計どおりに動いているが、設計時の「想定」が現実の使用条件をカバーしきれていなかった、という問題だ。SOTIFはこの「想定の限界」を体系的に管理する。
ISO 21448は、システムの動作領域を4つに分類する。整理すると次のようになる。
| 領域 | 状態 | SOTIFの目標 |
|---|---|---|
| 既知の安全 | 想定条件下で安全に動作 | 拡大する |
| 既知の不安全 | 既知の性能限界がある | 縮小する |
| 未知の不安全 | 未発見の性能限界がありうる | できる限り縮小する |
| 未知の安全 | 未検証だが安全と推定 | — |
SOTIFの狙いは、「未知の不安全」を可能な限り縮小し、「既知の安全」を拡大することにある。
トリガー——性能限界を引き起こすきっかけ
SOTIF分析の核心は「トリガー」（性能限界を引き起こすきっかけ）の特定である。センサー関連では悪天候・逆光・夜間・センサー汚れ・電磁干渉など、アルゴリズム関連では学習データに含まれない物体、複雑な交通シナリオ、地域固有の交通ルールなどがトリガーになる。これらをパラメータ化し、シナリオベースの検証で体系的に網羅・評価していくのが、SOTIF準拠の検証プロセスの中核になる。
AI時代のSOTIF——AI安全規格との境界
AIの採用が進むと、SOTIFの分析には構造的な緊張が生じる。ルールベースの運転支援では、トリガーは「センサーの性能限界」として比較的明確に特定できた。しかし、端から端まで一つのAIモデルで処理する方式では、膨大なパラメータを持つネットワークが「なぜ」特定の入力で誤った出力を出すのかの説明が難しく、入力空間のどこでトリガーが発現するかを網羅的に特定することが原理的に困難になる。
業界では、SOTIFが「入力条件（環境・センサー）に起因する限界」を、AI安全規格（ISO/PAS 8800）が「AI/MLモデル自体の特性に起因する限界」を、それぞれ対象とする方向で整理が進む。ただし実務上この境界は曖昧で、両規格を統合的に適用するのが現実的だ。
SDVアーキテクチャとの統合——ODD管理が中核
SOTIFをSDVに統合するうえで中核になるのがODD（運用設計領域＝システムが安全に動作できる条件の範囲）の管理である。ODD境界の判定——いま安全に動作できる条件内にいるか否かのリアルタイム判定——を、安全度の最も高い決定論的な安全制御領域の責務として実装する。AI推論領域がODD境界を超えた条件で動いていると判定されれば、安全制御領域が段階的に介入し、最終的に最小リスク状態（MRC）への移行を保証する。
この設計では、設計段階の目標ODDと走行中のリアルタイムODDを照合し、その乖離をトリガーの発現として検出する。AI推論の不確実性を、形式検証済みの安全制御が監視・制約する二層構造によって、トリガー発現時の安全を担保する——これが、SOTIF要件をアーキテクチャレベルで構造的に満たす手法になる。さらにSOTIFは、市場投入後も継続的にデータを収集して新たなトリガーを発見・対応する「市販後の活動」も求めており、AIのデータライフサイクル管理と連動する。
まとめ：SOTIFは「限界の管理」を体系化する
SOTIFの要点は、性能限界の存在を前提に、それが安全に管理されていることを体系的に論証することにある。機能安全（壊れたときの安全）とは別軸の安全であり、AI時代にはAI安全規格と統合して使う。自社で具体化する際の論点は次のあたりだ。
- 自社システムのトリガー（環境・データ起因の性能限界）をどう洗い出し、検証に落とすか。
- ODD境界の判定と離脱動作を、安全制御領域にどう実装するか。
- 市販後のデータ収集を、トリガー発見と再発防止のループにどうつなぐか。
機能安全との関係はISO 26262と機能安全・ASILの構造を、規制・安全対応の経営インパクトはSDVとサイバーセキュリティ／法規制の経営インパクトを、SDV全体像は【SDV入門】経営層が掴むSDVの全体像をあわせて参照してほしい。自社の機能・ODDに即したSOTIF分析は個別性が高く、具体化の段階では外部の視点を入れると論点整理が速い。