# マッチングサイト開発の費用相場｜外注の進め方

- 公開日: 2026-08-07
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/matching-site-development-cost-guide

マッチングサイト開発の費用相場は、300万〜900万円程度、期間は3〜10カ月が一般的な目安です。外注では、取引成立に必要な最小機能と運営ルールを先に固め、総額ではなく前提・対象外・保守費まで比較することが重要です。

## マッチングサイト開発の費用相場と期間

マッチングサイト（＝仕事・商品・人・場所などを提供する側と探す側を結び付けるWebサービス）の開発費は、一般的に300万〜900万円程度です。ただし、単に会員を検索して問い合わせるサイトと、予約・決済・本人確認まで完結するサイトでは、必要な設計とテストの量が大きく異なります。

以下は、Web版を開発会社へ外注する場合の一般的な目安です。消費税、広告宣伝費、社内人件費、公開後のカスタマーサポート費などは含みません。

| 開発規模 | 想定する主な機能 | 開発費の目安 | 期間の目安 |
|---|---|---:|---:|
| 小規模な検証版 | 会員登録、プロフィール、掲載、検索、問い合わせ、簡易管理画面 | 100万〜200万円 | 1〜2カ月 |
| 標準的なサービス | 応募・予約、メッセージ、決済、レビュー、通知、運営管理 | 200万〜500万円 | 2〜3カ月 |
| 複雑な取引基盤 | 本人確認、売上分配、複数権限、審査、高度な推薦・分析 | 500万〜1,000万円以上 | 3〜5カ月以上 |

金額はあくまで目安です。同じ機能名でも、たとえば「決済」が単純な月額課金なのか、取引ごとのキャンセル・返金・売上分配まで扱うのかによって工数が変わります。

### マッチング方式による費用の違い

費用を左右するのは画面数だけではなく、どこまでシステム上で取引を完結させるかです。

| マッチング方式 | 取引の例 | 必要になりやすい機能 | 費用への影響 |
|---|---|---|---|
| 掲載・問い合わせ型 | 店舗検索、専門家紹介、資料請求 | 掲載、検索、問い合わせ、運営審査 | 比較的抑えやすい |
| 応募・承認型 | 求人、副業、人材・案件紹介 | 応募、選考状況、承認、メッセージ | 状態管理が増える |
| 予約型 | 場所、レッスン、訪問サービス | 空き枠、予約、変更、キャンセル、通知 | 日時や在庫の整合性が必要 |
| 取引・決済型 | スキル、商品、業務委託 | 決済、返金、売上分配、取引履歴、評価 | 設計・テスト・運用負担が大きい |

発注のご相談を受ける開発会社の立場から見ると、見積もりが膨らみやすいのは、通常の取引よりも「例外時の処理」です。予約後の日程変更、一部返金、提供者の辞退、連絡不通、審査の差し戻し、複数人での売上分配などをシステム化するほど、画面・通知・権限・テスト項目が増えます。

### 開発方法別の費用と向いているケース

| 開発方法 | 初期費用の目安 | 向いているケース | 注意点 |
|---|---:|---|---|
| ノーコード・既製サービス | 50万〜300万円程度 | 掲載と問い合わせを中心に早く需要を試したい | 独自の決済や複雑な権限に制約がある |
| パッケージのカスタマイズ | 200万〜1,000万円程度 | 標準機能を利用しつつ一部だけ変更したい | 月額料金、改修可能範囲、データ移行条件を確認する |
| フルスクラッチ開発 | 300万〜1,000万円以上 | 独自の取引フローや運営方法が競争力になる | 初期費用、期間、保守負担が大きくなりやすい |

ノーコード（＝プログラムを一から書かず、既製の部品を組み合わせる開発手法）は、仮説検証には有効です。一方、細かな売上分配や特殊な審査、利用者ごとに異なる権限が必要な場合は、制約に合わせるための回避策がかえって高くなることがあります。

フルスクラッチ（＝既製品を前提にせず個別に設計・開発する方法）を選ぶべきなのは、独自機能が多いからではなく、独自の取引体験が事業の競争力に直結する場合です。初期版の目的が需要確認なら、手作業や既製サービスを組み合わせる方法も比較してください。

### 費用が上がりやすい機能

次の機能は、外部サービスとの連携、審査、例外処理、セキュリティ対策が必要になりやすく、費用差が出ます。

- クレジットカード決済、返金、キャンセル料、売上分配
- 本人確認、法人確認、資格証明の提出・審査
- 予約枠、在庫、指名、繰り返し予約
- リアルタイムチャット、既読表示、添付ファイル
- 地図、外部カレンダー、電子契約、会計サービスとの連携
- 行動履歴や条件に基づく推薦
- 違反報告、取引監視、会員停止、証跡確認ができる管理画面
- iOS・Androidアプリの同時開発
- 多言語、多通貨、海外決済への対応

「AIで相性のよい相手を推薦したい」という相談もありますが、公開直後は推薦に使える利用データが不足しています。初期版では条件検索や運営者による手動紹介で検証し、成約データが蓄積してから推薦機能を追加するほうが、費用と事業リスクを抑えやすくなります。

### 公開後にも必要な費用

開発予算は、初期費用だけでなく公開後12カ月程度まで見積もることが重要です。

| 費目 | 一般的な目安・考え方 |
|---|---|
| サーバー・監視 | 小規模では月数万〜数十万円程度。利用量や画像・動画の保存量で増える |
| 保守運用 | 月3万〜10万円程度。対応時間、改修枠、監視範囲で変わる |
| 外部サービス | 決済、本人確認、メール・SMS、地図など。月額または利用量に応じた従量課金 |
| カスタマーサポート | 問い合わせ、審査、返金、違反対応に必要な社内外の人件費 |
| 改善開発 | 利用状況に応じた画面改善、機能追加、不具合以外の変更費用 |

保守費に「軽微な改修」が含まれるか、障害対応だけなのかは会社によって異なります。月額だけでなく、対応時間帯、作業上限、追加料金の計算方法を確認してください。

## 外注前に決める事業設計と必要機能

外注前に優先して決めるべきなのは、画面の色や機能一覧ではなく、「誰と誰を、どの条件で結び付け、どの時点で取引成立とするか」です。マッチングサイトは、利用者が両側に存在して初めて価値が生まれるため、開発と集客・審査・トラブル対応を分けて考えることはできません。

### 最初に整理する事業上の8項目

開発会社への相談時には、少なくとも次の項目を1〜3ページ程度にまとめておくと、提案と見積もりの精度が上がります。

- 提供者側と利用者側は誰か
- 両者が現在使っている代替手段は何か
- 掲載、検索、応募、承認、予約、決済までの流れ
- 「マッチング成立」をどの時点と定義するか
- 運営者が審査・紹介・契約・決済に介在する範囲
- 成約手数料、月額課金、掲載料などの収益モデル
- キャンセル、返金、違反、連絡不通への対応ルール
- 公開後3〜6カ月で検証する数値と継続・撤退の判断条件

特に重要なのが、マッチング成立の定義です。問い合わせ送信、双方の承認、予約確定、契約締結、決済完了のどこを成立とするかによって、売上計上、手数料徴収、通知、キャンセル処理に必要な機能が変わります。

### 初期版に含める機能の決め方

MVP（＝顧客価値を検証できる最小限の製品）では、「あると便利な機能」ではなく「取引仮説を確認するために欠かせない機能」を残します。

| 優先度 | 判断基準 | 機能例 |
|---|---|---|
| 初期公開に必須 | ないと利用者が相手を見つけ、取引を開始できない | 会員登録、プロフィール、掲載、検索、応募・問い合わせ |
| 運営に必須 | ないと安全性や日々の運営を維持できない | 掲載審査、会員停止、通報確認、履歴閲覧、手動修正 |
| 条件付きで必須 | 事業モデル上、公開時から必要 | 予約、決済、本人確認、資格審査 |
| 公開後に検証 | 利用状況を見てから判断できる | AI推薦、ランク、ポイント、高度な分析、アプリ化 |

管理画面は後回しにされがちですが、利用者向け画面と同じくらい重要です。初期は運営者が手作業で補える部分も多いため、すべてを自動化する必要はありません。ただし、会員停止、掲載内容の修正、取引状況の確認、問い合わせ調査に必要な履歴は、公開時から用意したほうが安全です。

初期機能の絞り込み方は、[MVP開発の費用相場｜外注範囲・進め方・選び方](https://www.geek-bridge.com/column/mvp-development-cost-outsourcing-guide)でも詳しく解説しています。

### 法令・契約・運営ルールも要件に含める

マッチングする対象によっては、人材紹介、職業紹介、旅行、宿泊、不動産、金融、医療、古物、通信販売などの法令や許認可が関係する可能性があります。決済を預かる方式や利用者への表示内容についても確認が必要です。

開発会社は画面や機能の実現方法を提案できますが、事業の適法性を最終判断する立場ではありません。該当可能性がある場合は、企画段階で弁護士、行政書士、決済事業者などの専門家へ相談してください。後から取引方式を変更すると、会員規約だけでなく決済・データ・画面設計まで作り直す場合があります。

外注前の確認事項は次のとおりです。

- 利用規約とプライバシーポリシーを誰が作成するか
- 提供者と購入者のどちらが契約当事者になるか
- 運営会社が代金や手数料をどのように受け取るか
- 本人確認や資格審査が必要か
- 個人情報や本人確認書類をどこに保存するか
- 退会後のデータをいつまで保持するか
- 通報、事故、損害、禁止行為への対応窓口は誰か
- 未成年者や海外利用者を対象に含めるか

## マッチングサイト開発を外注する進め方

外注は、事業仮説の確認、依頼資料の作成、要件定義、設計・開発、受け入れテスト、限定公開の順に進めます。機能が未整理のまま複数社へ見積もりを依頼すると、各社が異なる前提で金額を出すため、適切に比較できません。

### 1. 手作業で取引仮説を確認する

開発前に、候補者へのインタビュー、表計算ソフトでの掲載管理、メールやオンライン会議による手動紹介などを行います。確認したいのは、登録者数ではなく、実際に応募・予約・成約まで進むか、運営者の仲介にどれだけ作業が発生するかです。

この段階でキャンセル理由や利用者からの質問を記録すると、必要な機能と運営ルールを具体化できます。

### 2. 三者の取引フローを図にする

提供者、利用者、運営者の3者に分け、登録から取引終了までを時系列で整理します。正常な流れだけでなく、次の例外も記載してください。

- 登録・掲載が審査で否認された場合
- 応募後に提供者が辞退した場合
- 予約日時を変更する場合
- 期限までに支払われない場合
- サービス提供後に苦情や返金依頼があった場合
- 退会、利用停止、重複登録が発生した場合

例外処理を先に整理すると、必要な通知、操作権限、履歴、管理画面の範囲が明確になります。

### 3. 初期範囲・予算・公開条件をそろえる

機能を「必須」「予算内なら含める」「公開後」の3段階に分類します。開発会社には予算上限も共有したほうが、現実的な代替案を受けやすくなります。

依頼資料には次を記載します。

- 事業の目的と対象利用者
- 取引フローと収益モデル
- 初期機能と将来機能
- 参考にする既存サービスと、参考にしたい箇所
- 予算上限と希望公開時期
- Web版・アプリ版の対象範囲
- 法務、デザイン、インフラ、保守の依頼範囲
- 未決事項と、開発会社に提案してほしい事項

RFP（＝候補会社へ要件や提案条件を伝える依頼書）を作る場合は、[RFPの作り方｜システム開発の依頼準備](https://www.geek-bridge.com/column/system-development-rfp-creation-guide)を参考にしてください。新規事業ではすべてを確定できないため、決まっていない点を隠さず「仮説」「要相談」と明記することが重要です。

### 4. 要件定義で機能と運用を具体化する

要件定義（＝作るものと満たす条件を決める工程）では、画面一覧だけでなく、権限、データ、通知、例外時の処理、管理方法を決めます。標準的な案件では、要件定義だけで1〜2カ月程度かかることがあります。

要件定義で確認したい主な項目は次のとおりです。

- 会員種別ごとに閲覧・登録・変更できる情報
- 検索条件と検索結果の並び順
- 応募、承認、予約、取引の状態と変更条件
- 決済、キャンセル、返金、手数料計算のルール
- メールやアプリ通知を送るタイミング
- 運営者による審査、修正、停止、履歴確認の権限
- 個人情報、本人確認資料、取引記録の保存方法
- 利用増加を想定した性能とセキュリティの条件
- 公開後の分析に必要な記録項目

### 5. 段階的に開発し、発注者も途中確認する

完成時に初めて確認するのではなく、画面設計、試作画面、主要機能の完成時など、複数回に分けてレビューします。文字や色だけでなく、取引フローと運営作業が想定どおりかを確認してください。

発注者側でも、事業責任者、実際の運営担当者、法務・経理担当者の確認時期を決めます。特に決済や返金は、開発担当者だけで決めると、実際の経理処理と合わないことがあります。

### 6. 受け入れテストと限定公開を行う

受け入れテスト（＝発注者が業務上問題なく利用できるか確認する作業）では、通常操作だけでなく、運営上困りやすいケースを試します。

- 入力途中で通信が切れた場合
- 同じ時間帯に予約が重なった場合
- 決済に失敗した場合
- キャンセル期限の前後で操作した場合
- 返金後に取引履歴や売上が正しく更新されるか
- 会員停止後にログインや連絡ができないか
- 管理者の操作履歴を追跡できるか

公開時は地域、業種、招待人数などを限定し、問い合わせ内容や離脱箇所を確認します。利用者が少ない時期から大量アクセス向けの機能へ投資するより、成約を妨げている箇所の改善を優先するほうが合理的です。

## 見積もり・開発会社の選び方と失敗回避策

見積もりは総額の安さではなく、「何を前提とし、どこまで含み、変更時にどう精算するか」で比較します。安い見積もりでも、管理画面、決済の例外処理、データ移行、公開作業、保守が対象外なら、最終的な支払額が高くなる可能性があります。

### 見積書のチェックリスト

- 要件定義、画面設計、デザイン、開発、テスト、公開作業の内訳があるか
- 提供者側、利用者側、管理者側の機能が区別されているか
- 決済、本人確認、通知など外部サービスの初期費・月額・従量課金が示されているか
- スマートフォン対応がWeb表示だけか、アプリ開発まで含むか
- セキュリティ対策、バックアップ、障害監視の範囲が明確か
- 動作保証するブラウザや端末が記載されているか
- 仕様変更時の単価、承認方法、納期への影響が決まっているか
- ソースコード、デザインデータ、ドメイン、利用アカウントの権利が明確か
- 公開後の不具合保証期間と保守契約の範囲が記載されているか
- 運用マニュアルや管理者向け説明が納品物に含まれるか

要件が固まっている部分は請負（＝合意した成果物の完成を前提とする契約）、仮説検証や継続改善は準委任（＝専門業務の遂行や作業時間を委託する契約）が向く場合があります。契約名だけで判断せず、成果物、検収条件、作業上限、変更手続きを確認してください。

### 開発会社を比較する質問

マッチングサイトの発注では、過去の制作画面がきれいかだけでなく、事業と運用を具体化する質問ができる会社を選びます。

| 確認項目 | 質問例 | 見極めたい点 |
|---|---|---|
| 事業理解 | 成立率を上げるため、初期版で何を優先しますか | 機能数ではなく事業目的から提案できるか |
| 例外処理 | キャンセルや連絡不通をどう設計しますか | 通常時以外の運用を考慮できるか |
| 類似経験 | 類似案件で難しかった論点は何ですか | 経験を一般化して説明できるか |
| 体制 | 要件定義、設計、テストの責任者は誰ですか | 営業後の担当体制が明確か |
| セキュリティ | 個人情報と本人確認資料をどう扱いますか | リスクに応じた対策を説明できるか |
| 公開後 | 不具合、問い合わせ、改善要望をどう切り分けますか | 保守運用のルールが具体的か |
| 引き継ぎ | 契約終了時に何を受け取れますか | 他社への移管や内製化が可能か |

類似サービスの開発実績は参考になりますが、実績数だけで選ぶ必要はありません。対象業界、取引方式、決済、審査、運営体制が自社と近いかを確認し、守秘義務で詳細を開示できない場合は、設計上の論点や進め方を説明してもらいましょう。

### よくある失敗と回避策

| よくある失敗 | 起きる理由 | 回避策 |
|---|---|---|
| 初期版に機能を詰め込みすぎる | 競合サービスの機能をすべて必要と考える | 取引成立に必要な機能と検証項目から逆算する |
| 集客費と運営費が残らない | 開発費だけで事業予算を使い切る | 公開後12カ月の集客・保守・サポート費も確保する |
| 管理画面を簡略化しすぎる | 利用者向け画面だけを重視する | 審査、停止、調査、手動修正に必要な操作を洗い出す |
| 決済を終盤に追加する | 支払いは外部サービスを付ければ済むと考える | 返金、分配、経理処理を要件定義前に確認する |
| 両側の利用者が集まらない | システム公開が集客開始になっている | 開発前から片側ずつ獲得し、対象地域や業種を絞る |
| 成約状況を測定できない | 画面完成を優先し、分析項目を決めていない | 成立の定義と記録するイベントを要件に含める |
| 特定会社から移管できない | 権利・アカウント・資料の納品条件が曖昧 | 契約前に所有権、納品物、引き継ぎ条件を明記する |

発注前にすべての仕様を確定する必要はありません。重要なのは、未確定事項を把握し、検証しながら決める範囲と、公開前に確定すべき範囲を分けることです。取引モデルに合う開発方法や概算費用を整理したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談いただけます。

## まとめ

- マッチングサイト開発の費用は300万〜1,000万円程度、期間は3〜5カ月が一般的な目安です
- 本人確認、決済・返金・売上分配、予約、複雑な審査、アプリ対応は費用が上がりやすい要素です
- 初期版では、利用者同士が出会い、取引を開始・完了できる最小範囲へ機能を絞ります
- 画面だけでなく、審査、キャンセル、返金、違反、問い合わせなどの運営ルールも設計します
- 見積もりは総額ではなく、前提条件、対象外、外部サービス料金、変更手続き、保守範囲で比較します
- 開発会社は、通常操作だけでなく例外処理や公開後の運営まで質問・提案できるかで見極めます
- 開発費とは別に、公開後の集客、保守、カスタマーサポート、外部サービス利用料を確保します

## よくある質問

### マッチングサイトの開発費はいくらですか？

Web版を外注する場合、一般的には300万〜1,000万円程度が目安です。検索と問い合わせを中心とする小規模版は300万〜700万円、決済やレビューを含む標準版は800万〜2,000万円、本人確認や売上分配を含む複雑なサービスは1,000万円を超えることがあります。

### マッチングサイトの開発期間はどのくらいですか？

小規模な検証版は1〜2カ月、標準的なサービスは2〜3カ月、複雑なサービスは3〜5カ月以上が一般的な目安です。要件の整理状況、外部サービスの審査、決済やアプリ開発の有無によって変動します。

### 開発会社へ相談する前に何を準備すればよいですか？

誰と誰を結び付けるのか、取引成立の定義、収益モデル、三者の取引フロー、初期機能、予算上限、希望公開時期を整理してください。未確定事項は無理に決めず、仮説や提案してほしい事項として共有すれば相談できます。

### パッケージとフルスクラッチのどちらを選ぶべきですか？

掲載・検索・問い合わせを中心に需要を検証するなら、パッケージやノーコードが候補です。独自の取引フロー、審査、複雑な決済が競争力に直結する場合はフルスクラッチが適しています。初期費用だけでなく、月額料金、データ移行条件、将来の改修自由度も比較してください。