ブログ ISO 26262 と SOTIF (ISO 21448) の違いとは?機能安全との比較解説

ISO 26262 と SOTIF (ISO 21448) の違いとは?機能安全との比較解説

2025年12月4日 ALM お問い合わせ 無償試用版はこちら

Hanna Taller is a content creator for PTC’s ALM Marketing team. She is responsible for increasing brand awareness and driving thought leadership for Codebeamer. Hanna is passionate about creating insightful content centered around ALM, life sciences, automotive technology, and avionics.

この筆者の記事一覧を見る

ADAS(先進運転支援システム)から自動運転レベル3、4へと技術が急速に進化する中、車両開発における「安全性」の定義も拡大しています。これまで自動車業界では、電子システムやハードウェアの故障によって引き起こされる危険(バグや破損など)に対処するため、機能安全規格「ISO 26262」への準拠が事実上の義務とされてきました。

しかし、AI や高性能センサーが主導権を握る現代の車両では、「部品は故障していないのに、環境要因や認識ミスで事故が起きる」という新たなリスクが顕在化しています。このギャップを埋めるために策定されたのが、SOTIF (ISO 21448) です。本記事では、2022年に国際規格として正式発行されたISO 21448 (SOTIF) と、従来の ISO 26262(機能安全)の決定的な違いについて、最新の視点から解説します。

ISO 26262 と SOTIF の違い

自動車の安全性を確保する上で、ISO 26262(機能安全)と ISO 21448 (SOTIF) は、どちらも不可欠ですが、そのアプローチは大きく異なります。

最大の違いは、リスクの原因がシステムの「故障」にあるか、それとも故障していないシステムが直面する「性能限界や環境」にあるかという点です。

両者の主な相違点を以下の表にまとめました。

ISO 26262(機能安全) ISO 21448 (SOTIF)
安全の定義 システムの「故障」による不合理なリスクがないこと 意図した機能の「性能限界」
や「誤用」による不合理なリスクがないこと
対象となる原因
  • ハードウェアのランダム故障
  • ソフトウェアのバグや欠陥
  • 電子部品の経年劣化
  • センサーの認識限界(逆光、濃霧など)
  • AI やアルゴリズムの判断ミス
  • ドライバーが引き起こしそうな誤用
リスクの性質 既知の不安全
(予測できる故障への対策)
未知の不安全
(想定外のシナリオへの対策)
主な対策
  • 冗長化やフェイルセーフ設計
  • 厳格な開発プロセス(V 字モデル)
  • ASIL に基づくリスク低減
  • 大規模シミュレーション
  • コーナーケース(極端な事例)の検証
  • 機械学習データの拡張と改善

このように、ISO 26262 は「システムが設計通りに動かなくなった場合」の安全を担保するものです。対して SOTIF は、「システムは設計通りに動いているが、状況に対応しきれない場合」の安全を担保します。

自動運転車においては、これらが対立するものではなく、互いの抜け漏れを防ぐ「両輪」として機能することで、初めて公道での安全性が証明されることになります。

ISO 26262(機能安全)の概要と限界

システム故障への徹底的な対応

ISO 26262 (Road vehicles - Functional safety) は、自動車の電気・電子 (E/E) システムが「故障」した際に発生するリスクを最小限に抑えるための国際規格です。

親規格である IEC 61508 から派生したこの規格は、開発から廃棄に至るまでの製品ライフサイクル全体をカバーしており、自動車メーカーやサプライヤーにとって事実上の義務要件となっています。

機能安全の核心は、システムにバグやハードウェアの破損などの「不具合」が発生したとしても、人命に関わる危険な状態(ハザード)に陥らせないことにあります。具体的には、ASIL (Automotive Safety Integrity Level) というリスク指標を用いて危険度を評価し、それに応じた安全対策(冗長化やエラー検知など)を実装します。

機能安全が対象とする「故障」の例

 

ISO 26262 が防止しようとしているのは、以下のような「システム内部の異常」に起因する事故です。
  • 電子ステアリングシステムの故障による操舵アシストの喪失
  • 電子パーキングブレーキの誤作動
  • 衝突していないにも関わらず発生する意図しないエアバッグの展開
  • バッテリー制御システムの不具合による発火

ISO 26262 の「限界」とは

しかし、自動運転技術の高度化に伴い、ISO 26262 のアプローチだけではカバーできない領域が浮き彫りになりました。それは、「システムや部品は故障しておらず、設計通りに動いているにも関わらず発生する事故」です。

例えば、濃霧で前方が見えない状況でも、カメラが「異常なし」と判断して走行を続けた場合、カメラ自体は故障しておらず、正常に稼働しています。部品が壊れていない以上、機能安全 (ISO 26262) の観点では「正常」とみなされますが、車両としては「危険」な状態です。

この「故障なき危険」という空白地帯に対処するために、新たな概念である SOTIF が必要となったのです。

なお、ISO 26262 について詳しく知りたい方は、こちらの無料 eBook よりご覧いただけます。

ISO26262

ISO 26262 が自動車業界にもたらす機能安全とは?

ISO 26262 に準拠する際に陥りやすい8つの失敗と回避するための対策にちうて詳しく解説します。

詳細はこちら

 

SOTIF (ISO 21448) の概要と必要性

SOTIF(意図した機能の安全性)とは

SOTIF (Safety Of The Intended Functionality) は、日本語で「意図した機能の安全性」と訳されます。ISO 26262 が「システムの故障」を扱うのに対し、SOTIF は「システムが故障していないにも関わらず、性能限界や予期せぬ環境変化によって発生するリスク」を扱います。

この規格は当初、ISO 26262 のパート14として検討されていましたが、自動運転技術における「故障なき危険」の対応があまりに複雑で重要性が高いため、独立した規格として策定が進められました。その後、2022年に国際規格「ISO 21448:2022」として正式に発行されています。

故障なき危険の例

SOTIF が対処すべき典型的な例には以下のようなものがあります。

  • 逆光や濃霧により、カメラセンサーが前方車両を見失う
  • 路面の汚れや消えかけた白線をシステムが誤認識し、対向車線にはみ出す
  • 雪景色を「障害物のない道路」とAI が誤判断する
  • ドライバーがシステムの性能を過信し、警告を無視して手放し運転を行う(誤用)

「未知の不安全」を「既知の安全」へ

SOTIF の最大の目的は、「未知の不安全 (Unknown Unsafe)」な領域を縮小することです。

開発段階では想定していなかった(未知の)危険なシナリオを、シミュレーションや公道走行テストを通じて洗い出し、それらを一つずつ対策可能な(既知の)状態へと変えていくプロセスが求められます。

AI・機械学習と SOTIF の深い関係

自動運転車の頭脳である AI(機械学習・ディープラーニング)は、SOTIF において最も重要な検討対象です。

AI は従来のプログラムと異なり、なぜその判断を下したのかという論理がブラックボックス化しやすく、特定の条件下でのみ誤った判断を下す可能性があります。

ISO 21448 では、AI のトレーニングデータに偏りがないか、未知のシナリオに対してAI がどう振る舞うかを厳密に検証することを求めています。そのため、自動車メーカーは SOTIF 準拠のために、数百万キロに及ぶ仮想シミュレーションや、エッジケース(極端な事例)を含む膨大なデータセットを用いた検証が不可欠となっています。

具体例で見る違い

理論だけでなく、実際の走行シーンでどのような違いとして現れるのか、2つの具体例で比較してみましょう。

例1:ISO 26262(機能安全)のケース

  • 状況
    高速道路を自動走行中、電子制御ステアリング (EPS) のモーター内部で断線が発生した。
  • 結果
    ステアリングのアシスト力が突然失われ、操舵不能になる危険が生じる。

このような状況はハードウェアの「故障」と言えます。

ISO 26262 に基づく設計では、このような故障が発生した瞬間にシステムが異常を検知し、予備の回路に切り替える(冗長化)か、安全に路肩へ停止する(フェイルセーフ)ことが求められます。これが「機能安全」の領域です。

例2:ISO 21448 (SOTIF) のケース

  • 状況:
    高速道路を自動走行中、突発的な濃霧が発生し、視界が真っ白になった。 車載カメラ自体は「正常」に稼働しており、故障はしていない。
  • 結果:
    カメラは映像を送り続けるが、白線や先行車が映っていないため、AI が「前方に障害物なし」と誤判断し、減速せずに走行を続けて衝突事故を起こす。

このような状況では、ハードウェアもソフトウェアも「故障していません」。

カメラは仕様通りに映像を撮影し、AI はプログラム通りに処理を行いました。しかし、システムの「性能限界(霧を見通せない)」を超えた環境に置かれたことで、危険な挙動を引き起こしました。

SOTIF では、こうした事態を防ぐために「霧を検知したらドライバーに運転権限を移譲する」あるいは「カメラだけでなくミリ波レーダー(霧に強い)を併用して判断する」といった対策を講じます。

両規格に準拠した開発プロセスの重要性

複雑化する開発現場の課題

ここまで解説した通り、自動運転車の開発においては、ISO 26262(機能安全)と ISO 21448 (SOTIF) という、性質の異なる2つの規格に同時に準拠する必要があります。

  • ISO 26262:V 字モデルに基づく厳格なプロセス管理と、故障率の計算
  • SOTIF:シミュレーションと再検証を繰り返すイテレーティブ(反復的)なプロセスと、膨大なシナリオ分析

これらを別々のツールや Excel で管理していると、「あるセンサーの仕様変更が、機能安全上の故障率と、SOTIF 上の認識性能の両方にどう影響するか」を追跡(トレース)することが極めて困難になります。結果として、設計の不整合や、認証取得の遅れを招くリスクが高まります。

Codebeamer によるトレーサビリティの一元管理

こうした課題を解決するためには、要件定義からリスク分析、テスト管理に至るまで、すべてのプロセスを単一のプラットフォームで統合管理することが重要と言えます。

PTC の Codebeamer は、自動車業界の厳格な規制に対応した ALM(アプリケーションライフサイクル管理)ソフトウェアです。

Codebeamer を活用することで、ISO 26262 が求める「故障リスク」と、SOTIF が求める「機能限界リスク」を、同一のシステム内で関連付けて管理できます。具体的には、下記のような機能やメリットがあります。

  • トレーサビリティ:要件、リスク、テストケース、検証結果の相互リンクを自動化し、変更の影響範囲を即座に特定
  • コンプライアンス対応:監査に必要なドキュメントやレポートを自動生成し、認証プロセスを効率化
  • テンプレート活用:自動車業界標準のテンプレートにより、立ち上げ期間を短縮

自動運転の安全性を証明するためには、規格への理解だけでなく、それを支える強固な開発プロセスとツールが不可欠です。

Codebeamer

Codebeamer:ALM ソリューション

Codebeamer は、コラボレーション、トレーサビリティ、セキュリティ、プロセス管理を実現するアプリケーションライフサイクル管理 (ALM) プラットフォームです。

詳細はこちら

 

事例:Codebeamer で安全性を向上させた Veoneer 社のケース

世界的な自動車安全システムプロバイダーである Veoneer 社は、旧来のツール(IBM DOORS など)からの脱却を目指し、Codebeamer を標準ツールとして採用しました。

導入の決め手:

  • ISO 26262、FMEA、Automotive SPICE に標準機能で対応している
  • V 字開発プロセス全体でリアルタイムのトレーサビリティが確保できる
  • 直感的な操作性(トレーニング時間が4.5日から45分へ短縮)

成果:

Codebeamer の導入により、「1 Veoneer, 1 Process」というグローバル統一プロセスを実現。ソフトウェア、ハードウェア、製造、監査の全部門が単一のプラットフォームで連携し、複雑化する安全規制への対応と開発スピードの向上を両立させています。

Veoneer 社の事例詳細はこちら

よくあるご質問 (Q&A)

Q. SOTIF (ISO 21448) は ISO 26262 の一部ですか?

A. いいえ、現在は独立した国際規格です。

当初は ISO 26262 のパート14として検討されていましたが、内容の複雑さと重要性から分離され、2022年に ISO 21448:2022 として正式に発行されました。現在は、ISO 26262(機能安全)を補完する規格として位置づけられています。

Q. 自動運転車を開発する場合、SOTIF への準拠は義務ですか?

A. 法的な強制力は国や地域によりますが、製造物責任(PL 法)の観点からは準拠が強く推奨されます。

万が一事故が起きた際、ISO 21448 に準拠していることは「十分な安全対策を行っていた(State of the Art:最高水準の技術)」という証明になり、メーカーの責任リスクを低減する要素となります。

Q. ISO 26262 と SOTIF の一番の違いは何ですか?

A. リスクの原因が「故障」か「性能限界」かの違いです。

ISO 26262 は部品が壊れたりバグが発生したりする「故障」への対策です。一方、SOTIF は部品が壊れていなくても、霧でカメラが見えない、AI が誤判断するといった「性能限界・環境要因」への対策です。安全な自動運転には両方の対応が不可欠です。

まとめ:安全な自動運転の実現に向けて

自動運転車の実用化に向けた競争が激化する中、安全性への要求はかつてないほど高まっています。

本記事で解説した通り、ISO 26262(機能安全)による「故障への備え」と、ISO 21448 (SOTIF) による「未知の環境への備え」は、どちらも欠かすことのできない車の両輪です。

これら2つの異なるアプローチを深く理解し、開発プロセスの中で適切に統合していくことこそが、信頼される自動運転車を市場へ送り出すための鍵となります。

【関連情報】自動車業界向けソリューション
自動車業界の DX と規制対応を包括的に支援するソリューションについては、こちらからご確認いただけます。

https://www.ptc.com/ja/industries/automotive

ALM ソフトウェア「Codebeamer」で規格対応を効率化

30日間無償試用版で、実際の機能を体験する

ISO 26262 や SOTIF に対応したプロセス管理が、Codebeamer によってどれほど簡素化できるかを実際にご確認ください。

あらかじめ定義された自動車業界向けワークフローやテンプレートを利用し、トレーサビリティの自動化やチーム間の連携強化をすぐにご体験いただけます。

Codebeamer trial

ALM Codebeamer 無料体験版

Codebeamer の機能を実際に30日間試してみませんか?

詳細はこちら

専門家に直接相談する(導入・移行・価格)

「自社の開発プロセスに合わせた運用は可能?」「既存ツール(DOORS等)からの移行方法は?」といった具体的なご相談に、専門スタッフがお応えします。お客様の課題をヒアリングし、最適なプランをご提案します。

Inquiry

お問い合わせ

Codebeamer エキスパートにお気軽にお問い合わせください。

詳細はこちら

 

CTA Image

Codebeamer の無償試用版はこちら

複雑な製品やソフトウェアエンジニアリングを大幅に簡素化。Codebeamer オープンプラットフォームの無償試用版は、ALM 機能にプロダクトラインの構成機能を統合し、複雑なプロセスに独自の構成を提供できます。

無償試用版はこちら
Hanna Taller

Hanna Taller is a content creator for PTC’s ALM Marketing team. She is responsible for increasing brand awareness and driving thought leadership for Codebeamer. Hanna is passionate about creating insightful content centered around ALM, life sciences, automotive technology, and avionics.

次のホワイトペーパー