SOTIF(ISO 21448、意図した機能の安全)

1. 概要

A. 定義

SOTIF(Safety Of The Intended Functionality、意図した機能の安全) とは、システムに何ら故障(malfunction)がないにもかかわらず、意図した機能そのものの性能限界・誤認識・仕様不足によって生じる不合理なリスク(unreasonable risk)からの自由を扱う自動車安全の概念であり、これを体系化した国際規格が ISO 21448:2022 である。「部品が故障していなくても、機能が設計された限界の中で正常に動作していても危険でありうる」という問題意識の上に立っている。

SOTIFが登場した背景は、自動車安全の重心が「故障への備え」から「認知・判断の性能限界への備え」へ移ったことにある。従来の機能安全規格である[[iso-26262]]は、センサ断線、ビットフリップ、ソフトウェア欠陥のように「原因を特定できる故障」がリスクへ波及するのを防ぐ。しかしカメラ・レーダ・ライダと深層学習の認知アルゴリズムに依存するADAS(先進運転支援)・自動運転では、どの部品も故障していないのに逆光で歩行者を見落とす、路上のビニール袋を障害物と誤認して急制動する、といった事故が発生する。これは「故障」ではなく「設計された機能が対応しきれない状況(性能不足)」であるため、ISO 26262の枠組みでは説明も制御もできない。この空白を埋めるため、2019年にISO/PAS 21448(技術仕様書)として出発し、2022年6月に正式な国際規格(ISO 21448:2022)として発行された。

SOTIFを理解する出発点は「故障がなくても安全でありうる」という逆説である。ISO 26262が「システムが正しく動作できないとき(malfunction)」を扱うのに対し、SOTIFは「システムが仕様どおり正しく動作したにもかかわらず結果が危険なとき」を扱う。たとえば緊急制動(AEB)システムが前方の停止車両を認識できなかったのは、レーダが「設計された反射特性の範囲」内で金属構造物と停止車両を区別できなかった性能限界であって故障ではない。したがってSOTIFの核心的な問いは「故障をいかに検出・対応するか」ではなく、「意図した機能の限界をどこまで把握し、その限界が危険にならないようにいかに立証するか」である。

ISO 21448はADASと運転自動化レベル1〜5(SAE J3016)にまたがり、とりわけ複雑なセンサと処理アルゴリズムで状況を認知する機能、さらに合理的に予見可能な誤使用(reasonably foreseeable misuse) までを適用範囲とする。すなわち運転者が運転支援機能を過信してハンドルから手を離すといった誤使用も「システムが対応すべき条件」と見なし、安全論証に含める点が特徴である。

規格の発展経路そのものが、この問題意識の成熟を示している。初期は2019年にISO/PAS 21448という「公開仕様書(Publicly Available Specification)」の形、すなわちまだ完全な合意に至っていない暫定指針として出発した。自動運転の事故事例が蓄積され業界の経験が積み重なるにつれ、2022年に正式な国際規格へ昇格し、このとき適用範囲がレベル1〜2の運転支援からレベル3〜5の自動運転まで明示的に拡張された。「故障なきリスク」という概念が周縁の問題意識から自動車安全の中心的な議題へ上がった過程を、凝縮して表しているといえる。

B. SOTIFが扱うリスクの二つの源泉

SOTIFが狙うリスクは、大きく二つの仕様的欠落に由来する。第一は機能仕様不足(functional insufficiency) であり、意図した機能を車両レベルで定義する際に特定の状況を考慮しきれず生じる隙間である。第二は性能限界(performance limitation) であり、センサ・認知・判断アルゴリズムが物理的・統計的に持たざるを得ない限界(センサ解像度、悪天候での減衰、学習データの偏り)である。この二つが特定のトリガ条件(triggering condition) ——逆光、霧、工事区間、異例の道路標識といった環境・シナリオ要素——と出会うと、危害挙動(hazardous behavior) として現実化する。

ここで必ず区別すべき概念が「トリガ条件」と「機能不足」の関係である。機能不足はシステムが内在的に持つ弱点であり、トリガ条件はその弱点を外から刺激して発現させる状況である。たとえば「夜間低照度で黒い服の歩行者の認識率が低下する」という機能不足があっても、そのような歩行者が現れるトリガ条件がなければ事故は起こらない。したがってSOTIF活動の本質は、① 機能不足を見つけて減らし、② それを発現させるトリガ条件を体系的に発掘し、③ 両者が出会っても危害へ波及しないよう設計・検証することに要約される。答案では「性能限界 × トリガ条件 = 危害シナリオ」という因果構造を明確に記述することが鍵である。

C. 合理的に予見可能な誤使用

SOTIFがISO 26262と明確に区別されるもう一つの点は、人の誤使用までシステムが対応すべき条件として含めることにある。運転支援機能を「自動運転」と誤解してハンドルから手を離す、警告を無視して権限委譲(テイクオーバー)を遅らせる、設計されていない道路で機能をオンにする、といった行為はすべて「合理的に予見可能な誤使用(reasonably foreseeable misuse)」に当たる。SOTIFはこうした人的要因を「利用者の過ち」と片づけず、システムが予見して緩和すべき設計入力と見なす。これは自動運転における事故の相当数が、技術的限界と人間の過信・誤認がかみ合った「人間-機械相互作用(HMI)」の問題から生じるという洞察を反映している。

この観点が実務に与える含意は大きい。単に認知性能を高めるだけでは安全を立証できず、運転者の注意状態監視(DMS、Driver Monitoring System)、明確な作動限界の告知、段階的な権限委譲警告、モード混同(mode confusion)防止の設計がSOTIF安全論証の必須要素となる。たとえば「システムがオンだと錯覚した運転者が介入しない状況」をトリガ条件として明示し、そうした状況でも安全な最小リスク状態へ遷移するよう設計せねばならない。したがってSOTIFはセンサ・アルゴリズムの工学的問題であると同時に、人間工学・行動科学の問題でもある。

2. SOTIFのシナリオ四領域と核心概念

SOTIFの最も広く知られた概念枠組みは、シナリオを「既知/未知(known/unknown)」×「安全/危険(safe/unsafe)」 の二軸で分けた四つの領域(Area 1〜4) である。下の構造図は、この2×2の枠組みと、SOTIF活動が各領域をどう移そうとするかを示す。

graph TD
  subgraph KNOWN["既知のシナリオ"]
    A1["Area 1: 既知の安全<br/>正常動作の領域"]
    A2["Area 2: 既知の危険<br/>識別された危害シナリオ"]
  end
  subgraph UNKNOWN["未知のシナリオ"]
    A4["Area 4: 未知の安全"]
    A3["Area 3: 未知の危険<br/>未発掘の危害シナリオ"]
  end
  A3 -->|"シナリオ発掘・走行蓄積"| A2
  A2 -->|"設計改善・機能修正"| A1
  A4 -.->|"分析で確認"| A1
  GOAL["目標: Area 2・3の最小化"]
  A2 --> GOAL
  A3 --> GOAL

この四領域の意味を解けば次のとおりである。Area 1(既知の安全) はシステムが意図どおり安全に動作すると確認された領域で、開発が目指す最終状態である。Area 2(既知の危険) は分析・試験で既に識別した危害シナリオで、設計改善・機能制限・運転者警告といった措置でArea 1へ移さねばならない。Area 3(未知の危険) はまだ発見できていない危害シナリオで、SOTIFが最も警戒する領域である——存在すら分からないため直接除去できず、シナリオ発掘・大規模な走行データ蓄積を通じて「既知」の領域(Area 2)へ引き出した後にのみ除去できる。Area 4(未知の安全) はまだ分からないが実際には安全なシナリオである。したがってSOTIFの戦略目標は明確である——Area 2とArea 3の大きさを受容可能な水準まで減らすことである。

この枠組みが重要なのは、自動運転安全の本質的難題を露わにするからである。Area 3は「分からないことすら分からない(unknown unknowns)」領域であるため完全には空にできない。世のすべての走行状況を事前に列挙することは不可能だからである。そこでSOTIFは「どれだけ検証すれば十分に安全と宣言するか」という検証目標(validation target)を設定し、統計的論証で残存リスクが受容可能であることを示す方式に依拠する。まさにこの点が、故障経路を決定論的に追跡するISO 26262と根本的に異なる。

領域	既知か否か	安全/危険	核心活動
Area 1	既知	安全	正常動作 — 維持・拡大
Area 2	既知	危険	設計改善でArea 1化
Area 3	未知	危険	シナリオ発掘でArea 2化
Area 4	未知	安全	分析でArea 1を確認

表は四領域を整理したものだが、実際の開発で核心的な労力は境界面に集中する。すなわちArea 2↔Area 3の境界(まだ分からない危険をどう露わにするか)と、Area 1↔Area 2の境界(識別された危険をどの措置で安全化するか)がSOTIFエンジニアリングの二つの戦線である。実務では体系的リスク分析(HAZOP・機能分析)でArea 2を広げ、シミュレーション・フィールド運用・エッジケースマイニングでArea 3をArea 2へ引き込む。

この四領域モデルをODDと重ねて見ると理解が一段と深まる。ODDを狭く設定するとシステムが遭遇するシナリオ空間が小さくなりArea 3(未知のリスク)も小さくなるが、その分だけ機能が提供される範囲が制限される。逆にODDを広げると効用は大きくなるが未知のトリガ条件が急増しArea 3が膨張する。すなわちODDは四領域の全体の大きさを規定する「舞台の境界」 であり、SOTIF活動はその舞台の中でリスク領域を照らして減らしていく作業である。このため「ODDをどこまで広げ、その境界をどう検知・強制するか」がSOTIF戦略の最初のボタンとなる。

また四領域間の移動は一方向ではなく反復的である点に留意せねばならない。設計を変えてArea 2をArea 1へ移すと、その変更が予期せぬ新たな危害を生み、別のArea 3を生むことがある。たとえばfalse positive制動を減らそうと認知の感度を下げると、今度は実際の障害物を見落とすfalse negativeリスク(新たなArea 3)が大きくなる。このようにSOTIFのリスクは「相反(trade-off)構造」を帯びるため、一つの領域を減らす措置が別の領域を大きくしないかを交差検証する反復ループが必須である。

3. SOTIF活動プロセスと検証・妥当性確認

ISO 21448はSOTIF達成のための活動を、ライフサイクルにまたがる反復(iterative)プロセスとして提示する。下の詳細図は、機能定義から出発してリスク評価、設計措置、検証・妥当性確認、運用段階フィードバックへ循環する流れを表す。

flowchart LR
  F["意図機能の定義<br/>(機能・ODD仕様)"] --> H["危害の識別・評価<br/>(HARA, 危害挙動分析)"]
  H --> T["トリガ条件分析<br/>(機能不足・性能限界の導出)"]
  T --> D["設計改善・機能修正<br/>(Area 2の低減)"]
  D --> V["検証(Verification)<br/>既知リスク除去の確認"]
  V --> VAL["妥当性確認(Validation)<br/>未知リスクの統計的論証"]
  VAL --> ACC{"受容可能?"}
  ACC -->|"いいえ"| T
  ACC -->|"はい"| REL["リリース・配備"]
  REL --> OP["運用段階モニタリング<br/>(フィールドデータ・OTA改善)"]
  OP -.->|"新規トリガ発見"| T

このプロセスがISO 26262のVモデルと似て非なる点を押さえる必要がある。両規格とも「要求→設計→検証」のライフサイクル骨格とトレーサビリティを共有するが、ISO 26262のVモデルが各段階の成果物の整合性を決定論的に検証する「閉じたループ」であるのに対し、SOTIFプロセスは未知のリスクを継続的に発掘して還元する「開いた反復ループ」に近い。すなわちSOTIFは「開発が終わる時点」が明確でなく、受容基準を満たすまで、そして運用中も回り続ける。この構造的差異が両規格の検証哲学を分ける。

プロセスの各段階を散文で説明すればこうである。まず意図機能の定義段階で、機能の目的とともにODD(Operational Design Domain、運用設計領域) ——道路種別・速度・気象・照度などシステムが安全に動作するよう設計された条件範囲——を仕様化する。ODDはSOTIFの出発点であり境界であって、「この範囲内では安全を保証し、範囲を外れれば安全に機能を制限・委譲する」という約束である。ODDを狭めれば安全の立証は容易になるが機能効用が減り、広げれば効用は大きくなるが検証負担が膨れ上がるトレードオフがここで決まる。

次に危害の識別・評価では、機能が意図どおり動作したときにも起こりうる危害挙動を導出し、トリガ条件分析では、その危害を誘発する環境・状況要素と、その背後の機能不足・性能限界を体系的に洗い出す。続いて設計改善で、センサ多重化(カメラ+レーダ+ライダの融合)、認知アルゴリズムの強化、機能制限(低速でのみ作動)、運転者への権限委譲(takeover)要請といった措置で識別されたリスク(Area 2)を減らす。

SOTIF活動のハイライトは検証(Verification)と妥当性確認(Validation) の区別である。検証は「識別された既知リスク(Area 2)が措置で実際に除去されたか」を確認する活動で、目標シナリオに対する試験・シミュレーションで行う。一方、妥当性確認は「まだ識別できていないリスク(Area 3)を含め、残存リスクが受容可能な水準か」を統計・シナリオカバレッジで論証する活動である。前者が決定論的な点検であれば後者は確率的な説得であり、自動運転が数億kmの実走行・シミュレーションデータを要求する理由は、まさにこの妥当性確認の負担にある。たとえば致命的事故が人間の運転者より稀であることを統計的に示すには、事故間の平均走行距離が非常に長いため天文学的な走行距離が必要だという「approval trap(検証の罠)」が知られており、これを緩和するためにシナリオベース検証・シミュレーション・加速試験が組み合わされる。

SOTIF論証で見落としやすい段階が受容基準(acceptance criteria)の設定である。未知リスクを完全には消せないため、「残存リスクがどの水準なら社会的に受け入れられるか」を事前に定義して初めて「十分に検証した」という宣言が可能になる。実務ではGAMAB(Globally At Least As Good、既存手段と同等以上に安全)、MEM(Minimum Endogenous Mortality、自然死亡率に対する追加リスクの制限)、ALARP(As Low As Reasonably Practicable、合理的に実行可能な限り低く)といったリスク受容原理を参照して定量目標を立てる。たとえば「同等の人間運転者の事故率以下」を目標とすれば、これを統計的に立証するための走行距離・シナリオカバレッジが逆算される。この受容基準が曖昧だと検証は際限なく増えるか恣意的に終わるため、基準の透明性と社会的合意がSOTIFの信頼性を左右する。

もう一つの核心的な設計要素が最小リスク状態(MRM/MRC、Minimal Risk Maneuver/Condition) である。システムがODD境界を外れるか自らの性能限界を検知すると、リスクを増やさない状態——たとえば安全に減速して路肩停車する、運転者へ制御を委譲する動作——へ遷移せねばならない。ここで重要なのは「限界を自ら知る能力」である。認知の不確かさが高まる状況(悪天候・OOD入力)をランタイムに検知して機能を優雅に低下(graceful degradation) させる設計がなければ、システムは自分が誤っている事実すら知らぬまま危険な決定を下す。したがって不確かさの定量化とODDモニタリングはSOTIFアーキテクチャの心臓部に置かれる。

最後に運用段階モニタリングは、SOTIFを一回限りの認証ではなく継続的な安全保証にする軸である。リリース後もフィールドデータから新たなトリガ条件が見つかればこれをArea 3→Area 2へ反映し、OTA(無線更新)で認知モデル・制御ロジックを改善して安全水準を維持・向上する。このフィードバックループが自動運転安全の核心的な運用モデルである。

4. 比較 — ISO 26262との関係および適用事例

SOTIFを正確に用いるには、ISO 26262との分担構図を明確にせねばならない。両規格は競合ではなく相互補完の関係にある。ISO 26262が扱うのは「E/E故障(fault)」が生むリスク、すなわち「故障空間(fault space)」であり、SOTIFが扱うのは故障がなくても性能が不足して生じるリスク、すなわち「不足空間(insufficiency space)」である。差が生じる根本的な理由は、リスクの源泉と証明の方式にある。故障は原因を特定でき確率で定量化されるため、FTA・FMEAで追跡しハードウェア指標で残存リスクを数値化する。一方、性能不足は「いつどの状況で誤認識するか」を完全には列挙できず、シナリオカバレッジと統計的論証に依拠する。興味深いことに、ISO 21448は当初ISO 26262の一部(part)として議論されたが、「故障なきリスク」という性格が根本的に異なるため別個の規格へ分離された。

区分	ISO 26262	ISO 21448(SOTIF)
対象リスク	E/E故障(malfunction)	性能限界・誤認識(故障なし)
空間	故障空間(fault)	不足空間(insufficiency)
等級体系	ASIL A〜D(+QM)	等級なし(シナリオ論証)
核心技法	HARA・FTA・FMEA・HW指標	シナリオ発掘・V&V・統計論証
証明哲学	決定論的な証拠	確率・シナリオ的な論証

この比較で実務的に重要な含意は、一つの自動運転システムを安全にするには二つの規格を同時に適用せねばならない点である。たとえば自動緊急制動(AEB)を見よう。レーダECUがビットフリップで誤作動して制動指令を欠落させるのはISO 26262の領域であり、レーダが故障なしに金属マンホール蓋を停止車両と誤認して不要な急制動(false positive)をかけるのはSOTIFの領域である。実際、2016〜2018年の一部の自動運転・運転支援の事故は、部品故障ではなく認知アルゴリズムの限界(停止トレーラ・工事構造物の誤認など)に由来すると分析され、これがSOTIFの正式な規格への昇格の直接の動因となった。

同じECUの中で二つの規格がどう共存するかを見れば分担構図はより明確になる。自動運転制御器は、ISO 26262の観点ではロックステップコア・ECC・ウォッチドッグで「故障なき演算」を保証する一方、SOTIFの観点では認知結果の不確かさを定量化し、信頼できないときに安全に機能を低下させる。前者は「計算が誤っていないか」を、後者は「計算は正しいが、その結果を信じてよいか」を問う。したがって一つの安全アーキテクチャの中に決定論的な故障安全メカニズムと確率的な性能安全メカニズムが層をなして共存し、どちらか一方でも欠ければ自動運転の安全論証は成り立たない。答案で「26262=故障への備え、SOTIF=性能限界への備え、両者は相互補完」という分担を具体事例で解きほぐせば比較の深みが増す。

もう一つの適用事例として車線維持支援(LKAS)を挙げられる。路面表示が消えているか、工事区間で仮設車線と既存車線が重なるトリガ条件で、LKASが誤った車線に沿って操舵するのは典型的なSOTIFリスクである。これをODD仕様(車線表示品質が一定基準以上の道路に作動を制限)、運転者への権限委譲要請、多重センサ融合で緩和する。このようにSOTIFは、機能の効用と安全の間でODDをどう引き、限界状況をどう検知して安全に委譲するかを設計する活動である。

センサ融合がSOTIFで占める比重も、これらの事例が共通して露わにする。カメラは色・形状の認識に強いが低照度・逆光に弱く、レーダは距離・速度に強いが停止物・形状の区別に弱く、ライダは三次元形状に強いが悪天候・コストに弱い。互いの性能限界が重ならないよう異種センサを融合(redundancy・diversity) すれば、あるセンサが特定のトリガ条件で失敗しても別のセンサが補ってArea 3を構造的に減らせる。ただし融合そのものが新たな機能不足(センサ間の時空間整合の誤り、相反判定)を生みうるため、融合ロジックもSOTIF分析の対象になる点を忘れてはならない。

5. 深化 — AI安全規格への拡張と最新動向

近年のSOTIFの地形の最大の変化は、AI・機械学習ベースの認知の安全立証という難題である。深層学習の認知モデルは、学習データにない分布(out-of-distribution)入力で予測不能に失敗し、内部の決定過程を説明しにくいブラックボックス特性を持つ。これはSOTIFのいう「機能不足」の典型だが、従来のシナリオ分析だけではモデルの限界を十分に露わにしにくい。この空白を埋めるため、2024年にISO/PAS 8800(Road vehicles — Safety and artificial intelligence)が発行され、自動車AIの安全ライフサイクル・データセット品質・モデル性能保証をSOTIF・ISO 26262と連携させる体系を提示する。あわせてUL 4600(自動運転車の安全ケース規格)は完成システムの安全論証(safety case)を要求し、これらの規格が多層に結合して「故障安全(26262)+ 性能安全(21448)+ AI安全(8800)+ 全体安全ケース(UL 4600)」の立体的な体系を形成している。

この流れを支える基盤技術として不確かさの定量化(uncertainty quantification)とランタイムモニタリングが注目される。深層学習モデルに自らの予測がどれだけ信頼できるかを併せて出力させ(例:ベイジアンニューラルネットワーク、アンサンブル、OOD検知)、信頼度が低ければ別のセンサで交差検証するか機能を低下させる設計がそれである。モデルが「確信に満ちて誤る(confidently wrong)」瞬間を捉えることこそSOTIFがAI認知に求める核心能力であり、説明可能AI(XAI)と安全アーキテクチャが出会う接点である。

第二の動向はシナリオベース検証(scenario-based validation)とシミュレーションの台頭である。先に述べた「検証の罠」(天文学的な実走行距離)のため、業界はOpenSCENARIO・OpenDRIVEのような標準フォーマットで走行シナリオを記述し、高忠実度シミュレーションとデジタルツインで数百万個の変形シナリオを自動生成・実行する方式でArea 3を探索する。とりわけエッジケースマイニング(実走行・事故データから稀で危険な状況を抽出)と敵対的シナリオ生成(意図的に認知を攪乱する状況を合成)が結合し、限られたコストで未知リスクのカバレッジを高めることが核心的な研究テーマとなった。

第三はデータセット品質が安全属性になるという認識である。深層学習認知の性能限界は結局、学習・検証データの分布に由来するため、ISO/PAS 8800はデータセットの完全性・代表性・均衡性・正確性を安全要求へ引き上げる。特定の人種・体型・悪天候・地域道路がデータで過少標本化されれば、そのままArea 3の未知リスクとして残るからである。これに伴い、「どのODDをカバーするにはどの分布のデータがどれだけ必要か」を逆設計するデータ要求工学と、データの出所・ラベル品質・偏りを追跡するデータガバナンスがSOTIF実務の新たな軸として台頭した。これはAI・データ分野のデータ品質・MLOps能力が安全工学と直接かみ合う地点である。

第四はセキュリティとの融合である。コネクテッド・自動運転環境で敵対的攻撃(adversarial attack)——たとえば交通標識にステッカーを貼って認知モデルを誤分類させる攻撃——は「悪意で誘発されたトリガ条件」であり、SOTIF(性能限界)とサイバーセキュリティ規格ISO/SAE 21434の境界に置かれる。したがって安全とセキュリティを一つの脅威モデルへ統合して分析する取り組みが求められる。予想される出題方向としては「ISO 26262・SOTIF・ISO/PAS 8800の統合安全プロセスを自動運転の認知事例で論ぜよ」という融合型の論題、あるいは「SOTIFのArea 3(未知のリスク)を減らすためのシナリオベース検証・シミュレーション戦略を設計せよ」というアーキテクチャ型の論題が有力である。

6. 考慮事項および示唆点

適用戦略 — ODD中心の設計と段階的な縮小: SOTIF活動の成否は、ODDをどれだけ明確に引き、その境界をリアルタイムに検知して安全に機能を制限・委譲するかにかかっている。初期にはODDを保守的に狭く設定して安全を確実に立証した後、フィールドデータ・シミュレーションで未知リスク(Area 3)を減らしながら段階的にODDを拡張する段階的展開戦略が現実的である。ODDを外れる状況の検知(ODD monitoring)と安全な最小リスク状態(MRM、Minimal Risk Maneuver)の設計が核心能力である。
トレードオフ — 効用 vs 検証負担 vs コスト: ODDを広げ自動化水準を高めるほど機能効用は大きくなるが、立証すべきシナリオ空間が爆発的に増え、検証コスト・期間が非線形に増加する。逆に過度に保守的な設計(頻繁なfalse positive制動、頻繁な権限委譲要請)は安全だが商品性を損なう。技術士の観点では「安全は妥協不可」という前提の下、ODD・センサ構成・検証目標の間でリスク比例的な最適点を見いだす均衡感覚が求められる。
展望 — データ駆動の継続的安全保証への転換: SOTIFは出荷時点の一回限りの認証ではなく、運用中のフィールドデータ・OTA・シミュレーションを通じた継続的安全保証(continuous safety assurance) へパラダイムを移す。新たなトリガ条件が見つかるたびに安全ケースを更新する「生きた安全論証(living safety case)」が標準実務の中心になるであろうし、これはデジタルツイン・シナリオDB・エッジケースマイニングの能力と直結する。
連携技術 — 機能安全・AI安全・セキュリティの統合: SOTIFは独立した活動ではなく、[iso-26262]、ISO/PAS 8800(AI安全)、ISO/SAE 21434(サイバーセキュリティ)、[[software-safety-analysis]]のFMEA・FTA、[[rtos]]のリアルタイム性と有機的に結合せねばならない。特に深層学習認知の不透明性・データ依存性は従来の安全分析技法だけでは扱えないため、説明可能AI・不確かさの定量化・ランタイムモニタリングといった新技術を安全アーキテクチャへ統合する設計能力が必須となる。
国内・制度の観点 — 規制・認証との整合: 韓国でも自動運転の臨時運行許可とレベル3の安全基準が整備されるにつれ、SOTIFは完成車・部品業界の型式承認・安全評価の実務に直接影響する。UNECE WP.29の自動運転関連規定とISO 21448・ISO/PAS 8800が認証根拠として定着する流れの中で、技術士は規格の技術内容だけでなく、それが規制・認証・責任(製造物責任)体系とどうかみ合うかを併せて俯瞰せねばならない。性能限界による事故の責任の所在が製造者・運用者・運転者のうち誰にあるかという法的議論も、SOTIF立証の水準と直結する。
組織・ガバナンス — シナリオ資産と安全文化: SOTIFの競争力は結局「どれだけ豊かで体系的なシナリオ・走行データの資産を蓄積したか」に帰着する。シナリオDBの構成・バージョン管理、データ品質ガバナンス、未知リスクを継続的に発掘・反映する組織プロセスが支えなければ、どれほど優れたアルゴリズムも「立証されていない安全」にとどまる。技術士はSOTIFを単一プロジェクトの検証活動ではなく、データ・プロセス・文化にまたがる全社的な継続投資として設計・運用するガバナンスの観点を備えねばならない。

参考資料

ISO, "ISO 21448:2022 Road vehicles — Safety of the intended functionality (SOTIF)": https://www.iso.org/standard/77490.html
ISO, "ISO/PAS 8800:2024 Road vehicles — Safety and artificial intelligence": https://www.iso.org/standard/83303.html
PTC, "ISO 26262 vs. SOTIF (ISO/PAS 21448): What's the Difference?": https://www.ptc.com/en/blogs/alm/iso-26262-vs-sotif-iso-pas-21448-whats-the-difference
Visure Solutions, "ISO 21448 (SOTIF) — Safety of the Intended Functionality": https://visuresolutions.com/automotive/iso-21448/

一言まとめ: SOTIF(ISO 21448:2022)は故障がなくても意図した機能の性能限界・誤認識によって生じるリスクを扱う自動車安全規格であり、シナリオを既知×安全の四領域に分けてArea 2・3を減らし、トリガ条件分析・検証・妥当性確認・運用モニタリングで未知リスクを統計的に論証し、ISO 26262(故障安全)・ISO/PAS 8800(AI安全)と結合して自動運転の安全を支える。