この型の要点
- ソフトの中核部分をオープンソースとして無償で公開し、企業が必要とする追加機能や運用サービスを有償で提供する型です。無償の部分が利用者を集め、有償の部分が収益を作ります。
- 無償で使う人の数と、有償に切り替える企業の数は別物です。個人や小規模チームに広く使われることと、企業の担当者が予算を通せる理由を用意することの両方が要ります。
- 「どこまでを無償にし、どこからを有償にするか」の線引きが、開発者コミュニティとの信頼関係と収益の両方を左右します。この線を一度引くと、後から動かすのは容易ではありません。
収益が生まれる仕組み
無償の中核は、誰でも入手して使え、改変も配布もできます。ここからは直接の収益は入りません。お金を払うのは、その中核を業務で使うことになった企業で、支払いの対象は主に次のいずれかです。
- 企業向けの追加機能。たとえば、社内の認証基盤との連携、操作履歴の保管、複数拠点での権限管理など、個人利用では不要で、組織で使うと必要になる機能です。
- 運用の引き受け。自社でサーバーを立てて保守する代わりに、提供側が動かして面倒を見る形で、月額や年額で課金します。
- 保守と問い合わせ対応の契約。障害時に応答時間を約束し、更新や脆弱性対応の案内を優先して受けられる契約です。
たとえば、社内の文書検索を行うソフトを開く場合、検索の中核は無償で公開し、企業が求める権限管理や監査の機能と、運用の代行を有償にする、という分け方になります。
お金が入るタイミングは、企業が試用を終えて本番で使う判断をした時点からで、契約を年単位にすれば更新のたびに入ります。費用がかかるのは、中核の開発そのもの、コミュニティからの質問や貢献への対応、有償機能の開発、そして企業向けの営業と契約手続きです。無償の利用者が増えるほど質問や報告への対応の手間は増えるのに、収益は有償契約からしか入らないため、この差をどう埋めるかが採算の中心になります。
成り立つ条件と、裏側の仕事
顧客側の条件は、中核を無償で試せることが導入の入り口として働くことです。企業の担当者が上司の承認を得る前に、自分の手元で動かして価値を確かめられると、有償の話に進みやすくなります。逆に、試用に専門知識が要りすぎると、無償公開が入り口として機能しません。
供給側、つまり自社の条件は、中核の開発を主導し続けられる技術力と、外部からの貢献を受け入れて品質を保つ運営力です。中核の設計や方向性を自社が決められる状態でないと、有償機能の計画も立てられません。
裏側で必ず必要になる仕事は、次のようなものです。
- 外部からの不具合報告や修正提案への対応。返事が遅れると貢献者が離れますが、これは直接の収益にならない仕事です。
- ライセンスの選択と管理。中核をどの条件で公開し、有償部分をどう区別するかは、後から変えると利用者の反発を招きます。
- 無償利用者と有償顧客の両方に向けた文書の整備。導入手順や設定の説明が整っているほど、問い合わせの人手が減ります。
- 有償機能の線引きを守る判断。コミュニティから「この機能も無償にしてほしい」という声が出たとき、収益と信頼の両方を見て決める仕事が続きます。
向く事業・向かない事業
向くのは、開発者や技術担当者が導入の判断に関わる分野です。無償の中核を自分で動かして評価するという行動は、技術者が自分で行いやすいものだからです。また、企業が本番で使う段になると、権限や監査、運用体制といった組織固有の要件が出てくる分野であれば、有償機能の境目を自然に引けます。
向かないのは、利用者が技術に詳しくなく、無償公開が入り口として働かない分野です。この場合、無償で公開しても試す人が現れず、結果として有償顧客も生まれません。また、中核の機能だけで企業の要件がほぼ満たされてしまう分野では、有償に切り替える理由が弱く、無償利用が増えるほど費用だけがかさみます。
もう一つの見方は、競合が中核を持ち出して同じサービスを始めたときに、自社に残る強みがあるかです。中核が公開されている以上、これは想定すべき事態で、運用の実績や有償機能の蓄積、コミュニティの中心にいることが強みになるかを考えます。
追いかける指標
- 有償転換率：中核を業務で使っている組織のうち、有償契約に進んだ割合です。分母を「ダウンロード数」ではなく「継続して動いている組織数」に近づける工夫が必要で、期間は四半期程度で見ます。
- 有償契約の継続率：契約中の企業が翌年も更新した割合です。分母は更新期を迎えた契約数とします。
- コミュニティの活性度：一定期間に外部から寄せられた不具合報告や修正提案の数と、それに初めて応答するまでの日数です。無償部分の健全さを示します。
- 問い合わせのうち有償契約からの比率：対応にかかった時間のうち、有償顧客に費やした割合です。無償側の対応に人手が偏っていないかを見ます。
- 中核の開発に占める自社の貢献比率：中核への変更のうち自社が行った割合です。主導権を保てているかの目安になります。
新規事業として小さく試すなら
- 中核として公開する範囲を決め、まず数人の外部の技術者に使ってもらいます。導入手順を見ただけで動かせるかを確かめ、つまずく箇所を文書で埋めます。動かせる人が現れれば次に進みます。
- 企業で使う場合に何が足りないかを、試した人に聞き取ります。「組織で使うなら必要」と複数の人が挙げた機能を、有償候補として書き出します。
- 有償候補のうち一つを、契約を前提に作ります。この段階で「無償の範囲で十分」と言われたら、線引きを見直す合図です。
- 有償契約の一件目を取り、契約に至った理由と、承認を得るまでにかかった期間を記録します。理由が再現できるものなら、有償機能の計画と営業の流れを整えて広げる段階に進みます。
設計時の注意点
価格については、有償の理由を「機能が多い」ではなく「組織で使うために必要」に置くと、企業の担当者が説明しやすくなります。個人が欲しがる機能を有償にすると、無償の利用者が離れ、入り口が細くなります。
契約については、無償部分に適用するライセンスの条件を最初に固めてください。中核を第三者が持ち出して競合するサービスを始めることを、ライセンスで制限するのか、それを受け入れて別の強みで戦うのかは、事業の性格を決める判断です。ライセンス条項の解釈や、契約書への反映は、個別に専門家へ確認してください。
運用については、無償の利用者からの問い合わせにどこまで応じるかの方針を、公開の場に書いておくことが大切です。方針がないと、有償顧客と同じ水準の対応を無償の利用者にも期待され、人手が持ちません。
また、外部からの貢献を受け入れる際には、貢献されたコードの権利の扱いを決めておく必要があります。後で有償機能に転用しようとしたときに問題にならないよう、貢献の受け入れ条件を最初から明示しておきます。
最後に、この型は中核の開発が止まると信頼を損ないます。有償機能の開発に人手を寄せすぎて中核が放置されると、コミュニティが離れて入り口がなくなります。開発の人手の配分を、収益の状況とは別に固定しておくことが、長く続けるための条件になります。
この型が見られる企業事例
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、収益の構造、成り立つ条件、検証の進め方を中心にまとめています。法務・税務・会計の制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.27