求人サイト・マッチングサイトの構築とは？開発手法・費用とIndeed連携、法規制を解説

求人サイトの構築とは、求人企業と求職者という二種類のユーザーを引き合わせるマッチングサイトを、必須機能・法規制・求人検索エンジンへの連携・運用体制まで含めて形にする開発プロジェクトです。この記事では、マッチングサイトと求人ポータルの仕組みとビジネスモデル、会員登録から決済・評価までの必須機能を押さえたうえで、求人サイト専用パッケージ・ASP・スクラッチの選び方と、初期費用だけでなく3年総額で見た費用相場を整理します。後半では、Googleしごと検索とIndeedに求人を載せるための実装要件、2022年10月施行の改正職業安定法で求人サイトに課された届出と的確表示、立ち上げ初期に直面する二面市場の壁と公開後の運用体制を示します。

まとめ：求人サイト構築の全体像と、手段選定から運用まで成否を分ける論点

マッチングサイトは、提供者と利用者という二つのユーザー層を抱える二面市場のプラットフォームです。求人ポータルなら求職者と求人企業、スキルシェアなら発注者と受注者というように、性質の異なる二者をシステム上で結びつけます。構築では、会員登録・検索・メッセージ・決済・評価・管理画面という必須機能をそろえ、扱うジャンルに応じた法規制への対応を設計段階で織り込みます。

開発手法はフルスクラッチ・パッケージ・CMS・ノーコードの四つに整理でき、求人サイトではこれに月額制のASP（SaaS型の求人サイト作成サービス）が加わります。費用は数十万円から数千万円まで開くため、初期費用ではなく3年間の総額で比べるのが筋です。

求人サイトに固有の論点は二つあります。一つは集客の大部分を占めるGoogleしごと検索とIndeedへの連携で、構造化データやフィードの要件を満たさないと求人が表示されません。もう一つは職業安定法で、会員登録やメール配信で求職者の情報を集める求人サイトは厚生労働大臣への届出が必要です。システムを作れば利用者が集まるわけではなく、どちらのユーザーもいない状態から一方を先に集めるコールドスタート問題が事業の成否を大きく左右します。以下で、手段・費用・連携・法規制・運用体制の順に具体化します。

マッチングサイト・求人ポータルとは：二面市場の仕組みとジャンル別の収益モデル

まず、マッチングサイトがどんな仕組みで成り立ち、どう収益を上げるのかを押さえます。

二面市場という仕組みと、求人ポータルが通常のWebサイトと違う点

マッチングサイトとは、何かを提供したい人と、それを求める人をインターネット上で引き合わせるWebサービスです。仲介役としてプラットフォームが両者の出会いと取引を仲立ちし、成約手数料や掲載料、月額会費などで収益を得ます。求人ポータルはこのマッチングモデルの代表例で、求人を出したい企業と仕事を探す求職者をつなぎ、応募や採用の成立を支えます。提供者と利用者という二つの市場を同時に成立させる必要がある点が、通常のECサイトや情報サイトとの大きな違いです。自社の求人だけを載せる採用サイトは一方の市場しか持たないため、ここで扱う求人サイトとは構築の論点が別物になります。

主なジャンルと収益モデル：成約手数料・掲載課金・応募課金の違い

マッチングサイトは扱う対象で幅広く分かれます。人材領域の求人ポータルや業務委託マッチング、モノを売買するフリマ・中古品取引、スキルや知識を売買するスキルシェア、企業どうしをつなぐBtoB・ビジネスマッチングやM&Aマッチングなどが代表的です。収益モデルも、成約時に手数料を取る従量課金、掲載企業から得る掲載料・月額課金、応募1件ごとに課金する応募課金、有料オプションによる課金と複数あります。

求人サイトで収益モデルを決めると、システム要件も連動して決まります。掲載課金なら掲載期間の管理と請求、応募課金なら応募の重複判定と不正応募の除外、成功報酬なら採用決定の報告フローが必要です。どのジャンルと収益モデルを選ぶかで、必要な機能と後述する法規制、そして集客の難易度が変わってきます。不動産物件を集約するジャンルでは、掲載課金型と反響課金型で開発要件が分かれるうえ表示規約の制約も加わるため、不動産ポータルサイトの収益モデルと構築費用で個別に整理しています。

マッチングサイトに必要な主な機能：会員・検索から決済・評価・管理画面まで

マッチングサイトは、二者を出会わせてから取引が完了するまでを支える複数の機能で構成されます。求人サイトに絞った機能の全体像は求人サイトに不可欠な機能一覧で網羅しているので、ここでは構築の判断に効く中核機能だけを取り上げます。

会員登録・プロフィール・検索マッチングの基本機能と求人検索の条件軸

中核となるのは、提供者と利用者それぞれの会員登録・プロフィール機能と、条件で相手を探す検索・マッチング機能です。利用者は希望条件で相手を絞り込み、提供者は自分のスキルやサービスを掲載して見つけてもらいます。求人ポータルであれば、職種・勤務地・給与などの条件で求人を検索し、気になる求人へ応募する導線がこれにあたります。相手を的確に見つけられる検索精度は、マッチング率に直結する要素です。

メッセージ・決済・評価・管理画面：取引完了までを支える4機能

出会った二者が取引へ進むには、当事者間のメッセージ機能、料金のやり取りを担う決済機能、そして相互評価・レビュー機能が要点になります。特に金銭が絡むマッチングでは、代金を仲介者が一時預かりし取引完了後に提供者へ渡すエスクロー決済が、トラブル防止に有効です。取引後の評価が蓄積されると、初対面の相手でも信頼を判断でき、二者のマッチングが促されます。運営側には、会員・掲載内容・取引・通報を監視して不正やトラブルに対処する管理画面が必要で、これがサービスの健全性を支えます。

求人サイトの場合、応募を受け取った企業が選考をどう進めるかも設計の対象です。応募データを企業側の採用管理システムへ渡すのか、サイト内で選考まで完結させるのかで開発範囲が大きく変わります。媒体と採用管理システムの連携の型は採用管理システムの比較｜タイプ・媒体連携・料金の軸で比較しています。

求人サイトの構築手段の選定：パッケージ・ASP・スクラッチの向き不向き

マッチングサイトの構築方法は複数あり、必要な独自性と予算で選び方が変わります。求人サイトでは専用パッケージとASPの選択肢が厚いため、汎用の開発手法に加えて両者の違いも整理します。

4つの開発手法（フルスクラッチ・パッケージ・CMS・ノーコード）の特徴

開発手法は大きく四つに分かれます。ゼロから設計するフルスクラッチは自由度が最も高い一方、費用と期間がかさむため、クリーンアーキテクチャのように保守性を重視した設計で、後の仕様変更に耐える構造にしておくと安心です。マッチングサイト向けのパッケージをベースにする方法は、標準機能を土台に不足分だけを追加開発でき、コストと独自性の均衡を取りやすい手法です。WordPressなどのCMSや、StrapiのようなヘッドレスCMSを基盤にする方法なら、掲載コンテンツの管理を作り込みやすく、比較的短期間で立ち上げられます。ノーコードツールは最も安価で速い反面、機能や拡張性に制約が残ります。

求人サイト専用パッケージとASPの違いと、どちらを選ぶかの判断条件

求人サイトに特化した製品は、自社サーバーに導入して改修できるパッケージと、月額料金でサービスを借りるASP（SaaS型）に分かれます。違いはソースコードに手を入れられるかどうかです。

地域や職種を絞った小規模な求人サイトを早く出したいなら、ASPで始めて求人数と応募数の推移を見るのが合理的です。一方で、独自の収益モデル（応募課金や成功報酬の請求）や自社の他システムとの連携が決まっているなら、ASPの設定範囲では収まらないことが多く、パッケージかスクラッチを選びます。ASPを選ぶ場合は、契約前に「解約時に会員・求人・応募データをどの形式で出せるか」を必ず確認してください。移行先へデータを持ち出せないと、事業が伸びた段階で乗り換えられなくなります。

スクラッチを選ぶ条件と、見送ったほうがよい求人サイトの事業規模

スクラッチ開発を選ぶのは、次のいずれかに当てはまるときです。独自のマッチングロジック（スキルや勤務条件のスコアリング）が事業の差別化要因になっている、職業紹介や派遣管理などの基幹業務とデータを一体で扱う、求人件数が数万件規模で検索性能とフィード生成を自前で制御したい、の三つです。

反対に、事業の検証段階で求人数が数百件程度にとどまる、差別化が求人の中身（地域・業界の独自求人）にあってシステム機能ではない、という場合はスクラッチを見送ります。この段階で数千万円を投じても、集客が立ち上がらなければ回収できません。職業紹介の業務管理まで含める判断は、人材紹介システムとは？両面管理の機能・職業安定法の要件と自社開発の判断軸が参考になります。

求人サイトの構築費用と開発期間の相場：初期費用だけでなく3年総額で比べる視点

手法ごとの費用と期間の目安を示したうえで、月額費用と保守費を含めた比べ方を整理します。

開発手法別の費用と開発期間の相場（ノーコードからフルスクラッチまで）

手法ごとの費用と開発期間の相場は、次のように整理できます。あくまで目安で、機能の範囲や会員規模で上下します。

フルスクラッチは費用と期間の幅が大きく、必須機能に絞った小規模なら数百万円台、決済や本人確認、独自マッチングロジックまで作り込むと数千万円規模になります。まず必須機能だけで小さく立ち上げ、反応を見ながら拡張する進め方なら、初期費用を抑えられます。

3年総額で見る求人サイトの費用：月額・連携・保守費を足した比較の仕方

上の表は初期費用だけの比較です。求人サイトは公開後に費用が積み上がるため、3年間の総額で並べ直すと順位が入れ替わることがあります。足し込む費目は次のとおりです。

• ASPの月額利用料（36か月分）と、求人件数やオプションによる加算
• サーバー・ドメイン・SSL証明書・メール配信サービスの費用
• Indeedなどへのフィード連携の開発・保守費（仕様変更への追随を含む）
• 保守運用費（障害対応・OSやライブラリの更新・軽微な改修）
• 集客費（求人検索エンジンへの有料掲載や広告）

見落とされやすいのは最後の集客費で、システム費を上回ることも珍しくありません。初期費用の安さでASPを選んでも、機能不足を補う外部ツールの月額と手作業の人件費が3年で膨らむ例があります。逆にスクラッチは初期費用が重い代わりに、月額の負担は保守費だけです。比べるときは、手段ごとに「初期費用＋月額×36＋改修見込み」を同じ表に置き、事業計画上の3年後の求人件数でも同じ手段で耐えられるかを確かめます。

Googleしごと検索とIndeedへの求人連携：構造化データとフィードの実装要件

求人サイトの流入は、自サイトの検索順位よりも求人検索エンジン経由の比重が大きくなりがちです。ここを構築時に作り込んでおかないと、公開しても求人が求職者の目に触れません。

Google向けJobPosting構造化データの必須項目と募集終了時の処理

Googleの検索結果に表示される求人枠（Googleしごと検索）に載せるには、求人詳細ページにJobPosting構造化データを埋め込みます。Google検索セントラルのJobPosting構造化データのドキュメント（2026年9月時点）では、必須プロパティは datePosted・description・hiringOrganization・jobLocation・title の5つです。構造化データは1件の求人を載せた最も詳細なページに付ける決まりで、一覧ページには付けません。

{
  "@context": "https://schema.org/",
  "@type": "JobPosting",
  "title": "Webアプリケーションエンジニア",
  "description": "<p>自社求人サイトの開発・運用を担当します。</p>",
  "datePosted": "2026-09-28",
  "validThrough": "2026-10-31T23:59",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "株式会社サンプル"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "addressRegion": "東京都",
      "addressLocality": "千代田区",
      "addressCountry": "JP"
    }
  }
}

このJSON-LDを求人詳細ページの <script type=”application/ld+json”> に出力します。求人サイトで事故が起きやすいのは募集終了の処理です。同ドキュメントは、終了した求人を validThrough を過去日にする、ページを削除して404か410を返す、構造化データを外す、のいずれかで取り下げるよう求めています。管理画面で企業が掲載を止めた瞬間にこの処理が走るよう、掲載ステータスと出力を連動させて設計してください。また同ドキュメントは求人URLの通知にサイトマップより Indexing API を推奨しており、求人の登録・更新・終了のたびにAPIを呼ぶ仕組みも構築範囲に含めます。

Indeedへの求人連携：XMLフィードと更新頻度・審査で詰まる箇所

Indeedに求人サイトの求人をまとめて載せるには、求人データをXMLフィードで提供する方法が一般的です。Indeed Partner DocsのJob Sync XMLフィード仕様（2026年9月時点で確認）では、求人ごとに一意の参照番号・求人ページURL・企業名・所在地・職務内容などを要素として持たせ、日本の求人は最低1日1回の更新が求められています。

実装で詰まるのは次の2点です。一つは、フィードの内容と求人詳細ページの表示が食い違うと審査で弾かれる点で、給与や勤務地をフィード専用に加工すると不一致が起きます。フィードは求人ページと同じデータベースから生成し、手で編集しない構成にします。もう一つは、募集を終えた求人がフィードに残り続ける問題です。Googleの構造化データと同じく、掲載ステータスと連動してフィードからも外れる設計にしておけば、両方の求人検索エンジンで鮮度を保てます。有料掲載との関係や連携の申請手順は契約形態で変わるため、構築前にIndeedの窓口で確認しておくと手戻りを防げます。

求人サイト構築前に押さえる法規制と、事業を左右する二面市場の壁

機能と費用の見通しが立っても、法規制と集客設計を見落とすと事業が立ち行きません。ここが構築前に固めておきたい要点です。

ジャンル別に確認する法規制：職業安定法・古物営業法・資金決済法ほか

マッチングサイトは扱う対象によって、順守すべき法律が変わります。求人・人材紹介では職業安定法や有料職業紹介の許可、中古品売買では古物営業法、利用者間で金銭を預かる仕組みでは資金決済法の登録が関わります。有料職業紹介の手数料規制が社内の業務システムの要件をどこまで縛るかは、前述の人材紹介システムの記事にまとめました。加えて、ネット上で商品やサービスを扱う以上は特定商取引法の表示義務があり、会員の個人情報を扱うため個人情報保護法への対応も全ジャンル共通で必要です。該当する規制を初期の要件定義で洗い出さないと、公開後の作り直しや行政指導につながりかねません。専門性の高い領域のため、要件定義から関与できる開発会社と法務の確認を並行させると安全です。

求人サイトに届出と的確表示が必要になる条件（2022年10月施行の改正職業安定法）

求人広告型のサイトは職業紹介の許可こそ不要ですが、無規制ではありません。厚生労働省の令和4年職業安定法改正の解説によれば、2022年10月1日施行の改正で、求人情報や求職者情報を提供する事業は「募集情報等提供事業」として整理され、他サイトからクローリングした求人の提供や転載も対象に加わりました。

システム設計に直結するのは届出の要否です。求職者の情報を集める事業者は「特定募集情報等提供事業者」として厚生労働大臣への届出が必要で、同省のリーフレットは会員登録を求める場合、メールアドレスを集めて配信する場合、閲覧履歴に基づいて情報を出し分ける場合を「届出が必要」な例に挙げています。ここでいう求職者の情報は氏名に限らず、メールアドレスや経歴、閲覧履歴もその対象です。会員機能を持つ求人サイトはほぼ該当し、年に1度の事業概況の報告も求められます。

あわせて、求人情報を正確・最新に保つ措置も義務です。依頼を受けて求人を載せる事業者は、募集終了や内容変更を速やかに通知するよう求人企業へ依頼するか、求人情報の時点を明示します。管理画面に「最終更新日」を表示し、掲載期限を過ぎた求人を自動で非公開にする機能は、この義務を仕組みで支える実装です。さらに2025年4月1日からの新ルールでは、募集情報等提供事業者が求職者に金銭やギフト券を提供することが原則禁止されました。応募でポイントを付与する仕組みを検討している場合は、設計の前に該当するかを確認してください。

コールドスタート問題と、段階的な開発で初期投資を抑える進め方

マッチングサイト最大の難関が、提供者も利用者もいない立ち上げ初期のコールドスタート問題です。求職者がいなければ企業は求人を載せず、求人がなければ求職者も集まらないという、鶏と卵の関係に陥ります。この壁を越えるには、まず片方のユーザーを重点的に集める、特定の地域や職種に絞って濃い密度を作るといった集客戦略を、システムと並行して設計する必要があるのです。求人サイトなら、求人検索エンジンへの連携が求職者側を集める最短経路になるため、初期リリースに含める価値があります。開発面では、最初から全機能を作り込まず、コアとなるマッチング機能だけで小さく公開し、利用状況を見て投資判断を下す進め方が現実的です。どの機能を初期に含め、どこから独自開発すべきかの線引きは、要件定義から実装・保守まで一貫して担えるマッチングシステム開発の視点で詰めると、過剰投資と手戻りを避けやすくなります。

求人サイト公開後の運用体制：求人の鮮度管理と問い合わせ対応を回す役割分担

求人サイトは公開してからが本番で、運用体制の設計が抜けると求人の鮮度が落ち、求人検索エンジンからの評価も下がります。

求人サイト運営に必要な4つの役割と、少人数で回すための自動化の範囲

運営に要る役割は、求人の審査・掲載管理、求人企業の営業とサポート、求職者からの問い合わせ対応、システムの保守の四つです。立ち上げ期は兼務でも回りますが、どの役割も手作業に寄せると求人件数の増加に比例して工数が膨らみます。

そこで構築時に、どこまでを自動化するかを決めておきます。優先度が高いのは、掲載期限切れの求人の自動非公開、構造化データとフィードの自動更新、求人内容の変更履歴の記録の3点です。前の2点は求人検索エンジンと職業安定法の双方の要件を満たし、変更履歴は求人企業との表示内容をめぐる問い合わせに対応する際の根拠です。応募の受け渡しは、企業側が使う採用管理システム（ATS）とのCSV出力やAPI連携を用意すると、営業とサポートの負担が軽くなります。求人サイトの構築から運用を見据えた機能の線引きまでを一体で相談したい場合は、求人サイトシステム開発で要件整理から支援しています。

よくある質問

求人サイト・マッチングサイトの構築で問い合わせの多い論点を、判断の目安とあわせて整理します。

求人サイトの構築費用はどのくらいかかりますか？

開発手法によって大きく変わります。ノーコードやCMSなら数十万円台から、パッケージをベースにした追加開発なら200万〜500万円、フルスクラッチなら300万円から数千万円規模と幅が大きいのが実情です。求人サイトでは初期費用に加えて、ASPの月額、フィード連携の保守、求人検索エンジンへの有料掲載が毎月かかるため、3年間の総額で比べると判断を誤りにくくなります。まず必須機能に絞って見積もると予算の目安を掴めます。

開発期間はどのくらい必要ですか？

必須機能に絞った小規模なマッチングサイトなら3〜4ヶ月、決済や複雑な検索を含む中規模で5〜8ヶ月が一つの目安です。ノーコードやCMSを使えばさらに短縮できますが、独自要件が増えるほど設計と実装に時間がかかります。公開日から逆算し、初期リリースの機能範囲を絞り込んでおくと、期間の見通しが立てやすくなります。

求人ポータルサイトを作るのに資格や許可は必要ですか？

サービスの形態によって変わります。求人情報を掲載して応募へつなぐ求人広告型なら、職業紹介の許可は不要です。ただし、会員登録やメール配信で求職者の情報を集める場合は、2022年10月施行の改正職業安定法により特定募集情報等提供事業者として厚生労働大臣への届出が必要になります。求職者と企業を個別に引き合わせて採用を成立させる職業紹介にあたる場合は、有料職業紹介事業の許可が要ります。どれに該当するかは設計段階で法務や専門家に確認しておくと安全です。

求人サイトはパッケージ・ASP・フルスクラッチのどれで構築すべきですか？

独自性と予算のどちらを優先するかで決まります。地域や職種を絞って早く安く立ち上げたいならASPやパッケージが向いています。独自のマッチングロジックや応募課金の請求、他システムとの連携、大規模な会員数を前提とするならフルスクラッチが選択肢です。多くの場合は、小さく始めて需要を確かめ、事業が伸びた段階で作り込みへ移行する進め方が投資の無駄を抑えられます。ASPを選ぶなら、解約時にデータを出力できるかを契約前に確かめてください。

マッチングサイトを立ち上げれば、すぐに利用者は集まりますか？

すぐには集まらないのが一般的です。提供者と利用者の両方がそろって初めて価値が生まれる二面市場では、どちらもいない立ち上げ初期のコールドスタート問題が避けられません。まず片方のユーザー層を重点的に集める、地域や職種を絞って利用者の密度を高めるといった集客の工夫が要ります。求人サイトならGoogleしごと検索やIndeedへの連携が求職者を集める近道です。公開後の集客と改善を続ける前提で計画を立てると、事業が軌道に乗りやすくなります。

関連記事

• ECサイトの構築・作り方を解説｜5つの方法の選び方と要件定義から公開までの手順——商品を扱うマッチング型サービスの構築手順を比べたい場合に。
• 会員管理システムとは？機能・顧客管理との違いと、Excelから移行する判断基準を解説——求職者・企業の会員基盤を設計したい場合に。
• 予約システムとは？機能・種類・費用と既製サービスで足りない場合の開発判断——面談・面接の日程調整を仕組み化したい場合に。
• 採用サイトとは？作り方・費用相場と制作会社の選び方をWeb制作目線で解説——自社の求人だけを載せる採用サイトとの違いを確かめたい場合に。