入社予定者から届く雇入時の健康診断書を読み取り、受診日と法定の11項目の抜けを確かめて、追加の受診が要る人と人事の台帳への記録を分けて出す

処理の起点を決める

入社手続のフォームに健康診断書が提出されたことを起点にします。 フォームの保存先のフォルダを、Python のプログラムが10分おきに見て、新しいファイルを処理します。ファイルの名前には、フォームが付ける入社予定者の番号が入っているので、そこから入社日と配属先を引きます。

提出のたびに動かすのは、追加受診の案内を早く出すためです。 入社日の2週間前に提出された健康診断書に項目の抜けがあれば、その日のうちに案内を出せば、入社前に追加の受診を済ませてもらえます。 1週間まとめて処理すると、入社日に間に合わない人が出ます。

もう1つのトリガーは、入社日の変更です。 採用の担当が入社予定者の一覧の入社日を書き換えたら、その人の台帳の受診日と照らし直します。 一覧の変更を1日1回見て、入社日が変わった人だけを処理します。処理が終わったファイルは処理済みのフォルダへ移し、移すのは成功したときだけにします。

入力データを集める

質を決めるのは、項目名の対応表です。 労働安全衛生規則の第43条は、肝機能検査を「GOT、GPT及びγ-GTPの検査」、血中脂質検査を「LDLコレステロール、HDLコレステロール及び血清トリグリセライドの量の検査」と書いています。医療機関の結果表では、同じ検査が「AST」「ALT」「中性脂肪」と書かれていることが多くあります。 言い方の一覧が無いと、受けている検査を「無い」と判定します。

対応表は、運用しながら足していきます。 担当が確認の一覧で「この言い方は GOT のことだ」と分かったら、その言い方を対応表に足し、次から同じ医療機関の書類が確認に回らないようにします。

入社予定者の情報は、番号と入社日と配属先だけを渡します。 住所や連絡先は、この処理には要りません。追加受診の案内を送るときに、フォームの仕組みの側で宛先を付けます。

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

読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。オンラインの処理は1回の要求で最大15ページで、健康診断書は数ページに収まるので、1回で送れます。

受診日は、項目と値から取り、全文で確かめます。 健康診断書には、受診日のほかに、発行日、前回の受診日、生年月日と、日付がいくつも並びます。「受診日」「健診日」「実施日」のように書かれた項目の値だけを受診日とし、それが無ければ受診日は空にします。 発行日を受診日の代わりにしません。

AIへ渡す前に整形する

1. 形式の確認 … 公式の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。それ以外は提出し直してもらいます
2. 解像度の確認 … 公式の説明では、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。写真の画素数が足りないものは、撮り直しを頼みます
3. ページの組み立て … 1人分の結果が複数のファイルで出されたら、入社予定者の番号でまとめて1件にします
4. 本人の確認 … 健康診断書の氏名と生年月日を、入社予定者の一覧と照らします。合わなければ処理を止めます
5. 受診者以外の書類の除外 … 予防接種の記録や診断書のように、健康診断の結果でない書類を見分けます

4番目を省かないでください。 家族の健康診断書を取り違えて出す、前の会社の別の人の書類が混ざる、ということが実際に起きます。他人の健康診断の結果が、別の人の個人票に入るのは、この構成で最も避けたい事故です。 氏名と生年月日が一覧と合わないものは、読み取りの先に進めません。

2番目は、写真での提出が多いほど効きます。 机の上で斜めに撮った写真は、結果表の細い文字が読めません。読み取りの信頼度が低いものの多くは、撮り方の問題です。 フォームの説明に、真上から明るい場所で撮ることを書いておきます。

AIに処理させる

させるのは、読み取り結果から受診日と11項目それぞれの有無をそろえることだけです。 値の良し悪しの判断と、期限の判定はさせません。

いちばん大事な区別は、not_done と unreadable です。 not_done はその検査の項目そのものが健康診断書に無いということで、追加の受診を頼むもの、unreadable は項目はあるが値が読めないということで、画像を見直せば済むものです。分ける材料は、項目名が全文に見つかったかと、値の欄の信頼度です。

「中の一部」を1つずつ見させるのが、第3章の（b）の答えです。 「肝機能 済」で1つに丸めると、γ-GTP だけが無い健康診断書を見落とします。3つの検査を別々の項目として返させ、1つでも not_done なら追加受診の対象にします。

いちばん起きやすい失敗は、2行目です。 健康診断書を読ませると、生成AIは頼まれなくても「LDLコレステロールが高めです」と書き添えます。その一文が人事の台帳に入った時点で、要配慮個人情報が見る必要のない人の目に触れます。 出力の項目に値の評価の欄を作らず、指示でも禁じます。

指示内容を固定する

あなたは人事部で、入社予定者が提出した健康診断書について、
労働安全衛生規則第43条の項目が受けられているかを確かめる補助をする立場です。
OCRが返した項目と値、表のセル、全文だけを見て、項目の有無を返してください。
推測で埋めないでください。

【確かめる項目】
history（既往歴・業務歴）、symptoms（自覚症状・他覚症状）、
height、weight、waist、vision、hearing_1000、hearing_4000、
chest_xray、blood_pressure、hemoglobin、rbc、
got、gpt、ggt、ldl、hdl、tg、glucose、urine_sugar、urine_protein、ecg

【status の選び方】
- done ......... 項目名があり、値か所見が読み取れる
- not_done ..... 項目名が健康診断書のどこにも無い
- unreadable ... 項目名はあるが、値か所見の文字が読めない
迷ったときに done を選ばないでください。

【厳守事項】
- 項目名の言い方は、次の対応表に従ってください。対応表に無い検査を、
  似た検査として done にしないでください。
- 受診日は「受診日」「健診日」「実施日」と書かれた項目の値だけから
  取ってください。発行日や前回の受診日を受診日にしないでください。
  該当の項目が無ければ空にしてください。
- 値は写さないでください。値が基準の内か外か、再検査が要るかを
  書かないでください。所見の内容も要約しないでください。
- 聴力は 1,000Hz と 4,000Hz を別に見てください。
- 健康診断の結果でない書類と判断した場合は、document_type に種類を
  書き、項目を返さないでください。

【項目名の対応表】{item_aliases}
【読み取り結果】{ocr_result}

「値は写さない」を最初に決めておくのが、この指示の要です。 有無の確認に値は要りません。値は健康診断個人票の側に、OCRの結果から直接写します。 生成AIの出力に値が無ければ、人事の台帳に値が紛れ込む経路が最初から無くなります。

「対応表に無い検査を似た検査にしない」は、done の水増しを防ぐためです。 「肝機能 ALP」は対応表のどれにも当たりません。似ているからと GOT の代わりにすると、受けていない検査を受けたことにします。

出力形式を固定する

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

{
  "candidate_id": "",
  "document_type": "health_checkup",
  "name_match": "matched | mismatch",
  "exam_date": { "value": "", "status": "ok | blank | ambiguous" },
  "clinic": "",
  "items": [
    { "item": "got", "status": "done | not_done | unreadable",
      "label_found": "", "confidence": 0 }
  ]
}

items にはこの形の要素を、第7章の22の項目の分だけ並べます。label_found には、健康診断書で見つけた項目名の文字だけを入れ、値は入れません。

1つ目の理由は、期限の判定をプログラムの規則で行えることです。 exam_date と入社予定者の一覧の入社日から、受診日が入社日の3か月前の日より後かを規則で決めます。入社日が変わったら、同じ規則で照らし直します。

2つ目は、追加受診と確認の一覧を、AIでなくプログラムが決められることです。

3つ目は、人事の台帳と健康診断個人票を、出力の形で分けられることです。 台帳には exam_date と items の status だけを書き、個人票の側にはOCRが返した値を、別の保管先に写します。 どちらに何を書くかを、プログラムの側で固定できます。

システムへ連携する

案内は自動では送りません。 下書きには、足りない項目の名前と、提出の期限だけを書きます。送る前に担当が画像と見比べ、本当に項目が無いかを確かめます。

人が確認する

1. name_match が mismatch のものを最初に見る … 書類の取り違えの疑いです。入社予定者に連絡して、正しい書類を出し直してもらいます
2. 追加受診の案内の下書きを確かめる … not_done の項目について、健康診断書の画像で本当に無いかを見ます。見落とした項目名があれば、対応表に足します
3. 確認の一覧を見る … 受診日と unreadable の項目を画像で確かめて直します
4. 直したら記録する … どの項目を何から何に変えたかを残します

2番目を省かないでください。 追加受診の案内は、入社予定者に時間と費用をかけさせる連絡です。 受けていた検査を「無い」と案内した1件は、入社前の印象に残ります。

目標は、200件をならして1件3分です。 確認の一覧と案内の下書きに出るのは3割前後という想定で、それより多い月は、対応表の言い方が足りていないか、写真の提出が増えています。

例外に対処する

上の3行目が、運用の最初の1か月にいちばん多く出ます。 医療機関ごとの結果表の癖で、同じ医療機関の書類は同じところで読めません。 医療機関ごとに件数を数え、多いところから対応表と拾い方を直します。

記録を残す

• 健康診断書の画像と提出日時（健康診断個人票の保管先にだけ置く）
• OCRが返したJSONの全文（同じく個人票の保管先にだけ置く）
• AIが返した受診日と項目の有無（値を含まない）
• 期限の判定に使った入社日と、判定の結果
• 追加受診の案内を送った日と、追加の結果が届いた日
• 人が判定を直した記録と、対応表に足した言い方

1つ目と2つ目を個人票の保管先にだけ置くのは、ログが値の漏れ道にならないようにするためです。 処理の記録を共有のフォルダに書き出すと、OCRの値がログの中に残り、人事の誰もが見られる場所に置かれます。