RAS AIISO 26262で言及されたSTPA、そしてすべての安全分析をサポートするVisualPro
01要約
02ISO/DIS 26262第3版原案でSTPAに言及
ISO 26262第3版は国際規格原案の段階にあります。投票は2026年10月14日に始まり2027年1月6日に締め切られ、その後も文言や条項番号は変わる可能性があります。この記事は原案の第1部から第10部に基づいています。第11部（半導体）と第12部（二輪車）は確認していません。
STPAは、10の部の本文のうち2か所で言及されています。
| 位置 | 記述内容 | 位置づけ |
|---|---|---|
| 第9部 8.2節（安全分析、一般） | 定性分析手法のリスト：定性的FMEA、定性的FTA、HAZOP、STPA（SAE J3187参照）、定性的ETA | 説明文中の例示リスト |
| 第10部 13.6.1節の注記（NOTE） | 危険なシナリオの探索には、第9部のSTPAなどの手法を使用できる | 機能安全とSOTIFの相互作用を扱う節の注記（NOTE） |
第9部のリストは「以下を含むが、これらに限定されない（include, but are not limited to）」で始まる説明文です。STPAは要求事項の条項（8.4節）には登場しません。第4部と第5部の手法の表はASILに応じて帰納的分析と演繹的分析を推奨しており、第6部は第9部の8節に従うとだけ述べています。原案はSTPAを帰納的・演繹的のどちらにも分類していません。STPAでこれらの表の推奨を満たしたと主張したい組織は、独自に根拠を用意する必要があります。
要するに、第3版原案においてSTPAは「使用できる定性的安全分析手法として規格本文で言及された」手法です。2018年版第9部の同じリストにはSTPAは含まれていませんでした。もう1点付け加えると、8.4.1節は、安全分析を適切な規格またはガイドラインに従って実施することを要求しています。STPAを選択する組織にとっては、原案が参照するSAE J3187がそのガイドラインとなります。
03ISO 26262が要求すること
ISO 26262は、道路車両の電気・電子（E/E）システムの誤動作によって生じる危害を防ぐための機能安全規格です。業界横断の規格であるIEC 61508を自動車向けに適合させたもので、2011年に初版、2018年に第2版が発行されました。
全体の流れは、ハザード分析およびリスクアセスメント（HARA）から始まります。ここでは、ハザーダスイベントごとに過酷度（S）、暴露確率（E）、制御可能性（C）を評価してASIL AからDを決定し、安全目標を設定します。安全目標は機能安全要求に詳細化され、システム、ハードウェア、ソフトウェアに割り当てられます。各段階で、安全分析によって設計が要求に違反する可能性がないかを確認し、テストと確認方策で作業を完了します。第3版原案では、ASIL決定表の値、ハードウェアメトリクスの目標値（SPFM、LFM、PMHF）、帰納的・演繹的分析の推奨レベルは変わっていません。ただしDISの段階であるため、最終版では異なる可能性があります。
原案の序文には8つの主な変更点が挙げられています。そのうち3つが安全分析に関係します。
- 意図した機能の安全性（SOTIF、ISO 21448）との相互作用を定義
- その他の技術（OT：機械、油圧、化学など、E/E以外の技術）との相互作用を定義
- 予知保全を対象に追加
04STPAが加わった背景
原案は、STPAを追加した理由を説明していません。ただし、同じ8節の文を読むと、STPAがどこで使われるかが見えてきます。
8.1節は、安全分析が適用に応じて行うことのリストの最初に「ハザード分析およびリスクアセスメントで識別されなかった新たなハザードの識別」を挙げています。8.4.5節は、そのようにして見つかったハザードを更新したHARAに含めることを要求しています。
8.4.9節は、定性分析が体系的に識別すべき故障の発生源として、アイテムまたはエレメント自体、他のアイテムまたはエレメントとの相互作用、そしてその使用の3つを挙げています。
8.2節と8.4.9節は、故障が違反しうる要求を「SOTIF関連の要求を含む」と記述しています。故障なしに生じるハザードは引き続きISO 21448で扱われますが、2つの分析は同じ要求を見ることになります。
FMEAは部品の故障モードから出発して影響を上位へとたどり、FTAはトップ事象から原因の組み合わせへと下っていきます。どちらも「何が故障するか」を問うのに適しています。STPAは出発点が異なります。コントローラ、被制御プロセス、そしてその間のコントロールアクションとフィードバックをコントロールストラクチャとしてモデル化し、特定の状況でハザードにつながるコントロールアクション（非安全なコントロールアクション、UCA）と、それを生み出すシナリオを探します。必要なコントロールアクションが提供されない場合もUCAであり、STPAは何も故障していない場合と故障が関与する場合の両方を扱います。ドライバーとシステムの間、システムとシステムの間の問題がここで明らかになります。これが上記2つ目のポイントが指す領域です。
| 手法 | 得意なこと | 手薄になること |
|---|---|---|
| FMEA（主に帰納的） | この部品や機能がこのように故障したら何が起こるか | 部品と故障モードごとに行うと、エレメント間の相互作用を見落としやすい（機能FMEAやインタフェースFMEAで一部カバー） |
| FTA（主に演繹的） | どの故障の組み合わせでこの事象が起こるか、その確率はどの程度か | 各エレメントは正しく動作しているのに組み合わさると危険になる場合など、故障事象として表現しにくい原因 |
| HAZOP | 設計意図からの逸脱（多い、少ない、遅いなど）の原因と結果 | コントローラの判断とフィードバックが絡み合うシナリオの構造化 |
| 従属故障分析（DFA） | 独立とみなした2つのエレメントを同時に故障させる原因、または一方の故障を他方へ伝播させる原因 | 個々のエレメントの機能的な故障 |
| STPA | 特定の状況で危険になるコントロールアクション、相互作用と使用の文脈 | 故障率とハードウェアメトリクスの計算。シナリオ数が多く、選別に手間がかかる |
STPAはFMEAやFTAを置き換えるものではありません。ハードウェアメトリクスは引き続き定量的FMEA（FMEDA）とFTAで計算し、原案もその部分は変えていません。また、相互作用を扱う手法はSTPAだけではありません。同じリストにあるHAZOPもそれを扱います。STPAが最も適しているのは、コントロールストラクチャが複雑で、人とソフトウェアの判断が絡み合う場合です。
05実施すべき安全分析は増えていく
原案を条項ごとに読むと、1つのアイテムに対して複数の分析と、それらの間の連携が求められています。STPAを加えると、その数はさらに増えます。以下の条項番号はDISのものであり、最終版では変わる可能性があります。
| 原案の記述 | 条項 | 実務上の意味 |
|---|---|---|
| E/Eシステムが防止・軽減に寄与する技術関連のハザードもHARAで扱う | 第3部 6.4.6 | アイテムにそのような機能がある場合、感電のようにE/Eの誤動作が原因ではないハザードがHARAの表に入る |
| HARAの検証では他のリスクアセスメントとの一貫性を確認する | 第3部 6.4.7.1 | SOTIFのリスクアセスメントやサイバーセキュリティのTARAがあれば、HARAと照合する |
| 故障が違反しうる要求にSOTIF関連の要求を含める | 第9部 8.2、8.4.9 | 安全分析の項目をSOTIF関連の要求と紐づける |
| 従属故障分析は安全分析とは別の分析 | 第9部 7.2 | 独立性または干渉からの自由が求められる場合、DFAの結果を安全分析の結果と分けて提示する。FMEAの1列として残すだけでは不十分。作業成果物は、システム（第4部 6.5.7）、ハードウェア（第5部 7.5.3）、ソフトウェア（第6部 7.5.4）に規定されている |
| 定性分析は相互作用と使用に起因する原因を識別する | 第9部 8.4.9 | それらの原因をどの分析で識別するかを決める |
| 分析で新たに識別されたハザードは更新したHARAに含める | 第9部 8.4.5 | 分析項目からHARAのハザーダスイベントへのリンクと変更管理 |
| 安全分析ツールはツール信頼度評価の対象となるツールの例 | 第8部 附属書B.1 | 分析ツールの分類と適格性確認のエビデンスを準備する |
STPAが加わると、1つのアイテムでHARA、FMEA、FTA、DFA、STPAを実施することになり、その結果をサイバーセキュリティのTARAとも照合しなければなりません。分析ごとに別のファイル、別のツールを使っていると、同じハザーダスイベントや同じ安全目標が複数の場所に別々に記録され、一方の変更が他方に反映されません。原案は分析結果間の一貫性も要求事項としています。従属故障分析は安全分析の結果と一貫していなければならず（第9部 7.4.1）、新たに識別されたハザードはHARAに含めなければならず（第9部 8.4.5）、HARAは他のリスクアセスメントと一貫していなければなりません（第3部 6.4.7.1）。
06VisualPro：複数の安全分析を1つのプロジェクトで
VisualProはVWAYが開発した安全分析ツールです。HARA、FMEA、FTA、STPA、CAST（事故原因分析）、TARAを1つのプロジェクトでまとめて扱います。この記事のタイトルの「すべての安全分析」はこの6つを指します。原案のリストにあるHAZOP、ETA、マルコフモデルまでVisualProがカバーするという意味ではありません。従属故障分析（DFA）の機能は近日追加予定です。
STPAモジュールは、MIT STPA Handbookの4つのステップ（分析目的の定義、コントロールストラクチャのモデル化、非安全なコントロールアクションの識別、ロスシナリオの識別）に従います。MIT PSASSが公開するSTAMP Toolsのリストに掲載されています。掲載はMITによる評価や推奨を意味するものではありません。VisualProはSGS-TÜV Saarのツール認証（ISO 26262、IEC 61508、IEC 62304）を取得しています。これは前述の表の最終行で述べた状況、つまり分析ツール自体の信頼性の根拠を求められたときに活用できる資料です。この認証書は、ユーザーが行うツールの分類と適格性確認へのインプットであり、その評価を代替するものではありません。
07AIが担うこと、人が担うこと
分析の数が増えると、まず人の時間が足りなくなります。VisualProはMCP（Model Context Protocol）接続を提供しており、ClaudeなどのAIが開いているプロジェクトの分析データを読み取り、項目を作成して保存できます。接続されているのはFMEA、FTA、STPA、TARA、HARAの各モジュールです。
2026年10月に公開した技術資料で、これを実際に試しました。運転支援機能の教育用の例の1つで、AIがコントロールストラクチャとガイドワードを読み取り、17件のロスシナリオを作成して保存しました。6件は比較基準とした単一アーキタイプのシナリオ、11件はアーキタイプを組み合わせたシナリオです。その11件を人が判定したところ、対策が変わるものが3件、単一アーキタイプをもっと選んでいれば見つけられたものが3件、既存のシナリオと一部重複するものが2件、設計の確認が必要な仮説が2件、重複が1件でした。AIは幅広い候補を生成し、各候補が実際の設計で成り立つかどうかは人が設計文書をもとに判定しました。これらの結果は1つの例について筆者が判定したものであり、一般化するのは時期尚早です。
原案の要求と照らし合わせると、次のようになります。第9部8.4.8節は安全分析とその結果の検証を要求し、第8部10.4.1節は出力が十分に検査または検証されないツールの評価を要求しています。AIが作成したすべての項目を、作業成果物とする前に人がレビューするのは、この条件を満たすためです。第8部10.4.1節には、AIベースのツールは専門規格においてさらなる考慮の対象となるという注記（NOTE）もあります。
08明日確認すること
- 現在の分析リストの横に第9部8.4.9節の3つの発生源（エレメント自体、相互作用、使用）を書き出し、それぞれをどの分析でカバーしているかを記入します。どの分析でもカバーされていない発生源があれば、HAZOPやSTPAなどの手法を検討します。
- 独立性または干渉からの自由が求められる箇所で、従属故障分析の結果を安全分析の結果と分けて提示できるかを確認します。
- 分析で新たに見つかったハザードをHARAに反映する手順と、その記録があるかを確認します。
- 1つのハザーダスイベントをHARA、SOTIFのリスクアセスメント、TARAで比較し、記録内容が異なっていないかを確認します。
- 使用している安全分析ツールの分類と適格性確認のエビデンス（認証書、既知の問題リスト、リリースノート）を集めます。
- AIが作成した分析項目を誰がいつレビューしたかを記録する方法を決めます。
09まとめ
第3版原案において、STPAは要求された手法ではなく、言及された手法です。原案は定性分析に対して相互作用と使用に起因する原因の識別を要求しており、その要求に対応するために使用できる手法としてSTPAに言及しています。
増えていく分析を個別に管理すると、分析間の一貫性を保つのが難しくなります。分析は1つのプロジェクトでまとめて扱い、AIが生成した候補は人が判定するようにしましょう。
10よくある質問
Q1ISO 26262第3版が発行されたら、STPAは必須になりますか？
いいえ。原案では、STPAは第9部8.2節の定性分析手法の例示リストで言及されているだけで、要求事項の条項にもASILに応じた推奨表にも含まれていません。ただし8.4.9節は、定性分析が相互作用と使用に起因する原因を識別することを要求しています。その要求にどの手法を使うかは各組織が決めることであり、STPAは原案が言及する選択肢の1つです。
Q2STPAを実施すれば、FMEAやFTAを減らせますか？
いいえ。ハードウェアアーキテクチャメトリクスとPMHFは故障率に基づく定量分析で評価され、原案も帰納的・演繹的分析の推奨を維持しています。原案はSTPAを帰納的・演繹的のどちらにも分類していません。STPAは、特定の状況で危険になるコントロールアクションと相互作用を見つけるために、FMEAやFTAと並行して使います。
Q3原案が参照しているSAE J3187とは何ですか？
自動車のセーフティクリティカルなシステムの評価にSTPAを適用するための推奨プラクティスをまとめたSAEの文書です。原案の第9部はSTPAの手順そのものを説明しておらず、参考文献でこの文書を示しています。手順を学ぶには、MITのSTPA Handbookが基本的な参考資料です。
Q4まだ原案の段階です。今から準備する意味はありますか？
文言は投票とコメント処理を経て変わる可能性があるため、条項番号に合わせた文書作業はまだ早いといえます。今やっておく価値があるのは、分析範囲の確認です。相互作用と使用に起因する原因をどの分析で識別するか、従属故障分析の結果を分けて提示できるかは、最終版の文言にかかわらず確認しておく価値があります。
Q5AIが生成した分析結果を、そのまま審査に提出できますか？
いいえ。原案の第9部8.4.8節は安全分析とその結果の検証を要求しており、第8部10.4.1節にはAIベースのツールにはさらなる考慮が必要であるという注記（NOTE）があります。AIが候補を作成し、人が設計文書と照合して、成り立つものだけを作業成果物として採用するのが正しい方法です。
参考資料
- ISO/DIS 26262-1～-10:2026, Road vehicles — Functional safety（国際規格原案、投票期間：2026年10月14日～2027年1月6日）。この記事で引用した条項：第9部 7.2、7.4.1、8.1、8.2、8.4.1、8.4.5、8.4.8、8.4.9 / 第10部 13.6.1 / 第3部 6.4.6、6.4.7.1 / 第4部 6.5.7 / 第5部 7.5.3 / 第6部 7.5.4 / 第8部 10.4.1、附属書B.1
- SAE J3187, System Theoretic Process Analysis (STPA) Recommended Practices for Evaluations of Automotive Related Safety-Critical Systems
- ISO 26262-9:2018, 8節 Safety analyses; ISO 21448:2022（SOTIF）; ISO/SAE 21434（サイバーセキュリティ）
- VWAY 技術資料「The Next Step in STPA Loss Scenarios: Cross-Class Guide Words + MCP AI」、2026年10月29日
- Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT, 2018 — psas.scripts.mit.edu
- MIT PSASS, STAMP Tools — psas.scripts.mit.edu/home/stamp-tools
この記事はISO/DIS 26262:2026（国際規格原案）の第1部から第10部に基づいており、第11部と第12部は扱っていません。国際規格原案は発行済みの規格ではなく、投票とコメント処理を経て文言や条項番号が変わる可能性があります。原案からは短い語句を引用しており、要約と解釈は筆者によるもので、認証や審査の判断を代替するものではありません。スクリーンショットの運転支援機能は架空の教育用の例であり、特定の車両やメーカーの設計ではありません。AI生成の数値は前述の2026年10月29日の技術資料の結果であり、判定は筆者が行ったもので、独立した再判定は受けていません。