求人マッチングシステムの発注は、事業モデルと業務を整理し、RFPで提案条件をそろえることが基本です。契約・開発・運用を段階的に進めると、必要な機能と改善体制を整えられます。
発注形態の選び方、RFPと契約、費用相場、委託先の選定、開発の進め方を、この順に説明します。
▼全体ガイドの記事
・求人マッチングシステム開発の完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
求人マッチングシステムを発注する前に整理すべき全体像
求人マッチングシステムは、求人企業と求職者の情報を蓄積し、条件検索や推薦で両者の接点をつくる業務システムです。機能の一覧だけを伝えると、求人メディアを作るのか、採用管理なのか、人材紹介業務なのかが曖昧になります。そのため、見積もりの前に、誰が誰をどの条件でつなぎ、どの業務までを対象にするかを定義しておきます。
人材紹介・派遣・求人メディア・社内公募別の要件の違い
事業モデルごとに必要な業務を整理すると、設計の範囲を決めやすくなります。事業モデルが違えば、扱う業務も変わります。
- 人材紹介：求人受付から早期離職まで、候補者検索、推薦、面談、選考、入社を担当者単位で追う流れ。
- 派遣：就業条件、契約期間、勤怠、派遣先との連携。
- 求人メディア：掲載審査、公開期限、応募導線、広告・掲載課金。
- 社内公募：社員の所属や権限、応募を上司に知られたくない事情。
検索結果を表示するだけか、運営者が候補者を選んで求人企業へ紹介するかで、業務と法的な確認事項も変わります。なお、厚生労働省は、情報の選別・加工や意思疎通の中継などが職業紹介に該当し得る区分を示しています（出典：厚生労働省「募集情報等提供と職業紹介の区分」、2026年確認）。
MVPと将来機能の切り分け
初回の機能を絞ると、費用だけでなくデータ設計とテストの範囲も抑えられます。一方で、AI推薦、アプリ、媒体連携を初回から一度に作ると、負担が増えます。
請求計算、本人確認、チャット、詳細分析も加わると、さらに負担が重なります。そのため、初回と将来の範囲を分けて発注すると、機能と基盤、見積もりの優先度を判断できます。
- 初回の最小機能：企業・求職者登録と求人登録、検索と応募、管理画面、通知、権限管理。
- 初期版から設計する基盤：ID体系とマスタ、テナント分離、監査ログ、データ出力、個人情報削除。
- 見積もりの区分：将来候補も見積もる場合は、必須費用とオプション費用の区分。
求人マッチングシステムの発注形態の選び方
標準業務を早く始めたいならSaaS、標準機能を生かして業務に合わせたいならパッケージやローコードが候補になります。独自のマッチングや収益モデルを強みにする場合は、スクラッチ開発を検討します。
発注形態は、会社の規模より、独自業務の深さ、利用者数、既存システムとの連携、データを自社資産として蓄積する必要性で判断します。
標準業務を短期間で始めたい企業向けのSaaS
SaaSは、求人・応募者管理、選考フロー、通知、分析などを月額で使う方式です。サーバーの構築や更新を自社で抱えないため、情報の分散を早く解消したい企業に向いています。
たとえば、Thinkings株式会社のsonar ATSは、初期費用なし、基本プラン月額2.2万円からと公開されています（出典：Thinkings株式会社「sonar ATS 料金」、2026年確認）。
このほか、sonar ATSは求人作成や応募者管理、エージェント連携、採用フロー、分析、外部連携などを提供しています。
SaaSでは、独自の推薦スコア、紹介手数料、複数企業の権限、特殊な審査を実現できるとは限りません。そこで、対応範囲、費用の増え方、データの持ち出しやすさを製品ごとに確かめます。
- 独自要件：API連携や追加開発で実現できるか。
- 利用料金：月額に加えて、利用者数・応募数に応じた従量課金やオプションの有無。
- データ：出力費用と、解約時のエクスポート条件。
パッケージ・ローコードの費用と柔軟性のバランス
パッケージやローコードは、基本的なデータを使って業務に合わせる方式です。契約の前には、調整の範囲と責任を次のとおり確認しておきます。
- 調整対象：求人、求職者、担当者、進捗のデータ。画面・項目・権限・ワークフロー。
- カスタマイズ：範囲と上限、製品のデータ構造に合わせる条件。
- 更新時の責任：標準更新で追加開発が動かない場合の検証・修正担当を、契約書や仕様書に記す。
- 提案範囲：CSV移行、ATS・CRM連携、メール・SMS通知設定、企業ごとの管理権限。
ゼロから作るより導入を短くできるため、標準業務と独自業務が混在する企業に適しています。比べるときは、ライセンス費だけで判断せず、調整や更新、提案範囲の条件をそろえて見ます。
独自ロジックを事業資産にしたい場合のスクラッチ開発
スクラッチは、独自の業務やロジックを事業モデルに合わせて作る方式です。独自ロジックを事業資産にするには、設計の範囲から運用の条件まで、検討の段階で整理しておく必要があります。
- 設計できる範囲：情報とスキルマスタ、検索と推薦理由、履歴、料金計算、テナント、API。
- 事業上の狙い：特定職種の推薦、媒体横断の候補者管理、独自課金による競争力。
- AIの進め方：初回はルールベースから始め、データと担当者評価を蓄積する。
- 運用条件：人が推薦理由を確認し、誤推薦を修正できる形。
成果は、要件定義の精度と発注者の意思決定に左右されます。そのため、高度なAIより、スキル・職種マスタや検索ログを蓄積する方が、初期の検証を進めやすくなります。担当者評価や手動修正履歴も、あわせて残しておきます。
RFPと要件整理の準備範囲
RFP（提案依頼書）は、委託先が同じ前提で提案・見積もりをするための判断材料です。機能一覧だけでなく、事業目的、対象ユーザー、現状業務、データ量をまとめます。さらに、連携先、希望時期、予算、提案範囲も書いておきます。
必須要件と提案に委ねる部分を分けておくと、各社の提案を比べやすくなります。
RFPに書く事業目的と現状業務
RFPには、改善したい業務と、利用者ごとの情報や権限を具体的に書きます。
- 現状と目的：「応募数を増やす」に加えて、推薦品質や対応速度の差、終了求人の紹介も書く。
- 情報の分散：求人・求職者情報がExcel、メール、求人媒体、CRMに分かれている状況。
- 改善する工程：検索、推薦、応募、面談、入社のうち、どこを変えるか。
- 利用者と権限：求人企業、求職者、担当者、管理者、請求・運用者ごとの閲覧・操作・承認。
- 個人情報の閲覧：職務経歴書を求人企業が閲覧できる時期と条件。
職務経歴書の閲覧条件は、個人情報保護と画面設計の両方に関わります。
業務シナリオで書く機能要件
機能要件は、利用者ごとにどの業務を行うかで書き分けます。
- 担当者の検索・推薦：勤務地、雇用形態、年収、必須スキル、経験年数で絞り、理由を確認して送る。
- 求人企業の業務：求人票の下書きと審査、公開と期限、修正履歴、応募確認、選考更新。
- 求職者の業務：登録と公開範囲の設定、応募と辞退、メッセージ、退会、情報削除。
- 非機能・AI要件：性能、復旧、安全性、AI利用条件の定義。
非機能要件には、月間の求人・求職者件数、同時アクセス数、検索応答時間を書きます。加えて、バックアップ、復旧目標、ログ保存期間も記します。
MFAや権限、暗号化、脆弱性診断の条件を書きます。また、データ移行、API制限、運用時間も、同じ要件に含めます。
AIを使う場合は、入力データの保存場所、学習利用、推薦の説明、担当者の承認、誤推薦の修正方法を決めておきます。
成果物・スケジュール・提案フォーマットの統一
提案の内容と工程をそろえておくと、費用や作業範囲を並べて比べられます。
- 提案書の項目：適合状況、対象外、技術、体制、経験、テスト。移行、保守、費用、前提、リスクも含めます。
- 工程：要件定義、基本・詳細設計、開発、テスト。移行、受入、教育、安定化まで続きます。
- 発注者の準備：公開希望月に加え、業務ルールやマスタを確定する時期を示す。
自由形式の依頼では、安い見積もりが目立ち、対象外の作業を見落としやすくなります。
また、IPAの要件定義ガイドでも、発注者が要件を主体的に明確にすることが重視されています（出典：独立行政法人情報処理推進機構「ユーザのための要件定義ガイド」、2021年版）。
契約形態の使い分け（請負と準委任）
契約は、工程の不確実性と成果物の定義のしかたで選びます。要件定義や導入支援は準委任、仕様が確定した後の開発やテストは請負が候補になります。
責任の範囲は、契約名称よりも、契約書と仕様書の中身で決まります。そのため、成果物、検収、変更管理、協力体制、支払いの条件を書き込みます。知的財産、再委託、個人情報、障害対応についても、契約書と仕様書で決めておきます。
請負契約の成果物と検収条件
請負では、成果物と変更管理の条件を合意してから、開発を進めます。
- 成果物：画面、API、データ項目、権限、テスト項目、納品物の特定。
- 検収：期間と契約不適合への対応期間を定め、検索条件、同義語、順序、推薦理由、終了求人も確認する。
- 変更管理：受付、影響評価、費用・納期の再合意、承認者、仕様更新の記録。
「検索できる」の一言では、完成かどうかを判断しにくく、検索条件の細部まで確かめる必要があります。
口頭の追加要望は認識のずれを招きやすいため、チャットや議事録で済ませず、変更台帳に記録します。
準委任契約が向く要件の検証とアジャイル開発
準委任は、一定期間の要件整理、設計、開発、運用支援といった業務に対して報酬を払う契約です。利用者の反応を見ながら優先順位を変える推薦の検証や、MVP改善に使いやすい形です。
IPAの「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年）は、固定の成果物を完成させることより、専門家業務の遂行に対する対価を前提にしています。
準委任でも完成の責任が要らなくなるわけではありません。成果を確かめる仕組みは必要になるため、次のとおり条件を決めて運用します。
- 月ごとの運営：作業内容、稼働時間、会議体、成果確認、翌月の優先順位。
- 役割：発注者の責任者と未完了事項の扱い。
- 契約の組み合わせ：要件定義後に請負へ移る、または機能単位で個別契約する。
契約前に確認する権利・データ・保守の分担
契約には、権利、保守移管、個人情報、生成AI利用の条件を明記します。
- 権利と移管：コードとデザイン、DB、推薦、マスタ、学習データ、AIプロンプト・出力の帰属を定める。
- 保守とデータ：他社への保守移管、クラウド名義、管理者アカウント、CSV・API出力の確認。
- 個人情報の管理：権限、保存場所、暗号化、ログ。事故連絡期限、削除・返却、監査、再委託承認。
- 生成AIの利用：履歴書を入力する場合は、利用規約と学習利用の有無を確認する。
個人情報保護委員会も、生成AIサービスを使う際に利用目的や学習利用を確認するよう促しています（出典：個人情報保護委員会「生成AIサービスの利用に関する注意喚起」、2023年）。
求人マッチングシステムの費用相場とコスト内訳
既製サービスは月額の費用が中心です。一方で、カスタム開発は初期費用が中心で、スクラッチは要件定義から保守までの総額で考えます。
求人専用システムについて、公的な一律の相場は確認できていません。そこで、公開されているマッチング・求人サイトの開発費を、近接領域の目安にします。
ここで示す金額は、要件を前提に置いた推定レンジで、個別案件の確定価格ではありません。
発注方式別の相場と前提条件
方式別の公開情報に、求人向けに必要な範囲を重ねて予算を検討します。
- 公開相場：ノーコード等は20万〜100万円、ベースカスタムは100万〜300万円。
- フルスクラッチの公開相場：300万〜800万円以上。
- SaaS導入：初期0万〜50万円程度、月額2万〜30万円程度。
- 求人向けカスタム：初期100万〜500万円程度。求人マッチングMVPは500万〜800万円程度。
- 機能を含むスクラッチ：推薦、紹介、メッセージ、選考、連携、監査を含め800万〜1,500万円以上。
上の価格目安は、マッチングサイトplusの2025年公開情報に基づいています（出典：マッチングサイトplus、2025年公開情報）。ここに挙げた金額は、確定価格ではなく、前提条件のある目安です。
求人向けの場合は、会員管理、審査、応募、紹介履歴が加わります。権限、個人情報、連携も必要になります。そのため、近接領域の下限内に収まるとは限りません。
推定レンジは、2025〜2026年の類似領域の公開情報を組み合わせたものです。移行、アプリ、複雑な課金、高可用性を加えると、金額は上振れします。あわせて、利用者数とオプションも確認します。
初期費用以外のランニングコスト
初期費用に加え、運用費と利用増に伴う費用を見積もりに含めます。
- 運用費：クラウド、監視、バックアップ、通知、検索、AI API。本人確認、脆弱性対応、問い合わせ、改修、連携も含まれます。
- 利用増加：求人・求職者数に応じた検索基盤・ストレージと、固定・従量の月額費。
- SaaSの総額：初期、月額、オプション、利用者追加、導入支援、データ出力。
- 受託開発の総額：要件定義、開発、移行、教育。保守、クラウド、障害、改修、解約・保守移管。
比べるときは、1年目だけでなく3年総額を作ります。解約時のデータ出力費や、別会社への保守移管費も含めます。
費用と開発期間を左右する不確実性
期間の目安と、納期が揺れる要因を合わせて見積もります。
- 期間の推定：MVPは3〜6か月程度、運用込みスクラッチは6〜12か月程度。
- 変動要因：複数の移行元、未確定API、複雑な審査・手数料、厳しい審査、意思決定の遅れ。
- 短納期の進め方：意思決定者を決め、週次レビューと未決事項の期限を設定する。
- 品質と費用：機能は増やさず、短縮の前提や増員・並行開発の費用影響を確認する。
期間は一般的な推定です。機能を増やしたまま納期を保つと、テストや移行の品質が下がります。
委託先の選定と見積比較で確認すべきポイント
委託先は、機能数や会社規模に加えて、求人・求職者データへの理解、類似モデルの経験、要件定義、移行、運用改善体制で比べます。
納品できるかに加えて、公開後も推薦精度や応募率を改善できるかを確認します。
業界経験の評価軸：機能の有無より運用理解
実績の件数だけでなく、業務理解、運用改善、推薦の検証方法を確認します。
- 業務理解：登録・審査、同意、公開範囲。推薦、紹介、選考、入社後管理。
- 類似実績：自社に近い事業モデル、利用者数、移行元、連携先、保守担当。
- AI推薦：正解データ、表記揺れ、理由表示、担当者の上書き、属性による偏り。
- 改善KPI：推薦から応募、応募から面談、面談から入社への転換。
人材紹介と求人メディアでは、情報提供の主体や操作が異なります。AIや推薦機能は、精度の数字に加えて公開後の改善内容も確認します。会社名の一覧より、中身で比べることが大切です。
見積もりの総額・前提・対象外の横並び比較
金額差の理由を判断するために、対象範囲と前提を次のようにそろえます。
- 費目：要件定義、設計、開発、テスト、移行。教育、リリース、保守、クラウド、外部サービス、予備費。
- 対象外：未計上作業、発注者が用意するデータ、API確認、診断、審査対応。
- 範囲の統一：必須・推奨・将来候補に分け、同じMVP範囲で比較する。
たとえば、A社の500万円ではデータ移行と受入テストが含まれず、B社の700万円には含まれている場合があります。初期目的に不要な高機能提案は費用対効果を下げるため、価格差の理由を各社に質問します。
提案段階で確認するリスクごとの受け持ち範囲
リスクごとに、どこまでを委託先が受け持ち、どこからを発注者が受け持つかを決めます。
- 想定リスク：遅延、変更、移行不備、漏えい。障害、API停止、誤推薦、担当者離任への対応。
- 委託先の体制：PM、開発責任者、再委託先、コード管理。レビュー・テスト担当、障害窓口、復旧目標。
- 発注者の体制：事業、現場、情シス、法務・個人情報、経理、最終承認者と意思決定期限。
週次会議を設定し、発注者も業務ルールやデータの正しさを判断します。判断を担える体制があると、追加費用や手戻りを抑えやすくなります。
発注後の求人マッチングシステム開発を失敗させない進め方
発注後は、要件定義、設計・開発、テスト・移行・リリースの各段階で、発注者が確認する内容を決めておきます。
納品日の管理に加えて、業務シナリオとデータを使い、早い段階で画面や検索結果を確認します。運用後の改善まで、計画に入れておきます。
要件定義で確定する業務シナリオとデータ
通常時と例外時の業務、データ、責任範囲をまとめ、要件定義の成果物として書面に残します。
- 業務と機能：利用者ごとのフロー、画面、権限、項目。通知、連携、検索・推薦ルール。
- 例外ケース：求人非公開、退会、辞退、条件変更、同一候補者への複数推薦。
- 責任と成果物：各者の責任・同意、推薦根拠、手動除外、判断履歴。画面遷移、データ定義、非機能、受入条件。
AIを使うかどうかに関わらず、担当者が推薦根拠を見て候補者を除外でき、判断履歴も追えるようにします。
設計・開発の段階で行う実データに近い検証
将来の追加に備えつつ、MVPのデータと業務を早い段階で確認します。
- 設計：MVPを優先し、求人項目・スキルマスタを後から変更可能にする。
- 追跡と連携：検索・推薦の項目と重み、API認証、再送、レート制限、仕様変更確認を定める。
- 段階レビュー：月末を待たず、企業登録から求人公開、求職者登録から応募、担当者の検索から推薦、面談から入社までを動かして確認する。
- 実データに近い検証：検索から入社までを通し、表記揺れ、重複、空欄、古い求人、権限差を試す。
テスト・移行・リリース後のKPIまでの契約範囲
テストから運用改善までを契約の範囲に含め、確認項目をそろえます。
- テスト：機能、権限、個人情報、検索、推薦理由。通知、API、負荷、復元、脆弱性、操作ログ。
- データ移行：件数に加え、公開状態、同意、所属、重複を照合する。文字コード、添付、削除対象も対象に含める。
- 切り戻し：移行前にバックアップし、移行後の照合と旧運用へ戻す計画を用意する。
- 運用後KPI：検索から推薦、推薦から応募、応募から面談、面談から入社の転換、推薦採用・手動修正の割合、終了求人表示件数、更新遅れ、問い合わせを測る。
- 改善契約：KPI会議、提案頻度、追加改修の見積方法を決める。
公開後の改善まで保守の範囲に含めると、納品後の放置を防ぎやすくなります。
よくある質問（FAQ）
発注時によくある疑問をまとめました。事業モデルや個人情報の扱いによって答えが変わるため、最終的にはRFPと契約条件に反映させてください。
求人マッチングシステムの発注費用はいくらですか？
標準SaaSは初期費用と月額費用、カスタム開発は100万〜500万円程度が目安です。求人マッチングMVPは500万〜800万円程度です。
独自推薦や業務連携を含むスクラッチは、800万〜1,500万円以上を検討の起点にします。金額は、公開された近接領域の相場から推定したもので、移行・連携・セキュリティ・保守の範囲によって変わります。
SaaSとスクラッチ開発はどちらがよいですか？
標準業務を早く始める場合はSaaS、独自ロジックやデータ連携を競争力にする場合はスクラッチが候補です。
迷う場合は、SaaSやパッケージで業務を標準化し、独自性が明確な部分だけを追加開発する段階導入も選べます。
RFPはシステムに詳しくない担当者でも作れますか？
作成できます。機能名より先に、現状業務と困りごとを整理することが大切です。そのうえで、利用者、データ、改善指標、希望時期、必須条件を書き出します。
必要なら要件定義だけを準委任で支援してもらい、その成果物で複数社に開発提案を依頼できます。
求人情報をマッチングするだけでも法的な確認は必要ですか？
必要です。掲載だけの場合と、運営者が候補者を選別して連絡したり、求人者と求職者の意思疎通を中継したりする場合とでは、職業紹介に該当する可能性が異なります。
機能を決める前に、厚生労働省の区分を確認します。必要に応じて専門家や所管の労働局に相談し、本人同意と個人情報の利用目的を設計に反映させます。
まとめ
まず、人材紹介、派遣、求人メディア、社内公募のどの事業モデルかを決めます。次に、SaaS、パッケージ、スクラッチを独自性と総コストで比べます。
RFPには、現状業務、シナリオ、利用者・権限、データを書きます。連携、非機能、セキュリティ、必須・将来機能も記載します。
同じRFPで2〜3社に相談する進め方
作業範囲、対象外、移行、保守、外部サービスの前提をそろえます。そのうえで、3年総額、契約、成果物、リスクも同じ条件で見積もりを比べます。
公開後のKPIと改善体制も提案できる委託先を2〜3社に絞り、同じRFPで提案を受けます。これにより、必要な機能と不要な機能を判断しやすくなります。
AIの説明可能性と人の確認を含めた発注
AI推薦でも、合否や紹介の可否は人が確かめる形にし、推薦理由、担当者承認、手動修正、ログ、バイアス確認を含めます。
求人・求職者情報を守りつつ、検索・推薦・応募・入社のデータを改善に生かす仕組みが、長く使えるシステムにつながります。
▼全体ガイドの記事
・求人マッチングシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。