マッチングプラットフォーム公開前に決めるべき5つのポリシー：手数料漏れと品質崩壊を防ぐ運用ルール

核心要約

ペットシッター、家庭教師、インテリア、清掃、レッスン、ケアのように、人と人をつなぐマッチングプラットフォームは、機能だけでは運営できません。予約、決済、プロフィール、チャット、レビュー機能をAIで素早く作ることはできますが、プラットフォームの収益と信頼を守るのはコードではなくポリシーです。

特にマッチングプラットフォームの売上は、その大半が取引手数料から生まれます。供給者と需要者がプラットフォームを通じて初めて出会った後、外部の連絡先を交換して直接取引を始めると、プラットフォームは顧客獲得コストと運営コストだけを負担し、売上は失うことになります。したがって、公開前にマーケットプレイスのルールを先に定め、そのルールを機能要件に変換してAIと開発チームに伝える必要があります。

マッチングプラットフォームはなぜ一般的なWebサイトと違うのか

両面市場の構造

マッチングプラットフォームは、片側だけを満足させればよいサービスではありません。需要者と供給者の両方が顧客です。

この構造では、機能よりもルールが重要になる瞬間が多くあります。例えば「シッター一覧を表示する」という機能は簡単ですが、誰を先に表示するかは事業の核心です。返信率が高くレビューの良いシッターを上に出すのか、新規シッターにも機会を与えるのか、広告商品を入れるのかによって、マーケットプレイスの信頼と収益構造が変わります。

機能だけのプラットフォームが失敗する3つのパターン

1. 表示順がないと良い供給者が離れる

登録された順番でだけ供給者を表示すると、一生懸命働いた人と放置されたアカウントが同じ扱いを受けます。評価4.9点、レビュー47件、素早い返信率を持つシッターが下に押し出され、レビューのないアカウントが上位に表示されることがあります。

このような構造では、供給者が良いレビューを積み上げ、素早く返信する理由が弱くなります。需要者も「なぜこの人が先に表示されるのか？」という不信感を持つようになります。表示ポリシーは検索品質、供給者のモチベーション、顧客の信頼を同時に左右します。

2. 連絡先が早すぎる段階で公開されると手数料が漏れる

チャットが自由で、決済前に連絡先が露出すると、「アプリではなく直接連絡してくれればもっと安くします」という会話が簡単に発生します。このときプラットフォームは、探索、推薦、信頼形成、カスタマーサポートのコストを負担したにもかかわらず、実際の売上は得られません。

直接取引は単なる手数料損失だけを生むわけではありません。外部で取引が行われると、返金、安全事故、ノーショー、サービス品質の問題をプラットフォームが確認したり仲裁したりすることが難しくなります。結局、需要者と供給者の双方が保護の仕組みの外に出てしまいます。

3. キャンセルポリシーがないと一方が一方的に損をする

当日キャンセルでも全額返金されるなら、供給者は1日の予定を空けておいたにもかかわらず、補償を受けられない可能性があります。反対に、供給者が突然キャンセルしたのに何のペナルティもなければ、需要者は重要な予定を台無しにされる可能性があります。

キャンセルポリシーは、顧客フレンドリーさと供給者保護の間のバランスです。基準がなければ、毎回運営者が感情的に判断しなければならず、同じ事案に異なる結論が出て不公平だという議論が生じます。

公開前に定めるべき5つの必須ポリシー

1. 表示順：誰が上位に表示されるのか

表示順はプラットフォームの報酬体系です。上位表示をどの行動の結果として与えるのかを先に定める必要があります。

推奨基準

• 直近の返信率
• 平均返信時間
• レビュー評価
• レビュー数
• 直近の活動日
• 予約完了率
• キャンセル率
• 通報または紛争履歴
• 新規供給者かどうか

ポリシー例

重要な原則

表示基準を完全に公開しないとしても、主要な要素は画面上で説明するのが望ましいです。例えば「返信率、レビュー、直近の活動、予約完了率を総合しておすすめ順が決まります」と案内すれば、供給者はどのような行動をすべきか理解できます。

2. マッチング方式：自動割り当てか、応募と選択か

マッチング方式は、顧客体験と責任構造を決定します。

信頼が重要なサービスであれば、「応募と選択」方式が有利です。飼い主や保護者がプロフィール、レビュー、経歴、対応可能時間、価格を直接比較して選択すれば、心理的な安心感が大きくなります。一方、自動割り当ては速いものの、結果が気に入らないときに「プラットフォームが誤って割り当てた」という不満が大きくなる可能性があります。

3. キャンセルポリシー：いつ、いくら返金するのか

キャンセルポリシーは必ず決済前に表示し、同意を得なければなりません。決済後になって初めて返金制限を知ると、紛争の可能性が高まります。

キャンセル・返金基準の例

上記の数字は例であり、実際の比率はサービスの特性、地域の規制、決済代行会社のポリシー、顧客の期待水準に合わせて定める必要があります。

供給者キャンセルのペナルティ

供給者に無条件で金銭的な罰則を課す方式は、法的・運営上の負担が生じる可能性があります。初期には、次のような非金銭的ペナルティのほうが実用的な場合があります。

• 推薦スコアの減点
• 一定期間、上位表示から除外
• 繰り返しキャンセルした場合、新規予約を制限
• 顧客への自動お詫びクーポン提供の可否を検討
• 運営者の検討後、アカウント警告または停止

4. 手数料と直接取引防止：防ぐことより保護の利益を設計すべき

手数料率は事業モデルによって異なります。例えば10%、15%、20%のうち何を選ぶかは、顧客獲得コスト、決済手数料、カスタマーサポート費用、保険または保証費用、供給者のマージンを考慮して定める必要があります。

問題は手数料率そのものよりも直接取引です。直接取引の防止は、単に電話番号を隠す機能ではなく、「プラットフォーム内で取引するほうがより安全で有利だ」という構造を作ることです。

必要な機能とポリシー

警告文言の例

「安全のため、決済前の連絡先と口座番号の共有は制限されています。プラットフォーム外で取引すると、返金、紛争仲裁、取引記録の保護を受けられません。」

この文言の核心は「しないでください」ではなく、「アプリ内で決済すれば保護されます」です。需要者と供給者がプラットフォーム内取引の利益を理解してこそ、直接取引の誘惑が減ります。

5. 紛争と精算：お金をいつ支払うのか

紛争仲裁の実質的な力は精算構造から生まれます。決済金額がサービス完了直後に供給者へ全額支払われると、問題が発生したときにプラットフォームが返金や一部返金を執行することが難しくなります。

したがって、多くのマッチングプラットフォームは、決済後に一定期間金額を保管したり、支払いを保留したりする構造を置いています。一般にエスクローに類似した概念として説明されますが、実際にどのような方式が可能かは、決済代行会社の約款と各地域の金融・電子商取引規制を確認する必要があります。

精算ポリシー例

48時間は例です。サービスの特性によって、24時間、72時間、7日などに変わる可能性があります。ペットケアやインテリアのように、問題が後から発見される可能性のあるサービスでは、より長い確認期間が必要になる場合があります。

運営者画面に必ず必要な紛争データ

紛争を適切に処理するには、運営者が1つの画面で事案の文脈を確認できる必要があります。

運営者の決定理由を記録することは非常に重要です。「なぜ全額返金したのか」、「なぜ一部返金したのか」、「なぜ供給者責任と判断したのか」が残ってこそ、一貫した運営基準が生まれます。

AI開発プロンプトに入れるべきポリシー要件

AIに「予約、決済、チャット機能を作って」とだけ指示すると、マーケットプレイスの核心的なルールが抜ける可能性が高くなります。以下のようにポリシーを明示する必要があります。

プロンプト例

ペットシッターマッチングプラットフォームを作る。単純な機能実装ではなく、以下の運営ポリシーを反映して設計してほしい。

1. シッター一覧は、返信率、レビュー評価、レビュー数、直近の活動日、予約完了率を総合して基本ソートする。
2. 新規シッターがレビュー不足によって完全に押し下げられないよう、別途新規シッター領域に表示する。
3. マッチングは、飼い主がリクエストを投稿するとシッターが応募し、飼い主がプロフィールとレビューを見て選択する方式にする。
4. 決済前にキャンセル・返金ポリシーを画面に表示し、同意を得る。
5. 決済前は電話番号、メール、口座番号、外部メッセンジャーIDの共有を制限する。
6. チャットで連絡先または口座番号のように見えるパターンが検知されたら、直接取引の警告文言を表示する。
7. サービス完了後48時間は精算を保留し、この期間に紛争が受け付けられた場合は精算を止める。
8. 運営者は予約情報、決済状態、チャット記録、証拠ファイル、決定理由を1つの画面で確認できなければならない。

実装する前に、私が定めていないポリシーのうち決定が必要なものがあれば、先に質問してほしい。

最後の文は重要です。AIが抜けているポリシーを質問するようにしなければ、開発成果物は単なる画面の集まりではなく、運営可能なプラットフォームに近づきます。

データモデルに置き換えて考える

ポリシーは最終的にデータとして残らなければなりません。以下の項目は、Ruby on RailsのようなWebフレームワークでも、基本テーブルと状態値で実装できる構造です。

このように設計すれば、運営ポリシーがコードのあちこちに散らばるのではなく、状態と記録として管理されます。

公開前チェックリスト

• 基本ソート基準を定めたか？
• 新規供給者に表示機会を与える方法があるか？
• 自動マッチング、応募と選択、混合型のうちどの方式かを定めたか？
• 顧客キャンセルと供給者キャンセルを区別したか？
• 返金比率と時点を決済前に告知するか？
• 決済前の連絡先と口座番号の共有を制限するか？
• 直接取引の警告文言が、処罰よりも保護の利益を説明しているか？
• プラットフォーム手数料率と精算金額の計算式が明確か？
• サービス完了後の精算保留期間があるか？
• 紛争受付時に精算を自動で止められるか？
• 運営者が証拠とチャット記録を1つの画面で確認できるか？
• 運営者の決定理由が記録されるか？
• AIまたは開発チームに「定めていないポリシーは先に質問せよ」と要求したか？

結論

マッチングプラットフォームの初期開発で最も危険な錯覚は、「機能があればマーケットプレイスは回る」という考えです。実際にマーケットプレイスを動かすのは、表示、マッチング、キャンセル、手数料、精算、紛争処理のようなルールです。

AIはコードを素早く作ることができますが、どの行動に報酬を与え、どのリスクを防ぐかは創業者が決めなければなりません。公開前に5つのポリシーを文書化し、それを画面・状態値・管理者機能・顧客向け案内文言につなげてこそ、手数料が漏れず、サービス品質も維持されます。