RAS AIMIL-STD-882Eが求めるソフトウェアセーフティケース
VisualPro Tech Brief
MIL-STD-882Eが求めるソフトウェアセーフティケース
問題は分析ではなく、つながりにある
MIL-STD-882E システム安全 | 防衛ソフトウェア安全論証 | 業界動向ブリーフ
MIL-STD-882ESwHASSRSwCI 1-5セーフティケース
01概要（TL;DR）— 882Eが求めるのは文書ではなく論証
米国防総省のシステム安全規格であるMIL-STD-882Eは、構想検討から廃棄までのライフサイクル全体にわたり、ハザードを除去し、除去できないリスクを最小化するための計画的かつ規律ある取り組みを義務付けています。兵器、車両、航空機に広く適用され、ソフトウェアが機能の大部分を担うようになった現在、実務の中心はソフトウェアセーフティケースの構築へと移っています。
セーフティケースは報告書の束ではありません。予見可能なすべてのハザードが特定されたこと、管理策によって各ハザードが許容可能なリスクまで低減されたこと、その管理策が正しく実装されたこと、そして残留リスクが正式に受容されたことを立証する主張–論拠–証拠の階層構造です。ソフトウェアに欠陥がないと主張するものではありません。そのような主張は達成不可能であり、882Eが求めるものでもありません。
そして、実務においてこの論証が崩れるのは、分析の深さではありません。分析と検証の間のつながりです。
ソフトウェア安全プログラムで最もよくある失敗は、分析の不足ではなく、その後のつながりの不足である。
02なぜ今か — 防衛ソフトウェア安全論証を押し上げる3つの圧力
1ソフトウェアがハザードの主経路になったハザード経路の移行
兵器システムの機能がソフトウェアへ移るにつれ、壊滅的なハザードへの寄与経路もソフトウェアへ移りました。882Eは、ソフトウェアがハードウェアを制御する度合い（5段階のソフトウェア制御カテゴリ）と重大度（4区分）を掛け合わせてソフトウェア安全クリティカリティマトリクス（SSCM）を構成し、そこからソフトウェアクリティカリティ指標（SwCI 1-5）を導き、要求される厳格度レベル（Level of Rigor）を定めます。クリティカリティが高いほど、コードカバレッジ目標、独立検証、形式解析が任意ではなく義務として課されます。
2契約が成果物を明記する契約要求
882Eのタスクは契約の作業範囲記述書（Statement of Work）で指定され、成果物はCDRLとして提出されます。ソフトウェア集約型システムでは、5つのタスクが工数の大半を占めます — Task 205（ソフトウェア安全要求分析）、Task 206（ソフトウェア安全設計分析）、Task 301（安全性評価）、Task 302（試験・評価の安全）、Task 303（システム安全プログラムレビュー）。安全データパッケージには、SwHAワークシート、SSRリストとトレーサビリティマトリクス、ソフトウェアFMEA、安全上重要な試験ケースとその結果、カバレッジレポート、ハザードリスク決定報告書（HRDR）、安全性評価報告書が含まれます。
3能力の差がそのまま受注の差になる競争力
残留リスクの受容権限は、ハザードリスク指標（HRI）に応じて変わります。壊滅的かつ頻発するハザード（HRI 1）はマイルストーン決定権者まで上げられ、無視できるほど軽微でまず起こり得ないハザード（HRI 20）はワーキンググループのレベルで完結します。セーフティケースはリビングドキュメントです。ソフトウェアを変更するたびにレビューが必要となり、受容済みの残留リスクに関わる変更には新たなHRDRが必要です。このサイクルをファイルで回す組織と、ツールで回す組織との差は広がっていきます。
03882Eのソフトウェア安全は3段階で展開される
3段階の分析チェーン
| 段階 | 内容 | 成果物 |
|---|---|---|
| PHA 予備ハザード分析 | 機能分解と運用構想からシステムレベルのハザードを特定 | ハザードリスト、初期HRI、寄与機能 |
| SwHA ソフトウェアハザード分析 | システムハザードをソフトウェアの故障モードに対応付け | ハザード–故障モード対応ワークシート |
| SSR導出 ソフトウェア安全要求 | 故障モードごとに要求されるソフトウェアの振る舞いを規定 | 肯定制約・否定制約・範囲制約および監視要求 |
SSRは4つの定型で記述します — 肯定制約（必須の動作）、否定制約（禁止される状態）、範囲制約（有効な出力の境界）、監視要求（ハザード検出を可能にする条件）。
5段のトレーサビリティチェーン — 実際に途切れる場所
| リンク | 要求事項 |
|---|---|
| PHAハザード → SwHA | ソフトウェアの寄与があるすべてのハザードがSwHAの行に到達すること |
| SwHA → SSR | すべてのSwHAの行が少なくとも1つのSSRにつながること |
| SSR → SRS/SDD | すべてのSSRが要求仕様書・設計書の特定の項目に対応すること |
| SSR → 検証証拠 | すべてのSSRが試験ケース、カバレッジ、ソフトウェアFMEA、またはレビュー記録によって裏付けられること |
| 証拠 → 構成ベースライン | すべての証拠がソフトウェアの特定のバージョンに紐付けられること |
要点 出典はトレーサビリティを「SwHA品質の運用指標」と位置付け、トレーサビリティの欠落が、レビューサイクルにおけるSwHA手戻りの最も一般的な原因であると指摘しています。最後のリンクも妥協できません。どのバージョンを試験したのかを正確に特定する構成ベースラインのない試験結果は、再現可能な証拠とはいえません。
04SwHAの5つの故障モードはFMEA・STPAと同じ骨格を持つ
SwHAはシステムハザードを5つの定型的なソフトウェア故障モードに分解します。この分類は、私たちがすでに実施している2つの手法と構造的に対応しています。
| 882E SwHA 故障モード | FMEAの視点 | STPAの視点 |
|---|---|---|
| 誤った出力 | 機能の誤動作 — 値または状態の誤り | ハザードを引き起こすコントロールアクションの提供（UCA） |
| 出力なし（欠落） | 機能喪失 | 必要なコントロールアクションの不提供（UCA） |
| 遅れた出力 | タイミング故障 | 誤ったタイミングまたは順序（UCA） |
| スプリアス出力 | 意図しない作動 | 不要な状況でのコントロールアクションの提供（UCA） |
| 誤った宛先への出力 | インターフェース故障 | 制御パスの欠陥 — ロスシナリオの領域 |
最初の4つはSTPAの非安全なコントロールアクションの類型と直接重なり、5つ目はUCAではなく、STPAロスシナリオの制御パスの欠陥カテゴリに対応します。逆方向から取り組む2つの手法が、同じ故障空間をカバーしているということです。
実務上の意味 882Eは新しい分析言語を学ぶことを求めているのではありません。FMEAの故障モード軸、STPAの制御の視点、FTAの論理展開を1つの構造上で結び付け、証拠まで追跡することを求めているのです。実際、ソフトウェアFMEAは、SwHAの完全性をクロスチェックする証拠として安全データパッケージに明記されています。
実務上の意味 882Eは新しい分析言語を学ぶことを求めているのではありません。FMEAの故障モード軸、STPAの制御の視点、FTAの論理展開を1つの構造上で結び付け、証拠まで追跡することを求めているのです。実際、ソフトウェアFMEAは、SwHAの完全性をクロスチェックする証拠として安全データパッケージに明記されています。
05VisualProによる支援
1つの構造ツリー、5つの分析構造の共有
FMEA、FTA、HARA、TARA、STPAが同じシステム構造データベースを共有します。PHAで特定したハザードを構造ツリー上に配置し、同じツリーからSwHAの故障モードとFTAの論理展開を続けます。ハザードを二重に入力することはありません。
SSRと証拠のトレーサビリティ中核的価値
ハザード、故障モード、安全要求、検証項目が単一のデータベース内で双方向に紐付けられます。882Eが求めるトレーサビリティマトリクスは分析データベースから直接生成されるため、設計変更があれば途切れたリンクが即座に明らかになります。まさにここで、出典が指摘する「最もよくある失敗モード」をツールのレベルで防ぎます。
重大度・クリティカリティ体系への対応評価体系
重大度4区分と発生確率5段階からなるハザードリスク指標、およびソフトウェア制御カテゴリから導出されるSwCIを、プロジェクトごとに設定できます。AIAG-VDA AP、ISO 26262 ASIL、ISO/SAE 21434 CALと同じ方法で扱われます。
MCPベースのAIエージェント連携AI連携
FMEA、FTA、HARA、TARA、STPAに対応するMCP（Model Context Protocol）により、ClaudeなどのAIエージェントがVisualProと直接通信します。故障モード候補の特定からSSRの草案作成までを対話形式で行い、分析者は検証と判断に集中できます。専任の安全組織を持たないサプライヤーほど、その効果は大きくなります。
06よくある質問（FAQ）
Q1自動車分野のFMEAの能力は、防衛ソフトウェアの安全論証に活かせますか？
原理は同じです。ハザード特定、故障モードの分解、要求の導出、検証のトレーサビリティという骨格はISO 26262と882Eに共通しており、SwHAの故障モード分類はFMEAに対応します。異なるのは、評価体系（ASILに対してSwCIとHRI）、成果物の名称（セーフティケース、HRDR、SDP）、そしてタスクが契約のSOWとCDRLで指定される点です。新しい手法を学ぶことではなく、表記と成果物を合わせる問題です。
Q2セーフティケースは必ずGSNで描かなければなりませんか？
いいえ。出典は、Goal Structuring Notation（GSN）は階層関係を可視化する手段であって必須ではなく、表記にかかわらず重要なのは論理構造そのものであると明言しています。重要なのは、主張・論拠・証拠が欠落なくつながっているか、そしてそのつながりを追跡できるかです。
Q3すでにSwHAを実施しましたが、レビューで手戻りの指摘を受けました。どこを確認すべきですか？
まずトレーサビリティの欠落から確認してください。出典がSwHA手戻りの最も一般的な要因として挙げている原因です。確認すべきは4点です。ソフトウェアの寄与があるのにSwHAの行がないハザード、SSRに到達しないSwHAの行、試験ケースにつながっていないSSR、そしてバージョンのベースラインが特定されていない試験結果です。指摘の大半はこの4点から見つかります。
07今すぐ始めましょう（Next Step）
防衛ソフトウェアの安全論証には、分析能力とトレーサビリティ確保の能力が同時に求められ、後者はツールなしには維持できません。自動車、半導体、ロボティクスのプログラムで実績のあるVisualProで、ハザードから検証証拠までを1つの構造上でつなぐセーフティケースを準備してください。
ハザードから証拠まで途切れなくつなぐ — VisualProによる防衛ソフトウェア安全論証。
参考資料 — Corvus Intelligence, “Software Safety Case Development under MIL-STD-882E”（2026-06-25）、LDRA, MIL-STD-882E / JSSSEH 資料