課金状態の「正」はどこにある？ — Antigravityで設計するad-free Source of Truthパターン

AdFreeManager：状態の集約点を作る

AdFreeManager は、課金状態の唯一の出どころになるクラスです。アプリ内のどこからでも、このクラスを通じて状態を取得します。

実装のポイントは、isAdFree という単一のプロパティが「購入済みかどうか」と「リワード視聴後かどうか」の両方を考慮した上で最終的な状態を返すことです。呼び出し側は、どちらの理由で ad-free になっているかを意識する必要がありません。

class AdFreeManager private constructor(
    private val billingManager: BillingManager,
    private val rewardManager: RewardedAdManager
) {
    val isAdFree: Boolean
        get() = billingManager.isPurchased() || rewardManager.isAdFreeSession
 
    val isPermanentlyAdFree: Boolean
        get() = billingManager.isPurchased()
 
    val isSessionAdFree: Boolean
        get() = rewardManager.isAdFreeSession && !billingManager.isPurchased()
 
    companion object {
        @Volatile private var instance: AdFreeManager? = null
 
        fun getInstance(
            billingManager: BillingManager,
            rewardManager: RewardedAdManager
        ): AdFreeManager = instance ?: synchronized(this) {
            instance ?: AdFreeManager(billingManager, rewardManager).also {
                instance = it
            }
        }
    }
}

シングルトンパターンを採用しているのは、アプリ全体で状態が一致することを保証するためです。@Volatile と synchronized の組み合わせは、マルチスレッド環境でのインスタンス生成の競合を防ぐ慣用的な書き方です。

isAdFree、isPermanentlyAdFree、isSessionAdFree の3つのプロパティに分けているのも設計上の工夫です。ほとんどの場所では isAdFree を使えばよいのですが、「購入済みの人だけに表示する永続的な機能」と「リワード視聴後の一時的な特典」を区別したい場面があります。その場合は isPermanentlyAdFree や isSessionAdFree を使うことで、コードの意図が明確になります。

これ以降、アプリ内の全ての判定は adFreeManager.isAdFree に集約されます。

BillingManager：Google Play Billing との橋渡し

AdFreeManager が依存する BillingManager は、Google Play Billing Library のラッパーです。設計の核心は、購入状態を StateFlow で管理することです。

StateFlow は Kotlin Coroutines のデータホルダーで、値が変わると購読者に自動的に通知されます。購入状態に StateFlow を使う理由は明確です。購入完了や購入復元は非同期イベントとして発生するため、イベント駆動の設計が自然に合います。また、画面回転などの構成変更が起きても、StateFlow が最後の値を自動的に再配信するため、UI の状態が失われません。

class BillingManager(private val context: Context) {
 
    private var billingClient: BillingClient? = null
    private val _isPurchasedFlow = MutableStateFlow(false)
    val isPurchasedFlow: StateFlow<Boolean> = _isPurchasedFlow.asStateFlow()
 
    init {
        setupBillingClient()
    }
 
    private fun setupBillingClient() {
        billingClient = BillingClient.newBuilder(context)
            .setListener { billingResult, purchases ->
                if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
                    handlePurchases(purchases)
                }
            }
            .enablePendingPurchases(
                PendingPurchasesParams.newBuilder()
                    .enableOneTimeProducts()
                    .build()
            )
            .build()
        connectAndVerify()
    }
 
    private fun connectAndVerify() {
        billingClient?.startConnection(object : BillingClientStateListener {
            override fun onBillingSetupFinished(billingResult: BillingResult) {
                if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
                    queryExistingPurchases()
                }
            }
            override fun onBillingServiceDisconnected() { }
        })
    }
 
    private fun queryExistingPurchases() {
        val params = QueryPurchasesParams.newBuilder()
            .setProductType(BillingClient.ProductType.INAPP)
            .build()
        billingClient?.queryPurchasesAsync(params) { billingResult, purchases ->
            if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
                handlePurchases(purchases)
            }
        }
    }
 
    private fun handlePurchases(purchases: List<Purchase>?) {
        val hasPurchased = purchases?.any { purchase ->
            purchase.products.contains(PRODUCT_ID_AD_FREE) &&
            purchase.purchaseState == Purchase.PurchaseState.PURCHASED
        } ?: false
        _isPurchasedFlow.value = hasPurchased
    }
 
    fun isPurchased(): Boolean = _isPurchasedFlow.value
 
    companion object {
        const val PRODUCT_ID_AD_FREE = "remove_ads"
    }
}

重要なのは、handlePurchases が呼ばれるタイミングが2か所あることです。ひとつは startConnection の成功後（queryExistingPurchases 経由）で、アプリ起動時に既存の購入を確認します。もうひとつは setListener のコールバックで、購入フローが完了した直後に呼ばれます。この2つのトリガーにより、購入直後と起動時の両方で状態が正確に更新されます。

ModalGate：ダイアログの競合を防ぐ

Source of Truth の考え方は、ダイアログ表示の管理にも応用できます。

私の壁紙アプリには、課金関連のダイアログが複数存在します。PaywallDialog（広告削除の課金案内）、ReviewInductionDialog（アプリレビュー誘導）、RewardedInterstitialDialog（リワード広告の説明）の3つです。

これらが同じタイミングで表示されようとすると、ユーザー体験が壊れます。ペイウォールを閉じようとしたらレビュー画面が出てきて、リワード広告を視聴しようとしたら別のダイアログが割り込みます。こういう状況が実際に起きていました。

根本的な問題は、各ダイアログが「今他のダイアログが表示されているかどうか」を知る手段を持っていないことです。そこで ModalGate という概念を導入しました。アプリ全体でダイアログの表示状態を管理するシングルトンであり、全てのダイアログがここを通じて表示を試みます。

object ModalGate {
    private val activeModal = AtomicReference<String?>(null)
 
    fun tryShow(tag: String): Boolean {
        return activeModal.compareAndSet(null, tag)
    }
 
    fun dismiss(tag: String) {
        activeModal.compareAndSet(tag, null)
    }
 
    fun isShowing(): Boolean = activeModal.get() != null
    fun currentTag(): String? = activeModal.get()
}

AtomicReference.compareAndSet(expected, update) は、現在の値が expected と一致する場合にのみ update に書き換え、成功すれば true を返します。これにより「表示を試みる → 成功なら表示 → 失敗なら諦める」というスレッドセーフなプロトコルが実現されます。ロックを使わないため、デッドロックのリスクがありません。

全ての DialogFragment はこのプロトコルに従います。

class PaywallDialog : DialogFragment() {
 
    override fun onStart() {
        super.onStart()
        if (!ModalGate.tryShow(TAG)) {
            dismissAllowingStateLoss()
        }
    }
 
    override fun onDismiss(dialog: DialogInterface) {
        super.onDismiss(dialog)
        ModalGate.dismiss(TAG)
    }
 
    override fun onDestroyView() {
        super.onDestroyView()
        ModalGate.dismiss(TAG)
    }
 
    companion object {
        const val TAG = "PaywallDialog"
    }
}

onDestroyView でも dismiss を呼んでいるのは、アプリがバックグラウンドに移動してプロセスが強制終了したとき、onDismiss が呼ばれない場合への保険です。両方でクリアすることで、ModalGate にタグが残り続ける問題を防いでいます。

実装で直面した4つの罠

AdFreeManager・BillingManager・ModalGate の実装を通じて、私自身がはまった問題を共有しておきます。

罠1：BillingClientの接続タイミング問題

BillingClient は非同期で接続されます。アプリ起動直後に isPurchased() を呼ぶと、まだ接続が確立していないため false が返ることがあります。購入済みのユーザーが起動直後に AdMob のバナー広告を一瞬見てしまう、という事象でした。

当時の対策は、SplashScreen の表示中に BillingClient の初期接続と購入確認を終わらせ、ホーム画面へ移る時点で StateFlow の値を確定させることでした。待機時間を少し延ばすコストで誤表示を減らす、という発想です。

この対策は減らしはしましたが、消しはしませんでした。理由と、作り直した設計は後段の「起動直後の『まだ分かりません』を false と呼ばない」で書き残します。

罠2：ModalGateのバックスタック復元後の残存状態

アプリがバックグラウンドに移動してプロセスが強制終了したとき、フォアグラウンドに戻ると ModalGate.activeModal に古いタグが残ることがありました。ダイアログが onDismiss を呼ばずに消えた場合に発生します。

対策として、DialogFragment の onDestroyView にも ModalGate.dismiss(TAG) を追加しました。onDismiss と両方でクリアすることで、残存を防いでいます。処理の重複はありますが、compareAndSet の特性上、余分な呼び出しは安全に無視されます。

罠3：テスト時のシングルトン汚染

object ModalGate はプロセスライフタイムのシングルトンです。ユニットテストで複数のテストケースが ModalGate の状態を共有してしまい、テスト間で干渉が起きました。テストを一個実行すると次のテストの tryShow が失敗する、という一見わかりにくいバグでした。

対策として、テスト専用の ModalGate.reset() メソッドを @VisibleForTesting アノテーション付きで追加し、各テストケースの @Before でリセットするようにしました。本番コードからは呼ばれないように、アノテーションでドキュメント化しています。

罠4：acknowledgePurchase の3日期限

Billing Library 2.0 以降、購入は3日以内に承認（acknowledge）しないと自動的に払い戻されます。私の場合、購入フロー自体は正常に見えるのに、数日後に「購入が取り消されていた」という問い合わせが届いたことがありました。原因を追うと、acknowledgePurchase の呼び出しが購入直後のコールバックにしか存在せず、通信断やプロセス終了でそこを通らなかった購入が、未承認のまま期限切れになっていました。

対策は、購入直後のコールバックだけでなく、起動時の queryPurchasesAsync の結果側でも未承認の購入を検出して承認することです。

private fun handlePurchase(purchase: Purchase) {
    if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED
        && !purchase.isAcknowledged) {
        val params = AcknowledgePurchaseParams.newBuilder()
            .setPurchaseToken(purchase.purchaseToken)
            .build()
        billingClient?.acknowledgePurchase(params) { result ->
            if (result.responseCode != BillingClient.BillingResponseCode.OK) {
                // 失敗時は次回起動時の照会で再試行される（この経路に置くこと自体が再試行機構になる）
            }
        }
    }
}

起動時の購入照会と同じ経路にこの処理を置くことで、「アプリを起動しさえすれば未承認が解消される」状態を作れます。課金状態を Source of Truth に集約してあると、こうした追加処理の置き場所が一意に定まります。これも集約がもたらす恩恵のひとつです。

起動直後の「まだ分かりません」を false と呼ばない

罠1 に書いた「スプラッシュで待つ」という対策を、いまの私は採りません。あれは時間で殴る対処で、回線の細い端末や Play ストアの応答が鈍い日には届かないのです。

原因は待ち時間の長さではなく、型のほうにありました。MutableStateFlow(false) という既定値は、「購入していない」と「まだ分かっていない」を同じ false に畳んでしまいます。広告枠のコードには、この2つを見分ける手段がありません。購入してくださった方に広告が一瞬出るのは、ここから来ています。

どれくらい広い範囲で起きることなのか、手元で模型を作って確かめました。広告枠が最初に isAdFree を読む時刻を t_ui、startConnection から queryPurchasesAsync のコールバックが返るまでを t_bill として、t_ui を 0〜1,000ms、t_bill を 0〜2,000ms の 10ms 刻みで総当たりした 20,301 点の格子です。実機の計測値ではありません——順序の問題が格子のどのあたりを占めるかを見るためだけの、条件を固定した模擬です。

その格子の上では、既定値 false の設計は 15,150 点（74.6%）で購入済みの方に広告を出しました。t_bill が 300ms を超える領域に絞ると 85.5% です。そしてスプラッシュを延ばすという対策は、この面積を削るだけで、ゼロにはしません。

ゼロにするには、格子の右端まで——つまり想定する最悪の応答時間より長く——待つしかありません。実際の t_bill に上限はありませんから、この方針は原理的に終わりません。全員に2秒の白画面を見せて、それでもなお取りこぼす設計です。

そこで私は既定値をやめ、状態そのものを三値にしました。

sealed interface AdFreeState {
    data object Unknown : AdFreeState
    data class Known(val adFree: Boolean, val source: Source) : AdFreeState
 
    enum class Source { CACHE, BILLING, REWARD }
}

BillingManager 側は、キャッシュを「とりあえずの正」として先に置き、Google Play の応答が返った時点で必ず上書きします。判定できなかった応答は、false に読み替えずにそのまま無視します。

private val _state = MutableStateFlow<AdFreeState>(AdFreeState.Unknown)
val state: StateFlow<AdFreeState> = _state.asStateFlow()
 
init {
    // キャッシュは暫定値。billing の応答が来れば必ず上書きされる
    if (prefs.getBoolean(KEY_AD_FREE, false)) {
        _state.value = AdFreeState.Known(adFree = true, source = Source.CACHE)
    }
    setupBillingClient()
}
 
private fun handlePurchases(result: BillingResult, purchases: List<Purchase>?) {
    if (result.responseCode != BillingClient.BillingResponseCode.OK) return
    if (purchases == null) return  // OK だが中身が無い応答を「未購入」と読み替えない
 
    val hasPurchased = purchases.any { purchase ->
        purchase.products.contains(PRODUCT_ID_AD_FREE) &&
        purchase.purchaseState == Purchase.PurchaseState.PURCHASED
    }
    prefs.edit().putBoolean(KEY_AD_FREE, hasPurchased).apply()
    _state.value = AdFreeState.Known(adFree = hasPurchased, source = Source.BILLING)
}

前の版との差は ?: false を落としたところだけに見えますが、意味は大きく変わります。通信が失敗した瞬間に ad-free を取り上げてしまう経路が、ここで閉じます。

UI 側は、Unknown を「広告を出す」ではなく「まだ描かない」に対応させます。

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        adFreeManager.state.collect { state ->
            when (state) {
                is AdFreeState.Unknown -> adContainer.isVisible = false
                is AdFreeState.Known -> adContainer.isVisible = !state.adFree
            }
        }
    }
}

キャッシュを種として置く効果も、同じ格子で測りました。誤表示は 15,150 点から 201 点（1.0%）へ減り、残るのはキャッシュの読み出しが終わる前に広告枠が描かれた場合だけです。スプラッシュを2秒に延ばすより、5ms のキャッシュ読み出しのほうが効きます。

未確定を false に丸めた時点で、真実源はひとつではなくなります。 分からないという状態を型として持ち、それを UI まで運ぶところまでが Source of Truth の仕事なのだと、作り直してから気づきました。

ついでに、当時のコードにはもうひとつ穴がありました。onBillingServiceDisconnected() の中身が空だったことです。切断されたあと再接続も再照会もしないため、別の端末で購入を復元した方の状態は、次にプロセスを立ち上げ直すまで届きません。いまは切断時に指数バックオフで再接続し、onResume でも queryPurchasesAsync を呼び直しています。購入の照会を onResume で行うことは、一時購入商品のライフサイクルにも取得手段のひとつとして書かれています。

Antigravityを「設計の壁打ち相手」として使う

ここまでのコードは、Antigravity と会話しながら設計しました。Antigravity の使い方として、コードを生成させることに集中する方が多いと思います。しかし私が最も価値を感じているのは、設計の問いかけに答えてもらうという使い方です。

たとえば、こういう問いかけをします。「BillingManager と SharedPreferences の両方に課金状態があります。どちらを Source of Truth にすべきか、その根拠は何か」「複数のダイアログが競合する問題を解決したい。AtomicReference 以外のアプローチも見せてほしい」「このコードの潜在的な問題点を挙げてほしい。特にマルチスレッドとライフサイクルの観点で」といった形です。

Antigravity は、コードを生成する前に「なぜそうするのか」を説明してくれます。この説明を理解した上でコードを受け取ることが、単なるコピーアンドペーストではなく、設計の力として自分に蓄積されていきます。

AIが生成したコードでも、自分の手で一行ずつ確認してから組み込む——この一手間を私は省かないようにしています。生成されたコードを読み解く時間こそが、提案された設計を自分の設計に変える時間だと感じているからです。

UIとの統合：StateFlowで広告表示を自動更新する

設計が整ったところで、実際にどう使うかを示します。Application クラスで全てのマネージャーを初期化し、Fragment から参照するパターンです。

class MyApplication : Application() {
    lateinit var billingManager: BillingManager
        private set
    lateinit var rewardedAdManager: RewardedAdManager
        private set
    lateinit var adFreeManager: AdFreeManager
        private set
 
    override fun onCreate() {
        super.onCreate()
        billingManager = BillingManager(this)
        rewardedAdManager = RewardedAdManager()
        adFreeManager = AdFreeManager.getInstance(billingManager, rewardedAdManager)
    }
}
 
class HomeFragment : Fragment() {
    private val app by lazy { requireActivity().application as MyApplication }
 
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
 
        viewLifecycleOwner.lifecycleScope.launch {
            app.billingManager.isPurchasedFlow.collect { _ ->
                updateAdVisibility()
            }
        }
    }
 
    private fun updateAdVisibility() {
        val isAdFree = app.adFreeManager.isAdFree
        binding.bannerAdView.visibility = if (isAdFree) View.GONE else View.VISIBLE
    }
}

このパターンにより、ユーザーが購入を完了した瞬間に isPurchasedFlow が更新され、それを購読している全てのFragmentで updateAdVisibility() が自動実行されます。手動でのUI更新は不要です。購入直後に「もう一度起動してください」とユーザーに伝える必要がなくなります。

この設計が生み出す長期的なメリット

Source of Truth を設計することで、短期的なバグ修正にとどまらない恩恵があります。

新しい課金プランを追加する場合、変更は AdFreeManager の isAdFree プロパティの判定ロジックだけです。Fragment やService に散らばった判定を探して回る必要がありません。新しい広告フォーマット（リワード動画、インタースティシャルなど）を追加する場合も、RewardedAdManager の更新と AdFreeManager への影響を確認するだけです。

ModalGate も同様です。新しいダイアログを追加するとき、ModalGate に乗るだけで競合が防がれます。既存のダイアログがどのタイミングで表示されるかを調査する必要がありません。

個人開発の運営を続けてきて痛感するのは、最も消耗するのが「どこを直せばいいかわからないバグ」だということです。Source of Truth の設計は、その消耗を根本から減らします。

アーキテクチャ設計をAntigravityと学ぶ価値

Antigravity を使って設計を学ぶとき、私が意識しているのは「Antigravity が提案した設計を、なぜその設計にしたかを理解してから採用する」という姿勢です。

今回の AdFreeManager + BillingManager + ModalGate という組み合わせも、最初の提案のままではなく、いくつかの問い返しを経て今の形になっています。「なぜシングルトンなのか」「Dependency Injection を使った場合との比較は」「テスタビリティへの影響は」といった問いを返すたびに、設計の理解が深まりました。

Antigravity との設計の会話は、コードを手に入れるための手段ではなく、設計力を身につけるための学習プロセスとして機能します。生成されたコードを採用するかどうかは最終的に自分が判断するという姿勢が、長期的な保守性につながります。

全体を振り返って：今日から始める最初の一歩

自分のアプリに課金機能がある方は、まずこれを確認してみてください。

grep -rn "is_ad_free\|isPurchased\|isAdFree\|isAdRemoved" \
  app/src/main/java/ --include="*.kt" --include="*.java" | wc -l

10件以上ヒットするなら、Source of Truth の設計を検討する価値があります。まず Antigravity に既存コードを見せて「課金状態の Source of Truth を設計したい」と伝えてみてください。コードより先に「どこが問題で、何を目指すのか」を整理してもらうことで、リファクタリングの方向性が明確になります。

移行の進め方は、次の順序をおすすめします。

1. 既存コードの課金状態参照を上記の grep で洗い出し、参照箇所の一覧を作ります
2. BillingManager を導入し、Google Play Billing への問い合わせを1クラスに閉じ込めます
3. AdFreeManager を作り、洗い出した参照箇所を isAdFree の参照へ1か所ずつ置き換えます
4. 最後に ModalGate を導入してダイアログ表示を集約します（この段階は独立しているため、後回しでも構いません）

一度にすべてを書き換えるのではなく、参照箇所を1つずつ AdFreeManager 経由に移す進め方なら、動作確認しながら安全に移行できます。

Source of Truth は、地味ですが確実に効く設計投資です。機能を追加するたびに課金状態の判定を書き直す必要がなくなり、バグの追跡が1か所に収束します。個人で長くアプリを育て続けるための、静かな土台になります。

最後までお読みいただきありがとうございました。同じ課題に取り組んでいる方の参考になれば幸いです。

個人開発者がアーキテクチャ設計を学ぶ意味

個人開発でアーキテクチャ設計を学ぶことには、企業の開発とは異なる意味合いがあります。企業では、設計の悪さはチーム全体の生産性の問題です。しかし個人では、設計の悪さは直接、運営の持続可能性に直結します。

この壁紙アプリのコードベースは、初回リリース以来少しずつ変化し続けています。最初のバージョンは Java で書かれていました。少しずつ Kotlin に置き換わり、いまは大半が Kotlin です。UI も何度か刷新されています。この間、機能が増えるたびに当時のベストプラクティスでコードを追加してきました。

問題は、それぞれの時代のベストプラクティスが必ずしも互いに一貫していないことです。2015年頃に書かれた SharedPreferences 周りのコードと、2022年に追加されたリワード広告の状態管理は、異なる前提の上に書かれています。この「時代の差」が、技術的負債の本質的な発生源です。

Source of Truth のような設計原則を採用することの価値は、未来の自分への配慮です。3年後の自分が機能を追加するとき、今書いたコードがどれだけ「追加しやすい構造」になっているかを考えること。Antigravity はその「未来への配慮」を設計の言葉で具体化する手助けをしてくれます。

設計判断の記録という習慣

もうひとつ、Antigravity との設計の会話を通じて学んだことがあります。設計判断を記録しておくことの価値です。

なぜ SharedPreferences を Source of Truth にしなかったのか。なぜ StateFlow を選んだのか。ModalGate に AtomicReference を使った理由は何か。これらは、数年後に同じコードを読んだとき（多くの場合、それは未来の自分です）、「なぜこうなっているのか」を理解するための文脈です。

Antigravity との会話ログを DEVELOPMENT_NOTES.md として残しておく、という習慣を始めました。コードのコメントとは異なり、設計判断の経緯と却下した代替案を記録しておくことで、リファクタリング時の意思決定が速くなります。「ここはこういう理由で AtomicReference にした。Mutex に変えると〇〇の問題がある」という記録が、将来の自分の時間を節約します。

アプリを個人で長く運営するということは、事業の設計とコードの設計が一致していなければ持続できない、ということでもあります。良い設計は、単なる技術的な美しさではなく、長く運営し続けるための実用的な基盤です。Antigravity はその基盤を作る思考の相手として、実際に役立っています。

Google Play Billing Library のバージョンアップへの備え

Source of Truth 設計のもうひとつの利点は、ライブラリのバージョンアップへの耐性です。

Google Play Billing Library には、バージョンごとに2年の廃止サイクルがあります。各版に「新規アプリとアップデートの締切」と「延長申請の締切」が設定されていて、一覧は公式の廃止に関する FAQ にあります。

この記事を見直している2026年9月の時点で、v7 のままのアプリは新規リリースもアップデートも提出できません。延長を申請していても2026年11月1日で終わります。移行先は v8 以降で、v9 への移行ガイドも公開されています。

もうひとつ、更新したはずなのに Play Console の警告が消えないときは、AndroidManifest.xml の com.google.android.play.billingclient.version がマニフェストマージで落ちていないかを確かめてみてください。私はここで半日ほど手が止まりました。

こうした移行のとき、課金状態の判定が5か所に散らばっていれば、5か所すべてを直す必要があります。ひとつ見落とせば、そこだけ古い API を使い続けることになります。

BillingManager にラッパーを設けることで、API変更の影響範囲が BillingManager 内部に閉じます。handlePurchases の実装が変わっても、isPurchased() と isPurchasedFlow のインターフェースが保たれていれば、呼び出し側のコードは一切変更不要です。

AdFreeManager も同様です。将来「定期購読型の ad-free プランを追加する」という要件が出てきたとき、変更は AdFreeManager の isAdFree の判定ロジックに対して billingManager.isSubscribed() を追加するだけです。Fragment やActivity のコードは変更しません。

これは個人開発において特に重要です。企業なら複数人でコードレビューしながらライブラリ更新できますが、個人では自分ひとりで全ての変更点を追う必要があります。影響範囲を最小化する設計は、そのままメンテナンスコストの削減です。

副次効果：レビューへの返答品質が上がる

Source of Truth 設計の話からは少し外れますが、バグが減ることで生まれる副次効果についても触れておきたいと思います。

「広告が消えない」というレビューへの返答は、バグが再現しているときと修正済みのときとで、質が大きく変わります。再現中は「ご不便をおかけして申し訳ございません。現在調査中です」という曖昧な返答しかできません。しかし修正済みであれば「v2.1.0 でこの問題を修正しました。アップデートをお試しください」と具体的に案内できます。

私の壁紙アプリには日本語・英語・中国語・スペイン語など複数の言語圏のユーザーがいます。多言語でのレビュー返答は Antigravity を使って処理していますが、返答の質は「修正済みかどうか」という事実が土台になります。設計が良くなることは、ユーザーコミュニケーションの質にも直結します。

個人で長くアプリを育てていくとき、技術的な品質とユーザーとの信頼関係は切り離せません。Source of Truth のような設計原則は、コードの話でありながら、ユーザーとの関係を守る話でもあります。設計に投資することは、ユーザーへの投資でもあると感じています。