人材紹介・派遣の会社で、登録会に来た求職者の手書きの登録票と履歴書を読み取り、求職者データベースの項目にそろえて、記入漏れを面談の担当へ返す

処理の起点を決める

Google Apps Script の時間主導型トリガーで、1分おきに拠点の取込フォルダを見ます。 登録会では、受付から面談が始まるまでの時間は長くて十数分です。その間に空欄の一覧が面談の担当に届かなければ、聞き取りは面談の後の電話に戻ります。

スキャンは受付で、1人分ずつ行います。 登録票2枚と履歴書をまとめて1つのPDFにし、ファイル名に受付番号を入れます。何人分かをまとめてスキャンすると、どこからどこまでが1人分かを判定する手間が増え、一覧が届くのも遅れます。

1回の実行で処理する件数に上限を置きます。 Apps Script の1回の実行は6分までとされています。1人分の読み取りと項目のそろえには数十秒かかることがあるため、1回に3人分までとし、残りは次の実行に回します。 処理が終わったファイルは処理済みフォルダへ移し、移すのはCSVの下書きと一覧の書き込みまで成功したときだけにします。

入力データを集める

質を決めるのは、様式の定義です。 欄の範囲がずれていれば、隣の欄の文字を拾って filled と判定します。様式を改訂したら、定義も同じ日に改訂します。 様式の右下に版の番号を印刷しておき、読み取った版の番号で定義を引き分けます。

いちばん下の一覧は、法令への対応として持ちます。 職業安定法に基づく指針では、人種、民族、社会的身分、門地、本籍、出生地その他社会的差別の原因となるおそれのある事項、思想及び信条、労働組合への加入状況を、原則として収集してはならないとされています。履歴書にこれらに当たる記載があっても、データベースに入れる項目に写しません（第13章）。

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

読み取りは、Apps Script から Document AI の処理のAPIを呼ぶだけです。依頼の processOptions.ocrConfig に、次の設定を入れます。

位置は、ページの大きさで割った値（normalizedVertices）で扱います。 スキャンの解像度が拠点の複合機ごとに違っても、0から1の値で欄の範囲を定義しておけば同じ定義が使えます。

数字の欄は文字の単位で信頼度を見ます。 電話番号11桁のうち1桁だけ信頼度が低いとき、欄全体としては読めているように見えます。数字の欄は、1文字でも基準を下回れば illegible にします。

AIへ渡す前に整形する

1. 形式の確認 … Enterprise Document OCR の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP です。複合機の保存形式は PDF にします
2. 解像度の確認 … 公式には、OCRの精度のためにスキャンは最低200dpiが望ましいとされています。鉛筆の薄い字を読むなら、300dpiにします
3. 圧縮の確認 … JPEG のような非可逆の形式は、強く圧縮すると精度が落ちることがあるとされています
4. ページの種類の判定 … 1ページ目の様式の版の番号を読み、登録票のページと履歴書のページを分けます
5. 向きの確認 … 逆さまに置かれたページは、読み取りの前に回します
6. 品質の点数の確認 … 品質の点数が0.5を下回ると、ぼやけ・暗さなどの理由が返るとされています。理由が返ったページは、受付にスキャンのやり直しを知らせます
7. 受付番号の照合 … ファイル名の受付番号と、登録票に書かれた受付番号が合うかを見ます

6番目を受付に返すのが要です。 求職者がまだ会場にいるうちにスキャンし直せば済みますが、帰ってから気づけば、紙を見直すしかありません。 品質の点数は、そのためにいちばん早く届く合図です。

AIに処理させる

欄ごとの記入の有無は、AIに判定させません。 様式の定義の範囲に手書きの文字があるかで、Apps Script が決めます。

AIにさせるのは、欄ごとの文字をデータベースの項目にそろえることだけです。

1行目がいちばん起きやすい失敗です。 生年月日から年齢の欄を、住所から最寄り駅の欄を、AIは善意で埋めます。埋まった欄は blank の一覧から消え、面談で聞く機会がなくなります。 年齢の計算は必要ならデータベースの側で行います。

指示内容を固定する

あなたは人材派遣会社の登録の事務で、求職者が手書きした登録票と履歴書を、
求職者データベースの項目にそろえる立場です。
OCRが返した欄ごとの文字だけを見てください。推測で埋めないでください。

【やること】
1. 登録票の欄ごとの文字を、データベースの項目と選択肢のコードにそろえる
2. 履歴書の学歴・職歴の行を、年月・名称・区分（入学／卒業／入社／退社）に分ける
3. 資格を、資格のコードにそろえる

【厳守事項】
- status が blank の欄は、value を空のままにしてください。
  ほかの欄から計算したり推し量ったりして埋めないでください。
  （例：生年月日から年齢を、住所から最寄り駅を埋めない）
- status が illegible の欄は、value を空にし、candidates に読みの候補を
  最大3つまで入れてください。候補のどれかに決めないでください。
- 電話番号、メールアドレス、郵便番号、番地は、読み取った文字をそのまま写してください。
  桁を補う、よくある形に直すことをしないでください。
- 選択肢のコードに当てはまらない記載は、code を空にし、raw に原文を残してください。
- 職歴の空白期間や転職の理由について、解釈や所見を書かないでください。
- 「取り込まない項目の一覧」に当たる記載は、どの項目にも写さないでください。
  記載があったことだけを excluded_found に true で示してください。
- 求職者の向き不向きや、紹介の可否について書かないでください。

【欄ごとの文字と状態】{fields}
【データベースの項目の定義】{db_schema}
【取り込まない項目の一覧】{excluded_items}

「生年月日から年齢を埋めない」と例を挙げているのは、例が無いと止まらないからです。 「推測で埋めない」だけでは、計算で出せるものは推測ではないと扱われます。禁じるのは、空欄を何かで埋めることそのものです。

取り込まない項目について「記載があったこと」だけを返させるのは、紙の扱いを決めるためです。 写さないだけでは、その履歴書の写しがドライブに残ります。記載があった件だけ、事務が保管のしかたを見直せます。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、指定したJSONスキーマに従う応答を生成させられ、enum で値の候補を限り、required で必須の項目を決められるとされています。

{
  "reception_no": "",
  "form_version": "",
  "fields": [
    { "field": "", "status": "filled | blank | illegible | not_applicable",
      "value": "", "code": "", "raw": "", "candidates": [], "confidence": 0 }
  ],
  "career": [
    { "kind": "education | work", "year_month": "", "name": "",
      "event": "", "raw": "" }
  ],
  "excluded_found": false
}

1つ目の理由は、status を Apps Script が決め、value をAIが埋めるという分担を形で守れることです。 AIは status を受け取って返すだけで、書き換えません。返ってきた status が渡したものと違えば、その件を全部人に回します。

2つ目の理由は、スキーマに合っていても値が正しいとは限らないことです。 公式にも、出力は構文として正しいJSONでも、値はアプリケーションの側で必ず検証するよう書かれています。Apps Script では、blank の欄に value が入っていないか、電話番号が数字だけか、コードが選択肢の一覧にあるかを確かめます。

3つ目は、面談の担当への一覧をそのまま作れることです。 必須の欄のうち blank と illegible のものを抜き出し、次の形でメールとスプレッドシートに出します。

システムへ連携する

一覧の宛先は、その日の面談の担当です。 拠点ごとの登録会の担当表をスプレッドシートで持ち、受付番号から担当を引きます。拠点の全員に送ると、誰も見ない一覧になります。

求職者データベースへは、この構成から書き込みません。 既存のシステムのCSVの取り込みは事務が行い、取り込む前に illegible が残っていないことを確かめます。

人が確認する

人が確かめるのは2か所です。

1. 面談の前に、コーディネーターが一覧を見る … blank の欄を面談の中で本人に聞き、登録票の余白に書き足します
2. 面談の後に、事務が下書きを確かめる … illegible の欄を紙で見て直し、面談で書き足された内容を足します。電話番号とメールアドレスは、filled でも紙と見比べます
3. コードに当てはまらなかった記載を見る … raw に残った原文を読み、コードを選ぶか、データベースのメモの欄に入れます
4. excluded_found が true の件を見る … 写しの保管のしかたを決めます
5. 直したら記録する … どの欄を、何から何へ直したかを残します

2番目の電話番号とメールアドレスの見比べは、省かないでください。 信頼度が基準を上回っていても、1文字の違いで連絡がつかなくなる欄です。 ここに数十秒かけることが、後の聞き直しの電話を減らします。

目標は、360件をならして1件3分です。 事務の確認は、filled の欄を流し見て、印の付いた欄だけを紙と見比べる作業になります。

例外に対処する

上から3行目までは、様式とスキャンの問題です。 欄の枠を大きくする、記入例を様式に刷る、鉛筆ではなくボールペンを置くといった直し方のほうが、読み取りの精度を上げるより効きます。

記録を残す

• 元のPDFと、受付番号・拠点・受け付けた日時
• Document AI が返した Document のJSONの全文と、品質の点数
• 欄ごとの状態と、そのとき使った様式の定義の版
• Gemini API が返した fields と career
• 面談の担当への一覧と、面談で聞き取って書き足した内容
• 事務が直した記録と、CSVを取り込んだ日時

様式の定義の版を残すのは、様式の改訂で欄の範囲が変わるためです。 古い定義で新しい様式を読むと、blank が大量に出ます。版が残っていれば、どの日の分を読み直せばよいかが決まります。

保存の期間を決めておきます。 指針では求職者の個人情報を適正に管理するために必要な措置を講じるとされています。登録をやめた人の書類の写しと読み取り結果をいつ消すかを、データベースの側の扱いとそろえて決めます。