◈ Agents & Manager/2026-05-27上級

6 アプリ並行の iOS 更新を Antigravity の Main / Sub エージェントで束ねた実体験

Beautiful HD Wallpapers / Ukiyo-e Wallpapers / Relaxing Healing / Law of Attraction を含む 6 アプリの iOS 更新を、Antigravity の Main エージェント + 6 サブエージェント構成で並行運用した実装ノート。直列化すべきところと並列化すべきところの判断軸を残します。

antigravity⁴³⁵ agents⁹⁰ ios³⁵ indie-development orchestration¹⁵

✦ プレミアム記事

Beautiful HD Wallpapers / Ukiyo-e Wallpapers / Relaxing Healing / Law of Attraction / Cool Wallpapers / Fractal Galleria — この 6 アプリの iOS 更新を、Antigravity の Main エージェントと 6 体のサブエージェントで束ねたのが、今月の個人開発の中心仕事でした。新 iPhone 解像度対応、Firebase の CocoaPods → SPM 移行、StoreKit 2 への切り替え、ATT プロンプト順序の見直しが同時に走っていたため、人間 1 人で 6 アプリを並列に持つことは難しい状況です。

ここで重要だったのは、「並列化できる仕事」と「直列で 1 人の頭を通さないと壊れる仕事」を最初に切り分けることでした。私が個人開発を 12 年続けてきて分かったのは、判断と作業を混ぜたまま AI エージェントに渡すと、後で帳尻が合わなくなる、という構造的な落とし穴です。Antigravity の Main / Sub エージェント構成は、この帳尻問題に正面から向き合える設計でした。

まずは「6 アプリ × 4 タスク」の依存グラフを描く

最初にやったのは、6 アプリ × 4 タスク（解像度 / Firebase SPM / StoreKit 2 / ATT）の依存グラフを 1 枚の紙に書くことです。

新解像度 ────┐
            ├──→ ビルド確認 ──→ TestFlight ──→ App Store Connect 段階公開
Firebase SPM ┤
            │
StoreKit 2 ──┤
            │
ATT 順序 ───┘

このグラフの「ビルド確認」までは並列化できます。「TestFlight」以降は App Store Connect 側のキューがあるため、6 アプリを完全に並列に流すと処理が積まれて遅くなります。直列ノードと並列ノードを混在させるなら、その境目をエージェントに事前に伝える ことが、6 アプリ並行運用の出発点でした。

Main エージェントに渡した最初のプロンプト

Antigravity の Main エージェントに渡したプロンプトは、判断と作業を分離した形にしました。

あなたは 6 アプリ並行 iOS 更新の Producer です。実装作業は行わず、
Sub エージェントへの指示と進捗監視のみを担当してください。
 
各 Sub エージェントには、以下の 4 タスクを順に投げてください:
  T1: 新解像度（iPhone Air / 17 Pro / 17 Pro Max）対応
  T2: Firebase Apple SDK の CocoaPods → SPM 移行
  T3: StoreKit 2 への移行（SKPayment → Transaction.currentEntitlements）
  T4: ATT プロンプト順序（MobileAds 初期化前に呼ぶ）
 
判断ルール:
  - T1 と T4 は依存なし、並列化してよい
  - T2 は T1 のビルドが通ってから着手（ビルド失敗の原因切り分けのため）
  - T3 は T2 の Firebase 動作確認が取れてから着手
  - 各タスクの完了条件は「ビルド成功 + TestFlight 内部配信通過」
 
報告フォーマット:
  | App | T1 | T2 | T3 | T4 | Notes |

Main エージェントを「Producer」と定義したのが効きました。実装に手を出さないと宣言させると、Sub エージェントへの委任に集中します。判断は人間とMain、作業は Sub という三層構造が、6 アプリ並行運用の最小単位になりました。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦Beautiful HD Wallpapers をはじめとする 6 アプリの iOS 更新（新解像度 + Firebase SPM + StoreKit 2 + ATT 順序）を、Antigravity の Main / Sub エージェントで束ねるための具体的な分担マップを再現できます

✦12 年の個人開発で見えてきた「並列化してよいタスク」と「直列で 1 人の頭を通すべきタスク」の判断軸を、実際の 6 アプリ運用のリリースゲートに落とし込めます

✦Antigravity の Plans 機能を 6 アプリで共有する場合の、競合と差分管理の設計（命名規約 + diff チェック + Crash-free 99.7% を超えるロールバック判定）を導入できます

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

Sub エージェントが手を出してはいけない領域

Sub エージェントには、それぞれ 1 アプリの作業を任せました。同時に、Sub が手を出してはいけない領域 を明文化したのが効きました。

あなたは Beautiful HD Wallpapers の Sub エージェントです。
以下の領域には絶対に手を出さないでください:
 
1. AdMob のメディエーション設定（収益直結のため Producer 承認必須）
2. App Store Connect 上の段階公開比率の変更
3. Stripe 連携の課金プラン定義
4. 6 アプリで共有している DefineManager.h のマクロ宣言
5. 5,000 万 DL を超える既存ユーザーの優先度に関わるレビュー返信文面
 
これら以外のコード変更・テスト実行・PR 作成は自律的に進めてよいです。

12 年の個人開発を続けてきて、最も痛い目を見るのは「収益に直結する設定の自動変更」です。AdMob の eCPM 設定や App Store Connect の価格層、これらはエージェントに勝手に動かされると 1 日で月収数十万円が消えます。私は明示的に Sub の作業範囲から外し、Main の上に人間の判断を必ず置く構造にしています。

並列化してよかったタスク

実際に並列で動かせたのは、「T1: 新解像度対応」と「T4: ATT 順序見直し」でした。

T1 は前回の記事で書いた通り、DefineManager.h に三項演算子を 29 箇所追加する仕事です。6 アプリで同じ手順を踏むため、Main から 6 Sub に同じテンプレートを渡せます。

T4 の ATT 順序見直しは、AppDelegate.application(_:didFinishLaunchingWithOptions:) 内の呼び出し順を変えるだけです。

// 修正前: MobileAds 初期化が ATT より先に走っていた
GADMobileAds.sharedInstance().start(completionHandler: nil)
ATTrackingManager.requestTrackingAuthorization { _ in }
 
// 修正後: ATT 完了を待ってから AdMob 初期化
ATTrackingManager.requestTrackingAuthorization { status in
    DispatchQueue.main.async {
        GADMobileAds.sharedInstance().start(completionHandler: nil)
        // Crashlytics への opt-in 状態の記録もここで
        Analytics.setUserProperty(
            status == .authorized ? "authorized" : "denied",
            forName: "att_status")
    }
}

iOS の ATT は MobileAds 初期化前に呼ばないと、AdMob のメディエーション側でユーザートラッキングのシグナルが間に合わず、eCPM が下振れする可能性があります。これは公式ドキュメントの行間にしか書かれていない実運用の落とし穴で、6 アプリ並行で同時に直したかった理由でもあります。

T1 と T4 は他タスクへの副作用がほぼないため、Main は 6 Sub に同時投入できました。実時間で 90 分以内に 6 アプリ × 2 タスクが完了しています。

直列にすべきだったタスク

逆に、T2（Firebase SPM 移行）と T3（StoreKit 2 移行）は直列にすべきでした。

Firebase の CocoaPods → SPM 移行は、Podfile を完全に削除して Package.swift 経由に切り替える作業です。途中で .swiftpm/xcuserdata や Pods/ の Dropbox 同期競合が起きやすく、私は最初に Relaxing Healing で検証してから他 5 アプリに展開しました。

# Dropbox 同期競合を防ぐ xattr フラグ
xattr -w com.dropbox.ignored 1 build
xattr -w com.dropbox.ignored 1 Pods
xattr -w com.dropbox.ignored 1 .swiftpm
xattr -w com.dropbox.ignored 1 xcuserdata

このコマンドはアプリごとに必ず 1 回打つ必要があります。Sub エージェントに渡すと「Dropbox の挙動を知らないため hang する」可能性があるので、Main が直接実行するようにしました。エージェントに任せてよい仕事と、人間または Main 経由で実行すべき仕事は、開発環境の特殊性で線が引かれるという気づきが得られました。

StoreKit 2 への移行は、Transaction.currentEntitlements の async sequence への切り替えです。

// 旧 StoreKit 1
SKPaymentQueue.default().restoreCompletedTransactions()
 
// StoreKit 2 への切り替え
Task {
    for await result in Transaction.currentEntitlements {
        if case .verified(let transaction) = result {
            await handlePurchasedEntitlement(transaction)
        }
    }
}

ここは挙動を間違えると課金復元が動かなくなる領域なので、6 アプリで一度に切り替えるのは危険でした。1 アプリで TestFlight 検証を完了してから残り 5 アプリに展開する直列運用に切り替えています。

Main エージェントへの「報告フォーマット」固定が効いた

Main エージェントには、進捗報告のフォーマットを最初に固定させました。

| App                  | T1 | T2 | T3 | T4 | Notes                          |
|----------------------|----|----|----|----|--------------------------------|
| Beautiful HD         | ✅ | ✅ | ⏳ | ✅ | StoreKit 2 検証中（残 1 アイテム）|
| Ukiyo-e              | ✅ | ✅ | ⬜ | ✅ | T3 は明日着手                   |
| Relaxing Healing     | ✅ | ✅ | ✅ | ✅ | 段階公開 50% 突入               |
| Law of Attraction    | ✅ | ⏳ | ⬜ | ✅ | SPM 移行の hang を調査中        |
| Cool Wallpapers      | ✅ | ⬜ | ⬜ | ✅ | T2 着手待機                     |
| Fractal Galleria     | ✅ | ⬜ | ⬜ | ✅ | T2 着手待機                     |

このテーブルがあると、Main が Sub の遅延を即座に検知できます。Law of Attraction で SPM 移行に hang が出た時点で、私は他 5 アプリの T2 着手を一時停止しました。理由は、同じ hang が他アプリでも出る可能性があったからです。Producer 役の Main が全体を俯瞰しているからこそ、こうした横断的な判断ができます。

6 アプリ並行運用の Crash-free 監視

段階公開後の Crash-free 監視は、6 アプリ分のフィルタを 1 つの Crashlytics ダッシュボードにピン留めしました。

project_id IN [bw, uw, rh, loa, cw, fg]
AND app_version >= "3.0.0"
AND fatal == true
AND device_model starts_with "iPhone18"

これで 6 アプリ × 新解像度の起動クラッシュを一度に俯瞰できます。閾値は Crash-free users 99.7%、ANR 0.20% 未満です。1 アプリでも閾値を下回ったら、Main エージェントに「該当アプリの段階公開比率を 0% に halt する PR を作る」と指示するだけで止められます。

Crashlytics の Issue を起点に Claude on Xcode に流す手順は、Claude Lab の Glide 5.0.5 の記事と同じテンプレートで動いています。Antigravity と Claude on Xcode を併用すると、Producer が判断、Sub が一次対応、Claude on Xcode が IDE 内の手直し、という三段ロケットになります。

1997 年から続けてきた個人開発と、エージェント時代の判断

1997 年に独学でインターネットに触れ、2014 年から個人でアプリを公開し続けて累計 5,000 万 DL を超え、その間ずっと「人間 1 人で何アプリまで持てるか」を考えてきました。Antigravity の Main / Sub エージェント構成は、6 アプリ並行を初めて現実的にしてくれた仕組みだと感じています。

ただし、エージェントに何でも任せると判断と作業が混ざります。私が個人開発の中で大切にしているのは「収益直結の意思決定」と「歴史的経緯を必要とするコード」だけは自分の頭を通すことです。AdMob の eCPM、Stripe の価格、5,000 万ダウンロードを支えるユーザーへのレビュー返信文面 — これらは人間が手で書きます。それ以外の「ビルドを通す」「テストを書く」「TestFlight に上げる」は Sub に任せるという線引きで、ようやく 6 アプリ並行が持続可能になりました。

両家の祖父が宮大工で、見えない接合部を丁寧に組む姿を子供の頃に見ていました。Antigravity の Main / Sub の関係も、見えにくい接合部を丁寧に設計しなければ崩れます。Sub に作業を渡すときに「触ってはいけない領域」を文章で書ききっておくと、半年後に別アプリで同じ事故が起きません。

試してみる最初の一歩

もし今、複数アプリやサービスを個人で並行運用しているのであれば、Antigravity の Plans 機能で 1 アプリだけ Main / Sub の 2 階層を試してみることを推奨します。Main の仕事を「あなたは Producer であり、自分では実装しない」と明文化するところから始めると、エージェントに渡してよい範囲が自然に整理されます。

同じく個人で複数プロジェクトを抱えている方の参考になれば幸いです。お読みいただきありがとうございました。