RevenueCatとは？アプリ内課金・サブスク実装を1SDKで担う仕組みと導入判断【実装者向け】

RevenueCatは、App StoreとGoogle Play、そしてWebの課金処理を1つのSDKに集約し、サブスクリプションやアプリ内課金（IAP）の実装と収益管理をまとめて引き受けるバックエンド基盤です。StoreKitやGoogle Play Billingを直接叩く代わりに、レシート検証・購入状態の同期・解約や返金の追跡をRevenueCat側へ委ねられる点が特徴です。この記事では、RevenueCatが担う役割と3つの中核概念、Paywalls・Charts・Web Billingといった主要機能、MTR2,500ドルまで無料で超過分は1%という料金体系、そして自前実装との損益分岐までを実装者の視点で整理します。Flutterやreact nativeでの位置づけ、StripeによるWeb課金、MCPサーバーやWebhookの連携先も扱います。

まとめ：RevenueCatはストア課金の実装と収益管理を1SDKに集約する基盤

RevenueCatの本質は、Apple・Google・Web（Stripe）で異なる課金APIを1つのSDKの裏に隠し、購入状態を「エンタイトルメント」という単一の判定に正規化する点にあります。開発者はレシート検証サーバーやサーバー間通知の受信基盤を自前で維持せずに、機能のロック解除だけをコードで判定できます。

料金はProプランで月間トラッキング収益（MTR）2,500ドルまで無料、超過分は追跡収益の1%です（2026年7月時点の公開料金）。判断の軸は単純で、レシート検証やサーバー通知の保守にかかる自社工数が、この1%を上回るならRevenueCatが有利になります。逆に単発課金しか扱わない、あるいは収益規模が大きく1%が重くなる場合は自前実装が選択肢に残ります。実装や課金基盤の設計から相談したい場合は、アプリ内課金やサブスク基盤の受託開発として一創にご相談ください。

RevenueCatがアプリ内課金とサブスク実装で担う役割と立ち位置

まず押さえるべきは、RevenueCatが「決済代行」ではないことです。実際にお金を処理するのはApp StoreとGoogle Play、そしてWeb課金ではStripeであり、RevenueCatはその上に載る管理レイヤーです。課金の入口ではなく、購入後の状態管理を一手に引き受ける立ち位置になります。

レシート検証とストア課金APIの抽象化を引き受ける中核の役割

iOSのStoreKitとAndroidのGoogle Play Billingは、レシート（購入トークン）の検証方式もサーバー通知の形式も別物です。自前で実装すると、Appleのapp-store-server-notifications V2とGoogleのReal-time Developer Notificationsを個別に受信し、失効・返金・猶予期間の状態遷移を両方で維持する必要があります。RevenueCatはこの検証と状態管理を肩代わりし、開発者には正規化済みの購入情報だけを返します。手元のコードに残るのは「この機能を使わせてよいか」の判定だけです。

エンタイトルメント・オファリング・プロダクトという3つの中核概念

RevenueCatを理解する鍵は、ストア商品を直接扱わずに3層で抽象化することです。実装ではこの3語がそのままAPIに現れます。

年額と月額など複数のProductを1つのOfferingにまとめ、それらがひも付くEntitlement（例：「プレミアム機能」）を1つ持たせます。コードでは「premiumのEntitlementがactiveか」だけを見ればよく、価格改定や新プラン追加でアプリ側の判定ロジックを書き換えずに済みます。この設計がリモートでのプラン変更を可能にする土台です。

対応SDKとFlutter・react nativeなどマルチプラットフォーム状況

RevenueCatのSDK（Purchases SDK）は、Swift（iOS）、Kotlin（Android）、Flutter、React Native、Kotlin Multiplatform、Web（JavaScript）などをカバーします。FlutterやReact Nativeのクロスプラットフォーム開発では、ネイティブの課金APIをプラグイン越しに叩く煩雑さを避けられる点が採用理由になりやすいところです。Purchases.configureでAPIキーを渡して初期化し、getOfferingsで商品を取得、購入後はCustomerInfoのEntitlementを見る、という流れはどのプラットフォームでもほぼ共通です。1つのメンタルモデルで複数OSを扱えるのが実装上の利点になります。

RevenueCatの主要機能とアプリ収益基盤としての構成要素

RevenueCatはSDKによる課金抽象化を土台に、収益を伸ばすための周辺機能を重ねています。実装者が押さえておきたいのは、コードを書かずに運用側で回せる領域が広いことです。

Paywallsによるアプリ審査を挟まない課金画面のリモート更新

Paywalls機能は、課金画面（ペイウォール）のレイアウトやコピー、価格表示をRevenueCatのダッシュボード側で構成し、アプリに配信します。描画はiOSのSwiftUI、AndroidのJetpack Composeでネイティブに行われるため、WebViewの見た目にならずに済みます。要点は、価格やデザインの変更にアプリのアップデート審査を挟まないことです。訴求文言を差し替えたいとき、ストア審査の数日を待たずに反映できます。

ChartsとExperimentsによる収益分析とA/Bテストの実行

Charts機能はサブスク収益・解約率・課金継続のコホートをダッシュボードで可視化し、公式説明では1時間未満のデータ遅延で反映されます。LTV（顧客生涯価値）の予測は機械学習によるものです。Experiments機能では価格やレイアウト、コピーを最大4パターン同時にA/Bテストでき、どのOfferingが継続に効くかを実データで比較できます。分析基盤やBIツールを別途構築せずに、課金の意思決定に必要な数字が最初からそろう構成です。

Webhook・REST API・MCPサーバーによる外部システム連携

サーバー側の連携手段も豊富です。Webhook（サーバー通知）は購入・更新・解約などのイベントを自社サーバーへ即時に送り、CRMや会員DBへの反映に使えます。購読状態の照会や付与にはREST API（v1およびv2）を利用できます。RevenueCatはMCPサーバーも提供しており、AIエージェントからRevenueCatのデータへ問い合わせる連携も可能です。Webhookで受けたイベントを起点に、社内の業務システムやメール配信を自動化する構成が現実的な使い方になります。

Web BillingとStripe連携によるストア手数料の圧縮

Web Billingは、アプリ内ではなくWebブラウザ上でサブスクを販売する仕組みです。決済を担うのはStripeです。App StoreとGoogle Playの手数料は標準で15〜30%ですが、Web経由の課金ならこの枠の外になります。RevenueCatの公式ケースでは約27%のコスト削減が言及されています。ストア課金とWeb課金のEntitlementをRevenueCat側で統合できるため、どの経路で買ったユーザーも同じ機能判定で扱える点が強みです。Stripe単体でできることはStripeが提供する主なサービスと機能に整理しており、決済基盤とサブスク管理層の役割分担を確認できます。

RevenueCatの料金体系とトラッキング収益に応じた費用構造

RevenueCatの料金は、扱う金額に連動する従量制です。固定の月額サブスクではなく、追跡した収益に対する割合で決まります。

MTR2,500ドル無料枠と1%課金という費用構造の実コスト

Proプランは月間トラッキング収益（MTR＝プラットフォーム手数料を引く前の売上）が2,500ドルまで無料で、超過分に追跡収益の1%がかかります（2026年7月時点）。Enterpriseプランは大規模向けのカスタム料金です。自前インフラを持つ場合はGrowth Toolsとして、PaywallsやWebファネル経由の売上に対してのみ1%を払う選び方もできます。実額の感覚をつかむために、MTR別の概算を示します。

ここで見るべきは、料金が売上に比例して増える点です。収益が小さいうちは無料枠に収まり、伸びるほど支払いも増えます。だからこそ、次章の「自前実装との損益分岐」を収益規模ごとに判断する必要があります。

RevenueCatを採用すべき条件と自前実装で足りる場面の判断

ここは競合の実装記事があまり踏み込まない領域です。結論から言えば、RevenueCatは「サブスクを複数OSで運用し、課金保守の工数を買いたいチーム」に向き、「単発課金だけ」「収益が大きく1%が重い」「データを自社管理必須」の3条件のいずれかに当たるなら自前実装が残ります。玉虫色にせず、条件で切り分けます。

RevenueCatを採用すべきプロジェクトの具体的な条件と適性

採用が合理的なのは次のような場合です。第一に、iOSとAndroidの両方でサブスクを提供し、レシート検証とサーバー通知を二重に保守したくないチーム。第二に、FlutterやReact Nativeで開発し、ネイティブ課金APIの差異を吸収したい場合。第三に、価格やペイウォールをアプリ審査なしで頻繁に変えたいプロダクトです。これらでは、月あたりの課金保守工数（検証サーバーの運用・OSアップデート追従・返金/猶予期間の状態管理）が、MTR1%を容易に上回ります。少人数チームほど、この工数の削減効果が大きく出ます。

自前実装で足りる場面とRevenueCatの採用を見送るべきケース

見送りを勧めるのは3つの場面です。単発の買い切り課金しかなく、サブスクの状態管理が不要なアプリでは、RevenueCatの強みが活きません。StoreKit2の購入検証だけで完結します。次に、月間収益が数十万ドル規模まで育ち、1%が年間で数百万円に達する段階では、専任エンジニアを置いて自前基盤に移す方が安くなる分岐点が来ます。最後に、金融や医療など課金・購買データを外部SaaSに預けられない規制要件がある場合は、そもそも選択肢に入りません。これらに1つでも当たるなら、無理に導入しないほうが合理的です。

自前実装の保守工数とRevenueCat1%の損益分岐の考え方

判断を数字に落とすと分かりやすくなります。仮にMTRが1万ドル/月なら、RevenueCatの支払いは概算75ドル前後です。一方で自前実装では、App Store Server NotificationsとGoogle RTDNの受信・冪等処理、失効や返金の状態遷移、OS側の課金仕様変更への追従を維持し続けます。この保守にエンジニアが月に数時間でも取られるなら、人件費換算で75ドルを超えることは珍しくありません。収益が小さい初期はRevenueCatが割安、収益が大きく育つと1%の絶対額が効いてくる、という交差点で乗り換えを検討するのが実務的な線引きです。設計段階からこの分岐を織り込みたい場合は、アプリ内課金・サブスク基盤の実装と受託開発で要件に合わせた構成を相談できます。

よくある質問

RevenueCatの導入検討でよく挙がる質問に、実装者の視点で簡潔に答えます。

RevenueCatは無料で使えますか？

Proプランは月間トラッキング収益（MTR）が2,500ドルまで無料で使えます（2026年7月時点の公開料金）。超過分に追跡収益の1%がかかる従量制で、クレジットカードの登録なしで開始できます。個人開発や検証段階では無料枠に収まるケースが多く、収益が立ってから支払いが発生する構造です。

RevenueCatはFlutterやReact Nativeでも使えますか？

使えます。Purchases SDKはSwift（iOS）、Kotlin（Android）に加え、Flutter、React Native、Kotlin Multiplatform、Web（JavaScript）向けを提供しています。クロスプラットフォーム開発では、iOSとAndroidで異なる課金APIをプラグイン越しに個別実装する手間を減らせる点が採用の決め手です。

RevenueCatとStripeは何が違いますか？

役割が異なります。Stripeはクレジットカードなどを実際に処理する決済プロバイダーで、RevenueCatはその上でサブスクの状態を管理する層です。アプリ内課金ではApp StoreとGoogle Playが決済を担い、Web課金ではRevenueCatのWeb Billingが裏でStripeを使います。両者は競合ではなく、組み合わせて使う関係にあります。

RevenueCatにWebhookやAPIはありますか？

あります。Webhook（サーバー通知）で購入・更新・解約などのイベントを自社サーバーへ送れるほか、REST API（v1・v2）で購読状態の照会や付与ができます。加えてMCPサーバーも提供され、AIエージェントからRevenueCatのデータを参照する連携も可能です。会員DBやCRMへの反映は、このWebhookを起点に組むのが一般的です。

アプリのアップデートなしで課金画面を変更できますか？

できます。Paywalls機能では、課金画面のレイアウト・コピー・価格表示をダッシュボード側で構成し、アプリに配信します。描画はSwiftUIとJetpack Composeでネイティブに行われ、変更にストア審査を挟みません。訴求の文言や価格の見せ方を、審査待ちなしで差し替えられます。

関連記事

• Stripeが提供する主なサービスと注目すべき機能一覧：RevenueCatのWeb Billingが裏で使う決済基盤Stripeの機能を整理しています。
• Webシステム開発（受託開発）：アプリ内課金・サブスク基盤の実装や設計から相談したい場合の窓口です。