STAMP/STPAとは何か：基礎から学ぶSTAMP/STPA（1）（1/4 ページ）

システムとシステムがつながる、より複雑なシステムの安全性解析手法として注目を集めているのがSTAMP/STPAだ。本連載はSTAMP/STPAについて基礎から学ぶことを主眼とした解説記事となっている。第1回は、STAMP/STPAの生まれた理由や、従来手法との違い、実施の大まかな流れについて説明する。

[石井正悟（IPA ソフトウェア高信頼化センター 調査役），MONOist]

なぜSTAMP/STPAは誕生したのか

　「われわれの生活に満ちあふれている自動車や列車、航空機、ロボット、家電製品……。これらの工学システムは、その内部にコンピュータとネットワーク機能を持ち、高度なソフトウェアで制御されている」^※1）。そして、それら工学システムやソフトウェアは加速度的に大規模化、複雑化している。

※1）「はじめてのSTAMP/STPA 実践編」巻頭の記述を元に記載したもの

　しかし、既存の安全性解析手法や安全規格は、このような複雑化したシステム、特にソフトウェアの安全評価に対応できていないのが現状だ。

　こうした社会的潮流を背景に誕生したのが、STAMP（Systems-Theoretic Accident Model and Processes：システム理論に基づくアクシデントモデル）/STPA（System-Theoretic Process Analysis）である。

　STAMP/STPAは2012年、マサチューセッツ工科大学（MIT） 教授のナンシー・レブソン（Nancy Leveson）氏が提唱した、「相互作用する機能単位でハザード要因を考える」という新しい安全性解析手法である。ハザードとは、「危険の原因」という意味で、アクシデントが潜在している具体的な状態を指す。

　1990年代までのシステムの多くは、ハードウェア機器がシステムの基幹を担う要素となっていた。それゆえ、アクシデントは、機器の故障や人間のオペレーションミスが根本原因であり、それが他の機器や人間に伝搬し、最終的にアクシデントに至るものと捉えられていた。その延長で、従来の安全分析では、システム構成機器を組み合わせたものをシステム全体と捉えて分析していたのである。

　しかし、この考え方では、複雑化するシステムに対応できない。システムの基幹を担う要素がソフトウェア中心に変化するに伴い、システムにかかわる「人」「ソフトウェア」「ハードウェア」といった要素が、爆発的に増大してきた。そのため、要素間の相互作用も複雑になり、個々の要素の役割を理解しただけでは、もはやシステムを理解できなくなったのである。

　実際、多くの機器が複雑に接続する大規模システムにおいては、たとえ構成機器が故障しなくても、アクシデントが発生している。そして複雑なシステムにおけるアクシデントの原因は、1つの構成要素に限定できる要因だけではなく、複数の要素間の相互作用による要因も考えなければならなくなった。複雑な相互作用に隠れていたハザード要因が表面化する、いわゆる「創発特性（Emergent Properties）」をカバーするためには、新たな手法が必要とされているのだ（図1）。

図1　従来の手法とSTAMP/STPAの違い（クリックで拡大）