RAS AI安全分析の改善対策、いま何件完了していますか？ — FMEA・STPAの対策をリスクやスケジュールのように管理する方法
01要約（TL;DR）
02分析は承認済み。では、対策は誰が見ているのか
分析報告書が承認される日は、分析チームにとっては終わりですが、リスクの観点からは始まりです。分析で決めた改善対策が実際に設計、試験、保守文書に反映されて初めて、リスクは下がります。
下の画面は、VisualProのトランスミッションDFMEAサンプルプロジェクトのステップ6（最適化）です。対策優先度（AP）がHまたはMの故障原因12件すべてに予防対策と検出対策が記入されており、対策後のAPもすべてLと予測されています。分析としては整った状態です。
対策の行を選択すると、その下に責任者、目標完了日、ステータスの欄が表示されます。一番下には「エビデンスへのポインタを伴う実施済み対策」の欄もあります。
このサンプルの12件を照会すると、目標完了日はすべて入力されていますが、責任者の欄は12件すべて空欄です。サンプルデータだからかもしれません。ただ、実務でも同じことが起こります。分析会議では「制御チームが対応する」といった程度で話がまとまり、その合意がファイルの欄にまで落とし込まれないのです。
対策の内容を見ると、もう一つのことがわかります。12件の中には、「保守マニュアルにフィルター交換周期を明記する」のように設計チームの外で対応すべき作業が含まれています。また、2つの故障原因（油圧バルブの固着による変速不能と、油圧制御の喪失）はまったく同じ対策を共有しています。分析表では2行ですが、実際には1つの作業です。
03PMにとってこれらの対策が意味するもの：リスク登録簿と課題スケジュールから抜け落ちた行
PMが管理するリスク登録簿や課題ログには、通常、リスクごとに担当者、対応計画、ステータス、期限があります。FMEAで見つかった故障原因は製品リスクであり、リスク登録簿は主にプロジェクトリスクを扱うため、対象は異なります。しかし、管理すべき情報は同じです。故障原因がリスクであり、予防・検出対策が対応計画であり、目標完了日が期限です。
ところが、この2つのリストはたいてい別々に存在します。安全分析は分析ツールの中に、プロジェクトスケジュールはPMのガントチャートやイシュートラッカーの中にあります。そのためPMは、「APがHだった対策のうち今月が期限のものは何件か」や「試験評価チームに集中している対策が試験スケジュールと重なっていないか」を知るには、分析担当者に尋ねなければなりません。安全対策が遅れればいずれスケジュールリスクになりますが、そのシグナルがPMの画面に届くのは遅れてからです。
04既存の枠組みが問うもの、問わないもの
対策を管理する枠組みはすでに存在します。まず、それらが何を求めているかを認めるところから始めましょう。
| 既存の枠組み | 問うもの | 問わないもの |
|---|---|---|
| AIAG-VDA FMEAハンドブック ステップ6（最適化） | 各対策に担当者、目標完了日、ステータス、エビデンスを伴う実施済み対策、対策後のS·O·DとAPが記録されているか | 分析完了後にそれらの欄を毎週誰が確認するのか、複数チームにまたがる対策をどこで一覧できるのか |
| STPA Handbook (Leveson & Thomas, 2018) | ロスシナリオから要求と制約が漏れなく導出されているか | 導出された要求と対策を、プロジェクト内で誰がいつまでに完了するのか |
| ISO 26262-8 箇条6（安全要求の仕様化と管理） | 安全要求が仕様化・トレース・検証されているか | ソフトウェア要求ではない対策（保守文書、サプライヤー確認）をどこで管理するか |
| プロジェクトのリスク登録簿・課題ログ | すべてのリスクと課題に担当者、対応、ステータス、期限があるか | そのリスクがどの故障原因から生じたのか、対応によって分析上のAPがどこまで下がるのか |
| ALM・イシュートラッカー（Polarion、codebeamer、Jiraなど） | 登録済みの要求と課題のステータスとトレーサビリティ | 登録されていない対策、ソフトウェアチーム外の担当者が持つ対策 |
AIAG-VDAハンドブックはすでに担当者とエビデンスを求めています。リスク登録簿もすでに担当者と期限を求めています。新たに求めるべきものはありません。問うべきは「それらの欄が実際に埋められ、誰かが毎週見ているか」、そして「安全分析の対策とプロジェクトスケジュールが同じ画面にあるか」です。ギャップは要求事項ではなく、運用にあります。
053つのルール
ツールよりもルールが先です。次の3つを守れば、Excelを使ってもALMを使っても追跡は機能します。
これらは、AIAG-VDAステップ6にすでにある原則を、分析ファイルの外でも守られるようにする仕組みと考えてください。この3つのルールは、PMのリスク登録簿のルールとも一致します。
06実践：トランスミッションDFMEA → Recoble
VisualProのトランスミッションDFMEAから、APがH・Mの故障原因12件とその対策を読み取り、Recobleのワークスペースに移しました。分析データはVisualPro MCPで照会し、Recoble側のノート、ワークボード、リンクもMCPで作成しました。手作業で移しても構成は同じです。
1) 故障原因はノートに（安全エンジニアの根拠）
故障原因1つをノートの見出し1つとし、その下に構造、機能、故障モード、S/O/D、AP、現在の予防管理・検出管理を表にまとめました。分析の根拠はこのノートに残ります。
2) 対策はワークボードの項目に（対策・課題リスト）
1つの対策が1つの項目です。同じ対策を共有する2つの故障原因（FC-01とFC-03）は1つの項目にまとめたため、12件が11件になりました。カスタムフィールドには、故障原因番号、担当チーム、対策前後のAP、重大度、完了条件、検証エビデンス（ファイル）を設定しました。目標完了日と進捗ステータス（計画 → 未着手、進行中 → 進行中）はVisualProの値をそのまま移しました。担当チームは、本記事のために各対策の内容に合わせて例として割り当てた値です。
担当者（個人）の列は意図的に空欄にしました。元データに責任者がいなかったためです。重要なのは、空欄の列がボード上ですぐに目に入ることです。週次会議では「担当者のいない対策11件」を1つの画面で確認できます。
3) リンクで故障原因と対策をつなぎ、トレース表で抜けを見つける
「対策 / 対応する故障原因」というリンクタイプを作成し、ノートの故障原因の見出しとワークボードの項目をリンクしました。Recobleのトレース画面の表ビューは、文書を順に並べ、リンクごとに1行ずつ展開します。
12件すべてが「リンク済み」と表示され、FC-01とFC-03が同じ対策につながっていることもわかります。最終行の「欠落 1」は故障原因ではなく、ノート文書全体を表す行です。上部のリンク欠落フィルターをオンにすると、処置のない故障原因だけが残るため、会議の前にルール1を確認するための画面になります。
4) 同じ項目をガントチャートで（PMのスケジュールビュー）
PMには、同じ対策をスケジュールとして見るビューが必要です。ワークボードにガントビューを追加すると、11件の対策が目標完了日までのバーとして展開されます。別のスケジュールではなく同じデータを別のビューで見ているため、分析側で期限を変更すると、PMの画面も一緒に変わります。
この例では、11月30日（ガータースプリング溝形状の変更）が最も早い期限で、期限は12月中旬から2027年1月中旬に集中しています。項目間に依存関係を設定すれば、試験枠のように他の対策をブロックしている項目がどれかも、スケジュール上で確認できます。
5) ダッシュボードで毎週レビューする（PMと品質管理者の週次チェック）
対策総数、完了率、期限超過件数、完了件数と、ステータス・担当チーム・AP変化別の分布を1つのダッシュボードにまとめました。本日時点で11件すべてが未完了で、期限超過はまだありません。担当チーム別では、機構設計チームが5件、制御ソフトウェアチームが4件、油圧設計チームが2件です。
会議で決定が必要な項目（例：対策を行わないという決定）は、会議ノートに記録して該当項目にリンクします。後から「なぜこう決めたのか」に、項目から直接答えられます。
07すでにALMやイシュートラッカーを使っている場合
ソフトウェア安全要求の正本はALMに置くべきであり、二重管理は避けるべきです。その場合、ワークボードが担う役割は2つだけです。1つは、保守文書やサプライヤー確認のようにALMになじまない対策を、同じルールで管理する場所です。もう1つは、故障原因ごとに、各対策がALMのどのIDで登録されたかを記録しておく作業スペースです。ALMのない小規模チームや研究プロジェクトであれば、ワークボードだけですべてを運用できます。
08明日確認すること
分析担当者（安全エンジニア）
- 前回の分析で、APがH・Mの故障原因（またはロスシナリオ）のうち、処置のないものは何件ありますか？
- 対策を行わないと決めた項目に、根拠と決定者が記録されていますか？
- すべての対策に、完了条件、つまり何があれば完了とみなすかが記載されていますか？
プロジェクトマネージャー・品質管理者
- 責任者の欄が空欄の対策は何件ありますか？
- 安全分析の対策は、プロジェクトのリスク登録簿やスケジュールに入っていますか？
- 今月が期限のAP Hの対策は何件あり、担当チームの他のスケジュールと重なっていませんか？
- 設計チーム外（保守、サプライヤー、試験）の対策の担当者は、自分の項目を把握していますか？
09おわりに
安全分析の成果物は報告書ではなく、完了すべき改善対策のリストであり、プロジェクトの視点では、スケジュールを伴うリスクのリストです。すべての故障原因に処置を、すべての対策に担当者・期限・エビデンスを付ければ、分析は承認された日ではなく、最後の対策がクローズされた日に終わります。前回の分析を開き、責任者の欄が空欄の対策が何件あるかを数えることから始めてください。
10よくある質問（FAQ）
· AIAG & VDA, FMEA Handbook, 1st Edition, 2019.
· Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT Partnership for Systems Approaches to Safety and Security, 2018. — STPA Handbook（PDF）— MIT PSASS
· ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes.
· Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
VisualPro FMEA | VisualPro STPA | Recobleを無料で始める | VisualPro Lite