メインコンテンツへスキップ

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

📝 はじめに

このページでは、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の評価対象である。

上に戻る