建設現場で協力会社から届く作業員名簿と資格者証・健康診断の写しを読み取り、入場前に資格と受診日の不足を点検して、差し戻しの連絡を作る

処理の起点を決める

30分おきの定時実行にします。 協力会社は名簿と写しを何回かに分けて入れることが多く、ファイルが入るたびに動かすと、写しがまだ届いていないだけの作業員を「不足」として差し戻してしまいます。

そこで、最後のファイルが入ってから30分以上たった協力会社の束だけを対象にします。 途中でファイルが増えた束は次の回に回します。

入場予定日の前々日の夕方には、未処理の束をまとめて流す回を足します。 処理済みの印は、判定と下書きまで作れたときだけ付けます。

入力データを集める

質を決めるのは、作業と必要な資格の表です。 労働局の「資格が必要な業務（免許・技能講習）一覧表」では、たとえば車両系建設機械（整地・運搬・積込用、掘削用）は機体重量3トン以上が技能講習、3トン未満は特別教育、玉掛けは1トン以上が技能講習、高所作業車は作業床の高さ10メートル以上が技能講習とされています。この境目を自社の表に写し、名簿の「作業の内容」の書き方とつなぎます。

名簿の作業の書き方は協力会社によって違い、「バックホウ」「ユンボ」「重機オペ」が同じ作業を指していることがあります。表には、現場で使われている呼び方の一覧も持たせます。

健康診断は、定期のものが1年以内ごとに1回、特定の業務に就く人は6か月以内ごとに1回の実施とされています。 どちらの基準で見るかは、作業の内容から規則で決めます。

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

Enterprise Document OCR には、次の2つを指定して送ります。

Form Parser からは、次の3つを取ります。

表のセルには rowSpan と colSpan が付き、単純な表では常に1です。 名簿のページで表が1つも返らないか、行の数が名簿の人数より明らかに少ないときは、表として取れなかったとみなし、OCRの全文を生成AIに渡します。

スキャンは最低200dpi、できれば300dpi以上で取ります（Document AI の案内）。現場の複合機の既定の設定を最初に確かめてください。

AIへ渡す前に整形する

1. 形式をそろえる … Document AI が受け付ける画像は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などで、HEIC は対応形式に含まれていません。 スマートフォンの HEIC の写真は JPEG に変えます
2. むやみに圧縮しない … 非可逆の形式でファイルを小さくすると、画像の品質と読み取りの精度が落ちるとされています。変換は1回だけにします
3. ページ数で分ける … 同期の処理は1回に15ページまでです。数十ページのまとめスキャンは、15ページずつに分けて送ります
4. 品質の足りないページを分ける … qualityScore が0.5を下回ったページは、不具合の種類とともに撮り直しの候補にし、後段に送りません
5. 健診の結果の欄を覆う … 健康診断の写しと分かったページは、氏名・受診日・実施機関の欄の位置だけを残し、ほかの領域を塗りつぶした画像を作り直してから Form Parser に送ります
6. 同じ写しの重複を落とす … 前回の入場で出された写しが、また入っていることがあります。画像の近さで重複を見つけます

5番目は、OCRの文字の位置で行います。 「受診日」「氏名」の語が見つかった行の周りだけを残し、見つからなかったページは needs_human に回します。 結果の欄が生成AIに渡る経路を残さないためです。

4番目で送らないのは、読めないページの値を使わないためです。 反射で「技能講習」の文字が取れなかった修了証を特別教育の修了証と扱うと、不要な差し戻しになります。

AIに処理させる

生成AIにさせるのは、書類の種類の判定と、決まった項目の取り出しだけです。

表の右端が、この構成で大事な区別です。 missing は読めたうえで書かれていないこと、unreadable は品質不足のページにあったか、値として確定できないことです。前者は写しの出し直し、後者は撮り直しに回ります。

いちばん起きやすい失敗は、表の3行目です。 名簿に「バックホウ 0.45」とあると、生成AIは容量から機械の大きさを推測し、「技能講習が必要」と書きたがります。大きさは協力会社か現場の機械の一覧で確かめる情報で、名簿から分からなければ分からないまま人に渡します。

指示内容を固定する

あなたは建設会社の安全書類の受付で、協力会社から届いた
作業員名簿と添付の写しを読む担当です。
渡された読み取り結果だけを見て、項目を取り出してください。
判断や計算はしないでください。

【書類の種類】
- roster       : 作業員名簿
- certificate  : 技能講習修了証、特別教育の修了証、免許証などの資格の証
- health_check : 健康診断の写し（結果の欄は覆い隠されています）
- other        : それ以外
other の書類からは項目を取り出さないでください。

【取り出す項目】
roster ……… 作業員ごとに、氏名、生年月日、作業の内容、名簿に書かれた資格
certificate … 氏名、生年月日、講習・免許の種類、交付日、有効期限
health_check  氏名、受診日、実施機関

【status の選び方】
- ok ......... 値が読み取れている
- missing .... 読み取り結果の中に、その項目が無い
- unreadable . その項目があるはずのページが「品質不足」と印の付いたページ、
               または文字はあるが値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 記載がなければ status を missing にしてください。推測で埋めないでください。
- 講習・免許の種類は、証に印字された名称をそのまま写してください。
  短い名前や、別の講習の名前に言い換えないでください。
- 作業の内容は、名簿に書かれた文字列をそのまま写してください。
  機械の大きさや能力を、型式や容量の数字から推測しないでください。
- その作業にどの資格が必要か、資格が足りているかを書かないでください。
- 有効期限の欄が無い証は、有効期限を空にしてください。
  期限が無いと判断したとは書かないでください。
- 日付は西暦（YYYY-MM-DD）に直してください。元の表記は evidence に残してください。
- 健康診断の写しについて、覆い隠されていない部分に結果の数値や所見が
  見えても、取り出さないでください。
- evidence には、根拠にした文字列をそのまま写してください。

【読み取り結果（ページごと、品質不足のページには印）】{pages}
【この束の工事名と協力会社名】{batch_info}

「機械の大きさを推測しない」を入れないと、資格の判断まで進みます。 結論がたまたま正しくても、根拠が名簿に無い以上、点検としては使えません。 「期限が無いと判断したとは書かない」も、空の欄の意味を「期限の欄が無かった」という事実の1つにそろえるためです。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONを受け取ります。 要求の response_format に、mime_type を application/json、schema にJSONスキーマを指定します。

{
  "batch_id": "",
  "documents": [
    {
      "page_refs": [3],
      "doc_type": "roster | certificate | health_check | other",
      "workers": [
        { "name": "", "birth_date": "", "work": "", "listed_qualifications": [],
          "status": "ok | missing | unreadable | ambiguous", "evidence": "" }
      ],
      "fields": [
        { "item": "holder_name", "status": "ok | missing | unreadable | ambiguous",
          "value": "", "evidence": "" }
      ]
    }
  ]
}

workers は名簿のページだけで使います。fields の item は holder_name ／ holder_birth_date ／ qualification_name ／ issue_date ／ expiry_date ／ exam_date ／ exam_facility です。

スキーマでは doc_type と status を enum で固定し、日付の項目には format の date を指定します。 ただし、構文として正しいJSONが返っても、値はアプリケーションの側で確かめるよう案内されています。 スクリプトは、日付が実在するか、page_refs が束の中のページかを確かめます。

受け取ったあと、スクリプトが作業員ごとの判定を足します。

{
  "worker_key": "",
  "required": [ { "rule_id": "", "qualification": "", "matched_doc": 0 } ],
  "exam": { "date": "", "basis": "annual | six_months", "within": true },
  "identity": "matched | name_only | mismatch",
  "retake_pages": [ { "page": 0, "defects": [] } ],
  "missing_docs": [],
  "verdict": "ok | needs_docs | needs_retake | needs_human"
}

status と verdict を別の層に置くのが要点です。 取り出しは生成AI、判定は自社の表と規則です。表の境目や受診日の基準が変わっても、直すのはスクリプトの表だけです。

システムへ連携する

受付簿の登録の欄には書き込みません。 機械の判定がそのまま「入場可」に見える状態を作らないためです。

差し戻しの下書きは、協力会社ごとに1通にまとめます。 作業員の氏名、足りない書類、撮り直しが要るページと不具合の種類（「反射で講習の種類が読めません」）を並べ、何を出し直せばよいかが1通で分かる形にします。

人が確認する

担当者は、判定の一覧を verdict の順に読みます。

1. needs_human を先に見る … 作業の内容が表に無いもの、機械の大きさが書かれていないもの。協力会社か現場の機械の一覧に確かめます
2. needs_docs の根拠を確かめる … evidence を読み、必要な写しが本当に束の中に無いかを、束のページの一覧で見ます
3. 差し戻しの下書きを直して送る … 送るのは担当者です
4. ok の作業員を受付簿に登録する … 一覧で氏名と作業を流し見て登録します
5. 判定を覆したら記録する … どの作業員の、どの判定を、どちらに変えたか

2番目を省かないでください。 写しが別の協力会社の束に紛れ込んでいることがあり、不足として差し戻すと、協力会社は出したはずの写しを探し直すことになります。 一方で ok の写しは開きません。全員分を開き直すと、第10章の2分には収まりません。

例外に対処する

件数として多いのは、上の2行目と6行目です。 写真の反射と、表に無い作業の書き方で、どちらもAIではなく撮り方と表の整備の問題です。

記録を残す

• 協力会社の束ごとの、名簿と写しの原本と、変換後・覆い隠した後の画像
• Document AI が返した結果の全文（品質スコア、欄の名前と値、表）
• 生成AIに渡した読み取り結果と、返ったJSON
• スクリプトが足した判定と、そのとき使った作業と必要な資格の表の版、受診日の基準の版
• 担当者が判定を覆した記録と、その理由
• 差し戻しを送った日時と、出し直された写しとの対応
• 協力会社ごとの撮り直しと差し戻しの件数

表の版を残すのは、境目や基準が後から変わるためです。 当時の版が残っていないと、過去の判定のどれをやり直すかが決まりません。 最後の件数は、撮り方の案内を協力会社に送る材料になります。