海外の候補者について調査会社から届く英文の経歴確認レポートを読み取り、応募書類と照らして、食い違いと照会できなかった項目を採用担当に返す

処理の起点を決める

起点は2つあります。レポートが保存されたときと、毎朝9時の定時です。

1つ目は、受付フォルダ（Amazon S3）にレポートのPDFが保存されたことです。調査会社の完了の通知メールを受けたら、メールの添付またはリンクからPDFを取り出し、ファイル名に候補者IDと受け取った日時を付けて保存します。保存の通知で AWS Lambda が動き、読み取りから一覧への記録までを済ませます。調査会社の依頼番号もファイル名に入れておくと、同じ候補者の途中版と最終版を結び付けられます。

2つ目は、毎朝9時の定時です。照会中の項目が残っている候補者、照会できなかった項目について代わりの書類を頼んでから7日たっても届かない候補者、入社予定日まで14日を切ったのに最終版のレポートが届いていない候補者を一覧にして、採用担当に送ります。途中版を受け取ったあとの追いかけを、担当者の記憶ではなく一覧に持たせます。

入力データを集める

質を決めるのは、依頼の内容と名称の別名の一覧です。 依頼の内容が無いと、頼んだのにレポートに出てこない項目に気づけません。調査会社が照会を飛ばした項目は、レポートの表に行が無いだけで、何も書かれていないからです。

名称の別名の一覧は、学校で特に効きます。 応募書類には IIT Bombay と書かれ、レポートには Indian Institute of Technology Bombay と書かれる。大学の統合や改称で、卒業時と今で名前が違うこともあります。一覧にある書き方だけを同じ学校とし、無いものは人に見せます。

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

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

ClientRequestToken は64文字までで、英数字とハイフン・下線しか使えません。ハッシュをそのまま連ねると超えるので、短くして使います。

質問は表紙だけに使い、学歴と職歴の中身は表から取ります。 質問は英語の文書でしか使えず、1ページあたり非同期で30個までです。項目の数は候補者ごとに違うので、質問で1項目ずつ聞くより、表をそのまま取って行と列で読むほうが漏れません。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。JobId は7日しか有効でないので、完了の通知を受けたらその日のうちに結果を取り、S3に保存します。

応募書類の項目、依頼の内容、判定の対応表、別名の一覧は、Python が読みます。 生成AIには、応募書類の内容を渡しません。照合はプログラムの側で行うからです。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFには対応していないので、届いたら調査会社に通常のPDFを頼みます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。調査会社がパスワード付きで送ってくる場合は、受け取りの段で解除してから保存します
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 版の特定 … 依頼番号で同じ候補者の前の版を探し、あれば今回を新しい版として結び付けます
5. 照合の相手の特定 … 候補者IDで、採用管理システムの応募書類の項目と、依頼の内容を引きます
6. 候補者の同意の記録の確認 … 照会の同意を取った記録が無い候補者のレポートは、読み取りに回さず担当者に戻します

6番目を入れているのは、読み取りの前に止める理由があるからです。 同意の記録が無いまま照会の結果を社内で使い始めると、後から同意の範囲を確かめようとしても、どの段で何を使ったかが分からなくなります。

AIに処理させる

させるのは、Textract が返した表と全文から、学歴と職歴の項目ごとに値を取り出し、原文の文字列と、日付の解釈を分けて書き出すことです。 照合と判定の読み替えはさせません。

申告と照会結果を別々に取るのが、この記事でいちばん大事なところです。 第1章のとおり、レポートの Verified は「申告と照会結果が合っている」という意味です。Python は、レポートの申告と自社の応募書類を照らし、照会結果と自社の応募書類も照らします。 片方しか取っていないと、この2本の照合ができません。

コメントを要約させないのも大事です。 「Registrar did not respond after 3 attempts」と「Institution closed in 2018」は、どちらも照会できなかった理由ですが、次に頼む代わりの書類が違います。 要約するとこの区別が落ちます。

最後の行が、いちばん起きやすい失敗です。 照会結果の在籍期間が空のレポートで、申告の欄の日付を参考に埋めると、照合は必ず一致し、照会できていなかったという事実まで消えます。

指示内容を固定する

あなたはSaaS企業の採用チームで、海外の調査会社から届いた
英文の経歴確認レポートの記載を記録する担当です。
OCRの読み取り結果（表のセルと全文）だけを使ってください。
推測で埋めないでください。

【取り出す単位】
レポートの学歴・職歴の項目（component）ごとに1件。
component_type は education か employment。

【項目ごとに取り出すもの】
institution_provided_raw、institution_verified_raw、
degree_provided_raw、degree_verified_raw、major_provided_raw、major_verified_raw、
titles_provided_raw（配列）、titles_verified_raw（配列）、
start_provided_raw、start_verified_raw、end_provided_raw、end_verified_raw、
start_verified、end_verified（解釈できるときだけ）、
vendor_status_raw、verification_source_raw、comments_raw、
各値の status と source（ページ、表の番号、行と列）

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

【厳守事項】
- provided（候補者の申告）と verified（照会で確かめた値）は、
  表の列見出しで区別してください。列見出しで区別できないときは
  両方とも ambiguous にし、どちらかに寄せないでください。
- verified の欄が空なら missing にしてください。provided の値や、
  ほかの項目の値から補わないでください。
- 日付は、日と月の順序が文面から確定できるときだけ YYYY-MM-DD で
  入れてください。月までなら YYYY-MM とし、決まらなければ空にしてください。
- vendor_status_raw は書かれたとおりに写してください。
  Verified や Discrepancy を言い換えたり、まとめたりしないでください。
- comments_raw は要約せず、全文を写してください。
- 経歴が正しいか、候補者に問題があるかを書かないでください。
- 犯罪歴・信用情報・健康・家族・出身地に関する記載があっても、
  取り出さずに other_sections に見出しの名前だけを書いてください。
- 経歴確認レポートでない書類（請求書、同意書、本人確認の書類など）と
  判断した場合は、項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_tables_forms_queries}

「犯罪歴・信用情報…は取り出さない」を書いているのには理由があります。 調査会社によっては、頼んでいない照会の見出しや、照会の対象外である旨の記載がレポートに入ることがあります。この構成で扱うのは学歴と職歴だけで、それ以外の記載は値として一覧に入れません。 見出しの名前だけを残し、そのページを人が確かめます。

「列見出しで区別できないときは両方 ambiguous」も外せません。 列見出しが1行目に無い表や、調査会社のロゴの下に小さく書かれた見出しは、OCRで見出しと判定されないことがあります。そのときにAIが左右の列の意味を推測すると、申告と照会結果が逆になり、照合の結果がすべてずれます。

出力形式を固定する

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

{
  "file": "",
  "candidate_id": "",
  "order_id": "",
  "report_type_raw": "Interim Report",
  "overall_status_raw": "In Progress",
  "document_type": "background_check_report",
  "components": [
    {
      "component_type": "employment",
      "institution_provided_raw": "Acme Cloud Pvt Ltd",
      "institution_verified_raw": "ACME CLOUD PRIVATE LIMITED",
      "titles_provided_raw": ["Engineer"],
      "titles_verified_raw": ["Engineer"],
      "start_provided_raw": "07/2019",
      "start_verified_raw": "01-Jul-2019",
      "start_verified": "2019-07-01",
      "end_verified_raw": "30-Jun-2024",
      "end_verified": "2024-06-30",
      "vendor_status_raw": "Verified",
      "verification_source_raw": "HR Department",
      "comments_raw": "",
      "items": [
        { "item": "titles_verified", "status": "ok", "confidence": 0, "source": "p3:T2:R4C3" }
      ]
    }
  ],
  "other_sections": [],
  "request_draft": ""
}

confidence は、Textract がそのセルに付けた信頼度を Python があとから書き込みます。 AIには信頼度を付け直させません。

1つ目の理由は、照合の印をプログラムの側で決められることです。 Python が判定の対応表で vendor_status_raw を読み替え、応募書類の項目と照らして印を付けます。

期間の基準は社内で決めます。 例えば「入社日・退職日とも1か月以内のずれは match」のように、月の単位で書く国と日の単位で書く国が混ざるので、ずれの許容を表で持たせます。

2つ目は、前の版と比べられることです。 項目ごとに印を持っているので、途中版で pending だった項目が最終版で何になったかを、プログラムが項目単位で並べられます。 pending から vendor_discrepancy に変わった項目は、一覧の先頭に出します。

3つ目は、原文と解釈を並べて持てることです。 採用担当は、start_verified_raw と start_verified を並べて見れば、日付の解釈が正しいかを原文で確かめながら候補者に説明を求められます。

システムへ連携する

採用管理システムへは書き込みません。 レポートに合わせて応募書類の職歴を直すかは、候補者に事情を聞いたうえで採用担当が決めます。 自動で直すと、食い違いがあったという事実が応募書類から消えます。

採用管理システムから項目を取る方法は、製品によって違います。 APIで応募書類の項目を取れる製品ならAPIを使い、取れない製品なら、毎朝の定時に候補者一覧を書き出したファイルを S3 に置き、それを Python が読みます。 この部分は利用している製品に応じた個別の実装になります。

人が確認する

採用担当が開くのは、match 以外の印が付いた項目です。 match の項目は、候補者ごとの一覧で流し見ます。

1. needs_human を先に片付ける … 列見出しが読めない表、対応表に無い判定、学歴・職歴以外の見出しを、レポートの画像で確かめます
2. app_mismatch と vendor_discrepancy を候補者に聞く … 職位の呼び方の違い、試用期間や業務委託の期間の扱い、社名の変更などを確かめます
3. unable の代わりの書類を頼む … 照会できなかった理由（照会先の無回答・閉鎖・記録の保存期間切れなど）に合わせて、卒業証書、成績証明書、在職証明書、給与明細などを頼みます
4. pending の最終版を待つ … 毎朝の一覧で追いかけます
5. 採用の責任者に上げる … 候補者の説明と代わりの書類をそろえて渡します

2番目で候補者に聞く前に、レポートの画像を必ず見ます。 OCRが日付の列を取り違えていただけの食い違いを候補者に問いただすと、内定者との関係に直接ひびきます。 画像で確かめてから連絡するのを、手順として固定します。

例外に対処する

上から4行目と5行目が、照合の誤りのほとんどを生みます。 どちらも「どの値が何を意味するか」の取り違えで、ここを人に回す設計を崩すと、一覧の印がまとめて当てにならなくなります。

記録を残す

• 元のレポートと、受け取った日時、候補者ID、依頼番号、版（途中版／最終版）
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（申告と照会結果、原文と解釈）
• 照合の結果と、そのとき参照した応募書類の項目、判定の対応表、別名の一覧の版
• 採用担当が印を覆した記録と、候補者から聞いた説明
• 代わりの書類の依頼と、届いた書類との対応
• 照会の同意を取った日と、同意の範囲

保存の期間と、見られる人を先に決めます。 レポートには候補者の学歴・職歴と、照会先の担当者の情報が書かれています。採用に至らなかった候補者のレポートをいつ消すかも、ここで決めておきます。