ハインリッヒの法則とは
1931年、アメリカのトラベラーズ保険会社に勤務した安全技師ハーバート・ウィリアム・ハインリッヒが、7万5千件以上の労働災害を分析した結果として導き出した法則です。 正式名称は「災害トライアングル」または「1：29：300の法則」と呼ばれます。
この法則が示す核心は、「1件の重大事故の背後には、29件の軽微な事故と300件のヒヤリハットが存在する」という比率です。 ヒヤリハットとは「ヒヤリとした」「ハッとした」体験のことで、実際に被害は発生しなかったものの、一歩間違えば事故になっていたような出来事を指します。
図1: ハインリッヒの法則 — 1:29:300 の比率とシステム運用への適用
💡 法則の本質的なメッセージ
重大事故を防ぐには、重大事故そのものを管理するのでは手遅れです。その手前にある「300件のヒヤリハット」を収集・分析・改善することが、唯一の予防策です。この考え方は製造業・航空業・医療業で広く採用されており、システム運用にも直接適用できます。
システム運用への適用
ハインリッヒの法則は製造業の文脈で生まれましたが、ソフトウェアシステムの運用管理においても同じ構造が成り立ちます。 IT運用における3つのレベルを整理すると、次の表のようになります。
| レベル | 件数比率 | システム運用の例 | ドキュメントの役割 |
|---|---|---|---|
| 重大障害 | 1件 | 本番データ消失・長時間サービス停止・セキュリティインシデント | インシデント対応手順書・ポストモーテム |
| 軽微な障害 | 29件 | 手順ミスによる一時的な機能停止・限定的なデータ不整合・デプロイ失敗 | 障害対応記録・ロールバック手順書 |
| ヒヤリハット | 300件 | 手順書が曖昧で迷った・コマンドを打ち間違えそうになった・確認ステップをスキップしたくなった | ヒヤリハット記録ドキュメント |
重大障害（1件）が発生した後に対処するのは後手の管理です。 軽微な障害（29件）は記録されることもありますが、対策まで繋がらないケースが多い。 真に重要なのは「300件のヒヤリハット」を可視化し、手順書改善に繋げることです。
⚠️ よくある落とし穴：「大きな問題がない = 安全」という誤解
重大障害が発生していない期間こそ、水面下でヒヤリハットが蓄積されている可能性があります。「問題が起きていないから大丈夫」という慢心が、突発的な重大障害を引き起こします。ヒヤリハット記録は「問題がない時期こそ」収集する必要があります。
ヒヤリハット記録ドキュメントの役割
ヒヤリハット記録ドキュメントは、単なるメモではありません。以下の3つの機能を持ちます。
これらの機能を最大化するために、ヒヤリハット記録は手順書と一体化して管理することが重要です。 手順書の末尾にヒヤリハット記録欄を設けることで、「作業のたびに気づきを記録する」という行動が自然に促されます。
ヒヤリハット記録の書き方
ヒヤリハット記録は、できるだけ記入の手間を少なくすることが重要です。 複雑なフォーマットでは記録されないまま忘れられてしまいます。 最低限記録すべき項目は以下の5項目です。
| 項目 | 記入内容 | 記入例 |
|---|---|---|
| 日付 | 発生した日付（YYYY-MM-DD） | 2026-06-27 |
| 記録者 | 氏名またはチーム名 | 田中 / 運用チーム |
| 発生ステップ | 手順書の何番目で起きたか | ステップ3「設定ファイル更新」 |
| 内容 | 何がヒヤリとしたか、なぜ迷ったか | コマンドの出力が手順書の例と異なり、正常完了か判断できなかった |
| 対応状況 | 未対応 / 対応中 / 手順書更新済み | 手順書の「期待する出力例」を追記済み |
手順書に埋め込む場合は、以下のようなMarkdownのテーブル形式が使いやすいです。 作業のたびに1行追記するだけで記録が蓄積されます。
📋 手順書末尾に追加するヒヤリハット記録欄の例
## ヒヤリハット記録欄
| 日付 | 記録者 | 発生ステップ | 内容 | 対応状況 |
|------|--------|-----------|------|---------|
| 2026-06-01 | 田中 | ステップ3 | 出力が手順書の例と異なり迷った | 手順書更新済み |
| 2026-06-15 | 鈴木 | ステップ5 | ロールバック手順が不明瞭だった | 対応中 |
改善サイクルへの組み込み方
ヒヤリハットを記録するだけでは不十分です。「記録 → 分析 → 手順書改善 → 実作業 → 次のヒヤリハット発見」というサイクルを組織に定着させることが目標です。
図2: ヒヤリハット → 手順書改善サイクル
このサイクルを継続的に回すためには、「いつ分析するか」を事前に決めておくことが必要です。 ヒヤリハット件数が蓄積しても、誰も見なければ意味がありません。 以下のタイミングでレビューを設定することを推奨します。
| レビューの契機 | 対象 | アクション |
|---|---|---|
| 作業完了直後 | 今回の作業で発生したヒヤリハット | 記録欄への即時記入 |
| ヒヤリハット5件以上蓄積時 | 未対応の全件 | 原因分析・手順書更新 |
| インシデント発生後 | 関連する過去のヒヤリハット | ポストモーテムと連携して分析 |
| 四半期レビュー | 全期間の件数・種類・対応状況 | 傾向分析・優先度付け・改善計画立案 |
✅ ポストモーテムとの連携
重大インシデント発生後のポストモーテム（事後分析）では、必ず「このインシデントの前兆となるヒヤリハットが記録されていたか？」を確認してください。記録があれば「なぜ改善されなかったか」を分析し、記録がなければ「なぜ記録されなかったか」を分析します。どちらも改善のための重要な問いです。
ヒヤリハットを報告しやすい文化の作り方
技術的な仕組み（記録欄・集計スクリプト）を整えても、報告する文化がなければ機能しません。 ヒヤリハットの報告を妨げる最大の要因は「報告すると責められるのではないか」という恐怖です。
この恐怖を取り除くために、組織として以下の原則を明示することが重要です。
⚠️ 匿名での報告手段を用意する
心理的安全性がまだ醸成されていない組織では、匿名での報告手段（共有スプレッドシート・匿名フォームなど）を用意することも有効です。ただし、匿名報告は原因分析の際に詳細が聞けないデメリットもあります。最終的には実名での報告が安心してできる文化を目指してください。
まとめ
ハインリッヒの法則は、重大障害予防のための強力な思考フレームワークです。 「300件のヒヤリハットを収集・改善すること」が、1件の本番障害を防ぐための唯一の確実な手段です。
| ポイント | 内容 |
|---|---|
| 法則の本質 | 重大事故1 : 軽微な事故29 : ヒヤリハット300 — 根本から対処するには300件を見る |
| IT運用への適用 | 本番障害・軽微な障害・ヒヤリハットの3レベルで管理する |
| ドキュメント設計 | 手順書の末尾にヒヤリハット記録欄を設ける |
| 改善サイクル | 実作業 → 発見 → 記録 → 分析 → 手順書更新 → 再び実作業 |
| 文化の醸成 | ブレームレス・感謝・改善の見える化の3原則で報告しやすい環境を作る |
✅ 次のステップ
ヒヤリハットの背景を理解したら、次は具体的な手順書の設計に進みましょう。手順書 — なぜ作らなければならないのかでは、手順書が必要な4つの理由を詳しく解説しています。