スカウト代行 / LAPRAS
LAPRASの検索条件の組み方|母集団を狭めすぎない設計
LAPRASの検索条件は、項目を選ぶというより目盛りを合わせる作業に近くなります。技術力スコアもタグレベルも連続値で、公式ヘルプが平均値と分布まで公開しているからです。この記事では、条件を一度で決めるのではなく、出てきた人数を見て次に何を動かすかという分岐の形で、母集団が尽きるまでの手順を整理します。以下は、2026年9月24日時点で公式サイトおよび採用担当者向けヘルプセンターに記載されている内容に基づいており、運営はLAPRAS株式会社です。
最初の分岐:候補者検索で探すか、レコメンドで待つか
最初に決めるのは、どの画面から入るかです。候補者検索は条件を細かく指定する画面で、キーワード検索では「指定したキーワードの職歴、職務要約、活かせる経験・スキル、経験技術、自己紹介文、アウトプットから生成される『タグ』を持っているユーザーを検索できます」とされ、AND検索とOR検索が使えます。検索対象を「職歴・経験技術に絞る」にチェックを入れるとタグを除外でき、アウトプット由来の語に引っ張られない検索にできます。求める経験が職歴に書かれやすいものなら、こちらから入るのが早道です。
レコメンドには二つのモードがあります。基本検索は、スキル(アウトプットの量[少・中・多]で絞り込み)、技術力、転職意欲、興味のある雇用形態、必須の情報(やりたいこと/職歴)の項目で絞る簡易版です。詳細検索から基本検索に変更すると詳細検索で設定した内容が消えてしまうため、ヘルプは「新規でレコメンドを作成いただくことをおすすめ致します」としています。条件を試行錯誤するなら、モードを切り替えるのではなく、レコメンドを分けて作っておきます。
どちらの入口でも、前提は同じです。アプローチできる候補者はLAPRASユーザーのみで、検索でヒットしても送れない相手が混ざります。レコメンドは約150万人の候補者データベースから探す仕組みですが、実行した直後は表示される候補者が極端に少なくなるため、5分から10分ほどおいてからブラウザをリロードするよう案内されています。人数を見て分岐するこの記事の手順では、この待ち時間を置いてから数えることが最初の約束です。
人数を見て分岐する:数十〜200人を目安にする
分岐の基準になる数字は、ヘルプ自身が示しています。レコメンドについて「『この条件に該当する候補者』に表示される人数は数十〜200人程度に絞って検索してみましょう」という目安です。条件を入れて人数を見たら、この幅に入っているかどうかで次の手を決めます。次の表は、人数ごとの状態と、次に動かす目盛りを並べたものです。
| 表示された人数 | 起きていること | 次に動かすもの |
|---|---|---|
| 200人を大きく超える | タグが少なく、別の職種の人が混ざっている | タグを1つ足す(言語よりフレームワーク) |
| 数十〜200人 | 目安の範囲 | 動かさずに読み始める |
| 数十人を下回る | どこかの目盛りが狭すぎる | 次の章の順番で緩める |
| ほぼ0人 | マイナーなタグを高レベルで設定している可能性 | タグレベルを下げるか、タグを外す |
多すぎるときに足すのはタグです。ヘルプは、タグの数が少なすぎる例として「『Python』をレベル8で設定していたとしても、Web系なのか解析系なのかなどの指定が無ければ、Webアプリ開発の候補者とデータサイエンティストが一緒にレコメンドされる」と書いています。足すタグは、経歴やポジション名より、求めるスキルを持ったエンジニアがアウトプットに使用する言葉を選ぶのがよいとされています。開発に使用するツール・手法(CircleCIやVimなど)や、技術的によく使用されるテーマ(テスト自動化やリファクタリングなど)も候補になります。
ただし、タグはAND条件です。ヘルプは「多数設定すると全ての条件を満たす候補者の数が少なくなりすぎるため、1〜3個程度を目安にしましょう」としています。タグを4つ以上に増やしたくなったら、分岐を間違えていると考えて、入口の選び方か技術力スコアの幅を見直します。
少なすぎるときに緩める順番
人数が足りないときに、どの目盛りから緩めるかで母集団の質が変わります。おすすめする順番は、希望条件の「未入力を含める」、タグレベル、技術力スコアの幅の順です。影響が大きく、かつ採用要件を変えずに済むものから触ります。
一つ目は希望条件です。希望する年収、働き方、雇用形態、業態、勤務地には、「どの希望条件も『未入力を含める』のチェックボックスにチェックを入れることで、希望条件を入力していないユーザーも検索対象に含めることができます」とされています。希望を書いていない人を外すと、プロフィールを作り込んでいない層がまるごと落ちます。要件を一つも緩めずに人数が増えるので、最初に確かめる価値があります。
二つ目はタグレベルです。タグレベルは5が平均で、10に近づくほどレベルが上がると説明されています。ただし、この目安が当てはまるのはRubyやRailsのようにWeb上で公開されることの多い言語やフレームワークで、あまり有名でない言語やフレームワーク、GitHubに公開される量が少ないインフラ関連や機械学習のアウトプットはレベルが高く出づらいとされています。
| タグレベル | 公式の説明 | 下げるときの考え方 |
|---|---|---|
| 1〜3 | そのスキルに興味を持っている、少し触れたことがある | 実務経験を問わない職種以外では下限にしない |
| 4〜6 | 実際にそのスキルを活用したことがあり、アウトプットしている | インフラや機械学習ならここまで下げても実務層が残る |
| 7〜10 | そのスキルをメインに活用して日々の業務にあたった経験がある | ポピュラーな言語以外で必須にすると人数が尽きやすい |
三つ目が技術力スコアです。スコアは1.0〜5.0で、3.0が平均、3.5以上では上位4%に絞り込まれるとされています。幅は0.3〜0.5程度から始め、3.2〜3.5などの区間から下限・上限をスライドさせていくのが勧められていて、幅が2.5もあるような設定は拡げすぎの例として挙げられています。緩めるときも一度に広げず、区間を下へずらして人数の変化を見ます。3.0前後を下限から外すと、アウトプットを出さない実務者を落とすことも覚えておきます。
エラベルの見解
スコアとレベルが公開されている媒体では、数字を上げたくなる引力が働きます。稟議の場で「技術力スコア3.5以上に絞りました」と言えば、説明としては通りやすいからです。しかし公式自身が上位4%だと書いているものを必須条件にすれば、母集団はそこで決まってしまいます。
担当者によって差が出るのは、人数が足りないときの緩め方です。スコアの下限を下げて人数を戻す担当者と、「未入力を含める」とタグレベルを先に見直す担当者では、同じ人数でも中身が違います。前者は要件を緩めており、後者は要件を保ったまま取りこぼしを拾っています。担当者を選ぶときは、条件の設定値より「足りないときにどこから動かすか」を聞いてみてください。
読み切ったあとに、新しい母集団を出す
目安の人数に入った母集団も、送り終えれば尽きます。そのときに条件を広げる前に、時間の目盛りと保存条件で「新しく入ってきた人」を拾う手があります。候補者検索には、時間で絞る項目が三つあります。
| 項目 | 選べる範囲 | 使い方 |
|---|---|---|
| 転職意欲最終変更日 | 1週間以内/1ヶ月以内/3ヶ月以内 | 絞り込みではなく並べ替え(転職意欲変更日順)で使う |
| 最終ログイン | 1週間以内/1ヶ月以内/3ヶ月以内 | 同上。ログイン日順のソートで上から読む |
| 閲覧履歴での絞り込み | 1日以内/1週間以内/1ヶ月以内/3ヶ月以内に自分が閲覧した候補者を除外 | 複数人で運用するときの重複防止に使う |
時間の目盛りは、母集団を減らすかわりに反応率を上げる方向に働きます。絞り込みに使うと人数が減るので、ソートの転職意欲変更日順やログイン日順で並べ、上から読むほうが母集団を保てます。閲覧履歴の除外は、読み終えた人を外して新しい人だけを見る道具です。一度読んだ母集団を毎週読み直す手間が省けます。
条件は「条件を保存」から保存でき、保存名も変更できます。検索結果一覧には、自分がその候補者の詳細ページを最後に見た日付が出るので、週次で同じ条件を開き直して差分を見る運用が組めます。ソートのキーワードマッチ順は、活かせる経験・スキルスコア、職務要約スコア、職歴スコアに重み付けをして総合的に評価するとされています。保存した条件を週に一度開き、差分だけを読むのが、目盛りを動かさずに母集団を補充するいちばん手堅い方法です。
本当に尽きたかを判断する前に見るところ
差分も出なくなったら、条件の外側を見直します。経験職種の選択肢は登録人数が多い順に並んでいるとされ、過去経験した職種も含むという注記があります。画面の並び順そのものが母集団の分布を示しているので、隣接する職種を足せるかどうかを並び順から判断できます。在籍企業名での絞り込みもありますが、複数入力はできず、対象はWantedly、GitHub、teratail、Qiitaで入力された所属企業に限られるので、ピンポイントの用途にとどまります。
もう一つ見落としやすいのが、上限側の目盛りです。スコア4.0超はCTOや、Web上で知名度がある有名人などが含まれる層で、ヘルプは「スカウトの内容などに注意が必要です」としています。人数が尽きたからといって上へ広げても、送り方を変えなければ反応は返ってきません。上に広げるときは、文面の書き方も一緒に変える必要があります。
それでも足りないなら、条件ではなく要件のほうを見直す段階です。技術力スコアはアウトプットからエンジニアスキルを得点化した値なので、Webにアウトプットを出さないエンジニアは低く出ます。公式自身が「〜3.0」の層の説明に「SIer所属など」と書いているとおり、スコアが低い層にも実務経験のある人はいます。要件の書き方を変えて、この層を読みにいくかどうかを社内で決めます。
エラベルの見解
担当する側から見ると、この媒体の検索でいちばん時間を取られるのは、条件を決める作業ではなく、同じ母集団を読み直す作業です。閲覧履歴の除外と保存条件を使わずに運用すると、毎週同じ人の経歴を開き直すことになり、読む時間の多くが確認に消えます。経歴を読む時間を増やしたいなら、まず読み直しを減らすほうが先です。
そのため私たちは、運用を始める週に、条件を保存し、閲覧履歴の除外期間を決め、ソートを転職意欲変更日順にするところまでを一度に済ませます。ここまで決めてから読み始めると、2週目以降は差分だけを読めば済みます。運用の進め方はLAPRASのスカウト運用設計、文面の設計はLAPRASのスカウトテンプレートの作り方にまとめています。
まとめ
- 入口は、職歴に書かれやすい経験なら候補者検索、条件を試すならレコメンドを分けて作る。どちらも送れるのはLAPRASユーザーだけ
- 表示人数は数十〜200人を目安にし、多ければタグを1つ足す。タグはAND条件なので1〜3個まで
- 少なすぎるときは「未入力を含める」、タグレベル、技術力スコアの幅の順に緩める
- 読み切ったら、時間の目盛りを並べ替えに使い、閲覧履歴の除外と保存条件で差分だけを読む
- 差分も尽きたら、経験職種の並び順や要件の書き方を見直す。スコアはアウトプット由来である点を忘れない
よくある質問
Q. 技術力スコアはいくつに設定すればよいですか
公式ヘルプでは3.0が平均、3.5以上で上位4%とされています。幅は0.3〜0.5程度から始め、3.2〜3.5などの区間からスライドさせていくことが勧められています。最初から高い下限を置くより、人数を見ながらずらすほうが母集団を保てます。
Q. タグは何個まで設定してよいですか
タグはAND条件なので、ヘルプは1〜3個程度を目安にしています。人数が多すぎるときは、言語よりフレームワークのタグを足すと職種の混在が減ります。マイナーなタグはレベルを低くして1〜2個程度に留めるよう案内されています。
Q. 検索で出てきた候補者には、全員スカウトを送れますか
送れるのはLAPRASユーザーだけです。LAPRASに登録していない候補者も、クロールした情報を検索・閲覧することはできますが、スカウトは送れません。送信計画は、検索件数ではなく送信可能な人数で立ててください。
※料金・通数・機能の条件は変わります。掲載した内容は2026年9月24日時点の公式サイトおよび採用担当者向けヘルプセンターの記載であり、契約前に運営にご確認ください。