🔗 ISO 26262 / 21434 とA-SPICEの役割分担

~~NIP~~

📝 はじめに

このページでは、ISO 26262（機能安全）、ISO/SAE 21434（サイバーセキュリティ） と A-SPICE が、 それぞれ何を担当し、何を担当しないのか を構造的に整理する。

規格同士を横並びで比較することが目的ではない。 なぜA-SPICEが「背後」にいて、他規格を支える位置づけになるのか── その理由を理解することが主眼である。

🌍 背景・前提：なぜ規格が増え続けるのか

自動車ソフトウェアは、もはや単なる制御プログラムではない。

機能安全（ISO 26262）サイバーセキュリティ（ISO/SAE 21434）将来的には AI・OTA・法規対応など

規格が増えているのは、品質が悪化しているからではなく、対象とするリスク領域が拡張しているからである。

ここで重要なのは、 これらの規格が「同じレイヤ」を見ていない という点だ。

🧱 A-SPICEの立ち位置：プロセスの土台

A-SPICEは、機能安全やセキュリティの規格とは性格が根本的に異なる。

A-SPICEが見るもの

要求はどう作られ、どう管理されているか設計判断は説明可能か検証は定義された根拠に基づいているかプロセスは再現可能か

A-SPICEは「何を作るか」ではなく、「どう作るか」を保証する。

A-SPICEが見ないもの

その機能が安全かどうか攻撃に耐えられるかどうかリスクが十分に低減されているか

これらは ISO 26262 / 21434 の責務 である。

🔐 ISO 26262：機能安全は「中身の正しさ」を問う

ISO 26262は、製品そのものの安全性を扱う規格である。

HARA（ハザード分析） ASIL 割り当てセーフティ要求安全メカニズムの妥当性

ISO 26262は「この設計・実装は安全か」を問う規格であり、プロセスの再現性そのものは主目的ではない。

ただし、実務ではこうなる。

セーフティ要求は SYS/SWE の要求プロセスに流れるセーフティ検証はテストプロセスに乗る

つまり、ISO 26262はA-SPICEのプロセスの上に「安全という制約」を載せている。

🛡️ ISO/SAE 21434：セキュリティは「想定外」を扱う

ISO/SAE 21434は、悪意ある攻撃という不確実性を対象とする。

TARA（脅威分析）セキュリティ要求ライフサイクル全体での対策

セキュリティは後付けできない。要求定義・アーキテクチャ段階での取り込みが必須となる。

ここでも同様に、

セキュリティ要求は要求管理に統合され対策は設計・実装・検証プロセスに展開される

21434はA-SPICEを「回す前提」で設計されている規格と言える。

🔄 なぜ役割分担が崩れやすいのか

現場でよく起きる誤解がある。

「ISO 26262 / 21434をやっているから、A-SPICEは大丈夫」 これは完全な誤りである。

理由は単純だ。

安全要求が存在しても、管理されていなければ再現できないセキュリティ設計があっても、判断根拠を説明できなければ継承できない

中身が正しくても、作り方が崩れていれば組織としては失格 ──それを見ているのがA-SPICEである。

🧠 構造で捉えるとこうなる

A-SPICE

プロセスの骨格・再現性・説明責任

ISO 26262

安全という品質属性の中身

ISO/SAE 21434

セキュリティという品質属性の中身

A-SPICEは横断的な「基盤」、他規格は縦に刺さる「専門領域」。

📌 まとめ（このページで伝えたい一点）

A-SPICEは他規格と競合しない。支配する。

ISO 26262や21434は、 A-SPICEという「作り方の器」があって初めて、正しく機能する。

規格を増やす前に問うべきは一つだけだ。

その組織は、作り方を説明できるか？

それに Yes と答えられるかどうかが、A-SPICEの評価対象である。