選考を終えた応募者の個人情報のうち保存期限が来たものを応募者台帳から拾い、削除の対象と残す理由がある例外を判定して、採用担当の確認を経てから消す

処理の起点を決める

毎月1日の朝7時に、スケジュールされたクラウド フローを動かします。 作ると繰り返しのトリガーがフローに入り、「毎週月曜日の午前9時」のような定期的なスケジュールで実行できます。日次にしないのは、確認と承認を月に1回のまとまった作業にするためです。 毎日数人ずつ確認を頼むと、担当は後回しにします。

判定の結果は、その月の「削除確認」として1つのまとまりにします。 削除確認のリストに「対象月」の列を持たせ、同じ月の行は同じ承認にかけます。 前の月の確認が終わっていない行があれば、新しい月の判定を出す前に Teams で担当に知らせます。

フロー②の起点は、承認の結果です。 フロー①の最後で「開始して承認を待機」を置き、承認が返ってきたらフロー②を呼びます。 承認が拒否されたら何も消さず、拒否の理由を削除確認のリストに残します。

入力データを集める

質を決めるのは、対応の記録の本文です。 残す理由のほとんどは、ここにしか書かれていません。逆に言えば、記録に書かれていない事情はこの構成では拾えません。 本人とのやり取りを個人のメールだけで行い、記録に残さない運用だと、判定は「削除の候補」と出ます。

保存期限は、台帳の列で持ちます。 選考終了日から計算する式で埋めますが、列として持つことで、例外として残した人の期限を担当が延ばせるようにします。

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

選考中の再応募は、メールアドレスで探します。 氏名で探すと、同姓同名の別人を拾い、表記の違いで同じ人を落とします。メールアドレスを変えて応募した人は拾えません。 そこは担当の確認に残します。

書類の一覧は、判定のときには中身を開きません。 履歴書や職務経歴書をAIに渡す理由はありません。残す理由は書類ではなく、対応の記録に書かれているからです。 一覧はフォルダが空でないか、消す対象が何件あるかを数えるためだけに取ります。

AIへ渡す前に整形する

1. 入社した人を除く … 選考の結果が「入社」の行は、人事の管理へ移す対象なので、この構成では扱いません
2. 人材プールの同意を規則で見る … 同意があり、同意の期限が今日より後なら「同意期間中」として、AIに渡さずに残す側へ回します
3. 選考中の再応募を規則で見る … 同じメールアドレスで選考中の応募があれば「再応募の選考中」として、AIに渡さずに担当の確認へ回します
4. 対応の記録から個人を識別できる情報を除く … 氏名、メールアドレス、電話番号、住所を、記録の本文から置き換えます。「〇〇様」は「本人」に、アドレスは「（メール）」にします
5. 記録を日付順に並べてつなぐ … 1人分の記録を、日付と書いた人の役職だけを付けて1つの文にします
6. 記録が無い人 … 対応の記録が1件も無ければ、AIに渡さずに「記録なし」として削除の候補にします

4番目を省かないでください。 判定に氏名は要りません。AIに渡す文に氏名や連絡先が残っていると、期限が来て消すはずの情報を、消す直前にもう一度外へ渡すことになります。

2番目と3番目をAIに任せないのは、決まった欄で決まるからです。 同意の期限も選考中の応募も、日付と状態の比較で答えが出ます。AIに渡すと、記録の文の「また応募したいと言っていた」を同意と取り違えます。

AIに処理させる

させるのは、1人分の対応の記録を読み、決まった「残す理由」に当たる事情が書かれているかを判定し、根拠にした文を写すことだけです。

4行目の consent_unclear が、この構成でいちばん大事な区別です。 本人が「また声をかけてほしい」と言ったことは、人材プールへの同意の記録ではありません。残すなら同意を取り直し、取れないなら消すのが筋で、どちらにするかは担当が決めます。 AIには「同意に近い記載がある」と示させるだけにします。

最後の行が、思ったより起きやすい失敗です。 「面接後、本人から電話あり」とだけ書かれた記録を渡すと、AIは苦情だった可能性を考えて complaint を付けがちです。書かれた内容で決められないものは needs_human にさせます。 残す側にも消す側にも、推測で倒さないことが大事です。

指示内容を固定する

あなたは人事部で、選考を終えた応募者の個人情報を、保存期限が来たときに見直す担当です。
1人分の対応の記録を読み、決まった「残す理由」に当たる事情が書かれているかを判定してください。
記録に書かれていることだけを根拠にしてください。

【残す理由のコード】
open_request：本人からの開示・訂正・利用停止などの請求や、情報の扱いについての問い合わせが対応中
complaint：選考や面接についての苦情が対応中、または対応を終えた記録が無い
dispute：弁護士・行政機関からの連絡など、紛争や法的な請求のおそれがある
consent_unclear：今後の連絡を望む記載があるが、人材プールへの同意の記録ではない
other_hold：上のどれでもないが、残すよう求める記載がある

【判定】
delete_candidate：残す理由に当たる事情が書かれていない
keep_candidate：残す理由のどれかに当たる
needs_human：書かれた事情が、残す理由に当たるか決められない

【厳守事項】
- 記録に書かれていない事情を推測しないでください。
  「電話あり」とだけ書かれていて内容が分からないときは needs_human にしてください。
- 「また応募したい」「次の募集を教えてほしい」は、同意の記録ではありません。
  consent_unclear とし、keep_candidate にしてください。
- 「対応済み」「解決」と書かれている請求や苦情は、残す理由に当たりません。
  ただし、対応を終えた記録が無いものは対応中として扱ってください。
- 根拠にした文は、記録の文をそのまま evidence に写してください。
- 消してよいかどうか、保存期間を何か月延ばすべきかは書かないでください。
- 残すことが法的に許されるかどうかの意見を書かないでください。
- 回答に JSON マークダウンを含めないでください。

【保存期限】{retention_date}
【選考の結果と選考終了日】{result}／{closed_date}
【対応の記録（日付順。氏名と連絡先は置き換え済み）】{records}

「対応済み」の扱いを1行で書いているのは、古い苦情で全員が残る側に倒れるのを防ぐためです。 苦情という語があるだけで complaint を付けると、1年前に解決した苦情の記録がある人まで、いつまでも消えません。 対応を終えた記録があるかで分けます。

プロンプトの温度は既定の0のまま使います。 同じ記録を毎月見直すことがあるので、月によって判定が変わらないことを優先します。

出力形式を固定する

次の形のJSONで受け取ります。 プロンプトの出力を JSON にし、形式をカスタムで保存します。

{
  "applicant_id": "A-2025-03812",
  "verdict": "delete_candidate | keep_candidate | needs_human",
  "reasons": [
    { "code": "open_request", "evidence": "" }
  ],
  "note": ""
}

JSONで受け取る1つ目の理由は、判定と理由を別の列に書けることです。 削除確認のリストに「AIの判定」「理由のコード」「根拠の文」「担当の判断」の列を並べ、担当は「AIの判定」で絞り込んで、keep_candidate と needs_human から見ます。

2つ目は、規則の判定と同じ列に並べられることです。 前処理で決まった「同意期間中」「再応募の選考中」「記録なし」も、同じリストの「AIの判定」の列に、規則で決まったことが分かる値で入れます。 担当は1つのリストで全員を見られます。

3つ目は、evidence で確認が速くなることです。 担当は記録の全文を開く前に、どの文を見て判定したかを一覧で読めます。

公式の説明では、プロンプトを保存すると形式が固定され、フローで使うときは保存された形式が使われるとされています。reasons をキーを持つ要素の配列にしているのは、キーの無い配列の形式がサポートされないためです。

システムへ連携する

フロー②が消すのは、「担当の判断」が「削除する」になっている行だけです。 AIの判定が delete_candidate でも、担当の判断が空なら消しません。担当の判断の列を空のまま承認に回すことは、フローの条件で止めます。

メールボックスと日程調整の道具に残る情報は、このフローでは消しません。 採用の共有メールボックスにある応募者とのメールや、面接の日程調整に使った道具の記録は、それぞれ別の消し方が要ります。 削除の記録に「メールボックスは手作業で消す」の列を設け、担当が月に1回まとめて消して印を付けます。

人が確認する

採用担当が見るのは、削除確認のリストの全員ですが、時間をかけるのは一部です。

1. keep_candidate と needs_human を先に見る … 根拠の文を読み、必要なら記録の全文を開いて、残すか消すかを決めます
2. 残すなら、次に見直す日を入れる … 請求の対応が終わる見込みの日など。期限を決めずに残さないのが決まりです
3. consent_unclear は同意を取り直すか決める … 取り直すなら本人に連絡し、取れなければ翌月に消します
4. 再応募の選考中は、選考の担当に聞く … 前回の記録を選考に使っているかを確かめます
5. delete_candidate は一覧で流し見る … 根拠の欄が空であること、選考の結果と終了日に違和感が無いことを見て、「削除する」を入れます

採用責任者は、その月の一覧で件数と「残す」の理由を見て承認します。 1人ずつを見直すのではなく、残す人の理由が規程に合っているかと、削除の人数が月ごとに大きく変わっていないかを見ます。

1番目を省かないでください。 keep_candidate を見ずに承認すると、残す理由のある人まで、担当の判断の列が「削除する」のまま消えることがあります。

例外に対処する

6行目の順番が大事です。 書類を消し終えてから台帳を消去済みにします。逆にすると、書類が消えていないのに台帳では消したことになり、どこにも記録の無い個人情報がフォルダに残ります。

記録を残す

• 判定にかけた応募者ID、保存期限、選考の結果と終了日
• プロンプトに渡した文（置き換えた後の記録）と、返ってきた JSON
• 担当の判断、判断した人と日時、残す場合の次に見直す日
• 承認の結果、承認した人と日時
• 消した書類の件数とファイル名、台帳を消去済みにした日時
• メールボックスなどを手作業で消した印

ログには、消した人の氏名を残しません。 応募者IDと日付と件数だけにします。消した個人情報を、削除の記録の側に写して残してしまっては意味がありません。 本人から「自分の情報は消えたか」と問い合わせを受けたときは、本人のメールアドレスから台帳の応募者IDを引けないので、問い合わせの時点で受け取った情報と応募者IDの対応を、請求の手順の側で確かめます。