建設現場で毎朝手書きされる危険予知（KY）活動表を読み取り、危険のポイントと対策を工種・事故の型で分類して、対策の書き漏れと毎月の危険の傾向を安全担当へ出す

処理の起点を決める

職長が危険予知活動の後に、表をスマートフォンで撮って現場ごとの取込フォルダに保存することを起点にします。 現場事務所にスキャナが無いことが多いため、撮影を前提にします。ファイル名は「現場コード_日付_班名」にし、共有ドライブのアプリから保存します。

Apps Script の時間主導型トリガーが、15分おきに10現場の取込フォルダを順に見ます。 朝の危険予知活動は8時台に集中するので、9時から11時のあいだに大半の表が届きます。 1回の実行で扱う枚数に上限を置き、残りは次の実行に回します。処理済みのフォルダへ移すのは、台帳への書き込みまで成功したときだけです。取込フォルダに残っている枚数が、そのまま未処理の枚数になります。

11時を過ぎても表が1枚も届いていない現場は、所長に知らせます。 撮り忘れなのか、雨天で作業が中止なのかは、この仕組みからは分かりません。届いていないことを知らせるだけにして、理由は所長が返します。

入力データを集める

質を決めるのは、事故の型の決まりの一覧です。 職場のあんぜんサイトは、事故の型を「傷病を受けるもととなった起因物が関係した現象」と説明し、複数の型が競合する場合は災害防止対策を考える上で主要なものを選ぶとしています。どれを主要とするかは、自社で例を挙げて決めておかないと、AIも人も毎回違う答えを出します。

現場の工程は、工種の手がかりに使います。 「上の階で作業」としか書かれていない表でも、その日の工程が型枠の建込みなら、型枠の工種の候補として扱えます。 ただし、工程から工種を決めつけず、AIには候補として渡します。

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

読み取りは、Apps Script から Document AI の処理の API を呼ぶだけです。画像を渡すと、Document という形の応答が返ります。

行を「危険のポイントと対策の組」にまとめるのは Apps Script です。 同じ行の「危険のポイント」の升と「対策」の升を1組にし、組の番号を振ってから AI に渡します。 どの危険にどの対策が対応するかを AI に推し量らせると、空いていた対策の升が、隣の行の対策で埋まってしまいます。

署名の欄は、人数だけを数えます。 署名の文字を読んで氏名にする必要はありません。欄に何かが書かれている升の数を、表の上の「作業人数」と比べるだけです。 氏名を読まないので、AIに作業員の名前を渡さずに済みます。

AIへ渡す前に整形する

1. 形式の確認 … Document AI の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。スマートフォンの写真の JPEG はそのまま入れられます
2. 画質の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。A4の表を枠いっぱいに撮るよう、撮り方を1枚の紙で職長に配ります
3. 圧縮の確認 … 非可逆の形式は、ファイルを小さくすると画質と精度が落ちることがあるとされています。チャットのアプリで送り直した画像は使いません
4. 様式の確認 … 表の四隅にある様式の番号を読み、旧い様式は別の扱いにします
5. 向きと傾きの確認 … 斜めに撮った画像は、向きを直してから入れます
6. 重複の検知 … 同じ現場・日付・班の画像が2枚あれば、後のものを「撮り直し」として扱います

4番目のために、様式そのものを直します。 活動表によくある「危険のポイント」の升を2行にまたがせる作り、「指差し呼称　実施・未実施」を○で囲む作りは、Form Parser の苦手なところにそのまま当たります。行をまたぐセルを無くし、○で囲む欄を □ に変えた様式を1つ作り、全現場で使います。

AIに処理させる

させるのは、Apps Script がまとめた「作業／危険のポイント／対策」の組ごとに、工種と事故の型を選び、対策の書き方に印を付けることだけです。

事故の型は、危険のポイントの「〜になる」の部分で選ばせます。 危険予知活動の危険のポイントは、職場のあんぜんサイトの説明でも「危険要因とその要因がひきおこす現象」を出し合うものとされています。「脚立の天板に乗るので、バランスを崩して落ちる」なら、選ぶ手がかりは「落ちる」です。

vague の印は、対策の良し悪しではありません。 「足元に注意する」は、その班にとって十分な対策かもしれません。AIが見るのは、行動の形（〜を使う、〜を置く、〜してから〜する）で書かれているかどうかだけです。

2行目がいちばん起きやすい失敗です。 「足場の上で鉄筋を運ぶ」と書かれた表を渡すと、AIは書かれていない「飛来・落下」の危険まで挙げようとします。挙げれば役に立ちそうに見えますが、それをすると「班が何を予想したか」の記録ではなくなります。

指示内容を固定する

あなたは建設会社の安全環境部で、現場の危険予知活動表を分類する立場です。
渡すのは、表の行を「作業／危険のポイント／対策」の組にまとめた読み取り結果です。
書かれている文字だけを見て分類してください。推測で埋めないでください。

【やること】組ごとに次を付けてください。
1. trade：工種の一覧から1つ。当たらなければ unclear
2. accident_type：事故の型の一覧から1つ。危険のポイントのうち
   「〜になる」「〜する」にあたる現象の部分で選んでください。
   現象が書かれていなければ unclear
3. accident_evidence：型を決めた根拠の文字列をそのまま写す
4. measure_style：concrete／vague／empty／unreadable
   - concrete … 何を使う、どこに置く、何をしてから何をする、が書かれている
   - vague ……… 「注意する」「気をつける」「確認する」だけで行動が書かれていない
   - empty ……… 対策の欄に文字が無い
   - unreadable … 文字はあるが読み取りの信頼度が低く確定できない
5. measure_text：対策の欄の文字列をそのまま写す

【厳守事項】
- 書かれていない危険を足さないでください。組の数を増やさないでください。
- 対策が空なら empty とし、他の行の対策で埋めないでください。
- 対策が十分かどうかは書かないでください。vague は書き方の印です。
- 型が2つ考えられるときは、事故の型の決まりの一覧に従ってください。
  一覧に無い組み合わせなら unclear にし、候補を note に書いてください。
- 工程表の工種は候補です。表に書かれた作業内容と食い違うときは、
  表の作業内容を優先し、note に食い違いを書いてください。
- 作業員の氏名や職長への評価を書かないでください。

【工種の一覧】{trades}
【事故の型の一覧と決まり】{accident_rules}
【その日の工程の工種（候補）】{schedule_trades}
【読み取り結果】{rows}

「書かれていない危険を足さない」を最初に書いているのは、AIが親切に危険を補うからです。 補われた危険は、もっともらしいほど目立ちません。月末の集計に「班が予想していなかった危険」が混ざると、集計の意味が逆になります。

型が2つ考えられるときの扱いを、一覧に委ねているのも同じ理由です。 その場で選ばせると、日によって選び方が変わります。決まりを一覧に書き、一覧に無ければ unclear にして人に回します。

出力形式を固定する

Claude API の構造化出力を使い、次の形のJSONで受け取ります。 output_config.format に JSON スキーマを渡すと、応答がそのスキーマに沿った形になります。

{
  "sheet_id": "S07_20261007_tobi",
  "rows": [
    {
      "row_no": 1,
      "work": "3階床 型枠の建込み",
      "trade": "型枠",
      "accident_type": "墜落・転落",
      "accident_evidence": "開口部から落ちる",
      "measure_style": "concrete",
      "measure_text": "開口部に蓋をしてから作業する",
      "note": ""
    },
    {
      "row_no": 2,
      "work": "資材の荷揚げ",
      "trade": "unclear",
      "accident_type": "飛来・落下",
      "accident_evidence": "上から材料が落ちてくる",
      "measure_style": "vague",
      "measure_text": "上下作業に注意する",
      "note": "工程表は型枠。表の作業内容からは工種を決められない"
    }
  ]
}

1つ目の理由は、Apps Script がそのまま規則にかけられることです。 measure_style が empty の行があれば no_measure、vague だけの表は vague_measure として、同じ規則で全現場を振り分けます。

2つ目は、trade と accident_type を列挙の値に固定できることです。 スキーマの enum に工種の一覧と21分類を並べれば、「墜落」「転落・墜落」のような書き方の揺れが集計に入りません。 ただし公式は、列挙の値の大文字・小文字までは保証しないとしているので、照合は書き方の揺れを許す形で行います。

3つ目は、stop_reason で失敗を見分けられることです。 公式には、応答が max_tokens で打ち切られたときや断ったときは、スキーマに合わない出力になりうるとされています。Apps Script は stop_reason を見て、そのときは台帳に書かずにやり直します。

システムへ連携する

台帳は、行ごとに1行にします。 1枚の表が4行なら4行です。月末の集計は、この台帳の工種と事故の型を数えるだけになります。 災害とヒヤリハットの記録も同じ事故の型の列を持つので、同じ升目で並べられます。

当日の通知に入れるのは、表の画像へのリンクと、どの行の何が空いているかだけです。 AIが付けた事故の型は通知に入れません。所長が見るべきなのは「対策が書かれていない行がある」という事実で、分類の正しさを現場で議論させないためです。

人が確認する

1. 所長が当日の通知を見る … no_measure と no_signature は、職長に聞いて書き足すか、話し合った内容を通知の返信に書きます
2. 安全担当が unreadable と unclear を見る … 画像を開き、読み取りと分類を直します。直した結果は台帳に「人が直した」として残します
3. 安全担当が vague_measure を週に1回まとめて見る … 同じ職長に続いていれば、巡回の日に書き方を一緒に考えます
4. 月末の集計を読む … 件数の多い組み合わせだけでなく、災害やヒヤリハットが多いのに表に挙がっていない組み合わせを探します

2番目の直しを残すのは、決まりの一覧を育てるためです。 人が直した組み合わせを月に一度見直し、同じ直しが3回あれば一覧に決め方を書き足します。 そうすると unclear が減っていきます。

安全担当が開くのは、ならして全体の2割前後という想定です。 それより多い月は、撮り方が崩れているか、新しい協力会社が入って書き方が変わっています。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、撮り方と様式の問題です。 判定の精度を上げるより、様式を直して撮り方の紙を配るほうが効きます。

記録を残す

• 活動表の画像と、現場コード・日付・班名・取り込んだ時刻
• Document AI が返したJSONの全文
• Claude API に渡した組と、返ってきた分類の全文、stop_reason
• そのとき使った工種の一覧と事故の型の決まりの版
• 表の判定と、当日の通知を送った時刻、所長の返信
• 人が直した分類（どの行を、何から何へ）

4つ目で一覧の版を残すのは、決まりが後から変わるためです。 「脚立からの転落」の扱いを変えると、過去の月との比べ方が変わります。当時の版が残っていないと、前月との差が決まりの変更によるものか、現場の変化によるものかが分かりません。

署名の升は数だけを残し、氏名は保存しません。