スカウトを送る相手の選び方｜採用業務のAI活用（第4部）

この記事は、シリーズ「採用業務のAI活用」（全8部）の第4部です。各部の一覧はシリーズの目次にあります。内容は、HRdevが採用支援の実務で培った知見をもとにした使い方の例です。

スカウトの前半は、候補者を集め、送る相手を絞り込む作業です。数百人を扱うため、AIを使った効果がいちばん大きく出る一方で、間違いもいちばん起きやすい部分です。第4部では、候補者のリストアップ、応募済みの方との照合、スカウト対象の判定の3つを扱います。

図1　リストアップから送る相手が決まるまで

検索条件づくりは、送り手が設計できる要素のなかでスカウトの成果をいちばん大きく左右する一方で、AIにいちばん任せにくい作業でもあります。AIを使って空いた時間は、この作業に充てます（第2部4章）。

1. スカウト前半の3つの作業とAIの使い方

リストアップは整理タイプ（情報を集めて整える）、応募済みの方との照合とスカウト対象の判定は判定タイプ（ルールで仕分ける）です。うまくいくかどうかは、判定のルールを人が文章で書き切れるかどうかでほぼ決まります。

2. 作業ごとのAIの使い方

2-1　候補者のリストアップ（作業1）

図2　候補者のプロフィールを管理シートへ取り込む流れ

要約せず原文のまま入れておくと、判定ルールを変えたときも同じシートで判定をやり直すことができます。

媒体の検索結果から、候補者のプロフィールを候補者IDと元のページのURLとあわせて管理シートへ入力します（図2）。

媒体の利用規約で確かめること

候補者のプロフィールを管理シートへ転記してAIに渡す前に、契約している媒体ごとに利用規約と利用ガイドを確認します。確かめるのは、会員の情報を媒体の外へ転記・保存してよいか、外部のツールやAIに入力してよいか、自動で情報を取得してよいか、氏名を伏せた会員をほかの情報と照らして特定してよいか、の4点です。規約を読んでも判断できない点は媒体の担当者にメールで問い合わせ、回答を保存しておきます。認められていない媒体では、管理シートへの転記とAIへの入力を行わず、媒体の中の機能で判定します。

プロフィールは原文のまま入力する

入力するときは、要約ではなく原文をそのまま列に入れてください。要約して入力すると、その後の判定が要約の出来に左右されます。ルールを変えたときも、原文があれば同じシートで判定をやり直すことができます。

貼り付けた全文には、画面のメニューや広告など、判定に関係のない文字も混ざります。不要な文字の除去と、項目ごとの振り分けはAIに任せます。職務経歴の文章そのものは書き換えさせません。

取り込んだ行を確かめるときに見る列

取り込んだ結果を確認するとき、後の作業で埋まる列が空いているのを見て「この行は入力できていない」と判断しないでください。行が正しく入力できているかどうかは、候補者IDの列と元のページのURLの列で対象者を確かめ、あわせてプロフィールの列に本文が最後まで入っているかを確認します。

絞り込んだ件数が少ないときに最初に疑うもの

絞り込んだ結果が0件、あるいは想定よりずっと少ないときは、媒体の側ではなく、まず自分の絞り込み条件を疑ってください。0件でも条件を勝手に広げず、広げるかどうかは、検索条件を決めた担当者に判断を依頼します。

この章のまとめ

候補者のプロフィールは要約せず、原文のまま列に入力します。媒体の画面からコピーした全文の貼り付けで構いません。

2-2　応募済みの方との照合（作業2）

すでに応募している方へスカウトを送らないよう、採用管理システムに登録されている応募者と照らし合わせます。

氏名が伏せられた媒体での重複の扱い

候補者の氏名が見える媒体なら、氏名で照らし合わせることができます。氏名が伏せられた媒体では、2-1で確かめた利用規約が会員の特定を認めている場合に限り、在籍企業の社名や在籍期間など、確認できる職務経歴の情報を組み合わせて照らし合わせます。認められていない媒体では、職務経歴による照合は行わず、応募済みの方を除く方法を媒体の担当者に確認します。この方法では同じ人だと言い切れないため、結果を「重複あり」と「重複なし」の2つに無理に振り分けてはいけません。

「要確認」と書いただけでは、送るかどうかが決まらないまま行が残ります。要確認とするときは、誰が、何を確かめて、いつまでに結論を出すのかまでを同じ行に書きます。

この章のまとめ

名前が伏せられた媒体では、同じ人かどうかを言い切れません。「要確認」とするときは、誰が何を確かめ、いつまでに結論を出すかまで同じ行に書きます。

2-3　スカウト対象の判定ルールの書き方（作業3）

判定ルールは、見送りの条件・必須の条件・加点と減点の3段に分けて書き、「プロフィールに書かれていない項目は、条件を満たしていないとは扱わない」という一文をルールの冒頭に入れる書き方ができます。以下はその一例です。

図3　判定ルールの3段と書かれていない項目の扱い

見送りの条件と必須の条件は性質が違うため、分けて書きます。書かれていない項目は、どの段でも不足として扱いません。

判定ルールの3段（見送り・必須・加点と減点）

3段のうち、必須の条件は満たさなければ通さない条件、見送りの条件は当てはまった時点でほかがどれだけ良くても見送りになる条件です。この2つは性質が違い、混ぜると判定がぶれるため、別々の箇条書きにします。第3部であわせて聞いた見送り条件が、そのまま見送りの条件の材料になります。

書き分けの例

必須の条件は「該当領域での開発経験が通算5年以上」、見送りの条件は「直近1年以内に当社の選考を受けて見送りになっている」のように、1つの内容はどちらか一方にだけ書きます。「経験5年未満は見送り」を見送りの条件にも重ねると、経験年数が書かれていない候補者の扱いが2か所で食い違います。

判定の区分に入れる「要確認」

判定の区分には、A・B・Cのような送るかどうかの区分に加えて、「要確認」を入れておきます。要確認は、ルールに照らしてもAIでは適切に判断できず、人が確認するべき当落線上の候補者に付ける区分です。どれか1つの区分を必ず選ばせると、判断のつかない候補者も無理にいずれかの区分に入り、送るべき人を外したり、送らなくてよい人に送ったりする原因になります。要確認の行は、人が職務経歴を読んで送るかどうかを決定します。

プロフィールに書かれていない項目の扱い

プロフィールにその項目が書かれていないとき、条件を満たしていないと判定してはいけません。書かれていないことは、その経験がないことを意味しないためです。

この一文をルールに書いていないと、AIは記載の少ない候補者を機械的に見送ります。その結果、プロフィールを丁寧に書く習慣のある候補者だけが残り、実力とは別の理由で候補者が減っていきます。

「その項目が書かれていない場合、その項目では見送りにしない」という一文を、ルールの冒頭に入れておきます。書かれていない項目は、満たしているとも満たしていないとも扱わず、「未確認」として判定の理由に書かせます。未確認の項目が多い候補者に送るかどうかは、ルールの中で別に決定しておきます。

判断に迷う例のルールへの追記

運用を始めると、判断に迷う例が必ず出てきます。転職回数をどう数えるのか。副業や派遣での経験を経験年数に含めるのか。管理職が中心の候補者に開発の経験が書かれているとき、どう扱うのか。

こうした例は、出てきた順にルールへ追記します。追記せずにその都度判断していると、同じ候補者でも、担当者や週によって違う結果が出ます。

判定の理由の書き方

区分だけを出させず、理由を必ず書かせます。理由には、職務経歴に書かれた事実と、その事実を基準に照らした解釈を、分けて書かせます。どの条件を満たし、どの条件が足りないかが、事実と解釈の区別とともに読める形にするためです。区切り方は、「事実：」「解釈：」の見出しでも、列を分ける方法でも構いません。

書き方の要点の1つめは、職務経歴に書かれている事実をそのまま書くことです。事実を伏せた理由では、読んだ人が要件に照らして判定が正しいかどうかを確かめられません。2つめは、結論を事実だけで言い切らず、どの要件に照らしてその結論になったのかを書くことです。見送りの条件に当てはまった場合も、当てはまった事実と、該当した見送りの条件をあわせて書きます。

判定の理由を社内や採用に関わる人と共有する場合、書いてよい範囲は、職務経歴に書かれている事実と、要件と照らし合わせた結果までです。今後の見込みや勤務への影響といった推測を書き足さないでください。

3. 判定ルールと指示の原本（プロンプト）をどこに置くか

2か所で管理すると起きる食い違い

HRdevでは、スカウトに関する設定要件を、複数のシートにまたがって管理していた時期がありました。運用の中で片方のシートだけを更新し、もう片方に古い条件が残り、2つのシートで判定の条件が食い違ったことがあります。この経験から、原本は1か所にまとめるのがよいと考えています。

原本はシートの1か所に置き（第2部5章）、ほかのシートやツールの設定へ写す場合は、原本を更新したら写し直す手順を書き出しておいてください。

判定に使う指示文（プロンプト）も、シートのタブや文書など、人が読みやすい形で1か所に保管し、AI関数やスキルからそれを参照する形をおすすめします。AI関数なら指示文を書いたセルを範囲として渡し、スキルなら指示文の文書を資料として登録します。指示文を関数の式やスキルの中に直接書き込むと、どこに何が書いてあるかを人が確かめにくくなります。1か所にまとめておけば、修正はそこだけで済み、メンテナンス性も一定担保できます。なお、指示文の編集は、人が直接書き換えるより、原則としてAIを経由して行うほうが安定します。編集の手順をまとめたスキルや編集用の指示文を別に用意しておけば、人が細かな要件を1つずつ直さなくても、決めたルールに沿ってAIが編集できるためです。

ルールを変えたときは、変える前と後で同じ候補者を判定し直し、結果がどう変わったかを確認します。あわせて、ルールを変えるたびに版の番号を付け、判定にどの版を使ったかを記録します。版を記録していないと、判定の正確さが変わったとき、ルールを変えたせいなのか、届いた候補者の顔ぶれが変わったせいなのかを見分けられません。

この章のまとめ

同じルールを複数の場所で管理すると、片方だけが更新されて食い違いが起きます。原本は1か所に置きます。ほかのシートやツールにも同じルールを置く場合は、原本を更新したら写しも更新する手順を書き出しておきます。

4. スカウト対象判定の管理シートの列

AIの判定と人の最終判定を別々の列に記録し、2つが食い違った行にだけ関数で印を付けます。人はその行で食い違った原因を調べ、ルールの修正に使います。

重複の判定が「重複あり」の行は、スカウト対象の判定から外します。「要確認」の行は送信を保留し、人が確認した結果と送るかどうかを記録してから先へ進めます。外す作業は関数で行い、AIに判断させないでください。

5. 判定作業での進め方Aと進め方B

進め方A（スプレッドシートとGemini）

1件ずつ確かめながら進めたい場合。スプレッドシートのAI関数（セルの中からAIに頼む機能）と、Geminiのスキル（指示と資料を保存して繰り返し呼び出せる機能）を使います。会社のGoogle Workspaceのアカウントでスキルがまだ使えない場合は、同じ指示をGemsに保存して使います（第2部6章）。

スカウト対象の判定には、スプレッドシートのAI関数が向いています。プロフィールの列と、判定ルールを書いたタブの内容を合わせてAIに渡す形にします。

判定ルールの本文は、関数の式に直接書かず、専用のタブに書いてそこを読ませます。AI関数はほかの関数の中に入れて使えず、シートの内容は範囲として渡したセルしか読みません。そのため、ルールの全文とその行のプロフィールを1つのセルに連結する列を通常の関数で作り、AI関数にはその列を範囲として渡します。

進め方B（Claude CodeとCodex）

件数が多く、手順の決まった作業をまとめて任せたい場合。Claude CodeやCodex（パソコン上のファイルやスプレッドシートの操作から資料の作成まで、手順ごとまとめて任せられるAIエージェント）を使います。

判定用の指示文（プロンプト）をファイルに保存して管理し、その指示文で管理シートの行を判定して書き戻す処理を、Claude CodeやCodexに作成させて実行します。AIへの頼み方を毎回会話で書かず、判定用の指示文をファイルに保存し、同じ指示文で全件を判定させます。会話で頼むと頼み方が回ごとに変わり、どの頼み方で判定した結果なのかを後から確認できないためです。Claude CodeやCodexからスプレッドシートを読み書きするには、つなぐ設定が別に必要です（第2部6章）。処理の中身は次のとおりです。

手順5では、書き込む行を行番号で決定しません。処理の途中で誰かがシートを並べ替えたり行を追加したりすると、読み込んだときに5行目だった候補者が、書き込むときには別の行に移っているためです。読み込んだときの行番号のまま書き込むと、ある候補者の判定と理由が、別の候補者の行に入ります。

手順2でAIの判定が空の行だけを対象にするため、処理が途中で止まっても、もう一度実行すれば残りの行から判定を再開します。判定ルールを変えたときは、原本の版番号を上げ、3章のとおり同じ候補者を変更前と変更後の版で判定し直して、結果を比較します。

この章のまとめ

進め方A（スプレッドシートとGeminiで1件ずつ進める）では、判定ルールを専用のタブに書き、AI関数からそのタブを読みます。進め方B（Claude CodeやCodexでまとめて処理する）では、判定用の指示文をファイルで管理し、判定ルールは実行のたびに原本から読み込んで、同じ指示文で1人ずつ判定させます。書き戻す前に答えを検査し、書き込む行は候補者IDで探します。

6. 判定の正確さの測り方

図4　判定の確認を減らしていく流れ

運用を始めたばかりのうちは、人がAIの判定を見る前に全件を判定し、最終判定を別の列に入れます。先にAIの判定を見ると、人の判断がそれに引きずられるためです。担当者どうしで結論が割れた候補者は、根拠を照合し、結論が出なければ材料をそろえて現場の責任者に判断を依頼します。

食い違った行だけを読み返すと、原因は3つに分かれます。ルールに書いていない条件で人が判断していた場合は、その条件をルールへ追記します。ルールの言葉があいまいで、AIが別の意味に受け取った場合は、言葉を具体的にします。人の判断が間違っていた場合は、最終判定を直したうえで、ルールにも直すところがないかを確認します。

食い違いは、向きを分けて集計します。送るべき人をAIが外した誤りは採用の機会を失わせ、送らない人をAIが残した誤りは確認の手間を増加させます。目標も別々に決定します。

一部に絞ったあとは、無作為に抜き出した行を人が判定し、AIが要確認とした行はすべて確認します。抜き出さなかった行は、AIの判定をもとに送る相手を決定します。誤りの件数は、無作為に抜き出した行だけで集計し、要確認の行の結果とは分けます。件数が少ないうちは、目標を下回っていても絞り込みを見送ります。

この章のまとめ

運用の初めは、人がAIの判定を見る前にすべての行を判定し、食い違った行を読んでルールを修正します。食い違いは、送るべき人を外した誤りと、送らない人を残した誤りに分けて集計します。どちらも目標を下回り、責任者が承認したら、確認する行を一部に絞り込みます。

7. 判定作業での候補者情報の取り扱い

判定を運用する採用担当の方が、始める前に決めておくことは2つあります。

1つは、AIに渡す情報の範囲です。判定に使うのは職務経歴やスキルなどのプロフィールで、氏名や連絡先は判定に要りません。AIに渡す列は、候補者IDとプロフィールの本文に絞ります。AI関数はGoogle検索の結果を使って答えることがあるため（第1部）、氏名を渡さなければ、候補者の名前が検索に使われるおそれもなくなります。候補者の情報をAIに入力してよいかは、契約や設定、社内の取り扱いルールで確かめておきます（第1部）。

もう1つは、判定の結果を社内で相談するときの書き方です。社内チャットで「この候補者に送るかどうか相談したい」と書くときは、プロフィールを貼り付けず、候補者IDと管理シートの該当行へのリンクを送ります。チャットは参加者が多く、書いた内容が長く残るため、プロフィールの全文を貼ると、選考に関わらない人まで読める状態になります。管理シートは閲覧できる人を絞れるため、詳しい内容はシートで確認してもらいます。候補者対応や面接の記録での扱いは第6部3章で説明します。

シリーズ「採用業務のAI活用」の構成

• 第1部　AIを使い始める前に

• 第2部　AIはどこで使えるのか

• 第3部　求人票づくりのどこをAIに任せるか

• 第4部　スカウトを送る相手の選び方（この記事）

• 第5部　スカウトの文面と送付回数

• 第6部　候補者対応と個人情報の線引き

• 第7部　選考データの分析

• 第8部　導入の進め方と課題の記録