Rork で作るモバイルアプリの収益化入門 — 広告・課金・サブスクの選び方を実例で整理する

広告モデルの実装ポイント

Rork で広告を組み込む場合、AdMob が最も導入しやすく、レポートも詳細です。実装の際に押さえておきたいポイントを共有します。

// React Native + Rork での AdMob 実装例
import { BannerAd, BannerAdSize, TestIds } from "react-native-google-mobile-ads";
 
function AppScreen() {
  const adUnitId = __DEV__
    ? TestIds.BANNER
    : "ca-app-pub-XXXXXXXXXXXXXXXX/YYYYYYYYYY";
 
  return (
    <View style={{ flex: 1 }}>
      <YourMainContent />
      <BannerAd
        unitId={adUnitId}
        size={BannerAdSize.ANCHORED_ADAPTIVE_BANNER}
        requestOptions={{
          requestNonPersonalizedAdsOnly: false,
        }}
      />
    </View>
  );
}

実装上のコツは 3 つあります。

ひとつめは「広告フォーマットの使い分け」。バナー広告（画面下部に常時表示・収益小）、インタースティシャル広告（画面切り替え時に全面表示・収益中）、リワード広告（ユーザーが見ると報酬を得られる・収益最大）の 3 種類を、アプリの性質に合わせて使い分けます。私のアプリでは「リワード広告で機能解放」というパターンが最も収益と UX のバランスが良いと感じています。

ふたつめは「初回起動から数秒は広告を出さない」こと。アプリ起動直後に広告を出すと UX が大きく損なわれ、レビュー評価が下がります。最低 30 秒〜1 分のグレースピリオドを設けるのが鉄則です。

みっつめは「インタースティシャル広告の表示頻度を制御する」こと。画面遷移のたびに毎回出すとユーザーが激怒します。「3 回に 1 回」「最後の表示から 5 分以上経過していたら」のような制御ロジックを入れます。

AdMob メディエーションで eCPM を底上げする実務

広告モデルを選んだあと、収益を左右するのは「どのネットワークから広告を取るか」です。AdMob 単独でも動きますが、複数の広告ネットワークを束ねるメディエーションを組むと、同じ表示回数でも eCPM（1,000 表示あたり収益）が変わってきます。

私は長らく AdMob をメディエーションのハブに据え、Meta Audience Network・Unity Ads・AppLovin・Pangle を束ねる構成で運用してきました。単独運用からメディエーションへ切り替えた壁紙アプリでは、リワード面の eCPM が概ね 1.4 倍に上がりました。理由は単純で、同じ 1 インプレッションを複数ネットワークに競わせると、より高い単価を出したネットワークが落札するからです。

ここで判断が要るのが「ウォーターフォール」と「ビディング（入札）」の使い分けです。ウォーターフォールは各ネットワークに固定の優先順位と単価フロアを設定し、上から順に在庫を問い合わせる方式。ビディングは全ネットワークに同時入札させ最高値を採る方式です。私の実感では、主要面はビディングに寄せて取りこぼしを減らし、単価の読める補助ネットワークだけウォーターフォールに残す折衷が扱いやすいです。全面ウォーターフォールは設定こそ楽ですが、問い合わせのレイテンシが積み上がり、広告が出るまでの待ち時間が伸びていきます。

もうひとつ、収益の解像度を上げてくれるのが eCPM の「揺れ」を知ることです。私が観測してきた範囲では、日本の眠る深夜帯より、北米が動いている時間帯のほうがリワード eCPM が高く出やすく、同じアプリでも配信国の構成で月次収益が二割ほど動きます。だからこそ、収益レポートは合計値だけでなく「国別 × フォーマット別 × 時間帯別」で見る癖をつけると、どの面を厚くすべきかが見えてきます。

数値はアプリのジャンルや時期で動きますので、絶対値より「フォーマット間の序列」を掴む材料として捉えていただければ幸いです。私自身、最初は eCPM の高いリワードばかり増やそうとして UX を崩しかけ、あとから「任意視聴だから増やしても嫌われにくい面」に絞り直した経緯があります。数字は増やす方向だけでなく、どこで止めるかを教えてくれるものでもありました。

アプリ内課金（IAP）モデルの実装ポイント

IAP は React Native では react-native-iap ライブラリ、Apple/Google ストアでの商品設定、そしてサーバー側の検証が必要になります。Rork の場合、テンプレート的な実装はかなり楽ですが、必ず押さえてほしいポイントは以下です。

import { initConnection, getProducts, requestPurchase, finishTransaction, useIAP } from "react-native-iap";
 
const productIds = ["pro_unlock", "premium_pack", "feature_x"];
 
function PurchaseScreen() {
  const { connected, products, getProducts: fetchProducts, requestPurchase: doPurchase } = useIAP();
 
  useEffect(() => {
    if (connected) {
      fetchProducts({ skus: productIds });
    }
  }, [connected]);
 
  const handlePurchase = async (sku: string) => {
    try {
      await doPurchase({ sku });
      // 購入完了処理（重要: サーバー側検証へ送る）
    } catch (err) {
      console.error("Purchase failed", err);
    }
  };
 
  return (
    <View>
      {products.map((p) => (
        <TouchableOpacity key={p.productId} onPress={() => handlePurchase(p.productId)}>
          <Text>{p.title} - {p.localizedPrice}</Text>
        </TouchableOpacity>
      ))}
    </View>
  );
}

実装上のコツは 3 つあります。

ひとつめは「サーバー側でレシート検証を必ず行う」こと。クライアント側だけで購入完了を信じると、改ざんされたレシートを受け入れて不正に機能解放してしまいます。Apple は verifyReceipt API、Google は inAppPurchases.subscriptions.get API でサーバー側検証ができます。

ふたつめは「Restore Purchase（購入の復元）機能を必ず提供する」こと。これがないと、ユーザーが機種変更したときに「お金払ったのに使えない」という最悪のクレームが来ます。Apple のレビューでもリジェクトされる頻出項目です。

みっつめは「価格を国別に最適化する」こと。日本の 480 円が米国の 4.99 ドルとは限りません。Apple/Google ストアの「価格マトリックス」を理解し、各国の購買力に合わせた価格設定をすることで全体収益が 1.3〜1.5 倍になります。

サブスクリプションモデルの実装ポイント

サブスクは IAP の特殊形ですが、運用が複雑になります。私が運用しているサブスクアプリで重要だと感じているポイントを 3 つに絞って共有します。

ひとつめは「無料トライアル期間の設計」。3 日・7 日・14 日のどれにするかで継続率が大きく変わります。私の経験上、「使い込みが必要なツール系」は 14 日、「コンテンツ系」は 7 日が最適でした。3 日は短すぎて継続せずに解約されることが多いです。

const subscriptionId = "monthly_pro";
 
const handleSubscribe = async () => {
  try {
    await requestSubscription({
      sku: subscriptionId,
      // 7 日間の無料トライアルを設定（ストア側で事前設定が必要）
      andDangerouslyFinishTransactionAutomaticallyIOS: false,
    });
  } catch (err) {
    console.error("Subscription failed", err);
  }
};

ふたつめは「サブスク状態の管理」。ユーザーが解約しても、現在の課金期間が終わるまでは Pro 機能が使える状態を維持する必要があります。サーバー側で expiresAt を必ず記録し、expiresAt > now の判定で機能解放を制御します。

みっつめは「キャンセル前の引き止め UI（解約抑止）の設計」。「今キャンセルすると以下の機能が使えなくなります」「期間中はこの機能が継続して使えます」のような情報を解約ボタン直前に出すだけで、解約率が 10〜20% 下がります。これは小さな実装で大きな効果が出る部分です。

サブスク解約を「数字」で管理する — コホートで見る継続率

サブスクは入り口の獲得より、出口の解約をどう抑えるかが収益を決めます。ここで役立つのが、登録した月ごとに束ねてその後の継続率を追う「コホート」の見方です。

私が運用する業務効率化アプリでは、トライアル開始から本課金への転換がおよそ三割、初月を越えたユーザーの翌月継続がおよそ九割弱、という水準で推移しています。ここで大事なのは、この二つの数字を分けて見ることです。転換率が低いならトライアル体験や価格に問題があり、初月後の継続が低いなら価値提供そのものに穴がある。混ぜて「解約率が高い」と嘆いても、打ち手が定まりません。

// 登録月ごとのコホートで N か月後の継続率を出す最小例
type Sub = { userId: string; startedAt: Date; canceledAt: Date | null };
 
function retentionByCohort(subs: Sub[], monthsOut: number) {
  const cohorts: Record<string, { total: number; retained: number }> = {};
  for (const s of subs) {
    const key = `${s.startedAt.getFullYear()}-${s.startedAt.getMonth() + 1}`;
    cohorts[key] ??= { total: 0, retained: 0 };
    cohorts[key].total++;
    const boundary = new Date(s.startedAt);
    boundary.setMonth(boundary.getMonth() + monthsOut);
    // monthsOut か月後もまだ解約していなければ継続とみなす
    if (!s.canceledAt || s.canceledAt > boundary) cohorts[key].retained++;
  }
  return Object.entries(cohorts).map(([month, c]) => ({
    month,
    retention: c.total ? Math.round((c.retained / c.total) * 100) : 0,
  }));
}

このコホート表を毎月眺めていると、価格改定や機能追加が「どの登録月から効いたか」が線として見えてきます。私は一度、トライアルを 7 日から 14 日に延ばした月を境に転換率が数ポイント上がったことがあり、それはコホートに並べて初めて確信できました。合計値の折れ線だけを見ていたら、季節変動と区別がつかなかったはずです。

解約の抑止は UI だけの仕事ではありません。継続率の低いコホートに共通する「使われていない機能」を見つけ、そこを作り直すほうが、引き止めダイアログを一つ足すよりも効きます。数字は責めるためでなく、次にどこへ手を入れるかを教えてくれる地図として使いたいところです。

法令面で必ず押さえるべきこと

国内でサブスク・IAP を提供する場合、以下の対応が必須です。

「特定商取引法に基づく表記」を必ず設置すること。屋号・住所・連絡先・返金ポリシー等を明記したページが必須で、これがないとストア審査でリジェクトされる可能性があります。

「自動継続課金の明示」を必ず行うこと。サブスクの場合「いつ・いくら・どうやって解約するか」を購入直前に明示する必要があります。これは消費者庁の指針で、違反すると返金対応の負担が増えます。

「子供向けアプリの広告制限」に注意すること。13 歳以下を対象にしたアプリは、AdMob でも制限の厳しい広告のみ表示可能です。アプリストアの年齢区分と広告設定が一致していないと、リジェクトや収益停止のリスクがあります。

実数値: 私の収益化モデル別の実績

参考までに、私の現役アプリの収益化モデル別の月次平均収益を共有します（2026 年時点）。

広告モデル（壁紙・癒し系・10 アプリの合計）: 月収益 280,000 円 / DAU 合計 約 50,000 / 1 DAU あたり月収益 約 5.6 円

IAP モデル（写真加工アプリ 1 本）: 月収益 95,000 円 / DAU 4,200 / 課金率 2.8% / ARPPU 月 810 円

サブスクモデル（業務効率化アプリ 1 本）: 月収益 134,000 円 / 課金ユーザー 142 名 / 平均月単価 944 円

合計すると月収益 50 万円程度で、ピーク時の 150 万円からは下がりましたが、「個人開発で生計が立つ」レベルは維持しています。重要なのは、3 モデルを併用することで特定モデルの市場変動（広告単価の下落など）に強い構造になっていることです。

Rork で作ったアプリも結局はストア経由で配布するため、ASO 知識は収益化の前提として必須になります。

全体を振り返って

モバイルアプリの収益化で最も重要なのは「自分のアプリにどのモデルが合うかを最初に決める」ことです。「全部入れる」は楽そうに見えて、実は最も難しい選択肢になります。本記事の判断軸を使って、まず 1 つのモデルで成立させてから、必要に応じて他モデルを追加するのが現実的な戦略です。

今日からひとつだけ始めるとしたら、自分のアプリの DAU・継続率・差別化要素を紙に書き出して、3 大モデルのどれが最も合いそうか判定してみてください。判断が難しいなら広告モデルから始めるのがリスクが最も低い選択です。

次のステップとして、月 10 万円超の収益を目指す具体的な戦略に踏み込みたい方は、姉妹記事の 個人開発で月10万円を超えるアプリ収益化の実践戦略 で、Rork で作ったアプリで実際に試した収益チューニングの実装と運用フローを解説しています。