第2章 ― 1本当てる時代の終わり(後編): 100本に分散する戦略
“10本生き残ればMRR月100万円。だから100本作る。”
前編で「9ラウンドの絶望が、戦略を変えさせた」と書いた。後編では、その絶望をどうやって CLAUDE.md という形式知に変換したか、具体的に書く。
CLAUDE.mdの「絶対ルール」5本
アプリ工場の `CLAUDE.md` には、最重要ミッションの直下にこう書いてある。
“「絶対ルール: 完璧主義禁止 / MVP最速リリース / 月10本以上量産 / 失敗前提 / AppStore審査通過率最優先 / バグゼロ主義 / UX・継続率最優先」”
1つずつ、NFCTool の経験と紐付けて書く。
ルール1. 完璧主義禁止
NFCToolで9ラウンド食らった一番の遠因は、「完璧にしてから出す」マインドだった。「全機能揃ってから出そう」「UIをもっと磨こう」「edge case 全部対応してから」と思ってる間に、Apple のガイドラインが1つ更新されて、結果として全部やり直しになる。
完璧主義の対義語は「最低限動くもの(MVP)を1日で出す」。アプリ工場のルールは、企画決定 → 雛形 → ビルド → 提出までを最短で48時間以内に通す。read-big-ocr は実際 2026-04-24 に企画決定して同日に実機インストールまで終わってる(`registry.json` の `created_at` と `installed_at` で確認できる)。
ルール2. MVP最速リリース
MVP の定義は「3画面以内 / 1機能だけ / サブスク3日無料トライアル」。これは `agents/07_product_planner.md` に書いてある。
「3画面」と決めたのは、画面数が増えるほど審査リスクが増えるから。NFCToolは時期によって画面数が15以上あって、審査ラウンドごとに「全画面チェックされる」というコストを払い続けた。3画面なら全画面チェックされても2時間で確認できる。
ルール3. 月10本以上量産
月10本というのは、365日で120本のペース。実際のリリース歩留まりを 1/2 と見積もって、年間60本リリース。NFCToolが月数万円のMRRを立てたペースから逆算すると、60本のうち5〜10本が月数万円のMRRを立てれば、合計で月50〜100万円のMRRが見える。
10本量産するために、雛形を作って `pipeline/factory.mjs scaffold <slug>` でワンコマンド生成できる仕組みを入れた。SwiftUI + MVVM、StoreKit2、Supabase、SIWA、i18n、AppIcon、ASC API 提出スクリプト — これら全部、雛形に最初から入っている。
ルール4. 失敗前提
これは精神的にも実装的にも大事だ。`apps/registry.json` には、ステータスとして `planning / installed_on_device / submitted / production` がある。**`failed` ステータスは無い**。失敗したアプリは、ステータスを動かさず、新しいアプリを作る。失敗の言語化はするが、消すコストすらかけない。
失敗前提だからこそ、`pre_submit_local.mjs` と `pre_submit_gate.mjs` というゲートキーパースクリプトがある(`NFCーTOOL/scripts/` から流用)。提出前に必ず通す。失敗してもいいが、避けられる失敗は避ける。
ルール5. AppStore審査通過率最優先
これが NFCTool 9ラウンドの一番の教訓だ。`agents/15_apple_review_master.md` には、提出前に必ずチェックする項目が並んでいる。
Guideline 2.1(Performance、クラッシュゼロ)、2.3.7(スクショと実画面一致)、3.1.1(IAP経由以外の決済なし)、5.1.1(プライバシーポリシー完備)、Sign in with Apple必須(他SNSログインある場合)。これらは NFCTool で実際に落とされた項目を、そのままチェックリスト化したものだ。
KPI ピラミッド ― 月300万円までの登山地図
CLAUDE.md には KPI 目標がある。1ヶ月目10万円 / 3ヶ月目50万円 / 6ヶ月目100万円 / 12ヶ月目300万円+。これを実数で逆算すると、こうなる。
MRR目標 → 必要な生存アプリ数(平均MRR1万円/本想定)
| 時期 | MRR目標 | 生存アプリ数 | 総量産数(歩留まり1/10) |
|---|---|---|---|
| 1ヶ月目 | 10万円 | 10本 | 10〜15本 |
| 3ヶ月目 | 50万円 | 50本相当 | 50本相当(課金率向上で本数減) |
| 6ヶ月目 | 100万円 | 10本×平均10万円/本 | 30〜40本 |
| 12ヶ月目 | 300万円+ | 10本×平均30万円/本 | 100本 |
「1ヶ月目10万円のために10本」というのは、当然全部のアプリが月1万円立てる前提なので、現実的には15本作って5本が月2万、5本が月0、5本が月1未満、合計10万円ちょい、というイメージだ。これがアプリ工場の登山地図。
量産しても品質を落とさない仕掛け
量産=雑、ではない。雑になったら審査で落ちて結局時間ロス。だから量産しながら品質を担保する仕組みが必要だった。
1つは、Agent システム(22人のAIエージェント、第4章で詳述)。各工程に専門の Agent が責任を持つ。2つ目は、雛形のデフォルト品質。`skills/ios-app-default-ux.md` に「TextField太枠 / 自動フォーカス / プリセットchip / キーボード閉じる / トースト / 56pt高さボタン / 17pt以上文字」を絶対デフォルトとして書いてある。雛形に最初から入ってるので、量産しても UX が劣化しない。
3つ目は、i18n の Day1 投入。`agents/19_i18n_master.md` がリリース前に必ずレビューする。CareFam が初日から ja/en/it/es 4言語、ハードコード文字列ゼロで出せたのは、これが効いている。
4コマ漫画 ― 「100本に分けたら絶望が薄まった」
- 1コマ目「9ラウンド食らう絶望、もう繰り返したくない」
- 2コマ目「1本に賭けるから絶望が来る。100本に分けたら?」
- 3コマ目CLAUDE.mdに書く: 月10本量産 / 失敗前提 / 完璧主義禁止
- 4コマ目翌朝、新規アプリ3本の雛形が立ち上がっていた
次回、第3章は「アプリ工場という発想 ― CLAUDE.mdの誕生」。なぜ CLAUDE.md が「憲法」になり得たか、どのファイル構造を採用したか、なぜ `pipeline/factory.mjs` が中心にあるかを書く。