この記事についてClaude(Anthropic)との共同編集により作成されました。
要約
- モバイルアプリにサブスク課金を入れようとして、StoreKitとGoogle Play Billingを自前で叩く運用コストの高さに気づいた
- 主要5社は「業界デファクト系(RevenueCat)」「ペイウォール最適化系(Adapty / Superwall)」「価格・差別化系(Qonversion / Apphud)」の3系統に分かれる
- 無料枠は Qonversion / Apphud / Superwall が5K、RevenueCatは$2.5K と差が大きいが、個人開発レベルではどれも当面はゼロ円で動く
- 個人開発フェーズなら RevenueCat が無難な選択。ドキュメント・SDK網羅性・エコシステムの厚みで、最初の1本に迷ったらここで困ることはない
- ペイウォールABテストや自動ウィンバックを本格化したいフェーズに入ったら Adapty / Superwall / Apphud を併用・移行する選択肢がある
- 2025年3月にGlassfyが事業清算した教訓もあり、無料で攻めるSaaSより長く残りそうなデファクトを選んでおくのが個人開発では効く
個人開発で作っているモバイルアプリにサブスクリプション課金を入れたくなった。が、AppleとGoogleそれぞれのストアAPIを直接叩いて、レシート検証サーバを立て、解約・グレースピリオド・返金・リストアを全部自分で面倒見るのは現実的じゃない。本業の合間に書いている個人プロジェクトでそこを丁寧に作り込むのは無理がある。
そこで「サブスク管理SaaS」と呼ばれるカテゴリを横断的に整理して、いまどれを選ぶのがいちばん無難か、自分なりに調べ直したのが本記事だ。具体的にはRevenueCat・Adapty・Qonversion・Apphud・Superwallの5社を比較し、最後に個人開発フェーズではRevenueCatに倒すのが安全という結論に至った。その途中で見えた他社の強みも合わせて整理する。
そもそも何を肩代わりしてくれるSaaSなのか
最初に、このカテゴリのSaaSが具体的に何を引き受けてくれるのかを整理しておく。モバイルアプリでサブスクを自前実装する場合、開発者が抱えることになる作業はざっくり以下のとおりだ^1。
- レシート検証サーバの構築・運用 — AppleとGoogleから受け取るレシートをサーバサイドで検証する仕組みを自前で持つ必要がある
- サブスクリプション状態管理のステートマシン — 更新・キャンセル・グレースピリオド・ダウングレード・アップグレード・返金・リストアなど、22種類以上のイベントに対応するステートを全部捌く
- クロスプラットフォーム対応 — iOS / Android / Web のそれぞれで取得した購入情報を、同一ユーザーとして紐付けて一元管理する
- ストアAPIの継続的変更への追従 — Apple/Googleは課金APIの仕様を頻繁に更新する。追従し続けるメンテナンスコストが地味に重い
これを自前で丁寧に作るなら、それだけでバックエンドエンジニアが1人専任で必要になるレベルの作業量がある。サブスク管理SaaSは、これを丸ごと肩代わりしてくれる「サブスクリプション・バックエンド・イン・ア・ボックス」として位置づけられている^2。
具体的に提供される機能を並べるとこうなる。
- サーバサイドレシート検証
- 正規化されたサブスクリプションデータ(ストアごとの差異を吸収)
- エンタイトルメント解決エンジン(「このユーザーはどの権限を持つか」の判定)
- リアルタイムWebhookによるライフサイクルイベント通知
- クロスプラットフォームでの顧客データ統合
- ダッシュボードによる分析・顧客管理
つまり、自前でやるなら最低でも数ヶ月かかる仕事を、SDK導入+ダッシュボード設定で1日〜1週間に圧縮してくれる、という位置づけだ。個人開発でサブスクを入れるなら、迷わずこのカテゴリのSaaSを使うべき、という前提から話を始める。
主要サービスは3系統に分かれる
調べていくと、サブスク管理SaaSは大きく3つに分類できる。
| カテゴリ | サービス | 特徴 |
|---|---|---|
| 業界デファクト系 | RevenueCat | エコシステムの厚みとSDK網羅性で標準扱い。最初の1本に困らない |
| ペイウォール最適化系 | Adapty, Superwall | A/Bテストやペイウォールビルダーが主役。収益最適化フェーズに刺さる |
| 価格・差別化系 | Qonversion, Apphud | 無料枠が大きい、リアルタイム分析、ウィンバック自動化など独自軸で勝負 |
加えて、参考までに撤退組として Glassfy(2025年3月に事業清算)^3 がある。完全無料・MTR上限なしという破格のプランで攻めていたが、収益化に難があって清算に至ったとされている。SaaS選定の際は「無料が永遠に続くわけではない」という教訓として頭の片隅に置いておきたい。
ここからは、5社それぞれを順番に見ていく。
料金と無料枠を横並びで眺める
まず一番気になる料金から並べる。サブスク管理SaaSの料率は基本的に「MTR(Monthly Tracked Revenue)= 月間追跡収益」に対する%課金が主流で、Superwallだけは「MAR(Monthly Attributed Revenue)= ペイウォール経由で発生した収益」だけを対象にする、という違いがある。
| サービス | 無料枠 | 有料プラン | 課金ベース |
|---|---|---|---|
| RevenueCat | $2,500 MTR/月 | 超過分の 1% | MTR(グロス収益) |
| Adapty | $5,000 MTR/月 | 超過分の 1% | MTR(グロス収益) |
| Qonversion | $10,000 MTR/月 | 0.6%〜0.8% | MTR |
| Apphud | $10,000 MTR/月(Free) | $49〜59/月+超過分 | MTR + 月額固定 |
| Superwall | $10,000 MAR/月 | MARの1%+月額 | MAR(帰属収益のみ) |
| — | 事業清算済 |
※料金は2026年5月時点。各社は予告なく改定する可能性があるので、契約前に必ず公式ページを確認すること^4 ^5 ^6 ^7 ^8。
数字だけ見ると、無料枠の大きさは Qonversion > Apphud ≧ Superwall > Adapty > RevenueCat の順で、RevenueCatが最も狭い。「個人開発で月2,500(日本円で約40万円)を超える個人アプリは普通に成功している部類なので、その規模に達してから1%の手数料を支払えばいいだけだ、と思い直した。
Superwallの MAR は他社の MTR と計算基準が違う点に注意がいる。MARは「Superwallのペイウォール経由で発生した売上のみ」をカウントするので、アプリ全体の売上が大きくてもSuperwall経由の購入が少なければ手数料は小さくなる。料率1%という見かけの数字だけで他社と並べると判断を間違えるので、ここは強調しておきたい。
SDK対応プラットフォームを横並びで眺める
次にSDK対応。クロスプラットフォーム展開を視野に入れるなら、ここが選定の分かれ目になる。
| サービス | iOS | Android | Flutter | React Native | Unity | Web | KMP |
|---|---|---|---|---|---|---|---|
| RevenueCat | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Adapty | ✅ | ✅ | ✅ | ✅ | ✅ | — | — |
| Qonversion | ✅ | ✅ | ✅ | ✅ | ✅ | — | — |
| Apphud | ✅ | ✅ | ✅ | ✅ | — | — | — |
| Superwall | ✅ | ✅ | — | — | — | — | — |
RevenueCatが唯一、Web SDKとKotlin Multiplatform(KMP)SDKまで揃えている^9。これは個人開発の文脈ではかなり効いてくる。最初はiOS単発で出して、後からAndroid、さらにWebに横展開……というルートを取りたい場合、追加のサブスク管理SaaSを足したり、ユーザー情報を別管理にしたりせずに済む。
Superwallはペイウォール特化のためiOS/Androidだけだが、これは設計思想の差だ。「Superwallはペイウォール、サブスク管理は別のSaaSと組み合わせる」という使い方が想定されていて、実際に多くの事例で Superwall + RevenueCat の組み合わせが使われている。
機能比較で見える各社の色
ここまで料金とSDKを並べたが、機能面で各社の「色」がはっきり見えてくる部分も整理しておく。
| 機能 | RevenueCat | Adapty | Qonversion | Apphud | Superwall |
|---|---|---|---|---|---|
| レシート検証 | ✅ | ✅ | ✅ | ✅ | ✅ |
| エンタイトルメント管理 | ✅ | ✅ | ✅ | ✅ | ✅ |
| Webhook | ✅ | ✅ | Starter〜 | Expert〜 | ✅ |
| ペイウォールビルダー | ✅ | ✅ | ✅ | — | ✅(主力) |
| A/Bテスト | 2バリアント | 無制限 | 2〜10 | ✅ | ✅ |
| リアルタイムデータ | 24h遅延あり | ✅ | ✅ | ✅ | ✅ |
| AI予測分析 | — | ✅ | — | ✅(LTV) | — |
| ウィンバック自動化 | — | — | — | ✅(Rules) | — |
| Geo-pricing最適化 | — | ✅ | — | — | — |
| Web Billing | ✅(Stripe/Paddle) | — | ✅(Stripe) | ✅(Paddle) | — |
| 返金管理 | ✅ | add-on | ✅ | ✅ | Scale〜 |
各機能の意味は次のとおり。
- レシート検証 — Apple/Googleから受け取った購入レシートをサーバサイドで真正性検証する機能。改ざん・偽造を排除する
- エンタイトルメント管理 — 「このユーザーはどのプレミアム機能にアクセスできるか」を判定する仕組み。製品IDの違いを抽象化し、アクセス権というレイヤで扱える
- Webhook — 購入・更新・キャンセル・返金などのライフサイクルイベントを自前サーバへ通知する仕組み。自前DBのサブスク状態をリアルタイムに同期できる
- ペイウォールビルダー — 課金画面のUIをコードを書かずにダッシュボードで構築・更新できる機能。アプリ再リリースなしにリモートで差し替え可能
- A/Bテスト — ペイウォールデザインや価格を複数バリアントに分配して、どれが最もコンバージョンするか実験する機能。バリアント数と分配比率の自由度が各社の差
- リアルタイムデータ — 売上やイベントが即時にダッシュボードへ反映される機能。RevenueCatは集計に最大24時間の遅延があるとされる
- AI予測分析 — LTV(顧客生涯価値)予測やチャーン予兆検知をAIモデルで自動算出する機能
- ウィンバック自動化 — 解約済み・解約予兆ユーザーへの自動オファー(割引クーポン送信など)でリテンションを引き上げる機能
- Geo-pricing最適化 — 国・地域ごとに最適な価格を自動算出して適用する機能。新興国向けの価格弾力性対応に効く
- Web Billing — モバイルIAPだけでなく、Webブラウザ経由の決済(Stripe / Paddle)もカバーする機能。Web併売アプリで効く
- 返金管理 — Apple/Googleからの返金リクエストの自動処理、返金後のエンタイトルメント自動取り消しなどを担う機能
そのうえで、それぞれの色を一言でまとめるとこうなる。
- RevenueCat — 「全部そこそこ揃っている」安定型。突出した強みがない代わりに弱点もない
- Adapty — ペイウォールABテストの自由度(無制限バリアント・カスタムトラフィック分配・既存ユーザへの実験実行)が頭ひとつ抜けている^10
- Qonversion — リアルタイムデータと安い料率(0.6%〜)。RevenueCatの24時間遅延が許せない人に刺さる
- Apphud — Rules機能によるウィンバック自動化とLTV予測。チャーン低減を自動化したい段階で本領発揮
- Superwall — ペイウォール特化。MARベース課金で「実際に貢献した分だけ手数料を払う」設計
逆に言えば、個人開発の最初期はこのうちのどれを選んでも基本機能で困ることはない。差別化機能が効いてくるのは収益が出始めて最適化フェーズに入ってからだ。
個人開発フェーズで RevenueCat に倒した理由
ここまで横並びで眺めたうえで、自分が個人開発フェーズの選択として RevenueCat を第一候補にした理由は、ざっくり4つある。
1. ドキュメント・SDK・コミュニティが圧倒的に厚い
RevenueCatは2017年設立で、現時点でこのカテゴリの業界デファクトスタンダードとして扱われている^11。公式ドキュメントの整備、SDKの安定性、コミュニティの厚さ、サードパーティのチュートリアル量、いずれも他社を引き離している。詰まったときの情報量という意味で「個人開発の最初の1本」に向く。
2. クロスプラットフォーム網羅性
前述のとおりWebとKMPまで対応しているのはRevenueCatだけだ。最初はiOSだけで始めても、後からAndroid・Web・Flutter…と展開していくときに追加のSaaSを買い足したり乗り換えたりしなくていい。個人開発は「あとから展開先が増える」ことが普通にあるので、最初から網羅されている安心感は地味に大きい。
3. 無料枠は狭いが、収益が出てからの1%は許容範囲
無料枠2,500を個人アプリで安定して超えた段階なら、月10K相当まで広げているQonversion/Apphudの料金体系が将来どこまで維持されるかのほうが個人的には気になる。Glassfyの事業清算は無料モデルの持続性に対する警告として読める。
4. オブザーバモードがあるので逃げ道がある
RevenueCatには、既存の課金実装はそのまま残し、購入だけRevenueCatにリッスンさせる オブザーバモード がある^12。これがあるおかげで、後から別のSaaSに乗り換えたいとなったときの経路依存度が低い。SaaS選定で「あとから乗り換えやすいか」は地味に効くので、ここは安心材料になった。
それでも他社が刺さるケース
公平のために、RevenueCat以外を選んだほうがいいケースも整理しておく。
- ペイウォールABテストを高速で回したい → Adapty または Superwall。RevenueCatのABテストは2バリアント・50/50分配のシンプルな仕様で、本格的なペイウォール最適化を始めるとすぐ物足りなくなる^13
- コストを徹底的に抑えたい → Qonversion。無料枠$10K、有料0.6%〜という料率はRevenueCatの半分以下だ
- チャーン対策を自動化したい段階に入った → Apphud。Rulesによるウィンバック自動化は他社にない強み
- ペイウォールUIだけ外部化したい → Superwall + RevenueCat の併用。Superwallがペイウォール、RevenueCatがバックエンド、という分業
- アプリの売上規模が大きく、1%の手数料が無視できない金額になった → どのサービスもEnterprise契約でボリュームディスカウントが効くので、$100K+ MTRを超えたあたりで再交渉する
特にペイウォール最適化フェーズは、収益の伸びに直結するのでSaaS変更コストを払う価値が出てくる。最初RevenueCat、収益が出てきたらAdapty / Superwallを併用または移行、というのが現実的な進化パスだと思う。
おまけ: 2026年のハイブリッドモデル
調べていて面白かったのが、2026年のサブスクモデルは「単一SaaSで全部やる」から「組み合わせる」設計に移っているという話だ^13。
具体的には、
- モバイル側: RevenueCat / Adaptyなどのモバイル特化SaaS(StoreKit / Play Billingを叩く)
- Web側: Stripe / Chargebee / Paddleなど(DMA対応の外部決済やB2Bシート販売)
- 統一されたユーザーID: 両者を同一ユーザーとして紐付けて顧客管理する
という構成だ。EUのDMA(Digital Markets Act)対応でiOSにも外部決済リンクが許可される流れがあり、Apple/Google経由のIAPと、Web経由のStripe決済が混在するアプリが増えている。
「どの1つのSaaSが勝つか」ではなく「モバイル側のSaaS + Web側のSaaSをどう統合するか」が2026年の主要な設計課題、というのは個人開発者にとっても示唆的だった。最初からモバイル単独で完結する想定じゃなくて、Webへの展開も視野に入れた選定をしておくと、後で困らない。これも RevenueCat(Web Billing 対応)を選んだ理由の一つになっている。
まとめ
- モバイルアプリにサブスクを入れるなら、StoreKit / Play Billingの自前運用は現実的じゃない。サブスク管理SaaSを使うべき
- 主要5社は「業界デファクト系(RevenueCat)」「ペイウォール最適化系(Adapty / Superwall)」「価格・差別化系(Qonversion / Apphud)」の3系統に分かれる
- 無料枠は Qonversion / Apphud / Superwall が広く、RevenueCatは狭め。ただし個人開発レベルではどれも当面ゼロ円で動く
- 個人開発フェーズの最初の1本は RevenueCat が無難。ドキュメント・SDK網羅性・エコシステムの厚みで困ることがない
- 収益最適化フェーズに入ったら Adapty / Superwall をペイウォール側で併用、Apphud をチャーン対策に追加、という進化パスが現実的
- 2026年のサブスクは「単一SaaSで全部やる」から「モバイルSaaS + Web決済の組み合わせ」へ。最初からWeb展開を視野に入れた選定をしておきたい
個人開発で課金まわりに時間を溶かすのは本当に得策じゃないので、迷ったらRevenueCatに乗せて先に進めるのが、いまの自分の結論だ。
参考文献
- RevenueCat Webhooks Guide https://www.revenuecat.com/guides/revenuecat-android-sdk/webhooks
- RevenueCat公式サイト https://www.revenuecat.com/
- Glassfy 2026 Company Profile (PitchBook) https://pitchbook.com/profiles/company/519795-82
- RevenueCat Pricing FAQs https://community.revenuecat.com/general-questions-7/pricing-faqs-112
- Adapty New Pricing 2026 https://adapty.io/blog/adapty-new-pricing-2026/
- Qonversion Pricing https://qonversion.io/pricing
- Apphud公式 https://apphud.com/
- Superwall Pricing https://superwall.com/pricing
- Hybrid SDK Architecture at RevenueCat https://www.revenuecat.com/blog/engineering/how-our-hybrids-work/
- Adapty SDK https://adapty.io/sdk/
- Stripe Billing vs RevenueCat: picking the right billing layer https://adamarant.com/en/blog/stripe-billing-vs-revenuecat-picking-the-right-billing-layer
- Where Does RevenueCat Fit In Your App? https://www.revenuecat.com/blog/growth/where-does-revenuecat-fit-in-your-app/
- RevenueCat Alternatives Comparison 2026 https://sph.sh/en/posts/revenuecat-alternatives-comparison-2026/