「プログラミングはできないが、専門家と依頼者をつなぐサービスを作りたい」「問い合わせ対応や入金確認に追われる副業にはしたくない」と考えていないでしょうか。
ニッチ業種向けマッチングサイトは、大手サービスで探しにくい専門家と、依頼先が見つからず困っている発注者をつなぐ仕組みです。
ただし、サイトを公開しただけでは自動化資産になりません。需要が弱ければ案件は集まらず、決済・権限・例外処理が不十分なら、取引が増えるほど運営者の対応時間も増えます。
本記事では、ノーコードを中心に、必要な部分だけローコードを使って次の業務を自動化する手順を解説します。
- 会員登録
- 案件受付
- 候補者の抽出
- LINE・メール通知
- 決済
- 報酬分配
- 未対応者への催促
- KPI集計
- 例外案件の振り分け
目標は「完全放置」ではありません。平常処理を自動化し、紛争、不正、返金、本人確認など、人間が判断すべき例外だけを管理画面へ送る状態です。
ニッチ業種向けマッチングサイトが向く市場
候補となるのは、たとえば次のような市場です。
- 古い業務用刺繍機を修理できる技術者
- 特定のCAD形式を変換できるオペレーター
- 医療機器分野に詳しい翻訳者
- 特殊な測量機器を扱える事業者
- 特定地域の許認可申請に詳しい専門家
重要なのは、単に「珍しい業種」であることではありません。次の3条件を満たす必要があります。
- 発注者が依頼先を探すのに困っている
- 条件をデータとして整理できる
- 1件あたりの手数料で運営コストを回収できる
発注頻度が年に数回しかなく、対応可能な受注者も数人しかいない市場では、競合が少なくてもマッチングが成立しません。
反対に、検索数が少なくても、業界団体、紹介、展示会、既存取引などで定期的に依頼が発生している市場なら、事業化できる可能性があります。
ノーコードで作れる範囲と、コードが必要な範囲
初心者向けの構成例は次の通りです。
| 役割 | ツール候補 | 用途 |
|---|---|---|
| 会員・案件画面 | Bubble、Softr、Glide | 登録、案件投稿、応募、進捗確認 |
| データベース | Airtable、Supabase | ユーザー、案件、取引履歴 |
| 自動処理 | Make、Zapier、n8n | 条件照合、通知、催促、集計 |
| 通知 | LINE公式アカウント、メール | 新着案件、応募、検収依頼 |
| 決済 | Stripe、Stripe Connect | カード決済、手数料、報酬分配 |
| 分析 | GA4、Search Console、Looker Studio | 集客、登録、成約の測定 |
ノーコードだけで作りやすいのは、登録フォーム、案件一覧、単純な条件照合、メール通知、KPI集計です。
一方、次の処理はローコードまたは専門家の確認が必要になりやすい部分です。
- Stripe Connectによる報酬分配
- Webhookの署名検証と重複防止
- 複雑なアクセス権限
- 一部返金と送金取消
- 本人確認状況の同期
- 紛争・不正利用への対応
- 法令や業界規制に応じた利用制限
したがって、現実的な設計は「完全ノーコード」ではなく、ノーコード中心でMVPを作り、決済・権限・例外処理だけをローコードで補強する構成です。
自動化型マッチングサイトの処理フロー
基本フローは次の通りです。
- 発注者が案件条件を入力する
- データベースへ案件を保存する
- 条件に合う受注者を抽出する
- LINEまたはメールで通知する
- 受注者が応募する
- 発注者が受注者を選ぶ
- 発注者が決済する
- 受注者が納品する
- 発注者が検収する
- 規定に従って報酬を分配する
- 成約・介在時間・エラーを集計する
ここで必要になるのがWebhookです。Webhookとは、Stripeなどでイベントが発生したとき、別のシステムへ自動通知する仕組みです。
ただし、Webhookは一度だけ順番通りに届くとは限りません。Stripeはイベントの到着順を保証しておらず、同じイベントが複数回届く場合もあります。そのため、イベントIDを保存し、処理済みのイベントを再実行しない設計が必要です。StripeのWebhook公式ドキュメント
ステップ1：誰と誰をつなぐのか一文で定義する
最初に、次の形式で事業を一文にします。
「＿＿＿＿で困っている発注者」と「＿＿＿＿ができる受注者」をつなぐ。
悪い例は「専門家のマッチングサイト」です。対象が広く、既存サービスとの違いが分かりません。
良い例は次の通りです。
古い業務用刺繍機を修理したい工場と、対象機種に対応できる技術者をつなぐ。
候補業種ごとに、以下を○・△・×で採点してください。
| 確認項目 | 判定基準 |
|---|---|
| 探しにくさ | 検索や既存サービスで依頼先が見つからない |
| 発注頻度 | 同種の依頼が繰り返し発生する |
| 案件単価 | 手数料を引いても運営費を回収できる |
| 条件化 | 地域、資格、機材、納期などを項目化できる |
| 検収可能性 | 作業完了や成果物を確認できる |
| 供給量 | 対応可能な受注者を複数確保できる |
| 規制リスク | 必要な資格・許認可・契約条件を確認できる |
○が多いだけでは採用しません。次の聞き取りで、実際の困りごとを確認します。
ステップ2：開発前に需要を手作業で検証する
最初からサイトを作らず、発注者候補5人、受注者候補5人を目安に聞き取りを行います。
各5人は市場全体を統計的に判断する人数ではありません。個人が短期間で「この課題は実在するか」を確認するための最小検証条件です。
発注者に聞く質問
- 最後に依頼先を探したのはいつか
- どこで探したか
- 見つかるまで何日かかったか
- 見つからなかったことはあるか
- 選定時に必ず確認する条件は何か
- 過去の案件単価はいくらか
- 仲介手数料を払ってでも使いたいのはどんな状況か
- 次回の依頼予定はあるか
受注者に聞く質問
- 対応できる業務と対応できない業務
- 対応地域
- 必要な事前情報
- 最低受注額
- 標準納期
- 保有資格・機材
- 繁忙期
- 案件通知を受け取りたい条件
「便利そう」という感想は弱い証拠です。次の行動を重く評価します。
- 次回の案件時に連絡してほしい
- 実際の案件条件を共有してくれた
- 事前登録に同意した
- テスト案件への参加に同意した
- 有料でも使う条件を具体的に答えた
開発へ進む前に、少なくとも「実在する案件例3件」と「対応可能な受注者3人」を確保してください。
ステップ3：契約・許認可・資金の流れを確認する
マッチングサイトでは、最初に次の関係を明確にします。
- 発注者と受注者の契約形態
- 運営者が契約当事者になるか
- 誰が返金責任を負うか
- 誰が決済手数料とチャージバックを負担するか
- 運営者が受注者を選定するか
- 個人情報を誰へ、いつ開示するか
業務委託のマッチングと、雇用関係の成立をあっせんする職業紹介は同じではありません。厚生労働省は、求人者と求職者の間の雇用関係成立をあっせんする事業を「職業紹介」としており、有料職業紹介事業は原則として許可制です。
さらに、運営者の判断で提供相手を選別する場合などは、自動処理であっても職業紹介に該当する可能性があります。厚生労働省「募集情報等提供と職業紹介の区分」
また、Stripe Connectを導入しただけで、すべての法的確認が不要になるわけではありません。「資金決済法を回避できる」と断定せず、契約関係、資金の流れ、返金条件、対象業種の規制を弁護士や税理士へ提示してください。
最低限、公開前に以下を用意します。
- 利用規約
- プライバシーポリシー
- 禁止事項
- キャンセル・返金条件
- 検収期限
- 紛争時の連絡方法
- 資格・本人確認の扱い
- 個人データの保存・削除ルール
個人データについては、取得、利用、保存、提供、削除の各段階で取扱方法と責任者を決めます。個人情報保護委員会の通則ガイドライン
ステップ4：収益モデルと採算ラインを決める
主な収益モデルは次の3種類です。
| 収益モデル | 向くケース | 注意点 |
|---|---|---|
| 成約手数料 | 決済をサイト内で完結できる | 返金・紛争・サイト外取引への対策が必要 |
| 月額掲載料 | 継続的に受注したい事業者がいる | 案件が少ないと解約されやすい |
| リード課金 | 取引金額を把握しにくい | 問い合わせ品質への不満が出やすい |
Hiroサイト内の構築マニュアルでは、プラットフォーム手数料を10〜20%とする試算例があります。ただし、これは市場平均や収益実績ではなく、設計資料上の仮定です。
たとえば、案件単価3万円、プラットフォーム手数料15%なら、1件あたりの手数料売上は4,500円です。
30,000円 × 15% = 4,500円
ここから決済費用、Connect費用、返金、広告費、通知費、サポート費、税金を差し引きます。
2026年7月22日時点で、Stripeの日本向け標準料金には国内カード決済成功1件あたり3.6%という表示があります。一方、Connectは料金管理方式により、アクティブアカウントや入金に対する費用が発生する場合があります。必ず導入方式を決めてから再計算してください。Stripe料金ページ・Stripe Connect料金ページ
採算確認には、次の式を使います。
1取引あたり限界利益
= 手数料売上
- 決済関連費用
- 通知費
- 返金・貸倒引当
- 1取引あたりサポート費
売上だけでなく、この限界利益がプラスになる案件単価と手数料率を決めます。
ステップ5：3テーブルと状態遷移を設計する
MVPでは、次の3テーブルから始められます。
users：発注者・受注者のプロフィールjobs：案件条件と進行状況transactions：決済、手数料、返金、送金履歴
usersの主な項目
- ユーザーID
- 利用者区分
- 対応スキル
- 対応地域
- 最低受注額
- 本人確認状態
- Stripe連結アカウントID
- 通知可否
jobsの主な項目
- 案件ID
- 発注者ID
- 必要スキル
- 地域
- 予算
- 希望納期
- 担当受注者ID
- 募集状態
- 決済状態
- 納品状態
- 検収期限
transactionsの主な項目
- 取引ID
- 案件ID
- Stripe決済ID
- 請求額
- 手数料額
- 返金額
- 送金額
- 決済状態
- 送金状態
- 処理済みWebhookイベントID
状態は、次のように一方向へ進めます。
下書き
→ 募集中
→ 受注者選定済み
→ 決済済み
→ 作業中
→ 納品済み
→ 検収済み
→ 送金済み
「決済済みでなければ作業中にできない」「検収済みでなければ送金できない」といった制約を設けることで、未入金着手や二重送金を防ぎます。
Hiroサイト固有の一次情報と検証ログ
2026年7月22日JSTに、Hiroサイトのリポジトリ内にある次の資料を確認しました。
generator/source_manuals/niche_matching_system_manual.md
PowerShellで確認した結果は次の通りです。
| 確認項目 | 結果 |
|---|---|
文字数（Get-Content -Rawの.Length） | 4,313文字 |
内容行数（Get-Contentの要素数） | 126行 |
| ファイルサイズ | 8,829バイト |
| 最終更新日時 | 2026-06-24 10:22:48 +09:00 |
末尾の改行を分割後の空要素として数える方法では127になりますが、内容行は126行です。
資料にはusers、jobs、transactionsの3テーブルと、LINE、Supabase、Stripe Connectを組み合わせる構成が記載されていました。
ただし、これは売上実績や本番稼働結果ではありません。また、資料の構成にはLIFF、React、サーバーレス関数が含まれるため、厳密には完全ノーコードではなくローコード構成です。本記事では、この設計資料を仮説として扱い、公式仕様とテスト結果で検証する前提にしています。
ステップ6：登録・案件・応募画面を作る
作成する画面は、次の8つに絞ります。
- 利用者区分の選択
- 発注者プロフィール
- 受注者プロフィール
- 案件投稿
- 案件一覧
- 応募
- 取引状況
- 問い合わせ・紛争報告
見た目を整える前に、各フォーム項目の保存先を決めます。
| 画面項目 | 保存先 |
|---|---|
| 対応地域 | users.service_area |
| 最低受注額 | users.minimum_price |
| 必要スキル | jobs.required_skill |
| 希望納期 | jobs.due_date |
| 決済状態 | transactions.payment_status |
地域、資格、価格帯、納期を自由記述だけにすると、自動照合できません。照合条件は選択式にし、補足だけを自由記述にします。
初回登録では必須項目を減らし、応募時や本人確認時に追加情報を取得すると離脱を抑えやすくなります。
ステップ7：条件照合と通知を自動化する
初期段階では、AI推薦より説明可能なルール判定が適しています。
必要スキルが一致
AND 対応地域が一致
AND 予算が最低受注額以上
AND 希望納期に対応可能
AND 本人確認状態が有効
Makeやn8nで次の処理を組みます。
- 新規案件を検知する
- 条件に合う受注者を検索する
- 候補者IDと一致理由を保存する
- 対象者だけへ通知する
- 候補者が0人なら運営者へ送る
- 応募期限前に未回答者へ1回だけ再通知する
通知には次の情報を含めます。
- 案件概要
- 予算
- 対応地域
- 希望納期
- 応募期限
- 詳細画面へのリンク
LINE Messaging APIには月間メッセージ数の上限があり、上限を超えると送信に失敗します。配信対象を条件一致者に限定し、残数と送信失敗を監視してください。LINE Messaging API公式ドキュメント
ステップ8：決済・返金・報酬分配をテストする
Stripe Connectの資金フローは、検収タイミングと返金責任を決めてから選びます。
Destination chargeでは、決済確定後に接続先アカウントへ資金が移動し、プラットフォーム手数料が運営側へ戻る構成を取れます。プラットフォームがStripe手数料を負担する場合があるため、手数料売上をそのまま利益と考えてはいけません。StripeのDestination charge公式ドキュメント
納品後まで決済確定を待つ設計では、オーソリの有効期限にも注意します。日本のJPY建てオンライン取引では、一部ブランドで最長30日保持できる場合がありますが、通貨、カードブランド、取引条件で期限が異なります。案件期間が長い場合は、単純な「納品後キャプチャ」が使えない可能性があります。Stripeのオーソリ・売上確定公式ドキュメント
公開前に、少なくとも次をテストします。
| テストケース | 確認内容 |
|---|---|
| 決済成功 | 案件と取引が決済済みになる |
| 決済失敗 | 作業開始できず、再決済を案内する |
| 二重送信 | 同じWebhookで二重計上されない |
| 順序逆転 | 遅れて届いたイベントで状態が巻き戻らない |
| 全額返金 | 取引・案件・会計記録が一致する |
| 一部返金 | 手数料と受注者報酬を再計算できる |
| 検収期限超過 | 規約に沿って催促または管理キューへ送る |
| 報酬分配失敗 | 自動再試行せず原因を確認できる |
| 本人確認未完了 | 送金処理を開始しない |
| 通知失敗 | 代替通知または運営アラートが届く |
Webhookでは、次の4点を必須にします。
- Stripe署名を検証する
- イベントIDを保存する
- 同じイベントを二重処理しない
- 受信処理と本処理を分離する
Stripeは本番環境で失敗したWebhookを最長3日間、自動再送します。再送を前提に、処理を何度実行しても結果が重複しない設計にしてください。
ステップ9：小規模公開してKPIを改善する
最初から広告を大量投入せず、受注者3〜10人、発注者1〜5社程度の限定公開から始めます。
最初の案件は運営者が観察し、次を記録します。
- どの条件で候補者が0人になったか
- どの通知が読まれなかったか
- どの入力項目で質問が発生したか
- どの状態で処理が止まったか
- 1取引に何分介在したか
- 返金や紛争の原因は何か
手作業が発生したら、すぐ自動化するのではなく、同じ作業が3回以上発生したかを確認します。頻度の低い例外まで自動化すると、開発・保守コストの方が大きくなるからです。
権限管理は画面ではなくデータベース側で行う
ボタンやメニューを非表示にするだけでは、URLやAPIを直接呼び出された場合にデータを守れません。
Supabaseを使う場合は、公開スキーマのテーブルでRow Level Security（RLS）を有効にし、次のような権限を設定します。
- 発注者は自分の案件だけ更新できる
- 受注者は応募可能な案件だけ閲覧できる
- 取引相手の連絡先は成約後だけ閲覧できる
- 決済状態はサーバー側だけ更新できる
- 管理者操作は監査ログへ残す
Supabaseも、公開スキーマで公開されるテーブルにはRLSを有効にするよう案内しています。Supabase RLS公式ドキュメント
よくある失敗と対策
失敗1：開発してから需要を探す
原因：サイトを作ることが目的になっている。
対策：実在案件3件と受注者3人を確認してからMVPを作る。
失敗2：対象業種が広すぎる
原因：「フリーランス全般」のように大手と同じ市場を選ぶ。
対策：技能、機材、地域、資格のうち2項目以上で絞る。
失敗3：自由記述が多く照合できない
原因：案件フォームを文章入力へ依存している。
対策：地域、資格、予算、納期を選択項目にする。
失敗4：決済成功だけ確認する
原因：返金、重複、順序逆転、本人確認未完了を想定していない。
対策：異常系を含むテスト表を作り、結果と証拠を保存する。
失敗5：完全放置を前提にする
原因：紛争や不正まで定型ルールへ任せる。
対策：自動化対象と人間判断対象を明文化する。
失敗6：マッチング数だけを追う
原因：成約しても運営対応が増え続ける。
対策：1取引あたり介在時間と例外率を同時に測る。
成果を測るKPI
| KPI | 計算方法 | 改善箇所 |
|---|---|---|
| 登録転換率 | 登録完了数÷訪問者数 | 訴求、登録フォーム |
| 有効案件率 | 条件を満たす案件数÷投稿数 | 集客先、入力チェック |
| 候補者充足率 | 候補者1人以上の案件数÷有効案件数 | 受注者開拓 |
| 通知開封率 | 開封数÷通知成功数 | 件名、通知時間 |
| 応募発生率 | 応募があった案件数÷通知案件数 | 報酬、条件、期限 |
| 成約率 | 成約数÷有効案件数 | マッチング精度 |
| 決済成功率 | 決済成功数÷決済開始数 | 決済導線 |
| 完了率 | 検収完了数÷決済済み案件数 | 品質、進行管理 |
| 紛争率 | 紛争件数÷完了取引数 | 規約、検収基準 |
| 自動処理率 | 人手なしの処理数÷全処理数 | 自動化範囲 |
| 例外率 | 管理キューへ送られた件数÷全処理数 | 失敗原因 |
| 1取引あたり介在時間 | 人間の対応時間÷完了取引数 | 運営効率 |
| 取引限界利益 | 手数料売上－変動費 | 採算性 |
立ち上げ直後の目標値は、市場実績ではなく仮説として設定します。
たとえば「候補者充足率80%以上」「決済成功率90%以上」「1取引あたり介在時間30分以下」と置き、実測値を見て修正します。母数が10件未満の段階では、率だけで判断せず、失敗案件の内容も確認してください。
証拠として残すべき実行ログ
記事や販売ページで信頼性を示すなら、完成イメージだけでなく、次の検証証拠を掲載します。
- 案件投稿から送金までのフロー図
- 案件登録画面
- 3テーブルの関係図
- Makeやn8nの実行履歴
- Stripeテスト環境の決済結果
- 条件一致・不一致のテスト表
- Webhook重複時の処理結果
- 通知失敗時の運営アラート
- KPIの集計期間と母数
- 人間が介在した理由の一覧
個人名、メールアドレス、アクセストークン、決済IDは必ず伏せます。
売上を掲載する場合は、対象期間、案件数、取引総額、返金額、手数料売上、決済費用を分けて表示してください。売上画面の一部分だけでは、収益性の証拠にはなりません。
反論・限界：自動化に向かないケース
ニッチ業種向けマッチングサイトは、すべての市場に向くわけではありません。
次の業種では、自動化できる範囲が狭くなります。
- 緊急対応が多い
- 現地確認なしでは見積もれない
- 成果の良否を客観的に判定できない
- 高額な損害が発生する可能性がある
- 法令上の仲介規制が強い
- 受注者が極端に少ない
- 発注頻度が低すぎる
ノーコードサービスにも、従量課金、処理上限、障害、仕様変更があります。取引数や権限ルールが増えたら、決済、認証、監査ログなど、重要部分から独自実装へ移す判断が必要です。
また、ニッチ市場は競合が少ない一方で、需要自体が小さい可能性があります。収益は保証されません。開発費を投入する前に、手作業のテスト取引で支払意思を確認してください。
まとめ：今日から始める3つのアクション
ニッチ業種向けマッチングサイトは、次の順番で作ります。
- 誰と誰をつなぐか定義する
- 発注者・受注者へ聞き取りを行う
- 契約、許認可、資金の流れを確認する
- 収益モデルと採算ラインを決める
- 3テーブルと状態遷移を設計する
- 登録・案件・応募画面を作る
- 条件照合と通知を自動化する
- 決済・返金・送金の異常系をテストする
- 小規模公開し、KPIと介在時間を改善する
今日行う作業は、次の3つだけです。
- 以下の一文を埋める
- 発注者候補1人へ連絡する
- 過去の実在案件を1件聞く
私は「＿＿＿＿で困っている発注者」と「＿＿＿＿ができる受注者」をつなぎ、＿＿＿＿の時点で手数料を受け取る。
ツール選定より先に、発注者へ「最後に依頼先を探したとき、どこで何日探しましたか」と聞いてください。
このサイト設計の差別化は、ツールを並べるだけでなく、状態遷移、異常系テスト、自動処理率、1取引あたり介在時間まで設計対象にすることです。
目標はサイトを所有することではありません。自分が画面を開いていない時間にも平常処理が進み、例外だけを安全に判断できる収益基盤を作ることです。
本気で自動化型の仕組みを構築したい方へ
「全体像は分かったが、データベース、LINE連携、決済、例外処理をどの順番で組めばよいか迷う」
その状態で止まると、マッチングサイトはアイデアのまま残ります。
必要なのは派手な成功談ではなく、登録、照合、通知、決済、報酬分配、保守をつなぐ実装手順と、正常系・異常系の検証記録です。
自動化型ビジネスの構築手順をまとめた実践マニュアルを、商品一覧ページで公開しています。