非安全なコントロールアクション「UCA」の書き方：今こそ知りたい！STAMP/STPAの勘所（4）（2/2 ページ）

より複雑なシステムの安全性解析の理論とその分析手法である「STAMP/STPA」を実践する上での勘所をTips形式で簡潔に分かりやすく説明する本連載。第4回は、STPA手順「第3のステップ：UCAの識別」を失敗しないための重要ポイント、注意点について解説する。

[石井正悟，MONOist]

UCAの書き方の例

　UCAの具体的な書き方を一つ、例を用いて紹介しよう。この書き方については、STAMP広場に掲載されているUCAの識別に関するTips（2025年11月5日：向山輝氏）で分かりやすく解説されている。この例では、IPAが無償公開しているSTAMP支援ツール「STAMP Workbench」を用いた。

　図2のようなCS図を描いたとする。

図2　CS図の一例

　UCA表にUCA文言のテンプレートを埋める（図3）。

• 「XXXXのときに『CA』が実行されず、YYYYのハザードに至る」：Not Providing
• 「XXXXのときに『CA』が実行されて、YYYYのハザードに至る」：Providing causes hazard
• 「XXXXより前に『CA』が実行されて、YYYYのハザードに至る」：Too early
• 「XXXXより後に『CA』が実行されて、YYYYのハザードに至る」：Too late
• 「XXXXのときに『CA』の実行が短か過ぎて、YYYYのハザードに至る」：Stop too soon
• 「XXXXのときに『CA』の実行が長過ぎて、YYYYのハザードに至る」：Applying too long

図3　UCA表の一例［クリックで拡大］

　どういう場合（コンテキスト：XXXX）にどういう状態（ハザードまたはシステム安全制約違反：YYYY）になるかを考える。そして、整形して自然な言葉にする（図4）。

図4　図3のUCA表の文言を整形して自然な言葉に変えた状態［クリックで拡大］

　分析の際、論理的にはUCAになり得るが、このシステムの場合にはUCAに成り得ない、という場合は非UCAとする。その場合、なぜ非UCAとしたかの理由をコメントして残すこと。もしかしたら、将来その理由がひっくり返るような事態が発生するかもしれず、そのときには残されたコメントがとても役に立つであろう。非UCAと判断したときに、当該の欄を空白にしたり、「-」「N/A」などとしたりするのではなく、非UCAである理由を記しておくことをお勧めする。

コントローラーの動作上の制約

　UCAの書き方の話から少し逸れるが、第3のステップで行うことはUCA識別だけではないので付け加えておく。STAMP分析において必須ではないが、こういう使い方もあるということである。

　第1のステップでシステムレベルのハザードを定義すると、その裏返しとしてシステム安全制約を導出できた。同様に、第3のステップでUCAを識別すると、その裏返しとしてコントローラーの動作上の制約を導出できる。

　STAMPにおけるコントローラー制約とは次のように定義されている。

コントローラー制約：コントローラーの制約は、UCA を防ぐために満足されるべき必要なコントローラーの動作を特定する

　似たような言葉にコンポーネント安全制約がある。STAMP分析の最後に対策を検討することになるが、その対策がコンポーネント安全制約である。コンポーネント安全制約はコントローラーの動作上の制約と共に、コンポーネント設計における要求仕様に含まれるべきものである。対策の内容によっては、システム安全制約として追加されることもある。

まとめ

　今回は、UCA識別の際に4つのガイドワードで与えられる視点による網羅性を確保するためのちょっとした書き方の工夫を紹介した。お試しいただきたい。

　STPA Handbookでは、UCAを識別する際の一般的なミスを防ぐためのヒントとして以下のような項目が挙げられている。

• UCAが、CAが非安全な状態になるコンテキストを特定していること
• UCAのコンテキストが、実際の状態についての潜在的に信じていることではなく、コントロールアクションを非安全にさせるであろう実際の状態や条件を特定していること
• UCAのコンテキストが明確に定義されていること
• UCAのコンテキストが、将来の影響や成果に置き換えられないこと
• 全てのUCAが1つのまたは複数のハザードとリンクするようにトレーサビリティーが文書化されていること
• N/Aであると想定するCAをレビューして、それらが適用されないことを確認すること
• パラメータを持つ連続CAに対して、パラメータの過剰、不足や方向の間違いを考慮していること
• UCAの背後にある仮定や特別な推論が、全て文書化されていること

　これらのヒントについて本記事では詳述しないが、レビュー時のチェック項目として参考になれば幸いである。（次回に続く）

筆者プロフィール

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

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

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