人材紹介会社のキャリアアドバイザーが、職務経歴書と面談記録から企業に出す推薦文の下書きを作り、本人が特定できる記載を伏せる

処理の起点を決める

キャリアアドバイザーが推薦の一覧で「推薦文を作る」にしたことを起点にします。 推薦するかどうかは人が決めるので、決めた組み合わせだけを処理します。 推薦の候補をAIが自動で選んで推薦文まで作る形にはしません。

下書きは数分で出る想定で、出たら担当者に通知します。 同じ求職者を複数の企業に推薦するときは、組み合わせごとに別々に処理します。前に書いた別の企業向けの推薦文は、入力に使いません。 第3章の（b）の混ざりの元を、最初から断ちます。

入力データを集める

質を決めるのは、面談記録の欄の分け方です。 転職の理由を「本人から聞いた理由」と「企業に伝える理由」の2つの欄に分けて書いておけば、AIに渡すのは後者だけにできます。 1つの自由記述の欄に全部書かれていると、どこまで渡してよいかを機械では分けられません。

同意の記録には、伏せる項目を値で持たせます。 「現職の社名：伏せる、置き換え：従業員3,000名の電機メーカー」「担当顧客名：伏せる、置き換え：大手通信会社」のように、伏せる値と置き換えの言い方を組で登録します。 面談のときにキャリアアドバイザーが求職者と一緒に決める欄です。

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

面談記録は、欄を指定して読みます。 記録の全体を読んでから使う欄を選ぶのではなく、最初から使ってよい欄しか取り出しません。 渡さない欄は、Azure Functions のメモリにも載せないようにします。

推薦先の企業への提供の同意が無いときは、処理を止めます。 同意の記録を読み、その企業への推薦に同意が無ければ、下書きを作らずに担当者へ戻します。

AIへ渡す前に整形する

1. 伏せる値の置き換え … 同意の記録の伏せる値を、職務経歴書と面談記録の中から探し、登録された置き換えの言い方に置き換えます。全角・半角、「株式会社」の前後、略称も一覧に入れて探します
2. 固定で伏せる値 … 氏名、生年月日、住所、電話番号、メールアドレスは、同意の内容にかかわらず推薦文の材料から外します。企業には別の欄で渡るものです
3. 漏れの検出 … Azure AI Language のテキストの PII 検出で、Person、Organization、Address、PhoneNumber、Email の区分を拾います。拾ったものは自動では伏せず、担当者に確かめてもらう一覧にします
4. 渡すべきでない語の検出 … 本籍、出生地、家族の状況、宗教、政党、労働組合などに関わる語の一覧で検出し、その文を材料から外して担当者に知らせます
5. 求人票の条件の分解 … 必須の条件と歓迎の条件を、1行1条件に分けて番号を付けます

1番目の置き換えは、AIには伏せ字と分かる形にします。 「〔現職：従業員3,000名の電機メーカー〕」のように括弧でくくり、初出だけ置き換えの言い方を付け、2回目以降は「〔現職〕」にそろえます。 こうしておくと、AIは同じ会社だと分かったうえで文章を組み立てられ、伏せ字を元の名前に戻そうとすることもありません。

3番目で拾ったものを自動で伏せないのは、拾いすぎるからです。 組織名の区分には、「AWS」「Salesforce」のような使える技術の名前も入ります。全部伏せると、推薦文から求職者の強みが消えます。伏せるかどうかは担当者が決め、決めたものは同意の記録に足して次から機械で置き換えます。

PII 検出は日本語に対応しています。 公式の言語の一覧では、テキストの PII 検出の対応言語に日本語（ja）が含まれています。区分は piiCategories で指定して絞れるとされているので、推薦文の材料で問題になる区分だけを指定します。

4番目は、厚生労働省の指針に合わせた一覧です。 職業紹介事業者は、人種、民族、社会的身分、門地、本籍、出生地その他社会的差別の原因となるおそれのある事項、思想及び信条、労働組合への加入状況を、原則として収集してはならないとされています。収集してはならない情報が、推薦文を通じて企業に渡ることも防ぎます。

AIに処理させる

させるのは、求人票の条件ごとに合う経験を職務経歴書から拾い、推薦文の下書きにし、根拠の箇所を示し、特定につながりうる記載に印を付けることです。

一番上の行の右端が、この構成でいちばん大事な扱いです。 必須の条件に合う経験が見当たらないとき、AIは近い経験を広く解釈して「十分な経験があります」と書きます。推薦文に書かれた経験を、企業は書類選考の根拠にします。 書けないものは書かず、担当者に「この条件は経歴から読めない」と示します。

最後の行は、置き換えでは消えない特定の手がかりです。 社名を「大手電機メーカー」に置き換えても、「社内で初めて〇〇賞を受けた」「新聞に載った××の立ち上げ」と書けば、業界の人には誰か分かります。AIは文脈からこうした記述を見つけるのが得意なので、ここだけは候補を広めに出させます。

2行目がいちばん起きやすい失敗です。 「売上を前年の1.8倍にした」を「約2倍」と丸めると、面接で数字を聞かれた求職者が、推薦文と違うことを言うことになります。

指示内容を固定する

あなたは人材紹介会社で、求人企業に出す推薦文の下書きを作る担当です。
渡された職務経歴書・面談記録・求人票だけを使って書いてください。推測で補わないでください。

【書くこと】
1. requirement_matches: 求人票の条件の番号ごとに、合う経験を職務経歴書から拾い、1〜2文で書く。
   evidence に、根拠にした職務経歴書の文を一字一句写す。
2. strengths: 面談記録の強みの欄と、職務経歴書の成果から、2〜3点。
3. motivation: 面談記録の「企業に伝える転職の理由」「志望の動機」の欄だけから書く。
4. conditions: 面談記録の希望の条件の欄から書く。
5. identifying_risks: 置き換えの後でも本人を絞り込めそうな記述を引用する。

【厳守事項】
- 職務経歴書と面談記録に無い経験、成果、資格を書かないでください。
- 合う経験が見当たらない条件は、status を not_found にし、text を空にしてください。
  近い経験を広く解釈して埋めないでください。
- 数字は職務経歴書に書かれたとおりに書いてください。丸めたり言い換えたりしないでください。
- 〔 〕で囲まれた語は伏せ字の置き換えです。そのまま使い、元の名前を推測しないでください。
- 年齢、性別、家族の状況、健康、出身地、宗教、政治、労働組合について書かないでください。
  材料の中にあっても書かないでください。
- 推薦の可否、選考に通る見込みを書かないでください。
- identifying_risks は迷うものも含めて出してください。印を付けるだけで、書き換えないでください。

【求人票（条件は番号付き）】{job}
【職務経歴書（伏せ字の後）】{resume}
【面談記録（使ってよい欄だけ）】{interview}

「材料の中にあっても書かない」を足しているのは、前処理をすり抜けたものへの備えです。 渡すべきでない語の一覧は完全ではありません。一覧から漏れた家族の話が材料に残っていても、指示の側でもう一度止めます。

identifying_risks だけ「迷うものも含めて」と書いているのは、倒す向きが他と逆だからです。 推薦文の本文は書かない側に倒し、特定の手がかりは出す側に倒します。どちらも、間違えたときに求職者の不利益が小さい側です。

出力形式を固定する

次の形のJSONを、構造化出力のスキーマで受け取ります。

{
  "recommendation_id": "",
  "requirement_matches": [
    { "req_no": "", "req_type": "must | nice", "status": "matched | not_found",
      "text": "", "evidence": "" }
  ],
  "strengths": [ { "text": "", "evidence": "" } ],
  "motivation": "",
  "conditions": "",
  "identifying_risks": [ { "quote": "", "reason": "" } ]
}

公式の説明では、構造化出力ではすべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する必要があり、最大100個のオブジェクトのプロパティと最大5段の入れ子が持てるとされています。

1つ目の理由は、根拠をプログラムで照合できることです。 Azure Functions が evidence を伏せ字の後の職務経歴書と突き合わせ、一致しないものは「根拠を確認できない」として下書きの画面で赤く示します。

2つ目は、伏せた値の残りを機械で探せることです。 下書きのすべての文字列を、同意の記録の伏せる値と固定で伏せる値で検索します。1件でも見つかれば、下書きを担当者に出さずに止めます。 前処理で伏せているので通常は起きませんが、伏せる値の表記ゆれの一覧が足りないと起きます。

必須の条件の1つには、たとえば次のような要素が返ります。

{ "req_no": "M2", "req_type": "must", "status": "matched",
  "text": "〔現職〕で基幹システムの刷新に5年携わり、要件定義から移行まで6名のチームを率いました。",
  "evidence": "2019年4月〜現在 〔現職〕 基幹システム刷新プロジェクト（要件定義〜移行、チームリーダー、メンバー6名）" }

text の「5年」は根拠の「2019年4月〜現在」から読める範囲かを、担当者が見る箇所です。 期間の計算を伴う記述は、照合が通っても目で確かめる対象にします。

3つ目は、求人票の条件への答え方がそろうことです。 requirement_matches を条件の番号順に並べて推薦文の前半にすれば、第3章の（d）の書き方の違いが、構成のところでそろいます。

システムへ連携する

職務経歴書のファイルそのものは、この構成では書き換えません。 企業に出す職務経歴書の伏せ字は、同じ伏せる値の一覧を使って別の工程で作るか、担当者がいまの方法で行います。推薦文と職務経歴書で伏せ方がずれないよう、一覧は1つにします。

人が確認する

1. blocked を最初に見る … 伏せた値が残った理由を確かめ、表記ゆれを同意の記録の一覧に足してから作り直します
2. review の印を見る … identifying_risks と PII 検出の拾い出しを1つずつ見て、伏せるか残すかを決めます
3. not_found の条件を確かめる … 経歴から本当に読めないのか、職務経歴書に書かれていないだけなのかを考えます。後者なら求職者に聞いて経歴書を直してもらいます
4. 本文を読んで直す … 求職者の人柄や、面談で感じた強みを担当者の言葉で足します
5. 迷う記載は求職者に確かめる … 伏せるか迷った記載は、送る前に求職者に聞きます

確認の画面は、左に下書き、右に根拠の職務経歴書を並べます。 下書きの文を選ぶと、根拠にした箇所が右側で光るようにし、照合が通らなかった文は赤、identifying_risks の引用は黄色で示します。担当者が見る場所を色で先に示しておくことが、1件7分に収める工夫です。

3番目は、推薦文の外にも効きます。 条件に合う経験があるのに職務経歴書に書かれていないなら、直すべきは職務経歴書のほうです。 求職者と一緒に経歴書を直すと、他の企業への推薦でも同じ経験が拾えるようになります。

目標は、600件をならして1件7分です。 ready の下書きは読んで担当者の言葉を足すだけで数分、review の下書きは印を見て決める分だけ時間がかかります。

例外に対処する

上の2行は、AIの前で止める例外です。 同意が無いまま下書きを作れば、その時点で求職者の情報を推薦の目的で使ったことになります。作ってから捨てるのではなく、作る前に止めます。

記録を残す

• 推薦の番号ごとの入力（伏せ字の後の職務経歴書、渡した面談記録の欄、求人票）
• 適用した伏せる値の一覧の版と、置き換えた箇所の数
• PII 検出の結果と、担当者が伏せる・残すと決めた記録
• Azure OpenAI に渡した入力と、返ってきたJSONの全文
• 根拠の照合の結果と、下書きの状態
• 担当者が直した記録と、企業に送った最終版

3つ目が、伏せる値の一覧を育てる材料になります。 担当者が「伏せる」と決めた組織名は、次からその求職者の同意の記録に足し、機械で置き換えます。 使える技術の名前で「残す」と決めたものは、検出の除外の一覧に足します。