1. はじめに

1-1. 機能安全とSOTIF

自動車開発における安全性は、もはや単独の性能項目ではなく開発ライフサイクル全体を貫く設計思想です。現行車両には数百 ECU 相当の機能が統合され、ブレーキやステアリングといったクリティカル系については、自己診断・冗長構成・フォールトトレランスを前提とした設計が不可欠です。こうした故障起因リスクへの備えが「機能安全（ISO 26262）」として定着しました。一方、センサ誤認識や限界を越えた環境による誤動作など、「故障していないのに安全でない」リスクを扱うのが SOTIF（Safety of the Intended Functionality）です。この「SOTIF（ISO 21448）」は、高度運転支援 （ADAS） や自動運転の主機能を中心に適用されており、機能安全と合わせた包括的な安全を構築しています。

当社の支援スタンス

当社は OEM／Tier 1 経験者で構成した専門チームが、皆様の現場の言葉と実装できる方法論でご支援いたします。機能安全やSOTIFのプロジェクト支援や導入支援はもちろんのこと、皆様のご要望に応じて、例えば下記のようなカスタマイズしたご支援も得意としています。

• Automotive SPICE × ISO 26262 のプロセス統合
• プロジェクト横断の 機能安全 & SOTIFのアセスメント
• SDV（Software Defined Vehicle） を見据えた OTA（Over-the-Air）対応設計

導入フェーズで頻出する課題

• 安全要求トレーサビリティがレビューで不合格
• 安全設計チームと機能開発チームの認識齟齬
• 海外拠点との ASIL 割付・安全要求解釈の不統一
• ASIL デコンポジション／パーティショニングの妥当性に自信がない

展開フェーズで顕在化する課題

• 2 系統監視と複雑性のトレードオフが整理できない
• MBD（Simulink）自動コード生成と ASIL 階層の整合が不透明
• ドメイン連携機能追加による要求爆発に追従できない
• SDV／OTA 時代の SOTIF 対応手順が見えない

当社はこのような現場固有の悩みに対し、グローバルに実績のある手法を活用しながら、皆様の会社や組織の競争力を培うために、臨機応変に寄り添い、共に解決していきます。

1-2. 機能安全とは？

システム異常によるリスクを許容レベルまで低減する体系的アプローチ

自動車技術が目覚ましい進化を遂げるなか、私たちの移動を支える車両はかつてないほど高度で複雑な電気・電子 （E/E） システムによって制御されています。パワートレイン、シャシー制御、先進運転支援システム （ADAS）、さらには自動運転システムに至るまで、ソフトウェアとハードウェアが織りなすこれらのシステムは利便性・快適性・環境性能を高める一方で、その故障がもたらすリスクも増大させています。

機能安全 （Functional Safety） とは、こうした E/E システムの異常に起因する不合理なリスクを回避または低減するための考え方と、それを実現する体系的な活動全般を指します。ここでいう「異常」には、ハードウェアの偶発的故障だけでなく、システム構成の不整合やソフトウェアのバグといった設計起因の不具合も含まれます。

ISO 26262 は、この機能安全を自動車分野で実現するために国際標準化機構 （ISO） が策定した国際規格です。2011 年に初版が発行され、2018 年の第 2 版ではトラック・バス・二輪車も対象に追加されました。本規格はコンセプト開発から設計、実装、検証、量産、保守、廃棄に至るまでの安全ライフサイクル全体を通じ、実施すべき要求事項やプロセス、手法を具体的に定義しています。

ISO 26262 の基本思想は、「安全は後付けではなく、開発の初期段階からプロセス全体を通じて作り込むもの」という点にあります。単に安全機能を追加するのではなく、開発プロセスそのものを規律し、潜在的な危険を体系的に分析・評価したうえで対策を講じ、システム全体の安全を確保します。電動化や自動運転化が進み、依存関係が複雑化する現代の自動車開発において、ISO 26262 は安全な車両を実現するための不可欠な基盤となっています。

進化する技術と変化する環境に対応する機能安全

自動運転、SDV、コネクティビティの進展は、機能安全の重要性を一層高めるとともに、新たな課題も突き付けています。

SDV・OTA と機能安全

SDV 時代には OTA アップデートが頻繁に行われます。機能追加や性能向上が容易になる一方で、新たな不具合の混入や既存安全機能への影響リスクも生じます。開発時だけでなく市場投入後も、変更管理・リグレッション検証・市場監視などを通じて機能安全を継続的に維持する仕組みが重要です。

サイバーセキュリティ （ISO/SAE 21434） との連携

コネクテッドカーの普及により外部からのサイバー攻撃リスクが増大しています。不正操作により安全機能が無効化されれば重大事故につながりかねません。機能安全とサイバーセキュリティは開発初期から連携し、互いの要求を考慮した設計・検証を進める必要があります（Security-informed Safety / Safety-informed Security）。

これら新しい技術や環境変化に対応するため、機能安全の手法も進化を続けています。しかし、その根底にある「リスクベースで考え、体系的プロセスを通じて安全を作り込む」という基本思想は変わりません。組織全体で安全を最優先する機能安全文化を醸成し、技術者一人ひとりがその重要性を理解して開発に取り組むことが、未来の安全なモビリティ社会を実現する鍵となります。機能安全は、もはや特別な取り組みではなく、高品質な自動車開発に欠かせない要素なのです。

1-3. SOTIFとは？

SOTIF（Safety Of The Intended Functionality）は、「E/Eシステムが故障していないにもかかわらず、その性能限界や仕様の抜け漏れ、あるいは想定外の使用状況によって危険が生じるリスク」を扱う安全規格です。従来の機能安全（ISO 26262）はハード・ソフトの故障起因リスクを対象としますが、センサや AI アルゴリズムを駆使する ADAS／自動運転では“壊れていないのに安全でない”シナリオこそが重大事故につながります。

• 機能安全：回路短絡，メモリエラー等の故障→危険
• SOTIF：霧でカメラ視界低下，AI 誤認識，ドライバー誤用→危険

両者は補完関係にあり、特に L2+ 以上の高度運転支援や自動運転システムでは両方を満たして初めて「包括的な安全設計」と言えます。

SOTIFが対象とするリスク：既知／未知の“安全でないシナリオ”をどう捉えるか

リスクの発生には以下のような要因があり、SOTIFではこれらを網羅的に洗い出し、シナリオ単位で評価します。

• センサ限界（視野角・分解能・悪天候耐性）
• 推論アルゴリズム限界（AIの訓練データ偏り、閾値設定不足）
• HMIの誤解誘発（機能の過信、警報の認知負荷）
• 環境要因（複雑な交通、インフラの地域差）

概念	例	主な要因
Known Unsafe Scenarios	豪雨でレーダー反射乱れ距離過小検出	センサ物理限界
Unknown Unsafe Scenarios	特殊反射材を標識と誤分類	AI 汎化不足

SOTIF達成プロセス：リスクの特定・評価・対策・検証を繰り返す

1. シナリオ分析
   • 機能仕様と運用環境を組み合わせ、トリガーイベント→システム反応→結果を列挙
   • モデルベースシナリオ生成やデータドリブン解析が有効
2. リスク評価
   • 発生頻度×影響度などで優先度付け（ASILとは異なる軸）
3. 対策実施
   • 例：センサヒーティング追加、CNN 再学習、雨量閾値以上で機能 OFF、HMIで警告強化、最低リスク状態へ移行 など
4. 検証・妥当性確認
   • SIL/HIL/車載シミュレーション＋実車テストで有効性確認
   • 未知シナリオ探索のためのフェールファスト試験、大規模フィールドデータ解析
5. 市場投入後の監視
   • OTAログ／クラウドでフィールドデータを収集し、新たな unsafe シナリオをフィードバック

この PDCA を量産後も継続することで、性能限界を認知しつつ安全域を絶えず広げていきます。

SOTIFの重要性と今後の展望：安全な自動運転社会を支える“第三の柱”

• ADAS/ADS での決定的な役割
  自律度が高まるほど人間の監視余力は減り、性能限界リスクが顕在化。SOTIFは残留リスクを工程と運用の両面で制御する鍵。
• 機能安全・SOTIF・サイバーセキュリティの三位一体
  故障・性能限界・悪意ある攻撃という３方向の危険を同時に扱う統合安全マネジメントが必須。
• AIモデルの説明可能性とSOTIF
  学習ベース機能のブラックボックス性を緩和し、リスク要因を説明可能にする XAI が検証効率と監査性を高める。
• SDV/OTA時代の課題
  ソフトウェア定義自動車ではアップデート後も SOTIF を維持するための差分評価手法とモニタリング基盤が重要。

2. 規格の最新動向

機能安全（ISO 26262）

次版	刊行時期	主な改訂論点
ISO 26262 第3版	• WD2  ~2026 Q2 • DIS    ~2026 Q4 • FDIS  2027 Q1 • 公開   2027 Q2	• 関連キーワード：SDV、OTA、AD、EV • Predictive Maintenanceの適用 • ソフトウェアの非干渉技術

SOTIF（ISO 21448）

次版	刊行時期	主な改訂論点
ISO 214448 第2版	• WD    ~2026 Q1 • CD     ~2026 Q3 • DIS    ~2027 H2 • 公開   2028年内目標	• L4/L5 用ODDの拡張 • データ品質の評価 • 未知シナリオ探索のメトリクス化

3. 用語解説

機能安全（ISO 26262）やSOTIF（ISO 21448）の用語集に登場しませんが、よく問合せがある用語を解説します。

3-1．機能安全に関する用語の解説

Graceful Degradation
故障時に性能を段階的に下げながら安全を保持する動作コンセプト。ステアリングトルクを徐々に制限して走行継続する例など。

Fail-Operational
クリティカル機能を故障後も一定期間維持する思想。冗長化 ECU・二重センサで“走り続ける”設計を指す。

Fail-Silent
故障を検知した瞬間に出力を完全遮断し、外部へ“無信号”で知らせる設計手法。バスにエラーフレームを撒かずに他 ECU の判断を妨げない利点があるが、一般にフェールオペレーショナル要件とは両立しにくい。

Safety Manual
SEooC や IP 供給時に添付される安全利用ガイド。ASIL 前提条件・診断設定・制約一覧を示す。

Safety Management System（SMS）
製品ライフサイクル全体（企画 → 開発 → 生産 → サービス → 廃棄）にわたり、機能安全活動が一貫して計画・実行・監視・改善されるように整備した組織的な管理枠組み。実際の例では、以下を含む場合が多い。

• 経営レベルの安全方針
• 安全を維持する組織体制と責任
• プロジェクトごとに実施する安全計画
• 安全活動や安全スキルの向上に向けた教育や訓練
• 安全を維持するための変更管理と構成管理
• 監査やアセスメントの仕組み、体制、運用
• 安全の維持の向けた継続的改善

Safety-Critical
システムや製品の設計において、高い安全性や高い信頼性を重要視することを指す。この場合のCriticalは「重要な、極めて必要な」の意味。

3-2．SOTIFに関する用語の解説

Edge Case
学習データや設計仕様の外縁に位置する稀少シナリオ。性能限界を突くため SOTIF 検証で重視。

Corner Case
異常系・複合条件が重なり危険を招く極端シナリオ。一般にEdge Case より発生頻度はさらに低い。

Data Drift Monitor
学習モデル運用中に入力分布が変化していないかを監視する仕組み。未知 Unsafe シナリオ検出の早期警報として使う。

Fallback
車載機能が何らかの理由で「本来の性能を維持できなくなった」ときに、より安全な簡易機能へ自律的に切り替わる仕組みを指す総称。Graceful DegradationやFail-Operationalと同じような意味合いで使われるが、自動運転においてよく使われている。

X-in-the-Loop (XiL)
SIL/MIL/HIL を拡張し “Sensor-in-the-Loop” や “AI-in-the-Loop” まで網羅する統合検証枠組み。

SPI（SOTIF Performance Indicator）
認識率・誤警報率などを安全観点で KPI 化したメトリクス。規格外だが欧州で導入例多数。

4. 設計と実装のポイント

4-1．E/Eシステムの安全設計

アーキテクチャにおけるシンプル化と階層化：複雑化するE/Eシステムの管理

現代の車両E/Eシステムは、ゾーンECUとセントラルコンピュータ（高性能SoCを搭載）を中核とする大規模な統合プラットフォームへと進化しています。膨大な量のソフトウェアが実装され、個々のECUを追加・連携させる従来型の手法では、データ経路の複雑化、リグレッションテストの増大、そして改修時の安全設計における非効率性を招くこととなります。この課題に対し、システム安全の基本原則に立ち返ることが求められます。

• 最小化 （Minimization）: 機能単位を可能な限り小さく分割し、各々の責務を明確に定義する。これは影響範囲の限定化に寄与します。
• 独立化 （Independence）: 安全上クリティカルな機能は、ASILデコンポジションの適用を考慮しつつ、物理的および論理的に分離する。電源系統、クロックドメイン、メモリ空間の分離に加え、Freedom from Interference （FFI） の概念に基づく厳密な検証が不可欠です。
• 冗長化 （Redundancy）: フェールオペレーショナルを確保するため、主要機能には複数の独立した経路を設ける。特に高度自動運転システムにおいては、センシング、認識、判断、制御の各段階における冗長設計が要求されます。

これらの原則をE/Eシステム設計、ハードウェア設計、ソフトウェア設計のアーキテクチャに反映させ、階層化された設計を定義することが重要です。これにより、複数のサプライヤや部門間における設計意図の共有が促進され、OTAによるソフトウェア更新時においても、アーキテクチャレベルでの整合性維持が期待できます。

E/Eシステムの安全設計のポイント

SDV時代における自動車の安全設計は、従来技術の深化に加え、新たな技術領域への適応が求められる複雑な課題です。当社が提供する階層化と構造化によるアーキテクチャ設計をE/Eシステムの安全設計へ活用いただき、皆様の実践的な技術として、これらの安全設計手法も継続的に進化させながら、高度な安全性を有するモビリティシステムの実現を支援します。

4-2．従属故障分析

従属故障分析 （DFA） ：非干渉性の論証による開発効率の向上

FMEA（故障モード影響解析）やFTA（フォールトツリー解析）が故障の伝播経路を特定するのに対し、DFAは、特定の安全目標（SG）に直接関連しない要素が、当該SGに対して悪影響を及ぼさないこと（非干渉性）を論証する手法です。DFAは、複雑なSoC内部やリソース共有型システムにおいて、非干渉性の論証に対して重要な役割を果たします。

実務的には、以下の2段階で分析を進めます：

STEP 1：論理的非干渉性の検証

データフロー図や機能ブロック図を用いて、機能ブロック間のインタフェースを定義し、安全目標（SG）に関連するデータパスおよび制御パスを特定します。これらの情報を活用し、「従属関係」の有無や箇所を構造的に明示します。

機能ペア間の潜在的干渉を「要求干渉マトリクス」を用いて分析し、意図しない依存関係や矛盾する要求が存在しないかを確認します。「接続の有無」ではなく「要求の意味の整合性」に注意しながら、安全機構の要求を“打ち消すような要求”の有無を確認します。

エレメント名		XXX機能
インタフェース		要求	分類		SG侵害	理由
入力	出力		安全機構	その他
XXX	XXX	XXX	✓	–	侵害する	XXX
XXX	XXX	XXX	–	✓	侵害しない	XXX

STEP 2：物理的非干渉性の検証

電源系統、クロック供給、共有メモリ、バスアクセス、SoC内部の共有リソース（例：DMA、割り込みコントローラ）など、物理的依存関係をリストアップします。

エレメント名	要求	マイコンリソース
		CPU	DMA	メモリ	・・・
XXX	XXX	侵害あり XXXのため	侵害なし XXXのため	侵害なし XXXのため	・・・
	XXX	侵害なし XXXのため	侵害なし XXXのため	侵害なし XXXのため	・・・

これらの物理的依存関係が安全目標（SG）関連要素間に存在しないこと、または存在する場合でも適切な分離メカニズム（例：MPUによるメモリ保護、電源ドメイン分離、時間的隔離）が実装されていることを、専用のチェックリストに基づき検証します。

この「図（論理構成）＋マトリクス（要求干渉）＋チェックリスト（物理分離）」を組み合わせた成果物によって、共通原因故障（CCF）やカスケード故障（CF）のリスクを体系的に低減できます。これにより、開発後工程における手戻りの大幅な削減が期待でき、特に大規模SoC開発や複雑な分散制御システムにおいて有効な手法です。

従属故障分析のポイント

自動車のE/Eシステムは、制御構造、ハードウェア部品、ソフトウェアの全ての階層において、大規模化・複雑化が進展し、従来通りの安全分析の適用に大きな課題が生じています。当社が提供する論理的視点と物理的視点を活用した従属故障分析を活用いただき、皆様の実践的な技術として、現実的で効率性のある安全分析手法の構築と適用を支援します。

4-3．ハードウェア設計の定量分析

ミッションプロファイルを適用したハードウェア定量分析：実運用環境を考慮した故障率評価

従来のHDBK-217Fに代わり、ISO 26262-11のガイダンスやIEC TR 62380（あるいはSN 29500等の業界・企業規格）が、ハードウェア部品の故障率推定の参照基準となりつつあります。この定量分析における最重要概念の1つは「ミッションプロファイル」であり、車両が実際に使用される環境条件（温度、湿度、振動）および運転パターン（負荷、電圧）を、故障率計算に精密に反映させることが求められます。この課題に対する解決策として、以下のアプローチが考えられます。

• IEC TR 62380の活用
  IEC TR 62380（旧称：RDF 2000）は、ミッションプロファイルを詳細に考慮した故障率予測手法を提供しています。この規格は廃止されていますが、その手法はISO 26262-11:2018に組み込まれており、引き続き活用可能です。具体的には、動作温度や負荷条件などの実際の使用環境を反映した故障率の計算が可能となります。
• ISO 26262-11のガイドラインの参照
  ISO 26262-11では、ベース故障率の計算に関するガイドラインが提供されています。特に、ミッションプロファイルを考慮した故障率の適用方法についての指針が示されています。このガイドラインを参照することで、最新の規格に基づいた適切な故障率の算出が可能となります。
• 部品メーカーとの連携
  部品メーカーが提供するFMEDA（Failure Modes, Effects, and Diagnostic Analysis）レポートや信頼性データを活用することで、実際の使用条件に即した故障率データを入手することができます。これにより、ミッションプロファイルを考慮したより正確な故障率の算出が可能となります。
• フィールドデータの収集と解析
  自社製品のフィールドデータを収集・解析し、実際の使用環境に基づいた故障率データベースを構築することも一つの方法です。これにより、より現実的な故障率の予測が可能となります。

ハードウェア定量分析のポイント

自動車のE/Eシステムにおけるハードウェア部品は、安全性に直接影響がある故障を担っています。このため、複雑化や微細化の技術が適用されている半導体部品においても、業界の先端技術や最新動向を捉えた設計や検証、管理が求められています。当社が提供するハードウェア部品の定量分析手法やミッションプロファイルの設定手法を活用いただき、皆様の実践的な技術として、ハードウェア設計とハードウェア部品の適切な検証と管理を支援します。

4-4．機能安全アセスメント

機能安全アセスメントの役割と目的：安全を「確認」し、「保証」するもう一つの開発工程

機能安全アセスメントの目的は、製品設計やプロセスが機能安全要求の充足を客観的に検証し、市場投入の安心を保証する ことにあります。レビュー対象は製品単位だけでなく、プロジェクトマネジメント、技術文書の整合性、開発プロセスの遵守状況まで多岐にわたります。近年は SDV やドメインアーキテクチャ対応の開発が増え、従来以上に システム間の整合性 や ソフトウェア構成の説明力 が問われています。

アセッサーの視点と着眼点

アセッサー（第三者評価者）が注目するのは「設計の正しさ」に加えて、安全に設計されたことを論理的に説明できているか です。主な評価ポイントは次のとおりです。

• トレーサビリティ：上位要求 → 安全ゴール → テクニカルセーフティ要件 → システム構成 → テストケースまで整合性が維持されているか
• ASIL 分解の正当性：ASIL の割り当て・分解が適切で、責任分界が明確か
• 安全機構の妥当性：検出率・カバレッジ・診断時間など定量的根拠が示されているか
• プロセス準拠：ISO 26262 Part 2〜7 に沿い、役割・文書・レビュー・確認ステップが計画どおり実行されているか
  

設計者が直面するアセスメントの課題

開発チームがアセスメントで抱えがちな悩みには、次のようなものがあります。

• 「成果物はあるが、相関が不明瞭」問題
  要件書・設計書・テスト仕様はそろっているものの、関係性が追えない。ツールを導入しても運用が追いついていないケースが多発。
• 「後付け安全設計」問題
  機能開発後に安全対応を追加すると説明構造が破綻しやすく、指摘されやすい。
• 「要求レベルの解釈不一致」問題
  OEM と Tier 1、複数ドメイン間で安全要求の粒度や定義が異なり、ASIL 配分や安全ゴールがそろわない。
• 「SDV・OTA・仮想化プラットフォーム」への未対応
  ソフト更新が前提となる中で、ASIL 再評価やトレーサビリティ更新の仕組みが追いつかない。

これらを回避するには、開発初期からアセスメントを意識した設計準備とレビュー体制 を整えることが有効です。

機能安全アセスメントのポイント

自動車のE/Eシステムの安全設計において主流となっている機能安全では、適切なアセスメントのルール化、プロセス適用、実務活用が強く求められています。当社が提供する実際のアセスメント現場で培われたドメインに共通する判断基準とドメイン固有のノウハウを活用いただき、皆様の実践的なアセスメント活動を支援します。

5. よくあるご質問（FAQ）

機能安全

Q1. ASILの割り当ては誰が決めるべきですか？

通常はシステムレベルでのHARA（Hazard Analysis and Risk Assessment）によってASILが決まり、システムエンジニアや安全担当者が中心となって割り当てを定義します。開発後の変更には注意が必要です。

Q2. ASILデコンポジションの正当性はどう証明しますか？

独立性の要件（設計、物理、検証）を満たしているかを示すことが重要です。安全機構における共通原因故障（CCF）を排除し、冗長構成が独立して動作することを設計・検証文書で示します。片方のみでも異常の検出や安全状態へ到達できる作用が必要です。（補完関係では成立しません）

Q3. ASILの高い部品やソフトウェアでも開発委託できますか？

可能ですが、委託先が機能安全プロセスを理解し、適切な開発・検証能力を有することが前提です。また、責任分界の明確化と成果物のレビューが必要です。

Q4. 安全メカニズムの検出率や診断カバレッジはどこまで求められますか？

ASILによって異なります。ASIL Dでは90%以上の診断カバレッジが推奨されますが、文脈に応じてFMEDAや経験値から合理的な説明が求められます。

Q5. MBD（モデルベース開発）と機能安全の整合はどう取るべきですか？

MBDツール（Simulinkなど）から生成されたコードに対してもASIL要求が適用されます。モデル、生成設定、コードの各層でトレーサビリティと検証が必要です。

Q6. ASILの再評価はOTA更新ごとに必要ですか？

はい、OTAによりソフトウェアや仕様が変更された場合、それが安全に影響を及ぼす可能性があるため、影響範囲分析と必要に応じたASIL再評価が必要です。

Q7. AIや機械学習の誤認識は機能安全でカバーできますか？

基本的にはSOTIFの適用対象です。機能安全は「故障」に起因するリスクへの対処であり、AIの挙動不安定性や説明性の欠如といった問題にはSOTIFの考え方が必要です。

Q8. 自社に安全開発の経験が少ないが、どこから始めればよいですか？

まずはISO 26262のパート2（プロセス、マネジメント）に基づいて、安全開発体制・計画・教育から着手するのが実践的です。HARAやFMEAなどの安全分析の基本から整えるのが理想です。

SOTIF

Q1. 能安全とSOTIFの違いは何ですか？

機能安全（ISO 26262）はE/Eシステムの「故障」に起因するリスクを対象とします。一方、SOTIF（ISO 21448）は「故障がない状態でも危険が生じる可能性（例：センサ誤認識、環境条件）」を対象とし、主にADASや自動運転の設計に適用されます。

Q2. SOTIFはどのような機能に適用すべきですか？

主にセンサベースの認知・判断系（例：自動緊急ブレーキ、車線維持支援、歩行者検出など）やAIを活用したアルゴリズムが該当します。ADAS・自動運転系の機能が中心です。

Q3. SOTIFにASILの考え方はありますか？

SOTIFではASILの割り当ては行いません。リスク優先度は「発生可能性 × 結果の重大さ」に基づく評価で決まり、リスクに対して「妥当な安全（reasonable safety）」が達成されているかを検討します。

Q4. SOTIFの評価は設計段階だけで完結しますか？

いいえ。設計・実装・検証に加え、市場投入後もフィールドデータの監視と継続的なリスク管理（例：OTAログの分析、ユーザ行動パターンの検証）が求められます。

Q5. SOTIFの「トリガーイベント」とは何ですか？

リスクが顕在化するきっかけとなる外部条件や内部状態のことです。例えば「逆光で対象物が不明瞭」「誤った初期化設定」「センサデータ欠落」などが該当します。

Q6. SOTIFの「未知のリスク」とは具体的にどのようなものですか？

設計段階では想定されていなかった危険シナリオ（例：想定外の交通状況、データセットにない対象物、複合環境など）です。フィールドデータの収集・解析や仮説駆動試験により、後から発見されるリスクです。

Q7. SOTIFの「未知のリスク」はどこまで対処すべきですか？

完全な排除は困難ですが、未知リスクを想定したシナリオ探索・フェールファスト戦略・市場監視によって継続的にリスクを最小化することがSOTIFの考え方です。

Q8. SOTIFにおける「安全な挙動」とは何を意味しますか？

システムがその意図された機能を、誤作動や誤認識なしに、期待される条件下で提供できることです。必要であれば安全側へ制御移行（例：MRC＝Minimum Risk Condition）できることも含まれます。

リスクベースアプローチとASIL

危険を定量的に評価し、必要な安全レベルを決定する

ISO 26262の中核をなすのが、リスクベースアプローチ です。これは、システムが故障した場合に発生しうる潜在的な危険（ハザード）を特定し、そのリスクの大きさを評価した上で、リスクに応じた適切なレベルの安全対策を講じるという考え方です。すべてのリスクをゼロにすることは現実的ではないため、「社会的に許容可能なレベル」までリスクを低減することを目標とします。

このリスク評価プロセスは、ハザード分析およびリスクアセスメント (H&RA: Hazard Analysis and Risk Assessment) と呼ばれます。開発の初期段階（コンセプトフェーズ）で実施され、以下の3つの要素を考慮してリスクの大きさを評価します。

1. シビリティ (Severity, S): ハザードが発生した場合に想定される乗員や交通参加者の傷害の 重大性 （S0: 傷害なし ～ S3: 生命に関わる重傷/致命傷）。
2. エクスポージャ (Exposure, E): そのハザードにつながる可能性のある自動車の 状況 （危険な状況にどれだけ晒されるか）の 発生頻度 （E0: 極めて稀 ～ E4: 高確率）。
3. コントローラビリティ (Controllability, C): ハザードが発生した場合に、ドライバー（または他の交通参加者）がそれを 回避または制御できる 能力（C0: 容易に制御可能 ～ C3: 制御困難/制御不能）。

これらS, E, Cの評価結果を組み合わせることで、ASIL (Automotive Safety Integrity Level) と呼ばれる自動車用の安全度水準が決定されます。ASILは、以下の5段階で定義されます。

• ASIL D: 最も高い安全度水準。リスクが非常に高く、最も厳格な安全要求事項が課される（例：ブレーキシステム、ステアリングシステム、エアバッグ）。
• ASIL C: 高い安全度水準。
• ASIL B: 中程度の安全度水準（例：メーターの速度表示、ABS）。
• ASIL A: 最も低い安全度水準。リスクは比較的低いが、安全対策が必要。
• QM (Quality Management): リスクが十分に低く、特別な安全要求事項は不要。通常の品質管理プロセスで対応可能（例：カーオーディオ）。

決定されたASILは、その後の開発プロセス全体を通じて、要求されるプロセスの厳格さ、実施すべき安全分析の種類や深さ、検証・妥当性確認の方法、そしてハードウェア/ソフトウェア設計における技術的な安全要求事項（例：故障検出率、冗長化構成など）を決定するための重要な指標となります。リスクの大きさに応じて、開発にかける労力やコストを合理的に配分するための基準となるのです。

技術的な安全要求事項：故障への対策

システマティック故障とランダムハードウェア故障への具体的なアプローチ

ISO 26262は、開発プロセスだけでなく、E/Eシステムが持つべき技術的な安全能力についても、決定されたASILレベルに応じて具体的な要求事項を定めています。これらの要求は、主に「システマティック故障」と「ランダムハードウェア故障」という二種類の故障への対策として整理されます。

システマティック故障 (Systematic Failures) 対策:

• 設計仕様の誤り、開発プロセスの不備、ソフトウェアのバグなど、特定の原因によって確定的に発生する故障です。
• 対策の基本は、厳格な開発プロセス の遵守です。要求仕様の明確化、レビュー（設計レビュー、コードレビュー）、検証手法の適用（静的コード解析、動的解析、半形式的/形式的手法）、テストカバレッジの確保などが求められます。
• ソフトウェア開発においては、安全なソフトウェアアーキテクチャ設計（例：階層化、モジュール化、情報隠蔽）、コーディング規約（MISRA C/C++など）の遵守、使用する開発ツールの信頼性確認（ツール認定）なども重要です。

ランダムハードウェア故障 (Random Hardware Failures) 対策:

• 電子部品の物理的な劣化や製造ばらつきなどにより、偶発的に発生するハードウェア故障です。
• 対策は、故障が発生しても安全目標を侵害しないようにすること、あるいはその確率を許容レベル以下に抑えることに主眼が置かれます。
  • 故障検知 (Fault Detection): 故障をシステム自身が検知する能力。自己診断機能（電圧監視、メモリチェック、ロジックテスト、通信エラー検出など）や、冗長化された要素間の相互監視によって実現されます。検知能力は 診断カバレッジ (Diagnostic Coverage, DC) として定量化されます。
  • 故障影響の抑制 (Fault Tolerance / Control): 故障が検知された場合、あるいは検知できない場合でも、システムを安全な状態に移行させる（フェールセーフ）、または機能を維持する（フェールオペレーショナル）ための設計。冗長化（ハードウェア冗長、時間冗長、情報冗長）は、故障影響を抑制するための最も基本的な手法です。
  • 安全目標侵害確率の評価: ASIL CおよびDでは、ランダムハードウェア故障による安全目標の侵害確率が、規定された目標値以下であることを定量的に示す必要があります。そのための指標として以下が用いられます。
    • SPFM (Single-Point Fault Metric): 単一故障（Single-Point Fault）や、検知されずに残存する故障（Residual Fault）が直接安全目標を侵害しない割合。
    • LFM (Latent Fault Metric): 潜在故障（Latent Fault：複数点の故障が組み合わさって初めて危険な状態になる故障のうち、検知されずに隠れているもの）がシステム内に存在しない割合。
    • PMHF (Probabilistic Metric for Random Hardware Failures): 時間あたりのランダムハードウェア故障による安全目標の侵害確率。

これらの技術的要求事項は、ASILレベルが高いほど厳しくなります。例えば、ASIL Dでは非常に高い故障検出率や、より堅牢な冗長化構成、そして極めて低いPMHF目標値の達成が求められます。

安全ライフサイクルと開発プロセス

V字モデルに基づく体系的な安全活動

ISO 26262は、自動車の 安全ライフサイクル 全体、すなわち構想段階から運用、廃棄に至るまでの全てのフェーズにおける機能安全活動を規定しています。このライフサイクルは、一般的に V字モデル で表現される開発プロセスと密接に関連しています。
V字モデルの左側（下降プロセス）は仕様化と設計、右側（上昇プロセス）は検証と妥当性確認に対応します。

1. コンセプトフェーズ:
   • アイテム定義（対象システムの明確化）
   • ハザード分析とリスクアセスメント (H&RA) → ASIL決定
   • 安全目標 (Safety Goal) の設定（ASILに基づき、回避すべきハザードを定義）
   • 機能安全コンセプト (Functional Safety Concept) の策定（安全目標達成のためのシステムレベルの安全要求とアーキテクチャ概要）
2. システム開発フェーズ:
   • 技術安全要求仕様 (Technical Safety Requirements, TSR) の策定（機能安全コンセプトを具体的な技術仕様に落とし込み、HW/SWへの割り振り）
   • システム設計仕様の策定
   • システムレベルの安全分析（例：FMEA, FTA）
   • システム統合テスト仕様の策定
3. ハードウェア（HW）開発フェーズ:
   • HW安全要求仕様の策定
   • HW設計仕様の策定
   • HWレベルの安全分析（例：FMEA, FMEDA, FTA）
   • HW統合テスト・単体テスト仕様の策定
4. ソフトウェア（SW）開発フェーズ:
   • SW安全要求仕様の策定
   • SWアーキテクチャ設計仕様の策定
   • SWユニット設計・実装（コーディング規約の遵守など）
   • SWレベルの安全分析
   • SW統合テスト・ユニットテスト仕様の策定

V字モデルの右側では、各設計フェーズで作成された仕様や成果物に対して、テストによる 検証 (Verification) （要求通りに正しく作られているか）と、実環境での動作確認を含む 妥当性確認 (Validation) （そもそも意図した要求を満たしているか）が実施されます。システム → HW/SW → ユニットへと詳細化された要求仕様が、ユニット → HW/SW → システムへとテストを通じて検証され、最終的に安全目標が達成されていることを確認します。

これらの開発フェーズ全体を通じて、トレーサビリティ（追跡可能性） の確保が極めて重要です。安全目標から各レベルの安全要求、設計仕様、そしてテストケースまで、全ての要素が双方向に紐付けられ、変更があった場合の影響範囲を特定し、対応漏れを防ぐ必要があります。

さらに、これらの主要な開発プロセスを支える支援プロセスも規定されています。構成管理、変更管理、文書管理、検証、確認レビュー、監査、アセスメントなどが含まれ、開発プロセス全体の一貫性と品質を保証する上で不可欠な役割を果たします。