建設現場で協力会社からメール・チャットでばらばらの形で届く作業日報を拾い、元請けの工事日報の様式（作業内容・人数・資機材）にそろえてまとめる

処理の起点を決める

トリガーは2つあります。届いた日報を1件ずつ読むものと、夕方にまとめるものです。

1件ずつ読む側は、Gmail の「Watch emails」と Slack の「Watch Private Channel Messages」です。どちらも、届いた順に動かします。 夕方にまとめて読むと、未着に気づくのが遅れ、催促が職長の帰った後になります。Make のシナリオのスケジュールを「一定間隔」にし、15分ごとに見に行く設定にします（最短の間隔は契約のプランで異なります）。

まとめる側は、毎日18時に動くスケジュールです。 その日の作業予定と一覧を突き合わせ、未着と「不明」を工事担当者に知らせます。19時30分にもう一度動かし、遅れて届いたものを反映します。

Gmail の側は、送り主で絞ります。 協力会社の一覧に登録されたアドレスから届いたものだけを拾い、広告や他の連絡を読み取りに回しません。 一覧に無いアドレスから「日報」を含む件名で届いたものは、別のラベルを付けて工事担当者に回します。

入力データを集める

質を決めるのは、協力会社の一覧と資機材の辞書です。 一覧にメールアドレスや Slack のユーザーが登録されていなければ、送り主から会社を特定できません。辞書が無ければ、「ユニック」と「4tユニック」は別の資機材として数えられます。

作業予定は、未着を見つけるために使います。 予定に載っていない会社から日報が届いたときも、一覧に出します。予定の変更が現場で決まって、予定表に反映されていないことがあるからです。

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

協力会社は、送り主のアドレスとユーザーで決めます。AIに本文から推し量らせません。 職長が本文に会社名を書かないことは珍しくなく、書いていても略称です。会社の特定を誤ると、出面が別の会社に計上されます。

チャットは、スレッドの返信も拾います。 「さっきの人数、6名に訂正です」のような訂正は、元の書き込みへの返信として届くことが多いからです。訂正は、元の日報と同じ日・同じ会社の行に結び付けて扱います。

AIへ渡す前に整形する

1. 送り主の特定 … アドレスまたは Slack のユーザーから、協力会社の一覧を引きます。一覧に無ければ「送り主不明」として人へ回します
2. 日報かどうかの見分け … 件名や本文に、日報の語や日付がなく、短いあいさつや質問だけのものは、読み取りに回しません
3. 署名と引用の除去 … メールの署名と、過去のやり取りの引用部分を外します
4. 写真の形式の確認 … Claude が受け付ける形式は JPEG、PNG、GIF、WebP です。それ以外の形式は変換します
5. 写真の大きさの確認 … 直接のAPIで1枚10MBまで、縦横8000ピクセルまでとされています。スマートフォンの写真は大きいので、縮小して送ります
6. 作業日の候補を付ける … 届いた日時を渡します。深夜0時を過ぎて届いた日報は、前日のものの可能性があることを指示に書きます
7. 同じ日・同じ会社の前の日報を探す … 2件目なら、訂正か追加かを判断する材料として前の内容を渡します

5番目は、読み取りの精度と費用の両方に効きます。 公式の説明では、画像は大きすぎると縮小されて処理され、縮小で文字が読みにくくなることがあるとされています。手書きの日報は、用紙の部分だけを切り出してから送るのが確実です。

6番目を忘れると、作業日がずれます。 夜遅くに送ってくる職長は少なくありません。届いた日付をそのまま作業日にすると、月末の出面の集計で、ある日が0名、次の日が倍になります。

AIに処理させる

させるのは、本文と写真から決まった項目を読み取り、書かれていない項目を「不明」と返すことだけです。

人数の行がいちばん大事です。 「作業員：山田、佐藤、鈴木」のように氏名だけが並ぶ日報は、人数が書かれているわけではありません。 列挙された氏名の数は別の欄に入れ、headcount は unknown のままにします。職長が自分を数えていない、応援の作業員を書き忘れた、という食い違いがあるためです。 確定は工事担当者が行います。

2行目の「前日の人数で埋めない」は、指示に明記します。 同じ会社の前日の日報を渡していると、今日の人数が書かれていないときに前日の値を写してくることがあります。値として正しく見えるので、人の確認でも見落とされます。

指示内容を固定する

あなたは建設現場の元請けで、協力会社から届いた作業日報を
工事日報の項目に読み取る立場です。
渡された本文と画像に書かれていることだけを読み取ってください。

【読み取る項目】
work_date / location / work_description / headcount（foreman, workers, total）/
work_hours / equipment（name_as_written, count）/ next_day_plan / safety_notes

【厳守事項】
- 書かれていない項目は "unknown" にしてください。推測で埋めないでください
- 人数は、数字で書かれているものだけを headcount に入れてください。
  氏名が並んでいるだけのときは、headcount は unknown のままにし、
  listed_names_count に並んでいた氏名の数を入れてください
- 前に届いた日報（previous_report）の値を、今日の値として写さないでください。
  previous_report は、訂正か追加かを判断するためだけに使ってください
- 資機材は、書かれていた呼び方のまま name_as_written に入れてください。
  正式な名前に言い換えないでください
- 作業日が本文に無いときは、受信日時を候補として入れ、
  date_source を "received_at" にしてください。
  受信が0時から5時の間なら、date_note に「前日の作業の可能性」と書いてください
- 手書きの文字が読めないときは、その項目を unreadable にし、
  evidence に読めなかった箇所の様子を書いてください
- 安全上の特記事項は、書かれていた文をそのまま写してください。評価しないでください
- 日報ではない書き込みと判断したときは、document_type を "other" にしてください
- 訂正の書き込みのときは、is_correction を true にし、訂正された項目だけを入れてください

【協力会社】{company_name}（職種：{trade}）
【受信日時】{received_at}
【前に届いた日報】{previous_report}
【本文】{body}
【画像】（添付）

「氏名の数を headcount に入れない」を書かないと、AIは数えて入れます。 数えること自体は正しいのですが、日報に書かれた人数と、工事担当者が確かめた人数の区別が消えます。 出面の記録として後から説明できなくなります。

「前の日報を写さない」は、渡し方の副作用への手当てです。 訂正を見分けるために前の日報を渡すと、それが空欄を埋める材料に見えます。使い道を限ることを、渡すのと同じ場所に書きます。

出力形式を固定する

次の形のJSONで受け取ります。 Messages API の structured outputs で output_config.format に json_schema を指定し、スキーマに沿った応答を受け取ります。

{
  "document_type": "daily_report | other",
  "is_correction": false,
  "work_date": "",
  "date_source": "body | received_at",
  "date_note": "",
  "location": "",
  "work_description": "",
  "headcount": { "foreman": "", "workers": "", "total": "" },
  "listed_names_count": 0,
  "work_hours": "",
  "equipment": [ { "name_as_written": "", "count": "" } ],
  "next_day_plan": "",
  "safety_notes": "",
  "unreadable_fields": [],
  "evidence": ""
}

1つ目の理由は、「不明」を値として持てることです。 unknown、none_stated、unreadable を区別して返させると、書かれていないのか、資機材を使わなかったのか、読めなかったのかが一覧で分かります。工事担当者が職長に聞く内容が、それぞれ違います。

2つ目は、name_as_written と辞書を分けられることです。 資機材の正式な名前は、ワークフローが辞書で引いて別の列に入れます。辞書に無い呼び方は空欄のまま一覧に出し、工事担当者が辞書に足します。 足すほど、次からは自動でそろいます。

3つ目は、is_correction で訂正を機械的に扱えることです。 訂正なら同じ日・同じ会社の行を更新し、元の値を履歴の列に残します。

システムへ連携する

協力会社への返信は、自動で送りません。 未着と「不明」の確認の文面は、工事担当者への通知に下書きとして添えます。送るのは工事担当者で、Slack なら自分のアカウントから書き込みます。

工事日報の文書は、工事担当者が一覧を確定してから作ります。 確定前の一覧から作ると、unknown の欄が空白のまま所長に回ります。空白は「0名」と読まれることがあります。

人が確認する

工事担当者が見るのは、18時の通知に出た行だけです。

1. 「未着」を最初に見る … 職長が帰る前に確認します。作業が中止になった、別の会社にまとめて書いてもらった、といった事情を一覧の備考に書きます
2. 「要確認」の人数を確かめる … 氏名の列挙だけの行は、職長に人数を確かめます。応援の作業員や職長自身を含むかを聞きます
3. 読めなかった箇所を確かめる … unreadable の項目は、写真を開いて読むか、職長に聞きます
4. 安全上の特記事項を読む … 書かれていたら、その日のうちに所長へ伝えます。翌朝の工事日報を待ちません
5. 辞書に無い資機材の呼び方を足す … 空欄の正式名を埋め、辞書に1行足します
6. 一覧を確定する … 確定した時点で工事日報の文書が作られます

4番目は、取りまとめとは別の流れとして扱います。 日報に「足場の手すりが外れていた」と書かれていたら、工事日報の項目として記録するだけでなく、すぐに動くべき連絡です。 通知の中でも、安全上の特記事項がある行は先頭に出します。

月末の出面の集計は、確定した人数だけを使います。 unknown が残っている日があれば、集計の段階で一覧に出し、常用の精算の前に必ず埋めます。

例外に対処する

1行目と2行目が、運用を始めた最初の月に多く出ます。 新しい協力会社の登録漏れと、1人の職長が複数の会社の作業員をまとめて報告する書き方です。どちらも取り決めで減らせるので、件数を数えて協力会社との打合せで伝えます。

記録を残す

• 届いたメール・書き込みの原文と、添付の写真
• 生成AIの応答のJSONの全文と、stop_reason
• 工事担当者が確かめて直した値と、直す前の読み取りの値
• 訂正の履歴（いつ、どの項目が、何から何に変わったか）
• 未着の催促を送った日時と、日報が届いた日時
• 辞書に足した資機材の呼び方

3つ目の「直す前の値」は、出面の記録を説明するためにも残します。 月末に協力会社から「この日は6名入っていた」と言われたとき、日報に何と書かれていて、誰がいつ確かめたかを示せます。

5つ目の未着の記録は、協力会社ごとに数えます。 毎週同じ会社が遅れるなら、送り方の取り決めを見直す材料になります。