Claude Code で iOS 壁紙アプリ 4 タイトルの StoreKit 2 移行を並行で回した 5 月の実測ノート

StoreKit 2 移行で個人開発者がつまずく 5 つの分岐点

ここからが本題です。Apple の StoreKit から StoreKit 2 への移行は、ドキュメントを読めば手順自体は素直なのですが、個人開発で複数タイトルを扱うと別の難しさが出てきます。私が今回出会った分岐点を 5 つに整理します。

1. レシート検証を「サーバー or クライアント」のどちらに置くか

新 API の Transaction.currentEntitlements を使えばクライアントだけで完結します。ただし、サブスクの不正利用対策を真面目にやるならサーバー側で検証したいところです。私は 4 タイトルとも App Store Server API を api.dolice.asia 側に新エンドポイントを切って受け取る方式に統一しました。クライアントは fallback として Transaction.currentEntitlements も読み、両方が一致しない場合だけサーバー判定を優先するようにしています。

2. プロモーション IAP の Transaction.updates の購読タイミング

App 起動時の最初の Task で Transaction.updates を購読しないと、ユーザーが App Store からプロモーションオファーを踏んだときに購入完了イベントを取り損ねます。Claude Code に「@main の中で Task.detached で購読を張って」と頼んだのですが、初稿は App.init で同期的に呼ぶ実装で、起動が 200ms ほど遅れました。明示的にバックグラウンドタスクとして切る指示を出すまで気づきませんでした。

3. Product.products(for:) のキャッシュ戦略

StoreKit 2 の Product.products(for:) は内部キャッシュがあるとはいえ、毎回呼ぶとオフライン時にスピナーが回り続けます。私は UserDefaults に最後に取得した Product の displayPrice と id を保存し、ネットワーク不可時はキャッシュを返す実装にしました。Claude Code が提案した最初のコードは Codable で Product 全体を保存する形でしたが、Product は Codable 適合ではないので動きません。型の制約をプロンプトに含めるかどうかで提案精度が変わるところです。

4. テストフライトと本番の価格差

サンドボックスの displayPrice は実機の本番価格と異なることがあります。AdMob のリワード経由でプロ機能を解放するロジックを書いていると、サンドボックスでは ¥120 表記、本番では ¥150 表記、という差が起きます。価格表示部分を「サーバーから取った推奨価格」と「StoreKit が返す displayPrice」の二系統に切ったところ、本番のレビュー対応で 1 ターンも往復しませんでした。

5. 旧 SKPaymentQueue ベースのリスナーを「消し忘れる」

私が一番ハマったのはここです。SKPaymentTransactionObserver を残したまま Transaction.updates を購読すると、IAP の state 通知が二重で飛んできます。Crashlytics で「finishTransaction が 2 回呼ばれた」というクラッシュが本番リリース直前の TestFlight で 4 件出て、最後のステージングで気づきました。Claude Code に「旧 StoreKit のリスナー痕跡を grep して列挙してくれ」と頼むと、SKPaymentQueue.default() を含む箇所を 4 タイトル合計で 17 箇所抽出し、ここから順に潰しています。

AdMob と RevenueCat の判定順序を任せるときの落とし穴

今回の作業では RevenueCat は使わず、Apple 公式の StoreKit 2 + 自前サーバー検証で組みました。ただし AdMob のリワード広告を踏んだユーザーをプロ機能に昇格させる「reward_action_count」という API フィールドが旧来から存在し、これを StoreKit のサブスクと OR で扱う必要があります。

@MainActor
final class Entitlement: ObservableObject {
    @Published private(set) var isPro: Bool = false
 
    func refresh() async {
        let subscribed = await checkSubscription()       // StoreKit 2 由来
        let rewardUnlocked = await checkRewardUnlock()   // AdMob+サーバー由来
        let serverGrant = await checkServerEntitlement() // 自前 API
        isPro = subscribed || rewardUnlocked || serverGrant
    }
 
    private func checkSubscription() async -> Bool {
        for await result in Transaction.currentEntitlements {
            if case .verified(let tx) = result, tx.productType == .autoRenewable {
                return true
            }
        }
        return false
    }
}

Claude Code に「サブスクとリワードを OR で判定するヘルパーを書いて」と頼んだ際、最初は短絡評価でサブスクが true なら他の確認を飛ばす実装になっていました。実運用では、サブスクのキャンセル直後にリワード残期間で延命するパターンがあるので、すべての判定を必ず通したい場面があります。これも結局はプロンプトで「常に 3 経路すべて判定して」と指示し直すまで気づきませんでした。

段階公開のスケジュール設計

4 タイトル同時の段階公開はリスクが大きいので、私は以下の順序で出しました。

1. Day 1: 浮世絵壁紙（最も DAU が少ないタイトル）に 1% リリース
2. Day 3: 1% → 10% に拡大、Crashlytics と AdMob レポートを 24 時間観察
3. Day 4: 10% で問題がなければイラスト壁紙にも同じスキームで 1% 開始
4. Day 7: 浮世絵壁紙を 100% に上げると同時に、Dolice 壁紙を 1% 開始
5. Day 10: 綺麗な壁紙を最後に 1% 開始（収益寄与が最大なので最も慎重に）

この順序で、Day 3 にイラスト壁紙の Transaction.updates 二重発火を検知し、綺麗な壁紙のリリース前に修正できました。すべてを同時に上げていたらフルロールバックで広告収益が 2 日分飛んでいた計算になります。

Claude Code に渡してよかったタスクと、渡してダメだったタスク

5 月の作業を振り返ると、Claude Code に渡してよかったのは次のような工程でした。

• 4 リポ横断で同じパターンの diff を当てる作業（SKPaymentQueue 痕跡の列挙と置換）
• ATT ダイアログ文言とプライバシーマニフェストの整合性チェック
• AdMob と StoreKit の OR 判定ヘルパーの初稿生成
• レビュー前のリリースノート 4 言語版の素案作成

逆に渡してダメだったのは次のような場面です。

• 価格表記の和文校正（敬体・常体のゆらぎが残った）
• TestFlight でのみ再現するクラッシュの再現コード生成（再現せず、後で手動再現が必要）
• 段階公開のパーセンテージ判断（営業日数や DAU 推移を考えずに「すぐ 50%」と提案してくる）

私が次に試したいこと

5 月の作業はひとまず段階公開の 3 タイトル分で大きなクラッシュが出ていない状態に落ち着きました。次は、Claude Code の Hooks を使って git commit 前に「SKPaymentQueue 痕跡が残っていないか」「Transaction.updates 購読が Task.detached になっているか」を自動チェックする仕組みを足そうとしています。

並行作業は人手では限界がありますが、Claude Code に「触らない範囲」と「絶対に守る順序」をしっかり伝えれば、Mac mini 1 台でもここまでは回ります。同じように壁紙やユーティリティアプリを複数本動かしている個人開発者の方は、まず 1 タイトルだけ Claude Code に通して 1 週間運用してみる、というところから入るのが一番事故が少ないように思います。

私自身まだ模索の途中ですが、参考になれば嬉しいです。