合同企業説明会や学内の説明会で学生が手書きするアンケートを読み取り、氏名・学校・連絡先・関心のある職種を応募者台帳にそろえて、その日のうちにお礼と案内を送れるようにする

処理の起点を決める

説明会ごとのドライブのフォルダにスキャンが保存されたことを起点にします。 Apps Script の時間主導型トリガーを数分おきに動かし、新しいファイルを探します。フォルダの名前に説明会の日付と名前を入れておき、台帳の行と下書きに差し込みます。

スキャンは、説明会の当日に行います。 会場に持ち運べるスキャナーがあれば会場で、無ければ帰社した日のうちに行います。翌日に回すと、お礼が翌日以降になり、この構成を入れた意味が半分になります。

処理が終わったファイルは処理済みのフォルダに移します。移すのは、台帳への書き込みと下書きの作成まで終わったときだけにします。

入力データを集める

質を決めるのは、アンケートの書式です。 メールアドレスの欄を1文字ずつの枡目にすると、読み違いが減ります。案内の希望を□の1つの選択にしておけば、チェックボックスとして読めます。書式を変えられるなら、構成を作る前に変えます。

応募者台帳は、重複の候補を探すために使います。 AIには渡さず、Apps Script の側で照らします。

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

読み取りは、Apps Script から Form Parser のプロセッサを呼ぶだけです。オンラインの処理は1回の要求で最大15ページなので、説明会のスキャンをまとめて1回で送らず、1枚ずつに分けてから送ります。 まとめて送る場合は、公式の上限が100ページのバッチ処理を使います。

メールアドレスは、信頼度を文字のまとまりごとに見ます。 アドレス全体の信頼度が高くても、1文字だけ低いことがあります。低い文字を含むアドレスは、下書きを作らずに担当に回します。

応募者台帳は、Apps Script がスプレッドシートを読むだけです。 重複の照合のために、メールアドレスは小文字にそろえ、前後の空白を落とした形を別の列に持ちます。氏名は漢字の異体字で揺れるので、ふりがなと卒業予定年の組み合わせも照合の材料にします。どちらも規則で書ける処理なので、AIには任せません。

AIへ渡す前に整形する

1. 形式の確認 … スキャンはPDFで保存します
2. 解像度の確認 … 手書きの細かい文字を読むため、300dpiで保存します
3. 1枚ずつに分ける … 説明会のスキャンをページごとに分け、ページの順を残します
4. 白紙と別の紙の確認 … 書きかけで白紙に近いもの、会社案内の資料が混ざったものは、処理せずに担当へ回します
5. 向きの確認 … 逆さに通されたページの向きを直します
6. 書式の版の確認 … 利用目的の案内が入った新しい書式かを、用紙の隅に印刷した版の番号で確かめます。古い書式のアンケートは、担当へ回します

4番目で白紙に近いものを外すのは、学生が書きかけでブースを離れることがあるためです。 氏名だけが書かれたアンケートから台帳の行を作ると、連絡先の無い行が台帳に残ります。

6番目で書式の版を見るのは、案内を送ってよいかが書式によって変わるためです。 利用目的の案内と案内の希望の□が無い古い書式で集めたアンケートは、学生が案内を受け取ることに同意したかどうかが分かりません。 書式を改めた後も、ブースに古い用紙が残っていることがあるので、版の番号で機械的に分けます。

AIに処理させる

させるのは、アンケートの欄を台帳の項目に書かれたとおりに写すことと、自由記述から質問を取り出すこと、選考に関係のない記載に印を付けることです。 重複の候補とアドレスの確認は、Apps Script の規則で行います。

4行目が、AIを使う理由です。 学生は「父が御社の取引先に勤めています」「地元の○○県に戻りたい」のように、さまざまな書き方で書きます。 決まった言葉の一覧では拾いきれないので、記載の種類に当たるかどうかだけをAIに見させ、中身は写させません。

1行目がいちばん大事です。 「taro.yamada」の「.」が読めないとき、AIは「taroyamada」と「taro.yamada」のどちらかを選びます。選んだアドレスが正しく見えるほど、読み違いに気づけません。

指示内容を固定する

あなたは採用の担当で、説明会で学生が手書きしたアンケートの
読み取り結果を、応募者台帳の項目に写す立場です。OCRが返した結果だけを見て、
書かれていることを写してください。推測で埋めないでください。

【写す項目】
name（氏名）、kana（ふりがな）、school（学校）、faculty（学部・学科）、
grad_year（卒業予定年）、email、phone、
job_interest（印の付いた職種）、wants_info（案内の希望）

【厳守事項】
- メールアドレスと電話番号は書かれたとおりの文字列で写してください。
  読めない文字を推測で補わないでください。読めない文字が1つでもあれば
  status を unreadable にし、読めた部分だけを value に入れてください。
- 学校名は書かれたとおりに写してください。略称を正式名に直さないでください。
- 欄が空欄なら status を blank にしてください。空欄と読めない欄を混ぜないでください。
- 自由記述のうち、当社への質問だけを questions に書き出してください。
- 自由記述に、本籍・出生地、家族（家族の職業・勤め先を含む）、
  宗教、支持政党、思想・信条に当たる記載があれば、sensitive を true に
  してください。その記載の中身は、どこにも書き写さないでください。
- 学生を評価する言葉や、選考に進めるべきかは書かないでください。
- アンケートでない紙と判断した場合は、document_type に種類を書いてください。

【読み取り結果】{ocr_result}

「読めない文字が1つでもあれば unreadable」を明記しないと、読めた部分から推測してアドレスを完成させます。 推測が当たることも多いので、外れたときにだけ気づけないという形の失敗になります。

「中身はどこにも書き写さない」は、質問の取り出しとの関係で書いています。 質問と同じ段落に家族のことが書かれていると、質問として書き出した文に、そのまま家族のことが入ります。

出力形式を固定する

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

{
  "document_type": "job_fair_survey",
  "fields": [
    { "item": "name | kana | school | faculty | grad_year | email | phone",
      "value": "", "status": "read | blank | unreadable" }
  ],
  "job_interest": [],
  "wants_info": "yes | no | unclear",
  "questions": [],
  "sensitive": false
}

1つ目の理由は、メールアドレスの status で下書きを作るかを機械的に決められることです。 unreadable のアドレスには、どの規則でも下書きを作りません。

2つ目は、仕分けを Apps Script の規則で持てることです。

wants_info が unclear のときに下書きを作らないのは、案内を送ってよいかは学生の選んだことだからです。 印が薄い、両方に印がある、といったアンケートは、送らない側に倒します。

3つ目は、sensitive で記載の有無だけを残せることです。 中身を台帳に写さずに、原本に記載があることを担当に知らせられます。 原本の扱いは、自社の個人情報の取扱いの決まりに沿って担当が決めます。

公式のページでは、列挙の値の大文字・小文字までは保証されないとされているので、status などは Apps Script で小文字にそろえてから使います。stop_reason が max_tokens のときは出力が途中で切れているので、台帳に書かずに呼び直します。

システムへ連携する

応募者台帳の本体には、この構成から書き込みません。 取り込み待ちのシートから本体へ移すのは、担当の操作です。重複の候補を自動で既存の行にまとめることもしません。 別の学生を1人にまとめてしまうと、片方の学生への連絡が消えます。

メールは下書きまでです。 公式のリファレンスでは、GmailApp.createDraft は任意の引数付きで下書きを作るとされています。送る操作は、担当が下書きの一覧を確かめてから行います。

人が確認する

担当が原本を見るのは、印の付いた行だけです。 印の無い行は、取り込み待ちのシートの行と下書きを流し見ます。

1. check_email を先に見る … 原本でアドレスを確かめます。確かめられないものは、電話番号があれば電話で、無ければ送らないことにします
2. check_consent を見る … 原本で案内の希望の欄を確かめます。判断がつかなければ送りません
3. duplicate と possible_duplicate を見る … 既存の行に説明会の参加を足すか、新しい行にするかを決めます
4. sensitive_note を見る … 原本を見て、自社の決まりに沿って扱いを決めます。台帳には写しません
5. question に返信する … 質問への返信は、担当が書きます
6. 下書きの一覧を確かめて送る … 宛先と型の組み合わせを確かめます

1番目を先にするのは、その日のうちにお礼を送るためです。 読めないアドレスの学生は、放っておくと案内がまったく届かない学生になります。

6番目の下書きの確かめでは、宛先と型の組み合わせを見ます。 関心のある職種の印から型を選んでいるので、印の読み違いがあると、営業職に関心のある学生に技術職の案内が届きます。 一覧で職種の列と型の名前を並べて見れば、数十件を数分で確かめられます。送る時刻は、夜遅くを避けて担当が決めます。

目標は、900枚をならして1枚1.4分です。 印の無い行は流し見で数十秒、印の付いた行は原本を見るので数分かかります。

例外に対処する

6行目を入れているのは、合同企業説明会に高校生が来ることがあるためです。 高卒の採用には、新卒の大学生とは別の決まりがあります。この構成で扱わず、担当が別の手順で扱います。

記録を残す

• 元のスキャンと、説明会の日付・名前・スキャンした担当
• OCRが返したJSONの全文と、Claude API の応答の全文（sensitive の中身は含まない）
• 付いた印と、担当が確かめた結果・台帳の本体に移した日時
• 作った下書きと、送った日時・送った担当
• 宛先不明で戻ったメールと、確かめ直した結果
• 説明会ごとの check_email の割合

2つ目で sensitive の中身を残さないのは、ログが台帳の代わりにならないようにするためです。 写させなかった記載が、ログから読めては意味がありません。

最後の行は、アンケートの書式とスキャンを見直す材料になります。 特定の説明会だけ check_email が多いなら、机の高さや筆記具、スキャンの設定に理由があります。