検索条件を作る前に求人要件を整理する
採用背景とポジションの役割を確認する
検索条件を作る前に、「なぜこの人を採用するのか」を整理します。
同じ営業職でも、新規事業の立ち上げ、既存顧客の深耕、エンタープライズ開拓、パートナー営業では必要な経験が異なります。
エンジニアでも、開発担当、PL、PM、プリセールス、インフラ設計などで見るべき経歴は変わります。
求人票に書かれている職種名だけではなく、入社後に担う役割から条件を考えます。
MUST・WANT・NGを分ける
MUSTは、満たさなければ採用が難しい条件です。
WANTは、あると評価が上がる条件です。
NGは、採用できない明確な条件です。
ここで重要なのは、WANTをMUSTとして検索しないことです。
「営業経験3年以上」「同業界経験」「マネジメント経験」「大手顧客経験」をすべて必須にすると、実際には採用可能な候補者まで検索結果から消える可能性があります。
まず、本当に必須な条件だけを残します。
検索条件と選定条件を分ける
求人要件の中には、検索画面だけでは正確に判断できないものがあります。
たとえば「大規模プロジェクトの上流工程経験」「経営層への提案経験」「複数部署を巻き込んだプロジェクト経験」などです。
こうした条件は、検索キーワードで補助的に探すことはできますが、最終的には職務経歴書を見て確認します。
検索条件は候補者を見つけるための入口であり、採用判定そのものではありません。
ビズリーチの検索条件へ落とし込む考え方
職種を決める
まず、候補者が現在または過去に経験していそうな職種を設定します。
求人票の募集職種と、候補者側の職種名が一致するとは限りません。
たとえば「ソリューション営業」を採用したい場合でも、候補者側では「法人営業」「アカウント営業」「IT営業」「エンタープライズセールス」など別の名称で登録されている可能性があります。
募集職種名だけで絞らず、候補者側で使われる職種名を広めに考えます。
業種を決める
同業界経験が本当に必要な場合は業種条件を使います。
一方、商材知識より営業プロセスや顧客層が重要な求人では、業界条件を必須にすると候補者を狭めすぎることがあります。
たとえばSaaS営業を採用する場合でも、必ずSaaS企業経験が必要なのか、ITソリューション営業や無形商材の法人営業でも対象になり得るのかを確認します。
経験年数を設定する
経験年数は使いやすい条件ですが、厳しくしすぎると母集団を狭めます。
「5年以上」が理想でも、実際の採用基準として3年以上でも対象になるなら、検索では3年以上まで広げ、選定時に経験の深さを確認する方法があります。
年数だけでなく、どの業務をどのレベルで経験しているかを見ることが重要です。
勤務地・居住地を設定する
勤務地や居住地は、出社頻度、リモート可否、転居可否によって扱いが変わります。
フルリモート可能な求人で、現在地だけを厳しく絞ると候補者を減らす可能性があります。
一方、出社が必要な求人では勤務地条件がMUSTになります。
求人の働き方に合わせて設定します。
年収条件を設定する
現年収や希望年収は、求人の想定年収との乖離を確認するために使えます。
ただし、年収だけで候補者のスキルを判断しません。業界、企業規模、職種によって年収レンジは異なります。
求人の上限を超えている候補者をどこまで対象にするか、現年収と希望年収のどちらを見るかなど、運用ルールを決めます。
キーワードを使う
選択式の条件だけでは見つけにくい経験は、職務経歴書のキーワード検索で補います。
製品名、技術名、業務名、顧客属性、役割名など、求人と関係する語を洗い出します。
エンジニア求人であれば、AWS、Azure、HPE、FortiGate、SAPなど具体的な技術・製品名が有効な場合があります。
営業求人であれば、エンタープライズ、アカウント、ソリューション、公共、金融、製造など、対象顧客や営業スタイルを表す語を使います。
キーワード検索で同義語を展開する
職務経歴書では、同じ経験でも異なる表現が使われます。
たとえば「キッティング」なら、「PCセットアップ」「端末セットアップ」「PC初期設定」「PC展開」「端末展開」など複数の表現があります。
「PM」なら、「プロジェクトマネージャー」「プロジェクト管理」「PMO」「PL」など求人によって関連する表現が異なります。
検索キーワードを一つに固定せず、候補者が経歴書で使いそうな表現を広げます。
生成AIは、この同義語・関連語の洗い出しに使いやすいツールです。
AND条件を増やしすぎない
検索条件でよくある失敗は、求人票の条件をすべてANDで設定することです。
「IT業界」「法人営業」「SaaS」「新規開拓」「大手顧客」「マネジメント」「年収600万円以下」をすべて必須にすると、検索結果がほとんどなくなる可能性があります。
条件を追加するたびに、候補者数がどの程度減るかを確認します。
MUSTではない条件は、検索から外して選定時の加点条件に回す方法もあります。
検索結果が少ないときの緩和順序
1. WANT条件を外す
最初に外すのは、採用に必須ではない条件です。
業界経験、特定製品、歓迎資格など、WANTに分類した条件から見直します。
2. 経験年数を広げる
5年以上を3年以上へ、3年以上を2年以上へなど、年数条件を広げます。
ただし、求人で必要なスキルレベルを満たせるかは選定時に確認します。
3. 業界を広げる
同業界だけでなく、近い顧客層、商材、営業プロセスを持つ業界へ広げます。
たとえばSaaS営業なら、ITソリューション、クラウド、Webサービスなど近接領域を検討します。
4. 職種名を広げる
募集職種と完全一致する名称だけでなく、類似職種を追加します。
5. キーワードを見直す
必須キーワードが厳しすぎないか確認します。
製品名や特定用語が書かれていなくても、同等の経験を持つ候補者がいる場合があります。
6. 地域・年収条件を見直す
リモート可否、転居可否、年収の調整余地があるなら見直します。
ただし、採用不可条件まで外さないことが重要です。
検索結果が多すぎるときの絞り込み方
求人との関連性が高い条件から追加する
候補者が多すぎる場合は、単に年齢や年収で切るのではなく、求人の業務に直結する条件を追加します。
職種、顧客層、製品、技術、役割、マネジメントなど、入社後の業務と関係が強い条件を優先します。
キーワードを組み合わせる
単一キーワードで候補者が多い場合は、関連語を組み合わせます。
たとえば「AWS」だけでは広すぎるなら、「AWS」と「設計」、「AWS」と「プリセールス」など求人に必要な役割を追加します。
選定工数を見ながら決める
検索結果を数十人まで絞る必要はありません。
候補者確認を1日に何人できるか、月間何通送りたいかによって、適切な候補者数は変わります。
100人検索結果があっても運用上問題ない場合もあれば、数千人では確認が追いつかない場合もあります。
検索結果の件数だけで「良い条件」と判断しない
検索結果が300人あるから良い、30人しかいないから悪い、という単純な判断はできません。
重要なのは、実際に候補者を見たとき、どの程度がスカウト対象になるかです。
検索結果100人のうち80人が対象外なら、条件が広すぎます。
検索結果30人のうち25人が対象でも、月間100通送りたいなら母集団が不足しています。
検索条件の評価では、「検索結果数」と「対象率」の両方を見ます。
保存した検索条件は固定しない
候補者数は変化する
スカウト媒体の候補者は、新規登録、転職意欲、プロフィール更新などによって変わります。
一度作った検索条件でも、時間が経てば対象者数や候補者の質が変わります。
定期的に再確認します。
採用要件も変わる
採用活動を進めると、「この条件は不要だった」「この経験は必須だった」とわかることがあります。
企業側の候補者確認結果をもとに、MUST・WANT・NGを更新し、検索条件へ反映します。
送付実績から改善する
スカウト送付後の返信や面談結果も検索条件改善に使えます。
特定の候補者層から返信が多い場合は、その特徴を検索条件や選定条件へ反映します。
反対に、対象として送っても面談につながらない候補者層があれば、選定基準を見直します。
生成AIを検索条件設計に使う方法
求人票の構造化
生成AIへ求人票や採用要件を入力し、ポジションの役割、MUST、WANT、NGを整理します。
この段階では企業側の求人情報を扱います。
類義語・関連語の洗い出し
職種名、製品名、技術名、業務名、顧客属性の類義語候補を作ります。
候補者の職務経歴書で使われそうな表現を広げる用途に向いています。
緩和案の作成
検索条件を整理し、「MUSTを残したまま、どの条件から緩和できるか」をAIに検討させることができます。
ただし、実際に何人の候補者が出るかはAIでは判断できません。ビズリーチ上で件数を確認します。
検索条件シートの標準化
求人ごとに、職種、業種、年齢、年収、勤務地、キーワード、MUST・WANT・NG、緩和順序を同じフォーマットへ整理できます。
検索条件を属人的なメモではなく、再利用できる設定として残すと、担当者変更や改善がしやすくなります。
候補者情報は外部AIへ送らない
TechSuiteの現行ビズリーチ運用では、候補者情報を外部生成AIへ送信しません。
検索条件案をAIで作っても、実際の候補者確認・選定はビズリーチ上で人が行います。
「この候補者が合うか」を外部AIへ聞くのではなく、「この求人では何を確認すべきか」をAIで整理する使い方です。
検索条件設計の実務フロー
1. 求人票と採用背景を確認する
募集職種、役割、採用人数、採用期限、必須条件、歓迎条件を整理します。
2. MUST・WANT・NGを決める
採用担当者・現場責任者と、採用不可条件と加点条件を分けます。
3. 検索に使う条件を選ぶ
職種、業種、経験年数、勤務地、年収、キーワードなど、検索画面で設定しやすい条件を選びます。
4. 同義語・関連キーワードを作る
候補者が職務経歴書で使いそうな別表現を追加します。
5. ビズリーチ上で候補者数を確認する
件数が少なすぎないか、多すぎないかを確認します。
6. 数名〜数十名を実際に見る
検索結果の上位だけでなく複数の候補者を見て、対象率を確認します。
7. 条件を調整する
対象者が少なければ緩和し、対象外が多ければ求人との関連性が高い条件を追加します。
8. 検索条件と選定条件を保存する
設定した条件だけでなく、MUST・WANT・NG、緩和順序、選定時に見るポイントも残します。
9. 送付・返信結果を見て更新する
実際のスカウト運用結果を次回の検索条件へ反映します。
検索条件設計でよくある失敗
求人票の条件を全部入れる
最も多い失敗は、理想条件をすべて検索条件へ入れることです。
検索結果が少ない場合は、まずWANTが混ざっていないかを確認します。
検索条件だけで候補者を判定する
検索は候補者を見つける入口です。
職務内容、役割、成果など、検索画面だけで判断できない要素は候補者プロフィールで確認します。
キーワードを一つしか使わない
職種名や経験の表現には揺れがあります。
一つの言葉だけで絞ると、同等の経験を持つ候補者を取り逃がす可能性があります。
件数だけを追う
候補者数が増えても、対象率が下がれば確認工数だけ増えます。
検索結果数と実際の対象率をセットで見ます。
一度作った条件を変えない
求人要件、候補者数、企業側の判断、返信状況は変わります。
保存条件は定期的に見直します。
AIスカウトくんのビズリーチ検索条件設計
AIスカウトくんでは、TechSuite株式会社が、求人票や採用基準など企業側の情報をもとに、検索条件案やキーワード候補、緩和順序を整理します。
生成AIは、求人要件の構造化、MUST・WANT・NGの整理、職種・経験の類義語展開、条件緩和案の作成などに活用できます。
一方、実際の候補者数はビズリーチ上で確認し、候補者本人の確認・選定も媒体上で行います。候補者情報を外部生成AIへ送ることを前提にしません。
検索条件を一度作って終わりにせず、企業側の候補者確認、送付数、返信状況をもとに継続的に更新します。
よくある質問
ビズリーチの検索条件は細かく設定した方がよいですか？
細かいほど良いとは限りません。条件を追加するほど候補者数は減ります。MUSTだけを検索条件にし、WANTは候補者確認時の加点条件にする方法もあります。
検索結果は何人くらいが適切ですか？
一律の正解はありません。月間送付数、候補者確認工数、対象率によって変わります。検索結果数だけでなく、実際に何割がスカウト対象になるかを確認します。
キーワードはいくつ入れるべきですか？
求人によります。重要なのは数ではなく、候補者が職務経歴書で使う表現を漏らさないことです。類義語や製品名、技術名、業務名を整理して使います。
生成AIだけでビズリーチの検索条件を作れますか？
求人要件の整理や条件案、類義語、緩和案の作成には使えます。ただし、ビズリーチの現行検索項目や候補者数は媒体上で確認する必要があります。
検索条件が厳しすぎるかはどう判断しますか？
検索結果数だけでなく、候補者を実際に見たときの対象率と、必要な月間送付数を見ます。必要通数を確保できない場合は、WANT条件や経験年数、業界、キーワードから順に緩和します。
AIスカウトくんに関するよくある質問
スカウト代行とRPOの違いは？
違いは支援範囲です。AIスカウトくんはスカウト運用を中心に支援し、TechSuiteでは採用活動全体を支援するRPOサービスの「AI RPOパートナー」も提供しています。
候補者検索から送信まで、すべて任せられる？
はい。AIスカウトくんでは、候補者検索・選定からスカウト文の作成、送信まで対応できます。ただし、プランによっては検索条件の作成や定期的な振り返り・改善支援を含まない場合があります。
スカウト媒体の利用料金は代行費に含まれる？
いいえ。AIスカウトくんの代行費とは別に、利用するスカウト媒体の契約・利用料金が必要です。
新卒採用と中途採用の両方で使える？
はい。AIスカウトくんは新卒採用・中途採用の両方に対応しています。人材紹介会社の候補者スカウト運用にも対応できます。ただし、媒体の利用規約により第三者による代行が認められていない媒体では対応できません。
どのスカウト媒体でも代行できる？
はい。ビズリーチやOpenWorkリクルーティングなど、基本的に各種スカウト媒体で代行できます。ただし、媒体の利用規約により第三者による代行が認められていない媒体では対応できません。利用予定の媒体について、事前に対応可否を確認します。
まとめ｜ビズリーチの検索条件は「理想の人を一発で探す」より「対象者を見ながら調整する」
ビズリーチの検索条件設計では、求人票の理想条件をすべて設定するのではなく、MUST・WANT・NGを整理し、検索に必要な条件だけを使うことが重要です。
職種、業種、経験年数、勤務地、年収、キーワードを組み合わせたら、実際の候補者数と対象率を確認します。
少なければWANTや経験年数、業界、キーワードから緩和し、多すぎれば求人との関連性が高い条件を追加します。
生成AIは求人要件の整理、類義語、条件緩和案の作成に使えますが、候補者数と候補者本人はビズリーチ上で確認します。
検索条件を一度作って固定せず、企業側の判断とスカウト結果を反映しながら更新することが、継続的な運用改善につながります。
この記事に近い導入事例
