ヒューマンエラーを構造で理解する

1. 出発点：「ヒューマンエラー」を原因にしない

ヒューマンエラーという語は、英語の human error として成立しており、事故や障害の説明で広く使われる。一方で、この語を「原因ラベル」として置いた瞬間に、分析が止まることが多い。ここでいう「止まる」とは、観測された事実の列挙が終点になり、次に行うべき因果の分解や設計変更の検討が省略される状態を指す。結果として、事故の説明が「人がミスした」で完了し、再発防止が「注意する」「教育する」「気をつける」に縮退する。これは実務における失敗であり、なぜなら人間の注意力は有限で、同じ種類のミスが別の人・別の場面・別のタイミングで再現されるからである。

ここで押さえるべき点は、ミスという現象を否定することではない。観測されたミスは実在し、ログや記録や証言として残る。しかし「ミスが起きた」という記述は、原因の説明ではなく、原因へ至る入口である。実務で必要なのは、観測点としてのミスを手がかりにして、ミスが事故や障害に接続された経路を、構造・手順・設計・運用条件の言葉で再構成し、介入可能な形に分解することである。言い換えると、ヒューマンエラーは結論ではなく、設計変更を開始するための診断所見として扱うべきである。

この問題意識は、航空・医療・原子力の安全工学で共有され、層状防御が破られる条件を説明する枠組みが提案されてきた。代表例がスイスチーズモデルであり、複数の防御層の穴が整列したときに事故が貫通するという直観を与える[1]。同モデルは学術的にも多分野に展開され、レビュー論文などで適用例が整理されている[2]。また、国際機関の教材でも層状防御と人的要因の関係が説明されている[3]。

1.1 「原因ラベル化」が生む実務上の損失

「ヒューマンエラー」を原因ラベルとして置くと、再発防止の設計が困難になる。理由は単純で、ラベルは因果の粒度を粗くし、介入点を消してしまうからである。例えば「入力ミス」と書いた時点で、本来は別々に検討すべき要素、すなわち入力画面の設計、必須項目の妥当性、単位や桁の制約、確認フロー、二重入力の要否、監視と検知の遅れ、作業時間帯、割り込み頻度、教育と訓練の設計、権限と責任分界などが、ひとまとめに曖昧化される。曖昧化されたままでは、対策が「注意する」に戻り、同型の失敗が繰り返される。

一方で、ヒューマンエラーを「観測点の記述」に留め、そこから手前へ戻る姿勢を採用すると、再発防止は構造変更の設計に移行できる。具体的には、「どの防御層があったか」「それぞれの層がなぜその場面で機能しなかったか」「機能しない状態が再発する条件は何か」を順に列挙し、列挙した条件に対して「除去」「弱化」「迂回」「検知」「隔離」「復旧」のいずれで介入するかを選べるようになる。ここまで落とすと、個人の注意力ではなく、システムの設計変数として対策を議論できる。

1.2 最低限の整理：「観測」から「設計」へ落とすための対比表

観測の書き方	その書き方の限界	設計に落とす書き方	設計に落とせた時に得られるもの
原因はヒューマンエラーだった。	介入点が消え、再発防止が注意喚起に縮退する。	どの防御層が存在し、どの層がどの条件で機能しなかったかを列挙する。	構造・手順・設計のどこを変えるべきかが候補として抽出される。
オペレーターが操作を誤った。	誰が誤ったかだけが残り、誤りが成立する条件が不明のままになる。	誤操作が成立した前提条件として、識別性・制約・確認・権限・時間圧・割り込みを分解する。	注意依存の工程を減らし、誤操作が通らない制約や検知を設計できる。
確認不足だった。	確認が不足する理由と、確認を成立させるコストが説明されない。	確認が省略される圧力要因と、確認を強制または支援する仕組みの不足を記述する。	確認を「個人の善意」から「工程の性質」に移し、再現性のある運用にできる。
手順を守らなかった。	手順自体の妥当性と、手順が現実に適合しない条件が無視される。	手順が現実に適合しない局面と、例外運用を常態化させる構造要因を特定する。	手順の改訂、例外の明文化、制約の設計により、逸脱が必要ない状態へ寄せられる。

1.3 本節の結論

本節で確定したいのは、ヒューマンエラーという語を禁止することではなく、用法を限定することである。ヒューマンエラーは「観測点の短い要約」としては有用だが、「原因の結論」として置くと設計が停止する。したがって、報告書やポストモーテムでは、ヒューマンエラーを結論欄に単独で置かず、必ず防御層と条件の列挙に接続し、介入可能な設計変数に分解してから対策を記述する、という運用規律が必要になる。

2. 本稿の前提：ヒューマンエラーは「構造の振動」が行動として観測されたもの

本稿は、次の定義を前提にする。ヒューマンエラーとは「構造の振動が人間の行動として観測されたもの」である。この定義は、人間を責めないための道徳ではなく、原因同定のための技術的態度である。すなわち、人間の行動は最終出力であり、その手前にある構造と揺らぎを解析しない限り、原因に到達しない。ここで重要なのは、観測された行動を否定しない点である。入力ミスや誤操作は実在するが、それは原因の終点ではなく、原因へ到達するための入口として扱う。

この前提を採用すると、「ミスをした人」を中心に説明する文章が、構造説明へと置き換わる。人は現場で瞬間的に判断し、限られた情報で操作し、割り込みや時間圧の中でタスクを成立させる。そのとき人間の行動は、個人の性格というより、環境が要求する調整の結果として現れる。つまり、ヒューマンエラーという語が指しているのは「個人の欠陥」ではなく、「構造が要求した調整が破綻した局面」である。この読み替えにより、再発防止は人への説教ではなく、構造の設計変更として議論できるようになる。

ここでいう「構造」とは、個人の性格ではなく、環境・制度・設計・役割分担・権限・手順・インターフェース・評価制度・時間制約などからなる社会技術システムである。現場の行動は、これらの要素が作る制約条件の中で発生する。例えば、権限が過剰なら危険操作が通りやすく、権限が不足なら正しい復旧が遅れやすい。手順が複雑なら省略が起きやすく、手順が粗いなら判断のばらつきが増える。インターフェースの識別性が低ければ取り違えが増え、識別性が高ければ注意依存が減る。つまり、行動の発生確率は構造のパラメータとして設計されている。

「振動」とは、これらの要素が日々の運用の中で生む偏りと揺らぎであり、例えば時間圧、情報の遅延、タスクの割り込み、確認の省略、役割境界の曖昧化、例外処理の常態化などとして現れる。ここでの振動は、誰かがサボったという意味ではなく、現実の運用が必ず持つ変動である。人員は日によって違い、負荷は時間帯で変わり、依頼は割り込みで入る。トラブル時には普段より情報が欠け、判断は速く求められ、作業は並列化される。こうした変動が同時に発生すると、構造は局所的に歪み、揺らぎが増幅する。その増幅が一定点を超えたとき、調整が破綻し、誤操作や見落としが発生する。

振動は通常は不可視で、可視化されるのは「ミス」という形で露出した瞬間である。つまり、われわれがログや記録で見ているのは、揺らぎの全体ではなく、揺らぎが最も弱い部分から破れた結果としての行動である。したがってミスは原因ではなく、構造の状態を示す観測点になる。ここから直ちに、分析の焦点は「誰がやったか」ではなく、「どの揺らぎが、どの防御層を弱め、どの地点で行動として露出したか」へ移る。この移動ができると、再発防止は教育や注意喚起ではなく、権限・手順・設計・インターフェース・監視・責任分界などの変更として設計可能になる。

2.1 用語の最低限の定義

用語	本稿での意味	観測できるもの	典型例
構造	行動の選択肢とコストを決める社会技術システムの条件集合。	設計、手順、権限、役割、UI、評価制度、時間制約の仕様や運用。	production と staging の識別手段、権限設計、確認フロー、オンコール体制。
振動	構造が運用の変動で生む偏りと揺らぎであり、局所的な歪みとして累積する。	負荷変動、割り込み、情報欠損、例外増加、手順省略、判断の遅れや焦り。	締切直前の負荷集中、障害時の情報不足、同時多発タスクでの確認省略。
観測点	振動が人間の行動として露出し、ログや記録として残る端点。	誤操作、入力ミス、見落とし、誤判断、復旧失敗、アラート無視など。	誤ったコマンド実行、環境取り違え、監視の見落とし、手順逸脱。

2.2 本前提が要求する分析規律

この前提に立つなら、少なくとも次の規律が必要になる。第一に、ヒューマンエラーを結論として書かない。書くとしても観測点の短い説明に留め、必ず構造と振動の列挙へ接続する。第二に、再発防止策は「人の気合い」ではなく「構造の設計変更」として記述する。第三に、対策は単発の穴塞ぎではなく、振動が整列して貫通する条件を弱める形で設計する。これにより、同型の失敗が別の人に乗り換えて再発する現象を抑制できる。

3. 「旧い見方」から「新しい見方」へ：人間は欠陥ではなく資源

安全工学の歴史を見ると、ヒューマンエラーの理解には大きな転換がある。初期の安全研究では、人間は不確実で不安定な存在であり、事故は主として人間の失敗から発生すると考えられていた。この立場では、人間はシステムの弱点であり、事故を減らすには人間の行動を規律化し、監督し、逸脱を減らす必要があるとされた。その結果として、教育訓練、手順遵守、監視、懲戒などが中心的な対策として採用された。これがいわゆる「旧い見方」である。

しかし実務の経験が蓄積されるにつれて、この説明は現実を十分に説明できないことが明らかになった。なぜなら、同じ現場、同じ人員、同じ設備でも、大半の時間は問題なく仕事が成立しているからである。もし人間が単純に「誤りやすい部品」であるなら、日常の業務はもっと頻繁に破綻しているはずである。実際には、事故はまれであり、むしろ人間は不完全なシステムを補完しながら日常業務を成立させている。この事実は、人間を欠陥部品として扱う説明と整合しない。

この問題に対して、Erik Hollnagel はヒューマンエラーの理解を再定義する必要を指摘した。旧い見方では、人間の行動は「正しいか間違っているか」で評価され、誤りは人間内部の失敗メカニズムとして説明される。しかし実際の現場では、人間は常に状況を調整し、情報の不足や時間圧の中で判断し、構造の欠陥を補いながら作業を成立させている。したがって、人間の行動を単純な「エラー機構」として扱うことは、現実の作業の性質を誤解することになる[4]。

この認識を体系化したのが Safety-II の視点である。Safety-II では、安全とは単に「事故が起きない状態」ではなく、「通常業務が安定して成立する能力」として定義される。現場の作業は常に変動しており、計画通りに進むとは限らない。設備の状態、情報の遅れ、割り込み、負荷の変化などが日常的に発生する。その中で人間は状況を解釈し、優先順位を調整し、必要に応じて手順を補完しながら作業を成立させている。つまり日常業務の成功も失敗も、同じ調整能力から生まれている[5]。

この視点から見ると、人間はシステムの欠陥ではなく、むしろシステムを成立させる資源である。設計された手順や規則は、すべての状況を完全にはカバーできない。予期しない条件が現れたとき、最終的に判断し調整するのは人間である。人間は状況に応じてルールを補完し、足りない情報を推定し、システムの穴を埋める役割を担っている。この意味で、人間の調整能力は安全の核心でもある。

本稿の前提である「構造の振動」という概念は、この理解と自然に接続する。構造は常に変動しており、完全に静止した状態は存在しない。負荷の変化、情報の遅れ、資源の制約、組織の圧力などが、構造の中に揺らぎを生む。その揺らぎの中で、現場の人間は状況を調整しながら仕事を成立させている。したがって、人間の行動は振動の外にあるのではなく、振動の内部で行われる調整である。

ここから重要な帰結が導かれる。日常業務が成立しているとき、人間の調整は成功として観測される。しかし同じ調整が、ある条件の組み合わせの下で破綻したとき、それはミスとして観測される。つまり成功と失敗は別の仕組みから生まれるのではなく、同じ仕組みの異なる結果として現れる。この点を理解しない限り、事故分析は常に「成功した無数の事例」を無視し、「失敗した一例」だけを説明するという偏った構造になる。

3.1 旧い見方と新しい見方の対比

観点	旧い見方	新しい見方
人間の位置づけ	人間は不確実で誤りやすい弱点である。	人間は状況変動を調整する資源である。
事故の説明	事故は人間の失敗によって起きる。	事故はシステムの変動と調整の破綻として生じる。
安全の定義	事故が起きない状態。	日常業務が安定して成立する能力。
対策の中心	教育、監視、規律、懲戒。	設計改善、構造調整、運用支援。
分析の焦点	誰がミスしたか。	どの条件が破綻を生んだか。

3.2 本節の結論

以上をまとめると、安全工学における重要な転換は、人間を欠陥部品として扱う視点から、人間をシステムの調整資源として理解する視点への移行である。この転換を採用すると、ヒューマンエラーは「人間の弱さ」ではなく、「調整が成立しなくなった局面」として解釈される。したがって、事故分析の目的は人を責めることではなく、調整が破綻する条件を特定し、構造を再設計することに置かれる。

4. 観測点モデル：ミスは端点であり、原因は手前にある

前節までで確認したように、ヒューマンエラーは原因の終点ではなく、構造の状態が人間の行動として露出した観測点である。この整理を実務で使える形にするためには、「観測された事実」から「構造の条件」へ遡る分析手順を明確にする必要がある。本稿ではその手順を単純化し、分析対象を三つの層に分けて扱う。これは理論的分類というより、事故分析やポストモーテムを実務で進めるための思考順序である。

多くの報告書では、まず観測された事実が列挙され、そのまま原因として記述される。しかし観測された行動は、構造の中で生じた振動が最も弱い箇所から露出した結果にすぎない。したがって分析は、観測点から一段ずつ手前に戻る必要がある。すなわち「何が起きたか」を記述した後に、「どの条件がその行動を誘発したか」を検討し、さらに「その条件を作った構造は何か」を特定する。この順序を守ると、事故の説明は個人のミスではなく、設計変更の対象として整理される。

4.1 3 層分解

層	見るべき対象	典型的な問い
構造層	制度、役割、権限、手順、インターフェース、監視、レビュー、教育、評価制度などの安定条件。	何が「当たり前の運用」を形づくっているか。
振動層	時間圧、情報不足、割り込み、例外増加、手順の省略、認知負荷、コミュニケーションの劣化などの揺らぎ。	どの条件が、どの方向に運用を押し流しているか。
観測層	ミス、逸脱、誤操作、誤判断、見落とし、復旧失敗などの可視化された事象。	どの地点で振動が「行動」として露出したか。

この三層の関係は、原因の方向を逆にたどることで理解できる。現場で観測されるのは観測層の事象であり、例えば誤操作や入力ミス、見落としなどである。しかしこれらの事象は突然発生するわけではない。作業の途中には、時間圧の増加、割り込みの頻発、情報の欠落、手順の省略などの揺らぎが存在する。これが振動層である。そして振動層を生む条件は、制度、設計、権限、手順、評価制度などの構造に由来する。つまり構造層が振動層を生み、振動層が観測層として露出する。

この関係を理解すると、ヒューマンエラーという語の位置づけが変わる。ヒューマンエラーは観測層の記述としては有用であるが、原因の説明としては不十分である。なぜなら、同じ種類のミスが別の人間によって繰り返される場合、原因は個人ではなく構造にあるからである。例えば、環境の識別が困難なインターフェースでは環境取り違えが繰り返されるし、確認工程が時間圧の中で省略される設計では確認漏れが再発する。このような再現性は、構造の条件によって説明される。

一般的な報告書は観測層の事実を列挙して結論を「ヒューマンエラー」に置きがちだが、本稿の前提ではそれは「温度計の数字」を病名にしている状態である。温度計が三十八度を示したとき、原因は温度計ではなく身体の内部にある。同様に、ヒューマンエラーという観測点は、構造内部の状態を示す指標である。必要なのは、振動層と構造層に遡り、観測点が必然化された条件を列挙し、再発防止を構造の変更として設計することである。

4.2 分析の実務手順

三層モデルを実務で使う場合、分析は観測層から開始する。まず、ログ、証言、記録などから「何が起きたか」を具体的に書き出す。次に、その行動が起きた状況を振動層として整理する。時間圧はなかったか、割り込みはなかったか、情報は十分だったか、確認工程は現実的だったか、といった問いを順に検討する。そして最後に、その振動を生んだ構造条件を特定する。手順設計、権限分離、UI の識別性、監視の設計、組織の評価制度などがここに含まれる。

この順序を守ると、事故分析は自然に設計変更へ接続する。観測層の記述だけでは「注意する」しか対策が残らないが、構造層まで遡れば「権限を分割する」「確認工程を自動化する」「識別性を上げる」「監視を強化する」など、具体的な変更が設計できる。これが観測点モデルの実務的な意味である。

5. 防御層モデルの再解釈：スイスチーズは「振動の整列」を示す

安全工学で広く知られているスイスチーズモデルは、事故が単一の原因で発生するのではなく、複数の防御層の弱点が連鎖したときに発生することを説明するために提案された。モデルの基本的なイメージは単純であり、防御層をチーズのスライスとして表現し、それぞれのスライスに穴が存在すると考える。通常は複数の層が互いに補完し合うため事故は防がれるが、複数の穴が偶然同じ位置に並んだとき、事故が防御層を貫通する。この現象が事故として観測される[1]。

このモデルは直観的で理解しやすく、多くの分野で採用されてきた。しかし本稿の前提である「構造の振動」という観点から見ると、このモデルはさらに別の意味を持つようになる。すなわち、チーズの穴は固定された欠陥ではなく、運用の変動によって開いたり閉じたりする可変の窓として理解できる。日常業務では、人間の調整や余裕によって多くの穴は実質的に塞がれている。しかし時間圧が高まり、情報が不足し、作業が並列化されると、複数の防御層で同時に穴が開く。この状態が「振動の整列」である。

振動の整列とは、構造の中で発生している複数の揺らぎが、同じ方向に作用する状態を指す。例えば、時間圧が増えると確認工程は省略されやすくなる。確認が省略されると誤操作の検知が遅れる。検知が遅れると復旧の余裕が減る。このような連鎖が同時に起きると、防御層は機能しているにもかかわらず、実際には事故を防げない状態になる。このとき事故は「突然起きた」のではなく、振動が整列した結果として発生する。

この読み替えの重要な点は、防御層を静的な欠陥の集合として扱わないことである。旧い理解では、事故の原因は「どの層に穴があったか」を探すことに集中していた。しかし振動の観点では、問題は穴の存在ではなく、穴が同時に開く条件である。つまり分析の対象は個々の欠陥ではなく、欠陥が整列する状況である。

この視点を採用すると、再発防止の設計も変わる。もし問題が単一の穴であるなら、その穴を塞げばよい。しかし振動の整列が原因である場合、単一の修正では不十分である。必要なのは、整列を起こす条件を弱めることである。具体的には、作業の同時並行を減らす、重要な確認のタイミングを分散させる、権限を分割して危険操作を複数人の判断にする、設計上危険な操作を実行できないようにするなど、構造全体の変動を調整する介入になる。

5.1 静的モデルと動的モデルの違い

観点	静的な理解	振動モデルによる理解
穴の意味	設計上の欠陥や手順の不備。	運用条件によって開閉する可変の弱点。
事故の発生	複数の欠陥が偶然重なった結果。	複数の変動が同じ方向に整列した結果。
分析の焦点	どこに穴があったか。	なぜ穴が同時に開いたか。
対策の発想	欠陥を修正し、穴を塞ぐ。	振動が整列する条件を弱める。

5.2 実務への含意

この解釈を実務に適用すると、事故分析の焦点は「個々のミス」から「変動の相互作用」へ移る。例えば、ある事故が確認漏れによって起きたとしても、その原因を単純に確認不足と結論づけるのではなく、なぜ確認が省略されたのかを調べる。そこには時間圧、タスクの過密、情報不足、責任の曖昧さなどが存在する場合が多い。これらの条件が同時に存在すると、防御層は形式的には存在していても実質的には機能しない。

したがって、防御層モデルの本質は「多重防御」そのものではなく、「多重防御が同時に弱くなる条件」を理解することにある。振動という概念は、その条件を記述するための言語である。スイスチーズモデルは、事故が単一原因ではなく構造的連鎖によって生じることを示した。本稿の読み替えは、その連鎖を「振動の整列」という動的現象として理解するものである。

6. IT 運用への接続：Blameless Postmortem は「観測点から手前へ戻る」技法

ソフトウェアとネットワークに依存する現代のサービス運用では、障害は「単発のバグ」や「単一装置の故障」として現れるとは限らない。多数のサービスが連携し、設定変更やデプロイが頻繁に行われ、負荷は時間帯や外部要因で変動する。その結果、障害は複数の条件が重なったときに発生し、原因は単線の因果ではなく、運用の変動が結合した形で現れる。この性質は、安全工学で議論されてきた「単一原因ではなく条件の整列で事故が起きる」という理解と同型である。したがって IT 運用の障害分析もまた、「誰がミスしたか」ではなく「どの条件が整列したか」を説明できなければ再発防止として弱い。

この文脈で、Google の SRE が示したブレイムレスなポストモーテムは、文化論として語られやすいが、実務上は分析技法として理解すると筋が通る。SRE では、ポストモーテムの目的は責任追及ではなく、学習と再発防止のために寄与要因を特定することだと明示されている[6]。ワークブックでも、個人名の強調や感情的表現が学習を阻害し、組織としての改善に結びつかない点が具体的に説明される[7]。さらに、実際のポストモーテム例では、障害の引き金、潜在要因、軽減策、アクションアイテムが構造化され、単なる出来事の列挙ではなく「次に変えるべき設計」が読み取れる形で提示される[8]。

本稿の前提に沿って言えば、ブレイムレスとは倫理ではなく解析手順である。非難を始めると、分析の焦点が観測層の個人行動に固定され、構造層の欠陥が見えなくなる。これは単に雰囲気が悪くなるという話ではない。責任追及のモードに入ると、説明は「誰が」「何を」したかに収束し、再発防止は「注意」「教育」「手順遵守の徹底」といった個人依存の対策へ縮退する。個人依存の対策は、運用負荷や人員交代や緊急対応といった振動条件の下で再び崩れやすい。逆に非難を保留すると、観測点から手前へ戻る問いが成立し、振動層の条件を列挙でき、構造層の変更として再発防止を設計できる。

この「手前へ戻る」という動作は、前節の三層モデルで言えば、観測層から振動層へ、振動層から構造層へ遡る操作である。SRE のポストモーテムが強いのは、ここを文章の形式として強制できる点にある。障害の出来事を時系列で書くだけでなく、寄与要因とアクションアイテムを書かせることで、観測点を結論にしない構造を作っている。したがってブレイムレスは「優しさ」ではなく「分析を止めないための装置」だと言える。

6.1 典型例：production での危険操作

典型的な障害として、production 環境で危険操作を実行してしまう事象を考える。観測層の記述は「誤った操作が実行された」で終わるが、振動層と構造層に戻すと説明は具体化され、対策は設計変更として書けるようになる。ここで重要なのは、危険操作そのものを否定することではなく、「危険操作が通ってしまう構造」と「危険操作を誘発する振動条件」を分離して記述することである。

観測として見える事実	振動として疑う条件	構造として変える候補
危険操作が実行された。	時間圧と割り込みが増え、確認手順が省略されやすかった。	危険操作を制約する権限分離と実行前確認を設計する。
環境を取り違えた。	staging と production の識別が視覚的に弱く、注意に依存していた。	プロンプトや UI に強制的な環境識別を組み込む。
レビューが機能しなかった。	運用が属人化し、チェックが形骸化していた。	手順とログの標準化でレビュー可能性を上げる。

この形式で書けるようになると、対策は「注意する」ではなく「設計を変える」へ自然に移る。ここでいう設計は、コードだけでなく権限、手順、観測、教育、責任分界などを含む。さらに言えば、設計とは「危険操作をできなくする」だけでなく、「危険操作が起きても事故にならない」ように隔離し検知し復旧できるようにすることも含む。ブレイムレスなポストモーテムは、この設計変更の議論を成立させるために、観測点から手前へ戻る視点を組織に定着させる。

6.2 SRE の用語と三層モデルの対応

SRE のポストモーテムで使われる典型的な区分を、本稿の三層モデルに対応づけておく。これにより、SRE の記法が単なるテンプレートではなく、観測点モデルを実務に落とす形式であることが明確になる。

ポストモーテムの要素	三層モデルでの位置づけ	目的	書き方の要点
Impact と Timeline	観測層	何が起きたかを再現可能に記述する。	事実と時刻を中心に書き、評価語を混ぜない。
Trigger と Contributing Factors	振動層	なぜその時に破綻したかを条件として列挙する。	時間圧、割り込み、情報欠損、手順省略などの揺らぎを具体化する。
Action Items と Follow-ups	構造層	再発防止を設計変更として実装可能にする。	権限、手順、UI、監視、レビュー、責任分界のどれを変えるかを明示する。

この対応表が示す通り、SRE のポストモーテムは、観測点を原因にしないための書式である。書式があることで、議論が個人攻撃へ流れるのを防ぎ、条件の列挙と設計変更へ収束させられる。ここまでが、IT 運用においてブレイムレスが重要になる理由であり、本稿の前提である「観測点から手前へ戻る」という分析規律が、実務に実装された例である。

7. 「振動」を具体化する方法：変動が共振して破綻する

ここまで本稿では、事故や障害を「構造の振動」として理解する視点を提示してきた。しかし振動という言葉を単なる比喩として使うだけでは、実務にとって十分ではない。重要なのは、日常運用の中で発生している小さな変動が、どのように相互作用し、どの条件で破綻へと結びつくのかを具体的に記述することである。すなわち、変動がどこで発生し、どの経路を通って伝播し、どの条件で増幅されるのかを分析できなければ、「振動」という概念は説明力を持たない。

この課題に対して安全工学が提示した代表的な方法論の一つが、Erik Hollnagel による FRAM（Functional Resonance Analysis Method）である。FRAM は、複雑な社会技術システムが「普段はうまく回る」理由と「ときどき壊れる」理由を、機能の相互依存と変動の共振として説明する枠組みとして提案された[9]。この方法論は書籍や研究文献によって体系化されており、出版情報や適用例も整理されている[10]。

FRAM の重要な特徴は、事故原因を単一の連鎖として扱わない点にある。従来の事故分析では、「A が失敗したため B が起き、その結果として事故が発生した」という線形の因果関係で説明されることが多かった。しかし現実のシステムでは、多数の機能が相互依存しながら同時に動いている。各機能には常に小さな変動が存在するが、通常はそれらが互いに吸収されることで全体は安定している。ところが特定の条件が重なると、複数の変動が同じ方向へ強まり、全体として大きな揺れになる。この現象を FRAM は「機能共振（functional resonance）」と呼ぶ。

この視点を本稿の議論に接続すると、ヒューマンエラーの位置づけは大きく変わる。誤操作や判断ミスは事故の根本原因ではなく、共振の末端に現れた観測結果である。すなわち、人間の行動だけを修正しても、共振を生む構造条件が残っていれば同じ事故は再び起こる。したがって再発防止の焦点は、単一の欠陥を修正することではなく、変動が結合して共振する条件を弱める設計に置かれる。

7.1 FRAM の基本構造

FRAM では、システムは複数の機能（function）の集合として記述される。各機能は独立した部品ではなく、情報や資源を共有することで互いに結びついている。FRAM では各機能を複数の側面から記述し、それらの結合関係を明示することで、変動がどの経路で伝播するかを分析できるようにする。

FRAM の要素	意味	システム理解における役割
Function	システムを構成する基本的な活動や処理。	システムを部品ではなく活動の集合として記述する。
Input	機能を開始させる情報や条件。	他の機能との依存関係を明示する。
Output	機能が生み出す結果。	他の機能への影響を記述する。
Precondition	機能が実行されるために必要な状態。	運用条件や環境条件を表現する。
Resource	機能の実行に必要な資源。	資源不足や競合が変動を生むことを示す。
Control	機能を制御する規則や手順。	組織やルールが振る舞いに与える影響を記述する。
Time	時間制約やタイミング。	時間圧や遅延が変動を拡大する条件を表す。

7.2 変動が共振する仕組み

FRAM のもう一つの特徴は、変動を例外ではなく通常状態として扱う点である。人間の判断のばらつき、通信の遅延、情報不足、資源競合などは、日常の運用では常に存在する。通常はこれらの変動が互いに吸収されることでシステムは安定している。しかし機能間の依存関係を通じて複数の変動が同時に強まると、全体として大きな揺れが発生する。これが共振である。

日常の変動	結合の仕組み	共振したときの結果
作業時間の遅れ	後続工程の時間圧を増大させる。	確認工程が省略されやすくなる。
情報の欠損	判断を個人の経験に依存させる。	判断のばらつきが拡大する。
資源不足	複数作業の同時処理を増やす。	注意資源が分散する。
手順の複雑化	ショートカット行動を誘発する。	安全装置が実質的に無効化される。

7.3 本稿の三層モデルとの対応

FRAM の視点は、本稿で用いてきた観測層・振動層・構造層という三層モデルとも対応している。観測層では事故や障害として現れた結果を記述する。振動層では、どの機能の変動がどのように結合したかを分析する。そして構造層では、その結合を弱めるための設計変更を行う。したがって FRAM は、「振動」という概念を具体的な分析手順として運用するための方法論と位置づけられる。

三層モデル	FRAM における位置づけ	分析の目的
観測層	事故や障害として観測された結果。	何が起きたかを事実として記述する。
振動層	機能間の変動とその結合。	なぜその時に破綻したのかを説明する。
構造層	機能の配置や依存関係。	共振を弱める設計変更を行う。

このように、FRAM は「振動」という概念を実際の分析に適用するための道具である。事故を単一原因として説明するのではなく、複数の機能変動が共振する条件として理解することで、再発防止は個人の注意ではなく構造の設計へと移る。これが、振動という概念を実務の中で具体化する方法である。

8. 複雑化するシステムへの拡張：STAMP と制御構造

前節では、FRAM を例として「振動」を具体的な分析手順として扱う方法を示した。FRAM は機能間の変動と共振を記述する枠組みとして有効であるが、さらに複雑なシステムでは別の視点が必要になる。とくにソフトウェアと組織と運用が密接に結合したシステムでは、事故は単なる部品故障や操作ミスの連鎖として説明できない場合が多い。航空、医療、金融、クラウドサービスのような領域では、個々の装置は正常に動作していても、制御関係やフィードバックの欠落によって事故が発生する。この問題に対応するために提案されたのが Nancy Leveson による STAMP（Systems-Theoretic Accident Model and Processes）である[11]。

STAMP は、事故を部品故障の結果ではなく、制御構造の破綻として理解するモデルである。システムは階層的な制御構造として表現され、各層は上位からの制約を受けながら動作する。事故は部品が壊れたから起きるのではなく、システムが守るべき制約（safety constraint）が破れたときに発生すると定義される。この視点では、人間の操作、ソフトウェアの挙動、組織の意思決定はすべて同じ制御構造の要素として扱われる。国内でも IPA などが STAMP を紹介し、事故を要素間の相互作用として理解する重要性を指摘している[12]。また、STAMP に基づく具体的な分析手順である STPA（System-Theoretic Process Analysis）はハンドブックとして公開されており、制御構造を明示的に分析する方法が整理されている[13]。

このモデルを本稿の議論に接続すると、STAMP は「振動がどの制御ループで増幅し、どの制約が破れ、どこで観測点として露出したか」を描く道具と理解できる。FRAM が変動の共振を記述する枠組みだとすれば、STAMP はその共振がどの制御構造の中で拡大したかを説明する枠組みである。特にソフトウェアが支配的なシステムでは、誤操作という観測点の手前に、設計上の制約不足やフィードバック欠落が存在しやすい。そのため、個人の注意力を高めるだけでは同じ型の破綻は別の場所で再発する。

8.1 STAMP の基本概念

STAMP はシステムを階層的な制御構造として記述する。各層にはコントローラが存在し、対象となるプロセスを制御する。コントローラは制御指令を送り、フィードバックを受け取り、その情報をもとに次の制御を決定する。このループのどこかで制約が破れたり、フィードバックが欠落したりすると、システムは安全な状態を維持できなくなる。

STAMP の概念	意味	事故分析での役割
Safety Constraint	システムが満たすべき安全条件。	事故を防ぐための制約として定義される。
Controller	対象プロセスを制御する主体。	人間、ソフトウェア、組織などが該当する。
Controlled Process	制御対象となるシステムや作業。	制御が適切に機能しているかを評価する対象。
Control Action	コントローラが出す制御指令。	不適切な指令が事故の要因になる。
Feedback	制御対象から返される状態情報。	欠落すると制御が誤った方向へ進む。

8.2 制御構造としての事故

STAMP の視点では、事故は単一の原因によって起きるのではなく、制御構造の中で安全制約が維持されなくなった結果として発生する。例えばソフトウェア運用の現場では、運用担当者、デプロイツール、監視システム、組織の手順などが相互に制御関係を持つ。これらの関係が適切に機能している間はシステムは安定するが、制御の遅れや誤ったフィードバックが生じると、安全制約が破れ、障害が発生する。

制御構造の問題	具体例	結果として起こる破綻
制約が不十分	危険な操作を防ぐ設計が存在しない。	操作ミスがそのまま事故になる。
フィードバック欠落	システム状態が監視や UI に反映されない。	誤った判断が継続する。
制御の遅延	異常検知から対応までの時間が長い。	障害が拡大する。
制御モデルの誤り	運用者がシステム状態を誤解している。	誤った操作が合理的判断として実行される。

8.3 三層モデルとの対応

本稿で用いてきた三層モデル（観測層・振動層・構造層）と STAMP の関係を整理すると、両者は補完的な関係にある。観測層では障害として表面化した現象を記述する。振動層では変動や相互作用の連鎖を説明する。そして構造層では、制御構造や安全制約を設計する。STAMP はこの構造層を明示的に描くための道具であり、FRAM が変動の結合を示すのに対して、STAMP は制御構造を示す。

三層モデル	STAMP での対応	分析の目的
観測層	事故や障害として観測された結果。	何が起きたかを事実として記述する。
振動層	制御ループ内の変動や相互作用。	どの条件で破綻が拡大したかを説明する。
構造層	制御構造と安全制約。	再発防止の設計を行う。

このように、STAMP は複雑な社会技術システムを理解するための制御理論的な枠組みである。FRAM が変動の共振を説明する方法であるのに対し、STAMP はその共振がどの制御構造で発生したのかを明示する。両者を併用することで、事故は単なるミスではなく、構造と変動の相互作用として理解できるようになる。

9. 社会レベルの視点：リスク管理は「動的な制御問題」である

ここまで本稿では、ヒューマンエラーを個人の失敗として扱うのではなく、構造の振動として理解する視点を提示してきた。この視点が重要になる理由は、現場の行動が現場だけで決まるわけではないからである。実際の組織では、作業手順、管理制度、経営判断、規制、技術基盤などが重なり合い、現場の判断や行動に影響を与える。そのため、現場の誤操作や判断ミスだけを原因として扱うと、事故を生んだ構造条件が分析から消えてしまう。

この問題を体系的に論じたのが Jens Rasmussen の研究である。Rasmussen は、リスク管理を単なる安全対策の問題としてではなく、社会の複数レベルにまたがる制御問題として理解する必要があると指摘した。動的な社会では、技術、経済、規制、組織の圧力が相互に作用し、システム全体を安全境界の方向へ押し流す。この圧力の中で安全を維持するためには、単一の装置や手順ではなく、社会全体の制御構造を考える必要があると論じられている[14]。同様の内容は学術誌でも整理されており、複雑な社会技術システムの事故を理解するための枠組みとして紹介されている[15]。

この系統の研究では、事故を単一の原因として説明するのではなく、意思決定の階層構造を通じて理解する方法が提案されている。Svedung と Rasmussen は、政策決定者、規制機関、企業管理者、現場管理者、作業者といった層を階層構造として図式化し、事故がどのような経路で伝播するかを分析する方法を提示した[16]。このアプローチは後に AcciMap と呼ばれる多層モデルとして整理され、社会制度から現場操作までを同一の図の中で記述する方法として発展している[17]。

この視点を本稿の前提に合わせて整理すると、ヒューマンエラーとは現場個人の行動ではなく、「社会的制御構造が生んだ振動」の末端観測と理解できる。現場で観測される誤操作や判断ミスは、社会のさまざまな圧力が収束した結果として現れる。したがって事故分析では、個人の注意や技能だけでなく、どの層の制約や圧力が振動を増幅したのかを検討する必要がある。

9.1 社会技術システムの階層構造

Rasmussen のモデルでは、社会技術システムは複数の意思決定層によって構成される。上位層は制度や規制を通じて制約を与え、下位層は実際の作業を通じてシステムを運用する。事故は、この階層構造の中で制約やフィードバックが適切に機能しなかったときに発生する。

層	主な主体	役割
政府・規制	法律制定機関や規制当局。	安全基準や制度的制約を定める。
企業経営	経営層や経営戦略部門。	投資配分や組織方針を決定する。
管理・設計	マネージャーやシステム設計者。	運用手順や技術構成を設計する。
現場運用	オペレーターや技術者。	実際の作業を実行する。
技術基盤	装置やソフトウェア。	システムの物理的・技術的基盤を提供する。

9.2 圧力が振動を生む仕組み

社会技術システムでは、各層が独立しているわけではない。経済圧力、納期要求、評価制度、技術的制約などが互いに影響し合い、現場の行動を方向づける。Rasmussen は、このような圧力がシステムを安全境界の方向へ徐々に押し流すと説明した。つまり事故は突然起きるのではなく、長期的な圧力の中で安全余裕が削られた結果として現れる。

社会的圧力	現場への影響	事故への接続
納期圧力	作業の短縮や手順省略が増える。	確認不足が事故につながる。
コスト圧力	設備投資や人員配置が削減される。	安全余裕が減少する。
評価制度	短期成果が重視される。	長期的安全対策が後回しになる。
技術選択	複雑なツールや構成が導入される。	理解不足による誤操作が増える。

9.3 三層モデルとの対応

本稿で用いてきた三層モデルと Rasmussen の社会技術モデルを対応させると、次のように整理できる。観測層では事故として現れた出来事を記述する。振動層では、社会的圧力や組織条件がどのように現場の変動を増幅したかを分析する。構造層では、制度設計や責任分界を含む制御構造を設計する。

三層モデル	社会技術システムでの対応	分析の目的
観測層	現場で観測された事故や誤操作。	何が起きたかを事実として記述する。
振動層	社会的圧力や組織条件による変動。	なぜその時に破綻したかを説明する。
構造層	制度、責任分界、制御構造。	再発防止の設計を行う。

このように、社会レベルの視点を導入すると、事故分析は現場のミスの説明から、社会技術システム全体の制御設計へと拡張される。ヒューマンエラーはその末端に現れた観測点にすぎず、再発防止は圧力の設計と制御構造の設計を含む問題になる。これが、リスク管理を「動的な制御問題」として理解する理由である。

10. 具体例：テネリフェ事故を「観測点」として読む

抽象的な議論を具体化するために、航空史上もっとも有名な事故の一つである 1977 年のテネリフェ空港地上衝突事故を例として取り上げる。この事故では、濃霧の中で離陸滑走を開始した KLM 機と、滑走路上に残っていた Pan Am 機が衝突し、583 名が死亡した。航空事故調査の古典的事例として広く引用されており、コミュニケーション、視界、手順、権威勾配など複数の要因が絡み合った事故として分析されてきた。事故調査資料では、無線通信の曖昧な表現、標準手順の運用、管制と乗員の情報共有の問題などが具体的に指摘されている[18]。事故報告書のミラーも公開されており、一次資料として参照できる[19]。さらに、この事故は人的要因の研究でも繰り返し再分析されており、組織文化やチーム意思決定の問題としても論じられている[20]。

一般的な説明では、この事故は「誤った離陸判断」として語られることが多い。しかし本稿の三層モデルに沿って読むと、その説明は観測層に留まっている。つまり、最終的に観測された出来事は「離陸許可がない状態で離陸を開始した」という行動であるが、その背後には複数の振動条件が存在していた。視界不良、空港の混雑、通信の曖昧さ、手順理解の差、そしてチーム内の権威勾配が同時に作用し、防御層の穴が整列した結果として事故が発生したと理解できる。

10.1 観測層としての事故

事故の表面に現れるのは、特定の行動や判断である。テネリフェ事故の場合、観測層の事実は比較的単純である。滑走路上に別の航空機が存在する状態で、離陸滑走が開始されたという一点に集約される。しかしこの観測だけでは、なぜその判断が成立したのかを説明することはできない。

観測された事実	直接的な説明	限界
KLM 機が離陸滑走を開始した。	離陸許可を誤って解釈した。	なぜ誤解が成立したかを説明できない。
Pan Am 機が滑走路上に残っていた。	滑走路離脱が遅れた。	なぜ離脱が遅れたかを説明できない。
管制は衝突を防げなかった。	状況把握が不十分だった。	視界や通信条件を説明していない。

10.2 振動層としての条件

観測層の説明を手前へ戻すと、事故を成立させた複数の振動条件が見えてくる。これらは単独では事故を生まないが、同時に作用することで防御層を貫通する。

振動条件	内容	影響
視界不良	濃霧により滑走路状況を直接確認できなかった。	状況認識が通信情報に依存した。
通信の曖昧さ	無線通信で標準的でない表現が使用された。	離陸許可の解釈が分かれた。
空港混雑	多数の航空機が同一空港に集中していた。	手順の運用が複雑化した。
権威勾配	経験豊富な機長に対する異議が出にくかった。	チーム内の相互確認が弱まった。

10.3 構造層としての設計問題

振動条件をさらに手前へ戻すと、手順設計や組織文化といった構造要因が現れる。これらは事故後に航空業界全体で見直されることになった。

構造要因	問題点	事故後の改善例
通信手順	曖昧な表現が許容されていた。	標準化された用語の導入。
チーム運用	機長中心の意思決定。	Crew Resource Management の導入。
状況共有	滑走路状況の確認手段が限られていた。	地上監視レーダーなどの導入。

このように事故を三層で整理すると、「誰が誤った判断をしたか」という説明は、構造振動の露出点に過ぎないことが分かる。視界不良、混雑、通信の曖昧さ、チーム内の権威勾配といった振動条件が重なり、防御層の穴が整列して事故が発生したのである。重要なのは、個人の能力ではなく、曖昧さを許容する手順設計と、異議申し立てが機能しにくい組織構造が振動の増幅器になっていた点である。この理解が成立したことで、航空業界では通信規則の標準化や CRM（Crew Resource Management）といった構造的改善が進められることになった。

11. まとめ：ヒューマンエラーは「診断指標」であり、設計の入口である

本稿では、ヒューマンエラーという概念を個人の失敗としてではなく、「構造の振動が人間の行動として観測されたもの」として再定義し、その理解から事故分析と再発防止の設計原理を整理してきた。一般的な説明では、事故は誤操作や判断ミスの結果として語られることが多い。しかし安全工学やシステム理論の研究を参照すると、事故は単一の失敗ではなく、複数の条件が整列したときに発生することが分かる。この理解に立つと、ヒューマンエラーは原因ではなく、構造状態を読み取るための観測点として位置づけられる。

まず、Reason のスイスチーズモデルは、防御層の穴が整列したときに事故が発生するという直観を与える[1]。このモデルは、事故を単一原因ではなく複数条件の重なりとして理解する基礎を提供した。IT 運用の領域では、Google SRE が提唱するブレイムレスなポストモーテムが、観測点から手前へ戻る分析手順として機能する[6]。個人の責任追及を保留することで、寄与要因を列挙し、構造変更として再発防止を設計できるからである。

さらに、安全研究の分野では、Hollnagel による Safety-II が「日常の調整が成功と失敗の両方を生む」という立場を明確にした[5]。この視点では、事故は異常な出来事ではなく、通常の運用変動が特定条件で増幅した結果として理解される。FRAM（Functional Resonance Analysis Method）は、その変動がどのように共振して事故に至るかをモデル化する方法を提供する[10]。

一方、Leveson の STAMP は事故を制御構造の破綻として理解する枠組みを提示した[13]。ここでは事故は部品故障ではなく、安全制約が維持されなくなった結果として発生すると定義される。さらに Rasmussen の研究は、リスク管理を社会の複数レベルにまたがる動的な制御問題として理解する必要を示している[14]。政策、組織、管理、現場といった層が互いに影響し合い、その圧力の中で事故が発生するからである。

これらの理論を統合すると、ヒューマンエラーは「個人の欠陥」ではなく、「構造状態を読み取るための診断指標」として理解できる。現場で観測される誤操作や判断ミスは、振動が表面化した観測点であり、その背後には変動の結合や制御構造の問題が存在する。したがって再発防止は、教育や注意喚起だけで終わるべきではない。むしろ、手順、権限、通信、監視、制度といった構造設計を変更することが中心になる。

11.1 本稿で示した分析枠組み

本稿の議論は、事故や障害を三層構造で理解する方法として整理できる。観測層では事故として表面化した出来事を記述する。振動層では、どのような変動が重なり事故を生んだのかを分析する。構造層では、変動が共振しないように設計を変更する。

層	内容	目的
観測層	事故や誤操作として観測された出来事。	何が起きたかを事実として記述する。
振動層	運用変動や条件の相互作用。	なぜその時に破綻したかを説明する。
構造層	制度、手順、設計、制御構造。	再発防止の設計変更を行う。

11.2 設計原理としてのヒューマンエラー

この三層モデルの下では、ヒューマンエラーは単なる失敗ではなく、設計改善の入口として機能する。誤操作が発生したときに「注意不足」と結論づけるのではなく、その行動を観測点として手前へ戻り、振動条件と構造要因を特定することで、より強い再発防止策を設計できる。

従来の理解	本稿の理解	設計への影響
ヒューマンエラーは事故原因。	ヒューマンエラーは観測点。	分析を構造へ拡張できる。
対策は教育や注意喚起。	対策は構造設計の変更。	再発防止の持続性が高まる。
事故は個人の問題。	事故は社会技術システムの問題。	制度や組織の設計が対象になる。

結論として、ヒューマンエラーという言葉は事故原因の説明として使うよりも、システム診断の指標として使う方が有用である。誤操作や判断ミスは、構造振動が表面化した観測点であり、その背後にある変動と制御構造を読み取るための手がかりになる。この視点に立つと、事故分析は責任追及から設計改善へと転換される。ヒューマンエラーは終点ではなく、構造設計を見直すための入口なのである。

参考文献

James Reason. The Swiss Cheese Model of Accident Causation. https://en.wikipedia.org/wiki/Swiss_cheese_model
Salmon, P. M., Stanton, N. A., Walker, G. H., & Jenkins, D. P. (2009). Human factors methods and accident analysis: a review. https://doi.org/10.1016/j.apergo.2008.12.002
ICAO. Human Factors Training Manual (Doc 9683). https://www.icao.int/safety/training/pages/humanfactors.aspx
Erik Hollnagel. The ETTO Principle: Efficiency-Thoroughness Trade-Off. https://erikhollnagel.com/onewebmedia/ETTO%20Principle.pdf
Erik Hollnagel. Safety-II in Practice. https://erikhollnagel.com/onewebmedia/Safety-II%20in%20Practice.pdf
Google. Site Reliability Engineering: Postmortem Culture. https://sre.google/sre-book/postmortem-culture/
Google. SRE Workbook: Postmortems. https://sre.google/workbook/postmortems/
Google. Example Postmortem Template. https://sre.google/workbook/postmortems/#example-postmortem
Erik Hollnagel. FRAM (Functional Resonance Analysis Method). https://functionalresonance.com/
Hollnagel, E. FRAM: The Functional Resonance Analysis Method. https://functionalresonance.com/FRAM_BOOK.pdf
Nancy Leveson. STAMP (Systems-Theoretic Accident Model and Processes). https://psas.scripts.mit.edu/home/materials/
IPA. STAMP / STPA 解説. https://www.ipa.go.jp/security/fy21/reports/stamp.html
Nancy Leveson. STPA Handbook. https://psas.scripts.mit.edu/home/get_file.php?name=STPA_handbook.pdf
Jens Rasmussen. Risk Management in a Dynamic Society. https://www.sciencedirect.com/science/article/pii/S0925753597000520
Leveson, Rasmussen safety research overview. https://safetyresearch.net/rasmussen/
Svedung & Rasmussen. Graphic representation of accident scenarios. https://backend.orbit.dtu.dk/ws/files/158016663/SAFESCI.pdf
AcciMap method overview. https://skybrary.aero/articles/accimap
Tenerife Airport Disaster overview. https://en.wikipedia.org/wiki/Tenerife_airport_disaster
Dutch Investigation Report (Tenerife). https://www.faasafety.gov/files/gslac/courses/content/232/1081/finaldutchreport.pdf
Human factors analysis of Tenerife accident. https://rosap.ntl.bts.gov/view/dot/13937/dot_13937_DS1.pdf