プラットフォーム事業の設計は、「誰と誰をつなぎ、何を交換させ、そのどこから収益を得るか」を決める作業です。自社が商品を仕入れて売るのではなく、参加者同士の取引ややり取りが生まれる場をつくり、その場の価値から収益を得る。そのため、機能や画面を考える前に、参加者の種類、それぞれが得る価値、取引の流れ、手数料の取り方、信頼の担保の仕方を整理しておく必要があります。
プラットフォームの設計で最も多い失敗は、片側の参加者の視点だけで考えることです。例えば発注者が便利になる仕組みを考えても、受注者側が参加する理由がなければ取引は生まれません。また、手数料を取りやすい場所に課金を置いた結果、参加者が場の外で直接取引するようになる、ということも起こります。設計では、すべての参加者にとって「この場を使い続ける理由」があるかを確かめます。
この記事は、マッチングサービス、マーケットプレイス、業界向けの取引・情報共有の場など、プラットフォーム型の事業を企画している事業責任者や新規事業担当者に向けて、参加者の関係の整理、価値の交換、収益構造の決め方、立ち上げの順序、信頼の設計を、判断基準とよくある失敗とともに解説します。
プラットフォームビジネスとは何か
プラットフォームビジネスは、複数の種類の参加者を同じ場に集め、その間で取引や情報のやり取りを成立させることで価値を生む事業です。代表的な形として、売り手と買い手をつなぐマーケットプレイス、仕事の発注者と受注者をつなぐマッチング、ユーザーと開発者をつなぐアプリの配信基盤などがあります。
一般的な販売の事業との最大の違いは、参加者が増えるほど場の価値が高まる性質を持つことです。買い手が多い場には売り手が集まり、売り手が多い場には買い手が集まります。この性質は、うまく回り始めれば強い競争力になりますが、立ち上げの段階では「どちらもいないので、どちらも来ない」という問題を生みます。
| 観点 | 一般的な販売事業 | プラットフォーム事業 |
|---|---|---|
| 価値の源泉 | 自社の商品・サービス | 参加者同士の取引・やり取り |
| 顧客の種類 | 主に一種類 | 二種類以上(売り手と買い手など) |
| 在庫・提供の責任 | 自社が持つ | 主に参加者が持つ(形態による) |
| 収益の取り方 | 販売価格と原価の差 | 取引手数料、掲載料、会費など |
| 立ち上げの難しさ | 顧客の獲得 | 複数の参加者を同時に集める必要 |
参加者の種類と関係を整理する
プラットフォームの設計は、参加者を洗い出すところから始めます。
参加者を洗い出す手順
- 取引の当事者を書き出す:売り手と買い手、発注者と受注者、貸し手と借り手など、取引の両側にいる人を書きます。
- 取引を支える参加者を書き出す:決済、配送、保険、審査、広告主など、取引そのものではないが場に関わる参加者を書きます。
- それぞれの立場を細かく分ける:同じ「売り手」でも、個人と法人、本業と副業では、求めるものが大きく異なります。最初に狙う参加者の層を絞ります。
- 参加者同士の関係を図にする:誰から誰に、何が(商品、サービス、お金、情報、評価)流れるかを矢印で描きます。
- 自社の位置を決める:取引にどこまで関わるか(紹介だけか、契約や決済まで仲介するか、品質の保証まで担うか)を決めます。
参加者を細かく分ける作業は特に重要です。例えば、家事の代行を個人に依頼する場を考える場合、受注者が「家事の経験を活かして空いた時間に働きたい個人」なのか「事業として家事代行を営む事業者」なのかで、求める仕事の量、価格、支払いの頻度、必要な保険や契約が変わります。両方を最初から対象にすると、どちらにとっても中途半端な場になりがちです。
自社が取引にどこまで関わるか
| 関与の深さ | 自社の役割 | 向いている場面 | 負う責任と負担 |
|---|---|---|---|
| 情報の掲載 | 参加者の情報を載せ、つなぐだけ | 取引の金額が大きく、条件交渉が個別に必要 | 小さい。ただし場の外での取引を防ぎにくい |
| 取引の仲介 | 申し込み、連絡、決済を場の中で行う | 取引が定型的で、繰り返し発生する | 決済や紛争への対応が必要 |
| 品質の保証 | 参加者の審査、品質の基準、保証の提供 | 品質のばらつきが取引の障害になっている | 審査や保証の運用が重い |
| 実質的な提供者 | 自社が提供責任を持ち、参加者は実務を担う | 顧客が品質の一貫性を強く求める | 一般的な販売事業に近い責任を負う |
関与を深くするほど、参加者にとっての安心感は増し、手数料を取る根拠も強くなりますが、運用の負担と責任も大きくなります。仲介する取引の種類によっては、許認可や登録が必要になる場合もあるため、事業の形を決める段階で、該当する法令を専門家や公的窓口に確認してください。
価値の交換を設計する
参加者を整理したら、それぞれの参加者が場から何を得るのか、なぜ場を使い続けるのかを書き出します。
参加者ごとの価値を書き出す
価値は「場がない場合と比べて、何が良くなるか」で考えます。
- 探す手間の削減:自分で相手を探す、比較する、問い合わせる手間が減る。
- 選択肢の広がり:自分の人脈や地域の外の相手と出会える。
- 取引の安全:支払いの保証、評価の仕組み、紛争時の対応がある。
- 事務の削減:契約、請求、支払い、記録などの事務を場が代行する。
- 収入の機会:売り手や受注者にとって、新しい顧客や仕事に出会える。
ここで確かめたいのは、両側の参加者にとって、価値が十分に大きいかどうかです。片側にとっては便利でも、もう片側にとっては「手数料を取られるだけ」と感じられるなら、その参加者は場に定着しません。
場を使い続ける理由をつくる
プラットフォームでは、最初の取引が成立した後、参加者同士が場の外で直接やり取りするようになる「中抜き」が起こりやすくなります。特に、継続的な関係が生まれやすい取引(同じ家庭教師に毎週頼む、同じ業者に定期的に発注するなど)では、手数料を避けるために場の外へ出る誘因が強くなります。
中抜きを完全に防ぐことは難しいため、場の中にいることの価値を高める方向で考えます。
- 支払いや請求の事務を場の中で完結でき、外でやるより楽である
- 取引の記録が残り、確定申告や経費精算に使える
- 評価が蓄積され、受注者にとって新しい仕事の獲得につながる
- トラブル時の補償や仲裁を受けられる
- 予定の管理や連絡の機能が、外の手段より便利である
収益構造の決め方
プラットフォームの収益の取り方には、いくつかの型があります。どの型が合うかは、取引の頻度、金額、参加者の性質、場が提供する価値によって変わります。
| 収益の型 | 内容 | 向いている場面 | 注意点 |
|---|---|---|---|
| 取引手数料 | 成立した取引の金額に応じて手数料を取る | 取引が場の中で完結し、金額が把握できる | 中抜きの誘因になる。手数料の根拠を示す必要 |
| 掲載料・出店料 | 掲載や出店に対して固定の料金を取る | 取引の金額が大きい、場の外で取引が完結する | 成果が出ないと掲載をやめられやすい |
| 会費・月額 | 参加者に定額の会費を課す | 継続的に場を使う参加者が多い | 参加の敷居が上がり、立ち上げ期に集まりにくい |
| 成果報酬 | 紹介や成約に対して報酬を取る | 一件あたりの価値が大きい(人材、不動産など) | 成約の把握と、報酬の支払い漏れへの対策 |
| 付加サービス | 決済、保険、広告、分析などを有料で提供 | 基本機能は無料で参加者を集めたい | 付加サービスの需要を見極める必要 |
どちらの参加者から取るか
収益の型と同時に、どちらの参加者から料金を取るかを決めます。一般に、場への参加をより強く必要としている側、取引から得る価値が大きい側から取ることが多くなります。逆に、集めるのが難しい側、場への参加をためらいやすい側は、無料や低い料金にして参加を促します。
例えば、多数の個人の買い手と少数の事業者の売り手をつなぐ場では、買い手は無料にし、売り手から手数料を取る形がよく見られます。一方、専門性の高い受注者が少なく、発注者が多い場では、発注者から料金を取り、受注者を優遇して集める考え方もあります。
手数料の水準の決め方や見直しの考え方は、マーケットプレイスの手数料設計と、用語ページのテイクレートで詳しく扱っています。具体的な水準は、参加者が場から得る価値、場の外で取引する場合の手間や費用、運営にかかる費用から考え、一律の相場に合わせるのではなく、自社の場の価値で説明できる水準にすることが大切です。
立ち上げの順序と信頼の設計
どちらの参加者から集めるか
プラットフォームの立ち上げでは、両側の参加者を同時に集める必要がある、という問題に直面します。この問題への対処の考え方はマッチングサービスの「鶏と卵」問題で詳しく解説していますが、設計の段階で決めておきたいのは次の点です。
- 先に集める側を決める:一般に、集めるのが難しい側、供給側(売り手や受注者)を先に集めることが多くなります。供給が揃っていない場に買い手を呼んでも、期待外れで離れてしまうためです。
- 範囲を狭く始める:地域、業種、取引の種類を絞り、狭い範囲で両側の密度を高めます。全国・全業種で薄く始めるより、特定の地域や業種で取引が成立する状態を先に作ります。
- 場がなくても価値がある機能を用意する:供給側にとって、取引がなくても使える機能(予約の管理、顧客の管理、見積もりの作成など)があると、先に参加してもらいやすくなります。
- 運営が手作業で仲介する:最初は運営者が手作業で相手を探し、紹介し、取引を成立させます。どんな取引が成立しやすいか、どこでつまずくかを学ぶ機会にもなります。
- 取引が自然に回り始めたら範囲を広げる:運営の手作業がなくても取引が成立するようになった段階で、隣の地域や業種に広げます。
信頼と安全の設計
プラットフォームでは、見知らぬ参加者同士が取引をするため、信頼の仕組みが場の価値を大きく左右します。信頼の設計は、機能の追加ではなく、事業の設計そのものとして考えます。
- 参加時の確認:本人確認、事業者の登録情報の確認、資格や許可の確認など、参加者の素性をどこまで確認するか。
- 取引中の保護:代金を一時的に預かり、取引の完了後に支払う仕組み、キャンセルの規定など。
- 取引後の評価:相互の評価、口コミ、問題のあった参加者への対応。
- 問題が起きたときの対応:問い合わせの窓口、紛争の仲裁、補償の範囲、利用規約での責任の範囲。
- 禁止事項と監視:禁止する取引や行為を定め、どう発見し、どう対応するか。
信頼の仕組みは、強くするほど参加の手間が増え、参加者が集まりにくくなるという関係があります。取引の金額やリスクの大きさに応じて、どこまでの確認と保護が必要かを決めます。具体的な設計の論点はマッチングサービスの信頼性と安全の設計で詳しく扱っています。
具体的な場面の例:地域の農家と飲食店をつなぐ場
架空の例として、地方都市で、近隣の農家と飲食店をつなぎ、野菜の直接取引ができる場を企画しているチームを考えます。
チームは最初に参加者を洗い出しました。取引の当事者は農家と飲食店です。取引を支える参加者として、配送を担う地元の運送業者と、決済の仕組みが挙がりました。さらに参加者を細かく分けると、農家には「少量でも珍しい野菜を作る小規模農家」と「量を安定して出せる中規模農家」、飲食店には「地元の食材にこだわる個人店」と「仕入れの安定を重視するチェーン店」がいることが分かりました。
チームは最初の参加者を、小規模農家と地元の食材にこだわる個人店に絞りました。個人店は珍しい野菜を少量ずつ使いたい一方、農家を自分で探す手間と、少量の注文を受けてもらえるかという不安を抱えていました。小規模農家は、既存の流通では値がつきにくい珍しい野菜を、価値を分かってくれる相手に売りたいと考えていました。
収益の取り方として、チームは飲食店からの取引手数料を中心に置き、農家の参加は無料にしました。農家は集めるのが難しく、ITへの抵抗感も大きいため、参加の敷居を下げることを優先したのです。また、配送と代金の回収を場の中でまとめて行うことで、農家にとっては請求や集金の手間がなくなり、飲食店にとっては複数の農家からの仕入れを一つの請求にまとめられる、という場の中にいる理由をつくりました。
立ち上げでは、運営メンバーが農家を一軒ずつ訪ねて参加をお願いし、最初の数か月は電話とメッセージで注文を受けて手作業で仲介しました。取引が繰り返されるうちに、飲食店が定期的に頼む野菜と、注文が集中する曜日が見えてきたため、チームはそれをもとに、最初のシステムで作る機能を「定期注文」と「配送のまとめ」に絞ることにしています。
信頼の仕組みについても、チームは最初から大がかりな審査を設けず、運営メンバーが農家を訪ねた際に栽培の様子と出荷の体制を確認することで代えました。一方、代金は場が飲食店から回収してから農家に支払う形にし、農家が未払いの心配をしなくてよいようにしています。品質に関する苦情が出た場合の対応も、最初の数件は運営が間に入って農家と飲食店の双方に事情を聞き、その経験をもとに返品や値引きの規定を利用規約に書き加えていく方針です。
この例のように、最初の参加者を絞り、運営の手作業で取引の流れを学んでから機能を決めると、作ったシステムが実際の取引に合わないという事態を避けやすくなります。チェーン店や中規模農家への拡大は、小規模な取引で回り始めた後の次の段階として、ロードマップに置いています。
よくある失敗と避け方、設計のチェックリスト
よくある失敗
- 片側の参加者の視点だけで設計する:もう片側に参加する理由がないと、取引は生まれません。参加者ごとに価値を書き出し、両側にとって十分かを確かめます。
- 最初から対象を広げすぎる:参加者がまばらに散らばり、どこでも取引が成立しません。地域や業種を絞って密度を高めます。
- 手数料を取ることだけを考える:場の中にいる理由がないまま手数料を課すと、中抜きが進みます。場の中で取引する方が便利な仕組みを先に設計します。
- 信頼の仕組みを後回しにする:最初の大きなトラブルで場の評判が損なわれると、立て直すのは困難です。取引の金額とリスクに応じた最低限の仕組みを最初から用意します。
- システムを先に作り込む:取引の流れが分からないうちに多機能なシステムを作ると、実際の取引に合わない部分が多く出ます。手作業での仲介で流れを学んでから作ります。
設計のチェックリスト
- 取引の当事者と、取引を支える参加者を洗い出した
- 最初に狙う参加者の層を絞った
- 参加者同士の関係と、お金・商品・情報の流れを図にした
- 自社が取引にどこまで関わるかを決めた
- 参加者ごとに、場から得る価値を書き出した
- 場の中で取引を続ける理由を設計した
- 収益の型と、どちらの参加者から料金を取るかを決めた
- 先に集める参加者と、立ち上げの範囲を決めた
- 取引の金額とリスクに応じた信頼の仕組みを決めた
- 必要な許認可や法令上の論点を専門家に確認した
よくある質問
Q. プラットフォーム事業は、どのくらいの規模になれば黒字化しますか?
取引の金額、手数料の水準、運営にかかる費用によって大きく異なり、一律には言えません。設計の段階では、一件の取引から得られる収益と、一件の取引を成立させるためにかかる費用(参加者の獲得、仲介、問い合わせ対応など)を比べ、取引が増えるほど一件あたりの費用が下がる構造になっているかを確認します。
Q. 既存事業の顧客を参加者にしてもよいでしょうか?
既存事業の顧客を片側の参加者として呼び込めることは、立ち上げの大きな強みになります。ただし、既存事業と競合する取引が場の中で生まれる場合や、既存の取引先との関係に影響する場合があるため、事前に既存事業の部門と調整しておきます。
Q. 最初からアプリを作るべきですか?
多くの場合、最初からアプリを作る必要はありません。取引の流れが固まるまでは、Webの画面や既存のメッセージツール、手作業での仲介で始め、参加者の使い方が分かってからアプリの必要性を判断する方が、投資の無駄を減らせます。
Q. 手数料は後から変えられますか?
変えることはできますが、参加者の反発や離脱を招くおそれがあります。特に値上げの場合は、場が提供する価値の向上とセットで説明し、十分な告知期間を設けることが大切です。利用規約の変更の手続きについては、専門家に確認してください。
Otsumuに相談できること
プラットフォーム事業の設計は、参加者の層を絞り、両側の参加者に話を聞き、手作業での仲介から始められる体制があれば、自社で進めることができます。この記事のチェックリストに沿って参加者と価値の交換を整理し、狭い範囲で最初の取引を成立させてみることが第一歩です。
一方で、参加者の整理や収益の取り方について判断の軸が定まらない、手作業での仲介を経て取引の流れが見えてきたがシステムにする段階で何から作ればよいか分からない、決済や信頼の仕組みを含めた開発の体制がない、という場合は、事業の設計とシステムの開発の両方を見られる外部の支援が役に立ちます。
Otsumuは新規事業開発コンサルティングで、参加者の整理、価値の交換と収益構造の設計、立ち上げの順序の検討を伴走します。取引の流れが固まった段階では、マッチングシステム開発や、AIを活用した少人数・短期間の新規事業の爆速MVPシステム開発で、最初に必要な機能に絞った開発を進められます。
構想の段階でも、立ち上げの途中でも構いません。30分の無料相談で、つなぎたい参加者と今の状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆:Otsumu株式会社 / 編集日 2026.10.01