ISO 26262とは何か：自動車の機能安全規格の全体像

ISO 26262は、自動車に搭載される電気・電子（E/E）システムの故障に起因するリスクを、開発プロセス全体で体系的に低減するための国際規格です。

本記事では、機能安全（FuSa）の考え方から、適用範囲、規格（Part 1〜12）の構造、ASILやHARAの要点、ソフトウェア／ハードウェア開発での実務ポイント、監査・アセスメントまでを俯瞰します。

最後に、ISO 26262対応によって得られるメリットと、未対応時のリスク、導入時の課題や関連規格（Automotive SPICE）との関係を整理し、これから取り組む際の道筋を示します。

車載ソフトウェア開発のお問い合わせはこちら

AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援

機能安全（FuSa）とISO 26262の目的

機能安全は「故障が起こり得る」前提で、不合理なリスクがない状態へ導くための考え方です。ISO 26262はその実現を自動車開発で共通化することを目的にしています。

機能安全とは、部品やソフトウェアがいつか故障する現実を前提に、それでも人命や重大事故につながる危険を許容できる水準まで下げるアプローチです。ここで重要なのは「故障ゼロ」を目指すのではなく、「故障しても危険にならない」設計と開発の仕組みにする点です。

ISO 26262は、自動車のE/Eシステムに対して、この考え方を開発の共通言語として落とし込みます。安全目標の決め方、要求の作り方、設計・実装・テスト・変更管理のやり方まで、誰が見ても説明できる形で一貫させることを求めます。

規格対応の本質は、成果物の量を増やすことではなく、判断の根拠を追えるようにすることです。リスク評価の前提、要求分解の理由、検証で何をもって合格としたかが辿れると、手戻りや議論の迷走が減り、安全と開発効率の両方を押し上げます。

ISO 26262が求められる背景

車両の電子化・ソフトウェア化が進み、システム間連携が複雑化したことで、単体品質だけでは事故リスクを十分に抑えられなくなりました。

現代の車は、多数のECUやセンサー、通信ネットワークで車両全体を制御しています。単一の装置が正しくても、複数システムが連携することで想定外の振る舞いが起きる可能性が増え、従来の部品単位の品質保証だけでは限界が出てきました。

ソフトウェア規模の増大も背景です。バグは「作り込み」だけでは避けきれず、仕様の抜けや誤解、例外処理の不足など、設計の不備が危険な状態を引き起こし得ます。だからこそ、上流で危険を定義し、要求からテストまで筋を通すプロセスが必要になります。

さらに、完成車メーカーとサプライヤーの分業が進むほど、前提のずれが事故の芽になります。ISO 26262は、アイテム定義や安全要求、インターフェースの明確化を通じて、企業間でも安全を「説明可能」にする枠組みとして機能します。

対象範囲：対象車両・システム・開発フェーズ

ISO 26262は、車両カテゴリー、対象となるE/Eシステム、そしてコンセプトから廃棄までのライフサイクルを通じて、どこまで適用するかを明確に定義します。

対象は基本的に自動車のE/Eシステムで、機能不全が安全に影響する機能が中心です。ポイントは「どのECUが対象か」ではなく、「どの機能が安全関連か」を起点に範囲を切ることです。ここが曖昧だと、後から安全要求が追加されて大きな手戻りになります。

開発フェーズはコンセプト、システム設計、ハード設計、ソフトウェア設計、検証・妥当性確認までに加え、生産、運用、サービス、廃棄まで含みます。量産後の不具合対応やソフトウェア更新が一般化した今、開発だけ整えても安全が維持できないためです。

実務では、ライフサイクル全体を一度に完璧に整えるより、まずは安全計画とHARA、要求分解とトレーサビリティの骨格を作り、変更管理・構成管理で運用を安定させるのが近道です。範囲と責任分界を明文化することが、適用の成否を左右します。

対象外：SOTIF（ISO 21448）との違い

ISO 26262が扱うのは「故障に起因する危険」です。一方で、故障がなくても意図した機能の限界で危険が生じる領域はSOTIFが主にカバーします。

ISO 26262は、センサー断線や計算ミス、ソフトウェア不具合など「故障」により想定外の振る舞いが起きることを対象にします。つまり、壊れた・間違った状態を前提に、安全目標や安全メカニズムでリスクを下げる枠組みです。

一方SOTIFは、故障していないのに危険が生じるケースを扱います。例えば、カメラが逆光で歩行者を認識できない、学習データの偏りで特定条件の判断が弱いなど、性能限界や仕様の不備が原因のリスクが中心です。

ADASや自動運転に近い領域では、両者を切り分けて考えるのが重要です。故障対策だけを強化しても、意図した機能の限界が残れば事故は防げません。逆に、SOTIFだけを進めても、ランダム故障やソフウェアトの体系的故障が抜けると安全は成立しません。

車載ソフトウェア開発のお問い合わせはこちら

AUTOSAR・機能安全から車載Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援

ISO 26262の規格構成（Part 1〜12）

ISO 26262は複数のPartで役割分担され、管理・コンセプト・開発（システム／HW／SW）・生産運用・支援プロセス・分析手法までを網羅します。

Partごとに要求が分かれているのは、機能安全を一部門だけで完結させないためです。安全は設計だけでなく、計画、変更管理、検証、量産後の対応まで含む「システム」だからです。

読み進めるコツは、まず全体の流れをV字モデルでつかみ、次に主要Partがどの工程と成果物を要求するかを把握することです。細かな手法に入る前に、どの成果物が次工程の入力になるのかを理解すると、規格が単なるチェックリストではなく開発の設計図として機能します。

現場では、Partの要求をそのままドキュメントに写すと運用が破綻しがちです。プロジェクトの開発形態（アジャイル、MBD、外部委託など）に合わせて、成果物の最小単位とレビューゲートを設計し、トレーサビリティを保てる形に整えることが重要です。

V字モデルで理解する開発ライフサイクル

V字モデルは、左側で要求定義から設計、実装へ落としていき、右側で単体テストから統合テスト、システムテスト、妥当性確認へ積み上げていく考え方です。ISO 26262では、この左右の対応関係が崩れないようにすることが本質的な狙いです。

例えば、上位の安全目標から派生した安全要求が、どのシステム設計要素に反映され、どのソフトウェア・ハードウェア要素に落ち、どのテストで検証されたかを追える必要があります。これがトレーサビリティで、監査やアセスメントで必ず確認されます。

実装後にテストを増やしても、そもそもの要求が曖昧なら安全は証明できません。V字モデルで重要なのは、左側で「検証可能な要求」を作り、右側でその要求に対する合否基準を明確にして証拠を残すことです。

主要Partの役割（概念・システム・ハード・ソフト・生産・運用）

全体を押さえる上で、まず見る頻度が高いのはPart 2、3、4、5、6、7、8、9です。Part 2は機能安全管理で、計画、役割、独立性、力量など運用の土台を定めます。

Part 3はコンセプトで、アイテム定義とHARAを通じて安全目標を作ります。Part 4はシステム開発で、技術安全コンセプトやシステム要求、システム検証を扱います。Part 5とPart 6はそれぞれソフトウェアとハードウェアの詳細開発で、設計・実装・テストの要求が具体化されています。

Part 7は生産・運用・サービス・廃棄までを扱い、市場で安全を維持する視点を提供します。Part 8は構成管理や変更管理など支援プロセスで、実務上はここが弱いと安全要求が崩れます。Part 9はASIL導出や依存故障分析など分析手法を深掘りし、論理の一貫性を補強します。

安全度水準ASILの基礎

ASILは、リスクの大きさに応じて要求される安全活動の厳格さを決める“ものさし”であり、以降の安全要求や検証レベルを左右します。

ASILは「危険がどれほど深刻で、どれだけ起こりやすく、どれだけ回避しにくいか」を基に決まります。ASILが上がるほど、要求仕様の厳密さ、独立レビュー、テストの深さ、分析の追加などが増えます。

重要なのは、ASILが設計のためのラベルではなく、開発活動の強度を決める入力である点です。初期にASILが不適切だと、後工程で安全活動が足りない、または過剰でコストが膨らむなど、プロジェクト全体に影響します。

現場で起きやすい失敗は、機能単体の感覚でASILを決めることです。同じ機能でも、車種、利用シーン、ドライバーの関与度、フェール時の遷移（どう安全状態へ持っていくか）によってリスクが変わります。シナリオと前提条件を揃えた上で評価することが不可欠です。

ASIL（A〜D）とQMの違い

QMは、通常の品質管理で十分と判断される領域です。安全上の追加要求がほぼ不要という意味であり、「重要ではない」ではなく「安全リスクとしては低い」と整理された状態です。

ASILはAからDまであり、Dが最も厳格です。典型例として、制動・操舵・パワートレインのトルク制御などは高ASILになりやすく、オーディオや表示の一部機能はQMになりやすいです。ただし、表示でも誤表示が運転操作を誤らせる設計ならASIL対象になり得ます。

実務では、QMかASILかの境界が意思決定を難しくします。迷ったときには「安全目標に影響する故障か」「フェール時に人へ危害が及ぶ経路があるか」「安全機構が成立しているか」を軸に、リスクの説明を成立させることが重要です。

ASIL導出の考え方（S・E・C）

ASILはSeverity（S：危害の深刻度）、Exposure（E：危険状況への曝露頻度）、Controllability（C：回避可能性）の3要素で評価し、組み合せで決まります。規格の表に当てはめるため、評価の前提がぶれると結論もぶれます。

評価では、まず運転シナリオを具体化します。例えば「高速道路で追い越し中」「市街地で右折時」「雨天夜間」など、危険事象が起きる状況を明確にし、その状況でのS/E/Cを一貫した尺度で判断します。

ポイントは、議論を抽象化しないことです。「危ない」「頻繁」といった感覚ではなく、車両の使われ方、地域特性、ドライバー支援機能の有無などを前提条件として固定し、変更したときには再評価する運用にします。ASILは一度決めて終わりではなく、設計変更と連動して維持されるべき判断です。

車載ソフトウェア開発の詳細はこちら

当社の強みから開発実績までをご紹介

HARA（ハザード分析とリスク評価）の進め方

HARAは、開発対象（アイテム）のハザードを洗い出し、S/E/Cでリスクを評価してASILと安全目標を定義する、コンセプト段階の中核プロセスです。

HARAは、機能安全の出発点であり、後工程の要求・設計・テストの方向性を決めます。ここでの抜けや前提の誤りは、後からテストを増やしても埋めにくく、最も高い手戻りコストを生みます。

重要なのは「故障モード一覧」を作ることではなく、「危険事象」として人に危害が及ぶ筋道を具体化することです。機能不全が起点でも、最終的に何が起き、誰がどの状況で危険にさらされるのかまで落とします。

HARAを強くするコツは、シナリオの粒度管理です。細かすぎると網羅性が崩れ、粗すぎるとS/E/Cが評価できません。プロジェクト内で前提条件を管理し、変更したときには影響分析につなげられる形に整えると、HARAが生きた成果物になります。

ハザードの洗い出しとシナリオ設定

一般的な流れは、アイテム定義で対象機能と境界、インターフェース、想定使用を明確にし、次に機能不全（意図しない加速、出力低下、誤制御、制御不能など）を同定します。その上で運転状況を設定し、危険事象として列挙します。

網羅性の鍵は、シナリオの切り口を複数持つことです。速度域、道路種別、気象、交通密度、ドライバー状態、他システムとの連携状態など、危険に影響する要素を整理して漏れを減らします。

また、前提条件の管理が重要です。例えば「この機能は特定条件で無効化される」「ドライバーが常時監視する」などの前提は、実装・HMI・取扱説明・診断仕様まで含めて守られて初めて成立します。前提が設計や運用で崩れるなら、HARAも成立しません。

安全目標（Safety Goal）と安全要求への落とし込み

危険事象ごとに、安全目標をASIL付きで定義します。安全目標は最上位の安全要求であり、「何を防ぐべきか」を明確な言葉で示します。例としては「高速走行中の意図しない制動を防止する（ASIL D）」のように、状況と危険を結びつけるのがポイントです。

次に、安全目標を機能安全コンセプトへ展開し、どのような安全方針で達成するかを決めます。例えば、監視による検出、フェールセーフ遷移、運転者への警告、機能制限など、上位方針を設計可能な要求へ変換します。

ここでの品質がトレーサビリティを左右します。安全目標が曖昧だと、下位要求が恣意的になり、テスト合格の根拠も弱くなります。安全目標は「検証できること」「設計で実現できること」「前提条件が明確であること」を満たす必要があります。

安全要求の分解とトレーサビリティ

安全目標からシステム／HW／SW要求へ分解し、設計・実装・テストまで一貫して追跡可能にすることが、ISO 26262適合の実務の要になります。

安全要求の分解は、単なる階層化ではなく、設計上の責務分担を決める行為です。システムで担保すべきこと、ハードで実装すべき安全機構、ソフトウェアで実現すべき監視や制御を切り分け、インターフェース要求として固定します。

トレーサビリティは、要求管理ツールの導入そのものが目的ではありません。「どの変更がどの要求・設計・テストに影響するか」を短時間で判断できる状態が目的です。特に安全要求は、変更が連鎖しやすいため、リンク切れや重複を防ぐ運用設計が必要です。

実務上は、要求の粒度を揃え、検証方法（レビュー、解析、試験）と受入基準を要求とセットで持たせると破綻しにくくなります。テストが作れない要求は、多くの場合、曖昧か現実的でないため、上流で修正するのが最も効果的です。

安全アーキテクチャと冗長化の考え方

安全アーキテクチャは、故障を検出し、危険な出力を抑え、安全状態へ遷移するための構造です。代表的な安全メカニズムとして、監視（モニタリング）、相互監視、異常検知時の出力遮断、フェールセーフ、場合によってはフェールオペレーショナル（故障しても機能を維持）があります。

冗長化は万能ではなく、単一点故障だけでなく共通原因故障への配慮が必須です。例えば、同じ電源系統や同一ソフトモジュールに依存する冗長は、同時に破綻する可能性があります。そのため、独立性の設計、分離、異種冗長、診断の多様化などが論点になります。

ASIL分解（ASIL decomposition）は、適切な独立性が成立する条件で、要求される厳格さを分割できる考え方です。ただし、独立性の根拠が弱いと逆にリスクが増えます。分解はコスト削減の手段ではなく、安全ケースとして説明できる設計判断である必要があります。

車載ソフトウェア開発の詳細はこちら

当社の強みから開発実績までをご紹介

ソフトウェア開発での適用ポイント

Part 6を中心に、要求仕様の明確化、設計原則、コーディング規約、静的解析、単体・結合テスト、カバレッジ確保などを計画的に実施します。

ソフトウェアでは「体系的故障」が主要なリスクです。つまり、ランダムに壊れるのではなく、仕様の誤りや実装ミスが特定条件で顕在化します。そのため、要求の明確化とレビュー設計が最優先になります。

実装面では、コーディング規約（例：MISRA Cなど）や静的解析を使い、バグの温床になりやすい書き方を排除します。ただし、ツールの警告を潰すことが目的化すると逆効果です。警告の背景にある安全上の意図を理解し、逸脱（deviation）する場合は理由と影響を記録して説明可能にします。

テストは単体・結合だけでなく、要求ベースでのテスト設計が鍵です。カバレッジを数値で満たすだけでなく、「危険につながる分岐や異常系をどれだけ押さえたか」を示せると、監査で強い証拠になります。安全要求は正常系より異常系の設計・テストが価値を持つ点を意識すると品質が上がります。

ハードウェア開発での適用ポイント（故障率・診断・メトリクス）

Part 5では、ランダム故障を見積もる故障率モデルや診断カバレッジ設計、SPFM/LFMなどのメトリクスで、目標ASILに見合うHW安全性を示します。

ハードウェアは、ソフトウェアと違いランダム故障が中心になります。そこで、故障率のモデル化やFMEA/FTAなどの分析を通じて、故障が危険事象につながる経路を抑える設計にします。

診断設計は特に重要です。自己診断や監視回路で故障を検出できても、検出のタイミングと安全状態への遷移が遅ければ危険は防げません。診断カバレッジは数値だけでなく、どの故障をどの手段で、どれだけの時間内に検出し、何に遷移するかまでセットで設計します。

メトリクス（SPFM/LFMなど）は、設計の安全性を客観的に示すための指標です。数字を満たすために後付けで診断を増やすと、コストや誤検知が増えます。上流から安全アーキテクチャとして診断を組み込み、要求・設計・検証の整合を保つことが結果的に最短になります。

ツール適格性（ツール認証）とツールチェーン管理

開発ツールの不具合が安全成果物に影響し得るため、ツール適格性（TCL評価など）と、ツールチェーン全体の一貫運用（バージョン管理、設定管理）が必要です。

コンパイラ、コード生成、静的解析、テスト自動化など、ツールは安全成果物に直接影響します。もしツールが誤ったコードを生成したり、検査の抜けを作ったりすれば、プロセスを守っても危険が混入します。そのため、ツールが安全上どの程度重要かを評価し、必要な適格性を確保します。

実務では、単体ツールだけでなくツールチェーンとして管理するのが難所です。同じツールでもバージョンが違えば出力が変わることがあります。設定、オプション、ライブラリ、スクリプト、実行環境まで含めて再現できる状態を作ることが、監査の強い証拠になります。

効率化の観点では、既に適格性の根拠が整ったツールや、ベンダーから十分な証拠提供があるツールを選ぶのが現実的です。自社ですべてを証明しようとすると工数が膨らむため、ツール選定は安全計画の一部として早期に行うべきです。

確証方策：レビュー・検証・妥当性確認の設計

レビュー、解析、試験をどう組み合わせて要求を満たしたことを示すかを、計画段階で設計し、独立性や受入基準を明確にします。

確証方策は、後から「証拠が足りない」とならないための設計図です。どの成果物を、誰が、どの観点で確認し、どんな記録を残すのかを事前に決めます。安全活動は後付けが最も高コストになりやすい領域です。

レビューは単なる読み合わせではなく、欠陥を検出するための技術活動です。チェック観点をテンプレート化し、ASILに応じた独立性（作成者と別の人がレビューするなど）を確保すると、品質が安定します。

検証と妥当性確認の違いも重要です。検証は「要求どおりに作れたか」、妥当性確認は「その要求がユーザーや利用状況に対して正しいか」です。HARAの前提条件が妥当性確認で崩れると、安全ケース全体が弱くなるため、シナリオとテストの紐づけを意識すると良いです。

機能安全監査と機能安全アセスメント

プロセスが規格要求に沿って運用されているかを監査で確認し、最終的にアセスメントで安全ケースと成果物の妥当性を独立視点で評価します。

監査は、計画どおりに安全活動が実施され、支援プロセス（変更管理、構成管理、文書管理など）が機能しているかを確認する場です。ここで弱いと、成果物が揃っていても「継続的に安全を維持できる体制」とは見なされません。

アセスメントは、より総合的に、成果物と論理が安全目標を満たすかを評価します。HARAから安全要求、設計、検証結果までの一貫性と、残留リスクの説明が問われます。結局のところ、問われるのは書類の厚さではなく、主張と証拠が矛盾なくつながっているかです。

準備として有効なのは、安全ケースの考え方で成果物を整理することです。安全主張、根拠、証拠をセットで管理すると、監査やアセスメントだけでなく、設計変更時の影響説明も速くなります。

車載ソフトウェア開発の詳細はこちら

当社の強みから開発実績までをご紹介

ISO 26262対応のメリット

安全性の説明可能性が高まり、取引要件への適合や市場展開のしやすさ、手戻り削減、組織的な開発力向上といった効果が期待できます。

最大のメリットは、安全性を客観的に説明できることです。完成車メーカーや認証・監査の場で、なぜ安全と言えるのかを成果物と論理で示せるため、取引要件を満たしやすくなります。

開発面では、上流でリスクと要求を固めることで、後工程の手戻りが減ります。安全要求が曖昧なまま進むと、試験段階で問題が見つかっても修正範囲が広くなり、コストが跳ね上がります。ISO 26262はこの「後で効かない努力」を減らす方向に働きます。

組織としては、属人性の低減と再現性のある開発が進みます。プロジェクトが変わっても同じ思考手順でHARAや要求分解ができ、ノウハウが蓄積されます。安全は一度きりではなく、世代開発で効いてくる投資です。

未対応のリスク：品質・取引・法規対応への影響

未対応の場合、重大不具合の流出やリコール、顧客監査不合格による取引機会損失、説明責任の不備による法規・訴訟リスク増大につながり得ます。

未対応の直接的なリスクは、重大事故につながる欠陥の見逃しです。問題は、欠陥が起きたこと自体よりも、発生可能性を事前に検討していたか、おきたときに安全側へ制御できたか、再発防止を仕組み化できていたかが問われる点です。

取引面では、監査で要求水準を満たせず、受注機会を失うことがあります。特にサプライヤーは、成果物の提供責任やインターフェースの明確化が求められ、曖昧なままでは契約・責任分界の面でも不利になります。

また、法規・訴訟対応では説明責任が重要になります。事故や不具合が発生したときには、合理的なプロセスでリスク低減を行っていたことを示せないと、組織としての信頼・コスト両面のダメージが大きくなります。

課題：コスト・工数・体制・人材育成

追加の分析・検証・文書化により負荷が増えるため、役割分担、教育、テンプレート化、ツール活用などで継続運用できる体制を作ることが重要です。

ISO 26262導入の壁は、短期的には工数増に見えることです。HARA、要求管理、レビュー、テスト証拠などが増えるため、従来のやり方のままだと負荷に耐えられません。

対策は、まず役割と責任を明確化することです。機能安全マネージャーだけに集中させると破綻します。システム、ソフトウェア、ハードウェア、品質、製造、サービスがそれぞれ担う成果物を定義し、レビューゲートと出口条件を揃える必要があります。

人材育成では、規格知識だけでなく「安全要求を検証可能に書く」「シナリオで議論する」「前提条件を管理する」といった実務スキルが重要です。テンプレート化と教育、ツール活用で再現性を上げ、プロジェクトごとの個別最適を減らすと定着が早まります。

関連規格・プロセス：Automotive SPICEとの関係

Automotive SPICEがプロセス成熟度を評価する枠組みであるのに対し、ISO 26262は安全成果物と安全活動の要求を定義します。両者は補完関係にあり、整合した運用が効果的です。

Automotive SPICEは、開発プロセスが再現性をもって回っているかを成熟度として評価します。一方ISO 26262は、安全という目的に対して何を実施し、何を証拠として残すべきかを規定します。目的が違うため、片方だけでは不十分になりがちです。

実務上は、SPICEで整えた要求管理、変更管理、検証プロセスに、ISO 26262の安全固有の成果物（HARA、安全目標、安全要求、独立レビューなど）を組み込む形が自然です。二重運用にすると現場が疲弊するため、共通プロセスに統合する設計が重要です。

両者を整合させると、顧客監査への強さが増すだけでなく、開発の品質指標と安全指標がつながります。結果として「安全のために遅くなる」のではなく、「無駄な手戻りが減って早くなる」状態を作りやすくなります。

当社の自動車分野における取り組み

当社は、創業以来40年間にわたり組込みシステム開発で培った、ソフトウェア・ハードウェア両側面の高度な技術力と製造現場の知見を有しています。

現在、さまざまな産業分野でデジタル化が加速しており、組込みシステムの需要は増加傾向にあります。特に自動運転や高度運転支援システム（ADAS）の発展に伴い、自動車分野が市場全体の成長を強力に牽引しています 。

当社では、モビリティ系企業の注力領域で培った自動車分野のシステム開発技術を、他企業や他領域（ADAS、統合ECUなど）へと積極的に横展開し、拡大を推進しています 。ISO 26262をはじめとする機能安全規格への適合や、厳格なプロセス管理が求められる車載開発において、当社の強みである技術・開発力に裏打ちされたソリューションを提供し、日本のGDPの約20%、CO2排出量の約35%を占める製造業のDXを推進することで、生産コスト・CO2排出量削減、そして安全・安心なモビリティ社会の実現へ貢献してまいります。

まとめ

ISO 26262は、故障起因のリスクをライフサイクル全体で管理するための実践規格です。ASILとHARAを起点に要求分解とトレーサビリティを確立し、SW/HW開発、ツール、V&V、監査・アセスメントまで一貫させることが成功の鍵になります。

ISO 26262は、E/Eシステムの故障が重大事故につながる時代に、機能安全を共通化するための規格です。重要なのは、故障を前提に危険を定義し、要求・設計・検証を論理でつなぐことです。

実務の要点は、HARAで前提条件を明確にした上でASILを適切に導出し、安全目標からシステム/HW/SW要求へ一貫して分解し、テストまで追跡可能にすることです。支援プロセス（構成・変更管理）と確証方策を早期に設計すると、運用が安定します。

導入は負荷が増えるように見えますが、説明可能性が上がり、取引・監査対応や手戻り削減につながります。まずは適用範囲の明確化、安全計画、HARA、要求管理の骨格づくりから始め、継続運用できる体制と人材育成に投資することが現実的な第一歩です。

車載ソフトウェア開発のお問い合わせはこちら

AUTOSAR・機能安全から車載 Android、SDV、サイバーセキュリティまで車載ソフトウェア開発を一貫して支援