第4章 ― 22人のAIエージェント組織(後編): 品質・売上・専門の8人
“「売上」と「品質」を分けた瞬間、量産の歩留まりが上がった。”
前編で経営2 + 市場4 + 制作5 = 11人を紹介した。後編は残りの11人。
品質部(4名)
**12_bug_hunter_chief.md ― Bug Hunter Chief**
永続ループで動く。ループは5つ: 全画面クラッシュテスト、表示崩れ(iPhone SE 〜 Pro Max 全機種)、課金不具合(購入/復元/失敗/キャンセル)、多言語崩れ(en/ja/de/fr/ko/zh)、メモリリーク(Instruments)。報告先は `apps/<slug>/bugs.md`。発見即SwiftUI Engineerへ修正指示。
**13_device_tester.md ― Device Tester**
実機テストの責任者。UDID `4D4243FB-9890-59D4-9511-A2F2E30534FC` で `xcrun devicectl device install app` でインストールしてから動作確認。シムだけでは見つからないバグを実機で潰す。
**14_crash_hunter.md ― Crash Hunter**
クラッシュログ専門。報告先は `apps/<slug>/crashes.md`。
**15_apple_review_master.md ― Apple Review Master**
事前チェック必須。Guideline 2.1(Performance、クラッシュゼロ)、2.3.7(スクショ実画面一致)、3.1.1(IAP外決済なし)、5.1.1(プライバシーポリシー)、Sign in with Apple必須。リジェクト時は2-3時間以内に原因特定→修正→再提出。
売上部(3名)
**16_subscription_master.md ― Subscription Master**
価格設計: ライト¥300/スタンダード¥500/PRO¥980 + 年¥4,980/¥9,800。3日無料トライアル全プラン共通。IAP作成は `skills/ios-iap-management.md` でASC API完全自動化。解約防止: 7日後成果表示プッシュ、解約寸前ディスカウントオファー。
**17_growth_hacker.md ― Growth Hacker**
TikTok/YouTube Shorts用30秒動画、Reddit niche コミュニティへのオーガニック投稿、Product Hunt ローンチ、自社クロスプロモ。指標は CPI < LTV/3 を死守。
**18_aso_master.md ― ASO Master**
App Store キーワード最適化、ストアタイトル、サブタイトル、スクショコピー設計。
専門職(4名)
**19_i18n_master.md ― i18n Master**
全iOSアプリの文字列を完全多言語化。新規アプリ・新規画面のリリース前に必ずレビュー。ハードコード文字列を発見したら即xcstrings化。機械翻訳禁止、文脈に沿ったネイティブ品質。介護・医療・高齢者向けは敬語/親しみやすさのバランスを文化ごとに調整。CareFam が初日から ja/en/it/es 4言語で出せたのはこの Agent のおかげ。
**20_user_research_master.md ― User Research Master**
全アプリ企画の実装前に、使う側のリアルな生活・痛点・法律・文化・時系列を徹底シミュレーション。最低15軸 × 10シナリオ。実例は `specs/2026-04-25_carefam_user_research_review.md` で確認できる。CareFam の「両親別グループ問題」を企画段階で発見し、`group_member ↔ patient` の M:N 関係テーブル(担当割当)を必ず先に入れる必要がある、という構造的指摘をした。
**21_carefam_master.md ― CareFam Master**
CareFam(IT/ES/JA介護アプリ)の専属メンテナ。iOSアプリ本体・Webサイト・App Store資料・Supabase の4領域。新機能追加・バグ修正・公開作業を一手に引き受ける。
**22_domain_master.md ― Domain Master**
Vercel + バリュードメインCLI/API完全自動化。nextcode.ltd配下のサブドメイン発行をブラウザ不要・CLI/API完結で実行。`recommendedCNAME[0].value` rank 1 厳守、バリュードメインAPI PUT は curl 必須(python urllib だと 403)、既存DNS末尾追記時は改行明示。
22人の組織図、全体像
アプリ工場 22人組織図
| 部署 | 人数 | メンバー |
|---|---|---|
| 経営 | 2 | 01 CEO / 02 CFO |
| 市場調査 | 4 | 03 Trend Hunter / 04 AppStore Spy / 05 SEO Hunter / 06 Competitor Hunter |
| 制作 | 5 | 07 Product Planner / 08 Architect / 09 UI Master / 10 SwiftUI Engineer / 11 AI Integrator |
| 品質 | 4 | 12 Bug Hunter Chief / 13 Device Tester / 14 Crash Hunter / 15 Apple Review Master |
| 売上 | 3 | 16 Subscription Master / 17 Growth Hacker / 18 ASO Master |
| 専門 | 4 | 19 i18n Master / 20 User Research Master / 21 CareFam Master / 22 Domain Master |
合計22人。経営2 + 市場4 + 制作5 + 品質4 + 売上3 + 専門4 = 22。
「専門職」を後から増やした理由
最初は18人の組織図だった。後から19〜22の4人を専門職として追加した。理由は単純で、量産しながら回してたら必然的に発生した役割だから。
**i18n Master(19)** ― 機械翻訳のままリリースした初期アプリで★1食らった。各国の介護・医療用語のニュアンスは、機械翻訳じゃカバーできない。
**User Research Master(20)** ― CareFamで「1患者前提」のままスキーマを切ったら、両親持ちユーザーで詰むことが実装直前に発覚した。「実装後に気づく」を「設計前に気づく」に変える役割が必要だった。
**CareFam Master(21)** ― CareFam が複雑化しすぎて、汎用 SwiftUI Engineer では運用しきれなくなった。専属の保守 Agent を割り当てた。
**Domain Master(22)** ― バリュードメイン+Vercel連携の罠が多すぎて、毎回同じミスを繰り返してた。専属の Agent に作法を全部書いて、二度と踏まない。
つまり、専門職の追加は「失敗の頻度が一定以上になったら、その領域を専門化する」というルールから生まれている。
エージェントを「増やす」と「束ねる」のバランス
22人で十分か?と聞かれると、現時点では十分。これ以上増やすとプロンプトが膨らみすぎて、CLAUDE.md の管理コストが上がる。22人くらいが丁度いい。
ただし、量産が進むにつれて新しい専門職が必要になる。例えば「猫トイレログ専属 Master(23)」とか「老眼アプリ専属 Master(24)」とか。CareFam Master の例にならって、複雑化したアプリには専属 Agent を割り当てる方針。
4コマ漫画 ― 「22人組織のミーティング」
- 1コマ目9:00 Trend Hunter「今日のSランクは『AuDHD』『GLP-1副作用』」
- 2コマ目9:30 Product Planner「企画3本提出」 CEO「2番目で行く」
- 3コマ目10:00 SwiftUI Engineer 実装中、i18n Masterが横でレビュー
- 4コマ目18:00 Apple Review Master「審査リスクLow。提出可能」
次回、第5章は「最初の5本 ― registry.json誕生」。read-big-ocr / focus-timer-adhd / sleep-mind-link / carefam / cat-litter-log の5本がどう生まれたか、市場・差別化・収益モデルを1本ずつ書く。