RAS AI半導体ファブの統合防災STPAを再検証 — ロスシナリオ6件を26件へ、半日で
VisualPro Tech Brief
網羅性は記憶に頼るべきではない
半導体ファブの統合防災STPAを再検証 — ロスシナリオ6件を26件へ、半日で
半導体ファブ安全分析 | STPAとMCPの実践 | プロジェクトレポート
STPAMCP連携トレーサビリティDBClassカバレッジ半導体ファブ
01概要（TL;DR）— 半日で何が変わったか
半導体ファブの火災・ガス・設備を対象とした統合防災コントロールストラクチャについて、既存のSTPA分析を再検証しました。防災センターのオペレータ（EHS/FMS Operator）から、中央のFMS/GMS統合監視サーバー、現場の安全インターロックPLCを経て、クリーンルーム空調・スクラバー排気、OHT搬送物流、特殊ガス・ケミカル供給バルブという3つの設備群に至るまで、コントロールアクションとフィードバックが図として定義された構造です。
重要だったのは作業方法です。VisualPro STPAのMCP（Model Context Protocol）連携上で、AIエージェントがすべての照会・登録・修正を行い、人が担ったのは意味の判断のみでした。GUI操作はゼロです。
| 累積指標 | 初回（原本） | 最終（Rev 2.1） |
|---|---|---|
| ロスシナリオ | 6件（100％故障ベース） | 26件（故障6件／非故障20件） |
| UCA | 8件 | 15件 |
| ハザード／システム制約 | 5 / 5 | 6 / 6 |
| トレースチェーンが途切れたハザード | 1件（H-5） | 0件 |
再検証の中心的な発見は、新しいシナリオではありませんでした。既存の分析がどこに偏っていたかです。元の6件のシナリオはすべて故障ベースで、設計判断と法規上の義務を扱うResponsibility系統（Class 1、C1～C4）が丸ごと空白でした。その後の7件の発見は、すべてこの空白から逆方向に導き出されたものです。
まだ何を分析すべきかをツールが教えてくれる — だから網羅性は、もはや分析者の勤勉さに左右されません。
[図1] VisualPro Control Structure — 半導体ファブの統合防災コントロールストラクチャ（コントロールアクションは赤、フィードバックは青）。この図の矢印一つひとつが、15件のUCAと26件のロスシナリオが結び付く箇所です。画面のラベルは、プロジェクトデータと同じく韓国語です。
02何がそれを可能にしたのか — 3つの要素
1MCP連携 — 自然言語の指示がそのままSTPA作業になる自動化
VisualProはMCPサーバーを内蔵しているため、AIエージェントがツールのデータモデルに直接アクセスできます。今回の作業で人が入力したのは「整合性を確認して」「これらのシナリオを登録して」といった自然言語だけで、実際の照会・登録・修正は15種類のSTPAエンティティ（loss、hazard、uca、loss_scenario、5種類のリレーションなど）に対するAPIコマンドとして実行されました。
・このセッションでエージェントが登録したデータ：ハザード1件、システム制約1件、UCA 7件、ロスシナリオ20件、リレーションリンク約50件
・すべてのコマンドはdescribe（仕様の取得）→ execute（実行）の2段階で、エージェントが自らスキーマを把握するため、誤入力なしで登録できます：バッチ登録エラーはゼロ
・UCA ID（UCA-N-9、UCA-P-13）とシナリオ番号は種別ごとのルールで自動採番 — 手作業による採番は一切不要
・このセッションでエージェントが登録したデータ：ハザード1件、システム制約1件、UCA 7件、ロスシナリオ20件、リレーションリンク約50件
・すべてのコマンドはdescribe（仕様の取得）→ execute（実行）の2段階で、エージェントが自らスキーマを把握するため、誤入力なしで登録できます：バッチ登録エラーはゼロ
・UCA ID（UCA-N-9、UCA-P-13）とシナリオ番号は種別ごとのルールで自動採番 — 手作業による採番は一切不要
2トレーサビリティデータベース — 整合性監査が「照会」になる監査可能性
VisualProはSTPAデータを、Loss → Hazard → UCA → Loss Scenario → Countermeasureの双方向リレーションとして保存します。そのため「チェーンが途切れているのはどこか」という監査上の問いは、手作業による突き合わせではなく、数回のリレーション照会で答えが出ます。同じ仕組みでLoss↔Hazardの双方向リンク20件すべてを網羅的に検証しました — 文書ベースの分析では通常まったく行われない確認です。
3Class原型カバレッジ — 空白が数値になる網羅性
すべてのシナリオがClassタグをデータとして持っているため、「66の原型ケースのうちどこが空白か」がすぐにマトリクスとして得られます。スプレッドシートベースの作業では、シナリオが増えるほど採番・紐付け・分類が崩れ、カバレッジは分析者の記憶頼みになります。データモデル上であれば、シナリオが26件になってもトレーサビリティ・ID・リレーションが保たれ、空白・断絶・偏りが照会によって定量化されます。
03照会だけで見つかった3つの構造的欠陥
作業の開始時点で、リレーション照会だけで見つかったものです。いずれも「分析が間違っている」ではなく、3件とも「分析が空白である」という種類の欠陥です。
| 発見された欠陥 | 発見方法 | 対応 |
|---|---|---|
| ハザードH-5（非常用電源喪失）のUCA・シナリオが0件 — トレースが完全に断絶 | ハザードごとに1回のリレーション照会 | LS-11とLS-23の登録によりチェーンを復元 |
| UCA-3とUCA-7にロスシナリオがない | UCA↔シナリオの突き合わせ | 追加シナリオの作成対象として特定 |
| コントロールアクション「非常用手動遮断」（オペレータ）にUCAがない | コントロールアクション↔UCAのマッピング | UCA-9とUCA-10の追加により解消 |
[図2] VisualPro Trace View — Loss → Hazard → UCA → Loss Scenario → Countermeasureのチェーン。このチェーン内のLS-13は今回の作業中にAIエージェントが登録したもので、登録と同時にトレースチェーンに加わり、既存のレコードと同様に照会・監査の対象となりました。画面のラベルは、プロジェクトデータと同じく韓国語です。
04空白が教えてくれた7つの事故経路
いずれもすべての構成部品が正常で、すべての試験に合格していても成立します。各項目は、文書を確認すれば約1時間で答えられる監査質問の形で示しており、「いいえ」となった質問は、そのまま現実の事故経路です。
| # | 発見 | 見落とされる理由 | Class |
|---|---|---|---|
| 14 | 火災モード vs ガスモード — 法規同士が衝突する | 消防設備とガス安全設備は法規も設計業者も図面も異なり、相互レビューが行われることがない | 1-C4 |
| 15 | 解除されていないForceタグ — 試運転の亡霊 | Force状態は診断画面の奥深くにしか表示されず、ロジックレビューはソースを読むだけで、出力の強制上書きは確認しない | 1-C23 |
| 16 | 「信号なし」を正常と読み取る初期設定 | 設計レビューは「値が間違っていたら」は検討しても、「値が届かないときの方針」はほとんど検討しない | 1-C20 |
| 17 | ファブ改造後の古いマッピング — MOCの盲点 | 値は正しいため、どの自己診断でも検出できない。間違っているのはデータではなく座標系である | 2-C7 |
| 18 | 復電の罠 — 停電よりも再通電のほうが危険 | 停電訓練やUPS試験は電源が落ちる瞬間を対象とする。設備が復帰する順序は試験されない | 3-C7 |
| 19 | 共通原因としての計装空気 | すべての部品は正常で、単体試験もすべて合格。「全ゾーン同時作動」はどの試験手順にも含まれていない | 3-C11 |
| 20 | スケジュールの裏切り — カレンダーは非常事態を知らない | スケジューラが制御要素として扱われないため、インターロックマトリクスに登場しない | 4-C11 |
事例1 — 火災モード vs ガスモード（A-Ha #14）
火災受信機からの火災信号は、煙の拡散を防ぐため、消防法に基づいてHVACの停止と防火ダンパーの閉鎖を義務付けます。しかしガス火災では、排気を止めればガスが滞留し、二次爆発の危険が生じます。消防法とガス安全が同じダンパーに正反対の動作を求めている — 法規レベルの衝突です。
1ガス配管のフランジからSiH4（シラン）が微量に漏えいし、シランは空気に触れると自然発火するため、局所的な火災も同時に発生します。
2火災受信機が火災を検知し、消防法に基づくインターロックがHVAC停止と防火ダンパー閉鎖を自動的に実行します。
3同じ瞬間、ガス検知システムが漏えいを検知します — 本来なら安全PLCが非常排気を最大にするよう指令すべき状況です。
4しかし、排気経路上の防火ダンパーは、すでに火災ロジックによって閉じられています。PLCの排気指令は物理的に無効です。
5未燃焼のガスが屋内に滞留・濃縮し、二次爆発の危険（H-1）が高まります — 2つの安全ロジックがそれぞれ「正しく」動作した結果です。
監査質問 火災信号とガス信号が同時に入ったとき、ダンパーと排気の優先順位は設計文書に明記されていますか？
事例2 — 共通原因としての計装空気（A-Ha #19）
非常時に全ゾーンの空気圧駆動バルブとダンパーが一斉に作動すると、計装空気（IA）ヘッダーの圧力が低下し、一部の遮断バルブが所定時間内に閉じられなくなります。定期試験ではバルブを1つずつ作動させるため、この現象が検出されることはありません。
1定期的なバルブ機能試験は、1回に1つずつ行われます。IAの需要には常に余裕があり、試験は毎回合格します。
2実際の非常事態が発生します — 大規模な漏えいにより、全ゾーンのインターロックが一斉に作動します。
3数十個の空気圧駆動バルブとダンパーが同時に作動を始め、IAヘッダーの圧力が急激に低下します。
4空気が不足した一部のバルブは駆動トルクが足りず、所定時間内に全閉できません（一部が開いたまま残ります）。
5システムは「遮断完了」と集計しますが、一部が開いたままのラインからガスが流れ続けます（H-1）。
監査質問 全ゾーン同時作動シナリオにおけるIA需要量は、計算または試験によって実証されたことがありますか？
053段階のワークフローと監査チェックリスト
7件の発見は、ブレインストーミングから生まれたのではありません。データ上で実行された手順から生まれたものです。各ステップでツールが何を担ったかこそが、この方法を再現可能にしています。
| ステップ | 専門家の役割 | VisualProの役割 |
|---|---|---|
| 1. タグ付け監査 | ケースの原文と各シナリオの因果構造を、意味の観点から照合 | 26件のシナリオ全体をタグ・リンク付きで即座に照会。誤ったタグ付け（LS-8）の修正は1回の保存で反映 |
| 2. カバレッジマトリクス | 空白のうち、ファブで実際に起こり得る系統を選定 | Classタグのデータから66ケース × 26シナリオのマッピングを自動算出 |
| 3. 逆方向の導出と登録 | %slots%にドメインのエンティティを代入し、監査質問を設計 | 新規UCA・シナリオ・リレーションを一括登録。IDを自動採番し、トレーサビリティを即時にリンク |
ポイント 専門家の時間は、すべて意味の判断に充てられました。照会、突き合わせの準備、登録、採番がツールに移ったことで、同じ半日のうちに分析は6シナリオの体系から26シナリオの体系へと進みました。
成果物がそのまま対策リスト — 設計監査チェックリスト
| # | 監査質問 | 確認する文書 | 関連 |
|---|---|---|---|
| 1 | 火災・ガスの同時信号時のダンパー優先順位は文書化されているか？ | 消防インターロック設計書、インターロックマトリクス | LS-20 |
| 2 | PLCのForceタグの常時監視と、交代時の引き継ぎチェックはあるか？ | PLC運用手順書、交代日誌 | LS-26 |
| 3 | 通信タイムアウト時のタグ品質ポリシーは「警報」になっているか？ | PLCロジック標準、タグデータベース | LS-21 |
| 4 | 設備移設のMOCに、防災マッピングの更新が含まれているか？ | MOC手順書、マッピングテーブル履歴 | LS-22 |
| 5 | 復電シーケンスは文書化され、試験されているか？ | 復電手順書、再起動試験記録 | LS-23 |
| 6 | 全ゾーン同時作動時のIA需要量は計算・実証されているか？ | 計装空気容量計算書 | LS-24 |
| 7 | スケジュール動作に、非常状態での保留条件はあるか？ | 自動試験スケジュール設定、インターロック一覧 | LS-25 |
06機能と効果
本プロジェクトで確認された効果を、それをもたらした機能と対応付けて示します。数値はすべて今回のセッションでの実測値です。
| VisualProの機能 | 今回の作業での効果 |
|---|---|
| MCPサーバー（AIエージェント連携） | 自然言語からSTPAの照会・登録・修正へ。GUI操作ゼロで作業全体を半日で完了 |
| LossからCountermeasureまでのトレーサビリティモデル | 3つの構造的欠陥（H-5のトレース断絶、コントロールアクションのUCA欠落）を照会だけで発見 |
| 双方向リレーションデータ | Loss↔Hazardの20件の関係すべてを網羅的に相互検証 — 文書分析では通常省略される確認 |
| UCA種別体系（N/P/T/S）と自動ID | UCAが15件に増えてもIDと種別の一貫性を維持。手作業による採番ゼロ |
| UCAに紐付かないシナリオのサポート | プロセスの自律的挙動（Class 4）や伝達失敗（Class 3）の系統も正式なデータとして扱える |
| describe/executeの2段階API | エージェントが登録前にスキーマを確認 — 20件のバッチ登録でエラーゼロ |
07よくある質問（FAQ）
Q1VisualProのMCP連携とは何ですか？
VisualProはMCP（Model Context Protocol）サーバーを内蔵しており、ClaudeなどのAIエージェントがSTPA、FMEA、FTA、HARA、TARAのデータモデルに直接アクセスできます。ユーザーは自然言語で指示し、エージェントがツールのAPIコマンドを通じて照会・登録・修正を行います。今回の作業は、すべてこの方法で進められました。
Q2AIが登録したデータは信頼できますか？
2つの仕組みがあります。第一に、すべてのコマンドはdescribeの段階で必須フィールドとルールを返すため、エージェントはスキーマに合わないデータを送信できません — このセッションでのバッチ登録エラーはゼロでした。第二に、登録後に再照会して結果を検証することが標準手順です。意味的な妥当性は、引き続きタグ付け監査を通じて専門家が担います。
Q3スプレッドシートベースのSTPAとの決定的な違いは何ですか？
トレーサビリティがデータとして存在することです。「シナリオのないハザードはどれか」「未分析のコントロールアクションはどれか」といった網羅性に関する問いに、照会で答えられます。今回の作業でH-5のトレース断絶とResponsibility系統の空白を発見したことが、その実証です。文書の場合、同じ問いに答えるには手作業による網羅的な突き合わせが必要です。
Q4このワークフローを導入すると、何が改善しますか？
専門家の時間が、照会・登録・採番・リンクの維持といった機械的な作業から、意味の判断 — シナリオが妥当か、設計が成り立つか — へと移ります。本事例では、シナリオ体系を6件から26件へ拡張し、整合性監査を完了するまでにかかった時間は半日でした。
Q5STPA以外の分析にも同じアプローチを使えますか？
はい。VisualPro MCPサーバーはSTPAに加え、FMEA、FTA（カットセットとPMHF計算を含む）、HARA（現代自動車規格を含む）、TARAのコマンドも提供しているため、同じ自然言語、照会と登録、検証のワークフローを安全分析全般に適用できます。
08今すぐ始める（Next Step）
STPAの難しさは、手法を習得することではありません。分析がどこまで進み、何がまだ空白なのかを把握することにあります。文書で管理すれば、その問いの答えは分析者の記憶の中にしかありません。データとして管理すれば、答えは照会結果として返ってきます。半導体、自動車、防衛、航空、ロボットの分野で実績のあるVisualProから始め、網羅性を誰かの勤勉さではなく、構造の特性にしましょう。
網羅性を、誰かの勤勉さではなく構造の特性に — VisualPro STPA。
本ブリーフは、VWAYソリューション事業部がVisualPro STPAのMCP連携上でAIエージェントと協働して実施した再検証をまとめたものです。累積データセット（ハザード6件、UCA 15件、ロスシナリオ26件）は、Semicon.vsaプロジェクトでトレーサビリティとともに確認できます。