In-App Purchase — 概要、購入の種類、収益化の仕組み

In-App Purchaseとは？

In-App Purchase（IAP）は、モバイルアプリケーション内でデジタル商品やサービスを販売できる技術です。支払いはApp Store（iOS）またはGoogle Play（Android）を通じて処理され、取引処理手数料がかかります。開発者はストアの手数料を差し引いた金額を受け取ります。

Appleは30%の手数料（収益が100万ドル未満の小規模事業者は15%）を請求します。Google Playも30%（開発者収益の最初の100万ドルまでは15%）を請求します。2024年から、Googleは開発者が代替支払いシステムを利用できるUser Choice Billingプログラムをテストしています。

App StoreとGoogle Playのポリシーに従い、アプリ内でのデジタル商品販売にはIAPが必須です。物理的な商品、サービス（ライドシェア、フードデリバリー）、P2P支払いは第三者の支払いシステムを利用できます。

In-App Purchaseの種類：consumable、non-consumable、サブスクリプション

App StoreとGoogle Playは3つの主要なIn-App Purchaseタイプをサポートしています。各タイプは異なる収益化モデル向けに設計されています。製品タイプの選択は、購入復元ロジック、サブスクリプション管理、アプリ再インストール時の動作に影響します。

Consumable（消費型購入）

消費型購入は、複数回購入でき、使用中に消費されるアイテムです。典型的な例：ゲーム内通貨（コイン、ジェム）、追加ライフ、ブースター、消費型パワーアップ。アプリを再インストールしても消費型アイテムは復元されません — 開発者は自社サーバーで各ユーザーの残高を管理します。

Non-Consumable（非消費型購入）

非消費型購入は、一度購入すると永久に利用できるアイテムです。例：アプリの完全版、プレミアムレベル、フィルターのロック解除、広告削除。非消費型製品はRestore Purchases APIを通じて復元可能です：再インストール後、ユーザーは以前に購入したアイテムを再請求なしで取り戻せます。

Auto-Renewable Subscription（自動更新サブスクリプション）

自動更新サブスクリプションは、一定期間（週、月、年）のコンテンツやサービスへのアクセスに対する定期支払いです。ユーザーがアカウント設定でキャンセルするまで、サブスクリプションは自動的に更新されます。ストアはサブスクリプションステータスの変更（更新、期限切れ、返金）に関するサーバー通知（App Store Server Notifications、Google Play Developer Notifications）を提供します。

App Store ConnectとGoogle Play ConsoleでのIAP設定

設定は開発者パネルから始まります：iOS用のApp Store ConnectとAndroid用のGoogle Play Consoleです。各製品について、プロダクトID、名前、説明、タイプ、および地域通貨に自動変換される米ドル価格を指定します。作成後、製品はストアの審査を受けます。

App Store Connectでは、IAP製品はFeatures → In-App Purchasesセクションで作成します。各製品について、タイプ（consumable、non-consumable、auto-renewable subscription、non-renewing subscription）を選択し、ローカライズされた名前を入力します。サブスクリプションの場合は、サブスクリプショングループ（互換性のあるサブスクリプションのグループ）を追加で設定します。

Google Play Consoleでは、管理製品はMonetise → Products → In-app productsセクションで設定します。GoogleはManaged Product（non-consumableに相当）とSubscriptionという用語を使用します。Androidでの消費型購入には、製品を再購入可能にリセットする個別のconsumeフラグを使用します。

IAP製品の審査は通常、App Storeで24～48時間、Google Playで数時間かかります。価格変更は再審査なしで即座に適用されます。プロダクトIDは作成後に変更できません — 削除して再作成するのみです。

サーバーサイドのレシート検証と不正防止

レシート検証はIn-App Purchase処理の必須ステップです。クライアントアプリケーションが自社サーバーにレシートを送信し、サーバーがApple API（https://buy.itunes.apple.com）またはGoogle API（https://androidpublisher.googleapis.com）を通じて検証し、検証成功後にのみユーザーにアイテムを提供します。

サーバーサイド検証がないと、攻撃者がストアの応答を偽装してアイテムを無料で入手できてしまいます。クライアントサイド検証はユーザーが制御する環境で実行されるため安全ではありません。サーバーサイド検証により、レシートが本物で支払いが成功したことが保証されます。Appleの場合はverifyReceiptエンドポイント（本番またはサンドボックス）で検証し、Googleの場合はAndroid Publisher APIで検証します。両ストアともJSON形式で確認を返します。

Appleはレシートに購入データ（product_id、transaction_id、purchase_date、expiration_date（サブスクリプション用））を返します。GoogleはPurchases.products.getまたはPurchases.subscriptions.get APIを通じて同様のフィールドを返します。サーバーは各レシートのtransaction_idを保存し、リプレイ攻撃を防ぐために同じIDの重複リクエストを拒否する必要があります。

SwiftとKotlinを使ったモバイルアプリへのIAP統合

統合にはプラットフォームライブラリの接続が必要です：iOSのStoreKit 2とAndroidのBilling Library 7+。APIを使用して、製品一覧の取得、購入の開始、結果の処理、以前に購入したアイテムの復元ができます。

Swift — iOS 17+のStoreKit 2

import StoreKit

func purchaseProduct(productID: String) async throws {
    guard let product = try await Product.products(for: [productID]).first else { return }
    let result = try await product.purchase()
    switch result {
    case .success(let verification):
        let transaction = try verification.payloadValue
        await validateReceipt(transaction)
        await transaction.finish()
    default:
        break
    }
}

Kotlin — Billing Library 7

import com.android.billingclient.api.BillingClient
import com.android.billingclient.api.BillingFlowParams

val billingClient = BillingClient.newBuilder(context)
    .setListener { billingResult, purchases ->
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
            purchases?.forEach { purchase ->
                validateReceipt(purchase)
            }
        }
    }
    .build()

val params = BillingFlowParams.newBuilder()
    .setProductDetails(productDetails)
    .build()
billingClient.launchBillingFlow(activity, params)

サーバーサイドのレシート検証（Node.js）

const response = await fetch('https://buy.itunes.apple.com/verifyReceipt', {
    method: 'POST',
    body: JSON.stringify({
        'receipt-data': receiptBase64,
        'password': 'SHARED_SECRET'
    })
})

const data = await response.json()
if (data.status === 0) {
    // レシート確認済み — アイテムを提供中
    await grantProduct(data.receipt.product_id)
}

In-App Purchaseによる収益化のベストプラクティス

収益化には、慎重に設計された価格戦略とUXが必要です。ユーザーは低価格の魅力的なスターターパックを提供されると、最初の購入に踏み切りやすくなります。AppleとGoogleは、購入確認の前に製品価格を表示することを推奨しています。

サブスクリプションオンボーディングは重要なコンバージョン段階です。支払いを請求する前に、無料トライアル期間、プラン比較、特典リストなど、サブスクリプションの価値をユーザーに示してください。調査によると、無料トライアル期間により有料ユーザーへのコンバージョンが25～40%向上します。

購入復元（Restore Purchases）は非消費型製品とサブスクリプションで必須です。復元ボタンはアプリ設定または支払い画面でアクセス可能にする必要があります。GoogleとAppleは、関連するIAPタイプの購入復元が実装されていない場合、アプリを拒否する可能性があります。

猶予期間（Grace Period）は、支払い失敗後もユーザーがアクセスを維持できるサブスクリプションの猶予期間です。iOSとAndroidは最長30日の猶予期間をサポートしています。猶予期間を有効にすると、チャーンレートが10～15%低下します。

A/Bテストは重要な収益化手法です。App Store Connectは再審査なしで価格変更が可能な現地価格（Price Tiers）をサポートしています。Google Play Consoleは1つのサブスクリプション製品に対して最大5つの異なる価格のベースプランを設定できます。最低2つの価格ポイント（現在と新しい価格）をテストすることを推奨します。テストは価格ポイントごとに少なくとも1000ユーザーのサンプルで2～4週間実施します。

ストアレビューと却下対応はIAPアプリ公開の必須段階です。Appleは自動更新サブスクリプション付きアプリを特に厳しく审查します：アクティブなサブスクリプション付きテストアカウントの提供、サブスクリプションキャンセル画面の表示、購入復元の実装が必要です。Google Playはそれほど厳しくありませんが、デジタルコンテンツの権利確認が必要です。IAPロジックを説明するレビューノートを追加することを推奨します。