協力会社から届く再下請負通知書を読み取り、施工体制台帳の項目にそろえて、許可業種の食い違いと記載漏れを拾う

処理の起点を決める

受付フォルダにファイルが保存されたことを起点にします。 着工の前後に固まって届くため、1日1回の定時実行にはしません。まとめて処理すると、照らした結果が出るのが翌日になり、二次下請が現場に入った後で記載漏れに気づくことになります。

ファイル名の先頭に現場コードを付けることを、現場の工事事務との取り決めにします。工事名称から推定すると、同じ発注者の工事が複数あるときに取り違えます。

処理が終わったファイルは処理済みのフォルダへ移します。移すのは確認の一覧に載せ終えたときだけにし、受付フォルダに残る数を未処理の数とします。

入力データを集める

質を決めるのは、いちばん下の対応表です。 建設工事は2つの一式工事と27の専門工事の計29の種類に分かれ、許可はこの種類ごとに取ります。ところが通知書の「担当工事内容」には「LGS・ボード貼り」「空調ダクト」のような現場の言葉が書かれます。現場の言葉と29の業種をつなぐ表が無ければ、照合そのものができません。

協力会社の名簿は「照合の相手」として持ちます。 許可番号が名簿と違っても、どちらが正しいかは分かりません。違うという事実を出し、人が許可通知書の写しで確かめます。

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

読み取りは、Azure Functions からレイアウトモデルを呼ぶだけです。このとき features=keyValuePairs を付け、出力を Markdown 形式（outputContentFormat=markdown）で受け取ります。 Markdown では表が HTML の表として表され、結合されたセルや複数行の見出しも崩れずに残ります。

許可番号と日付は、単語の信頼度を必ず持ち回します。 「第12345号」の一桁の読み違いは、文字としては自然に見えるので、生成AIの段では気づけません。信頼度が低い単語を含む値には、後段で印を付けます。

AIへ渡す前に整形する

1. 形式の確認 … PDFまたは画像（JPEG、PNG、BMP、TIFF、HEIF）であることを確かめます。スマートフォンの写真はそのまま受け付けます
2. ページ数とサイズ … PDFとTIFFは最大2,000ページ、有料（S0）レベルで500MBが上限です。通知書の束をまとめてスキャンしたものは、通知書ごとに分けます
3. 画像の大きさ … 50×50ピクセルから10,000×10,000ピクセルの間である必要があります
4. 文字の大きさ … 抽出できる文字の最小の高さは、1024×768の画像で12ピクセルです。150dpiで約8ポイントの文字に当たります。細かい欄の多い様式は、スキャンの解像度を上げます
5. パスワードの解除 … パスワードでロックされたPDFは、提出前に解除が必要です
6. 添付書類の切り分け … 通知書には下請契約の書面の写しを添付することとされています。通知書の本体と契約書面の写しをページで分け、契約書面は読み取りの対象から外します
7. 重複の検知 … 同じ現場・同じ再下請負人・同じ契約日のものが直近にあれば、変更の届けか重複かを判定する印を付けます

6番目を省かないでください。 契約書面の写しには、工事名や工期が通知書とは違う書き方で出てきます。両方を一緒に読ませると、契約書の側の値を通知書の値として拾います。

AIに処理させる

させるのは、読み取り結果を施工体制台帳の項目に並べ直し、値ごとに根拠の文字列と読み取りの状態を付けることだけです。 項目は、建設業法施行規則が再下請負通知書の記載事項として定める範囲に合わせます。

右端の列の区別が、この構成でいちばん大事です。 missing と not_in_form は一次下請に問い合わせるもの、unreadable は自社でスキャンし直すものです。混ぜると、紙が汚れていただけの通知書のために一次下請へ電話をかけることになります。

3行目がいちばん起きやすい失敗です。 名簿を渡すと、生成AIは名簿の許可番号で空欄を埋めます。名簿は生成AIに渡さず、照合は規則の段で行います。

指示内容を固定する

あなたは建設会社の工事事務で、協力会社から届いた再下請負通知書を
施工体制台帳の項目に写す係です。
OCRが返した読み取り結果だけを見て、指定の項目に値を入れてください。

【入れる項目】
1. 通知する会社：商号・名称、住所、許可番号
2. 通知する会社が請けた工事：工事名称、注文者、注文者との契約日
3. 再下請負人：商号・名称、住所、許可番号、許可業種、
   大臣・知事の別、特定・一般の別、許可（更新）年月日、
   健康保険・厚生年金保険・雇用保険の加入状況
4. 再下請負人の工事：工事名称・担当工事内容、工期（自・至）、契約日
5. 技術者：主任技術者の氏名・資格内容・専任か非専任か、専門技術者
6. 現場の担当者：現場代理人、監督員、安全衛生責任者
7. 外国人の従事：一号特定技能外国人、外国人技能実習生の従事の有無

【status の選び方】
- ok ........... 値が読み取れており、その項目として解釈できる
- missing ...... 欄はあるが値が無い。印を付ける欄で、どれにも印が無い
- not_in_form .. この様式にその欄がそもそも無い
- unreadable ... 文字は検出されているが、値として確定できない
- ambiguous .... 候補が複数ある。印を付ける欄で、二つ以上に印がある
迷ったときに ok を選ばないでください。

【厳守事項】
- 書かれていない値を推測で埋めないでください。記載がなければ
  value を空にし、status を missing にしてください。
- 「許可番号」という項目名があっても、値が空なら missing です。
- 許可番号・日付は、読み取った文字列をそのまま value に入れてください。
  桁を補う、和暦と西暦を直す、それらしい番号にすることをしないでください。
- 印を付ける欄は、selection_marks の state だけを根拠にしてください。
  文字の並びから、どちらに印があるかを推測しないでください。
- 下請契約の書面の写しのページに書かれた値は使わないでください。
- 許可業種が担当工事に合っているか、許可が有効かは書かないでください。
- evidence には、根拠にした文字列をそのまま写してください。
- 再下請負人が複数社ある場合は、会社ごとに subcontractors の要素を分けてください。

【現場コード】{site_code}
【読み取り結果（Markdown）】{layout_markdown}
【キーと値の組】{key_value_pairs}
【選択マーク】{selection_marks}

「印を付ける欄は state だけを根拠にする」を明記しないと、文字から推測します。 作成例の様式では「専　任　非専任」のように選択肢が並んで印刷されており、何も言わなければ先に書かれている「専任」を値として拾うことがあります。

「和暦と西暦を直さない」のは、直した値では人が通知書と見比べるときに探せなくなるからです。 換算は規則の段で行います。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONを返させます。

{
  "notice_id": "",
  "site_code": "",
  "notifier": {
    "name": { "value": "", "status": "ok", "evidence": "" },
    "permit_no": { "value": "", "status": "ok", "evidence": "" }
  },
  "subcontractors": [
    {
      "name": { "value": "", "status": "ok", "evidence": "" },
      "permit_no": { "value": "", "status": "ok", "evidence": "" },
      "permit_trade": { "value": "", "status": "ok", "evidence": "" },
      "permit_date": { "value": "", "status": "ok", "evidence": "" },
      "work_content": { "value": "", "status": "ok", "evidence": "" },
      "period_from": { "value": "", "status": "ok", "evidence": "" },
      "period_to": { "value": "", "status": "ok", "evidence": "" },
      "chief_engineer": { "value": "", "status": "ok", "evidence": "" },
      "full_time": { "value": "", "status": "ok", "evidence": "" },
      "health_insurance": { "value": "", "status": "ok", "evidence": "" },
      "foreign_workers": { "value": "", "status": "ok", "evidence": "" }
    }
  ]
}

status は5つの値の列挙にします。ここでは項目の一部を抜き出しています。

構造化出力では、すべての項目を必須にし、オブジェクトに additionalProperties: false を付けます。 値が無い項目も省略させず、空の値と missing を必ず返させます。 pattern のような制約は使えないため、許可番号の桁数や日付の形の検査は規則の段で行います。

規則の段では、次の表で verdict を決めます。

AIの出力と規則の判定を別の層に置くのが要点です。 基準を変えても、直すのは規則だけで、過去の読み取り結果から判定をやり直せます。

システムへ連携する

名簿へは書き込みません。 通知書で初めて出てきた二次下請の会社も、名簿に載せるかどうかは、許可通知書の写しを確かめた人が決めます。 自動で載せると、読み違えた許可番号が名簿の正しい値として残り、以後の照合の相手になってしまいます。

人が確認する

人が開くのは needs_inquiry と needs_human のものだけです。 ok のものは一覧で会社名・担当工事・工期を流し見て確定します。全件を開くと、第10章の24.0時間には収まりません。

1. needs_human の許可業種の食い違いを先に見る … 法務の担当が、対応表の不足なのか、許可の範囲の問題なのかを分けます。許可が要らない小さな工事かどうかは、一次下請に請負代金の規模を確かめないと分かりません
2. 許可の期限が工期中に来るものを確かめる … 更新後の許可通知書の写しをもらいます
3. unreadable と信頼度の低い番号を元の通知書で見る … 多くはスキャンのし直しで解決します
4. needs_inquiry の問い合わせ文を直して送る … 送信は人が行います
5. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

1番目の結果を「違反の疑い」として扱わないでください。 言えるのは、対応表と通知書の言葉がつながらなかったということだけです。

例外に対処する

最後の行が、運用が育つかどうかの分かれ目です。 対応表に足すたびに、同じ言葉の通知書は次から ok で流れます。needs_human が減らないなら、対応表の言葉の粒度が細かすぎます。

記録を残す

• 元の通知書ファイルと、受け取った日時・経路・現場コード
• レイアウトモデルが返したJSONの全文（文字、表、キーと値の組、選択マーク、信頼度）
• 生成AIが返した項目の値と status・evidence
• 規則で照らした結果と verdict、そのとき使った対応表と名簿の版
• 人が値や判定を覆した記録 … どの項目を、どちらに変えたか
• 問い合わせを送った日時と、返ってきた回答・差し替えの通知書との対応
• 台帳へ確定した値と、確定した人・日時

4番目で「そのときの対応表の版」を残すのは、対応表が育っていくためです。 半年前に ok で流れた通知書が、いまの対応表では needs_human になることがあります。当時の基準が残っていないと、過去の台帳を見直す範囲が決まりません。