ナレッジベース

LAPRASは、GitHubや技術記事といった公開アウトプットをもとにエンジニアのプロフィールを生成する採用サービスです。職務経歴だけでは見えにくい技術力や興味関心まで確認したうえでアプローチでき、今すぐ転職しない候補者とも中長期で関係を築ける点が他媒体との違いになります。

この記事では、料金プランや主な機能に加え、候補者の見極め方や興味通知とスカウトの使い分け、タレントプールの運用まで、企業の採用担当者向けに実践的なポイントをまとめています。

LAPRASとは？

LAPRASは、LAPRAS株式会社が運営するITエンジニア向けのダイレクトリクルーティングサービスです。職務経歴だけでなく、エンジニアが公開しているアウトプットをもとにプロフィールを生成する仕組みを持っています。

公開情報から候補者を理解する媒体

LAPRASの最大の特徴は、一般的な転職データベースと異なり、エンジニアのブログ・OSS活動・SNSなどをもとにプロフィールが生成される点です。

企業側は候補者を確認する際、次のような情報を横断して見られます。

• GitHubの活動
• QiitaやZennの技術記事
• 技術ブログ
• connpassなどのイベント参加・登壇履歴
• 職務経歴
• 本人が記載している「やりたいこと」
• 直近のアウトプット

職務経歴書だけでは見えにくい技術力や興味関心まで把握したうえでアプローチできます。

現在はハイクラス層だけでなく、AIエンジニア・エンジニアリングマネージャー・SREなど採用難度の高い職種を主要ターゲットとして打ち出しています。

「最近何をしているか」まで読める

LAPRASらしい運用として、候補者の直近の活動から志向を推測するアプローチがあります。

導入企業の事例では、次のような読み取り方が紹介されています。

以前はフロントエンド中心のアウトプットだった
↓
最近はサーバーサイドの発信が増えている
↓
バックエンドにも興味があるのではないかと仮説を立てる
↓
「当社ではフロントだけでなくサーバーサイドも担当できます」と伝える

本人の自己申告だけでなく、公開されているアウトプットから仮説を立てられる点が他媒体との違いです。

「興味通知」で段階的にアプローチできる

LAPRASでは、いきなりスカウトを送るのではなく、候補者をタレントプールに追加したうえで「興味通知」を送れます。

候補者は「この会社が自分に興味を持っている」ことを確認し、自分も興味があれば「興味あり」とリアクションできます。

候補者を発見する
↓
タレントプールに追加する
↓
興味通知を送る
↓
候補者が「興味あり」を返す
↓
個別のスカウトを送る

一次接触のハードルを下げられるため、転職を明確に決めていない層とも接点を作れます。

中長期の関係構築を前提とした設計

エンジニア採用では母集団が限られるため、LAPRASは再アプローチを前提とした中長期の採用を想定した設計になっています。

「今は転職できない」という候補者を対象から外すのではなく、タレントプールに残して転職意欲の変化を待つ運用が可能です。

導入企業のなかには、最初の接点から4か月後に応募意思を獲得し、その候補者が他社の選考を受けずに入社したという事例もあります。

他のエンジニア向け媒体との違い

観点	一般的なエンジニア向け媒体	LAPRAS
候補者の判断材料	職務経歴・スキルデータ	職歴＋公開アウトプット・活動履歴
アプローチの起点	スカウトの送信	興味通知による一次接触
時間軸	短期の母集団形成	中長期の関係構築
候補者管理	送信済みリスト	タレントプールによるCRM的な管理

よくある質問

Q：GitHubやブログを公開していないエンジニアも登録していますか？
A：登録しています。アウトプットが少ない候補者については職務経歴や本人の記載内容から判断することになります。ただしLAPRASの強みは公開情報から候補者を理解できる点にあるため、アウトプットのある候補者ほどこの媒体の特性を活かせます。

Q：スカウトを送らずに採用することはできますか？
A：可能です。導入企業のなかには、スカウトメールをほとんど送らず、興味通知と作り込んだ求人票だけで運用している企業もあります。候補者側から求人を見つけて興味を示すオーガニックな流入も発生するため、求人票の作り込みが成果に直結します。

LAPRASの特徴と登録者層

LAPRASを活用するには、どのようなエンジニアが登録しているのか、そして候補者側から企業がどう見えているのかを理解しておく必要があります。

登録者層のイメージ

項目	内容
職種	ITエンジニア全般
注力領域	AIエンジニア・エンジニアリングマネージャー・SREなど採用難度の高い職種
特徴	技術記事やOSS活動など公開アウトプットのある層が多い
転職状況	転職潜在層を含む
志向	技術的な発信や技術コミュニティへの参加が活発な層

公開情報をもとにプロフィールが生成される仕組みであるため、技術的なアウトプットを行っているエンジニアの解像度が特に高くなります。

LAPRASの5つの特徴

公開アウトプットから技術力と興味関心を確認できる

GitHub、Qiita、Zenn、技術ブログ、イベント登壇履歴などを横断して確認できます。職務経歴書に書かれていない技術的な関心や取り組みを把握したうえでアプローチできる点が、他媒体との大きな違いです。

AIによるスキルの補完がある

候補者が明示的に「エンジニアリングマネージャー」「テックリード」と記載していなくても、職歴や職務要約をAIが読み取り、次のような経験を判定する機能があります。

• ピープルマネジメントの経験
• エンジニアリングリードの経験
• プロジェクトマネジメントの経験
• AIプロダクトの開発経験や志向

肩書きが一致していなくても、実質的に近い経験を持つ候補者を拾えます。

ただしLAPRAS自身も、AI判定の正確性は100%ではなく、最終判断ではプロフィールの詳細を確認するよう明記しています。見落としを減らす入口として使い、最終的には人が職歴とアウトプットを確認する運用が適切です。

候補者側に企業の閲覧行動が見える

候補者は「どの企業が自分のプロフィールやアウトプットを見たか」を確認できます。

この仕組みにより、実際にアウトプットを読んだうえでその内容に触れたスカウトを送ると、候補者に「本当に自分を見てくれた」という印象を与えられます。逆に、見ていないのに「拝見しました」と書くようなスカウトは、媒体の設計と噛み合いません。

スカウトの品質に関するガイドラインがある

LAPRASにはスカウトの品質ガイドラインが用意されています。背景には、一方的なスパム的メッセージ、虚偽や誇張、候補者との情報の非対称性といった従来型の採用手法への問題意識があります。

ちゃんと候補者を見る企業ほど有利になる媒体であると理解しておく必要があります。

転職意欲が可視化されている

候補者は転職意欲を設定しており、企業側はその状態を確認できます。また転職意欲が変化した際の通知も活用できるため、タレントプールに保存した候補者が動き始めたタイミングを捉えられます。

条件検索よりアウトプットを見る

導入企業の事例では、使用言語や経験年数で候補者を過度に限定していないケースが目立ちます。

実際に見ている観点

• プロジェクトでどこまで踏み込んだか
• 設計から実装まで何を担当したか
• GitHubやZennで何を発信しているか
• 会社の方向性と本人の志向が合うか

「Goの経験3年以上」「AWSの経験5年以上」といった条件よりも、「大規模サービスの設計から実装まで一貫して担当した」「自分で課題を見つけて動いた」「技術を目的ではなく事業を作る手段として捉えている」といった実態を確認するほうが、特にシニア層では実力を捉えやすくなります。

よくある質問

Q：AIスキルハイライトはどこまで信用できますか？
A：見落としを減らす入口として活用してください。肩書きが一致しない候補者を拾える点は有用ですが、判定の正確性は100%ではないとLAPRAS自身も明記しています。候補者を絞り込む際は、AIの判定結果だけで判断せず、職務経歴と公開アウトプットを確認したうえで最終判断してください。

Q：候補者に閲覧行動が見えることはデメリットではありませんか？
A：丁寧に運用する企業にとってはメリットになります。プロフィールやアウトプットを実際に読んだうえで、その内容に触れたスカウトを送れば、候補者は企業の本気度を認識します。逆に大量配信を前提とした運用では、閲覧行動と文面の不一致が見抜かれるリスクがあります。

LAPRASの主な機能

LAPRASには、公開情報から候補者を理解し、中長期で関係を築くための機能が揃っています。

求人票

採用したいポジションを掲載します。LAPRASで重要なのは、この求人票が候補者に見えるファーストビューを構成する点です。

候補者が興味通知を受け取ると、企業名だけでなく次の情報を確認します。

• 求人タイトル
• 職種
• 年収
• 勤務地
• リモートの可否
• こだわり条件

公式でも、このファーストビューがその後の興味リアクションやスカウトの返信率に大きく影響すると説明されています。求人票の作り込みはスカウト施策の一部と捉える必要があります。

候補者検索

条件を設定して候補者を検索します。技術要件だけでなく、転職意欲や希望する働き方でも絞り込めます。

AIスキルハイライト

候補者の職歴や職務要約をAIが読み取り、明示されていない経験を判定する機能です。

判定される内容の例

ピープルマネジメントの経験

エンジニアリングリードの経験

プロジェクトマネジメントの経験

AIプロダクトの開発経験・志向

肩書きがエンジニアリングマネージャーでなくても、実質的に近い経験を持つ候補者を検索で拾えます。

Social Search

外部の技術コミュニティから候補者を探せる機能です。

導入企業のなかには、connpass上で「アジャイル」「スクラム」といった関連イベントの参加者を探し、そこからアプローチしている企業があります。同社は技術スキルだけでなく、どのコミュニティに参加しているかを候補者理解に使っています。

活用の例

採用ポジション	探すコミュニティの例
SRE	SRE関連・Observability・Kubernetes
エンジニアリングマネージャー	組織開発・スクラム・EM関連
AIエンジニア	機械学習・LLM関連

職種名での検索とは異なる軸で候補者を発見できます。

タレントプール

候補者を保存して管理する機能です。LAPRASの運用ではこの機能が中心に置かれます。

保存する候補者の分類例

• 今すぐ会いたい候補者
• 興味通知を送った候補者
• 「興味あり」が返ってきた候補者
• 今すぐ転職しない候補者
• 面談済みの将来候補
• 転職意欲の変化を待つ候補者

単なる「スカウトを送った人の一覧」ではなく、将来採用したいエンジニアを蓄積するCRMとして使う設計です。

興味通知

タレントプールに追加した候補者へ、企業が興味を持っていることを伝える機能です。候補者は自分も興味があれば「興味あり」とリアクションできます。

スカウトの前段階として、負荷の低い一次接触に使えます。公式ヘルプでも、「興味あり」が返ってきた候補者だけにメッセージを送るためのタレントプールを作る方法が紹介されています。

スカウト

個別のメッセージを送る機能です。興味通知に反応があった候補者や、明確に会いたい候補者に対して使います。

転職意欲の変更通知

タレントプールに保存した候補者の転職意欲が変化した際に通知を受け取れます。候補者が動き始めたタイミングを捉えられるため、中長期の運用において重要な機能です。

分析機能

候補者の検索からアプローチ、スカウト、再アプローチまでの各工程を確認できます。どの段階に課題があるかを特定するために使います。

採用支援サービス

LAPRAS自身が採用代行やBPaaSを提供しています。候補者の発掘やスカウト運用を外部に委託し、社内のリソースを候補者との対話に集中させるという使い方も可能です。

導入企業のなかには、技術的な見極めをエンジニアリングマネージャー、候補者の発掘とスカウト運用をLAPRASのBPaaS、候補者とのキャリア対話を人事という形で役割を分け、導入から約半年で5名の入社につなげた企業があります。

よくある質問

Q：興味通知とスカウトはどう使い分けますか？
A：興味通知は負荷の低い一次接触、スカウトは「なぜあなたと会いたいのか」を説明する手段と役割を分けてください。いきなり長文のスカウトを送るのではなく、まず興味通知で反応を見て、「興味あり」が返ってきた候補者に個別のスカウトを送る流れが基本になります。

Q：Social Searchはどのような場面で使いますか？
A：職種名での検索だけでは候補者が見つからない場合や、特定の技術領域に関心のある層を探したい場合に有効です。参加しているコミュニティは候補者の関心を示す情報であるため、スキルだけでなくカルチャーのマッチを重視する採用でも活用できます。

LAPRASのメリット・デメリット

公開情報から候補者を理解できる点が最大の強みですが、その分だけ読み込みの工数が発生します。

メリット

候補者の理解を深めたうえでアプローチできる

GitHub、技術記事、イベント参加履歴といった公開情報を確認できるため、職務経歴書だけでは分からない技術力や興味関心を把握できます。パーソナライズしたスカウトを作りやすい環境です。

肩書きに縛られず候補者を探せる

AIスキルハイライトによって、明示されていない経験を持つ候補者も検索で拾えます。エンジニアリングマネージャーやテックリードといった、肩書きが一致しにくいポジションの採用で効果を発揮します。

低い負荷で一次接触できる

興味通知はスカウト文を作成する必要がありません。まず接点を作り、反応があった候補者に個別のスカウトを送るという流れにできます。

中長期の候補者管理ができる

タレントプールと転職意欲の変更通知によって、今すぐ転職しない候補者も将来の候補として管理できます。母集団が限られるエンジニア採用において、この蓄積が効いてきます。

独自のソーシングができる

Social Searchで外部の技術コミュニティから候補者を探せます。職種名での検索とは異なる軸でアプローチできるため、他社と競合しにくい候補者を発見できます。

オーガニックな流入も期待できる

求人票を作り込むことで、候補者側から求人を見つけて興味を示す動きが生まれます。導入企業のなかには、スカウトをほとんど送らずに採用へつなげた事例もあります。

採用支援サービスを併用できる

LAPRAS自身が採用代行やBPaaSを提供しているため、候補者の発掘やスカウト運用を外部に委託できます。社内のリソースを候補者との対話に集中させる設計が可能です。

デメリット

アウトプットがない候補者は判断しにくい

公開情報が少ない候補者については、職務経歴だけで判断することになります。LAPRASの強みを活かしきれないケースが生じます。

候補者の読み込みに工数がかかる

GitHubや技術記事を確認したうえでスカウトを作るため、1名あたりの時間は他媒体より長くなります。大量送信を前提とした運用はできません。

ばらまき型の運用ができない

スカウトの品質ガイドラインがあり、候補者側にも企業の閲覧行動が見える設計です。実際に見ていないのに「拝見しました」と書くような運用は、媒体の思想と噛み合いません。

母集団が限られる

エンジニアに特化しており、なかでも技術的な発信をしている層が中心です。大量採用や幅広い職種の採用には向きません。

短期間の採用には向かない

興味通知から関係を作り、転職意欲の変化を待つという中長期の運用が前提です。数週間で採用したい状況には適していません。

求人票の作り込みが前提になる

候補者が見るファーストビューを構成するため、求人票が薄いと興味通知への反応も得られません。作成に相応の時間が必要です。

エンジニア以外の採用には使えない

ITエンジニアに特化した媒体です。

メリット・デメリットの整理

観点	メリット	デメリット
候補者理解	公開アウトプットまで確認できる	読み込みの工数がかかる
検索	肩書きに縛られず探せる	AI判定は最終判断にならない
アプローチ	興味通知で低負荷に接点を作れる	ばらまき運用ができない
時間軸	中長期で候補者を蓄積できる	短期採用には向かない
求人票	オーガニック流入も期待できる	作り込みが前提になる

よくある質問

Q：工数がかかる媒体だと聞きましたが、どう対応すればよいですか？
A：役割分担と外部委託の2つの選択肢があります。人事が候補者を探し、エンジニアが技術的な着眼点を数行で提供し、人事が文面を仕上げるという分担であれば、現場の負担を抑えられます。またLAPRASの採用代行やBPaaSを活用し、候補者の発掘とスカウト運用を委託する方法もあります。

Q：スカウトを送らない運用は現実的ですか？
A：求人票を作り込めば可能です。導入企業のなかには、スカウトをほとんど送らず、興味通知と求人票だけで運用している企業があります。ただしこの運用には求人票をランディングページのように作り込む必要があり、初期の工数は相応にかかります。

LAPRASの料金体系

LAPRASには、運用スタイルに応じて3つのプランが用意されています。固定費型と成功報酬型のどちらを選ぶかで、費用構造が大きく変わります。

3つのプラン

プラン	料金構造	想定される使い方
セルフプラン	月額固定・成功報酬なし	自社でスカウト運用を行う
BPaaSプラン	月額＋成功報酬	運用の一部をLAPRASへ委託する
JOB BOARDプラン	完全成功報酬（年収の15%程度）	求人掲載のみで運用する

セルフプラン

月額固定制で成功報酬が発生しません。採用人数に上限がないため、複数名を採用するほど1名あたりの単価が下がります。

複数名を採用したケースでは、1名あたりの採用単価を20万〜30万円台に抑えている例も紹介されています。

自社で候補者の検索からスカウトの送信までを行う体制がある企業に向いたプランです。

BPaaSプラン

月額費用に加えて、採用決定時に成功報酬が発生するプランです。

LAPRASが候補者の発掘やスカウト運用を支援するため、社内のリソースを候補者との対話に集中させられます。導入企業のなかには、技術的な見極めをエンジニアリングマネージャー、候補者の発掘と運用をBPaaS、候補者とのキャリア対話を人事という形で役割を分け、導入から約半年で5名の入社につなげた企業があります。

採用体制が縮小するなかでBPaaSを活用し、半年で2名のシニアエンジニアを採用した事例も公開されています。

JOB BOARDプラン

月額の固定費用が発生せず、求人を掲載して採用が決定した際に成功報酬が発生するプランです。成功報酬は年収の15%程度とされています。

固定費をかけずに始められるため、まず求人を掲載して反応を見たい段階の企業に適しています。

採用単価のシミュレーション

セルフプラン（月額固定）の場合

月額費用を年間120万円と仮定した試算です。

採用人数	年間総額	1名あたりの単価
1名	120万円	120万円
3名	120万円	40万円
5名	120万円	24万円

JOB BOARDプラン（成功報酬15%）の場合

年収800万円のエンジニアを採用した場合です。

採用人数	総額	1名あたりの単価
1名	120万円	120万円
3名	360万円	120万円
5名	600万円	120万円

採用人数が増えるほど、固定費型のセルフプランが有利になります。1名だけの採用であれば、成功報酬型のJOB BOARDプランのほうがリスクを抑えられます。

他の採用手法との比較

年収800万円のエンジニアを採用した場合の比較です。

採用手法	料金構造	1名あたりの目安
LAPRAS（JOB BOARD）	成功報酬15%程度	120万円
LAPRAS（セルフ）	月額固定	採用人数によって変動
人材紹介	完全成功報酬30〜35%	240万〜280万円
Forkwell Jobs	基本利用料＋成功報酬25%	基本利用料＋200万円

成功報酬の料率は他の手法と比べて低く設定されています。

運用工数も含めて評価する

セルフプランを選ぶ場合、運用にかかる人件費が実質的なコストになります。LAPRASでは特に次の工数が発生します。

• 求人票の作り込み
• 候補者の公開アウトプットの読み込み
• 興味通知とスカウトの送信
• タレントプールの管理と再アプローチ
• カジュアル面談の実施

候補者1名あたりの読み込みに時間がかかる媒体であるため、この工数を確保できるかどうかがプラン選定の判断材料になります。工数を確保できない場合は、BPaaSプランの活用を検討してください。

よくある質問

Q：どのプランを選ぶべきですか？
A：採用人数と社内の運用体制で判断します。複数名を採用する計画があり、運用工数を確保できるならセルフプランが有利です。運用に手が回らない場合はBPaaSプラン、まず固定費なしで試したい場合はJOB BOARDプランが選択肢になります。

Q：プランの具体的な金額はどこで確認できますか？
A：月額費用の具体的な金額は公開されておらず、問い合わせが必要です。成功報酬の料率についても情報源によって記載が異なるため、契約前に必ず商談時に確認してください。

LAPRAS採用の全体像と運用体制

LAPRASは候補者1名あたりの読み込みに時間がかかる媒体です。人事が単独で運用しようとすると、技術的な理解が追いつかず、逆にエンジニアに全工程を任せると運用が止まります。役割分担の設計が成果を左右します。

採用のファネル

候補者検索
↓
タレントプールへ追加
↓
興味通知の送信
↓
候補者からの「興味あり」
↓
個別スカウトの送信
↓
返信
↓
カジュアル面談
↓
選考
↓
内定
↓
承諾

このほか、候補者側が求人を見つけて「興味あり」を返すオーガニックな流入もあります。求人票を作り込むことで、この経路からの反応も期待できます。

実際の運用フロー

① CTO・EM・人事で採用要件と技術課題を整理する

技術要件だけでなく、現在どのような技術課題を抱えていて、入社した人に何を任せたいのかまで言語化します。

② 求人票を作り込む

事業内容、技術課題、開発組織、カルチャー、期待する役割を具体化します。候補者のファーストビューを構成する部分であるため、スカウトより先に着手する価値があります。

③ 候補者を広めに検索する

AIスキルハイライトや検索機能を使い、条件を絞りすぎずに候補者を抽出します。

④ 公開アウトプットを確認する

職務経歴だけでなく、GitHub、Qiita、Zenn、登壇履歴、直近の活動を確認します。「最近何に興味があるか」まで仮説を立てます。

⑤ タレントプールへ追加する

候補者を状態別に整理して保存します。

⑥ 興味通知で一次接触する

いきなりスカウトを送るのではなく、まず興味通知で反応を見ます。

⑦ 優先順位をつける

「興味あり」の有無と転職意欲の状態で、アプローチの温度を変えます。

⑧ エンジニアから着眼点をもらう

「この人のここが技術的に気になる」という1〜2行を現場から受け取ります。

⑨ 個別スカウトを送る

「なぜあなたなのか」「自社の課題」「期待する役割」を書きます。

⑩ カジュアル面談を実施する

エンジニアリングマネージャーやCTOなど現場を参加させます。

⑪ 今すぐ転職しない候補者はタレントプールへ残す

関係を維持し、転職意欲の変化を待ちます。

⑫ ファネルごとに数値を確認して改善する

人事とエンジニアの分業

LAPRASが推奨している運用も、次のような分業を前提としています。

担当	役割
人事	候補者のサーチ・文章化・送信・運用管理
エンジニア	アプローチの判断・技術的な着眼点の提供

なぜこの分担が有効なのか

非エンジニアの人事が「このGitHubの何がすごいのか」をすべて理解するのは困難です。一方、エンジニアに「候補者の検索からスカウト送信まですべてお願いします」と依頼すると、運用が止まります。

そこで、人事が候補者を探し、エンジニアが1〜2行のコメントを残し、人事がそれをもとにスカウトを作成するという分担にします。

導入企業のなかには、社内エンジニアが候補者のプロフィールを見て「この方のここが気になった」というポイントをLAPRAS上のコメントに1〜2行残し、リクルーターがそれを使ってアプローチを進めている企業があります。同社はこの共同運用によって、常時50〜60名程度との接点を維持しています。

エンジニアにスカウト文を書いてもらう必要はありません。技術者にしか分からない着眼点だけを提供してもらうという分担であれば、現場の負担を大きく抑えられます。

外部支援も含めて役割を分ける

導入企業のなかには、次のように完全に役割を分けている企業もあります。

工程	担当
技術的な見極め	エンジニアリングマネージャー
候補者の発掘・スカウト運用	LAPRASのBPaaS
候補者とのキャリア対話	人事

同社は2025年初頭の導入から約半年で5名のエンジニアの入社が決定しています。

「誰が候補者を探すか」「誰が技術を見るか」「誰が口説くか」をすべて人事1人に集約しないことが重要です。

量ではなく候補者と向き合う時間を増やす

LAPRAS自身も、ばらまき型の運用やスカウト疲れを課題として捉えており、AIと専門チームで興味通知などを支援するプランを提供しています。

導入企業でも、スカウト作業を外部に委託して人事が候補者との対話に集中する運用が見られます。

量を増やす部分は仕組みや外部支援に寄せ、人は候補者理解・面談・アトラクトに時間を使うという方向性が、この媒体の運用に適しています。

よくある質問

Q：エンジニアに協力を依頼する際、どう伝えればよいですか？
A：「スカウトを書いてほしい」ではなく、「候補者のプロフィールを見て、技術的に気になった点を1〜2行で教えてほしい」と依頼してください。作業内容が明確で負担も小さいため、協力を得やすくなります。慣れてきた段階で、カジュアル面談への参加へ広げていく進め方が定着しやすくなります。

Q：運用開始からどのくらいで成果が出ますか？
A：中長期の関係構築を前提とする媒体であるため、導入直後から採用が決まるとは限りません。導入企業のなかには最初の3か月を求人票の改善に充てた例や、最初の接点から4か月後に応募意思を獲得した例があります。半年程度を前提に運用計画を立ててください。

LAPRASの求人票の作り方

LAPRASでは求人票が候補者のファーストビューを構成します。興味通知を受け取った候補者は、企業名だけでなく求人の情報を見て反応するかを判断します。

求人票はスカウト施策の一部

候補者が興味通知を受け取った際に確認するのは、次の情報です。

• 求人タイトル
• 職種
• 年収
• 勤務地
• リモートの可否
• こだわり条件

公式でも、このファーストビューがその後の興味リアクションやスカウトの返信率に大きく影響すると説明されています。

スカウト文だけを改善しても、求人票が薄いままでは成果につながりません。

スカウトを送る前に求人票を作り込む

導入企業のなかには、LAPRAS導入後の最初の3か月はあえてスカウトを送らず、求人票の改善に集中した企業があります。

改善前の状態

• 企業の肩書き（研究機関発のスタートアップであること）だけが強く打ち出されている
• 仕事内容は「アプリ開発をお願いします」という一般的な記載

改善後に追加した内容

• 何を実現する会社なのか
• 技術的に何が面白いのか
• 最終的に何を成し遂げたいのか
• カルチャー
• バリュー

その結果、同社はLAPRAS経由で3名を採用し、そのうち2名は候補者側から興味を持ったオーガニックな流入でした。

求人票を「エンジニア向けのLP」として作る

導入企業のなかには、スカウトメールをほとんど送らず、興味通知と徹底的に作り込んだ求人票だけで運用している企業もあります。

同社は求人票をランディングページのように捉え、候補者が次の順序で理解を深められる情報を作り込んでいます。

会社を知る
↓
仕事内容を理解する
↓
技術と組織を理解する
↓
興味を持つ
↓
カジュアル面談へ進む

求人票に盛り込みたい要素

要素	記載する内容
事業	何を実現しようとしている会社なのか
技術課題	現在どのような課題に取り組んでいるのか
技術スタック	使用言語・インフラ・開発環境
開発組織	チーム構成・意思決定の進め方
期待する役割	入社後に何を任せたいのか
カルチャー	大切にしている考え方

求人タイトルに具体性を持たせる

候補者が最初に目にする要素です。抽象的な表現ではなく、技術情報や事業の具体性を入れます。

• 避けたい例：「社会課題を解決するエンジニア募集」
• 推奨される例：「〇〇の基盤刷新を担うバックエンドエンジニア｜Go×AWS」

年収と働き方を明示する

ファーストビューに含まれる情報であるため、年収レンジやリモートの可否が空欄だと、候補者は検討の土台に乗せられません。記載できる範囲で具体的に示してください。

オーガニックな流入を設計する

LAPRASでは、候補者自身が求人を見つけて「興味あり」を返す動きもあります。

この経路から反応した候補者は、企業側からアプローチした候補者より関心が高い状態です。公式でも、求人への「興味あり」が届いた場合は1週間以内を目安にカジュアル面談を案内することが推奨されています。

求人票を作り込むことは、スカウトの返信率を上げるだけでなく、この能動的な流入を生むことにもつながります。

よくある質問

Q：求人票の作り込みにどのくらい時間をかけるべきですか？
A：導入企業のなかには3か月をかけた例もあります。すべての企業がそこまで時間をかける必要はありませんが、スカウトを送り始める前に一度作り込んでおくほうが、その後の運用効率は上がります。薄い求人票のまま興味通知を送っても、反応が得られずに機会を消費することになります。

Q：技術課題を書くと候補者が敬遠しませんか？
A：敬遠されるより、取り組む価値のある課題として受け取られるケースのほうが多くなります。重要なのは課題を挙げるだけでなく、それをどう解こうとしているのか、入社した人に何を任せたいのかまで書くことです。課題と方針をセットで提示することで、技術的な挑戦として伝わります。

候補者の探し方と見極め方

LAPRASの強みは、職務経歴書だけでは分からない情報を確認できる点にあります。条件検索で機械的に絞るのではなく、候補者を読み込む前提で運用します。

検索条件を絞りすぎない

導入企業の事例では、使用言語や経験年数で候補者を過度に限定していないケースが目立ちます。

条件で絞る代わりに見ている観点

• プロジェクトでどこまで踏み込んだか
• 設計から実装まで何を担当したか
• GitHubやZennで何を発信しているか
• 会社の方向性と本人の志向が合うか

「Goの経験3年以上」「AWSの経験5年以上」といった条件よりも、「大規模サービスの設計から実装まで一貫して担当した」「自分で課題を見つけて動いた」「技術を目的ではなく事業を作る手段として捉えている」といった実態を確認するほうが、特にシニアやリード層では実力を捉えやすくなります。

公開アウトプットを確認する

候補者を判断する際に確認したい情報源です。

情報源	分かること
GitHub	実装の内容・コードの書き方・関わっているプロジェクト
Qiita・Zenn	技術的な関心領域・思考の深さ
技術ブログ	設計判断の考え方・課題への向き合い方
connpassなどのイベント	参加・登壇しているコミュニティ＝関心のある領域
SNS	直近で何に興味を持っているか

職務経歴には書かれない情報から、候補者の技術的な関心を把握できます。

「最近の活動」から志向を読む

LAPRASらしい運用として、直近のアウトプットの変化から候補者の志向を推測するアプローチがあります。

読み取りの例

以前はフロントエンド中心のアウトプットだった
↓
最近はサーバーサイドに関する発信が増えている
↓
バックエンドにも関心が向いているのではないかと仮説を立てる
↓
「当社ではフロントだけでなくサーバーサイドも担当できます」と伝える

導入企業のなかには、この読み取りに加えてSNSまで確認し、候補者が何に興味を持っているかを理解したうえで文面を作成した結果、運用初期から25%以上の返信率を維持し、高い月には42%だったという事例があります。これは個別企業の実績であり、媒体全体の平均値ではありません。

「何をやってきた人か」だけでなく、**「最近どこへ向かおうとしている人か」**まで読むことが、この媒体の使い方を象徴しています。

AIスキルハイライトで見落としを減らす

候補者が明示的に「エンジニアリングマネージャー」「テックリード」と記載していなくても、職歴や職務要約をAIが読み取り、実質的に近い経験を判定します。

肩書きが一致しない候補者も検索で拾えるため、母集団を広げる用途に有効です。

ただしLAPRAS自身も判定の正確性は100%ではないと明記しています。次の順序で使ってください。

AIスキルハイライト・検索で候補者を広く抽出する
↓
プロフィールの詳細を確認する
↓
公開アウトプットを確認する
↓
最終的に人が判断する

スコアや判定結果だけで候補者を絞り込む運用は避けてください。

Social Searchでコミュニティから探す

外部の技術コミュニティから候補者を探せます。

導入企業のなかには、connpass上で「アジャイル」「スクラム」といった関連イベントの参加者を探し、そこからアプローチしている企業があります。同社は技術スキルだけでなく、どのコミュニティに参加しているかを候補者理解に使っており、LAPRAS経由の平均返信率17.4%、高い月は30%超だったとしています。

活用の例

採用ポジション	探すコミュニティの例
SRE	SRE関連・Observability・Kubernetes
エンジニアリングマネージャー	組織開発・スクラム・EM関連
AIエンジニア	機械学習・LLM関連

過去には、特定のキーワードからその領域に関心のあるエンジニアを探し、スキルとカルチャーの両面でマッチングした事例もあります。

職種名での検索とは異なる軸で候補者を発見できるため、他社と競合しにくい層にアプローチできます。

よくある質問

Q：候補者1名の確認にどのくらい時間をかけるべきですか？
A：一律の基準はありませんが、GitHubや技術記事を確認したうえでスカウトを作る場合、1名あたり10分以上かかることも珍しくありません。すべての候補者を同じ密度で読み込む必要はないため、興味通知の段階では簡易的に確認し、「興味あり」が返ってきた候補者を深く読み込むという配分が現実的です。

Q：アウトプットが少ない候補者はどう判断すればよいですか？
A：職務経歴と本人が記載している「やりたいこと」から判断することになります。ただしLAPRASの強みは公開情報から候補者を理解できる点にあるため、アウトプットのある候補者を優先するほうが、この媒体の特性を活かせます。

興味通知とスカウトの使い分け

LAPRASでは、いきなりスカウトを送るのではなく、興味通知で一次接触してから個別のメッセージを送る流れが基本になります。

2つの機能の役割を分ける

機能	役割
興味通知	接点を作るノックの役割
スカウト	なぜあなたと会いたいのかを説明する役割

興味通知はスカウト文を作成する必要がないため、負荷の低い一次接触として使えます。反応があった候補者に対して、時間をかけた個別のスカウトを送るという配分が効率的です。

「興味あり」が返ってきたら早く対応する

公式では、興味通知にリアクションがあった場合、1〜2営業日以内を目安に連絡することが推奨されています。

スカウトに含めたい内容

1. 興味を返してくれたことへのお礼
2. なぜ声をかけたのか
3. 候補者のどこを評価しているのか
4. 想定しているポジション
5. 期待する役割
6. カジュアル面談の案内

「興味ありがとうございます。一度お話しませんか」というだけでは、候補者にとって会う理由になりません。

求人への「興味あり」は最優先で対応する

企業からの興味通知に候補者が反応するケースとは別に、候補者自身が求人を見つけて「興味あり」を返す動きもあります。

後者は候補者が自分から求人を探して行動しているため、企業への関心がかなり高い状態です。公式でも、求人への「興味あり」が届いた場合は1週間以内を目安にカジュアル面談を案内することが推奨されています。

候補者の優先順位

優先度	候補者の状態
A	求人へ候補者から「興味あり」が届いている
B	興味通知へ候補者から「興味あり」が返ってきた
C	転職意欲が高いが、リアクションはない
D	転職意欲が低く、リアクションもない

上位から順に対応することで、限られた時間を効率的に使えます。

スカウトの冒頭で会社紹介をしない

LAPRASでは開封前にメッセージの冒頭部分が表示されます。自己紹介だけで冒頭を消費すると、他社との差別化が難しくなります。モバイルでは開封後も冒頭部分の見え方が重要になります。

避けたい書き出し

「突然のご連絡失礼いたします。株式会社〇〇で採用を担当しております〇〇と申します」

推奨される書き出し

「GitHubで公開されている〇〇の設計を拝見し、現在当社が進めている△△の基盤刷新と非常に近いご経験だと感じ、ご連絡しました」

「なぜあなたに送ったのか」を先に書き、会社紹介は後ろに置くという順序にします。

具体的なアウトプットに触れる

候補者側には「どの企業が自分のプロフィールやアウトプットを見たか」が表示されます。実際に読んだうえでその内容に触れると、候補者に「本当に自分を見てくれた」という印象を与えられます。

• 弱い書き方：「〇〇社でバックエンドをされている点に興味を持ちました」
• 強い書き方：「Zennで書かれていた『〇〇から△△へ移行した際の設計判断』の記事を拝見しました。特に□□という考え方が、当社の現在の課題と近く」

LAPRASではアウトプットを読むこと自体がパーソナライズになります。

「褒める」のではなく「なぜ自社と合うか」を書く

公式の運用設計でも、次の内容を整理してからアプローチする「採用シナリオ」の作成が推奨されています。

• 現在の事業とプロダクトのフェーズ
• 技術的な課題
• 今後作りたいエンジニア組織
• その候補者にどのような活躍をしてほしいか

構成の例

現在当社には〇〇という課題がある
↓
あなたの△△の経験なら、この課題を解決できると考えている
↓
入社いただいたら□□までお任せしたい

「非常に高い技術力をお持ちですね」という賛辞では、候補者にとっての意味が生まれません。

転職意欲と自社への興味でメッセージの温度を変える

候補者の状態によって、伝え方と提案を変えます。

候補者の状態	提案の仕方
転職意欲が高く、自社にも興味がある	面談を強く提案する
転職意欲は高いが、リアクションがない	自社の魅力と課題を丁寧に伝える
転職意欲は低いが、自社に興味がある	転職前提ではなく技術やキャリアの話として提案する
転職意欲がなく、興味もない	無理にアプローチせず、タレントプールで管理する

全員に同じ提案を送るのではなく、状態に応じてCTAを変えることが重要です。

ばらまき型の運用は避ける

LAPRASにはスカウトの品質ガイドラインがあります。背景には、一方的なスパム的メッセージ、虚偽や誇張、候補者との情報の非対称性といった従来型の採用手法への問題意識があります。

「GitHubを見ました」と書きながら実際には見ていないというスカウトは、閲覧行動が候補者に見える設計上、見抜かれる可能性があります。

丁寧に候補者を見る企業ほど有利になる媒体であると理解して運用してください。

よくある質問

Q：興味通知を送っても反応がない場合はどうすればよいですか？
A：求人票を見直してください。候補者は興味通知を受け取った際、求人タイトル・職種・年収・勤務地・リモートの可否を確認して判断します。この情報が不足していたり、内容が一般的だったりすると反応につながりません。あわせて送信対象が自社の訴求と噛み合っているかも確認してください。

Q：スカウトはどのくらいの長さが適切ですか？
A：冒頭で「なぜあなたなのか」を伝えたうえで、自社の課題と期待する役割が伝わる範囲に収めます。会社概要や事業の詳細は求人票に委ねてください。候補者は興味を持てば求人票を確認するため、スカウトですべてを説明する必要はありません。

タレントプールと中長期の関係構築

LAPRASの強みのひとつが、今すぐ転職しない候補者を将来の採用につなげられる点です。母集団が限られるエンジニア採用において、この蓄積が成果を左右します。

「今は転職できない」で終わらせない

通常の採用媒体では、「今すぐ転職できますか」という確認に対して「できません」という回答があった時点で、その候補者との接点は終わります。

LAPRASでは次のように設計します。

接点を作る
↓
今は転職できないと分かる
↓
タレントプールに残す
↓
関係を維持する
↓
転職意欲が変化する
↓
再アプローチする

導入企業の事例では、母数が非常に少ないポジションで条件に合う候補者と接点を作ったものの、その候補者は大規模プロジェクトに参加中ですぐには転職できない状況でした。

同社は接点を切らずにコミュニケーションを継続し、最初の接点から4か月後に応募意思を獲得。その候補者は他社の選考を受けずに入社しています。

再アプローチを前提とした運用設計

LAPRASの運用ガイドでも、母集団が限られるエンジニア採用では再アプローチを前提とした中長期の採用が不可欠と明記されています。初回面談前の再アプローチと、面談後の関係構築の両方が運用として用意されています。

再アプローチの例

3月：スカウトを送る
↓
返信なし
↓
6月：新機能をリリース
↓
「以前お声がけしましたが、〇〇の技術課題が増えてきたため改めてご連絡しました」
↓
9月：候補者の転職意欲が上がる
↓
あらためてカジュアル面談を打診する

同じ文面を再送しない

再アプローチで重要なのは、接触する理由を新しく作ることです。

接触理由になる変化

変化の主体	具体例
自社側	新機能のリリース・資金調達・新しい技術課題・組織体制の変更
候補者側	転職意欲の変化・所属企業の変更・新しいアウトプットの公開

毎回同じ文面を送るのは催促にしかなりません。会社側か候補者側に新しい変化が生じたタイミングで、その内容を接触の理由として伝えます。

タレントプールを「送信済みリスト」にしない

タレントプールは候補者を状態別に整理する場です。単にスカウトを送った候補者の一覧として使うと、機能を活かせません。

分類の例

• 今すぐ会いたい候補者
• 興味通知を送った候補者
• 「興味あり」が返ってきた候補者
• 今すぐ転職しない候補者
• 面談済みの将来候補
• 転職意欲の変化を待つ候補者

状態ごとに分けておくことで、次に何をすべきかが明確になります。

転職意欲の変更通知を活用する

タレントプールに保存した候補者の転職意欲が変化した際に通知を受け取れます。

候補者をストックしておけば、動き始めたタイミングを捉えられます。この仕組みがあるため、LAPRASは検索データベースというより、将来採用したいエンジニアを貯めるCRMとして捉えるほうが実態に近くなります。

蓄積が採用の安定につながる

エンジニア採用では、必要なタイミングで条件に合う候補者が転職市場にいるとは限りません。

タレントプールに候補者を蓄積しておくことで、次のような状態を作れます。

• 新しいポジションが発生したときに、すぐに声をかけられる候補者がいる
• 候補者の転職意欲が変化したタイミングを逃さない
• 面談済みで自社を理解している候補者が一定数いる

導入企業のなかには、この運用によって常時50〜60名程度との接点を維持している企業もあります。

よくある質問

Q：タレントプールに保存した候補者へは、どのくらいの頻度で連絡すべきですか？
A：定期的な連絡そのものを目的にすると、内容が薄くなります。会社側か候補者側に変化があったタイミングで連絡するほうが自然です。目安として3か月から半年に一度、伝える内容がある場合に接触するという運用が現実的です。転職意欲の変更通知を受け取ったタイミングも接触の機会になります。

Q：面談したものの選考に進まなかった候補者はどう扱えばよいですか？
A：タレントプールに残し、将来の候補者として管理してください。一度面談をしている候補者は自社を理解している状態であり、まったく接点のない候補者より採用につながる確率が高くなります。組織のフェーズが変わったタイミングや、新しいポジションが生まれたタイミングで再度声をかけてください。

カジュアル面談の設計と数値改善

スカウトで候補者ごとにパーソナライズしたにもかかわらず、面談では全員に同じ会社説明をするという運用では効果が薄れます。個別化を面談まで維持することが重要です。

候補者ごとに話す内容を変える

LAPRASのプロフィールは面談前の準備にも活用できます。

導入企業のなかには、職歴だけでなくGitHub、勉強会での登壇、技術記事を確認し、「この人は何をやりたいのか」「何に興味を持っているのか」を把握したうえでカジュアル面談に臨んでいる企業があります。

同社は候補者一人ひとりに「なぜ来てほしいのか」を繰り返し伝えており、カジュアル面談後の70〜80%が次の選考へ進んでいるとしています。

面談前に確認したい情報

• 直近のアウトプットとその内容
• 参加しているコミュニティ
• 本人が記載している「やりたいこと」
• 転職意欲の状態

これらを踏まえて、その候補者にとって意味のある話題を選びます。

転職意思がない候補者に志望動機を聞かない

潜在層とも接点を持てる媒体であるため、カジュアル面談を一次面接のように運用すると噛み合いません。

今すぐ転職できない候補者に聞くこと

• 現在のキャリアと取り組んでいること
• 今後やりたいこと
• 興味のある技術やプロダクト
• いつ頃なら動けそうか

無理に選考へ進めず、「では数か月後にまたお話ししましょう」と関係を維持できることがLAPRASの強みです。

エンジニアリングマネージャーやCTOを参加させる

技術的な対話ができる人が面談に出ることで、候補者は判断に必要な情報を得られます。人事による会社説明だけでは、技術環境や任せたい役割の解像度が上がりません。

追うべきファネル

候補者検索
↓
タレントプールへの追加
↓
興味通知の送信
↓
興味あり
↓
スカウトの送信
↓
返信
↓
カジュアル面談
↓
選考
↓
内定
↓
承諾

LAPRASの運用支援でも、候補者のサーチ、アプローチの判断、スカウト、再アプローチまで工程別に改善する設計になっています。

ボトルネックの切り分け

状態	疑うべき箇所
興味通知への反応が少ない	求人タイトル・年収や働き方の条件・求人票の内容
「興味あり」は返るがスカウトに返信がない	「なぜあなたなのか」の具体性の不足
返信はあるが面談に至らない	日程調整・提案内容・期待する役割の伝え方
面談は多いが選考へ進まない	アトラクトの内容・採用ペルソナのずれ
選考に進むが承諾に至らない	条件・キャリアの提示・選考スピード

返信率だけを見ていても原因は特定できません。興味通知の段階まで遡って確認してください。

改善は1か所ずつ行う

求人票・興味通知の対象・スカウト文・面談の設計を同時に変更すると、効果の要因を特定できません。

改善の順序

1. 求人票（すべての受け皿・興味通知への反応に直結）
2. 求人タイトルと条件の記載（興味通知への反応）
3. 候補者の選定と読み込みの深さ（返信率）
4. スカウトの冒頭と個別化の内容（返信率）
5. カジュアル面談の設計（選考移行率）
6. 選考プロセスのスピード（承諾率）

LAPRASでは求人票が候補者のファーストビューを構成するため、上流の改善が下流のすべてに影響します。

量を追わずに質を上げる

LAPRAS自身も、ばらまき型の運用やスカウト疲れを課題として捉えています。

送信数を増やすことで数値を改善しようとすると、候補者の読み込みが浅くなり、結果として返信率が下がるという悪循環に陥ります。

量を増やす部分は仕組みや外部支援に寄せ、人は候補者理解と面談に時間を使うという配分が、この媒体の設計に合っています。

よくある質問

Q：どのくらいの期間で成果を判断すべきですか？
A：中長期の関係構築を前提とする媒体であるため、3か月程度では判断材料が不足します。導入企業のなかには最初の3か月を求人票の改善に充てた例や、最初の接点から4か月後に採用が決まった例があります。半年程度を前提に評価し、その間は興味通知への反応率と面談数を確認しながら改善を重ねてください。

Q：面談数は増えているのに採用に至りません。
A：面談での伝え方とターゲット設定を確認してください。候補者の関心や志向を踏まえた話ができているか、任せたい役割を具体的に伝えられているかが影響します。またターゲット自体が自社の提示条件と噛み合っていない可能性もあるため、面談に来た候補者の傾向から採用要件を見直すことも有効です。

まとめ

LAPRASは、職務経歴だけでなくGitHubや技術記事といった公開アウトプットから候補者を理解し、興味通知を起点に中長期の関係を築いていくサービスです。大量にスカウトを送って確率で当てる運用とは、設計思想が根本的に異なります。

押さえておきたい要点

• 職歴に加えてGitHub・Qiita・Zenn・登壇履歴などから候補者を理解できる
• 「何をやってきたか」だけでなく「最近どこへ向かおうとしているか」まで読む
• AIスキルハイライトは見落としを減らす入口。最終判断は人が行う
• 求人票が候補者のファーストビューを構成する。スカウトより先に作り込む
• 興味通知で一次接触し、反応があった候補者に個別スカウトを送る
• 求人への「興味あり」は最優先。1週間以内を目安に面談を案内する
• スカウトの冒頭は会社紹介ではなく「なぜあなたなのか」から書く
• 実際に読んだアウトプットの内容に触れることがパーソナライズになる
• 今すぐ転職しない候補者はタレントプールに残し、変化を接触理由にする
• 人事が探し、エンジニアが1〜2行の着眼点を提供し、人事が文面を仕上げる
• 量を追わず、候補者理解と面談に時間を使う

候補者側にも企業の閲覧行動が見える設計であるため、丁寧に候補者を見る企業ほど有利になります。工数の確保が難しい場合は、BPaaSプランや採用代行の活用も選択肢になります。

経営幹部・重要ポジションの採用ならGrowth Talentへ

LAPRASはエンジニアの採用に強みを持つ一方、CTOやVPoEといった技術組織の責任者、あるいはCxOクラスの採用では母集団が限られます。経営に近いポジションには、その層に特化したチャネルを併用することが有効です。

Growth Talentは、スタートアップ・ベンチャー企業のCxOクラス・経営幹部・事業責任者などの重要ポジションに特化した求人プラットフォームです。成長企業で経営に関わることを前提にキャリアを考えている層が登録しており、事業フェーズへの理解がある候補者と出会えます。

このような採用ニーズに適しています

• CTO・VPoEなど技術組織を統括する人材を採用したい
• CFO・COOなどCxOクラスのポジションを募集している
• 事業責任者・部門責任者など経営に近いポジションを探している
• エンジニアメンバーの採用と並行して、技術責任者の採用も進めたい

採用の運用体制にお悩みなら採用支援サービスへ

「候補者の読み込みに時間を割けない」「エンジニアを採用に巻き込めない」といった課題は、多くの企業に共通するものです。

Growth Talentを運営する株式会社Interiorでは、採用要件の設計から媒体選定・求人票の改善・スカウト運用まで、採用活動を包括的にサポートする採用支援サービスを提供しています。