第6章 ― KPI設計(後編): registry.jsonとkpi/dashboard.mjsで全アプリを1画面に
“見えない数字は伸ばせない。だからdashboard.mjsを書いた。”
「見えない数字は伸ばせない」。これは経営の鉄則。アプリ工場でも、5本 → 10本 → 30本 と増えていったときに、どのアプリが伸びてどれが死んでるか、一画面で見える仕組みが必要だ。それが `kpi/dashboard.mjs`。
kpi/dashboard.mjs の現状(Step1)
現在の dashboard.mjs はミニマル実装。中身はこう。
1. `apps/registry.json` を読み込む
2. アプリ総数を出す
3. ステータス別の集計を console.table で出す
4. ASC Sales Reports API 連携は『Step2 で実装』とコメントだけ書いてある
Step1ではあえて最小実装に留めた。理由は、最初は registry の中身をシンプルに集計するだけで十分だから。アプリが30本超えてから ASC API に手を出す。
「Step1で十分」というMVP判断
ダッシュボード自体も MVP だ。CLAUDE.md の「完璧主義禁止」「MVP最速リリース」がここにも効いている。
Sales Reports API を実装してフルダッシュボードにすると、開発に2週間かかる。その間 dashboard が無い状態が続くより、20行の最小ダッシュボードを今日デプロイして、registry の集計だけでも見える方が遥かに価値が高い。
dashboard が伸びれば、Step2 で ASC連携。Step3 で 解約率分析。Step4 で 予測モデル。段階的に拡張する。
ASC Sales Reports API の概要
Step2で実装予定の ASC Sales Reports APIの概要。App Store Connect には Sales Reports API があり、毎日のDL数・売上・国別集計を JSON でダウンロードできる。
認証は ASC API Key + JWT。アプリ工場の認証情報は HANDOFF.md に記録あり: Key `775PX32QH5` / Issuer `d89909ec-...` / p8 `/tmp/apple_keys/AuthKey_775PX32QH5.p8`。これは ios-appstore-submit-full.md でも使ってる同じキー。
1日1回 cron で叩いて、registry.json の各アプリエントリに `daily_dl` `daily_mrr` `country_top3` をマージする設計。
CFOレポートの中身
`agents/02_cfo.md` の出力フォーマットはこう書かれている。`kpi/cfo_report_YYYY-MM-DD.md` に「アプリ別 MRR / 継続率 / LTV / CAC」「今月の総API費用」「停止推奨アプリ / 伸ばすべきアプリ Top3」を毎日。
サンプル(まだ実装してないが理想形): 「2026-05-01 ― 全5アプリ集計。MRR合計 ¥125,000(前月比+25%)。Top3伸長: carefam(月¥80,000、+15%) / read-big-ocr(月¥25,000、+30%) / cat-litter-log(月¥12,000、+200% リリース直後)。停止推奨: なし。今月API費用: Claude¥15,000 / OpenAI¥8,000 / Supabase¥5,000 = ¥28,000。利益率: 77.6%。」
kpi/ の中の更新ループ
毎日のフローは、こう設計してある。
**朝(6:00 cron)**: ASC Sales Reports API を叩いて昨日のデータ取得 → registry.json 更新 → kpi/daily_*.json 出力
**朝(7:00 Trend Hunter)**: market_research/YYYY-MM-DD_*.md を出力
**朝(8:00 CFO Agent)**: kpi/cfo_report_YYYY-MM-DD.md を出力 → 停止推奨があれば CEO に通知
**朝(9:00 CEO Agent)**: CFOレポート + 市場調査を読んで、当日の方針決定
**夜(20:00 dashboard.mjs)**: 当日のダッシュボードを stdout に出して終了
全部 cron + JSONファイル。SaaSダッシュボードは買わない。10万円の Mixpanel 契約より、20行のスクリプトの方が透明で早い。
「JSONファイルベース」の哲学
アプリ工場はDB に依存せず、JSON ファイルベースで動く。registry.json、market_research/*.md、specs/*.md、kpi/*.json、logs/*.log。全部テキストファイル。git で変化を追える。Claude Code が読んで判断できる。
この哲学は CLAUDE.md にも反映されている。「全リポジトリ読込は禁止。指定ファイルのみ読む」。1ファイルあたり数百行に収めて、Claude Code のコンテキスト効率を最適化する。
結果として、ダッシュボードは「ノートPCで `cat registry.json | jq` する」レベルの素朴さで運用できる。これがアプリ工場の透明性。
計測の盲点 ― 「気持ち」
数字で全部見えるか、というとそうじゃない。月MRR 5万円のアプリと月MRR 5,000円のアプリ、後者の方が『書いてて楽しい』ことがある。これは KPI に出ない。
アプリ工場では、KPI 第一だが、KPI が拾わない『楽しさ』『学び』『コミュニティ』は無視しない。CareFamがその例で、MRR的にはまだ立ち上げ期だが、4言語・19テーブル・Web併設の規模で動かす経験そのものが、次の99本の品質を底上げする。これは数字に出ない複利。
4コマ漫画 ― 「dashboard.mjsの真夜中」
- 1コマ目深夜2:00、5本のアプリが動いてる。どれが伸びてる?」
- 2コマ目kpi/dashboard.mjsを書く。20行。registry.jsonを集計するだけ
- 3コマ目node kpi/dashboard.mjs → 「Total: 5 / production: 1 / installed: 4」
- 4コマ目完璧じゃない。でも見える。これでよい。Step2はASC API連携」
次回、最終章 第7章は「ブルーオーシャン20本 ― 次の100本の地図」。market_research/2026-04-24_top20.mdの全20本を1本ずつ評価し、次に作るアプリの優先順位と、創業編全体のまとめを書く。