この型の要点
- 自社が持つ基盤（端末、業務ソフト、サービス）の上で動くアプリや拡張機能を、外部の開発者が配信できる場を用意します。利用者はその場から安全に入手でき、開発者は集客と決済を自分で作らずに済みます。
- 収益は、アプリの販売額やアプリ内の課金額に対する手数料が中心で、開発者の登録料や、目立つ位置への掲載料を組み合わせることがあります。審査と決済を自社が握ることが、手数料を受け取れる根拠になります。
- 成り立つ条件は、開発者が作る動機を持てるだけの利用者数が基盤側にあり、利用者がその場を通して入手する理由（安全性・手軽さ・一括の支払い）があることです。
収益が生まれる仕組み
お金の流れは、利用者が支払い、運営側が決済を行い、手数料を差し引いて開発者へ分配する形です。利用者から見ると、支払い先は運営側の一つにまとまります。開発者から見ると、売上の一部を手数料として払う代わりに、決済・配信・利用者への到達を運営側に任せられます。たとえば、地域の飲食店向けに予約管理を提供する事業者が、外部の開発者に会計連携や顧客分析といった追加機能を作って配信させる場合、追加機能の月額料金から手数料を受ける形が考えられます。
入金は利用者の支払い時点で運営側に入り、開発者への分配は月ごとなど締めてから行うため、この時間差の間は運営側が資金を預かる状態になります。返金や取り消しがあった場合の分配の戻しも、ここで処理します。
費用は、審査を行う人手と手順の整備、決済の手数料と不正対策、配信の基盤の開発と運用、開発者向けの技術文書と問い合わせ対応、税務や請求の処理にかかります。開発者向けの支援は表に見えにくいですが、開発者が離れるかどうかを決める費用です。
成り立つ条件と、裏側の仕事
利用者側の条件は、基盤そのものに日常的に触れていて、そこで追加の機能を探す習慣が生まれることです。開発者側の条件は、その基盤の利用者に売れば回収できると見込めること、そして自分で販路や決済を持つより手数料を払うほうが得だと判断できることです。自社の能力としては、外部の開発者が安全に作れる技術的な土台、審査の判断基準を維持する体制、そして基盤本体の開発と場の運営を両立させる余力が必要です。
裏側の仕事の第一は、審査です。動作の確認、利用者の情報の扱い、基盤本体への悪影響、規約違反の有無を一件ずつ見ます。審査が厳しすぎれば開発者が離れ、緩すぎれば利用者の信頼が失われるため、基準そのものを継続的に見直す仕事になります。第二は、開発者向けの仕組みの整備です。連携の仕様、テスト環境、公開の手順、売上の確認画面などがないと、開発者は作れません。基盤本体を変更するたびに、既存のアプリが動かなくなる影響も管理する必要があります。第三は、決済と分配の運用です。返金、取り消し、不正な購入、通貨や税の扱いを含めて、開発者ごとに正確に計算し支払います。第四は、場の中での発見のしやすさです。アプリが増えるほど、利用者が目的のものを見つけられなくなり、検索・分類・おすすめの設計が必要になります。第五は、自社と開発者の役割の線引きです。自社が同じ機能を本体に組み込めば、開発者の売上を奪うことになります。どこまでを自社が作り、どこからを開発者に任せるかの方針が、開発者の参加意欲を左右します。
向く事業・向かない事業
向くのは、既に一定の利用者を持つ基盤があり、利用者の要望が多様で、自社だけでは全てに応えられない事業です。業種特化の業務ソフトや、利用者が日常的に使う端末やサービスなど、利用者ごとに欲しい追加機能が異なる場合、外部の開発者に任せることで対応範囲が広がります。利用者が支払いを一つにまとめたいと考える状況も、この型に向きます。
向かないと考えられるのは、基盤の利用者がまだ少なく、開発者が回収の見込みを持てない段階の事業です。開発者を先に集めても、利用者がいなければ場は成り立ちません。利用者の要望が均質で、自社だけで十分に応えられる場合も、場を作る費用に対して得るものが少なくなります。また、審査や開発者支援に人手を割けない状況で始めると、品質の低いアプリが並び、基盤本体の評判を落とす結果になり得ます。
追いかける指標
- 開発者の登録数と公開までの到達率：登録した開発者のうち、実際にアプリを公開した割合。登録した月ごとに追います。
- 審査にかかる日数：申請から公開可否の連絡までの日数。中央値と、長くかかった案件の理由を併せて見ます。
- 利用者のうち導入した割合：基盤の利用者のうち、一つ以上のアプリを導入している割合。分母は当該期間の利用者数です。
- 取扱高と手数料収益：期間内に場を通じて発生した売上の総額と、そこから受けた手数料。アプリの分類ごとに見ます。
- 開発者の継続率と売上の分布：翌期も公開を続けた開発者の割合と、売上が少数の開発者に集中しているかどうか。
- 返金・苦情の割合：購入件数に対する返金件数と、利用者からの苦情件数。審査基準の妥当性の代理指標になります。
新規事業として小さく試すなら
- 自社の基盤の利用者に対して、欲しいが自社では対応できていない機能を聞き取り、外部に任せられそうな領域を数個に絞ります。
- 開発者を数社または数人、直接声をかけて集め、限定した連携の仕様を提供して一つずつ機能を作ってもらいます。この段階では審査も分配も人手で行い、二〜四週間で公開まで到達できるかを見ます。
- 公開した機能を利用者に有料で提示し、導入と支払いが起きるかを確かめます。利用者が場を通して買う理由があるのか、開発者が手数料を払っても続ける意思があるのかが、ここで分かります。
- 支払いと継続の両方が確認できたら、審査の基準、分配の計算、開発者向けの手順を文書にし、開発者を少しずつ増やします。この時点で、審査と支援にかかる人手の実測値が得られます。
設計時の注意点
価格の面では、手数料の率と、それに含まれるもの（決済、配信、支援）を開発者に明確に示します。手数料の変更は開発者の事業計画を直接揺らすため、変更の予告期間と適用の仕方を最初に決めておくことが望まれます。
契約の面では、開発者との規約に、審査の基準、公開の停止や削除の条件、利用者の情報の扱い、売上の分配と返金時の取り扱い、開発者が自社の商標をどう使えるかを含めます。開発者が他の販路でも同じアプリを配信できるかどうかも、明示しておく必要があります。
運用の面では、基盤本体を更新するたびに既存のアプリへ影響が出ます。更新前の告知、互換性を保つ期間、開発者側の確認期間を運用の決まりにしておかないと、利用者側で機能が突然使えなくなる事態が起きます。
法規制の面では、決済を自社で行う場合の資金の扱い、開発者への分配に伴う税務、利用者の情報の第三者への提供に関する取り扱いなど、複数の観点が関わります。場の設計が固まった段階で、個別に専門家へ確認してください。
この型が見られる企業事例
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、収益の構造、成り立つ条件、検証の進め方を中心にまとめています。法務・税務・会計の制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.27