STPAの第1ステップでハマりがちな「システム境界の定義」はどうすればいいのか：今こそ知りたい！STAMP/STPAの勘所（2）（2/2 ページ）

[石井正悟，MONOist]

システム境界を定義する

　繰り返しになるが、STPAにおいて「システム境界を定義する」とは、「STPAで何を分析するのかを明確にする」ことである。

　STAMPにおいてハザードは次のように定義されている。

ハザードとは、一組の最悪ケースの環境条件で、損失につながるような、システム状態、または、一組の条件である。

　そして、STPA Handbookにもシステムレベルのハザードを識別するにはシステム境界の識別が必要であると記されている。下記はその一部の引用である。

システムレベルのハザードを識別するには、最初に解析されるシステムおよびシステム境界を識別する必要がある。システムは、アナリストによって考え出される抽象概念である。システムに含まれるものおよびシステム境界が何であるかを決めなければならない。

　第1のステップを構成する4段階の手順のタイトルにも「2．システムレベルのハザードを識別する」とあるように、ハザードを「システム状態」と定義している。それでは、ここでいうところのシステムとは何か？　それは今、分析対象としているシステムである。前ページで安全分析の最初の手順としてシステム全体の概要を認識共有する、と説明したが、そのシステム全体と分析対象としているシステムとは必ずしも同一とは限らない。一般的には異なるものと思う。本記事で伝えたいのはこの点である。

システム境界定義の例

システム境界が定義されなかった場合

　例えば、将来の都市交通システム構想の中で、自動車の自動運転が大きな役割を果たすと位置付けられている場合を考えてみよう。そして、分析者が開発担当するのは自動車に搭載される自動運転コントローラーであると仮定する。

　その場合、まずはシステム全体の概要を認識するには都市交通システムという範囲の概要を共通認識して、開発対象が利用される環境も理解する必要があろう。しかし、STPA分析でシステムレベルのハザードを識別するときに、分析対象を都市交通システム全体と捉えていたら、おそらく議論は発散して、分析者にとって最も関心のある自動運転コントローラーについての分析にたどり着けないのではないか。あるいは、無理やりこじつけたら、分析者／設計者にはコントロールできないものまでを含めた分析になってしまい、関係者への説明に窮するような分析結果になりかねず、STPA分析に期待した効果を得られないであろう。

システム境界が定義された場合

　次に正しくシステム境界を定義した例を、架空システムを題材として記す。

　図2は、一般的な企業の小規模ネットワークを開発するに当たり、ステークホルダー間でシステム概要の認識を共有するために作成したシステム構成図（ポンチ絵レベルの概念図）である。開発対象は黒枠の中である。そして、この開発案件の関係者は、悪意ある攻撃からシステムを守るため、赤枠部分の安全確保が重要と考えた。そして、分析対象システムのシステム境界として定義したのが赤枠である。この場合は、STPAで分析する対象を、ステークホルダーが最も関心のある赤枠の中に絞り込んだということだ。システム境界がきちんと定義された例である。

図2　小規模ネットワークの開発においてステークホルダー間でシステム概要の認識を共有するために作成したシステム構成図［クリックで拡大］ 出所：JASA「STAMP広場」の「なるほどSTAMP」コーナーより抜粋

　もし、このように絞り込んでいなかったら、例えば「IT知識が乏しいサーバ管理者がいる」もハザードとして挙げられるかもしれない。開発対象の黒枠内で考えたら確かに最悪の場合に“サービス停止”というアクシデント（損失）につながり得るシステムレベルのハザードである。しかし、そこから「悪意ある攻撃からシステムを守る」ための対策（コンポーネント安全制約）を導くのは難しいであろう。運良くできたとしても、かなりの遠回りになってしまう。

　分析する対象を明確に絞り込むことによって、ステークホルダーが関心を持つ対象に分析の思考を集中させることができる。そして、思考が発散することを避け、遠回りもせず、効率的に目的とするコンポーネント安全制約策定にたどり着けるようになる。

STPAは反復的である

　最後に、STPAが反復的であることを説明する。

　ここまでの説明と一見矛盾するように感じられるかもしれないが、STAMPの提唱者であるNancy Leveson氏がIPA（情報処理推進機構）に来訪された際、「STPA分析するときにシステム境界を定めておく必要はない」と語られた。おそらく、事前に決まっていなくても、分析を進めながらシステム境界を決めれば良い、ということと筆者は理解した。

　そして、もう一つ重要なのは、第1のステップでシステム境界をいったん決めて認識共有するが、最終決定でなくても良いということだ。この後の分析を進める過程でシステム境界を見直しても良い。その場合、ハザードも見直すことになる。STPAはこのように反復的に実施しながら、分析を洗練することが推奨されている。反復的に実施することになっても、それを無駄な手戻りとは考えず、そこまで分析したからこそ気付きを得られた、と前向きに捉えてほしい。

おわりに

　本連載の第2回以降では、MIT発行のSTPA Handbook第2章に記載された多くの重要ポイントや注意事項の中から幾つかの項目に絞って解説している。STPA Handbook第2章および同等の内容を簡潔にまとめてIPAが発行した「はじめてのSTAMP/STPA」の第1章と第2章には有益な情報が凝縮されている。STPA分析を実践される際、その都度、これらを何度も繰り返して読むことをお勧めする。

　次回は、STAMPの肝となるCS（コントロールストラクチャー）図の構築についてのTipsを紹介する。（次回に続く）

筆者プロフィール

石井 正悟（いしい しょうご）

京都大学理学部卒業後、東芝にてOSカーネル、仮想計算機、システム高信頼化技術、システムシミュレーション技術の研究開発に携わる。その後IPAにて、STAMP、FRAMなどの安全性解析手法の調査研究に従事。STAMP普及促進のため、書籍「はじめてのSTAMP」シリーズ発行、STAMP支援ツール「STAMP Workbench」開発や各種教材作成などを担う。現在はIPA専門委員としてSTAMP普及活動に関わる。

・IPA デジタル基盤センター STAMPサイト