海外の前職から届く英文の在職証明書を読み取り、候補者台帳と照らして、経歴の食い違いと在留資格の申請に足りない記載を拾う

処理の起点を決める

起点は2つあります。証明書が保存されたときと、毎週月曜の定時です。

1つ目は、受付フォルダ（Amazon S3）に証明書のPDFが保存されたことです。担当者は候補者から転送されたファイルを、ファイル名に候補者IDと職歴の行番号を付けて保存します。保存の通知で AWS Lambda が動き、読み取りから一覧への記録までを済ませます。どの職歴の証明かをファイル名で決めておくので、照合の相手を探す手間がかかりません。

2つ目は、毎週月曜9時の定時です。内定者ごとに、職歴の行のうち証明書がまだ届いていないもの、取り直しを頼んで2週間たっても届かないものを一覧にして担当者に送ります。申請の予定日から逆算して、遅れている候補者を先に見られるようにします。

入力データを集める

質を決めるのは、会社名の別名の一覧です。 履歴書には ABC Technologies と書かれ、証明書の発行元は ABC Technologies Private Limited や親会社の名義、ということはよくあります。一覧にある書き方だけを同じ会社とし、無いものは人に見せます。

候補者の氏名はパスポートの表記で持ちます。 証明書には名と姓の順が違うもの、ミドルネームを省いたものがあります。照合は表記のゆれを規則で吸収し、吸収できないものは人に回します。

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

読み取りは StartDocumentAnalysis にS3の場所と FeatureTypes を渡して始めます。完了は NotificationChannel に指定した Amazon SNS のトピックに通知され、状態が SUCCEEDED なら GetDocumentAnalysis で結果を取ります。

質問の答えが見つからなければ空のまま返ります。 退職日が空なら、全文から till、to、until、currently、is working を含む行を探し、在職中と書かれていれば employed を、何も無ければ missing を記録します。 退職日を、発行日や履歴書の日付で埋めることはしません。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。証明書の本体は1〜2ページでも、職務の別紙が付くことがあるので非同期で読みます。

候補者台帳、紹介先の一覧、記載の基準は、Python が読みます。 生成AIには、台帳の職歴の内容を渡しません。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。スマートフォンで撮った写真は、PDFにまとめて入れます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは候補者に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 文字の大きさの確認 … 文字の高さは最小15ピクセルで、150 DPIで8ポイントの文字に相当します。写真で撮った証明書は、この下限を下回りやすい書類です
5. 言語の確認 … 6言語に入らない証明書は読み取りに回さず、担当者が目で見る一覧に入れます
6. 照合の相手の特定 … ファイル名の候補者IDと職歴の行番号で、台帳の行と紹介先の区分を引きます

4番目は、受付の時点で候補者に伝えておくと効きます。 写真ではなく、前職から受け取ったPDFそのものを送ってもらうよう、内定の連絡と一緒に案内します。

AIに処理させる

させるのは、証明書から8つの項目を読み取り、原文の文字列と、日付の解釈を分けて書き出すことです。 照合と不足の判定はさせません。

職位を全部並べるのは、期間中の昇進が普通にあるためです。 「Software Engineer」から「Senior Software Engineer」に変わった証明書で、最後の職位だけを取ると、履歴書の職歴の行と照らしたときに食い違いに見えます。

職務内容を要約させないのも大事です。 要約すると、「関連する業務」として読めるかの判断に使う言葉が落ちます。原文のまま箇条で残し、読むのは人です。

最後の行が、いちばん起きやすい失敗です。 退職日の無い証明書で、履歴書の職歴の日付を参考に埋めると、照合は必ず一致し、見つけたかった食い違いと不足がまとめて消えます。

指示内容を固定する

あなたは人材紹介会社の内定者支援チームで、候補者の前職から届いた
英文の在職証明書の記載を記録する担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
issuer_letterhead_raw、issuer_signature_block_raw、employee_name_raw、
start_date_raw、start_date、end_date_raw、end_date、employment_status、
job_titles_raw（配列）、duties_raw（配列）、issue_date_raw、issue_date、
signatory_name_raw、signatory_title_raw、signatory_contact_raw、
各項目の status と source（ページと行）

【status の選び方】
- ok ........... 値が読み取れており、その項目として解釈できる
- missing ...... 書かれていない
- unreadable ... 文字は検出されているが値として確定できない
- ambiguous .... 候補が複数ある、または日付の順序が決まらない

【厳守事項】
- 日付は、日と月の順序が文面から確定できるときだけ YYYY-MM-DD で
  入れてください。月までしか書かれていなければ YYYY-MM としてください。
  決まらなければ空にし、ambiguous にしてください。
- 退職日が書かれていない場合は missing にしてください。
  在職中と書かれていれば employment_status を employed にしてください。
  発行日やほかの日付から補わないでください。
- 職務内容は要約せず、書かれたとおりに箇条ごとに配列へ入れてください。
- 職位が複数書かれていれば、すべてを並べてください。
- 証明書が本物か、在留資格の要件を満たすかを書かないでください。
- 在職証明書でない書類（給与明細、推薦状、雇用契約書など）と
  判断した場合は、項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_forms_queries_signatures}

「推薦状」を在職証明書でない書類として挙げているのには理由があります。 前職の上司が書いた推薦状にも在籍期間と職務が書かれていることがあり、区別しないと、会社が発行した証明書と同じ扱いで一覧に入ります。 どちらとして扱うかは人が決めます。

出力形式を固定する

Claude API の構造化出力（output_config.format に json_schema を指定）で、次の形のJSONを受け取ります。

{
  "file": "",
  "candidate_id": "",
  "career_row": 2,
  "document_type": "employment_certificate",
  "issuer_letterhead_raw": "ABC Technologies Private Limited",
  "employee_name_raw": "Mr. Ravi Kumar S",
  "start_date_raw": "1st June 2021",
  "start_date": "2021-06-01",
  "end_date_raw": "31st March 2024",
  "end_date": "2024-03-31",
  "employment_status": "left",
  "job_titles_raw": ["Software Engineer", "Senior Software Engineer"],
  "duties_raw": ["Design and development of backend APIs", "Code review"],
  "issue_date_raw": "April 5, 2024",
  "signatory_name_raw": "",
  "signature_detected": true,
  "items": [
    { "item": "signatory_name", "status": "unreadable", "confidence": 0, "source": "p1:L31" }
  ],
  "request_draft": ""
}

1つ目の理由は、照合と不足の判定をプログラムの側に置けることです。 Python が台帳の職歴の行と照らし、記載の基準で印を付けます。

2つ目は、紹介先のカテゴリーで扱いを分けられることです。 カテゴリー1と2の紹介先では、missing_item を取り直しの依頼ではなく記録だけにし、カテゴリー3と4の紹介先では、取り直しの依頼の下書きまで作ります。

3つ目は、原文と解釈を並べて持てることです。 訳文を作る人は、start_date_raw と start_date を並べて見れば、解釈が正しいかを原文で確かめながら訳せます。

システムへ連携する

候補者台帳へは書き込みません。 証明書の期間に合わせて台帳の職歴を直すかは、候補者に事情を聞いたうえで担当者が決めます。 自動で直すと、食い違いがあったという事実が台帳から消えます。

人が確認する

担当者が開くのは、ok 以外の印が付いた証明書です。 ok のものは、期間と職位を並べた一覧で流し見ます。

1. needs_human を先に片付ける … 読めない署名者や順序の決まらない日付を、画像で確かめます
2. period_mismatch と name_mismatch の理由を候補者に聞く … 試用期間の扱い、社名の変更、グループ会社への転籍などを確かめます
3. missing_item の取り直しを頼む … 下書きを直して、候補者に送ります
4. 申請に使えるかを責任者と専門家に上げる … そろった証明書と照合の結果を並べて渡します

2番目で台帳の側を直すときは、直した理由を残します。 「証明書は入社日を正社員登用の日で書いている」のように理由が分かっていれば、申請の書類どうしで期間を説明できます。

例外に対処する

上から3行目と4行目が、照合の誤りのほとんどを生みます。 どちらも期間という1つの値の問題で、ここを人に回す設計を崩すと、食い違いの印が当てにならなくなります。

記録を残す

• 元の証明書と、受け取った日時、候補者ID、職歴の行番号
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（原文と解釈の両方）
• 照合の結果と、そのとき参照した台帳の職歴、記載の基準、別名の一覧の版
• 担当者が印を覆した記録と、候補者から聞いた理由
• 取り直しの依頼と、新しい証明書との対応

保存の期間と、見られる人を先に決めます。 証明書には候補者の職歴と、署名者の氏名や連絡先が書かれています。内定を辞退した候補者の証明書をいつ消すかも、ここで決めておきます。