人材紹介CRMのデータ設計｜求職者・求人・求人企業を3層でどう持つか

「求職者はCRMに入っているけれど、求人票はスプレッドシートとメールの中にある」

「同じ求人を10人に提案したはずなのに、その求人が何人書類通過したのかが出てこない」

——人材紹介のCRMを入れ替えようとしている企業から、こうした相談をいただくことが多いかなと思います。

人材紹介のCRMは、機能を比較する前にデータ構造を決めることが先です。具体的には、人（求職者）・ポジション（求人）・法人（求人企業）の3つを別々のレコードとして持ち、その組み合わせである「選考」を1件のレコードとして表現するという設計になります。ここを曖昧にしたまま導入すると、入力は増えるのに数字が取れないCRMになってしまいます。

この記事では、HubSpotを前提にしながらも、他のCRMでも通用するデータ設計の考え方を整理します。

人材紹介のCRMをこれから選ぶ方、既存システムからの入れ替えを検討している方に向けた内容です。

• 求人をどこに持つか ── 取引のプロパティーに持った場合に何が起きるかを、入力工数とレポートの両面から具体的に説明します。
• 3層モデルの構造 ── 求職者・求人・求人企業をどのオブジェクトに割り当て、何で関連付けるかを図で示します。
• 選考の表現方法 ── 「求職者 × 求人」を1件の取引にする設計と、そうしない場合の代替案を比較します。
• 業態ごとの違い ── 人材紹介・人材派遣・RPOで必要なオブジェクトがどう変わるかを表で整理します。

読み終える頃には、求職者・求人・求人企業をどの層で持ち、選考をどう表現するかの設計方針が固まるはずです。ぜひ最後までご確認ください。

人材紹介のCRMが破綻する原因は「求人をどこに持つか」を決めていないこと

人材紹介のCRM導入で最初につまずくのは、求職者の管理方法ではありません。求職者はコンタクト（人）として持つ、というところまでは、たいていの企業ですんなり決まります。問題は求人です。

求人は「求人企業に属する情報」でありながら「求職者に紐づけて提案するもの」でもあります。この二面性を持つデータを、既存のオブジェクトのどこかに無理やり収めようとすると、あとから取り返しがつかなくなります。

求人を取引のプロパティーに持つと、同じ求人を10人分入力することになります

よくあるのが、「選考1件＝取引1件」としたうえで、求人名・年収レンジ・勤務地・必須スキルといった求人の情報を、その取引のプロパティーとして持たせるパターンです。一見すると素直な設計に見えます。

ところが、同じ求人に10人の求職者を提案した瞬間に破綻します。求人の情報が10件の取引にコピーされて重複するからです。求人企業から「年収レンジを50万円上げます」「勤務地が本社から支店に変わりました」と連絡が来たときに、10件の取引をすべて開いて直す必要が出てきます。

現実にはそこまで手が回らないので、古い条件のまま残った取引が発生します。そうなると、CRMに入っている求人条件を誰も信用しなくなり、結局スプレッドシートやメールを見に行く運用に逆戻りします。Excel管理から脱却するために入れたはずのCRMが、Excelの二重管理を増やしてしまうわけです。

求人単位の数字が一切取れなくなります

もっと痛いのはレポート側です。求人が独立したレコードとして存在しないと、次のような数字が原理的に出せません。

• この求人に何人推薦して、何人書類通過して、何人決まったのか（求人別の通過率）
• 3ヶ月以上決まっていない求人はどれか（滞留求人の把握）
• 求人企業ごとの平均決定リードタイム
• 職種別・年収帯別の決定率

「求人名」というテキストのプロパティーでグルーピングすればいいのでは、と思われるかもしれません。ただ、表記ゆれ（「営業（法人）」と「法人営業」）が入った時点で集計は崩れます。レポートで軸にしたいものは、プロパティーではなくレコードとして持つ、というのがデータ設計の基本になります。

決めるべきなのは「どの単位でレコードを作るか」だけです

逆に言えば、人材紹介のCRM設計で本当に決めなければいけないのは、機能の有無ではなく「求職者・求人・求人企業・選考のうち、どれを独立したレコードにして、どれをプロパティーで済ませるか」の1点です。

ここさえ決まれば、あとの実装はどのCRMでも大きくは変わりません。プロパティーの粒度をどう決めるかは、プロパティー設計のベストプラクティスも合わせてご覧いただくと整理しやすいかなと思います。

3層で持つという考え方（人・ポジション・法人）

私たちが人材紹介のデータ設計を考えるときは、人・ポジション・法人の3層に分けて整理します。それぞれ更新される頻度も、更新する人も、寿命も違うからです。

求職者は「コンタクト」、求人は「カスタムオブジェクト」、求人企業は「会社」

HubSpotに当てはめると、次のような割り当てになります。

ポイントになってくるのは、求人企業の人事担当者も求職者も、同じコンタクトオブジェクトに入るという点です。同じ人が「求職者」でもあり「発注元の人事担当」でもあるケースは実際に起こるので、無理にオブジェクトを分けず、contact_type（求職者／企業担当者／その他）のような区分プロパティーで分岐させるほうが運用が破綻しにくいです。ビューやリストはこの区分で切り分けます。

求人を独立レコードにすると、更新が1箇所で済みます

3層で持つと、先ほどの「年収レンジが変わった」ケースは求人レコードを1件直すだけで終わります。関連付けられた選考の取引からは、常に最新の求人条件が参照できます。求人企業側の情報（企業規模、選考スピード、就業条件の傾向）も会社レコードに集約されるので、RAが持っている知見が個人のメモではなく会社レコードに溜まっていきます。

担当者が丁寧に入力してくれることを前提にせず、構造のほうで重複入力が発生しないようにするという「仕組み化」の発想です。求人をカスタムオブジェクトで持つ具体的な作り方は、求人をカスタムオブジェクトで管理するで詳しく扱っています。

企業マスターを外部の法人データベースから取り込む構成もあります

3層の考え方を広げると、法人側をさらに階層化する設計もあり得ます。企業・拠点・部署を分けて持ち、それぞれに担当者コンタクトを紐づけ、契約・求人・マッチングの取引を関連付けるという形です。

この図は、企業マスターを自社で手入力するのではなく、外部の法人データベースと連携して取り込む構成例です。全国の法人情報を持つデータベースと接続しておくと、拠点単位でのアプローチ管理や、名寄せ・重複排除の負荷が下がります。

ただし、いきなりここまで作る必要はありません。拠点・部署の階層が要るのは、同一企業の複数拠点と個別に取引している場合です。まずは「企業＝会社レコード1件」で始めて、必要になってから拠点を足すという進め方をおすすめします。

カスタムオブジェクトが使えないプランの場合

正直にお伝えすると、HubSpotのカスタムオブジェクトはEnterpriseプランでのみ利用できる機能です（出典: HubSpot ナレッジベース「カスタムオブジェクトを作成する」 / 確認日 2026-08-01）。Professional以下のプランでは、求人を独立したオブジェクトとして持つことはできません。

その場合の現実的な代替は次の2つです。

1. 求人を「取引」の別パイプラインで持つ：取引オブジェクトを「選考」と「求人（案件）」の2つのパイプラインで使い分ける方法です。取引同士の関連付けができるので、選考の取引と求人の取引を紐づけられます。ただし取引レポートの中で2種類のレコードが混ざるため、必ずパイプラインでフィルターする運用ルールが必要になります。
2. 求人は業界特化ATSに置き、HubSpotには参照キーだけ持つ：既にATSを使っている場合はこちらのほうが素直です。分担の考え方は後述します。

求職者をコンタクトで持つときの設計

求職者をコンタクトに置くこと自体は迷いどころが少ないのですが、プロパティーの持ち方で後々の使い勝手が大きく変わります。

希望条件は必ず選択式で持つのが結構ミソになってきます

面談メモをそのままフリーテキストのプロパティーに貼り付けている運用をよく見かけます。情報としては残るのですが、これでは「年収600万円以上を希望していて、リモート可の求人を探している東京在住のエンジニア」を抽出できません。

マッチングやリスト抽出に使う条件は、ドロップダウン（単一選択）または複数選択のプロパティーで持ちます。目安として、以下は選択式にしておくと後で効いてきます。

選択肢の設計は「多すぎない」ことが大事です。希望職種を100個の選択肢にすると、入力する側が選べなくなります。まずは自社の決定実績の上位20〜30職種でスタートして、運用しながら足していくくらいがちょうどよいかなと思います。

個人情報の取り扱いは「業務の目的の達成に必要な範囲内」が原則です

求職者データは機微な情報を含みます。職業紹介事業者に適用される指針（平成11年労働省告示第141号）では、業務の目的の達成に必要な範囲内で、その目的を明らかにして個人情報を収集すること、そして保管または使用は収集目的の範囲に限られることが定められています。あわせて、人種・民族・社会的身分・門地・本籍・出生地その他社会的差別の原因となるおそれのある事項、思想および信条、労働組合への加入状況は、原則として収集してはならないとされています（出典: 厚生労働省 指針（平成11年労働省告示第141号）（抄） / 確認日 2026-08-01）。

CRM設計の観点で言えば、これは「プロパティーを作る前に、そのデータを何の目的で使うのかを決める」ということです。集められるから集める、という発想でプロパティーを増やさないほうがいいと思います。実務上は、収集目的に必要な項目だけをプロパティー化すること、閲覧権限を分けること（求職者の個人情報を、法人開拓しか担当しないメンバーが見られる必要はありません）、保管期間と削除の運用を決めること、の3点を設計時に決めておくと安全です。

HubSpotであれば、プロパティー単位の権限設定やチーム単位の閲覧制御が使えます。ただしプラン差があるので、必要な制御ができるかは契約前に確認いただくのが確実です。

選考をどう表現するか

3層モデルの中心にあるのが「選考」です。ここをどのレコードで表現するかで、取れる数字が決まります。

「求職者 × 求人」1件を1つの取引にするのが基本形

推奨は、1人の求職者を1つの求人に推薦したら、取引を1件作るという設計です。取引には求職者のコンタクトと、求人のレコードと、求人企業の会社レコードをすべて関連付けます。

こうすると、取引パイプラインのステージがそのまま選考プロセスになります。

ステージごとに確度を持たせておくと、進行中の選考から着地見込み（加重売上）が自動で計算できます。ステージ設計の考え方そのものはHubSpotのパイプライン設計で詳しく解説していますが、人材紹介の場合は「受注率が変わる瞬間」でステージを切るのがポイントになってきます。書類通過と一次面接の間で確度が大きく動くなら、そこは必ず別ステージにします。

求人が独立レコードだと、こういう画面が作れます

求人をレコードとして持っておくと、求人側から求職者を検索する画面が成立します。

※ HubSpotのデモアカウントの画面です。表示されている企業名・氏名・メールアドレスはすべてデモ用のデータです。

※ 画面中央で条件を指定して求職者を検索している部分は、当社がHubSpotの拡張機能（UI Extensions）を使ってデモ環境に構築したものであり、HubSpotの標準機能ではありません。

求人レコードの左側に掲載ステータス・雇用形態・募集人数・勤務エリア・職種といったプロパティーが並び、そのレコードの中から条件に合う求職者を検索してスコア付きで一覧できます。求人がプロパティーの寄せ集めだと、この「求人を起点に人を探す」動線自体が作れません。マッチングの具体的な運用は候補者と求人のマッチング運用で扱っています。

取引名の付け方と、重複推薦の防止

取引名は自動生成のルールを決めておくと運用が安定します。たとえば「求職者名｜求人企業名｜職種」のような形式です。ワークフローで自動的に命名すれば、担当者ごとの表記ゆれがなくなります。

同じ求職者を同じ求人に二重推薦してしまう事故は、求人レコード側から関連する取引の一覧を見られるようにしておけば防げます。ここも「担当者が気をつける」ではなく、画面構造で防ぐという発想です。

選考を取引にしない代替案との比較

すべての企業に取引が最適とは限りません。代替案も含めて整理すると次のようになります。

現場で多いのは1つ目です。ただし大量応募型（1求人に数百人が応募するアルバイト・派遣登録）では取引が膨らみすぎるため、3つ目に近い設計や、業界特化ATSとの併用を検討することになります。

求人企業側のパイプラインを分ける

ここが人材紹介ならではの論点です。求職者側（選考）と法人開拓側は、同じ取引オブジェクトを使っていても、別のパイプラインにするべきです。

ステージの意味も、担当者も、集計単位も違うからです

法人開拓の取引は「求人企業と契約し、求人（与件）を獲得する」プロセスです。ステージは、リード獲得→初回商談→基本契約締結→求人ヒアリング→求人公開、といった流れになります。一方、選考の取引は求職者ごとに動きます。

この2つを1つのパイプラインに混ぜると、次の問題が起きます。

• 取引の総件数や平均金額といった標準レポートが、意味のない合計になってしまいます
• ステージ名が20個近くになり、営業メンバーが使いこなせなくなります
• RAとCAで見たいボードが違うのに、同じボードを見ることになります

RAとCAで分業している組織では、この分離はほぼ必須です。

金額の持ち方も分けます

法人開拓の取引金額は「その企業から見込める年間紹介売上」といった予測値になります。選考の取引金額は「決定時の理論年収 × 手数料率」で、決定して初めて確定します。この2つを同じレポートで合算すると二重計上になるので、レポート側では必ずパイプラインで絞り込む前提で設計します。

パイプラインの本数には上限があります

HubSpotの取引パイプラインは、公開されている製品カタログによるとStarterで最大2本、Professionalで最大15本、Enterpriseで最大100本とされています（出典: HubSpot Product and Services Catalog / 確認日 2026-08-01）。またカスタムプロパティーは1オブジェクトあたり1,000件までです。

Starterで運用する場合は、選考と法人開拓の2本でちょうど枠を使い切る計算になります。将来的に「アルバイト紹介」「エグゼクティブ」など事業別にパイプラインを分けたくなる可能性があるなら、プラン選定の段階で本数を数えておいたほうが安全かなと思います。

人材派遣・RPOではデータモデルがどう変わるか

同じ人材ビジネスでも、業態が変わると必要なオブジェクトが変わります。ここを混同したまま「人材業界向けCRM」として設計すると、必ずどこかで無理が出ます。

3業態の比較

人材派遣で一番違うのは、契約更新が繰り返し発生するという点です。1回の決定で終わる紹介と違い、3ヶ月更新の契約が何度も続きます。そのため、稼働（就業期間）を独立したレコードにして、更新のたびに新しいレコードを作るか、期間プロパティーを持つ設計が必要になります。この考え方はSaaSのMRR管理に近く、人材紹介の設計をそのまま持ち込むと更新管理ができません。詳しくは人材派遣のHubSpot活用をご覧ください。

RPOの場合は、応募者データの所有者が自社ではなく求人企業側にあるという前提が入ります。CRMの設計としては、求人企業ごとに応募者データを分離して見られるようにする（権限とビューの分離）ことが優先になります。

業界特化ATSとHubSpotを併用する場合の分担

すでに業界特化のATSや求人管理システムを使っている企業の場合、すべてをHubSpotに寄せる必要はありません。むしろ、無理に一本化しようとして失敗するケースのほうが多いです。

どちらを「正」にするかを項目ごとに決めます

併用でうまくいくかどうかは、同じ項目を両方で編集できる状態を作らないことにかかっています。項目ごとに更新元（マスター）を1つに決めます。

選考進捗をどちらに置くかが最大の判断ポイントです。ATSに置くなら、HubSpot側には集計に必要な結果だけを同期します（決定日・決定年収・求人ID）。逆にHubSpotに置くなら、ATSは書類の保管庫として割り切ります。両方で進捗を管理しようとすると、必ずどちらかが古くなります。

連携の実装方法

HubSpotとATSの連携は、標準のコネクタがなければ、Data Hubのデータ同期やカスタムコードワークフローでAPI連携を組むことになります。同期の頻度は「1日1回のバッチで足りるか、リアルタイムが必要か」を先に決めておくと、実装の重さが変わってきます。選考の進捗を営業会議でリアルタイムに見る必要がないなら、日次バッチで十分なことも多いです。人材業界全体でのHubSpot活用の全体像は、人材業界のHubSpot活用法にまとめています。

設計を間違えると取れなくなる数字

最後に、データ設計を逆方向から検証する方法をお伝えします。取りたい数字から、必要なレコードとプロパティーを逆算するというやり方です。

指標から必要な構造を逆算する

この表を作ってみると、求人レコードがないと出せない数字が2つあることがすぐ分かります。求人別の通過率と滞留求人です。この2つを経営指標として見たいかどうかが、求人をカスタムオブジェクトにするかどうかの判断基準になります。

ステージの「通過日」を残す設計にしておきます

リードタイムや通過率を出すうえで見落とされがちなのが、各ステージに入った日付です。取引のステージは現在値しか持たないため、「いつ書類通過したか」を後から遡ることができません。HubSpotには各ステージの入退出日を保持する仕組みがありますが、レポートで使いやすい形にしたい場合は、ステージ移行時に日付プロパティーを更新するワークフローを組んでおくのが確実です。

数字は「その時点」で固定して残す

月次のレポートはスナップショットで残しておくこともおすすめします。CRMのレコードは更新されるので、先月時点で見ていた「今月の決定見込み」と、今月末に見る数字がずれることがあります。ダッシュボードの定期配信でPDFを残しておくと、後から「あのとき何を見て判断したのか」を追えます。

よくある質問

人材紹介のCRM設計について、実際にご相談をいただくことが多い論点をまとめました。

Q1. 求職者と求人企業の担当者を、同じコンタクトオブジェクトに入れて混乱しませんか？

区分プロパティー（求職者／企業担当者）を必ず持たせ、ビューとリストをその区分で分ければ実務上の混乱はほとんど起きません。オブジェクトを分けてしまうと、同じ人が両方の立場になったときに二重管理が発生します。むしろメールの配信対象を誤らないよう、区分プロパティーを必須項目にしておくほうが重要です。

Q2. 求人をカスタムオブジェクトにできないプランです。何から始めればよいですか？

まずは選考の取引を正しく作るところからで十分です。求職者・求人企業・選考の3つが正しく関連付いていれば、決定数・単価・リードタイムは取れます。求人別の通過率が本当に必要になったタイミングで、取引の第2パイプラインで求人を持つか、プランを上げるかを検討すればよいと思います。最初から完成形を目指さず、段階的に広げるほうが現場に定着します。

Q3. 選考のステージはいくつくらいが適切ですか？

7〜8個が目安です。受注確度が明確に変わる瞬間だけをステージにします。「求人企業に連絡した」「返信待ち」のような、確度が変わらない状態をステージにすると、営業が動かすだけの作業が増えます。細かい状態はステージではなくタスクやプロパティーで持つのがよいかなと思います。

Q4. すでに数万件の求職者データがあります。全部移行すべきですか？

全件を機械的に移行するより、直近で活動のあるデータと、決定実績のあるデータを優先することをおすすめします。連絡が取れない古いデータをそのまま入れると、リストの精度が下がり、メール配信の到達率にも影響します。移行前に「いつまでのデータを対象にするか」を、個人情報の保管期間の方針と合わせて決めておくと、その後の運用が軽くなります。

Q5. 人材紹介と人材派遣の両方をやっています。1つのポータルで管理できますか？

可能ですが、パイプラインとレポートは必ず分けてください。収益の発生タイミングも管理単位も違うため、混ぜると経営指標が意味をなさなくなります。求職者（コンタクト）は共通で持ちつつ、紹介の選考と派遣の稼働は別のパイプライン、可能であれば別のオブジェクトで管理する設計が現実的です。

まとめ

人材紹介のCRM設計で押さえておきたい点を整理します。

• 求人をどこに持つかを最初に決める。取引のプロパティーに持つと、同じ求人を推薦人数分だけ重複入力することになり、求人別の通過率も滞留求人も見えなくなります。
• 人・ポジション・法人の3層で持つ。求職者はコンタクト、求人はカスタムオブジェクト、求人企業は会社に置き、その組み合わせである選考を取引で表現します。
• 求職者側と法人開拓側でパイプラインを分ける。ステージの意味も担当者も金額の意味も違うため、混ぜると標準レポートが機能しません。
• 業態でモデルが変わる。人材派遣は稼働と契約更新、RPOは求人企業ごとのプロジェクトが中心になります。紹介の設計をそのまま流用しないことが大切です。
• 取りたい数字から逆算して検証する。決定数・単価・リードタイム・求人別通過率を並べ、それぞれに必要なレコードとプロパティーが揃っているかを確認します。

最初の一歩としては、いまExcelやスプレッドシートで管理している項目を書き出し、それが「人・ポジション・法人・選考」のどれに属する情報なのかを仕分けしてみてください。この仕分けができていれば、どのCRMを選んでも設計はぶれません。逆にここが曖昧なまま製品比較を始めると、機能の多さで選んでしまい、運用が始まってから作り直すことになります。

もちろん、最適な形は企業様によって異なります。自社の業態・体制にどう当てはめるかを具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の運用をうかがったうえで、設計の方向性をご提案します。