セーフティー・ケースとは「安全性論証」を記述するための文書の集合体である。ゴールとして目指す機能に対し、どのような安全性能が求められ（ステップ1：要求、Claim）、そうした要求が満たされていると示すにはどのような要件の組み合わせが必要なのか（ステップ2：論証、Argument）を検討し、それらの要件を満たしている証拠を示す（ステップ3：証拠、Evidence）、というアプローチだ。
自動車の機能安全規格「ISO 26262」を運用するときの誤解として、「セーフティー・ケースは、機能安全活動の成果物をまとめて保存しておくことである」というものがある。これは完全に間違いというわけではないが、「要件の組み合わせ」という観点から正解ではないということもまた確かである。
なぜかというと、「まとめて保存しておく」だけでは寄せ集めにすぎないからだ。つまり、セーフティー・ケースの本質としては、全体が「構造化された議論（a structured argument）」になっていることが要求されるのである。
「寄せ集め」にすぎなかった安全策
多数の安全策を導入したパイパー・アルファはなぜ、大事故を引き起こしてしまったのか。筆者はその原因を整理するため、FTA（Fault Tree Analysis、故障の木解析）を実施した。まず、筆者が作成したパイパー・アルファのFT図を見てほしい（図3）。要素が多くて申し訳ないが、ポイントは大きく2つである。
1つは、個々の出来事（事象）をANDゲートでつながるように構成しているということである。ANDゲートとは、そこに接続されている2つまたはそれ以上の出来事が同時に起こらない限り、それより上流に出来事が波及しないことを記述する方法だ。図3の凡例では、「論理積」として記してある。
普通に起こるトラブル（基本事象）や、これ以上単純化できない出来事（非展開事象）があちこちに存在していても、ANDゲートでつながっていれば、複数の故障（フェール）が同時に起こらない限り最も上流にある要求である「従業員に多数の死傷者が出る」には到達しない。つまりは安全であると言えるのだ。
もう1つは、火災が起きてもそれが「拡大しない」対策がある、ということである。これまで放送されたテレビ番組や出版された書籍の事故説明では、図3の右下にある「ポンプAの駆動許可の不適切さ」に焦点が当たっていた。この部分をクローズアップしてみよう（図4）。
事故のきっかけは、メンテナンスのため停止中のポンプAに代わり稼働していた（1）のポンプBが故障したことだった。本来、予備ポンプが故障したのであればシステム全体の停止もやむを得ないが、ポンプ運転管理者はシステム停止を避けるため、（2）のポンプAの稼働許可を出した。ポンプの運転管理者と安全弁の管理者が縦割りになっていたことが原因とされている。
つまり、安全弁Aはメンテナンスのため分解中であり、それにつながるポンプAも駆動してはいけなかったが、ポンプAは分解されてはいなかったので運転自体はできてしまう（図5）。これで、安全弁まで石油ガスが圧送されることになってしまった。
さらにこの時、メンテナンスで外されていた弁の代わりのシール板が正規の締め付けトルクで取り付けられていれば問題はなかったはずだ。しかし、手で締めた程度では（3）弁の封止が不完全で、ガスの大量の漏洩が起こり、原因不明な着火が起こったことにより爆発火災を招くことになった。結局、（2）と（3）の同時発生がANDゲートを開けてしまった（2つの故障が同時に起こった）というわけだ。
