AIexpoパフォーマンスreact-nativeウィジェット

2026年にモバイルアプリで稼ぐなら、いちばんいい方法は何か

Expo のベストな技術スタックに関する私見、アプリのマネタイズデータが示すもの、そしてそれでもなお React Native を選んで勝つべき理由

Expo BlogPerttu Lähteenlahti約 18 分

日本語
中文日本語
コピー
Best way to build a mobile app that makes money in 2026

この記事は Perttu Lähteenlahti によるゲスト投稿です。同氏は RevenueCat のデベロッパーアドボケイトとして、開発者がアプリで収益を上げるための支援をしています。

モバイルアプリのビジネスはすでにかなり厳しいものになっている。そしてこの事実は、語られる以上に深刻だ。RevenueCat の「2026 年サブスクリプションアプリ現状レポート」は 115,000 以上のアプリ、約 160 億ドルの収益を対象としているが、上位 25% のアプリは前年比 80% 成長した一方、下位 25% のアプリは 33% 縮小した。市場は勝者と敗者の二極化へと向かっている。

問題は、この差がより良いアイデアから生まれているわけではないことだ。上位 4 分の 1 に入るアプリのほとんどは、誰も思いつかなかったことをしているわけではない。他と同じことをしながら、より速くリリースし、より多くテストし、マネタイズを後回しの作業ではなく継続的に反復するプロセスとして扱っている。

この記事では、収益を生むモバイルアプリの作り方を扱う。適切な技術スタックの選び方、最も優れたアプリのマネタイズ手法に学ぶこと、そして Expo アプリが勝ち抜くために何が必要かを見ていく。来週 App.js カンファレンスで登壇するが、このブログはその予習のようなものだ。テーマは、AI が React Native を時代遅れにしつつあるのかという問い。ここに書く内容は、その問いに答えるために行った調査と、もう一つの問い——React Native アプリで稼げるのか、それとも agent に Swift や Kotlin で書いたアプリを他プラットフォームへ移植させるべきなのか——から直接得たものだ。

2026 年の技術スタック、はっきり言う

私の技術スタックに対する意見はかなり偏っている。読み進めればその理由がわかるはずだ。突き詰めると、このスタックはいくつかの核心理念に基づいている。

  • 速く作り、さらに速く届ける

  • 可能な限り OS ネイティブの API を活用する

  • オフライン体験を快適で機敏にする

この理念に従い、私のスタックはこの数年で変わり続けてきた。より使いやすいツール、より DX の良いツールへと、古いものを次々に置き換えてきた。

  • Expo と EAS：ビルド、提出、アプリの更新を担当する。すべてはここから始まる。数年前なら bare React Native アプリを選んでいただろうが、今は Expo なしでリリースするなど考えられない。

  • Tanstack query：データ取得、mutation、そして広い意味でのサーバー状態を管理する。react-native-network-info と react-native-mmkv を組み合わせれば、オフライン状態を優雅に処理できるアプリが作れる。

  • expo-apple-targets：ネイティブコードに踏み込むための道具だ。ネイティブ統合は重要で、widget、App Intents、Spotlight 検索、ライブアクティビティを使えないアプリにしてはいけない。ユーザーはこれらの機能を期待している。

  • RevenueCat：サブスクリプション、ペイウォール、エンタイトルメントを担当する。もちろん私は立場のある人間で、RevenueCat で働いている。だがこの点だけは私の言うことを聞かなくてもいいから、一つの教訓だけは覚えておいてほしい。サブスクリプションの基盤を自作してはいけない。あなたのアプリとそのマネタイズがあなたのビジネスであり、決済基盤はそうではない。

ここに挙げた選択はどれも時間を取り戻してくれる。そして取り戻した時間こそが、「週末でリリース」と「四半期がかりでリリース」の差になる。個人開発者が、うまく調整した agent とこのスタックを揃えれば、数日で実際のアプリで本物の金を稼げるようになる。

このスタックがマネタイズにとって重要なのは、統計的に見て React Native アプリのほうが稼げるからだ。State of Subscription Apps レポートはフレームワーク別に収益を分解しており、React Native アプリはインストールあたりの収益、有料ユーザーの継続率、LTV といったほぼすべての主要指標でネイティブアプリと Flutter アプリを上回っている。過去 2 年分のデータもほぼ同じ傾向で、AI 駆動開発による一時的な異常とは言えない。

React Native のマネタイズ成績が良い理由は以前も書いた。一言でいえば、React Native にはリリース速度とクロスプラットフォーム対応を最初から最適化しようとする開発者が集まり、そういう人たちはマネタイズを後回しの作業ではなくプロダクトの問題として扱う傾向がある。さらに React Native は素早い反復を可能にし、反復は品質を高め、品質はエンドユーザー体験を良くし、良い体験はより多くの収益を生む。

アプリマネタイズの早見表

アプリのマネタイズに関するアドバイスは、ひどく漠然としているか（「プロダクトマーケットフィットを見つけよう！」）、個別アプリの実績に基づいているかのどちらかだ。あるアプリでうまくいった方法が、別のアプリでもうまくいくとは限らない。結局のところ、プロダクト開発のほぼすべてのことと同じで、実験あるいは実験しかない。

とはいえこの記事のために、330 ページある「State of Subscription Apps」レポートを最初から最後まで読み込み、React Native 開発者にとって最も重要な洞察を選び出し、マネタイズ戦略を組み立てるのに使える考え方としてまとめた。

1. ユーザーは 0 日目に去留を決める

3 日間トライアルのキャンセルの 55% は 0 日目に起きている。直感に反するが、3 日目——トライアルが有料に転換するまさにその瞬間——ではない。ユーザーはアプリをインストールした当日、おそらくダウンロードしてトライアルに登録してから数分以内に、すでにキャンセルしている。

つまり、サブスクライバーを獲得するための戦いはすべて最初のセッションで起きている。ここで負ければ、そのサブスクライバーは永久に失われる。実務的には、「なるほど」と思わせる瞬間を作るチャンスは一度きりだと想定すべきだ。アプリが自分にとって価値のあるものかどうかを確かめる前に、待たせたり、登録させたり、大量の項目を入力させたりしてはいけない。注意力はもともと短く、面倒な UI への許容度はさらに低い。

アプリを自分で作るときも、他の開発者に助言するときも、いつも同じことを強調している。ユーザーが初めてアプリを開いてから30秒以内に、自分のデータが見えている状態にしろ、と。たとえば自分のアプリ Netli.fyi のオンボーディングは、要点が3つ、認可が1回だけで、そのままプロジェクトとデプロイが表示される。通知のような他の機能は後回しにする。権限を求める行為が、フローの摩擦になるからだ。

この「自分のものを見せろ」というやり方は、開発者ツールのようなユーティリティ系のアプリにはよく効く。ただ、他の種類のアプリには別の戦略が要る。たとえばヘルスケア系なら、データの重要度は低い。大事なのは、ユーザーにこのアプリを使い続ける長期目標を立ててもらうことだ。

Over-the-air updates はまさにこのためにある。Expo の OTA Updates のような仕組みを使えば、月曜に新しいオンボーディングを出し、数日後にデータを見て、1週間以内にもっと摩擦の少ないフローをデプロイできる。App Store や Google Play の審査を待つ必要は一切ない。両ストアの審査時間が数時間から数日へとじわじわ伸びている今なら、なおさらだ。

新規ユーザーにとって、オンボーディングは最も重要なページだ。ランディングページと同じように反復すべきで、離脱を分析し、A/B テストを回し、どこでユーザーが去っているのかを突き止める。オンボーディングを仕上げれば、最初の指標、つまりダウンロードから課金への転換はすでに改善されている。

2. ペイウォールは製品であって、ページではない

よく見る失敗はこれだ。何週間もかけてアプリを磨き上げ、最後に一番考えの浅いペイウォールをくっつける。ペイウォールがおざなりで、ダウンロードがサブスクに変わらないことのどこが不思議だろうか。ペイウォールは収益を生むページなのだから、機能と少なくとも同じくらいの重みで扱うべきだ。

ここはデータが面白く、少し直感に反する。ハードペイウォール、つまり購読しないと何もアンロックできない形式は、インストール時の転換率が freemium のおよそ5倍になる。10.7% 対 2.1%。この差は大きく、転換が主目的ならハードペイウォール一択ということになる。

だが一方で、1年後のリテンションはハードペイウォールと freemium でほぼ同じだ。ハードペイウォールは初期に有料ユーザーを多く集め、ソフトペイウォールの freemium は転換が遅い。それでも最終的に行き着く先は似ている。問いはどちらが優れているかではなく、自分のアプリにどちらが合うかだ。

同種のアプリとベンチマーク比較すると、どちらを選ぶべきか判断しやすい。瞑想系やフィットネス系は、価値を実感するまで数週間かかるから、freemium のほうがまず合う。写真エディタのように、最初の1分で欲しいかどうか分かるタイプなら、ハードペイウォールをやらないのはただ金を捨てているだけだ。

ソフトペイウォールは魅力的に見える。できるだけ多くのユーザーに、せめて機能の一部だけでも使ってもらうのが狙いだ。自分も何度もこの考えに引き込まれた。ただ、無料で使うユーザーと、最終的に課金するユーザーでは、目指しているものが違うことが多い。自分がレストランの店主で、看板メニューが誰にでも愛される5品のコースだとする。無料枠を作ってパン棒と水道水だけを出し、店内を満員にしたところで、本業が良くなるわけではない。賑わっては見えるし、パン棒を食べた人の一部がいつかコースを頼むかもしれない。それでも、彼らを客と呼ぶだろうか。

この節は結局、もうひとつの話に行き着く。テストだ。どちらのモデルを選んでも、テストすべきだ。優れたペイウォールはリモートで設定でき、実験機能を備えている。つまり新しいバージョンを出さずに、コピー、オファー、価格、UI を変えられる。ペイウォールが製品なら、頻繁に手を入れ、どの変更が体験を良くしたかをテストすればいい。

3. トライアル期間はおそらく間違っている

『订阅应用现状』で目が止まったデータがある。17日以上のトライアルは、3日以内のトライアルより転換率が70%高い。42.5% 対 25.5%。ところがレポート内のアプリのほぼ半数が、今は4日以内のトライアルを使っている。自分でも見覚えがあるだろう。月額サブスクに3日トライアルを付けているアプリは多い。

ここは安心して言える。業界全体がずっと間違った方向に進んでいる。直感は、トライアルが短いほど切迫感が出ると告げる。データは逆を言う。トライアルが長いほど、ユーザーがアプリを日常に組み込みやすくなり、だからこそトライアル終了時に課金するのだ。

開発者と話していて分かるのは、3日トライアルを選ぶ理由がキャッシュフローの最適化だということだ。転換を早く得て、指標の変化を早く見たい。だがそれでは、はるかに大きな転換率の伸びを、少し早いシグナルと引き換えにしている。割に合わない。

今3日トライアルを回しているなら、今月いちばん簡単にできる実験は、14日か21日のバージョンと比べてみることだ。

4. Android の支払い失敗は捨てられている収益

これは Android だけの話で、誰も話題にしないが、ある日データを見て、解約の3分の1が本来防げたと気づくまで気に留めない類の問題だ。

Google Play では、サブスクリプションの解約のおよそ30%が非自発的だ。つまりユーザーは去るつもりなどなく、ただ支払いが失敗しただけだ。カードの期限切れだったり、銀行の不正検知が見慣れない引き落としを止めたりと、理由はいろいろある。App Store ではこの数字は約14%。だから Android を作っているなら、純粋に機械的な理由で失うユーザーの割合は iOS の2倍以上になる。

良い知らせは、これが製品の問題ではなく配管の問題だということだ。配管の問題は一度直せば忘れられる。長めの猶予期間、支払いのリトライ処理、アカウント凍結からの復旧フローを加える。こうした機能の多くは、バックエンドでスイッチを入れるだけで済む。一度有効にすれば、解約として数えていたはずのユーザーのかなりの部分を取り戻せるはずだ。おまけに、アプリの使い勝手も良くなる。

もしあなたのアプリが Android 中心で、まだ支払い失敗時のリカバリー導線を検証していないなら、今いちばん費用対効果が高いのはこれだ。

週末ひとつで作れる

ここまで話してきた戦略はどれも実行可能だが、エンジニアの思考法には必ずしも合わない。製品論で終わらせないために、RevenueCat を組み込んでこれらを全部実装する方法を見ていこう。ゼロから実際にお金を集めるまでの最短ルートだ。これらの機能を使うには RevenueCat のアカウントが必要だが、アプリの月収が 2.5k ドルに達するまでは完全に無料だ。

Expo プロジェクトを新規作成し、2 つのパッケージを入れる。react-native-purchases と react-native-purchases-ui だ。前者は RevenueCat SDK を提供し、アプリ内課金、サブスクリプション、entitlement を扱う。後者は RevenueCat のダッシュボードで作成した paywall を表示できるようにする。

npx create-expo-app my-app

cd my-app

npx expo install react-native-purchases react-native-purchases-ui

SDK 統合の作業のほとんどは、agent がデフォルトでそれなりにこなしてくれる。ただ RevenueCat は各プラットフォーム向けの skills も提供していて、SDK 統合のベストプラクティスに沿えるようになっている。RevenueCat skills はこちら。

次のステップは RevenueCat を App Store Connect と Google Play Console に接続し、両方でプロダクトを設定すること。前者はこのガイドに沿って進めればいい。後者は以前かなり苦痛だった。Google と Apple がプロダクト設定に大量の要件を課すからだが、今はRevenueCat MCP をそのまま使えばいい。MCP を使えば、両ストアと RevenueCat にプロダクトと entitlement を同時に追加できる。必要なのは次のような prompt ひとつだ。

RevenueCat MCP でサブスクリプションを 2 つ追加して。年払いと月払いで、前者は 49.99、後者は 5.99 の価格。月払いには 14 日間のトライアルを設定。サブスクリプションは ‘Pro’ という entitlement に紐づけて。表示は RevenueCat Paywall 経由で。

RevenueCat SDK を初期化して paywall を表示する

アプリ内で SDK を初期化するのは数行で済む。

import { Platform } from 'react-native';
import Purchases from 'react-native-purchases';

const apiKey = Platform.select({
  ios: 'appl_xxxxxxxxxxxxxxxxxxxxxxxxx',
  android: 'goog_xxxxxxxxxxxxxxxxxxxxxxxxx',
  default: 'appl_xxxxxxxxxxxxxxxxxxxxxxxxx',
});

Purchases.configure({ apiKey });

ユーザーに有効な entitlement があるか（つまりアプリの一部機能にアクセスできるか）を確認するのは 2 行だけだ。

const info = await Purchases.getCustomerInfo();
const isPro = info.entitlements.active['pro'] !== undefined;

entitlement のチェックはこれで全部。これをカスタム hook にまとめておけばもっと使いやすくなる。

import { useEffect, useState } from 'react';
import Purchases, { CustomerInfo } from 'react-native-purchases';

type UseEntitlementResult = {
  isActive: boolean;
  isLoading: boolean;
};

export function useEntitlement(entitlementId: string): UseEntitlementResult {
  const [isActive, setIsActive] = useState(false);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    let cancelled = false;

    const update = (info: CustomerInfo): void => {
      if (cancelled) return;
      setIsActive(info.entitlements.active[entitlementId] !== undefined);
      setIsLoading(false);
    };

    const load = async (): Promise<void> => {
      try {
        const info = await Purchases.getCustomerInfo();
        update(info);
      } catch (e: unknown) {
        if (cancelled) return;
        console.warn('RevenueCat: failed to fetch customer info', e);
        setIsLoading(false);
      }
    };

    void load();
    Purchases.addCustomerInfoUpdateListener(update);

    return () => {
      cancelled = true;
      Purchases.removeCustomerInfoUpdateListener(update);
    };
  }, [entitlementId]);

  return { isActive, isLoading };
}

export const useIsPro = (): UseEntitlementResult => useEntitlement('pro');

hook の戻り値で課金が必要な機能を包めば、それで終わり。

RevenueCat Paywalls コンポーネントを実際の購入ページに置けば、dashboard から直接更新でき、リリースし直す必要のない paywall が手に入る。

import RevenueCatUI from 'react-native-purchases-ui';

function PaywallScreen({ navigation }) {
  return (
    <RevenueCatUI.Paywall
      onPurchaseCompleted={() => navigation.goBack()}
      onRestoreCompleted={() => navigation.goBack()}
      onDismiss={() => navigation.goBack()}
    />
  );
}

この Paywall は RevenueCat dashboard で作成できる。ドラッグ&ドロップのビルダーを使うか、AI builder に prompt を書いてもいい。paywall のアイデアを探しているならこれを見てみるといい。

最後はアプリを EAS に提出して、お母さんや、あなたが感銘を与えたい誰かの手元に届けるだけだ。

eas build --platform all
eas submit

ここまでの内容はおそらく既に知っているだろうから、このセクションで強調したいのは実質ひとつだけだ。要はプロダクト戦略がものを言い、開発そのものではない。全部合わせて週末ひとつの作業量でしかない。時間の大半はコードではなく、App Store Connect と Google Play の各種手続きに消える。

この問題にこれだけ紙幅を割いたのは、1 年前なら今説明した作業に少なくとも 1〜2 週間かかっていたからだ。さらに数年前なら、何倍もかかった。エンジニアリングの工程は速くなったが、良いプロダクトを作るには依然として時間がかかる。ただ、今のスタート地点は、かつての 1 週間の成果より高い。

時間はどこに使うべきか

インフラの問題が片付けば、本来インフラに投じるはずだったエンジニアリング時間の 80% が浮く。その時間で何をするかが本当の論点だ。やる価値があるのは 3 つだけだと思う。

ひとつ目はオンボーディング。EAS アップデートで継続的に改善できるので、長いストア審査を待たなくていい。今日のアクティベーションファネルがどんな形であれ、半年後のバージョンは見違えるほどになっているはずだ。その間に少なくとも 20 のバリアントを出しているのだから。

ふたつ目は paywall。理屈は同じ。毎週テストする生きた画面として扱う。新しいコピー、新しい価格表示、新しいプランの並び順、新しいトライアル期間。RevenueCat Paywalls があれば、こうしたテストのほとんどはリリースすら不要だ。

みっつ目はユーザーと話すこと（ええ、わかってます）。エンジニアが最も投資を怠りがちで、最も複利効果が強い。専任のユーザーリサーチチームは要らない。レビューを読み、サポートメールに返信し、実際にお金を払ってくれている人に自分から連絡すればいい。こうした会話から浮かび上がるパターンは、どんなグロースハックよりも価値がある。

技術スタックが残りすべてを引き受けたあと、仕事はこれだけになる。プロダクトを作り、ファネルを回し、人と話す。

AI アプリと、AI でアプリを作ることについて

ここは独立して触れておく価値のある注記だ。2026 年にリリースされるアプリの半分は何らかの形で AI を帯びるからだ。State of Subscription Apps レポートのデータは興味深い。AI 駆動のアプリは、非 AI アプリより有料ユーザー 1 人あたりの収益が 41% 高い。熱は本物で、支払い意欲も本物で、ユーザーあたり平均収益も本物だ。

ただし、手を動かす前に受け入れておくべきことがひとつある。AI アプリの解約は 30% 速い。ユーザーは登録し、しばらく盛り上がり、1 週間使って、新鮮味が切れて、解約する。

つまり、AI アプリを作っているなら、マネタイズの問題は価格設定ではなくリテンションにある。2 週目に入ったとたんに「もう役に立たない」と感じさせるのが根本原因なら、トライアル期間の長さやペイウォールの文言を最適化する時間に使うべきではない。まずリテンションを直す。残る理由を、去る理由より大きくする。人が使い続けたいと思うプロダクトができて、はじめて価格の最適化に意味が出る。

今日、アプリを作れ

個人開発者やチームが今手にしている道具は、数年前なら想像するしかなかったものだ。AI が実装の退屈な部分を引き受けてくれる。Expo と React Native が、2 つのプラットフォームへの配信コストを解決した。

残っているのは、昔からずっと一番難しい部分だ。本当に解決する価値のある問題を見つけて、ひたすらリリースし続けること。インフラはもうボトルネックではない。あなたがボトルネックだ。

ここまで読んで、もっと長いバージョンが欲しい人へ。今月 App.js で登壇する。タイトルは Is AI making React Native obsolete?。数か月取り組んできた副業プロジェクトの話をする——同じアプリを 3 通りの方法で作り、そのひとつは agentic coding だけで SwiftUI アプリを Kotlin に変換する——そしてこの実験から、AI 支援開発の時代に React Native がどう位置づけられるかが見えてくる。ネタバレすると、この記事は Expo のブログに書いているので、結論はだいたい想像がつくだろう。でも細部は面白い。会場に来るなら、声をかけてほしい。

出典: Expo Blog← ホームへ戻る