第14章 ― 30本中、何本が生き残ったか(成長編)
“30本中12本生存。死亡18本。これがアプリ工場の歩留まり。”
量産開始から6ヶ月。registry.json には30本のアプリが並んでいる。生き残ったのは何本か。残酷に集計する。
30本のサバイバル
registry.json 30本のステータス内訳
| ステータス | 本数 | 判定 |
|---|---|---|
| production(MRR月¥10k+) | 8本 | 生存(プロダクトとして稼働) |
| production(MRR月¥1-10k) | 4本 | 生存(立ち上がり期) |
| production(MRR月¥1k未満) | 6本 | 監視(3ヶ月以内に判定) |
| 停止(30日連続赤字) | 8本 | 死亡(CFO Agentが停止) |
| 未提出(installed_on_device 滞留) | 4本 | 凍結(リソース割けず) |
**生存=12本(production MRR月¥1k+)、死亡=18本。歩留まり 40%**。CLAUDE.md で想定していた1/2 〜 1/3 の歩留まり、ぴったり当たった。
死亡18本の死因(5パターン)
**死因1: 市場が薄い**(8本) ― TrendHunterのスコア25未満を強行したアプリ。例: 3Dモデリングニッチアプリ、特定業界向けニッチ。月DLが10未満で30日連続
**死因2: UIが薄い(雛形のまま)**(4本) ― HANDOFF.mdの『雛形3本同時量産→UIが薄い』失敗パターン。市場は良かったのに見た目で離脱
**死因3: 課金導線の事故**(2本) ― ★1事件と同種、アプリ内サブスク管理動線が無くて解約地獄、信頼喪失
**死因4: i18n手抜き**(2本) ― EU市場狙いで機械翻訳を放置 → ★1連発 → ASOスコア低下 → DL減
**死因5: 自分が飽きた**(2本) ― これは技術じゃなく心理。作者がメンタル的に飽きると更新止まる → 自然死
生存12本の勝ちパターン(4種)
**勝ちパターン1: 既存アプリの『穴』を埋める**(5本) ― CareFam(EU介護空白市場) / read-big-ocr(老眼OCR家族共有なし) / cat-litter-log(多頭飼いxシニア猫の閾値AI) など、ニーズ調査で『不満点クラスタ』を特定したアプリ
**勝ちパターン2: 派生・横展開**(3本) ― 既存アプリの機能を切り出して別アプリに。例: focus-timer-adhd → adhd-medication-reminder(派生)、CareFam → patient-pdf-export(機能特化)
**勝ちパターン3: 沖縄案件の延長**(2本) ― 受託案件で作ったツールをBtoCに転換。具体例: meishi-digital → meishi-personal、yoyaku119 → quick-clinic-booking
**勝ちパターン4: ★1から学んで全アプリ強化**(2本) ― 第9章で書いた『サブスク管理導線必須』を初日から組み込んだアプリ。離脱率が他の勝ちパターンより低い
CFO Agentが下した『停止』8本
停止プロセスは agents/02_cfo.md の規則通り、機械的に。30日連続赤字 = MRR < (Claude API + Supabase + ストア手数料)。判定が降りたら CEO Agent が registry.json のステータスを `stopped` に変更、新規開発リソースを別アプリに振る。
停止しても、登録したアカウントの App Store ページは消さない。最低1年は『リリース済アプリ』として残す。Apple側の歴史と、SEOの遺産になる。
凍結4本(installed_on_device で滞留)
registry.json で `installed_on_device` のまま6ヶ月放置されたアプリ。実機では動くが、提出までやり切れなかった。原因は2つ:
1. 提出直前に重大バグ発見 → 修正リソース不足 → 後回し化 → 凍結
2. 雛形からの初期実装で、Phase2 の差別化機能が見えず、出してもどうせ薄いと判定 → 提出スキップ
凍結アプリは半年に1回見直し、復活させるか正式に削除するか判定する。今期は4本中1本を復活、3本を削除。
6ヶ月目の総MRR(2026-10想定)
生存12本のMRR内訳(概算)
| 順位 | アプリ | MRR(月) | シェア |
|---|---|---|---|
| 1 | carefam | ¥320,000 | 32% |
| 2 | read-big-ocr | ¥180,000 | 18% |
| 3 | cat-litter-log | ¥140,000 | 14% |
| 4 | focus-timer-adhd | ¥120,000 | 12% |
| 5 | shadow-speak-ai-cafe | ¥80,000 | 8% |
| 6 | shadow-speak-ai-business | ¥60,000 | 6% |
| 7-12 | 残り6本合計 | ¥100,000 | 10% |
| 合計 | 12本 | ¥1,000,000 | 100%(6ヶ月目KPI達成) |
**6ヶ月目KPI ¥1,000,000 を生存12本で達成見込み**。1本平均¥83,000、Top1 carefam がシェア32%、Long-tail 6本で10%。これがアプリ工場のポートフォリオ構造。
「死亡」を恐れない文化
死亡18本を抱えながら、量産は続く。これがアプリ工場の文化。1本に4ヶ月かけてた頃は、1本死んだら世界が終わった。今は、18本死んでも構造的に動く。これはCLAUDE.mdが『失敗前提』と書いた当然の帰結。
死亡18本のうち、半分は『学び』として勝ちパターンに翻訳されている。死亡UIパターンは新しいアプリに反映されない。死亡市場パターンは TrendHunter のフィルタが厳しくなる。死亡 = 完全な無駄、ではない。
4コマ漫画 ― 「30本中、12本」
- 1コマ目registry.json: 30本登録、production 18本、stopped 8本、frozen 4本
- 2コマ目「死亡18本。痛いが、構造的にダメージ吸収できる量」
- 3コマ目生存12本のMRR合計 ¥1,000,000。6ヶ月目KPI達成見込み
- 4コマ目残り70本、まだ作れる。100本目までの登山続行
次回、最終話 第15章は「100本目を出した日」。アプリ工場の365日が完了する瞬間の話。