ヒヤリハットとインシデントの違い｜報告基準の決め方と社内ルール設計
「これはヒヤリハットなのか、それともインシデントとして扱うべきか」——報告書を前にした現場担当者が、この線引きで手を止める場面は少なくない。言葉の定義が曖昧なまま運用すると、本来報告すべき事象が漏れたり、逆に何でもかんでも報告されて分析が回らなくなったりする。
ヒヤリハットとインシデントは似た文脈で使われるが、組織がどこまでを報告対象にするかを決める「基準」がなければ、報告制度そのものが機能しない。本記事では両者の定義の違いを整理したうえで、報告対象を一発で判定できるフローチャートと、そのまま使える社内規程テンプレートを提示する。安全管理担当者が自社のルールを設計し直すための実務ガイドである。
1. ヒヤリハットとインシデントの違い――定義と関係性
ヒヤリハットとは、事故には至らなかったが「ヒヤリ」「ハッと」した危険な出来事のことである。インシデントとは、業務遂行に影響を与えた、または与えかねなかった事象全般を指す広い概念であり、ヒヤリハットを含む上位の言葉として使われることが多い。
混乱の原因は、業界によって言葉の使い方が異なる点にある。製造・建設では「ヒヤリハット」が主流だが、医療・介護では同じ事象を「インシデント」と呼び、IT・SRE領域では「インシデント」がサービス障害そのものを指す。つまり言葉の優劣ではなく、自組織でどの語を、どの範囲に当てるかを定義することが先決である。
| 用語 | 定義 | 主に使う業界 | 結果の有無 |
|---|---|---|---|
| ヒヤリハット | 事故に至らなかったが危険を感じた出来事 | 製造・建設・物流 | 被害なし |
| インシデント | 影響を与えた／与えかねなかった事象全般 | 医療・介護・IT | 被害なし〜軽微 |
| アクシデント | 実際に被害・損害が発生した事象 | 全業界 | 被害あり |
| 重大災害 | 死亡・後遺障害など重篤な結果を伴う事象 | 全業界 | 重篤な被害 |
「ヒヤリハット＝インシデントの一部」という整理が実務的
医療現場での標準的な整理では、患者に影響が及ばなかった、または及んでも軽微だった事象を「インシデント（ヒヤリハット）」、実際に被害が生じた事象を「アクシデント（事故）」と区別する。この枠組みは製造・建設にも応用できる。
つまり実務上は「被害が出たか／出なかったか」で大きく二分し、被害が出なかった側をヒヤリハット（インシデント）として一括管理するのが扱いやすい。報告制度を設計する際は、用語を細かく分類するより「どこまで拾うか」の線引きを優先したほうが現場は迷わない。
報告基準の曖昧さを解消したい現場では、報告から原因分析までを一本の流れで管理できる仕組みが効く。WhyTrace Plusはヒヤリハット報告をQRコードで受け取り、AIがなぜなぜ分析まで支援する。報告の入口と分析の出口を分断しない運用を試せる。
2. インシデントとアクシデントの違い――結果の有無が分岐点
アクシデントとは、実際に人身被害や物的損害が発生してしまった事象である。インシデントとの最大の違いは「結果が出たかどうか」にある。
両者を分ける基準は、損害の発生有無で考えるとぶれにくい。たとえば「足場の隙間につまずいたが転倒しなかった」はインシデント（ヒヤリハット）、「つまずいて転倒し打撲した」はアクシデントである。同じ原因事象でも、結果の有無で扱いが変わる。
- インシデント側：危険を感じた／ミスをしたが、被害には至らなかった
- アクシデント側：実際にケガ・設備損傷・品質流出・サービス停止が発生した
この線引きが重要なのは、報告のスピード要件が変わるからだ。アクシデントは初動対応・原因調査・再発防止が即時に求められる。一方インシデントは「予防情報」として蓄積し、傾向分析で先回りする性質が強い。同じ報告制度の中でも、緊急度に応じて処理フローを分けておく必要がある。
ハインリッヒの法則が示す報告の価値
労働安全の分野では、1件の重大災害の背後に29件の軽微な事故、300件のヒヤリハットが存在するという「ハインリッヒの法則」が広く知られる。これはアメリカのハーバート・ウィリアム・ハインリッヒが1931年に発表したもので、330件の労働災害のうち1件が重傷、29件が軽傷、300件が無傷害だったという比率に基づく（参考：ハインリッヒの法則とは – リクルートマネジメントソリューションズ）。
厚生労働省は2001年、医療現場の安全対策にこの考え方を応用したヒヤリハット運動を取り入れている（参考：ハインリッヒの法則 – シャープ スリーゼロ）。2026年時点でも、被害が出ていない300のインシデントをいかに拾い上げるかが、1件の重大災害を防ぐ鍵という構造は変わらない。ヒヤリハット報告の本質的な価値はここにある。
ハインリッヒの法則そのものの活用法はハインリッヒの法則の実務活用ガイドで詳しく解説している。
3. 報告基準を決める3つの判断軸
報告基準とは、ある事象を報告対象とするか否かを判断するための組織共通のものさしである。基準を「結果の重大性」「発生可能性」「学習価値」の3軸で定義すると、現場が迷わず判断できる。
報告制度が形骸化する典型的な原因は、基準が「気づいたら報告する」程度の精神論にとどまっていることだ。何を報告すべきかが人によって違えば、報告件数は属人化し、データとしての一貫性も失われる。次の3軸を組み合わせて閾値を設けることで、判断のばらつきを抑えられる。
| 判断軸 | 内容 | 設定のポイント |
|---|---|---|
| 結果の重大性 | 起きていたら被害はどの程度だったか | 想定される最悪の結果で評価する |
| 発生可能性 | 同じ状況が再び起きる頻度 | 一度きりか、日常的に起きうるか |
| 学習価値 | 他者・他現場に共有する価値があるか | 横展開で防げる事象を優先 |
「想定される最悪の結果」で評価する
報告するかどうかを迷ったときは、実際の結果ではなく「もし不運が重なっていたら何が起きたか」で判断する。今回は何も起きなかったとしても、想定される最悪の結果が重傷や設備停止であれば、報告対象とすべきである。
この「最悪結果ベース」の考え方は、リスクアセスメントの重大性評価と相性が良い。報告された事象を後工程でリスク評価につなげる前提に立てば、報告段階から重大性を意識した記述が集まる。リスクアセスメントの進め方はリスクアセスメントの実践ガイドを参照されたい。
「報告して損はない」を原則にする
基準を厳しくしすぎると報告件数が激減する。迷ったら報告する、報告したことを咎めない——この「ノーブレーム（非難しない）」原則を基準とセットで掲げることが、制度を生かすうえで欠かせない。基準は「報告を絞り込む道具」ではなく「報告後の分類・優先順位づけの道具」と位置づけるのが正しい。
4. ヒヤリハット・インシデント判定フローチャート
判定フローチャートとは、事象に直面した担当者が、報告すべきか・どの区分で報告すべきかを順番に判断していくための分岐手順である。Yes/Noで進める形にすると、現場で即座に使える。
以下は製造・建設・物流現場を想定した汎用フローである。自社の事情に合わせて閾値を調整して使う。
【START】何か危険・異常・ミスがあった
│
▼
Q1. 実際に被害（ケガ・設備損傷・品質流出・停止）が出たか？
│
├─ YES ─▶ 【アクシデント】
│ → 即時報告＋初動対応＋原因調査（24時間以内）
│
└─ NO
│
▼
Q2. もし不運が重なっていたら、重傷・重大損害になり得たか？
│
├─ YES ─▶ 【重要ヒヤリハット】
│ → 当日中に報告＋なぜなぜ分析対象
│
└─ NO
│
▼
Q3. 同じ状況が他の人・他の現場でも起こり得るか？
│
├─ YES ─▶ 【共有ヒヤリハット】
│ → 通常報告＋横展開で共有
│
└─ NO ─▶ 【記録ヒヤリハット】
→ 簡易報告（件数集計・傾向分析用）
4区分の処理を変える
フローの出口を4区分に分けることで、すべてを同じ重さで扱う非効率を避けられる。重要なのは、区分ごとに「誰が・いつまでに・何をするか」を変えることだ。
| 区分 | 報告期限 | 主な処理 | 分析の深さ |
|---|---|---|---|
| アクシデント | 即時（24時間以内） | 初動対応・原因調査・再発防止 | なぜなぜ分析＋FTA |
| 重要ヒヤリハット | 当日中 | 根本原因分析・対策立案 | なぜなぜ分析 |
| 共有ヒヤリハット | 数日以内 | 横展開・注意喚起 | 簡易要因分析 |
| 記録ヒヤリハット | 任意・随時 | 件数集計・傾向把握 | 集計のみ |
このように緩急をつけることで、限られた安全管理リソースを重大事象に集中できる。すべての報告に同じ分析工数をかけようとすると制度は破綻する。区分けは「手を抜く」ためではなく「重大事象に集中する」ための設計である。
なお、なぜなぜ分析が必要な区分（アクシデント・重要ヒヤリハット）については、原因の深掘りに体系的な手法を使うと精度が上がる。原因分析の進め方はフィッシュボーン図（特性要因図）の書き方も参考になる。
5. 社内規程テンプレート――そのまま使える条文例
社内規程とは、報告基準・報告フロー・関係者の役割を文書として明文化したものである。口頭ルールではなく文書化することで、人の入れ替わりがあっても基準が維持される。
以下は中小規模の製造・建設現場を想定した「ヒヤリハット・インシデント報告規程」の骨子テンプレートである。自社の組織体制・用語に合わせて編集して使う。
規程テンプレート（骨子）
第1条（目的） 本規程は、ヒヤリハットおよびインシデントの報告基準と処理手順を定め、事故の未然防止と再発防止を図ることを目的とする。
第2条（定義）
- ヒヤリハット（インシデント）：業務中に被害が発生しなかったが、危険を感じた、またはミスが生じた事象をいう。
- アクシデント：業務中に人身被害・物的損害・品質流出・業務停止が実際に発生した事象をいう。
第3条（報告義務） 従業員は、第2条に該当する事象を認識した場合、判定フローに従い速やかに報告しなければならない。報告は非難の対象としない（ノーブレーム原則）。
第4条（報告区分と期限） 報告区分および報告期限は別表のとおりとする。アクシデントは24時間以内、重要ヒヤリハットは当日中に報告する。
第5条（処理体制） 安全管理責任者は報告を受領後、区分に応じた原因分析・対策立案を行い、結果を報告者および関係部署へ通知する。
第6条（記録と見直し） すべての報告は記録・保管し、月次で傾向を分析する。報告基準は年1回以上見直すものとする。
規程を「生きた文書」にする3つの工夫
規程は作って終わりでは機能しない。以下の3点を盛り込むと、現場に定着しやすい。
- フィードバック条項を入れる：報告者に必ず処理結果を返す旨を明記する。「報告しても何も返ってこない」が制度を殺す最大の要因である。
- 報告手段を限定しない：紙・口頭・スマホ入力など複数手段を認め、第3条に「報告手段は問わない」と添える。書く手間が報告の壁になる。
- 見直しサイクルを明記する：第6条のように見直し頻度を条文化し、基準が形骸化しないようにする。
報告手段のデジタル化についてはヒヤリハット報告の書き方と例文もあわせて参照すると、現場での記述ハードルを下げるヒントになる。
6. 報告基準を現場に定着させる運用設計
定着とは、報告が一部のベテランだけでなく組織全体の習慣になり、件数とデータの質が安定して維持される状態である。基準と規程を作るだけでは定着しない。運用の仕掛けが要る。
報告制度がうまくいかない現場の多くは、「基準が悪い」のではなく「基準を運用に落とす設計が抜けている」。次の4要素を運用に組み込むことで、報告は習慣化に向かう。
| 運用要素 | 具体策 | 期待効果 |
|---|---|---|
| 入口の簡素化 | 項目を3つ以内に絞る、写真1枚で可とする | 報告のハードルを下げる |
| 即時フィードバック | 受領・処理結果を必ず返す | 「報告は無駄」の払拭 |
| 可視化 | 報告内容と対策を掲示・共有 | 横展開と当事者意識 |
| 経営層の関与 | トップが報告に感謝を表明する | 心理的安全性の確保 |
デジタル化で「入口」と「分析」をつなぐ
紙の報告書は、書く手間と集計の手間の二重の負担を生む。スマホやQRコードで報告できる仕組みにすると入口の負担が下がり、データがそのまま分析に流れる。報告と分析が分断されていると、せっかくの300件のヒヤリハットが集計だけで終わってしまう。
デジタル化したヒヤリハット運用の具体像はデジタルヒヤリハット導入の進め方で詳しく扱っている。報告の入口設計に悩む現場には、業界別のヒヤリハット活動の優良事例10選も実践のヒントになる。
報告基準は決めた。では、集まった報告をどう原因分析につなげるか？
WhyTrace Plus は、ヒヤリハット・インシデント報告の受付からなぜなぜ分析・対策管理までを一本化する根本原因分析プラットフォームである。判定フローで「重要ヒヤリハット」に分類された事象を登録すると、AIが「なぜ？」を対話形式で深掘りし、因果関係をツリー図で可視化する。報告がExcelの行で眠ったまま終わる運用から、組織のナレッジへと変える。
よくある質問（FAQ）
Q. ヒヤリハットとインシデントは同じ意味ですか？
ほぼ同義で使われることが多いが、厳密にはインシデントのほうが広い概念で、ヒヤリハットを含む。製造・建設では「ヒヤリハット」、医療・介護・IT領域では「インシデント」が主に使われる。自組織でどちらの語をどの範囲に当てるかを定義しておけば、呼称の違いは問題にならない。
Q. 報告すべきか迷ったときはどう判断すればよいですか？
実際の結果ではなく「もし不運が重なっていたら何が起きたか」という最悪結果ベースで判断する。想定される最悪の結果が重傷や設備停止なら、今回被害がゼロでも報告対象とすべきである。迷ったら報告する、を原則にしておくと拾い漏れを防げる。
Q. 報告基準を厳しくしすぎると何が問題ですか？
基準を厳格にすると報告件数が激減し、ハインリッヒの法則でいう300件のヒヤリハットを取りこぼす。報告基準は「報告を絞り込む道具」ではなく「報告後の分類・優先順位づけの道具」と位置づけ、入口は広く、出口で区分を分ける設計が望ましい。
Q. 社内規程はどのくらいの頻度で見直すべきですか？
最低でも年1回の定期見直しに加え、重大事象の発生時・組織変更時・関連法令の改正時には随時更新する。規程の第6条などに見直し頻度を明記しておくと、形骸化を防げる。報告区分や期限が現場実態と乖離していないかを点検するとよい。
Q. 報告区分は必ず4つに分ける必要がありますか？
必須ではない。組織規模が小さければ「アクシデント／ヒヤリハット」の2区分から始めてもよい。重要なのは区分の数ではなく、緊急度に応じて処理の重さを変えることである。運用に慣れてから段階的に細分化していくほうが定着しやすい。
まとめ
ヒヤリハットとインシデントの違いは用語の優劣ではなく、自組織でどの語をどの範囲に当てるかという「定義の問題」である。実務では被害の有無で大きく二分し、被害なし側をヒヤリハット（インシデント）、被害あり側をアクシデントとして整理するのが扱いやすい。
本記事の要点を整理する。
- 定義の違い：インシデントはヒヤリハットを含む広い概念。アクシデントは被害が実際に発生した事象。
- 報告基準の3軸：結果の重大性・発生可能性・学習価値で判断し、迷ったら報告する原則を掲げる。
- 判定フローチャート：被害の有無→最悪結果→横展開性で4区分に分け、区分ごとに処理を変える。
- 社内規程テンプレート：定義・報告義務・区分と期限・処理体制・見直しを条文化し、文書として残す。
- 定着の運用設計：入口の簡素化・即時フィードバック・可視化・経営層の関与の4要素を組み込む。
報告基準と規程を整えたら、次は集まった報告を原因分析へとつなげる仕組みづくりである。報告が集計で終わらず、根本原因の特定と再発防止まで一貫して回る運用を目指したい。
関連サービス
安全管理・ヒヤリハット報告の運用をさらに強化するために、姉妹サービスの記事もご活用いただきたい。
- ヒヤリハット報告を増やす方法5選（安全ポスト+）
- 4M分析の完全ガイド（安全ポスト+）
- KYボードAIの最新比較（AnzenAI）
- リスクアセスメントの実践ガイド（GenbaCompass）
著者
國分 良太
制御設計エンジニア → AI・IoT・DX推進｜AIコンサルタント｜東京の製造業メーカー開発部門
製造業の現場で設備設計・改善プロジェクト・品質向上施策に従事。なぜなぜ分析（RCA）やリスクアセスメントの実務経験をもとに、現場DXを支援するアプリケーションの開発と情報発信に取り組んでいます。AIコンサルタントとして、企業のAI・生成AI活用や現場DX導入の支援も行っています。
※ 本サイトは所属企業とは関係のない個人活動です。記載の見解は筆者個人のものです。