mcpField
R
revenuecat-app-valuation

revenuecat-app-valuation

github.com/revenuecatその他76208 回インストール1 日前に更新
リポジトリ

revenuecat-app-valuation について

revenuecat-app-valuationは、RevenueCatのデータと明示した財務上の前提を使い、アプリ創業者が売却価格の目安を検討するスキルです。利益を基準とする評価レンジや事業リスクを示し、財務・法律・税務の助言ではなく一般的な情報として扱います。

主な機能

  1. 01売上ではなく営業利益を基準に評価
  2. 02市場全般と成熟したサブスクリプションの評価レンジを比較
  3. 03継続率、成長、収益化、収益集中度を評価
  4. 04RevenueCatデータを評価の前提に活用
  5. 05レンジ、確度、主要な前提を提示

活用シーン

  1. 01売却の相談前に根拠のある評価額を準備
  2. 02過去利益と直近ランレートの感度を比較
  3. 03サブスクリプションアプリの成熟帯の条件を確認
  4. 04解約率や収益集中など買い手の懸念を特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/revenuecat/ai-toolkit --skill revenuecat-app-valuation

インストール後、Claude Code で/revenuecat-app-valuationを入力して読み込まれたか確認します。

詳細

アプリの評価額と売却

創業者が自分のアプリの価値を把握し、アプリ買収の仕組みを理解できるよう支援します。 以下のフレームワークは、アプリの売却に関するRevenueCatのガイダンスをもとに、買い手がリスクをどう判断するかを加味したものです。一般的な相場をそのまま引用するのではなく、可能な限り、ユーザー自身のRevenueCatデータをもとにすべての見積もりを算出してください。

このトピックでは、次の2つのルールを守ってください。

  • 評価額は必ず信頼度とともに幅で提示し、確実な単一の金額は提示しないでください。最終的にアプリの価値を決めるのは買い手が支払う金額であり、どの価格でも買い手が見つかる保証はありません。
  • 一般的な情報提供として扱い、財務、法律、税務に関する助言はしないでください。査定、税務上の扱い、または取引条件については、ブローカー、弁護士、税務専門家に相談するよう伝えてください。

手法

評価額は、順番に決める4つの要素からなります。各要素を明示的に検討してください。

  1. 利益の基準を選び、明記します。
  2. その基準に適用する倍率の範囲を選びます。
  3. 根拠に基づき、その範囲内でアプリがどの位置にあるかを判断します。
  4. 評価額の範囲、信頼度、および評価額を左右する要素を示します。

1. 利益の基準を選ぶ

アプリの評価額は売上ではなく、利益に対する倍率で算出します。このスキルにおける倍率はすべて利益倍率です。売上指標に直接倍率を適用しないでください。

基準倍率
月間営業利益12x~36x(広い範囲)、36x~60x(成熟したサブスクリプションアプリ)
年間営業利益1x~3x(広い範囲)、3x~5x(成熟したサブスクリプションアプリ)

MRRとARRも重要です。利益の算出元となるトップラインであり、以下の継続率、成長率、集中度の確認にも使用するためです。ただし、評価額の算出基準ではありません。

ユーザーが売上は把握していてもコストを把握していない場合は、コストを尋ねてください。提示できない場合は、利益率の仮定を明示し、計算式の全体を示してください。たとえば、「$200k ARR × 利益率を60%と仮定 = 利益$120k × 3~5倍 = $360k~$600k」のように示せば、ユーザーは仮定を修正できます。

オーナー所得または採用後利益

妥当な利益の基準は2つありますが、相互に置き換えることはできません。どちらかを選び、回答で明記したうえで、それに対応する倍率を適用してください。

  • オーナー所得 — 1人の買い手が自ら作業を行った場合に手元に残る金額です。収入から現金支出の運営コストを差し引き、一時的または継続しない費用を加え戻します。個人の買い手に売却するオーナー運営のアプリに使用します。
  • 採用後の営業利益 — 創業者が現在無償で行っている作業に市場相当の対価を支払った後に、アプリが生み出す利益です。オーナー所得から、その作業を代替する人材の費用を差し引きます。買い手がスタジオまたはポートフォリオ買収企業で、アプリの運営に人員を配置する場合に使用します。これをデフォルトとします。

公表されている3x~5xの範囲は、採用後の数値です。この倍率を提示する買収企業は、運営コストを負担するポートフォリオ買収企業です。

代替コストを見積もるには、エンジニアリング、サポート、マーケティング、管理業務に週何時間かかっているか、現在誰にいくら支払っているか、また創業者が移行期間中も関与する予定かを尋ねてください。パートタイムの保守作業であれば、代替コストは月に数千ドル程度です。エンジニアリングとユーザー獲得を担うフルタイムの創業者であれば、給与相当の金額になります。これらは算出された事実ではなく、明示した仮定として提示してください。

数値の算出

総売上ではなく、売上税/VATとストア手数料を差し引いた売上収益を起点にします。App Store/Play Storeの手数料はすでに差し引かれているためです。revenueチャートでget-chart-dataをリクエストし、revenue_typeセレクターをproceedsに設定して売上収益を取得します(revenuecat-chartsを参照)。次に、アプリの運営を直接支える費用、つまり運営コスト(サーバー、カスタマーサポート、ライセンス)、マーケティングおよびユーザー獲得費用、継続的な保守費用を差し引きます。上記の加算項目を適用します。

  • 支払利息や法人所得税は差し引きません。これらは売り手の資金調達や税務状況を反映するものであり、買い手は自身の状況に置き換えるためです。売上収益からすでに差し引かれている「税金」は売上税/VATです。所得税をさらに差し引かないでください。
  • _新しい_機能の開発費用は、通常は除外します。既存の利益の維持ではなく、将来の利益のための費用だからです。アプリごとに異なるため、開発費用の一部を数値に含める場合はその旨を記載してください。
  • 基準には直近12か月(TTM)の数値を使用します。

次に、直近の完全な2四半期の数値を年率換算し、ランレートの感度分析を行います。TTMの基準値との差が約20%を超える場合は、両方を提示します。

TTM利益が10万ドルの場合、評価額の範囲は30万~50万ドルです。現在のランレートが14万ドルなら、同じ倍率で42万~70万ドルになります。買い手はTTMの数値に近いところを基準とし、ランレートが維持されることを証明するよう求めます。持続的な成長は範囲の上限を正当化する材料であり、基準額を引き上げる理由ではありません。

この考え方は、どちらの方向にも当てはまります。業績が低下しているアプリでは、ランレートの数値が買い手の目指す下限となり、TTMの数値が売り手の主張する基準になります。どちらの場合も差を示してください。ランレートの感度分析は、一時的な急増を年率換算してよいという意味ではありません。2四半期以上にわたる一貫した変化はトレンドですが、ローンチ後の好調な1か月や季節的なピークはトレンドではありません。トレンドと判断する前に、チャートのannotationsを確認してください。

2. 倍率帯を選ぶ

RevenueCatは2つの倍率帯を公表していますが、同じ範囲ではありません。それぞれ、異なる層のアプリを対象としています。

  • 市場全般の目安:アプリの一般的な売却価格は、月間営業利益の12~36倍(年換算で約1~3倍)です。これは、比較的新しいアプリや解約率の高いアプリを含む市場全体を対象としています。これを大きく上回る倍率で売れるアプリもあれば、まったく売れないアプリもあります。
  • 成熟したサブスクリプション事業の下限:実績があり、リスクの低いサブスクリプション事業では、慎重な買い手は年間営業利益の3~5倍(月間の約36~60倍)を基準とします。計算例:年間営業利益が10万ドルのアプリは、3~5倍でおよそ30万~50万ドルの価値があります。

これらの倍率帯は端から端まで並び、年換算3倍/月間36倍のところでのみ重なります。2つの倍率帯を平均したり、単一の数値で両方を調整できると主張したりしないでください。

成熟サブスクリプション帯の判定に必要なのは、経過年数ではなく根拠です

判定基準は、完全な更新サイクルを観測できるかどうかです。通常、アプリの2周年を迎えるずっと前に確認できます。次の3点をすべて確認してください。

  • サブスクリプションが収益の中心であること — 収益のおよそ70%以上がサブスクリプションによるものです。
  • 主流プランの期間に応じた更新サイクルが完了していること。subscription_retention または cohort_explorer を確認してください。年額プランが主流のアプリでは、最初の更新がデータに含まれるよう、月次観測期間が12か月を超えるコホートが必要です。月額プランが主流のアプリでは、最初の1か月後の解約の急増を十分に過ぎたコホートが必要です。必要なのは、1回ではなく複数回の更新期間です。まず収益に占める年額プランと月額プランの割合を確認してください。それによって適用する基準が決まります。月次観測期間が12か月まで完了したコホートがある18か月の年額プラン主体アプリは条件を満たしますが、年額プランを導入したばかりの3年目のアプリは条件を満たしません。
  • 曲線が横ばいになっていること。少なくとも連続する2つのコホートで、リテンションが低下した後に横ばいになる必要があります。最後に観測された期間でも曲線が急激に低下している場合、履歴がどれだけ長くても根拠は不十分です。

いずれかの項目を満たさない場合は、広範な市場向けの区分が適用されます。どの項目を満たさないのか、そして何があれば条件を満たせるのか(通常は具体的な月数)を伝えてください。

基準を満たした後は、アプリの経過年数は関係ありません。倍率はコホートのデータによって決まります。

サブスクリプションが収益の中心ではないアプリ

RevenueCat は現在、サブスクリプション主体ではないアプリ向けに、公開済みまたは推奨される評価情報を提供していません。問い合わせ対象のアプリがサブスクリプション主体ではない場合、評価額を提示しないでください。

3. バンド内での位置付け

バンドが出発点であり、以下の要因によって、その中でアプリがどこに位置するかが決まります。各要因を強・中立・弱で評価し、それぞれの判断の根拠となった情報を示してください。

要因強弱確認する場所
継続率(重み2倍)解約率/継続率が同カテゴリの上位30%で、曲線が横ばい下位30%、または低下し続けている曲線get-benchmarks(月次解約率)、subscription_retention
推移2四半期以上にわたって継続的に前年比25%以上成長前年比10%以上の減少revenue(収益)、直近12か月とその前の12か月
収益化実現LTV、トライアルからの転換率、有料転換率が上位30%下位30%、または価格を引き上げる余地がないget-benchmarks、conversion_to_paying
販売チャネルチャネルが複利的に成長し、有料顧客獲得費用を健全に回収借り物の成長、または費用を回収できない有料施策ユーザーに確認
集中度ストア、地域、SKUに分散以下のしきい値を超える単一の依存先があるstore、country、product_idでセグメント化したrevenue
譲渡可能性運用負担が小さく、文書化され、ストアアカウントを譲渡可能創業者に依存し、文書化されておらず、譲渡が妨げられるユーザーに確認

get-benchmarksのpercentile_bucketをそのまま使用してください。70以上は強、30~70は中立、30未満は弱です。逆指標はすでに考慮されているため、解約率のパーセンタイルが高ければ、解約率が低いことを意味します。is_eligible_for_benchmarking: falseの行は信頼度が低いため、中立と評価し、その旨を示してください。

次に、位置付けを判断します。

  • 強が2つ以上で、弱がない — バンドの上位3分の1。
  • おおむね拮抗している — 中央の3分の1。
  • 弱が2つ以上 — バンドの下位3分の1。

買い手が支払う意思のある金額に上限を設ける要因として、収益の減少、アプリの譲渡を妨げる可能性のある問題、財務情報の未整備、集中度(下記参照)があります。該当するものがあれば記載してください。

結論だけでなく、評価一覧も示してください。「継続率は上位四分位で、前年比30%成長しているが、収益の90%を1か国に依存している」が回答です。数値はその内容を要約するものです。

評価要因の読み解き方
  • 継続率/サブスク登録者の定着率 — プロダクトマーケットフィットと将来のキャッシュフローを示す最も強いシグナルであり、倍率を左右する最大の要因です。そのため、比重を2倍にしています。「良好」とされる水準はカテゴリーによって異なります。購入者が挙げた、健全な年間サブスクリプションの継続率は約25%から約70%まで幅があります。一律の数値ではなく、アプリのカテゴリーを基準に比較してください。また、初期の解約(サブスクリプションの約30%は最初の月に解約されます)について説明できるようにし、その後のコホートで安定していることを示しましょう。

  • 収益化の伸びしろ — 収益化が不十分であることは、購入者にとってプラスです。収益化の実績があり、価格設定、オファー、プラン構成を改善する余地が明確にある状態が望まれます。

  • 販売チャネルの持続性 — 顧客獲得チャネルは好みではなく、品質の段階として捉えましょう。

    • 複利的に伸びる(最も強い):オーガニックASO、SEO、ブランド、口コミ。
    • 購入可能:有料ユーザー獲得。獲得数だけでなく、投資回収期間を確認しましょう。
    • 借り物(最も弱い):UGC、バイラルループ、インフルエンサー主導やアルゴリズム主導の成長、単一のクリエイター、ストアでの特集掲載。大幅に割り引いて評価し、それが明日止まった場合にインストール数がどうなるかを確認しましょう。

    オーガニックと有料のバランスについて、購入者の意見は異なります(好みとして挙げられた割合は、オーガニック100%から50対50、さらに有料75%・オーガニック25%までさまざまです)。そのため、独善的な構成より、根拠を示せる構成が優れています。

  • 集中度 — 過去12か月間のstore、country、product_id別に、収益に占める最大セグメントの割合を確認しましょう。

    • プラットフォーム/ストア。iOSのみの展開は一般的で、それだけであれば割引要因は軽微です。
    • 地域。1か国が収益の約70%を超える場合、実質的な上限要因になります。
    • SKU/製品。1つの製品が収益の約70%を超える場合、事業が単一の価格帯に依存していることを意味します。
    • グラフに表れない要因:単一のトラフィックソース、単一の連携先、そしてB2B型アプリの場合は収益を担う少数のアカウント。
  • 技術インフラ — クリーンなアーキテクチャ、低い運用負荷、優れたドキュメントは、認識されるリスクを軽減し、譲渡可能性の評価の大部分を占めます。

評価表の対象外

これらの要因は、評価レンジ内でのアプリの位置ではなく、取引条件を変えるものです。取り上げるべきですが、レンジには織り込まないでください。

  • 戦略面/ポートフォリオとの適合性 — 最も高い価格を提示するのは、多くの場合、最大の相乗効果を見込む購入者です。
  • 創業者の関与 — ほとんどの購入者は、移行期間中に創業者が残ることをプラスに評価します。社内チームを持つ大規模なスタジオは例外です。
  • 取引の構成 — オファーは現金(最も一般的)、株式、またはアーンアウトとして提示されます。オファーのおよそ3分の2は現金のみです。現金取引では、クロージング時に約50%が支払われ、残額はその後6〜12か月にわたって支払われることがよくあります。

4. 評価レンジと確信度を示す

結果は、利益の基準値×低めの倍率から×高めの倍率、レンジ内での位置とその理由、続いて確信度の順に示します。

データが乏しい、または変動が大きい場合、評価要因が相反する場合、複数の入力値がユーザー提供で検証できない場合、あるいは収益の大部分が継続的でない場合は、確信度が低くなります。整ったデータが12か月以上あり、解約率が低く、更新サイクルが完了していて、収益が分散している場合は、確信度が高くなります。根拠のない狭いレンジよりも、幅が広くても誠実なレンジのほうが優れています。

ユーザーのRevenueCatデータに基づく見積もり

ユーザーが自分のアプリについて見積もりを求めている場合は、まず実際の指標を取得してください。

  • revenuecat-chartsを使って、上記の手順で必要なデータを取得します。優先する指標は、売上金額(直近12か月および四半期別)、コホート別のサブスクリプション継続率、月次解約率、トライアルからの転換率と有料プランへの転換率、ARPU、年間プランと月間プランの構成比、実績LTV、ストア・国・プロダクト別の売上金額です。
  • get-benchmarksを使ってカテゴリ別ベンチマーク(実績LTV、トライアル転換率、初回転換率、有料プランへの転換率、月次解約率、返金率)と比較します。手順3の説明に従って、パーセンタイルをスコアカードに記載してください。
  • RevenueCatには顧客獲得コストのデータがないため、単独ではCAC、LTV/CAC、回収期間を算出できません。ユーザーから顧客獲得データが提供されていない限り、CACに基づく数値を提示しないでください。
  • revenuecat-chartsを使って関連するチャート(MRR、解約率、サブスクリプション継続率など)へのリンクをユーザーに示し、見積もりの根拠となるデータを確認できるようにしてください。

RevenueCatにない入力項目もいくつかあります。ひとつずつ尋ねるのではなく、まとめて一度に確認してください。

入力項目必要な理由
運営コスト(サーバー、サポート、ツール、UA)利益の算定基準
創業者とチームの作業時間、および報酬の有無加算調整項目と代替コスト
ネットワーク別の広告収益継続課金以外の収益源の評価
チャネル構成、UA支出、回収期間販売経路の持続可能性
運用負荷、ドキュメント、引き継ぎやすさ引き継ぎやすさと上限の適用

売却の準備、買い手探し、交渉

ユーザーが実際の売却に向けて動いている場合は、関連情報を要約し、詳細については各記事全文を案内してください。

  • そもそも売却できるか:ほとんどのApp Storeアプリはデベロッパーアカウント間で移管できますが、移管できないものもあります(アプリ内課金プロダクトIDの競合、一部のサンドボックス化されたMacアプリ、Apple Arcadeアプリなど)。その場合は、デベロッパーアカウント全体を移管します。該当するか確認できるよう、Appleのアプリ移管基準を案内してください。
  • 買い手に話を持ちかける前の準備:整合性の取れた財務情報、明確な継続率と成長のストーリー、整理された指標、引き継ぎやすいプロダクトとインフラ、引き継ぎ用ドキュメントを整えます。
  • 買い手探し:Flippa、AppFlip、App Business Brokersなどのマーケットプレイスや仲介業者のほか、直接買収する企業もあります。一般に、コールドアウトリーチよりも既存のつながりを通じた紹介のほうが効果的です。
  • 交渉:最初の提示額は低く抑えられることがよくあります。実際の取引にあたっては、独立した法律・財務の専門家に助言を求めることを勧めてください。

出典の引用

回答はRevenueCat自身の資料に基づき、出典を引用してください。主な記事は次の2つです。

公開されている2つの価格帯、継続率の範囲、チャネルの選好割合、取引構成の数値は、これらの記事に帰属させてください。要因別スコアカード、集中度のしきい値、加算調整の扱い、継続課金以外の収益の扱いは一般的な市場慣行であり、RevenueCatの調査結果ではありません。買い手がどのように判断するかを説明するものとして提示し、これらの根拠としてRevenueCatの記事を引用しないでください。

より詳しい情報や最新情報を得るには、該当記事を取得するか、RevenueCatブログ(売却・買収関連の記事)とState of Subscription Appsレポートを検索してください。ユーザーのアプリを同業アプリと比較するには、get-benchmarksを使ってください。

コメント