社会・産業のデジタル変革

STAMPおよびSTAMPツールのTips

公開日:2025年2月17日

最終更新日:2025年4月15日

独立行政法人情報処理推進機構
デジタル基盤センター

本Tipsページでは、STAMP Workbenchの便利な利用方法/操作方法やSTAMP/STPA分析手法に関するちょっとした勘所をいくつか紹介します。一部の操作方法はマニュアルにも掲載されていますが、頻繁に問い合わせのある項目をピックアップして本Tipsページでも紹介しています。
また、STAMP Workbench使用において発生し得る軽微な問題を回避するための注意事項についても記しています。
本ページに示すノウハウなどは必ずしも汎用的なものではなく、「こうしたらうまくいった」という実施体験者からいただいた意見等も掲載しています。本Tipsページをご参考としてご自身で良いと感じた方法、効果的・高効率な方法を取り入れ、皆様の分析作業が改善されますことを望みます。

皆様からお問い合わせいただいた内容は、このTipsページへの掲載を検討します。お問い合わせに限らず、皆様が工夫された利用方法などありましたら、本Tipsページに掲載し、多くの方々と共有できることを期待しています。また、既記載のTips内容への改善案などありましたらお聞かせください。
お問い合わせおよび利用方法の情報提供などは「お問い合わせ先」メールアドレス宛てに送信ください。

お問い合わせ先
E-mail:
ikc-stamp-workbenchアットマークipa.go.jp
印刷用ファイル

便利な操作方法

  • 図や表の文字サイズを変更する

    ツールとして常に有効にする方法ではなく、プロジェクトファイル毎の設定です。

    1. STAMP Workbenchで、文字サイズを変更したいプロジェクトファイル(.stmpファイル)を開く。

      • プロジェクトファイル(.stmpファイル)を開く
    2. 左上プロジェクトビューのタブに STPA手順/構造ツリー/マップ/図 があります。「構造ツリー」タブを選択。

      • 「構造ツリー」タブを選択
    3. プロジェクトファイル名を選択し、コンテキストメニューを開く(右クリック)。
      下図では「中級-#7」がプロジェクトファイル名。

      • プロジェクトファイル名のところを右クリック
    4. プルダウンメニューから、「フォントの設定」を選択。

      • 「フォントの設定」をクリック
    5. 「フォントの指定」ダイアログで、「自動」が選択されているので、オフにする。

      • 「フォントの指定」ダイアログで、「自動」が選択されているのでクリックして選択をオフにする
    6. 文字フォントのサイズを数字で選択。デフォルトは16。

      • 文字フォントのサイズを数字で選択

      設定できるサイズは6から18まで。
      OKを押して確定する。
      選択したフォント指定はすべての図や表に適用される。別の方法を使って、CS図上の一部の文字列のみ文字色やフォントを変更することもできる。

  • 目立つように一部の文字だけ文字色を変更する

    コントロールストラクチャー図(CS図)において一部の文字列のみ文字色やフォントを変更することができます。全ての表で一部の文字単位で文字色を変更する機能はありません。

    • CS図やコントロールループ図において、CA、FB、input、outputなど色を変更したいコンポーネントや文字列を選択して、ツール画面にある帯状のツールバーで「文字色の設定」を押して色を選択する。変更できるのは文字色とフォント種類で、文字サイズは変更できない。

      • 文字色の設定の説明画像
      • 文字色の設定の説明画像

      変更できない例:文字単位で色を変更

      • 文字単位では色を変更できない

      変更できる例:文字列全体の色とフォントの変更

      • 文字列全体では色とフォントの変更ができる
  • input/output線の操作方法

    STAMPのコントロールストラクチャー図(CS図、CSD)において、input/outputは、外界からシステム内のコンポーネントへの入力/システム内のコンポーネントから外界への出力を意味します。
    CS図、あるいはコントロールループ図(CL図、CLD)において、コンポーネント間の線は制御(CA)またはフィードバック(FB)であり、input/outputは入力元や出力先のコンポーネントが現れません。
    但し、「外界モデル」の項に記したように、外界の何とのinput/outputかを示したいときには外界モデルというコンポーネントを配置して、その外界モデルコンポーネントとシステム内コンポーネントの間をinput/output線で結ぶ方法もあります。
    その場合、STAMP Workbenchではinput/output線がCA線(赤い矢印線)またはFB線(青い矢印線)で結ばれるので、線の色を黒に変更すると良いです。
    CA、FB、input/outputの違いを線の色で明確に区別することをお勧めします。
    この対策はツールが自動的にサポートすることが望ましいですが現状サポートできていません。

    • 下図では、inputの文字も線もCAと同じ赤になっているので、CAと勘違いし易い。

      • inputの文字も線もCAと同じ赤になっているので、CAと勘違いし易い例

      変更したい線を選択すると線色変更のボタンが有効になる。

      • 線色を変更している画面

      下図では外界からのinputの文字色と線色の両方を黒に変更した。CS図上でCAとinputの違いが明確になった。

      • 外界からのinputの文字色と線色の両方を黒に変更し、CS図上でCAとinputの違いが明確に
  • 図から削除/モデルから削除

    コントロールストラクチャー図(CS図)を編集する際、コンポーネントやCA/FB線などを削除する場合、削除対象を選択してからコンテキストメニューを開く(右クリックする)と、「モデルから削除(Ctrl+D)」と「図から削除(Delete)」を選択できる。

     「モデルから削除(Ctrl+D)」を選択することをお勧めします。

    「図から削除(Delete)」とすると見かけ上は見えなくなりますが、モデルとして残っている(コンポーネント抽出表にも残っている)ので、後で何らかの編集をしているときに図に復活することがあり戸惑うことが有り得ます。不要と判断したら「モデルから削除(Ctrl+D)」を選択することをお勧めします。

    • 「モデルから削除(Ctrl+D)」を選択する図
  • Excelに変換して列を増やす

    UCA表や対策表に列を増やしたいことがあります。例えば、

    • UCA表にメモを残したい。UCAを考えるときには原因を考えないようにするが、思いつくことはある。あとのステップのために思いついたことをメモしておきたい。
    • 対策表に、自社(自プロジェクト)独自のIDなどの情報をつけておきたい。

    等々、STAMP Workbenchへの機能拡張要望が多々あります。STAMP Workbenchは汎用的かつ基本的な機能を実装しており、とりあえずたいていの場合は事足りることを想定しているので、IPAによる機能拡張予定はありません。このような要望については、次の2通りの対応策があります。

    • 【対応策1】
      利用者様自身が(IPAがオープンソースとして公開している)ソースコードを改編して機能追加することも可能です。モデリングツール一般に精通していない技術者様でも、実は、列を追加する程度の改編は然程ハードルの高いものではありません。プログラミングの腕に覚えのある方ならば、ソースコードにザックリ目を通していただければお判りいただけるかと思います。ソースコード改編後のビルド方法も公開しています。改編して利用されている事例は国内外から報告されています。

    • 【対応策2】
      STAMP Workbenchで作成した表をExcel出力して、Excel上で列追加する。

      (1)UCA表や対策表ウィンドウの右上にある「右向き矢印」を押す。
      下図はUCA表の場合。

      • Excel出力して、Excel上で列追加する例

      対策表の場合も同じ。

      • Excel出力して、Excel上で列追加する例

      (2)「保存」のウィンドウを開いたら、保存先を選択して「保存」ボタンを押す。

      • Excelファイルを保存する

      保存先にExcel表(.xlsxファイル)が保存されるので、Excelを起動して任意に列追加などを行う。

    注意事項

    STAMP WorkbenchからExcelへのエクスポート機能は有るが、ExcelからSTAMP Workbench へのインポート機能は無い。
    Excelで編集した内容を自動的にSTAMP Workbenchに取り込むことはできない点に注意のこと。

    デフォルトの保存先フォルダーはProgram Filesフォルダーなので書き込みできません。必ず、プロジェクトファイル(.stmpファイル)と同じフォルダーなど、書き込み可能なフォルダーを選択してください。

  • CS図のCA,FBに番号を付ける

    CS図を見て議論するときにCA,FBに番号があると話が早いです。
    CA,FBの番号振り直しは次のようにすると簡単です。

    1. CS図で直接CA,FBの名前を編集して"CAn"のように適当に番号を振る。
    2. UCA表でCAを"CAn"のnに合わせてドラッグ&ドロップで上下に移動する。
      CAを押して掴み、挿入したい横線のところまで上下にマウスカーソルを移動して放す。
      または、
    3. UCA表の最左列のCA番号に合わせて、名前に付けた"CAn"のnを修正する。
    ツールへの要望

    UCAの番号はUCA表で整理できるが、FBの番号はCS図かコンポーネント抽出表でやるしかないので不整合が出そうな気がする。できることなら、(一般的にはCAとFBは対になるので)コントロールループを成すCAと対応付くFBが同じ番号になると良いが、自動的にナンバリングするのは難しそう。せめて、番号の重複を無くすくらいはできると良い。

    この対策はツールが自動的にサポートすることが望ましいが現状サポートできていません。

    • 下図のように「アクセル」や「ブレーキ」といった同名のCAがあるときなど、レビュー時に言葉だけでは区別が面倒なのでCS図に番号が表示されると便利。

      • 同名のCAがある

      CS図の中でCA1、CA2、・・のように番号を振る。

      • CA1、CA2のように番号を振る

      UCA表で順番が上下逆なのが気になる。

      • UCA表で順番が上下逆

      UCA表でNo欄の番号を選択してドラッグし、移動したいところまでマウスカーソルを移動してドロップする。

      • UCA表での順番を修正している図

      UCA表の中のUCA番号(UCA12-N-1など)は自動的に変わるので、手作業での修正は不要。同時に、対策表の中のUCA番号なども自動的に変わるので、UCA表以外に対して手作業での修正は不要。

      • UCA表での順番を修正している図
  • 一画面に複数windowを表示する、CS図とUCA表を同時に見ながらUCAを考える

    STAMP Workbenchを用いて分析(思考)するとき、異なる画面を行ったり来たりするのは思考の妨げになるので、関係する情報を一度に見たくなります。そういうときにはSTAMP Workbenchの「ウィンドウ」機能を用いて、1画面内に複数のWindowを表示することが有効です。

    1. 同時に見たいWindowを開く。

      • 1画面内に複数のWindowを表示する手順
    2. ツールバーの「ウィンドウ」を選択してポップアップウィンドウを開く。

      • 1画面内に複数のWindowを表示する手順
    3. ポップアップウィンドウで、「上下に並べて表示」、「左右に並べて表示」、「上下左右に並べて表示」から並べたい配置を選ぶ。

      • 1画面内に複数のWindowを表示する手順
    4. 画面を最大化するため、左側のプロジェクトペインを隠す。プロジェクトペインの右上の◀ボタンを押す。

      • 1画面内に複数のWindowを表示する手順
    5. マルチウィンドウになったら、それぞれのウィンドウサイズを変更したり、配置を変えて、見易くする。
      下図の1枚目は2つのWindowを同時に表示。2枚目は3つのWindowを同時に表示。
      1枚目の図では、CS図とUCA表を同時に見ながらUCAを考えるときに良く使うものと思われる。この例では、CS図の中の着目するCAに関するコントロールループのみを表示している。2枚目の図では、コントロールループとUCAを見ながらHCFやシナリオを考えるときに有効。

      • 1画面内に複数のWindowを表示する手順
      • 1画面内に複数のWindowを表示する手順
  • CS図を見ながらコンポーネントの責務を確認する、プロセスモデルを入力する

    CS図を見ながらCAやUCAを考えているとき、考えている最中の対象コンポーネントの責務やinput/outputなどを確認する場合、コンポーネント抽出表を見れば書いてあるが、画面を変えずにサッと確認したいことがある。その場合は、画面左下のペインに表示させることができる。

    1. CS図で対象コンポーネントを選択。

    2. 画面左下のペインでベースタグを押す(デフォルトはベースタグの画面が表示されている)。

      • CS図を見ながらコンポーネントの責務を確認する、プロセスモデルを入力する方法
    3. プロセスモデルの入力もこの画面のプロセスモデルタグを押してから入力、編集できる。

      • CS図を見ながらコンポーネントの責務を確認する、プロセスモデルを入力する方法
  • プロセスモデルを表示する

    • プロセスモデルをコンポーネント内に表示するには、CS図でコンポーネントを選択し、コンテキストメニューを開き(右クリック)、「プロセスモデル区画の表示」を選択する。

      • プロセスモデルを表示する方法

      プロセスモデルをコンポーネント内に表示すると、表示する分だけコンポーネントが大きくなるので、CS図内でのコンポーネント配置を再度編集する必要がある。プロセスモデルを表示してみて見難いと思ったら、「プロセスモデル区画の表示」をオフにして戻せば良い。

      • プロセスモデルを表示する方法

      分析している最中に、一時的にプロセスモデルを表示したいと思った時だけ表示するのでも良い。UCAを識別するときにはプロセスモデルの表示がとても有用だが、分析結果をレビューするときには相互作用に注目して欲しいのでプロセスモデルの表示は目障り、というケースもある。

    Power Pointでは難しいことですが、STAMP Workbenchはモデリングツールなので、表示のオン/オフ切り替えは容易ですし、切り替えの際に修正ミスも有り得ません。利用場面に応じて柔軟に切り替えてご利用ください。

STAMP及びツールのノウハウ

  • UCAはコントロールループで考える

    UCAを識別するときには、CAとFBから成るコントロールループの単位を対象として考える。
    下図のようなCS図において、外界からのinputをトリガーとして、必ず「CA1 → CA2 → FB2 → FB1」の順番となるシステムもあります。その場合、CA1に関するUCAを識別するのに「CA1 → FB1」のコントロールループで考えるのか、「CA1 → CA2 → FB2 → FB1」のコントロールループで考えるのか、悩ましいことがあります。
    結論から言うと、UCAの識別においてはどちらでも構いません。
    但し、ハザードシナリオを抽出する際には、「CA1 → CA2 → FB2 → FB1」のコントロールループの方が考え易いかもしれません。
    UCAの識別では「CA1 → FB1」のコントロールループで考えて、ハザードシナリオの抽出では「CA1 → CA2 → FB2 → FB1」のコントロールループで考える、というのでも構いません。
    STAMP/STPAは柔軟な手法であって、このような細かなルールを強制しません。

    • UCAはコントロールループで考える 説明画像
    • UCAはコントロールループで考える 説明画像
  • UCAの識別では原因を考えない(思いついても我慢)

    UCAを識別するときには原因を考えないようにします。原因を考えながらUCAを識別しようとすると、原因を思いつかないケースではUCAが識別できなくなります。原因を先に考えたら、対象システムについての知見が有るか否かに分析結果が依存することになります。
    UCAの識別では、4つのガイドワードを参考にして、漏れの無い『観点』から論理的に識別します。STAMP/STPAにおいて、『観点』として漏れが無いことを示せることが重要で、分析の有効性を説明する際の肝となります。
    それでも原因を思いつくことはあります。それは不必要な思いつきではなく、次のステップでHCFやハザードシナリオを特定する際にとても有用な思いつきです。その貴重な思いつきは捨てることなくメモに残しておき、次のステップに役立てます。
    大事なことは、UCAを識別するときには先に原因を考えない。思いついてもその原因だけに捕らわれないように我慢することです。

  • コントロールループ図は必要?

    コントロールループ図(CL図、CLD)は必ずしも描かなくても良いです。
    コントロールループ図を描く目的は、CA・FBからなるコントロールループの中に存在し得るハザード要因(HCF)を探しやすくすることです。CS図でコンポーネントの数が多く、少し複雑な場合には着目するCAのコントロールループが見づらくなるため、対象コントロールループだけを抜き出してコントロールループ図を作成します。しかし、それほど複雑なCS図でなかったり、コントロールループを見失うことが無いCS図ならば、コントロールループ図を作成する意味がありません。

    • 下図では、Open/CloseのCAを含むコントロールループは、Open/CloseのCAとゲート開閉状態のFBから成ることが明確なのでCL図を作成するまでもない。下図のように対象CAを発出するコンポーネントを選択すると、そのコンポーネントが直接関与するCA線とFB線がハイライトされて見易くなる。

      • コントロールループ図を描かない例
  • 外界モデル

    コントロールストラクチャー図(CS図、CSD)やコントロールループ図(CL図、CLD)において、一般的にはシステム外のコンポーネントは記述しません。しかし、外界の何とのインタラクション(何からinputを受け取る/何に対してoutputを発出する)かを記述しておきたい場合もあります。その場合は、外界モデルとしてコンポーネントを記述する方法が都合が良いでしょう。
    但し、気を付けて欲しいことは、外界モデルとのCAやFBのやり取りは無いはずです。外界モデルとのやり取りはinput/outputだけになります。CAやFBが出てきたときにはシステム境界の定義が曖昧になっていると考えられるので、現在の分析対象範囲はどこまでなのかを再確認してください。

    • 下図では分析において「環境」を意識するように外界モデルとして明記。

      • 「環境」を意識するように外界モデルとして明記した例
  • STAMP用語

    STAMP解説書では次の用語を定義している。

    Accident

    事故(アクシデント)。 損失(人命の損失や負傷、経済的損害、環境汚染などを含む)をもたらす、望ましくない、計画されていない事象。

    Hazard

    ハザード。 最悪の環境条件において事故(損失)(accident (loss))につながるシステムの状態(system state)または条件の集合(set of conditions)。または潜在危険。

    1. 注釈
      Engineering a Safer World翻訳本「システム理論による安全工学」より

    これらは、一般用語としての用語定義ではなく、STAMP用語としてのローカル定義なので、一般用語としての用語定義と勘違いしないこと。英語辞書にも日本語辞書にもaccidentやアクシデントに損失という意味は含まれない(辞書によっては、特殊な例で、そういう記述もあるかもしれないが)。
    アクシデントを損失と定義するのも、ハザードをシステム状態と定義するのも、STAMPを広く適用できるようにするための工夫と考えられる(本Tips筆者の個人的な推測である)。
    例えば、「アクシデント」は、人命の損失や身体の損傷だけでなく、所有物の毀損、経済的損失、ミッションの未達なども該当する、と解説している。アクシデントを一般用語の通りに「事故」と捉えるとミッションの未達等はアクシデントに含め難いが、アクシデントを「損失」と捉えることによって、その解説が尤もらしくなる。

  • STPA手順は変化している?

    結論から言うと、STPAの手順は変わっていません。

    皆様が良く参照されるSTPA手順解説書には次の3つがあると思います。

    1. STPA Primer(2012年MIT発行)
      • 公開終了。Engineering a Safer Worldにおける解説と同じ。
    2. はじめてのSTAMP/STPA(2016年IPA発行)
    3. STPA HANDBOOK(2018年MIT発行)

    これらの解説書に記述されたSTPA手順の解説が異なるので、STPA手順が変化していると感じられるかもしれませんが、それぞれの解説範囲と表現が異なるだけで、STPA手順の基本は同じです。変わっていません。
    それぞれ理由・背景があって表現や解説範囲を変えています。その理由・背景は汲み取っていただきたいところですが、「STPA手順が変わった」などと過度に反応されることのないようお気を付けください。

    • 【一般的な安全分析手順】
      活用する安全分析手法が何か(STPAか、FMEAか、FTAか、HAZOPか等)に依らず、(1)⇒(2)⇒(3)が一般的な安全分析の手順である。

      • 一般的な安全分析手順
    • 【STPA Primer】
      純粋にSTPA固有の手順についてのみ解説している。

      • STPA Primerの手順
    • 【はじめてのSTAMP】
      対策検討のステップを含めて解説している。IPAのSTAMP向けモデリングツールSTAMP Workbenchは、この表現を用いている。

      • はじめてのSTAMPの手順
    • 【STPA Handbook】
      「STPA Primer」に記されたSTPA手順に分析目的・分析対象の整理・認識共有の重要性を解説に加えた。

      • STPA Handbookの手順

    表現と解説範囲に差異があるが、(2)のSTPA固有の分析手順に差異はない。

  • STAMPとFRAM、Safety-ⅡとSafety2.0

    IoT時代の複雑システムに対するこれからの安全分析では、システム理論に基づき、システムを俯瞰して分析する必要性が増している。また、止める安全(Safety1.0:機械による安全)から止めない安全(Safety2.0:人と機械による協調安全)への要望が増している。そして、ハザード要因から守る(Safety-Ⅰ)だけではなく、成功から学ぶ(Safety-Ⅱ)という安全戦略も注目されている。 このような背景においてシステム安全に関わる理論や手法としてSTAMP(その代表的な分析手法がSTPA)やResilience Engineering(その代表的なモデリング手法がFRAM)が提唱されている。

    STAMPとFRAM、Safety-ⅡとSafety2.0について、その違い・関係性を俯瞰するシンプルな分類および分類図をここに紹介する。

    • STAMPとFRAM、Safety-ⅡとSafety2.0の違いと関係性についての分類図
    1. 注釈
      STAMPとFRAM、Safety-ⅡとSafety2.0に関し、この4象限で示す分類と分類図は、多少乱暴ではあるが関係を俯瞰するのに役立つと思い、筆者がIPAにて作成したオリジナルの分類と分類図である。この分類および分類図も「CC BY」のライセンスのもとに使用を許諾する。
  • FRAMを応用したSTPA手法

    FRAM分析を実施するにはResilience Engineeringに関するかなり深い知識と独特な感性が要求されるが、ここではSTPAにおいて「Resilience性についても意識する」という程度のFRAM応用手法(言うなれば“FRAM風味のSTPA”)を紹介する。

    下図は、Resilience Engineeringにおける機能間の関係を図示するモデリング手法FRAMでの、機能を表現する要素である。
    I,T,C,P,R,Oの6つの側面(aspect 視点)で表現している。

    • FRAMでの機能を表現する要素

    STAMP/STPAのHCF(ハザード誘発要因)を特定する際のヒントワードにFRAMの6つの視点を取り込んだ。

    • STAMP/STPAのHCF(ハザード誘発要因)を特定する際のヒントワードにFRAMの6つの視点を取り込んだ図
    •  (1)コントロール入力や外部情報の誤り、遅れや喪失

    •  (2)不適切なコントロールアルゴリズム(作成時の欠陥、プロセスの変更、誤った修正や適用)。適切な制御判断不可

    •  (3)前提となる制御出力条件が揃わず、不整合、不完全、または不正確なプロセスモデル。不適切な操作、不適切な制御判断

    •  (4)コンポーネントの不具合。経年による変化。必要な資源不備で指示通りの動作不可

    •  (5)不適切なフィードバック、あるいはフィードバックの喪失。フィードバックのタイミングが早過ぎる/遅すぎる

    •  (6)不正確な情報の供給、または情報の欠如。測定の不正確性。フィードバックの遅れ

    •  (7)操作の遅れ

    •  (8)不適切または無効な内容のコントロールアクション、コントロールアクションの喪失。制御タイミングが不適切

    •  (9)コントロールアクションの衝突。プロセス入力の喪失または誤り

    •  (10)未確認、または範囲外の障害

    •  (11)出力能力が不足し出力できない、システムにハザードを引き起こすプロセス出力

    基のヒントワードの(1)~(11)と、FRAMの6つの視点I,T,C,P,R,Oの対応関係を以下に記す。

    • ヒントワードの(1)~(11)と、FRAMの6つの視点の対応関係
  • 制御される側(被制御コンポーネント)にもプロセスモデルがある

    STAMPで使用するモデルの基本要素は下図のように制御する側(制御コンポーネント)と制御される側(被制御コンポーネント)とそれらの間に相互作用である制御(CA)、フィードバック(FB)が有り、制御する側は制御アルゴリズムと制御内容/可否判断材料となるプロセスモデルで構成される。

    • STAMPで使うモデルの基本

    上記モデルに関するハザード誘発要因(HCF)を考える際のヒントワード

    • 上記モデルに関するハザード誘発要因(HCF)を考える際のヒントワード

    一般的には上記の通りであるが、場合によっては制御される側(被制御コンポーネント)にもプロセスモデルが存在することを意識すべきことがある。特に、人と人、組織と組織、人と組織から成るシステムにおいては、ハザード誘発要因(HCF)やハザードシナリオ(ロスシナリオとも呼ぶ)を考えるときに制御される側のプロセスモデルを意識すべきケースが少なくない。
    下図は被制御コンポーネントにもプロセスモデルを設定して拡張したSTAMPモデルの基本要素である。

    • 拡張したモデル

    上記モデルに関するハザード誘発要因(HCF)を考える際のヒントワードをここに提案するので、使えるケースがあれば活用いただきたい。

    • コントロールアクションを「出すコンポーネント」と「受けるコンポーネント」にフォーカスし、UCAの要因となり得る因子を示した図

    下図は医療における人と人のコミュニケーションエラーに着目したCS図の例で、制御される側のプロセスモデルを意識しなければ、ハザード誘発要因に気付かない可能性が高い。

    • 医療における人と人のコミュニケーションエラーに着目したCS図

    尚、この「制御される側にもプロセスモデルが有る」という考え方は、STAMPの原著Engineering a Safer Worldや、STAMP/STPA解説書のSTPA HANDBOOKには記述が無いので、STPAの派生手法、あるいはSTPAの発展手法とも言えるものだが、ハザード誘発要因を検討する際にとても役に立つ手法と思われるので、ここで紹介する。お試しいただきたい。
    また、この手法は、人対人、人対組織、組織対組織のシステムだけでなく、人とコンピューター、人と機械、コンピューターと機械などあらゆる組み合わせのシステムにおいても通ずるものと、筆者は考えている。

    1. 注釈
      制御する側と制御される側の双方のコンポーネントにプロセスモデルが存在することは、早稲田大学理工学術院 人間生活工学研究室の小松原明哲教授が提唱された。小松原先生は、どの相互作用に着目するかによって、制御する側と制御される側の主従を入れ替えたモデル(CS図)を使って分析することの有効性を述べられている。この小松原先生の提案にヒントを得て、コンポーネントの主従を入れ替えることなく、FBに対するアルゴリズムとプロセスモデルの存在を仮定し、改訂版ヒントワードを用いたハザード誘発要因(HCF)検討の手法を筆者が提案する。この提案は小松原先生が提唱される「制御される側にもプロセスモデルが存在する」ことを前提とし、小松原先生の提案の見る向きを変えたものと言える。小松原先生の提案について詳しくは「患者安全推進ジャーナル77号」p.41-46 特別寄稿を参照ください。
  • 双方向のCAが出てくる

    2つのコンポーネント間で双方向のCA(Control Action)が出てくることがある。

    結論

    異なるハザードについて同時に考えているからだと思われる。

    説明

    分析対象が同じシステムでも、分析対象のハザードが異なればCS図が 異なる場合がある。双方向のCAをひとつのCS図を用いて同時に分析するのではなく、制御する側と制御される側の主従を入れ替えたCS図も用いて、それぞれのCAを別のCS図で分析する方法がある。

    Controller(制御する側)とControlled process(制御される側)の関係は、分析者がどの関係性(相互作用)をどちらから見たいのか(何を見たいのか)によって異なる。例えば、

    • 政治が調子良い時:
      • Controller=政治家
      • Controlled process=有権者
    • 政治が調子悪い時や選挙のとき:
      • Controller=有権者
      • Controlled process=政治家

    この二つは同じシステムを扱っていても、分析対象のハザードが異なるから CAが逆方向になっている。どちらも間違いではない。
    今、分析したいハザードがどちらなのかを再度、ステークホルダーと議論して認識を共有しなおすと良い。 両方のハザードを同時に分析すると混乱する可能性がある。

    1. 脚注
      本Tipsページの「制御される側(被制御コンポーネント)にもプロセスモデルがある」も参考にして欲しい。
  • 対策検討の対象はHCFかシナリオか?

    シナリオ(ハザードシナリオ、ロスシナリオとも呼ぶ)に対して対策を検討するのか? それともHCF(ハザード誘発要因)に対して対策を検討するのか?

    HCFに対して対策を検討すべき。

    シナリオを睨みながら考えると対策を思いつき易い。また、シナリオはテストシナリオにもなるので、とても重宝する。よって、安全分析でシナリオを特定しておくことは重要である。
    但し、対策が特定のシナリオに特化したものにならないように注意すべき。特定のシナリオに特化した対策では、同じHCFの別シナリオに対応できない対策になってしまう恐れがある。
    対策検討時には、特定のシナリオのみに縛られないようにする。

    HCFに対して対策を考えたら、その対策がすべてのシナリオの対策になっていることを確認することで、対策の十分性を確認できる。

    シナリオを特定することのメリットとして次のことが考えられる。

    • 対策を思い浮かべ易い。
    • 対策の十分性を論理的に検証し易い。
    • 対象HCFが発生し得るものであることを示せる。
    • コンポーネント開発者へのアドバイスになる。
    • テストシナリオになる。
    • HCFを説明し易く、認識共有し易い。

    決して、シナリオを作成しなくても良いということではないので、勘違いしないで欲しい。HCFを特定したら、そのHCFを含むシナリオを考え、作成することは上記のようにとても有用なので、是非シナリオ作成して欲しい。

    シナリオをたくさん思いつくならば多いに越したことはない。しかし、発生する可能性のある全てのシナリオを網羅することなど不可能である。極端に言えば、シナリオを一つ特定できて、対象HCFが発生し得るものであることを示せれば良い。一方、シナリオが多ければ多いほど、多くの対策案を思いつき易く、対策の十分性も確かめ易くなるので、シナリオ作成を軽視しないこと。

  • 対策表の備考欄にシナリオをコピーする

    対策表の備考欄に、手動でHCFのシナリオをコピーしている。

    ツールへの要望

    このコピー作業を自動化するか、対策表に列を追加してシナリオが自動的に表示されると良い。
    この対策はツールが自動的にサポートすることが望ましいが現状サポートできていません。

    • 下図では、HCF表と対策表の2つのWindowを上下に並べて2画面表示しているが、対策表の備考欄にシナリオをコピーしておけば2画面表示しなくても済む。

      • HCF表と対策表の2つのWindowを上下に並べて2画面表示しているが、対策表の備考欄にシナリオをコピーしておけば2画面表示しなくても済む例
  • 対策表に【機能】【運用】【教育】など分類を記載した

    対策のところに【機能】【運用】【教育】など分類を記載し後から見やすくした。
    対策表をExcel出力して、列を増やし、それぞれの対策に【機能】【運用】【教育】などの分類を記載して、後で他の人が対策表を見たときに、次の開発ステージであるコンポーネント設計に対するコンポーネント安全制約なのか、運用で考慮するという対策なのか、設計者・運用担当者に対して教育すべき事項なのか、が分かるようにした。

    このように自社独自、自プロジェクト独自のIDや分類などを表に追加する機能はSTAMP workbenchに備わっていないので、Excelファイルに出力してからExcelで列を追加して対応した。

  • 人のコミュニケーションの対策例3wayコミュニケーション

    人のコミュニケーションの対策例として3wayコミュニケーションという方法がある。

    3wayコミュニケーションとは伝達→復唱→確認のこと。
    (「指示する」、「指示を復唱する」、「指示をもう1回繰り返して確認する」)



    伝達

    「○○してください」

    復唱

    「○○ですね?」

    確認

    「はい、○○です」

    原子力業界では一つの操作ミスが重大なトラブルに繋がったり、地域住民の信頼を損ねることに成り得るためコミュニケーションは重要な課題として捉えられており、3wayコミュニケーションが行われているそうだが、3wayコミュニケーションの伝達→復唱→確認という一連の流れは原子力業界以外でも重要な指示に対して有効と考えられる。対策例として参考にして欲しい。


注意事項

  • ダークモード(ハイコントラストモード)

    Windowsの設定で「ハイコントラストモード」を有効にして、「ハイコントラスト:黒」とすると一部の文字が読めない問題が確認されています。STAMP Workbenchは「ハイコントラストモード」での文字・図形色自動変更に対応していないため、黒地に黒文字/黒線のような設定となり文字が読めなくなる現象です。ツール -> システムプロパティの「ダイアグラムエディタ」や「新規図要素のスタイル」で背景・図形・線・文字の色を選択することをお試しください。

    1. システムプロパティ画面を起動

      • システムプロパティ画面を起動している様子
    2. 「ダイアグラムエディタ」で背景や図要素の色を変更

      • 「ダイアグラムエディタ」で背景や図要素の色を変更している様子
    3. 「新規図要素のスタイル」で文字・線色を変更

      • 「新規図要素のスタイル」で文字・線色を変更している様子
  • Excel出力時の問題

    MS Officeの性能限界への対応方法です。Excelでは既定の列幅最大値が255文字(MS Officeのバージョンに依る)となっているため、STAMP Workbenchで表の列幅(セル幅)を256文字以上にした場合、Excel出力時にエラーが発生する可能性があります。
    4K以上のディスプレイで高解像度設定し、かつ縮小表示して、STAMP Workbenchのウィンドウを全画面表示し、更にセル幅が255文字を超えるようにした場合、STAMP Workbenchの表をExcel出力したときにエラーが発生します。但し、エラー発生時にSTAMP Workbenchが保持するデータが壊れたり、失われたりすることはありません。
    Excel出力を実施する前に、STAMP Workbenchのウィンドウ幅を少し小さめに変更することで問題を回避できます。

  • バージョンアップ時の注意事項(DLページの再掲)

    既にSTAMP Workbenchをご利用の方がバージョンアップされる場合は、旧versionを一旦アンインストールまたは削除してから新versionをインストールしてください。

    実行形式インストーラーで旧versionをインストールされた方

    インストール済みの旧versionを一旦アンインストールした後に、最新の実行形式インストーラー(msiファイル)を実行してご利用ください。

    旧versionのzip版をインストールされた方

    zipを展開して利用していた旧versionのフォルダーを削除した後に、最新のMSI形式インストーラーを実行するか、最新のzipファイルを展開してご利用ください。
    旧versionをアンインストールあるいはフォルダーを削除しても、旧versionで行った設定内容は新versionに自動的に引き継がれます。

    画面表示に問題がある場合

    新versionのSTAMP Workbenchをインストールした後、一部の文字が読めなくなるなどの問題が確認されています。最新versionをインストールした際、古いversionのファイルが残っていると、この画面表示の問題が発生する場合があります。古いversionをアンインストールしたときにアンインストーラーでは古いファイルを削除しきれない場合があるためです。以前にアンインストールせずに上書きインストールしたことがある場合に、このような状態になります。この問題が発生した場合には、下記手順をお試しください。

    1. STAMP Workbenchを終了する
    2. アンインストーラーでアンインストールする
    3. 元インストールしていたstampworkbenchのフォルダーを完全に削除する(デフォルト設定では、C:\Program Files\stampworkbenchフォルダー)
    4. 再度STAMP Workbenchをインストールする

ライセンス

  • クリエイティブ・コモンズ表示4.0国際ライセンス

本Tipsページの情報はクリエイティブ・コモンズ表示4.0国際ライセンスの下で提供します。

  1. 参考

本ページのTips情報(コンテンツ)は改変、再配布、商用利用も可能で、改変版コンテンツの開示義務もありません。このライセンス適用は、本ページ・コンテンツの再利用を推進することを目的としており、他のホームページや論文、書籍への転載、改変版コンテンツの掲載も可能です。
但し、適切なクレジットを表示(© 2025 IPAのような著作権表示)し、ライセンスへのリンクを提供し、改変したらその旨(改変したかどうかを示し、それまでの改変の表示を保持)を示さなければなりません。

お問い合わせ先

デジタル基盤センター デジタルエンジニアリング部 ソフトウェアエンジニアリンググループ

  • E-mail

    ikc-stamp-workbenchアットマークipa.go.jp

更新履歴

  • 2025年4月15日

    • Tips情報追加
      • STAMP用語
      • STPA手順は変化している?
      • STAMPとFRAM、Safety-ⅡとSafety2.0
      • FRAMを応用したSTPA手法
      • 制御される側(被制御コンポーネント)にもプロセスモデルがある
      • 双方向のCAが出てくる
      • 対策検討の対象はHCFかシナリオか?
      • バージョンアップ時の注意事項(DLページの再掲)
    • ライセンス追記
    • 誤字の修正、図の微調整
    • 印刷用ファイルの更新
  • 2025年2月17日

    公開