「ヒヤリハットは匿名にすべきか」という質問に、単純な正解はない。名前を書かせれば確認が楽になる一方、報告そのものが出てこなくなる恐れがある。名前を書かせなければ報告は出やすくなるが、後から状況を確認できなくなる。どちらを選んでも、何かを失う前提で考える必要がある。
本稿では、匿名にすることで得られるものと失われるもの、そして現実的な折衷案を整理する。あわせて、写真の扱いと、報告した人へのフィードバックという、匿名性の議論で見落とされがちな2つの論点も扱う。どこまでの匿名性を選ぶかは、現場ごとの事情によって変わる判断である。
安全ドリル＋を1問だけ試す · 10秒の映像 → 3択
考えて答える
この映像の どこが 危ない？
名前を書かせると何が起きるか
ヒヤリハットの多くは、本人の不安全な行動や判断ミスがきっかけで起きる。氏名を記入させる様式では、報告することが自分の落ち度を申告することと同じ意味を持ってしまう。
厚生労働省 新潟労働局の資料は、この点を率直に指摘している。「ヒヤリハットは報告する側にとっても、報告を受ける側にとっても、あまり名誉なことではありません」としたうえで、「労働者を責めないという取決めをし、これを実行しないと、制度が長続きしません」と述べている（出典：厚生労働省 新潟労働局「ヒヤリハット事例・想定ヒヤリ報告制度の導入について」）。
氏名を書かせる運用は、責めないという約束を口頭でどれだけ徹底しても、様式そのものが「あなたが誰か分かっています」と伝えてしまう。この構造がある限り、責めるつもりがなくても報告は出にくくなる。運用側に悪意がなくても、様式の設計そのものが心理的な抑止として働いてしまう。
匿名にすると何が失われるか（追跡・確認）
一方、匿名化にも代償がある。もっとも大きいのが、状況を確認したいときに本人へ聞き直せなくなることである。
「足場の板が浮いていた」という一文だけの報告では、どの位置の、どの程度の浮きだったのかが分からない場合がある。氏名が分かっていれば本人に詳細を尋ねられるが、匿名では確認の手段そのものがなくなる。
追跡ができないことは、対策の検討にも影響する。原因を深掘りするには状況の再現が要るが、匿名の報告だけでは再現に必要な情報が不足することがある。この不足を承知のうえで、それでも匿名を選ぶかどうかが判断の分かれ目になる。
もうひとつ見落とされがちなのが、再発した際の扱いである。同じ状況のヒヤリハットが繰り返し報告された場合、氏名が分かっていれば「同じ人が繰り返しているのか、別の人が同じ場所でつまずいているのか」を区別できる。匿名ではこの区別ができず、対策の方向性を誤る可能性がある。個人の癖が原因なのか、場所や設備そのものに問題があるのかによって、打つべき対策はまったく異なる。
折衷案：所属だけ残す、当日だけ分かる
氏名を完全に受け取らない設計と、氏名を必須にする設計のあいだには、いくつかの折衷案がある。どれを選ぶかは、現場の人数や、過去に報告が集まっていたかどうかによって変わる。
- 所属（会社名）だけ残す：個人は特定できないが、どの会社の作業に関する報告かは分かる
- 任意の連絡先を添えられる：確認が必要な場合だけ、本人の判断で連絡先を書き足せる
- 当日だけ内容を確認できる：時刻や到着順を隠すことで、後から遡って報告者を突き止めにくくする
安全ドリル＋のヒヤリハット機能は、氏名を一切受け取らない設計を採っている。記名式の教育記録とは別のテーブルで管理し、報告と個人を結びつける情報そのものを持たない。あわせて、監督者が見る画面には投稿時刻を表示せず、並び順も到着順にはしていない。時刻や到着順は、繰り返し画面を確認すれば間接的に推測できてしまう手がかりであり、表示しないだけでも読み取りにくくなる。
ただし、これで完全な匿名が実現するわけではない。作業員の少ない現場では、報告に書かれた状況そのものから、誰の報告かが絞り込める余地は残る。「探そうとしない限り分からない」程度の設計であって、「絶対に分からない」設計ではないという点は、正直に理解しておく必要がある。
折衷案を選ぶ際は、どこまでの追跡不能を許容できるかを、事前に現場側と共有しておくことが望ましい。「氏名は分からないが、対策の検討には支障がない」という前提を運用開始前に伝えておかないと、後から「なぜ確認できないのか」という不満につながりやすい。逆に、匿名性を売りにして導入したのに、実際には所属会社まで絞り込める設計だった場合、報告する側の信頼を損ないかねない。設計と説明を一致させておくことが、折衷案を機能させる前提になる。導入前の段階で、どこまでを匿名の範囲とするかを文書化しておくと、後から運用がぶれにくい。
「報告した人を責めない」を仕組みにする
匿名化と並んで重要なのが、責めないという方針を、口頭の約束ではなく仕組みとして組み込むことである。
具体的には、報告を受け取った後の対応から、個人への注意という選択肢そのものを外しておく。報告内容を扱う会議の場でも、対策の検討にとどめ、誰が起こしたかを詮索する時間を作らない運用にする。
責めない方針が形だけのものになっていないかは、過去に出た報告への対応を振り返れば分かる。報告者本人への注意で終わっていた事例があれば、その運用が続く限り、次の報告は出にくくなる。
責めない方針を仕組みにする際は、管理者側の評価制度とも整合させる必要がある。ヒヤリハットの件数を安全成績の一部として扱い、件数が多い担当区画の責任者を低く評価するような制度が残っていると、現場の責任者が報告を歓迎しない動機が生まれる。報告を増やすことを推奨しながら、評価の仕組みが報告を減らす方向に働いていないかは、あわせて点検しておきたい。
個人が特定される写真の扱い
文章の匿名性を保っても、添付された写真に人の顔や車のナンバー、特徴的な作業服が写り込めば、そこから個人が特定される可能性がある。写り込みを完全に避けるのは、現場の実態として難しい。
現実的な対応は、写り込みそのものを禁止するのではなく、写真を閲覧できる範囲を限定することである。撮影を制限すると報告のハードルが上がってしまうため、制限すべきは撮ることではなく見られる範囲のほうである。閲覧権限を持つ人数自体も、必要最小限に絞っておくことが望ましい。安全ドリル＋では、写真は非公開のストレージに保存し、表示のたびに数分間だけ有効な署名付きURLを発行する方式を採っている。写真のURLを知る人全員が読める公開設定は避け、権限を持つ監督者だけが都度アクセスできる形にしてある。
撮影時刻や位置情報などの付随情報についても、対応できる端末では画像を一度描き直すことで取り除く処理を行っている。ただし、すべての端末・形式で確実に処理できるわけではなく、対応できない場合は原本のまま保存される。写真の扱いに完璧はないという前提で、閲覧範囲の限定を優先する設計になっている。
写真を扱う運用でもうひとつ見落とされやすいのが、報告する側への説明である。「写真は最大3枚まで、閲覧できる人を限定して保管する」という運用の説明を事前にしておかないと、写真を撮ること自体への抵抗感が残る。文章だけでも報告は成立するため、写真を撮ることに迷いがある場合は無理に添付させない、という選択肢を残しておくことも大切である。
報告した人へのフィードバック
匿名にするかどうかにかかわらず、報告がその後どう扱われたかを、報告者本人が確認できる経路を用意しておくことが望ましい。
氏名が分かる運用であれば、対応結果を本人に直接伝えることができる。匿名の運用では個別のフィードバックは難しくなるが、その分、朝礼や掲示で「こういう報告があり、こう対応した」という形の全体周知を徹底する必要がある。
フィードバックが一切ない状態が続くと、匿名かどうかに関わらず、報告することの意味そのものが感じられなくなる。全体周知の頻度についても、毎日では負担が大きい場合、週の節目に「今週出た報告とその対応」をまとめて共有する形で十分に効果が出ることが多い。大切なのは頻度の高さより、報告と対応がつながっていることが継続的に伝わることである。
出た報告をその日のうちに扱う仕組みは、ヒヤリハットが現場から出てこない3つの理由｜報告しやすさの設計でも扱っている。
なお、現場のヒヤリハット集約に特化した姉妹アプリとして安全ポスト＋もある。
日々のKY活動全体との関係は、毎日のKY活動を記録に変えるで整理している。
実際の画面を1分半で試す
QRを読むと10秒の映像が5本流れ、最後の1問だけが記名の記録として残ります。 アプリのインストールもログインも要りません。
- 職人が見る画面をそのまま試す
- サービスガイド（PDF） — 導入の流れと記録の様式
- 料金 — 1現場あたりの月額
よくある質問
Q. 匿名にすれば報告数は必ず増えますか
増える傾向はあるが、必ず増えるとは限らない。書くのが面倒、出しても変わらないといった別の理由が残っていれば、匿名化だけでは報告は増えない。理由を見誤ったまま匿名化だけを進めても、期待した効果は得られない。
Q. 完全な匿名を実現する方法はありますか
現実的には難しい。人数の少ない現場や、状況が具体的な報告ほど、内容そのものから個人が絞り込める余地が残る。この限界を認めたうえで、探そうとしない限り分からない程度の設計を目指すのが現実的である。
Q. 匿名の報告でも対策の検討はできますか
多くの場合できる。状況が具体的に書かれていれば、報告者本人に確認せずとも対策の検討は可能である。確認が必要な場合のみ、任意の連絡先が役に立つ。
Q. 写真から個人が特定されるリスクはどう抑えればよいですか
写り込みそのものを避けるのは難しいため、写真を閲覧できる範囲を限定する設計であるかどうかを優先して確認したい。公開範囲の広いストレージに保存する運用は避けるべきである。