故障の一覧から、安全だと言える根拠へ

架空事例：青葉機材が、点検状況を確認できない機材の貸出しを防ぐ設計を検討する。原因、操作、数値、論証は独自の作例であり、実際の事故分析や安全認証を示すものではない。情報システムが出庫承認を制御する範囲と、現物を扱う人の作業を区別する。

接続できなければ、安全なのか

点検DBへの接続が失敗した。画面にはエラーが出て、出庫承認ボタンは押せない。開発担当者は、この試験で危険な機材の貸出しを防げたと考えた。

倉庫担当者は別のことを気にしていた。前日に印刷した出庫票が残っている。それを使えば、画面を開かずに機材を渡せる。

試験が誤っていたわけではない。確認した範囲が、言おうとしている結論より狭かったのである。

「接続失敗時に画面で新しい承認を作れない」と、「点検が確認できない機材が現場から出ない」では、必要な根拠が違う。前者は一つの機能の振る舞いを確かめる。後者には、既存の出庫票、現場の確認、例外時の権限まで関わる。シラバスのシステム方式設計がハードウェア、ソフトウェアだけでなく手作業への要件の割当ても扱う理由を、この場面から理解できる。1

部品がどう壊れるかから、仕事への影響をたどる

点検DBが完全に止まる場合だけでなく、応答が遅れる、古い記録を返す、別の機材の記録と取り違える場合を並べてみる。同じ「点検DBの不具合」でも、利用者が遭遇する結果は違う。

応答がないなら、情報不足に気付ける。古い「点検済み」を正しい情報だと思って受け取る場合は、処理が成功したように見える。接続監視だけでは、この違いを捉えられない。

FMEA（故障モード影響解析）は、構成要素や機能の故障モードを出発点に、その影響をたどる考え方である。NASAの公開資料も、FMEAをボトムアップの分析として説明している。2 原教材第13章の定義を、本事例では次のような小さな分析へ展開する。

対象と故障モード	直近の影響	業務上の影響	対策として検討すること
点検DBが応答しない	有効な点検結果を取得できない	出庫承認が保留になる	未確認を成功に変換せず、保留の処理を用意する
古い点検結果を返す	現在も点検済みと誤認する	点検条件を満たさない承認が生まれる	対象機材、有効期間、参照時点を確認する
通知先が誤っている	別の倉庫へ出庫指示が届く	対象外の機材を準備する	機材・拠点・指示の対応を確認する

これは標準帳票の転載ではなく、分析の方向を示すための作例である。原因と故障モードも同じではない。設定誤りという原因から誤った通知先へ送る故障モードが生じ、その先に誤出庫の影響がある。一つの欄へすべてを「人為ミス」と書けば、どこを直すべきか見えなくなる。

起こしてはならない結果から、逆にたどる

倉庫側の懸念から始めるなら、問いは「点検状況を確認できない機材が出庫されるのは、どの条件が重なったときか」になる。望ましくない結果を頂上事象として、原因の組合せを分解するのがFTA（故障の木解析）の方向である。1

説明を単純にするため、Rを「点検条件を満たさない機材への出庫要求がある」、Dを「システム上の承認制御が働かない」、Eを「画面外の手順で承認制御を迂回する」と置く。本事例の限定したモデルでは、頂上事象Tを次のように表す。

T ＝ R AND (D OR E)

点検条件を満たさない機材への要求があり、そのうえで、システムの制御が働かないか、制御を通らない手順が使われる。ANDは両方が必要な組合せ、ORはどちらかで成立する組合せを表す。NASAのFault Tree Compilerに関する公開抄録でも、こうした論理ゲートを用いた頂上事象の評価が扱われている。3

もちろん、現実の原因がR、D、Eだけだと証明されたわけではない。対象の運用や境界を変えれば、木も変える必要がある。図が完成したことと、原因を取りこぼしていないことは別の問いになる。

一つの条件を、二つの確率として数えない

論理式を展開すると、T ＝ (R AND D) OR (R AND E) となる。二つの枝に分かれたが、Rは同じ事象である。

ここで左右の枝を独立だと思って計算すると誤る。両方にRが含まれ、Rが起こらなければ両枝とも成立しないからだ。図の線が分かれたことは、独立性の根拠にならない。

単純化した一回の機会について、R、D、Eそのものは互いに独立で、発生確率をそれぞれ0.1、0.02、0.03と仮定する。このとき、P(T)＝0.1×(0.02＋0.03−0.02×0.03)＝0.00494、すなわち0.494%になる。これは仮定したモデルの演算結果であり、青葉機材や一般のシステムの事故確率ではない。

重複するRを共通条件として扱えば、二重に数える部分が見える。故障の木は絵を描く道具であると同時に、論理の重複や、根拠のない独立性を見つける道具にもなる。

対策を置く場所で、残る危険が変わる

システムの承認制御を直せば、Dに対応できる。しかしEが残るなら、出庫票による迂回は防げない。画面へ警告を一つ追加するだけでは、画面を使わない経路へ届かない。

青葉機材は、紙の出庫票を廃止すれば解決するかを検討した。平常時には単純になる。だが、通信断のときにどの依頼を保留し、誰が顧客へ連絡するかが決まっていなければ、現場で別の紙が作られるかもしれない。形式的に旧手段を禁止するだけでは、迂回を必要とする業務上の事情が残る。

本作例では、出庫票の機材番号と承認状態を出庫直前に確認する手順、確認できない場合の保留、例外承認を行える役割を組み合わせる。すべてをシステムに押し付けるのではなく、システムで強制する範囲と人が判断する範囲を明示する。その代わり、人の判断を含む部分については、教育や手順の実行可能性を別途確かめなければならない。

対策の追加は、責任が消えることではない。新しい依存や作業が生まれた場所を設計へ戻すことである。

点数を掛ければ、優先順位は決まるか

発生しやすさ、影響の大きさ、検出しにくさに点数を付け、積を使って検討対象を並べる方法がある。ところが、積が同じでも、重大な結果を招く低頻度の故障と、軽微だが頻繁な故障は同じ判断にはならない。

点数が順序を表す尺度であるなら、8点の影響が4点の二倍の損失額を意味するとは限らない。掛算の結果を、そのまま期待損失額や事故確率と呼ぶこともできない。原教材第13章の故障分析と、第23章の確率・損失の計算を、同じ「リスクの数字」として混ぜない。1

本事例では、少なくとも「重大な結果を許容できるか」という判断を総合点だけで隠さない。点数の高いものから順に直すことに加え、特定の重大性に対して外せない条件があるかを確認する。尺度と優先付けの規則は、採用する方法や組織の合意によって定める。

安全だという主張を、証拠へつなぐ

「対策済み」と書かれた一覧ができた。だが、一覧には、その対策が正しく動いたことを示す資料が付いていなかった。

アシュアランスケースは、主張、論証、証拠を関係付け、なぜある性質が成り立つと判断するのかを説明する。SEIの解説は、試験結果があっても、それが主張をどう支えるかの論証がなければ十分ではなく、論証だけでも証拠がなければ不足すると説明している。4

青葉機材の限定した主張を「指定した運用条件の下で、点検を確認できない機材の新規出庫承認をシステムが発行しない」とする。未確認を承認済みに変換しない設計、承認APIの分岐と権限の確認、接続断や期限切れを与えた試験結果を、その主張へ結ぶ。現物が絶対に出庫されないという広い主張には、これだけでは足りないことも併記する。

証拠には対象版と実行条件が要る。前版の試験で問題がなかったことを、新版の承認ロジックへ説明なく移すことはできない。反対に、変更の影響を分析して証拠を再利用できると説明できれば、何でも最初から試し直す必要はない。SEIのAssurance Cases Overviewも、証拠が現在の版に対応すること、または変更によって結果が変わらないことの説明を重視している。5

疑いを残したまま、扱いを決める

出庫直前の確認を確実に実行できるか。保留中の依頼が集中して、担当者が手順を省略しないか。こうした疑いは、主張を弱く見せる邪魔な注記ではない。どの証拠が不足しているかを示す入口になる。

本作例では、現場の処理量を想定した手順確認を行い、保留が一定数を超えた場合の応援体制も検討する。ただし、ここに書いた手順が現実の安全性を認証するわけではない。成立条件、確認結果、残った不確実性を分けて説明する練習である。

FMEAは故障から影響を広げ、FTAは結果から原因の組合せを絞る。アシュアランスケースは、その分析から選んだ対策と証拠を、主張へ戻してつなぐ。三つを一枚の名称一覧として覚えるより、分析の途中で何がまだ分からないかに注目すると、使い分けが定まる。

知識を答案へ戻す

午前Ⅱ。 FMEAとFTAは分析の起点を区別する。ANDとORは成立条件の違いであり、独立性は別の仮定である。主張・論証・証拠の組合せは、対策や試験資料を集めただけの一覧とは異なる。

午後Ⅰ。 障害が起きる部品だけでなく、その結果を受け取る業務、迂回手順、共通原因を本文から読む。設問が求める結果に届く対策かを確認し、問題文にない故障確率を作って補わない。

午後Ⅱ。 想定した望ましくない結果、特定した原因、採用した対策、確かめた証拠を因果で説明する。適用範囲や残存リスクを示し、自分が実施していない検証を経験として記述しない。

立ち止まって考える：接続断の試験に合格した記録だけで、危険な機材は貸し出されないと言えるか

言えるのは、その試験条件で観測した機能の振る舞いまでである。古い情報を正常に取得する場合、別APIからの承認、既存の出庫票による迂回などが主張の範囲へ入るなら、それらに対応する設計と根拠も必要になる。主張を試験の範囲へ狭めるか、広い主張に必要な証拠を追加する。

出典と照合範囲

[1] コンプリートテキスト第10・13・23章、IPA「SAシラバス Ver.5.2」4-14、5-5、8-1、8-4、11-7、13-2：故障分析、保証、品質評価を出発点とした。表、論理式、確率、対策と答案への接続は独自の説明である。公式シラバス

[2] NASA/SP-2000-6110, Failure Modes and Effects Analysis (FMEA): A Bibliography：NTRSの公開抄録にあるボトムアップの分析という位置付けを照合した。収録された465文献の本文を調査したという意味ではない。NASA公開記録

[3] NASA-TP-2915, The Fault Tree Compiler (FTC): Program and mathematics：公開抄録の論理ゲートと頂上事象評価の説明を参照。本文の三変数モデルは独自に作成し、全8組の真理値と数値演算を照合した。NASA公開記録

[4] SEI, Assurance Cases and Confidence（2013）：主張、論証、証拠の関係を参照。認証制度の現在の適用状況については主張していない。公開解説

[5] SEI, Assurance Cases Overview（2013）：公開概要の、現在のソフトウェア版に対応する証拠と変更影響の説明を参照。公開概要