SaaSの事業計画で収益モデルを作るときは、売上を「顧客数 × 単価」の掛け算で一気に置くのではなく、月ごとに「期首の顧客数 ＋ 新規獲得 − 解約」で顧客数を積み上げ、そこに単価と単価の変化（アップセル・ダウングレード・値上げ）を掛けて月次の売上を出す形にするのが基本です。SaaSは売上が積み上がる一方で、解約によって毎月少しずつ削られていくため、この「流入と流出」を表に組み込まない計画は、ほぼ確実に楽観的になります。
もう一つの要点は、数字そのものより「前提の置き方」を説明できるようにすることです。新規獲得数は何から決まるのか、解約率はどの根拠で置いたのか、単価はどう変わる想定なのか。前提が一行ずつ見える形になっていれば、計画が外れたときにどこがずれたのかを特定でき、計画を検証の道具として使えます。
この記事は、社内で新しいSaaS事業の計画を任された担当者や、起業準備中で投資家や金融機関に説明する計画を作る方に向けて書いています。収益モデルの骨格、前提の置き方、シナリオの作り方、よくある失敗とチェックリストまでを、スプレッドシートで作れる形で整理しました。
SaaS事業計画の収益モデルが「掛け算」では足りない理由
売り切り型の事業であれば、「何個売れるか × いくらで売るか」で売上の見通しをある程度立てられます。SaaSでは、今月の売上は過去に獲得してまだ解約していない顧客の積み重ねで決まります。つまり、今月の売上は今月の営業成果だけでなく、過去すべての月の獲得と解約の結果です。
この構造のため、次のような特徴が出ます。
- 立ち上げ初期は、獲得した顧客がまだ少ないため売上が小さく、開発費や営業費が先行して赤字が続く
- 獲得が一定でも、解約がある限り顧客数はどこかで頭打ちになる（獲得数と解約数が釣り合う点がある）
- 単価の小さな改善や解約の小さな改善が、時間をかけて大きな差になる
- 顧客を獲得するための費用は先に出ていき、その回収は契約期間を通じてゆっくり戻ってくる
「年間で何社獲得し、平均単価がいくらだから売上はいくら」という掛け算の計画では、これらがすべて見えなくなります。特に、解約による頭打ちと、獲得費用の回収の遅さは、資金計画に直結する部分です。サブスクリプション型の収益の性質はサブスクリプションモデルでも整理しています。
収益モデルの骨格：顧客数の積み上げ表を作る
収益モデルの中心は、月を横軸にとった顧客数の積み上げ表です。行は次のように並べます。
| 行 | 計算の考え方 | 前提として置くもの |
|---|---|---|
| 期首顧客数 | 前月の期末顧客数 | なし（自動計算） |
| 新規獲得数 | チャネル別の獲得数の合計 | 流入数、商談化率、受注率など |
| 解約数 | 期首顧客数 × 月次解約率 | 月次解約率（時期によって変える） |
| 期末顧客数 | 期首 ＋ 新規 − 解約 | なし（自動計算） |
| 平均単価 | プラン構成と単価変化から計算 | プラン別の単価と構成比、拡張率 |
| 月次経常収益 | 期末顧客数 × 平均単価（または顧客群ごとに計算） | なし（自動計算） |
| 初期費用・導入支援などの一時収益 | 新規獲得数 × 一時収益の単価 | 導入支援の有無と単価 |
このうち、前提として入力するのは「新規獲得数の元になる数字」「解約率」「単価とその変化」の三つの系統だけにし、残りは計算式で出すようにします。入力欄と計算欄を色分けしておくと、他の人が見たときにどこを動かせば何が変わるのかが一目で分かります。
月次経常収益（MRR）を顧客数と平均単価の掛け算で出すのは単純化した方法です。プランごとに単価が大きく違う場合や、顧客の規模によって単価が変わる場合は、プラン別に積み上げ表を分けて合計します。最初は一本の表で作り、必要になったら分けるので十分です。
新規獲得数の前提をどう置くか
新規獲得数は、計画の中で最も楽観的になりやすい数字です。「月に10社くらいは取れるだろう」という置き方は、根拠が説明できず、外れたときに何を直せばよいかも分かりません。獲得数は、獲得の経路ごとにファネルで分解して置きます。
チャネル別のファネルで分解する
たとえば法人向けのSaaSなら、獲得の経路は次のように分けられます。
- Webからの問い合わせ：サイト訪問数 × 問い合わせ率 × 商談化率 × 受注率
- 展示会や紹介：接点の数 × 商談化率 × 受注率
- アウトバウンド営業：アプローチ数 × 返信率 × 商談化率 × 受注率
- 既存事業の顧客への案内：対象顧客数 × 案内への反応率 × 受注率
各段階の率は、可能なら小さな検証で得た実績を使います。実績がない段階では、仮置きであることを明記し、どの検証で確かめるかを書いておきます。率の置き方そのものより、「この数字はまだ仮説である」と計画書の中で区別されていることのほうが重要です。営業活動の数字の分解は営業KPIの設計も参考になります。
営業の処理能力という上限を入れる
ファネルの計算だけで獲得数を出すと、問い合わせが増えれば獲得も比例して増えることになります。実際には、商談を担当できる人数、導入支援をできる人数に上限があります。営業担当1人が月に対応できる商談数を置き、それを超える分は獲得できない、または採用が必要になる、という制約を表に入れておくと、人員計画と売上計画がつながります。
立ち上がりの時間差を入れる
広告やコンテンツを始めてすぐに問い合わせが来るわけではありませんし、法人向けでは検討期間があります。最初の数か月の獲得数を小さくし、徐々に立ち上がる形にしておくと、実態に近い資金の動きが見えます。
解約率の置き方：一律にしない
解約は、SaaSの収益モデルで最も軽視されやすい要素です。解約率を一つの数字で全期間に置くと、実態と大きくずれることがあります。
時期によって解約率を変える
一般に、契約直後の数か月は「思っていたものと違った」「使いこなせなかった」という理由の解約が出やすく、使い続けている顧客は徐々に定着していきます。計画では、契約からの経過月数によって解約率を変える置き方が現実的です。最初は「契約から3か月までは高め、それ以降は低め」の二段階で十分です。
年契約と月契約を分ける
年間契約の顧客は、契約期間中は解約が起きず、更新のタイミングでまとめて判断されます。月契約と年契約が混在する場合は、それぞれ別の行で扱い、年契約は更新月にだけ解約率を適用します。こうすると、年に一度、顧客数が大きく動くタイミングが表に現れ、資金繰りの山谷も見えるようになります。
解約率の根拠をどう説明するか
自社にまだ実績がない段階では、解約率の根拠は弱くならざるを得ません。その場合は、次のように扱います。
- 計画上は保守的な値で置き、楽観的なシナリオとは分けて示す
- 解約の主な原因を仮説として書き、それを減らす施策を計画に入れる
- 試験導入や初期顧客の利用状況から、早めに実績値へ置き換える
解約の兆候を利用データから見つける方法は解約の予兆を検知する方法で詳しく扱っています。計画の段階から、どのデータで解約リスクを見るかを決めておくと、実績への置き換えが早くなります。
単価の推移：拡張収益と値上げをどう組み込むか
単価を固定値で置く計画も多いのですが、SaaSでは顧客ごとの単価が時間とともに変わります。
- 利用人数や利用量が増えて単価が上がる（アップセル）
- 上位プランや追加機能を契約する（クロスセル）
- 利用人数を減らしたり、下位プランに移ったりして単価が下がる（ダウングレード）
- 料金改定による単価の変化
これらは「既存顧客の売上が月ごとに何割増減するか」という拡張率として置くこともできますし、プラン間の移行を表で持つこともできます。最初は、既存顧客の売上に対する月次の純増減の割合を一つ置く方法が簡単です。ただし、その割合が何から来ているのか（席数の増加なのか、上位プランへの移行なのか）を説明できるようにしておきます。
値上げを計画に入れる場合は、値上げ時に一定の解約が増える可能性も同時に置きます。単価だけが上がる計画は楽観的です。料金改定の影響の測り方は値上げ・料金改定の影響を測る方法を参照してください。
費用側と獲得効率：売上だけの計画にしない
収益モデルは売上の表だけでは完成しません。SaaSの計画では、費用の構造と獲得効率をセットで見る必要があります。
費用を性質で分ける
| 費用の区分 | 主な中身 | 売上との関係 |
|---|---|---|
| 売上原価に近い費用 | インフラ費、外部サービスの利用料、サポート人件費 | 顧客数や利用量に応じて増える |
| 獲得のための費用 | 広告費、営業人件費、展示会費、販売代理店への手数料 | 新規獲得数に応じて増える |
| 開発・改善の費用 | 開発人件費、外注費 | 売上とは直接連動しない |
| 管理の費用 | 管理部門、オフィス、各種ツール | おおむね固定的 |
この区分で分けておくと、「顧客1社あたりの粗利」「顧客1社を獲得するのにかかる費用」「その費用を何か月で回収できるか」が計算できます。
獲得費用の回収期間を見る
顧客1社の獲得にかかった費用を、その顧客から得られる月あたりの粗利で割ると、回収にかかる月数が出ます。この月数が、想定する平均継続期間より長ければ、顧客を獲得するほど損をする構造になっています。この比較は計画の健全性を確かめる最も分かりやすい指標です。顧客の生涯価値の伸ばし方はLTVを伸ばす施策にまとめています。
収益モデルを作る手順
ここまでの要素を、実際にスプレッドシートで組み立てる手順です。
- 前提シートを作る：獲得ファネルの率、解約率、単価、費用の単価など、入力する数字をすべて一枚のシートに集め、それぞれに根拠と確度（実績・仮説・仮置き）を書く。
- 顧客数の積み上げ表を作る：月を横軸に、期首・新規・解約・期末の行を作り、新規はチャネル別に分けて計算する。
- 単価と売上の行を作る：プラン構成と拡張率から平均単価を出し、月次の経常収益と一時収益を計算する。
- 費用の表を作る：変動費は顧客数や獲得数に連動させ、人件費は採用計画と連動させる。
- 獲得効率の指標を出す：顧客1社あたりの獲得費用、粗利、回収月数を月ごとに計算する。
- 資金の推移を出す：月ごとの収支を累積し、資金が最も少なくなる月とその金額を確認する。
- シナリオを作る：獲得・解約・単価の三つについて、基本・慎重・楽観の値を用意し、切り替えられるようにする。
- 感度を確かめる：どの前提を動かしたときに結果が最も大きく変わるかを確認し、その前提を優先的に検証する計画を立てる。
手順8が特に大切です。感度の高い前提が分かれば、検証の優先順位が決まります。たとえば解約率を少し動かしただけで資金の底が大きく変わるなら、まず解約の要因を確かめる検証に時間を使うべきだと判断できます。
前提シートに書く内容の例
前提シートは、計画の中で最も多くの人に読まれる部分です。1つの前提につき、次の項目を1行で書きます。
- 前提の名前（例：Web問い合わせからの商談化率）
- 置いた値と単位
- 根拠（試験導入の実績、既存事業の類似データ、担当者の見立てなど）
- 確度（実績・仮説・仮置きの三段階）
- 検証の方法と時期（例：最初の3か月の問い合わせ記録で確かめる）
- 担当者
確度の列があると、経営層との議論が「この数字は高すぎるのではないか」という印象の言い合いから、「この仮置きの前提をいつまでにどう確かめるか」という建設的な話に変わります。計画を更新するときは、仮置きだった前提が実績に置き換わっていく様子を前提シート上で追えるため、事業の進み具合を説明する資料にもなります。
計画と実績を比べる運用
計画を作ったら、毎月の実績を同じ行構成で横に並べます。新規獲得数がずれたなら、ファネルのどの段階がずれたのか。解約がずれたなら、どの時期に契約した顧客の解約が多いのか。行構成を計画と実績でそろえておくと、ずれの原因をすぐに分解できます。四半期に一度は前提シートを更新し、更新前後の計画を並べて残しておくと、判断の履歴にもなります。
具体的な場面の例：業務管理SaaSの計画を作り直す
架空の例で考えます。ある中堅企業が、自社で使ってきた業務管理の仕組みを同業向けのSaaSとして提供することになりました。最初の計画は「初年度に50社、平均単価は月額で一定、3年目に黒字化」という掛け算の計画でした。
前提を分解して積み上げ表に作り直すと、いくつかのことが見えてきました。
- 50社の獲得には、Webからの問い合わせが当初想定の数倍必要で、それだけの集客の手段がまだ決まっていなかった
- 営業担当が1人のままでは、導入支援の負荷から月に対応できる新規顧客数に上限があった
- 契約直後の解約を考慮すると、顧客数の伸びは当初の想定よりなだらかになった
- 獲得費用の回収に必要な期間が、想定する継続期間と比べて余裕が小さかった
この結果、計画は「まず既存の取引先に試験導入してもらい、導入初期の定着率と解約理由を確かめる」「導入支援の手順を整えて1社あたりの負荷を下げる」という検証を先に置く形に変わりました。売上の見通し自体は控えめになりましたが、経営層への説明は「どの前提が確かめられたら次の投資に進むか」という形で行えるようになりました。
よくある失敗と避け方
- 解約を入れていない、または全期間一律で置いている：経過月数で解約率を分け、保守的な値を基本シナリオにする。
- 新規獲得数を根拠なく置いている：チャネル別のファネルで分解し、各率の根拠と確度を書く。
- 営業や導入支援の人数の上限を考えていない：1人あたりの処理能力を置き、人員計画と連動させる。
- 単価が上がり続ける前提になっている：拡張収益の中身を説明できるようにし、ダウングレードや値上げ時の解約も同時に置く。
- 売上の表しかない：費用を性質別に分け、獲得費用の回収月数と資金の底を確認する。
- 前提と計算が混ざっている：入力欄を一枚の前提シートに集め、計算式の中に数字を直接書き込まない。
- 一度作った計画を更新しない：月次の実績を並べ、前提との差を定期的に確認して置き換える。
月次の実績との比較には、SaaSの経営指標をまとめたダッシュボードがあると便利です。見せ方はSaaS経営指標のダッシュボード設計で解説しています。
SaaS収益モデルのチェックリスト
- 顧客数が「期首 ＋ 新規 − 解約」で月ごとに積み上がっている
- 新規獲得数がチャネル別のファネルで分解されている
- 営業・導入支援の処理能力の上限が考慮されている
- 解約率が経過月数や契約形態で分けて置かれている
- 単価の変化（拡張・縮小・値上げ）の前提が説明できる
- 費用が性質別に分かれ、獲得費用の回収月数が計算できる
- 資金が最も少なくなる月と金額が分かる
- 基本・慎重・楽観のシナリオを切り替えられる
- 感度の高い前提が特定され、その検証計画がある
- すべての前提に根拠と確度が書かれている
よくある質問
Q. 実績がまったくない段階でも、収益モデルを作る意味はありますか？
あります。むしろ実績がない段階こそ、どの前提が事業の成否を左右するのかを把握するために作ります。数字の正確さより、前提を分解して並べ、感度の高いものから検証していくための地図として使うことが目的です。
Q. 何年分の計画を作ればよいですか？
社内の承認や資金調達の求めに応じて3〜5年分を作ることが多いですが、細かく作り込むのは最初の1〜2年で十分です。それ以降は前提の不確かさが大きくなるため、月次ではなく四半期や年単位で大まかに示し、前提の更新に合わせて見直します。
Q. 投資家や経営層には、どこまで細かい表を見せるべきですか？
まずは前提シートと、顧客数・売上・資金の推移を要約したグラフ、シナリオ別の比較を見せます。詳細の計算表は質問が出たときに示せるように用意しておけば十分です。重要なのは、どの前提がまだ仮説で、いつどう確かめるのかを説明できることです。
Q. フリーミアムやトライアルがある場合はどう組み込みますか？
無料利用者数を別の行で持ち、そこから有料への転換率を掛けて新規獲得数を出します。無料利用者にもインフラ費やサポート費がかかるため、費用側にも無料利用者の人数に連動する行を入れておきます。
Otsumuに相談できること
獲得の経路がある程度見えていて、社内にスプレッドシートで計画を組める担当者がいる場合は、この記事の骨格と手順に沿って自社で収益モデルを作れます。前提を一枚に集め、シナリオと感度を確かめるところまで進めば、社内の議論にも十分使えるはずです。
一方で、前提を置くための検証がまだ何もない、計画は作ったものの経営層から根拠を問われて答えられない、どの前提から確かめるべきか優先順位が決まらない、といった状況では、事業計画と検証の進め方の両方を知る外部の視点が役立ちます。数字を整えることより、計画を検証の順序に変換することが難所だからです。
Otsumuは自らも事業を手がける立場から、収益モデルの前提の分解、検証計画への落とし込み、必要に応じたMVPの開発までを一気通貫で支援しています。新規事業開発コンサルティングでは、計画と前提を短期間で点検する新規事業レビュー Sprint（48万円・税別、1〜2週間）もご用意しています。
計画の作り方に迷っている段階でも構いません。まずは30分の無料相談で、いまの計画と前提をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01