はじめに
「ARRが前年比2倍で、チャーンレートも3%台。良い案件ですよね」——こう言われたSaaS企業のDDに入ったとき、筆者が最初に確認するのは「チャーンの計算方法」と「ARRの定義」です。これが揃っていないと、その数字がどういう意味を持つのかまったく判断できない。
SaaS企業のDDは、従来型の製造業・サービス業のDDと前提が違います。過去の売上より「将来の継続性」が価値の源泉だからです。ARRは成長しているのに収益構造が危うい、チャーンが低く見えるが計算方法を変えれば深刻——そういう状況は珍しくない。さらに2024年以降は、生成AIの普及で「SaaS is Dead」論が現実味を帯びはじめ、過去の指標が健全でも顧客が来期からAIで内製代替に動く可能性まで視野に入れる必要が出てきました。M&Aで取得してから気づいても、バリュエーションを後から修正することはできません。
SaaS企業のDDで最初に見るべきは「どの指標を・どう定義して・いつから計測しているか」です。数字そのものより、その数字の作り方を確認することが先決です。
ARRが示さないこと——「成長している」の内側を読む
ARR（Annual Recurring Revenue）は「年次の定期収益合計」ですが、これだけ見ていると重要な事実を見逃します。ARRが前年比150%に成長していても、その内訳が「新規契約の積み上げのみ」で既存顧客の解約が急増していれば、バケツに穴が開いたままジョウロで水を注ぎ続けている状態です。
ARRを分解するとき、筆者が最低限確認するのは4つの構成要素です。まずNew ARR——新規契約から追加されたARRで、「ARRが伸びている」の主因がこれだけの場合は要注意です。次にExpansion ARR——既存顧客のアップセルやシートの追加によるARR増加で、これが大きいほど事業の持続性が高いと判断できます。一方でChurned ARRは解約・ダウングレードで失ったARRで、開示資料では隠れていることが多い。そしてContraction ARRはプラン変更（ダウングレード）によるARR減少で、これがチャーンと別管理されているかどうかを確認します。
「ARRが1億円」という情報だけでは、その企業が健全かどうか判断できません。Expansion ARRの比率が高く、Churned ARRが小さいSaaSは、顧客が価値を認めて追加投資している状態。逆にNew ARRだけで成長しているSaaSは、顧客基盤の質ではなく営業力で数字を作っている可能性があります。この違いがバリュエーションに直結します。
ARR2億円の裏に潜んでいた解約ラッシュ
BtoBのSaaS企業のDDで、ARRが2年間で6,000万円から2億円に成長していた案件があります。ビジネスDDの段階でARRの内訳を要求したところ、開示が遅れました。最終的に開示されたデータを確認すると、同期間の解約ARRが8,000万円に達していました。
つまり、新規獲得で2億4,000万円分のARRを追加しながら、8,000万円が解約で消えていた計算です。当初「良い案件」と評価されていたこの会社は、チャーンARRを考慮した場合のバリュエーションが買い手の想定より約35%低下しました。ARR単体では見えない現実が、内訳の開示で初めて明らかになりました。
チャーンレートの定義が変わると結論が変わる
チャーンレートは「解約率」ですが、同じ事業データを使っても計算方法によって数値が大きく変わります。売り手から「チャーンレート3%」という情報をもらったとき、まず確認すべきは「何の3%か」です。
| 計算方法 | 計算式 | 傾向・注意点 |
|---|---|---|
| 顧客数チャーン | 解約顧客数 ÷ 期初顧客数 | 小規模顧客の解約が多い場合、ARRへの影響より高くなる |
| ARRチャーン | 解約ARR ÷ 期初ARR | 大口顧客の解約が1件あると急上昇する。顧客集中リスクの指標にもなる |
| ネットチャーン（ロゴ） | （解約 − 新規追加）÷ 期初顧客数 | 新規獲得でチャーンを相殺した「見かけの良さ」が出やすい |
| 月次 vs 年次 | 月次チャーン3% ≒ 年次約31%（複利換算） | 「月次チャーン3%」は年次換算すると3割近くが入れ替わる水準 |
売り手が自社に有利な方法で計算したチャーンレートを提示してくることは珍しくない。「月次3%」と言われると低く感じますが、複利で年次換算すると約31%（1−0.97の12乗）。3年後には現在の顧客の大半が入れ替わっている計算です。買い手として同じデータを複数の方法で再計算し、どの水準が実態に近いかを確認することが、SaaS DDの基本作業のひとつです。
「月次チャーン2.8%」の本当の意味を確認した案件
人事SaaSのDDで、売り手から「月次チャーンレート2.8%、業界平均よりかなり低い水準です」という説明を受けました。複利で年次換算すると約29%（1−0.972の12乗）——筆者が「これは年間で約3割が入れ替わる水準ですね」と指摘したところ、売り手の担当者が「そういう見方は一般的ではない」と返してきました。
実際に過去2年間の解約データを顧客単位で確認したところ、小口顧客の解約が多く顧客数ベースのチャーンは2.8%でしたが、ARRベースのチャーンは月次4.5%でした。大口顧客2社が解約に動いていたことがデータに現れていました。その2社の継続意向を個別にヒアリングしたいと買い手側に提案したのですが、売り手は「営業中の顧客に直接当てると関係が壊れる」と当初は難色を示しました。最終的にCS担当者の同席を条件に1社だけ面談が実現し、そこで出てきたのが「競合への乗り換えを検討中」という一言でした。残り1社は面談にこぎつけられないまま、リスクとして開示前提に書き残すしかなかった——数字の精緻化より、誰にどこまで会えるかの交渉のほうが結論を左右した案件です。
NRR（ネット収益維持率）が事業の健全性を映す
NRR（Net Revenue Retention）は、既存顧客から前年と比べてどれだけの収益を維持・拡大できているかを示す指標です。計算式は「（前年ARR − 解約ARR − 縮小ARR + アップセルARR）÷ 前年ARR」。100%を超えていれば、新規獲得ゼロでもARRが成長するという状態を意味します。
NRRが100%を超えるSaaSは、顧客が使えば使うほど投資額を増やしている——つまりプロダクトが顧客の業務に深く組み込まれているということです。一方でNRRが80%台のSaaSは、新規獲得を止めたとたんにARRが縮小する構造にある。
NRRの水準と事業評価の目安
筆者の体感では、グローバルのSaaS企業では一部のトップ企業が130%超、優良案件で110〜120%台、要注意水準で90%台前半、危険水準で90%未満という感覚で評価されることが多い（上場SaaSの多くは110〜120%台で、130%超は一握りです）。日本の中堅SaaSでは100〜110%程度が現実的な水準です。
ただし、NRRが高いからといって安心はできません。NRRが120%でも、その多くが1〜2社の大口顧客のアップセルで達成されている場合、その顧客が離れた瞬間にNRRが急落します。顧客集中リスクとNRRは必ずセットで評価します。
NRR104%を「低い」と切り捨てかけた案件
物流向けSaaSのBDDで、提示されたNRRは104%。買い手社内の投資委員会では「グローバルの優良SaaSは120%超なのに、これは見劣りする」という声が先に出ていました。筆者も最初は同じ印象を持ちました。
ところがアップセルとチャーンを分けて顧客別に追っていくと、印象が反転していきました。この会社は単価の安い小口顧客を意図的に切り、残った顧客の単価を年々引き上げていた。NRRの分子で解約ARRが大きく見えていたのは、低単価層を計画的に整理した結果だったわけです。整理後の中核顧客だけで再計算したコホートのNRRは120%を超えていました。投資委員会の懸念に対し、筆者が用意したのは新しい目標数値ではなく、「どの顧客層を残す経営判断をしてきたか」を時系列で並べた一枚の図でした。委員の一人が「これは縮んでいるんじゃなくて、絞り込んでいるのか」と言ったところで、議論の前提がようやく揃いました。NRRの数字そのものより、その数字が生まれた経営判断のほうが先に検証されるべきだ、と痛感した案件です。
プロダクトロードマップのDD——「作る予定」と「作れる組織」は別の話
SaaS企業のバリュエーションには「このプロダクトがどこまで成長するか」という将来の期待値が織り込まれます。ロードマップ通りに機能追加が進めば買い手の期待に応えられますが、プロダクトロードマップが絵に描いた餅だったとき、その期待値は実現しません。
ロードマップのDDで確認すべき核心は「そのロードマップを実行できる開発組織が存在するか」です。具体的には3点を見ます。まず開発者の実人数と対応可能な工数——ロードマップに記載された機能量と、実際の開発チームの規模が合っているか。「5名のチームで月3機能リリース」はほぼ不可能です。次に技術的負債の水準で、既存コードの品質が低く、新機能追加のたびに修正工数が発生する状態では、ロードマップ通りには進みません。これはIT-DDと連携して確認します。そして過去のリリース実績——直近12ヶ月でどれだけの機能をリリースしたかは、ロードマップの実現可能性の最も正直な証拠です。
「来年中にAI機能を3つ追加する予定」というロードマップを持つSaaSのDDをしたとき、直近1年のリリース実績が機能追加ゼロだったことがあります。ロードマップはバリュエーション根拠として使われていましたが、実行組織の裏付けがなかった。ビジネスDDとIT-DDを連動させないと、こういう実態は見えてきません。
CTOがロードマップの90%を抱えていた案件
マーケティングSaaSのDDで、「積極的な機能開発が競合優位を作っている」という説明を受けました。BDDで開発体制を確認したところ、プロダクトの主要機能の設計・実装がほぼすべてCTO一人に依存していました。CTOは32歳で創業者の一人。クロージング後にCTOが離脱するリスクについて確認すると、「クロージング後2年は残ってもらう予定」という回答でした。
ただしその「予定」に対する書面化がなく、インセンティブ設計も「これから協議」という状況でした。ロードマップの実行可能性がCTO一人にかかっている状態では、CTOの残留保証なしにバリュエーションを維持することはできません。結果として、CTOとのアーンアウト付きの雇用契約締結をクロージング前提条件として盛り込みました。
SaaS DDで財務DDが見落としがちな論点
SaaS企業の財務DDは、製造業や小売業のそれと前提が変わります。従来型の財務DDは過去の損益・B/S・キャッシュフローを中心に評価しますが、SaaSの価値の大半は将来の契約継続にあります。財務DDだけでは捉えきれない論点があります。
コホート分析による解約パターンの把握
同じ時期に契約した顧客群（コホート）が時間とともにどのように解約しているかを追うと、「解約が特定の時期に集中しているか」「長期顧客ほど定着しているか」が見えます。契約から6ヶ月以内の解約が集中しているSaaSは、オンボーディングに問題がある可能性があります。12ヶ月以降に解約が急増するSaaSは、契約更新タイミングで顧客が「続ける理由」を見失っているかもしれません。
収益認識タイミングの確認
SaaSの中には「初期費用」を受注時に一括収益として計上し、月次の継続収益と合算してARRに含めているケースがあります。この場合、初期費用込みのARRは解約率の計算を歪めます。財務DDでは収益認識の会計処理がAR（前受金）とARRに与える影響を確認する必要があります。
CAC・LTVの実態
「LTVがCACの3倍以上なら健全」という目安がSaaS界隈では使われますが、このLTVの計算にチャーンレートが直接影響します。チャーンレートが低く計算されていれば、LTVは過大に見積もられます。財務DDとビジネスDDを連携させ、LTV計算の前提となるチャーン仮定を検証することが、SaaS DDの実務では欠かせません。
コホート分析で見えた「12ヶ月の壁」
中小企業向けのSaaSツールのBDDで、コホート別の解約データを開示してもらいました。月次チャーンは平均2.5%と良好な水準でしたが、コホート分析をすると契約12〜14ヶ月目に解約が集中していることが判明しました。年間契約の更新タイミングと一致しています。
「使い続けている」という感覚でいる顧客が、更新案内が来たタイミングで「そういえばあまり使っていない」と気づいて解約しているパターンでした。月次チャーンの平均では見えない「更新離脱」が、コホート分析で初めて可視化されました。この事実をバリュエーションに反映し、買い手にはオンボーディング改善投資を100日プランに組み込むことを提案しました。
「SaaS is Dead」時代のAI耐性評価——3年後も顧客が払い続けるSaaSかを見極める
2024年以降、米国のVCや業界関係者の間で「SaaS is Dead」という議論が広がってきました。生成AIの普及により、単機能SaaSやワークフロー寄りのSaaSは、顧客が自前のAIで代替できる時代に入りつつあるという主張です。実際、上場SaaS各社の決算でNet New ARRの鈍化や契約単価の下落が散見され、PER水準も切り下がってきています。M&Aの買手にとって、この潮流はバリュエーション前提に直接効きます。
SaaS DDで、これまで以上に重要になっているのが「3年後にもこの顧客基盤がARRを払い続けるか」という問いです。ARRもチャーンもNRRも、過去のスナップショットに過ぎません。AI普及で顧客の業務前提が変わったとき、その指標が維持される構造的な根拠——いわゆるmoat（堀）——があるかを評価しないと、買収後3年で陳腐化するSaaSを掴むリスクが残ります。
AI耐性を評価する6つの軸
最初に見るのがデータmoatです。対象会社のみが蓄積している顧客行動データ・業界特化データがあり、汎用LLMでは再現できないか、再現に時間とコストがかかる構造になっているかを確かめます。確認の入口になるのは利用規約とデータ処理契約（DPA）の条項で、蓄積したデータを学習・二次利用してよいのか、顧客が解約時にデータ削除を請求できるのかを読みます。契約上データを自社の資産として使えないなら、データ量がいくらあってもmoatにはなりません。次にワークフロー統合の深さ——顧客の基幹システムや他SaaSとの連携でどれだけ業務に組み込まれているかを見ます。聞き方としては、本番稼働中の連携API・コネクタの数、そして「もし御社が乗り換えるとしたら移行に何人月かかりそうか」を顧客側のIT担当に直接尋ねると、乗り換えコストの実感値が出てきます。加えて規制・コンプライアンス対応として、医療・金融・公共・人事など、認証・監査・法令遵守が求められる領域での参入障壁の厚さを評価します。取得済みの認証（ISMS・SOC2など）と、それを前提に契約している顧客の比率を見ると、規制が実際に乗り換えを止めているかが分かります。
さらにネットワーク効果——マルチサイド型（売手・買手、雇用主・求職者など）で、ユーザー数の増加が個別顧客の価値に直結する構造かどうかも軸になります。ここは「ユーザーが増えても各顧客の体験が変わらない」なら効果は薄い、と割り引いて見ます。そしてAI取り込みの速度と質として、自社プロダクトにAIを「機能」として後付けしているのか、「中核」として再設計しているのかを見極めます。AI-nativeかretrofitかは中長期の差別化に直結するからです。判断材料は、AI関連機能のコードがいつ追加されたかのコミット履歴やリリースノートで、ここはIT-DDと連動して確かめます。最後に顧客自身のAI代替検討状況——顧客インタビューで「AIで内製代替を試している」と話す層がどの程度いるかを把握し、指標では見えない内製化リスクを直接捕捉します。
このうち最も軽視されがちなのが、最後の「顧客自身のAI代替検討状況」です。ARR・NRR・チャーンはすべて過去の挙動の記録ですが、AI普及で顧客の発想が変わるのは「これから」起きる話です。財務的に健全に見えるSaaSでも、上位顧客の数社にAI内製化の動きがあるだけで、3年後のARRは大きく揺らぎます。買手として顧客インタビューを設計する際、「AI代替の検討状況」を必ず聞くべき項目に加えるのが、ここ1年の実務的な変化です。
また、AI耐性評価はビジネスDDだけで完結しません。データmoatの実態（学習に使えるデータが本当に独自か、契約上の制約はないか）はIT-DDで踏み込みますし、AI機能の再設計コストはプロダクトロードマップとIT-DDを連動させて見ます。「AIに駆逐されない」を示す材料は、領域横断で組み立てる必要があります。
「ChatGPTで代替を試している」と顧客が言ったSaaS
中規模のマーケティングSaaSのBDDで、過去のARR成長率は前年比+45%、月次チャーンは2.1%と良好な水準でした。財務DDだけ見れば「優良案件」と評価される数字です。ただし上位顧客10社への顧客インタビューを実施したところ、3社から「ChatGPTやClaudeで一部機能の代替を試している」という回答がありました。うち1社は「来期の更新時には継続するか改めて判断したい」と明言しています。
このSaaSのコア機能は、顧客リストのセグメント分析とメール文面の自動生成でした。生成AIのAPIを直接叩けば、中堅企業の社内エンジニアが2〜3ヶ月で内製可能な機能水準です。データmoatもワークフロー統合も浅く、AI普及後の継続性に構造的な弱点がありました。バリュエーションは過去指標ベースのケースとAI内製化を織り込んだダウンサイドケースで分け、ベースケースとの差額分は売手側のアーンアウト条項として後ろ倒しすることで合意しました。「数字が良いから安心」が成立しない時代に入っています。
まとめ
SaaS企業のDDで扱う指標——ARR・チャーン・NRR——は、定義と計算方法を確認しないと「良い案件」と「要注意案件」の区別がつきません。売り手が提示する数字をそのまま使ってバリュエーションを組むことは、SaaS DDにおいては特にリスクが高い。
ビジネスDDとIT-DDを連動させることで、プロダクトロードマップの実行可能性・開発組織の実態・技術的負債がバリュエーションに与える影響を、財務DDだけでは見えない角度から補完できます。SaaS企業のDDは、指標の定義確認から始めて、コホート分析・顧客集中リスク・開発組織の実態まで連続した流れで評価する設計が必要です。
加えて、2024年以降は「SaaS is Dead」論を踏まえたAI耐性の評価が、SaaS DDで避けて通れない論点になりました。過去のARR・チャーン・NRRが健全でも、AI普及で顧客が内製化に動き始めれば、3年後の事業継続性は別の話です。データmoat・ワークフロー統合の深さ・AI取り込みの質、そして顧客自身のAI代替検討状況——指標の裏側にある構造的なmoatをDDで確認することが、これからのSaaS M&Aで標準になります。
「ARRが伸びているから良い案件」という前提でDDに入ると、クロージング後に気づく——このパターンは防げます。DDの設計段階から「どの指標を・どう定義して確認するか」と「AIに駆逐されない構造を持っているか」の両軸を明確にしておくことが出発点です。