Safety-Ⅰ と Safety-Ⅱ｜「失敗を防ぐ」から「うまくいく要因を増やす」へのパラダイム転換

「ヒヤリハット件数が減らない」「無災害日数を更新しても突然の重大事故が起きる」——こうした行き詰まりを経験している現場は少なくない。失敗を数える従来の安全管理（Safety-Ⅰ）には構造的な限界があり、Erik Hollnagel はその先に Safety-Ⅱ という新しい視点を提示した。本稿では Safety-Ⅰ と Safety-Ⅱ の違い、4つの能力、現場での統合方法を、実務に落とせる粒度で解説する。

「うまくいったこと」も報告できていますか — 安全ポスト＋ はQRで匿名報告、AIが4M分析。ヒヤリハットだけでなくポジティブ事例も同じ仕組みで蓄積できる。無料プランあり。

Safety-Ⅰ とは——失敗を最小化する従来型の安全観

Safety-Ⅰ とは、「事故や失敗が可能な限り少ない状態」を安全と定義する考え方だ。1900年代の労働災害統計研究（ハインリッヒ）以来、ほぼすべての産業安全活動はこの前提に立って構築されてきた。

Safety-Ⅰ の前提と方法論

Safety-Ⅰ の基本ロジックは次のように整理できる。

1. 安全 = 失敗の不在：負の事象（事故・災害・ヒヤリハット）が少ないほど安全だと評価する
2. 失敗には特定可能な原因がある：原因を見つけて取り除けば失敗は防げる
3. 人は変動の源：ばらつきを生むヒューマンファクターを管理・制御することで安全を確保する

この前提に基づく代表的な手法が、事故調査・ヒヤリハット分析・FMEA・FTA・スイスチーズモデルによる原因究明であり、いずれも「何が悪かったのか」を起点にする。詳細はスイスチーズモデルの記事を参照してほしい。

Safety-Ⅰ がもたらした成果

誤解しないでほしいのは、Safety-Ⅰ は決して「古い」「間違っている」ものではないという点だ。20世紀後半に労働災害が大幅に減少した最大の要因は、Safety-Ⅰ 的アプローチによる多重防護の整備とルール化である。

• 機械の安全カバー・インターロックの普及
• 標準作業手順書（SOP）・チェックリストの導入
• KY活動・指差呼称・ヒヤリハット報告制度
• 法令（労働安全衛生法）に基づく義務的な安全管理体制

これらの仕組みは現在も安全活動の土台であり、これを否定する話ではない。Safety-Ⅱ は Safety-Ⅰ の「次の階段」であって「置き換え」ではない。

Safety-Ⅰ の限界——「ゼロ事故」が達成できない構造的理由

しかし2000年代以降、多くの産業で「事故件数の下げ止まり」が観察されるようになった。設備・ルール・教育を強化しても、ある水準から先は事故が減らない。Erik Hollnagel はこの現象を Safety-Ⅰ の構造的限界として指摘した。

限界1：分析対象が「失敗」だけに偏る

Safety-Ⅰ は失敗事例しか研究対象にしない。1日の現場で起きている数百〜数千の作業のうち、99.9%以上はうまくいっているのに、そのうまくいっている事例の中身は誰も調べない。「うまくいっているのだから、いじる必要はない」という暗黙の前提が働く。

結果として「失敗の裏側にある成功のメカニズム」が言語化されないまま蓄積されない。職人の暗黙知のまま属人化し、ベテランが引退すると一気に失われる——これは多くの現場で起きている現実だ。

限界2：複雑系では原因と結果が線形に対応しない

Safety-Ⅰ は「原因→結果」の線形モデルを前提とする。しかし現代の現場は、機械・人・情報・気象・他部門との連携が複雑に絡み合う相互依存システムだ。同じ操作ミスでも、状況によって何も起きないこともあれば重大事故になることもある。

Hollnagel はこれを「変動の同期（resonance）」と呼び、複数の小さな変動が偶然タイミング良く重なったときに事故が顕在化すると説明する（FRAM: The Functional Resonance Analysis Method, Ashgate, 2012）。線形の原因究明だけでは捕捉できない領域がある。

限界3：「ゼロベース」は数学的に不可能

事故件数がゼロに近づくほど、追加対策1件あたりの限界効果は小さくなる。一方で対策のコスト（時間・お金・現場の負担）は単調に増加する。

下げ止まり期に Safety-Ⅰ だけで突破しようとすると、現場は「過剰なルール・書類仕事・形だけのチェック」に疲弊する。安全活動そのものが現場の余力を奪い、別のリスクを生む逆説が起きる。

Safety-Ⅱ とは——「うまくいくこと」を理解し増やす視点

Safety-Ⅱ とは、Erik Hollnagel が著書 Safety-I and Safety-II: The Past and Future of Safety Management（Ashgate, 2014）で提唱した新しい安全観であり、「できるだけ多くのことが、できるだけうまくいく状態」を安全と定義する。

Safety-Ⅱ の前提

Safety-Ⅰ の前提を裏返すと Safety-Ⅱ になる。

1. 安全 = うまくいくことの最大化：成功事象が多いほど安全だと評価する
2. 成功にも理解可能なメカニズムがある：なぜうまくいったかを解明すれば再現できる
3. 人は柔軟性の源：現場の調整能力こそが事故を未然に防いでいる

Hollnagel が繰り返し強調するのは、「事故と日常業務は同じメカニズムから生じる」という点だ。普段の作業がうまくいくのも、稀に事故が起きるのも、人が状況に応じて判断を調整しているという同じ過程の結果である。差は「変動が同期したかどうか」だけだ。

Safety-Ⅱ が見るもの

Safety-Ⅰ が「氷山の海面上に現れた失敗」を見るのに対し、Safety-Ⅱ は「海面下にある膨大な成功」を見る。

両者は対立するものではない。Hollnagel 自身が著書で「Safety-Ⅱ は Safety-Ⅰ を置き換えるものではなく、補完するものだ」と明記している。

Safety-Ⅱ の4原則——Respond / Monitor / Learn / Anticipate

レジリエンス・エンジニアリングでは、レジリエント（しなやかで強い）な組織が備える4つの能力を定義している。Hollnagel と Wreathall らが整理した「Resilience の4本柱」だ。

1. Respond（対応する力）

実際に起きた事象や変化に対して、適切に対応する力を指す。マニュアル通りの対応だけでなく、想定外の事態でも現場が即興で適応できる柔軟性が含まれる。

• 異常発生時の初動判断
• 不在者が出たときの役割の振り替え
• 計画変更時の段取りの組み直し

ベテラン作業員が「いつもと違うな」と感じて手を止めるとき、その判断は Respond の力だ。マニュアル化されていない判断こそが、日々の事故を防いでいる。

2. Monitor（監視する力）

組織内外の状態を継続的にモニタリングし、変化の兆候を早期にキャッチする力だ。重要なのは「何を監視するか」の選定であり、KPIや指標の設計力が問われる。

• 設備の異常値・異音・振動
• 作業員の疲労・モチベーション
• 取引先・気象・規制動向

監視は技術だけでなく、現場の感覚値と組み合わせて初めて機能する。設備異音の監視についてはPlantEarのような AI 監視ツールを使うと、人の感覚と機械の精度を両立できる。

3. Learn（学習する力）

過去の事象（成功も失敗も）から学び、組織として記憶・改善する力だ。Safety-Ⅰ が失敗からのみ学ぶのに対し、Safety-Ⅱ は成功事例からの学習を重視する。

• なぜいつも通りにうまくいったのか
• ベテランは何を見て判断を変えたのか
• どの段取りが今日の工程をスムーズにしたのか

学習の対象を成功にまで広げると、暗黙知が形式知に変換され、組織知として継承される。

4. Anticipate（予見する力）

まだ顕在化していない将来のリスクや機会を予見する力だ。Monitor が現在の状態を見るのに対し、Anticipate は未来を見る。

• 来月の繁忙期に発生しそうな疲労リスク
• 新人配属後3か月以内に起きやすいエラー
• 設備の更新時期と作業の習熟タイミングのずれ

予見はデータと現場知見の両方を必要とする。蓄積されたヒヤリハット・成功事例・改善履歴を AI が傾向分析することで、人間の経験だけでは見えなかったパターンを発見できる。

WAI と WAD——「想像された仕事」と「実際の仕事」のギャップ

Safety-Ⅱ を理解するうえで欠かせない概念が WAI（Work-as-Imagined）と WAD（Work-as-Done）だ。Hollnagel と Steven Shorrock が体系化し、現在ではレジリエンス・エンジニアリングの中核概念になっている。

WAI（Work-as-Imagined）——想像された仕事

WAI とは、計画者・管理者・経営層が「現場ではこう作業されているはずだ」と想像する仕事の姿だ。手順書・SOP・標準作業書に書かれている内容はすべて WAI である。

WAI の特徴は次の通りだ。

• 理想的・標準的な条件を前提にしている
• 想定外の変動（人員不足、設備不調、天候、顧客の急な変更）が省かれている
• 作業者の経験・スキルの個人差が捨象されている

WAD（Work-as-Done）——実際の仕事

WAD とは、現場で実際に行われている仕事の姿だ。手順書通りにいかない場面で、作業員が判断・調整・即興でやりくりしている実態を指す。

• 「手順書ではこうなっているけど、現場ではこうしている」
• 「マニュアル通りやると終わらないので、ベテランが順序を変えている」
• 「機械の癖を知っている人だけが回せている工程」

このギャップ（WAI ≠ WAD）は、ほぼすべての現場に存在する。Safety-Ⅰ ではこのギャップを「ルール違反」として埋めようとするが、Safety-Ⅱ では「現場の調整能力の発露」として理解する。

WAI/WAD ギャップへの向き合い方

WAD が WAI を上回るからこそ、現場は日々機能している。重要なのは「WAD を否定してルールに戻す」ことではなく、「WAD を観察して WAI を更新する」ことだ。

現場巡回や対話で WAD を可視化し、合理的な工夫は手順書に反映する——この往復が WAI と WAD のギャップを健全に縮める。

安全ポスト＋ で WAI と WAD のギャップを可視化

匿名QR報告なら、現場の「実はこうしてます」が安全に集まる。AIが4M分類してくれるので、WAIの更新ポイントを管理者が一目で把握できる。

👉 無料で始める

現場運用での統合——ヒヤリ報告とポジティブ報告の両輪

Safety-Ⅰ と Safety-Ⅱ は対立しない。実務的には「両輪で回す」のが正解だ。具体的な統合の進め方を3段階で示す。

段階1：既存のヒヤリハット報告を維持する（Safety-Ⅰ の継続）

まず、ヒヤリハット報告・事故調査・KY活動といった Safety-Ⅰ 的な仕組みは継続する。これらは法令・社内規程の根幹であり、外す必要はない。むしろ「報告された失敗にきちんと対応する」サイクルの精度を上げる方が先だ。

段階2：ポジティブ報告（成功事例の報告）を追加する

次に「うまくいった事例」を意図的に集める仕組みを追加する。これが Safety-Ⅱ の入り口になる。

ポジティブ報告の例：

• 「いつもと違う手順でやったら段取りが短縮できた」
• 「気温が高くて疲れたので、休憩のタイミングを早めたら午後の効率が上がった」
• 「新人にこの順番で教えたら習熟が早かった」
• 「設備のこの音を聞いて止めたら、軽微な不具合のうちに修理できた」

ヒヤリハットと同じフォーマットで報告できるようにすると、現場の運用負荷が増えない。多くの現場ではすでに匿名QR報告などのデジタル仕組みがあるので、選択肢に「ヒヤリ／良かった事例／改善提案」を並べるだけで運用が始まる。

段階3：両報告の分析を統合する

ヒヤリ報告とポジティブ報告を同じ分析基盤に乗せ、4M（Man・Machine・Material・Method）で分類すると、組織全体の「変動のパターン」が見えてくる。

AIで4M分類すると、同じ要因がヒヤリ側にもポジティブ側にも現れることがある。たとえば「ベテランの段取り変更」がヒヤリの原因にも、ポジティブの成功要因にもなりうる。これは「現場の調整能力」そのものを示しており、Safety-Ⅱ が見たい現象だ。

なぜなぜ分析を Safety-Ⅱ 文脈で使うと「なぜうまくいったか」を5回掘れる。詳しくはWhyTrace Plusの使い方も参考になる。

医療・航空での先行事例——Safety-Ⅱ の実装

Safety-Ⅱ は概念だけが先行しているわけではない。医療・航空という安全先進業界で実装が進んでいる。

医療：CARe-QI と Resilient Health Care Network

医療分野では Erik Hollnagel と Robert Wears らが Resilient Health Care Network を組織し、Safety-Ⅱ の医療実装を進めている（Resilient Health Care, Ashgate, 2013）。

オランダの病院では、救急外来の WAI と WAD を観察し、ベテラン看護師がどのように患者のトリアージを調整しているかを記録した。結果、マニュアルにない複数の調整パターンが言語化され、新人教育に組み込まれた。

英国NHSの一部トラストでは、インシデント報告に加えて「Learning from Excellence（卓越からの学習）」プログラムを導入。同僚の優れた対応を報告できる仕組みで、報告された卓越事例は教育資材に反映される。

航空：CRM から Resilient Performance へ

航空業界はもともと Safety-Ⅰ の優等生だが、2010年代以降は Safety-Ⅱ の取り込みが進んでいる。

• LOSA（Line Operations Safety Audit）：通常運航中のコックピットを観察し、パイロットが想定外の状況にどう対応しているかを記録する。失敗事例ではなく日常運航の中の調整を分析するアプローチ。
• CRM の進化：従来は権威勾配の是正に焦点があったが、現在は「想定外への適応力（Resilient Performance）」の訓練にウェイトが移っている。

両業界とも、Safety-Ⅰ をベースに維持しながら、その上に Safety-Ⅱ を積み上げる「二階建て」のアプローチをとっている。製造・建設業の現場でも同じ構造が再現できる。

製造・建設現場での Safety-Ⅱ 実装ステップ

最後に、製造・建設の現場で Safety-Ⅱ を導入する具体的なステップを示す。

ステップ1：ポジティブ報告の入口を作る（1か月以内）

既存のヒヤリハット報告フォームに「うまくいった事例」「改善提案」のカテゴリを追加する。紙でもデジタルでも構わない。重要なのは「失敗以外も書ける場所」を明示することだ。

ステップ2：管理者の対話スタイルを変える（3か月以内）

朝礼や1on1で「今日危なかったこと」だけでなく「最近うまくいったこと・誰かのナイスな段取り」を聞く時間を設ける。管理者が良い事例に関心を持つ姿勢を見せると、現場の報告内容が変わる。

ステップ3：WAD 観察を月1回ルーティン化する（6か月以内）

管理者が手順書を持って現場に入り、「手順書通りにやっているか」を見るのではなく「手順書とどこが違うか」を観察する。違いに合理性があれば手順書を更新する。違いに危険があれば手順を強化する。判断は両方向にありうる。

ステップ4：4能力（Respond/Monitor/Learn/Anticipate）の自己診断（年1回）

自組織が4能力をどの程度備えているかを年1回診断する。簡易な自己評価でよい。

各能力を5段階で自己評価し、年次推移をレビューする。Hudson モデルの安全文化診断（安全文化の記事参照）と組み合わせると、組織全体の成熟度が立体的に見える。

よくある質問

Q. Safety-Ⅰ を捨てて Safety-Ⅱ に移行すべきなのか？

いいえ。Hollnagel 自身が Safety-I and Safety-II（2014）の中で「Safety-Ⅱ は Safety-Ⅰ を置き換えるものではなく補完するもの」と明記している。失敗から学ぶ仕組み（事故調査・ヒヤリハット報告・FMEA など）は安全活動の土台であり、これを捨てる必要はない。Safety-Ⅱ はその上に「成功からも学ぶ」階層を追加するアプローチだ。

Q. 中小企業でも Safety-Ⅱ は実装できるのか？

実装できる。むしろ中小企業の方が組織が小さいぶん、管理者と現場の距離が近く、WAD の観察も実施しやすい。最初の一歩は「うまくいった事例も報告できる場所を作る」だけでよい。紙・スプレッドシート・QR報告ツールのいずれでも始められる。大規模なシステム投資は不要だ。

Q. ポジティブ報告は「自慢話の場」にならないか？

なる可能性はある。これを防ぐには報告フォーマットの設計が重要だ。「何がうまくいったか」だけでなく「なぜうまくいったと思うか」「他の人や工程でも応用できそうか」を書く欄を設けると、自慢ではなく組織知の共有になる。管理者の受け答えも「ありがとう、共有させてください」と展開志向にすると文化が定着する。

Q. Safety-Ⅱ の効果はどのくらいで現れるのか？

事故件数の減少という形では即効性はない。しかしポジティブ報告を始めて3〜6か月で「現場の発言量が増えた」「手順書が現場の実態に近づいた」「新人の習熟が早くなった」といった定性変化が観察されるケースが多い。Safety-Ⅰ の指標（事故件数・ヒヤリ件数）に加えて、Safety-Ⅱ の指標（ポジティブ報告件数・手順書改定数・現場発言件数）を併用して評価することを勧めたい。

まとめ

Safety-Ⅰ と Safety-Ⅱ は対立する考え方ではなく、安全マネジメントを支える両輪だ。

1. Safety-Ⅰ は失敗を減らす土台 — ヒヤリハット報告・事故調査・多重防護は今後も安全活動の根幹であり、捨てる必要はない。
2. Safety-Ⅱ は成功を増やす拡張 — うまくいっている日常業務の中に、事故を防いでいる調整能力が隠れている。これを言語化することで暗黙知が組織知になる。
3. 両輪で回すと現場が変わる — ヒヤリ報告とポジティブ報告を同じ仕組みで集め、4Mで分析し、WAI/WADのギャップを健全に縮める。これが Hollnagel の言う「Resilient な組織」への現実的なルートだ。

最初の一歩は小さくていい。報告フォームに「うまくいった事例」というカテゴリを追加するだけでも、現場の見え方は変わり始める。

現場改善に役立つ関連アプリ

GenbaCompassでは、安全ポスト＋以外にも現場のDXを支援するアプリを提供している。