ヒヤリハット報告を分類して、危険の傾向と対策候補を月次でまとめる

処理の起点を決める

トリガーは2つあります。

1つ目は、フォームが送信されたときです。Apps Script のインストール可能なトリガーには「フォーム送信時」があり、Googleフォームの回答が入るたびに関数を実行できます。1件ずつその場で分類します。

2つ目は、毎月1日の時間主導型トリガーです。Apps Script の時間主導型トリガーは最短で1分ごと、最長で月1回まで設定でき、月次のまとめはこれで動かします。

1件ずつ処理する設計にしてください。 月末にまとめて300件を処理する形にすると、API呼び出しが一度に集中して実行時間の上限に当たります。また、報告が入った時点で分類されていれば、危険度の高い報告をその日のうちに拾えるという副次的な効果があります。

なお、インストール可能なトリガーは作成した人のアカウントで動きます。 担当者が異動すると止まるので、共用アカウントか、部門の代表アカウントで作成してください。 失敗時はそのアカウント宛に通知メールが届きます。

入力データを集める

「事故の型」を自分で作らないでください。 厚生労働省の「職場のあんぜんサイト」では、ヒヤリ・ハット事例が事故の型別に整理されており、労働災害の統計もこの区分で公表されています。同じ区分を使えば、自社の傾向を公的な統計と比べられます。 自社独自の分類軸を作ると、比較する相手がいなくなります。

データの取得方法を決める

報告： Googleフォームの回答は、連携先のスプレッドシートに1行ずつ追加されます。Apps Script のフォーム送信トリガーで、追加された行を受け取ります。

起因物と場所の一覧： 設備台帳とレイアウト図から、名称と現場での呼び名（略称・通称）を対応づけた表を作ります。「3号機」「三号」「サンゴー」がすべて同じ設備を指すことを、あらかじめ表にしておく必要があります。これは1度作れば、設備を入れ替えたときだけ直します。

過去の報告： すでにスプレッドシートにあります。類似事例の照合に使います。件数が多いので、毎回15,000件を渡すのではなく、同じ工場・同じ事故の型のものに絞ってから渡します。

生成AIの呼び出し： Apps Script の UrlFetchApp.fetch() で Gemini API の generateContent を呼びます。リクエストには contents 配列にテキストを入れ、contentType を application/json にします。応答は candidates[0].content.parts[0].text で取り出します。APIキーはスクリプトプロパティに置き、コードに直接書かないでください。

AIへ渡す前に整形する

1. 個人が特定できる記述の除去 … 報告に「Aさんが」「◯◯班長が」といった記述が入ることがあります。AIに渡す前に、氏名と役職を除きます。 ヒヤリハット活動は報告者を責めない前提で成り立っており、個人名が集計に残ると報告数が落ちます
2. 場所の表記ゆれの正規化 … 「第2工場A棟」「2工場A」「2-A」をそろえます。対応表で機械的に置き換えます
3. 短すぎる報告の分離 … 「危なかった」だけの報告があります。分類できないので、AIには渡さず「情報不足」として担当者に回します
4. 重複の検出 … 同じ事象を複数人が報告することがあります。「同じ日・同じ場所・似た記述」で候補を出し、自動では統合せず担当者に判断を委ねます。統合すると件数が減り、現場の関心が下がります
5. 緊急度の一次判定 … 「けがをしていたら重大」と読める報告は、月次を待たず当日中に担当者へ通知します。分類の前にこの判定を通します

AIに処理させる

AIに対策を決めさせないでください。 対策候補を並べるところまでです。ヒヤリハットへの対策は、費用・工期・現場の運用・他の作業への影響を踏まえて安全衛生委員会が決めるものであり、記述だけから決められるものではありません。候補は「検討の出発点」として出させます。

「不安全行動／不安全状態」の判定は、使い方に注意が必要です。 これを個人の評価に使うと、報告が「自分のミスを申告する行為」になり、数が落ちます。この判定は、対策を人への教育に向けるか設備の改善に向けるかを決めるためだけに使ってください。

指示内容を固定する

あなたは製造業の安全衛生を担当する実務者です。
現場から上がったヒヤリハット報告を読み、決められた区分で分類してください。

【厳守事項】
- 事故の型は、下記の15区分からのみ選んでください。
  新しい区分を作らないでください。判断できない場合は「その他」とし、
  reason に判断できなかった理由を書いてください。
- 記述に書かれていないことを補わないでください。
  起因物や場所が書かれていない場合は null とし、
  needs_review に「起因物の記載なし」のように入れてください。
- 個人名、役職名、班名が含まれていた場合は、抽出結果に転記しないでください。
- 「不安全行動」「不安全状態」の判定は、記述に現れた事実だけから行ってください。
  報告者の不注意を推測しないでください。
  どちらとも言えない場合は both としてください。
- けがに至っていた可能性が高いと読める記述は、severity を high にしてください。
  判断に迷う場合は high にしてください。
- 類似事例は、意味が同じものだけを選んでください。
  同じ場所で起きただけの報告を類似として挙げないでください。

【事故の型（15区分）】
墜落・転落 / 転倒 / 激突 / 飛来・落下 / 崩壊・倒壊 / 激突され /
はさまれ・巻き込まれ / 切れ・こすれ / 高温・低温の物との接触 /
感電・火災 / 有害物との接触 / 交通事故 / 動作の反動・無理な動作 /
破裂 / その他

【自社の設備・場所の名称一覧（略称を含む）】
{equipment_and_locations}

【今回の報告】
発生日時: {occurred_at}
場所（報告者の記入）: {place}
何が起きたか: {description}
どうすればよかったか: {suggestion}

【過去の報告（同じ工場・直近3年、要約）】
{past_reports}

「新しい区分を作らないでください」の1行が重要です。 これを書かないと、「作業手順の不備」「注意不足」といった、事故の型とは別の軸の言葉が返ります。混ざると集計が崩れます。

「判断に迷う場合は high にしてください」も外せません。 重大さの判定は、安全側に倒す設計にします。担当者が後から下げるほうが、見落とすより安全です。

出力形式を固定する

{
  "accident_type": "",
  "accident_type_confidence": "high | medium | low",
  "causative_object": "",
  "causative_object_matched": "",
  "location": "",
  "process": "",
  "task_at_the_time": "",
  "time_band": "",
  "unsafe_factor": "action | condition | both",
  "severity": "high | medium | low",
  "similar_reports": [
    { "report_id": "", "reason": "" }
  ],
  "needs_review": [],
  "reason": ""
}

自由記述の要約は入れていません。 元の記述をそのまま台帳に残し、AIは分類のための項目だけを返す設計にしています。要約すると、後から読み返したときに現場の言葉が失われます。 「ガシャンと音がして振り向いたら」という記述が「異音を確認」に置き換わると、危険の実感が伝わらなくなります。

月次のまとめでは、別の呼び出しで次を返させます。

{
  "clusters": [
    {
      "theme": "",
      "report_ids": [],
      "count": 0,
      "trend": "increasing | flat | decreasing",
      "common_factor": "",
      "countermeasure_candidates": [
        { "approach": "設備 | 作業手順 | 教育 | 表示・標識", "content": "", "note": "" }
      ]
    }
  ],
  "new_themes": [],
  "recurring_after_countermeasure": []
}

recurring_after_countermeasure は、対策台帳に記録済みの対策が打たれた後に、同じ危険が再び報告されたまとまりです。ここに入ったものは、委員会で優先して扱う対象になります。この欄が、単発の対策で終わらせないための仕掛けです。

システムへ連携する

当日通知の設計が重要です。 月次でまとめるだけの構成にすると、重大なヒヤリハットが月末まで埋もれます。危険度の高いものは、その日のうちに現場へ返します。

人が確認する

全件を人が見る必要はありません。 ただし、次の3つは必ず人が確認します。

月300件のうち、この3つに当たるのは70〜90件程度が目安です。残りは確認なしで台帳に入れ、月次のまとめを作る段階で担当者が全体を見渡します。

「その他」の扱いを軽くしないでください。 既存の区分に収まらない報告が増えているとき、それは新しい作業や新しい設備が入ったサインであることがあります。件数が少なくても毎月確認します。

例外に対処する

記録を残す

• 報告の原文（要約せずそのまま）
• 分類結果と確信度、判断の理由
• 人が修正した項目と、修正前後の値
• 月次まとめのまとまりと、委員会での判断
• 対策台帳（対策の内容、対象となった報告、実施日）

2つ目と3つ目の組み合わせが、分類の基準そのものになります。 「台車と棚の接触は激突として分類する」という判断が積み上がれば、それをプロンプトの例示に加えることで、翌月以降の精度が上がります。担当者が2名いても基準がそろうのは、この仕組みがあるからです。

個人名は保存しません。 前処理で除いたうえで、除去前の原文も残さない設計にしてください。