HubSpotで求人を管理する方法｜求人票をカスタムオブジェクトで扱う設計

——「求人票はスプレッドシート、選考の進捗だけHubSpotの取引で管理しています」

——「同じ求人に3人応募したら、取引が3件できて、求人の情報も3回コピーされました」

人材紹介・人材派遣の会社でCRMの設計を見ていくと、この2つはかなりの確率で出てきます。取引（案件）のプロパティーに求人情報を持たせる形は最初こそ問題なく回るのですが、事業が伸びるとある一点で急に苦しくなります。その分岐点は、同じ求人を2人目の求職者に提案し始めた瞬間です。

結論から言うと、1つの求人に複数の求職者を並行して動かすようになった時点で、求人は取引のプロパティーではなく独立したレコード（HubSpotではカスタムオブジェクト）として持つ設計に切り替えるのが素直です。逆に、求人が数十件で1求人あたり1名しか動かさないのであれば、無理に作る必要はありません。

この記事では、以下の4点を実装レベルで整理します。

人材紹介・人材派遣でHubSpotの求人管理を設計する方、求人票がスプレッドシートに残ったままの方に向けた内容です。

• 限界の見極め方 ── 求人を取引のプロパティーで持つと、どの業務から先に壊れるのか
• プロパティー設計 ── 何を持たせ、どの型を選ぶか（後から変えられないものは何か）
• 関連付けと運用 ── 会社・取引・人事担当・求職者をどうつなぎ、締切をどう自動で閉じるか
• やらない判断 ── カスタムオブジェクトを使わない方がいいケースの条件

読み終える頃には、自社が求人をカスタムオブジェクトに切り出すべきか、切り出す場合に何をどの型で持つかが判断できるはずです。ぜひ最後までご確認ください。

なお本記事の設計例は、HubSpotのデモアカウントで再現した構成と、人材業界で一般的に見られる課題をもとにしたものです。特定の企業の実装内容ではありません。

求人を「取引のプロパティー」で持つと、どこで詰まるか

なぜ多くの会社が求人を取引のプロパティーで持つところから始めるのか、そしてそれがどこで限界を迎えるのか。ここを飛ばして「とりあえずカスタムオブジェクトを作りましょう」と進めると、使われない箱だけが残ります。

最初は取引のプロパティーで十分に回る

担当者が数名の段階では、求人情報を取引のプロパティーとして持つ設計は合理的です。取引レコードに「求人企業名」「職種」「想定年収」「勤務地」を並べておけば、1画面で選考の状況と求人の中身が両方見えます。

この状態で困っていないなら、変える必要はありません。項目もオブジェクトも少ない方が現場は集中できます。先回りして構造を複雑にすると、たいてい入力されなくなります。

詰まるのは「同じ求人を2人目に提案した瞬間」

取引を求職者ごとに作ると、同じ求人情報が取引の数だけコピーされます。求人企業から「年収レンジを上げます」「募集人数を2名に増やします」と連絡が入るたびに、関係する取引をすべて探して直す必要が出てきます。3件ならまだ追いつきますが、10件になると必ず直し漏れが発生します。

——「古い条件のまま求職者に提案してしまった」

人材紹介でいちばん起きてほしくない事故ですが、構造的にはデータの持ち方が原因です。1つの事実が複数の場所に複製されている限り、人の注意力では防げません。

実務で詰まる4つの場面

とくに2番目は見落とされがちです。取引は選考が始まって初めて作られるものなので、取引だけを持っている限り、求人のデータベースにはなりません。ここが結構ミソになってきます。

回避策として求人だけスプレッドシートで持つ運用もよく取られますが、今度は情報の分散という別の問題に変わります。オブジェクト単位の考え方は人材紹介CRMのデータ設計で整理しています。

求人を独立したレコードにすると何がつながるか

求人を独立したレコードにすると、単に一覧できるようになるだけではなく、求人が他のレコードをつなぐハブになるという変化が起きます。

求人を中心に4方向がつながる

求人レコードは、それ自体が「募集条件という事実」を1か所で保持します。そのうえで、求人企業（会社）、選考（取引）、先方の人事担当（コンタクト）、応募している求職者（コンタクト）の4方向に線が伸びます。求人条件を直す場所が1つになるので、先ほどの直し漏れは構造的に起きなくなります。

求人と選考は別のものだと切り分ける

設計の前に整理しておきたいのが、「求人」と「選考」は別の概念だという点です。求人は企業側の募集という事実で、選考は特定の求職者がその求人に進んでいるプロセスです。

この2つを1レコードに混ぜると、必ずどちらかが不自然になります。求人にステージを持たせると1人目の選考しか表現できませんし、選考に求人条件を持たせると複製問題が起きます。求人＝カスタムオブジェクト、選考＝取引（パイプラインを持つ）と役割を分けるのが素直な形です。

HubSpotでは「カスタムオブジェクト」がその器になる

標準のコンタクト・会社・取引・チケット以外の独自レコードを持つための仕組みが、カスタムオブジェクトです。求人・物件・契約といった、業種固有のマスターデータを扱うために使います。ここで必ず確認が必要なのがプラン要件です。

公式ナレッジベースでは、カスタムオブジェクトは各HubのEnterpriseプランで利用可能と明記されています（出典：HubSpotナレッジベース「カスタムオブジェクトを作成する」／2026年8月1日確認）。同ページには「契約内容によっては、使用できるカスタムオブジェクトとプロパティーの数に上限があります」とも記載されており、上限の数値は契約により異なります。作るべきかどうかの判断軸はカスタムオブジェクトを使うべきかにまとめています。

求人オブジェクトに持たせるプロパティーの設計

構造が決まったら、次は何を持たせるかです。ここは多いほどいいのではなく、入力され続ける数に絞る方が結果的に使えるデータベースになります。

デモ環境で組んだ求人レコードの構成

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

この例では、求人名が「人事採用担当」、企業名が「北海道フードテック株式会社」、掲載ステータスが「募集中」、雇用形態が「正社員」、募集人数が「1」、勤務エリアが「札幌」、職種が「人事」、稼働日数が「週5日」となっています。左サイドバーに並ぶこの構成が求人レコードの中身です。

なお画面中央で条件を指定して求職者を検索している部分は、当社がデモ環境に作り込んだ拡張機能であり、HubSpotの標準機能ではありません。マッチングを運用にどう落とすかは候補者と求人のマッチング運用で扱っています。

最小構成として持たせたい項目

項目は「検索と集計に使うもの」から決めます。逆に、検索も集計もしない情報はテキストエリア1つにまとめて構いません。

10項目前後が目安です。「歓迎スキル」「選考フロー」「面接回数」なども足したくなりますが、増やすほど登録が止まるので運用が回り始めてから足す方が安全です。粒度や命名はプロパティー設計のベストプラクティスを参照してください。

フィールドタイプの選び方で失敗する典型例

いちばん効いてくるのがフィールドタイプの選択です。ここを外すと、後から検索も集計もできないデータの山ができます。

第一に、年収を1行テキストで作るケースです。「400〜550万円」「応相談（500万前後）」といった値が入り、「年収500万円以上の求人」という範囲検索ができません。下限と上限を分けて数値型で持つのが基本です。

第二に、職種を自由記述で作るケースです。「人事」「人事採用」「HR」「採用担当」が混在し、職種別の求人数も決定数も集計できません。ドロップダウン選択にして選択肢を管理します。

第三に、応募締切日をテキストで持つケースです。「月末まで」「随時」が入り、後述する締切ベースの自動化が組めなくなります。「随時」は締切日を空にして掲載ステータス側で表現する方が扱いやすくなります。

後から型は変えられないという前提で組む

公式ナレッジベースには、プロパティーのオブジェクトタイプまたは内部名は編集できないこと、フィールドタイプを編集して「スコア」または「計算」にすることはできず、これらのタイプを別のフィールドタイプに編集することもできないこと、さらに「フィールドタイプを変更すると、プロパティーに保存されている現在の値が無効になることがあります」と記載されています（出典：HubSpotナレッジベース「プロパティーを作成および編集する」／2026年8月1日確認）。

一方で選択肢の追加や表示ラベルの変更は後からでも柔軟にできます。「型は慎重に、選択肢は気楽に」と考えるのが実務的です。

関連付けの設計

求人レコードを作っただけでは、まだデータベースにはなりません。他のオブジェクトとどうつなぐかを決めて初めて業務が回り始めます。

求人↔会社と求人↔取引

求人と会社は、1社が複数の求人を持つ「1対多」です。注意したいのは大企業やグループ企業の扱いで、先に会社の粒度（法人単位か事業所単位か）を決めてから求人を紐づけるのが順番として正しく、逆にすると後で全件付け替えになります。

求人と取引も「1対多」です。求人1件に対し、選考中の求職者ごとに取引が1件ぶら下がり、求人レコードを開けば「今何名が動いていて、それぞれどのステージか」が見えます。取引側のパイプラインは、書類選考 → 一次面接 → 最終面接 → 内定 → 入社 のように選考の進行そのものをステージにします。

求人↔コンタクトは関連付けラベルで分ける

求人には2種類のコンタクトが関わります。求人企業側の人事担当と、提案対象の求職者です。この2つを同じ関連付けとして扱うと、右サイドバーで混ざってどちらか分からなくなります。

そこで使うのが関連付けラベルです。公式ナレッジベースによると、関連付けラベルは各HubのProfessional以上で利用でき、1つのオブジェクトペアにつき最大50個のラベルを作成できます（出典：HubSpotナレッジベース「関連付けラベルの作成と使用」／2026年8月1日確認）。

3つ目は人材派遣や業務委託で効いてきます。契約する会社と実際に働く場所が違うケースを、ラベルなしで表現しようとすると必ず無理が出ます。ただしラベルは作りすぎると誰も選ばなくなるので、まずは2つ程度から始めるのが現実的です。

掲載ステータスと締切をどう運用するか

求人データベースが失敗する原因は、設計よりも運用にあります。もっとも多いのが、閉じられない求人が溜まっていくという現象です。

ステータスは3つで足りる

掲載ステータスは細かく分けたくなりますが、まずは「募集中（提案対象に含める）」「保留（企業都合で一時停止・再開の可能性あり）」「募集終了（充足・取り下げ・期限切れ）」の3つで十分です。

終了理由を分析したい場合は、ステータスを増やすのではなく「終了理由」という別のプロパティーを持たせます。ステータスに理由まで混ぜると選択肢が10個を超え、現場が選べなくなります。ステータスは状態、理由は別プロパティーという切り分けが結構ミソになってきます。

「閉じられない求人」が溜まる理由

求人が閉じられないのは担当者の怠慢ではありません。企業側から「もう終わりました」という連絡が来ないケースがほとんどだからです。決まったポジションの連絡は来ても、「結局採用しないことになった」という連絡は来ません。

その結果、半年前に終わった求人が「募集中」のまま残ります。求職者に提案してから「その求人はもう終わっています」と言われるのは、信頼を大きく損ないます。

応募締切日でワークフローを回す

これは人ではなく仕組みで解決します。HubSpotのワークフロー（各HubのProfessional・Enterpriseで利用可能／出典：HubSpotナレッジベース「ワークフローを作成する」／2026年8月1日確認）を使い、応募締切日を起点に3段構えで組みます。

1. 応募締切日の7日前に、担当者へ「この求人はまだ募集中ですか」という社内通知またはタスクを作成する
2. 応募締切日を過ぎた時点で、掲載ステータスを自動的に「保留」に変更する
3. 保留になってから14日動きがなければ「募集終了」に変更する

いきなり「募集終了」にしないのがポイントです。締切を延長しただけの求人まで消えると、現場から「勝手に閉じられる」という不満が出て、結局ワークフローが止められます。組み方はHubSpotワークフローの設定を参照してください。

正直に書いておくと、これだけで鮮度が完全に保たれるわけではありません。締切日を入れずに登録された求人はワークフローに乗りませんし、「随時」の求人も同様です。締切日が空の求人は「最終更新日から60日経過」で別のワークフローを回すか、月次で棚卸しする運用を併用します。すべてをシステムで解決しようとしない割り切りが必要な領域です。

求人データをどう入れるか

設計とワークフローができても、データが入らなければ意味がありません。登録経路は大きく3つに整理できます。

企業からの依頼をフォームで受ける

もっとも精度が高いのが、求人企業に直接フォームから依頼を出してもらう方法です。職種・勤務地・雇用形態・想定年収・募集人数・応募締切日を、求人レコードのプロパティーと同じ選択肢で作ります。

フォーム送信で直接カスタムオブジェクトのレコードを作れるかは契約や設定によって挙動が変わるため、実務ではフォーム送信をトリガーにワークフローで作成する形が現実的です。企業側に入力してもらう項目は5〜7個までに絞ると回収率が変わります。

初期データはインポート、媒体連携は後回しでよい

すでにスプレッドシートで管理している場合、初期移行はインポートで行います。気をつけたいのは次の3点です。

• 求人IDを1列作る：既存シートの管理番号をユニーク値として持ち込むと、後から差分更新（上書きインポート）ができます
• 職種・エリアの表記を先に統一する：インポート後にドロップダウンへ寄せるのは手間なので、シート側で名寄せしてから入れます
• インポート前にワークフローを止める：締切日ベースのワークフローが動いていると、過去の求人が大量に「募集終了」になったり通知が飛んだりします

求人媒体やATS（採用管理システム）から取り込みたい場合、HubSpot側はAPIで受け取れますが、自動連携の難易度は媒体側の仕様に完全に依存します。まずはインポート運用で回し、手作業が耐えられなくなった段階で連携を検討する順番をおすすめします。

必須項目は5つ以内に抑える

登録経路を整えても、入力項目が多いと現場は止まります。求人名・企業・職種・勤務エリア・掲載ステータス。この5つがあれば「提案できる求人を探す」という最重要の用途は成立します。

年収や業務内容は選考が始まるタイミングで埋めれば十分です。取引のステージ移行時に必須入力を設定するのと同じ考え方で、必要になった段階で必要な情報を求める方がデータは埋まります。

求人単位で取れるようになる数字

求人を独立したレコードにした最大の見返りは、それまで数えられなかった数字が取れるようになることです。

カスタムオブジェクトも標準オブジェクトと同じように扱える

カスタムオブジェクトは、コンタクトや取引と同じように一覧ビューを作り、フィルターをかけ、レポートの対象にできます。求人オブジェクトで用意しておきたいビューを整理すると、次のようになります。

「募集中かつ職種＝人事かつ勤務エリア＝札幌」のビューを保存しておけば、提案候補を探す作業がワンクリックになります。スプレッドシートのフィルターと見た目は似ていますが、裏で選考の取引や求職者のコンタクトとつながっている点が決定的に違います。

求人単位で見たい4つの指標

滞留日数は計算プロパティーで作るのがおすすめです。ワークフローで毎日日数を書き換える形にすると実行回数が膨らみますし、更新タイミングによって値がずれます。こうしたものはワークフローに頼らない方が安定します。

数字を「見る会議」まで設計する

指標を作っただけでは運用は変わりません。求人一覧のダッシュボードを作り、週次で「滞留60日以上の求人」「応募ゼロの求人」を確認する場を決めるところまでがセットです。ダッシュボードは営業会議用・企業開拓（RA）用・求職者対応（CA）用のように用途を絞ると、見られる確率が上がります。

カスタムオブジェクトを使わない方がいいケース

ここまで求人カスタムオブジェクトの設計を書いてきましたが、全社に勧められる構成ではありません。使わない方がいいケースをはっきり書いておきます。

求人が数十件で、1求人1名しか動かさない場合

もっとも重要な判断基準がこれです。同時に扱う求人が数十件で、1求人に1名しか提案しないなら、求人は取引のプロパティーで持つ方がシンプルで速いです。オブジェクトを増やすと入力画面が増え、関連付けの操作が増え、権限設計も増えます。

目安としては、同時進行の求人が100件を超えるか、1求人あたり平均2名以上を提案しているかどうかが分かれ目です。当てはまらない段階では、まず取引のパイプラインを整える方が効果が大きくなります。

プランがEnterpriseでない場合／文書管理が目的の場合

前述のとおりカスタムオブジェクトはEnterpriseプランの機能です。求人管理のためだけにEnterpriseへ上げる判断は、他に必要な機能（権限セット、サンドボックス、レポート上限など）とあわせて考えるべきものです。Professionalの範囲で近いことをするなら、取引を「求人パイプライン」と「選考パイプライン」の2本に分けて関連付ける方法がありますが、運用負荷は上がります。

また「求人票のPDFを整理したい」という目的なら、カスタムオブジェクトは最適な道具ではありません。効くのは、その情報を軸に検索・集計・自動化をしたいときです。

「やらない判断」も設計のうち

いきなり完成形を作るより、まず取引のパイプラインとプロパティーを整え、件数が増えて明確に痛みが出てから求人オブジェクトを切り出す方が定着します。企業様によって最適な形は異なりますので、自社の求人件数・提案の並行度・プランを踏まえて決めることが結構ミソになってきます。人材業界全体での使い方は人材業界のHubSpot活用法にまとめています。

よくある質問

求人をカスタムオブジェクトで扱う際に、設計の判断が分かれやすい5つの論点を整理します。

Q1. 求人カスタムオブジェクトはどのプランで使えますか

公式ナレッジベースでは、カスタムオブジェクトは各HubのEnterpriseプランで利用可能と記載されています（出典：HubSpotナレッジベース「カスタムオブジェクトを作成する」／2026年8月1日確認）。同ページには、契約内容によって使用できるカスタムオブジェクトとプロパティーの数に上限があるとも記載されており、具体的な数値は製品・サービスカタログでの確認が必要です。

Q2. 求人と選考を1つの取引にまとめてはいけませんか

1つの求人に1名しか提案しないのであれば、まとめても問題ありません。分ける必要が出るのは、同じ求人に複数の求職者を並行して進める段階です。まとめたままだと求人条件が取引の数だけ複製され、条件変更時に直し漏れが発生します。「同じ情報を2か所以上に書いているか」が判断基準になります。

Q3. 求人のプロパティーは後からフィールドタイプを変更できますか

制約があります。公式ナレッジベースには、オブジェクトタイプまたは内部名は編集できないこと、「フィールドタイプを変更すると、保存されている現在の値が無効になることがあります」と記載されています（出典：HubSpotナレッジベース「プロパティーを作成および編集する」／2026年8月1日確認）。年収を数値で持つか文字列で持つかは、最初に決めておくのが安全です。

Q4. 関連付けラベルはどのプランで使えますか、いくつまで作れますか

公式ナレッジベースによると、関連付けラベルは各HubのProfessional以上で利用でき、1つのオブジェクトペアにつき最大50個まで作成できます。ペアになっているラベルは、上限をカウントする際に1つとして数えられます（出典：HubSpotナレッジベース「関連付けラベルの作成と使用」／2026年8月1日確認）。

Q5. 募集が終わった求人を自動で閉じることはできますか

応募締切日を日付型のプロパティーで持たせておけば、ワークフローで自動化できます。ワークフローは各HubのProfessional・Enterpriseで利用可能です（出典：HubSpotナレッジベース「ワークフローを作成する」／2026年8月1日確認）。ただし締切日を過ぎた瞬間に「募集終了」にすると、延長された求人まで消えてしまうため、通知 → 保留 → 募集終了の段階的な設計にするのが安全です。締切日が入っていない求人はワークフローに乗らないので、月次の棚卸しで補います。

まとめ

求人をHubSpotで管理する設計について、判断のポイントを整理します。

• 切り替えの分岐点は「同じ求人を2人目に提案した瞬間」 ── 求人条件が取引の数だけ複製され始めたら、独立したレコードに切り出すタイミングです
• 求人と選考は別の概念として分ける ── 求人＝カスタムオブジェクト（募集という事実）、選考＝取引（求職者ごとのプロセス）
• フィールドタイプは最初に決める ── 年収は数値で下限・上限に分け、職種はドロップダウンにする。型は後から変えると値が壊れる可能性があります
• 求人が閉じられない問題は仕組みで解く ── 応募締切日を起点に、通知 → 保留 → 募集終了の3段階でワークフローを回します
• やらない判断も設計のうち ── 求人が数十件で1求人1名なら、取引のプロパティーで十分です

最初の一歩は、いきなりカスタムオブジェクトを作ることではありません。まず、いま抱えている求人の件数と、1求人あたり平均何名を提案しているかを数えてみることです。この2つの数字が、求人オブジェクトを作るべきかどうかをほぼ決めます。作ると決めたなら、プロパティーは10項目前後、必須は5項目以内から始めるのが定着しやすい形です。

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