ASPICE 4.0 vs 3.1 — 何が変わり、どう移行するか

ASPICE 4.0はなぜ生まれたのか

ASPICE 3.1は2017年以降、自動車ソフトウェア開発プロセスの事実上の標準として使用されてきました。しかし、自動車産業の急速な変化により、3.1だけではカバーできない領域が生まれてきました。

第一に、3.1はソフトウェア中心でした。ハードウェアエンジニアリングやシステムレベルの統合的な視点が不足していました。現代の車両のE/Eシステムはソフトウェアとハードウェアが緊密に結合したメカトロニクスシステムですが、プロセスモデルがこれを反映していませんでした。

第二に、AI/ML（機械学習）ベースのソフトウェアが自動車に本格的に導入され始め、従来のV-Modelベースのプロセスではデータ駆動型開発を扱えなくなりました。自動運転、ドライバーモニタリング、予知保全などにMLが活用されていますが、これに対するプロセスガイドラインが一切ありませんでした。

第三に、SDV（Software Defined Vehicle）時代の到来により、サイバーセキュリティが重要課題となり、ISO 21434やUN R155といった規制が登場しました。ASPICEがこうした変化を反映すべきだという業界の要求が高まりました。

こうした背景のもと、VDA QMCはASPICE 4.0を開発し、2023年12月に公式リリースしました。評価者の移行期間は2025年3月31日に終了し、以降のすべての公式評価は4.0基準で実施されます。

主要変更点の比較

ASPICE 3.1から4.0への移行は、単なるアップデートではなく構造的な再編です。ASPICEの基本概念を理解していれば、以下の比較が変化の大きさをよく示しています。

適用範囲：3.1はソフトウェアエンジニアリング中心でしたが、4.0はソフトウェア、ハードウェア、機械学習を含むメカトロニクス全体を包括します。

ハードウェアプロセス：3.1にはハードウェア関連のプロセスがありませんでしたが、4.0ではHWE.1（要求事項分析）からHWE.4（検証）まで4つのハードウェアエンジニアリングプロセスを新設しました。

機械学習プロセス：3.1にはML関連のプロセスが全くありませんでしたが、4.0ではMLE.1（データ管理）からMLE.4（検証）まで機械学習エンジニアリングプロセスを新たに定義しました。

安全およびサイバーセキュリティ：3.1は一般的なガイドラインレベルでしたが、4.0は安全管理（Safety Management）とサイバーセキュリティ管理の要件を大幅に強化しました。ISO 26262およびISO 21434との整合が明示的に行われています。

トレーサビリティ：3.1ではトレーサビリティと一貫性が別々のBase Practiceとして分離されていましたが、4.0ではこれらを統合し、管理効率を向上させました。

評価基準：3.1はISO 15504をベースとしていましたが、4.0はISO/IEC 33002:2015に整合し、国際標準との互換性を強化しました。

Agile/DevOps：3.1ではアジャイル方法論に対する明示的なサポートがありませんでしたが、4.0はアジャイルおよびDevOpsアプローチを公式にサポートしています。自動車向けCI/CDパイプラインとの連携が自然になりました。

アーキテクチャ評価：3.1では代替アーキテクチャ評価を別のBPとして要求していましたが、4.0では選択根拠の正当化（justification）に変更し、実務的な柔軟性を高めました。

プロセス領域の新設 — HWとML

4.0で最も目立つ変化は、ハードウェアと機械学習プロセスの新設です。

ハードウェアエンジニアリング（HWE）は4つのプロセスで構成されます。

• HWE.1 — ハードウェア要求事項分析：システム要求事項からハードウェア要求事項を導出します。
• HWE.2 — ハードウェア設計：回路設計、PCBレイアウトなどのハードウェアアーキテクチャを定義します。
• HWE.3 — ハードウェア実装：設計に基づくハードウェアの製作およびプロトタイピングを実施します。
• HWE.4 — ハードウェア検証：ハードウェアが要求事項を満たしているか検証します。

機械学習エンジニアリング（MLE）も4つのプロセスで構成されます。

• MLE.1 — MLデータ管理：学習データの収集、前処理、ラベリング、品質管理を扱います。
• MLE.2 — MLモデル開発：モデルアーキテクチャの選択、学習、ハイパーパラメータチューニングを行います。
• MLE.3 — ML統合：MLモデルをシステム全体に統合します。
• MLE.4 — ML検証：モデルの性能、精度、ロバスト性を検証します。

これらのプロセスは、既存のSWE（ソフトウェアエンジニアリング）、SYS（システムエンジニアリング）プロセスと相互参照の関係にあります。例えば、MLE.3（統合）はSWE.5（ソフトウェア統合）と連携し、HWE.1（要求事項）はSYS.2（システム要求事項）から導出されます。

安全およびサイバーセキュリティ要件の強化

ASPICE 4.0は安全（Safety）とサイバーセキュリティ（Cybersecurity）に関する管理要件を大幅に強化しました。

安全管理プロセスは、ISO 26262 機能安全標準との整合を強化しました。安全関連ソフトウェア開発において、安全要求事項のトレーサビリティ、安全分析、安全検証がプロセス全体を通じてより体系的に求められるようになりました。

サイバーセキュリティ管理は、ISO/SAE 21434との連携を通じて強化されました。脅威分析およびリスク評価（TARA）、セキュリティ要件の導出、セキュリティ検証が開発プロセスに統合されなければなりません。これはUN R155規制にも直結する部分です。

既存の3.1では安全とセキュリティが別々の関心事として扱われていましたが、4.0では開発プロセス全体を通じて安全とセキュリティを同時に考慮するよう設計されています。これは、現代の車両が機能安全とサイバーセキュリティを同時に確保しなければならないという現実を反映しています。

マイグレーションロードマップ

ASPICE 3.1から4.0への移行は体系的に進める必要があります。以下は実務で検証済みの5段階ロードマップです。

Phase 1：現状分析（1〜2ヶ月）

現在の3.1ベースのプロセスを4.0の要件と比較するギャップ分析を実施します。どのプロセスがすでに充足しているか、どの部分が新たに必要かを把握します。特にHWプロセス（HWE）とMLプロセス（MLE）の該当有無を確認します。

Phase 2：教育および意識転換（1〜2ヶ月）

開発チーム全体にASPICE 4.0の変更点を教育します。経営層の支援を確保し、移行の必要性について組織レベルの合意を形成します。

Phase 3：プロセス更新（2〜3ヶ月）

既存のプロセス記述書、テンプレート、チェックリストを4.0基準に更新します。新しいプロセス領域（HWE、MLE）が該当する場合は、新規にプロセスを定義します。ツールの設定もこの段階で調整します。

Phase 4：パイロットプロジェクト適用（3〜4ヶ月）

1つのプロジェクトを選定し、更新されたプロセスを全面的に適用します。実際の適用中に発見された問題を修正し、教訓を整理します。

Phase 5：全社展開 + 外部評価（2〜3ヶ月）

パイロットで検証されたプロセスを全社的に展開し、認定ASPICE評価者による公式評価の準備をします。

現実的なタイムラインは、新規プロジェクトの場合6〜12ヶ月、既存プロジェクトのリバースエンジニアリングが必要な場合は12〜18ヶ月です。組織の現在の成熟度と4.0の該当範囲（HW、ML含むかどうか）によって異なります。

PopcornSARとともにASPICE移行を

ASPICE 4.0への移行は、プロセスの再定義だけでなく、ツールと自動化のアップデートも伴います。PopcornSARのPARVISはこの移行を効率的にサポートします。

• PARVIS-Spec：要求事項分析を自動化し、システム-ソフトウェア-ハードウェア間のトレーサビリティを確保します。4.0で強化されたトレーサビリティ要件に対応します。
• PARVIS-Coder：MISRA Cなどのコーディング規則を自動適用し、SWE.3（詳細設計および実装）プロセスをサポートします。
• PARVIS-Verify：AIによりテストケースを自動生成し、検証段階（SWE.4〜SWE.6）の工数を3〜4倍削減します。

また、ASPICE 4.0マイグレーションコンサルティングと教育サービスにより、ギャップ分析から外部評価の準備まで全プロセスをサポートしています。

PARVIS製品ページで詳細をご確認いただくか、お問い合わせよりご相談をお寄せください。