候補者と求人のマッチングをCRMで運用する｜検索・推薦・記録の設計

「あの求人に合いそうな人、たしか半年前に面談した気がするんですが……」

「担当が変わった瞬間に、どの候補者にどの求人を出したのか分からなくなりました」

——人材紹介の現場でよく聞く話かなと思います。

候補者と求人のマッチングをCRMで運用するとは、希望条件と求人条件を同じ選択肢で構造化し、双方向に検索でき、推薦した事実がレコードとして残る状態をつくることです。マッチングの精度を決めているのは検索アルゴリズムではなく、その手前にある「条件の持ち方」だと考えています。

この記事では、当社がHubSpotのデモ環境に構築したマッチング画面を使いながら、運用に乗せるための設計を順番に説明します。

マッチングが特定の担当者に依存している人材紹介会社の方、候補者データはあるのに使えていないと感じている方におすすめの内容です。

• 属人化の原因は記憶力ではなく設計 ── 条件が自由記述で保存されている限り、誰が担当しても検索できません
• 精度を上げる前に、まず選択式にする ── 検索の改善もAIの導入も、構造化されたデータがなければ効きません
• スコアは正解ではなく「見る順番」 ── 上位10件をどう並べるかの装置として割り切ると運用が回ります
• 推薦を取引として残さないと数えられない ── 通過率も担当者別の傾向も、記録がなければ一生取れません

読み終える頃には、明日から着手できる最初の一歩がはっきりするはずです。ぜひ最後までご確認ください。

マッチングが属人化する本当の理由

マッチングが属人化している会社ほど、「経験の差」や「センス」の問題として語られがちです。ただ、実際に運用を見せていただくと、原因はもっと機械的なところにあることがほとんどかなと思います。

条件が「文章」で保存されているから検索できない

面談メモに「東京か神奈川希望、経理経験5年、年収は480万以上は欲しいとのこと。時短も相談したい」と書かれている状態を想像してみてください。人が読めば分かりますが、システムからは何ひとつ検索できません。「年収480万以上」で絞り込もうとしても、この文章はヒットしないわけです。

この状態だと、候補者を探す方法は「担当者に聞く」しかなくなります。担当者の記憶にある候補者だけが提案の対象になり、面談から3ヶ月経った候補者は事実上いないのと同じ扱いになります。属人化は能力の問題ではなく、検索できないデータ構造がそうさせているという理解が出発点になります。

「情報はある」のに使えない状態が一番もったいない

多くの会社では、情報そのものは十分に集まっています。面談記録もあり、求人票もあり、やり取りの履歴もあります。それでも使えないのは、保存先がバラバラで、しかも形式が揃っていないからです。

Excelの候補者リスト、求人票のPDF、メールの本文、担当者の手元メモ。この4箇所に情報が散っていると、突き合わせる作業自体が仕事になってしまいます。CRMに集約する価値は「入力を強制すること」ではなく、突き合わせの作業を人間からシステムに移すことにあります。

属人化が表面化するタイミング

属人化のコストは、平常時にはほとんど見えません。表面化するのは、だいたい次のような場面です。

いずれも「人の頑張り」で解決しようとすると再発します。仕組みで解決する対象だと考えています。

マッチングを運用に乗せる4ステップ

マッチングの改善というと、いきなり検索機能やAIの話から始まりがちです。ただ、順番を間違えると効果が出ません。当社では次の4ステップの順に整えることをおすすめしています。

4ステップの全体像

順番を入れ替えると効かない

一番よくある失敗は、ステップ1を飛ばしてステップ2から始めることです。条件が自由記述のまま検索機能を作り込んでも、検索対象のデータが揃っていないので結果が返ってきません。「システムを入れたのに使われない」の典型的なパターンかなと思います。

同じ理由で、AIの導入も順番としては最後になります。AIは書かれていない情報を推測してくれるわけではありません。条件が構造化されていない状態でAIを載せても、精度は上がらないというのが正直なところです。

なお、この4ステップの土台になるのは候補者・求人企業・求人のデータ設計です。オブジェクトの持たせ方から整理したい場合は、人材紹介CRMのデータ設計を先にご覧いただくと理解しやすいかと思います。

ステップ1: 希望条件と求人条件を「同じ選択肢」で持つ

マッチングの精度を決めるのは、ここです。検索の作り込みよりも先に、条件の持ち方を直す必要があります。

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

※ この画面は、当社がHubSpotの拡張機能（UI Extensions）を使ってデモ環境に構築したもので、HubSpotの標準機能としてそのまま存在するものではありません。標準機能でできる範囲との切り分けは、この章の最後で整理します。

上の画面では、エリア＝仙台、職種＝経理・財務、働き方＝出社、稼働日数＝週5日、スキルキーワード＝簿記1級／freee／Excel という条件で求人を検索しています。検索結果の10件が、スコア80点・50点・40点……という順に並んでいる状態です。

自由記述をやめて、選択式にする

まず取り組むべきは、面談メモに書かれている条件を選択式のプロパティーに移すことです。エリア・職種・雇用形態・働き方・稼働日数のように、候補が有限のものはすべてドロップダウン（選択肢）にします。年収は上限と下限を数値プロパティーで分けて持ちます。

ここで「選択肢を細かくしすぎない」のがポイントになってきます。職種を200個に分けると、入力する側が選べなくなり、結局「その他」に集まります。最初は20〜30個程度の粒度で始めて、運用しながら足すという進め方が現実的です。プロパティー設計の考え方はプロパティー設計のベストプラクティスにまとめています。

求職者側と求人側で「同じ選択肢」を使う

意外と抜けやすいのが、この点です。求職者の「希望エリア」と求人の「勤務エリア」が別々の選択肢で作られていると、突き合わせができません。求職者側が「東京都」、求人側が「東京23区」だと、文字列としては一致しないわけです。

対応表としては、次のように整理します。

この「同じ選択肢マスターを共有する」という点が、結構ミソになってきます。逆に言えば、ここさえ揃っていれば、検索の実装方法は後から変えられます。

スキルだけは現実的にキーワードで持つ

一方で、すべてを選択式にするのは無理があります。スキルや資格は種類が多すぎて、選択肢に収めきれません。デモ環境でも、スキルは「簿記1級 / freee / Excel」のようなキーワードで持たせて、部分一致で加点する扱いにしています。

正直なところ、このキーワード方式は表記ゆれに弱いです。「Excel」と「エクセル」は別物として扱われます。運用でよく使うキーワードだけは表記を決めておく、といった折衷が必要になってきます。すべてを完璧に構造化しようとせず、効くところから選択式にするのが現実的な進め方かなと思います。

ステップ2: 双方向に検索できるようにする

条件が揃ったら、次は検索です。ここで大事なのは、片方向だけでは運用に乗らないという点です。

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

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

求職者→求人（CA側の動き）

キャリアアドバイザーは、目の前の求職者に対して「今出せる求人は何か」を探します。起点は求職者レコードです。面談直後にその画面から検索できることが重要で、別システムに移動して条件を入れ直す運用になると、まず使われなくなります。

デモ環境では、求職者レコードの中に「求人マッチング」のタブを置いて、そのレコードの希望条件が初期値として入った状態で検索できるようにしています。担当者は必要に応じて条件を緩めたり、エリアだけ広げたりして再検索します。

求人→求職者（RA側の動き）

一方でリクルーティングアドバイザーは、求人企業から依頼を受けて「この求人に出せる人は誰か」を探します。起点は求人レコードです。上の画面では65件がスコア順に並んでいて、上から順に検討していく形になります。

この2方向は、同じデータを別の入口から見ているだけです。だからこそステップ1の「同じ選択肢」が効いてきます。RA・CAの分業体制そのものの設計についてはRA・CA体制とCRMでも触れています。

標準機能でできる範囲と、作り込みが必要な範囲

冒頭でも触れたとおり、ここまでの画面は当社がHubSpotの拡張機能（UI Extensions）を使ってデモ環境に構築したものです。では標準機能だけならどこまでできるのか、正直に切り分けておきます。

標準機能だけでも、実はかなりの部分が実現できます。整理すると次のようになります。

また、求人をカスタムオブジェクトとして持つ場合、HubSpotの公式ナレッジベースでは対象プランが「Marketing Hub Enterprise / Sales Hub Enterprise / Service Hub Enterprise / Data Hub Enterprise / Content Hub Enterprise / Smart CRM Enterprise / Revenue Hub Enterprise」と明記されています（出典: HubSpot ナレッジベース「Create and edit custom objects」、確認日2026-08-01）。

UI拡張機能については、当社が確認した時点で公式の概要ページ（UI extensions overview、確認日2026-08-01）に対象プランの明記が見当たりませんでした。ただ、土台になるカスタムオブジェクトがEnterprise限定である以上、実質的にはEnterpriseプランが前提になると考えていただくのが安全です。導入前には必ず自社の契約プランで利用可否をご確認ください。

求人をどう持つかの判断は、求人をカスタムオブジェクトで管理するで詳しく整理しています。取引やチケットで代替できるケースもあるので、いきなりカスタムオブジェクトを前提にしないほうがいいかなと思います。

スコアの考え方

検索結果に点数が出ていると、どうしても「この点数は正しいのか」という議論になります。ここは最初に立場を決めておいたほうがいい部分です。

スコアは順位づけであって、正解ではない

結論から言うと、スコアは見る順番を決めるための装置です。80点の求人が50点の求人より必ず良いという意味ではありません。65件を上から順に見るときに、可能性の高いものが上に来ていれば役割は果たしています。

この割り切りができていないと、「スコアが実態と合わない」という理由で運用が止まります。マッチングの最終判断は人がするものであって、スコアはその手前で候補を絞るためのものだという共通認識を、最初にチームで持っておくのが結構重要かなと思います。

配点の考え方

配点は業態によって変わりますが、考え方としては「外せない条件」に重く配分します。デモ環境では次のような発想で組んでいます。

満点は100点に揃えておくと、担当者の感覚と結びつきやすくなります。「エリアと職種が両方合っていれば60点前後」といった目安を先に決めてから、細部の配点を埋めていくと組み立てやすいかなと思います。

運用しながら配点を直す

初期の配点は仮置きで構いません。むしろ、3ヶ月ほど運用して「スコア上位から推薦したのに書類が通らない」というパターンが見えてきてから直すほうが、実態に合った配点になります。

見るべきは、スコア帯ごとの書類通過率です。80点以上と50点台で通過率がほとんど変わらないなら、その配点は機能していないことになります。逆に明確な差が出るなら、閾値を決めて「60点未満は原則推薦しない」といった運用ルールにできます。

ステップ3: 推薦した事実を取引として残す

ここが、多くの会社で抜けている工程です。検索して、良さそうな求人を見つけて、求職者に電話して、そこで記録が途切れてしまう。これだと後から何も分かりません。

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

「推薦」を1件の取引にする

デモ環境では、検索結果から推薦を実行すると、求職者と求人を結ぶ取引が1件作られ、双方のレコードに関連付けられます。画面上部に「1件のマッチング取引を作成し、関連付けました」と表示されているのがその通知です。

なぜ取引にするかというと、推薦は「候補者の属性」でも「求人の属性」でもなく、その2つの間に発生した出来事だからです。1人の候補者が5つの求人に推薦されることも、1つの求人に30人が推薦されることもあります。この関係を候補者レコードのプロパティーに書こうとすると、必ず破綻します。

パイプラインのステージ設計

推薦を取引にすると、そのままパイプラインで進捗管理ができます。人材紹介の場合、ステージは選考プロセスに沿って設計するのが自然です。

ステージの定義を1行でも書いておくと、担当者ごとの解釈のブレが減ります。「面接」が日程確定なのか実施済みなのかが人によって違うと、集計した数字が意味を持たなくなるためです。ステージの切り方の考え方はHubSpotのパイプライン設計にまとめています。

記録しないと何が失われるか

推薦を記録していない会社が失っているものは、意外と大きいです。具体的には次の4つが取れなくなります。

• 同じ求人に過去誰を出したか（重複推薦の防止）
• 同じ候補者にどの求人を出したか（提案の履歴）
• 書類通過率・面接通過率（工程ごとの歩留まり）
• 担当者別・求人企業別の傾向（改善のヒント）

しかも、これらは後からさかのぼって作れません。記録を始めた日からしかデータは貯まらないので、完璧な設計を待つより、粗くてもいいので早く記録を始めるほうが結果的に有利になります。

ステップ4: 推薦数・応募数・通過率を数える

記録が貯まれば、集計ができます。ここまで来て初めて、マッチングの改善が「感覚の議論」から「数字の議論」に変わります。

最低限見るべき4つの数字

まずは次の4つから始めるのがいいかなと思います。いきなり20種類のレポートを作ると、誰も見なくなります。

数字から改善箇所を特定する

数字が揃うと、どこを直すべきかが分かります。たとえば応募率が低い場合、原因はマッチングの精度ではなく、求人の見せ方や連絡のタイミングにあるかもしれません。一方で書類通過率が低いなら、条件は合っているのに求人企業が求める経験の質が違う、という可能性が高くなります。

この切り分けができると、ステップ1に戻って「実は年収より通勤時間のほうが決定要因だった」といった発見につながります。4ステップは1回やって終わりではなく、回しながら条件設計を直していくループとして捉えていただくのがいいかなと思います。

AIに任せられる範囲と、任せてはいけない範囲

マッチングの文脈でAIの話が出ないことはまずありません。ここも、できること・できないことを正直に整理しておきます。

Breeze と Agent Hub の現況

HubSpotのAI機能は「Breeze」というブランドで提供されてきましたが、2026年7月23日に発表された内容では、AIエージェントの基盤が「Agent Hub」、エージェントを作るツールが「Agent Builder」という名称で案内されています。公式のニュースリリースでは、両者は「available today in public beta for all Professional and Enterprise customers」と記載されています（出典: HubSpot「Meet Agent Hub and Agent Builder」、確認日2026-08-01）。

製品ページでは「Agent Hub, formerly Breeze Agents」という表記があり、旧称がBreeze Agentsであることが確認できます（出典: HubSpot AI 製品ページ、確認日2026-08-01）。なお、提供されているエージェントの総数は公式サイト内でも表記に幅があるため、本記事では「◯個」という形での断定は避けます。

AIが得意なこと・人間が判断すべきこと

マッチング業務に当てはめると、役割分担は次のように整理できます。

特に「面談メモから条件を抽出して選択式プロパティーの下書きを作る」という使い方は、ステップ1の負担を減らす方向で効きます。ただし、抽出結果をそのまま確定させず、担当者が確認する運用にするのが前提です。条件は推薦の根拠になるデータなので、間違ったまま貯まると後の集計もすべて狂います。

一方で、候補者への最終的な推薦判断をAIに任せるのはおすすめしません。転職は本人の人生に関わる意思決定で、スコアに現れない事情が必ずあります。AIは一流のコンサルタントというより、下調べと下書きを引き受けてくれるアシスタントとして位置づけるのが現実的かなと思います。

よくある質問

マッチングの仕組み化について、実際にご相談をいただくことの多い質問をまとめました。

Q1. Excelでのマッチング管理は、どの規模まで耐えられますか

候補者数が数百名で、担当者が1〜2名なら、Excelでも回ります。厳しくなるのは、担当者が3名以上になって「他人が入力したデータを検索する」必要が出てきたタイミングです。表記ゆれや入力ルールの差が一気に効いてくるためです。人数より「他人のデータを使うかどうか」が分かれ目になります。

Q2. ATS（採用管理システム）を使っている場合、CRMは不要ですか

役割が違うので、併用しているケースも多いです。ATSは応募後の選考管理に強く、CRMは応募前の候補者との関係構築や、求人企業側の営業管理に強みがあります。両方を持つ場合は、どちらを正とするかを先に決めることが重要です。詳しくは人材業界のHubSpot活用法でも整理しています。

Q3. 求人はカスタムオブジェクトにしないといけませんか

必ずしもそうではありません。求人数が少なく、1求人1名の紹介が中心であれば、取引やチケットで代替できる場合もあります。カスタムオブジェクトはEnterpriseプランが前提になるため、まずは既存オブジェクトで設計できないかを検討してから判断するのがいいかなと思います。

Q4. スコアの配点は、最初からどこまで詰めるべきですか

初期は詰めすぎないほうがいいです。エリア・職種・年収の3つに配点して、残りを補助的に扱う程度から始めて問題ありません。実際の書類通過率と突き合わせないと、正しい配点は分からないためです。3ヶ月ほど運用してから見直す前提で置くのがおすすめです。

Q5. 過去の推薦履歴がない状態から始めても意味がありますか

意味があります。むしろ、過去分の入力を頑張るより、今日以降の推薦を確実に記録するほうが効果が出ます。3ヶ月分貯まれば通過率の傾向は見え始めますし、半年あれば担当者別・求人企業別の比較もできるようになります。過去データの整備は、必要になった時点で範囲を絞って行うのが現実的です。

まとめ

候補者と求人のマッチングは、検索機能の性能ではなく、その手前の設計で決まる部分が大きいと考えています。

• 条件が自由記述のままでは、何を足しても検索できません。 まず選択式に移すのが最初の一歩です
• 求職者側と求人側で同じ選択肢マスターを共有します。 ここが揃えば、検索の実装方法は後から変えられます
• 双方向に検索できることで、CAとRAの双方が自分起点で動けます。 片方向だけでは運用に乗りません
• スコアは正解ではなく、見る順番を決める装置です。 通過率と突き合わせながら配点を直していきます
• 推薦を取引として残さないと、通過率も傾向も一生取れません。 記録は始めた日からしか貯まりません

最初の一歩としておすすめしたいのは、面談メモに書かれている条件のうち、選択式にできる項目を5つだけ洗い出すことです。エリア・職種・希望年収・働き方・稼働日数あたりから始めれば十分で、いきなり30項目を設計する必要はありません。そこから求人側の項目と選択肢を揃えていけば、双方向の検索が成立する土台ができます。

自社の業務にどう当てはめるかを具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の運用をうかがったうえで、設計の方向性をご提案します。