ARR を盛る AI スタートアップを見て、micro SaaS の自分が決めた数字の出し方

今朝の研究ログに、TechCrunch の「How VCs and founders use inflated 'ARR' to crown AI startups」が入っていました。AI スタートアップが、まだ署名も入金も済んでいない契約見込みまで足し込んだ数字を、ただの ARR として公表している。VC 側もそれを承知で黙認し、業界全体で「盛った成長数字」が普通の状態になっている、という調査記事です。読みながら、桁も規模もまるで違うのに、これは micro SaaS を回している自分にも地続きの話だと感じました。

ARR と CARR の境目が、意図的に溶かされている

記事の核心は、ARR と CARR という二つの数字の境目をわざと曖昧にしている点にあります。ARR は確定した年間経常収益で、いま実際に課金が回っている分です。CARR は契約済みだが開始前・請求前の見込みまで含む数字で、定義上 ARR より大きくなります。記事が指摘しているのは、多くの AI スタートアップが高い方の CARR を計算し、それを「ARR」というラベルで発表しているという構図です。

怖いのは、これが明白な嘘ではないことです。「契約は取れている」のは事実で、ただラベルを一段階すり替えているだけです。だから誰も訴えられないし、VC も次のラウンドで使える数字が大きいほうが都合がいいので止めません。境目を溶かすインセンティブが、出す側と受け取る側の両方に働いています。これは個人開発の MRR 報告にも、形を変えて存在する誘惑だと思っています。無料トライアル中のユーザー、年払い前提で月割りしていない契約、解約予告済みだがまだ課金されている分。どれを足してどれを引くかで、同じ事業の数字が平気で 1.5 倍くらい動きます。

一人だと、盛る誘惑も盛るコストも両方小さい

スタートアップが数字を盛るのは、次の資金調達のためです。個人開発には VC がいないので盛る相手がいない、と言いたいところですが、実際には違いました。X に「micro SaaS で MRR をいくら達成した」と書く瞬間や、Show HN で実績を一行に圧縮する瞬間に、まったく同じ誘惑が来ます。読み手に強い印象を与えたいので、つい一番大きく見える数字を選びたくなるのでした。

ただ、一人でやっていることには救いもあります。数字を分解して問われたときに、即座にバレるという点です。スタートアップの ARR は監査の壁の向こうにあって外からは検算できませんが、個人開発者が出す数字は規模が小さいぶん、「その MRR は年払いを月割りしているか、無料期間は抜いているか」と聞かれたら逃げ場がありません。だからこそ、一人にとっては正直であることが最も低コストな戦略になります。これは 複数の micro SaaS を一人で回している 立場で、特にそう感じています。一度盛った数字は、次に正直な数字を出した瞬間に矛盾するからです。

「崩れない数字」は、それ自体が差別化になりつつある

ARR インフレが業界の標準運転になればなるほど、逆に実数を分解して出す個人開発者の信頼が相対的に上がる、という気がしています。build in public の文脈で実数を出す indie hacker が支持されるのは、数字の大きさではなく、その数字が後で崩れないという信頼に対してです。盛られた数字が溢れる市場では、控えめでも崩れない数字のほうが資産になります。

自分の場合、これは少し具体的なルールに落としています。gpdf のような MIT License の OSS は、そもそも直接の売上がゼロの部分があります。その上に乗る hosted な API は別の数字です。この二つを混ぜて「gpdf で MRR がいくら」とは言わないようにしています。OSS のダウンロード数や Star は売上ではないので、売上の話をするときには持ち出さない。副業として micro SaaS をやる 規模では、数字が小さいのは前提なので、小さいことより崩れることのほうがずっと痛いと考えています。

質問への応答

個人開発で ARR を気にする意味はあるのか

資金調達をしないなら、ARR の絶対額そのものにはあまり意味がありません。VC に見せる数字ではないからです。意味があるのは、出した数字が半年後に検算されても崩れないこと、そして確定売上と見込みを自分の中で常に分けておくことです。記事の AI スタートアップがいつか直面するのは、CARR と ARR の差を現実に詰められなかったときの揺り戻しです。個人開発で同じ轍を踏まないために必要なのは、大きく見せる技術ではなく、最初から分けて数える規律のほうだと思っています。

今朝の他に読むべき記事

• Project Glasswing: An Initial Update (Anthropic) Anthropic の Mythos Preview を AWS や Google ら 50 社超と使い、初月で高・重大の脆弱性を 1 万件超発見したという報告です。AI が脆弱性発見を一気に加速させる中で、OSS メンテナーが修正ペースをどう保つかが問われます。
• AI is being used to resurrect the voices of dead pilots (TechCrunch) 事故で亡くなった UPS パイロットの声を AI がスペクトログラムから再構成し、NTSB が調査資料の公開を一時制限した事例です。死者の声を復元できる時代に、開発者が何を設計原則に置くかを考えさせられます。
• Deno 2.8 (Deno Blog) Node.js 互換テストの成功率が 42% から 76.4% へ、npm インストールが 3.66 倍高速化しました。TypeScript ランタイムの選択肢が本格的に広がってきたと感じます。
• The Case for Design Disposables (Nielsen Norman Group) デザイナーが思考のために作る「捨てる前提のアーティファクト」を、完成度の高い納品物と分ける主張です。プロトタイピングの探索フェーズと納品フェーズを切り分ける発想として読めます。
• Closing the Loop: What to Do After a Design Critique Ends (Nielsen Norman Group) デザインクリティークは実施するだけでは足りず、変更内容を参加者へ返す「ループを閉じる」ことが信頼を作るという実践ガイドです。OSS のレビュー文化にも応用が効きそうです。
• Smart ring maker Oura files to go public (TechCrunch) スマートリングの Oura が 550 万個の販売実績と 110 億ドル評価で SEC に届け出ました。ハードウェアのサブスク収益でここまで来た事例として、マネタイズ設計の参考になります。

次に renma や gpdf-api の数字を誰かに話すときは、まず確定分と見込み分を分けてから口を開くようにします。盛らないことが、一番安く効く差別化になる気がしています。