建築・土木におけるSTPA完全ガイド:設計・施工・運用で使える安全解析の実践法

イントロダクション — なぜ建築・土木でSTPAが重要か

近年、社会インフラや都市構造の複雑化に伴い、事故や重大な品質問題の原因が従来型の「部品故障」だけでは説明できないケースが増えています。STPA(Systems-Theoretic Process Analysis)は、MITのNancy Levesonが提唱したシステム安全工学の手法で、システム全体の制御構造と制約からハザードを導出する点に特徴があります。建築・土木分野では、設計・施工・維持管理にわたる多様なアクター(設計者、施工者、管理者、自治体、住民等)とプロセスが関わるため、STPAは従来のFTA(故障木解析)やHAZOP(危険源と運転解析)では見落とされがちな社会技術的因子やインターフェース問題を洗い出すのに有効です。

STPAの基本概念と流れ

STPAはSTAMP(Systems-Theoretic Accident Model and Processes)に基づく解析法で、主な流れは以下の通りです。

  • ステップ0:目的・損失(loss)とハザード(hazard)の定義
  • ステップ1:制御構造図の作成(コントローラ、アクチュエータ、センサー、コントロールループ)
  • ステップ2:不安全な制御動作(Unsafe Control Actions, UCA)の特定
  • ステップ3:UCAを引き起こす因果要因(制約違反や設計欠陥、人為ミス、通信/情報不足など)の分析と安全制約の導出
  • ステップ4:対策・設計変更、運用ルールの提案と検証

従来の故障中心アプローチと異なり、STPAは「制御が不適切に行われること」に着目します。建築現場での指示伝達ミス、設計意図の不一致、維持管理情報の欠落などが典型的な解析対象です。

建築・土木の事例に当てはめると — 具体的な適用場面

ここでは代表的な適用例を挙げます。

  • 橋梁の設計・施工:設計・荷重モデルの誤解、施工時の仮設支保工の管理不足、交通管理の不備などがハザードを生む経路を特定。
  • トンネル工事:湧水や地盤変状に対する監視・判定の遅れ、掘削速度と支保の不整合、換気・排水の制御ループの問題点を抽出。
  • 高層建築の施工:仮設の安全監督、資材搬入経路、クレーン運用と地上作業者間の制御信号の欠落などの不安全制御動作を特定。
  • インフラ維持管理:点検計画・情報伝達・状態基準の不備が保守遅延や誤判断を招くメカニズムを明示。

ステップごとの実務的なやり方(建築・土木向け)

実際のプロジェクトでSTPAを回す際のポイントを現場目線で整理します。

  • 目的の明確化(ステップ0):どの損失を防ぎたいか(死傷、構造損傷、サービス停止、環境汚染、社会的信用失墜等)を利害関係者と合意する。
  • 制御構造図の作成(ステップ1):単なる組織図ではなく、実際の制御信号や情報の流れ(設計図、施工指示、監視データ、アラート等)を含めて図示する。ICT(BIM/IoT)との連携点を明確にすると効果的。
  • UCAの抽出(ステップ2):制御アクションが「行われない」「誤って行われる」「不適切なタイミングで行われる」「継続/停止されるべきでない」などの観点で洗い出す。現場でのヒヤリハット事例を活用すると現実的なUCAが出やすい。
  • 因果分析と制約設定(ステップ3):人的要因、手順・契約の不備、情報伝達の欠落、技術的センサーの限界、予算・スケジュール圧力などを因果として洗い出し、具体的な安全制約(例:撤去手順を明文化、監視閾値の設定、二重確認の導入)を定義する。
  • 対策と検証(ステップ4):設計変更、作業手順、監視システム、訓練、チェックリストなど多層防御を提案し、効果をトレーサビリティで追えるようにする。BIMや施工管理システムを用いたシミュレーションで一部の対策を検証できる。

STPAと既存手法の比較・使い分け

STPAはシステム全体の制御やインターフェースから問題を見つけるのに優れますが、ハードウェアの故障確率を定量評価する場合はFTAやFMEAの方が適しています。実務では次のように使い分けるとよいでしょう。

  • 概念設計やプロジェクト初期:STPAで大域的な設計制約を導出し、リスク源の体系化を行う。
  • 詳細設計・製造段階:FMEA/FTAで部材や装置の故障確率や対策を評価。
  • 施工段階:STPAで施工工程の制御ループ(指示、監視、判断、実行)を検討し、人的・組織的ミスを低減。
  • 維持管理:STPAで点検・意思決定プロセスの脆弱性を洗い出し、予防保全ルールを設計。

実際に出る代表的なUCA(建築・土木向け例)

  • 設計変更が現場に伝わらず古い図面で施工される(制御アクションが伝達されない)
  • 荷重条件や仮設支保工の制約が誤設定され、施工中に過負荷が発生(誤ったアクションが実行される)
  • センサの故障が検知されず継続して状態確認が行われない(必須の監視が行われない)
  • 緊急停止の手順が不明瞭で、停止が遅れ被害が拡大(タイミングが不適切)

導入上の実務的課題と対策

STPA導入時のよくある課題と対応策を挙げます。

  • 課題:関係者が多くてワークショップが煩雑になる。対策:事前に役割とスコープを限定し、複数回の段階的ワークショップで絞り込む。
  • 課題:制御構造の描き方に慣れが必要。対策:BIMや現場管理フローをベースにテンプレート化する。
  • 課題:抽出される要因が多岐に渡り現場実装が難しい。対策:リスク優先度(発生可能性×影響度)で優先順位付けし、短期・中期・長期施策に分ける。
  • 課題:定量評価が難しい。対策:STPAは基本的に定性的手法なので、重要なUCAについては別途定量手法を併用する。

ツール・リソースと組織内導入のヒント

STPA自体は特別なソフトを必要としませんが、ワークショップの効率化やトレーサビリティの確保にはツールが有効です。BIMとの連携、施工管理アプリやデジタルツインを用いると、制御構造と実データの照合が可能になります。組織導入では、以下が鍵になります。

  • 経営層の支持:初期投資とワークショップ時間を正当化するためのトップダウン支援
  • 横断的なチーム:設計、施工、品質、保守、ICT担当者を含めたクロスファンクショナルチーム
  • 事例蓄積とナレッジベース:過去のUCAや対策を蓄積し、類似プロジェクトで再利用する
  • 教育とトレーニング:STPAの原理とワークショップ進行法を現場担当へ教育する

具体的な導入プロセス(提案スケジュール例)

中規模プロジェクトを想定した導入スケジュール例:

  • Week 0:目的定義、関係者選定、資料収集
  • Week 1〜2:制御構造図作成ワークショップ(半日〜1日×2)
  • Week 3:UCA抽出ワークショップ(1日)
  • Week 4:因果分析と制約定義(内部レビュー)
  • Week 5:対策立案と優先順位化、実装計画作成
  • 以降:実装、効果検証、教訓の蓄積

STPAのメリットと限界

メリットはシステム横断で根本原因に切り込める点、設計段階から運用まで一貫した安全制約が設計できる点、人的・組織的要因を体系的に扱える点です。一方で限界としては、定量評価を直接提供しないこと、ワークショップと熟練が必要であること、出力が多岐に渡るため実装への落とし込みに手間がかかることが挙げられます。したがってSTPAは単独で完結させるのではなく、FMEAやリスクマトリクス、BIM・IoTによる検証と組み合わせるのが現実的です。

まとめ — 実務への勧め

建築・土木においては、単純な故障モデルだけでは見落とされる組織・情報・制御の問題が多数存在します。STPAはそうした見落としを体系的に検出し、設計・施工・維持管理それぞれの段階で実行可能な安全制約を導出する強力な手法です。導入にあたっては、現場の実情に合わせたスコープ設定と、成果を実装に結びつけるための優先順位付け、ツール連携(BIMや工事管理システム)を検討してください。初期は小さなスコープ(重要工種・クリティカル箇所)から始め、適用範囲を広げていく段階的導入が成功の鍵です。

参考文献

Nancy Leveson, "Engineering a Safer World: Systems Thinking Applied to Safety" (MIT Press, 2011)

MIT STAMP/STPA リソース(Nancy Leveson/MIT — sunnyday.mit.edu)

ISO 31000 — リスクマネジメントの国際規格(ISO)

ISO 45001 — 労働安全衛生マネジメントシステム(ISO)