SOTIF（ISO 21448）とは何か：安全なのに危険になる問題を扱う規格
🧭 はじめに
SOTIF（Safety Of The Intended Functionality）は、**自動車の先進運転支援（ADAS）や自動運転（AD）**のようなシステムにおいて、
- 「故障していないのに」
- 「設計通りに動いているのに」
- 「それでも危険になる」
というタイプの安全課題を扱う考え方・規格です。 規格としては ISO 21448 が SOTIF に対応します。
SOTIF は ISO 26262（機能安全）と対立するものではなく、26262ではカバーしづらい危険領域を補う位置づけです。
🧩 まず結論：SOTIFが扱うのは「意図した機能が危ない」ケース
自動車の安全規格の大枠は、こう整理すると理解が速いです。
🧯 ISO 26262（機能安全）
- 対象：故障（ランダム故障、設計不具合）
- 例：センサー断線、ECU暴走、メモリ破損で誤作動
🛰️ ISO 21434（サイバーセキュリティ）
- 対象：攻撃（悪意ある介入）
- 例：CAN注入、OTA改ざん、鍵漏洩
👀 SOTIF（ISO 21448）
- 対象：意図機能の限界・不完全さ
- 例：カメラは正常だが、霧で白線が見えず誤認識する
SOTIFは「故障でも攻撃でもないのに危ない」を扱う、と覚えるのが一番わかりやすいです。
🚗 SOTIFが重要になった背景：ADASの安全問題は“故障”だけでは説明できない
従来の自動車は、危険の多くが
- 機械的な故障
- 電子部品の故障
- ソフトウェアのバグ
で説明できました。
しかし ADAS/AD は違います。 環境を認識して判断するため、「正常動作」でも危険になります。
🔍 SOTIFが扱う代表例（イメージが掴めるケース）
🟠 ケース1：検知できない（センサーの限界）
- 逆光で歩行者を見落とす
- 夜間で黒い服の人が検出しにくい
- 雪で白線が消える
故障ではなく、設計上の限界です。
🟠 ケース2：誤認識する（知覚の誤り）
- 標識を誤読する
- 影を障害物と誤検出する
- 反射で車線を誤認識する
システムは「ちゃんと推論」したが、結果が間違う。
🟠 ケース3：仕様は正しいが、前提が崩れる
- 想定外の道路形状
- 予想外の交通ルール（海外）
- 工事中で臨時標識だらけ
SOTIFの難しさは「システムは正常」のため、従来型の“故障前提の安全設計”が効きにくい点です。
🧠 「意図した機能」って何？
SOTIFの “Intended Functionality（意図した機能）” は、要するに
- このシステムは、こういう目的で
- こういう範囲で使う前提で
- こう振る舞うように設計している
という 仕様そのものです。
例：
- レーンキープ：高速道路の車線維持を支援する
- 自動ブレーキ：対象を検知したとき衝突を回避/軽減する
ここで重要なのは、「仕様に書けない現実」が必ず残る点です。
🧊 SOTIFの本質：未解決の危険領域が必ず残る
SOTIFでは危険をざっくり分けると、次のようになります。
✅ Known Safe（安全だと分かっている領域）
- 十分に検証できた
- 仕様通りに安全に動く
⚠️ Known Unsafe（危険だと分かっている領域）
- 弱点が分かっている
- 対策・制限が必要
❓ Unknown Unsafe（危険だと分かっていない領域）
- まだ気づいていない危険
- 実際に事故やヒヤリで発覚する
SOTIFで本当に怖いのは Unknown Unsafe です。これは「故障解析」だけでは見つけにくいです。
🧪 SOTIFで重要になる開発アプローチ：テストというより“探索”
ISO 26262 は「故障を想定して潰す」が中心です。 一方 SOTIF は「事故になる状況を探しに行く」が中心です。
🔎 1) シナリオベースで危険を洗う
- どんな道路
- どんな天候
- どんな交通状況
- どんな速度域
で危険になるかを体系化します。
🧫 2) データ不足を認識する
機械学習を使う場合は特に、
- 学習データが偏っている
- 珍しいケースを見ていない
- ラベル品質が悪い
が「正常動作だが危険」を誘発します。
🧰 3) 対策は“安全停止”や“制限”も含む
SOTIFの対策は必ずしも「100%検知」ではありません。
- 検知できないと判断したら抑制する
- 条件が悪いときは機能制限する
- 運転者へ明確に返す（Take Over）
SOTIFでは「できない時はやらない」という設計が、むしろ高度な安全設計になります。
🧱 ISO 26262 と SOTIF の棲み分け（混乱しやすいポイント）
✅ ISO 26262 が強い領域
- センサー断線
- ECU故障
- ソフトのバグ
- 仕様逸脱（期待しない動作）
→「壊れたから危ない」
✅ SOTIF が強い領域
- 認識限界
- 誤検知 / 見落とし
- 想定外環境
- MLの不確実性
→「壊れてないのに危ない」
実務では「これは26262？SOTIF？」が混ざります。両方から見て安全を成立させるのが正解です。
🧩 SOTIFの“仕様設計”で重要なこと
📌 1) ODD（運用設計領域）を定義する
ODD（Operational Design Domain）は、
- この機能はこの条件で使う
- それ以外は使わない（使えない）
を明確にする枠です。
例：
- 高速道路のみ
- 晴天または小雨まで
- 車線が明瞭な道路
- 特定速度域
ODD は「逃げ」ではなく、安全保証の境界です。
📌 2) フェイルセーフではなく “フェイルオペレーショナル” の話になることがある
壊れたら止めればいい、が通じないケースがあります。
- 止まったら危険（高速道路）
- すぐ停止できない（周囲状況）
なので、SOTIF領域は 「安全に継続する」「安全に引き継ぐ」設計に寄ります。
🧾 まとめ
SOTIF（ISO 21448）は、ADAS/自動運転のようなシステムで起きる
- 故障でもなく
- 攻撃でもなく
- 意図通り動作しているのに危険になる
という問題を扱うための規格です。
ポイントは次です。
- SOTIFは「意図機能の限界」を扱う
- 危険は “未知の危険（Unknown Unsafe）” が残る
- シナリオ探索とODD定義が重要
- ISO 26262 と補完関係にある
SOTIFを理解すると「安全=壊れないこと」ではなく、現実世界の不確実性と向き合うことだと見えるようになります。