建設現場で毎日手書きされる協力会社の出面表を読み取り、日付・会社・職種・人数を労務の集計表にそろえて、入場記録との食い違いを拾う

処理の起点を決める

共有フォルダにスキャンが保存されたことを起点にします。 工事担当が夕方に確認の印を押した後、現場事務所の複合機でスキャンします。印を押す前の出面表はスキャンしません。 職長が後から書き足すことがあるためです。

保存先は現場ごとに分け、ファイル名に現場コードと日付を付けます。 複合機の宛先を現場ごとに登録しておけば、工事担当が手で名前を付ける必要はありません。

Python のプログラムは、毎日21時に1日分をまとめて処理し、翌朝7時に食い違いを知らせます。出面表は夕方に集中して届き、照らす相手の入退場の記録もその日の退場が終わらないとそろわないので、1枚ずつの即時処理にはしません。 処理が終わったファイルは処理済みのフォルダへ移し、移すのは成功したときだけにします。

入力データを集める

質を決めるのは、現場の施工体制の一覧です。 出面表の会社名をマスタ全体から探すと、略称の似た別の会社に当たることがあります。その現場に入っている会社の中から探せば、候補は10社前後に絞られます。

一次の会社の列は、（d）の失敗のために持ちます。 入退場の記録が二次の会社ごとに分かれていて、出面表が一次の会社でまとめて書かれていれば、二次の人数を一次に合算してから比べます。

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

読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。オンラインの処理は1回の要求で最大15ページで、出面表は1枚ずつ送るので上限に届きません。

現場名と日付は、読み取った値よりファイル名を優先します。 手書きの日付は書き損じがあり、読み違いもあります。ファイル名の日付と読み取った日付が違えば、知らせに載せて工事担当に確かめます。

入退場の記録は、現場で使っている仕組みから日ごと・会社ごとの人数を書き出したCSVを、毎日決まったフォルダに置く形にします。書き出しを自動にできる仕組みもあれば、工事担当が画面から書き出す必要がある仕組みもあります。どちらにするかは、現場で使っている製品の機能を確かめて決めます。

AIへ渡す前に整形する

1. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。複合機の保存は PDF にします
2. 解像度の確認 … 公式のページでは、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。人数の数字が小さく書かれることが多いので、300dpiに設定します
3. 1ファイル1枚にそろえる … 数日分をまとめてスキャンしたものは、ページで分け、ページごとに日付を確かめます
4. 現場と日付の確認 … ファイル名の現場コードがマスタに無ければ処理を止めます
5. 出面表が無い日の確認 … 入退場の記録があるのに出面表が届いていない日を拾います
6. 同じ日の出面表が2枚ある場合 … 両方を工事担当に回し、どちらかを捨てない

5番目は、この構成で初めて見えるものです。 入場記録はあるのに出面表が無い日は、出面表を書き忘れたのか、スキャンを忘れたのかのどちらかです。月末に気づくと、どちらだったかを確かめようがありません。

6番目で両方を回すのは、書き直しの可能性があるからです。 職長が書き損じて新しい用紙に書き直し、古いほうも現場事務所の机に残ってスキャンされることがあります。どちらが現場で合意した人数かは、印を押した工事担当にしか分かりません。 新しいほうを機械的に選ぶと、印の無い下書きを集計に入れることがあります。

AIに処理させる

させるのは、出面表の各行を、会社コード・職種コード・人数（書かれたとおり）・作業内容にそろえることです。 人数の比較も、集計も、Python が行います。

人数は、計算させずに写させます。 「4＋1」を5にするのは Python です。AIが足すと、「4＋1」が見習い1人を分けて書いたものなのか、別の会社の1人を書き足したものなのかという情報が消えます。 写した文字列を残しておけば、工事担当が確かめるときに元の書き方が分かります。

4行目がいちばん起きやすい失敗です。 施工体制に無い会社の名前が書かれていると、AIは似た名前の会社に寄せたくなります。その現場に施工体制の登録の無い会社が入っていた、という事実は、元請にとって大事な知らせです。寄せた瞬間に消えます。

指示内容を固定する

あなたは建設会社の経理部で、現場の出面表の読み取り結果を
労務の集計の形にそろえる立場です。OCRが返した結果だけを見て、
協力会社の行を1つずつ写してください。推測で埋めないでください。

【やること】
1. 各行の会社名を、下の「この現場の協力会社の一覧」の会社コードに対応させる
2. 各行の職種を、下の「職種のコード表」の職種コードに対応させる
3. 人数の欄を、書かれたとおりの文字列で写す
4. 作業内容を原文のまま写す
5. 職長の署名欄に記入があるかを写す

【厳守事項】
- 会社名は、一覧の正式な名前か呼び名に一致するときだけ対応させてください。
  一覧に無い会社名は company_code を unmatched にし、
  written_company に書かれたとおりに写してください。
  似た名前の会社に寄せないでください。
- 人数は計算しないでください。「4＋1」「4(1)」は、そのまま写してください。
- 人数の欄が空欄なら status を blank、文字はあるが読めなければ
  unreadable にしてください。空欄と読めない欄を混ぜないでください。
- 1つの行に2つの職種が書かれているときは、行を分けずに
  trade_code を multiple にし、written_trade に原文を写してください。
- どちらの人数が正しいか、入場の記録と合っているかを書かないでください。
- 単価や金額を書かないでください。
- 出面表ではない書類と判断した場合は、document_type に種類を書いてください。

【読み取り結果】{ocr_result}
【この現場の協力会社の一覧（コード、正式名、呼び名）】{site_contractors}
【職種のコード表（コード、名称、揺れのある書き方）】{trade_codes}

「似た名前の会社に寄せない」を2度にわたって書いているのは、書かないと必ず寄せるからです。 一覧を渡されたAIは、その中から最も近いものを選ぼうとします。選ばないという選択肢を、明示しておく必要があります。

行を分けさせないのは、人数の内訳が分からないからです。 「鉄筋・型枠 6」を2行に分けると、AIは3人ずつに割るか、片方に6人を入れます。どちらも書かれていない情報です。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に JSON スキーマを渡す方式）を使い、形を固定します。

{
  "site_code": "",
  "work_date": "",
  "document_type": "attendance_sheet",
  "rows": [
    {
      "company_code": "",
      "written_company": "",
      "trade_code": "",
      "written_trade": "",
      "headcount_text": "",
      "status": "read | blank | unreadable",
      "work_description": "",
      "foreman_signature": "present | missing",
      "row_ref": ""
    }
  ]
}

1つ目の理由は、書かれたままの値とコードを並べて持てることです。 written_company と company_code が並んでいれば、工事担当はAIがどの書き方をどの会社に対応させたかを1行で確かめられます。呼び名の一覧に足すべき書き方も、ここから拾えます。

2つ目は、比較を Python の規則で行えることです。

over と under を分けるのは、確かめる相手が違うからです。 over なら職長と技能者に入場の仕方を、under なら出面表の書き方を確かめます。どちらも、確かめた結果と理由を記録してから集計表に入れます。

3つ目は、unregistered が施工体制の点検にもなることです。 施工体制の登録の無い会社が出面表に出てくれば、登録の漏れか、届け出の無い再下請かを工事担当が確かめる必要があります。

公式のページでは、列挙の値の大文字・小文字までは保証されないとされているので、status などは Python で小文字にそろえてから使います。stop_reason が max_tokens のときは出力が途中で切れているので、集計表に書かずに呼び直します。

システムへ連携する

工事原価の管理ソフトへは書き込みません。 労務の集計表から原価の管理ソフトへの取り込みは、月末に経理がこれまでの手順で行います。 確かめの済んでいない行が原価に入ると、後から直す手間が増えます。

入退場の仕組みにも書き込みません。 食い違いの理由がカードのかざし忘れであっても、入退場の記録を直すかどうかは、その仕組みの運用の決まりに沿って工事担当が判断します。

人が確認する

工事担当が見るのは、自分の現場の食い違いの知らせだけです。 食い違いの無い日は、知らせが来ません。

1. unregistered を先に見る … 施工体制に無い会社です。登録の漏れか、届け出の無い再下請かを、その日のうちに確かめます
2. over と under を見る … 出面表の該当行に枠が出るので、そこだけを見て、職長に確かめます
3. 確かめた結果を記録する … どちらの人数に合わせたか、理由（かざし忘れ、書き漏れ、別現場の混入など）を選びます
4. check_sheet を見る … 読めなかった人数、署名の無い行です。出面表の原本で確かめます

3番目の理由は、選択肢から選ぶ形にします。 自由に書かせると、月末に経理が集計できません。理由ごとの件数が見えると、カードのかざし忘れが多い現場や会社が分かります。

経理が見るのは月末です。 確かめの済んだ集計表と、協力会社の常用の請求を突き合わせます。目標は、600枚をならして1枚1.5分です。 内訳は、工事担当の確かめと経理の月末の突き合わせの合計です。

例外に対処する

1行目は、導入の初めに多く起きます。 入退場の記録の書き出しが工事担当の手作業になっている現場では、書き出しを忘れた日は比較ができません。 その日の分は、翌日の処理でまとめて比べます。

記録を残す

• 元のスキャンと、スキャン日時・現場・スキャンした工事担当
• OCRが返したJSONの全文と、Claude API の応答の全文
• 比較に使った入退場の記録のファイルと、その書き出し日時
• 比較の結果（over、under など）と、工事担当が確かめた結果と理由
• 協力会社マスタと施工体制の、そのときの内容
• 会社ごと・現場ごとの食い違いの発生率と理由の内訳

4つ目が、この構成で最も大事な記録です。 常用の人工の請求で協力会社と金額が合わないとき、どの日のどの食い違いを、誰が、どういう理由でどちらに合わせたかをたどれます。

最後の行は、現場の運用を見直す材料になります。 かざし忘れが多い現場なら、入退場の機器の置き場所に理由があることがあります。