建設現場で毎日手書きされる安全日誌を読み取り、作業内容・人数・指示事項・巡視の記録を現場ごとの記録データにそろえて、記入漏れと是正の未完了を拾う

処理の起点を決める

Apps Script の時間主導型トリガーで、毎日夜に1回動かします。 公式のページでは、時間主導型のトリガーは毎分から月1回までの間隔で設定でき、実行の時刻はわずかにずれることがあるとされています。日誌は夕方の片付けの後にスキャンされるので、夜に1回まとめて動かせば、翌朝に担当が出社したときには印が付いています。

数分おきにしないのは、日誌が1日の終わりにしか完成しないためです。 日中に書きかけの日誌がスキャンされることは少なく、夜にまとめて読めば、同じ現場の日誌を1日1回だけ照らせば済みます。 遅れて保存された日誌は、翌日の実行で拾います。

処理が終わったPDFは、現場ごとの「処理済み」フォルダへ移します。 移すのは、記録の表と台帳への書き込みが終わったときだけです。「受付」フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、現場の作業日のカレンダーです。 巡視の欄の空欄を拾うには、その日が作業日だったかが分からなければなりません。休工日の日誌が届かないことを「提出漏れ」と扱うと、毎週日曜に25現場分の印が付きます。

未完了の指摘を何日で確かめるかは、安全品質部で決めます。 この構成は決めた日数で機械的に印を付けるだけで、是正の期限そのものは、指摘したときに所長が決めた内容が台帳に入っている前提です。

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

Apps Script は、現場ごとの「受付」フォルダの getFiles() で新しいPDFを探し、Form Parser のプロセッサに送ります。日誌は1枚か2枚なので、最大15ページのオンラインの処理で足ります。

公式のページでは、Form Parser の表のセルの rowSpan と colSpan は常に1とされています。2行にまたがって書かれた作業内容は、2つの行に分かれて返ることがあり、2行目は会社名と人数が空の行になります。これを1つの行に戻すのは、次の生成AIの仕事です。

未完了の指摘の一覧は、その現場の分だけを指摘台帳から読みます。 他の現場の指摘を混ぜると、似た指摘（「開口部の養生」はどの現場にもあります）を別の現場の是正と結びつけてしまいます。

AIへ渡す前に整形する

1. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。現場の複合機の出力はPDFにそろえます
2. 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。現場の複合機の既定の設定を300dpiに変えてもらいます
3. 現場の決定 … 保存されたフォルダから現場コードを決めます。日誌の現場名の欄は照らし合わせに使うだけにします
4. 日付の確認 … 日誌の日付と保存した日が大きく離れていれば、前の日の書き忘れか、日付の書き間違いの印を付けます
5. 重複の確認 … 同じ現場・同じ日付の日誌が2枚あれば、書き直しか二重のスキャンかを担当に確かめる印を付けます
6. 未完了の指摘を添える … その現場の未完了の指摘を、番号・指摘日・指摘事項・場所だけにして添えます

3番目でフォルダから現場を決めるのは、日誌の現場名が略称で書かれることが多いためです。 「○○マンション新築」が「○○M」と書かれていても、保存されたフォルダが現場を決めます。 現場名の欄とフォルダが食い違ったときだけ、印を付けます。

AIに処理させる

させるのは2つです。読み取り結果を記録データの行に書かれたとおりに写すことと、未完了の指摘について、是正の済みがはっきり書かれた記述を探して写すことです。 人数の合計、巡視の空欄、未完了の日数は、Apps Script の規則で確かめます。

5行目が、AIを使う理由です。 是正の記載は「昨日指摘の2F東開口部、手すり復旧済み」のように、台帳の指摘事項とは違う言葉で書かれます。 どの指摘のことかを場所と内容から結びつけるのは、決まった規則では書きにくい作業です。

2行目がいちばん大事です。 「開口部の養生を確認」は、手すりを戻したことを意味するとは限りません。「確認」「点検」「注意した」を是正済みと読むと、直っていない開口部が台帳の上で閉じられます。 そうした記述は unclear にして、人が日誌を読んで決めます。

指示内容を固定する

あなたは建設会社の安全品質部の担当で、現場の安全日誌の読み取り結果を、
記録データに写す立場です。OCRが返した結果だけを見て、
書かれていることを写してください。推測で埋めないでください。

【写す項目】
見出し：diary_date、weather、total_workers、new_entrants
協力会社の行：company_text（書かれたとおり）、trade、workers、work、place
巡視：patrol_time、patrol_by、finding、instruction、checked（□の印）

【厳守事項】
- 人数は書かれたとおりの文字列で写してください。
  協力会社ごとの人数の合計と total_workers が合わなくても、直さないでください。
- 会社名は書かれたとおりに写してください。正式な社名に直さないでください。
- 欄が空欄なら blank、文字はあるが読めなければ unreadable にしてください。
- 作業内容が2行に分かれ、2行目の会社名と人数が空のときは、
  前の行の続きとしてつなげてください。つなげられなければ
  table_broken を true にし、無理に行を作らないでください。
- 巡視の記録が何も書かれていなければ patrol_blank を true にしてください。

【是正の記載の探し方】
下の「未完了の指摘」それぞれについて、この日誌の中に、
その指摘が直された・是正された・復旧したとはっきり書かれた記述があれば、
mentions に指摘の番号と、その記述をそのまま写してください。
- 「確認した」「点検した」「注意した」「指導した」だけの記述は、
  直したことにはなりません。status を unclear にしてください。
- 場所か内容のどちらかしか一致しない記述も unclear にしてください。
- 該当する記述が無ければ no_mention にしてください。
- 是正済みかどうかの結論は書かないでください。

【未完了の指摘】{open_findings}
【読み取り結果】{ocr_result}

「確認した」を是正と読まない、を名指しで書いているのは、日誌にこの言葉がいちばん多く出るためです。 何も言わなければ、指摘と同じ場所で「確認」と書かれた記述を、是正の記載として返します。禁じたい言葉を並べることで、unclear の側に倒します。

未完了の指摘をAIに渡しているのは、結びつけのためだけです。 指摘の一覧を見せると「どれかは直っているはず」と寄せる心配がありますが、記述をそのまま写させ、結論を書かせないことで、寄せた結果が台帳に入らないようにしています。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力（/v1beta/interactions に response_format として mime_type: application/json と schema を渡す方式）を使い、形を固定します。

{
  "document_type": "safety_diary",
  "header": [
    { "item": "diary_date | weather | total_workers | new_entrants",
      "value": "", "status": "read | blank | unreadable" }
  ],
  "companies": [
    { "company_text": "", "trade": "", "workers": "", "workers_status": "read | blank | unreadable",
      "work": "", "place": "" }
  ],
  "table_broken": false,
  "patrol_blank": false,
  "patrols": [
    { "patrol_time": "", "patrol_by": "", "finding": "", "instruction": "", "checked": "filled | unfilled | unclear" }
  ],
  "mentions": [
    { "finding_no": "", "status": "mentioned | unclear | no_mention", "evidence": "" }
  ]
}

1つ目の理由は、記録の表と指摘台帳に書き分けられることです。 companies は現場ごとの記録の表へ、patrols の新しい指摘は指摘台帳の新しい行へ、mentions は台帳の既存の行の「確認待ち」の列へ入ります。

2つ目は、確かめを Apps Script の規則で持てることです。

overdue と no_patrol は、他の印より先に担当に出します。 どちらも、現場の所長にその日のうちに確かめる必要がある印です。

公式のページでは、出力は構文として正しいJSONになるが、値の正しさはアプリケーションの側で確かめる必要があるとされています。finding_no が渡した未完了の指摘の一覧に無い番号なら、その行は捨てて check_mention にします。

システムへ連携する

指摘台帳の「状態」の列には、この構成から書き込みません。 書き込むのは「確認待ち」の列だけで、状態を「是正済み」に変えるのは、日誌の記述を確かめた担当の操作だけです。

現場への問い合わせも、この構成からは送りません。 所長に何を確かめるかは、印を見た担当が決めます。

人が確認する

本社の安全の担当が見るのは、印の付いた行だけです。 印の無い日誌は、現場ごとの件数を流し見て確認済みにします。

1. overdue と no_patrol を先に見る … 現場の所長に、指摘が是正されたか、巡視をしたかを確かめます
2. close_candidate を見る … evidence の一文を日誌の写しで確かめ、直したことが読み取れれば台帳を是正済みにします
3. check_mention を見る … 「確認した」などの記述を読み、必要なら所長に是正の状況を聞きます
4. count_mismatch と company_unknown を見る … 書き落としの会社がないかを確かめ、呼び名の一覧に新しい書き方を足します
5. check_image と incomplete を見る … 写しの該当箇所を読み、読めないものは推測せず現場に確かめます

目標は、480件をならして1件2分です。 印の無い日誌は流し見で数十秒、overdue や close_candidate の付いた日誌は台帳と見比べるので数分かかります。

例外に対処する

2行目が、この構成の数字を守る行です。 行がずれたまま写すと、ある会社の人数が隣の会社に付き、その日その会社が何人で何をしていたかの記録が入れ替わります。

記録を残す

• 元の日誌のPDFと、保存した日時・保存したフォルダ
• OCRが返したJSONの全文と、Gemini API の応答の全文
• 照らすときに渡した未完了の指摘の一覧（そのときの台帳の状態）
• 担当が台帳を是正済みにした記録 … どの指摘を、どの日誌のどの記述で、いつ、誰が
• 付いた印と、所長への確認の結果
• 現場ごとの no_patrol と overdue の件数

4つ目が、この構成でいちばん大事な記録です。 指摘が是正済みになった根拠が日誌のどの一文かが残っていれば、後で同じ場所で災害が起きたとき、いつ誰がどの記述で閉じたかを説明できます。

最後の行は、月次の安全衛生協議会の資料になります。 巡視の空欄や是正の遅れが特定の現場に偏っていれば、その現場の体制に理由があります。