概要
これは Perttu Lähteenlahti による寄稿記事です。彼は RevenueCat の developer advocate で、開発者がアプリで収益を上げる手助けをすることに注力しています。モバイルアプリビジネスは、十分に語られていない形で厳しくなっています。RevenueCat の State of Subscription Apps 2026 レポート（115,000 を超えるアプリ、約 $16B の収益をカバー）によれば、上位 25% のアプリは前年同期比 80% 成長した一方で、下位 25% は 33% 縮小しました。市場は勝者と敗者に二極化していると言えます。
重要なのは、その格差は必ずしもより良いアイデアの差ではないということです。上位四分位の多くのアプリは誰も思いつかなかったことをやっているわけではありません。みんなと同じことをやっているが、より早くリリースし、より多くテストし、マネタイズを後回しにせず反復的プロセスとして扱っているのです。
この記事では、適切なスタックの選定、成功アプリからのマネタイズのコツ、そして Expo アプリが勝つために必要なことを取り上げ、収益を生むモバイルアプリの作り方を解説します。この記事は、私が来週の App.js conference で行う「AI は React Native を陳腐化させるか？」というトークの前菜でもあります。これらの見解は、その質問に答えるために行った調査と密接に関連しています。もう一つの問いは、React Native アプリでお金を稼ぐべきか、あるいは Swift や Kotlin で書かれたアプリを他のプラットフォームに移植するためにエージェントを使うべきか、という点です。
2026 年の（意見を含む）スタック
私には非常に確信を持ったスタックがあります。以下はこの記事を読み進めると納得できるはずのコア概念です:
- 早く作り、より速く届ける
- 可能な限りネイティブ OS レベルの API を活用する
- オフライン時も快適で素早く使えること
これらの概念に従い、私は古いツールをより良い DX を提供する新しいツールに置き換えてきました。現在のスタックは以下の通りです:
- Expo と EAS：ビルド、提出、アップデート。すべてはここから始まります。数年前なら bare React Native を選んでいたかもしれませんが、今は Expo なしでリリースを考えられません。
- Tanstack query：データ取得、ミューテーション、サーバー状態管理全般。これに react-native-network-info と react-native-mmkv を組み合わせ、オフライン状態をうまく扱うアプリを構築します。
- expo-apple-targets：ネイティブコードに踏み込むため。ウィジェット、App Intents、Spotlight 検索、Live activities のようなネイティブ統合は重要です。ユーザーはこれらを期待します。
- RevenueCat：サブスクリプション、ペイウォール、エンタイトルメント。私は RevenueCat に勤めているのでバイアスはありますが、1つ持ち帰ってほしい学びはこれです：サブスクリプションのインフラは自分で作るな。あなたのアプリとマネタイズはあなたのビジネスであり、決済インフラは違います。
これらの選択は時間を取り戻させます。その「取り戻した時間」が、週末で出せるものと四半期かかるものの差になります。エージェントとこのスタックを巧みに使うソロ開発者なら、実際のアプリで数日内に有料化を始められます。
なぜスタックがマネタイズに重要か
統計的に React Native アプリは収益化がうまくいく傾向があります。State of Subscription Apps レポートはフレームワーク別に収益を分解しており、React Native はネイティブや Flutter よりもほとんど全ての重要指標（インストール当たりの収益、課金ユーザーのリテンション、LTV）で上回っています。過去2年のデータも似ているので、単なる AI 駆動の開発バブルとは言えません。
私が以前書いた結論の TL;DR はこうです：React Native は最初からリリースの速度とクロスプラットフォームのリーチを最適化する開発者を引き付けます。そうした開発者はマネタイズを後回しにせずプロダクト問題として扱う傾向があり、反復がしやすいことが品質向上と良い UX を生み、結果的に収益につながります。
アプリマネタイズ チートシート
多くのマネタイズに関する助言は一般論（"product-market fit を見つけろ"）か、個別アプリの事例に基づいています。ある開発者に効く方法が別の開発者に効くとは限りません。結局のところ、ほとんど全てのプロダクト開発は実験に帰着します。
この記事では、私は330ページの State of Subscription apps レポート全体を読み、React Native 開発者にとって重要なインサイトを抽出し、それを基に戦略セットにまとめました。以下がその主要ポイントです。
1. Day 0（インストール当日）で勝つか負けるかが決まる
- 全ての 3 日間トライアルの取消しのうち 55% が Day 0 に発生します。直感的に考えるとトライアル終了直前（Day 3）にキャンセルが多いと思いがちですが、実際はインストール当日に、ダウンロード後数分でトライアルをキャンセルしてしまうケースが多いのです。
- つまり、サブスクライバーを獲得する戦いは最初のセッションでほぼ決まります。一度失うと取り戻せないことが多い。
- 実務では "aha" モーメントを一撃で届けるつもりで設計してください。ユーザーに長時間待たせたり、登録や複数フィールドの入力を強いたりしてはいけません。注意持続時間は短く、面倒な UI への許容はさらに低いです。
- 私自身や助言する際は、初回開封から 30 秒以内にユーザーのデータを見せられるフローを作ることを重視しています。例：自分のアプリ Netli.fyi ではオンボーディングは 3 つの箇条書きと認証のフローだけで、その後すぐにプロジェクトとデプロイが表示されます。通知などユーザーが好む他の機能は後で導入します。権限要求がフローの摩擦になるからです。
- この "自分のものを見せる" アプローチはユーティリティ系（例：開発者ツール）に有効ですが、ヘルス系のように長期目標設定が鍵となるアプリでは別の戦略が必要です。
- ここで OTA（over-the-air）アップデートが効いてきます。Expo の OTA Updates のような仕組みを使えば、月曜日に新しいオンボーディングを出し、数日後に数値を確認して、週内に摩擦を減らしたフローをデプロイできます。App Store / Google Play の審査を待つ必要がありません。特に両ストアの審査時間が数時間から数日に延びている今では有効です。
- 新規ユーザー向けのオンボーディング画面は最重要画面です。ランディングページと同じように繰り返し改善できるべきで、離脱解析や A/B テストを行い、どこでユーザーが離脱しているかを理解してください。オンボーディングを最適化すれば、ダウンロードから有料化への最初の指標を改善できます。
2. ペイウォールは単なる画面ではなくプロダクトである
- よく見る失敗例は、アプリ本体を何週間も磨いてから、最もぞんざいに設計されたペイウォールでリリースしてしまうことです。無頓着なペイウォールなら、当然ダウンロードがサブスクリプションに変換されないのは不思議ではありません。
- ペイウォールはお金が動く画面です。機能と同じくらいの注意を払うべきです。
- データは少し直感に反します。ハードペイウォール（何も解除せずサブスクを強制する）は、インストール時点のコンバージョンで freemium より約 5 倍良い（10.7% 対 2.1%）です。これは変換が主目標ならハードペイウォールを選ぶ価値がある差です。
- しかし、1 年後のリテンションはハードペイウォールと freemium でほぼ同じです。ハードは初動でより多くの有料ユーザーを引き込み、freemium はゆっくりと変換していきますが、最終的に同じ地点に落ち着きます。
- 重要なのは "どちらが優れているか" ではなく "自分のアプリにどちらが合うか" です。類似アプリとベンチマークして決めるのが良いでしょう。例えば、瞑想やワークアウトアプリのように価値を数週間かけて感じてもらうタイプは freemium が有利なことが多い一方、写真編集のように最初の1分で価値が明らかになるアプリではハードペイウォールを試さないと機会損失になるかもしれません。
- ソフトペイウォール（フリーミアム寄り）に惹かれるのはユーザー数を最大化できるからですが、無料ユーザーの目標は有料ユーザーのそれとは本質的に異なることが多い点に注意してください。レストランに例えるなら、あなたのコアビジネスが五皿のフルコースだとして、パンと水だけの無料レベルを導入して満席にしてもコアビジネスはそんなに改善されないかもしれません。
- このセクションの要点はテストです。どのモデルを採るにせよ、ペイウォールはリモートで設定変更・実験ができるようにしておくべきです。コピー、オファー、価格、UI をリリースなしで変えられること。ペイウォールはプロダクトなので頻繁に変更してどれが体験を改善するかテストしてください。
3. あなたはおそらくトライアルを間違って運用している
- State of Subscription Apps の統計で衝撃的だったのは、17 日以上のトライアルは 3 日以下のトライアルより 70% も良く変換するということです（42.5% 対 25.5%）。にもかかわらず、レポート中のアプリのほぼ半数が 4 日以下のトライアルを使っています。
- 多くのアプリが月額サブスクに対して 3 日トライアルを提供しているのを見かけるでしょう。業界全体が間違った方向に動いていると言えます。直感的には短いトライアルは緊急性を生むと思われがちですが、データは長いトライアルこそユーザーがアプリを日常に組み込む時間を与え、それがトライアル終了後に払わせる原因になると示しています。
- 開発者たちの話によれば、3 日トライアルが選ばれる理由はキャッシュフローの最適化（早くコンバージョンを得て指標を早く動かしたい）であることが多いです。しかし多くのコンバージョン増をわずかに早い信号のために犠牲にするのは悪いトレードオフです。
- もし今 3 日トライアルを運用しているなら、今月できる最も簡単な実験は 14 日または 21 日のトライアルと A/B テストすることです。
4. Android の課金失敗は床に落ちている無料の収益である
- これは Android に特有の話で、ほとんどの人が自分の数値を見て初めて気づく種類の問題です。Google Play のサブスクリプション解約の約 30% は involuntary（非自発的）です。つまりユーザーが自ら辞めたのではなく、カードが課金に失敗したために発生しています（古いカードが登録されている、銀行のセキュリティによる未承認の課金ブロックなど原因は複数）。
- App Store では同じ比率が約 14% です。つまり Android に出している場合、iOS と比べて機械的な理由で失うチャーンが 2 倍以上発生しています。
- 良い点は、これはプロダクト問題ではなく配管（plumbing）の問題であり、一度直せば放置できるタイプだということです。長いグレース期間、課金リトライロジック、アカウント保留からの回復フローなどを導入してください。多くの場合これらはトグルでオンにできます。初めてこれらを有効にすると、失われるはずだったユーザーの意味のある割合を回復できるでしょう。
- さらに UX の改善にもなります。Android が強い比重のアプリでまだ課金失敗回復の監査をしていないなら、これが今すぐ手を付けるべき最も影響の大きい項目です。
Build it in a weekend
ここまでで述べた戦略は実行可能ですが、...