本記事は、自動車の安全性確保に不可欠な「ISO 26262(自動車の機能安全規格)」について、その全体像を解説するものです。
「ASILとは何か?」「HARAの進め方は?」といった疑問に答えながら、規格の基本から専門用語までを、表などを交えてわかりやすく紐解いていきます。
この記事を読むだけでISO 26262の要点を体系的に理解できることを目指します。

ISO 26262とは何か? 自動車の機能安全規格
現代の自動車は、かつての機械中心の構造から、多数のECU(Electronic Control Unit)に制御される高度な電気・電子(E/E)システムの集合体へと進化してきました。
このE/Eシステムの高度化は、自動車に利便性と快適性をもたらす一方で、新たなリスクを生み出しました。それは、システムの「機能不全」が人命に関わる重大な事故を引き起こしかねないというリスクです。
このような背景から、自動車業界における安全設計の共通言語として制定されたのが、国際標準規格「ISO 26262」です。

多数の電子制御装置が搭載された車両の構成例(自動車用先端SoC技術研究組合)
機能安全とは何か?ISO 26262の目的
ISO 26262を理解する上で、まず押さえるべき中心的な概念が「機能安全(Functional Safety)」です。機能安全とは、規格のPart1(用語集)において
「電気電子(E/E)システムの機能不全のふるまいにより引き起こされるハザードが原因となる、不合理なリスクの不在」
と定義されています。
これを平易に解釈すると、「万が一、システムが故障しても、フェールセーフ(故障しても安全な状態に移行すること)などの安全機能を設けることで、ドライバーや乗員、周囲の交通参加者など人間に危害が及ぶような危険な事態を、許容できるレベルまで低減する」という考え方です。
ここで重要なのは、「故障は起こり得る」という前提に立っている点です。何十万行ものコードで構成される複雑なソフトウェアや、無数の電子部品から成る現代のE/Eシステムにおいて、故障の可能性をゼロにすることは現実的ではありません。
そこで機能安全は、故障の発生を前提とし、それでもなお一定の安全性を確保するための体系的なアプローチを取ります。
この機能安全を実現することが、ISO 26262の最大の目的です。
ISO26262制定の背景
ISO 26262がなぜ必要とされるようになったのか、その背景には自動車産業の劇的な技術変革があります。
1990年代以降、自動車の電子化は急速に進み、搭載されるECUの数は数十個に及び、それらが連携して車両全体を制御するようになりました。 エアバッグ、ABS(アンチロック・ブレーキ・システム)、ESC(横滑り防止装置)といった安全装備の普及は、E/Eシステムなしにはあり得ませんでした。
しかし、システムの複雑化は、新たな課題を生み出します。それは、個々の部品は正しくても、システム全体として意図しない振る舞いを起こす可能性や、ソフトウェアのバグ、ハードウェアのランダムな故障が、かつては想定されなかったような危険を引き起こすリスクです。
こうした状況を受け、産業分野全般の機能安全を包括的に扱っていた国際規格「IEC 61508」をベースとして、自動車分野に特化した派生規格の策定が始まりました。
そして2011年、ISO 26262の初版が発行されます。 この規格は、自動車業界における安全設計の共通言語となり、自動車メーカーと部品サプライヤーが同じ基準で安全について議論し、開発を進めるための土台としての役割を担っています。
| 年代/年 | 出来事 |
| 1990年代以降 | 自動車の電子化が急速に進展。ECUの搭載数が増え、新たな安全上のリスクが課題となる。 |
| (規格策定期間) | 産業分野全般の機能安全規格「IEC 61508」をベース(親規格)として、自動車の量産開発プロセスや特有の環境を考慮した派生規格の策定が開始。 |
| 2011年 | 自動車の機能安全に関する国際規格「ISO 26262」の初版が発行。 |
| 2018年 | 第2版が発行。適用範囲がトラックや二輪車へ拡大され、半導体に関するガイドラインも追加された。 |
SOTIF(ISO21448)との違い
ISO 26262は、2018年に第2版へと改訂されました。この改訂では、初版では対象外だった総重量3.5トン超のトラックやバス、二輪車なども適用範囲に含まれるようになり、さらに半導体開発に関するガイドラインが追加されました。
しかし、第2版の改訂と並行して、自動車業界では新たな安全性の課題が顕在化していました。それは、ADAS(先進運転支援システム)や自動運転技術の進化に伴う課題です。
これらのシステムは、カメラやLiDARといったセンサーを用いて外部環境を認識し、AIや機械学習アルゴリズムによって状況を判断します。ここで問題となるのが、「システムは故障していないにもかかわらず、機能が不十分な為に危険な状況が発生する」ケースです。
これらはシステムの「故障」ではありません。むしろ、システムが「意図したとおりだが不十分な機能」により生じる安全上のリスクです。このような課題に対応するために生まれたのが、「SOTIF(Safety Of The Intended Functionality:意図した機能の安全性)」という新しい概念であり、2022年に国際規格「ISO 21448」として発行されました。
| ISO 26262(機能安全) | E/Eシステムの故障に起因するハザードを対象。電子部品のランダムな故障や、ソフトウェアの体系的な(設計上の)不具合によって引き起こされる危険を扱う。 |
| SOTIF(意図した機能の安全性) | システムの機能仕様や性能の限界など、故障以外の要因に起因するハザードを対象。センサーの性能限界、AIの判断ミス、ドライバーの誤用(ヒューマンエラー)などが含まれる。 |
言い換えれば、ISO 26262が「システムが壊れたときの安全性」を担保するのに対し、SOTIFは「システムが壊れていないときの安全性」を追求する規格です。自動運転レベルが高度化するにつれて、AIやセンサーの役割は増大し、SOTIFの重要性はますます高まっています。現代の自動車開発において、ISO 26262とSOTIFは、安全性を確保するための両輪として機能しているのです。
ISO 26262の規格構成(Part1〜Part12)と全体像
ISO 26262は、自動車のコンセプト策定から開発、生産、運用、そして廃棄に至るまでの全ライフサイクルを網羅しています。その全体像を理解するために、本規格がどのような構造で成り立っているのか、そして開発プロセスとどう関連しているのかを解説します。
V字モデルで見る開発ライフサイクル全体像
ISO 26262の開発プロセスは、一般的に「V字モデル」を用いて説明されます。 V字モデルは、ソフトウェアやシステムの開発工程を視覚的に表現したもので、開発プロセスの流れと、それに対応する検証・妥当性確認プロセスとの関係性を明確に示します。
V字の左側は、要求定義から設計、実装へと進むフェーズです。V字の谷底が実装の完了地点となり、ここから右側のフェーズへと移ります。V字モデルの特徴は、左右の各工程が水平に対応している点です。

この対応関係により、「どの要求が、どの設計に反映され、どのテストで検証されたのか」というトレーサビリティ(追跡可能性)を確保することが可能になります。ISO 26262では、このトレーサビリティの確保が極めて重要視されます。
各Partの役割解説
ISO 26262は、前述のV字モデルに沿った開発ライフサイクルをカバーするため、全12のパートで構成されています。
| Part | 名称 | 概要 |
| Part 1 | 用語集 | 規格全体で使われる用語を定義します。 |
| Part 2 | 機能安全の管理 | 安全文化の醸成や開発プロセス全体の管理体制を規定します。 |
| Part 3 | コンセプトフェーズ | アイテム定義、HARA(ハザード分析とリスク評価)を実施します。 |
| Part 4 | システムレベルの製品開発 | システムレベルでの安全要求仕様の策定と設計、テストを行います。 |
| Part 5 | ハードウェアレベルの製品開発 | ハードウェアの安全要求仕様の策定と設計、テストを行います。 |
| Part 6 | ソフトウェアレベルの製品開発 | ソフトウェアの安全要求仕様の策定と、設計、コーディング、テストを行います。 |
| Part 7 | 生産、運用、サービス、廃棄 | 量産から市場での運用、廃棄までの安全活動を規定します。 |
| Part 8 | 支援プロセス | 構成管理、変更管理、文書管理など開発全体を支えるプロセスです。 |
| Part 9 | ASIL指向および安全性指向の分析 | ASILの求め方や従属故障分析などの詳細な安全分析手法を扱います。 |
| Part 10 | ISO 26262のガイドライン | 規格の解釈を助けるための補足的なガイドラインです。 |
| Part 11 | 半導体への適用ガイドライン | IPやSoCなど半導体開発への適用方法を解説します(第2版で追加)。 |
| Part 12 | 二輪車への適用 | 二輪車特有の考慮事項を規定します(第2版で追加)。 |
ISO 26262におけるASIL(自動車安全度水準)の重要性
ISO 26262を貫く最も重要な概念の一つが、「ASIL(Automotive Safety Integrity Level:自動車安全度水準)」です。
ASILは、開発するシステムに故障が発生した場合に、どれほどのリスク(危険度)があるかを示す指標であり、規格対応のあらゆる活動の厳格さを決定するものさしとして機能します。
ASILとは?4段階のリスク分類
ASILは、ハザードのリスクレベルを客観的に評価し、分類するための指標です。 そのレベルは、最もリスクが低い「ASIL A」から、最もリスクが高い「ASIL D」までの4段階に分類されます。
これらに加えて、安全要求が特に必要ないレベルとして「QM(Quality Management)」が定義されています。
各機能のASILは自動車メーカーが導出します。例えば、ブレーキ制御はASIL D、カーオーディオはQMなどです。
| ASILランク | リスクレベル | 安全要求の厳格度 |
| ASIL D | 非常に高い | 最も厳しい |
| ASIL C | 高い | 厳しい |
| ASIL B | 中程度 | 中程度 |
| ASIL A | 低い | 基本的 |
| QM | ごく低い | 一般的な品質管理 |
3つの要素で決まるASILの導出方法
ASILは、規格で定められた客観的な手法に基づいて導出されます。その際に評価するのが、以下の3つの要素です。
| 名称 | 説明 |
| S:Severity(危害の深刻度) | 危険事象が発生した場合に、人がどれほど深刻な危害を被るかを示します。 |
| E:Exposure(危険状況への曝露頻度) | 危険事象につながる可能性のある運転状況に、どれくらいの頻度で遭遇するかを示します。 |
| C:Controllability(ドライバーによる回避可能性) | 危険事象が発生した際に、ドライバーがそれを回避できる可能性の高さを示します。 |
これらS、E、Cの3つの要素をそれぞれクラス分けし、その組み合わせを規格で定められた表に当てはめることで、ASIL AからD、またはQMが決定されます。
例えば、ブレーキ故障のように深刻な危害につながりやすく、ドライバーが回避できない機能は、最も高いASIL Dに分類される傾向があります。
ISO 26262のHARA(ハザード分析とリスク評価)のプロセス
ASILを導出するための具体的なプロセスが「HARA(Hazard Analysis and Risk Assessment:ハザード分析とリスク評価)」です。HARAは、安全なシステムを設計するための出発点であり、その後の開発全体の方向性を決定づける、極めて重要な活動です。
HARAの目的
HARAの最大の目的は、開発対象のシステム(アイテム)に潜むあらゆるハザードを網羅的に洗い出し、それらが引き起こすリスクを客観的に評価することで、達成すべき「安全目標(Safety Goal)」と、その厳格度を示す「ASIL」を定義することです。開発の初期段階でリスクを徹底的に洗い出し、安全の「土台」を固めることで、後工程での甚大な手戻りを防ぎ、効率的な開発を実現します。
HARAの進め方
HARAでは、まず開発対象のシステムが持つ機能から潜在的なハザードを網羅的に洗い出し、そのハザードがどのような運転シナリオで危険につながるかを想定します。その上で、各シナリオのリスクを前述のS, E, Cの観点で評価し、ASILを導出するというステップで進められます。
安全目標(Safety Goal)の設定
HARAの最終的な成果物として、特定された重大なリスクを低減するための最上位の安全要求である「安全目標(Safety Goal)」がASILと共に設定されます。
例えば、「高速走行中の意図しないブレーキ作動を防止する(ASIL D)」といった形で定義されます。この安全目標が、後続のシステム設計、ハードウェア・ソフトウェア開発におけるすべての安全要求の出発点となります。
車載ソフトウェア開発におけるISO 26262の適用事例
ISO 26262、特にそのPart 6は、車載ソフトウェア開発に対して厳格なプロセスを要求します。先進的な開発現場では、規格要求を効率的かつ効果的に満たすため、モデルベース開発(MBD)やツール認証といったアプローチが積極的に活用されています。
ケース1:モデルベース開発(MBD)による検証の効率化
MBDは、実現したい制御機能の振る舞いをグラフィカルな「モデル」で表現し、開発の早い段階からシミュレーションを行う手法です。
これにより、実際のECUのハードウェアとソフトウェアが完成する前に設計上の欠陥を発見できるため、後工程での手戻りを削減します。
ケース2:開発ツールチェーンの信頼性証明(ツール認証)
規格準拠のためには、開発に使用するツール自体の信頼性も証明しなくてはなりません。コンパイラやOS、静的解析ツールといった開発ツールチェーンに不具合があれば、最終製品の安全性が脅かされるからです。これが「ツール認証」です。
多くのツールベンダーは、第三者認証機関から認証を受けた「認証済みツール」を提供しており、これを利用することで信頼性証明を簡略化できます。
ISO 26262への対応が企業にもたらすメリットと課題
ISO 26262への準拠は、自動車メーカーやサプライヤーにとって避けては通れない経営課題です。
規格対応には多大な労力とコストを要しますが、それを上回る戦略的なメリットが存在する一方で、乗り越えるべき課題も少なくありません。
対応のメリットは市場競争力の強化と品質向上
メリットの一つは、グローバル市場における競争力の強化でしょう。規格準拠は製品の安全性を客観的に証明する「グローバルパスポート」となり、特に欧米や中国メーカーとの取引でビジネスチャンスが拡大します。
また、規格が要求する体系的な開発プロセスは、属人化を排除し、開発初期段階での欠陥発見を促進するため、製品品質の向上と手戻り削減に直結します。これにより、開発ノウハウが組織に蓄積され、チーム全体の能力向上にも繋がるでしょう。
乗り越えるべき課題はコスト、工数、人材育成
その一方で、企業はいくつかの課題に直面します。
最も直接的な課題は、安全分析や検証、さまざまな文書作成に伴う開発コストと工数の増大です。従来の開発プロセスに追加の活動が必要となるため、短期的な視点では開発期間が長期化する可能性があります。
さらに、規格を深く理解し、プロジェクトを主導できる専門人材の不足も問題です。機能安全の専門家をいかにして確保・育成するかは、多くの企業にとって重要な経営課題でしょう。
まとめ
ISO 26262は、自動車開発における安全性の羅針盤となる不可欠な規格です。企業は規格対応を単なるコストとしてではなく、製品競争力を高める戦略的投資と位置づけるべきでしょう。
STELAQの国際規格適合コンサルティングサービスでプロジェクトを成功に導きます
STELAQでは、ISO26262やSOTIFをはじめとする、国際/業界標準規格に準拠した開発プロセスの導入・定着を支援しています。当社コンサルタントが伴走し、車載ソフトウェア開発におけるプロセスとプロダクトの品質向上に寄与します。
- 取引先より準拠要請があったが、何から始めたら良いかわからない
- 準拠プロセスと開発現場にギャップがあり、運用がうまくできていない
- 成果物の作成に人手が足りない
- 教育担当部署がなく、現場社員の理解・協力が進まない
など、国際規格への準拠、社内体制含むプロセス構築、現場教育などに課題をお持ちでしたら、ぜひ一度STELAQにご相談ください。貴社の状況に合わせた最適な支援プランをご提案し、プロジェクト成功を全力でサポートいたします。