ヒヤリハット情報のRAG化が注目される理由
現場に蓄積されたヒヤリハット報告は、事故を未然に防ぐための重要な知識資産です。厚生労働省の「職場のあんぜんサイト」でも、墜落・転落、転倒、はさまれ・巻き込まれなど、事故の型別にヒヤリハット事例が整理されており、安全管理において事例検索が重要であることがわかります。
しかし、企業内のヒヤリハット情報は、紙、PDF、Excel、Word、メール、現場メモなどに分散していることが少なくありません。さらに、報告者ごとに表現が異なり、「台車」「カート」「運搬車」のような言い換えも発生します。そのため、単純なキーワード検索だけでは、似たリスクや過去の再発防止策にたどり着けないケースがあります。
そこで注目されるのが、RAGです。RAGは、社内文書などの外部知識を検索し、その内容を生成AIの回答に反映させる仕組みです。Microsoftは、RAGを「独自コンテンツに基づいてLLMの能力を拡張するパターン」と説明しており、企業内情報をAI活用につなげる基盤として位置づけています。
ただし、ヒヤリハット情報をRAG化する場合、「文書を読み込ませれば終わり」ではありません。重要なのは、現場の曖昧な報告を、検索しやすく、比較しやすく、再発防止に使えるデータへ整えることです。
ヒヤリハット報告はなぜ検索しにくいのか
ヒヤリハット報告には、一般的な業務文書とは異なる特徴があります。多くの場合、報告文には「いつ」「どこで」「誰が」「何をしているときに」「なぜ起きそうになったのか」「どう防いだのか」といった5W1Hに近い情報が含まれます。
ところが、実際の報告文では、これらの要素が必ずしも明確に分かれていません。
たとえば、「朝の出荷作業中に、通路で台車と接触しそうになった」という文には、時間、場所、作業内容、対象物、危険の種類が含まれています。しかし、検索システム側から見ると、「出荷作業」「通路」「台車」「接触」「朝」という情報を適切に抽出しなければ、似た事例を見つけにくくなります。
さらに、ヒヤリハット報告には、現場特有の略語や社内用語も混ざります。「1号ライン」「南側倉庫」「検品前置き場」のような表現は、外部の一般的なAIモデルだけでは正確に理解できないことがあります。だからこそ、RAG化の前段階で、社内の用語、工程、設備、部門名を整理する必要があります。
RAG化の第一歩はデータクレンジング
ヒヤリハット情報のRAG化では、最初にデータクレンジングを行います。これは、検索やAI回答の精度を下げるノイズを取り除き、文書を扱いやすい状態に整える作業です。
紙の報告書をOCRで読み取った場合、文字化けや誤認識が発生します。「5S」が「SS」に見えたり、「フォークリフト」が途中で改行されて別語として扱われたりすることもあります。こうしたノイズが残ったままベクトル化すると、検索結果の精度が落ちる可能性があります。
また、表記ゆれの統一も重要です。「ヒヤリハット」「ヒヤリ・ハット」「ヒヤリ・ハット報告」のように表記が揺れると、キーワード検索では取りこぼしが起きます。設備名、作業名、部署名、事故の型、原因分類などは、できるだけ標準表記を定めておくべきです。
もう一つ重要なのが、個人情報や機密情報の扱いです。ヒヤリハット報告には、氏名、部署、取引先名、製品名、現場写真などが含まれる場合があります。RAGシステムに投入する前に、匿名化、マスキング、アクセス制御の方針を決めておく必要があります。IBMも、RAGは外部知識とモデルを分けて扱える一方で、外部データベース自体の保護が重要であると指摘しています。
5W1Hで整理すると検索精度が上がる
ヒヤリハット報告をRAGに適したデータへ変換するには、5W1Hを軸に情報を整理すると効果的です。
具体的には、次のような項目を持たせます。
| 整理項目 | 内容 |
|---|---|
| 発生日時 | いつ発生したか |
| 発生場所 | どこで発生したか |
| 作業内容 | 何をしていたか |
| 対象物 | 何が関係したか |
| 危険の型 | 転倒、接触、巻き込まれ、落下など |
| 発生原因 | なぜ起きそうになったか |
| 再発防止策 | どう改善したか |
このように構造化しておくと、「フォークリフト」「倉庫」「夕方」「接触リスク」のような複数条件で検索しやすくなります。
単に本文をベクトル検索するだけでは、「似た文章」は見つかっても、「同じ事故の型」「同じ設備」「同じ作業工程」の事例を確実に集められるとは限りません。本文検索とメタデータ検索を組み合わせることで、実務で使える検索基盤に近づきます。
メタデータ設計がRAGの品質を左右する
RAG化で見落とされがちなのが、メタデータ設計です。メタデータとは、文書そのものに付与する分類情報のことです。
ヒヤリハット情報であれば、「事故の型」「主原因」「副原因」「発生場所」「対象者」「設備分類」「工程」「地域」「部署」などが候補になります。たとえば、同じ「転倒」でも、濡れた床が原因なのか、段差が原因なのか、急いでいたことが原因なのかによって、再発防止策は変わります。
この分類が粗すぎると、検索結果が広がりすぎます。反対に、分類が細かすぎると、入力作業が増え、現場で運用されなくなります。実務では、最初から完璧な分類体系を作るよりも、PoC段階では必要最低限の分類から始め、検索ログや利用者の声を見ながら改善する方が現実的です。
チャンク分割では「原因」と「対策」を切り離さない
RAGでは、文書を小さな単位に分割して検索しやすくします。この分割単位をチャンクと呼びます。
ヒヤリハット報告をチャンク化する際に注意したいのは、「状況」「原因」「再発防止策」を不自然に分断しないことです。たとえば、報告書の前半に「台車と接触しそうになった状況」があり、後半に「通路幅を確保し、置き場を変更した」という対策が書かれている場合、両者が別々のチャンクに分かれると、AIが原因と対策の関係を正しく把握しにくくなります。
そのため、ヒヤリハット情報では、固定文字数だけで機械的に分割するよりも、報告単位、見出し単位、5W1H単位で分割する方が向いています。IBMも、チャンクが大きすぎると検索クエリに対応しにくくなり、小さすぎると意味のまとまりを失う可能性があると説明しています。
ベクトル検索だけでなくハイブリッド検索を使う
RAGというと、ベクトル検索を思い浮かべる人が多いかもしれません。ベクトル検索は、意味が近い文書を探すのに向いています。たとえば、「荷物を運んでいるときにぶつかりそうになった」と検索した場合、「台車との接触」「運搬中のヒヤリハット」といった似た意味の事例を見つけやすくなります。
一方で、ヒヤリハット情報では、型番、設備名、工程名、場所名など、正確な文字列一致が重要な場面もあります。「A棟3階」「第2ライン」「フォークリフト3号機」のような情報は、意味検索だけでは取りこぼす可能性があります。
そのため、実務ではベクトル検索とキーワード検索を組み合わせるハイブリッド検索が有効です。MicrosoftもRAGの課題として、曖昧な質問への対応、複数データソース、トークン制約、応答速度、セキュリティとガバナンスを挙げており、単純な検索だけでは不十分であることがわかります。
GraphRAGやリランキングで関係性を扱う
ヒヤリハット情報では、個別の報告を検索するだけでなく、「どの設備で同じ原因が繰り返されているか」「どの工程で似たリスクが集中しているか」を把握することも重要です。
このような関係性を扱うには、GraphRAGの考え方が役立つ場合があります。GraphRAGでは、設備、作業、原因、対策、部署などをノードとして整理し、それらの関係をたどりながら情報を検索します。
たとえば、「台車」「通路」「接触」「置き場変更」「朝の出荷作業」がつながっていれば、単なる文章検索よりも、再発しやすい構造的なリスクを見つけやすくなります。
また、検索結果をそのままAIに渡すのではなく、リランキングを行うことも重要です。リランキングとは、最初に広く取得した候補の中から、質問により合う情報を並べ替える処理です。安全管理では、関係の薄い事例が上位に出ると、現場の信頼を失いやすくなります。検索精度の改善は、RAG活用を定着させるうえで欠かせません。
生成AIの回答には根拠文書を表示する
ヒヤリハットRAGの目的は、AIにもっともらしい回答をさせることではありません。現場が「どの過去事例を根拠に判断すればよいか」を確認できるようにすることです。
そのため、回答画面では、参照した報告書名、発生日、現場、該当箇所を表示する設計が望ましいです。IBMも、RAGでは回答に引用元を含めることで、利用者が出力内容を検証しやすくなると説明しています。
たとえば、AIが「同様の事例では、通路上の一時置き場を廃止し、床面表示を追加した対策が取られています」と回答する場合、その根拠となった過去報告をすぐ確認できるようにします。
安全管理では、「AIが言ったから」では不十分です。人が確認し、判断し、必要に応じて現場に合わせて修正する仕組みが必要です。
ヒヤリハットRAGの導入ステップ
実務で導入する場合は、いきなり全社展開を目指すより、小さく始める方が安全です。
まず、対象範囲を絞ります。たとえば、製造現場の転倒事例、物流現場の接触事例、介護現場の転落リスクなど、1テーマに限定します。次に、既存の報告書を集め、OCR、表記ゆれ補正、個人情報の除去、5W1H整理を行います。
その後、メタデータを付与し、チャンク分割、ベクトル化、検索テストを行います。現場担当者に実際に検索してもらい、「欲しい事例が出るか」「不要な事例が混ざりすぎないか」「回答文は使いやすいか」を確認します。
最後に、検索ログやフィードバックをもとに、分類項目、チャンク設計、プロンプト、検索条件を改善します。RAGは一度作って終わりではなく、使いながら精度を上げていくシステムです。
セキュリティとガバナンスを最初から設計する
ヒヤリハット情報には、事故やミスに近い内容が含まれます。扱いを誤ると、個人の責任追及、現場の萎縮、情報漏えいにつながる恐れがあります。
そのため、RAG化では、技術設計と同じくらいガバナンス設計が重要です。誰が閲覧できるのか、どの部署の情報まで検索できるのか、外部AIサービスに送信してよい情報は何か、ログをどう保管するのかを明確にします。
NISTの生成AI向けAIリスクマネジメントフレームワークは、生成AIシステムの設計・開発・利用・評価において、信頼性やリスク管理を組み込むことを目的としています。 ヒヤリハットRAGでも、精度だけでなく、説明可能性、アクセス制御、監査性、人による確認を含めて設計する必要があります。
ヒヤリハットRAGは「安全知識の検索基盤」である
ヒヤリハット情報のRAG化は、単なるAIチャットボットの導入ではありません。現場に眠っている安全知識を、必要なときに取り出せる形に変える取り組みです。
そのためには、報告書をそのまま読み込ませるだけでは不十分です。5W1Hで整理し、表記ゆれを直し、個人情報を守り、メタデータを付与し、意味のまとまりを壊さないようにチャンク化し、ベクトル検索とキーワード検索を組み合わせる必要があります。
さらに、根拠文書を表示し、人が最終判断できるUIを整えることで、現場に信頼される仕組みになります。
ヒヤリハットRAGの本質は、AIに安全管理を任せることではありません。過去のヒヤリハットを、未来の事故防止に活かすための「知識基盤」をつくることです。安全管理担当者、現場リーダー、教育担当者が同じ情報を参照できるようになれば、属人的だった安全ノウハウを組織全体で共有できる可能性があります。
まとめ
ヒヤリハット情報をRAG化するには、検索エンジンや生成AIを導入する前に、データ整理の設計が欠かせません。特に重要なのは、5W1Hによる構造化、メタデータ設計、チャンク分割、ハイブリッド検索、根拠表示、アクセス制御です。
RAGは、ヒヤリハット報告を「保管するだけの記録」から「再発防止に使える知識」へ変える可能性があります。ただし、現場の安全に関わる情報だからこそ、AIの回答を鵜呑みにせず、人が確認し、継続的に改善する運用体制が必要です。
次の研究テーマとしては、ヒヤリハットRAGの精度評価、現場教育への活用、事故報告書との連携、匿名化ルール、GraphRAGによるリスク構造分析などを掘り下げると、実務に近い議論へ発展できます。
コメント