ALMHARAとTARAが同じテーブルに着く
VisualPro Tech Brief
HARAとTARAが同じテーブルに着く
安全・セキュリティ統合分析がツール選定の基準になりつつある理由
機能安全（ISO 26262）× サイバーセキュリティ（ISO/SAE 21434） | 業界動向ブリーフ
ISO 26262ISO/SAE 21434UN R155AIAG-VDAHARA · TARA
01概要（TL;DR）— 問われるのは今や「連携しているか」
機能安全（FuSa）とサイバーセキュリティが、別々のチーム、別々のツール、別々の文書で進められていた時代は終わりつつあります。業界全体で、同じチームがISO 26262のHARA（ハザード分析およびリスクアセスメント）とISO/SAE 21434のTARA（脅威分析およびリスクアセスメント）を一緒に実施する「HARA・TARA合同ワークショップ」が、標準的な慣行になりつつあります。重複作業をなくし、セキュリティ侵害に起因する安全リスクを捉えるためには、同じアイテム定義と同じアーキテクチャモデルの上で、安全上のハザードとセキュリティ脅威を識別しなければなりません。
同様に、SAE Mobility Engineering Technology（Tech Briefs）は、DFMEA、HARA、FTAを個別に実施することの落とし穴を指摘し、その解決策として連携分析（linked analysis）を提示しました。結論は一つに収束します。安全・セキュリティの統合分析が、ツール選定の重要な要件として浮上しているのです。VisualProは、FMEA、FTA、HARA、TARA、STPAを単一のプラットフォーム、単一のデータベース上で連携させます。
求められるのは、個々の分析をうまくこなすツールではなく、分析同士をつなぐツールです。
02なぜ今か — 安全・セキュリティ統合を推し進める3つの変化
1規制の融合一つのアイテムに、二つの義務的評価
UN R155（CSMS）/R156の発効以降、型式認可にはサイバーセキュリティ管理システムが求められ、ISO 26262とISO/SAE 21434はいずれもコンセプトフェーズでのリスクアセスメント（HARA/TARA）を要求しています。分析対象のアイテムとアーキテクチャは同一なのに、分析は二つに分かれます。別々に進めれば、同じシステムを二度モデル化し、二度文書化することになります。
2プロセスの融合HARA・TARA合同ワークショップ
ハッキングされたブレーキECUは、セキュリティ脅威であると同時に安全上のハザードでもあります。安全とセキュリティの専門家がアイテム定義を共有し、シナリオを相互レビューする合同ワークショップは、重複をなくすとともに、どちらか一方の分析だけでは見えないドメイン横断のリスク（攻撃 → 誤動作 → 傷害）を捉えます。ASILとCALの評定が同じ会議記録から導かれるため、審査対応の一貫性も保たれます。
3サイロ化のコストDFMEA · HARA · FTAの連携
Tech Briefsの記事（Omnex）は明快に述べています。FMEA、FTA、HARAはいずれも製品リスクを異なる方向から扱うものですが、ほとんどの組織はそれらの間の一貫性を確保できず、非効率とリスクの見落としに悩まされています。推奨される流れは、HARAでハザードを識別・分類し、トップダウンのFTAとボトムアップのDFMEAを連携させて、反対方向から同じ全体像を完成させることです。
03分断された分析の5つの落とし穴
| 落とし穴 | 分断されているとどうなるか | 連携した場合 |
|---|---|---|
| 重大度評定の不整合 | HARAのSとDFMEAのSが個別に評定され、同じ故障に異なる等級が付く — 審査での指摘事項 | DFMEAがHARAから重大度を継承 |
| 故障分析から切り離された安全目標 | FTAのトップ事象が安全目標を参照せずに定義され、ASIL割り当ての根拠が弱まる | 安全目標の違反がそのままFTAのトップ事象 |
| 三重のデータ入力 | 同じ故障モードをHARA、FMEA、FTAに入力 — 工数の無駄、バージョンのずれ | 一度定義すれば、三つの分析すべてで再利用 |
| 変更の非同期 | 設計変更が一つの分析にだけ反映され、他の分析は気づかないうちに古くなる | 単一データベースですべての分析を同期 |
| セキュリティ脅威が安全分析に届かない | TARAの攻撃パスが安全分析に伝わらず、セキュリティに起因する安全リスクが見落とされる | HARAとTARAが同じモデルを相互参照 |
04連携分析は実際にどう機能するか
| 手法 | 方向 | 核心となる問い | 成果物 | 連携ポイント |
|---|---|---|---|---|
| HARA（ISO 26262） | アイテムレベル、トップダウン | 何が危険か？ | ハザード、ASIL、安全目標 | 安全目標 → FTAトップ事象 / 重大度 → DFMEA |
| FTA | トップダウン（影響 → 原因） | なぜ起こるのか？ | 故障論理ツリー、最小カットセット | 基本事象 → DFMEAの故障原因 |
| DFMEA（AIAG-VDA） | ボトムアップ（原因 → 影響） | どう防ぐか？ | 故障モード、故障原因、S/O/D、AP | 故障影響の重大度をHARAから継承 |
| TARA（ISO/SAE 21434） | 脅威の視点 | 誰が、どのように攻撃するか？ | 脅威シナリオ、攻撃パス、CAL | ダメージシナリオ ↔ HARAのハザード |
4つの分析が同じアイテム定義と同じシステムアーキテクチャ（構造ツリー）を共有するとき、これらのつながりは手作業によるマッピングではなく、データベース上のリレーションになります。これこそが「連携分析」の実体です。
05VisualProによる支援
一つの構造ツリー、五つの分析合同ワークショップ
FMEA、FTA、HARA、TARA、STPAが同じシステム構造データベースを共有します。HARA・TARA合同ワークショップでは、安全チームとセキュリティチームが同じモデルを使い、同じ画面上で分析します。
分析間のトレーサビリティ（デジタルスレッド）トレーサビリティ
安全目標 ↔ FTAトップ事象 ↔ DFMEA故障モード ↔ 安全要求、そしてTARAの脅威 ↔ 対策が、単一データベース上で連携しています。設計変更や新たな脅威は連携した分析全体に伝播し、生きたトレーサビリティが維持されます。
規格に準拠した成果物韓国語/英語レポート
AIAG-VDA FMEA、ISO 26262 HARA（ASIL）、ISO/SAE 21434 TARA、FTAを標準フォーマットで作成し、韓国語と英語のレポートを出力します。すべての分析について、審査員に条項レベルの根拠を示すことができます。
MCPベースのAIエージェント連携AI連携
FMEA、FTA、HARA、TARA、STPAのMCP対応により、ClaudeなどのAIエージェントがVisualProと直接通信します。ハザード・脅威候補の識別からスコアリング案の作成までを対話形式で進め、分析者は検証と判断に集中できます。
06よくある質問（FAQ）
Q1HARAとTARAは本当に一緒に実施しなければならないのですか？
規格は別々（ISO 26262 / ISO/SAE 21434）ですが、分析対象のアイテムとコンセプトフェーズのタイミングは同じで、その結果は互いに影響し合います（セキュリティ侵害 → 安全上のハザード）。合同ワークショップは、重複するモデル化をなくし、ドメイン横断のリスクを捉える最も効率的な方法であり、業界の慣行として定着しつつあります。
Q2すでにExcelでそれぞれの分析をきちんと行っています。なぜ統合ツールが必要なのですか？
問題は個々の分析の品質ではなく、分析間の一貫性です。重大度の不整合、三重のデータ入力、変更の非同期はファイルベースの作業では構造的に発生します。また、審査で求められるトレーサビリティ（どの安全目標がどの故障分析で検証されているか）を、スプレッドシートファイル間の手作業によるリンクで維持することは事実上不可能です。
Q3FTAとFMEAはどちらを先に行うべきですか？
順序よりも連携が重要です。HARAでハザードと安全目標を確立し、安全目標の違反をFTAでトップダウンに展開して因果構造を把握したうえで、DFMEAで原因レベルからボトムアップに定量化（S/O/D、AP）します。二つの手法は、反対方向から同じ全体像を完成させます。
07今すぐ始める（次のステップ）
安全・セキュリティの統合分析は、もはやベストプラクティスの見本ではなく、審査や契約が求める基本要件です。自動車、防衛、ロボット、半導体のプログラムで実績のあるVisualProで、次のHARA・TARA合同ワークショップを単一のプラットフォーム上で始めましょう。
構造を共有し、分析をつなぐ — VisualProで実現する安全・セキュリティ統合設計。
参考資料：SAE Mobility Engineering Technology / Tech Briefs, “Avoiding Risk Analysis Pitfalls: Implementing Linked DFMEA, HARA, and FTA” (Omnex)