スカウト代行 / LAPRAS
LAPRASのスカウトテンプレートの作り方
LAPRASの文面づくりには、ほかの媒体にない出発点があります。公式ヘルプが「候補者自身が確認できる項目=スカウトメッセージで言及することが可能な項目です」と言い切っているからです。この記事では、ガイドラインの説明から入るのではなく、実際の文面例を三つ置き、それぞれがなぜその形なのかを順に解説します。以下は、2026年9月24日時点で公式サイトおよび採用担当者向けヘルプセンターに記載されている内容に基づいており、運営はLAPRAS株式会社です。
文例1:カジュアル面談をお願いする初回スカウト
まず、いちばん使う機会の多い初回スカウトの例です。バックエンドのリードが、決済まわりの移行を経験した候補者に面談をお願いする想定です。固有名詞は伏せていますが、分量はこのくらいが目安です。
件名:Rails の API 設計のご経験について(◯◯株式会社・バックエンド/カジュアル面談のお願い)
◯◯株式会社でバックエンドチームのリードをしている△△と申します。採用の実務も兼任しています。
LAPRASのプロフィールで、Career History に書かれていた決済まわりの移行と、GitHub の◯◯リポジトリを拝見してご連絡しました。弊社もいま同じ移行の途中で、設計をご一緒できる方を探しています。
転職意欲を「情報収集中」にされていたので、選考ではなくカジュアル面談としてお願いできればと思っています。オンラインで30分、事業と技術の現状をお伝えする場として考えています。
この短さで足りるのは、LAPRASがスカウトガイドラインで求めている基準を一つずつ押さえているからです。ガイドラインは、ビジネスメッセージとして最低限の体裁が整っていることとして三つ、採用候補者の事情を踏まえていることとして二つを挙げています。次の表は、その五つが文例のどこで満たされているかを対応させたものです。
| ガイドラインの基準 | 文例で満たしている箇所 | 抜けたときの見え方 |
|---|---|---|
| なぜスカウトが届いたかが分かる | Career History と GitHub のリポジトリを名指ししている | 誰にでも当てはまる定型文に見える |
| 誰からスカウトされたのかが分かる | 差出人の役割(チームのリード、採用も兼任)を書いている | 素性の知れない人物からの連絡になる |
| どのような提案がなされているのかが分かる | 件名と本文でカジュアル面談、30分と書いている | 面談なのか選考なのか分からない |
| 文面が採用候補者の公開している事実と一致している | 候補者の画面で見える項目だけに触れている | どこから得た情報か分からず不審に映る |
| 採用候補者が明示している希望が考慮されている | 転職意欲「情報収集中」に合わせて選考ではなく面談にしている | 明示した希望を無視された印象になる |
ガイドラインは五つ目について、明示している事項を無視したコミュニケーションは企業に対して不信感を抱かせる、と説明しています。転職意欲の設定を読んで提案の形を合わせるのは、この文例でいちばん手間が少なく、いちばん効く部分です。表の五行のうち、ここだけは候補者の画面を一度見れば済みます。
文例に書いてよい材料、書いてはいけない材料
文例1で「候補者の画面で見える項目だけに触れている」と書いたのは、LAPRASでは言及してよい範囲が明示されているからです。ヘルプセンターが「確認できる項目」として挙げているものを、文面での使い方と並べると次のようになります。表にない情報は、文面の根拠に使わないのが原則です。
| 確認できる項目 | 文面での使い方 |
|---|---|
| LAPRAS SCORE(技術力) | 何を見て送ったかの入口にする |
| Career History(経歴情報) | いちばん具体的な根拠として名指しする |
| GitHub リポジトリ | 見た証拠としてリポジトリ名を出す |
| スキルタグ/プログラミング言語 | 自社の要件との重なりを示す |
| Speaker Deck/Qiita/note/teratail | 内容に触れて、読んだことを伝える |
| イベント参加履歴 | 関心の方向を読み取る材料にする |
| Selections/やりたいこと | 提案の方向を合わせる |
| 転職意欲/興味のある雇用形態/職種 | 提案の形(面談か選考か、雇用形態)を間違えない |
LAPRAS SCOREについては、ビジネス力と影響力は候補者自身のみ確認可能で、企業側から見えるのは技術力の側だと注記されています。スコアやタグの計算ロジックもLAPRAS登録者に公開されているので、候補者は自分のスコアがどう算出されたかを知っています。スコアの高さを褒めるだけの一文は、中身がないと見抜かれます。技術力スコアはGitHub、技術記事、技術イベント、スキルタグの4つの項目で評価されると候補者向けサイトにあるので、褒めるならスコアではなく、その元になったアウトプットのほうを名指しします。
反対に、「確認できない項目」として挙げられているのは英語力と近年の活動の二つです。ヘルプセンターは「上記は候補者の画面では確認できないため、スカウトメッセージでの言及は避けましょう」と案内しています。候補者は企業からの閲覧履歴(プロフィールを閲覧した企業名とその日付)も確認できるとされているので、いつ、どこを見たかが相手に分かっている前提で書きます。見えないはずの情報に触れると、その前提と食い違って不審に映ります。
文例2:X の DM で送る場合
LAPRASは、メッセージ以外の経路も公式に案内しています。「LAPRASでは、メッセージ機能を使うスカウトのほかに、XのDM機能を使ったスカウトも推奨しています」という記載です。同じ相手に登壇スライドをきっかけに声をかける場合、DMでは次のくらいの温度感になります。
はじめまして、◯◯でバックエンドを見ている△△です。突然のDM失礼します。
先日の◯◯勉強会の登壇スライドを拝見して連絡しました。移行の進め方のところ、弊社がいま詰まっている論点そのもので、話を伺えないかと思っています。
採用の話は抜きでも構いません。もしご興味あれば、LAPRASからも改めてご連絡します。
文例1と比べて短く、件名もありません。ヘルプは、「一般にスカウトメッセージを送った場合の返信率は5~10%ほど、返信率の高いLAPRASのスカウトメッセージでも20〜30%程度ですが、XのDMを使った場合、弊社調査による実績では50〜60%と高い返信率が期待できます」と書いています。ガイドラインも、素性のわかる個人のアカウントから、時にはフランクさも交えながら送るよう勧めています。同じ文面をDMに貼るなら、DMにする意味はありません。
差出人による違いも明記されています。CTOや現職のエンジニアの方からのDMは返信が返って来やすい一方、会社代表アカウントや採用アカウントからのDMは返信率が低くなる傾向があるとされています。文例2を人事の採用アカウントから送っても、同じ効果は期待しにくいということです。DMを使うなら、誰の個人アカウントから送るかを先に社内で決めます。
注意書きもあります。DMでのスカウトは失礼と捉えられる可能性もあり、候補者のポジションや年齢などから、DMやフランクな文体で送ってよいかを見極める必要があるとされています。フォロワー限定の設定なら、フォローしてフォローバックを待つ手順になります。DMは返信率が高い分、相手を選ぶ経路です。
エラベルの見解
担当する側から見ると、文例1と文例2の違いは文章の上手さではなく、差出人の選び方にあります。この媒体では、禁止行為の説明に「実際には面接や選考を担当しない役員の名義でスカウトを送信する」ことが虚偽の例として明記されています。返信率を上げるために役員の名前だけを借りる運用は、ここでは取れません。
そのため、文面の作成を任された担当者が最初にやるべきなのは、書き始めることではなく、実際に面談に出られる人とその枠を確認することです。誰の名前で送るかを決める作業が、そのまま誰が面談に出るかを決める作業になります。ここを先に聞いてくる担当者かどうかで、文面の質は大きく変わります。
文例3:3か月後に手動で再送する文面
返信がなかった相手への追客も、文例を用意しておきます。LAPRASでは、1回目の再送は初回送信の翌週月曜日にシステムが自動で行い、2回目以降は手動で3か月〜半年ほど空けることが勧められています。手動の再送では「前回のメッセージを引用して送付することができかねます」とされているので、前回何を送ったかを自分で書き入れる必要があります。
件名:以前お送りした「Rails の API 設計のご経験について」の続報です(◯◯株式会社)
◯◯株式会社の△△です。3か月ほど前に、決済まわりの移行のご経験についてカジュアル面談のお願いをお送りしました。
その後、弊社でテックブログを始め、移行の設計判断を記事にまとめました。前回お伝えしきれなかった技術の現状が、こちらで読めるようになっています。
引き続き、選考ではなく30分のカジュアル面談としてお話しできればうれしいです。
ガイドラインは再送について、前回のメッセージでどんな内容のものを送ったのか(件名など)を入れること、新しい情報があればお知らせを入れることを勧めており、新しい情報の例としてエンジニアピッチ資料ができた、テックブログを作り始めた、を挙げています。文例3の二段落目がそれにあたります。再送の文面は、新しい材料があって初めて書けるものなので、3か月の間に何を出すかを先に決めておきます。再送の予定と発信の計画の組み方は、LAPRASのスカウト運用設計で扱っています。
直す前と直した後:通報につながる書き方を書き換える
最後に、避けたい書き方を具体的な直し方と並べます。禁止行為のよくある質問には、通報につながる典型と、虚偽にあたる例が具体的に並んでいます。次の表は、その例を「どう直すか」の形に置き換えたものです。
| 直す前の書き方 | 何が問題か | 直した後 |
|---|---|---|
| 候補者名を別の人の名前のまま送る | 候補者名の誤りは通報の典型例 | 送信前に名前を照合する手順を入れる |
| 転職意欲「情報収集中」の人に選考の案内を送る | 転職意欲の無視にあたる | 文例1のようにカジュアル面談として提案する |
| 連携していないSNSの投稿に触れる | どう辿ったのかが分からない | 辿った経路を書くか、確認できる項目だけに触れる |
| 「転職市場の情報提供」と銘打った一斉配信 | メッセージマガジン同様の内容にあたる | 一人に宛てた理由を書く |
| 選考前提なのにカジュアル面談として誘う | 虚偽の例として明記されている | 選考かどうかを件名と本文に書く |
| 業務委託を想定しているのに正社員のスカウトを送る | 虚偽の例として明記されている | 想定する契約形態をそのまま書く |
パーソナライズの程度については、「基本は、パーソナライズ不足だけを理由に、弊社で差し止めを行うことはございません」とされています。丁寧さの不足そのものは咎められませんが、通報が2件以上入ると調査が入る仕組みなので、結果として文面の質が送れる数を決めます。表の左の列を一つでも含む文面は、送る前に止めるという運用にしておくと安全です。
エラベルの見解
相談で多い思い込みは、「文面を丁寧に書けば返信率は上がる」というものです。実際にこの媒体で差がつくのは、文章の丁寧さより前の、転職意欲の設定を読んだかどうかです。「情報収集中」の人に選考の案内を送れば、どれだけ書き込んでも読まれずに閉じられます。逆に、意欲が高い設定の人に「まずは情報交換から」と送るのも、相手の時間を無駄にします。
転職意欲の設定を見るのは一瞬です。テンプレートを作るときは、本文の言い回しを磨く前に、転職意欲の設定ごとに提案の形(カジュアル面談か選考か)を分けた型を持っておくことをおすすめします。型が分かれていれば、書き手が替わっても外しません。
まとめ
- 初回スカウトは、ガイドラインの五つの基準(届いた理由、差出人、提案の中身、公開情報との一致、明示した希望への配慮)を一つずつ満たす形で書く
- 言及してよいのは候補者自身が確認できる項目だけ。英語力と近年の活動には触れず、閲覧履歴が相手に見えている前提で書く
- XのDMは返信率が高いとされるが、個人アカウントから、相手を選んで、DM用の短い文面で送る
- 手動の再送は前回の件名を書き入れ、テックブログやピッチ資料など新しい情報を添える
- 役員名義の借用や、選考前提のカジュアル面談は虚偽の例として明記されている。送る前に止める
よくある質問
Q. スカウト文面で英語力に触れてもよいですか
ヘルプセンターは、英語力と近年の活動を候補者の画面では確認できない項目としており、言及は避けるよう案内しています。候補者が見えない情報に触れると、どこから得たのか分からず不審に映ります。言及は、候補者自身が確認できる項目にとどめてください。
Q. 役員の名前でスカウトを送っても問題ありませんか
実際には面接や選考を担当しない役員の名義で送ることは、虚偽の例として挙げられています。役員の名前で送るなら、その人が実際に面談に出ることが前提です。送信計画を立てる前に、面談に出られる人の枠を押さえておきます。
Q. 再送するとき、前回のメッセージを引用できますか
ガイドラインでは、再送で前回のメッセージを引用して送ることはできないとされています。そのため、前回の件名や送った時期を文面に自分で書き入れます。新しい情報があれば、その知らせを入れることも勧められています。
※料金・通数・機能の条件は変わります。掲載した内容は2026年9月24日時点の公式サイトおよび採用担当者向けヘルプセンターの記載であり、契約前に運営にご確認ください。