Rork でサブスクリプションアプリを設計する — 課金モデルからストア審査通過まで

Rorkでサブスクリプション収益モデルのアプリを設計する手順をまとめます。料金プランの決め方、生成コードへのStoreKit組み込み、Sandboxテストで確認すべき項目、ストア審査で指摘されやすい注意点、収益化後の改善サイクルまで実践的に解説します。

アプリ開発で一番難しいのは、実は実装よりも「いくらで売るか」の設計だと、長年開発を続けてきて確信するようになりました。

Rork はプロンプトからアプリの骨格を作ってくれますが、課金モデルの設計とストア審査のノウハウは依然として人間が考える必要があります。Rork で生成したアプリに適切な収益化設計を乗せる方法を、実際の経験をもとにお伝えします。

料金プランをどう設計するか

サブスクリプションは「毎月払ってもらう」ことへのユーザーの心理的抵抗が高い課金モデルです。この抵抗を下げるための設計が、解約率に直結します。

最も重要な判断のひとつは「無料プランをどこで切るか」です。私が開発してきた壁紙・癒し系アプリでの経験から言うと、機能の一部を制限するより、使用回数や容量を制限する方が離脱率が低い傾向があります。

理由は単純で、「この機能が使えない」よりも「もっと使いたくなった」という状態でアップグレードを促せるからです。

無料: 1日3回まで、ウォーターマーク付き
Pro: 無制限、ウォーターマーク非表示、高解像度ダウンロード

この構造では、ユーザーが価値を確認した後に課金を判断できます。「お試しして価値を感じたから払う」の流れが、「払わないと使えない」より解約率を低く保てます。

価格の設定については、月額 ¥500〜¥1,000 の範囲が日本市場でのスイートスポットと感じています。Apple が推奨する価格ティアで言えば Tier 3〜7 の範囲です。年払いは月払いの約 60〜70% の価格設定にすると、LTV（顧客生涯価値）が大幅に上がります。

Rork のコードに StoreKit を組み込む

Rork が生成した React Native / Expo ベースのコードに、expo-in-app-purchases または react-native-purchases（RevenueCat）を組み込む方法を説明します。

RevenueCat は初期設定のコストはありますが、iOS/Android の両対応と分析機能がそろっていて、長期的には時間の節約になります。Rork に以下のようなプロンプトを渡すと、ボイラープレートを生成してくれます。

RevenueCat を使ったサブスクリプション購入フローを追加してください。
以下の構造にしてください:
- useSubscription カスタムフック（購入状態の管理）
- SubscriptionScreen（価格表示・購入ボタン）
- PremiumGate コンポーネント（非購読者へのブロック表示）
購入完了後に isSubscribed: true を返してください。

生成されたコードを実際に動かす前に、RevenueCat ダッシュボードで商品 ID を正確に入力することが必須です。ここのタイポが原因でテスト購入が失敗するケースが非常に多いです。

// RevenueCat の初期化（App.tsx またはルートコンポーネント）
import Purchases from 'react-native-purchases';
 
const API_KEY_IOS = 'YOUR_REVENUECAT_IOS_KEY';
const API_KEY_ANDROID = 'YOUR_REVENUECAT_ANDROID_KEY';
 
export async function initPurchases() {
  Purchases.setLogLevel(Purchases.LOG_LEVEL.DEBUG); // 開発中のみ
  await Purchases.configure({
    apiKey: Platform.OS === 'ios' ? API_KEY_IOS : API_KEY_ANDROID,
  });
}

Sandbox テストで確認すべき項目

実機での Sandbox テストは、ストア審査の前に必ず完了させてください。特に確認すべき項目は次の通りです。

購入フロー: 正常購入 → プレミアム機能解放の確認。これだけでは不十分で、キャンセル（購入ダイアログで戻るボタン）後のアプリ状態が壊れないかも確認します。

復元フロー: 「購入を復元」ボタンが正しく機能するか。Apple の審査ガイドラインはこのボタンを必須としています。ないとリジェクトされます。

サブスク切れのシミュレーション: Sandbox では期間を短縮できます（月額 = 5分更新）。切れた後にアプリがどう振る舞うか、再購読フローがスムーズかを確認します。

ストア審査を通過するための注意点

課金関連のリジェクト理由で最も多いのは以下の三つです。

Guideline 3.1.1 — アプリ内課金の回避。「こちらから購入できます」という外部URLへの誘導は一切禁止です。Rork が生成するコードにたまにウェブ決済へのリンクが入ることがあるので、必ず確認してください。

Guideline 3.1.2(b) — サブスクリプションの内容が不明確。何が含まれるかをスクリーンショットと説明文で明示する必要があります。「プレミアム機能」のような曖昧な表現だけではリジェクトされます。

Guideline 4.0 — 機能が少なすぎる。Rork で生成した最小構成のアプリをそのまま申請すると、機能不足でリジェクトされることがあります。最低でも 5〜7 の実用的な機能が必要です。

審査メモ（App Review Notes）には、サブスクリプションのテストアカウント情報を必ず記載してください。審査官がテストできないアプリはリジェクトされます。

収益化後の改善サイクル

リリース後の最重要指標は「トライアル→有料転換率」と「月次解約率」です。

転換率が低い場合、原因はたいてい二つです。無料体験の価値が伝わっていないか、課金タイミングが早すぎるかです。RevenueCat のコンバージョンファネルを見ながら、購入画面に到達しているかどうかを確認するのが最初のステップです。

解約率については、月 5% 以下を目標にするのが現実的です。それ以上の場合は、プッシュ通知で価値を再想起させるか、長期ユーザーへのロイヤルティ割引を検討してください。

Rork でアプリの骨格を素早く作れるようになった今、差別化のポイントは実装速度よりも「どう収益化するか」の設計力にあると感じています。