ヒヤリハット報告書が「反省文」になってしまう本当の理由
介護BCP教育研究所 代表ヒヤリハットの報告数を増やしたいと、多くの事業所が考えています。事故の芽を早く見つけられれば、それだけ対策を打つ時間が生まれるのだから、当然のことです。
ところが現場では、報告書を書くという行為がとても重く、用紙を渡された職員の顔が曇るのを、私は何度も見てきました。事故には至らなかったとはいえ、書けば自分の落ち度が記録として残るのですから、責められている気持ちになると感じる職員も少なくありません。そうして提出された報告書には、「確認が不十分でした。今後は十分に注意します」と書かれている。私は、これを読んで書いた職員を責める気にはなれません。悪いのは書き方ではないからです。
自分が関わった出来事を自分で振り返れば、原因はどうしても自分の行為に行き着きます。ほかに見えるものがないからです。そこで私は、事実の確認だけを職員から行い、分析の部分を生成AIに任せてみることにしました。この記事は、そのときに起きたことの記録です。
事実だけを渡して、AIに書かせてみた
私が運営している居宅介護支援事業所で、実際に起きた事例をお見せします。関係者が特定されない形に加工していますが、内容はそのままです。
ある金曜日の夕方、担当のケアマネジャーがショートステイの空き状況を電話で確認し、その場で予約を取りました。続けて申込書を作り、eFaxで送信しています。ここまでは、どこの事業所でも毎日行われている業務です。
問題は、送信した申込書に別の利用者の氏名が記載されていたことでした。過去に作った書類をテンプレートとして流用したときに、氏名の差し替えが漏れていたのです。この誤りに気づいた先方から、担当者ではなく管理者である私の携帯に直接連絡が入りました。担当者どうしのやり取りで済ませる話ではないと、先方が判断したということです。すでに営業時間を過ぎており、訂正が完了したのは発生から5日後になります。
当事者からは、経過と原因についての報告を受けています。時系列は正確で、退勤時間が迫るなかで別の利用者の緊急調整も重なっていたという状況まで書かれていました。書けていないわけではありません。それでも、原因の記述が自分の焦りから始まり、対策の最後に確認する習慣を身につけるという一文が置かれている。事実を知っている人が、そのまま分析まで行うと、どうしてもこうなります。
そこで、この事案の分析だけを生成AIに任せてみました。職員には何が起きたかだけを書いてもらい、原因の分析と対策の立案をAIに行わせるという分担です。役割を分けるという発想そのものはAIがなくても成り立ちますが、それを実行できる人手がないというところで、多くの事業所は止まっているのではないでしょうか。
ここで引っかかるのが、個人情報の問題だと思います。ヒヤリハットには利用者名も職員名も先方の事業所名も入っているのだから、そんなものをAIに貼り付けていいはずがない。私も最初はそう考えていました。けれども実際に手を動かしてみると、分析に必要な情報にある個人情報は、非個人情報化して置き換えても全く問題がないということが分かりました。
先ほどの事例を、AIに渡す形に書き換えてみます。利用者の氏名は「利用者A」に、職員は「担当ケアマネ」「管理者」という役割名に、先方の事業所は「ショートステイB事業所」に置き換えました。日付も「発生日」「発生日＋4日」という相対表現にしています。一方で、16時24分といった時刻はそのまま残しました。曜日も、営業時間外だったという条件も残します。eFaxやLINEといったツール名、テンプレートを流用したという手順も、すべてそのままです。
置き換えたものと残したものを見比べると、境目がはっきりします。消したのは固有名詞だけで、原因分析に使う情報は何ひとつ失われていません。誰の氏名が書かれていたかは、なぜ誤送信が起きたのかという問いに、一切関係がなかったのです。判断に迷ったときの基準は単純で、それを消したら原因分析ができなくなるかどうかを考えます。できなくならないなら消してかまいません。
それでも、主語は当事者のままだった
AIに置き換えた事実を入力し、ヒヤリハット報告書として整理するよう指示しました。出てきたものは、体裁としてはよくできていました。時系列は正確で、発生要因は三つに分解され、再発防止策もそれぞれに対応しています。冒頭に挙げた「今後は注意します」とは、明らかに水準が違う。これで解決したと、そのときの私は思いました。
ところが数日後に読み返してみると、違和感がありました。発生要因の三つが、利用者名の差し替えを失念していた、送信前にファイルの内容を再確認していなかった、誤りの連絡を受けた後も先方での訂正処理まで確認しなかった、と書かれていたのです。
失念していた。不十分だった。確認しなかった。主語はすべて、当事者の行為になっています。対策も、送信前の目視確認を徹底することが筆頭に置かれていました。分析する役をAIに移したはずなのに、出てきたものは、当事者が自分で書いたときと同じ形をしていたわけです。
原因は、AIの能力ではありません。何が起きたかという事実だけを渡して報告書を作れと言えば、AIは書かれている出来事をなぞります。書かれているのは当事者の行為ですから、原因も当事者の行為になる。役割を分けただけでは、どこを見て分析するのかまでは変わらなかったということです。
そして原因が個人の行為に置かれると、対策もまた個人の行為を変えることになります。目視確認を徹底する、注意して確認するという属人的な対策では同じ事故が再発することは、現場の職員が一番よく分かっています。徹底できるのなら、とっくに徹底しているからです。
指示を変えると、原因の置き場所が変わる
足りなかったのは、どこを見て分析するのかという指示でした。そこで、当事者個人の注意不足を原因として書かないこと、原因は業務手順の欠落・確認体制の不備・情報管理の仕組みという観点から分析すること、対策に「徹底する」「注意する」といった精神論を含めないことを、AIのプロンプトに明記して作り直しました。
出てきた発生要因は三つでした。過去のテンプレートを流用して申込書を作成する運用でありながら、送信前に利用者氏名を確認する手順が定められていなかったこと。過去の利用者情報が残ったままの文書をテンプレートとして再利用できる状態そのものが、リスクを内包していたこと。そしてもうひとつ、誤記載が発見された際に担当者へ確実に連絡が届く体制が整っていなかったこと、が挙げられていました。
三つめは、私の判断で落としています。時間外に担当者へ連絡を回す必要はありませんし、連絡経路の整備は発見後の対応に関わる話であって、誤送信そのものが起きた原因ではありません。AIの出力は、読むかぎり筋が通っています。それだけに、業務を知っている人間が読んで判断しなければ、原因ではないものが原因として記録に残ります。
再発防止策も変わりました。目視確認を徹底するのではなく、利用者情報が入力されていない原本を管理して毎回そこから作成する。過去の情報が残った文書を、そもそもテンプレートとして保存できない管理方法に変える。並べると、違いは一目で分かります。
| 最初に作った報告書 | 指示を詰めた報告書 | |
| 要因 | 差し替えを失念していた | 確認する手順が定められていなかった |
| 要因 | 送信前の確認が不十分だった | テンプレート運用そのものがリスクを内包していた |
| 対策 | 目視確認を必ず行うよう徹底する | 利用者情報が空欄の原本から毎回作成する |
左は人が気をつけることを求めていますが、右は、気をつけなくても間違えられない仕組みに変えようとしています。同じ事実から出発して、指示を変えただけで、ここまで違うものが出てきました。
私が驚いたのは、確認が必要な未処理事項として「誤記載された個人情報の範囲」と「本件を個人情報漏えい事案として内部報告する必要性」が挙がってきたことです。この事案で先方が管理者に直接連絡してきたのは、まさにそこを事案として捉えたからでした。当事者の位置から離れて見れば見えるものが、確かにあるということだと思います。
事実の側にも、足りないものがあった
もっとも、これで完成したわけではありません。作り直した報告書の発生要因のひとつには、送信前に確認する仕組みがあったかどうかについて情報がなく誤記載を発見できなかった、と書かれてきました。事実として間違ってはいないのですが、これでは報告書として使えません。なぜなら、手順がなかったのか、あったのに機能しなかったのかで、打つべき対策は正反対になるからです。
今度は、AIに渡した事実の側に原因がありました。何が起きたかは詳しく書いていたのに、そのとき事業所にどういうルールがあったのかを書いていなかったので、書かれていない以上、AIには判断のしようがなかったわけです。
そこで、報告書を作らせる前に、AIに聞き取りをさせる工程を挟むことにしました。職員が書いた事実をまず読ませたうえで、分析に足りない情報があれば質問させるという形です。実際にやってみると、送信前の確認ルールはあったのか、あった場合は実施されたのか、訂正後に先方での処理を確認したのか、という三つの質問が返ってきて、人が聞くとしてもまさにここを聞くだろうという内容でした。
この工程には、思っていた以上の効果がありました。質問されることで、報告する側が気づくのです。確認のルールがあったかと問われて初めて、そういえば決めていなかった、と認識する。ヒヤリハットが分析にならないのは、当事者が構造を意識しないまま書くからでしたから、聞かれること自体が、その構造に目を向けさせることになります。
聞き取りを挟んだうえで報告書を作らせると、要因は「確認体制が存在しなかった」と断定的に書かれるようになり、ようやく使えるものになりました。プロンプトを一度書いて完成することはまずなく、出てきたものを読んで、どこがおかしいのかを考え、指示を直すという作業が必ず要ります。この記事で紹介している形も、三回書き直した結果です。
やらせてよいことと、人が判断すること
ここまで書いておいて申し訳ないのですが、事業所の業務にAIを活用するには注意点があります。
ひとつは、AIに任せてよいのはヒヤリハットまでだということです。実際に事故が起きた場合の報告は行政に提出する文書であり、責任の所在にも関わってきます。分析の参考にAIを使うことはあっても、最終的な判断と記載は人が行うべきもので、この線は最初に引いておいてください。
もうひとつは、個人情報を入力しないことです。本記事で示した通り、固有名詞を落としても分析の質は落ちないのですから、落とす手間を惜しむ理由がありません。無料で使えるサービスの中には入力した内容が学習に使われるものもあるので、事業所として使うのであれば、利用規約と設定を確認したうえで、入力する情報の範囲を決めておく必要があります。
そしてもう一点、AIが出したものをそのまま報告書にすることはできません。実害があったかどうかのように、AIには分からない事実が必ず残ります。出てきたものを読んで、事実と違う箇所を直し、足りないところを埋める。その作業は人の仕事として残り続けます。
実際に使ったプロンプト
参考までに、実際に使っているものをそのまま載せます。動かしたのはMicrosoft 365のCopilotです。業務で使うツールを選ぶ理由は、性能よりも先に、事業所として安全性を説明できるかどうかにあります。Microsoft 365の商用データ保護の範囲で使えること、そしてWordファイルをそのまま読み込めることが、この業務では決め手になりました。
まず、職員が書いた事実を読ませて、足りない情報を聞き取らせる段階です。
あなたは介護事業所のリスクマネジメント担当者です。
これからヒヤリハットの事実確認を行います。
【進め方】
- 報告者が伝えた内容を読み、分析に必要な事実が不足している
場合のみ質問してください
- 質問は一度に3つまで。番号を振ってください
- 報告者を責める表現、原因を示唆する表現は使わないこと
- 十分な情報が集まったと判断したら、質問を終えて
事実の一覧を出力してください
【必ず確認する事項】
- 該当業務のルール・手順は存在したか
- 存在した場合、守られたか
- 守られなかった場合、守れない事情があったか
- 発覚の経緯と、その後の処理状況
【禁止事項】
- 個人名、事業所名が入力された場合は、利用者A・B事業所等に
置き換えて扱うこと
【報告者からの情報】
（ここに書ける範囲で貼る）
聞き取りが終わって事実の一覧が出力されたら、それを次のプロンプトに渡して報告書を作らせます。
あなたは介護事業所のリスクマネジメント担当者です。
以下の事実情報をもとに、ヒヤリハット報告書を作成してください。
【厳守事項】
- 記載されていない事実を推測して補わないこと
- 事実情報に「存在しなかった」「行われていなかった」と
明記されている事項は、不明としてではなく、
欠落していた事実として断定的に記載すること
- 事実情報に記載がなく、確認もされていない事項のみ
「未確認」と記載すること
- 当事者個人の注意不足を原因として記載しないこと
- 原因は「業務手順の欠落」「確認体制の不備」
「情報管理の仕組み」の観点から分析すること
【出力形式】
1. 発生状況（時系列で客観的に記述）
2. 発生要因（3つ以内。それぞれ手順・体制・仕組みの
どこに問題があったかを明示）
3. 再発防止策（要因ごとに対応。「注意する」「徹底する」等の
精神論を含めないこと）
4. 影響範囲（実害の有無、拡大の可能性）
5. 確認が必要な未処理事項
【事実情報】
（第1段階で出力された事実一覧を貼る）
事業所ごとに様式も業務も違うので、このまま使えるとは限りません。使うツールによっても、質問の切り込み方や指示の守り方に差が出ます。同じプロンプトを別のツールに入れて、まったく同じものが返ってくるわけではありません。出てきたものを読んで、指示を足したり削ったりして調整してください。その調整の過程そのものが、AIを業務に組み込むということだと思っています。
この考え方は、ヒヤリハットに限りません。事実と分析を分けること、個人情報を落として構造だけを渡すこと、聞き取りを挟んで足りない情報を埋めること。この三つが使える場面は、事業所の中にいくつもあります。
