第5章 ― 最初の5本(後編): CareFam(本番運用中) と Cat Litter Log
“本番運用1本と、最新リリース1本。スコープが違う。”
前編で MVP3本(read-big-ocr / focus-timer-adhd / sleep-mind-link)を紹介した。後編は残りの2本、CareFamとCat Litter Log。この2本は「MVP3画面」とは違う、別タイプのアプリだ。
4本目 ― CareFam(本番運用中)
**slug**: `carefam` / **bundle_id**: `ltd.nextcode.carefam` / **市場**: 高齢者家族介護共有 / **ステータス**: production
「Web=carefam.nextcode.ltd / Supabase=krbkqkqpxxjdboqxfhyj / 4言語(en/ja/it/es) / 19テーブル」と registry.json にある。これは MVP じゃない。本番運用中のフルスケールアプリだ。
**スケールが違う4つの軸**
1. **データモデル**: 19テーブル。groups/group_members/group_invites/join_requests/patients/patient_assignments/patient_relations/medications/medication_logs/visits/symptom_logs/messages/threads/notification_prefs/consent_logs/emergencies/expenses/documents/pro_share_links/subscriptions。MVP3画面じゃ収まらない。
2. **i18n**: ja / en / it / es 4言語。CFBundleLocalizations + xcstrings 完全対応。Vercel側もvercel.json redirectsでAccept-Language自動判定。
3. **Web併設**: carefam.nextcode.ltd で / privacy / terms / support / delete-account / guide(4コマ漫画) を全4言語で出してる。通貨自動切替(¥780/€4.99/$4.99/€38.99)も。
4. **専属Agent**: `agents/21_carefam_master.md` がCareFam専属メンテナ。iOSアプリ本体・Webサイト・App Store資料・Supabase の4領域全部担当。
CareFamが「専属Agent」になった理由
汎用 SwiftUI Engineer Agent では運用しきれなくなった、というのが直接の理由。CareFam固有の罠が多い。
例えば、Postgres `date` 型に Swift `Date` を送ると型エラーになる罠。'yyyy-MM-dd' 文字列で送信、Modelもdecode時に文字列→Date変換、というパターンを毎回守る必要がある。これを毎回汎用 Engineer に教えると、プロンプトが膨らむ。専属 Agent に最初から書いておく方が早い。
他にも、RLS無限再帰(stack depth limit)を `is_member` 関数の SECURITY DEFINER 化 + `group_members.SELECT` policy を `user_id = auth.uid()` のみに絞ることで防ぐ、AppleSignIn後のchoose画面戻り問題を `appleLinked` フラグで明示UI、TodayMed.id を `medId-time` に複合化して同じ薬の複数時刻を1行にまとめない、など。CareFam固有のtrap が10個以上ある。
これらを `21_carefam_master.md` の「既知の罠」セクションに全部書いてある。
CareFam の構造的設計欠陥(過去) ― 11名家族問題
CareFamの本番運用に到達するまでに、企画段階で `20_user_research_master` がブロックした事例がある。`specs/2026-04-25_carefam_user_research_review.md` に記録されている。
“「『1グループ:N patient』だけでは破綻する。`group_member ↔ patient` の M:N 関係テーブル(担当割当)を必ず先に入れる必要がある。11名のうち父担当6名・母担当5名・両方担当3名と分かれるのに、現スキーマでは『全員が両親両方を見ている』フラットな世界になり、通知が爆撃化して全員ミュート → 解約一直線。」”
11人家族モデル(父・母・兄弟4・孫4・孫嫁1)で 10シナリオ(平日朝の薬時刻 / 通院日 / 急変・救急 / 入院期間 / 退院・処方変更 / 兄弟意見対立 / 介護費用記録 / 看取り / 死別直後 / 1年後)を回して、構造欠陥を12個洗い出した。これがあるから、CareFam は実装後にスキーマ作り直しにならずに済んだ。
5本目 ― Cat Litter Log(2026-04-30 リリース)
**slug**: `cat-litter-log` / **bundle_id**: `ltd.nextcode.catlitterlog` / **市場**: ペット管理(猫トイレログ) / **ステータス**: installed_on_device(2026-04-30)
registry.json の備考にこう書いてある。「多頭飼い+シニア猫向け。月¥500/年¥4,980/Lifetime¥9,800、3日無料。AI異常検知(無排泄24h/頻度急増/赤黒色/3日下痢)+獣医PDF。4言語(ja/en/es/it) Day1。」
**Core**: 猫トイレ記録(回数/時間/便の色/量) + AI異常検知 + 獣医PDF出力
**収益モデル**: 月¥500 / 年¥4,980 / Lifetime¥9,800 / 3日無料
**差別化**: 多頭飼い(猫複数管理)とシニア猫(年齢に応じた閾値)に特化。AI異常検知の閾値が「無排泄24時間」「頻度急増」「赤黒色」「3日下痢」の4種類具体化されてる。
**重要点**: 4言語Day1。CareFamで蓄積した i18n_master のノウハウが、cat-litter-logで初日から効いている。これがアプリ工場の複利。
CareFam → Cat Litter Logの複利効果
Cat Litter Log は最初から CareFam で作った i18n / Supabase / IAP / SIWA のテンプレートを流用できた。これがアプリ工場の量産が雪だるま式になる仕組みだ。
1本目(NFCTool)は4ヶ月。2本目(CareFam)は数週間。3本目(read-big-ocr / focus-timer-adhd / sleep-mind-link)は1日3本。4本目(cat-litter-log)は4言語Day1で数日。次の6本目はもっと早くなる。これが複利。
5本のステータス比較
registry.json の5アプリ詳細(2026-04-30時点)
| slug | 市場 | ステータス | 作成日 |
|---|---|---|---|
| read-big-ocr | 老眼/OCR | installed_on_device | 2026-04-24 |
| focus-timer-adhd | ADHD | installed_on_device | 2026-04-24 |
| sleep-mind-link | 睡眠×メンタル | installed_on_device | 2026-04-24 |
| carefam | 高齢者家族介護 | production | 2026-04-25 |
| cat-litter-log | ペット管理(猫トイレ) | installed_on_device | 2026-04-30 |
5本ともリリースまで進む。MVP3本の差別化、CareFamの専属運用、Cat Litter Logの複利。これが100本のうちの最初の5本の中身だ。
「production」と「installed_on_device」の差を埋める
5本のうち、`production` と書かれているのは CareFam だけ。残り4本は `installed_on_device`。この差を埋めるのが今後の作業だ。
production = App Store 公開 + 課金回収開始。installed_on_device = 自分の iPhone で動いてる、まだ提出してない。この差は数日で埋まる。実機 → スクショ生成 → ASC API 提出スクリプト → 審査 → リリース。`skills/ios-appstore-submit-full.md` に全自動フローが書いてある。
4コマ漫画 ― 「最初の5本」
- 1コマ目registry.json: 5本登録、4本がinstalled_on_device、1本がproduction
- 2コマ目CareFam(本番) ― 19テーブル、4言語、Web併設、専属Agent
- 3コマ目Cat Litter Log ― CareFamの遺産で4言語Day1
- 4コマ目1本ごとに、次の1本が早くなる。これが複利の正体
次回、第6章は「KPI設計 ― 月300万円までの登山地図」。1ヶ月10万 / 3ヶ月50万 / 6ヶ月100万 / 12ヶ月300万+ という KPI ピラミッドを、実数の MRR モデルで因数分解する。