自動運転システムの機能安全（ISO 26262）とSOTIF：技術的要件と実装アプローチ
はじめに：自動運転における安全性の新たな次元
自動運転タクシーの実用化に向け、安全性は最も重要な要素の一つです。従来の車両安全は、衝突安全や乗員保護といった受動的な安全と、ABSやESCなどの運転支援システムによる能動的な安全によって成り立っていました。しかし、運転タスクそのものをシステムが担う自動運転システムにおいては、システムの機能不全や限界が直接的に安全に関わるため、より体系的で技術的な安全設計が求められます。
この要求に応える主要な技術標準として、ISO 26262（機能安全）とISO 21448（SOTIF: Safety of the Intended Functionality）が存在します。ISO 26262は主にシステムやコンポーネントの故障（ランダムハードウェア故障やシステム的故障）に起因する危険を管理するための規格であり、自動車分野の電気・電子システムの機能安全に特化しています。一方、SOTIFは、意図した機能（例えば自動運転機能）が正常に動作しているにも関わらず、センサーの限界やアルゴリズムの未検出など、予期せぬ状況によって発生する危険を管理するための規格です。自動運転システムの安全性を技術的に担保するためには、これら二つの規格に沿った設計、検証、妥当性確認が不可欠となります。
本稿では、これら二つの重要な技術標準が自動運転タクシーの開発においてどのように適用され、どのような技術的要件と実装アプローチが必要とされるのかを深掘りします。
機能安全（ISO 26262）の技術的アプローチ
ISO 26262は、自動車における電気・電子（E/E）システムの機能安全に関する国際規格です。この規格は、製品のライフサイクル全体（企画、開発、製造、運用、サービス、廃止）を通じて、危険事象を引き起こす可能性のあるシステムの故障モードを特定し、リスクを低減するためのプロセスと技術要件を定めています。
ハザード分析とASIL決定
ISO 26262の最初のステップは、ハザード分析とリスクアセスメント（HARA: Hazard Analysis and Risk Assessment）です。これは、車両レベルで潜在的な危険事象を特定し、各危険事象の「重大度 (Severity)」、「暴露頻度 (Exposure)」、「制御可能性 (Controllability)」を評価することで、要求される機能安全レベル（ASIL: Automotive Safety Integrity Level）を決定します。ASILはA、B、C、Dの4段階があり、ASIL Dが最も高い安全要求レベルを示します。
自動運転タクシーの場合、システムの故障が直接的に車両の制御不能を引き起こす可能性が高いため、「意図しない加減速」「意図しない操舵」「走行中の機能停止」といったハザードが特定されます。これらのハザードが引き起こす結果（例：追突、車線逸脱）の重大度、発生しうる運転状況（暴露頻度）、システムや運転者による危険回避の可能性（制御可能性）を評価し、例えばASIL Dのような高いASILレベルが要求される機能が存在することになります。
システム・ハードウェア・ソフトウェアレベルの技術要求
ISO 26262は、決定されたASILレベルに基づき、システム、ハードウェア、ソフトウェアの各レベルで満たすべき技術的な要求を定めています。
- システムレベル:
- 安全目標を達成するための安全機構の設計。
- システム構成における冗長化（例: センサーフュージョンによる認識の多重化、二重系または三重系の意思決定・制御経路）。
- 安全状態への遷移戦略（例: 故障検出時の最小リスク状態への移行）。
- 診断機能による故障検出率の向上。
- ハードウェアレベル:
- ハードウェア故障の評価（例: FMEDA: Failure Modes, Effects, and Diagnostic Analysis）。
- 安全機構の実装（例: ウォッチドッグタイマ、ECCメモリ）。
- 目標故障率の達成（SPFM: Single Point Fault Metric, LFM: Latent Fault Metric）。
- ソフトウェアレベル:
- 安全関連ソフトウェアの開発プロセス（要件定義、設計、実装、テスト、検証）。
- 安全標準やコーディング規約（例: MISRA C/C++）の遵守。
- 静的解析や動的テストによるソフトウェアの信頼性検証。
- モジュールレベルおよび統合レベルでのテストカバレッジの確保。
これらの技術的要求は、システム開発において計画段階から組み込まれ、厳格なレビューと検証プロセスを経て満たされていることが証明される必要があります。
SOTIF（ISO 21448）の技術的アプローチ
SOTIF（ISO 21448）は、ISO 26262だけではカバーしきれない、意図した機能の性能限界や予期せぬ状況によって発生する危険を扱います。自動運転システムは、センサーデータ、認識アルゴリズム、意思決定ロジックといった複雑な要素の組み合わせで構成されており、これらの機能が「故障ではないが、期待通りに機能しない」状況が発生し得ます。SOTIFは、このような「機能の不当な振る舞い」に起因するリスクを管理することを目的としています。
SOTIFの分析フレームワークとリスク
SOTIFでは、自動運転システムが遭遇する可能性のある交通状況や環境を分析し、以下の4つの領域に分類します。
- Known Safe: 意図した機能が適切に動作し、既知のハザードが存在しないか、リスクが許容可能なレベルに低減されている領域。
- Unknown Safe: 意図した機能が適切に動作すると思われるが、完全には検証されていない未知の領域。
- Known Unsafe: 意図した機能が不適切に動作することが既知であり、ハザードが存在する領域。
- Unknown Unsafe: 意図した機能が不適切に動作する可能性があるが、まだ特定・分析されていない未知の領域。
SOTIFの主な技術的課題は、「Known Unsafe」領域のリスクを低減し、「Unknown Unsafe」領域を特定して「Known Safe」またはリスク低減後の「Known Unsafe」へと移行させることです。
不当なリスク低減のための技術的アプローチ
SOTIFに基づく不当なリスクを低減するためには、以下のような技術的アプローチが重要になります。
- センサー能力の設計と限界分析: センサー（カメラ、LiDAR、レーダーなど）の検出範囲、解像度、悪天候耐性などの物理的限界を理解し、設計に反映させます。例えば、雨や霧の中でのLiDAR性能低下を補うために、レーダーや高性能カメラを併用するなどの対策が講じられます。
- 認識アルゴリズムのロバスト性向上: 様々な照明条件、障害物の種類、シーンの複雑さに対する認識アルゴリズム（例: CNNベースの物体検出、セマンティックセグメンテーション）の頑健性を高めます。 adversarial attackに対するロバスト性の検討も含まれます。
- 不確実性モデリング: センサーデータや認識結果に含まれる不確実性を定量化し、意思決定プロセスに反映させます。例えば、検出された物体位置や速度の推定に確率分布を用いるなどの手法があります。
- 運用設計領域 (ODD) の定義と管理: 自動運転システムが安全に機能できる地理的領域、天候、時間帯、道路種別、速度などの条件を明確に定義します。ODD外でのシステムの振る舞いを安全に担保するための技術的メカニズム（例: ODD逸脱警告、安全なシステム停止）を実装します。
- データに基づいたシナリオカバレッジ分析: 実走行データやシミュレーションデータを用いて、システムが遭遇しうるシナリオを網羅的に分析し、 Known Unsafe/Unknown Unsafe シナリオを特定します。特定されたシナリオに対して、アルゴリズム改善や新しい安全機構の実装を行います。
- 技術的な検証・妥当性確認:
- シミュレーション: 多様なシナリオ（特に危険性の高い、あるいは稀なシナリオ）を効率的にテストするために不可欠です。Corner caseシナリオの自動生成や、センサーモデルの精度向上といった技術が重要です。
- テストコース・限定領域での走行テスト: 制御された環境下で、特定の機能やKnown Unsafeシナリオに対するシステムの振る舞いを検証します。
- 公道走行テスト: 実際の交通環境でシステムの総合的な性能と安全性を確認します。走行データの収集・分析を通じて、Unknown Unsafeを発見し、システム改善に繋げます。
ISO 26262とSOTIFの関係性
ISO 26262とSOTIFは、自動運転システムの安全性を多角的に保証するための補完的な関係にあります。ISO 26262は主にシステム内部の故障に焦点を当てるのに対し、SOTIFはシステムが外部環境と相互作用する際の機能性能に起因するリスクに焦点を当てます。
例えば、自動運転タクシーが前方の障害物を検出できなかった場合を考えます。 * もし検出できなかった原因が、センサーの物理的な故障や通信エラーであれば、これはISO 26262のスコープとなります。システムの冗長設計や診断機能によって、故障を検出し安全状態へ移行することが求められます。 * もし検出できなかった原因が、センサーの性能限界（例: 悪天候、障害物の特殊な形状）や認識アルゴリズムの限界（例: 未学習の物体カテゴリ）であれば、これはSOTIFのスコープとなります。センサーフュージョンの改善、アルゴリズムのロバスト化、ODD管理、不確実性モデリングといった技術的な対策によって、このような状況下でのリスクを低減することが求められます。
自動運転タクシーの技術開発においては、これら二つの規格の要求を統合的に考慮し、システム全体として許容可能な安全レベルを達成する必要があります。
技術的な課題と今後の展望
機能安全とSOTIFに基づく自動運転システムの安全開発は、いくつかの技術的な課題に直面しています。
- AIベースシステムの検証・妥当性確認の難しさ: 機械学習モデルの内部動作はブラックボックス性が高く、特定の入力に対する出力の根拠を完全に説明することが難しい場合があります。ISO 26262やSOTIFの要求する厳密な検証・妥当性確認プロセスを、AIコンポーネントに対してどのように適用するかは継続的な研究開発課題です。AIモデルの説明可能性（XAI）や、統計的な手法を用いた信頼性評価が重要になります。
- Unknown Unsafeへの対応: AI技術の進化により、Known Unsafeシナリオへの対応能力は向上していますが、予期しない未知のシナリオ（Unknown Unsafe）の網羅的な特定と対策は本質的に困難です。実走行データからの異常検知、不測の事態に対する汎用的な安全戦略（例: 急制動、安全な場所への退避）、人間オペレーターによる遠隔支援などが、この課題への技術的アプローチとなります。
- 継続的な安全性の維持: OTA（Over-The-Air）アップデートによるソフトウェア更新は、システムの機能改善やバグ修正に不可欠ですが、同時に新たなリスクを持ち込む可能性もあります。アップデート後の安全性をどのように検証・妥当性確認し、運用中の安全性を持続的に担保していくかは、技術的な運用課題です。
- 標準化の進化: 自動運転技術は急速に進歩しており、現行のISO 26262やSOTIFも進化を続けています。新しい技術（例: センサー技術、AIアーキテクチャ）に対応するための規格改訂や、新しい規格の策定動向を追跡し、開発プロセスに反映させる必要があります。
結論
自動運転タクシーの実現において、機能安全（ISO 26262）とSOTIF（ISO 21448）は、技術的な安全性を構築するための二本柱となります。ISO 26262はシステム故障による危険を、SOTIFは機能の限界や予期せぬ状況による危険をそれぞれ管理します。
これらの規格に準拠した開発は、単に認証を取得するためだけでなく、システムの設計段階から潜在的な危険を抽出し、技術的な対策を講じるための体系的なフレームワークを提供します。冗長化されたシステムアーキテクチャ、ロバストな認識・判断アルゴリズム、不確実性を考慮した意思決定、定義されたODD内での運用、そして網羅的な検証・妥当性確認プロセスは、これらの規格の要求を満たすための重要な技術的要素です。
自動運転システムの複雑性と未知の領域への挑戦は続いており、AI技術の発展や新たなシナリオへの対応など、技術的な課題は山積しています。しかし、機能安全およびSOTIFのフレームワークに基づいた継続的な技術開発と検証努力こそが、自動運転タクシーの信頼性を高め、社会実装を確実なものとしていく基盤となります。