マイクロSaaSとは
マイクロSaaSに厳密な公的定義はありません。実務では、特定業務の小さな問題を解くこと、創業者または少人数で運営すること、サブスクリプションなどの継続収益を持つこと、外部資金に頼らず成長できる規模を目指すことが共通点です。会社の売上や社員数だけで線を引くより、「誰の、どの作業を、どこまで引き受けるか」が限定されているかで判断するとわかりやすくなります。
たとえば、あらゆる企業の経営管理を扱う製品は対象範囲が広くなります。一方、EC担当者が商品画像を定型サイズへ変換する作業だけを自動化する製品は、顧客と仕事の境界が明確です。市場全体は小さく見えても、繰り返し発生する痛みが強ければ継続課金は成立します。
小さいことは目的ではない
「マイクロ」は事業を小さく保つ義務ではなく、複雑さを管理する手段です。顧客が増えても、個別開発や手作業のサポートが同じ割合で増えない設計が重要になります。顧客ごとに仕様を変え、創業者が毎回セットアップを代行するなら、売上が伸びるほど運営が苦しくなります。これはSaaSというより受託サービスに近い状態です。
SaaSの事業モデルと比べると、マイクロSaaSは市場の大きさより、少人数で保守できる範囲を先に決めます。大企業向けの多機能製品を縮小するのではなく、ひとつの業務から出発する点が違いです。
実例から見る収益化
小規模SaaSは売上を公開しないことも多いため、ここでは創業者や運営会社が経緯を公開している事例を使います。数字は企業規模の優劣を示すものではなく、課題の絞り方と収益化の順番を確認する材料です。
Plausibleは機能を絞った
Plausible Analyticsは、Webサイト分析を提供するブートストラップ型のSaaSです。同社の創業者は、最初の月間経常収益400ドルまで324日、その後10,000ドルへ到達するまで約9カ月かかったと振り返っています。2022年には年間経常収益100万ドルに到達し、当時は4人のチームでした。
重要なのは数字より選択です。Plausibleは、大規模な広告分析基盤と同じ機能数を目指さず、軽量さ、プライバシー、わかりやすさを中核に置きました。狭い価値を選んだから、製品説明と顧客獲得の軸をそろえられた例です。ただし、現在のPlausibleはチームも事業も成長しています。固定された「零細企業」ではなく、小さく始めて運営可能な範囲を広げた事例として見るべきでしょう。
Inkdropは価格と顧客を選び直した
日本の個人開発者・松山卓也氏が運営するMarkdownノートアプリInkdropは、開発者向けという対象を明確にしています。松山氏は2024年、月額料金を約5ドルから約10ドルへ引き上げた過程と、9カ月後に解約率が約3%まで下がった結果を公開しました。値上げは単なる売上増ではありません。低価格を理由に残る顧客より、製品の継続改善へ対価を払う顧客との関係を選ぶ判断でした。
この例は、安価なら売れるとは限らないことを示します。少人数で運営するほど、サポート、決済手数料、インフラ、開発時間を支えられる単価が必要です。顧客数だけを増やすと、問い合わせの総量に利益が追いつかないことがあります。
作る順番
マイクロSaaSの企画では、機能一覧より先に「今は誰が、いくらの手間をかけているか」を調べます。次の順番なら、作り込みすぎる前に需要を確かめられます。
- 同じ作業を繰り返す具体的な顧客を10人ほど探す
- 現在の手順、頻度、失敗したときの損失を聞く
- ひとつの成果までを最小機能で置き換える
- 無料利用数ではなく、有料で継続する理由を確認する
- 問い合わせと運用作業を記録し、自動化する
最初の顧客候補は「すべての中小企業」のように広く置きません。「Shopifyで月100点以上の商品を登録する担当者」のように、作業場面まで特定します。顧客が同じ言葉で悩みを説明できれば、ランディングページや検索記事のメッセージも具体的になります。
開発前のインタビューでは、欲しい機能を直接聞くより、直近にその問題が起きた日を聞きます。「あったら使う」は費用を払う証拠になりません。すでに表計算、外注、手作業などへ時間やお金を使っている問題ほど、有料化の根拠があります。
MVPは1つの成果で決める
MVP（実用最小限の製品）は、機能が少ない未完成品ではありません。顧客がひとつの仕事を最初から最後まで終えられる最小範囲です。データの入力だけできても出力が手作業なら、顧客は価値を受け取りきれません。反対に、設定項目が少なくても「週次レポートを自動で受け取れる」まで通れば有料化を試せます。
AIを使った事業開発では試作速度が上がりますが、コード生成の速さと需要の強さは別です。作れる機能が増えたからといって、対象範囲まで広げないことが大切です。
収支を先に計算する
継続できるかは、売上ではなく粗利から確認します。月額売上から、クラウド、外部API、決済手数料、顧客ごとに増えるサポートや手作業を引きます。AI APIを多用する製品では、利用量に応じて原価が増えるため、定額料金だけではヘビーユーザーの費用を吸収できない場合があります。
| 確認項目 | 月次で見る数字 | 危険な兆候 |
|---|---|---|
| 継続売上 | MRR、解約による減少 | 新規売上で解約を隠している |
| 変動原価 | API、決済、個別作業 | 利用が増えるほど粗利率が下がる |
| 顧客獲得 | 広告、営業、紹介 | 創業者の人脈だけに依存する |
| 運営負荷 | 問い合わせ、障害、更新 | 顧客数と同じ割合で工数が増える |
仮に月額3,000円で100社を獲得しても、1社あたり月1時間の個別対応が必要なら100時間を使います。月額1万円で30社、1社あたり10分で運営できる方が、売上は同じでも改善へ使える時間が残ります。価格は競合表の平均ではなく、顧客が得る価値と自社の提供原価から決めます。
AI時代のSaaSでは推論原価も論点になります。定額、従量、利用枠つき定額のどれが合うかを、実測した原価分布から選ぶ必要があります。
失敗しやすい境界
マイクロSaaSが止まりやすいのは、開発技術より境界が崩れたときです。要望の多い顧客へ合わせて機能を増やす、無料利用者の要望を優先する、問い合わせを創業者の善意で処理する、といった判断が積み重なると少人数運営の前提が失われます。
注意したいのは、次の4点です。
- 1社だけが使う機能を標準機能へ入れない
- 顧客データを扱う責任を「小規模だから」で軽く見ない
- 販売チャネルを単一のプラットフォームへ依存しすぎない
- 自分が休んだときに止まる作業を記録し、減らす
TinySeedは、ブートストラップ型SaaSを「外部資金を一切使わない会社」と限定せず、資本効率よく自立できる事業として扱っています。融資や少額出資を受けるかどうかより、急成長を前提にしなくても顧客価値と運営が続くかが本質です。
売却だけを出口にしない
小規模SaaSには売却事例もありますが、最初から買収されることだけを顧客価値に置き換えると、日々の判断がぶれます。運営を続ける、チームを増やす、事業を譲渡するという選択肢は、解約率、粗利、属人作業、顧客集中度が整ってから比較できます。まずは「今月の顧客が来月も使う理由」を作る方が先です。
よくある質問
個人開発と何が違いますか
個人開発は作り手の人数を表す言葉です。マイクロSaaSは、狭い課題、継続収益、運営可能な範囲を持つ事業モデルを表します。個人が作った買い切りアプリは個人開発ですが、必ずしもマイクロSaaSではありません。
BtoBとBtoCのどちらに向きますか
どちらでも成立します。BtoBは業務上の損失を金額で説明しやすく、BtoCは販売と導入が軽い場合があります。対象者が同じ問題を繰り返し、継続利用する理由があるかを優先します。
いくらで始められますか
開発費だけなら小さくできますが、法人、決済、セキュリティ、利用規約、サポートの費用も発生します。金額を一律に決めず、顧客1社を安全に受け入れるまでの費用を見積もります。
無料プランは必要ですか
必須ではありません。価値を体験するまでが短く、無料利用が有料化につながるなら有効です。サポートやAPI原価が重い製品では、無料トライアルや返金保証の方が管理しやすいこともあります。
会社員の副業でもできますか
できますが、勤務先の副業規程、競業避止、知的財産、利用するデータを確認してください。障害や問い合わせへ対応できる時間も、販売前に明示する必要があります。
まとめ
- マイクロSaaSの「小ささ」は売上規模ではなく、顧客、課題、機能、運営負荷の境界にあります。狭く決めるほど、少人数でも改善を続けやすくなります。
- 収益化は、作る、無料で広げる、有料化する、の順とは限りません。現在の作業コストを持つ顧客へ早く有料で届け、継続理由を確かめることが重要です。
- 売上だけでなく変動原価と運営時間を測ると、伸ばすべき機能と断るべき個別要望が見えます。継続できる余力も製品の一部です。
