AIで候補者ごとにスカウト文面を調整する方法|共通文をそのまま送らない

AIで採用スカウトを個別化するときは、候補者の確認できる公開情報から求人との接点を1つ示し、共通templateへ自然に加えます。性格や転職意欲を推測させず、文面は候補者ごとに送信前reviewします。

AIものさし編集部

候補者ごとにスカウトを調整するなら、候補者の公開profileで確認できる事実を一つ選び、求人内容との関係を短く伝えます。性格、転職意欲、価値観をAIに推測させず、求人条件や実績を創作しないことが前提です。AIは文面の下書きに使い、候補者ごとに根拠・求人との関連・表現を人が確認してから送信します。

個別化の入力を限定する

最初に求人側の確定情報と、候補者について確認できる情報を別の欄に置きます。求人の役割、必須業務、必要skill、勤務地、雇用形態、報酬レンジなどは採用側の承認済み情報から取得します。候補者側は、本人が公開しているprofileや応募資料に明示された経験・skillのうち、当該求人に関連するものに限ります。

| 入力 | 使う条件 | 文面での使い方 |

| 求人の業務 | 現在の募集要項で確認済み | 募集している役割を正確に紹介 |

| 必須skill | 採用要件と対応している | 候補者情報との接点を一つ説明 |

| 公開された経験 | 出典と原文を確認できる | どの経験を見て連絡したか示す |

| 勤務条件 | 会社が承認した現行条件 | 個人の希望を推測せず募集内容として伝える |

| 候補者の性格・意欲 | 推測しない | 入力・出力へ含めない |

| 根拠が曖昧な実績 | 確認できない | 個別化に使わず一般文へ戻す |

公開情報でも、文面へ転記してよいとは限りません。関係のない個人情報やセンシティブな属性を収集・推論しない運用を決めます。候補者の年齢、家族状況、健康、思想信条など、職務能力と関係しない情報からスカウト内容を調整する設計は避けます。採用基準は職務に必要な適性・能力と結び付け、各国・地域の法令や社内規程は人事・法務担当者へ確認します。

1通を作る構成

個別化は長い褒め言葉を足すことではありません。相手が「なぜ自分に連絡したのか」「どの役割の話なのか」「次に何をすればよいか」を理解できる構成にします。

| 部分 | 役割 | QAの問い |

| 冒頭 | 連絡理由を一つ示す | 公開情報のどの記載に基づくか |

| 求人との接点 | 経験と業務を結び付ける | 必要なskillを誇張していないか |

| 役割紹介 | 募集内容・条件を伝える | 最新の募集要項と一致するか |

| CTA | 任意の次Actionを示す | 返答の負担、方法、期限が明確か |

| 差出人 | 採用担当者と会社を示す | 候補者が連絡元を確認できるか |

「プロフィールを拝見しました」だけでは、なぜ声をかけたのか伝わりません。一方でprofileの情報を羅列すると監視されている印象を与える場合があります。求人に関係する一つの事実だけを使い、それが募集業務とどうつながるか説明します。根拠のない「業界を変える力」「必ず活躍できる」といった断定は避けます。

下書きに使う入力テンプレート

生成システムには、候補者情報を大量に貼り付けず、必要な項目だけを与えます。以下のように項目と禁止事項を明確にすると、AIに任せる範囲と人が確認する点が見えます。

入力

  • 求人の承認済み要約:role、業務、必須要件、勤務地、雇用条件

  • 候補者の確認済み公開情報:該当する原文、URLまたは確認場所

  • 個別化に使える事実:求人と直接関係するものを1つ

  • CTA:返信、日程調整、求人詳細など、採用側が認めた選択肢

指示

「求人の事実と候補者profileの事実を混ぜず、候補者情報を使った文の横に根拠を残す。性格、転職意欲、希望条件、成果を推測しない。未確認情報は使わず、該当する接点がなければ個別化文を作らず『人が確認』と返す。求人要件を候補者が満たすと断定せず、自然な質問として確認する。」

期待する出力

  1. 個別化に選んだ事実

  2. 根拠となるprofile上の記載

  3. その事実と求人の関係

  4. スカウト本文案

  5. 未確認事項

  6. 人が送信前に見る項目

この構成なら、自然な文面だけでなく、根拠のない称賛や適合判断を発見しやすくなります。候補者情報の一覧やAIへの指示、生成文をどこまで保存するかは、採用記録の管理方針に合わせて必要最小限にします。

送信前の候補者別レビュー

共通テンプレートの確認だけでは不十分です。差し込み欄の値が候補者ごとに異なるため、bulk送信を含めて送信単位で確認します。

| 確認 | 合格条件 | 不合格なら |

| 名前・会社 | profileと一致し、古い所属を現職と誤認しない | 修正または個別化を外す |

| 経験・skill | 原文から確認でき、求人業務に関係する | 根拠が取れなければ削除 |

| 求人条件 | 募集要項・承認済み条件と一致する | 送信を止め、ownerへ確認 |

| 個別化理由 | 使った事実と求人要件の対応が説明できる | generic文へ戻す |

| 推測・誇張 | 性格、意欲、成果を創作していない | 文を削除し再レビュー |

| CTA | 任意性、返答方法、次の手順が分かる | 相手の負担を下げて再作成 |

| 個人情報 | 職務に不要な情報を参照・転記していない | 入力・出力・保存先から除く |

人がレビューするときは、生成文を先に読むのではなく、根拠の記録と求人要件を先に見ます。出力の自然さが事実確認を代替しないようにするためです。誤った会社名や古い役職だけでなく、「この経験なら転職したいはず」という推測も修正対象です。

返信率を測る場合は、送信数だけを比較せず、求人、候補者層、送信時期、件名、送信者などの違いを記録します。短期の反応率だけで個別化の質を評価すると、強い表現や誤解を招くCTAが有利に見える場合があります。返信率、辞退・苦情、誤記、候補者の理解、採用担当の修正量を合わせて見ます。

機能を使うときに確認すること

LinkedIn Recruiterは、候補者や求人のcontextを使ったAI支援メッセージのdraft、文面の調整、bulk messageのpreview/reviewに関する機能を案内しています。実際に利用できる機能や設定は契約、権限、対象画面で異なる場合があるため、現在の公式Helpと自社accountで確認してください。機能が候補者別の文面を作れることと、その文面を自動送信してよいことは別です。送信前reviewを工程から外さない運用にします。

採用業務では、人の判断が応募機会に影響します。AIが作った適合度や優先順位を、検証済みの採用判断として扱わないでください。スカウトの個別化を超えて候補者を順位付けする場合は、対象データ、評価基準、説明責任、法令、社内承認を別途検討します。ここで扱うのは連絡文の下書きであり、候補者の選考を自動化する手順ではありません。

反応が悪いときの切り分け

返答が少ないとき、AI文面をさらに個別化すれば解決するとは限りません。求人内容が曖昧、募集条件が合わない、候補者に届いていない、連絡頻度が高い、CTAが重いなど、別の原因を切り分けます。候補者の反応がないことから、本人が転職に関心がないと決め付けず、追送をする場合は頻度と停止条件を人が定めます。

誤りが発生したときは、どの情報が入力に入り、どの文が生成され、誰が承認・送信したかを追える範囲で記録します。候補者の個人情報や生成履歴を過剰に保存しないよう、保存先・アクセス権・削除期間も先に決めます。bulk送信で誤りが見つかったら、残りの送信を止め、同じテンプレートやmappingを使う対象を確認します。

AIものさしの判断

個別化の質は、候補者情報を多く使った量ではなく、求人に直接関係する確認済み事実を一つ選び、なぜ連絡したのかを誠実に伝えられるかで判断します。候補者の意欲や性格を推測しないこと、求人条件を正確に保つこと、各人への送信前確認を残すことが中心です。根拠を説明できない個別化は追加せず、共通の正確な案内へ戻します。

例を使ったレビュー方法

以下は手順を説明するための架空例です。実在候補者の情報ではありません。求人票に「社内データの可視化と分析レポート作成」と明記され、候補者の公開profileに「営業実績のダッシュボードを設計」と書かれている場合、個別化の接点は「ダッシュボード設計の経験を拝見し、社内データの可視化を担うroleをご案内したい」です。この一文が言えるのは、両方の情報を確認できた場合だけです。

この例から「分析が得意」「データ職へ転職したい」「当社で活躍する」とは結論できません。profileに書かれていない成果を補ったり、応募意思を仮定したりせず、役割の説明と質問に留めます。公開情報に具体的な接点がない場合は、個別化欄を空にし、正確な共通文を使う選択を残します。

送信量を増やす前の小さな運用テスト

最初のテストでは、異なる職種・求人条件を含む少数の下書きを人が確認します。確認者は、①使った候補者情報の出典、②求人との関連、③表現の正確さ、④不要な個人情報、⑤次Actionの明瞭さを記録します。候補者ごとに評価し、テンプレート全体が自然でも差し込み値の誤りがないとは限らない点を確認します。

誤った会社名、古い所属、求人条件の食い違いがあれば、同じsourceや差し込み規則を使うdraftを送信前に止めます。モデルのpromptだけを直すのではなく、プロフィール取得時点、求人の承認済みデータ、差し込みfield mapping、review画面を順に調べます。原因が特定できるまでbulk送信へ広げません。テストの目的は反応率を最大化することではなく、送信前に誤情報と不適切な推測を見つけられることです。

誰が何を承認するか

採用担当者は求人内容と候補者ごとの関連を、募集ownerはrole・条件の最新性を、必要に応じて人事・法務は個人情報や採用手順との適合を確認します。AIベンダーの機能説明だけで社内の利用権限や候補者への通知義務が決まるわけではありません。組織のprivacy notice、保存・削除ルール、利用可能な候補者情報の範囲を確認し、担当者が判断できない条件は送信保留にします。

引用・データ出典

公式情報を編集部が見た内容です。Hands-on未実施の記述は本文かここに分けています。

確認日:2026-10-09

LinkedIn Recruiter:AI Messages(新しいタブで開く)

LinkedIn Recruiter:Messages InMail FAQ(新しいタブで開く)

厚生労働省:公正な採用選考の基本(新しいタブで開く)