最近、複数のAI搭載サブスクリプションアプリと関わる中で、このパターンに気づきました。本来促進したい行動――より多くの利用、より多くの探索、より多くのインタラクション――が、マネタイズとインフラが連動して設計されていない場合、利益率を圧迫してしまうのです。

AIは単なるプロダクト機能ではありません。インフラです。したがって、リリース前にAIの利用量をARPU、チャーン、LTVと照らし合わせてモデリングしていない場合、エンゲージメントを高めながら、気づかないうちに経済性を損なっている可能性があります。

ユーザーエンゲージメントはもはや無料ではない

サブスクリプションビジネスは構造的に効率的です。少なくとも、これまではそうでした。コアとなるプロダクト体験を構築してしまえば、アプリ内で追加のサブスクライバーにサービスを提供するための限界コストは通常ほぼゼロに近く、スケールするほど経済性は複利的に向上していきます。（この点については、Thomas Petitが「なぜハイブリッドマネタイズがサブスクリプションアプリのデフォルトになるべきか」というブログで触れています。）

一方でAIは、この美しい構造を崩します。AI機能を導入することで、機能単位での変動コストが発生します。ユーザーがAI機能を利用するたびにトークンが消費され、推論エンドポイントが呼び出され、サードパーティのプロバイダーに計算コスト（AIモデルを動かすためのハードウェアリソース）を支払う必要があります。

要するに、コスト構造は利用量と切り離せなくなります。

これにより、微妙ながら重要な緊張関係が生まれます。これまで増やしてきたエンゲージメントそのものが、今度は追加コストを生む要因になるのです。エンゲージメントが高まるほどAIの呼び出しが増え、AIの呼び出しが増えるほどインフラコストが増加します。そして、収益がそれに比例して拡大しない限り、粗利率は徐々に低下していきます。

アプリにおけるAIコストを削減する5つの方法

では、これは何を意味するのでしょうか？AI機能は本質的に利益率を下げるものなのでしょうか？必ずしもそうではありません。AIの導入によって、サブスクリプションビジネスはクラウドインフラビジネスのように考える必要が出てきます。つまり、利用量はもはや成長指標であるだけでなく、コストを生み出す要因でもあるということです。

1. AIインフラは自前で構築するのではなく、購入するべき

最近、複数のAIプロダクトに関わるポートフォリオのOpsマネージャーと話した際、よくある問題が挙げられました。あるアプリで使用していた音楽生成APIが不安定になり、有料ユーザーでさえコア機能にアクセスできなくなったのです。その結果、クレームが増え、レビューは悪化し、マネタイズのパフォーマンスも評価しづらくなりました。

これが、AIが従来のアプリ機能と異なる点です。問題は「ユーザーがその機能を求めているか」だけではなく、「インフラがそれを十分に安定して提供できるか（かつ経済性を損なわないか）」という点にあります。

そのため、どのインフラを選ぶかは慎重に検討すべきです。大規模なAIプラットフォームを運営している場合は、大規模データの学習や独自モデルの構築が適していることもあります。しかし、ほとんどのサブスクリプションアプリにとっては、サードパーティのAPI（例：OpenAIのChatGPT、GoogleのGemini、AnthropicのClaude）を利用する方がはるかに適しています。特に、マネタイズや機能、プロダクトマーケットフィットをまだ検証中であればなおさらです。

自前でモデルを運用する場合、以下のような課題が発生します：

• GPUのコスト負担
• DevOpsの複雑性
• モデルメンテナンスのリスク
• 利用量に関係なく発生する固定的な月額コスト

これは非常にリスクの高い状態です。そのため、多くの成長段階のサブスクリプションアプリにとっては、APIベースの基盤モデルを利用する方が合理的です：

1. トークン課金により、AIコストを実際の利用量に応じた変動コストにできる
2. 機能がインストールから課金へのコンバージョン、トライアル開始、ARPU、リテンションに寄与しなければ、その機能を停止すればコストも消える

要するに：変動コストは戦略的な柔軟性を維持する。一方で固定インフラは、正当化できない実験に縛り付けることになります。

2. AIの利用を広告費と同じように扱う

サブスクリプションチームは通常、獲得コストに対して非常に敏感です。CAC、回収期間、ROASなどを細かく追跡しています。しかし、その同じチームがAIの利用については軽視していることが多く、AIトークンもまた「支出の一種」であるという認識が十分ではありません。

ユーザーがAI機能を使うたびに、そのコストは発生します。プロンプトが長くなればなるほど、レスポンスが長くなればなるほど、そしてユーザーが「再生成」を押す回数が増えるほど、コストは増加します。これを有料広告と同じように考えてください。インプレッションごとにコストが発生し、クリックごとにコストが発生するのと同様に、AIでもリクエストごとに費用がかかります。

あるAIチームは、クレジットシステムを変更した際にこの影響をすぐに実感しました。日ごとの制限が厳しい仕組みから、柔軟な月次クレジットへと移行したところ、生成量は一夜にして増加しました。一部のユーザーは初日だけで大量のクレジットを消費しました。機能自体は変わっていませんが、利用制限が変わったのです。そしてAIプロダクトにおいては、この利用制限がインフラコストに直結します。

優れたチームは、コストを前提にAI機能を設計します。レスポンスの長さを制限し、ユーザーが必要としない限り不要な説明を生成させないようにします。このような小さな判断が、想像以上に大きな影響を持ちます。たとえば、600語の説明を書かせるよりも、構造化された30語の回答を返させる方が、はるかに低コストです。

スケールした場合、こうした選択はAIコストを大きく削減します。数百万件のリクエストにおいては、これは小さな最適化ではありません。粗利に直結する重要なレバーとなります。

3. 必要十分な最も安価なAIモデルを使う

もう一つよくあるコストの無駄は、すべてのAIリクエストを常に最も高性能なモデルに送ってしまうことです。一見安全に思えますし、最高のモデルが最良の体験を生むと考えがちです。しかし実際には、多くの場合それは単に請求額を最大化しているだけです。

すべてのタスクに高性能なモデルが必要なわけではありません。多くのAI機能は比較的シンプルな処理を行っています。たとえば、コンテンツのタグ付け、テキストの整形、情報の要約、短いアウトプットの生成などです。これらはより小型で安価なモデルでも十分に対応でき、ユーザー体験も変わりません。ユーザーはプレミアムモデルと中価格帯モデルの違いに気づかないかもしれませんが、インフラコストには確実に差が現れます。

高価なモデルは、本当に高度な推論が必要な複雑なタスクに限定し、それ以外は安価なモデルを使うべきです。タスクごとに適切なモデルを選択することは、AI搭載アプリにおいて最も効果の大きいコスト最適化の一つです。

4. AIの結果を再生成するのではなく再利用する

ユーザーの行動は、多くのチームが想像している以上に反復的です。特に生産性系やユーティリティ系のアプリでは、ユーザーは同じようなことを何度も繰り返し求める傾向があります。似たプロンプト、似た変換、似たワークフローです。もしアプリが毎回まったく新しいAIレスポンスを生成している場合、すでに生成済みの回答に対して繰り返しコストを支払っている可能性があります。同様に、ユーザーは過去の会話を遡る代わりに、再び同じ内容を質問することもあります。

こうした場面では、可能な限り結果を再利用することが重要です。よく使われる出力を保存し、再利用可能なテンプレートを用意し、頻出リクエストに対しては事前にレスポンスを生成しておくことで、再生成せず即座に提供できます。こうした小さな改善でも大きな効果があります。仮にリクエストの20％だけでも再利用できれば、AIコストは大幅に削減できます。

5. AI機能をマネタイズの背後に配置する

すでに、多くのアプリが無料プランでのAI利用を制限し、高度な機能をサブスクリプションプランの背後に配置する動きが見られます。通常、計算コストに応じて価格帯ごとに機能が分けられています。このような変更はユーザーにとって特に驚くものではありませんが、ビジネスには大きな財務的インパクトをもたらします。

一部のアプリでは、少数のヘビーユーザーが過剰なインフラコストを生み出さないように、日次または月次の利用上限を設けています。たとえば、月あたり0.15ドルのコストがかかるヘビーユーザーが、その後29.99ドルの年額プランを購入すれば、経済的には問題ありません。しかし、そのユーザーが課金せずにAIを使い続けた場合、収益構造は静かに悪化していきます。

あるチームは、AIを活用した学習プロダクトにクオータ制を導入しました。新規ユーザーには初期クレジットが付与され、追加利用は有料パッケージによって解放されます。このようなモデルは、利用量とコストが相対的であることを前提としています。

また、別のAIアプリチームでは、従来の無料トライアルを提供しないという判断をしました。トライアルユーザーが大量の出力を生成し、APIコストを消費したうえで課金せずに離脱してしまうためです。その代わりに、一度限りのクレジット付与をテストし、無制限の推論コストを発生させることなくプロダクトの品質を評価できるようにしました。

無料のAIクレジットにおける本当のリスクは、単にユーザーがそれを使うことではありません。プロダクトが十分に良くなる前に使われてしまうことです。その場合、あなたはアクティベーションではなくチャーンにコストを投じていることになります。

これが、サブスクリプションアプリにおけるAIマネタイズが従来のサブスクリプション設計と根本的に異なる理由です。単に価値へのアクセスに価格を付けているのではありません。マネタイズや価格設計の変更は、より広いインフラ経済全体に影響を与えます。利用状況とリテンションの分析は極めて重要です。誰が何をどれくらい使っているのか、なぜ使っているのかを理解し、それに基づいて価格設計（P&P）と計算コストをセットで見直していきましょう。

AIのユニットエコノミクス

AIの隠れたコストに関する議論は定量化が難しいものですが、すでにAI機能やアプリを運用している場合は比較的理解しやすくなります。ここでは、馴染みのあるサブスクリプション指標を使って考えてみましょう。

以下のような指標を持つサブスクリプションアプリを想定します：

• 月次 ARPU：$6.00
• 正規化された年次ARPU：$4.20
• ユーザーベース全体のブレンドARPU：$5.10
• 月次チャーン：5%
• 粗利率（AI導入前）：85%

ここでAI機能を導入します。平均的なAI利用ユーザーは月に10回リクエストを行い、各リクエストで1,000トークンを消費します。トークン単価は0.002ドルとすると、AIアクティブユーザー1人あたりのコスト（1,000トークンあたり）は0.02ドルになります。

MAUが300,000人で、そのうち15％がAI機能を利用している場合、AIアクティブユーザーは45,000人です。これにより、月間のAIコストは900ドル、年間では10,800ドルとなります。この水準であれば管理可能です。

しかし、利用量が増加し、より高価なモデルへのルーティングが増えた場合を考えてみましょう。AIアクティブユーザー1人あたりのコストが月0.10ドルに上昇すると、同じ45,000人でも月間コストは4,500ドル、年間では54,000ドルになります。

これが高いかどうかは様々な要因に依存しますが、最終的に重要なのは、AI機能がユーザーあたりのコスト増加以上にLTVを押し上げるかどうかです。つまり――

AI機能はコストに見合う価値があるのか？

年間100万インストールがあり、インストールから課金へのコンバージョン率が4％だとすると、有料ユーザーは40,000人になります。平均LTVが42ドルの場合、年間のサブスクリプション収益は168万ドルです。

ここでAI機能によってコンバージョン率がわずか0.5ポイント向上したとします。有料ユーザーは45,000人となり、5,000人の増加です。これは追加で210,000ドルの収益に相当します。

年間54,000ドルのAIインフラコストと比較すると、この機能はコストを大きく上回る収益を生み出しています。つまり、コストに見合う価値があると言えます。

しかし、コンバージョンが十分に改善せず、リテンションも向上しない場合はどうでしょうか。その場合、54,000ドルを使って収益に影響しないエンゲージメント指標を伸ばしているだけになります。結果として、粗利率は低下し、MAUあたりの貢献利益も縮小し、その機能は高コストな“気をそらす要因”になってしまいます。

これが、AIが静かにサブスクリプションビジネスを壊していく仕組みです。

誰もがAIに注目しているが、リテンションは改善されていない

これは、AIがコストに見合うためにはコンバージョンを向上させる必要があるという意味でしょうか？理想的にはそうです。しかし、リテンションを改善することでも価値を生み出せます。

月次ARPUが6ドル、チャーン率が5％の場合、理論上の定常状態のLTVは約120ドルになります。ここでAIによってチャーンが4.6％に低下したとすると、LTVは約130ドルに上昇します。これは1ユーザーあたり10ドルの増加であり、20,000人のサブスクライバー全体では200,000ドルの追加価値となります。

元の数値に戻ると、AIの年間コストが54,000ドルであっても、わずかなリテンション改善（この例では0.4％の低下）でも生み出せれば、非常に高いリターンを持つ投資となり得ます。

ただし、新しいAI機能を追加する前に重要な点があります。リテンションの改善は、単なるエンゲージメントから推測するのではなく、コホートデータで実際に確認する必要があります。AIによる改善は、必ず測定可能でなければなりません。

AIの価値を読み解く：AIコストは収益ダッシュボードに含めるべき

RevenueCatはすでに、サブスクリプションのパフォーマンスを左右する主要な指標――ARPU、チャーン、LTV、コホートリテンション――を明確に可視化してくれます。しかし、それはパズルの半分に過ぎません。アプリにAI機能が含まれている場合、これらの指標と並行してAIインフラコストも分析する必要があります。

実務的には、AIの利用データとサブスクリプション指標を組み合わせて、利用量が利益率にどのように影響しているかを理解することを意味します。

具体的には、以下のような指標を把握しておくべきです：

• MAUあたりのAIコスト
• AIアクティブユーザーあたりのAIコスト
• 課金ユーザーあたりのAIコスト
• ARPUに対するAIコストの割合
• ブレンドARPUに対するAIコストの割合

これらの数値をサブスクリプション指標と並べて見ることで、AIがビジネスを強化しているのか、それとも静かに利益率を削っているのかを理解しやすくなります。

たとえば、ARPUが6ドルでAIコストが0.18ドルの場合、収益の約3％をAIに使っていることになります。これは問題ありません。しかし、ARPUが3.50ドルでAIコストが0.60ドルになると、その割合は17％に跳ね上がります。これは単なる機能コストではなく、構造的な利益率の問題です。

ハイブリッドマネタイズにおけるブレンドARPU

広告とサブスクリプションを組み合わせたハイブリッドマネタイズモデルでは、分析はより複雑になります。AIコストがサブスクライバーだけでなく無料ユーザーにも広く適用される場合、MAUあたりのコストはブレンドARPUと比較して評価する必要があります。

数値で考えてみましょう。サブスクライバーのARPUが6ドル、広告ARPUが0.20ドル、MAU全体でのブレンドARPUが0.95ドルだとします。このとき、AIコストがMAUあたり0.06ドルであれば、収益の約6％に相当します。一方で、AIコストがMAUあたり0.20ドルであれば、ブレンド収益の20％以上を消費することになります。

これらの指標を分析することは、AIがどのようにマネタイズモデルを変化させているかを理解するうえで不可欠です。ハイブリッドモデルを採用しているチームは、ブレンドマージンを守るために特に厳密な管理が求められますが、AI機能を扱うすべてのチームにとって、利益率への影響を常に意識することが重要です。

AI導入前のチェックリスト

AI機能をリリースする前に、以下の項目について数値で答えられる状態にしておくべきです：

• どの指標を改善しようとしているのか？インストールから課金へのコンバージョン、トライアル開始、トライアルコンバージョン、リテンション、ARPUの向上のどれか
• どの程度の改善を想定しているのか？コンバージョンが0.3ポイント上がるのか、チャーンが0.2ポイント下がるのか
• アクティブユーザーあたり、課金ユーザーあたりのAIコストはいくらになる見込みか
• 想定される利用量において、AIコストはARPUの何％を占めるのか
• どの利用量を超えると、粗利率が許容範囲を下回るのか

これらの質問に答えられないのであれば、そのリリースは戦略的とは言えません。

AIは経済性が成立してこそ機能する

これまで長年にわたり、サブスクリプションアプリはシンプルな経済モデルの恩恵を受けてきました。エンゲージメントが高まるほど価値が増し、リテンションも向上し、コストはほとんど増えない――そうした構造でした。しかし、AIはそれを根本から変えました。

とはいえ、AIがサブスクリプションビジネスにとって悪いものだというわけではありません。多くの場合、リテンションの改善、コンバージョンの向上、LTVの拡大に寄与します。ただし、それらは保証された結果ではありません。チームがAIを「プロダクト機能」であると同時に「コストレイヤー」として扱った場合にのみ実現します。

チームはAIを、ユーザー獲得費用やインフラと同じように管理する必要があります。結果の再利用、安価なモデルへのタスク振り分け、マネタイズによるアクセス制御、そしてARPUやLTVといったサブスクリプション指標と並行したAIコストのトラッキングです。最も成功しているAIアプリは、単に機能を追加しているのではなく、利用量の経済性を中心にシステム全体を設計しています。

同じデータセットをもう一段深く見ると、Androidのトライアルから課金へのコンバージョン率は32.5％、iOSは32.6％となっています。つまり、どちらのプラットフォームでも、一度トライアルを開始したユーザーは統計的にほぼ同じ割合で課金に至っています。ただし重要な注意点があります。Androidではトライアルを開始するユーザー層がより絞り込まれている可能性があります。Androidではそもそもトライアルが表示される機会が少ないため、トライアルを開始するユーザーはより購買意欲が高い傾向にあります。この選択バイアスが、両者のコンバージョン率が近づく理由の一部となっています。それでもなお、主要なレバーは明確です。Androidアプリは、この最初のステージにユーザーを十分に送り込めていません。このギャップを埋めるには、まずより多くのユーザーにトライアルを開始してもらうことから始まります。

本記事では、Androidのペイウォールファネルが2段階で構成されていることと、そのどこでユーザーが離脱しているのか、Google Playのオファーおよびタグシステムがどのサブスクリプションオプションをユーザーに表示するかをどのように制御しているのか、RevenueCatのSubscriptionOptionsの選択ロジックがどのように機能し、どこでサイレントな設定ミスが発生するのか、ハードペイウォールとフリーミアムモデルに関するデータが何を示しているのか、そしてRevenueCat Experimentsを使ってこのギャップを体系的に解消する方法について解説します。

根本的な問題：2つのステージ、そのうち1つが壊れている

ダウンロードから課金に至るまでのユーザージャーニーは、2つの明確なステージに分かれており、それぞれ異なる挙動を示します。

最初のステージは「ダウンロードからトライアル開始まで」です。ユーザーはアプリをインストールし、ペイウォールに到達し、無料トライアルを開始するかどうかを判断します。2つ目のステージは「トライアル開始から課金まで」です。トライアルが終了し、ユーザーがサブスクライバーとして継続するかどうかを決定します。

RevenueCatのデータは、Androidにおいてこの2つのステージの挙動が大きく異なることを示しています。トライアルを開始したユーザーは32.5％の確率で課金に至り、iOSの32.6％とほぼ同じです。しかし、Androidアプリはこの最初のステージに送り込めているユーザー数が大幅に少ないのです。コンバージョンギャップの大部分は、このステージ1に存在しています。

これを具体的に示すデータがあります。トライアル開始の89.4％はインストール当日に発生しています。購買意欲の高いユーザーは、ダウンロード直後に行動します。一方で、インストール当日にトライアルを開始しなかったユーザーは、後から戻って開始することはほとんどありません。つまり、Androidにおける最初のペイウォール表示は、サブスクリプション収益の大半を決定づける瞬間なのです。その後のトライアル体験、オンボーディング、プロダクト自体のパフォーマンスは、AndroidでもiOSでもほぼ同等です。問題は、ユーザーがそもそもその瞬間に到達しているかどうかなのです。

ステージ1：ユーザーがトライアルを見るかどうかを決める要因

Androidでユーザーに無料トライアルが提示されるかどうかは、2つの要素によって決まります。それは「何を表示するか（ペイウォールの種類）」と「いつ表示するか（タイミング）」です。どちらも完全にコントロール可能です。

ペイウォールタイプの差

RevenueCatのデータでは、ペイウォールモデルごとにD35（35日間）のダウンロードから課金へのコンバージョン（最大1ヶ月のトライアル期間をカバーする測定ウィンドウ）が分析されています。コア機能にアクセスする前にサブスクリプションオファーとのインタラクションを必須とするハードペイウォールは、D35コンバージョンの中央値が10.7％です。さらに、上位10％のハードペイウォールアプリでは38.7％に達します。一方で、無料で一部機能を利用できるフリーミアムモデルの中央値は2.1％です。

これはコンバージョンにおいて約5倍の差でありながら、年間リテンションはほぼ同じです。ハードペイウォールは12ヶ月後に27％のサブスクライバーを維持し、フリーミアムは28％です。ほとんどのアプリカテゴリにおいて、ハードペイウォールの数値は大幅に優れています。もしあなたのプロダクトが1回のセッションで明確かつ即時に価値を提供できるのであれば、ハードペイウォールはほぼ確実に適したモデルです。一方で、フリーミアムが適しているのは、ネットワーク効果や価値の発見に時間がかかるカテゴリ――たとえばソーシャルアプリやコミュニティツールのように、収益化の前に広いユーザーベースの獲得が重要な場合です。

ただし、フリーミアムが後半のコンバージョンで優位性を示すケースが1つあります。6週目時点では、フリーミアムアプリはそのコホートの22.9％をコンバージョンさせるのに対し、ハードペイウォールは15.3％にとどまります。もしプロダクトが数週間かけて徐々に価値を発揮するような長い発見サイクルを持つ場合、フリーミアムはハードペイウォールでは取りこぼしてしまうユーザーを獲得できるのです。

ペイウォール表示タイミングの差

トライアル開始の89.4％がDay 0（初日）に集中しているという事実は、タイミングに対して明確な示唆を与えます。ペイウォールは最初のセッションで表示すべきです。最初のセッション以降は、効果が急速に低下していきます。

ただし、これはオンボーディングの前にペイウォールを表示すべきという意味ではありません。ユーザーがプロダクトの価値を理解する前にペイウォールを表示するアプリは、一般的にオプトイン率が低くなります。効果的なパターンはこうです：まず1つの強い価値体験（1つのタスクの完了、主要機能の提示、具体的なアウトプット）を提供し、その後にペイウォールを表示する。しかも、それをDay 0に行うことです。

見えない失敗：オファー設定ミスによってトライアルがサイレントに抑制される場合

ペイウォールの種類とタイミングが正しくても、Androidにはもう一つ見落とされがちなトライアル失敗の原因があります。それは、サブスクリプションオファー自体がユーザーに表示されていない可能性です。これはGoogle Playの設定に関する問題であり、エラーが表示されないまま発生することがあります。

Google Playにおけるサブスクリプションオファーの構造

Google Playのすべてのサブスクリプションは、ベースプランと、必要に応じて1つ以上のオファーで構成されます。オファーは、ベースプランの価格に先立つプロモーション価格のフェーズ（無料トライアル、導入価格、またはその両方）を定義します。オファーはBilling Library内では ProductDetails.SubscriptionOfferDetails として表現されます。

各 SubscriptionOfferDetails オブジェクトは、価格フェーズのリスト、オファータグのセット、そして購入を開始するためのオファートークンを持っています。価格フェーズは各ステージの価格と期間を示します。オファータグは、Play Console上でベースプランまたはオファー単位で設定する文字列です。Billing Libraryでは getOfferTags() によって両方のタグの集合（ユニオン）が返されるため、ベースプランに設定したタグは、その下のすべてのオファーにも自動的に適用されます。

RevenueCatがプロダクト情報を取得すると、各 SubscriptionOfferDetails は GoogleSubscriptionOption に変換されます。 subscriptionOptionConversions.kt における変換処理を見ると、以下のようになります：

internal fun ProductDetails.SubscriptionOfferDetails.toSubscriptionOption(
    productId: String,
    productDetails: ProductDetails,
): GoogleSubscriptionOption {
    val pricingPhases = pricingPhases.pricingPhaseList.map { it.toRevenueCatPricingPhase() }
    return GoogleSubscriptionOption(
        productId,
        basePlanId,
        offerId,
        pricingPhases,
        offerTags,
        productDetails,
        offerToken,
        presentedOfferingContext = null,
        installmentPlanDetails?.installmentsInfo,
    )
}

offerId はベースプランでは null であり、オファー付きのオプションでは値が設定されます。 The offerToken はユーザーが「無料トライアルを開始」をタップした際に課金フローへ渡されるものであり、The offerTags にはPlay Consoleで割り当てたラベルが含まれます。

RevenueCatがデフォルトオファーを選択する仕組み

プロダクトに GoogleSubscriptionOption オブジェクトのリストが含まれると、RevenueCatはそれらを SubscriptionOptions コレクションにまとめ、 defaultOffer プロパティとして公開します。これは、明示的に別のオプションを選択しない限り、ペイウォール上に表示されるオプションです。

SubscriptionOptions.kt における選択アルゴリズムは次のように動作します：

public val defaultOffer: SubscriptionOption?
    get() {
        val basePlan = this.firstOrNull { it.isBasePlan } ?: return null

        val validOffers = this
            .filter { !it.isBasePlan }
            .filter { !it.tags.contains(RC_IGNORE_OFFER_TAG) }
            .filter { !it.tags.contains(SharedConstants.RC_CUSTOMER_CENTER_TAG) }

        return findLongestFreeTrial(validOffers) ?: findLowestNonFreeOffer(validOffers) ?: basePlan
    }

このアルゴリズムでは、まず rc-ignore-offer または rc-customer-center のタグが付いたオファーを除外し、そのうえで最も長い無料トライアルを持つオファーを選択します。もし無料トライアルが存在しない場合は、最も低い導入価格のオファーが選択されます。これらの条件を満たすオファーが存在しない場合、プロモーションフェーズを持たないベースプランにフォールバックします。

このフォールバックこそが、サイレントに発生する失敗です。トライアルオファーに rc-ignore-offer のタグが付いている場合、正しいベースプランに紐づいていない場合、あるいはオファータグがまったく設定されておらずアプリ側がタグベースのフィルタリングに依存している場合、 defaultOffer はベースプランを返します。ペイウォール自体は正常に表示され、見た目も問題ありません。エラーも発生しません。しかし、トライアルは表示されていないのです。

ペイウォールが実際に何を表示しているかを確認する

他の最適化に着手する前に、まずプロダクトの defaultOffer が無料トライアル付きのオファーに解決されていることを確認してください。 SubscriptionOption インターフェースには、まさにこの確認のために freePhase プロパティが用意されています：

val freePhase: PricingPhase?
    get() = pricingPhases.dropLast(1).firstOrNull {
        it.price.amountMicros == 0L
    }

freePhase が null でない場合、そのオプションには無料トライアルのフェーズが含まれていることを意味します。同様に、introPhase は有料の導入フェーズの有無を確認します。もし defaultOffer の freePhase と introPhase の両方が null であれば、プロモーションフェーズは一切表示されません。また、 defaultOffer?.isBasePlan を直接確認することもできます。これが true の場合、SDKは有効なオファーを見つけられず、ベースプランにフォールバックしたことを意味します。いずれにしても、Play Console上のオファー設定を確認してください。

この確認は、offeringsを取得した後にコード上で行うことができます：

Purchases.sharedInstance.getOfferingsWith(
    onError = { error -> \/* handle *\/ },
    onSuccess = { offerings ->
        val currentOffering = offerings.current ?: return@getOfferingsWith
        val monthlyPackage = currentOffering.monthly ?: return@getOfferingsWith
        val subscriptionOptions = monthlyPackage.product.subscriptionOptions

        val defaultOffer = subscriptionOptions?.defaultOffer
        val hasFreeTrialOption = defaultOffer?.freePhase != null
        val hasIntroductoryOffer = defaultOffer?.introPhase != null

        Log.d("Paywall", "Default offer: ${defaultOffer?.id}")
        Log.d("Paywall", "Has free trial: $hasFreeTrialOption")
        Log.d("Paywall", "Has intro offer: $hasIntroductoryOffer")
    }
)

開発中にこれを実行し、出力結果がPlay Consoleで設定したオファー構成と一致していることを確認してください。もし hasFreeTrialOption が false で、トライアルが表示される想定だった場合、そのオファーは選択されていません。オファータグを確認し、オファーが正しいベースプランに紐づいていることを検証し、さらにそのオファーがPlay Console上で有効になっていることを確認してください。

注意すべき構造的な違い

トラッキングや実験に進む前に、AndroidとiOSの比較では完全には捉えきれない、プラットフォームレベルの違いを1つ押さえておく価値があります。

iOSでは、トライアル終了前にAppleがシステムレベルのプッシュ通知を送信し、ユーザーに有料へ移行することを知らせます。一方で、Google Playにはこれに相当するシステム通知は存在しません。つまり、iOSではトライアルから課金への重要なタイミングで、再エンゲージメントの仕組みがプラットフォーム側に組み込まれているのに対し、Androidにはそれがありません。Androidでは、このリマインドは完全にアプリ側の責任となります。アプリ内バナー、自前のバックエンドからのプッシュ通知、あるいはトライアル終了間際にユーザーが戻ってきた際に発動する再エンゲージメントフローなどで対応する必要があります。

この構造的な違いは、トライアル開始ユーザー数が大きく異なるにもかかわらず、トライアルから課金へのコンバージョン率が似て見える理由の一部を説明しています。iOSではコンバージョンのタイミングでプラットフォームによる後押しがあるのに対し、Androidでは同じ結果を得るためには明示的な実装が必要です。もしAndroidのトライアルから課金へのコンバージョン率がiOSより低い場合、その要因の一つとして、トライアル終了リマインダーがアプリ内に存在しないことが考えられます。

PresentedOfferingContextを使ったペイウォールパフォーマンスのトラッキング

オファー設定が正しく行われたら、次のステップは、どのペイウォール配置が最も多くのトライアル開始を生み出しているかを理解することです。RevenueCatの PresentedOfferingContext を使うことで、すべての購入に配置識別子を付与できるようになり、アプリ内のどの位置でペイウォールが表示されたかに基づいて分析をセグメント化できます。

PresentedOfferingContext には3つのフィールドが含まれます：

public class PresentedOfferingContext(
    public val offeringIdentifier: String,
    public val placementIdentifier: String?,
    public val targetingContext: TargetingContext?,
)

offeringIdentifier は、RevenueCatダッシュボード上のofferingを指します。 placementIdentifier は、その表示箇所に付けるために自分で定義する文字列で、たとえば"onboarding_paywall"、 "settings_upgrade"、 "feature_gate"などがあります。targetingContext には、RevenueCatのtargeting機能を使用している場合に、そのルールデータが含まれます。

購入を開始すると、このコンテキストはトランザクションとともに渡され、RevenueCatダッシュボードやWebhookイベント上に現れます。これにより、配置ごとのトライアル開始率やD35コンバージョンを比較し、どの表示箇所から優先的に最適化すべきかを判断できるようになります。

トライアル期間：見落とされがちな変数

オファーの可視性やペイウォールの種類に加えて、トライアル期間はトライアルから課金へのコンバージョンに測定可能な影響を与えます。RevenueCatのデータは明確なパターンを示しています：

より長いトライアルを提供しているアプリは、このデータセットにおいてトライアルから有料へのコンバージョンが約17ポイント高くなっています。ただし、これは相関関係であり、長いトライアルを提供するアプリは、単なる設定ではなく、意図的なプロダクト戦略として長いトライアルを採用している、生産性系やクリエイティブ系のツールである傾向があります。トライアル期間を延ばしたからといって、必ずしも17ポイントの改善が得られるわけではありません。それでもこのパターンは、価値が時間とともに積み上がるタイプのアプリにおいては、4日間のトライアルではユーザーが十分な体験を得る前に終了してしまう可能性があり、14日や30日のトライアルであればプロダクトが価値を示すための十分な時間を確保できることを示唆しています。

それにもかかわらず、このデータセットでは全トライアルの55％が4日以下となっており、前年の42％から増加しています。17日以上のトライアルを提供しているアプリはわずか5％にとどまっています。

もしあなたのトライアルから有料へのコンバージョン率が、Androidの中央値である32.5％を下回っている場合、トライアル期間はテストする価値があります。これは、新たにコードをリリースすることなく、RevenueCat Experimentsで検証できる高インパクトな変数の一つです。

RevenueCat Experimentsによる測定と改善

これまでに説明してきたすべての変数（ペイウォールの種類、タイミング、トライアル期間、オファー選択）は相互に影響し合っており、測定なしに最適解を導くのは困難です。何が効果的かは、プロダクト、ユーザー層、カテゴリによって異なります。

RevenueCat Experiments を使えば、コードのリリースやバックエンド構築を行うことなく、これらの変数に対してA/Bテストを実施できます。RevenueCatダッシュボード上で、トライアル期間、デフォルトオファー、パッケージ構成などが異なるバリアントofferingを作成します。RevenueCatはユーザーをコントロール群とバリアント群にランダムに割り当て、トライアルからコンバージョンまでの行動を追跡し、D35コンバージョン、LTV、トライアル開始率をバリアントごとに可視化します。

実験を開始した後は、CustomerInfo 内の EntitlementInfo.periodType を通じて、ユーザーごとのトライアル状態を監視することができます：

Purchases.sharedInstance.getCustomerInfoWith(
    onError = { error -> \/* handle *\/ },
    onSuccess = { customerInfo ->
        val premiumEntitlement = customerInfo.entitlements["premium"]

        when (premiumEntitlement?.periodType) {
            PeriodType.TRIAL -> {
                \/\/ User is in an active trial
                val trialEnds = premiumEntitlement.expirationDate
                showTrialExpirationReminder(trialEnds)
            }
            PeriodType.INTRO -> {
                \/\/ User is in an introductory paid phase
            }
            PeriodType.NORMAL -> {
                \/\/ User is a full subscriber
            }
            null -> {
                \/\/ No active entitlement
                showPaywall()
            }
        }
    }
)

periodType は、ユーザーのサブスクリプションが現在どのフェーズにあるかを示します。これは、トライアル状態を考慮したUIを構築する際に役立ちます。たとえば、トライアル終了が近づいた際にバナーを表示したり、サブスクリプションのフェーズに応じてメッセージを調整したり、トライアル終了後に課金へ至らなかったユーザーに対して再エンゲージメント用のペイウォールを表示したりすることが可能になります。

まとめ

Androidにおけるコンバージョンギャップは、主にファネル入口の問題であり、その原因は特定可能です。AndroidとiOSの間に見られるD35のダウンロードから課金への約3倍の差は、プラットフォームの限界を示しているわけではありません。これは、オファー設定ミス、トライアル開始を抑制するフリーミアムモデル、そして遅すぎる、あるいは表示されないペイウォールといった要因が重なった結果です。さらに、構造的な違いも影響しています。iOSはトライアル終了前にシステムレベルの通知を送りますが、Androidにはそれがないため、トライアル終了付近での再エンゲージメントはアプリ側で明示的に実装する必要があります。

このギャップを埋めるための道筋は明確な順序に従います。まず、アクティブなofferingにおける defaultOffer が freePhase を持つオプションに解決されていることを確認してください。そうでなければ、他の変更を行う前にPlay Consoleのオファー設定を修正します。次に、フリーミアムモデルを採用している場合は、ハードペイウォールのバリアントで実験を行い、トライアル開始率と12ヶ月リテンションの両方を測定します。すでにハードペイウォールを採用している場合は、より長いトライアル期間をテストします。そして最後に、PresentedOfferingContextに placementIdentifier を追加し、どの表示箇所がトライアル開始に寄与しているかを把握できるようにします。

これらの変更はすべて測定可能です。RevenueCat Experimentsは推測に頼らずテストを行うための基盤を提供し、D35やトライアルから課金への指標が意思決定のシグナルとなります。

本記事では、Androidのペイウォールコンバージョン問題が2段階ファネルのステージ1に主に存在すること、Google Playのオファーおよびタグシステムがどのサブスクリプションオプションを表示するかをどのように決定しているか、RevenueCatの SubscriptionOptions.defaultOffer アルゴリズムがどのようにトライアルを選択し、どこでサイレントな設定ミスが起こり得るのか、ペイウォールモデルやトライアル期間に関するデータが何を示しているか、トライアルリマインダーに関するプラットフォーム間の構造的な違い、そしてRevenueCatのツールを用いた診断と改善方法について解説してきました。

ギャップがどこに存在するかを理解することで、何を構築すべきかが変わります。大半の作業はステージ1にあります。つまり、ユーザーにトライアルを「見せて」「開始してもらう」ことです。トライアルを開始したAndroidユーザーは、iOSユーザーとほぼ同じ確率で課金に至ります。重要なのは、ユーザーにその開始の機会を与え、トライアル終了前に課金へ進む理由を提供することです。

昨年のレポートが大作だと思ったなら、今回は覚悟してください。今年は338ページにわたり、あらゆる指標、ベンチマーク、トレンドを網羅しています。

David Barnardの言葉を借りるなら、「多くのアプリが、莫大な金額を稼いでいる」ということです。

しかし、（驚くことに）もしあなたが（DavidやJacobのように）すべてのページを読む時間がないのであれば、この要約はあなたのためのものです。さあ、しっかりついてきてください。

1. サブスクリプションアプリの中間層は消滅した

サブスクリプションアプリにおいて、成長はもはや連続的なものではありません。二極化しています。

2026年のデータは、アプリの成長が大きく分極化していることを示しています。これまでアプリビジネスにおいて、安全で健全と考えられていた安定成長（例：前年比5〜15％）という中間領域は、現在では足元から消えつつあります。

市場のダイナミクス――ユーザー獲得コスト、アルゴリズムの変化、プラットフォーム手数料、AIのユニットエコノミクス――は、今やトップパフォーマーを強く優遇するようになっており、モバイルアプリ経済はより広い意味での富の格差を反映する構造になっています。すなわち、成功する者はさらに成功し、インディー開発者は生き残るのに苦しんでいるのです。

データ：

• 上位四分位：サブスクリプションアプリの上位25％は、月次経常収益（MRR）を前年比で80％以上成長させた
• 下位四分位：下位25％のアプリは、MRRが33％以上減少した
• 格差：急速にスケールする勝者と、収益を失っているアプリの間に、113ポイントという巨大な差が生まれている
• 2025年との比較：昨年のデータでは、上位5％と下位25％の間の収益格差が拡大しており（上位は2024年の200倍から400倍へ増加）、2026年のデータはこのトレンドを確認するとともに、成長率の観点から初めて定量化している

What next?

アプリチームはもはや「そこそこ良い」で満足することはできません。守りの余地はありません。もし中央値（5〜17％）の成長にとどまっている場合、下位四分位に落ち込み、埋もれてしまうリスクがあります。チームは維持モードから、積極的な成長最適化へとシフトする必要があります。

→ 次のステップ：アプリ成長のフレームワークである「Subscription Value Loop」について学びましょう

2. ハードペイウォールはフリーミアムより5倍高いコンバージョン

「ハードペイウォールはユーザー体験を損なう」という言説は、誰もが一度は耳にしたことがあるでしょう。しかし、その神話は覆されました。カテゴリ全体で見ると、35日後のトライアルから有料へのコンバージョンは、ハードペイウォールを採用しているアプリの方が5倍高くなっています。一般的な認識とは異なり、ハードペイウォールはユーザーを遠ざけたり、準備ができていない段階で購入を強制したりするものではありません。このような見方は、サブスクリプションに慣れたユーザーを過小評価しているに過ぎません。ユーザーは自分の意思で課金するタイミングを判断しています。現在では、ユーザーはハードペイウォールと積極的に向き合っており、その結果、アプリはより早く投資回収ができるようになっています。

「この選択（ハードペイウォール vs フリーミアム）はユニットエコノミクスを完全に変えます。同じ広告費でも、初日の収益は劇的に変わります。」— モバイルグロースコンサルタント Sven Jürgens

ペイウォールのタイプはコンバージョンに影響を与える一方で、長期的なリテンションはどちらのモデルでもほぼ同等になります。フリーミアムアプリは6週目以降も継続的にコンバージョンしており、最終的なコンバージョンの全体像は、想像よりも長期的なゲームであることを意味しています。

つまり、フリーミアムだからといって成功しないわけではなく、それを証明する成功事例も数多く存在します。しかしデータは明確に、ハードペイウォールの方がより高く、そしてより速くコンバージョンすることを示しています。2026年において、フリーミアムは安全な選択に見えるかもしれませんが、必ずしも最適な選択とは限りません。

データ：

• コンバージョン：ハードペイウォールは35日時点のトライアルから有料へのコンバージョン率の中央値が10.7％であるのに対し、フリーミアムアプリはわずか2.1％にとどまり、約5倍の差がある
• リテンション：フリーミアムアプリは1年後に年間サブスクライバーの28％を維持している一方、ハードペイウォールアプリは27％であり、この差は統計的にほぼ無視できるレベル
• インストールあたり収益：ハードペイウォールアプリは、60日目時点のRPIがフリーミアムの8倍（3.09ドル vs 0.38ドル）
• 2025年との比較：フリーミアムの35日後のコンバージョンは2025年から2.1％で変わっていない一方で、ハードペイウォールは約2％低下（2025年は12.1％）しており、全体的にコンバージョンへの慎重さが高まっていることを示唆している

次にやるべきことは？

ハードペイウォールに切り替えましょう（もし挑戦する勇気があるなら 😈）。ハードペイウォールは初期段階でROIを生み出し、その資金を成長に再投資することができます。フリーミアムモデルでユーザーとの信頼関係を築こうとしている場合、1年後にわずか1％のリテンション向上を得るために、ファネル上流の大きな収益機会を犠牲にしていることになります。この競争の激しい市場においては、リスクの高い選択です。

→ 次のステップ：優れたサブスクアプリがペイウォールで何を正しく行っているのかを理解しましょう

3. ゼロ日目の「購入直後の後悔」ウィンドウ

ここで意外な事実です：あなたの3日間トライアルは、実際には「1時間トライアル」です。そう、トライアル解約の55％はゼロ日目に発生しています。つまり、開発者が3日間の体験を設計している一方で、現代のユーザーは即座に価値が証明されることを求めているのです。

チームはもはや、ユーザーが数日かけてアプリの機能をじっくり試してから判断するとは考えられません。実際には、ユーザーはアプリのトライアルを衝動的な買い物のように扱っています。ペイウォールを通過するために登録し、すぐにコア機能を体験して評価し、その後、課金を避けるために解約します。最初の60分で「アハ体験」を提供できなければ、その時点でユーザーはすでに離脱しているのです。

データ：

• ゼロ日目の解約：3日間トライアルにおけるすべての解約のうち、正確に55.4％がゼロ日目に発生している
• 離脱の集中：3日間トライアルの解約の実に84％が、ゼロ日目から1日目の間に発生している
• 2025年との比較：昨年は約51％の解約がゼロ日目に発生しており（今年は約4％増加）、ユーザーの「即座に解約する」傾向がさらに強まっていることを示している

次にやるべきことは？

オンボーディングフローを、最も重要なリテンション施策として扱いましょう。ユーザーが最初のセッションで「aha体験」に到達しなければ、すぐに自動更新をオフにしてしまいます。トライアル期間を見直してください――本当に3日間である必要がありますか？（これについては次で詳しく説明します。）トライアル中に解放する機能についても考えましょう。即座に価値を示すものは何か、逆に余計なものは何かを見極めることが重要です。価値を最短で証明するルートを特定し、それを設計してください。

→ 次のステップ：グロースハックを追い求めるのをやめ、まずオンボーディングの改善方法を学びましょう

4. 7日間トライアルはまだ健在（場合によっては）

サブスクリプションアプリ業界は短いトライアルに強く偏っていますが、実際のデータは何を示しているのでしょうか？7日間トライアルは本当に終わったのでしょうか？

結論から言うと、そうではありません。

17〜32日のトライアルは、3日間トライアルと比べて70％高いコンバージョンを示しています（42.5％ vs 25.5％）。それにもかかわらず、46％のアプリが4日以下のトライアルへと移行しています。なぜでしょうか？グロースチームは、市場や経済的なプレッシャーの中で、短期間で収益を示すことを求められているからです。

「多くの開発者が3日間の無料トライアルを採用しているのはキャッシュフローのためです。30日後ではなく、3日で収益が欲しいからです。[あるいは] オンボーディングやペイウォールの実験を加速するために、コンバージョンデータをより早く取得したいという理由もあります。」 — David Barnard と Jacob Eiting（Sub Clubより）

短いトライアルはユーザーに迅速な意思決定を迫り、その結果として高い離脱率を招くことが多くあります（3日トライアルのゼロ日目解約率と長期トライアルの比較を参照）。一方で、長いトライアルはユーザーがアプリを日常習慣に組み込む時間を与え、誤って自動更新されることへの不安も軽減します。3日間トライアルはアプリチームにとって有用ではありますが、実際には短期的なダッシュボード上の成果（ドーパミン的な数値の上昇）のために、長期的なコンバージョンを犠牲にしているのです。

データ：

• 長期トライアルのコンバージョン：17〜32日のトライアルは、中央値で42.5％という非常に高いコンバージョン率を示している
• 短期トライアルのコンバージョン：4日未満のトライアルは25.5％にとどまり、長期トライアルの方が約70％高いコンバージョンとなっている
• 2025年との比較：昨年はトライアル期間が長期化する傾向にあったが、現在ではデータに反して、4日未満のトライアルの割合が2025年の42.1％から2026年には46.5％へと増加している

次にやるべきことは？

自分のカテゴリにおけるトライアルとリテンションのデータを深く分析しましょう。周囲の動向は参考にしつつも、それに縛られる必要はありません。トライアル期間を長くする実験を行い、コンバージョンやリテンションがどのように変化するかを確認してみてください。価値は最初にしっかり提示し、その上でユーザーに十分に体験する時間を与えることが重要です。

→ 次のステップ：あなたのアプリにとって最適なトライアル期間を見極めましょう

5. 年額サブスクリプションは思っているほど確実ではない

ユーザーが年額サブスクリプションを購入すると、開発者にとってはひと安心した気持ちになります。年額契約であれば、アプリの価値を証明するための12ヶ月があると考えるからです。丁寧に設計された各機能を示し、「来年もこのアプリを使い続けるべきだ」とユーザーに納得してもらうための12ヶ月がある、と思えるのです。

しかし、データは厳しい現実を示しています。ユーザーの3分の1以上が、最初の1ヶ月以内に自動更新をオフにしています。ユーザーは賢く、年額サブスクリプションを継続的な支払いとは捉えていません。今年分の一括支払いと考え、すぐに支出を守る行動を取ります。つまり、すでに見込んでいたYear 2の収益は、Year 1が本格的に始まる前に失われてしまうのです。

データ：

• 1ヶ月の解約：最初の1ヶ月だけで、年間サブスクリプションの解約全体の35％を占めている
• 解約の推移：1ヶ月目の急増後は、年間の中盤では解約率が3〜10％まで低下し、その後12ヶ月目（更新前）に再び増加する
• 2025年との比較：2025年には年間サブスクライバーの約56％が1年以内に解約していたが、2026年には約72％へと悪化している。ただし、1ヶ月目の解約スパイク自体は両年でほぼ同程度である

次にやるべきことは？

アプリチームは、ユーザーが年額サブスクリプションを「忘れてくれる」ことに頼ることはもはやできません。2年目をめぐる戦いは、1週目から始まっています。年間更新を勝ち取るための時間は11ヶ月もあるわけではなく、最初から自動更新をオフにしないようユーザーを事前に納得させる必要があります。そのためには、ダウンロード直後から価値を徹底的に強化して伝え、最初の2ヶ月間にわたってウィンバックキャンペーンを実施し、ユーザーが自動更新を再びオンにするよう促すことが重要です。ユーザーが最も関与している初期段階で働きかける必要があります。

→ 次のステップ：年額サブスクリプションのメリットとデメリットを理解し、その上で 年額プランの採用率を高める方法を学びましょう

6. Google Playの“見えない税金”

Android開発者にとって、成長は実はエンジニアリングの問題でもあります。Google Playにおける解約の31％は、意図しない決済エラーによるものであり、App Store（14％）の2倍以上に達しています。

アプリがサブスクライバーを失うと、その原因は通常、プロダクトの機能や価格設定にあると考えられがちです。しかしAndroidアプリの場合、解約の約3分の1はユーザーがアプリを嫌ったからではありません。単にクレジットカードの失敗、有効期限切れ、または決済拒否が原因であり、アプリ側の課金インフラがそれを適切に回復できなかっただけなのです。

これは取りこぼされている収益です。成長は広告だけの問題ではありません。Google Playのエコシステムにおける技術的な“漏れ”を、より良いリトライロジックやグレース期間によって補うことが重要なのです。

データ：

• Google Playの決済エラー：Google Playにおけるサブスクリプション解約のうち、実に31％が決済エラーによるもの
• App Storeとの比較：App Storeでは、決済エラーが占める割合はわずか14％
• 2025年との比較：Google Playの決済エラーは2025年の28.2％から今年は31％へと悪化している。一方でApp Storeは改善しており、決済エラーは1.1％減少（2025年は15.1％、2026年は14％）している

次にやるべきことは？

Androidユーザーが一定数いる場合、最もROIの高い施策は、督促（dunning）プロセス（決済リトライ）の最適化とグレース期間の有効化です。これを適切に実施すれば、新たにユーザーを獲得することなく、失われた収益の15〜20％をほぼ即座に回収することができます。

→ 次のステップ：離脱したサブスクライバー向けのウィンバックキャンペーンを設定しましょう

7. AIのパラドックス：獲得は強いが、リテンションは悪夢

AIは驚くほど売れますが、定着しません。AI搭載アプリはユーザーあたりの収益が41％高い一方で、非AIアプリと比べて36％も速く解約されます。問題はユーザーにAIアプリをダウンロードさせることではありません（実際、ユーザーはAIに対してお金を払う意思があります）。課題は、彼らを継続的に利用させ続けることです。

vibe codingの盛り上がりの中で、新しいアプリが市場を埋め尽くしていくのを既存の開発者が見守る状況においても、データはAIアプリが長期的な勝負にまだ適していないことを示しています。AI機能はトライアル収益を大きく押し上げていますが、多くのAIアプリはプロダクトマーケットフィットの深刻な不足に直面しています。ユーザーはAIツールを試すためにプレミアム価格を支払うことには前向きですが、実際に使い始めると、その価格に見合う長期的な価値を見出せていません。

確かに、vibe codingによってアプリは素早くリリースできます。AI機能はファネル上流で強力な集客要因になります。しかし、それが下流でも同じユーザーを維持できることを意味するわけではありません。ユーザーベースを持続できる保証にもなりません。

経験豊富な開発者には依然として優位性があります。それは「持久力」です。彼らはアプリを継続的に改善し、ユーザーとの信頼関係を築き、収益を成長させる方法を知っています。これこそが、成功するアプリとそうでないアプリを分ける本当の差です。誰が最も速くアプリを作れるか、どんなAI機能を持っているか、人間が書いたコードかエージェントが書いたコードか、といったことではありません。

データ：

• AIプレミアム：AIアプリは非AIアプリと比較して、1年目の実現LTVが41％高い（中央値：30.16ドル vs 21.37ドル）
• 解約の問題：高い収益にもかかわらず、AIの月額プランは12ヶ月間のリテンションが従来のアプリより36％低い
• 2025年との比較：AIアプリの12ヶ月後の課金ユーザーリテンションは、App Storeで9.2％、Google Playで11.5％と、それぞれのカテゴリにおける従来アプリと同程度だった。しかし2026年ではリテンションが大きく低下しており、AIアプリが主流化し、ユーザーがより長い期間で評価するようになった後に顕在化した問題であることを示唆している

次にやるべきことは？

速くリリースすることや、AIの話題性に頼るだけでは不十分です。アプリにAIを組み込むのであれば、その収益増加を活用して、本当に価値のあるユーザー体験と堅牢なバックエンドを構築しましょう。新規性や一発ネタのようなAI機能に依存してはいけません。それらは数ヶ月で解約されてしまうだけです。既存の成功しているアプリからリテンションや成長の学びを得て、それをAIによって迅速に実現することが重要です。長期的に勝つのは、AIか非AIかではなく、AIと人間の専門性をどれだけうまく活用できるかにかかっています。

→ 次のステップ：ユーザーに提供しているコアバリューを見直し、プロダクトマーケットフィットを確立しましょう

2027年に向けて

2026年の「State of Subscription Apps」レポートのデータは、アプリ業界における新たな変化を浮き彫りにしています。毎月14,000以上の新しいアプリが登場していることや、平均的なアプリの収益の安全圏が急速に崩れていることなどがその例です。とはいえ、これらのトレンドの多くはまったく予想外というわけではありません。Googleの課金に関する問題は数年前から顕在化しており、トライアル期間とコンバージョンの関係も新しい話ではありません。しかし2026年のデータが明確に示しているのは、アプリ開発者はこうした蓄積された変化や既知の課題を、もはや無視できないということです。

「そこそこ良い」では、もはや十分ではありません。トップアプリが急速に収益を伸ばしている一方で、下位四分位のアプリは同じスピードで収益を失っています。ユーザー価値を中心に設計され、明確な意図を持ってマーケティングされているサブスクリプションアプリは、すでにエコシステム内での地位を確立しています。そしてその成功は時間とともに積み重なっていきます。一方で、その他のアプリは残されたわずかな機会を奪い合う状況に置かれています。あとは、2027年のレポートに向けて、自分たちがどちら側に立つのかをチームが決断するだけです。

「State of Subscription Apps 2026」が示すように、データは長いトライアルの方が有利であるにもかかわらず、トライアル期間は3日程度へと短縮される傾向が強まっています。実際、17日以上のトライアルは70％高いコンバージョン（42.5％ vs 25.5％）を示しています。

この大きな差があるにもかかわらず、現在ではほぼ半数のアプリが4日以下のトライアルを採用しています。これは、より早い収益回収と短いペイバック期間を求める動きによるものであり、UAの観点から見て収益性を改善するための選択です。

これは偶然ではありません。AIは市場全体を大きく変えました。AI技術の利用には変動的かつ上昇するコストが伴うため、開発者やパブリッシャーはできるだけ短期間で高いARPU（ユーザーあたり平均収益）を実現する必要に迫られています。そうでなければコストを回収できず、ビジネスの持続が困難になります。その結果、アプリ自体がマーケティング不可能となり、プロダクトマーケットフィット（PMF）の達成もこれまで以上に難しくなっています。

さらに、Web-to-Appキャンペーンがシグナル設計において重要な役割を果たしている現状を考えると、「無料トライアルはもはやあまり意味をなさない」と結論づけることもできます。では、それは本当に正しいのでしょうか？私はその見方には一定の真実があると思います。ただし、それは無料トライアルが完全に終わったという意味ではありません。より高度な形に進化した「トライアル的なコンバージョンイベント」を活用する余地はまだあります。

その具体像に入る前に、まずはなぜ無料トライアルがこれほどサブスクリプションアプリで普及したのか、その背景を見ていきましょう。

無料トライアル：購入に最も近いプロキシイベント

タイトルの通り、無料トライアルは多くの企業のUA戦略の基盤となってきました。その理由はシンプルで、無料トライアルは「購入に最も近いイベント」だからです。さらに、このイベントはユーザーの購買意欲をフィルタリングしつつ、広告ネットワークが効率的に最適化するために必要なボリュームも確保できます。

AIが存在せず、アプリの選択肢も限られていた時代には、無料トライアルはユーザーに課金を促す有効な手段でした。パブリッシャーはプロダクトやUXの力に大きく依存し、トライアルからのコンバージョンを実現していました。しかし、現在は状況が変わっています。今では、サブスクリプションへ直接誘導するハードペイウォールが増えており、データによるとフリーミアムアプリと比べて初期収益がほぼ2倍に達するケースもあります。

この無料トライアルからのシフトは、2024年と2026年のレポートを比較すると明確に表れています。すべてのカテゴリにおいて、トライアルを提供しない戦略が14％増加しており（2024年は28％、2026年は32％）、無料トライアルを使わない選択が広がっています。

このような急速な変化の中で、パブリッシャーは新しい現実に適応する必要があります。ChatGPTが月額20ドルの支払いを一般化したことで、ユーザーの支払いに対する心理も変化しました。そして、その変化に対応する最も短い道が「価格設計の見直し」であり、それがトライアル戦略全体の変化につながっています。

Webキャンペーン：無料トライアル消滅を後押しする要因

この話題はもはや新しいものではありません。WebおよびWeb-to-Appファネルは、いくつかの理由から大手パブリッシャーにとって標準的な手法となっています。

• GoogleやAppleの手数料（約30％）を回避できる
• オンボーディングや価格設定のA/Bテストをより柔軟かつ高速に実施できる
• SKANなどの制約に依存せず、より正確なアトリビューションが可能
• ユーザーの購買意欲が高い
• 購買意欲をより細かくコントロールできる新たな広告在庫にアクセスできる
• iOSユーザーに対するリターゲティングが可能

一方で、現時点では手数料が15％以下の小規模パブリッシャーにとって、Webオンボーディングは必ずしも最適とは言えません。税務対応やStripeなどの決済手数料（約3％）、返金対応、オンボーディング構築のためのツール管理など、追加の複雑さが発生するためです。しかし、大手プレイヤーの戦略変化は市場全体に影響を与えており、現在では小規模な開発者もこれらの手法を模倣し始めています。

このような状況を踏まえると、もはや「無料トライアルから離れるべきかどうか」ではなく、「何に置き換えるべきか、そしていつ置き換えるべきか」が重要な問いとなっています。市場は大きく二つに分かれています。

1. 強いPMFとバイラリティを持つアプリ向けの、直接サブスクリプションへ誘導するハードペイウォール
2. 広告ネットワークに必要なボリュームを維持しつつ、シグナルの質を大幅に向上させる、より高度なトライアル手法

後者こそ、私が取り組んでいるアプローチであり、今後のシグナル設計の標準になると考えています。

App Growth Annual 2025では、有料トライアル（イントロオファー）がアクティベーション指標やUAパフォーマンスに与える即時的な影響について解説しました。現在では、この戦略をWebキャンペーンに取り入れる企業が増えています。というのも、Webキャンペーンはアプリキャンペーンよりも購買意欲の高いユーザーをターゲットしやすいからです。A

トライアルクオリファイアと有料トライアルは排他的ではない

イントロオファーに関する記事でも述べた通り、有料トライアルをアプリやWebキャンペーンに導入することで、指標は大きく変わります。ただし、有料トライアル後のコンバージョン率をしっかり監視する必要があります。この戦略は、直接サブスクリプションへ誘導するハードペイウォールと比べると、短期的なLTVを損なう傾向があるためです。

「State of Subscription Apps」レポートによると、新規サブスクライバーの約30％がイントロオファー経由で獲得されています（中央値）。

例えば「最初の1ヶ月を0.99ドルで提供する」モデルは、単にコンバージョンを改善するだけではありません。アルゴリズムに送るシグナルの質そのものを変えます。「無料ボタンをクリックしたユーザー」ではなく、「実際にクレジットカードを入力したユーザー」で学習させることになり、これはまったく異なる行動特性です。適切なクリエイティブ戦略と組み合わせてこれらのユーザーをターゲットできれば、大きなゲームチェンジャーになります。

このアプローチは、Webやweb-to-appキャンペーンで特に普及し始めました。なぜなら、上流ファネルの段階で購買意欲をフィルタリングできるチャネルを使えるためです。これは、現在主流となっている自動化されたアプリキャンペーンとは大きく異なります。

例えばGoogle Adsの検索キャンペーンでは、オーディエンスごとに広告グループを分け、キーワードによって購買意欲のレベルを調整できます。「free」を含むキーワードと含まないキーワードを使い分けることで、トライアルクオリファイアイベントへの影響を比較する戦略が有効です。

このような高度なターゲティングと有料トライアルを組み合わせることで、day 0から「実際に支払うユーザー」という強いシグナルをアルゴリズムに与えることができ、多くのパブリッシャーにとって非常に効果的な手法となっています。従来のトライアルのようなプロキシイベント（中央値30〜35％）ではなく、より直接的なシグナルを活用できるからです（出典：SOSA）。

ただし、私の見解では、これが将来の標準になるわけではありません。今後はトライアルクオリファイアがこの役割を担うようになるでしょう。そして重要なのは、この2つはどちらか一方を選ぶ必要はないという点です。Webキャンペーンではユーザーの意図をよりコントロールできるため有料トライアルを活用しつつ、アプリキャンペーンではトライアルクオリファイアを使う、といった併用が可能です。

「State of Subscription Apps 2026」を見ると、ほぼすべてのカテゴリでトライアル開始はday 0に集中しています。オンボーディング中にすぐ試さないユーザーは、その後も試さない傾向があります。

このデータから導かれる結論は明確です。現在、広告主にとって最も有効な手法はトライアルクオリファイアイベントです。その理由は以下の通りです。

• クレジットカード入力を強制せずに、day 0でアルゴリズムにシグナルを送れる
• 購入直前のイベントを最適化対象にでき、従来のトライアルよりも高い意図を持つユーザーを捉えられる
• そして最も重要なのは、ユーザーの購買行動データに基づいて、送信するシグナルを自由に設計・調整できることです

では、この仕組みをどのように自社のキャンペーンに実装していくべきでしょうか？

新しい無料トライアル：高度なトライアル設計の方法

トライアルクオリファイアイベントのパーソナライズは、アプリのカテゴリ、ペイウォールで提供しているサブスクリプションプラン、そして従来のトライアル開始イベントから分析できるユーザーの行動データに大きく依存します。ただし、初期設定としては、以下の条件をもとにトライアルクオリファイアイベントを設計することができます。

1. 無料トライアルをキャンセルせずに継続した時間

トライアルのキャンセルの多くは、開始から最初の2時間以内に発生しています。データでも、キャンセルはday 0が最も多く、次いでday 1に集中しています。

これらのユーザーは、単にペイウォールの中身を確認したいだけで、実際に課金する可能性はほとんどありません。しかし、こうしたユーザーは広告ネットワークに送るシグナルを汚染し、全体のパフォーマンスを悪化させます。そのため、まずはこの層をフィルタリングすることが重要です。自社の過去データを分析し、どの時間基準が最適かを見極めましょう。

2. 無料トライアルをキャンセルせずに継続した時間＋エンゲージメント

プロダクトによっては、積極的に利用するユーザーと、登録後に放置するユーザーとで、LTVやリテンション、回収期間に大きな差が生じます。そのため、トライアルクオリファイアを設計する際には、「キャンセルせずに継続した時間」に加えて、初回セッションでのエンゲージメントシグナルを組み合わせるのが有効です。これにより、広告ネットワークに送るシグナルの質が向上し、より最適化しやすくなります。

ただし注意点として、初回セッションのエンゲージメント条件を厳しくしすぎると、シグナルの量が減りすぎてしまい、キャンペーンの最適化が難しくなる可能性があります。

3. 無料トライアルをキャンセルせずに継続した時間＋追加シグナルの送信

これは1つ目の手法に近いですが、ユーザーごとに2つのシグナルを送る点でより高度です。具体的には、トライアル開始から2時間後に最初のシグナルを送信し、その後トライアル終了前日にもう1つのシグナルを送ります。例えば3日間のトライアルであれば、開始2時間後に1回、そしてday 2時点でトライアルが継続されていればもう1回シグナルを送ります。これによりイベント数が増え、広告ネットワークの最適化がしやすくなります。一方で、実際のトライアルコンバージョン率やインクリメンタリティの測定は複雑になります。

4. トライアルクオリファイアのマッピングを自動化する

さらに一歩進めたい場合は、RevenueCatとAppstackの新しい連携を活用することで、トライアルクオリファイアイベントのマッピングを数クリックで自動化できます。この連携により、キャンペーンユーザーをRevenueCatで作成した特定のペイウォールに誘導でき、広告視聴からアプリ内オンボーディング完了までの体験を完全にカスタマイズできます。これは市場でも非常にユニークな機能であり、購買意欲の高いユーザーに対してテストを行える点で、ペイウォール設計と検証の方法を大きく変える可能性があります。

最終的には、これらのアプローチをベースにトライアルクオリファイアイベントを試し、従来の無料トライアルキャンペーンとパフォーマンスを比較することをおすすめします。最適なパターンが見つかったら、シグナルの質と量のバランスを取りながら継続的に改善していきましょう。

無料トライアルを見直す準備はできていますか？

この記事は少し大げさに聞こえるかもしれませんし、従来の無料トライアルの方が良い成果を出すケースももちろん存在します。しかし、さまざまなアプリに日々関わる中で感じるのは、私たちが急速に「即時的な成果」を求める方向へと移行しているということです（AIに伴う限界費用の上昇がその背景にあります）。そのため、近い将来、多くのアプリがこのような形で無料トライアルのシグナルを洗練させていくと考えています。これにより、広告配信の精度が向上し、最終的にはユーザー獲得に投じる1ドルあたりの効率を最大化できるようになるでしょう。

それはYNABという家計管理アプリでした。最初は完全にランダムに思えました。多くの無料トライアルは5〜9日程度なので、なぜ34日なのかと疑問に感じたのです。

しかしアプリを開いたとき、その理由はすぐに理解できました。

家計管理はすぐに価値が出るものではなく、1つのサイクルが必要です。

• 給料日
• 支払いの発生
• 時間を通じた実際の行動

YNABは1週間で印象づけようとしていたのではありません。実際にプロダクトを体験できるだけの時間を提供していたのです。

この体験はとても印象に残りました。そしてこう考えるようになりました。「業界全体として、7日間トライアルをデフォルトにしていることで、自分たちの可能性を過小評価しているのではないか？」と。

2024年には、すべてのトライアルのうち半数以上が5〜9日の範囲にあり、2023年から増加しました。さらに2025年にはトライアルはより短くなり、4日以下のトライアルがシェアを伸ばし、全体のほぼ半分（46.5％）に達しています。

「7日間トライアルは終わった」という一般論を耳にしたことがあるかもしれませんが、実際にはトライアルが短くなり続けていることがその背景にあります。これから詳しく見ていく通り多くの要素があるにもかかわらず、業界のデフォルトはむしろ固定化されつつあります。

そしてそれこそが問題です。7日間トライアル自体が悪いわけではありません。ただ、それがほとんど疑われていないのです。トライアル期間は、オンボーディングやアクティベーション、リテンションと同じくらい真剣に検討されるべきです。

なぜなら最終的に、トライアル期間は価格の問題ではなく、プロダクトの問題だからです。

Apertureの創業者であるHannah Parvaz氏はこう述べています。

「私は“トライアル期間はデフォルトではなく設計の意思決定である”という立場です。複数のサブスクリプションアプリを見てきた中で最大のミスは、トライアル期間を単独のグロースレバーとして扱い、Time-to-Valueや信頼構築と結びつけていないことです。」

この「トライアル期間はプロダクトの意思決定である」という考え方が、私をいつもの“Daphne的な思考の深掘り”へと導きました。では実際に、適切な無料トライアル期間は何によって決まるのでしょうか？

トライアル期間の前に：そもそもトライアルは必要か？

異なるトライアル期間について考える前に、まず答えるべきもっと重要な問いがあります。

そもそも、トライアルは本当に必要なのでしょうか？

トライアル自体が適切な戦略でなければ、トライアル期間を最適化することに意味はありません。

以前の私は、トライアルは必須だと考えていました。実際、「State of Subscription Apps 2026」によると、ほとんどのカテゴリのアプリが何らかの形でトライアルを提供しています。

どのカテゴリにおいても、トライアルを提供していないアプリが多数派になることはありません。最もトライアル非提供の割合が高いのはソーシャルカテゴリで、それでも43.6％にとどまっています。

そんな中で、David Vargas氏の記事を読んだことで、トライアルに対する考え方が大きく変わりました。彼はこう説明しています。

「無料トライアルはあくまで数ある戦略の一つに過ぎない。重要なのは、プロダクトや機能がどれだけ“粘着性（stickiness）”を持ち、ユーザーをサブスクへと納得させられるかだ。」

特に印象的だったのは、彼が無料トライアルを完全に廃止した実験です。

大胆で（私の大好きなタイプの実験です）、少し恐ろしくもありました。しかし重要なのはその背景です。彼らはトライアルから有料へのコンバージョン自体は高かったものの、有料獲得がうまくいっていませんでした。なぜなら、1人の有料ユーザーを獲得するために必要なトライアル開始数を考慮すると、獲得単価が高すぎたからです。

トライアルを廃止したことで、LTVはほぼ2倍になり、有料成長が可能になりました。

これは、たとえトライアルを継続する場合でも重要な示唆です。トライアルが非常に短くない限り、広告最適化は「購入」ではなく「トライアル開始」に向かいがちです。そしてコンバージョンがアトリビューション期間外で発生すると、広告プラットフォームは「トライアルを開始する人」には最適化されても、「実際に課金する人」には最適化されません。

ここから導かれる第一原則はシンプルです。

トライアルが本当に必要かどうかを明確にするまでは、トライアル期間には手をつけないこと。

トライアルの廃止をテストするのは怖く感じるかもしれません。しかし、トライアルが十分な価値を生んでいないのであれば、その前提自体を疑う価値があります。または、まずトライアルの中で実際の価値提供を強化することに注力すべきです。Subscription Indexの創業者（元Codecademy、Uber）であるDan Layfield氏はこう述べています。

「トライアルは、ユーザーにとって分かりやすく、明確で、魅力的である限り、あなたの味方だ。」

トライアルの必要性に確信が持てたら、次はトライアルに関するよくある誤解を解いていきましょう。

神話：短いトライアルの方がコンバージョンが高い

直感的にはこう考えがちです。トライアルが短いほど緊急性が生まれ、緊急性が行動を促し、その行動がコンバージョンにつながる。シンプルですよね。

これは「24時間限定セール」や「残りわずか」といった訴求と同じ発想です。強力に行動を促す手法です。

もちろん、短いトライアルが有効なケースもあります。特に、有料キャンペーンを購入ベースで素早く最適化したい場合には効果を発揮します。しかし、データを見ると話はもっと複雑です。

RevenueCatの「State of Subscription Apps」レポートによると、短いトライアルでは初日〜翌日にかけての解約が大きく増加します。例えば3日間のトライアルでは、55％以上のユーザーがほぼ即座に解約します。一方、30日間トライアルではその割合は約31％にとどまります。

この初期解約は、必ずしもユーザーの意欲が低いことを意味するわけではありません。多くの場合、次のような心理が影響しています。

• 信頼の欠如
• 解約を忘れることへの不安
• そしてよくある「念のため今のうちに解約しておこう」という行動

興味深いのは、トライアルが長くなるほど解約率が下がる点です。3日間トライアルでは解約の84％、7日間トライアルでも64％が初日〜翌日に集中しています。リスクは後半ではなく、最初に集中しているのです。

つまり、短ければ良いというわけではありません。ただし、ここでさらにややこしいことを言うと、長ければ良いというわけでもないのです。

長いトライアル：効果がある場合と逆効果になる場合

ここまでの話を聞くと、多くの人はすぐに「じゃあ長い方が良いのでは？」と考えがちです。

しかし、集計データをそのまま鵜呑みにするのは、7日間トライアルをデフォルトにするのと同じくらい危険です。

確かに、17〜32日のトライアルは平均的にトライアルから有料へのコンバージョン率が高い傾向にあります（中央値で42.5％、4日未満のトライアルでは25.5％）。

一見すると素晴らしい結果ですが、私たちはしばしば「トライアル→有料のコンバージョン率＝良い結果」と考えてしまいがちで、ここに落とし穴があります。

例えば、私が関わったウェルネスアプリでは、主要なアクティベーション指標は「14日以内に長尺コンテンツを2本消費すること」でした。各コンテンツは約45分で、週次のライブセッションと関連していました（ただしそれだけではありません）。この行動は長期的なリテンションの強い指標でした。

そこで当然の疑問が生まれます。「アクティベーションに14日必要なのに、なぜ7日間トライアルなのか？」

そこで実験を行いました。7日間と14日間のトライアルでA/Bテストを実施したのです。結果として、長いトライアルの方がトライアル開始数はわずかに増えましたが、最終的なコンバージョンはむしろ減少しました。

理由は、不正利用や時間不足ではありません。アクティベーション自体が改善しなかったのです。ユーザーはコンテンツを多く消費するようにはならず、単に後回しにしただけでした。典型的な先延ばしです。結果として有料への転換率は悪化し、最終的に7日間トライアルへ戻しました。

これが、私たちが誰もが経験したことのある「長いトライアルの落とし穴」です。長いジムの無料体験は後回しにしやすいですが、「7日以内に予約が必要な有料の体験レッスン」は行動を促します。「後でやろう」は静かに「結局やらなかった」へと変わります。

ここからの重要なポイントは、トライアルのコンバージョンはあくまで先行指標に過ぎないということです。本当に重要なのは次の3つです。

• ユーザーあたりの長期的な収益
• リテンション
• 継続的なエンゲージメント

さらに、Hema Yoganarasimhan氏、Ebrahim Barzegary氏、Abhishek Pani氏によるSaaS研究では、短いトライアル（7日間）の方が、30日トライアルよりも獲得、リテンション、収益性の面で優れるケースがあることも示されています。

ただし、7日目に課金して8日目に解約するユーザーは成功とは言えません。

ここまでで少し混乱しているかもしれませんが、それも無理はありません（両極端を否定しましたからね）。しかし安心してください。答えはあります。それは「トライアル期間は文脈の中でのみ意味を持つ」ということです。

ApertureのHannah Parvazは、複数のチームを通じていくつかの共通パターンを見出しています。

• 「コア価値が1回のセッションで体験できる場合、長いトライアルは有料コンバージョンを下げることが多いです。この場合、短いトライアル（あるいはトライアルなし＋強い安心感の提供）の方が優れます。ユーザーはすぐに価値を理解するか、まったく理解しないかのどちらかだからです。
• 価値が時間とともに積み上がるプロダクト（習慣、学習、行動変容など）の場合は、長いトライアルが有効になることがあります。ただし、オンボーディングが積極的に“アハ体験”へ導く設計になっていることが前提であり、単に待つだけではうまくいきません。
• 7日間はデフォルトとして最適であることはほとんどありません。即時価値型のプロダクトには長すぎ、信頼構築が必要なプロダクトには短すぎることが多いです。実際には、ユーザーが意味のあるマイルストーンに到達する速度に応じて、3日から30日までさまざまな期間でより良い結果が出ています。」

この「文脈」をより深く理解するために、さらに詳しく見ていきましょう。そのうえで、あなたのアプリにとって最適なトライアル期間を決めるためのフレームワークを紹介します。

トライアル期間において価格は重要

トライアル期間について議論する際に見落とされがちなのが、価格やプラン設計との強い関係です。

例えば、月額5ドルのプラン前に設定された14日間トライアルと、年額120ドルのプラン前に設定された14日間トライアルでは、ユーザーの感じ方は大きく異なります。前者はリスクが低い一方で、後者は心理的ハードルが高く、ユーザーはより多くの証拠や安心感、あるいは単純により長い検討時間を必要とします。

そのため、年額プランに長めのトライアルが付いていたり、年額プランにのみトライアルが提供されているケースが多く見られます。これは単なる「太っ腹」ではなく、ユーザーが感じるリスクを下げるための設計です。価格が高い、または契約期間が長いほど、より長いトライアルが必要になる可能性があります。

実際に、年額プランに14日間の無料トライアル、月額プランに7日間のトライアルを提供することで、Headspaceはコンバージョンの大幅な向上を実現しました。これにより、ユーザーは長期プランへのコミットに対して安心感を持ちやすくなり、年額プランの魅力も高まったと考えられます。

さらに、サブスクリプション期間が短い場合、トライアルの追加は過剰になることもあり、かえってアプリの価値を下げてしまう可能性もあります。例えば週額プランは、それ自体が一種のトライアルの役割を果たすため、さらに無料トライアルを付ける必要はないかもしれません。実際、週額プランにトライアルを付ける場合でも、1週間まるごと無料にすると価値を下げてしまうため、3日間程度にとどめるケースが多く見られます。

カテゴリは想像以上に重要

「最適なトライアル期間」という万能の正解は存在しません（データ上は長めに寄る傾向はありますが）。トライアルデータをカテゴリ別に分解すると、その違いは非常に明確です。

ゲームアプリでは、圧倒的に短いトライアル（多くは4日未満）が好まれます。トライアルが長くなると、ユーザーは習慣形成ではなく「クリア」を目的に最適化してしまい、不正利用が起こりやすくなるためです。

写真・動画アプリも短い傾向にあります。価値が即座に体験できるため、ユーザーはすぐにコンテンツを編集し、ツールの利点を実感できます。

一方で、ヘルス＆フィットネス、教育、旅行アプリなどは、成果が出るまでに時間がかかったり、より大きな意思決定（例えば旅行の予約）を伴ったりします。そのため、5〜9日のトライアルが一般的であり、これが7日間トライアルが業界のデフォルトになった理由の一つです。

しかし、「一般的」であることは「正しい」ことを意味しません。だからこそ強調したいのは、どうか7日間をデフォルトにしないでほしいということです。重要なのは、トライアル期間を価格や業界慣習ではなく、アクティベーションまでの時間に合わせることです。

エンゲージメントは長期トライアルの静かな落とし穴

長いトライアルは一見すると良さそうに見えますが、実際には管理が難しいものです。まさに「Instagramの写真と現実」のようなものです。美しい旅行写真の裏で、実際は食あたりで寝込んでいる、そんなギャップがあります。

YNABの長期トライアルがうまく機能しているのは、負担がユーザーではなくプロダクト側にあるからです。ワークショップやライブセッション、明確なメソッドを通じて、ユーザーを積極的に導いています。

つまり、そのトライアルは受動的ではなく、しっかりと構造化されているのです。しかし残念ながら、こうした設計は一般的ではありません。

多くのアプリにとって本質的な問いは、「一度試してもらえるか」ではなく、「ユーザーが勢いを失う前に習慣を作れるか」です。

そのためには、次のことが必要です。

• 継続的な利用を促すこと
• 先延ばしを防ぐこと
• 価値の実感を積み上げ続けること

私自身も最近、GOWODというモビリティアプリでこれを体験しました。このアプリは14日間のトライアルを提供しています。オンボーディングは非常に良く、最初にモビリティ診断から始まります（私の股関節の可動域にはかなり改善の余地がありそうでした）。

しかし、モビリティは「やった方がいいと分かっているけれど、なかなか優先されない」典型的なものです。長いトライアルはそれを後回しにする余地を与えてしまいました。忙しい時期にトライアルを開始し、「後で時間を見つけてやろう」と思っていたのです。

実際には、14日間で2回しかセッションを行えず、習慣化にはまったく足りませんでした。もし、より明確な目標やチャレンジがあれば、続けられていたかもしれません。例えば「2週間で週にX回実施する」と決め、最後に再度モビリティを測定する、といった形です。

フリーミアムと無料トライアル

フリーミアムモデルになると、話はさらに複雑になります。あまりにも寛大なフリーミアムと長いトライアルを提供しているアプリを見ると、「本当にユーザーに課金してほしいのだろうか？」と疑問に思うことさえあります。

Ling Zhang氏とJiang Duan氏によるフリーミアムSaaS企業の研究では、長いトライアルはトライアル開始数を増やすものの、必ずしもコンバージョンを改善するわけではないことが示されています。ユーザーが十分な価値を感じていなければ、トライアル期間を延ばしても意味はありません。しかし興味深いのはここからです。長いトライアルは「遅延コンバージョン」を増やす効果がありました。つまり、プレミアム機能を試す時間が長かったユーザーは、後になってから課金する傾向があったのです。

これが、StravaやMediumのような一見シンプルに見えるアプリが、あえて30日間のトライアルを提供している理由です。彼らは即時のコンバージョンではなく、長期的な成果を狙っています。

フリーミアムアプリに影響する要素はいくつもあります。

• ネットワーク効果の価値：多くのフリーミアムアプリは口コミによる成長に依存しており、同時に価値あるデータの蓄積にも依存しています。例えばStravaでは、特定の地域に十分なユーザーがいなければリーダーボードを成立させることができません。Mediumでは読者の行動が、どのコンテンツが有益かを判断するアルゴリズムに影響します。
• 価値は時間とともに蓄積される：Stravaの場合、パフォーマンス分析などの機能は1週間程度では十分な価値が現れない可能性があります。フリーミアムアプリは「じわじわ効いてくる」タイプが多く、プレミアム機能をすべてペイウォールの裏に置いている場合（最初に一部体験させるのではなく）、長いトライアルの方が価値を生むことがあります。Mediumでも、ユーザーは時間をかけて好みのライターやコンテンツを見つけていき、それがスイッチングコストを高めていきます。

つまり、さらに一段階深い問いが生まれます。長いトライアルは、短期的なコンバージョンの低下を上回るネットワーク効果やスイッチングコストを生み出すのか？プラットフォーム型ビジネスでは、その答えは多くの場合「Yes」です。

フリーミアムモデルにおいて本当に考えるべきは、トライアル期間ではありません。課金する価値があると感じさせるために、どれだけの価値をペイウォールの裏に置くべきか、そして同時に無料ユーザーを十分にエンゲージさせ、エコシステムを強化できているか、という点です。

トライアル期間の背後にある心理

視点を少し引いてみると、トライアル期間は本質的には心理の問題です。

特に重要なのが「損失回避」です。トライアルが終了することは、すでに自分のものになっている何かを失うように感じられます。特にユーザーが次のような投資をしている場合はなおさらです。

• 時間を費やしている
• データを作成している
• 習慣を築いている

ここで重要なのは、期間そのものではなく「投資」です。写真編集アプリであれば数日でも損失回避を生み出せますし、ゲームであればさらに短期間でも可能です。一方で、他のプロダクトではより長い時間が必要になります。

これは「保有効果（エンダウメント効果）」とも密接に関係しています。ユーザーが多くの努力を費やすほど、それを手放すのが難しくなります。IKEAの家具のようなものです。組み立ては大変でも、一度完成すると手放しづらくなります（私のように組み立て中に壊してしまわない限りは）。

ただし、長いトライアルが機能するのは、その投資が自然で繰り返し可能な場合に限られます。一度きりのセットアップではなく、時間とともに積み上がるものである必要があります。

一方で、短いトライアルは「緊急性」を生み出す点で優れています。早期の行動を促し、先延ばしを防ぎます。

すべてのトライアルは次のバランスの上に成り立っています。

• 緊急性 vs 習慣形成
• スピード vs 深さ

また、利用頻度も重要です。

• 日常的に使うアプリは習慣化が早い
• 週次・月次で使うプロダクトは、より長い期間が必要

さらにここに認知負荷の要素が加わります（少し心理学の話ですがお付き合いください）。

• 複雑なプロダクトは学習時間が必要
• シンプルなプロダクトでは、長すぎるトライアルは不要な摩擦になる

最もシンプルに言えばこうです。トライアルは「習慣が形成されるのに十分な長さ」でありながら、「忘れられてしまわない程度の短さ」であるべきです。

トライアル期間を決めるための実践フレームワーク

これを実務に落とし込むために、私は「自然な利用習慣」という観点で考えるのが有効だと思っています。これはPhitureのMobile Growth Stackで提唱されている考え方です。

トライアル期間を決める前に、次の3つの問いを自分に投げかけてください。

1. ユーザーは価値を実感するために、どのくらいの頻度で利用する必要があるか？利用頻度とエンゲージメント回数のバランスを考えます。例えば、あるアプリでは「友達を1人作る」よりも「5人作る」方がリテンションに大きく影響する場合があります。
2. 最初の「アハ体験」はいつ起こるか？これは最終目標（例：Stravaでマラソン完走）ではなく、「進歩を実感する瞬間」です。例えば、最初の数回のワークアウトを終えたときや、何かしらの測定可能な成果を得たときです。
3. 課金が成立するために必要な行動は何か？プロダクトの価値を実感し、「お金を払う価値がある」と感じる最低限の行動を特定します。これがトライアルから課金へと移行する閾値になります。

それでもなお、必ずテストを行うことを強くおすすめします。トライアル期間を変更した際の短期的・長期的な影響の両方を測定してください。だからこそ、事前にこれらの問いを考えることが重要なのです。

まだ迷っている場合は、以下の目安（あくまでガイドラインでありルールではありません）を参考にしてください。

• 3〜7日：シンプルなユーティリティ、ゲーム、即時価値型アプリ
• 7〜14日：日常的に使うアプリ（習慣形成に時間が必要）
• 14〜30日：週次利用のツール（プロジェクト管理など、2〜3サイクル必要）
• 30日以上：複雑な分析・レポート系ツール（オンボーディングやデータ蓄積に時間が必要）

上級編：すべてのユーザーに同じトライアルは必要ない

十分なユーザーベースがある場合、トライアルの最適化はさらに進めることができます。ユーザーごとに最適なトライアル期間が異なる可能性があるためです。

• 早くアクティベーションするユーザー vs 遅いユーザー
• フリーミアムで活性化済みユーザー vs 初回ユーザー
• 月額プラン vs 年額プラン（年額のみトライアルを提供するケースもあります）
• 離脱ユーザーの復帰施策としてのトライアル

ただし注意点として、複雑さは適切に運用できてこそ意味があります。過度に複雑なマネタイズ設計は、しばしばユーザーの混乱を招くだけです。

また、App Storeにはトライアル期間や設定に関する制約もあります。YNABのような柔軟な設計を実現するには、Webベースのトライアルが必要になる場合もあります（最近はWeb-to-Appが主流になりつつあります）。ただし、その場合でもアプリ内体験との整合性を保たなければ、Appleの審査でリジェクトされる可能性があります。

特定のユーザーに対して延長トライアルを提供したい場合、iOSではプロモーションオファーを利用する方法もあります。Androidでは、コードによってサブスクリプションの期限を延長することが可能です。

このようなセグメンテーションは、十分なアクティベーション指標とデータ量が揃ってからでないと、結果が不明確になるリスクがあります。

7日間デフォルトを超えて

だからこそ、7日間をデフォルトにしないでください。多くのアプリにとって悪い出発点ではありませんが、より短い、あるいは長いトライアルの方が大きな成果を生むケースは数多くあります。

まずは、そもそもトライアルが必要かを判断し、それがユーザーのアクティベーションに寄与しているかを確認しましょう。Davidのように大胆にトライアル廃止を試すことも有効です。トライアル期間をテストする場合は、評価指標を正しく設定することが重要です。トライアル開始数やトライアル→課金のコンバージョン率だけでなく、アクティベーション、リテンション、収益を重視してください。

次に、ユーザーの心理を理解しましょう。ユーザーには緊急性が必要なのか、それとも時間をかけた投資が必要なのか。損失回避は働くのか。文脈が重要です。ゲームは短いトライアルと相性が良く、ヘルス＆フィットネスは長めが適しているのには理由があります。最終的に重要なのは、「最も多くのユーザーをコンバージョンさせるトライアル期間」ではありません。「実際に長く使い続ける顧客を生み出すトライアル期間」です。

しかし、多くの人が抱く不安があります。「App Reviewを通さずにリモートでアプリを変更したら、AppleにアカウントをBANされるのではないか？」

結論から言うと、ルールを正しく理解していれば、その心配はありません。

AppleはA/Bテストそのものに反対しているわけではありません。実際、App Store上のアセットをテストするためのProduct Page Optimizationツールも提供しています。アプリ内で安全にテストを行うためのポイントは、「データの変更」と「コードの変更」の違いを理解すること、そして審査プロセスの本質を尊重することにあります。

ここからは、リモートでテストすべき内容（そしてテストできる内容）、安全に実施する方法、そして絶対に越えてはいけないラインについて詳しく見ていきます。

青信号：テストすべきこと

リモートテストにおける最も重要なルールは、ガイドライン2.5.2です。ここでは「アプリは、機能や動作を追加・変更するコードをダウンロード、インストール、または実行してはならない」と定められています。

ここで注目すべきは「コード」という言葉です。

FirebaseやRevenueCat Offeringsのようなリモート設定を使って「データ」を変更している場合、つまり既にコンパイル済みのコードの挙動をJSONなどで制御しているだけであれば、基本的には問題ありません。以下は、特に積極的にテストすべき影響度の高い領域です。

• ペイウォールのUIやコピー：背景色を変えたり、ヒーロー画像を差し替えたり、「Start Free Trial」と「Subscribe Now」の文言をテストすることは問題ありません。ボタンを描画するコードはすでにアプリ内に存在しており、表示するテキストを変えているだけだからです。これはコンバージョン最適化における最も取り組みやすい領域です。
• 価格とパッケージ：ペイウォールに表示するStoreKitプロダクトを切り替える（例えば、年額プランをデフォルトにするか月額にするかをテストしたり、新しいプランを追加するなど）は一般的な手法です。プロダクト自体がApp Store Connectで承認されている限り、どれを表示するかを動的に変更することは安全であり、推奨されています。
• 段階的リリースのための機能フラグ：新機能のコードをAppleに提出したバイナリに含めており（かつレビュー担当者がアクセスできる状態にしている場合）、それをユーザーの10％にだけ有効化してクラッシュ率や利用状況を確認したい場合も問題ありません。機能自体はレビュー時点で存在していたため、単に無効化されていただけです。
• オンボーディングフロー：オンボーディング画面の順序を入れ替えたり、価値提案をより分かりやすくするためにテキストを変更することも、リモート設定の適切な使い方です。既存のコンポーネントを活用してユーザージャーニーを最適化しているだけです。

注意点：重要なのは「審査の精神」を守ること

開発者が問題に直面する原因は、リモート設定の仕組みそのものではなく、「何を設定しているか」にあります。最もよくある落とし穴は、App Reviewの本来の意図をすり抜けようとすることです。

典型的な例として、「ハードペイウォール」と「ソフトペイウォール」のテストを考えてみましょう。

ソフトペイウォールは、ユーザーが閉じることができ、制限付きでアプリを利用できます。一方、ハードペイウォールは、サブスク登録するまで一切のアクセスをブロックします。どちらがより高いLTVを生むかを確認するために、これらをA/Bテストしたいと考える開発者は多くいます。

問題は何でしょうか？ハードペイウォールは、アプリの本質を大きく変えてしまう点にあります。App Storeのメタデータやスクリーンショットでは「無料アプリ＋任意のプレミアム機能」として紹介されているにもかかわらず、リモート設定によって突然ユーザーの50％がアプリを全く使えなくなる状態になると、実態との不一致が生じます。

Appleはフリーミアムアプリとして審査・承認しましたが、実際には「最初から有料」の体験を提供していることになります。これはガイドライン2.3.1（正確なメタデータ）に違反します。ユーザーはダウンロード時に実際の体験を正しく理解できていないからです。

ここで問題になるのはリモート設定そのものではなく、「見せかけと実態のすり替え」です。ハードペイウォールをテストしたい場合は、審査時点でハードペイウォールを有効にした状態でアプリを提出し、App Store上の情報と実際の体験が一致していることを保証するのが最も安全な方法です。

赤信号：実際にBANされる行為

Appleはデータに基づくA/Bテスト自体には寛容ですが、絶対に越えてはいけないラインがいくつか存在します。ガイドラインの導入部分には明確にこう書かれています。「システムを欺こうとした場合（例えば審査プロセスをだまそうとした場合など）、アプリはストアから削除され、Apple Developer Programから追放されます。」ここでは特に注意すべきポイントを見ていきます。

レビュー検知パターン

これは最も多く、かつ致命的なミスです。開発者がリモート設定を使ってAppleによる審査中かどうかを検知し（IPアドレスの確認や特定のテストアカウントの判定など）、審査時にはクリーンでガイドラインに準拠したバージョンのアプリを表示します。そして承認後にスイッチを切り替えて、強いマネタイズ施策を有効化します。Appleはこの手法を積極的に検出しており、発覚すればアカウントは即停止されます。

Webチェックアウトへのすり替え

Epic対Appleの判決により、米国では外部のWebチェックアウトへのリンクが許可されるようになりました。しかしこの判決を誤解し、審査後にリモート設定でIAPペイウォールをWebチェックアウトに置き換えるケースが多く見られます。これはいくつもの理由でリジェクトの原因になります。

1. 判決では、多くのアプリに対して外部リンクと並行してIAPを提供し続けることが求められており、完全に置き換えることはできません。
2. この判決は米国ストアにのみ適用されます。リモート設定で全世界にWebチェックアウトを有効化すると、他のすべての国でガイドライン違反となります。
3. 審査後に支払い手段の本質を変更することは、機能を隠していたと見なされます。

ネイティブStripe SDKの落とし穴

Epic判決に関するもう一つの誤解は、StripeのネイティブモバイルSDK（Payment Sheetなど）を使ってアプリ内でデジタルサブスクリプションを処理できるというものです。しかしこれはできません。Appleが許可しているのは、外部チェックアウトページをデフォルトブラウザで開くリンクのみであり、WebViewも不可です。リモート設定でネイティブStripeチェックアウトを有効にするとリジェクトされますし、審査時に存在しなかったものを後から有効にするとアカウント停止のリスクがあります。

実行可能コードのダウンロード

レビュー済みのバイナリに含まれていない新しい画面や機能を追加するJavaScriptやネイティブコードをダウンロードすることはできません。画面に表示するデータを変更することは可能ですが、画面そのものを後からダウンロードして追加することは許可されていません。

黄信号：グレーゾーンへの向き合い方

ルールを守っていても、ガイドライン5.6（Developer Code of Conduct）に抵触する可能性があります。このガイドラインでは、ユーザーをだまして望まない購入をさせるような「操作的な行為（manipulative practices）」を禁止しています。

「操作的かどうか」は主観的な判断になるため、いくつかのテストはグレーゾーンに入ります。

• 離脱時オファー（Exit offers）：ユーザーがペイウォールを閉じようとしたときに、割引付きの別オファーを表示する手法です。これは効果的なリテンション施策とも言えますが、操作的と見なされる可能性もあります。実際にガイドライン5.6でリジェクトされた例もありますが、多くの高収益アプリが日常的に実施しています。
• 連続したペイウォール表示：オンボーディング中にペイウォールを表示し、ユーザーが拒否した直後に別のペイウォールを表示するようなケースは、5.6違反と判断されやすい傾向があります。

こうしたグレーゾーンでテストを行う場合、最も重要なのは透明性です。App Reviewに対して実験を隠そうとしてはいけません。離脱時オファーをテストする場合は、提出するビルドにもその機能を含めておきましょう。また、App Reviewのメモ欄で「現在、ペイウォールのA/Bテストを実施しており、レビュアーにはバリアントAまたはBのいずれかが表示される可能性があります」といった説明を加えることが推奨されます。

リモートテストは、成長を加速させる強力な手段です。未承認の機能をこっそり導入するのではなく、ユーザー体験の最適化や適切な価格設定を見つけるために活用する限り、自信を持ってテストを行うことができます。

編集者からのちょっとした補足：このブログ記事では、多くの段落の末尾にピリオドが付いていないことにお気づきかもしれません。これは見落としではなく、RevenueCatのマーケティング担当VPであるRik Haandrikmanの“お約束”のスタイルです。彼のユニークな投稿をもっと見たい方は、XでRikをフォローしてみてください（ピリオドが消えているアカウントが目印です）。

Web-to-Appファネルはこの流れを覆します。ユーザーがApp Storeに触れる前の段階で、Web上でユーザーを獲得し、適格化し、コンバージョンさせることができます。しかしこれまでは、ランディングページツール、決済プロセッサ、分析プラットフォーム、そしてそれらをアプリと連携させるためのカスタムコードを組み合わせて構築する必要がありました。

RevenueCat Funnelsは現在パブリックベータとして提供されており、このような自前構築のスタック全体を置き換えるものです。

Watch on YouTube

Web-to-Appオンボーディングファネルのためのノーコードビルダー

RevenueCat Funnelsを使えば、ビジュアルエディタ上で複数ステップのWeb体験を設計し、それらを分岐ロジックでつなぎ、ホストされたURLとしてデプロイできます。Web開発やインフラ、エンジニアの作業待ちに頼ることなく、構築から公開まで行えます。

RevenueCatのPaywall Builderを使ったことがある方であれば、このエディタには見覚えがあるはずです。同じドラッグ＆ドロップの仕組みをベースに、複数の画面をつなげて完全なユーザー獲得フローを構築できるよう拡張されています。

エンドユーザーの体験は次のようになります。ユーザーは広告をクリックしてファネルにアクセスし、オンボーディング画面やアンケートを進み、Web上のチェックアウトに到達して購入を完了します。その後、Redemption Linkを受け取り、アプリをダウンロードしてリンクをタップすると、すでにサブスクリプションが有効な状態になっています。

エディタの内部

ファネルは、キャンバス上にステップを配置し、それらを接続することで構築します。ステップには、スクリーン（テキスト・画像・ボタン・アンケートを含むカスタマイズ可能なページ）、チェックアウト（RevenueCat、Paddle、そして今後はStripe Billingに対応）、さらには独自の認証フローなどを設定できます。

各ステップは、ボタンのタップやフォーム送信といったトリガーで接続します。その上で分岐ロジックを追加し、ユーザーごとに体験をパーソナライズできます。

• 特定の広告キャンペーンから来たユーザーには、URLパラメータに基づいて異なるオファーを表示します。
• アンケートの回答に応じて、異なるオンボーディングフローへユーザーを誘導します。
• IPアドレスからユーザーの国を判定し、自動的に体験をローカライズします。

フローに満足したら「公開」をクリックします。すると、広告、メール、SNS投稿などから誘導できるホスト済みのURLが発行されます。

テンプレートですぐに公開

ゼロから作り始める必要はありません。RevenueCat Funnelsには、カスタマイズ可能な事前構築済みテンプレートが用意されています。テンプレートを選び、ブランド要素を反映し、コピーやフローを調整して、そのまま公開できます。ゼロの状態から実際に動くファネルまで、数分で立ち上げることが可能です。

収益の流れが分かるアナリティクス

すべてのファネルには、RevenueCatダッシュボード上で利用できる組み込みのアナリティクスが含まれています。

General Metricsタブでは、ユニークセッション数、コンバージョン率、時間ごとの収益を確認できます。トラフィックソース、キャンペーン、国などの軸でデータをセグメント化することで、どのチャネルが最も価値の高いユーザーを生み出しているかを把握できます。

Step-by-Step Metricsタブでは、各ステップごとのコンバージョン率と離脱率を詳細に分解して表示します。特定の画面でユーザーが離脱している場合、どこに改善の余地があるのかを正確に把握できます。このビューは現在ベータ初期段階にあり、今後さらに詳細な情報が追加される予定です。

また、アナリティクスにはカスタマーライフタイムの選択機能も含まれており、特定の日のセッションから得られた収益を、指定した期間（初日、7日間、14日間など）で測定できます。これはChartsにおけるRealized LTVと同様の概念で、トライアルを実施している場合に、キャンペーンごとの実際のROIを比較する際に役立ちます。

さらに、FunnelsはUTMパラメータ（source、medium、campaign、content、term）を自動で取得するため、ファネルで発生した収益をすべて、元となったキャンペーンに紐づけて把握することができます。

RevenueCat Funnelsを試すべき人

有料ユーザー獲得（広告運用）を行っている場合

広告トラフィックをクイズに誘導し、パーソナライズされたオファーを提示し、Web上で決済を完了させ、その後サブスクリプションが有効な状態でアプリにユーザーを送るファネルを構築できます。アトリビューションの可視性を保ったまま、アプリストアの手数料を回避できます。

エンジニアの対応待ちに疲れているグロースマーケターの場合

画面の差し替え、アンケート内容のテスト、分岐ロジックの調整を自分で行えます。結果はアナリティクスダッシュボードで確認でき、数分で変更をリリースできます。スプリント単位で待つ必要はありません。

Webチームを持たないインディー開発者の場合

RevenueCatがすべてをホスティングし、Web Billingによるチェックアウトも処理します。これにより、はるかに簡単に導入を始めることができます。

インフルエンサー施策やキャンペーン別プロモーションを行っている場合

1つのファネルを作成し、特定のキャンペーンコードを持つユーザーに対して特別な割引やプロモーションコンテンツを表示する分岐を追加できます。1つのファネルで、キャンペーンコードに応じて複数のオーディエンスに対応できます。

パブリックベータに含まれる内容

パブリックベータには、Web-to-appファネルの構築・公開・分析に必要なすべての機能が含まれています。

• ドラッグ＆ドロップで画面を構築できるビジュアルファネルエディタ
• 事前構築済みテンプレート
• アンケートコンポーネント（複数選択・単一選択）
• URLパラメータ、国、ブラウザ情報、アンケート回答に基づく分岐ロジック
• RevenueCat Billingによるチェックアウト
• Paddle Billingによるチェックアウト
• カスタムドメイン対応
• 共有可能なURLによるホスト型デプロイ
• Webでの購入をアプリのエンタイトルメントに紐づけるRedemption Link
• コンバージョン率、離脱率、収益、カスタマーライフタイム値セレクターを含むアナリティクスダッシュボード
• UTMパラメータの自動トラッキング
• Amplitude、Mixpanel、Metaとの連携
• ローカライズ管理
• 自動保存機能

Funnelsは追加料金なしでRevenueCatのプランに含まれています。Funnels経由の購入は、他のRevenueCatトランザクションと同様にMTRにカウントされます。

ロードマップの内容

現在、チームはファネル内でのA/Bテスト機能を開発中です。AppsFlyerとの連携もロードマップに含まれており、Stripe Billingのサポートはリリース後まもなく追加される予定です。さらに、メール収集や自由入力テキストなどの新しい入力タイプも今後追加されます。もし追加してほしい機能があれば、ぜひご意見をお聞かせください。

はじめ方

最初のファネルを作成する手順は以下の通りです。

1. Paddleを使用したRevenueCat Web、またはStripeアカウントを連携したRevenueCat Billingを設定します。
2. RevenueCat WebダッシュボードのFunnelsセクションを開きます。
3. テンプレートから新しいファネルを作成するか、ゼロから作成します。
4. 画面をデザインし、分岐ロジックを追加し、チェックアウトステップを接続します。
5. ファネルを公開し、URLを共有します。

詳細なセットアップ手順は、Funnelsのドキュメントに掲載されています。

RevenueCat Funnelsは現在、RevenueCatユーザー向けにパブリックベータとして提供されています。ダッシュボードを開いて、最初のファネルを作成してみてください。

現在、このプロダクトチームは5名のプロダクトエンジニアで構成されており、複数のポジションを募集中で、2026年に向けてさらに採用を進めていく予定です。そこで本記事では、RevenueCatにおけるプロダクトエンジニア（PE）の実際の働き方、ここで成功するために必要なこと、そして私たちが直面している課題について紹介していきます。

RevenueCatのプロダクトが特別である理由

プロダクトに関わる立場として取り組める製品には、誰もが知っている（あなたの両親ですら知っているような）コンシューマー向けプロダクトから、特定の業界にいないと理解が難しいニッチなプロダクトまで、さまざまなものがあります。RevenueCatは明らかに後者に分類されますが、それでも非常に特別なプロダクトです。

難解な問題と意味のあるインパクト

RevenueCatを特徴づける要素のひとつは、非常に複雑で、やや専門的で分かりにくい問題を解決している点です。アプリ内課金のペイロードに含まれる各フィールドが何を意味するのか、Apple・Google・Stripeそれぞれでどのようなエッジケースが存在するのか、そしてそれらをどう扱うのが最適かを理解することは、複雑で決して華やかなものではありません。

私たちはよく「痛みを食べて生きている」と言います。つまり、開発者が向き合わずに済むように、つらいインフラの問題を引き受けているという意味です。それだけでもRevenueCatは扱うのが難しいプロダクトですが、それ以上に意味があるのは、その取り組みの背景にある理由です。私たちはアプリ開発者がアプリで収益を得られるよう支援しています。なぜなら…

• 私たちは、ソフトウェアは（全体として見れば）世界にとってプラスの存在であると信じています。
• 人々がソフトウェアを作り、それで生計を立てられるようにすることが、人類がより多くのソフトウェアを生み出す最良の方法だと考えています。

これらの考えに共感できるのであれば、RevenueCatは非常に魅力的なプロダクトです。私たちが解決している問題は、何万もの開発者がアプリで収益化することを支えているからです。

また、RevenueCatの多くのメンバーはアプリ開発のバックグラウンドを持っており、今でも個人アプリをストアで公開している人もいます。そのため、私たちは顧客と同じ立場を経験してきており、自分たちが解決している問題や提供している価値を実感として理解しています。これが私たちのユニークな点です。

顧客に愛されるプロダクト

RevenueCatは多くのファンを持つプロダクトです。もちろん、すべての顧客がファンというわけではありません。正当な不満を持つ人もいれば、単に日々の業務で使うツールのひとつとして捉えている人もいます。それでも、私たちのプロダクトを本当に気に入ってくれている顧客は数多く存在します。なぜなら、RevenueCatによって「好きなこと（アプリ開発）で収益を得ること」が可能になっていると実感しているからです。

カンファレンスで自ら私たちのブースを訪れてアプリの話をしてくれる顧客や、App Growth Annualに参加してくれる人たちと直接会うと、自分たちが関わっているプロダクトが愛されていることを実感できます。また、顧客が初めてのRevenueCatの請求書について誇らしげにSNSに投稿しているのもよく目にします。これは無料プランの上限を超え、アプリで実際に収益を得られるようになったことを意味します。これほど「お金を払うこと自体を喜ばれる」プロダクトは多くありません。

こうしたフィードバックは、RevenueCatで働くことの大きなやりがいにつながるだけでなく、問題に直面している顧客を支援したいというモチベーションにもなります。

顧客と一致したビジネスインセンティブ

最初の請求書の話に関連して言うと、RevenueCatとそのビジネスモデルの大きな特徴のひとつは、私たちのインセンティブが顧客のインセンティブと一致している点です。私たちは顧客の収益の一定割合を課金します。つまり、顧客が成長すれば私たちも成長し、顧客が収益を上げれば私たちも収益を得るという構造です。

これ以上に純粋なビジネスモデルはほとんどありません。私たちは顧客の成功を望んでいます。なぜなら、それがそのまま私たちの成功にもつながるからです。両者のインセンティブは完全に一致しており、その結果、プロダクトの意思決定においてビジネス的な妥当性を判断することが非常にシンプルになります。

数年前、私たちは価格体系をシンプルにし、無料プランであってもエンタープライズプランであっても、すべての顧客がすべての機能を利用できるようにしました。これは、私たちの収益が顧客の収益に比例して増えるため、顧客が大きくなれば自然とより多くの料金を支払う構造になっているからです。また、私たちはすべての開発者が成長ツールの恩恵を受けるべきだと考えています。もし低価格プランの開発者に対してそれらのツールへのアクセスを制限してしまえば、自分たちの成長機会をも制限することになってしまいます。

異なるプロダクト領域とそれぞれの課題

最後に強調したいプロダクトの特徴は、複数の異なる領域（サーフェス）を持っている点であり、それぞれに固有の（技術的な）課題が存在することです。

1. バックエンド：私たちのバックエンドは顧客にとっての重要なインフラです。顧客の収益に影響を与えないよう、信頼性を最優先にする必要があり、同時に非常に高いスケーラビリティも求められます。バックエンドは毎日数十億件のAPIリクエストを処理しており、最も利用されるAPIエンドポイントは完全にキャッシュされていなければ、データベースは瞬時に崩壊してしまいます。
2. SDKおよびAPI：これらは、開発者がアプリやバックエンドを構築する基盤となるため、長期間にわたって安定して動作するように設計する必要があります。特にSDKは品質基準が非常に高く、バグのあるSDKが一度アプリに組み込まれてしまうと、ユーザーがアプリを更新しない限り、その問題が長期間にわたって残り続ける可能性があります。
3. Webダッシュボード：この領域では、より自由度高くイノベーションや改善を行うことができるため、非常に高速に変更をデプロイできます。
4. コンシューマー向けUI：最近では、より多くのコンシューマー向けUIを提供しています。ペイウォール、カスタマーセンター、Webチェックアウト、Webカスタマーポータルなどは、顧客のさらにその先のユーザーが利用するため、信頼感を与える高い完成度が求められます。

プロダクト開発へのアプローチ

私たちのプロダクト開発へのアプローチは、会社のバリューとタレントビジョンの両方によって形作られています。

プロダクトマネジメントではなく、プロダクトエンジニアリング

私たちは最近、プロダクトマネージャーという役割をプロダクトエンジニアへと変更し、プロダクトエンジニアをエンジニアリング組織に統合するという意思決定を行いました。AIによる開発支援によってコードを書くことがボトルネックではなくなりつつある現在、プロダクトとエンジニアリングはこれまで以上に密接に連携する必要があります。プロダクト担当者はソフトウェアエンジニアを介さずにプロダクトの変更をリリースできるようになり、一方でエンジニアは単にコードを書くのではなく、より高いプロダクト視点や判断力が求められるようになります。つまり、プロダクトとエンジニアの連携と一体化がこれまで以上に重要になっており、この役割変更はその整合性を強化するものです。

何を作るかを決める

私たちは毎年、プロダクト戦略を策定します。この戦略が、その年に注力すべき領域を決定します。一般的に、毎年の戦略は過去の戦略の延長線上にある進化であり、大きな転換や急激な方向転換ではありません。戦略は経営陣によって決定されますが、その形成過程にはプロダクトエンジニア（PE）が重要なインプットを提供します。

この戦略に基づき、チーム構成も見直されます。私たちは比較的安定したクロスファンクショナルチームを持ち、PEはエンジニアチーム、エンジニアリングマネージャー（EM）、そしてデザイナーと協力して業務を進めます。

ロードマップは主に四半期ごとのプランニングプロセスで決定されます。このプロセスはこれまで何度も改善されてきましたが、現在は次のような流れになっています。

各チーム（PE、EM、デザイナーで構成）が優先事項のセットを提案し、それを経営陣（CEO、CTO、Head of Product）がレビューおよび議論します。これらの議論の中で一部調整が行われることもありますが、基本的には各チームがロードマップと優先順位の決定を担います。プロダクトエンジニアはこのプロセスにおいて重要な役割を果たしており、自身の担当領域を最も包括的に理解し、顧客にどのような価値を提供できるかを最もよく把握している存在であることが多いです。

日々および週単位の業務では、プロダクトエンジニアはEMやデザイナーと密接に連携し、少なくとも週1回のミーティングと、より頻繁な非同期コミュニケーションを通じて協働します。チームにおける機能の発見（ディスカバリー）と実装（デリバリー）はチーム全体で担われ、緊密なコラボレーションによって実現されています。

プロダクトチームにおけるバリューの実践

前述の通り、私たちのプロダクト開発の進め方を形作っているもう一つの要素は、会社のバリューです。これらはNotionに書かれて忘れられているような単なるリストではなく、私たちが日々意識し、実践し、自分たちを評価するための指針となるものです。

顧客への徹底したフォーカス（Customer obsession）

RevenueCatでは、何よりもまず顧客に価値を提供することを重視しています。これはいくつかの具体的な行動につながります。

• PEは頻繁に顧客と会話し、関わることが求められる：これには1対1のミーティングやリサーチコールだけでなく、サポートチケット、SNSの投稿、営業との会話、顧客との共有Slackチャンネル、カンファレンスでの会話なども含まれます。
• PEと顧客の間に障壁はありません。より良いプロダクト判断につながるのであれば、すぐに会話を設定すべきです。
• 顧客の具体的なエピソードは、プロダクトの意思決定を議論する際に非常に説得力のある材料になります。もちろん、顧客の要望をそのまま全て実装するわけではありませんが、その背後にある本質的なニーズや課題を理解しようとします。一般的に、顧客が自分の問題や未解決の課題を伝えてくれるほどプロダクトに関心を持っているのであれば、その声には耳を傾けるべきだと考えています。
• チームは、問題の規模に関係なく顧客のニーズに向き合います。たとえ小さな不満であっても軽視しません。戦略やロードマップは重要ですが、バグを素早く修正したり、ユーザーが直面している制約を取り除いたりすることで「自分たちは大切にされている」と感じてもらえれば、それだけで顧客の印象は大きく変わり、懐疑的だったユーザーがファンになったり、ファンがさらに強い支持者へと変わることもあります。

常にリリースし続ける（Always be shipping）

「常にリリースし続ける」という価値観は、私たちのプロダクト開発の進め方に大きく影響しています。具体的には、計画している機能のスコープをMVP（最小実用製品）まで削減することを促します。その理由はいくつかあります。

1. 顧客に価値をより早く届けることができるため
2. できるだけ早い段階で顧客からフィードバックや検証結果を得ることができるため

リリース目標

この「常にリリースする」状態を実現し、スコープを最小化するための方法のひとつが、社内の締め切りを設定することです。

こうしたリリース目標を設定した場合、私たちはその期限までに必ずリリースできるよう、チームのスピードを上げるためにリソースを追加するなど、あらゆる手段を講じます。また同時に、「必須」だった要素を「あると良い」へと下げるといった、痛みを伴うスコープ削減を迫られることもあります（ソフトウェア開発を知っている人であれば分かる通り、多くの場合「あると良い」は実際には実装されません）。

興味深いのは、機能をリリースして顧客に使ってもらった後に寄せられる最初の要望が、後回しにした機能ではなく、まったく別のものになることが多い点です。これは、迅速にリリースすることの価値を示しています。私たち自身も顧客も、機能が実際にプロダクト内で使われたときにどう振る舞うかを正確に予測することはできません。それを知る唯一の確実な方法は、素早くリリースし、その後に改善を重ねることです。

行動バイアス（Bias for action）

「常にリリースし続ける」もう一つの側面は、行動バイアスです。私たちは常に不完全な情報のもとで意思決定を行っています。もし完全な情報を待っていたら、決断は永遠にできません。そのため、プロダクトエンジニアには、不確実性の中でも意思決定を前に進める責任があります。多くの決定は後から修正可能であるため、延々と議論し続けるよりも前進することの方が重要です。行動せよ、議論だけで終わるな。

オーナーシップを持つ（Own it）

RevenueCatではオーナーシップが非常に重要です。プロダクトエンジニアにとって、それは「どんな問題も他人事ではない」という意味です。私たちは共に勝ち、共に負けます。問題に気づいたら、それが自分の担当領域でなくても行動するべきです。

もちろん、PEがすべての問題を自分で解決する必要があるわけではありません。しかし、顧客の課題から解決策の設計、技術的な実装に至るまで、最も広くエンドツーエンドで理解していることが多いため、問題に気づく立場にあり、実際にそれが期待されています。

RevenueCatのプロダクトエンジニアは高い主体性を持っており、困難な状況でも変化を起こせると信じられています。彼らは目の前の問題を解決するためにできる限りのことを行い、ときにはそれ以上のこともします（例えば、より良く問題を解決するために新しいことを学ぶなど）。コードベースを掘り下げてバグの原因を特定したり、データウェアハウスをクエリしてデータを理解したり、顧客の問題をデバッグするために急遽ミーティングに参加したりします。

また、AI支援による開発の進化により、プロダクト担当者がコードベースに直接貢献することも珍しくなくなっています。変更が比較的シンプルな場合、チケットを書いてエンジニアに依頼するよりも、PE自身がCursorやClaude Codeを使って直接修正を行い、レビューを経てリリースする方がはるかに速いこともあります。

要するに、やるべきことは多く、全員が総力戦で取り組んでいるということです。

バランス（Balance）

「バランス」というバリューは、おそらく最も誤解されやすいものです。これは手を抜くという意味ではありません（むしろ、RevenueCatはスタートアップであり、仕事は意図的にハードです）。私たちはスピードを維持し続けてこそ成功できます。

しかし同時に、このバリューは「速く動くこと」と「燃え尽きること」の間にある微妙なバランスを意識させてくれます。興味深い課題に取り組み、モチベーションの高いチームと働くことは、大きなやりがいにつながります。PEはチームのモチベーションや関心を維持する上で重要な役割を担っており、自分たちが解決している問題と顧客へのインパクトを結びつけること、例えば顧客からのポジティブなフィードバックを共有したり、熱量のある雰囲気を生み出したりすることが求められます。

また、「バランス」は他者に対する思いやりや優しさ、そして信頼と相互理解に基づいたチーム環境を築くことも含んでいます。プロダクトエンジニアは自然とリーダー的な役割を担うことが多く、こうした行動を体現し、チームに広げていく上で重要な存在です。

RevenueCatのタレントビジョン

RevenueCatのタレントビジョンは、高い能力を持つメンバーで構成された「勝てるチーム」を築くことです。そのため、すべてのメンバーに対して高い基準を設けており、それを採用やパフォーマンス管理のプロセスを通じて維持しています。

この考え方は、プロダクト開発の進め方にもいくつかの影響を与えています。まず、私たちのチームは比較的シニアでプロダクト志向のエンジニアやエンジニアリングマネージャーで構成されています。そのため、RevenueCatのPEは、細かいプロジェクト管理や詳細なチケット作成に深く入り込む必要はあまりありません。むしろ、必要なコンテキストや問題領域の理解を的確に伝える能力が重要であり、それによってエンジニアがPEの意思決定によってボトルネックになることを防ぎます。

また、このビジョンはチームが比較的リーンであることも意味しています。私たちは、優秀な人材で構成された小さなチームの方が、基準の低い大規模なチームよりもはるかに速く動けると考えています。

プロダクトチームが直面している主な課題

ここでは、RevenueCatのプロダクトエンジニアとして直面している主な課題を紹介します。

やるべきことが多すぎて時間が足りない

これは典型的なスタートアップの課題かもしれませんが、RevenueCatでもまさに同じ状況です。私たちには常に、取り組むべきアイデアや解決すべき顧客の課題が、実際に対応できるキャパシティを上回っています。そのため、会社全体としても、各チームとしても、そしてPE個人としても、適切に優先順位を付け、それを市場や顧客、社内の関係者にしっかりと伝える必要があります。これに対しては、戦略とプランニングプロセスを通じて、常に最もインパクトの大きい機会に集中するようにしています。

顧客志向と戦略的優先順位のバランス

上記の優先順位付けの必要性に関連して、私たちはしばしば「顧客への徹底したフォーカス」と「戦略的優先順位」の間で引き裂かれる状況に直面します。戦略的なプロジェクトは成果が出るまでに時間がかかる一方で、顧客志向の価値観は小さなリクエストにも迅速に対応することを求めます。どちらかに偏りすぎるのは望ましくありません。顧客の声を無視して長期戦略だけに集中すれば、反応が遅いと見なされ、これまで築いてきた顧客からの信頼を失うリスクがあります。一方で、顧客の要望ばかりに対応していると、大きな成長機会を逃したり、市場の変化に乗り遅れたり、プロダクトや会社にとって次の大きなチャンスを掴めなくなります。

成長に伴う調整コストの増加

RevenueCatはここ数年で大きく成長してきました。タレントビジョンに基づき、収益ほど急速にチームを拡大してはいませんが、それでも組織は拡大しており、今後も成長を続けていく予定です。EPDチームが大きくなることでプロダクト改善のためのリソースは増えますが、その分、調整に必要なコストも増加します。エンジニアリングチームの人数が倍になったとしても、リリースできる変更が単純に倍になるわけではありません。一部のリソースは調整や連携に割かれる必要があるからです。また、チームが増えることで、プロダクトの各領域で一貫性のない体験が生まれるリスクも高まり、それを防ぐためにもさらなる調整が必要になります。

マルチプロダクト企業への転換

現在直面している最大の戦略的課題は、単一プロダクト企業からマルチプロダクト企業へと移行することです。RevenueCatは長年、アプリにアプリ内課金を導入するための最良の手段として位置づけられてきました。その結果、多くのサブスクリプションアプリが最初からRevenueCatを採用しています。しかし、新規のサブスクリプションアプリの市場には限界があります。

成長を続けるためには、既存のターゲット市場に対してより多くの価値を提供すると同時に、現在のRevenueCatプロダクトが適していない新しい顧客層にもアプローチする必要があります。そのためには、完全に新しいプロダクトを追加するか、既存のプロダクトを分解して個別に提供できるようにするなど、マルチプロダクト戦略が不可欠です。

私たちはその両方に取り組む計画であり、それに伴ってプロダクト意思決定のプロセスも大きく変わることになります。プラットフォームの一部だけを利用するユーザーにも適した体験を設計し、価格や課金モデルを構築し、適切なプロダクトを見つけて設定できるオンボーディングフローを設計する必要があります。

この取り組みはまだ始まったばかりであり、今後しばらくは私たちにとって大きなテーマであり続けるでしょう。

RevenueCatにおける優れたとはプロダクトエンジニアとは

ここまで読んでいただけましたか？それでは、RevenueCatにおけるプロダクトエンジニアに適した人物像について見ていきましょう。もしかすると、あなた自身がその人物かもしれませんし、思い当たる誰かがいるかもしれません。

• ビルダーであり、マネージャーではない：RevenueCatのPEは自分たちを「プロダクトを作る人」と捉えています。バックログを管理したりステークホルダーを調整したりするのではなく、協働し、最適な解決策を提案し、チームがより速く前進できるよう支援します。
• ミッショナリー：私たちのミッションは開発者がより多くの収益を得られるようにすることであり、PEはそれを強く信じています。ソフトウェアが世界にとって良いものであり、開発者が成功することでより多くのソフトウェアが生まれると考えているからこそ、顧客に強くフォーカスします。
• 徹底したオーナーシップ：RevenueCatのPEは、顧客の課題を解決しプロダクトを成功させるために必要なことはすべてやります。他人を責めたり失敗を受け入れたりするのではなく、チームの一員として責任を分かち合いながら前に進む方法を見つけます。孤立した個人ではなく、チームの一員として行動します。
• 不完全な情報でも決断できる力：スピードの速いスタートアップ環境では、PEは必要十分な情報を集めて素早く意思決定を行います。現在のデータに基づいて行動し、方針を定めてチームを導きつつ、新しい情報が得られた場合には柔軟に方向転換できる姿勢を持っています。
• 深い技術理解：RevenueCatは複数のユーザー層に対応していますが、本質的には開発者向けツールです。そのためPEには、API、分散システム、SDKの制約、データモデルといった領域について深い技術的理解が求められ、それらに関する意思決定を説明し評価できる必要があります。
• 非同期コミュニケーション力：グローバルなリモートチームであるRevenueCatでは、PEはドキュメント、Loom、FigJamなどを用いた明確な非同期コミュニケーションに優れており、必要に応じてリアルタイムの会話に切り替えてチームの認識を揃える判断力も持っています。

採用中です！

RevenueCatではプロダクトエンジニアチームを継続的に拡大しています。難しくも意味のある問題に取り組み、何万もの開発者が好きなことを仕事にできるよう支援したいと考えるビルダーであれば、ぜひお話ししましょう。詳しくはキャリアページの募集をご覧ください！

本記事では、既存の3つのアプリ外マーチャンダイジング機能の仕組みと役割、これらを新しい「Merchandising and optimization」ページに統合することでGoogle Playにどのような変更が加わるのか、既存設定に影響するタイムラインと3月16日の締め切り、移行時に各機能で注意すべきポイント、期限までに取るべき具体的な対応、そしてアプリ外購入がどのように課金基盤と連携するのかについて解説します。

背景：Google Playはどのようにアプリ外でプロダクトを販促しているのか

変更点に入る前に、Google PlayがすでにアプリのUIの外でどのようにプロダクトをプロモーションしているのかを理解することが重要です。アプリ外マーチャンダイジングが重要なのは、現在アプリを開いていないユーザーにもリーチできる点にあります。Playストアを閲覧しているとき、通知を受け取ったとき、関連コンテンツを見ているときなど、ユーザーはアプリを起動することなくあなたのプロダクトに触れる可能性があります。これは、アプリ内課金UIとは独立して機能する、追加の獲得およびコンバージョンチャネルを生み出します。

現在、このアプリ外マーチャンダイジングを担う機能は3つ存在し、それぞれがGoogle Play Console内で個別に設定されています。

購入フローのレコメンド（Purchase flow recommendations）

購入フローのレコメンド機能では、ユーザーがPlayストアを閲覧している際に、Google Playがあなたのプロダクトを提案することができます。ユーザーがアプリを探索したり、関連コンテンツを閲覧したり、購入画面を移動しているときに、アプリ内プロダクトやサブスクリプションがレコメンドとして表示されます。これらの提案は、ユーザーの購入履歴、閲覧行動、コンテキストシグナルに基づいて決定されます。

この機能は、どのSKUをプロモーション対象にするかを選択し、必要に応じて特定の国をターゲティングすることで設定します。その後、Google Playが適切なユーザーに対して、いつ・どこに表示するかを決定します。設定はGoogle Play Console内の専用の purchase flow recommendations ページ で管理されます。

注目プロダクト（Featured products）

注目プロダクトは、より直接的にプロモーションをコントロールできる機能です。Google Playに表示内容を任せるのではなく、どのプロダクトを強調するかを明示的に設定します。プロモーションの開始日と終了日を設定できるほか、特定のオファーやイベントと紐付けたり、特定のオーディエンスや国をターゲティングしたり、開発中はライセンステスターのみに限定することも可能です。

この機能は、期間限定のプロモーション、季節キャンペーン、新しいプレミアムコンテンツの訴求に適しています。何を、誰に、どの期間表示するかを細かく制御できる点が特徴です。

カート放棄リマインダー（Cart abandonment reminders）

カート放棄リマインダーは、購入ファネルの別の段階に対応する機能です。ユーザーが購入フローを開始したものの完了しなかった場合、Google Playが通知を送って購入の完了を促します。これは、ECで一般的な手法をアプリストアに適用したものです。

この機能では個別のプロダクト設定は行いません。代わりにGoogle Playが購入未完了の試行を自動的に追跡し、途中で離脱したユーザーにリマインド通知を送信します。この機能を利用したくない場合は、Google Play Consoleのフォームから完全にオプトアウトすることも可能です。現在は、ワンタイムプロダクトとサブスクリプションでそれぞれ別々にオプトアウト設定が管理されています。

何が変わるのか：統合されたML主導のアプローチ

Googleは、これまで別々に提供されていた3つのツールを、Google Play Console内の単一の Merchandising and optimization ページ に統合します。購入フローレコメンド、注目プロダクト、カート放棄リマインダーを個別に管理するのではなく、すべてを1か所で設定する形になります。

根本的な変化は、「手動設定」から「アルゴリズムによる最適化」への移行です。新しい仕組みは次のように動作します。

1. 対象となるSKUを選択：新しいページで、アプリ外プロモーションの対象とするプロダクトを選択します。
2. 残りはGoogleのMLが判断：Google Playの機械学習モデルが、選択したプロダクトを表示する最適なサーフェス、タイミング、オーディエンスを決定します。
3. より広いリーチと引き換えに手動コントロールは減少：MLシステムは、Google Playがサポートするすべてのアプリ外購入フローにプロダクトを配置できるため、手動で設定したプロモーションよりも多くのユーザーにリーチできる可能性があります。

これはつまり、これまで注目プロダクトで可能だった細かなコントロールの一部を失うことを意味します。マーチャンダイジングレベルでのオーディエンスターゲティングや国別ターゲティング、特定のオファーやイベントとの紐付けはできなくなります。国単位の制限が必要な場合は、SKUレベルで設定する必要があります。

このトレードオフはシンプルです。手動設定を手放す代わりに、GoogleのMLがより広範なサーフェスで最適化を行います。多くの開発者にとっては、MLモデルが人手よりもはるかに速く配置戦略をテスト・改善できるため、結果としてパフォーマンス向上が期待できます。

また、これまでこれらの機能を設定してこなかった開発者にとっては、新しいページはチャンスでもあります。従来は3つの異なる設定画面を管理する必要があり、その煩雑さがアプリ外マーチャンダイジングの利用を妨げていました。単一ページでシンプルに管理できることで導入のハードルが下がり、Google Play上でのプロモーションの恩恵を受けやすくなります。

タイムライン：いつ何が起きるのか

移行は段階的に進められ、明確な締め切り日が設定されています。各段階で何が起きるのかを見ていきましょう。

重要なポイントは、現在の設定を変更できる期限が3月16日であるということです。マーチャンダイジング設定を調整する必要がある場合は、その日までに対応を行ってください。

注目プロダクトに関する注意点

注目プロダクトは設定項目が最も多いため、移行パスも最も複雑になります。各設定項目が移行後にどう扱われるかを見ていきましょう。

注目プロダクトを積極的に活用している開発者にとって最も影響が大きい変更は、オーディエンスターゲティングおよび国別ターゲティングが廃止される点です。地域ごとに異なるプロダクトを表示する戦略に依存している場合は、そのアプローチを見直す必要があります。国別制限はSKUレベルで設定することが唯一の対応手段となります。

購入レコメンドに関する注意点

購入レコメンドは、注目プロダクトと比べて設定項目が少ないため、移行も比較的シンプルです。

• アクティブなSKUは引き続き有効：現在購入フローレコメンドに設定しているSKUは、3月16日以降も引き続きアプリ外購入の対象となります。
• 国別ターゲティングは廃止：購入レコメンドに設定されている国別ターゲティングはサポートされなくなります。注目プロダクトと同様に、必要な場合はSKUレベルで国制限を設定する必要があります。
• ライセンステスターは対象外：ライセンステスターのみに対象を限定しているプロダクトは、マーチャンダイジング対象から除外されます。
• パフォーマンスレポートは引き続き閲覧可能：パフォーマンスレポートおよび関連指標は、新しいページが公開されて該当ページが廃止されるまで、購入レコメンドページ上で引き続き確認できます。

購入レコメンドを利用している多くの開発者にとって、この移行はシンプルです。プロダクトは引き続きレコメンドされますが、どの国に表示するかを細かく調整する機能は失われます。

カート放棄リマインダーに関する注意点

カート放棄リマインダーは移行の影響が最もシンプルですが、理解しておくべき重要なポイントが1つあります。

• 初期リリースではワンタイムプロダクトのみ対象：新しい「Merchandising and optimization」ページでは、初期段階ではカート放棄機能は ワンタイムプロダクト のみに対応します。サブスクリプションは初期リリースの対象外です。
• サブスクリプションのブロックリストは変更なし：サブスクリプションに対してカート放棄リマインダーのブロックリストを設定している場合、その設定は引き続き有効であり、この移行の影響は受けません。
• オプトアウトの仕組み：ワンタイムプロダクトのカート放棄リマインダーは、3月16日までは既存のフォームからオプトアウトできます。それ以降は、新しいページが公開されるまでオプトアウトはできません。すでにオプトアウトしている場合は、その状態は維持されます。引き続きオプトイン状態にしたい場合は、特に対応は不要です。

3月16日までにやるべきこと

締め切り前に対応すべき具体的なチェックリストは次のとおりです。

1. 注目プロダクトの監査：Google Play Consoleの注目プロダクトページを開き、すべてのアクティブな設定を確認します。3月16日以降に終了日が設定されているものを特定し、無期限にするか削除するかを判断してください。
2. オファーおよびイベントへの依存を解消：注目プロダクトが特定のオファーやイベントに紐づいている場合、それらは今後サポートされなくなります。対象プロダクトについては別のプロモーション戦略を検討してください。
3. 国別制限をSKUレベルへ移行：注目プロダクトや購入レコメンドで国別ターゲティングを使用している場合は、3月16日までにSKUレベルで設定し直してください。これにより、移行後も地域戦略を維持できます。
4. ライセンステスター設定の確認：ライセンステスターのみに限定されているプロダクトは、マーチャンダイジング対象から除外されます。実ユーザーにも表示したい場合は、締め切り前にターゲティングを更新してください。
5. カート放棄リマインダーのオプトアウト判断：ワンタイムプロダクトのカート放棄リマインダーをオプトアウトしたい場合は、3月16日までにフォームを提出してください。それ以降は新しいページの公開までオプトアウトできません。
6. パフォーマンスデータの保存：履歴分析のために保持しておきたい指標がある場合は、注目プロダクトや購入レコメンドページからエクスポートまたはスクリーンショットを取得しておきましょう。ページが廃止されるまでは閲覧可能ですが、事前保存を推奨します。
7. チームへの共有：Google Play Consoleの設定を管理しているチームメンバー全員に、3月16日の締め切りと今後の変更内容を周知してください。

アプリ外購入が課金基盤とどのように連携するのか

アプリ外マーチャンダイジングについて議論する際によくある疑問は、これらの購入が実際にどのように課金インフラを通過するのかという点です。結論から言うと、Google Play上のサーフェスから開始されたアプリ外購入も、通常のアプリ内購入と同じPlay Billing Libraryのフローを通ります。

ユーザーがGoogle Play上でレコメンドされたプロダクト、注目プロダクト、またはカート放棄リマインダーをタップした場合、その購入は標準のGoogle Play Billingインフラを通じて処理されます。アプリ側では PurchasesUpdatedListener や queryPurchasesAsync といった、通常のアプリ内購入と同じ仕組みで購入を受け取ります。購入トークン、プロダクトID、承認（acknowledgment）の要件もすべて同一です。バックエンドでReal Time Developer Notifications（RTDN）を処理している場合も、アプリ外購入に対して同じ種類の通知を受け取ります。

つまり、課金基盤の管理にRevenueCatを使用している場合、アプリ外購入も自動的に処理されます。RevenueCatのSDKとバックエンドは、アプリ内購入と同様に、購入検証、エンタイトルメント付与、承認処理を行います。アプリ外サーフェスからの購入をサポートするために、特別なSDK統合やコード変更は必要ありません。

また、RevenueCat Chartsでは、アプリ外サーフェスからの収益もアプリ内収益と合わせて追跡できます。すべての購入が同じ課金パイプラインを通るため、既存の分析およびレポーティング基盤で追加設定なしにこれらの取引を把握できます。これは特に移行後に、ML主導のアプローチが従来の手動設定と比べて、アプリ外コンバージョンを増やしているのかどうかを確認する際に有用です。

重要なのは、「Merchandising and optimization」ページはConsole側の変更であるという点です。これはGoogle Playがどのようにプロダクトをユーザーにプロモーションするかに影響するものであり、購入処理そのものには影響しません。課金コード、RevenueCatの統合、バックエンドの仕組みは、これまで通りそのまま機能します。

結論

本記事では、購入フローレコメンド、注目プロダクト、カート放棄リマインダーという3つのマーチャンダイジング機能が、単一のML主導の「Merchandising and optimization」ページへ統合されるという、Google Playの今後の変更について解説しました。既存設定を変更できる期限は3月16日であり、各機能ごとの移行ルールを理解することで、プロダクトを引き続き効果的にプロモーションできるようになります。

手動設定からMLによる最適化への移行は、アプリストアにおけるプロダクト発見のあり方の変化を反映しています。多くの開発者にとって、手動コントロールの減少は、Google Playの各サーフェスにおけるより広範でアルゴリズム最適化されたリーチによって補われることになります。重要なのは、締め切り前に既存設定を見直し、国別制限をSKUレベルへ移行し、注目プロダクトの終了日について意図的に判断を行うことです。

Play Billing Libraryを直接利用している場合でも、RevenueCatを利用している場合でも、今回の変更はすべてConsole側で完結します。課金コード、購入処理、エンタイトルメントロジックには影響はありません。3月16日までにConsole設定の対応に集中し、その後の最適化はGoogleのMLに任せることが重要です。

しかし、このプラグインは単なるダッシュボードのミラーではありません。RevenueCatプロジェクトを理解し、ユーザーに代わって操作できるフル機能のAIエージェントを備えています。オファリングの作成、AIによるペイウォール生成、収益チャートの分析、統合のデバッグ、さらにはソースコードの編集まで、すべてIDEを離れることなく、自然言語のプロンプトで実行できます。

本記事では、RevenueCat IntelliJ Pluginの主要機能を紹介します。具体的には、OAuthサインインがどのように手動のAPIキー設定を置き換えるのか、ダッシュボードパネルがブラウザへの切り替えなしにリアルタイムの指標をどのように表示するのか、AIエージェントがどのように会話ベースでペイウォールを生成しプロジェクト全体を管理するのか、そしてAIによるコード編集がどのように差分プレビューやUndo対応付きでプロジェクトファイルを変更できるのかを見ていきます。

はじめに：OAuthサインイン

このプラグインは、従来のAPIキー設定に代わり、PKCEフローを用いたOAuth 2.0認証を採用しています。初めてRevenueCatのツールウィンドウを開くと、「Sign in with RevenueCat」ボタンが表示されたウェルカム画面が表示されます。

サインインボタンをクリックすると、認証のためにブラウザが開きます。プラグインはローカルのコールバックサーバーを起動し、トークンの交換を自動で処理し、認証情報を安全に保存します。認証が完了すると、プラグインはあなたのプロジェクトを取得し、どのプロジェクトで作業するかを選択できるようになります。

OAuthフローでは、プロジェクト設定、チャートおよび指標、顧客情報に対するスコープ付き権限が要求されます。トークンは期限切れになると自動で更新されるため、手動操作なしでセッションをまたいで認証状態が維持されます。

AIエージェントによるコード編集：エージェント主導のファイル変更

データの取得や問い合わせにとどまらず、AIエージェントはプロジェクトのソースファイルを直接読み取り、検索し、編集することができます。これにより、「ApplicationクラスにRevenueCat SDKの初期化処理を追加して」や「ペイウォール画面を新しいoffering IDに対応するよう更新して」といったワークフローを実現できます。

ステージド編集システム

エージェントがコード変更を提案すると、それらはインライン差分プレビュー付きのステージド編集として表示されます。適用する前に、各変更を確認できます。

• 個別に承認：特定の変更だけを適用し、他は拒否する
• すべて承認：提案された変更を一括で適用する
• 拒否：ファイルを変更せずに、提案された変更を破棄する

AIによるペイウォール生成

AIエージェントの最も強力な機能は、エンドツーエンドのペイウォール生成です。必要な内容を説明するだけで、エージェントがすべてを処理します。オファリングの作成、パッケージの設定、プロダクトの紐付け、そしてコピー、画像、スタイリング、テンプレート選択を含む、完全にデザインされたペイウォールをAIで生成します。

エージェントは生成ジョブをバックグラウンドで監視します。ペイウォールの準備が完了すると通知が表示され、ペイウォールビルダーへの直接リンクからデザインの確認や公開が行えます。この監視は、OAuthトークンが期限切れになった場合でも、APIキーを独立したフォールバックとして使用することで、安定して動作します。

複数のペイウォールを連続して生成することも可能です。エージェントは各ジョブを個別に追跡するため、「プレミアム」ペイウォールの後に「フリーミアム」ペイウォールを依頼しても、両方を競合なく管理できます。

会話ベースでプロジェクトを管理する

エージェントは、RevenueCatのリソース全体に対して、作成（Create）、取得（Read）、更新（Update）、削除（Delete）のすべての操作に対応しています。以下は、実際に依頼できる内容の例です。

リソースの作成：

「Premiumという名前の新しいオファリングを作成し、月額9.99ドルのパッケージと年額79.99ドルのパッケージを設定して」

エージェントはオファリングを作成し、両方のパッケージを作成し、適切なプロダクトを紐付けます。これらのリソースがすでに存在する場合でも、エージェントは重複を検出し、エラーにするのではなく再利用します。

「pro_accessというエンタイトルメントを設定して、すべてのサブスクリプションプロダクトに紐付けて」

エージェントはエンタイトルメントを作成し、既存のプロダクトを一覧化し、それぞれに紐付けます。

プロジェクトの確認：

「すべてのオファリングと、どれにペイウォールが設定されているかを見せて」

エージェントはオファリングとペイウォールのデータを取得し、設定済みのものと不足しているものを分かりやすくまとめて表示します。

「設定されているプロダクトは何？どれがパッケージに紐付いていない？」

エージェントはプロダクト、パッケージ、オファリングを横断的に参照し、未紐付けのリソースを特定します。

ペイウォール管理：

「プレミアムオファリング用にAIペイウォールを生成して。アプリはFitCatというフィットネストラッカーで、健康意識の高いミレニアル世代がターゲットです」

エージェントはアプリのコンテキストをもとに、ブランドに合ったコピー、スタイル、デザインを持つペイウォールを生成します。

「現在のペイウォールを複製して、Holiday Promoという名前にして」

エージェントはAPI経由でペイウォールを複製し、カスタマイズ用のビルダーリンクを提供します。

Charts APIで収益を分析する

エージェントは、収益、MRR、ARR、チャーン率、トライアルから有料への転換率、アクティブなサブスクリプション数、リテンションコホートなど、21種類のチャートにアクセスできます。分析的な質問を投げかけると、データに基づいた回答を得ることができます。

「過去6か月間のMRRトレンドは？」

「トライアルから有料への転換率を週別で見せて」

「今月の収益と先月の収益を比較して」

「年額サブスクライバーのチャーン率は？」

エージェントは、日付範囲、解像度、セグメントフィルターなど適切なパラメータを指定してCharts APIをクエリし、結果を読みやすい形式で提示します。

デバッグと統合サポート

エージェントはCRUD操作にとどまりません。RevenueCatのSDKを理解しており、統合時の問題のデバッグも支援できます。

「ペイウォールを表示しようとすると 'Configuration not found' エラーが出ます。何が問題ですか？」

エージェントはプロジェクト設定を確認し、オファリングにプロダクトが紐付いたパッケージが存在するかを検証し、根本原因を特定します。

「Kotlin MultiplatformプロジェクトでRevenueCatを設定する手順を教えて」

エージェントはCodelabsの内容にもアクセスできるため、プラットフォームに合わせたステップバイステップのガイダンスを提供できます。

「offering lookup key と offering ID の違いは何ですか？コードではどちらを使うべきですか？」

エージェントは、一般的なドキュメントの説明だけでなく、実際のプロジェクト設定の文脈も踏まえて概念を説明します。

モデル選択

AIエージェントは複数のモデルに対応しており、入力バーの歯車アイコンから切り替えることができます。利用可能なモデルには、GPT-4.1、GPT-4.1 Mini、Claude Sonnet 4、Claude Haiku 4.5などがあり、用途に応じて性能と応答速度のバランスを調整できます。

ダッシュボードパネル：コンテキスト切り替えなしで指標を確認

ダッシュボードパネルでは、ブラウザを開くことなく、RevenueCatプロジェクトの状態をリアルタイムで確認できます。サブスクリプションデータは折りたたみ可能なセクションとして整理されており、ツールウィンドウを開くと読み込まれます。

収益概要

最上部のセクションでは、主要な指標を一目で確認できます。アクティブなサブスクライバー数、アクティブなトライアル数、MRR、収益が表示されます。これらの数値はRevenueCat APIから直接取得されるため、常に最新のデータを確認できます。

マイルストーン

指標の下には、サブスクリプションビジネスの達成状況を追跡するマイルストーンセクションがあります。初めてのサブスクライバー獲得、収益の節目、トライアルに関するマイルストーンなど、RevenueCatダッシュボードで確認できるものと同じ内容が、IDE内に直接表示されます。

設定済みオファリング

オファリングセクションでは、すべてのオファリングと、それに紐づくパッケージおよびプロダクトが一覧表示されます。各オファリングを展開すると、パッケージ構成や紐づいているプロダクト、ペイウォールが設定されているかどうかを確認できます。ペイウォールが設定されているオファリングには、ペイウォールビルダーへの直接リンクが表示されます。

ペイウォールセクション

専用のペイウォールセクションでは、すべてのペイウォールがステータスバッジ付きで表示されます。Published（緑）、Draft（黄）、Has Unpublished Changes（オレンジ）といった状態が色分けされています。各ペイウォールには状態に応じたアクションボタンが用意されており、Edit、Publish、Unpublish、Discard、Duplicate、Deleteといった操作が可能です。Editボタンをクリックするとブラウザでペイウォールビルダーが開きます。ライフサイクル関連の操作はAPIを直接呼び出し、パネルは自動で更新されます。

結論

RevenueCat IntelliJ Pluginは、IDEを完全なサブスクリプション管理環境へと変えます。OAuthサインインによって手動のAPIキー設定は不要になり、ダッシュボードパネルではブラウザに切り替えることなく、指標、マイルストーン、オファリング、ペイウォールを確認できます。AIエージェントは単なるチャットボットをはるかに超えた存在です。オファリングの作成、AIによるペイウォール生成、Charts APIを用いた収益データの分析、統合のデバッグ、そして安全かつレビュー可能な形でのソースコード編集までを実行できます。

特にAIによるペイウォール生成は、大幅な時間短縮につながります。ダッシュボード上でオファリングの作成、パッケージ設定、プロダクトの紐付け、ペイウォールのデザインを手作業で行う代わりに、やりたいことを1文で伝えるだけで、エージェントがすべての工程を処理します。その結果、ビルダー上で確認可能な、完全にデザインされたペイウォールが完成します。

コードレビューの合間にMRRを確認する場合でも、新しいオファリング用のペイウォールを生成する場合でも、チャーンのトレンドを分析する場合でも、あるいはSDKの統合コードの雛形作成をエージェントに依頼する場合でも、このプラグインは開発の流れを途切れさせません。目的はシンプルです。タブの切り替えに費やす時間を減らし、サブスクリプションビジネスの構築により多くの時間を使うことです。RevenueCat IntelliJ Pluginは、 JetBrains Marketplace（RevenueCat Dashboard） からインストールできます。

Eitan Bernath

Eitan Bernathのカテゴリーでは、「作ろうと思っていた料理を実際に作れるようにする」ことがテーマでした。インスピレーションを行動に変えるツールを考えてみてください。レシピ動画やリンクから買い物リストを生成し、作りたい料理を整理し、すぐに始められるようにするアプリです。

受賞アプリ：Preplo – 料理動画を“作れるレシピ”へ

Preploは、料理のインスピレーションを実際に作れる形へと変えます。YouTube、TikTok、Instagramのリンクを貼り付けるだけで、分量、タイムスタンプ付きの手順、推定コスト、栄養情報を含む構造化されたレシピを瞬時に生成します。「あとで作ろう」と保存した状態から、「実際に食卓に並ぶ」状態へのハードルを大きく下げてくれます。

さらに、レシピはその場で調整可能です。よりスパイシーに、ヴィーガン仕様に、あるいは低糖質に変更すれば、内容は自動で更新されます。Expo React NativeとNext.jsバックエンドで構築されており、処理済みの動画はキャッシュされるため、同じ動画が二度解析されることはありません。

Devpostリンク

Gabby Beckford

Gabby Beckfordのブリーフでは、目標を日々の小さな行動に落とし込み、前向きでモチベーションを高めてくれるアプリを作ることが求められました。チャレンジ機能、ストリーク（継続記録）や達成の可視化、進捗トラッキング、そして進歩を楽しく感じられるゲーミフィケーション要素を備えたものです。対象は、夢の旅行や人生のアップグレードを実現したいと考えている意欲的な女性たち。しかし、日常の忙しさに阻まれたり、インスピレーションと行動の間で足踏みしてしまうことが多い層です。

受賞アプリ：Bloom – 大きな夢を日々の達成へ

Bloomは、夢を日常の一歩一歩へと変えるための行動を後押しする、女性向けのゲーミフィケーション型パーソナルグロースアプリです。単なるToDoリストではなく、目標、お金への自信、マインドセット、そして旅行といった要素をひとつのモチベーションシステムとして統合しています。

中心となるのは「Digital Garden」。日々の習慣が可視化された成長として反映されるため、進歩を実感できます。ユーザーは「Dream（夢）」を設定し、短時間で遊べる金融ミニゲームに挑戦し、AIのガイド付きでジャーナリングを行い、インタラクティブなマップで旅の記録を追跡できます。Flutterで構築され、SupabaseとMapboxによって支えられているBloomは、自己成長を“圧倒的”ではなく“前向き”に感じられる体験へと変えています。

Devpostリンク

Quin Gable

常に移動していると、旅先での出会いや友人づくりは簡単ではありません。デジタルノマドのQuin Gableは、ノマド向けのデーティング機能やアクティビティベースの友達探し、さらにはバン改造プロジェクト向けの有料「ビルダーヘルプ」セクションまで備えた、バンライフ向けアプリを求めていました。コミュニティの安全性を保つため、アプリは招待制または認証制とし、安全で意図的なつながりが生まれる設計が必要でした。

受賞アプリ：WanderBase – ロードライフのためのデーティング＆コミュニティ

WanderBaseは、バンライファーやノマドのために特化して作られたデーティング＆コミュニティアプリです。無限にスワイプする代わりに、ユーザーは自分のライフスタイルや旅の雰囲気を反映した、手描き風でカスタマイズ可能なバンのアバターを探索します。これはロードライフらしさを感じさせる、遊び心のあるアプローチです。

招待制を採用し、ルートベースのマッチング、双方合意でのチャット解放、バン改造プロジェクト向けのヘルプ掲示板などを備えています。React NativeとFirebaseで構築され、サーバーサイドでのマッチングと厳格なセキュリティルールにより、信頼性を担保しながら、安全性と楽しさの両立を実現しています。

Devpostリンク

Sam Beckman

Samはリマインダー中心の生活を送っていますが、AndroidとiOSを切り替えるたびに、リマインダーの仕組みを一から作り直さなければならないという課題がありました。彼のブリーフは、iOSとAndroidの両方で動作する、美しく完全に機能するリマインダーアプリを作ることでした。通知からのカスタムスヌーズ、強力な繰り返しルール、そして一度消せばすべての端末で同期して消える“真の同期”が必要とされました。

受賞アプリ：Remy Reminders – ついに同期するクロスプラットフォームのリマインダー

Remyは、iOSとAndroidを行き来する際にリマインダー環境を作り直さなければならないという現実的なストレスを解消します。どのプラットフォームを使っていても洗練されたリマインダー体験を提供し、シンプルかつ効果的なルール作成機能や、通知の一時停止機能などを備えています。

内部では、カスタムのオフラインファースト同期エンジンと、APNsおよびFCMと直接通信する通知システムが動作しており、すべてを正確に同期させています。React Native（Expo）とConvexで構築されたRemyは、どのデバイスを使っていても信頼できるリマインダー体験を実現することに注力しています。

Devpostリンク

Better CreatingのSimon

Simonのオーディエンスは、生産性や優れたデザイン、そして自己成長のための仕組みづくりを好みます。その中核にあるのがコーチングです。Simonは、コーチングによって得られる成長や自己確信を、より多くの人が手軽に体験できるようにしたいと考えました。そのために、ユーザーがAIコーチを閲覧・作成・共有でき、個人的な背景や価値観を追加し、すぐに対話を始められる、クリーンでミニマルなモバイルアプリを目指しました。

受賞アプリ：Editor – 明確に決断する

Editorは、従来のコーチングやAIチャット体験を根本から再設計しています。終わりのない会話を促すのではなく、ビルダーやクリエイターが迅速かつ意図的に意思決定へ到達できるよう設計されています。単なるコーチングアプリにとどまらず、ユーザーは「優先順位付け」「アイデアのレビュー」「トレードオフの比較」など、構造化された思考モードを選択できます。

各セッションは、素早く意思決定に到達し、その時点で終了するよう設計されています。成果は意思決定ブリーフやロードマップに変換でき、Notionへエクスポートすることも可能です。ネイティブのSwiftUIアプリとして構築されたEditorは、意図的にミニマルかつフォーカスされた体験を維持しています。

Devpostリンク

Rebecca Louise

Rebeccaが繰り返し耳にしてきたのは、ママたちは時間が足りず、経済的自立を望みながらも、実践的なサポートを必要としているということでした。彼女のブリーフは、日常的に役立つ節約ガイダンス（買い物の置き換え、まとめ調理、コスト比較、住宅リフォームの節約など）に加え、投資の基礎へ無理なく踏み出せる道筋を提供するアプリを作ることでした。ユーザーが圧倒されることなく、今あるものを着実に増やしていける設計が求められました。

受賞アプリ：Sunny Money – 忙しいママのためのファイナンシャルサポート

Sunny Moneyは、忙しいママたちが1日わずか数分で金融リテラシーと自信を高められるアプリです。日常的な節約アドバイスと、貯蓄や投資のシンプルな入門コンテンツを組み合わせています。

短時間で学べるレッスン、実用的な計算ツール、デイリーチャレンジ、そしてAIアシスタントにより、経済的な前進が無理なく感じられる設計になっています。React NativeとExpoで構築されたSunny Moneyは、ママたちの限られた時間を尊重しながら、実用的で本当に役立つツールを提供します。

Devpostリンク

VisualFaktoryのJosh

投資家は、株式、金、投資信託、債券、不動産などを複数のプラットフォームで管理しています。管理は煩雑で、全体像を一目で把握するのは困難です。Joshは、すべてを一元管理できるアプリを求めていました。可能な限りリアルタイムの価格更新を取得し、非上場商品には償却やリマインダーのアラートを設定でき、さらにプレミアム機能としてリスク分析や分散状況（国別・セクター別エクスポージャーなど）を確認できるアプリです。

受賞アプリ：Folio – ポートフォリオ全体を一目で把握

Folioは、分散した投資資産をひとつの洗練されたiOSダッシュボードにまとめます。株式、ETF、暗号資産、不動産、預貯金など、すべてを一か所で管理できるため、純資産全体やリスクエクスポージャーを一画面で把握できます。

ライブ価格、パフォーマンス分析、ウィジェット、アラートに加え、実際の保有資産を理解し、リバランスやポジション調整を支援するAIアシスタントも搭載しています。React NativeとSupabaseで構築されたFolioは、ポートフォリオ管理をシンプルかつ実践的なものに保ちます。

Devpostリンク

まとめ

7つのまったく異なるブリーフに対して、受賞アプリに共通していたものがあります。それは「フォーカス」です。

彼らは何でもやろうとはしませんでした。特定のオーディエンスと明確な課題を選び、その中心に据えてプロダクトを構築しました。バンライフ向けアプリは信頼と安全性を最優先にしました。リマインダーアプリはクロスプラットフォーム同期に徹底的にこだわりました。ファイナンス系アプリはユーザーの時間を尊重しました。AIコーチアプリはシンプルさに自ら制約を課しました。それぞれのチームは機能を追い求めるのではなく、意図的なトレードオフを選択しました。

これでコンテストは終了ですが、皆さんが引き続きアプリ開発を続け、そして何より実際にユーザーにダウンロードしてもらうことに取り組んでくれることを願っています。

Shipyardはいかがでしたか？楽しめましたか？改善してほしかった点はありますか？

ぜひご意見をお聞かせください。TwitterやLinkedInでお知らせいただくか、参加者の皆さんにお送りするアンケートにもご回答ください。

本記事では、なぜクロスプラットフォームのサブスクリプション状態の実装がこれほど難しいのかを掘り下げ、Google Play BillingとStoreKitの根本的な非互換性を検証し、ゼロからクロスプラットフォームのエンタイトルメント同期を構築するには何が必要かを見ていきます。そして、特に小規模チームやインディー開発者にとって、必要なエンジニアリング工数を大幅に削減できる自然な解決策として、RevenueCatのアイデンティティシステムがどのように機能するかを紹介します。

根本的な問題：1人のユーザー、2つのエコシステム

「Premium」サブスクリプションを提供するフィットネスアプリを考えてみましょう。あるユーザーがiPhoneのApp Store経由でサブスクに登録します。1週間後、そのユーザーはAndroidタブレットを購入し、あなたのアプリをダウンロードします。同じアカウントでログインし、当然のようにプレミアム機能が利用できることを期待します。では、実際には何が起きるのでしょうか？

クロスプラットフォームの基盤がなければ、Androidアプリはそのユーザーが有効なサブスクリプションを持っていることを認識できません。Google Play Billingは、Google Play経由で行われた購入しか把握していません。Appleのサーバー上にあるApp Storeのレシートは、Androidアプリからは見えないのです。その結果、ユーザーはすでに支払いをしているにもかかわらず、再度サブスク登録を求めるペイウォールを目にすることになります。

\/\/ On the Android side, this returns nothing
val params = QueryPurchasesParams.newBuilder()
    .setProductType(BillingClient.ProductType.SUBS)
    .build()

billingClient.queryPurchasesAsync(params) { billingResult, purchases ->
    \/\/ purchases is empty because the user subscribed through Apple
    \/\/ The Android app has no way to know about the iOS subscription
    if (purchases.isEmpty()) {
        showPaywall() \/\/ User sees this despite having an active subscription
    }
}

これはバグではありません。想定どおりの挙動です。各課金システムは独立して動作しており、それらを橋渡しするには、どちらのプラットフォームも提供していない大規模なインフラが必要になります。

2つの課金システム、相互運用性はゼロ

なぜクロスプラットフォーム同期がこれほど難しいのかを理解するには、GoogleとAppleが購入情報をどれほど異なる方法で表現しているかを理解する必要があります。これは単なるAPIの細かな違いではありません。根本的に異なるアーキテクチャなのです。

レシート形式と検証

AppleとGoogleは、購入が実際に行われたことを証明するために、まったく異なる仕組みを採用しています。

Google Playは購入トークンモデルを採用しています。ユーザーがサブスクに登録すると、アプリは購入トークンを受け取ります。このトークンをGoogle Play Developer APIに送信すると、現在のサブスクリプション状態が返されます。このトークン自体は意味を持たない不透明な文字列です。

一方、Appleは署名付きトランザクションモデルを採用しています。StoreKit 2では、購入情報はJSON Web Signature（JWS）として提供され、サーバー側でAppleの公開鍵を用いて検証できます。各トランザクションは、暗号学的に署名された自己完結型の記録です。

これは、同じ概念を異なるAPIでラップしているだけではありません。信頼の所在に対する哲学そのものが異なります。Googleは「我々のサーバーに問い合わせれば状態を教える」と言い、Appleは「暗号署名された証明を渡すので、自分で検証せよ」と言っているのです。

リアルタイム通知

両プラットフォームとも、サブスクリプションイベントに関するサーバー間通知（server-to-server notifications）を提供しています。しかし、その通知システムは大きく異なります。

GoogleはCloud Pub/Subを通じて通知を配信するため、Pub/Subサブスクリプションと、それを処理するサービスをセットアップする必要があります。一方Appleは、設定したURLに対してHTTPS POSTリクエストを直接送信します。イベント名も異なり、ペイロード構造も異なり、各通知タイプに含まれる情報も異なります。

つまり、バックエンド側では、認証方法も、パースロジックも、状態遷移（ステートマシン）の解釈も異なる、2つの完全に別々の通知処理パイプラインが必要になるのです。

プロダクト設定

サブスクリプションプロダクトの定義方法も、プラットフォーム間で異なります。

Google Playは2022年にベースプランとオファーを導入し、階層型のプロダクトモデルを採用しました。1つのサブスクリプションには1つ以上のベースプランが含まれ、それぞれに異なる価格フェーズを持つ複数のオファーを設定できます。単一のサブスクリプションプロダクトIDに、月額・年額のベースプラン、導入オファー、プロモーション価格などをすべて含めることができ、これらはPlay Console上で設定されます。

一方、Appleのプロダクトモデルはよりフラットです。App Store Connectにおける各プロダクトIDは、単一の期間を持つ1つのサブスクリプションを表します。月額と年額の両方を提供する場合は、2つの別々のプロダクトIDを作成し、それらをサブスクリプショングループにまとめます。導入オファーやプロモーションオファーは、ネストされた構造ではなく、各プロダクト単位で設定されます。

この構造の違いにより、Google PlayのサブスクリプションプロダクトとAppleのサブスクリプションプロダクトの間には、1対1の対応関係は存在しません。そのため、バックエンド側では、プラットフォーム固有のプロダクト識別子を統一されたエンタイトルメント概念へ変換するマッピングレイヤーを維持する必要があります。

自前でクロスプラットフォーム同期を構築する

サードパーティのサービスを使わずにクロスプラットフォームのサブスクリプション同期を構築する場合、アーキテクチャは次のようになります。この作業量を理解しておくことは、最終的にマネージドなソリューションを選ぶ場合でも重要です。というのも、なぜこの問題が本質的に難しいのかが見えてくるからです。

ステップ1：統一されたユーザーID（ユーザー同一性）

最初に必要なのは、プラットフォームをまたいで機能するユーザーID（ユーザー同一性）システムです。各プラットフォームにはそれぞれ独自の「ユーザー」の概念がありますが、どちらももう片方の存在を認識しません。そこで、iOSとAndroidの両方が購入情報を紐づけられるサーバー側のユーザーアカウントが必要になります。

\/\/ Android client: associate purchase with your user account
fun postPurchaseToBackend(purchase: Purchase, userId: String) {
    val request = PurchaseVerificationRequest(
        platform = "android",
        purchaseToken = purchase.purchaseToken,
        productId = purchase.products.first(),
        userId = userId,
    )

    backendApi.verifyAndRecordPurchase(request)
}

iOS側についても、Android側と大きく変わりません：

\/\/ iOS client: associate purchase with your user account
func postPurchaseToBackend(transaction: Transaction, userId: String) async {
    let request = PurchaseVerificationRequest(
        platform: "ios",
        transactionId: String(transaction.originalID),
        productId: transaction.productID,
        userId: userId
    )

    await backendAPI.verifyAndRecordPurchase(request)
}

両方のクライアント（iOS/Android）は、同じ userId を付けて購入データをバックエンドに送信します。バックエンドは、各購入を適切なプラットフォーム（Apple/Google）のAPIで検証し、その結果得られたエンタイトルメント（権利）を、統一されたユーザーアカウントに紐付けて記録する必要があります。

ステップ2：2系統のレシート検証

バックエンドは、両プラットフォーム（iOS/Android）からの購入を検証できる必要があります。そのためには、まったく異なる2つの検証API（Apple用とGoogle用）に統合することになります。

\/\/ Backend: platform-specific verification
class PurchaseVerifier(
    private val playDeveloperApi: AndroidPublisher,
    private val appStoreServerApi: AppStoreServerAPIClient,
) {
    suspend fun verify(request: PurchaseVerificationRequest): VerificationResult {
        return when (request.platform) {
            "android" -> verifyGooglePurchase(request)
            "ios" -> verifyApplePurchase(request)
            else -> VerificationResult.InvalidPlatform
        }
    }

    private suspend fun verifyGooglePurchase(
        request: PurchaseVerificationRequest,
    ): VerificationResult {
        val subscription = playDeveloperApi
            .purchases()
            .subscriptionsv2()
            .get(packageName, request.purchaseToken)
            .execute()

        return if (subscription.subscriptionState == "SUBSCRIPTION_STATE_ACTIVE") {
            VerificationResult.Valid(
                expiryTime = subscription.lineItems[0].expiryTime,
                productId = subscription.lineItems[0].productId,
                platform = "android",
            )
        } else {
            VerificationResult.Expired
        }
    }

    private suspend fun verifyApplePurchase(
        request: PurchaseVerificationRequest,
    ): VerificationResult {
        \/\/ Uses Apple's App Store Server API
        val statusResponse = appStoreServerApi
            .getAllSubscriptionStatuses(request.transactionId)

        val activeSubscription = statusResponse.data
            .flatMap { it.lastTransactions }
            .find { it.status == Status.ACTIVE }

        return if (activeSubscription != null) {
            val transactionInfo = activeSubscription.signedTransactionInfo
            VerificationResult.Valid(
                expiryTime = transactionInfo.expiresDate,
                productId = transactionInfo.productId,
                platform = "ios",
            )
        } else {
            VerificationResult.Expired
        }
    }
}

各検証フローには、それぞれ認証設定、エラーハンドリング、レスポンス解析が必要です。Google 側ではサービスアカウントの認証情報が必要になります。Apple 側では App Store Connect の秘密鍵で署名した JWT が必要です。さらに、レスポンス形式には共通の構造が一切ありません。

ステップ3：統一されたエンタイトルメントストレージ

バックエンドには、プラットフォーム固有のプロダクトをプラットフォーム非依存のエンタイトルメントにマッピングするデータモデルが必要です。

\/\/ Backend entitlement model
data class UserEntitlement(
    val userId: String,
    val entitlementId: String,         \/\/ e.g., "premium"
    val isActive: Boolean,
    val sourcePlatform: String,        \/\/ "android" or "ios"
    val platformProductId: String,     \/\/ Platform-specific product ID
    val platformPurchaseToken: String, \/\/ Platform-specific purchase proof
    val expiresAt: Instant?,
    val lastVerifiedAt: Instant,
)

\/\/ Product mapping configuration
val productToEntitlementMap = mapOf(
    \/\/ Google Play products
    "premium_monthly:monthly-base" to "premium",
    "premium_annual:annual-base" to "premium",
    \/\/ App Store products
    "com.yourapp.premium.monthly" to "premium",
    "com.yourapp.premium.annual" to "premium",
)

いずれかのクライアントがエンタイトルメントを問い合わせた際、バックエンドは、そのエンタイトルメントがどのプラットフォームで発生したものであっても、ユーザーに有効なエンタイトルメントが存在するかどうかを確認します。

\/\/ Backend endpoint
fun getEntitlements(userId: String): EntitlementResponse {
    val entitlements = entitlementRepository.findActiveByUserId(userId)

    return EntitlementResponse(
        entitlements = entitlements.map { entitlement ->
            EntitlementInfo(
                id = entitlement.entitlementId,
                isActive = entitlement.isActive &&
                    (entitlement.expiresAt?.isAfter(Instant.now()) ?: true),
                expiresAt = entitlement.expiresAt,
                sourcePlatform = entitlement.sourcePlatform,
            )
        }
    )
}

ステップ4：2系統の通知処理

エンタイトルメントをリアルタイムで同期し続けるためには、バックエンドが両プラットフォームからの通知を同時に処理できる必要があります。

\/\/ Google Play RTDN handler
fun handleGoogleNotification(message: PubSubMessage) {
    val notification = parseDeveloperNotification(message)
    val purchaseToken = notification.subscriptionNotification.purchaseToken

    when (notification.subscriptionNotification.notificationType) {
        NotificationType.SUBSCRIPTION_RENEWED -> refreshGoogleEntitlement(purchaseToken)
        NotificationType.SUBSCRIPTION_CANCELED -> markGoogleEntitlementCanceled(purchaseToken)
        NotificationType.SUBSCRIPTION_EXPIRED -> expireGoogleEntitlement(purchaseToken)
        NotificationType.SUBSCRIPTION_REVOKED -> revokeGoogleEntitlement(purchaseToken)
        \/\/ ... handle all notification types
    }
}

\/\/ Apple Server Notification handler
fun handleAppleNotification(signedPayload: String) {
    val notification = verifyAndDecodeAppleNotification(signedPayload)
    val transactionInfo = notification.data.signedTransactionInfo

    when (notification.notificationType) {
        "DID_RENEW" -> refreshAppleEntitlement(transactionInfo)
        "DID_CHANGE_RENEWAL_STATUS" -> updateAppleRenewalStatus(transactionInfo)
        "EXPIRED" -> expireAppleEntitlement(transactionInfo)
        "REVOKE" -> revokeAppleEntitlement(transactionInfo)
        \/\/ ... handle all notification types
    }
}

各通知ハンドラーは、イベント名も、ペイロード構造も、状態遷移（ステートマシン）の意味づけも異なります。グレース期間の扱いも異なります。返金フローも異なります。さらには「解約」という概念でさえ、両プラットフォーム間で微妙な違いがあります。

実際に必要となる工数の規模

クロスプラットフォームのサブスクリプション同期を構築するには、専用のインフラが必要になります。さらに、GoogleもAppleも課金システムを定期的にアップデートしています。Googleは2022年にbase planとofferを導入し、大幅なバックエンド変更が求められました。AppleはStoreKit 2をリリースし、まったく新しいトランザクションモデルを導入しました。こうした大きな変更があるたびに、インフラを適応させるためのエンジニアリング時間が必要になります。

専任のバックエンドエンジニアを抱える大規模チームであれば、これは対応可能かもしれません。しかし、両プラットフォーム向けにサブスクリプションアプリをリリースしようとしている小規模チームやインディー開発者にとっては、これはコアプロダクトとは直接関係のない数か月分の開発作業を意味します。

RevenueCatのアイデンティティシステム：自然な解決策

RevenueCatは、統一されたアイデンティティおよびエンタイトルメントシステムによって、クロスプラットフォーム問題を根本から解決します。前述のようなインフラを自前で構築する代わりに、RevenueCatがそれをサービスとして提供します。この仕組みを成立させている重要な設計判断が、app user IDという抽象化です。

アイデンティティシステムの仕組み

RevenueCat SDKを設定する際、独自のユーザーIDを指定することも、RevenueCatに匿名IDを生成させることもできます。

\/\/ Android: Configure with your own user ID
Purchases.configure(
    PurchasesConfiguration.Builder(context, "your_revenuecat_api_key")
        .appUserID("user_12345")
        .build()
)

iOS版は以下のような感じになります：

\/\/ iOS: Configure with the same user ID
Purchases.configure(
    with: .builder(withAPIKey: "your_revenuecat_api_key")
        .with(appUserID: "user_12345")
        .build()
)

両プラットフォームで同じ appUserID を使用すると、RevenueCatのバックエンド上に単一のサブスクライバーレコードが作成されます。ユーザーがどちらのプラットフォームでサブスク登録しても、RevenueCatがレシートを検証し、エンタイトルメントを記録し、そのユーザーIDに紐づけます。もう一方のプラットフォームのSDKが customer info を問い合わせると、他プラットフォーム由来のサブスクリプションも含めた完全なエンタイトルメント状態が返されます。

匿名ユーザーから認証ユーザーへの移行フロー

RevenueCatは、ユーザーが最初は匿名で利用し、後からアカウントを作成するという一般的なシナリオにも対応しています。ユーザーがアプリを初めて開いた際、RevenueCatは $RCAnonymousID:<uuid> という形式の匿名IDを生成します。アカウント作成前にサブスク登録した場合、そのサブスクリプションはこの匿名IDに紐づけられます。

その後、ユーザーがアカウントを作成してログインすると、RevenueCatの logIn メソッドによって、匿名ユーザーに紐づいていたすべての購入が、認証済みユーザーに移行されます。

Purchases.sharedInstance.logIn(
    newAppUserID = "user_12345",
    callback = object : LogInCallback {
        override fun onReceived(customerInfo: CustomerInfo, created: Boolean) {
            \/\/ customerInfo now contains entitlements from:
            \/\/ 1. Any previous purchases made under the anonymous ID
            \/\/ 2. Any purchases previously associated with "user_12345"
            \/\/ 3. Purchases from ANY platform linked to this user

            val isPremium = customerInfo.entitlements["premium"]?.isActive == true
        }

        override fun onError(error: PurchasesError) {
            \/\/ Handle error
        }
    }
)

created ブール値は、そのユーザーが新規ユーザーか既存ユーザーかを示します。既存ユーザーである場合、RevenueCatは購入履歴をマージします。これはクロスプラットフォームのシナリオにおいて非常に重要です。たとえば、最初にiOSでサブスク登録し、その後Androidアプリをインストールしたユーザーでも、同じユーザーIDでログインすれば、エンタイトルメントが自動的に引き継がれます。

CustomerInfo：ひとつのオブジェクトで、すべてのプラットフォームを

CustomerInfo オブジェクトは、クロスプラットフォームのエンタイトルメント問題に対するRevenueCatの回答です。あらゆるプラットフォームのサブスクリプション状態を集約し、単一の、簡単に問い合わせ可能なオブジェクトとして提供します。

Purchases.sharedInstance.getCustomerInfoWith { customerInfo ->
    val premiumEntitlement = customerInfo.entitlements["premium"]

    if (premiumEntitlement?.isActive == true) {
        \/\/ User has premium access, regardless of which platform they subscribed on
        val store = premiumEntitlement.store
        \/\/ Could be Store.APP_STORE, Store.PLAY_STORE, Store.AMAZON, etc.

        val expirationDate = premiumEntitlement.expirationDate
        val willRenew = premiumEntitlement.willRenew

        showPremiumContent()
    } else {
        showPaywall()
    }
}

各エンタイトルメントの store プロパティは、そのサブスクリプションがどのプラットフォーム由来かを示します。しかし、アクセスを付与する際にそれを確認する必要はありません。重要なのは isActive プロパティだけであり、これはすべてのプラットフォームで共通して機能します。

これが重要なポイントです。RevenueCatは、クロスプラットフォームのインフラ問題を、単一のプロパティチェックに変換します。AndroidアプリはAppleのレシート検証方法を知る必要がありません。iOSアプリもGoogle Playのpurchase tokenについて理解する必要はありません。これらはすべてRevenueCatのバックエンドが処理し、 CustomerInfo を通じて統一された状態を提供します。

裏側で何が起きているのか

ユーザーがiOSでサブスク登録し、その後Androidアプリを開いた場合、次のような流れになります。

1. iOS SDKがApp StoreのレシートをRevenueCatのバックエンドに送信します。
2. RevenueCatがAppleのサーバーでレシートを検証し、ユーザーのapp user IDに対してエンタイトルメントを記録します。
3. 更新、解約、請求エラーなどを追跡するために、RevenueCatがApple Server Notificationsに登録します。
4. Androidアプリが起動し、getCustomerInfo を呼び出すと、SDKは同じapp user IDをRevenueCatのバックエンドに送信します。
5. RevenueCatは、iOS由来のサブスクリプションを含む完全なエンタイトルメント状態を返します。
6. Androidアプリはプレミアムエンタイトルメントの isActive == true を確認し、アクセスを付与します。

すべての更新イベント、グレース期間、解約、期限切れはRevenueCat側でサーバー処理されます。両プラットフォームは、プラットフォーム固有のコードを書くことなく、常に最新のサブスクリプション状態を取得できます。

サブスクリプション管理の扱い

クロスプラットフォームのサブスクリプションで実務的に重要なのが、管理URLの振り分けです。iOSで登録したユーザーは、Google PlayではなくApp Store経由でサブスクリプションを管理する必要があります。RevenueCatはこれを managementURL プロパティで処理します。

Purchases.sharedInstance.getCustomerInfoWith { customerInfo ->
    val managementUrl = customerInfo.managementURL

    \/\/ This URL points to the correct store based on where the user subscribed
    \/\/ - App Store subscription settings for iOS purchases
    \/\/ - Google Play subscription settings for Android purchases

    showManageSubscriptionButton(managementUrl)
}

これにより、ユーザーがGoogle Playからサブスクリプションを解約しようとしても見つからない、なぜなら実際の契約はApple側にある、といった混乱した状況を防ぐことができます。

開発スピードへの影響

クロスプラットフォーム同期を自前で構築する場合と、RevenueCatを利用する場合とでは、実装コストに大きな差があります。AndroidとiOSの両方でサブスクリプションアプリを提供するチームを想定して、両者を比較してみましょう。

RevenueCatを使わない場合

2つのレシート検証統合を含むバックエンドサーバー、2系統の通知処理パイプライン、ユーザーアイデンティティシステム、エンタイトルメントデータベース、そして両プラットフォームからバックエンドと通信するためのクライアント側コードを構築・維持する必要があります。初期開発だけで10〜18週間を要し、さらに両プラットフォームの進化に合わせた継続的なメンテナンスも必要になります。

RevenueCatを使う場合

実装は、各プラットフォームでSDKにapp user IDを設定し、 CustomerInfo を確認してアクティブなエンタイトルメントをチェックし、ペイウォールを表示するだけに簡略化されます。バックエンドのインフラはすべてRevenueCatが処理します。

\/\/ The entire Android-side implementation for cross-platform entitlements
class SubscriptionManager(private val context: Context) {

    fun initialize(userId: String) {
        Purchases.configure(
            PurchasesConfiguration.Builder(context, "your_api_key")
                .appUserID(userId)
                .build()
        )
    }

    fun checkAccess(onResult: (Boolean) -> Unit) {
        Purchases.sharedInstance.getCustomerInfoWith { customerInfo ->
            val isPremium = customerInfo.entitlements["premium"]?.isActive == true
            onResult(isPremium)
        }
    }
}

これが、Androidでクロスプラットフォームのサブスクリプションをサポートするために必要なコードのすべてです。iOS側のコードも同様に非常に簡潔です。バックエンドサーバーも、レシート検証も、通知処理も、エンタイトルメントデータベースも必要ありません。それらはすべてRevenueCatが管理します。

インディー開発者や小規模チームにとって、この違いは単なる時間短縮の問題ではありません。実現可能性そのものに関わる問題です。クロスプラットフォームのサブスクリプション基盤をゼロから構築するには、バックエンドの専門知識、サーバーホスティング、監視体制、そして継続的なメンテナンスが必要になります。多くの小規模チームにとって、こうした投資は現実的ではありません。その結果、クロスプラットフォーム対応自体を諦めるか、プラットフォームAPIの変更で簡単に壊れてしまう脆弱な仕組みを構築することになります。RevenueCatは、チームの規模を問わずクロスプラットフォームのサブスクリプションを実現可能にし、開発者が限られた時間を自社アプリを差別化する機能の開発に集中できるようにします。

結論

本記事では、クロスプラットフォームのサブスクリプション状態の管理が、なぜモバイルマネタイズにおいて最も難しい問題のひとつなのかを見てきました。Google Play BillingとAppleのStoreKitは、レシート形式、検証API、通知メカニズム、プロダクト構造に至るまで根本的に異なるシステムです。これらを橋渡しするには、統一されたアイデンティティシステム、二重のレシート検証、プラットフォームに依存しないエンタイトルメント保存、そして2系統の通知処理パイプラインが必要になります。

このインフラをゼロから構築するには数か月を要し、さらに両プラットフォームの進化に合わせた継続的なメンテナンスが求められます。大規模チームにとっては大きな投資ではあるものの対応可能な範囲かもしれません。しかし小規模チームやインディー開発者にとっては、コアプロダクト以上のエンジニアリング時間を消費しかねません。

RevenueCatのアイデンティティおよびエンタイトルメントシステムは、単一の CustomerInfo オブジェクトの背後にプラットフォーム差異を抽象化することで、この問題に対する自然な解決策を提供します。プラットフォーム間で共有されるapp user IDと、RevenueCatによるサーバーサイドのレシート検証および通知処理を組み合わせることで、数か月規模のインフラ構築プロジェクトは、数行のSDK設定に置き換わります。サブスクリプションがApp Store、Google Play、Amazon、あるいはWebのいずれで開始されたものであっても、アプリ側では isActive を確認してアクセスを付与するだけで済みます。

複数プラットフォームにまたがってユーザーに提供するサブスクリプションアプリを構築するチームにとって、この問題のスコープを理解することは、内製か外部サービス利用かという判断を行う上で重要です。マネージドソリューションを利用することで節約できた時間は、アプリの改善、ペイウォールの最適化、そしてプロダクトを真に差別化する機能の開発に振り向けることができます。

今回のSub Clubのエピソードでは、SkylightのCEOとCPOが、どのようにして高いサブスクリプションアタッチ率を持つ収益性の高いハードウェアビジネスを構築したのかを語ります。また、日常的な利用、感情に基づく価格設定、プロダクトの成熟度、小売流通について彼らが学んだ厳しい教訓についても共有しています。

Watch on YouTube

ハードウェア連動型サブスクリプションビジネスを構築しているすべての人に向けた、5つの重要なポイントを紹介します。

ハードウェア連動型サブスクリプションは、日常的な利用があってこそ機能する

ハードウェアデバイスはサブスクリプションを正当化できます——ただし、それが毎日使われている場合に限ります。

デバイスが使われずに放置されていると、継続課金はすぐに「なくてもいいもの」に感じられます。顧客は、自分が何に対して支払っているのかを疑い始めます。しかし、プロダクトが日々の習慣に組み込まれ——スケジュールを整理し、タスクを可視化し、家族間のコミュニケーションの中心になるようになれば——サブスクリプションはその価値の自然な延長として受け入れられます。

日々の接触頻度が、サブスクリプションのレバレッジを生み出します。

Skylightにとっての転機は、Calendarプロダクトが「家庭の鼓動（heartbeat of the home）」になったときでした。家族が毎日それに頼るようになると、サブスクリプションは単なる機能のアップセルではなく、より深い価値を解放する手段へと変わりました。

習慣的な利用がなければ、サブスクリプションは伸び悩みます。習慣があれば、複利のように積み上がります。

構築すべきときに、最適化ばかりしない

A/Bテストやファネル最適化は、着実な改善をもたらします。しかし、ときに最大の成長レバーはコンバージョンではなく、プロダクトそのものです。

限られたリソースの中で、Skylightは慎重な優先順位付けを迫られました。無数の小さな実験にリソースを分散させるのではなく、体験全体を強化する、本質的に価値のある機能を構築することに集中しました。

最適化は重要です。しかし、段階的ではなく飛躍的な成長は、多くの場合、プロダクトを意味のあるレベルで向上させるものをリリースすることから生まれます。

リソースが制約されているとき、優先順位付けそのものが戦略になります。

データだけでなく、顧客の感情に基づいて価格を決める

Skylightがサブスクリプション価格を見直した際、テストでは年間99ドルが収益最大化につながるという結果が出ました。

数字上では、ARPUを最も押し上げる価格でした。

しかし、定性調査は異なる示唆を与えました。79ドルは「妥当」と感じられた一方で、99ドルはチームの言葉を借りれば「嫌悪感を抱かれる領域（disgust territory）」に近づいていたのです。その感情的な反応は重要でした。

長期的なブランド価値を重視する企業にとって、短期的な収益最適化のために顧客の反感を買うリスクを取る価値はありませんでした。彼らは79ドルを選び、1ドルでも多く回収することよりも、好意や信頼を優先しました。

価格設定は単なる計算ではありません。それは感情的なポジショニングです。

スプレッドシートは、何が収益を最大化するかを教えてくれます。しかし、ロイヤルティを維持できるかどうかを教えてくれるのは、顧客との対話だけです。

マーケティングを拡大する前に、優れたプロダクトを作る

弱いプロダクトを、マーケティングで補うことはできません。

2021〜22年にかけて、SkylightはCalendarプロダクトを積極的にスケールさせようとしました。広告投資を増やし、ユーザー獲得を加速させました。しかし、成長は伸び悩み、数字は合いませんでした。

問題は広告ではなく、プロダクトそのものでした。

チームが体験をNet Promoter Score（NPS）40以上にまで高めるまでは、マーケティング費用は誤ったネガティブシグナルを生み、無駄な支出につながっていました。プロダクトが本当にユーザーに響くようになって初めて、スケールは現実的になりました。

プロダクトマーケットフィットが確立していない状態でマーケティングを拡大すると、摩擦を増幅させるだけです。

まずはプロダクトを正しく作ること。その後に成長エンジンを回すべきです。

小売パートナーシップは究極のインフルエンサー

ハードウェアにおいて、流通は影響力そのものです。

CostcoやBest Buyのような企業との小売パートナーシップは、有料広告では再現できない「品質の証明」を与えてくれます。信頼されている棚に並ぶこと自体が、大規模に顧客へ信頼性を示すシグナルになります。

D2C（直販）チャネルは高いサブスクリプションアタッチ率を生みやすい一方で、マルチチャネルでの流通はリーチを拡大し、ブランドの正当性を強化します。

ハードウェアはコピーできます。しかし、流通は簡単には真似できません。

Skylightにとって、小売は単なる販売チャネルではなく、成長エンジンであり、ポジショニング上の優位性でもありました。

成長・利益・長期的な信頼のバランスを取る

この5つの教訓を通して浮かび上がるのは、より深いテーマです。それは、成長と利益はしばしば異なる方向に引っ張り合うということです。

• サブスクリプションを摩擦なく導入すれば、利益率は下がる可能性があります。
• 価格を引き上げれば、ARPUは向上しますが、長期的な信頼を損なうかもしれません。
• ハードウェア価格を下げれば、成長は加速しますが、収益性は圧迫されます。
• 最適化に過度に集中すると、持続的な価値の構築から目がそれることもあります。

すべての意思決定にはトレードオフが伴います。

Skylightのアプローチが示しているのは、ハードウェア連動型サブスクリプションビジネスをスケールさせるとは、あらゆる指標を同時に最大化することではないということです。重要なのは、どのレバーが最も意味を持つのか、そしてそれをいつ引くべきかを見極めることです。

ハードウェア連動型サブスクリプションとは、単にデバイスに継続収益を重ねることではありません。日々の生活にとって欠かせない存在になること、感情的な知性を持って価格を設定すること、そしてスケールに値する強いプロダクトを構築することなのです。

🎧 これらの教訓の背景にある詳細な対話や実験については、Sub Clubのフルエピソードをぜひお聴きください。

なぜ複数のペイウォールを運用するのか？

なぜ複数のペイウォールを同時に管理する必要があるのか、疑問に思うかもしれません。以下は、このアプローチが特に有効なケースです。

• 移行期間：これまで独自のカスタムペイウォールを構築してきたが、段階的にRevenueCatのペイウォールへ移行したい場合。
• A/Bテスト：既存のハードコードされたペイウォールと、RevenueCatで新たに構築したペイウォールを比較テストしたい場合。
• ターゲット別オファー：特定のユーザーセグメント向けに、独自の価格設定やプロモーションオファーを提示する必要があり、高度にカスタマイズされた表示が求められる場合。
• 高度なロジック：複雑なオンボーディングフローや特定のユーザージャーニーに対応する必要がある場合。

アプリ側でどのペイウォールUIを表示するかを決定しつつ、すべての購入処理は引き続きRevenueCat SDKを通して行います。これにより、ロジックの重複や価格の不一致、エンタイトルメント関連のバグを防ぎながら、必要に応じて表示部分の完全なコントロールを維持できます。

エンドツーエンドのフロー例

全体像として、2種類のペイウォールタイプを持つアプリは次のように動作します。

1. ユーザーがペイウォールの分岐ポイントに到達する

• 例：オンボーディングの終了、機能のゲート、プロモーションの入口など

1. アプリが特定の Placement に対して Offerings をリクエストする

• Placement は、ユーザージャーニーのどこでペイウォールを表示するかを表します

1. RevenueCat が適切な Offering を返す

• 返される Offering は、ターゲティングルールに応じてユーザーごとに異なる場合があります

1. アプリが Offering のメタデータを確認する

• メタデータによって、どのペイウォールを表示すべきかが決まります

1. アプリが表示するペイウォール UI を選択する

• RevenueCat のペイウォール UI
• または、完全にカスタム実装したペイウォール UI

1. ユーザーがプロダクトを選択する

• プロダクト情報と価格データは常に RevenueCat から取得します

1. RevenueCat SDK 経由で購入を開始する

• ペイウォール UI がどちらでも、購入フローは同一です

1. RevenueCat がエンタイトルメントを更新する

• アプリが CustomerInfo に基づいてコンテンツを解放／制限する

この仕組みにより、表示は柔軟にしつつ、サブスクリプションシステムは一元化して整合性を保つことができます。さらに RevenueCat の Experiment 機能を使えば、異なる Placement やペイウォール間でコンバージョン成果をテスト・比較することも可能です。

RevenueCat Paywallの理解

RevenueCatのペイウォールは、ユーザーにプロダクトを表示するプロセスを簡素化するよう設計されています。RevenueCat Paywallsのドキュメントにある通り、RevenueCatダッシュボード上で直接、さまざまなペイウォールデザインを作成・管理・テストすることが可能です。プロダクト情報の取得も自動で処理され、ユーザーフレンドリーな形で表示されます。しかも、ペイウォールを変更するたびにアプリの新しいリリースをストアに提出する必要はありません。

ほとんどの新規アプリにとって、RevenueCatでペイウォールを実装するのが最適な選択です。ストアにアップデートを提出することなく、ペイウォールを継続的に改善・更新できるからです。

カスタム実装のペイウォールを実装する

前述のとおり、RevenueCatのPaywallだけでは要件を満たせないケースもあります。たとえば、アプリ内の重要なデザイン要素をペイウォールにも表示したい場合です。ゲーミフィケーションされたアプリであれば、途切れてしまった連続記録（broken streak）の可視化をペイウォール上に出して、「サブスクに登録すればこの途切れた記録を修復できる」ことをユーザーに伝えたい、といったケースが考えられます。

カスタム実装のペイウォールを採用する場合、UI/UXは基本的に自分たちでコントロールすることになります。一方で、バックエンド側の処理（プロダクト情報の取得や購入処理）については、引き続きRevenueCat SDKに依存します。

ステップ1：プロダクト情報を取得する

カスタム実装のペイウォールを作る最初のステップは、RevenueCatからプロダクト情報を取得することです。これは、ユーザーに正しいサブスクリプションの選択肢、価格、導入オファー（初回オファー）を表示するために不可欠です。詳細な手順は、Displaying Products のドキュメントを参照してください。ctions.

Swift では通常、 Purchases.shared.getOfferings() メソッドを使って設定済みの Offerings を取得します。同様に Kotlin では、Purchases.sharedInstance.getOfferingsWith() を使用します。 これにより Offering オブジェクトが取得でき、必要なプロダクト詳細がすべて含まれています。

        Purchases.shared.getOfferings { (offerings, error) in
            if let packages = offerings?.current?.availablePackages {
                self.display(packages)
            }
        }

Purchases.sharedInstance.getOfferingsWith({ error ->
  \/\/ An error occurred
}) { offerings ->
  offerings.current?.availablePackages?.takeUnless { it.isNullOrEmpty() }?.let {
    \/\/ Display packages for sale
  }
}

ステップ2：購入処理を実行する

ユーザーがカスタム実装のペイウォール上でプロダクトを選択したら、RevenueCatのSDKを使って購入を開始します。この手順については、Making Purchases のドキュメントで詳しく解説されています。

iOSでは Purchases.shared.purchase(package:)を使用し、AndroidではPurchases.sharedInstance.purchaseWith()を使用します。購入完了時の処理や、発生し得るエラーのハンドリングを忘れずに実装してください。

Purchases.shared.purchase(package: package) { (transaction, customerInfo, error, userCancelled) in
  if customerInfo.entitlements["your_entitlement_id"]?.isActive == true {
    \/\/ Unlock "pro" content              
  }
}

Purchases.sharedInstance.purchaseWith(
  PurchaseParams.Builder(this, aPackage).build(),
  onError = { error, userCancelled -> \/* No purchase *\/ },
  onSuccess = { storeTransaction, customerInfo ->
    if (customerInfo.entitlements["my_entitlement_identifier"]?.isActive == true) {
      \/\/ Unlock "pro" content
    }
  }
)

ステップ3：Entitlement（権限）の管理

RevenueCatのペイウォールを使用する場合でも、カスタム実装のペイウォールを使用する場合でも、entitlement（権限）の管理はRevenueCatが処理します。購入が成功すると、RevenueCatはユーザーの CustomerInfoを更新します。これを利用して、プレミアム機能へのアクセスを付与または制限できます。Swiftでは、 Purchases.shared.customerInfo()を使用して CustomerInfo を取得できます。

Purchases.shared.getCustomerInfo { (customerInfo, error) in
    \/\/ access latest customerInfo
}

Kotlinで

Purchases.sharedInstance.getCustomerInfoWith(
    onError = { error -> \/* Optional error handling *\/ },
    onSuccess = { customerInfo -> \/* Access latest customerInfo *\/ },

ペイウォールの条件付き表示ロジック

異なるペイウォールやOfferingを表示するロジックは、Placement または Offering metadata を使って制御できます。Placement を使うと、各Offeringをアプリ内のどこで表示するかを定義できます。一方、Offering metadata を使うと、Offeringに追加情報を付与でき、それをアプリ側で参照することで「カスタム実装のペイウォールを表示するのか」「RevenueCatのペイウォールを表示するのか」を切り替えることができます。

Placementによるターゲティング

Targeting by Placement を使うことで、アプリ内のペイウォール表示位置ごとに異なるOfferingを配信できます。たとえば、以下のような場所ごとに異なるペイウォールを表示できます。

• オンボーディング終了時（例：onboarding_end）
• ユーザーが有料機能を使おうとしたとき（例：feature_gate）
• セール実施中（例：sale_offer）

Placementを設計する際の基本は、理想的なカスタマージャーニーをどう補完するかを理解することです。たとえばセールを実施している場合、初回利用ユーザーと既存ユーザーでは、表示すべきオファーやコピーが異なる可能性があります。そのような場合は sale_offer というPlacementを定義します。

アプリがPlacementを指定してOfferingsを取得すると、RevenueCatはそのPlacementとユーザーに応じたOfferingを返します。これにより、カスタマージャーニーに応じたユニークなペイウォールを表示できます。Swiftでは、次のように実装できます。

Purchases.shared.getOfferings { offerings, error in
    if let offering = offerings?.currentOffering(forPlacement: "your_placement_identifier") {
        \/\/ Show paywall
    } else {
        \/\/ Do nothing or continue on to next view
    }
}

同様にKotlinでは:

Purchases.sharedInstance.getOfferingsWith({ error ->
    \/\/ An error occurred
}) { offerings ->
    offerings.getCurrentOfferingForPlacement("your-placement-identifier")?.let {
        \/\/ show paywall
    } ?: run {
        \/\/ Do nothing or continue on to next view
    }
}

Offering metadataを使ったターゲティング

異なる種類のペイウォールを運用し、カスタム実装のペイウォールに表示する内容を柔軟に制御するための鍵となるのが Offering metadata です。RevenueCatダッシュボードでは、対象のOfferingに移動し、「Edit」または「Configure metadata」（まだ設定していない場合）をクリックすることで、Metadataフィールドに有効なJSONを追加できます。

ダッシュボードで設定するMetadataは、たとえば次のような形式になります。

{
  "custom_paywall": true,
}

このmetadataは、SDKを呼び出して利用可能なOfferingsを取得する際に、Offeringデータに紐づけられます。そのため、このmetadataを使って、アプリ内でのペイウォール表示方法を動的に変更できます。

SDKでOffering metadataを使用する

Swiftでは、RevenueCat SDKの offerings メソッドを使って取得した Offering オブジェクトから、metadata に直接アクセスできます。

do {
    let offerings = try await Purchases.shared.offerings()

    if let offering = offerings.current {
        let useCustomPaywall = offering.metadata["custom_paywall"] as? Bool

        if useCustomPaywall == true {
            \/\/ Show custom paywall UI
        } else {
            \/\/ Show RevenueCat Paywalls UI
        }
    }
} catch {
    \/\/ An error occurred
}

そしてKotlinでは同じ方法で:

Purchases.sharedInstance.getOfferingsWith({ error ->
    \/\/ An error occurred
}) { offerings ->
    offerings.current?.let { offering ->
        val useCustomPaywall = offering.metadata["custom_paywall"] as? Boolean

        if (useCustomPaywall == true) {
            \/\/ Show custom built paywall UI
        } else {
            \/\/ Show RevenueCat Paywalls UI
        }
    }

metadataの値は本質的にオプションです。そのため、ダッシュボードで値が定義されていない場合でも、アプリやペイウォールが正常に動作するように実装する必要があります。

条件分岐ロジックの例

最後に残っているステップは、カスタム実装のペイウォールを表示するか、RevenueCat ペイウォールを表示するかを判定するロジックを適用することです。

func shouldShowCustomPaywall(offering: Offering) -> Bool {
    offering.getMetadataValue(for: "custom_paywall", default: false)
}

func showPaywall(for offering: Offering) {
    if shouldShowCustomPaywall(offering: offering) {
        \/\/ Show your custom paywall UI
        displayCustomPaywall(offering: offering)
    } else {
        \/\/ Show RevenueCat's default paywall or a paywall built with RevenueCat's templates
        displayRevenueCatPaywall(offering: offering)
    }
}

そしてKotlinでは:

fun shouldShowCustomPaywall(offering: Offering): Boolean {
    return offering.metadata["custom_paywall"] as? Boolean ?: false
}

fun showPaywall(offering: Offering) {
    if (shouldShowCustomPaywall(offering)) {
        \/\/ Show your custom paywall UI
        displayCustomPaywall(offering)
    } else {
        \/\/ Show RevenueCat's default paywall or a paywall built with RevenueCat's templates
        displayRevenueCatPaywall(offering)
    }
}

まとめ

独自に実装したカスタムペイウォールを、RevenueCatのペイウォールと併用することで、実験やターゲット別オファーにおける柔軟性を確保できます。プロダクト情報の取得や購入管理はRevenueCatに任せつつ、UI部分は自社のエンジニアリングで最適化することで、iOSおよびAndroidユーザーに対して高度に最適化された、魅力的なサブスクリプション体験を構築できます。このハイブリッドアプローチにより、フロントエンドの表現は自分たちでコントロールしながら、サブスクリプション基盤については堅牢で実績のあるバックエンドに依存することが可能になります。

短い答えは、イエス。どうやらそのようです。

次から次へと開発者が、App Reviewから同じリジェクト通知を受け取っています。そして理由はいつも同じです。無料トライアルをオン／オフできるトグルを含むペイウォールデザインについてです。もしあなたがiOSでこのパターンを使っているなら、注意が必要です。これは演習ではありません。

トグル型ペイウォールとは？

ご存じない方のために説明すると、「トグル型ペイウォール」とは、ユーザーにサブスクリプションオファーを提示し、無料トライアルを追加するか外すかを切り替えられるトグルスイッチを設けたペイウォールデザインのことです。多くの実装では、トグルはデフォルトでオフになっています。つまり、ユーザーは最初にトライアルなしのプランを目にします。スイッチをオンにすると、トライアル期間付きの別プラン（通常は年額ではなく週額プラン）に切り替わります。

この仕組みを広めたのは、2024年半ばのAdam Lyttleです。彼はこのデザインを導入することで、週次のアプリ収益が約2,500ドルから5,300ドル超へと倍増したことを公開しました。その数字は衝撃的でした。初回オファーのコンバージョン率は63％に達し、サブスクリプションの継続率は68％に上りました。

これはまさに行動心理学の教科書のような設計でした。トグルは「オフ」がデフォルトで、見た目に安く感じられる年額プランがあらかじめ選択されています。無料トライアルを利用したいユーザーは、自分でスイッチをオンにする必要があり、その結果、より高額な週額プランへと切り替わります。多くのユーザーは年額の低い価格を見て、そのままトグルを操作せずに「続ける」をタップし、トライアルをスキップして前払いで支払いました。その結果はどうだったか？即時収益の大幅な増加と、ユーザーあたり平均収益（ARPU）の向上です。

その効果はあまりに強力で、瞬く間に広がりました。数か月のうちに、App Storeのさまざまなアプリでトグル型ペイウォールのバリエーションが見られるようになりました。マネタイズを強化したい開発者にとっての定番戦略となったのです。私たち自身のペイウォール再設計の事例でも取り上げ、あるアプリではARPUが17％向上し、別のアプリでは実装後に収益が64％増加しました。

しかし、少し効果がありすぎると感じられるパターンには、いつか必ず起こることがあります。最終的に、プラットフォーム側が気づくのです。

リジェクトの波

2026年1月中旬から、リジェクト通知が次々と届き始めました。Axel Le Pennecはそのひとりで、Appleからのリジェクト通知のスクリーンショットを添えて「My app got rejected for that（これでリジェクトされた）」と、どこか諦めたようなコメントを投稿しました。そしてその翌日、このパターンを広めた当の本人であるAdam Lyttleが、その投稿を引用リツイートし、たった3語の追悼メッセージを残しました。「RIP paywall toggle（安らかに、トグル型ペイウォール）」

それ以降も、報告は止まりませんでした。Aivars Meijers、Sergey、Ingo など、多くの開発者が同様のリジェクト体験を共有しています。この件に関するRedditスレッドでは、同じ経験をしたと認める開発者が何十人も集まっています。これは単発の出来事ではありません。明確なパターンです。

Appleからのリジェクト通知は、容赦ないほど明確です。

Guideline 3.1.2 – Business – Payments – Subscriptions

購入画面に、サブスクリプション購入に無料トライアルを追加または削除するためのトグルが含まれています。このデザインは混乱を招く可能性があり、ユーザーが無料トライアル期間終了後に課金が開始される自動更新サブスクリプションに同意していることを理解できなくなるおそれがあります。

Next Steps：サブスクリプション購入画面から、無料トライアルを追加または削除するトグルを削除してください。ユーザーには、無料トライアルが含まれているかどうかを明確に示した、分かりやすいサブスクリプションオファーを提示する必要があります。

ここに曖昧さはありません。

なぜ今なのか？

では、なぜこのパターンが1年以上広く使われてきたにもかかわらず、Appleは今になって取り締まりを強化しているのでしょうか。

正直なところ、私たちも100％確信しているわけではありません。Appleが明確なポリシー更新や公式ブログ投稿を出したわけでもありません。ただ、いくつかの点をつなぎ合わせることはできます。

まず第一に、Appleはここしばらく、サブスクリプションの慣行を是正する広範な取り組みを進めてきました。サブスクリプションに関するガイドライン（3.1.2）は常に透明性を重視していますし、詐欺防止に関する規定（3.1.2(a)）では、「虚偽の前提でユーザーをサブスクリプション購入へと誘導する」アプリを明確に問題視しています。デフォルトでオフになっているトグルは、見方によってはこのカテゴリに含まれる可能性があります。隠れたトグルを操作しなければ利用できない無料トライアルは、Appleの視点からすれば、多くのユーザーが目にすることのないトライアルです。それでは、トライアルを提供する本来の目的が損なわれます。

第二に、このパターンは広まりすぎました。少数のインディーアプリが巧妙なデザインを使っているうちは、目立ちません。しかし、ストア全体で何千ものアプリが同じ仕組みを採用し、さらにそれを解説するYouTube動画が何万回も再生されるようになれば、当然注目されます。AppleのApp Reviewチームがこのトレンドを把握していることは明らかで、そして一線を越えたと判断したのでしょう。

第三に、そしておそらく最も重要なのは、ユーザーが混乱していたという点です。トグルの本質は、多くのユーザーがトグルを操作しないことにありました。それは透明性ではなく、曖昧化です。Appleのポリシーにどう思うかは別として、ユーザーが何に同意しているのかを正しく理解できるようにすることに正当な関心を持つのは当然のことです。

どんでん返し：死んだのはiOSだけ

さて、トグル型ペイウォールは終わった。献杯しよう。私たちはほとんど知らないままだった。

……ただし、終わったのはiOSだけです。ここは重要なポイントです。

現時点で、Googleがこのデザインに問題を示しているという兆候はありません。Webベースのペイウォールについても同様です。マルチプラットフォームでアプリを展開しているなら、トグルはAndroidやWebでは依然として有効で、高い成果を出せる戦略である可能性があります。

だからこそ、柔軟でリモート設定可能なペイウォール環境が重要になります。RevenueCatのようなツールを使えば、Targeting機能によって、iOSには準拠済みのトグルなしペイウォールを表示し、Google PlayやWebには従来の高ARPUなトグル型デザインを表示するといった出し分けが可能です。すべてを一括で捨てる必要はありません。重要なのは、正しいプラットフォームに正しいペイウォールを表示することです。

代わりに何をテストすべきか

では、iOS開発者はどうすればいいのでしょうか？――設計を見直すことです。幸いなことに、コンバージョン率が高く、かつ完全にガイドラインに準拠したペイウォールデザインは数多く存在します。中には、これまでのトグル型よりも高い成果を出せる可能性のあるものもあります。

まずテストをおすすめしたいのは、次のパターンです。

1. 「正直な」タイムライン型ペイウォール

有名な「Blinkist型ペイウォール」です。Blinkistが広めたこのデザインは、「無料トライアルを開始」をタップした後に何が起こるのかを、明確なステップ形式のタイムラインで示します。たとえば、今日：フルアクセス → 5日目：リマインダー → 7日目：課金開始、といった具合です。Blinkistは、このパターンを導入したことでコンバージョン率が23％向上し、クレームが55％減少したと報告しています。これは強い信頼を構築する設計であり、多くの場合、トリックよりも信頼のほうが高いコンバージョンを生みます。

2. マルチパッケージセレクター

トライアルをオン／オフするトグルの代わりに、週額・月額・年額といった複数のサブスクリプションパッケージを横並びで提示します。トライアル付きのプランにはバッジを付けます。ユーザーは自分が望むパッケージを選択するだけで、トグルは不要です。トライアルは独立した仕組みではなく、プラン自体に組み込まれています。これは典型的な価格アンカリングを活用する方法で、（トライアル付きの）年額プランを最も魅力的な選択肢に見せることができます。

3. バリューファースト型ペイウォール

このアプローチでは、価値提案を最前面に出します。価格を表示する前に、強いビジュアル、ベネフィット重視のコピー、ソーシャルプルーフ、App Storeの評価などを提示します。ユーザーが価値に本当に納得すれば、支払いに対する心理的ハードルは大きく下がります。会話の焦点を「いくらかかるのか？」から「何が得られるのか？」へと移すのです。

4. 条件付き表示によるパーソナライズド・ペイウォール

より高度なアプローチです。ユーザー属性に基づいて条件分岐を行い、異なるペイウォールコンテンツを表示します。たとえば、初回オファーの対象かどうかによって出し分けます。対象ユーザーにはトライアル訴求を目立たせ、対象外のユーザーには直接購入フローを表示します。トグルは不要で、体験はユーザーごとに最適化されます。RevenueCatでは、Paywall Builder内のTargetingと条件付き表示機能によってこれをサポートしています。

5. エグジットオファー

Duolingoは「Web購入ファースト」のペイウォール設計を実験しています。離脱しようとしているユーザーに、もう一度コンバージョンのチャンスを与えられるとしたら？それがエグジットオファーの考え方です。ユーザーがペイウォールを閉じようとしたとき、ただ画面を閉じるのではなく、別の、しばしばより魅力的なオファーを提示します。たとえば、より低い価格、より長いトライアル、年額を拒否した後に月額プランを提示するなどです。

この機能は最近Paywall Builderに追加されました。すべてリモートで設定でき、コード変更は不要です。本来なら失われていた意図を回収する優れた方法です。ただし注意が必要です。Appleは即時の離脱阻止オファーにも厳しくなりつつあるため、ユーザーを閉じ込めているように感じさせない設計になっているか、慎重にテストしてください。

6. Web購入ボタン

少し変化球です。米国のiOSユーザーを完全にWebチェックアウトへ誘導する方法です。Appleの30％手数料を回避でき、購入フローを完全にコントロールできます。そして、Web購入にはApp Storeガイドラインが適用されないため、トグルを含め、好きなペイウォールデザインを採用できます。もちろん、アプリ内画面には引き続きアプリ内課金も含める必要があります。ただし、Webでは割引を提供する（あるいはアプリ内価格を引き上げる）ことで、Webオプションへと誘導することが可能です。私たちはテストを容易にするWeb Checkout Buttonコンポーネントを提供しています。結果は……なかなか興味深いものになっています。

重要なのは、今すぐ実験を始めることです。次のアプリアップデートがリジェクトされるのを待つ必要はありません。これらの代替案を積極的にテストし、iOS向けペイウォールの新たな勝ちパターンを見つけましょう。

もうひとつ付け加えると

少し気持ちが軽くなるかもしれない興味深いデータがあります。Fitsの創業者であるLudwig Henneは、Adam Lyttle型のトグルペイウォールと、Blinkist型の「正直な」ペイウォールを比較するA/Bテストを実施しました。結果は、トグル型がARPUで勝利（+19％）しました。しかし、トグルという仕組みそのものを切り分けて分析したところ、主な要因はトグル自体ではないことが分かりました。本当のコンバージョン向上要因は、ビジュアルヒエラルキーにありました。年額価格の正規化表示、「Most Popular」バッジ、そして年額プランを大きく見せるUI設計です。

言い換えれば、トグルを削除しても、ペイウォールを効果的にしていた他のデザイン要素を維持すれば、収益向上の大部分は保てる可能性があります。トグルは主役のように見えていましたが、実際に重い仕事をしていたのは脇役たちだったのです。

ひとつの時代の終わり

iOSにおけるトグル型ペイウォールの終焉は、ひとつの時代の終わりを意味します。刺激的な時代で、多くの開発者に大きな収益をもたらしました。しかし、App StoreはAppleの家であり、ルールを決めるのは彼らです。

最終的には、これはユーザーにとって良いことなのかもしれません。そしてユーザーにとって良いことは、長期的にはエコシステム全体にとっても良いことです。私たちに、より創造的で、より透明性があり、製品の本当の価値を伝えることに集中する姿勢を求めるからです。優れたペイウォールとは、ユーザーをだまして登録させるものではなく、ユーザー自身が登録したくなるものです。

さあ、トグル型ペイウォールに献杯を。そして、テストに戻りましょう。

Expo または React Native プロジェクトに react-native-purchases を追加するだけで、単一のコードベースから、3つのプラットフォームにわたる高度なサブスクリプション管理、アプリ内課金、エンタイトルメント管理を実現できます。

なぜこれを開発したのか

より多くの React Native アプリがモバイルの枠を超えて展開する中で、Web は単なるマーケティングの場ではなく、プロダクトの一部になっています。チームは、ユーザーがブラウザ上でサインアップやアップグレード、サブスクリプション管理を行いながら、iOS や Android アプリ内でも同じアクセス権を利用できることを求めています。これまでは、そのために Web 用の別個の課金システムを維持し、カスタムロジックで全体をつなぎ合わせる必要がありました。

React Native Web サポートは、その分断を解消します。Web での購入はネイティブ購入と同じ RevenueCat のバックエンドに流れるため、複数のデータソースを突き合わせる必要はありません。単一のエンタイトルメントシステムに依存することができます。

Webでの課金の仕組み

iOS と Android では、RevenueCat は App Store と Google Play に直接統合されています。一方、Web では購入は RevenueCat Web Billing を通じて処理され、Stripe または Paddle が決済プロセッサーとして利用されます。Web Billing はネイティブのアプリ内課金とは別の仕組みですが、同じエンタイトルメントシステムに接続されているため、共通の appUserID を使ってプラットフォーム間でアクセス権を付与できます。

アプリ側から見ると、ユーザーがどこでサブスクリプションを開始したかに関わらず、サブスクリプション状態は一貫しています。ユーザーが Web で登録した場合でも、特別なプラットフォーム別ロジックを書くことなく、すぐにモバイルでプレミアム機能へアクセスできます。

React Native Web の始め方

React Native Web サポートを有効にするには、まず各プラットフォームに対応する適切な API キーを使って RevenueCat を設定します。アプリが Web 上で動作する場合は Web Billing 用の公開 API キーで SDK を初期化し、iOS と Android では引き続きそれぞれのネイティブ用キーを使用します。

実際の設定は、次のようになります。

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

if (Platform.OS === 'web') {
  Purchases.configure({ apiKey: '<public_web_billing_api_key>' });
} else if (Platform.OS === 'ios') {
  Purchases.configure({ apiKey: '<public_apple_api_key>' });
} else if (Platform.OS === 'android') {
  Purchases.configure({ apiKey: '<public_google_api_key>' });
}

設定が完了すれば、エンタイトルメントの確認はすべてのプラットフォームで同じ方法で行えます。サブスクリプションがどのプラットフォームで購入されたかによって、アプリのロジックを分岐させる必要はありません。

import Purchases from 'react-native-purchases'
\/\/ all of the following methods work on iOS, Android, and Web

\/\/ Check offerings
try {
  const offerings = await Purchases.getOfferings();
  if (offerings.current !== null && offerings.current.availablePackages.length !== 0) {
    \/\/ Display packages for sale
  }
} catch (e) {
 
}

\/\/ Check entitlements
const customerInfo = await Purchases.getCustomerInfo();
if(typeof customerInfo.entitlements.active[<my_entitlement_identifier>] !== "undefined") {
  \/\/ Grant user "pro" access
}

\/\/ Purchase a package
try {
  const { customerInfo } = await Purchases.purchasePackage(package);
  if (
    typeof customerInfo.entitlements.active["my_entitlement_identifier"] !==
    "undefined"
  ) {
    \/\/ Unlock that great "pro" content
  }
} catch (e) {
  if (!e.userCancelled) {
    showError(e);
}

Web 購入を有効にするには、RevenueCat ダッシュボードで Web Billing 用のアプリを作成し、Web 向けにプロダクトを設定する必要があります。これらは iOS や Android のプロダクトと並んで管理されますが、ネイティブストアではなく Web Billing を通じて課金されます。

Expo を利用する場合

Expo で開発している場合、React Native Web サポートは開発体験も向上させます。カスタムの開発用クライアントをすぐに作成しなくても、Web 上でサブスクリプション UI をプレビューし、エンタイトルメントロジックをテストし、統合フローを検証できます。これにより、初期段階での反復開発がしやすくなり、設定がエンドツーエンドで正しく動作しているかを確認しやすくなります。

iOS と Android で実際のアプリ内課金を完全にテストするには、引き続き Expo の開発ビルドが必要です。Web サポートはその要件を置き換えるものではありませんが、初期開発段階における多くの摩擦を取り除きます。

現在の制限事項

Web 課金はネイティブのアプリストアとは仕組みが異なるため、いくつか注意すべき制限があります。Web での購入には RevenueCat Web Billing が必要であり、iOS や Android のネイティブアプリ内課金を処理することはできません。また、ネイティブストアの API に依存する一部の操作（ getProducts、 purchaseProduct、 restorePurchasesなど）は Web 環境ではサポートされていません。Expo Go や同様のサンドボックス環境でも、購入処理はサポートされていません。

\/\/ this will not work on web, but works on iOS and Android:
try {
  const restore = await Purchases.restorePurchases();
  \/\/ ... check restored purchaserInfo to see if entitlement is now active
} catch (e) {

}

ユーザーは、RevenueCat がホストするカスタマーポータルを通じて Web サブスクリプションを管理できます。これにより、ネイティブアプリストア外でも、サブスクリプションの更新や解約を一貫した方法で行うことができます。

今後について

サブスクリプションアプリがモバイルとWebの両方にまたがるケースが増える中、私たちはクロスプラットフォームでのサブスクリプション管理を、よりシンプルで信頼性の高いものにするための投資を続けています。React Native Web サポートはその基盤となる取り組みであり、チームが本番環境でさらに活用していく中で、体験を継続的に改善していきます。

すでにモバイルで React Native と RevenueCat を利用している場合、Web サポートの追加は自然な次のステップです。

当時は、まだ大きな流れにはなりませんでした。プレッシャーが十分に強くなかったのです。しかし数年が経ち、AI が静かに「利用量」を収益の重荷へと変えてしまいました。2025年にはハイブリッド・マネタイズが広がりつつある兆しが見えましたが、2026年にそれを無視することは、サブスクリプションアプリにとって致命的になりかねません。2026年は、ハイブリッド・マネタイズが本格的に離陸する年なのです。

ちなみに、2022年のそのブログ記事では、ストア外決済の選択肢についても触れていました。そして今、2026年。App Store の規約変更を受け、新たな不確実性に直面しています……。

サブスクリプションアプリにとって、成長モデルをハイブリッド・マネタイズへ移行することが何を意味するのかに入る前に、まずは「なぜ今なのか」を見ていきましょう。（ネタバレすると、またしても AI です。）

AI以前：限界費用が見えなかったからこそ、サブスクリプションは勝てた

この10年の大半において、サブスクリプションアプリには隠れた優位性がありました。ユーザーが1人でも100万人でも、変動費はほぼゼロだったのです。開発やデザインのコストを除けば、追加のユーザーを提供するコストは実質的に無料でした。

この前提が、価格エコシステム全体の進化を形作りました。

• フラットな価格設定は公平に感じられた
• ヘビーユーザーはリスクではなく、むしろプラス要因だった
• マネタイズはコスト抑制ではなく、コンバージョンとリテンションに集中していた

ユーザーが増えることや、アクティブユーザーが増えることが「悪いこと」になる時代など想像できませんでした。だからこそ、ゲーム以外の分野では「食べ放題型」サブスクリプションが当たり前になったのです。このモデルが機能していたのは、経済構造に余裕があったからです。

しかし、AIはその余裕を壊しました。2026年は、この変化を無視できなくなる年です。AIが新しいからではありません。その経済構造が、成熟したサブスクリプション市場と正面から衝突し始めているからです。

広がる亀裂

最近、サブスクリプション型アプリはApp Storeで「勝っている」ように見えます。ゲーム分野が横ばいの中、非ゲーム分野のApp Store収益はそれを上回り、創業者や人材、資本、ツールなどを引き寄せています（皮肉なことに、その多くはゲーム業界出身です）。しかし、状況は確実に厳しくなっています。

「食べ放題型」サブスクリプションモデルの亀裂は何年も前から見えていましたが、今やアプリの収益性にとって深刻な課題となりつつあります。

• ARPUの頭打ち
• プレミアム機能への転換率は一桁台前半にとどまる
• チャーンの上昇
• 最適化による限界リターンの低下
• サブスクリプション疲れへの懸念の拡大

なぜ今なのか？ハイブリッド化を加速させる3つの構造要因

2022年にハイブリッド・マネタイズの台頭を予測したのは、少し早すぎました。2026年が違うのは、複数のプレッシャーが同時に重なっている点です。

いまやハイブリッド・マネタイズへの移行は「あれば良い」ものではなく、「必要不可欠」なものになりつつあります。その背景には、いくつかの要因があります。

1. AIが競争密度を一気に高めた

AI支援による開発の普及で、新規アプリの数は爆発的に増えました。いわゆる“バイブコーディング”によって、アプリのリリースや改善のコストは大きく下がっています。より多くのチームが、より速く開発し、実証済みのマネタイズパターンを模倣し、同じカテゴリで競争しています。

その結果は明白です。アプリは増え、ファネルは似通い、マネタイズのミスを許す余地はますます小さくなっています。

2. 最適化はもはや持続的な優位ではない

かつては、ペイウォールのデザインや価格テスト、オンボーディングフローが明確な差別化要因でした。いまやそれらは“やっていて当然”の前提条件です。現在、ペイウォール最適化の限界リターンは低下しています。もはや競争優位ではなく、ベースライン要件と考えるべきです。

コンサル初年度に適用しやすいペイウォールレイアウトを販売してVahe Bagdasaryen は、100万ドルを稼ぎました。素晴らしいことですが、いまでは誰もが同じレイアウトを使っています（だからこそ、Blinkist風ペイウォールにも限界があるのです）。これらの手法は習得すべき必須スキルですが、すぐにコモディティ化します。改善の幅は縮小する一方で、同じ場所で注目を奪い合う新規アプリが増え、コストは上昇し続けています。

3. ユーザー獲得はますます難しくなっている

供給は増えましたが、ユーザーの可処分注意は増えていません。アプリは増えても、TikTokのフィードやApp Storeで見られる“目”の数は変わらないのです。ユーザー獲得（UA）コストは上昇し続ける一方で、多くの非ゲームカテゴリではコンバージョン率やARPUは頭打ちになっています。広告入札はますます勝ちにくくなり、大手がASOの主要枠を占有し、競争は激化するばかりです。UAインフレを相殺するには、毎年20〜25％のARPU向上が必要になります。しかしそれはあくまで“追いつく”ための数字にすぎません。それを超えて初めて、真の成長と言えるのです。

なぜ今なのか？AIの変動費がハイブリッド化を加速させる

長らく、ほとんどのサブスクリプション型ビジネスは変動費が実質ゼロでした。しかし、AI機能の導入によってその前提は崩れました。これは構造的な断絶です。コアバリューの一部としてAIを活用するアプリは、ユーザーを獲得するたびに実際にコストを支払うモデルへと変わっています。

最もアクティブなヘビーユーザーが、支払額以上のコストを発生させている場合、あるいは無料ユーザーであってもコストを生んでいる場合、そのビジネスモデルは書き直さなければなりません。

もともとはSaaS向けに書かれたものですが、Anh Tho Chuong の記事「So you want to price your AI features」は、あらゆるAIアプリに当てはまります。

「LLM APIに触れた瞬間、ソフトウェアの“限界費用ゼロ時代”は終わります。AIには実際のCOGS（売上原価）があり、私たちはそれに向き合うことを学ばなければなりません。」 — Anh Tho Chuong（Lago CEO & Co-founder）

変動費が高いということは、少数のアウトライヤー（極端なヘビーユーザー）だけで会社が破綻しかねないということです。そしてそれは、従来の「食べ放題型」サブスクリプションモデルそのものを脅かします。

• これまで最良の資産だったヘビーユーザーが、負債になり得る
• 無料ユーザーは、これまで評価・バイラル・後発コンバージョンといった間接的価値を無料で生んでいたが、いまや負のユニットエコノミクスを抱える可能性がある
• 無料トライアルは、まったく異なる設計思想で考える必要がある
• ARPUの平均値は、壊滅的なテールリスクを覆い隠す

これは、AIアプリにおいてサブスクリプションを中核にすべきでないという意味ではありません。しかし、その上に別のレイヤーを重ね、コスト構造に合わせて調整する必要があります。私は、Anh Tho の予測と同様に、ハイブリッド価格モデルがより一般化すると考えています。定期収益を安定させつつ、LTVを高める方向です。

ここまで述べたAIの変動費と、前述のプレッシャーを組み合わせると、次のような構図になります。

アプリ競争の激化 + 類似したマネタイズ／獲得プレイブック + 変動費の上昇 = サブスクリプションモデルの強制的進化

では、実際にそのモデルはどのような形になるのでしょうか。

• アクセスは予測可能：サブスクリプションが引き続き、収益・期待値・リテンションの基盤となる
• 利用は制限される：利用量の多い行動は上限設定・従量課金・別枠マネタイズの対象となる
• ヘビーユーザーは自発的に高額プランへ移行：他のユーザーに補助されるのではなく、自ら生むコストを自ら負担する

行動に移すための参考として、2つのリソースを紹介します。

• 基礎を学ぶ：最近の記事では、サブスクリプションアプリがハイブリッド・マネタイズによってどのように収益を拡大できるか、
• 具体例を深掘りする：Alice Muir Kocourková は、AIがアプリの価格モデルをどのように変えたか、そしてAIアプリが主要機能をどう価格設定しているかを詳しく解説しています。

ハイブリッド・マネタイズは自然な進化である

ここまで述べてきたものの、私は依然としてサブスクリプションは強力なモデルだと考えています。ただし、それはこの10年間、マネタイズ・リテンション・獲得を支配してきたような、静的な「食べ放題型」の形ではありません。

これらすべての要因が、モデル成熟の次の段階へと押し進めています。重要なのはサブスクリプションを捨てることではなく、より賢く設計し、その上にレイヤーを重ねていくことです。

AIアプリには、ほとんど選択肢がありません。ヘビーユーザーの利用量に応じたコストを、より適切に価格へ反映させる必要があります。しかしこれはAIアプリだけの話ではありません。重いAI機能を持たないアプリであっても、すでにこれらのダイナミクスによって形作られた市場で競争しています。たとえ変動費の問題がなくても、成長とはビジネスモデル同士の競争なのです。

いまサブスクリプションアプリを構築しているなら、何をすべきか

このブログは戦術的なチェックリストではありませんが、私の観察から導かれる無視できない方向性はいくつかあります。

• もしあなたのアプリにAI機能があるなら：いずれ「アクセス」と「利用量」を分離する必要があります。早い段階でこれを無視すればするほど、後での修正はより痛みを伴うものになりますし、競争に飲み込まれるリスクも高まります。
• もしあなたのアプリが（まだ）AIを使っていないなら：安心してはいけません。自分はプレッシャーと無縁だと思わないことです。あなたもすでにAI経済によって形作られたエコシステムで競争しています。価格の変化、模倣のスピード加速、そしてマネタイズ手法の寿命短縮を前提に考えるべきです。
• もしあなたがアーリーステージなら：「食べ放題型サブスクリプション」をデフォルトにするのは、もはや安全な選択肢ではありません。利用パターンが見えてきたときに進化できる価格設計を考えるべきです。ただし、ハイブリッドモデルには複雑性が増すという側面もあることを理解しておく必要があります。

最終的に、最も賢明なのは自分の収益構造を常に注視することです。AI由来の変動費がある場合は、外れ値やヘビーユーザーに注意を払いましょう。そして、これから訪れる変化に対して、自分の価格モデルをどう守るかを考え始めることです。

結論

サブスクリプションが失敗しているわけではありません。もともと想定されていなかった役割を求められているのです。

AIによって利用は高コスト化しました。ハイブリッド・マネタイズは、予測可能な収益を維持しながら、価格を実際のコストと価値に整合させることで、サブスクリプションアプリが適応する方法です。2026年は、ハイブリッド・マネタイズが実験段階を終え、現代のサブスクリプションビジネスのデフォルト形態になる年です。

今回の Sub Club エピソードでは、ホストの David Barnard が、Tanmay Jain（ElevenLabs モバイルグロースリード）と Jack McDermott（ElevenReader モバイルグロースリード）を迎え、急速に進化するテック分野の中で ElevenLabs がどのようにモバイルグロース、価格設計、ローンチ戦略、そしてチーム体制に取り組んでいるのかを掘り下げています。

浮かび上がってくるのは、AIモデルや技術的ブレークスルーの話ではありません。明確さ、スピード、そしてそれを可能にする仕組み――そしてそれらを実現するための意思決定の話です。

以下は、この対話から得られた特に重要な学びです。

Watch on YouTube

価格はAIの仕組みではなく、ユーザーの思考に合わせるべき

Tanmay と Jack が共有した大きな成果のひとつは、価格設計をシンプルにしたことでした。

ElevenReader では、社内では理解しやすいものの消費者には分かりづらい「トークン」や「クレジット」といった概念をやめ、その代わりに「リスニング時間」を販売する形に変更しました。その結果、価値の伝わり方が明確になり、コンバージョンも大きく改善しました。

ここから得られる教訓はシンプルですが、見落とされがちです。AIの複雑さを抽象化することは「単純化しすぎる」ことではありません。それは優れたプロダクト設計です。

価格を理解するためだけにユーザーが新しい思考モデルを学ばなければならないのであれば、その時点で摩擦はすでに高すぎるのです。

小さく自律したポッドが、スピードを競争優位に変える

ElevenLabs は、大きな中央集権型の組織として運営されているわけではありません。むしろ、ひとつの会社の中に 10〜12 の小さなスタートアップが存在しているような形で機能しています。

これらの小さく自律したポッドは、プロダクトの意思決定から実験、価格設計、ペイウォールに至るまで、全面的なオーナーシップを持っています。この構造によって、チームは素早くリリースし、徹底的に改善を重ね、社内プロセスではなく実際の成果に対して責任を持ち続けることができます。

変化の激しいAI市場において、これは単なる組織の好みではありません。明確な競争優位なのです。

アーンドメディアは積み上がり、広告成長も強化する

Jack は、ElevenLabs がローンチを単発のイベントではなく、積み上がっていく資産として捉えていることを説明しています。

成功したローンチはアーンドメディアを生み出し、ブランド検索を増やし、信頼を高め、広告による獲得コストを引き下げます。時間が経つにつれて、ストーリー、ブランド、パフォーマンスマーケティングが互いに強化し合うフライホイールが形成されます。

成長は「広告かオーガニックか」という二択ではありません。 重要なのは、その両者の相互作用です。

機能ではなく、まずはツイートスレッドからローンチを始める

ローンチ用のアセットやランディングページ、広告クリエイティブを作る前に、ElevenLabs はまずひとつのテストから始めます。

この機能の価値を、ツイートスレッドで明確に説明できるか？

答えがノーであれば、それは危険信号です。先にナラティブを書くことで、価値が明確になり、見た目は派手でもユーザーに響かない機能をリリースしてしまうのを防げます。

実際には、そのツイートスレッドが最初のプロダクト仕様書になります。

コンシューマーアプリは、プラットフォーム企業にとっての戦略的優位

ElevenLabs は、自社のコンシューマーアプリをプラットフォームや API ビジネスと競合する存在とは見なしていません。むしろ、それらは戦力の増幅装置と捉えています。

自らが「最高の顧客」になることで、チームはダッシュボードや API ログだけでは見えにくい UX の摩擦、パフォーマンス上の制約、そして感情的なユースケースを発見できます。そうした洞察はコアプロダクトへと還元され、結果としてプラットフォーム全体をより強くします。

モバイルは単なるディストリビューションチャネルではありません。学びの場でもあるのです。

結論：重要なのはハイプではなく、明確さ・スピード・仕組み

このエピソードから得られる本質的な学びは、AIそのものについてではありません。

重要なのは、価格設計、チーム体制、ローンチ戦略、フィードバックループといった「仕組み」を構築することです。それによって、優れたプロダクトを信頼や使いやすさを損なうことなく、スピーディーに前進させることが可能になります。

変化の速い市場で取り組む創業者やグロースリード、プロダクトチームにとって、ElevenLabs はスピードを落とさずに思慮深くスケールする方法を示す明確な事例と言えるでしょう。

🎧 Tanmay Jain と Jack McDermott が、ElevenLabs のコンシューマー向け成長戦略の裏側にある実験、意思決定、そしてトレードオフについて語る Sub Club のフルエピソードもぜひお聴きください。

本記事では、Google Play Billing における代表的なエッジケースを取り上げ、それぞれが発生する理由を理解し、Play Billing Library を使って正しく処理する方法を確認します。また、RevenueCat がこれらのシナリオをどのように簡素化し、課金インフラではなくプロダクト開発に集中できるようにするのかも見ていきます。

根本的な問題：ハッピーパスだけでは不十分

多くの課金実装は、Android の公式ドキュメントにあるサンプルコードから始まります。

\/\/ The happy path
billingClient.launchBillingFlow(activity, params)

\/\/ In PurchasesUpdatedListener
override fun onPurchasesUpdated(
    billingResult: BillingResult,
    purchases: List<Purchase>?
) {
    if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
        purchases?.forEach { purchase ->
            if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED) {
                acknowledgePurchase(purchase)
                grantEntitlement(purchase)
            }
        }
    }
}

これは、成功した即時購入を処理するケースを想定しています。しかし、ユーザーがコンビニで支払いを行い、支払いが48時間遅れる場合はどうでしょうか？ 以前の承認処理が静かに失敗しており、ユーザーがすでにその商品を所有している場合はどうでしょうか？ サブスクリプションのダウングレードが即時ではなく、次回の更新時に反映される場合はどうでしょうか？ これらの各シナリオには個別の対応が必要であり、無視するとサポート問い合わせの増加、返金リクエスト、そしてサブスクライバーの離脱につながります。

保留中の購入（Pending purchases）：支払いが即時ではない場合

すべての購入が即座に完了するわけではありません。コンビニでの現金支払い、銀行振込、一部のキャリア決済など、特定の支払い方法では非同期処理が必要になります。ユーザーがこれらの方法で購入を開始すると、Google Play は PURCHASED 状態ではなく、PENDING 状態の購入として返します。

なぜ保留中の購入が発生するのか

保留中の購入は、クレジットカードの普及率が低い市場で一般的です。

アプリをグローバルに展開している場合、保留中の購入に遭遇するのは避けられません。この状態を無視すると、これらの地域のユーザーはそもそも商品を購入できなくなるか、あるいは購入が「消えた」ように見える混乱した挙動に直面することになります。

保留状態の検出と処理

PurchasesUpdatedListener は、完了した購入と同様に、保留中の購入も受け取ります。重要な違いは、 purchaseState フィールドにあります。

override fun onPurchasesUpdated(
    billingResult: BillingResult,
    purchases: List<Purchase>?
) {
    if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
        purchases?.forEach { purchase ->
            when (purchase.purchaseState) {
                Purchase.PurchaseState.PURCHASED -> {
                    \/\/ Payment complete, grant access
                    processPurchase(purchase)
                }
                Purchase.PurchaseState.PENDING -> {
                    \/\/ Payment not yet complete
                    handlePendingPurchase(purchase)
                }
                Purchase.PurchaseState.UNSPECIFIED_STATE -> {
                    \/\/ Unknown state, query backend for clarification
                    queryBackendForState(purchase)
                }
            }
        }
    }
}

重要なルールは次のとおりです。保留中の購入に対してエンタイトルメントを付与してはいけません。ユーザーはまだ支払いを完了していません。代わりに、保留中の購入を記録し、そのステータスを明確にユーザーへ伝える必要があります。

fun handlePendingPurchase(purchase: Purchase) {
    \/\/ Store the pending purchase token for later verification
    purchaseRepository.savePendingPurchase(
        purchaseToken = purchase.purchaseToken,
        productId = purchase.products.first(),
        orderId = purchase.orderId,
        purchaseTime = purchase.purchaseTime,
    )

    \/\/ Show clear UI to the user
    showPendingUI(
        message = "Your purchase is being processed. " +
            "You'll get access once payment is confirmed.",
    )
}

保留中の購入の完了

支払いが最終的に確認されると、アプリは onPurchasesUpdated または queryPurchasesAsync を通じて更新された購入情報を受け取ります。purchaseState は PURCHASED になり、承認処理およびエンタイトルメントの付与を進めることができます。

ただし、注意点があります。支払いが完了した時点で、ユーザーがアプリを開いていない可能性があります。このケースには、Real-Time Developer Notifications（RTDN）を通じてバックエンドで対応すべきです。以前は保留中だったトークンに対して ONE_TIME_PRODUCT_PURCHASED または SUBSCRIPTION_PURCHASED の通知を受け取った場合、バックエンドでエンタイトルメントを更新し、ユーザーに通知する必要があります。

\/\/ Backend notification handler
fun handlePurchaseNotification(notification: DeveloperNotification) {
    val purchaseToken = notification.oneTimeProductNotification?.purchaseToken
        ?: notification.subscriptionNotification?.purchaseToken
        ?: return

    val pendingPurchase = purchaseRepository.findPendingPurchase(purchaseToken)
    if (pendingPurchase != null) {
        \/\/ Previously pending purchase is now complete
        val purchaseDetails = playDeveloperApi
            .purchases()
            .products()
            .get(packageName, pendingPurchase.productId, purchaseToken)
            .execute()

        if (purchaseDetails.purchaseState == 0) { \/\/ 0 = Purchased
            entitlementRepository.grantEntitlement(
                userId = pendingPurchase.userId,
                productId = pendingPurchase.productId,
            )
            purchaseRepository.markCompleted(purchaseToken)

            \/\/ Notify user that their purchase is ready
            notificationService.sendPushNotification(
                userId = pendingPurchase.userId,
                title = "Purchase Complete",
                body = "Your purchase has been confirmed. Enjoy your content!",
            )
        }
    }
}

BillingClient で保留中の購入を有効にする

保留中の購入をサポートするには、 BillingClient を構築する際に明示的に有効化する必要があります。これを行わない場合、遅延支払い方法による購入は完全に失敗します。

val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases(
        PendingPurchasesParams.newBuilder()
            .enableOneTimeProducts()
            .enablePrepaidPlans()
            .build()
    )
    .build()

Play Billing Library 7 以降では、 enablePendingPurchases() の呼び出しが必須となっています。これを行わない場合、 BillingClient の初期化は失敗します。

ITEM_ALREADY_OWNED レスポンス：よくある混乱の原因

最も頻繁に遭遇するエッジケースの一つが BillingResponseCode.ITEM_ALREADY_OWNED です。このレスポンスは、ユーザーがすでに所有している非消耗型商品やサブスクリプションを再度購入しようとした場合に発生します。一見すると分かりやすい挙動に思えますが、実際にこれが発生するシナリオは意外なものが少なくありません。

なぜ ITEM_ALREADY_OWNED が発生するのか

最も一般的な原因は、ユーザーが意図的に同じ商品を二重購入しようとしていることではありません。問題は、以前の購入が正しく承認（acknowledge）されなかったことにあります。Google Play では購入の承認が必須であるため、未承認の購入は宙ぶらりんの状態に置かれます。つまり、ユーザーはすでに課金されているものの、購入がアプリ側で確認されていない状態です。このまま同じ商品を再度購入しようとすると、未承認の購入が残っているため、Google Play は ITEM_ALREADY_OWNED を返します。

この状況は、想像以上によく発生します。

• アプリが購入受信後、承認前にクラッシュした
• ネットワークエラーにより承認呼び出しが完了しなかった
• 購入フロー中にユーザーがアプリを強制終了した
• 承認 API 呼び出しがエラーを返し、再試行されなかった

ITEM_ALREADY_OWNED を正しく処理する

ITEM_ALREADY_OWNED に対する正しい対応は、エラーメッセージを表示することではありません。代わりに、既存の購入をクエリし、未承認の購入があればそれを処理するべきです。

override fun onPurchasesUpdated(
    billingResult: BillingResult,
    purchases: List<Purchase>?
) {
    when (billingResult.responseCode) {
        BillingClient.BillingResponseCode.OK -> {
            purchases?.forEach { processPurchase(it) }
        }
        BillingClient.BillingResponseCode.ITEM_ALREADY_OWNED -> {
            \/\/ Query existing purchases and process any unacknowledged ones
            recoverUnacknowledgedPurchases()
        }
        BillingClient.BillingResponseCode.USER_CANCELED -> {
            \/\/ User backed out, no action needed
        }
        else -> {
            handleBillingError(billingResult)
        }
    }
}

private fun recoverUnacknowledgedPurchases() {
    val params = QueryPurchasesParams.newBuilder()
        .setProductType(BillingClient.ProductType.INAPP)
        .build()

    billingClient.queryPurchasesAsync(params) { billingResult, purchases ->
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
            purchases.forEach { purchase ->
                if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED &&
                    !purchase.isAcknowledged
                ) {
                    \/\/ Found the unacknowledged purchase, process it
                    processPurchase(purchase)
                }
            }
        }
    }
}

このパターンにより、フラストレーションを招くエラーを、シームレスな復旧処理へと変えることができます。以前の購入が承認に失敗していたことを、ユーザーが知る必要はありません。ユーザーの視点では、「購入」をタップすれば商品が手に入るだけです。

ITEM_ALREADY_OWNED を事前に防ぐ

最善のアプローチは、アプリ起動時に未承認の購入を処理することで、この状況を未然に防ぐことです。

fun processUnacknowledgedPurchasesOnStartup() {
    val inAppParams = QueryPurchasesParams.newBuilder()
        .setProductType(BillingClient.ProductType.INAPP)
        .build()

    val subsParams = QueryPurchasesParams.newBuilder()
        .setProductType(BillingClient.ProductType.SUBS)
        .build()

    billingClient.queryPurchasesAsync(inAppParams) { result, purchases ->
        if (result.responseCode == BillingClient.BillingResponseCode.OK) {
            purchases.filter {
                it.purchaseState == Purchase.PurchaseState.PURCHASED &&
                    !it.isAcknowledged
            }.forEach { processPurchase(it) }
        }
    }

    billingClient.queryPurchasesAsync(subsParams) { result, purchases ->
        if (result.responseCode == BillingClient.BillingResponseCode.OK) {
            purchases.filter {
                it.purchaseState == Purchase.PurchaseState.PURCHASED &&
                    !it.isAcknowledged
            }.forEach { processPurchase(it) }
        }
    }

このメソッドは、 BillingClient が正常に接続されたタイミングで呼び出してください。これにより、取りこぼされていた購入がユーザーに問題が発生する前に回復されます。

消耗型購入： acknowledge と consume の違い

ゲーム内通貨、追加ライフ、トークンパックのような消耗型商品では、承認（acknowledgment）と消費（consumption）の違いがバグの一般的な原因になります。どちらも消耗型商品には必要ですが、目的もタイミング要件も異なります。

承認と消費のフロー

承認（Acknowledgment）は、購入されたコンテンツを配信済みであることを Google Play に通知するものです。購入から3日以内に行う必要があり、期限を過ぎると自動的に返金されます。

消費（Consumption）は、その購入をリセットし、ユーザーが同じ商品を再度購入できるようにする処理です。商品を消費しない場合、ユーザーは再購入できず、再購入を試みると ITEM_ALREADY_OWNED が返されます。

消耗型商品の場合は、購入を消費するべきです。消費処理は暗黙的に承認も行います。

fun processConsumablePurchase(purchase: Purchase) {
    \/\/ Verify with backend first
    verifyPurchaseWithBackend(purchase) { isValid ->
        if (isValid) {
            \/\/ Grant the consumable content
            grantConsumableContent(purchase)

            \/\/ Consume the purchase (this also acknowledges it)
            val consumeParams = ConsumeParams.newBuilder()
                .setPurchaseToken(purchase.purchaseToken)
                .build()

            billingClient.consumeAsync(consumeParams) { billingResult, _ ->
                if (billingResult.responseCode != BillingClient.BillingResponseCode.OK) {
                    \/\/ Retry consumption, the user cannot rebuy until consumed
                    scheduleConsumptionRetry(purchase.purchaseToken)
                }
            }
        }
    }
}

複数量購入のエッジケース

Google Play は、消耗型商品の複数量購入をサポートしています。ユーザーは、1回のトランザクションで同じ消耗型商品を複数個購入できます。数量は Purchase オブジェクト内で取得できます。

fun processConsumablePurchase(purchase: Purchase) {
    val quantity = purchase.quantity  \/\/ Could be > 1

    verifyPurchaseWithBackend(purchase) { isValid ->
        if (isValid) {
            \/\/ Grant the correct quantity
            grantConsumableContent(purchase.products.first(), quantity)

            val consumeParams = ConsumeParams.newBuilder()
                .setPurchaseToken(purchase.purchaseToken)
                .build()

            billingClient.consumeAsync(consumeParams) { billingResult, _ ->
                if (billingResult.responseCode != BillingClient.BillingResponseCode.OK) {
                    scheduleConsumptionRetry(purchase.purchaseToken)
                }
            }
        }
    }
}

quantity フィールドを無視して常に1ユニットしか付与しない場合、複数個を購入したユーザーは支払った分より少ないアイテムしか受け取れません。これはサポート問い合わせや返金リクエストの原因になります。

複数量購入を有効にするには、Google Play Console で該当商品に対して「Allow multi-quantity purchases（複数量購入を許可）」を有効にする必要があります。さらに、 BillingFlowParams ではユーザーが選択できる最大数量を指定できます。

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(
        listOf(
            BillingFlowParams.ProductDetailsParams.newBuilder()
                .setProductDetails(productDetails)
                .build()
        )
    )
    .build()

消費処理（consume）の再試行問題

たとえばネットワークエラーなどで consumeAsync の呼び出しが失敗すると、ユーザーはコンテンツを受け取っているのに、購入が消費されていない状態になります。これは次のような問題につながります。

1. ユーザーが同じ消耗型商品を再度購入できない
2. 承認されないまま3日が経過すると購入が返金される可能性がある（消費処理は暗黙的に承認も行いますが）

そのため、消費処理に失敗した場合に備えて、再試行メカニズムを実装するべきです。

class ConsumptionRetryManager(
    private val billingClient: BillingClient,
    private val purchaseRepository: PurchaseRepository,
) {
    fun scheduleConsumptionRetry(purchaseToken: String) {
        purchaseRepository.markPendingConsumption(purchaseToken)
    }

    fun retryPendingConsumptions() {
        val pendingTokens = purchaseRepository.getPendingConsumptionTokens()

        pendingTokens.forEach { token ->
            val consumeParams = ConsumeParams.newBuilder()
                .setPurchaseToken(token)
                .build()

            billingClient.consumeAsync(consumeParams) { billingResult, _ ->
                if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
                    purchaseRepository.clearPendingConsumption(token)
                }
                \/\/ If still failing, it will be retried next time
            }
        }
    }
}

BillingClient が接続されるたびに、未承認購入のリカバリーロジックとあわせて retryPendingConsumptions() を呼び出してください。

サブスクリプションのダウングレードと proration（日割り計算）モード

ユーザーがサブスクリプションプランを変更する際の課金挙動は、アップグレードかダウングレードか、そしてどの proration モードを指定しているかによって異なります。特にダウングレードは、多くの開発者にとって予想外の挙動を示します。

デフォルトのダウングレード挙動

ユーザーがサブスクリプションをダウングレード（より安価なプランへ変更）した場合、デフォルトの挙動は DEFERRED です。つまり、ダウングレードは即時ではなく、次回の更新日に適用されます。現在の請求期間が終了するまでは、ユーザーは引き続き上位プランの機能を利用できます。

fun launchDowngrade(
    activity: Activity,
    newProductDetails: ProductDetails,
    newOfferToken: String,
    currentPurchaseToken: String,
) {
    val billingFlowParams = BillingFlowParams.newBuilder()
        .setProductDetailsParamsList(
            listOf(
                BillingFlowParams.ProductDetailsParams.newBuilder()
                    .setProductDetails(newProductDetails)
                    .setOfferToken(newOfferToken)
                    .build()
            )
        )
        .setSubscriptionUpdateParams(
            BillingFlowParams.SubscriptionUpdateParams.newBuilder()
                .setOldPurchaseToken(currentPurchaseToken)
                .setSubscriptionReplacementMode(
                    BillingFlowParams.SubscriptionUpdateParams
                        .ReplacementMode.DEFERRED
                )
                .build()
        )
        .build()

    billingClient.launchBillingFlow(activity, billingFlowParams)
}

リプレースメントモードの理解

各リプレースメントモードは、課金、アクセス権、そしてユーザー体験にそれぞれ異なる影響を与えます。

遅延ダウングレード（Deferred）の落とし穴

遅延ダウングレードで最もよくある誤りは、購入フロー完了直後にサブスクリプション状態を確認し、新しいプランが反映されていることを期待してしまうことです。 DEFERRED モードでは、次回の更新日まで元のサブスクリプションが元のプロダクト ID のまま有効です。新しいサブスクリプションが表示されるのは更新後になります。

つまり、エンタイトルメントのチェックでは、この移行期間を考慮する必要があります。

fun handleDowngradeResult(purchase: Purchase) {
    \/\/ After a deferred downgrade, the purchase still reflects
    \/\/ the OLD subscription until the next renewal
    val currentProductId = purchase.products.first()

    \/\/ Query the subscription status from your backend to check
    \/\/ if a deferred downgrade is pending
    checkBackendForPendingDowngrade(purchase.purchaseToken) { pendingDowngrade ->
        if (pendingDowngrade != null) {
            \/\/ Show UI indicating the downgrade is scheduled
            showDowngradeScheduledUI(
                currentPlan = currentProductId,
                futurePlan = pendingDowngrade.newProductId,
                effectiveDate = pendingDowngrade.effectiveDate,
            )
        } else {
            \/\/ Normal subscription state
            showSubscriptionUI(currentProductId)
        }
    }
}

プラン変更時の linkedPurchaseToken

サブスクリプションのリプレースメント（アップグレードまたはダウングレード）が処理されると、新しい購入トークンが生成されます。この新しい購入には、以前のサブスクリプションを参照する linkedPurchaseToken フィールドが含まれます。重複したエンタイトルメントを作成しないよう、バックエンドでこれを正しく処理する必要があります。

\/\/ Backend handler for subscription replacement
fun handleSubscriptionReplacement(newPurchaseToken: String) {
    val subscription = playDeveloperApi
        .purchases()
        .subscriptionsv2()
        .get(packageName, newPurchaseToken)
        .execute()

    val linkedToken = subscription.linkedPurchaseToken

    if (linkedToken != null) {
        \/\/ This is a plan change, not a new purchase
        val userId = userRepository.findByPurchaseToken(linkedToken)

        \/\/ Update to new token
        userRepository.updatePurchaseToken(userId, newPurchaseToken)

        \/\/ Invalidate old token to prevent double-counting
        subscriptionRepository.invalidate(linkedToken)
    }

    \/\/ Acknowledge the new purchase
    acknowledgePurchase(newPurchaseToken)
}

リプレースメント処理時に古い購入トークンを無効化しないことは、よくあるバグの一つであり、サブスクライバー数の水増しや誤った収益レポートにつながります。

ネットワーク障害と再試行戦略

課金処理はネットワークに依存しており、ネットワーク障害や遅延は避けられません。失敗する可能性がある重要な処理には、購入フローそのもの、承認（acknowledgment）、消費（consumption）、購入検証が含まれます。

承認の猶予期間

Google Play では、購入を承認するために3日間の猶予が与えられています。この期間内に承認しない場合、購入は自動的に返金されます。これはユーザー保護のための仕組みですが、その分、承認ロジックは一時的な障害に対して耐性を持つ必要があります。

class AcknowledgmentManager(
    private val billingClient: BillingClient,
    private val purchaseRepository: PurchaseRepository,
) {
    fun acknowledgePurchaseWithRetry(purchase: Purchase) {
        if (purchase.isAcknowledged) return

        val params = AcknowledgePurchaseParams.newBuilder()
            .setPurchaseToken(purchase.purchaseToken)
            .build()

        billingClient.acknowledgePurchase(params) { billingResult ->
            when (billingResult.responseCode) {
                BillingClient.BillingResponseCode.OK -> {
                    purchaseRepository.markAcknowledged(purchase.purchaseToken)
                }
                BillingClient.BillingResponseCode.SERVICE_UNAVAILABLE,
                BillingClient.BillingResponseCode.SERVICE_DISCONNECTED,
                BillingClient.BillingResponseCode.ERROR -> {
                    \/\/ Transient failure, schedule retry
                    purchaseRepository.markPendingAcknowledgment(
                        purchase.purchaseToken
                    )
                }
                else -> {
                    \/\/ Non-retryable error, log for investigation
                    logAcknowledgmentFailure(purchase, billingResult)
                }
            }
        }
    }

    fun retryPendingAcknowledgments() {
        val pendingTokens = purchaseRepository.getPendingAcknowledgmentTokens()

        val inAppParams = QueryPurchasesParams.newBuilder()
            .setProductType(BillingClient.ProductType.INAPP)
            .build()

        billingClient.queryPurchasesAsync(inAppParams) { result, purchases ->
            if (result.responseCode == BillingClient.BillingResponseCode.OK) {
                purchases
                    .filter { it.purchaseToken in pendingTokens }
                    .filter { !it.isAcknowledged }
                    .forEach { acknowledgePurchaseWithRetry(it) }
            }
        }
    }
}

BillingClient の切断

The BillingClient はいつでも切断される可能性があり、切断された状態で実行された操作は失敗します。そのため、指数バックオフを用いた再接続ロジックを実装する必要があります。

class BillingClientManager(
    private val context: Context,
    private val listener: PurchasesUpdatedListener,
) {
    private var billingClient: BillingClient? = null
    private var retryCount = 0

    fun connect(onConnected: () -> Unit) {
        billingClient = BillingClient.newBuilder(context)
            .setListener(listener)
            .enablePendingPurchases(
                PendingPurchasesParams.newBuilder()
                    .enableOneTimeProducts()
                    .build()
            )
            .build()

        billingClient?.startConnection(object : BillingClientStateListener {
            override fun onBillingSetupFinished(billingResult: BillingResult) {
                if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
                    retryCount = 0
                    onConnected()
                } else {
                    retryConnection(onConnected)
                }
            }

            override fun onBillingServiceDisconnected() {
                retryConnection(onConnected)
            }
        })
    }

    private fun retryConnection(onConnected: () -> Unit) {
        if (retryCount < MAX_RETRY_COUNT) {
            retryCount++
            val delayMs = (1000L * (1 shl retryCount)).coerceAtMost(MAX_RETRY_DELAY_MS)
            handler.postDelayed({ connect(onConnected) }, delayMs)
        }
    }

    companion object {
        private const val MAX_RETRY_COUNT = 5
        private const val MAX_RETRY_DELAY_MS = 30_000L
    }
}

RevenueCat がこれらのエッジケースをどう扱うか

これまでに説明した各エッジケースには、慎重な実装、再試行ロジック、そしてバックエンド基盤が必要です。ここで RevenueCat は、複雑さを抽象化し、これらのシナリオを自動的に処理することで大きな価値を提供します。

保留中の購入（Pending purchases）

RevenueCat は保留中の購入状態を内部で追跡し、支払いが確定したタイミングで CustomerInfo を更新します。アプリ側はエンタイトルメントを確認するだけで済みます。

Purchases.sharedInstance.getCustomerInfoWith { customerInfo ->
    val isPremium = customerInfo.entitlements["premium"]?.isActive == true

    if (isPremium) {
        showPremiumContent()
    } else {
        showSubscriptionOptions()
    }
}

RevenueCat のバックエンドは、Google Play からの RTDN 通知を処理します。そのため、保留中の購入が完了すると、エンタイトルメントは RevenueCat のサーバー側で更新されます。次にアプリが CustomerInfo を取得したときには、そのエンタイトルメントは有効になっています。こちら側で独自の通知処理や購入トークンの追跡を行う必要はありません。特に個人開発の場合、こうしたバックエンド基盤を一式構築するのは非常に大きなリソースが必要になります。

承認と消費

RevenueCat は承認（acknowledgment）と消費（consumption）を自動で処理します。SDK が購入を受け取ると、その購入は RevenueCat のバックエンドで検証され、RevenueCat があなたに代わって Google Play に対して承認を行います。消耗型商品については、検証後に RevenueCat が消費処理を行います。 acknowledgePurchase や consumeAsync を自分で呼び出す必要はありません。

これにより、承認失敗、消費処理の呼び忘れ、そして ITEM_ALREADY_OWNED 問題に関連する一連のバグをすべて排除できます。

サブスクリプションプランの変更

RevenueCat は、purchaseWith を通じてサブスクリプションのアップグレードおよびダウングレードのためのシンプルな API を提供しています。

Purchases.sharedInstance.purchaseWith(
    PurchaseParams.Builder(activity, newPackage)
        .oldProductId(currentProductId)
        .googleReplacementMode(GoogleReplacementMode.DEFERRED)
        .build(),
    onSuccess = { transaction, customerInfo ->
        \/\/ CustomerInfo reflects the new subscription state
        updateUI(customerInfo)
    },
    onError = { error, userCancelled ->
        if (!userCancelled) {
            showError(error)
        }
    }
)

RevenueCat は、linked purchase token の処理、エンタイトルメントの移行、そして遅延ダウングレードの追跡をバックエンドで処理します。アプリ側では、現在のエンタイトルメント状態を CustomerInfo で確認するだけで済みます。

ネットワーク耐性

RevenueCat の SDK には、すべてのネットワーク操作に対する組み込みの再試行ロジックが含まれており、 CustomerInfo をローカルにキャッシュしてオフラインでも参照できるようにしています。また、接続が回復した際にはバックエンドと自動的に同期されます。これにより、デバイスがオフラインの状態でもアプリはエンタイトルメントを確認できます。

\/\/ This works offline using cached CustomerInfo
Purchases.sharedInstance.getCustomerInfoWith { customerInfo ->
    val isPremium = customerInfo.entitlements["premium"]?.isActive == true
    updateUI(isPremium)
}

SDK は古いデータと最新データを区別し、失敗した操作を指数バックオフで再試行し、最終的にエンタイトルメントがサーバー側の状態と整合することを保証します。

まとめ

本記事では、サンプルレベルの課金実装と本番運用レベルの実装を分ける、さまざまなエッジケースについて見てきました。

これらの各シナリオには、Play Billing Library を直接使って解決するための明確な方法があります。しかし、それらをすべて実装するための累積的な工数は決して小さくありません。クライアント側の処理、バックエンドでの RTDN 処理、再試行メカニズム、そして各状態をまたいだ慎重なステート管理が必要になります。こうしたインフラを自前で構築・維持せずにサブスクリプション機能を提供したいチームにとって、RevenueCat はこれらのエッジケースを自動的に処理し、複雑な管理を行う代わりに単一の CustomerInfo オブジェクトを確認するだけで済むようにしてくれます。

課金インフラを自前で構築する場合でも、RevenueCat を利用する場合でも、これらのエッジケースを理解することは不可欠です。テスト環境では動く課金システムと、多様な市場や支払い方法にまたがる数百万のユーザーに対して安定して動作する課金システムとの違いは、まさにここにあります。

それでは、Happy coding！

— Jaewoong

しかし、私たちはそこで止まりません。2025年11月以降、特に勢いよくアップデートをリリースし続けています。最も要望が多く、最もインパクトの大きい機能改善を次々と提供し、「あらゆるアプリにとって最高のペイウォールビルダー」にすることを明確な目標としています。

本記事は、RevenueCat Paywalls に関するあらゆるアップデートをまとめるリビング・チェンジログとして更新していきます。ぜひブックマークして、最新情報を随時チェックしてください。

新しい Paywalls エディターレイアウト

Paywalls エディターを刷新し、従来のデュアルパネルインターフェースに代わって、サイドバー型レイアウトを採用しました。コンポーネント、レイヤー、ブランディング、メディア、ローカライズといった主要エリアは、分かりやすくラベル付けされたタブに整理され、より直感的に操作でき、学習もしやすくなっています。

新しいレイアウトではキャンバスを中央に据えつつ、今後 Paywalls を拡張していくための余地も確保しています。機能が増えてもエディターが煩雑になることはなく、より複雑なペイウォールを作成している場合でも整理された状態を保てます。

新しいエディターを見る ↗

より素早く編集できるキーボードショートカット

すばやく反復作業を行っていると、小さな操作の積み重ねが大きな差になります。Paywalls エディターでは、コンポーネントの移動、複製、選択、削除といった一般的な操作に、Figma スタイルのキーボードショートカットをサポートするようになりました。

ショートカットを簡単に見つけられるよう、エディター内にヘルプアイコンを追加し、対応しているコマンドの一覧を確認できるようにしています。いつでも開いて確認できるため、使いながら自然にショートカットを覚え、UI ではなくレイアウトそのものに集中できます。

すべてのショートカットを見る ↗

ペイウォール間でのコンポーネントのコピー＆ペースト

単一のペイウォール内だけでなく、異なるペイウォール間でもコンポーネントをコピー＆ペーストできるようになりました。これにより、ヒーローセクション、ベネフィットリスト、価格ブロックなど、すでに成果の出ているレイアウトを簡単に再利用できます。

別のペイウォールにコンポーネントを貼り付けると、その構造、スタイル、バインディングも一緒に引き継がれます。複数のキャンペーンや実験を運用しているチームにとって、繰り返し作業を減らし、バリエーション間でデザインの一貫性を保つのに役立ちます。

専用の Branding タブ

ビジュアルシステムを一元管理できるよう、Paywalls エディターに新しい Branding タブを追加しました。保存したカラー、グラデーション、カスタムフォントを一か所で管理し、プロジェクト内のすべてのペイウォールで再利用できます。

編集中は、ブランディングアセットがカラーやタイポグラフィのピッカーに直接表示されるため、ブランドに沿ったデザインを維持しやすく、場当たり的な値の使用を防げます。また、スタイルを一度標準化すれば、チーム全体が安心してその上に構築できるため、コラボレーションもよりスムーズになります。

新しいメディアギャラリー

新しいメディアギャラリーにより、ペイウォール間での画像管理がよりスムーズになりました。アップロード済みのアセットを一か所で確認でき、一覧でプレビューし、不要になったファイルを整理できます。

画像のアップロードは、ギャラリーにドラッグ＆ドロップするだけです。ペイウォール編集中も、同じファイルを再度アップロードすることなく、既存のアセットを再利用できます。アートワークやキャンペーン用ビジュアルを複数のペイウォールで共有しているチームにとって、特に便利な機能です。

期限切れアラートでより安全なローカライズ

ローカライズの状況が、より分かりやすくなりました。デフォルト言語のテキストを更新すると、エディターが自動的にどの翻訳が最新でないかを検出します。

サイドバーには警告バッジが表示され、影響を受けているロケールやフィールドの一覧が明確に示されます。そこからワンクリックで翻訳を更新することも、意図的な変更であれば警告を解除することもできます。これにより、気づかないうちにコピーがずれていくことを防ぎ、コンテンツが進化してもグローバルなペイウォールの整合性を保てます。

ローカライズの詳細を見る ↗

ペイウォール閉鎖時のエグジットオファー

ユーザーが購入せずにペイウォールを閉じた場合に表示されるエグジットオファーを設定できるようになりました。フローをそのまま終了させる代わりに、別のオファーを提示する2つ目のペイウォールを表示できます。

たとえば、異なる請求オプションの提示、より低価格の提案、あるいは離脱前の最後のリマインダーとして活用できます。エグジットオファーは iOS、Android、ハイブリッド SDK すべてで利用でき、既存のペイウォールや実験ともスムーズに連携します。

エグジットオファーを設定する ↗

ペイウォールドラフトの自動保存

Paywalls エディターでは、編集中のドラフトが自動保存されるようになりました。変更内容はバックグラウンドで継続的に保存されるため、ページを離れたりリロードしたりしても、作業内容を失うリスクが軽減されます。

また、ドラフトがより頻繁に保存されることで、バリデーションの問題も早い段階で検出されます。公開の挙動自体はこれまでと変わりません。公開を選択するまで内容が反映されることはありませんが、特に長時間のデザイン作業において、より安心してスムーズに編集できるようになります。

Figma デザインをそのまま Paywalls にエクスポート

デザインの引き継ぎが「最初からやり直し」を意味する必要はありません。そして今、それはもう必要ありません。

Figma のモックアップを直接 Paywall エディターにエクスポートできます。レイアウトはネイティブの Paywalls コンポーネントとして取り込まれるため、すぐに次の作業が可能です。

• 構造を変えずにコピーを編集
• プロダクトやパッケージを差し替え
• テキストをローカライズ
• 実験を追加
• 特定のオーディエンスをターゲティング

実務上の最大のメリットはスピードです。デザイナーは Figma に留まり、ペイウォールテストを実装するチームは、最終モックからライブのバリエーションまで、レイアウトを手作業で再現することなく進められます。

Figma デザインをインポート↗

Paywalls エディターのキーボードショートカット

すばやく反復作業を行っていると、小さなクリックの積み重ねが大きな差になります。

Paywalls エディターでは、コンポーネントの追加、セクションの複製、変更の取り消し・やり直し、ブロックの削除など、よく使う操作に対応したキーボードショートカットをサポートしています。作業の流れを止めることなく、スピーディーな反復を本当に快適に行えます。

すべてのショートカットを見る ↗

より多くのデバイスでペイウォールをプレビュー

ある画面では完璧に見えるペイウォールも、別の画面では不自然に見えることがあります。以前は公開後に気づくこともありましたが、現在はより幅広い iOS および Android のスマートフォンやタブレットでプレビューできるようになりました。キャンバスは実際の画面サイズに合わせて更新されるため、数秒でデバイスを切り替えながら次の点を確認できます。

• 余白の問題を早期に発見
• フォントサイズの確認
• 画像のトリミングや配置のチェック
• スクロール挙動の確認
• CTA が意図した位置に表示されているかの確認

シンプルな改善ですが、公開直前の修正を大幅に減らすことができます。

ペイウォールテンプレートのフィルター機能

テンプレートは、目的のものをすばやく見つけられてこそ役立ちます。

テンプレートギャラリーでは、購入方法、ティア、パッケージでフィルタリングできるようになりました。トライアル優先レイアウト、価格グリッド、プロモーション向けデザインなど、最初から求めるパターンが明確な場合に特に便利です。検索にかける時間を減らし、リリースにより多くの時間を使えます。

テンプレートから始める ↗

ペイウォール用カウントダウンコンポーネント

プロモーションは効果的なペイウォール施策になり得ますが、緊急性が明確かつ本物である場合にこそ最大の効果を発揮します。そのため、任意のペイウォールにカウントダウンタイマーを追加できるようになりました。終了日時を一度設定するだけで、タイマーは自動で更新されます。追加のコードも、手動での更新も必要ありません。

ブラックフライデー、ローンチプロモーション、期間限定割引など、タイミングが意思決定を後押しするキャンペーンに最適です。

カウントダウンを追加 ↗

プロジェクトレベルのブランドカラー設定

ブランドカラーをプロジェクト設定で定義できるようになりました。設定したカラーは Paywalls エディター内で利用でき（今後は他の場所でも利用可能になる予定です）、プロジェクト全体で一貫したデザインを保てます。

Paywalls エディターで実際の価格を表示

これまでは、ダッシュボードエディター上で表示される商品価格はプレースホルダー値でした。今回のアップデートにより、エディター内で実際の価格が表示されるようになりました。これにより、作業中でもより現実に近い状態のペイウォールを確認できます。（※表示には、その商品で少なくとも1回のテスト購入が行われている必要があります。）

AI を使ってペイウォールを作成

アプリストアページのデータをもとに、人工知能を使ってペイウォールを作成できるようになりました。インスピレーションを得たり、調整やテストの出発点となるしっかりしたたたき台を作るのに最適な方法です。

Paywalls での動画対応

Paywalls では、画像と同様に、動画を独立したコンポーネントとして追加できるようになりました。

動画背景

ルートのペイウォール、フッター、または任意の親コンポーネント（スタック、パッケージなど）に、動画を背景として設定できるようになりました。

購入意図のインターセプト

ネイティブの iOS および Android SDK では、購入意図（購入 CTA のタップ）をインターセプトし、購入フローに進む前にカスタム UI を表示できるようになりました。アプリで想定されるユースケースとしては、年齢確認／保護者同意のために購入前に年齢確認用の UI を表示することや、追加開示として国別の規約や法的文言などの情報を提示し、ユーザーに確認してもらったうえで先に進んでもらうことなどがあります。

すべてのプランを表示（シート）

ボタンの遷移先として、追加コンテンツを表示できるシートを選択できるようになりました。遷移先にシートを指定すると、Components パネル内のボタンの中に新しい Sheet コンポーネントが表示されます。シート、またはその中のいずれかのコンポーネントを選択すると、ペイウォールのプレビュー上にシートが表示されます。シートには、他のスタックと同様にコンポーネントを追加できます。

シートには独自のパッケージや購入ボタンを設定できるため、シート内に表示されたオプションからユーザーが直接購入することも可能です。

ドキュメントで詳しく見る ↗

• サインアップ数
• トライアル完了数
• セッション時間
• オンボーディング完了率

一見すると、どれも注視すべきもっともらしい指標に思えます。

問題は何か？ その多くが「質」ではなく「量」にフォーカスしていることです。これらは、何人があるステップを通過したかは教えてくれますが、その人たちが意味のあるユーザーになったのか、課金ユーザーになったのか、あるいは実際に継続したのかまでは教えてくれません。

要するに、誰かがリテンションやマネタイズにつながる形で本当にアクティベートしたのかどうかは示していないのです。

アクティベーションはサインアップと同じではありませんし、オンボーディング完了とも同じではありません。つまり、多くの「アクティベーション指標」は、あなたを誤った方向へ導く可能性があるのです。

間違った指標にフォーカスすると何が起きるか

ケース1：オンボーディングは好調だが、アクティベーションが起きていない

これはグロース監査やクライアントワークで本当によく目にします。ある事例では、オンボーディング完了率は非常に高く、iOS と Android の両方で 90％を超えていました。チームは、アクティベーションは順調だと自信を持っていました。

しかし、詳しく分析してみると、そのユーザーの大半は2日目までに離脱していました。

オンボーディングのフロー自体は簡単で、短く、分かりやすいものでした。それでも、ユーザーはプロダクトの本当に重要な部分に関与しておらず、実際の価値を体験していなかったのです。オンボーディング完了率は良好に見えても、アクティベーションの問題は解決していませんでした。

ケース2：機能利用は好調に見えるが、一部のセグメントだけ

別の事例では、アクティベーション指標は一見すると強く見えました。

• 高いエンゲージメント
• 健全な機能利用

しかし、無料ユーザーと有料ユーザーを分けて分析すると、状況はまったく異なりました。ほぼすべての指標を押し上げていたのは無料ユーザーでした。彼らはアクティブで、エンゲージメントも高く、数も多い。しかし、コンバージョンも更新もせず、収益にも貢献していなかったのです。

有料ユーザーのコホートだけを切り出してみると、本当に重要なユーザーにおけるアクティベーションの質は、トップラインの数値が示すよりもはるかに低いことが明らかになりました。

これら2つのケースは、アクティベーション指標を誤って解釈するリスクを浮き彫りにしています。間違った指標にフォーカスすること、あるいは意味のあるセグメンテーションを行わないことが、その原因です。

正しい指標にたどり着くには

ここでは次の点を見ていきます。

• サブスクリプションアプリにとって本当に重要なアクティベーション指標は何か
• 有用に見えてもリテンションや収益を予測しない指標をどう避けるか
• 他社を真似するのではなく、自社独自のアクティベーション指標をどう定義するか
• 選んだ指標が本物なのか、単なるバニティ指標なのかをどう検証するか

「これさえ見ればいい」という魔法のアクティベーション指標を提示できれば簡単ですが、すべてのアプリやユースケースに共通する単一の答えはありません。それぞれに少しずつ異なるアプローチが必要です。ここで提供できる最善のものは、「本当に意味のある指標」と「見た目が良いだけの指標」を見分けるためのフレームワークです。

なぜなら、ここに一つの真実があるからです。リテンションは、アクティベーションなしには起こりません。

多くのアプリは「リテンションの問題」や「マネタイズの問題」があると考えます。しかし一歩引いて見ると、ユーザーが意味のある価値を体験したり、習慣を形成したりする前に離脱していることが原因である場合が少なくありません。

重視すべき指標は、問題がアクティベーションにあるのか、それともリテンションにあるのかによって異なります。

本当に問うべきなのはこうです。ユーザーが定着しないのは、プロダクトが有用ではないからなのか。それとも、そもそも本当の意味でアクティベートしていないからなのか。

まさにその点を明らかにするために、適切なアクティベーション指標が役立つのです。

サブスクリプションアプリにおけるアクティベーションの本当の意味

正しいアクティベーション指標を定義する前に、まず「アクティベーションとは何か」を明確にする必要があります。ここが曖昧になりやすいポイントだからです。

私は、アクティベーションを獲得（acquisition）と混同したり、一般的なエンゲージメント指標をアクティベーションと呼んだり、あるいは「ユーザーが完了したステップ」として単純に扱ってしまうチームをよく目にします。本来見るべきなのは、そのステップがユーザーを長期的なサブスクライバーへと実際に近づけているかどうかです。

しかし、ここで用語の議論に迷い込むつもりはありません。シンプルにいきましょう。

アクティベーションとは、ユーザーがジャーニーの十分に早い段階で意味のある価値に到達し、その結果として次の可能性が高まる状態を指します。

• Convert：トライアルやフリーミアム経路にいる場合、課金に転換する
• Stay：初回更新まで継続利用
• Retain：初期期間を超えて継続する

これは、オンボーディングを完了したかどうかや、チェックリストを消化したかどうかの話ではありません。重要なのは、初期の行動が「生存」と「長期的価値」を予測するかどうかです。

別の言い方をすれば、

• アクティベーションとは「ステップをこなしたか？」ではありません。
• アクティベーションとは「そのステップによって、価値を得る確率、そしてその結果として継続し課金する確率が実質的に高まったか？」ということです。

これは、特定の行動を行ったユーザーと行っていないユーザーのリテンションカーブを比較することで検証できます。

ただし注意点があります。ほとんどの行動は「何もしない」場合よりは良く見えてしまいます。そのため、本当に長期的なリテンションやマネタイズを予測する行動に焦点を当てる必要があります。

本当に問うべきなのは、その特定の行動がリテンションや高価値ユーザーを本当に予測しているかどうかです。目的は単にアクティビティを追跡することではなく、長期的なサブスクライバーと相関する行動と、より早いチャーンや低価値な利用を示す行動（あるいは非行動）を見極めることです。

アクティベーションの2つのレイヤー：ファーストバリューとコアバリュー

サブスクリプションアプリにおけるアクティベーションを考えるとき、それを単一の瞬間として捉えないことが重要です。もちろん最初のセッションは重要ですが、State of Subscription App Report 2025 によると、フリーミアム型アプリとハードペイウォール型アプリの両方において、トライアルの開始が最も多いのは Day 0（初日）です。

とはいえ、アクティベーションは習慣形成における一つの瞬間にすぎません。サブスクリプションアプリにおいて、それが単一のステップで完結することはほとんどありません。

Wes Bush の『Product-Led Growth』では、これを3つの瞬間に分けて説明しています。

1. Moment of value perception：ユーザーが価値を理解する瞬間（例：サンプルやビジュアルを見ることで価値を認識する）
2. Moment of value experience：ユーザーが自ら価値を体験する瞬間（例：アプリの主要機能を初めて使う）
3. Moment of value adoption：ユーザーが意味のある形でアプリを使い始める瞬間（例：習慣を形成し始める）

アプリに関してよく語られる「Time to First Value（TTFV）」という概念は、通常この最初の2つの瞬間を指します。コアバリューは、行動が繰り返され始めて初めて現れるものです。

それでは、この二つの部分についてさらに深く掘り下げてみましょう。

1. Time to first value（TTFV）：価値の認識と体験の瞬間

TTFVとは、ユーザーが価値を「認識し、体験する」までの時間を指します。多くの場合その価値は小さなものですが、それでも重要です。なぜなら：

• 最も急激な離脱は、まさに最初の段階で起きるからです。
• 多くのユーザーは、非常に早い段階で「続けるか、やめるか」を判断します。

ユーザーが早期に価値を感じられなければ、その後どれだけプロダクトが優れていても、意味のあるアクティベーションに到達しない可能性があります。

この最初の価値の瞬間は、「進歩」を感じられるものであるべきで、単なる手間や摩擦であってはいけません。長いオンボーディングフローは流行しているかもしれませんが、時間を埋めるためだけに使うべきではありません。多くの場合、アクティベーションの改善にはつながりません。

2. Time to core value（習慣化または継続利用までの時間）：価値の定着の瞬間

コアバリューに到達するまでには、通常もう少し時間がかかります。ここでユーザーは「試してみる」段階から、「リテンションを予測できる使い方をする」段階へと移行します。

これは特に次のようなプロダクトで重要です。

• 習慣形成型プロダクト
• ウェルネス系やトラッキングアプリ
• 金融・家計管理ツール
• より複雑なワークフローを持つアプリ（例：B2Bアプリ）

たとえば語学学習アプリであれば、1回のレッスン完了がファーストバリューを示すかもしれません。しかし、複数日にわたっていくつかのレッスンを完了し、ルーティンが形成され始めたときに、コアバリューが現れます。新しい言語で30語を覚えた瞬間や、5つの完全な文章を作れるようになった瞬間で測定できるかもしれません。

多くのチームは、最初のセッションの最適化にとどまり、その後に重要となる行動にユーザーが到達しているかどうかを確認していません。私が関わったあるアプリでは、プッシュ通知や2回目・3回目のセッションを含め、実験を初回セッション以降まで拡張することで、7日目リテンションを成功指標としていました。最初の1週間でユーザーを十分に呼び戻し、定着させるために何が必要かを特定するためです。

アクティベーションを定義するときは、「1日目に何が起きるか？」だけを問わないでください。

「ユーザーが定着ユーザーのように振る舞う前に、何が起きている必要があるのか？」も問うべきです。

重要なのは、どちらのレイヤーも必要だということです。ただし、それぞれ異なる役割を持っています。

1. ファーストバリューは初期離脱を防ぐのに役立ちます。
2. コアバリューは、ユーザーが継続し、最終的に定着するかどうかを予測します。

アクティベーションで本当に重要な指標

ここまででアクティベーションを定義しました。次の問いは、「本当に重要な指標は何か？」です。

答えは、あなたのアプリ次第です（分かってはいるけれど、少しもどかしい答えですよね）。しかし、ここまでの考え方を整理し、データを分析していれば、すでに次のことは見えているはずです。

• どの行動がリテンションを予測するのか
• どの機能が意味のある価値を提供しているのか
• あなたのアプリにおけるファーストバリューとコアバリューの瞬間がどこにあるのか

その上で最も重要になるのは、ユーザーがそれらの価値の瞬間に到達しているかどうか、そしてそれがリテンションやコンバージョンにつながっているかを示す指標です。単にステップを消化しているか、ボリュームを生み出しているかではありません。

サブスクリプションアプリにおいてノイズとシグナルを見分けやすくするために、ここでは「重要な指標」「参考になる指標」「注意を逸らす指標」の例を挙げていきます。

重要な指標

これらの指標は、実際のアクティベーションの質を最もよく反映する可能性が高いものです。

1. ファーストバリューに到達したユーザーの割合

この指標は、最初の小さな「アハッ！」の瞬間、すなわちファーストバリューに到達したユーザーがどれくらいいるかを示します。

この初期ステップ（知覚された価値）をアプリで測定するのは簡単ではありませんが、次のような行動を追跡することで把握できます。

• 意味のある初期設定ステップを完了したか
• パーソナライズされたインサイトを閲覧したか
• 最初のセッションから24時間以内に再訪したか

なぜ重要か：ユーザーが価値に到達する前に離脱していないかを示すからです。

すべてのユーザーに即座に到達させることが目的ではありません。重要なのは、十分な数のユーザーが早期に価値を体験し、アクティベーション前にチャーンしてしまうのを防ぐことです。

もしファーストバリューに到達しているユーザーが十分でないなら、それはリテンションの問題ではなく、アクティベーションの問題です。

2. コアバリューに到達したユーザーの割合

これはより深いシグナルであり、ジャーニーの次の段階です。ユーザーがリテンションを支えるパターンや習慣を形成しているかどうかを示します。

この指標は、最初のセッションで起きることよりも、長期的な成功をはるかに強く予測することが多いものです。コアバリューは通常すぐには現れません。ユーザーがプロダクトと繰り返し関わる中で、徐々に形成されます。

3. Time to First Value（慎重に活用する）

Time to First Value は有用ですが、それ自体を目標にすべきではなく、あくまで診断用の指標として使うべきです。

ファーストバリューに関しては、一般的に速い方が望ましいですが、それは本当に意味のある価値が提供されている場合に限ります。表面的な価値を素早く与えるよりも、意味のある価値を少し時間をかけて提供する方がよい場合もあります。

コアバリューに関しては、タイミングは行動との関係で意味を持ちます。たとえば、1週目にコアバリューへ到達したユーザーと2週目に到達したユーザーでリテンションが大きく異なるのであれば、そのタイミング自体が重要なシグナルになります。

ここでの示唆は「短いほど常に良い」ということではありません。重要なのは、タイミングがアクティベーションの質について何かを教えてくれる、という点です。

4. ファネルにおけるアクティベーションの現れ方

ファーストバリューやコアバリューに到達しているユーザーの割合が分かったら、次に見るべきは、それが実際に収益へとつながっているかどうかです。以下のような一般的なサブスクリプション指標が、その判断材料になります。

• トライアル開始率：トライアルを提供している場合
• トライアルから課金への転換率：トライアルを提供している場合
• ダウンロードから課金への転換率

重要なのは、これらの指標を単独で見ないことです。

たとえば、トライアル開始率が高く、トライアルから課金への転換率が低い場合があります。しかし、それが必ずしもトライアル自体の問題とは限りません。多くの場合、ユーザーはまだ十分に価値を体験していない段階でトライアルを開始し、「念のため」にすぐ解約してしまうのです。

取るべき対応は、次のようなものかもしれません。

• トライアル開始までの導線を意図的に遅らせる
• まず価値提供を改善する
• トライアル数の減少を受け入れ、その代わりに質の高いユーザーを獲得する

繰り返しになりますが、アクティベーション指標において重要なのはボリュームではなく質です。それがリテンションを左右します。

参考にはなるが（成功KPIにすべきではない）指標

アクティベーションを理解するうえで役立つ指標はありますが、それを成功の証明として扱うべきではありません。

1. オンボーディング完了率

オンボーディング完了率は、最も過剰に使われているアクティベーション指標の一つです。完了率が高いからといって、アクティベーションがうまく機能しているとは限りません。

場合によっては、適度なポジティブなフリクションを加えることで、ユーザー理解を深め、体験をパーソナライズし、コミットメントを求める前に信頼を築くことができ、結果としてアクティベーションの質が向上することもあります。

「どうすればオンボーディング完了率を上げられるか？」と問う代わりに、次のように問いましょう。

• オンボーディングを完了したユーザーは、より高くリテンションしているか？
• 私たちは適切なユーザーの前進を支援できているか？
• 価値の高いユーザーを早期に失っていないか、あるいは意図の低いユーザーを適切にふるいにかけられているか？

完了はシグナルであって、目標ではありません。

2. 機能利用率（適切なセグメンテーションとともに）

機能利用率は有益な示唆を与えてくれますが、正しい視点で見た場合に限ります。

平均的な利用率はしばしば本質を隠します。ある機能は全体ではあまり使われていないように見えても、高LTVユーザーや有料ユーザーには頻繁に使われているかもしれません。一方で、リテンションに貢献しないまま複雑さだけを増やしている機能もあります。

機能利用率は、次の点を理解するのに最も役立ちます。

• どの機能がリテンションを支えているのか
• 無料ユーザーがプレミアム機能の価値を理解しているかどうか
• どの機能がアクティベーションを助けるのではなく、ノイズを増やしているのか

私が関わったあるアプリでは、無料ユーザーのうちメインのプレミアム機能を試した人はごくわずかでした（無料ユーザーにも制限付きで提供されていました）。その結果、彼らは適切にアクティベートされず、課金する可能性も低い状態でした。つまり、価値を理解していなかったのです。

機能利用率はノイズの特定にも役立ちます。もしある機能を使っているユーザーが全体の2％しかおらず、しかもそのユーザーが最も価値の高い層でないのであれば、それはアクティベーションに貢献しているのではなく、単に複雑さを増しているだけではないかと問い直すべきです。

この点については、Netflixが採用している採用基準についての素晴らしいポッドキャストもぜひチェックしてみてください。

注意を逸らす指標

これらの指標は最適化しやすく、しばしばグロースチームを誤った方向へ導きます。

1. 総サインアップ数

サインアップ数が増えたからといって、成長が改善しているとは限りません。サインアップはファネルにボリュームを流し込むために必要ですが、量だけを最適化すると次のような問題が生じます。

• 質の低いユーザーを集めてしまう
• アクティベーションの問題を覆い隠してしまう
• 獲得チームに誤ったインセンティブを与えてしまう

場合によっては、サインアップ数を減らしてでも、より質の高いトラフィックを獲得する方が正しい選択です。アクティベートし、リテンションする可能性が高いユーザーを集めることが重要です。

2. トライアル開始数

トライアル開始率が高いからといって、課金ユーザーが増えるとは限りません。場合によっては、ユーザーが十分に価値を体験する前にトライアルを開始してしまい、その結果：

• トライアルから課金への転換率が低下する
• 初回更新率が悪化する
• 全体のリテンションが弱くなる

といった事態につながります。

3. セッション時間

セッション時間が長いことは、動画プラットフォームやゲームのようなアプリではエンゲージメントを示すことがあります。しかし一方で、それは混乱や、コンテンツを見つけにくいことのサインである場合もあります。

多くのサブスクリプションアプリにおいては、単純な滞在時間よりも、効率的に価値を届けられているかの方が重要です。総分数よりもコンテキストの方がはるかに重要です。

4. 質の視点を伴わないDAU（デイリーアクティブユーザー）やMAU（マンスリーアクティブユーザー）

DAUやMAUが意味を持つのは、「アクティブ」が意味のある利用を反映しており、その頻度がプロダクト本来の利用リズムと一致している場合に限ります。

よく推奨されるのは、アプリのスティッキネスを測る stickiness ratio を見ることです。

しかし、この一般的なアプリのスティッキネス指標には2つの問題があります。

1. あなたのアプリにとって理想的な利用頻度が、必ずしも「毎日」であるとは限らないこと。
2. 「アクティブユーザー」が単に「アプリを開いた」ことを意味している場合が多く、それは「価値を体験した」ことと同義ではないこと。

これらの要素を調整すれば、スティッキネス指標は依然として有用です。ただし、より良い方法は、自社プロダクトにとって理想的な利用頻度を定義し、それをより長い期間で比較することで、何がリテンションを生み出しているのかを特定することです。

たとえば、私が関わったワークショップや瞑想コンテンツを提供するウェルネスアプリでは、「週に1回アプリを使う」ことよりも、「14日間で少なくとも2つのコンテンツを消費する」ことの方が、リテンションをより強く予測していました。

アクティベーション指標が本物か、見せかけかを検証する方法

アクティベーション指標を定義することは、あくまで第一歩です。次に必要なのは、それが単なる見栄えのよい数字ではなく、実際のアクティベーションを反映していることを証明することです。

指標が真のアクティベーションといえるのは、次のテストをクリアした場合に限ります。

1. アクティベートしたユーザーは、そうでないユーザーよりも明確に高いリテンションを示す

アクティベーションのマイルストーンに到達したユーザーと、到達しなかったユーザーのリテンションカーブを比較してください。

先ほどの図を思い出してください。

見るべきなのは、数週間後に消えてしまう一時的な差ではなく、持続的な差です。もし後になってカーブが再び収束するのであれば、その指標は単なるエンゲージメントの一段階にすぎず、真のアクティベーションではない可能性が高いです。

端的に言えば、「アクティベートした」ユーザーが明確に高く継続したり、より多く課金したりしていないのであれば、その指標は本当のアクティベーションではなく、単なるノイズです。

2. その関係が（ほとんどの）コホートやチャネルで成り立っている

アクティベーション指標がリテンションを一貫して予測しているかどうかを、次の観点で確認してください。

• 時間ごとのコホート
• 獲得チャネル
• Web と iOS と Android の比較
• デバイスタイプ
• 地域（該当する場合）

完璧である必要はありません。ある程度のばらつきは自然です。たとえば：

• あるチャネルでは関係性が弱い
• あるプラットフォームではアクティベーションの仕方が異なる

といったことは起こり得ます。

重要なのは、そのパターンが全体として成立していること、そしてどこで・なぜ崩れているのかを理解していることです。場合によっては、Web、iOS、Android、あるいは地域ごとに異なるアクティベーション指標が必要になることもあります。

3. 指標の改善が下流の成果を改善する

アクティベーションの効果がリテンションカーブに現れるまでには時間がかかることがあります。特に最近トラッキングを始めたばかりの場合はなおさらです。そのため、もう一つの重要なチェックは、そのアクティベーション指標を改善することで、本来影響すべき成果が改善しているかどうかです。

たとえば：

• それが初期の価値マイルストーンであれば → トライアルから課金への転換率は改善しているか？
• より深い習慣マイルストーンであれば → 初回更新率は改善しているか？
• ジャーニーの後半に位置するものであれば → 早期チャーンは減少しているか？

指標だけが改善しても、下流の成果が何も変わらないのであれば、それは意味があるように見えても、実際にはより良く、より持続的なユーザーを生み出してはいない可能性があります。

指標への信頼性を高めるための実践的チェック

十分なデータがある場合は、より踏み込んだ分析でアクティベーション指標をストレステストしてみてください。

• 同一コホート内で、アクティベートしたユーザーとそうでないユーザーを比較する
• 有料ユーザーと無料ユーザーに分けて分析する（フリーミアムモデルの場合）
• チャネルやデバイスの質ごとに分解する
• 高LTVユーザーが同じアクティベーションパターンをたどっているかを確認する

こうした分析によって、そもそも課金やリテンションの可能性が低いユーザーを前提にアクティベーションモデルを構築してしまうリスクを避けることができます。

アクティベーションウィンドウを見極める

アクティベーションは「何が起きるか」だけでなく、「いつ起きるか」も重要です。

リテンションカーブを確認し、急激な初期離脱がどこで落ち着くかを特定してください。そのポイントは、アクティベーションからリテンションへの移行地点を示していることが多く、あなたの指標が本当に意味を持つ期間（ウィンドウ）を定義する助けになります。

アクティベーションウィンドウが非常に長い場合、ユーザーが十分に早く価値を得られていない可能性や、そもそもプロダクトの性質上、アクティベーションに時間がかかる可能性を示しています。たとえば：

• ユーザーが価値に到達するまでに時間がかかりすぎている
• 初期段階で意味のある前進をするためのガイダンスやサポートが不足している

語学学習アプリの例に戻ると、1回のレッスンだけではコミットメントを示すには不十分です。ユーザーが長期的な学習者として本格的に関与する（あるいはフクロウを恐れて続けるようになる）には、1〜2週間にわたり複数のレッスンを完了する必要があるかもしれません。ウィンドウは単に最初のレッスンを捉えることだけではなく、ユーザーが継続する可能性を大きく高めるまでに必要な時間も含みます。

目的は、無理にアクティベーションを早めることではありません。現在どのタイミングで起きているのかを理解し、そのタイミングがリテンションを支えているかを見極めることです。

実務でどう活用するか

ここまで整理すると、追跡できる指標のリストはかなり長くなっているかもしれません。しかし、何十もの指標を追う必要はありません。指標を次の3つの明確なカテゴリに分けることで、焦点を保ちましょう。

1. 重要な指標は、コンバージョン、リテンション、更新を直接予測する指標です：これらを最適化する。
2. 知見を導く指標は、なぜアクティベーションが起きているのか、あるいは起きていないのかを理解するための指標です：これらを調査する。
3. 注意をそらす指標は、改善しやすいものの、質より量を最適化してしまいがちな指標です：注視はするが、追いかけすぎない。

もし一つだけ持ち帰るべきポイントがあるとすれば、これです。アクティベーションとは、ユーザーにステップをこなさせることではありません。適切なユーザーが価値に到達し、その結果として継続する可能性が高まる状態を作ることです。

チームがリテンションやマネタイズの問題だと考えている場合、その多くは実際にはアクティベーションが起きていないことが原因です。自社プロダクトにとっての「本当のアクティベーション」を早い段階で定義できれば、その後のすべては格段にシンプルになります。

最新の Sub Club エピソードでは、HabitKit と FocusKit を手がけるインディー開発者である Sebastian氏 が、アプリ開発におけるゆっくりとした、不確実な“中盤”について語ります。成長の停滞、はっきりしないシグナル、そして何も機能していないように見える状況でも続けるという決断についてです。

これは一夜にして成功した物語ではありません。粘り強さ、タイミング、そして基本を十分にやり切ることで、やがて成長が着地できる場所をつくる――そんなストーリーです。

Watch on YouTube

安定した仕事から、自ら設定した期限へ

ドイツでコンピューターサイエンスとソフトウェアエンジニアリングを学んだ後、Sebastian氏は C#、.NET、Angular を扱うエンタープライズ向けソフトウェア企業に就職しました。刺激的な仕事とは言えませんでしたが、確かな基礎力と、経験豊富なエンジニアたちと働く機会を得ることができました。

同時に、彼の中では自分自身のビジネスを築きたいという思いが静かに膨らんでいました。そして3年後、具体的なプランがないまま退職し、自らに明確な制約を課します――「12か月以内に何かを形にする」と。

エピソードの中で Sebastian氏が語っているように、彼は洗練されたビジネスアイデアを持って会社を辞めたわけではありません。ただ、自分のために何かを作りたいという思いと、その手段としてモバイルアプリがしっくりきていた――それだけでした。

最初のアプリは失敗ではなかった――だが、うまくもいかなかった

最初の挑戦は LiftBear というワークアウトトラッカーでした。Sebastian氏が自分のために作ったアプリです。彼は素早くリリースし、ベータテストは行わず、進捗を Twitter で公開する以外のマーケティングもほとんどしませんでした。

結果は、落胆させられるものでありながら、多くを学ばせてくれるものでした。

LiftBear は一定数のユーザーを獲得し、最終的には月間経常収益（MRR）約 150 ドルに落ち着きました。完全に失敗したわけではありません。しかし、成長もしていませんでした。6か月にわたってアップデートや細かな改善を続けたものの、進捗は止まってしまったのです。

Sebastian氏はこの時期を、強いモチベーション低下を感じた期間だったと振り返ります。アプリが明確に失敗しているわけではない。しかし、さらに注力すれば状況が変わるというシグナルも見えない――そんな状態でした。

HabitKit は、瞬時に共感を生んだ一つのビジュアルから始まった

HabitKit は、よりシンプルなアイデアから生まれました。GitHub のコントリビューショングリッドのような形式で、習慣の継続を可視化するトラッカーを作りたい――それが出発点でした。

最初のスクリーンショットを公開したとき、反応は即座に現れました。エンゲージメントは急増し、フォロワーも増加し、ローンチ前にもかかわらず、初めて明確な関心が示されたのです。

そのシグナルは、彼のエネルギーを一変させました。Sebastian氏は HabitKit に全力で集中し、約2か月の開発を経て最初のバージョンをリリースしました。

スタートアップの基準で見れば控えめなローンチでしたが、インディー開発者にとっては意味のあるものでした。初日の売上は約 150 ドル。何より重要だったのは、人々がこのプロダクトを瞬時に理解してくれたという事実でした。

公開開発は初期には有効だった――しかし長期的な成長エンジンではなかった

初期段階では、公開開発（building in public）が重要な役割を果たしました。HabitKit が最初のユーザーを獲得し、初期レビューを得て、最初の勢いを生み出す助けになったのです。また、静かな立ち上げ初期の数か月間において、Sebastian氏に責任感とモチベーションを与える存在でもありました。

しかし、最大の成長の瞬間はソーシャルメディアから生まれたわけではありませんでした。

ローンチから数か月後――Sebastian氏がすでに週4日勤務の仕事に戻った後――HabitKit は突如として、ドイツや英国を含む複数の App Store 地域で「habit tracker」というキーワードでランキング入りし始めました。その後、Google Play でも同様の動きが起こります。

バズ投稿があったわけでも、大きなメタデータ変更があったわけでも、明確なきっかけがあったわけでもありません。Sebastian氏自身も、なぜ起きたのかは分からないと語っています。ただ一つ明確だったのは、HabitKit がある閾値を超えた瞬間に、ダウンロードと収益が一気に加速したということです。

それは、これまで積み重ねてきたプロダクト品質、レビュー、そして一貫性といった取り組みが、ようやく報われた瞬間でした。

仕事に戻ったことは、物語の終わりではなかった

最初に設定した 12 か月の期限が過ぎた時点で、HabitKit はまだ Sebastian氏をフルタイムで支えられる状態ではありませんでした。彼は以前の会社に戻り、週4日勤務し、金曜日を自分のアプリ開発に充てることにしました。

その“セーフティネット”は、彼に安定と時間をもたらしました。

それから6〜7か月後、HabitKit の成長はもはや曖昧なものではなくなっていました。オーガニック経由の発見が積み重なり、収益も着実に増加。Sebastian氏は再び退職する決断を下します。今度は希望ではなく、明確なトラクションに裏打ちされた判断でした。

FocusKit は多角化ではなく、モチベーションのためだった

長年ほぼ HabitKit に専念してきた中で、Sebastian氏は別の停滞にも気づきました。それは、自身のモチベーションです。

アップデートは小さな改善にとどまり、公開での発信もどこか繰り返しのように感じられるようになっていました。新鮮さを取り戻すために彼が始めたのが、SwiftUI でネイティブに構築したミニマルなポモドーロタイマー、FocusKit です。

FocusKit は HabitKit を置き換えるためでも、すぐに同等の収益を生み出すためでもありませんでした。新しい技術を学び、ネイティブな iOS デザインに向き合い、創作の勢いを取り戻すためのプロジェクトだったのです。

ローンチも意図的にプレッシャーの少ない形で行われました。初期の収益は控えめですが、このプロジェクトの目的は別のところにあります。Sebastian氏が関心を持ち続け、好奇心を保ち、作り続けられる状態を維持することです。

Sebastian氏の歩みが示す、インディーアプリ成長の本質

Sebastian氏のストーリーは、巧妙なハックや攻撃的なグロース戦術によって築かれたものではありません。土台にあるのは、次のような基本の積み重ねです：

• 自分自身が本当に使いたいプロダクトをリリースすること
• 特に初期段階において、進捗を正直に共有すること
• 居心地が悪く感じるほど長く改善を続けること
• プロダクトがそれに値する状態になってから、流通（ディストリビューション）の複利効果に任せること

振り返れば成長は突然に見えます。しかし実際には、何か月にもわたる静かな積み重ねの先に訪れたものでした。

🎧 Sub Club のフルエピソードをぜひお聴きください。Sebastian氏が、成長が止まっているように感じた時期や挫折、そして当時は意味があるように思えなかったものの、最終的には大きな意味を持つことになった決断について詳しく語っています。

しかし、あまり語られていない事実があります。大多数の開発者にとって、30% 手数料は「神話」のようなものです。

実はここ数年、Apple と Google の両方が、その手数料を半分の 15% に引き下げるプログラムを提供しています。それでも私は毎日のように、こうしたプログラムの存在をまったく知らない開発者や、時間を割けないほど複雑な手続きだと思い込んでいる開発者に出会います。その結果、何万ドルものお金を取りこぼしているのです。もう一人エンジニアを雇ったり、マーケティングキャンペーンを回したり、あるいは、そうですね、家賃や支払いに充てたりできるはずのお金です。

これは秘密の抜け道ではありません。公的に提供されているプログラムです。そして、アプリからの年間収益が 100 万ドル未満であれば、あなたは対象になります。今日はそれを正します。言い訳はもう終わりです。あなたが得るべき 15% を取り戻すためのステップバイステップガイドを、ここから紹介します。

今すぐ参加すべきプログラム

Apple と Google では名称こそ異なりますが、基本的な仕組みは同じです。年間収益が 100 万ドル未満であれば、手数料率が 15% に引き下げられます。とてもシンプルです。

Apple：App Store Small Business Program

Apple のプログラムは、インディー開発者や小規模スタジオにとってまさに救いです。有料アプリのダウンロード、アプリ内課金、サブスクリプションなど、すべての収益に対して手数料が 30% から 15% に引き下げられます。

適用条件：

• 前暦年総収益（Apple の手数料控除後）が 100 万ドル以下であること
• 「Associated Developer Accounts」に該当するすべての開発者アカウントの収益が、この 100 万ドルの上限に合算されること
• 新規開発者の場合は、自動的に対象となること

Apple のプログラムへの登録方法（所要時間：約 10 分）：

1. 登録ページへアクセスする： まず、自身が Apple Developer アカウントの Account Holder であることを確認します。そのうえで登録ページにアクセスします。
2. アカウントの確認： Apple から開発者アカウントの確認を求められます。複数のアカウントを持っている場合は、すべてを申告する必要があります
3. 利用規約に同意する： まだ承認していない場合は、App Store Connect の最新の Paid Applications 契約を確認・承認します。その後、Small Business Program の利用規約に同意します

これで完了です。承認され次第、手数料率は 15% に適用されます。あなたは今、自分自身に大幅な昇給をもたらしたことになります。

Google：15% Service Fee Tier

Google のプログラムも同様に重要です。毎年の収益のうち最初の 100 万ドルまでは、手数料は 15% が適用されます。その上限を超えた場合、その年の残りの期間は 30% になります。多くの開発者にとっては、実質的に恒常的な 15% レートを意味します。

適用条件：

• 各暦年に得た収益の最初の 100 万ドルまでに、15% の手数料率が適用されること
• Apple と同様に、「Associated Developer Accounts」を申告し、「Account Group」を作成する必要があること

Google のプログラムへの登録方法（所要時間：約 10 分）：

1. Play Console にアクセス： ログイン後、「Associated developer accounts」ページに移動します
2. Account Group を作成： 画面の案内に従ってグループを作成します。ここで、所有している他の開発者アカウントを紐づけます
3. 登録： グループの設定が完了すると、15% のサービス手数料への登録を促すバナーが表示されます。「Review and enroll」をクリックします
4. 利用規約に同意： 利用規約を確認し、同意します

これで完了です。数回のクリックだけで、アプリの財務的な将来を大きく変えることができます。

もう一つのポイント：サブスクリプションの手数料割引

Small Business Program が主役であることは間違いありません。しかし、特にサブスクリプションに関しては、多くの開発者が見落としているもう一つの重要な仕組みがあります。

Apple：2年目以降の優遇

自動更新サブスクリプションには、Apple があらかじめ用意している割引制度があります。特定のサブスクライバーについて、最初の1年間は 30% の手数料を支払います。しかし、そのユーザーが12か月間継続してくれれば、2年目以降はそのサブスクライバーに対する手数料が 15% に引き下げられます。

もちろん、Small Business Program に参加していれば、最初から 15% が適用されています。しかし、アプリが成長し、Small Business Program の対象外になった場合、この「2年目割引」は非常に重要になります。これは、長期的なリテンションに注力することへの明確なインセンティブです。

Google：初日から 15%

Google はよりシンプルです。Google Play のすべての自動更新サブスクリプションに対して、サービス手数料は初日から 15% です。割引プログラムに参加しているかどうかは関係ありません。サブスクライバーの最初の月であっても、3年目であっても同じです。サブスクリプションの手数料率は常に 15% です。

これは Android 上のサブスクリプションアプリにとって大きな利点であり、開始時点からユニットエコノミクスをより有利にします。

内訳は以下のとおりです：

RevenueCat に登録状況を伝える

RevenueCat を利用している場合、もう一つ行っておきたいステップがあります。それは、これらのプログラムに登録していることを RevenueCat に設定することです。これにより、チャート、各種メトリクス、連携先に送信されるデータが、正しい手数料率を反映するようになります。

Apple の場合

RevenueCat アカウントでは、異なる会社の複数アプリを管理している場合もあるため、Small Business Program のステータスはアプリ単位で設定します。設定方法は以下のとおりです：

1. RevenueCat ダッシュボードへ移動： 左側ナビゲーションバー下部の「Apps & providers」を選択します
2. App Store アプリを選択： 下にスクロールし、「Apple Small Business Program」のドロップダウンを展開します
3. 開始日を入力： プログラムへの参加が有効になった日付を入力します。2020年12月18日以前に登録し、2020年12月30日までに通知を受け取っている場合は、2021年1月1日を入力します
4. 終了日を入力（該当する場合）： プログラムから退出、または除外された場合は、その日付を入力します

保存すると、RevenueCat はチャート上で正しく収益を計算し、連携先にも正確な価格データを送信します。開始日を過去の日付に設定した場合、チャートは 24 時間以内に再計算されます。

Google の場合

朗報です。RevenueCat は、Google の reduced service fee tier に登録している前提で自動処理を行います。サブスクリプション取引については、デフォルトで 15% の手数料率を使用します。

暦年内に 100 万ドルの上限を超えた場合、RevenueCat はその年の残り期間について自動的に 30% に切り替えます。複数アプリを管理している場合や、アプリを移管していて計算にずれがあると感じた場合は、RevenueCat サポートに連絡してください。プロジェクトの手数料率を手動で調整できます。

もう取りこぼさない

以上です。複雑な法的手続きも、リスクの高いサイドローディングのような手法も必要ありません。公式に提供されている2つの簡単に参加できるプログラムと、サブスクリプションに関する明確なルールがあるだけです。それだけで、手数料の半分を節約できます。

この投稿から一つだけ覚えておいてほしいことがあります。それは、今すぐ登録状況を確認することです。

• Apple の場合：App Store Connect の契約画面を確認してください
• Google の場合：Play Console の「Associated developer accounts」ページを確認してください
• RevenueCat の場合：アプリ設定を開き、Small Business Program のステータスが正しく設定されているか確認してください

まだ登録していないのであれば、10 分だけ時間を取りましょう。今年得られる中で、最も ROI の高い 10 分になるはずです。あなたは素晴らしいアプリを作りました。その対価として得た収益は、あなたが受け取るに値します。

編集部より愛を込めて：お気づきの方もいるかもしれませんが、本記事では多くの段落の末尾にピリオドがありません。見落としではありませんのでご安心ください。これは RevenueCat の VP of Marketing、Rik Haandrikman による“お約束”のスタイルです。彼の独特な投稿をもっと見たい方は、X で Rik をフォローしてみてください（ピリオドが見当たらなくなったら、正しいアカウントにたどり着いています）。

「そのテストは、いつ本番リリースされますか？」理想的な答えはこうです。「もうリリースされています。」

しかし現実はどうでしょうか。Zoom 画面の向こうにいる大勢の人たちに、気まずく説明しなければならない、お決まりの理由や遅延のリストが並びます。

• 開発の完了を待っている
• 他の誰かの承認がまだ必要
• ブランドチームがデザインにまだ納得していない

これが一度起きるだけなら、大きな問題ではありません。ですが、「動きが遅い状態」が当たり前になると、その影響は積み重なっていきます。特にスタートアップにとっては、1 つひとつの遅れが学習機会の損失につながり、ランウェイを短くしてしまいます。

私たちはしばしば、「理想の世界」を教えられてきました。すべての関係者が足並みを揃え、テストはきれいにキューに並び、ライフタイムバリュー（LTV）が十分に明らかになってから意思決定を行う、という世界です。

一方で、現実はこうです。毎月コストは発生し、初期のアイデアのほとんどはうまくいきません。そして、完璧なデータを待つということは、多くの場合、待ちすぎることを意味します。

どこかのタイミングで、硬直したルールを手放し、完璧な計画よりも速いフィードバックを選ぶ必要があります。それは居心地の良い選択ではありませんが、無謀になるという意味でもありません。どこで速く動き、どこで慎重になるのか、そして何から学ぶかをどれだけ早く判断するのかを、意図的に決めるということです。

この記事で学べること（そして、できれば実際に使ってほしいこと）は次のとおりです。

• 確実性を待ち続けることに潜むリスク
• なぜ速いフィードバックが「根拠のない自信」に勝るのか
• 実験を早期に止めるべきタイミング
• 信頼を損なうことなく、より速くリリースする方法
• そして、実際にスピードを落とすべき場面とはいつなのか

確実性は、リリースした後に得られるもの

以前、プレローンチ実験の一環として、ランディングページをテストしていたクライアントと仕事をしたことがあります。創業者は細部へのこだわりが非常に強いデザイナーで、私も一緒になって、あらゆる要素を二重三重にチェックしました。数か月にわたるリサーチ、競合分析、そして本格的な開発に入る前に関心を検証するためのペインテッドドアテストまで、やるべきことはすべてやっていました。

そして、ついにページが公開されました。お祝いの時間です。

私たちは、プレローンチの申し込みが次々と入ってくるのを待ちました。ペインテッドドアテスト（実際には存在しない機能やオファーを見せることで関心を測る手法）では需要が示されていたため、期待は高まっていました。しかし、結果はほとんど何も起きませんでした。意味のあるサブスクリプション登録はほぼゼロだったのです。

ただし、私たちが素早く学べたことは、それ以上に価値のあるものでした。

• Meta 広告はその時期は非常に高コストで、信頼を高めてコストを下げるには、より多くの動画コンテンツが必要だったこと
• サブスクリプション価格の段階でユーザーがためらっていたため、まず中間ステップを導入したところ、コンバージョン率が改善したこと

私たちは、ローンチ前に自信を持つために、あらゆることを「正しく」行っていました。しかし、何が機能し、何が機能しなかったのかという確実性は、実際にリリースし、本物のユーザーがページとやり取りして初めて得られたのです。

ここで多くのグロースチームが立ち止まってしまいます。初期段階では、ほとんどの賭けは外れます。使えるデータは限られており、リピート購読者も少なく、意味のあるライフタイムバリュー（LTV）のシグナルはほとんどありません。この段階のマネタイズ指標は、せいぜい方向性を示す程度のものであり、確信を持って待ち続けられるようなものではありません。

初期のマネタイズ判断で重要なのは、正確さではなく勢いです。ライフタイムバリューを正確に予測しようとしているのではなく、そもそもそのオファーに成立する可能性があるのかを見極めようとしているのです。トライアルから有料への転換率、初期解約、価格感度といったシグナルは、「最終的にどこへ行き着くか」を示すものではなく、「次にどこを見るべきか」を教えてくれます。完璧な LTV を待ってから行動しようとするのは、まだ存在していない確実性を前提にしてしまっているのです。

より速く動くためのシンプルなルール

Reid Hoffman氏は、ブリッツスケーリングを「不確実性の中で、効率よりもスピードを優先すること」だと表現しています。これはまさに、初期のグロースに求められる姿勢です。無謀になることではなく、明確さは準備からではなく、実際に世に出すことから得られる、という事実を受け入れることなのです。

私たちは、より深く考えたり、計画に時間をかけたりすることで確実性を得るわけではありません。物事を世に出し、その振る舞いを観察することで学びます。必ず成功するキャンペーンや機能を作れたら理想ですが、それはできません。誰にもできないのです。

では、戦略は何でしょうか。

より速く動くためのシンプルなルールは、次のとおりです。

間違っていた場合のコストが可逆的で、影響が限定的であれば、速く動く。 不可逆であったり、信頼を損なう可能性がある場合は、慎重に進める。

グロースとは、リリース前に自信を積み上げることではなく、リリース後に自信を獲得していくことです。だからこそ、速いフィードバックが極めて重要になります。

速いフィードバックは競争優位になる

初期段階のグロースについては、さまざまな数字を耳にするでしょう。「やっていることのうち、成果につながるのは 20％だけ」「本当に機能するのは 10％程度」「ほとんどの実験は失敗する」といった具合です。正確な数字がどれなのかは分かりません。ただ、初期フェーズのスタートアップでグロースをリードし、多くのチームと関わってきた中で私が確信しているのは、どれほど多くのことがうまくいかないか、という事実がとにかくフラストレーションを生むということです。

勝つチームは、成功率が高いチームではありません。より早く「分かる」チームです。

速いフィードバックとは、より多くの機能をリリースしたり、実験の数を増やしたりすることではありません。「最小限の方法で、意味のある学びを得るにはどうすればいいか？」と常に問い続けることです。たとえば、アプリに手を加える前に Meta 広告で価値提案をテストしたり、App Store のメッセージングを試して、どの機能訴求が実際にコンバージョンを生むのかを見極めたりすることも含まれます。

それは、次のような問いを立てることかもしれません。

• どのエンゲージメント行動が、継続利用を確実に予測するのか
• どの初期収益シグナルが、より価値の高いユーザーを示しているのか
• ユーザーはどの段階で、コミットすることをためらっているのか

多くのサブスクリプションアプリでは、年額プランのほうが月額プランよりも LTV が高くなることが知られています。そのため、年額プランをできるだけ強く押し出したり、月額プランを完全に削除したりするのが一般的な対応です。短期的にはマネタイズを最適化できるかもしれませんが、その分、学習のスピードは落ちてしまいます。

Streema は、あえてその逆を選びました。Martin Siniawski氏が共有しているように、彼らは月額サブスクリプションをあえて目立つ形で残しました。そうすることで、解約をより早く把握し、何が本当の意味で再現性のある価値を生んでいるのかを理解し、そして実際に離脱したユーザーと対話することができたのです。

実践における、速いフィードバックのルール

これが、実際の現場での「速いフィードバック」の姿です。遅れて得られる確実性よりも、学習スピードを優先するという考え方であり、具体的には次のような取り組みを意味します。

• 統計的に有意であることよりも、素早く失敗できるテストを設計する
• 方向性を示すものだと理解したうえで、プロキシ指標を意図的に使う（決定的ではないが、十分に役立つ）
• 大規模で一方向なリリースよりも、可逆的な変更を優先する
• コンバージョン率やマネタイズだけでなく、インサイトが得られる速さを最適化する
• 短期的にトップライン指標が下がったとしても、より早い「真実の瞬間」を作る
• 定量データだけに頼るのではなく、実際にユーザーと話す
• 期待していた結果でなくても、得られた学びを行動に移す

速いフィードバックは、プロダクトだけの問題ではありません。複数の承認がなければ意思決定できない組織や、学びを得ても実行に移す前に承認が必要な環境では、この仕組みは簡単に機能しなくなります。いわゆる「船頭多くして船山に登る」という状況です。

だからこそ、最後のルールはとてもシンプルです。複雑な承認フローに頼るのではなく、スピードを前提に設計された組織をつくり、自律性と信頼を育てることです。

断言します。速いフィードバックは時間とともに複利的に効き、成長スピードを確実に高めてくれます。

ダーリンは殺せ…速く、しかし自信を持って

速く動くうえで最も難しいのは、リリースそのものではありません。本当に難しいのはその後です。意図的に素早く動き、実際の代替案を作り上げたにもかかわらず、それがまったく機能しなかったときです。先ほど触れた、成果が出なかったプレローンチのランディングページのように。胸が痛む瞬間であり、たいていこのタイミングで「もう少し様子を見よう」という誘惑が忍び寄ってきます。

先ほどのプレローンチ実験に話を戻しましょう。ローンチから約 1 週間が経過していました。コンバージョンが起きるには十分な時間であり、ある程度のデータも集まっていましたが、公式に「確信が持てる」と言えるほどではありません。それでも数値を確認すると、そこから目を背けることはできませんでした。仮にクリエイティブを改善し、クリック単価（CPC）を下げられたとしても、サブスクリプション獲得の目標 CPA を大きく上回る状態になることは明らかだったのです。

その段階になると、「待つこと」は忍耐ではなく、ただの希望に変わります。初期データがこれほど大きく外れている場合、それが勝ちパターンに転じることはまずありません。多少は改善するかもしれませんが、引き続き時間や予算、そして注意を注ぎ込む価値があるほどではないのです。

だからこそ──創業者からの素晴らしい提案もあり──私たちはそれを修繕しようとはしませんでした。見切りをつけ、根本的に異なる構成である 2 ステップのページへと切り替えたのです。

ただし、ここから話は少し難しくなります。

別のクライアントで A/B テストを行っていたとき、私は「やってはいけないこと」をしてしまいました。早い段階で結果をのぞいてしまったのです。結果は芳しくありませんでした。新しいバリアントは、既存のものよりわずかにパフォーマンスが悪かったのです。正直、気に入らない結果でしたが、それでも私は止めませんでした。各バリアントのコンバージョン数がごくわずかで、まだ判断に足るシグナルがなかったからです。このケースでは、時間を与えた判断が結果的に正しく、最終的には新しいバリアントが勝ちました。

実験には、時間をかけるべきケースもあります。特に価格設定実験ではそれが顕著です。初期のコンバージョン率だけを見ると、新しい価格戦略やパッケージがうまくいっていないように見えても、1〜2 回の更新サイクルを経た後に、全体の収益が伸びていることが分かる場合があります。

つまり、すべてのダーリンをすぐに殺せと言っているわけではありません。同時に、すべてに無限の時間を与えるべきだとも言っていません。速くリリースし、速く学ぶことは、「とにかく全部切る」アプローチを意味するわけではないのです。すぐに止めるべきときもあれば、意図的に待つべきときもあります。

ダーリンを見切るためのルール

役立つのは、「なぜ続けるのか」「なぜ止めるのか」を明確にすることです。実際には、私たちは次のような基準でダーリンを見切っています。

• 戦略的に途中結果を確認するが、感情的な反応を招く形で早期結果を広く共有しない
• 統計的な確実性には程遠くても、方向性が見えるだけのデータは確保する
• 単に数値が「上がったか・下がったか」ではなく、目標からどれだけ乖離しているかを数値で把握する
• 実験を単発のテストではなく、より大きなシステムの一部として捉える。この実装が違っていても、仮説そのものを信じ続けることはできる
• 価格実験のように、効果が表れるまで更新サイクルが必要なものなど、あらかじめ時間を与えるべきダーリンを決めておく

何かを早期に止めることは、悲観的な判断ではありません。多くの場合、それは集中力を守り、次の、より良い賭けのための余地を生み出す、最も直接的な方法です。止めないことには、現実的な機会損失があります。生かし続けている実験一つひとつが、本来なら成果を生むかもしれない別の取り組みを選ばない、という判断になっているのです。

これは、植物の剪定のようなものです。元気そうな葉を切り落とすのは心苦しいものですが、それによって植物がより強く、よりよく成長することを分かっているからこそ、あえてそうするのです。

スピードは、品質やユーザーの信頼を犠牲にする必要はない

より速く動くことについて話すとき、多くのチームが抱く最大の不安の一つは、「品質が必ず下がってしまうのではないか」という点です。確かに、そうなるケースもあります。しかし、スピードを重視することが本来意味するのは、決して次のようなことではありません。

• 雑な仕事
• 壊れたユーザー体験
• ユーザーがまだ受け入れる準備のできていないものをリリースすること

私は以前、コミュニティ型アプリを運営するクライアントにアドバイスしていました。そのチームは、コミュニティを本当に居心地の良い場所に保つため、モデレーションの改善を目指していました。非常に良いアイデアでしたが、同時に規模の大きな取り組みでもありました。検討されていた複数の案はいずれも、スコアリングシステムを構築するバックエンド、フロントエンド、デザイン、プロダクトといった複数領域の連携を必要とするものでした。その複雑さゆえに、この施策は重要であるにもかかわらず、「着手するには大きすぎる」と感じられ、何度も後回しにされていたのです。

視点を引いて全体を見直したとき、ある一点が非常に明確になりました。彼らが構想していたモデレーションシステム全体は、たった一つの前提に依存していたのです。それは、ユーザーが実際に、いいねやリアクション、ポジティブ／ネガティブなやり取りを示すシグナルといった入力を提供してくれる、という前提です。もしユーザーがそれを行わなかったり、想定どおりに振る舞わなかったりすれば、このモデル全体は機能しないか、根本的な見直しが必要になります。

そこで私たちは、モデレーションシステム全体を構築するのではなく、まずその仮定を検証することに集中しました。

最初の一歩は、スコアリングモデルでも、完全なモデレーションフローでもありませんでした。単に、ユーザー同士のやり取りの中で、いいね／リアクションボタンを実際に使うかどうかを導入し、観察することだったのです。この単一の行動を見るだけで、より大きな構想に土台があるかどうかを判断できました。

もし利用が少なければ、優先すべきはモデレーションロジックの改善ではなく、その入力をどう促すか、あるいはどう再設計するかを理解することになります。一方で、それが機能すれば、チームははるかに高い確信を持って次のステップに進むことができたのです。

Minimum Viable Product（MVP）とは、実際には何を意味するのか？

ここで重要なのは、ユーザーにとってそれが「未完成」に感じられなかったという点です。ユーザーは、完成していないシステムにさらされたわけでも、質の低い体験を我慢させられたわけでもありません。ユーザーの視点では、単に他者とのやり取りに対して反応し、感じたことを表現する手段が増えただけでした。実際、それだけで、舞台裏でテストされている仕組みについて何も知らなくても、「良い・悪いインタラクションとは何か」に対するコントロール感が高まっていたのです。

これこそが、スピードを正しく活かした状態です。すべてを一気に作ろうとするのではなく、まず何を学ぶ必要があるのかを絞り込むこと。アイデアのリスクを実質的に下げるための、最小のテストは何か。どの前提が間違っていたら、他のすべてが無意味になるのか。

私が Ethan Gar氏による Minimum Viable Product（MVP）の捉え方を気に入っているのは、まさにこの点です。

「多くの人は、Minimum Viable Product という考え方を誤解しています。“Minimum” にばかり注目し、“Viable” を見ていないのです。中核となる機能が壊れているアプリを渡されても、価値は得られず、成果も出ません。スピードを重視するとは、価値を提供できる、最もシンプルな“実行可能な”バージョンに焦点を当てることなのです。」

この違いは非常に重要です。先ほどのモデレーションの例は、スピードそのものを目的にしたものでも、手を抜いたものでもありませんでした。重要だったのは、早い段階で価値を届けながら、どの前提が本当に重要なのかを学ぶことであり、複雑さに過度にコミットする前に、それを見極めることだったのです。

もちろん、スピードを上げれば、物事が壊れる頻度は高くなります。それはトレードオフの一部です。しかし、ほとんどの場合、ユーザーはそれに気づきません。そして、これを正しく行えたとき、速く学べることで得られる価値は、たまに起こる小さな失敗のコストを上回ります。

そして、ここからがより難しい問いです。いつスピードが最適な選択ではなくなり、いつ減速することが品質や信頼を守ることにつながるのでしょうか。

いつスピードよりも完成度を優先すべきか？

スピードが常に正解というわけではありません。慎重になることが臆病さではなく、責任ある判断となる場面もあります。完成度を重視してリリースするのが正しい選択となる瞬間です。こうした状況では、ジェネラリスト的な姿勢が通用しなくなり、速く動きすぎることで、得られる価値以上のリスクを生んでしまうことがあります。

チームが陥りがちな誤りは、完成度を常に標準的な運用モードとして扱ってしまうことです。しかし実際には、完成度を最優先すべきなのは、限られた特定の場面においてです。この緊張関係を乗り越えるためには、どの状況であれば意図的にスピードを落とすべきなのかを明確にすることが役立ちます。

以下に挙げるすべてが、すべてのアプリやブランドに当てはまるわけではありません。それでも、これらを一つひとつ確認していくことで、「偶発的に遅くなっている」のではなく、「意図して減速している」状態を見極めやすくなります。

1. アプリの中核となる機能

アプリが提供する中核的な価値については、満たすべき最低限の基準があります。抽象的な意味での「完璧さ」ではなく、ユーザーが利用の初期段階で、その価値を明確に体感できるレベルであることが重要です。

これは、Ethan Gar が提唱する「minimum viable value（最小限の実行可能な価値）」という考え方とも密接に一致します。目的は、すべてをリリースすることではなく、リリースするものが確実に機能することです。ユーザーがお金を払っている以上、パフォーマンスや信頼性は重要です。検証や改善のスピードを上げることは可能ですが、その土台となる体験は、最初から明確な基準を満たしている必要があります。

2. 大規模で一方向な技術的意思決定

技術的な選択の中には、後戻りが難しいものがあります。たとえば、Flutter への移行を検討しているアプリを支援した際には、どれほど多くのものが影響を受けるかが明らかになりました。このような移行は、ほぼすべての要素に関わり、長期的な影響をもたらします。

こうしたケースでは、スピードを落とすことが正当化されます。なぜそれを行うのか、どの問題を本当に解決するのか、そして成功をどのように測定するのかについて、明確にしておく必要があります。よくある落とし穴は、技術的なリライトを「すべてを直すための口実」として使ってしまうことで、その結果、長期の遅延を招いてしまうことです。

ここで言う完成度とは、すべてを劇的に改善することを意味するわけではありません。多くの場合、新しいバージョンが不安定さを持ち込むことなく、少なくとも従来のバージョンと同等に動作することを保証する、という意味です。その基準はチームが想像するより低いこともありますが、それでも守る価値のあるものです。

3. データプライバシーとセキュリティ

ユーザーデータを扱う場面では、スピードは二の次になります。プライバシー、同意、トラッキング、コンプライアンスといった領域がこれに含まれます。ここでの不注意は、信頼を一気に損ない、その回復は容易ではありません。

この分野は、荒削りな実験や近道が許される場所ではありません。数少ないケースの一つとして、過度なくらい慎重であることが、ほとんどの場合正しい判断となる領域です。

4. 配慮が必要なユーザー層

アプリが、特に配慮を要するユーザー層を対象としている場合は、より慎重な対応が求められます。以前、子ども向けのメンタルヘルスアプリに関わっている人と話したことがありますが、これは二重の意味で非常にセンシティブなテーマでした。

このようなケースでは、意味のあるものをリリースする前に、リサーチや検証に多くの時間と労力が割かれることが一般的です。それは「何もリリースしない」という意味ではありませんが、思慮深さや検証に求められる水準が高く、失敗した場合のコストが極めて重く受け止められている、ということを意味します。

5. ブランドを定義づける瞬間

中には、単に機能を追加するだけでなく、ユーザーがブランドをどう捉えるかそのものを変えるリリースもあります。こうした瞬間には、特別な配慮が必要です。

良い例が、フィットネスアプリの Ladder です。同社は栄養管理機能へと領域を広げ、純粋なフィットネスアプリから、より包括的なヘルスプラットフォームへとポジショニングを変えました。これは競争環境とユーザーの期待の両面において、大きな転換点でした。

最初のバージョンは完璧ではありませんでしたが、必要最低限以上に、意図的に完成度の高いものとして提供されていました。栄養入力についても、音声・画像・テキストといった複数の手段が最初から用意されており、いずれか一つに限定されてはいませんでした。この判断は、スピードや機能範囲の問題ではなく、新しいポジショニングをユーザーに即座に実感してもらうためのものでした。

6. 不可逆な意思決定（ワンウェイドア）

Jeff Bezos氏は、意思決定を「ワンウェイドア」と「ツーウェイドア」に分類しています。ツーウェイドアは元に戻せますが、ワンウェイドアは元に戻せません。

ターゲットユーザーを変更すること、アプリの目的を根本的に変えること、あるいは簡単には撤回できない約束をすることは、いずれもワンウェイドアに該当します。こうした局面では、スピードを落とし、前提条件を徹底的に検証し、長期的な影響について誠実に向き合う必要があります。

7. 実証済みの機能を再構築・スケールする場合

最後に、すでに有効性が確認されているものについては、実装を急ぎすぎるとかえって逆効果になることがあります。そうして生まれるのが、脆弱なシステム、スパゲッティ化したコード、そして増え続けるバグのバックログです。

この点については、私自身も身に覚えがあります。というのも、私の夫が edtech スタートアップで開発者として働いており、まさにこうした急ぎすぎた実装の後始末に、多くの時間を費やしているからです。最初に短縮できた時間は、ほとんどの場合、後になって利息付きで支払うことになります。

スピードを基本に、完成度は選択的に

多くのサブスクリプションチームが失敗する理由は、動きが速すぎることではありません。学ぶまでに時間をかけすぎてしまうことです。確実性は、より綿密な計画や、より多くの承認、整ったスプレッドシートから生まれるものではありません。リリースし、観察し、判断することで初めて得られるものです。

これは、確実性とリスクのバランスを取る行為でもあります。

速いフィードバックは競争優位になります。それは、成功を保証してくれるからではなく、間違ったことに時間を浪費するのを、より早く止められるからです。スピードは、雑な仕事や信頼の破壊を意味するものではありません。うまく機能している場合、それは学習すべき問いを絞り込み、意味のある最小の前提を検証し、うまくいかないと分かったら素早く次に進むことを意味します。

もちろん、スピードを落とすことが正当化される場面、むしろ必要な場面も存在します。信頼、安全性、不可逆性、あるいはコアとなる価値が関わるときです。しかし、そうした場面は例外であり、原則ではありません。多くの初期フェーズのチームにとって、スピードはあくまでデフォルトであるべきです。完成度は、間違えたときのコストが、待つことのコストを上回る場合にのみ、選択的に適用するものなのです。

価格変更は、新規ユーザーと既存のサブスクライバーに対して異なる影響を与え、特定の通知フローが必要となります。また、ユーザーの信頼を維持し、Google Play のポリシーを遵守するためにも、慎重な対応が求められます。そこで本記事では、Google Play におけるサブスクリプション価格変更の仕組みを詳しく解説します。具体的には、以下の内容を取り上げます。

• 新規および既存サブスクライバーそれぞれに対する価格変更の仕組み
• オプトイン型とオプトアウト型の値上げの違い
• 通知要件とそのタイムライン
• 実装の詳細（具体的な例を交えた解説）
• RevenueCat を活用して、サブスクライバー全体に対する価格変更をスムーズに管理する方法

価格変更が異なるサブスクライバーグループに与える影響

Google Play Console または API を通じてサブスクリプション価格を変更した場合でも、その影響はすべてのユーザーに同じように及ぶわけではありません。Google Play では、新規サブスクライバーと既存サブスクライバーを次のように異なる形で扱います。

新規サブスクライバー

新規サブスクライバーに対しては、価格変更は比較的早く反映され、通常は変更後数時間以内に有効になります。新しい価格が有効になると、新たにサブスクリプションを開始するユーザーは、更新後の価格を確認し、その価格で支払うことになります。このグループに対して特別な対応は必要ありません。購入画面に到達した時点で、常に現在の価格が表示されるだけです。

既存サブスクライバー：レガシー価格コホート

既存サブスクライバーはまったく異なる扱いになります。デフォルトでは、サブスクリプション価格を変更すると、現在のサブスクライバーは Google Play がレガシー価格コホートと呼ぶグループに分類されます。これらのユーザーは、価格変更の影響を受けることなく、更新のたびに引き続き元の価格を支払い続けます。このデフォルトの挙動は、想定外の請求変更からユーザーを保護すると同時に、いつ・どのように新しい価格へ移行させるかを、開発者がコントロールできるようにするためのものです。

このレガシーコホートの仕組みにより、Play Console 上で価格を変更しても、既存サブスクライバーが支払う金額が自動的に変更されることはありません。既存サブスクライバーを新しい価格へ移行させるには、明示的に移行を選択する必要があります。

レガシー価格コホートの終了

既存のサブスクライバーをレガシー価格から新しい価格へ移行する場合は、価格移行 API を使用します。これにより、新しい価格が現在ユーザーが支払っている金額より高いか低いかに応じて、「値上げ」または「値下げ」のフローが開始されます。

移行 API の利用

サブスクライバーを新しい価格へ移行するには、バックエンド側から monetization.subscriptions.basePlans.migratePrices エンドポイントを呼び出します。

\/\/ Backend service for initiating price migration
class PriceMigrationService(
    private val androidPublisher: AndroidPublisher
) {
    fun migrateSubscribersToNewPrice(
        packageName: String,
        productId: String,
        basePlanId: String,
        regions: List<String>,
        newPriceAmountMicros: Long,
        currencyCode: String
    ) {
        val regionalConfigs = regions.map { regionCode ->
            RegionalPriceMigrationConfig().apply {
                this.regionCode = regionCode
                this.priceIncreaseType = "OPT_IN" \/\/ or "OPT_OUT" if eligible
                this.oldestAllowedPriceVersionTime = null \/\/ migrate all legacy cohorts
            }
        }

        val request = MigratePricesRequest().apply {
            this.regionalPriceMigrationConfigs = regionalConfigs
        }

        androidPublisher
            .monetization()
            .subscriptions()
            .basePlans()
            .migratePrices(packageName, productId, basePlanId, request)
            .execute()
    }
}

この移行は地域ごとに設定されるため、異なる市場に対して段階的に価格変更を展開したり、地域ごとの価格差を個別に管理したりすることが可能です。

値下げのフロー

新しい価格が、ユーザーが現在支払っている金額よりも低い場合、移行プロセスはシンプルで、ユーザーにとっても負担の少ないものになります。値下げは、ユーザーの明示的な同意を必要とせず、自動的に適用されます。

値下げの仕組み

サブスクライバーを低い価格へ移行すると、Google Play は値下げが行われたことを知らせるメール通知をユーザーに送信します。その後、次回の更新時から、ユーザーは新しい低い価格で支払うことになります。値下げは自動的に適用されるため、ユーザー側での操作は一切必要ありません。

ただし、タイミングに関して注意すべき点が 1 つあります。Google Play では、更新の最大 48 時間前（インドおよびブラジルでは最大 5 日前）に支払いが承認される場合があります。値下げが適用される前に、すでに高い価格で支払いが承認されていた場合、その更新分については高い価格が請求されますが、以降の更新からは低い価格が適用されます。

アプリ内での値下げ対応

実装の観点では、値下げに対して特別な対応はほとんど必要ありません。ユーザーに対して、この変更を知らせるコミュニケーションを行うことを検討するとよいでしょう。

class PriceChangeManager(
    private val backendApi: BackendApi
) {
    suspend fun checkForPriceChanges(userId: String): PriceChangeInfo? {
        val subscriptionStatus = backendApi.getSubscriptionStatus(userId)
        val priceChange = subscriptionStatus.pendingPriceChange ?: return null

        return when {
            priceChange.newPriceMicros < priceChange.currentPriceMicros -> {
                PriceChangeInfo.Decrease(
                    currentPrice = formatPrice(priceChange.currentPriceMicros),
                    newPrice = formatPrice(priceChange.newPriceMicros),
                    effectiveDate = priceChange.effectiveDate
                )
            }
            else -> {
                \/\/ Handle price increase (covered in next section)
                handlePriceIncrease(priceChange)
            }
        }
    }
}

\/\/ In your UI layer
fun showPriceDecreaseNotification(info: PriceChangeInfo.Decrease) {
    showBanner(
        title = "Good news!",
        message = "Your subscription price is decreasing from ${info.currentPrice} " +
            "to ${info.newPrice} starting ${formatDate(info.effectiveDate)}."
    )
}

値下げは一般的にユーザーにとって前向きな変更であるため、主な対応ポイントは同意フローの管理ではなく、価格が変更されたことをユーザーに確実に認識してもらうことです。

値上げのフロー：オプトイン型

値上げは、ユーザーへの周知が必要であり、多くの場合、明示的な同意も求められるため、より複雑になります。値上げのデフォルト方式はオプトイン型で、ユーザーが新しい価格に明確に同意しない限り、課金されることはありません。

オプトインのタイムライン

オプトイン型の値上げフローは、明確に区切られたフェーズを持つ特定のタイムラインに沿って進行します。

冒頭の 7 日間のフリーズ期間は、意図的に設けられています。この期間中、Google Play による自動通知が始まる前に、開発者が自社のチャネルを通じてユーザーに通知することが可能です。これにより、メッセージ内容をコントロールし、値上げによってユーザーが得られる価値を説明する余地が生まれます。

ユーザーによる同意の要件

オプトイン型の値上げでは、ユーザーが新しい価格に明示的に同意する必要があります。ユーザーは、Play ストアのサブスクリプション管理画面で価格変更の説明を確認し、同意するか、または拒否するかを選択します。

新しい価格が適用される最初の更新までにユーザーが値上げに同意しなかった場合、そのサブスクリプションは自動的に解約されます。現在の請求期間が終了するまでは引き続き利用できますが、サブスクリプションは更新されません。

アプリ内でのオプトイン型値上げ対応

アプリ側では、保留中の値上げを検知し、ユーザーが同意プロセスを完了できるように案内する必要があります。

class OptInPriceIncreaseManager(
    private val billingClient: BillingClient,
    private val backendApi: BackendApi
) {
    sealed class PriceIncreaseState {
        object None : PriceIncreaseState()
        data class Pending(
            val currentPrice: String,
            val newPrice: String,
            val effectiveDate: Instant,
            val inFreezePeriod: Boolean
        ) : PriceIncreaseState()
        object Accepted : PriceIncreaseState()
        object Declined : PriceIncreaseState()
    }

    suspend fun checkPriceIncreaseStatus(userId: String): PriceIncreaseState {
        val subscriptionStatus = backendApi.getSubscriptionStatus(userId)
        val priceChange = subscriptionStatus.pendingPriceChange

        if (priceChange == null || priceChange.newPriceMicros <= priceChange.currentPriceMicros) {
            return PriceIncreaseState.None
        }

        return when (priceChange.state) {
            "OUTSTANDING" -> {
                val freezePeriodEnd = priceChange.initiatedAt.plus(Duration.ofDays(7))
                PriceIncreaseState.Pending(
                    currentPrice = formatPrice(priceChange.currentPriceMicros),
                    newPrice = formatPrice(priceChange.newPriceMicros),
                    effectiveDate = priceChange.effectiveDate,
                    inFreezePeriod = Instant.now().isBefore(freezePeriodEnd)
                )
            }
            "CONFIRMED" -> PriceIncreaseState.Accepted
            "CANCELED" -> PriceIncreaseState.Declined
            else -> PriceIncreaseState.None
        }
    }

    fun showPriceIncreaseUI(
        activity: Activity,
        state: PriceIncreaseState.Pending
    ) {
        if (state.inFreezePeriod) {
            \/\/ During freeze period, show your own messaging
            showCustomPriceIncreaseDialog(
                currentPrice = state.currentPrice,
                newPrice = state.newPrice,
                effectiveDate = state.effectiveDate,
                onAcceptClick = { openPlayStoreSubscriptionSettings(activity) }
            )
        } else {
            \/\/ After freeze period, can also use Google's in app messaging
            showInAppMessage(activity)
        }
    }

    private fun showInAppMessage(activity: Activity) {
        val params = InAppMessageParams.newBuilder()
            .addInAppMessageCategoryToShow(
                InAppMessageParams.InAppMessageCategoryId.SUBSCRIPTION_PRICE_CHANGE
            )
            .build()

        billingClient.showInAppMessages(activity, params) { result ->
            \/\/ Handle the result
            when (result.responseCode) {
                InAppMessageResult.InAppMessageResponseCode.NO_ACTION_NEEDED -> {
                    \/\/ No price change message needed or user already responded
                }
                InAppMessageResult.InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED -> {
                    \/\/ User interacted with the message - refresh subscription status
                    refreshSubscriptionStatus()
                }
            }
        }
    }

    private fun openPlayStoreSubscriptionSettings(activity: Activity) {
        val intent = Intent(Intent.ACTION_VIEW).apply {
            data = Uri.parse(
                "<https:\/\/play.google.com\/store\/account\/subscriptions>"
            )
            setPackage("com.android.vending")
        }
        activity.startActivity(intent)
    }
}

値上げ時に価値を伝えるコミュニケーション

フリーズ期間は、なぜ価格が引き上げられるのかをユーザーに対して直接伝えるための重要な機会です。この期間に適切なコミュニケーションを行うことで、値上げへの同意率を大きく向上させることができます。

fun showCustomPriceIncreaseDialog(
    currentPrice: String,
    newPrice: String,
    effectiveDate: Instant,
    onAcceptClick: () -> Unit
) {
    showDialog(
        title = "Subscription Update",
        message = """
            Starting ${formatDate(effectiveDate)}, your subscription will change
            from $currentPrice to $newPrice per month.

            Since you subscribed, we've added:
            \u2022 Advanced analytics dashboard
            \u2022 Offline mode for all content
            \u2022 Priority customer support
            \u2022 And 15+ other features

            To continue enjoying these features, please confirm the new price
            in your Play Store subscription settings.
        """.trimIndent(),
        positiveButton = "Review in Play Store" to onAcceptClick,
        negativeButton = "Maybe Later" to { \/* dismiss *\/ }
    )
}

値上げのフロー：オプトアウト型

特定の地域および一定の条件下では、Google Play でオプトアウト型の値上げが許可されています。オプトアウト型の値上げでは、価格変更についてユーザーに通知は行われますが、ユーザーが明示的に解約やプラン変更を行わない限り、自動的に新しい価格で課金されます。

適用条件

オプトアウト型の値上げは、すべてのケースで利用できるわけではありません。利用可否は、地域ごとの対応状況（オプトアウト型値上げに対応している国は一部に限られます）、この方式を使用できる頻度の制限、国ごとに定められた値上げ率または金額の上限、さらに開発者側に求められる追加の適格要件など、複数の要因によって決まります。これらの制約があるため、オプトアウト型の値上げは、価格変更の主な手段というよりも、補助的な選択肢として考えるべきものです。

オプトアウトのタイムライン

オプトアウト型の値上げは、オプトイン型とは異なるタイムラインで進行します。

オプトアウト型における通知期間は国によって異なります。30 日前の通知が求められる国もあれば、60 日前の通知が必要な国もあります。これらの地域ごとの要件は、オプトアウト移行を開始すると、Google Play によって自動的に処理されます。

オプトアウト型値上げへの対応

実装の観点では、オプトアウト型の値上げは、サブスクリプションを継続するためにユーザー側で特別な操作を行う必要がないため、比較的シンプルです。

fun handleOptOutPriceIncrease(priceChange: PriceChangeInfo) {
    \/\/ For opt-out increases, the state will be "CONFIRMED" rather than "OUTSTANDING"
    \/\/ Users will be charged the new price automatically unless they cancel

    showNotification(
        title = "Subscription Price Update",
        message = "Starting ${formatDate(priceChange.effectiveDate)}, " +
            "your subscription will be ${priceChange.newPrice}\/month. " +
            "No action needed to continue your subscription."
    )
}

ただし、ユーザーの操作が不要であっても、今後予定されている価格変更については、ユーザーに対して明確に伝える必要があります。

アプリ内通知の要件

オプトイン型・オプトアウト型のいずれの値上げ方式を使用する場合でも、Google Play では、価格変更に関するアプリ内通知を表示することが求められます。この要件は、アプリが動作するすべてのデバイスタイプに適用されます。

必須となる通知表示先

価格変更に関する通知は、モバイルデバイス（スマートフォンおよびタブレット）、Android TV、その他のストリーミングデバイスで表示する必要があります。唯一の例外はウォッチデバイスで、画面サイズが限られているため、アプリ内通知は推奨されてはいるものの、必須ではありません。

通知のタイミング

オプトイン型の値上げの場合、推奨される対応は、フリーズ期間（1 日目から 7 日目）に、値上げの理由や提供価値を説明する独自のメッセージを表示し、その後、フリーズ期間終了後（8 日目以降）は、リマインダーの表示を継続しつつ、Google の In-App Messaging API を使用することです。

class PriceChangeNotificationManager(
    private val billingClient: BillingClient
) {
    fun showPriceChangeNotificationIfNeeded(
        activity: Activity,
        priceIncreaseState: PriceIncreaseState
    ) {
        when (priceIncreaseState) {
            is PriceIncreaseState.Pending -> {
                \/\/ Always show some form of notification for pending increases
                if (priceIncreaseState.inFreezePeriod) {
                    showCustomNotificationBanner(activity, priceIncreaseState)
                } else {
                    \/\/ Use Google's in app messaging
                    showGoogleInAppMessage(activity)
                }
            }
            else -> {
                \/\/ No notification needed
            }
        }
    }

    private fun showCustomNotificationBanner(
        activity: Activity,
        state: PriceIncreaseState.Pending
    ) {
        \/\/ Show a subtle banner at the top of the screen
        val banner = PriceChangeBanner(activity).apply {
            setMessage(
                "Your subscription price will change to ${state.newPrice} " +
                "on ${formatDate(state.effectiveDate)}. Tap to review."
            )
            setOnClickListener {
                openPriceChangeDetails(activity, state)
            }
        }
        banner.show()
    }

    private fun showGoogleInAppMessage(activity: Activity) {
        val params = InAppMessageParams.newBuilder()
            .addInAppMessageCategoryToShow(
                InAppMessageParams.InAppMessageCategoryId.SUBSCRIPTION_PRICE_CHANGE
            )
            .build()

        billingClient.showInAppMessages(activity, params) { \/* handle result *\/ }
    }
}

価格変更が重複した場合の対応

以前の価格変更がまだ保留中の状態で、新たな価格変更を開始した場合はどうなるのでしょうか。Google Play では、先に進行中だった価格変更をキャンセルし、新しい価格変更を適用することで対応します。

キャンセルおよび置き換えのフロー

価格変更が重複した場合、以前の価格移行は CANCELED としてマークされ、 SUBSCRIPTION_PRICE_CHANGE_UPDATED の Real-Time Developer Notification (RTDN) が送信されます。その後、新しい価格移行が有効になり、ユーザーは最新の価格変更にのみ対応すればよくなります。この挙動により、ユーザーが複数の連続した値上げに同意することを求められる状況が回避され、ユーザー体験の悪化を防ぐことができます。

価格変更ステータスの追跡

バックエンド側では、RTDN 通知を処理して価格変更のステータスを追跡する必要があります。

\/\/ Backend notification handler
class PriceChangeNotificationHandler(
    private val subscriptionRepository: SubscriptionRepository,
    private val playDeveloperApi: AndroidPublisher
) {
    fun handlePriceChangeNotification(notification: DeveloperNotification) {
        val purchaseToken = notification.subscriptionNotification.purchaseToken

        when (notification.subscriptionNotification.notificationType) {
            NotificationType.SUBSCRIPTION_PRICE_CHANGE_UPDATED -> {
                \/\/ Query the current state of the price change
                val subscription = playDeveloperApi
                    .purchases()
                    .subscriptionsv2()
                    .get(packageName, purchaseToken)
                    .execute()

                val priceChangeState = subscription.lineItems[0]
                    .autoRenewingPlan
                    ?.priceChangeDetails

                if (priceChangeState != null) {
                    subscriptionRepository.updatePriceChangeStatus(
                        purchaseToken = purchaseToken,
                        state = priceChangeState.priceChangeState,
                        newPriceMicros = priceChangeState.newPrice?.priceMicros,
                        expectedNewPriceChargeTime = priceChangeState.expectedNewPriceChargeTime
                    )

                    \/\/ Notify app layer to update UI if needed
                    notifyPriceChangeUpdated(purchaseToken, priceChangeState)
                }
            }
        }
    }
}

誤って行った価格変更からの復旧

ミスは起こり得るものです。意図せず価格を変更してしまった場合や、想定していない価格移行を開始してしまった場合、復旧の方法は変更の種類や、どれだけ時間が経過しているかによって異なります。

オプトイン型値上げの取り消し

オプトイン型の値上げでは、取り消しを行うタイミングが非常に重要になります。7 日以内（フリーズ期間中）に取り消した場合、Google Play からユーザーへの通知は一切送信されていないため、この変更は実質的にユーザーから見えないものになります。7 日を過ぎてから取り消した場合、新しい価格でまだ課金されていないユーザーについては価格変更がキャンセルされますが、すでに通知を受け取っているユーザーも存在する可能性があり、混乱を招くことがあります。

オプトアウト型値上げの取り消し

オプトアウト型の値上げの場合、元の価格に戻すことで、新しい価格でまだ課金されていないユーザーに対しては値上げがキャンセルされます。ただし、支払い承認のタイミングには注意が必要です。地域によっては、更新の最大 5 日前に支払いが承認されることがあり、すでに承認されているユーザーについては、引き続き課金される可能性があります。

値下げの取り消し

値下げをキャンセルして元の高い価格に戻す必要がある場合は、まず Play Console 上で元の価格に戻し、その値上げをオプトイン型にするかオプトアウト型にするかを選択します。その後の結果は、取り消しとユーザーの更新タイミングとの関係によって決まります。取り消しからユーザーの更新までの期間が通知ウィンドウ（国によって 30〜60 日）よりも長い場合、ユーザーは次回の更新時に元の価格を支払います。一方、その期間が通知ウィンドウより短い場合は、ユーザーは一度だけ低い価格で課金され、その後、通常の値上げ通知フローに進むことになります。

分割払いサブスクリプションと価格変更

サブスクリプションで分割払いプラン（一定回数の支払いを前提とするプラン）を使用している場合、価格変更の挙動は通常のサブスクリプションとは異なります。

分割払いサブスクリプションでは、価格変更は、現在有効な契約期間が終了した時点でのみ適用されます。分割払いの途中にあるユーザーに対して価格を変更することはできず、新しい価格は、契約が終了した後、最初の更新時に有効になります。たとえば、12 か月の分割払いプランの後に月次の自動更新へ移行するサブスクリプションの場合、どのような価格変更を行っても、その変更が反映されるのは、12 か月の契約期間が完了し、月次更新フェーズに移行してからになります。

価格変更のテスト

本番環境のサブスクライバーに価格変更を展開する前に、Google Play が提供するテストツールを使って、各フローを十分に検証することが重要です。

ライセンステスターの利用

ライセンステスターは、実際のサブスクライバーに影響を与えることなく、価格変更に関する通知を受け取ることができます。Play Console でライセンステスターを設定し、通知の配信やタイミング、アプリ内メッセージの表示、同意および拒否のフロー、バックエンドにおける状態遷移などを確認してください。

Play Billing Lab

Google は、課金シナリオをテストするための Play Billing Lab アプリを提供しています。これを使用して価格変更のシナリオをシミュレーションし、アプリが各状態を正しく処理できているかを検証します。

監査ログ

Play Console では、すべての価格変更について変更履歴が記録されます。このログを利用することで、価格がいつ更新されたのか、誰が変更を行ったのか、どの地域が影響を受けたのかを確認できます。この監査ログは、問題の調査や、誤って行われた変更の履歴を振り返る際に非常に有用です。

RevenueCat が価格変更管理をどのように簡素化するか

大規模なサブスクライバーベースに対して価格変更を管理するには、高い複雑性が伴います。具体的には、ユーザーごとの移行ステータスの追跡、RTDN 通知の処理、適切なアプリ内メッセージの表示、そしてさまざまなエッジケースへの対応が必要になります。RevenueCat は、こうした複雑さの多くを抽象化しつつ、価格変更を効果的に管理するための追加ツールを提供します。

自動的な状態管理

RevenueCat は、Google Play の RTDN 通知を開発者に代わって処理し、保留中の価格変更を含む最新のサブスクリプション状態を維持します。通知を受信・処理するための独自のインフラを構築する代わりに、RevenueCat に対して現在のカスタマー状態を問い合わせるだけで済みます。

fun checkForPriceChanges() {
    Purchases.sharedInstance.getCustomerInfoWith { customerInfo ->
        val entitlement = customerInfo.entitlements["premium"]

        \/\/ RevenueCat's CustomerInfo reflects current subscription state
        \/\/ including any pending price changes processed from RTDN

        if (entitlement?.isActive == true) {
            \/\/ Check for billing issues that might indicate price change problems
            entitlement.billingIssueDetectedAt?.let { issueDate ->
                showBillingRecoveryUI(customerInfo.managementURL)
            }
        }
    }
}

ユーザー操作のための管理 URL

RevenueCat の CustomerInfo には、 managementURL プロパティが含まれており、Google Play のサブスクリプション管理画面への直接リンクが提供されます。ユーザーは、この画面で価格変更への同意または拒否を行います。

fun guideToPriceChangeAcceptance(customerInfo: CustomerInfo) {
    val managementUrl = customerInfo.managementURL

    showDialog(
        title = "Action Required",
        message = "Please review the upcoming changes to your subscription.",
        positiveButton = "Open Settings" to {
            openUrl(managementUrl)
        }
    )
}

クロスプラットフォームでの一貫性

複数のプラットフォームにまたがるアプリの場合でも、RevenueCat は Android、iOS、その他のプラットフォーム間でサブスクリプション状態の一貫性を確保します。ユーザーがいずれかのデバイスで価格変更に同意すると、その更新された状態は追加の実装なしで、すべてのデバイスに反映されます。

サーバーサイド処理のための Webhook

RevenueCat は、サブスクリプションイベントを正規化された形式でサーバーに通知する Webhook を提供します。これは、生の RTDN 通知を直接処理するよりもシンプルで、価格変更に関連するイベントも含まれています。

\/\/ Your webhook handler
fun handleRevenueCatWebhook(event: WebhookEvent) {
    when (event.type) {
        "RENEWAL" -> {
            \/\/ Renewal completed - check if price changed
            val transaction = event.transaction
            if (transaction.priceInPurchasedCurrency != previousPrice) {
                \/\/ Price change took effect
                updateUserPricing(event.appUserId, transaction.priceInPurchasedCurrency)
            }
        }
        "CANCELLATION" -> {
            \/\/ User canceled, might be due to price change rejection
            val reason = event.cancellationReason
            if (reason == "PRICE_INCREASE") {
                \/\/ Track churn related to price changes
                analytics.trackPriceChangeChurn(event.appUserId)
            }
        }
    }
}

価格変更の影響を把握するための分析機能

RevenueCatのChart では、価格変更の影響を把握するための分析データを確認できます。これには、価格変更のタイミングと関連づけた解約率、値上げ通知を受け取ったサブスクライバーのコンバージョン率、価格変更前後の収益への影響分析などが含まれます。これらのインサイトは、価格戦略に関する意思決定を行い、今後の価格変更において最適なタイミングやコミュニケーション方法を見極めるのに役立ちます。

RevenueCat を使う際のベストプラクティス

RevenueCat を価格変更管理に利用する場合は、カスタマー属性を活用して保留中の価格変更があるユーザーを特定し、フリーズ期間中に対象を絞ったコミュニケーションを行うなど、積極的な情報提供を重視してください。また、価格変更通知から同意に至るまでのコンバージョン率や、影響を受けたユーザーの解約率といった主要な指標を継続的にモニタリングすることも重要です。さらに、managementURL を通じて、ユーザーが Play ストアのサブスクリプション設定へ簡単にアクセスできる導線を常に用意しておくべきです。最後に、RevenueCat が提供する正規化されたデータを活用することで、値上げが保留中の状態でプラン変更が行われた場合などのエッジケースにも、無理なく対応できます。

サブスクリプション価格変更のベストプラクティス

これまでに解説してきた仕組みを踏まえ、価格変更を成功させるために実践すべき重要なポイントを紹介します。

コミュニケーション戦略を計画する

価格変更を開始する前に、影響を受けるユーザーにどのように伝えるかを計画しておきましょう。ユーザーが得られる価値を説明するメッセージを用意し、フリーズ期間を使って独自の案内を行うかどうかを検討します。また、価格変更に敏感なユーザー向けに、年額プランや既存価格を維持する選択肢などの代替案を提示することも考えられます。

地域ごとに段階的に展開する

グローバルに価格を引き上げる場合は、地域ごとに段階的に展開することを検討してください。まずは規模の小さい市場でテストを行い、反応を確認したうえで、初期のフィードバックをもとにメッセージを調整します。最大規模の市場に影響が及ぶ前に、問題へ対応する時間を確保することが重要です。

同意率をモニタリングする

オプトイン型の値上げに対して、どれだけのユーザーが同意し、どれだけのユーザーがサブスクリプションを解約しているかを追跡します。

class PriceChangeAnalytics(
    private val analytics: AnalyticsService
) {
    fun trackPriceChangeOutcome(
        userId: String,
        originalPrice: Long,
        newPrice: Long,
        outcome: PriceChangeOutcome
    ) {
        analytics.track(
            event = "price_change_outcome",
            properties = mapOf(
                "user_id" to userId,
                "original_price_micros" to originalPrice,
                "new_price_micros" to newPrice,
                "increase_percentage" to calculatePercentage(originalPrice, newPrice),
                "outcome" to outcome.name
            )
        )
    }
}

enum class PriceChangeOutcome {
    ACCEPTED,
    DECLINED,
    SUBSCRIPTION_CANCELED,
    NO_RESPONSE_BEFORE_DEADLINE
}

同意率が想定より低い場合は、コミュニケーション戦略の見直しや、値上げ幅そのものの再検討が必要になるかもしれません。

代替案を用意する

より高い価格を支払う意思がないユーザーでも、別のプランであれば継続する可能性があります。価格を抑えたプランへのダウングレード導線を用意したり、実質的な月額単価を下げた年額プランを提供したり、解約を防ぐための「ライト」プランを新たに用意することも有効です。

アプリ内での移行をスムーズに処理する

価格変更中のあらゆる状態を、アプリが適切に処理できるようにしておきましょう。値上げが保留中のユーザーには分かりやすいメッセージを表示し、値上げを拒否したユーザーが即座に利用できなくなることがないよう配慮します。また、同意したユーザーにとっては、価格の切り替えが違和感なく行われることが重要です。

まとめ

Google Play におけるサブスクリプション価格変更は、ユーザーを保護しつつ、開発者に柔軟性を提供するために設計された、慎重に構成されたプロセスです。理解しておくべき重要なポイントは、既存サブスクライバーを自動的な価格変更から守るレガシー価格コホートの仕組み、オプトイン型とオプトアウト型の値上げの違いとそれぞれのタイムライン、デバイスタイプを横断して適用される通知要件、そしてタイミングや適用可否に影響する地域ごとの違いです。

値下げの場合、プロセスは比較的シンプルです。ユーザーは次回の更新時から自動的に低い価格で課金されます。一方、値上げの場合は、デフォルトでオプトイン型フローが適用され、7 日間のフリーズ期間の後に 30 日間の Google Play 通知期間を経て、有効日を迎えます。このフローでは、ユーザーの明示的な同意が必要になります。

価格変更を直接実装するには、RTDN 通知の処理、バックエンドでのサブスクリプション状態の管理、そしてユーザーが同意プロセスを進められるようにするための UI 構築が必要です。RevenueCat は、これらの通知処理を自動で行い、正規化されたデータ、分析機能、さらにユーザー操作のための管理 URL を提供することで、この複雑さを大幅に軽減します。その結果、開発者はビジネスや、より重要な取り組みに集中することができます。

どのようなアプローチを取るにしても、価格変更を成功させるためには、ユーザーが受け取る価値について明確に伝えることが不可欠です。フリーズ期間は、Google Play の自動通知が始まる前に、メッセージの方向性を自らコントロールできる貴重な機会です。この期間を有効に活用することで、アプリが提供する価値を反映した価格調整を行いながら、ユーザーの信頼を維持することができます。サブスクリプション価格変更に関する完全なドキュメントについては、Android Developer の公式ドキュメントおよび RevenueCat のサブスクリプション管理ガイドを参照してください。

ただし、ここで強調しておきたい点があります。目的はサブスクリプションを置き換えることではありません。あくまで、それを補完することです。ユーザーがアプリを発見し、利用し、そして離脱していく過程の中で、ハイブリッドマネタイズは可能な限り多くのユーザーを収益化の対象として捉えることを可能にします。

なぜハイブリッドマネタイズなのか？サブスクリプション単体モデルの限界

私が長い間ハイブリッドマネタイズを提唱してきた理由は、獲得（UA）が本質的にはビジネスモデル同士の競争だからです。ARPUが高いほど、有料広告オークションで有利なポジションを取れ、回収期間は短くなり、リテンションやオンボーディングなどに再投資できる余地も広がります。そのため、サブスクリプションは優れたモデルである一方で、根本的な欠陥も抱えています。それが「高い最低ライン（フロア）と低い上限（シーリング）」という性質です（これについては後ほど詳しく触れます）。

サブスクリプションは二択です。支払うか、支払わないか。

しかし、実際の需要は二択ではありません。支払い意欲額は連続的に分布しています。

上のグラフ（State of Subscription Apps 2025 より）によると、90%のユーザーはコンバージョンしないと予測されています。しかも、特定の業種、地域、非iOSプラットフォームでは、この状況はさらに深刻です。昨年、私はある国で100万人以上のユーザーを獲得したにもかかわらず、有料サブスクユーザーが1,000人未満というアプリを目にしました。

問題は、単一の継続課金価格が「ほとんどのユーザーは同程度の支払い意欲を持っている」という前提に立っていることです。しかし現実には、プレミアム価格でも喜んで支払うユーザーもいれば、たまに価値を感じるものの、継続課金は正当化できないユーザーもおり、そもそも決してサブスクしないユーザーも多く存在します。

その結果、よくある2つのボトルネックが生まれます。

高いシーリング（上限）の問題

単一のオファーは、購入意欲の低いユーザーにとって障壁が大きすぎます。割引を試したり、サブスクリプション期間を短くしたりすることはできますが、それでも一部のユーザー（たとえば新興国のAndroidユーザーなど）は反応しません。

多くのユーザーは、そもそもサブスクリプションに加入しません。しかし彼らは依然として価値を生み出しています（注意、データ、拡散など）。そして、提示の仕方を変えたり（たとえばアプリ内課金を提供したり）、より低い価格帯であれば、何らかの形で支払う意思を持つユーザーもいます。

問題点：アプリに価値を感じているにもかかわらず、サブスクリプションという心理的・金銭的ハードルを越えられない購買意欲の低いユーザーからの収益を取りこぼしています。

低いフロア（下限）の問題

高いシーリングよりも、むしろ深刻かもしれません。多くのサブスクリプションモデルには「クジラ」、つまり超高額課金ユーザーが存在しません。ハイブリッドマネタイズ（主にIAP＋広告）を先駆けてきたゲームアプリでは、他のユーザーの支出が少なくても、ごく一部のユーザーが売上の大部分を占めることがあります。たとえば、私はかつて大規模な「マッチ3」ゲームのデータで、有料ユーザーの2%のうち、さらにその2%未満（つまり全体の0.04%）が、実際には売上の半分以上を生み出しているケースを見たことがあります。サブスクリプション単体のアプリでは、この可能性が失われます。

問題点：他のユーザーのコンバージョンを損なわずに価格を引き上げることができないため、購入意欲の高いユーザーを十分にマネタイズできていません。

本質的に、ハイブリッドマネタイズとは「需要の粒度」に「価格の粒度」を合わせることなのです。

需要曲線への適応

多くのアプリは、利用意図・利用頻度・緊急度が大きく異なるユーザーを同時に抱えています。しかし単一のサブスクリプション価格は、そうした違いをすべて平坦化してしまいます。

視覚的には、オーディエンスを次のような需要曲線として捉えることができます。

• 左側：パワー、スピード、利便性のためなら、より高い金額を支払う意思のあるユーザー
• 右側：まったく支払う意思のないユーザー
• 中央：ときどき価値は欲しいが、サブスクリプションには抵抗があるユーザー

ハイブリッドマネタイズは、この需要曲線上の各ポイントに対して、適切なマネタイズ手段を配置し、すべてのユーザーに同じ選択を強制することを避けます。

アプリにおけるマネタイズの需要曲線は非常に極端で、次のように表現できます。

この直線上の一点だけを選ぶ二値的なサブスクリプションモデルでは、多くの収益機会を取りこぼしています。

需要曲線に適応することで、オファーを改善し、ARPUを高めるための選択肢は数多く存在します。以下にその手段の一部を示します。

ハイブリッドマネタイズの手法（アプリ事例付き）

私がこれまでに関わり、また観察してきたハイブリッドマネタイズの事例はすべて、サブスクリプションを重力の中心（コア）として維持したまま、その上にレイヤーを重ねるという構成になっています。ここから、いくつかの具体例を見ていきましょう。

1. 価格設定とパッケージング

ここではあまり深掘りしませんが、より高度なマネタイズに向けた最も分かりやすい最初の一歩は価格設定とパッケージの調整です。ペイウォールのA/Bテストが以前よりも簡単に行えるようになったことで、これはすでに多くのアプリで実践されています。

この段階では、開発者は（そして実際に）さまざまな要素を試すことができます。たとえば、異なる価格帯の検証、プラン構成の組み合わせ（プランはいくつ用意するのか、週次／月次／年次なのか）、セグメンテーション（これは長年の遅れを経て、AIによってようやく本格化すると私は予想しています）、価格のローカライズなどです。

かなり極端な例としては、Headway のディスカウントフローがあります。私のケースでは、提示されるオファーが €89.99 から €21.99 まで下がっていきました。

2. サブスクリプションのティア（段階）

複数のサブスクリプションティアを提供すること自体は、厳密には「ハイブリッド」ではありません（あくまでサブスクリプションのみだからです）。しかし、需要曲線に合わせて提供内容を調整するという点では、ハイブリッドマネタイズに近づくアプローチと言えます。

SaaS（Software as a Service）ビジネスでは、異なるユーザープロファイルに対して機能を段階的に提供する手法が、以前から成功裏に使われてきました。その一例が Photoroom です。Photoroom では、利用パターンに基づいてユーザーをセグメントし、Photoroom Pro、Max、Ultra といった複数のプランを提供しています。

サブスクリプションの巨大プレイヤーである Noom や Tinder も、いずれもティア（段階）を活用しています。

また、厳密にはサブスクリプションの「ティア」とは言えないものの、複数のアプリをポートフォリオとして持つ多くのデベロッパーは、バンドルを用いてより高い価格帯へのアップセルを行っています。例としては、Monkey Taps（アプリ内およびアプリストア上）や Reflectly（Web）などがあります。

3. サブスクリプション＋広告

広告は、価格に関係なく一切支払う意思を示さないユーザーが約90%いる状況において、最も分かりやすいマネタイズ手段のひとつです。私自身、99%オフという極端なディスカウントを試したことがありますが、コンバージョン率の上昇はごくわずかでした。このようなユーザー層が多い場合、広告で補完するのは有効な手法になり得ます。

このユースケースでよく知られている例が、サブスクリプションのロールモデルとも言える Duolingo です。Duolingo は、広告付きのコアとなるフリーミアムオファーに加え、広告を削除できるプレミアムプランや IAP を組み合わせています。いくつかの事例研究では、サブスクリプション＋広告により、ユーザーベースや実装次第で 10〜30%の収益向上が見込めるとされています。

ただし注意すべき点として、ハードペイウォール型のアプリでは広告収益には限界があることも念頭に置く必要があります。たとえば Spotify の場合、広告を受け入れている無料ユーザー（＝ユーザー数としては多数派）からの収益は、全体の5%未満にとどまっています。私が関わった別のケースでは、1%程度しかありませんでした。

サブスクリプション＋広告を実装する際の考慮点

アプリに広告を組み込む際には、プライバシー法規制、広告 SDK を組み込むことによる影響、チャーン（解約率）への影響など、考慮すべき点が数多くあります。以下は、参考になる良質なリソースです。

• 7 smart ways to monetize low-intent users（低インテントユーザーを賢くマネタイズする7つの方法）
• How to turn freemium users into loyal subscribers（フリーミアムユーザーをロイヤルな購読者へと転換する方法）
• Boosting ARPU with ads: How to monetize free users without degrading UX（UXを損なわずに広告でARPUを高める方法）
• Sylvain Gauchet’s pros and cons of ads in subscription apps（Sylvain Gauchetによるサブスクリプションアプリにおける広告のメリットとデメリット）

サブスクリプション＋広告の手法

一部のアプリでは、広告を単なる収益追加の手段ではなく、障壁を生み出して広告のない体験（＝サブスクリプション）へ誘導する手段として捉えています。たとえば Impulse では、戦略的に配置された複数の箇所で「広告を削除する」ことをユーザーに促しています。

このフロー（GrowthGems より）では、広告を閉じると、週次プランとライフタイムプランを含むサブスクリプションのペイウォールが表示されます。さらにそれを閉じると、$4.99 で広告を削除できる非更新型 IAP が提示されます。

ゲーム業界の専門家である Matej Lancaric と Felix Braberg は、Impulse のハイブリッドモデルを分析した非常に良い動画を公開しています。また、広告枠を使って自社サブスクリプションを宣伝することも可能です。たとえばこの動画では、Duolingo の広告ブレイク中に 2 本の広告が表示され、1 本は NYT Games、もう 1 本は Duolingo MAX の広告になっています。ややメタな構造ですが、機能している例です。

Watch on YouTube

最後に、シンプルなバナー広告でも大きな効果を発揮する場合があります。たとえば park4night の例では、（興味深いことに米国外でも）ストア外の導線へと誘導しています。

4. サブスクリプション＋パートナーシップ

ここで言う「パートナーシップ」とは、AppLovin、Unity、AdMob などの SDK 経由で提供される一般的な広告モデルの代替を指しています。特定の業界（バーティカル）では、関連性の高いブランドと提携することで、大きなインパクト――場合によっては大きな収益――を生む可能性があります。これは、そのパートナーがプレミアムユーザーを含むユーザー体験に付加価値をもたらせるケースがあるためです。 その例として挙げられるのが、Strava のスポンサー付きチャレンジです。

このようなパートナーシップは、ユーザージャーニー上のさまざまなトリガーポイントに組み込むことができます。下記の Prematch の例は、その実装パターンを示しています。

5. サブスクリプション＋Eコマース／アフィリエイト

前述のとおり、サブスクリプション単一モデルの限界のひとつは、熱量の高いパワーユーザーやアンバサダーが、ブランドとさらに深く関わるための選択肢が用意されていない点にあります。そこで、サブスクリプションを補完する手段として有効なのが、Eコマースやアフィリエイト戦略の追加です。

たとえば、一部の熱心なファン（メガファン）は、ブランドグッズや物理的な商品を購入してくれる可能性があります。その例が Lingokids です。

また、Eコマースの機会がプロダクト内に組み込まれているケースもあります。たとえば、釣り人向けのソーシャルネットワークアプリ Fishbrain では、マーケットプレイスが提供されています。

さらに間接的な手法としては、他社と提携し、ユーザーに特典や割引を提供する方法もあります。これは Revolut が採用しているアプローチです。

6. サブスクリプション＋消費型／単発のアプリ内課金（IAP）

最後に紹介するのが、（多くのアプリにとって）最も大きな収益向上ポテンシャルを持つ手法です。それが、サブスクリプションに加えて、消費型アイテムや単発の IAP を提供することです。これらはアプリビジネスにとって非常に大きなリターンをもたらし得るにもかかわらず、依然として十分に活用されていません。

RevenueCat の State of Subscription Apps 2025 レポートによると、消費型アイテムの利用は限定的で、ゲーム分野（約 40%）を除くと、これらのマネタイズモデルを採用しているアプリは全体の 5〜15% に留まっています。

この手法を採用しているアプリは少数派ですが、採用しているアプリははるかに高い収益を上げています。最近のデータでは、ハイブリッド購入者は購入者全体のわずか 7% に過ぎない一方で、総収益の 25% を生み出していることが示されています。

非更新型／消費型アイテムは、サブスクリプションではカバーできない多くのユースケースに適合します。 サブスクリプションの代替（そもそも購読されないケース）として機能する場合もあれば、追加支出としてサブスクリプションの上に重ねられることもあります。アプリの種類によって、その中身は大きく異なりますが、代表的な例が「ブースト」です。これは Tinder や Wallapop といった、デーティングアプリやマーケットプレイスでよく見られます。

アプリ内課金は、価格に敏感なユーザーがプレミアム機能を個別、または期間限定でアンロックする手段としても使えます。たとえば、私が関わったある学習アプリでは、数日間すべてのコンテンツにアクセスできる単発 IAP（いわゆる「週末パス」）を追加しました。また、コンテンツ階層全体を解放しなくても、特定のレッスンだけにアクセスできる IAPも導入しました。

消費型アイテムはアップセルとしても機能し、特にヘルスケアやフィットネス分野で高い効果を発揮しています。たとえば、特定の部位を鍛えるためのガイド、特定の個人コーチ、専用のワークアウトや食事プログラムなどです。これらは、オンボーディング時に直接アップセルとして販売されることもありますが、私の経験上、アプリ内よりも Web（支払い完了後）のほうがうまく機能するケースが多いです。

IAP の可能性は非常に幅広く、Nebula は単発のタロット占いや霊能者との 1 対 1 チャットを販売し、Duolingo は個別テストや認定資格を提供しています。ほかにも、チップ、スタンプ、カスタマイズ要素などを提供するアプリは数多く存在します。

消費型アイテムに関する注意点として、そしておそらくここで避けて通れない論点が AI です。

AI には大きなコストが伴うため、同じ料金を支払っているユーザー間でも、実際の利用コストが大きく異なる場合があります。私が見た中で最初期のハイブリッド AI モデルのひとつが Lensa AI で、200 枚の AI アバターを $9.99 で販売していましたが、サブスクリプションに加入するとクレジット価格が 50% 割引になる仕組みでした（なぜ有料なのかを明示している点が興味深いと感じました）。

ChatGPT のような段階的なサブスクリプションと並行して、追加利用のための単発課金は、AI アプリの間でますます一般的になりつつあります。

7. 積み重ねる：ハイブリッド・マネタイズ手法を組み合わせる

ハイブリッドな選択肢は相互排他的ではなく、加算的です。であれば、重ねて使わない理由はありません。最も成熟したサブスクリプションアプリは、アップセル手法をひとつだけ採用するのではなく、複数を組み合わせています。

この図は、Subversive podcastの制作者であり、有名な Subscription Value Loop を提唱した Phil Carter氏によるもので、Tinder がどのように需要曲線に適応したかを示しています。また、Tinder の元 Chief Product Officer である Ravi Mehta は、Sub Club podcast でこの戦略について詳しく語っています。ハイブリッド・マネタイズが実際にどのように機能するのかを知るうえで、非常におすすめです。

Listen on: YouTube · Spotify · Apple Podcasts

以下は、複数の非サブスクリプション型収益源を組み合わせる方法の例です。

すべてを提供する！

たとえば、減量アプリ Simple は、まずトライアル期間をスキップするためのアップセルを提示し、その後に複数のサブスクリプション階層を用意し、さらにアプリ内ガイドの単発購入も提供しています。正直、かなり盛りだくさんです。

Me アプリも似た構成を採用しており、コアとなるサブスクリプションに加えて、コーチング、特典、アップセルが用意されています。

リアル商品とデジタル商品のバンドル

もうひとつの革新的（ただし比較的まれな）例が、デジタル商品とリアル商品をバンドルする手法です。これは高級ブランドやデザイナー向けに適しているように感じられますが、実際にはどのアプリでも成立し得ます。Arya は、初期オファーや、その後のストアでのアップセルを通じてこの手法を採用しています。

これらの例は細部こそ異なりますが、根底にあるロジックは同じです。有料サブスクライバーに転換するだけでも十分に難しいのだから、サブスク利用者から追加でマネタイズできる機会があるなら、それを活かすべきです。低いフロア（収益下限）を壊し、たとえ少数であっても大きく支払うユーザーを見つけましょう。オンボーディング時であれ、後から（たとえばマーチャンダイズ）であれ、ARPU を大きく引き上げられる機会があるなら、追求する価値はあります。

さらに多くを提供する

近年、多くのサブスクリプションビジネスは、純粋な B2C モデルを超えて展開しています。エンドユーザー、プロシューマー、小規模事業者、さらには大企業までを含む混合モデルで運営されるケースが増えています。これは特に、グラフィック、写真、動画ツールの分野で顕著です。その一例が Photoroom です。Photoroom は複数のサブスクリプション階層に加えて、ヘビーユーザー要件を超える B2B 向けプランも提供しています。

ハイブリッドマネタイズを実装する前の注意点と検討事項

ハイブリッドマネタイズは「やれば必ず勝てる」ものではありません。計画と実践が必要ですし、アプリマネタイズ全般と同様にリスクも伴います。ただし、よくある障壁はある程度予測可能です。

ユーザー側：選択肢過多はコンバージョンを阻害する

新しいマネタイズ手段を追加するたびに、それは特に意思決定ポイントにおいて、その存在意義を明確に示す必要があります。そうでなければ、選択肢が多すぎて「何も選ばれない」状態を招くリスクがあります。どのように、そしていつ選択肢を提示するかが極め indications です。たとえば Netflix では、1 行あたりに 7 本以上のタイトルを表示するとユーザーエンゲージメントが低下することが分かっています。また、Duolingo、Zapier、Airbnb、Trello などを例に、ヒックの法則や選択肢過多の事例を詳しく解説している良質なブログも存在します。

開発者側：複雑さは急速に増大する

SKU が増えれば増えるほど、ロジックも増え、エッジケースも増えます。 これが最大の注意点かもしれません。ハイブリッドマネタイズは、誰にでも向いているわけではありません。実際、ハイブリッドモデルの失敗原因は、プロダクト設計よりも組織構造に起因することの方が多いです。マネタイズ、UA（ユーザー獲得）、プロダクトなど、複数のチームで KPI が影響を受けるため、新たなアラインメントが必要になります。

複数の選択肢を提供するには、より強固なプロダクト運用・データ運用・オペレーションの規律が求められます。また、オーディエンスに刺さる形を見つけるまでに何度も実験を重ねる場合、データ負債や技術的負債が急速に積み上がる可能性もあります。

そのため、初期フェーズや小規模チームにとっては、まず純粋なサブスクリプションモデルに集中するのは、非常に合理的な選択です。

隠れたシグナルとカニバリゼーションのリスク

ハイブリッドマネタイズによる実際の収益向上を測定するのは、一見簡単そうに見えますが、実際はそうではありません。割引は逆効果になることがあります。設計の甘い IAP はサブスクリプションを弱体化させます。強気な価格設定の消費型アイテムは、単に収益を前倒ししているだけの場合もあります（同程度の LTV であっても、キャッシュフロー的には良いこともありますが）。その結果、更新収益を損ない、最終的には LTV を下げてしまうこともあります。広告は短期的な ARPU を押し上げる一方で、長期的なリテンションや後段のコンバージョンを悪化させる可能性もあります。

ごく単純な価格変更であっても、更新率、リテンション、アップセル余地に長期的かつ複合的な影響を与えることがあります。

要するに、導入前に必要な分析設計を十分に意識することが重要です。ハイブリッドマネタイズは、非常にもっともらしい「偽のポジティブ指標」を生みやすい手法でもあります。

国や文化による依存性

プラットフォーム間には、サブスクリプションのマネタイズに大きな格差があります（これが Google Play チームが早期から混合モデルを推進してきた理由です）。たとえば、少額 IAP は iOS より Android の方が効果的なケースが多いことがあります。これはユーザープロファイルや利用意図の違いによるものです。

支払い習慣、広告への耐性、価格感度も地域によって大きく異なります。Spotify は長らくグローバルで有意なスケールができなかった一方で、楽曲単位課金・単発購入・チップを提供する Tencent Music は世界的に成功しています。長期サブスクリプションに消極的な文化（例：中国）や、自動更新に強い不信感を持つ文化（例：ドイツ）も存在し、こうした地域では混合モデルが非常に有効に機能します。

さらに、各国固有の規制も存在します。たとえば、日本や韓国での 2025 年の制度変更による更新率の急落、カリフォルニア州で提案されている「クリックで解約」法案などが挙げられます。

まとめ：あなたのアプリはハイブリッドマネタイズに対応できていますか？

ここまで多くのことを見てきました。ハイブリッドマネタイズにはさまざまなフレームワークがあり、導入前に検討すべきメリット・デメリットも数多く存在します。そこで最後に、新しい収益源を導入する前に自分たちに問いかけるべき質問を挙げます。

• 自分たちは、高・中・低インテントユーザーを明確に理解できているか？
• コホートベースで信頼できるリテンションおよび収益データを持っているか？
• 変更を重ねすぎることなく、クリーンな実験を実施できるか？
• トレードオフしてもよい指標と、絶対に守るべき指標を把握しているか？

もしこれらにまだ答えられないのであれば、まずそこを整えるべきです。ハイブリッドマネタイズは、意図的に導入してこそ機能します。そうでなければ、施策は散漫で混乱したものになり、場当たり的な対応に陥ります。短期的な数値の改善を誤って成功と解釈し、長期的なリテンションを損なってしまう──そんな落とし穴に、くれぐれもはまらないようにしてください。

覚えておいてください。裏技は存在しません。ハイブリッドマネタイズは、低いARPUを手っ取り早く解決するための近道ではありません。サブスクリプションが明確で再現性のある価値を提供できていない場合、マネタイズのレイヤーを追加しても状況は悪化するだけです。プロダクトが悪ければ、マネタイズもうまくいきません。そして、より高度なモデルを採用すればするほど、「うまくマネタイズできない形」が増えるだけなのです。

それにもかかわらず、チェックアウトの段階で、多くのユーザーが立ち止まり、迷い、あるいは離脱してしまいます。

Express Checkout は、ブラウザ上でペイウォールが表示された際に、ネイティブウォレットの購入ボタンをペイウォール上に直接追加します。これにより、顧客は別のチェックアウトページへ遷移することなく、ワンタップで購入を完了できます。

すでに決断したあとで、チェックアウトが顧客の動きを鈍らせる

ユーザーがペイウォールに到達した時点で、ほとんどの仕事はすでに終わっています。 価値を理解し、価格にも納得し、次に進む準備ができています。

ところが、その流れで「別の場所へ移動してください」と求められます。

チェックアウトページの読み込みを待ち、支払い方法を選び、端末がすでに知っている情報を再入力し、すでに下した決断をもう一度確認する──。これらのステップは、信頼を高めるわけでも、価値を明確にするわけでもありません。ただ遅延を生むだけです。

チェックアウトは購買意欲を掻き立てません。最も重要な瞬間に、勢いを削いでしまうのです。

購入をペイウォール上で完結させることで、1ステップを丸ごと削除できる

一般的なWebフローでは、ペイウォールで購入意欲を高めたあと、別のページへ遷移して購入を完了させます。

Express Checkoutでは、意思決定が行われたその場所で購入が完結します。

ユーザーはペイウォール上のネイティブウォレットボタンをタップするだけで、取引は完了します。リダイレクトも、フォーム入力も、「はい」から「支払い完了」までの間に挟まる追加の判断もありません。

この変更により、ファネルから1ページ分が完全に削除され、離脱の機会も複数取り除かれます。これは見た目の調整やコピーのテストではありません。ブラウザにおける購入体験そのものを構造的に改善するものです。

Express Checkout でできること

Express Checkout は、Web 上で表示されるペイウォールに、ネイティブのデジタルウォレット購入ボタンを直接追加します。

このコンポーネントは、ユーザーごとに最適な支払い手段を自動で表示します。たとえば、iOS では Apple Pay、対応する Android デバイスやブラウザでは Google Pay が表示されます。ユーザーがタップすると、デバイスのネイティブな支払いプロンプトが即座に立ち上がり、通常のチェックアウトフローを経由することなく購入が完了します。

モバイルでは、従来のブラウザベースの購入体験よりも、アプリ内課金に近い感覚になります。購入フローの中で最も失敗しやすいステップが、ここで消えます。

設定手順や対応ウォレットの要件については、ドキュメントをご覧ください。

Web、App-to-Web、Web-to-App のフローで利用可能

Express Checkout は、ペイウォールが「意思決定の瞬間」になるあらゆる場面でコンバージョンを向上させます。

純粋な Web 流入

ユーザーが広告、SNS 投稿、ニュースレター内のリンクをタップし、ブラウザ上のペイウォールに到達します。オファーを読み、「価値がある」と判断したら、そのままデバイスのネイティブウォレットを使って即座に購入を完了できます。チェックアウトページへの遷移はなく、新しいページの読み込み中に購買意欲が冷めてしまうような“間”もありません。

App-to-Web での購入完了

ユーザーはアプリ内でペイウォールに到達し、購入は Web 上で完了します。直前に下した判断と切り離されたチェックアウトページに遷移する代わりに、オファー内容がそのまま反映されたブラウザ上のペイウォールが表示され、ワンタップで購入できます。体験は「取引的」ではなく、途切れのない流れとして感じられます。

Web-to-App のジャーニー

ユーザーは Web 上でプロダクトを知り、ブラウザ上のペイウォールで購入し、その後アプリへ進みます。プラットフォームをまたぐ体験であっても、購入ステップは高速で馴染みのあるもののままです。ペイウォールは一時的な通過点ではなく、スムーズな入口として機能します。

いずれの場合でもメリットは同じです。ユーザーがブラウザ上のペイウォールに到達したその瞬間、Express Checkout は「今まさに買う準備ができている」タイミングで不要なステップを取り除きます。

標準のチェックアウトは自動的に引き続き利用可能

ユーザーのデバイスやブラウザでネイティブウォレットが利用可能かつサポートされている場合、Express Checkout がペイウォール上に表示され、そのまま直接購入が完了します。

ネイティブウォレットが利用できない場合は、従来どおりの標準的な購入ボタンが表示され、通常のチェックアウトフローへ進みます。この 2 つの選択肢は共存できるため、常に最速の購入経路へユーザーを誘導しつつ、確実に購入を完了できるフォールバックも維持されます。

税金処理、コンプライアンス要件、各種エッジケースはすべて裏側で処理されます。ワンタップ決済が使えない状況でも購入を妨げることなく、可能な限り障壁を低減することができます。

セットアップの詳細、対応ウォレット、フォールバック時の挙動については、Express Checkout のドキュメントを参照してください。

始めましょう

すでに Web で RevenueCat Paywalls を利用している場合は、Paywall Builder から Express Checkout を追加できます。

これから Web での販売を始める場合でも、ブラウザ上でワンタップ購入体験を提供する最速の方法です。既存のプロダクト、トライアル、オファーとそのまま連携でき、変更するのは価格モデルではなく、ファネルの「最後の一歩」だけです。各チームが実験を開始し次第、コンバージョン結果も共有していく予定です。また、この同じボタンは、今後予定されている、より高度な App-to-Web ペイウォールフローへの基盤にもなります。

そこで本記事では、あなた自身の Web-to-App の取り組みに役立つよう、私のお気に入りの事例をいくつか紹介しつつ、そこから何を学べるのかを解説します。なぜなら、「なぜそのファネルが機能しているのか」「自分たちのブランドにどう応用できるのか」を理解せずに真似ても意味がないからです。安心してください。これはクイズ型ファネルだけを並べた記事ではありません。Web-to-App にはさまざまなアプローチがあるため、本記事では複数タイプのファネルを取り上げます。

とはいえ、まずは私のお気に入りのクイズから始めましょう。その後で、別のアプローチもきちんと紹介します。

1：Calm の Web-to-App クイズファネル

Web ファネルの種類：Webクイズ → トライアルオファー → アプリインストール

まずは、Gen Z の言い方で「クイズファネルの GOAT（Greatest Of All Time：史上最高、とは妹いわく）」から始めましょう。瞑想アプリの Calm は、Web-to-App のクイズファネルとして長年ずっと際立った存在です。シンプルで、洗練されていて、そして驚くほど効果的です。

私は、このフローがなぜ何年もほとんど変わっていないのかを理解するために、クイズの全バリエーションを確認しました。以下がファネル全体の流れですが、細かさに圧倒されて慌てないでください。ここからステップごとに順を追って説明します。自分のペースでこのフロー（あるいは他の例）を確認したい場合は、こちらでフローチャート全体をまとめて見ることもできます。

最初に注目すべき点は、Calm が本当にパーソナライズしているのは睡眠フローだけで、他の 4 つの選択肢はすべて標準化された同一の導線に進むことです。これは意図ベースのセグメンテーション（ユーザーを目的で分ける）の優れた例です。睡眠は緊急度が高く、感情にも強く結びつく課題なので、より深いパーソナライズに投資するのは理にかなっています。一方で他の目的はより探索的な性質があるため、軽めのフローにするのは現実的な選択です。

これは私がアプリのテストチームによく勧める戦術でもあります。最初からすべてをパーソナライズしようとしないこと。まずは最優先のオーディエンスから始め、そこから計測し、学び、反復していきましょう。

睡眠クイズのフロー

まずは睡眠フローから見ていきましょう。最初に聞かれるのは、この悩みにどのくらいの頻度で直面しているか、という質問です。

ここで行われているのは、とてもシンプルですが効果的なことです。回答に対して即座にフィードバックが返ってくるのです。

これは別画面ではありません。「あなたは大丈夫、ここに来て正解です」といった短い安心感のあるメッセージです。そこからクイズはさらに踏み込み、「寝つけない」のか「途中で目が覚めてしまう」のかを切り分け、その後で睡眠の課題につながる可能性のある原因を探っていきます。

不眠に悩んできた身として、これはとても心地よく感じました。否定も、的外れな質問もありません。ただ私の課題に対して、敬意をもって関心を示してくれているだけです。また、どちらの質問も複数選択できる点も気に入っています。1つだけ無理に選ばされることがないのです。

次に、自分と状況が重なりそうな人物からのレビューが表示されます。画像や名前によってパーソナルな印象はありますが、出典がわからない点は、やや信頼性を下げているとも言えます。ただし、Calm はこの分野ですでに広く知られたブランドなので、シンプルで共感しやすいレビュー以上に強いソーシャルプルーフに頼る必要はありません。

Calm が文脈を確認してくれる点も評価しています。「今まさに寝ようとしているのか？」という質問です。多くのアプリは、ユーザーが開いた瞬間に利用している前提で進めてしまいますが、フィットネスやウェルネス系アプリでは、必ずしもそうとは限りません。

興味深いことに、どちらの選択肢を選んでも、直後のステップ自体は変わりません。ただし、この回答は後続の体験に影響しているはずです。たとえば、登録後に表示されるコンテンツや送られてくる内容が、一般的な瞑想になるのか、その瞬間に合わせた睡眠ストーリーになるのか、といった違いです。

その後、興味のあるコンテンツタイプの好みを設定する質問が続きます。ここで唯一気になるのは、この時点では自分が何を求めているのか、まだ分かっていない場合も多いという点です。おすすめを探しているだけだったり、広く試してみたいだけのこともあります。Calm は、なぜそれらをおすすめするのかを、もう少し明確に示してもよかったかもしれません。

最後の画面（これはすべてのフローで共通です）に進む前に、他の選択肢を選んだ場合に何が起こるかも見てみましょう。

• ストレスや不安を減らしたい
• 集中力を高めたい
• 自己成長・セルフインプルーブメント
• その他

Calm の別パターンのクイズフロー

4つすべての選択肢をテストしてみましたが、結果的には毎回同じフローにたどり着きました。最初は、自分が今どんな気分なのかを確認する補足的な質問から始まり、睡眠フローと同じ種類の安心感を与えるフィードバックが添えられています。

ここではまず、原因の探索から始まるのが興味深い点です。その後、いったん戻る形で、問題への理解をより深めていきます。

再び似たようなレビュー画面が表示されますが、こちらはかなり汎用的で、回答内容によって変わることはありません。これまでの流れを踏まえると、もう少しパーソナライズされていることを期待していました。

Calm が経験レベルについて質問し、それに応じた安心感を与えてくれる点は気に入っています。私のように、何度も瞑想に挑戦してきた人間にとって、基礎を何度も繰り返されるのは正直フラストレーションになります。このステップは、瞑想経験の有無にかかわらず「このアプリは自分に合っている」と感じさせるシグナルにもなっています。

最後のパートでは、ユーザーにコントロール感を与えています。

瞑想は「やるべきタスク」のひとつに感じられてしまうこともあるため、Calm は、意欲が高まっている状態のユーザーに対して、やりすぎず、かといって少なすぎない、ちょうどよいバランスを取ろうとしています。そのうえで、現在の感情状態や、いつ瞑想をする予定なのかを把握し、プッシュ通知やメールを最適化しようとします。

感情状態や問題解決に引き続き焦点を当てている点は評価できますが、質問の順番がときどきランダムに感じられる場面もありました。

クイズ後のステップ（全フロー共通）

最終ステップは、すべてのフローで共通しています。全ユーザーに同一内容の追加レビューが表示されますが、その内容は睡眠によりフォーカスしており、その後にアカウント登録を促す流れになっています。

このパターンは、特にクイズ形式のWebファネルでは珍しくありません。この時点でユーザーはすでに多くの入力を行っており、Calm は設定内容を保存するという形で、さりげなく損失回避（loss aversion）を活用しています。

興味深いのは、Calm がクイズ終了時点でコンテンツに関するフィードバックを一切提示していない点です。クイズ自体は明らかに体験のパーソナライズを目的としていますが、その結果が可視化されるのはアカウント登録後になります。おすすめコンテンツ自体は無料で利用できるものの、この段階ではユーザーはそのことをまだ知りません。

これは、このクイズが即時的なコンバージョンの満足感よりも、その後のパーソナライズを重視して設計されていることを示唆しています。ユーザーにすぐ報酬を与えるのではなく、アプリ内でのレコメンド、通知、ライフサイクルメッセージングといった後続体験の最適化に軸足を置いているように見えます。メンタルヘルスという領域の特性を考えると理にかなったアプローチではありますが、「こんな体験が得られますよ」という訴求の余地を残しているとも言えます。

この時点でユーザーは、時間・感情・データをすでに投資しており、トライアルは強引なセールスではなく、自然な次のステップとして感じられる状態になっています。

支払いページは意図的にシンプルに設計されています。選択肢は年額プランに紐づいた7日間の無料トライアルのみで、ユーザーを迷わせることはありません。すぐに登録しなかった場合でも、Calm は後日、追加の割引オファーでコンバージョンを後押しすることがよくあります。

Calm の Web-to-App ファネルから、他のアプリが学べること

以下は、Calm から学べるポイントです。

1. インテントが最も高い部分にパーソナライズを集中させる Calm はすべてをパーソナライズしようとはしていません。睡眠には専用フローを用意し、それ以外の目標は共通フローにしています。これは、効果的なパーソナライズは「網羅性」ではなく「集中」によって成立する、という良い示唆です。

2. 感情的な安心感がコミットメントを生む このクイズが機能している理由は、アカウント登録やトライアル申し込みといった要求をする前に、まずユーザーを肯定している点にあります。価格が提示される頃には、ユーザーはすでに「理解されている」と感じています。

3. クイズの本当の価値は後から現れる Calm は多くの情報を収集しますが、その場ですぐにフィードバックを返しません。これは、このクイズが即時のコンバージョン獲得よりも、後続のパーソナライズやリテンションを目的として設計されていることを示しています。

4. ペイウォールでは、やはりシンプルさが勝つ 比較的長めのクイズの後（とはいえ、他アプリと比べて特別長いわけではありません）、Calm は意図的に選択肢を削ぎ落とします。1つのプラン、1つのトライアル。余計な判断をさせません。

5. ブランドへの信頼が、過度なソーシャルプルーフを補完する 汎用的なレビューや出典の少なさは、小規模アプリにとっては不利に働く可能性があります。Calm はファネル内で自社ブランドへの信頼を活用できますが、他のアプリではより多くのソーシャルプルーフが必要になるでしょう。

6. 強いファネルでも、完璧ではない 質問の順序がランダムに感じられる場面や、活かしきれていないパーソナライズも見られます。しかし、これはむしろ安心材料です。最初の Web-to-App ファネルであっても、あるいは100回目であっても、完璧である必要はありません。十分に機能するものは作れます。

2. Blinkist のコンテンツ主導型ファネル

Webファネルタイプ：ランディングページ → アプリインストール

学習・自己成長アプリである Blinkist の価値は「コンテンツ」に根ざしているため、獲得ファネルの最前線にコンテンツが置かれているのは非常に理にかなっています。アプリの機能や約束を前面に出すのではなく、Blinkist は「アイデア」から始めます。まず何かを学び、その体験をさらに深める手段としてプロダクトを知る、という流れです。

Blinkist は時間をかけて、アイデアを要約した短く洞察に富んだ記事を中心に、強力なコンテンツ成長エンジンを構築してきました。これらの記事は、オーガニックチャネルと有料チャネルの両方で配信され、ユーザーにダウンロードや購読を求める前に信頼を築く役割を果たしています。同じコンテンツ形式が広告、パートナーシップ、自社メディアでも再利用されており、このアプローチは非常にスケーラブルです。

Marcus Burke氏は、ある時点では Blinkist の獲得の約 70% が Web-to-App フロー経由だったと述べています。これは、このコンテンツ主導型アプローチが同社の成長においていかに中心的な役割を果たしてきたかを明確に示しています。

Blinkist の典型的な Web-to-App ジャーニーはどのようなものか？

典型的な Blinkist のジャーニーは、アプリではなく「コンテンツ」を訴求する広告から始まります。その広告は、ある概念・原則・アイデアを深く掘り下げた記事へとユーザーを導きます。そしてそのコンテンツの中で、Blinkist は「より深く学ぶ」「より効率的に理解する」ためのツールとして位置づけられます。

これは同じパターンの数あるバリエーションのひとつにすぎませんが、全体の構造自体は一貫しています。

以下は、Blinkist が現在有料トラフィックを流している記事の一部です。

Blinkist は、コンテンツ全体を通してソーシャルプルーフを強く活用しています。場合によっては Apple での特集や App Store での評価として現れ、別の場合には、そのアイデアを語る著者・思想家・著名人の権威性として表れます。このアプローチにより、過度に売り込み感を出すことなく、コンテンツからプロダクトへと信頼が自然に移転します。

CTA（行動喚起）は通常、「Start your free trial（無料トライアルを開始）」または「Create an account（アカウントを作成）」のいずれかです。トライアル CTA は、Calm と似た web オンボーディングクイズに進むことが多く、一方でアカウント作成 CTA はユーザーを web 上に留め、引き続きコンテンツを探索できるようにします。

マネタイズはどこで行われているのか？

ユーザーがアカウントを作成すると、さまざまな書籍要約を閲覧できるようになります。いずれかの要約をクリックすると、web サブスクリプションを促すペイウォールが表示されます。モバイルでは、Blinkist はあわせてアプリのダウンロードも促し、web 上での発見体験と、アプリでの消費体験を組み合わせた真のハイブリッド構造を作っています。

このアプローチが強力なのは、Blinkist が 「アハ体験」を前倒しで提供している点です。ユーザーは、アカウントを作成したりトライアルを開始したりする前に、「何か有益なことを学んだ」という体験を先に得ます。直接的にコンバージョンを狙うランディングページと比べると、サインアップ率自体は低くなる可能性があります。しかしこの戦略によって、Blinkist ははるかに広いオーディエンスにリーチし、早い段階で信頼を構築できます。そしてその信頼は、ユーザーが実際にサインアップを決めたとき、より強い意図と質の高いコンバージョンへとつながっていく可能性が高いのです。

注意すべきトレードオフとリスク

この戦略にはトレードオフも存在します。Blinkist のウェブサイトへのオーガニックトラフィックは、過去 2 年間で大きく減少しているように見えます。これは、検索行動の変化や、AI 主導のコンテンツ発見の影響を受けている可能性が高いです。

ソース：SemRush — Blinkist.comの全世界自然検索トラフィック

一方で、Semrush が計測している有料トラフィックは比較的安定しているものの、規模としては依然として小さいままです。

このアプローチは、特に大規模なオーディエンスに対してオンライン上で信頼を構築する強力な手段になり得ますが、コンテンツがきちんと見られ続け、かつ関連性を保ち続けられるようにするための戦略的な設計が重要になります。

他のアプリは Blinkist の Web-to-App ファネルから何を学べるか？

1. アハ体験を前倒しで提供する Blinkist は、サインアップを求める前に価値を体験させることで、その後の意図（インテント）を強められることを示しています。ユーザーがコンバージョンするのは、機能を売り込まれたからではなく、すでに「何かを学べた」と感じているからです。

2. コンテンツ自体がプロダクトのプレビューになり得る コンテンツ主導型のアプリでは、Web ファネルでアプリを説明する必要はありません。価値を直接示し、アプリを自然な次のステップとして位置づけることができます。

3. Web は即時コンバージョンしなくても十分に機能する Blinkist の多くのフローでは、Web は教育・選別・信頼構築のために使われています。コンバージョンは、アカウント作成、クイズフロー、あるいはアプリ内ペイウォールなど、後の段階で発生します。

4. ソーシャルプルーフはレビュー以外からも生まれる Blinkist は、一般的なユーザーレビューよりも、思想家やコンセプトそのものの権威性に重きを置いています。これは特に教育系アプリにおいて効果的です。

5. 配信（ディストリビューション）はコンテンツの質と同じくらい重要 コンテンツ主導型ファネルは、コンテンツが継続的に新しいオーディエンスに届いてこそ機能します。検索行動やプラットフォームの変化はパフォーマンスに即座に影響を与えるため、現在人々がどのように検索しているのかを意識し、AI 主導の検索においても適切に評価・表示されるよう設計することが不可欠です。

3. PlantIn のランディングページ型ファネル

Webファネルのタイプ：ランディングページ → Webでの購入 または アプリインストール

AI 植物ケアアプリの PlantIn は、比較的クラシックな Web-to-App 構成を採用していますが、過度に凝りすぎることなく、非常に意図的に設計されている点が際立っています。コンテンツ、アプリの訴求、Web ベースのサブスクリプションフローをうまく組み合わせることで、実際に「購入」を求められる前に、ユーザーが納得し、関与するための機会を数多く提供しています。

このジャーニーは、通常コンテンツから始まります。広告は、アプリとその目的を紹介する動的な中間ページへと誘導されます。そこから先の体験はデバイスによって変わります。モバイルでは、たとえ離脱しようとしてもアプリのダウンロードを促される一方、デスクトップでは Web サイトへと案内されます。これは小さな違いですが非常に賢い設計であり、PlantIn が「意味のない場面でアプリファースト体験を強制しない」ことを示しています。

PlantIn のランディングページ

Web-to-App のランディングページの中には、「この先がアプリにつながっている」ことが分かりにくいものもあります。特に Web 決済のみを提供している場合、誤ってユーザーを App Store に送ってしまうリスクがあるため、設計が難しくなりがちです。 その点、PlantIn ではその問題は発生しません。アプリを簡単にダウンロードできる QR コードを前面に配置し、App Store へのリンクを明示し、さらにアプリ内のスクリーンショットも表示しています。このスクリーンショットによって、ユーザーがアプリから得られる価値が明確に伝わります。

次の「What is PlantIn?（PlantIn とは？）」というセクションは、一見するとアプリの機能説明のように見えますが、実際には統計データを用いた信頼構築の役割を果たしています。PlantIn の信頼性と安心感を高めることを目的とした、6つの主要な数値が強調されています。

アプリの主要なベネフィットに進む前に、それぞれの数値がどのような意味を持つのかが分かるよう、丁寧に説明されています。その後、このセクションは簡単なソーシャルプルーフと、関連する記事へのリンクで締めくくられます。たとえば「コーヒーかすを植物に使う方法」の記事などがあり、これは個人的にもおすすめです。

PlantIn の優れている点は、ユーザーを急いでコンバージョンさせようとしないことです。代わりに、サインアップやより深いコンテンツへの誘導に重点を置いています。植物の種類、植物の病気、さらには識別可能なキノコまで紹介するなど、非常に充実した詳細ページが用意されています。これらはアプリの中核的な価値――「植物を自信を持って識別できること」――を損なうものでも、コンバージョンを妨げるものでもありません。むしろ、価値を示し、信頼を築く役割を果たしています。

まずはサインアップ、その後にサブスク登録

購入前にサインアップする、という昔ながらの定番フローです。これはアプリにとって非常に重要で、もしアカウントを作成せずに購入されてしまうと、購入後にアプリへ誘導・セットアップする流れが不自然で分かりづらくなってしまいます。また、サインアップを挟むことでメール登録も促せるため、その後のガイドやフォローもしやすくなります。

PlantIn の価格提示ステップで特に気に入っているのは、Web からサブスク登録することで、どれだけお得になるのかが明確に示されている点です。アプリ側は Web 経由でより低い手数料を実現でき、ユーザーにとっても長期的な継続率が高まりやすくなります。

Web では不正利用のリスクがあるため、無料トライアルはあまり一般的ではありません。その中で PlantIn がトライアルを提供しているのは注目に値します。期間は短めに設定されており、悪用を防ぐ意図と、ユーザーが比較的すぐにアプリの価値を実感できる点の両方を考慮しているのでしょう。

チェックアウトはポップアップ形式で表示され、何に対して支払うのか、そして何がアンロックされるのかが明確に分かります。この段階になると、強引な売り込みというよりも、ここまで体験してきた流れの中で「次に進むのが自然」だと感じられます。

全体を通して印象的なのは、PlantIn が何度も価値提案を繰り返しているにもかかわらず、決して押しつけがましく感じさせない点です。各ステップが、同じメッセージを強く押すのではなく、少しずつ文脈を積み重ねていきます。

ただし、表現にはやや誤解を招く点もあると感じました。タイトルでは「Web でサブスク登録」と書かれている一方で、すべてのプランでは「access（アクセス）」という言葉が使われています。定期課金であることが明確になるのは、最初の請求金額にドル記号すら付いていない小さな注意書きだけです。これでは、サブスクリプションだと気づかずに登録してしまい、不満を抱くユーザーが出るリスクがあります。価格表記には「サブスクリプション」や「◯期間ごと」といった表現を明確に使い、どれがサブスクでどれがそうでないのかを分かりやすく示すべきだと思います。

PlantIn の Web-to-App ファネルから、他のアプリが学べることは？

1. ユーザーが今いる場所に合わせる モバイルユーザーとデスクトップユーザーを異なる導線に振り分けることで、 プリダウンロードが適切でない場面でもそれを無理に強制せず、すべてのユーザーを同じように扱うことを避けています。

2. 主要機能だけでなく、アプリ全体の広がりを見せる PlantInは、サブスクリプションを単一のツールへの支払いではなく、ひとつのエコシステムへのアクセスとして感じさせる点が非常に優れています。同時に、「何でもできるオールインワン」を過度に打ち出してしまう落とし穴も回避しています。

3. 不安を和らげるためにコンテンツを活用する 特に「自分は植物の世話が苦手だ」と感じているユーザーに対して、PlantInは販売を始める前に、安心感を与えるコンテンツを提供しています。

4. ジャーニー全体を通してアプリの存在を可視化する Web上でマネタイズしている場合であっても、アプリは常に体験の中心に置かれている点が重要です。

5. Web特有の提供価値を伝えることを恐れない Web版の方が安価なサブスクリプションについても、単なる手数料回避ではなく、ユーザーにとっての付加価値として提示しています。

4. YNABのワークショップ型ファネル

Webファネルのタイプ：ワークショップ → Web購入またはWebオンボーディング → メール → アプリインストール

YNAB… You Need a Budget（予算が必要ですよね、みんな）。その名のとおり家計管理アプリであるこのサブスクリプションアプリは、非常に充実したWeb体験を提供しています。予算の設定や管理には多くのデータ入力が必要になるため、YNABではそのプロセス全体をWeb上で完結できるようにしており、アプリが登場するのはカスタマージャーニーのかなり後半です。

実際、その登場があまりにも遅いため、「もしかしてアプリは存在しないのでは？」と疑い始めたほどでした——でも、ちゃんとあります。ワークショップやウェビナーはB2Bアプリだけに有効なものではありません。信頼構築が重要な場合や、競争の激しい市場で差別化したい場合には、コンシューマー向けアプリでも非常に効果的です。私自身、以前に瞑想・マインドフルネス系アプリの仕事をしていた際、週次ワークショップを提供していました。そこでは、ストレスや感謝といったテーマを中心に、3日間や7日間のライブチャレンジを複数開催していました。

これらの無料ワークショップは、ユーザーがコーチとつながるきっかけとなり、その後アプリ購入へと自然に誘導されていました。 このアプローチは短期的な成果を生むだけでなく、「もっとこのコーチのコンテンツを使いたい」とユーザーが感じることで、長期的な成長につながるケースも多かったのです。

学習を支援するワークショップ

YNABは独自のメソドロジーを中核に構築されており、ユーザーをサポートし、学習を助ける点において非常に優れています。

ワークショップへの申し込みはZoom経由で簡単に行え、登録後には確認メールが届きます。この段階ではアプリについての言及は一切なく、そのためアプローチは驚くほど売り込み感がありません。既存ユーザー・新規ユーザーの双方に対して、純粋に価値を提供することにフォーカスしています。

では、Webフローを開始すると何が起こるのでしょうか。その答えは——かなり長めのWebオンボーディングです。このフローはWebサイトからも、ウェビナー参加後からもアクセスできます。なお、YNABはユーザーの課題（ペインポイント）に合わせてパーソナライズされた34日間の無料トライアルページへの広告も配信しており、そこからも同じWebオンボーディングへと進む構成になっています。

Webオンボーディングのプロセス

アプリやセールスへの言及が一切ないまま、これほど多くのステップを進むことになる点は非常に興味深いと感じました。ここで重視されているのは、ユーザーに投資感覚を持ってもらうことです。十分な「サンクコスト（すでに費やした時間や労力）」が積み上がることで、自然とフローに引き込まれるよう設計されています。また、これだけステップが多いにもかかわらず、セットアップが想像以上に簡単で楽しかったのも意外でした。

お金の話は、どこか気まずさを感じるものですし、質問内容も個人的になりがちです。それでも私は、自分の金銭的な考え方について驚くほど率直に共有できていました――Web-to-Appの事例記事で、こんな体験をするとは思っていませんでしたが。

一点、少し変わっていると感じたのはUIの構成です。オンボーディング中、コンテンツは画面下部に表示され、残りの部分は基本的に空白のまま進みます（最初の画面では表示されていますが、その後は表示されません）。フロー自体が長いため、ときどき未完成のように感じる瞬間もありました。

本質的に、優れたWebクイズはオンボーディングとの境界が曖昧になりがちですが、YNABの場合は違います。境界は一切なく、これは純粋なオンボーディングです。特に注目すべきポイントはいくつかあります。

• カスタマイズされたレビュー：自分が設定した目標によって、表示されるレビューがまったく異なっていました。
• 必要とされる「思考力」の段階的な引き上げ：質問は簡単なものから始まり、徐々に深く、考えさせる内容へと進んでいきます。
• 関連するフォローアップ質問のパーソナライズ：たとえば、持ち家があると答えると、後続で住宅保険に関する質問が出てきます。
• その場で答えやすい初期質問 → 計算や内省を伴う後半質問：最初は即答できる質問が中心ですが、後半になると「毎月いくら貯蓄したいか／必要か」「世帯収入はいくらか」といった、個人的で計算を要する質問が登場します。
• 質問の分割と緩急：質問数自体は多いものの、レビューや説明、フィードバックを挟むことで、フロー全体の負担感が和らげられています。

クイズの最後に至っても、アプリやYNABの料金についての言及は一切ありません。YNABは「お金を節約するためのツール」であるため、価値を体験する前にお金を払うことに違和感を覚える可能性があります。そのため、おそらく34日間という長めの無料トライアルが用意されているのでしょう。この期間は1か月のサイクルをカバーしており、実際にデータを入力し、金銭的な目標に向けて動き始め、YNABへの理解を深めることができます。

さらに、アカウント設定や銀行口座連携のための第2段階の質問票があり、その後に、より説明的で受動的なオンボーディングフェーズが続きます。ここで特に印象的だった点は2つあります。

1つ目は、第2段階のセットアップ完了後に用意されているお祝いの瞬間です。長期的な目標を扱うプロダクトにおいて、こうした進捗の祝福は非常に効果的です。カラフルな紙吹雪を嫌いな人はいませんよね。予算管理が、こんなに楽しく感じられるとは思いませんでした。

2つ目は、このフロー全体が安心感を与えてくれる点です。銀行口座の接続という、非常に信頼が求められる大きなお願いが出てくるのは、かなり進んだ後です。その前に、時間を投資し、前進を実感し、理解されていると感じられるため、ここで丁寧なセキュリティ説明を受けることで、行動前の不安がしっかり和らぎます。

それでも……まだアプリの話は出てきません。メニューにすら登場しないのです。

私が初めてアプリを目にしたのは、登録当日に届いたフォローアップメールでした。

これは、「優れたフローは、必ずしも最初にアプリを前面に出す必要はない」ということを示しています。もしアプリが主にリテンションのためのツールであったり、十分なセットアップや文脈理解を必要とする場合、まずWeb上で包括的かつ教育的な体験を提供する方が、結果的に効果的なこともあるのです。

YNABのWeb-to-Appファネルから、他のアプリが学べることは？

1. Web-to-Appは、必ずしも最初にアプリを前面に出す必要はない YNABは、意図的と言っていいほどアプリの存在を後回しにしています。ほとんど不安になるほどですが、それは狙いどおりです。YNABにおいて中核となる価値提案はアプリそのものではなく、そのメソドロジーにあります。Web体験が、教育・信頼構築・心理的なコミットメント形成といった重い役割を担い、アプリが登場する前にユーザーを十分に引き込んでいます。

2. 教育そのものがプロダクトである場合、ワークショップは強力に機能する これらのワークショップは、成長のために後付けされたギミックや単なるリードマグネットではありません。YNABの思想を自然に拡張したものです。もしプロダクトが、考え方の転換や新しい行動様式の習得を必要とするのであれば、ワークショップはランディングページでは決して達成できない価値を生み出します。

3. 「納得感」があれば、長いオンボーディングでも成立する このフローは確かに長いですが、長く感じません。質問は簡単なものから始まり、徐々に個人的な内容へと進みます。その間に、安心させるメッセージ、レビュー、説明が定期的に挟まれます。このケースでは、ステップ数そのものよりもペース配分のほうがはるかに重要です。

4. 信頼が築かれるまで「大きなお願い」は遅らせる 銀行口座の連携は、非常に大きな信頼を伴う瞬間です。YNABは、ユーザーが時間を投資し、前進を実感し、理解されていると感じるまで、このお願いを待ちます。その段階では、それは「リスク」ではなく「妥当な行動」に感じられます。

5. 成果ではなく、進捗を祝う 予算管理は長期戦です。YNABが祝うのは金銭的な成果ではなく、セットアップという進捗そのものです。パート2完了後の紙吹雪の演出は、節約額の話ではなく、目標に向かって前に進んでいるという勢いを祝うものです。

6. 無料トライアルは「やるべき仕事」に合わせて設計すべき 34日間の無料トライアルは、適当に決められたものではありません。1か月分の予算サイクルを一通り体験し、価値を実感してから支払い判断ができるだけの時間を提供しています。このトライアル期間は、単なるコンバージョン促進ではなく、行動変容を支えるための設計になっています。

5: Photoroomの無料ツール型ファネル

Webファネルのタイプ：無料ツール → Webオンボーディング → トライアルオファー → アプリインストール

写真編集アプリの Photoroom は、B2B志向のアプリが、押し付けがましさを感じさせずにWeb-to-Appを活用している好例のひとつです。アカウント作成やトライアルの背後にすべてを閉じ込めるのではなく、まず最初に「実際の作業」をさせてくれます。背景削除を、摩擦ゼロで、Web上ですぐに無料で試せるのです。それだけで、すでに明確な価値が提供されています。

興味深いのは、このWeb体験が「簡易的なティーザー」には感じられない点です。むしろ、それ自体がひとつの実用的なプロダクトとして成立しています。それでいて、各ステップごとに、より深いコミットメントへとさりげなく導かれていきます。

画像をアップロードして結果を確認した瞬間、ユーザーはすでに「なるほど！」というアハ体験をしています。そして、まさにそのタイミングで、Photoroomは次のステップを少しずつ重ねていくのです。

価値を先に提供し、その後にコミットメントを求める

Photoroomは、オンライン上でそのままアクセスして利用できる複数のツールを提供しています。

Photoroomが下している最も賢い判断のひとつは、アカウント作成を早い段階で強制しないことです。サインアップせずに最初のアクションを完了できるため、特に「一度きりの課題」を解決したいユーザーにとって、初期の摩擦が大きく軽減されます。

しかし、それだけでは終わりません。Photoroomは、その最初の成功体験を、次のステップを求める正当な理由として活用します。編集を続けたい、高画質で書き出したい、追加機能を試したい──そうなった段階で、アカウント作成が促されます。この時点では、それがごく自然に感じられます。支払いを求められるわけでも、何かをダウンロードさせられるわけでもありません。「試すために登録する」のではなく、すでに始めた作業を続けるために登録するという感覚です。

これは、Web-to-Appにおいて必ずしも強いゲート（ハードゲート）が必要ではないことを思い出させてくれる好例です。場合によっては、まずコアとなる価値を実際に体験してもらうことこそが、ユーザーの意欲（インテント）を最も早く高める近道になるのです。

個人事業主とビジネス利用：まったく異なる2つのジャーニー

アカウントを作成すると、Photoroomはすぐにどのような用途でプロダクトを使う予定かを尋ねてきます。ここで、このファネルは明確にB2B志向になります。

個人利用だと回答した場合、フローは比較的ライトなまま進みます。それでも、インポートするブランドを持っているかどうかは確認されます。

一方で、Photoroomをビジネス用途で使うと回答すると、体験は大きく変わります。オンボーディングはより深くなり、会社について、ニーズについて、想定している利用量についてといった質問が続きます。これは不要な質問をされている感じではなく、むしろ適切に見極められている（クオリファイされている）感覚に近いものです。

Photoroomは、あなたがどのような顧客なのか、どの価格帯やセットアップが適切なのかを明確に理解しようとしています。グロースの観点では、これは同時に次の2つを実現しています。

• 体験を最適化することで、関連性（リレバンス）を高める
• より高度で高価格帯のプランに対する期待値を、早い段階で設定する

これは、webオンボーディングを単なるコンバージョン手段としてではなく、アプリ体験が始まる前にユーザーを適切にセグメントするための手段として活用している、非常に良い例です。

ファネルの一部としてのチームセットアップ

Photoroomのフローの中で、私が特に気に入っている点のひとつが、チームセットアップを非常に早い段階で導入していることです。ビジネスユーザーにとって、チームメンバーの招待は「あとで見つける高度な機能」ではなく、自然な次のステップとして位置づけられています。

インターフェース上では、チームを招待して共有ワークスペースを設定することがとても簡単にできます。これによって、次の2つの重要な効果が生まれます。

• 早い段階でスイッチングコストを高める
• 課金が発生する前に、1人のユーザーを複数人のユーザーへと広げる

価格が提示される頃には、もはや「個人としてツールを評価している」状態ではありません。チームとしてワークフローを導入するという視点に切り替わっています。この意識の変化だけでも、価格の受け取られ方は大きく変わります。

繰り返しているのに、くどく感じさせない工夫

Photoroomは、価格提示までのフロー全体を通してさりげないが非常に効果的なことをしています。それは、どの無料ツールから使い始めた場合でも、同じ中核となる機能や価値提案が繰り返し表示されるという点です。

一見すると、プロダクト全体の幅広さをあえて控えめに見せているようにも感じられます。しかし、これは意図的だと思います。Photoroomができることをすべて並べてユーザーを圧倒するのではなく、少数のコア機能にフォーカスし、それを一貫して強調しているのです。

このような繰り返しは、理解を深め、認識を明確にします。「網羅性」よりも「フォーカス」のほうが、コンバージョンにつながりやすいということを思い出させてくれる好例です。

価格の分かりやすさとトライアル提示のタイミング

Photoroomが無料トライアルを提示するタイミングは、唐突ではありません。この時点までに、ユーザーはすでに次の体験をしています。

• プロダクトを実際に使っている
• アカウントを作成している
• 自分のワークフローの中でどう役立つかを理解している
• 場合によっては、チームメンバーを招待している

そのため、トライアルは強引な売り込みではなく、自然な延長線上の次のステップとして受け取られます。いくつかの質問に答え、アカウント設定も済んでいるため、オンライン決済の失敗リスクを下げる設計にもなっています。

また、Photoroomの価格表示が非常に明確である点も評価できます。何が提供され、いくら請求され、いつ課金されるのかがはっきり分かり、「うっかり忘れてしまうようなトライアルに騙された」という感覚がありません。このような透明性は信頼を生み、特にビジネスユーザーにとっては非常に重要です。

他のアプリは、PhotoroomのWeb-to-Appファネルから何を学べるか？

1. 実際に役立つ体験を、まず無料で提供する Photoroomは、最初に意味のある価値を無償で提供しても、コンバージョンを損なわないことを示しています。むしろそれが、コンバージョンを生み出しています。

2. Webオンボーディングは「売る」だけでなく「見極める」ために使う ビジネス利用かどうかを尋ねることで、より深いセグメンテーションが可能になり、後続の価格設計や体験の最適化につながります。 3. 早い段階からチーム利用を前提に設計する マネタイズ前にチーム設定を導入することで、ユーザーのコミットメントが高まり、アカウントあたりの価値も拡大します。 4. さりげない反復が、理解を深める 複数の入口で少数のコア機能に絞って繰り返し伝えることで、ユーザーは「このプロダクトが何のためのものか」を理解し、記憶しやすくなります。 5. トライアルは「納得感」があると最も効果的に機能する 無料トライアルが提示される頃には、それはリスクのある選択ではなく、自然で当然の次のステップとして感じられます。

「最適解」のWeb-to-Appファネルは存在しない

5つの事例を通して見えてくる最大の学びは、Web-to-Appに万能なテンプレートは存在しないということです。Calm、Blinkist、PlantIn、YNAB、Photoroomは、それぞれプロダクト、ユーザー、そして「達成したいジョブ（Jobs to be done）」が異なるため、まったく異なるアプローチを取っています。

• 感情に訴える
• 学習・教育を軸にする
• 実用性を前面に出す

共通しているのは、明確な意図とユーザー価値へのフォーカスです。これらのファネルはいずれも、Webを「できるだけ早くアプリに送客するためだけの薄い獲得レイヤー」として扱っていません。その代わりに、Webは以下の役割を担っています。

• 信頼を構築する
• コミットメントを生み出す
• 不安や不確実性を減らす
• そして場合によっては、プロダクトの中核となる価値そのものを提供する

もし一つだけ覚えておくべきことがあるとすれば、それはこれです。アプリが開かれる前に、最も難しい仕事をWebファネルが担うべきだということ。

それは、Calmのようにユーザーが自分自身をより深く理解する手助けかもしれません。あるいは、BlinkistやYNABのように、役立つ知識を教えることかもしれません。または、PhotoroomやPlantInのように、最初から実際の価値を体験させることかもしれません。

もちろん、最適なアプローチはサブスクリプションアプリごとに異なります。しかし機会は共通しています。Web-to-Appは単なる「橋渡し」ではなく、高品質なユーザーを生み出すプロダクト体験の一部として機能したとき、最も効果を発揮するのです。

この記事では、Jetpack Composeで高度なアニメーション付きペイウォールを構築する方法を学びます。「Day & Night」ペイウォールの実装を深掘りし、各アニメーション手法をステップごとに解説します。さらに、Firebaseを使ってカスタムペイウォールのコンテンツを俊敏にA/Bテストする方法も学び、RevenueCatのPaywall Builderを選ぶほうが適しているケースも把握できます。読み終える頃には、コンバージョンにつながるカスタムペイウォールを「いつ」「どのように」作るべきかを、総合的に理解できるはずです。

カスタムペイウォールを作る：Day & Night の深掘り

ここでは、16秒サイクルで昼と夜のテーマが切り替わる、プロダクション品質のアニメーション付きペイウォールを見ていきます。この実装では、複数の高度なComposeアニメーション手法が調和して連携しています。ペイウォールは、太陽が昇って沈み、星がきらめきながら現れ、雲が空を流れ、UI要素が時間帯に合わせて色を変える——といった、動的に変化する没入感のある環境を作り出します。この連続的なサイクルは注意を引きつけ、静的なペイウォールでは実現できない感情的なエンゲージメントを生み出します。

アーキテクチャ概要

Day & Night ペイウォールは、関心事を明確に分離したレイヤードアーキテクチャを採用しています。土台となるのは DayNightBackground コンポーザブルで、空のグラデーション遷移、個別にきらめく挙動を持つプロシージャル生成の星空、空を弧を描いて移動する太陽と月、継続的に流れるパララックス雲レイヤー、そしてシーン全体を支えるランドスケープのグラデーションなど、すべての環境アニメーションを担当します。

このアニメーション背景の上に、コンテンツオーバーレイとして実際のペイウォール情報が配置されます。サイクルに応じて「GOOD MORNING」と「GOOD EVENING」がクロスフェードする挨拶文、昼夜の状態に合わせて色が変化するアニメーション付きチェックマークの機能リスト、アクセントカラーがアニメーションする価格表示、そして昼は温かみのあるゴールド、夜はクールなインディゴへと遷移するCTAボタンが含まれます。

このレイヤードアーキテクチャにはいくつもの利点があります。背景のアニメーションロジックがコンテンツ表示から切り離されているため、両者をそれぞれ独立して変更しやすくなります。背景は必要に応じて他のコンテキストで再利用でき、コンテンツレイヤーは複雑なアニメーションコードに触れることなく更新可能です。さらに、この分離によって、Composeが各レイヤーごとに再コンポーズを最適化できるため、パフォーマンスの向上にもつながります。

アニメーションサイクルのセットアップ

このペイウォール全体は、16秒かけて 0 から 1 までループする単一の cycleProgress値によって駆動されます。この長さは慎重に選ばれていて、遷移をじっくり味わえるだけの余裕がありつつ、急かされている感じはしません。一方で、一般的なペイウォールの閲覧時間の中でユーザーがサイクル全体を体験できるくらいには短くもあります。

@Composable
fun DayNightPaywallScreen(onDismiss: () -> Unit = {}) {
    val paywallState = rememberPaywallState(onPurchaseSuccess = onDismiss)
    val infiniteTransition = rememberInfiniteTransition(label = "daynight")

    val cycleProgress by infiniteTransition.animateFloat(
        initialValue = 0f,
        targetValue = 1f,
        animationSpec = infiniteRepeatable(
            animation = tween(16000, easing = LinearEasing),
            repeatMode = RepeatMode.Restart,
        ),
        label = "cycle",
    )

    val isDay = cycleProgress < 0.5f
    \/\/ ...
}

このパターンは、複雑なアニメーションにおいて重要です。単一の進捗値を「唯一の真実（source of truth）」として扱い、そこから他のすべてのアニメーションを派生させます。こうすることで完全な同期が保証され、アニメーションの挙動も理解しやすくなります。このペイウォールのように複数のアニメーションが連動する必要がある場合、ドライバーを1つにすることでタイミングのズレ（ドリフト）をなくし、要素同士の関係を明確にできます。

LinearEasing を選んでいるのも意図的です。時間の経過を表す連続的なサイクルでは、線形の進行が最も自然に感じられます。非線形のイージングにすると、日中のある時間帯が速く感じたり遅く感じたりしてしまい、このメタファーが崩れます。 RepeatMode.Restart によって、深夜から夜明けへとシームレスにループできるようにしています。

サイクルは2つのフェーズに分かれています。昼のフェーズは 0.0〜0.5 で、この間に太陽が昇り、空を横切って沈みます。夜のフェーズは 0.5〜1.0 で、同じ軌道を月が辿ります。この対称的な分割により、ユーザーは昼と夜の両モードを同じだけ体験でき、2つのビジュアル表現の露出を最大化できる、バランスの取れた体験になります。

アニメーション背景の実装

DayNightBackground composable が、環境全体のアニメーションをすべて担当します。ここがまさに「魔法」が起きる場所で、シンプルな進捗値を、生き生きと動くシーンへと変換します。各レイヤーを分解して、どのように連携して動いているのかを理解していきましょう。

手続き的な星の生成

星は一度だけ生成して remember で保持し、自然なばらつきが出るようにプロパティをランダム化します。手続き的アプローチを採ることで、セッションごとにユニークな星空が生成され、体験にさりげない多様性が加わります。

data class NightStar(
    val x: Float,
    val y: Float,
    val size: Float,
    val twinklePhase: Float,
    val twinkleSpeed: Float,
)

@Composable
fun DayNightBackground(cycleProgress: Float, modifier: Modifier = Modifier) {
    val stars = remember {
        List(60) {
            NightStar(
                x = Random.nextFloat(),
                y = Random.nextFloat() * 0.6f,  \/\/ Upper 60% of sky only
                size = Random.nextFloat() * 2f + 1f,
                twinklePhase = Random.nextFloat() * PI.toFloat() * 2f,
                twinkleSpeed = Random.nextFloat() * 2f + 1f,
            )
        }
    }
    \/\/ ...
}

各星はそれぞれ固有の「きらめき（twinkle）」の位相と速度を持ち、同じタイミングで一斉に点滅しないようになっています。この非同期化はリアリティにとって重要で、同期したきらめきは不自然で機械的に見えてしまいます。 y 座標は 0.6 で上限を設け、星が本来あるべき空の上部に収まるようにしています。これにより、画面下部の地形（ランドスケープ）領域に星が出現するのを防げます。

星の数を 60 個にすることで、見た目の密度とパフォーマンスのバランスを取っています。星が少なすぎると夜空がスカスカに見え、逆に大幅に増やすと低スペック端末で描画パフォーマンスに影響する可能性があります。サイズを 1〜3px の範囲（Random.nextFloat() * 2f + 1f）にすることで奥行き感が生まれ、小さい星ほど遠くにあるように見せられます。

remember ブロックにより、星はコンポジションごとに一度だけ生成され、ペイウォールがサイクルで変化しても一貫性が保たれます。これがないと、再コンポーズのたびに星が再生成されてしまい、カオスなチラつきが発生します。

フレーム精度のデルタタイム

フレームレートに依存しない滑らかなアニメーションのために、実際に経過した時間を追跡します。この手法はプロ品質のアニメーションにおける基本で、性能特性が異なるデバイス間でも一貫した挙動を保証します。

var totalTime by remember { mutableFloatStateOf(0f) }
var lastFrameTimeNanos by remember { mutableLongStateOf(0L) }

LaunchedEffect(Unit) {
    while (true) {
        withFrameNanos { frameTimeNanos ->
            val deltaTime = if (lastFrameTimeNanos == 0L) {
                0.016f  \/\/ Assume 60fps for first frame
            } else {
                ((frameTimeNanos - lastFrameTimeNanos) \/ 1_000_000_000f)
                    .coerceIn(0f, 0.1f)  \/\/ Cap to prevent jumps
            }
            lastFrameTimeNanos = frameTimeNanos
            totalTime += deltaTime
        }
    }
}

このアプローチには2つのメリットがあります。1つ目は、端末性能に関係なくアニメーションが滑らかに保たれることです。30fps で動く端末でも 120fps の端末でも、同じ速度でアニメーションが進行します。2つ目は、デバイス間でアニメーション速度が統一されることです。低価格帯の端末でもハイエンド端末でも、ユーザーは同じ体験を見られます。

coerceIn(0f, 0.1f) は、アプリがバックグラウンドから復帰したときのアニメーションの「飛び」を防ぎます。この上限がない場合、アプリがサスペンドされている間のデルタタイムが数秒になることがあり、雲の移動のような連続アニメーションで不自然なジャンプが発生します。デルタタイムを 0.1 秒（100ms）に制限することで、短時間の中断後でも滑らかに復帰できます。

ここで重要になるのが withFrameNanos 関数です。次のフレームまでサスペンドし、ナノ秒単位で正確なフレームタイムスタンプを提供します。長時間動作するアニメーションでタイミング誤差が蓄積し得る delay() のような代替手段よりも、精度が高いのが特長です。

マルチフェーズの空グラデーション

空は 8 つの明確な色フェーズを順に遷移し、夜明け → 昼 → 夕暮れ → 夜 → 夜明けへと戻る、現実感のあるサイクルを描きます。各フェーズでは 3 色のグラデーションを使い、空に奥行きを与えています。

val sunriseColors = listOf(Color(0xFFFF8C42), Color(0xFFFFD700), Color(0xFFFFF4E0))
val dayColors = listOf(Color(0xFF4A90D9), Color(0xFF87CEEB), Color(0xFFB8E0F0))
val sunsetColors = listOf(Color(0xFFFF6B35), Color(0xFFFFAB5E), Color(0xFFFFD89E))
val duskColors = listOf(Color(0xFF2C3E50), Color(0xFF34495E), Color(0xFF5D6D7E))
val nightColors = listOf(Color(0xFF0D1B2A), Color(0xFF1B263B), Color(0xFF2C3E50))
val dawnColors = listOf(Color(0xFF1A1A2E), Color(0xFF16213E), Color(0xFF1F4068))

色の選定は意図的で、実際の空の観察に基づいています。日の出では暖かみのあるオレンジやゴールドから始まり、グラデーション上部に向かって淡い色調へと移ろいます。昼はおなじみのスカイブルーを基調に、地平線に近づくにつれて明るくなります。夕焼けでは、より深いオレンジや赤で暖色が強調されます。薄暮では光が失われ、くすんだブルーグレーが現れます。夜は上部が濃いネイビーからほぼ黒に近づき、次のサイクルに向けて夜明けでは再びわずかな暖色の兆しが加わります。

フェーズ計算では、各ハーフサイクル内での進捗を正規化し、昼または夜のフェーズそれぞれで 0〜1 のローカル進捗値を作ります。

val isDay = cycleProgress < 0.5f
val dayProgress = if (isDay) cycleProgress * 2f else (cycleProgress - 0.5f) * 2f

この正規化により遷移ロジックが単純化され、全体サイクルのどの位置にあっても、各フェーズは一貫して 0〜1 の範囲で扱えます。cycleProgress が 0.5 未満のときが昼フェーズ、上半分（0.5〜1.0）が夜フェーズです。

その後、各フェーズは lerp （線形補間）を使って滑らかに遷移します。進捗パラメータに基づいて色同士をブレンドします。

val skyColors = if (isDay) {
    when {
        dayProgress < 0.2f -> {
            val t = dayProgress \/ 0.2f  \/\/ Normalize to 0-1 within this phase
            listOf(
                lerp(sunriseColors[0], dayColors[0], t),
                lerp(sunriseColors[1], dayColors[1], t),
                lerp(sunriseColors[2], dayColors[2], t),
            )
        }
        dayProgress < 0.8f -> dayColors  \/\/ Hold steady during midday
        else -> {
            val t = (dayProgress - 0.8f) \/ 0.2f
            listOf(
                lerp(dayColors[0], sunsetColors[0], t),
                lerp(dayColors[1], sunsetColors[1], t),
                lerp(dayColors[2], sunsetColors[2], t),
            )
        }
    }
} else {
    \/\/ Similar structure for night phases...
}

この設計により、自然に感じられる遷移が実現します。各ハーフサイクルのうち、日の出・日の入りはそれぞれ 20% を占め、残り 60% は安定した昼／真夜中の状態が保たれます。このテンポは、地平線付近で遷移が比較的速く起こり、昼夜の大半は安定しているという現実の採光パターンを模しています。また、この 20/60/20 の配分により、ペイウォールを短時間しか見ないユーザーでも何らかの変化を目にしやすく、体験を動的に保てます。

フェード遷移を伴う星の瞬き

星は夜明けと夕暮れのタイミングでフェードイン／フェードアウトしつつ、夜の間はそれぞれが個別に瞬く必要があります。この「二重アニメーション」の要件は、エフェクトをきれいにレイヤー化する方法を示しています。

val starAlpha = if (isDay) {
    when {
        dayProgress < 0.15f -> 1f - dayProgress * 6f     \/\/ Fade out at dawn
        dayProgress > 0.85f -> (dayProgress - 0.85f) * 6f \/\/ Fade in at dusk
        else -> 0f  \/\/ Invisible during day
    }
} else {
    when {
        dayProgress < 0.15f -> dayProgress * 6f           \/\/ Fade in after sunset
        dayProgress > 0.85f -> 1f - (dayProgress - 0.85f) * 6f \/\/ Fade out before sunrise
        else -> 1f  \/\/ Fully visible at night
    }
}

if (starAlpha > 0f) {
    for (star in stars) {
        val twinkle = (sin(totalTime * star.twinkleSpeed + star.twinklePhase) + 1f) \/ 2f
        val alpha = starAlpha * (0.4f + twinkle * 0.6f)  \/\/ Range: 40% to 100%
        drawCircle(
            color = Color.White.copy(alpha = alpha),
            radius = star.size,
            center = Offset(star.x * width, star.y * height),
        )
    }
}

フェードのタイミングは、各フェーズの端に 15% のウィンドウを設けており、滑らかな遷移になります。倍率の 6（1/0.15 から導出）によって、フェードがそのウィンドウ内でちょうど完了するように調整されています。昼フェーズでは、時間の 70% は星が不可視（alpha 0）で、夜明けと夕暮れの遷移中にだけ星が現れます。

瞬き（twinkle）効果は、各星が持つ固有の位相でオフセットされたサイン波を使います。サイン関数は自然に -1〜1 の間を往復するため、 (sin(...) + 1f) / 2f で 0〜1 に正規化します。これに starAlpha を掛けることで全体のフェード効果を作り、さらに内側の計算 (0.4f + twinkle * 0.6f) によって星が完全に消えないようにしています。つまり、明るさは 40%〜100% の間で揺れ、実際の星のような大気による瞬きに近い見え方になります。

パフォーマンス最適化として、 if (starAlpha > 0f) により、昼の間（星が見えないとき）は星の描画ループ自体をスキップします。これにより、不要な計算を避けられます。

太陽と月の弧を描く軌道

太陽と月は、空の上を同じ弧のパスで移動し、説得力のある天体の動きを作り出します。ここで使っている三角関数によって、地平線から地平線へと自然に移る軌道になります。

val sunMoonY = height * 0.35f  \/\/ Arc center Y position
val arcRadius = width * 0.6f   \/\/ Arc radius
val centerX = width \/ 2f

if (isDay) {
    val sunAngle = PI.toFloat() * (1f - dayProgress)  \/\/ PI to 0 as progress increases
    val sunX = centerX + cos(sunAngle) * arcRadius
    val sunY = sunMoonY - sin(sunAngle) * arcRadius * 0.5f + height * 0.1f

    if (sunY < height * 0.7f) {  \/\/ Only draw when above horizon
        \/\/ Draw sun...
    }
}

この三角関数は、パラメトリックな計算で滑らかな弧を作ります。 dayProgress = 0 のとき角度は PI （180度）なので、 cos(PI) = -1 により太陽は画面の左側に位置します。 dayProgress = 0.5 のとき角度は PI/2 （90度）となり、 cos(PI/2) = 0 かつ sin(PI/2) = 1 なので、太陽は画面上部の中央に配置されます。 dayProgress = 1 のとき角度は 0 になり、cos(0) = 1によって太陽は画面の右側に位置します。

Y成分に 0.5f の倍率を掛けることで、円弧ではなく楕円弧になり、空の高い位置まで上がりすぎない、より自然な「地平線から地平線」への軌道になります。さらに height * 0.1f のオフセットで弧全体を下方向にずらし、太陽と月が可視領域の下から昇って、また下へ沈むように見せることで、適切な地平線の演出を作っています。

また、 if (sunY < height * 0.7f) という地平線チェックによって、天体が地形（ランドスケープ）エリアの下にあるときは描画しないようにしています。このシンプルなカリングにより、日の出・日の入り（および月の出・月の入り）の切り替わりがきれいになり、太陽と月が自然に地平線から現れて沈むように見えます。

アニメーションする光線を備えた太陽の描画

太陽は、発光して“生きている”ように見せるために複数レイヤーで構成されています。各レイヤーには役割があり、それらが合わさって放射するような暖かさの印象を作ります。

\/\/ Outer glow
drawCircle(
    brush = Brush.radialGradient(
        colors = listOf(
            Color(0xFFFFFFCC).copy(alpha = 0.4f),
            Color(0xFFFFD700).copy(alpha = 0.2f),
            Color.Transparent,
        ),
        center = Offset(sunX, sunY),
        radius = 80f,
    ),
    radius = 80f,
    center = Offset(sunX, sunY),
)

\/\/ Main sun body
drawCircle(
    brush = Brush.radialGradient(
        colors = listOf(
            Color(0xFFFFFFE0),
            Color(0xFFFFD700),
            Color(0xFFFFA500),
        ),
        center = Offset(sunX - 8f, sunY - 8f),  \/\/ Offset for 3D effect
        radius = 35f,
    ),
    radius = 35f,
    center = Offset(sunX, sunY),
)

\/\/ Animated rays
for (i in 0 until 12) {
    val rayAngle = (i * 30f + totalTime * 20f) * PI.toFloat() \/ 180f
    val innerRadius = 40f
    val outerRadius = 55f + sin(totalTime * 3f + i) * 5f  \/\/ Pulsing length
    drawLine(
        color = Color(0xFFFFD700).copy(alpha = 0.6f),
        start = Offset(
            sunX + cos(rayAngle) * innerRadius,
            sunY + sin(rayAngle) * innerRadius,
        ),
        end = Offset(
            sunX + cos(rayAngle) * outerRadius,
            sunY + sin(rayAngle) * outerRadius,
        ),
        strokeWidth = 3f,
        cap = StrokeCap.Round,
    )
}

外側のグロー（発光）には、透明へ向かってフェードする放射状グラデーションを使い、太陽の周りに柔らかなハロー（光の輪）を作ります。この大気的なグローが奥行きを与え、太陽がただの平坦な円として空間に浮いて見えるのを防ぎます。

太陽本体は、グラデーションの中心を少しオフセット（上と左へ8ピクセル）して、控えめな3D感を作っています。このオフセットにより片側がより明るく見え、太陽に厚みがあり、光が一定方向から当たっているかのように感じられます。中心の淡い黄色から金色を経て、縁のオレンジへと移る色の変化は、太陽の写真で見られる色の階調を再現しています。

光線（レイ）は2つの方法でアニメーションします。1つ目は、角度計算にある totalTime * 20f によってゆっくり回転し、スピンしているような効果を作ります。2つ目は、 sin(totalTime * 3f + i) * 5f によって各光線の長さがそれぞれ独立して伸縮し、 + i の位相オフセットで光線ごとに脈動のタイミングがずれるようにしています。この組み合わせにより、有機的で呼吸しているような質感が生まれ、太陽が“生きている”ように感じられます。

視差による雲の移動

雲は、互いに独立した移動速度によって奥行きを作ります。これは「パララックス（視差）」と呼ばれる手法で、2Dシーンに立体感を生み出すうえで基本となるものです。

data class Cloud(val xOffset: Float, val y: Float, val scale: Float, val speed: Float)

val clouds = remember {
    List(5) {
        Cloud(
            xOffset = Random.nextFloat(),
            y = Random.nextFloat() * 0.3f + 0.1f,  \/\/ Upper portion of sky
            scale = Random.nextFloat() * 0.5f + 0.8f,
            speed = Random.nextFloat() * 0.02f + 0.01f,
        )
    }
}

5つの雲には、それぞれ異なるスケール（大きさ）と速度が設定されています。大きくて遅い雲は遠くにあるように見え、小さくて速い雲は手前にあるように感じられます。この変化により、平坦な2Dキャンバスであっても大気的な奥行きが生まれます。Y座標は画面の上部1/3（高さの0.1〜0.4）に制限されており、雲が本来あるべき空の領域に収まるようになっています。

各雲は、重なり合う円で描画され、横方向にループ（wrap）する移動を行います。

val cloudAlpha = if (isDay) 0.9f else 0.15f  \/\/ Dim at night
val cloudColor = if (isDay) Color.White else Color(0xFF555555)

for (cloud in clouds) {
    val cloudX = ((cloud.xOffset + totalTime * cloud.speed) % 1.4f - 0.2f) * width

    drawCircle(
        color = cloudColor.copy(alpha = cloudAlpha * 0.8f),
        radius = 25f * cloud.scale,
        center = Offset(cloudX, cloudY),
    )
    drawCircle(
        color = cloudColor.copy(alpha = cloudAlpha),
        radius = 35f * cloud.scale,
        center = Offset(cloudX + 30f * cloud.scale, cloudY - 5f),
    )
    \/\/ Additional circles for cloud shape...
}

% 1.4f - 0.2f というラップの式によって、雲は右側へ抜けたあと、左側から自然に再登場します。 1.4 の範囲（画面幅の140%）と -0.2 のオフセットを組み合わせることで、雲は画面の左端より少し外側で生成され、可視領域全体を横切り、右端を少し超えたところまで進んでからラップします。これにより、端で“ポップ”して見えることなく、滑らかで連続的な動きになります。

雲の色とアルファ（不透明度）は昼夜で変化します。昼の雲は不透明度90%の明るい白で、青空に対してはっきり見えます。夜の雲は不透明度15%の濃いグレーになり、星空を邪魔しない程度の控えめなシルエットとして見えるようになります。

サイクルに合わせてUI要素をアニメーションさせる

UIレイヤーは、 animateColorAsState を使って昼／夜の状態に応じてアニメーションします。animateColorAsState は、ターゲットの色が変わるたびに色同士を滑らかに補間します。

val buttonColor by animateColorAsState(
    targetValue = if (isDay) Color(0xFFFFB800) else Color(0xFF6366F1),
    animationSpec = tween(800),
    label = "buttonColor",
)

val buttonTextColor by animateColorAsState(
    targetValue = if (isDay) Color.Black else Color.White,
    animationSpec = tween(800),
    label = "buttonTextColor",
)

val accentColor by animateColorAsState(
    targetValue = if (isDay) Color(0xFFFFD700) else Color(0xFF8B9DC3),
    animationSpec = tween(800),
    label = "accentColor",
)

800ms のdurationは、急ぎすぎない滑らかなトランジションを作ります。このタイミングは、ペイウォール全体のテンポに合わせて選ばれており、反応は十分に機敏に感じられつつ、ユーザーが変化を認識できて心地よい速さでもあります。色の選定も昼夜テーマを強化します。昼は暖かいゴールド系のトーンで日差しやエネルギーを想起させ、夜はクールなインディゴやシルバー系で落ち着きと洗練された印象を作ります。

label パラメータは、デバッグやツール連携で重要です。Android StudioのAnimation PreviewやComposeのデバッグツールを使うとき、これらのlabelによって可視化の中で「どのアニメーションがどれか」を識別しやすくなります。

挨拶テキストのクロスフェードアニメーション

挨拶テキストは、Crossfade を使って「GOOD MORNING」と「GOOD EVENING」を切り替えています。Crossfade は、コンテンツが切り替わる際の表示・非表示アニメーションを自動的に処理してくれます。

Crossfade(
    targetState = isDay,
    animationSpec = tween(800),
    label = "greeting",
) { day ->
    Text(
        text = if (day) "GOOD MORNING" else "GOOD EVENING",
        style = TextStyle(
            color = Color.White.copy(alpha = 0.8f),
            fontSize = 12.sp,
            fontWeight = FontWeight.Bold,
            letterSpacing = 4.sp,
        ),
    )
}

Crossfade コンポーザブルは、古いコンテンツをフェードアウトしつつ、新しいコンテンツを同時にフェードインさせます。これにより、ジャンプやチラつきのない、滑らかな切り替えが実現します。 800ms のdurationは他のUIアニメーションと揃えられており、全体として一体感のある体験を生み出します。

この挨拶テキストは、単なる装飾以上の重要な役割を持っています。時間帯に合った挨拶は、アプリがユーザーの状況を理解し、それに反応しているように感じさせる小さな工夫です。アニメーションする環境表現と組み合わさることで、配慮が行き届いた、完成度の高い体験であるという印象をユーザーに与えます。

カスタムチェックマークの描画

機能リストの各項目には、 Canvas で描画したアニメーション付きのチェックマークが含まれており、アニメーションに反応するカスタムグラフィックの作り方を示しています。

@Composable
fun TimeFeatureItem(title: String, checkColor: Color, modifier: Modifier = Modifier) {
    Row(
        modifier = modifier.fillMaxWidth().padding(vertical = 8.dp),
        verticalAlignment = Alignment.CenterVertically,
    ) {
        Box(
            modifier = Modifier
                .size(24.dp)
                .clip(CircleShape)
                .background(checkColor),  \/\/ Animated color from parent
            contentAlignment = Alignment.Center,
        ) {
            Canvas(modifier = Modifier.size(12.dp)) {
                val path = Path().apply {
                    moveTo(size.width * 0.2f, size.height * 0.5f)
                    lineTo(size.width * 0.4f, size.height * 0.7f)
                    lineTo(size.width * 0.8f, size.height * 0.3f)
                }
                drawPath(
                    path = path,
                    color = Color.White,
                    style = Stroke(width = 2f, cap = StrokeCap.Round, join = StrokeJoin.Round),
                )
            }
        }

        Spacer(modifier = Modifier.width(14.dp))

        Text(
            text = title,
            style = TextStyle(
                color = Color.White,
                fontSize = 15.sp,
                fontWeight = FontWeight.Medium,
            ),
        )
    }
}

アイコンではなく Canvas でチェックマークを描画することで、より精密にコントロールでき、アセットへの依存もなくせます。チェックマークのパスは相対座標（キャンバスサイズに対する割合）で定義されているため、どのサイズでも正しくスケールします。 StrokeCap.Round と StrokeJoin.Round によって、線の端や角が滑らかで、親しみやすい見た目になります。

背景色は親コンポーザブルから渡され、昼夜サイクルに合わせてアニメーションします。つまり、チェックマークの円は日中の暖かいゴールドから、夜の落ち着いたインディゴへと滑らかに移行し、ペイウォール全体のビジュアルと調和を保ちます。

購入のためのRevenueCat統合

このペイウォールは rememberPaywallState ヘルパーを通じてRevenueCatを統合しており、購入ロジックをすべてカプセル化して、UIレイヤーに対してクリーンなインターフェースを提供します。

@Composable
fun DayNightPaywallScreen(onDismiss: () -> Unit = {}) {
    val paywallState = rememberPaywallState(onPurchaseSuccess = onDismiss)

    \/\/ ...

    Button(
        onClick = { paywallState.purchase(PackageType.ANNUAL) },
        modifier = Modifier.fillMaxWidth().height(56.dp),
        colors = ButtonDefaults.buttonColors(containerColor = buttonColor),
        shape = RoundedCornerShape(14.dp),
    ) {
        Text(
            text = "Start Free Trial",
            style = TextStyle(
                color = buttonTextColor,
                fontSize = 16.sp,
                fontWeight = FontWeight.Bold,
            ),
        )
    }

    \/\/ ...

    Text(
        text = "Restore Purchases",
        modifier = Modifier.clickable { paywallState.restorePurchases() },
        \/\/ ...
    )
}

PaywallState クラスが購入に関するロジックをすべて内包することで、UIのコンポーザブルは表示（プレゼンテーション）に集中できます。

class PaywallState(
    private val scope: CoroutineScope,
    private val onPurchaseSuccess: () -> Unit,
    private val onPurchaseError: (String) -> Unit,
    private val onPurchaseCancelled: () -> Unit,
) {
    var offering by mutableStateOf<OfferingInfo?>(null)
    var isLoading by mutableStateOf(false)
    var errorMessage by mutableStateOf<String?>(null)
    var selectedPackage by mutableStateOf(PackageType.ANNUAL)

    fun purchase(packageType: PackageType) {
        scope.launch {
            isLoading = true
            when (val result = PurchaseHelper.purchase(packageType)) {
                is PurchaseResult.Success -> onPurchaseSuccess()
                is PurchaseResult.Error -> onPurchaseError(result.message)
                is PurchaseResult.Cancelled -> onPurchaseCancelled()
            }
            isLoading = false
        }
    }

    fun restorePurchases() {
        scope.launch {
            isLoading = true
            when (val result = PurchaseHelper.restorePurchases()) {
                is PurchaseResult.Success -> onPurchaseSuccess()
                is PurchaseResult.Error -> onPurchaseError(result.message)
                is PurchaseResult.Cancelled -> { \/* No-op *\/ }
            }
            isLoading = false
        }
    }
}

この関心の分離は、明確なアーキテクチャ原則に沿っています。つまり、UIコンポーネントは表示のみを担当し、ビジネスロジックは別クラスに置くべき、という考え方です。PaywallState はRevenueCatとのやり取り全般、ローディング状態、エラーハンドリングを管理し、UIが必要とするインターフェースだけを公開します。これにより、コードはテストしやすく、保守しやすく、変更もしやすくなります。購入ロジックの変更でUIコードを触る必要がなく、その逆も同様です。

アジャイルなA/BテストのためのFirebase活用

カスタムペイウォールは高い表現力とコントロールを提供しますが、異なるメッセージやオファーをテストするには、リモートで設定を切り替えられる仕組みが必要です。Firebase Realtime Database や Firestore を使えば、アプリのアップデートを行わずにペイウォールのコンテンツを反復改善できるようになります。

ペイウォールコンテンツにFirebaseを使う理由

RevenueCat は、サブスクリプションプロダクト、価格設定、アナリティクスの管理において非常に優れています。しかし、カスタムペイウォールを構築した場合、コンバージョンに影響する コンテンツレイヤー ― 見出し、サブ見出し、機能リスト、価格表示形式、CTA（コールトゥアクション）文言 ― をリモートで制御できる必要があります。これらの要素は実験によって最適化されることが多く、変更のたびにアプリストアの審査サイクルを待つのは、反復スピードを大きく落としてしまいます。

Firebase を使えば、アプリのアップデートなしでこれらの値を変更でき、迅速な実験が可能になります。朝にテストを立ち上げ、日中にデータを収集し、夜には勝ちパターンをロールアウトする──従来のアプリ更新では不可能なスピードです。この俊敏性は、どのメッセージがユーザーに響くのかを学んでいる マネタイズ初期フェーズ において、特に大きな価値を発揮します。

ブランド表現や高度なアニメーションを担う カスタムUI と、素早い反復改善を可能にする リモートコンテンツ を組み合わせることで、両方のメリットを享受できます。ペイウォールはユニークな見た目と体験を保ちつつ、テンプレート型ソリューションを使うチームと同じスピードでメッセージ最適化を行うことができます。

ペイウォールコンテンツのRemote Configを設定する

まず、Firestore にペイウォール設定の構造を定義します。この構造では、変更・検証したくなる可能性のある すべてのテキスト要素 を含めるようにします。

data class PaywallConfig(
    val headline: String = "Always On",
    val subheadline: String = "Premium works day and night",
    val features: List<String> = listOf(
        "24\/7 Access Anytime",
        "Sync Across All Devices",
        "Offline Mode Support",
        "Smart Scheduling",
        "Priority Notifications",
    ),
    val priceDisplay: String = "$39.99\/year",
    val priceSubtext: String = "Less than $3.50\/month",
    val ctaText: String = "Start Free Trial",
    val variant: String = "control",
)

デフォルト値には、主に2つの役割があります。1つ目は、ネットワークリクエストが失敗した場合の フォールバック として機能し、ペイウォールが常に妥当な内容で表示されるようにすること。2つ目は、想定するコンテンツを ドキュメント化 することです。各フィールドが何のためのものかが明確になり、運用や更新もしやすくなります。

また、 variant フィールドはアナリティクスにおいて重要です。設定そのものにバリアント識別子を含めておくことで、分析イベントに 常に正しい紐づけ（アトリビューション） を入れられるようになります。これは、A/Bテストでよくある「バリアントの割り当て」と「表示されたコンテンツ」がズレてしまう不具合の典型を防ぐことにもつながります。

ペイウォール表示時に設定を取得する

class PaywallConfigRepository(
    private val firestore: FirebaseFirestore
) {
    suspend fun getPaywallConfig(userId: String): PaywallConfig {
        \/\/ Determine which variant this user should see
        val variant = determineVariant(userId)

        return firestore.collection("paywall_configs")
            .document(variant)
            .get()
            .await()
            .toObject<PaywallConfig>()
            ?: PaywallConfig()  \/\/ Fallback to defaults
    }

    private fun determineVariant(userId: String): String {
        \/\/ Simple hash-based assignment for consistent user experience
        val hash = userId.hashCode().absoluteValue
        return when (hash % 3) {
            0 -> "control"
            1 -> "variant_a"
            else -> "variant_b"
        }
    }
}

ハッシュベースでのバリアント割り当てにより、一貫性が保たれます。同じユーザーはセッションをまたいでも常に同じバリアント を見ることになり、これは正しいA/Bテストを行ううえで不可欠です。もし訪問のたびに異なるバリアントが表示されてしまうと、特定の施策がどの程度効果を持ったのかを正確に測定することができません。

また、 ?: PaywallConfig() のような null 合体演算子を使って デフォルト値にフォールバック することで、Firestore が利用できない場合でもペイウォールが必ず動作するようになります。このような防御的な設計により、ネットワーク障害が原因で購入フロー全体が止まってしまう事態を防ぐことができます。

ペイウォールに動的コンテンツを組み込む

ペイウォールが 設定（config）を受け取れるように修正 します。

@Composable
fun DayNightPaywallScreen(
    config: PaywallConfig,
    onDismiss: () -> Unit = {},
) {
    \/\/ Use config values instead of hardcoded strings
    Text(
        text = config.headline,
        style = TextStyle(
            color = Color.White,
            fontSize = 38.sp,
            fontWeight = FontWeight.Bold,
        ),
    )

    Text(
        text = config.subheadline,
        style = TextStyle(
            color = Color.White.copy(alpha = 0.7f),
            fontSize = 14.sp,
        ),
    )

    \/\/ Dynamic feature list
    Column(
        modifier = Modifier
            .fillMaxWidth()
            .clip(RoundedCornerShape(16.dp))
            .background(Color.Black.copy(alpha = 0.3f))
            .padding(16.dp),
    ) {
        config.features.forEach { feature ->
            TimeFeatureItem(title = feature, checkColor = checkColor)
        }
    }

    \/\/ Dynamic pricing
    Text(text = config.priceDisplay, \/* ... *\/)
    Text(text = config.priceSubtext, \/* ... *\/)

    \/\/ Dynamic CTA
    Button(onClick = { paywallState.purchase(PackageType.ANNUAL) }) {
        Text(text = config.ctaText, \/* ... *\/)
    }
}

ペイウォールを config オブジェクトでパラメータ化することで、無制限のバリエーションをサポートする柔軟な仕組みを構築できます。アニメーションやビジュアルデザインは一貫して（かつ差別化された状態で）保たれ、コンテンツはリモートから調整可能になります。この分離は、ユーザーが「形」と「内容」の両方に反応するという示唆を反映しています。形（デザイン）はブランド認知を形成し、内容（メッセージング）はコンバージョンを促進します。

コンバージョンイベントのトラッキング

A/B テストの結果を分析するために、バリアント識別子を含めたコンバージョンイベントをログに記録します。

class PaywallAnalytics(
    private val analytics: FirebaseAnalytics
) {
    fun logPaywallViewed(variant: String) {
        analytics.logEvent("paywall_viewed") {
            param("variant", variant)
            param("paywall_type", "day_night")
        }
    }

    fun logPurchaseStarted(variant: String, packageType: String) {
        analytics.logEvent("purchase_started") {
            param("variant", variant)
            param("package_type", packageType)
        }
    }

    fun logPurchaseCompleted(variant: String, packageType: String) {
        analytics.logEvent("purchase_completed") {
            param("variant", variant)
            param("package_type", packageType)
        }
    }
}

これら 3 つのイベントによってコンバージョンファネルが構築され、ユーザーがどの段階で離脱しているのかを分析できるようになります。各イベントをバリアントごとにフィルタリングすることで、施策間のパフォーマンスを比較できます。 paywall_type パラメータは、複数のペイウォールデザインを運用している場合に、デザインごとの分析を可能にします。

Firebase での結果分析

Firebase Analytics でファネル分析を作成し、 paywall_viewed→purchase_started→purchase_completed という遷移を確認します。各ステップをバリアントごとにフィルタリングし、バリアント間でコンバージョン率を比較して勝ちパターンを特定します。

結果を解釈する際には、統計的有意性が重要であることを忘れないでください。特にサンプルサイズが小さい場合、コンバージョン率のわずかな差はノイズであり、意味のある差ではない可能性があります。Firebase のオーディエンス機能を使えば、セグメントごとの影響を把握できます。たとえば、新規ユーザーには効果的なバリアントが、リピーターには期待どおりに機能しない、といったケースもあり得ます。

ペイウォール A/B テストのベストプラクティス

A/B テストから実行可能な示唆を得るためには、いくつかの原則があります。まず、可能な限り一度にテストする変数は 1 つにしてください。見出し、機能リスト、CTA を同時に変更してしまうと、どの変更が結果に影響したのかを特定できません。どうしても複数の変更をまとめてテストする必要がある場合は、それらを1 つのバリアントとして扱い、個々の要素について結論を出さないようにします。

次に、一貫したユーザー割り当てを行い、同じユーザーが常に同じバリアントを見るようにしてください。これにより、訪問のたびに異なる体験をしてしまうことで生じるノイズを防げます。三つ目に、統計的有意性を得られる十分な期間テストを実施することが重要です。検出したい効果量にもよりますが、通常はバリアントごとに 1,000 件以上のコンバージョンが必要になります。

四つ目として、セグメント別のテストも検討してください。新規ユーザーと既存ユーザーではメッセージへの反応が異なることが多く、セグメント内でのテストによって、全体集計では見えない示唆が得られる場合があります。最後に、結果を記録し、アーカイブすることです。時間をかけて、自社のオーディエンスに何が有効かという組織的な知見が蓄積され、将来の実験に活かせるようになり、同じアイデアを再テストする必要も減っていきます。

RevenueCat Paywall Builder：カスタムを超えて

カスタムペイウォールは最大限の柔軟性を提供しますが、多くのケースにおいては RevenueCat’s Paywall Builder が非常に魅力的な選択肢になります。それぞれのアプローチがどのような場面で適しているかを理解することで、開発リソースをより効果的に配分できるようになります。

Paywall Builder が提供するもの

RevenueCat の Paywall Builder は、サーバードリブン UI の仕組みを採用したペイウォール構築ツールで、RevenueCat ダッシュボード上のビジュアルエディタを使って、コード変更なしでペイウォールをデザインできます。いったん作成したペイウォールは、アプリのアップデートを行うことなくリモートで更新でき、色、フォント、レイアウト、画像、コピーをいつでも変更可能です。組み込みの A/B テスト機能により、異なるデザインを統計的な厳密さをもってテストでき、トラフィックの自動割り当てや結果のトラッキングも行われます。

ローカリゼーション機能では、翻訳を一元管理でき、ユーザーのロケールに応じて自動的に適切な言語が配信されます。アナリティクスとの統合により、追加の計測実装なしでコンバージョンの自動トラッキングが可能です。また、テンプレートライブラリには実績のあるデザインが用意されており、それらをベースにカスタマイズすることもできます。

サーバードリブン UI の利点

Paywall Builder の最大の利点は、サーバードリブン UI にあります。アプリはサーバーから提供される設定内容をそのまま描画するため、ペイウォールの見た目をアプリのリリースサイクルから切り離すことができます。

@Composable
fun PaywallScreen(onDismiss: () -> Unit) {
    PaywallDialog(
        PaywallDialogOptions.Builder()
            .setDismissRequest(onDismiss)
            .build()
    )
}

この単一の composable によって、RevenueCat ダッシュボードで設定したあらゆるペイウォールデザインを描画できます。色、フォント、レイアウトの変更、画像やアイコンの差し替え、コピーや価格表示の修正、A/B テストの開始、勝ちパターンのロールアウトまで、いずれもアプリのアップデートは不要です。

運用面での影響は非常に大きいです。プロダクトチームはエンジニアリングに依存せずにペイウォールを改善・反復できるため、実験のサイクルを大幅に高速化できます。ペイウォール内容に関する不具合も、アプリストアの審査を待つことなく即座に修正可能です。また、季節キャンペーンなども、アプリ更新の調整を行わずに、正確なスケジュールで開始・終了できます。

Paywall Builder を選ぶべきタイミング

反復スピードが最優先される場合、Paywall Builder は多くのケースで最適な選択肢になります。コンバージョン最適化を目的として多数のバリエーションを素早くテストしたい場合、ビジュアルエディタと組み込みの A/B テスト機能によって、フィードバックループを大幅に短縮できます。プロダクトチームはエンジニアリングの関与なしにテストを作成・公開できるため、開発者は他の重要な作業に集中できます。

エンジニアリングリソースに制約がある場合も、Paywall Builder は有利です。カスタムペイウォールは初期実装だけでなく、その後の保守にも開発工数が必要になります。一方で Paywall Builder では、これらの作業をプロダクトチームやデザインチームに移譲でき、コードを書くことなくビジュアルエディタ上で対応できます。

高度なアニメーションが不要な場合も、Paywall Builder は十分に対応可能です。基本的なアニメーションやトランジションをサポートしており、複雑なカスタム演出を必要としないペイウォールであれば、テンプレートで事足ります。実際、多くの成功しているアプリは、凝ったモーションデザインよりも、明確なメッセージを重視したシンプルなペイウォールを採用しています。

また、クロスプラットフォームでの一貫性も重要な検討ポイントです。Paywall Builder は iOS、Android、Web で同じ見た目を一貫して描画できます。一方、カスタム実装ではプラットフォームごとに個別の開発が必要となり、エンジニアリング投資がその分増加します。

カスタムペイウォールが依然として有効なケース

ブランド表現が最優先される場合、カスタムペイウォールは今でも正しい選択肢です。独自のビジュアルアイデンティティやカスタムアニメーションに厳密に合わせる必要がある場合、テンプレートでは再現できません。ここまで見てきた「Day & Night」ペイウォールはその典型例で、プロシージャルに生成される星空、三角関数を用いた太陽／月の軌道、複数レイヤーが同期して動くアニメーションは、いずれもカスタムコードなしでは実現不可能です。

また、テンプレートでは対応できない独自のインタラクションが必要な場合も、カスタム実装が求められます。ゲーミフィケーションされたペイウォール、AR プレビュー、ジェスチャーベースのナビゲーション、あるいはプレミアム機能のミニデモなどは、いずれもカスタム実装が前提となります。こうしたインタラクティブな要素は、ユーザーが購入前に価値を体験できるため、コンバージョンに大きな影響を与えることがあります。

場合によっては、ペイウォールそのものがプロダクトの差別化要因になることもあります。たとえば、プレミアム体験のトーンを決定づける瞑想アプリの落ち着いたペイウォールのように、ペイウォール体験自体が「売り」になるケースでは、カスタム開発に投資する価値があります。第一印象は非常に重要であり、印象的なペイウォールは、プレミアムプランに対してユーザーが期待できる品質を強く印象づけるシグナルになります。

ハイブリッドアプローチ

多くの成功しているアプリは、これら2つのアプローチを戦略的に併用しています。初回のコンバージョンフローとなるメインのペイウォールにはカスタム実装を用い、ブランド表現や初めて課金に触れるユーザーに向けた印象的な体験を提供します。一方で、季節キャンペーン用のペイウォール、解約ユーザー向けのリカバリー施策、あるいは高速な反復が求められる実験用バリエーションについては、Paywall Builder が活用されます。これらのケースでは、カスタムデザインよりもスピードと柔軟性のほうが重要になるためです。設定画面内のアップセルや、機能制限時に表示されるプロンプトといったセカンダリな表示箇所でも、表示頻度が低く、簡単に調整できることが価値になるため、Paywall Builder が使われることが多くあります。

このハイブリッドアプローチにより、ブランド表現と反復スピードの両方を最大化できます。メインのペイウォールでは強い第一印象を作りつつ、Paywall Builder を使うことで、継続的な最適化やプロモーション施策に必要な柔軟性を確保できるのです。

結論

Jetpack Compose を使ってアニメーション付きのカスタムペイウォールを構築することで、テンプレート型のソリューションでは実現できないクリエイティブな表現が可能になります。今回紹介した Day & Night ペイウォールは、レイヤー化されたアニメーション、空のグラデーション、きらめく星、天体の軌道、パララックスで動く雲、そして同期した UI 要素を組み合わせることで、ユーザーの感情に訴えかける没入感のある体験を生み出しています。これらの手法は、コンバージョンの瞬間を単なる「取引」から「体験」へと変え、コンバージョン率とブランド認知の双方を高める可能性があります。

Firebase は、ペイウォールコンテンツをアジャイルに A/B テストするために必要なリモート設定レイヤーを提供します。見出し、機能説明、価格表示、CTA テキストを外部化することで、カスタムアニメーション体験を維持したまま、アプリ更新なしでメッセージングを反復改善できます。カスタムデザインとリモートコンテンツを組み合わせることで、ブランドの独自性と運用面での俊敏性の両方を手に入れることができます。

一方で、カスタムペイウォールが常に最適な選択肢とは限りません。RevenueCat の Paywall Builder は、サーバードリブン UI、組み込みの A/B テスト、高速な反復を可能にする機能を備えており、多くのケースではカスタム開発の利点を上回る価値を提供します。カスタムとテンプレートのどちらを選ぶべきかは、チームのリソース、反復スピードの要件、そしてブランド表現の重要度を踏まえて判断する必要があります。実際、多くの成功しているアプリは、主要な体験にはカスタムを、プロモーションやセカンダリな表示にはテンプレートを使うという形で、両者を併用しています。

RevenueCat の SDK 連携に関する完全なドキュメントについては、公式の RevenueCat ドキュメント を参照してください。また、本記事で紹介したソースコードの全体については、GitHub リポジトリ をご確認ください。

それから数年が経ち、ブームはひと段落。自宅のスペースにも少し余裕ができた頃、抗えないほど魅力的なオファーが舞い込みました。友人が、ほとんど使っていないPelotonのバイクを、定価の3分の1で譲ってくれるというのです。ただし条件はひとつ。2月の凍えるような朝に、ロンドン中を運んで持ち帰ること。――挑戦、受けて立ちました。

これは、そんな私の体験談です。Pelotonに夢中になったところから始まり、次第に単調さに悩まされ、値上げを乗り越え、そして最終的にサブスクリプションを解約するまで。インターバルトレーニングのような構成だと思ってください。つらくて息が上がるような記憶のパートの合間に、少し呼吸を整えられる“軽めの区間”として、あなたのサブスクリプションアプリにも実際に活かせる学びを挟んでいきます。

隔たり1：パーソナライズされたプランに飛び込む

最初のつまずきは、アカウント設定の段階でした。細かい注意書きを読むのは昔から得意ではなく、案の定、月額39ポンドのAll-Accessサブスクリプションに加入しないと、バイクをフルに活用できないことが判明しました。

……おっと。それでも、やってみようという気持ちは揺らぎませんでした。しかも、このサブスクリプションがあればパートナーもバイクを使える。それが彼にとってはかなり魅力的だったようです。外は雨。私はますますバイクに乗る理由を見つけ、室内ライドにのめり込んでいきました。

そして、何よりのハイライトはここでした。Pelotonのパーソナライズドプラン機能です。

Pelotonからのメール：プランのカスタマイズについて

私は以前から、多くのアプリが提供する「決められたプラン」にうまくはまれずにいました。たいていは一種類の運動にフォーカスしていますが、私はバリエーションがないと続かないタイプです。同じレシピを二度と作らない人間、と言えば伝わるでしょうか。本当にそうなんです。

Pelotonでは、バイク、ランニング、筋トレを組み合わせたルーティンをすぐにカスタマイズでき、迷うことなくスタートできました。

以下が、実際のオンボーディングフローです。

Pelotonの質問

オンボーディングは直感的で、使っていて「分からない自分が悪い」と感じさせることがありません。

• HIITカーディオのように馴染みのないワークアウトでも、内容を分かりやすく説明してくれる
• ビジュアルで器具の使い方が一目で分かる
• 目標についても、シンプルで率直な言葉で質問される

エクササイズのわかりやすい説明

インストラクターや音楽のバリエーションも素晴らしく、ハイエナジーなワークアウトと完璧にマッチしていました。毎週の連続記録（ストリーク）もあっという間に伸び、週に1回ワークアウトするだけでも継続できる仕組みだったので、世界のどこにいても、必ず最低1セッションはこなしていました。

教訓1：ユーザーがすぐにアプリの価値を最大限引き出せるようにする

Pelotonでは、コンテンツを見つけるのがとにかく簡単でした。いくつかのシンプルな質問に答えるだけで、アプリは私を理解し、本当に楽しめるワークアウトを提案してくれます。ここで言う「速い」とは、必ずしもオンボーディングが短いという意味ではありません。オンボーディングが長めでも、ユーザーが最初の段階で明確な価値を感じられることが重要です。

その点で、Pelotonは非常に優れています。パーソナライズされたルーティンを作るだけでなく、別の短いクイズを通じてお気に入りのインストラクターを見つける手助けまでしてくれます。TinderとStravaを掛け合わせたような体験で、「自分のワークアウトに本当に足りなかったのは、このマッチメイキングだったんだ」と気づかされました。

Pelotonウェブサイト上のインストラクター用診断テスト

隔たり2：Peloton利用が下り坂に入る

ハネムーン期間が永遠に続くことはありません。私たちの場合、それは夏に終わりました。その頃から、Pelotonでワークアウトする回数が明らかに減っていったのです。最初は、Pelotonから距離ができたことに対して、いくらでも言い訳がありました。なにしろ、私はすでにバイクに投資していたのですから。

• ケガをしていて、走れなかった
• 夏だったので、屋外でサイクリングや水泳をしていた
• 妹が家に滞在していて、ガイド付きの筋トレをやりたがっていた
• 旅行が多かった

それでも私は、何とか続けようとしました。気分を変えるために、パーソナライズされたプランをリセットしてみたこともあります。でも、実際には同じようなワークアウトを繰り返している感覚が拭えませんでした。

プランは1週間分のクラスが固定で提示される仕組みで、時間とともに進化したり調整されたりする感覚がなかったのです。結局のところ、同じルーティンの「新しいバージョン」が並んでいるだけで、パーソナライズというより、シャッフルされる静的なテンプレートのように感じ始めました。変化を求めているときほど、モチベーションを保つのが難しくなります。

目に見える進化のないパーソナライズは、停滞しているように感じられます。ユーザーが自分の成長を実感できないと、どれだけ優れたコンテンツライブラリでも、次第にマンネリに感じてしまうのです。

私はすでに最も難易度の高いワークアウトを選び、インストラクターもいろいろ試していました。トップパフォーマーではありませんでしたが（バイクでのパワー出力は、まだ伸ばせる余地がありました）、どうやって次のステップに進めばいいのかが分かりませんでした。

• ワークアウトの回数を増やす？
• 別の種類のワークアウトを選ぶ？
• パーソナライズされているなら、どこにガイダンスがあるの？

私はいったい、何を目指しているんだろう？そんな疑問が積み重なり、少しずつ、ひび割れが見え始めてきました。

教訓2：レコメンドが「なぜ自分向けなのか」を理解できるようにする

Pelotonのパーソナライズドプラン用クイズは、レコメンドを生成するという点ではとても優れていました。ただし、決定的に欠けていたステップがあります。それは、「なぜそのレコメンドが提示されたのか」を説明することです。

ユーザーが知りたいのは、何をすればいいかだけではありません。それがなぜ自分向けなのか、どんな目的に結びついているのかを理解したいのです。レコメンドの背景にある理由を説明することは、信頼とモチベーションの維持につながります。プロダクト側は、「ユーザーは考えたくないからこのサービスを使っている」と無意識に前提してしまうことがありますが、必ずしもそうではありません。面倒な部分を任せたいだけであって、「なぜ」に興味がないわけではないのです。

オンボーディングで10〜20問も質問したのであれば、偽の「考え中」ローディング画面の裏に隠れてしまってはいけません。ユーザーに、「あなたの回答はきちんと受け取られている」と示す必要があります。最低限でも、回答内容をフィードバックすること。さらに一歩進めるなら、それをどう理解し、どう解釈したのかを示し、ユーザーに確認することです。AIを活用したアプリなら、こうした体験はこれまで以上に実現しやすくなっています。

たとえば、減量アプリのNoomはオンボーディングが比較的長いですが、その途中に、ユーザーの回答から何を学んだのかを反映した小さな画面を挟み込んでいます。これによって、パーソナライズが「本物」だと感じられるのです。

Noomのオンボーディングフローにおけるパーソナライゼーション

Noomは、回答内容をもとにプロフィールへのフィードバックや、どこに注力すべきかを提示します。オンボーディングを進めるだけで、「このアプリは本当に自分のことを理解している」と感じられる設計になっています。

教訓3：短期リテンションと長期リテンションを分けて考える

月次課金ユーザーと年額課金ユーザーを比較すると、数か月で解約するユーザーと、1年・2年使ってから離れるユーザーとでは、解約理由がまったく異なることがよくあります。短期リテンションと長期リテンションは、同じゲームではありません。

まずあるのが、ユーザーにアプリを使い始めてもらう「初期アクティベーション」のフェーズです。Pelotonの場合、多くのユーザーがすでに高額なバイクを購入しているため、この段階は比較的クリアしやすくなっています。その次に来るのが、習慣化のフェーズです。しかし、長期リテンションには、それとはまったく別の要素が必要になります。ユーザーは時間とともに変化し、それに合わせてアプリも進化しなければなりません。

アプリを「使い切ってしまった」と感じたのは、今回が初めてではありません。ADHDの特性もあり、私は同じことの繰り返しにすぐ飽きてしまいます。マインドフルネス系アプリやレシピアプリでも、同じ経験をしてきました。基本をマスターし、アプリの提供価値を一通り体験すると、次のレベルを求めるようになるのです。

エンゲージメントを維持するためには、ユーザーのジョブ（jobs-to-be-done）が変化するのに合わせて、アプリも成長し、適応していく必要があります。Pelotonでは、クイズを再受験してレコメンドを更新することはできましたが、明確なレベル設計やマイルストーン、進歩している実感を与える仕組みを導入するチャンスを逃していました。ユーザーに「前に進んでいる」と感じさせる要素が欠けていたのです。

隔たり3：すべてのユーザーが恐れるメール――価格改定

この時点で、私の中にある2つの性格的特徴が真っ向から衝突していました。

1. ひとつは、「まだ9か月しか使っていないものを手放したくない」という頑固な自分。
2. もうひとつは、「新しさを求めずにはいられない」という落ち着きのない自分です。

そんなタイミングで、ついに届きました。すべてのサブスクユーザーが身構える、あのメールが。件名は「Pelotonメンバーシップに関する変更のお知らせ」。内容は、見なくてもだいたい想像がつきました。

私がPelotonの“ブーム”に乗るずっと前、実は過去の価格改定メールを「優れたコミュニケーションの好例」として紹介したことがあります。何が変わるのか、なぜ変わるのかが、クリーンで明確、そしてとても透明性の高い内容でした。2014年から2022年にかけて、ワークアウト数の増加やプログラム追加など、どれだけ価値が広がったのかを示す分かりやすい表まで用意されていました。

Pelotonの2014年版と2022年版の比較

もちろん、自分が支払う側でないときの方が、値上げメールは冷静に評価しやすいものです。

それでも私は、あのメールは今でも「よくできた価格改定の案内」だったと思っています。私はPelotonアンチではありませんし、良い価格アップデートであれば正当に評価したいタイプです。だから今回のメールも、同じレベルの分かりやすさを期待して、前向きな気持ちで開きました。ところが、理解できたどころか、逆に混乱してしまいました。こちらが、今回のPelotonの価格改定メールです。

価格改定のお知らせメール

変更のタイミングや適用方法が明確だった点は評価できます。これは意外と見落とされがちなポイントですし、少なくとも1か月前に予告してくれたので、不意打ちにはなりませんでした。

ただ今回は、以前のような分かりやすい比較表はなく、変更点がただ羅列されているだけでした。その中には、正直なところ、私自身にはあまり関係のないものも多く含まれていました。

• クラス数：「12,000本のクラス」と聞くと確かにすごそうですが、ある程度を超えると、もはや必要以上です。毎日1クラスやっても32年分ですから。
• Club Peloton：ユーザーエンゲージメントのための施策という印象が強く、私が追加料金を払う理由には感じられませんでした。
• 怪我予防：コンセプト自体は興味深いものの、「特殊外科手術」との文脈で書かれていたため、自分に関係があるのかどうかが分かりませんでした。
• Peloton IQによるパーソナライズドトレーニング：やや抽象的でした。何のことなのかはっきりせず、たぶんアプリ使用中に表示されていたいくつかの指標のことだと思うのですが、トレーニング体験が大きく変わった実感はありませんでした。

そして、メールの中で決定的に私を戸惑わせた一文がこれです。

「Breathwrk が Peloton の一部になりました。科学的根拠に基づいた呼吸エクササイズで、ストレス軽減、回復促進、集中力向上をサポートします。」

Breathwrkって何？私はアプリ内で呼吸コンテンツを見たことがありませんでしたし、そもそもそれを求めてもいませんでした。呼吸系はすでにCalmを使っていたからです。これは、ホテルに泊まったら部屋にカラオケマシンが追加されていた、みたいな感覚でした。確かにクールだし、誰かにとっては楽しいかもしれない。でも、私がそのホテルを予約した理由とはまったく関係ないし、頼んでもいないものを追加されて、しかもその分料金を上げられる——そんな違和感がありました。

教訓4：価格改定の前に、大きな新機能は必ずアプリ内で伝える

皮肉なことに、Breathwrkが何なのかを理解したのは、サブスクリプションを解約した後でした。実際には、Pelotonが提携した別アプリだったのですが、プロダクト内でそれに言及されているのを一度も見たことがなかったのです。

出典：Breathwrk

もし価格改定の前にきちんと説明されていれば、実際に使ってみたかもしれませんし、少なくとも「付加価値」として認識できたと思います。念のため受信箱を確認してみましたが、Breathwrkについて事前に案内するメールも送られていませんでした。

価格改定メールの中で新機能を強調すること自体は問題ありませんが、今回のケースは説明しすぎに感じられました。どこか「値上げの正当化」をしているような印象です。より良いアプローチは、まず価値を見せ、ユーザーに体験してもらい、その上で価格変更を伝えることです。もしユーザーがアップデートを認識しているか分からないのであれば、値上げ前に期待感を高めるためのコミュニケーションを増やすべきです。

Pelotonにとっては素晴らしいパートナーシップなのだと思いますが、十分な文脈がないまま名前を出すには、価格改定メールはあまり適した場ではなかったように感じました。

隔たり4：別のメンバーシップオプションを探す

ここで触れておかないといけないのが、Pelotonのハイブリッドなマネタイズモデルです。アプリ内サブスクリプションと物理的なハードウェアを組み合わせるのは、とても強力な戦略です。ただし、その大胆さの裏で、ユーザーの選択肢はかなり限られてしまっています。

私はすでに、バイクの機能を最大限に使うには最上位プランのサブスクリプションが必要だと気づいていました。そこに15%の値上げが加わり、「それでもバイクを使い続けられる別の選択肢はないだろうか？」と考え始めました。下位プランにダウングレードできないか、と。

答えは、はっきりと「ノー」でした。

Pelotonのサブスクリプションオプション

正当に評価すべき点として、Pelotonのアプリサブスクリプション自体には、ある程度の選択肢があります。

• 月額プランと年額プラン
• 「ベーシック」プランか、すべてのワークアウトタイプにアクセスできるプランか

少なくとも表面的には、これらの選択肢によって柔軟性は提供されています。しかし、すでに所有しているPelotonバイクを実際に使おうとすると、その柔軟性は消えてしまいます。一度最上位プランにコミットすると、気に入って使ってきた機能へのアクセスを失わずに調整できる余地は、ほとんどありません。

App One vs. App+ プラン

こうした選択肢が用意されている点自体は良いと思いましたが、All Accessサブスクリプションを使っている私にとって、実質的な選択肢は月額£45のプランしかありませんでした。まるで「バイクを持っていること」で罰せられているような感覚です。他の機器では使えるクラスもあるのに、Pelotonバイクそのものを使うためには、プレミアムな料金を支払わなければならない、そんな印象を受けました。

教訓5：ブランドに投資してくれた顧客をきちんと報いる

高価な機器を購入したユーザーを不利に扱うのではなく、ロイヤルティを維持するために、より良い価格で報いるべきです。もしPeloton以外のバイクでアプリを使うほうが高くつくとしたら、どうでしょうか。

そうなれば、バイクやトレッドミル、その他の機器を購入すること自体が、「使い続けることで報われる投資」になります。私は昔から、新規顧客には際限なく割引が提供される一方で、既存ユーザーのロイヤルティがほとんど評価されない構造に強い違和感を覚えてきました。

Pelotonがこれを実現する方法は、実はとてもシンプルだったはずです。たとえば、自社の機器でアプリを使う場合は他ブランドよりも安く設定する、あるいは既存のサブスクライバーに対しては値上げを一定期間延期する、といった形です。

教訓6：ユーザーに「選択肢がある」と感じさせる

子どもにブロッコリーを食べなさいと言ったことはありますか？ おそらく、あなたにとってもブロッコリーにとっても、あまり良い結果にはならなかったはずです。でも、5歳以下の子どもと接するときに、いとこから学んだ大切な教訓があります。それは、「選択肢があるように見せる」ことです。「ブロッコリーとニンジン、どっちを食べる？」と聞くだけで、どちらにせよ野菜は食べられ、みんなが一安心できます。

この話から得られる教訓はシンプルです。私たちは皆、たとえ事前に用意された2つの選択肢であっても、「自分で選んでいる」と感じたいのです。

Pelotonは通常のアプリサブスクリプションでは、この点をうまく実現しています。しかし、Pelotonの機器を所有しているユーザーに対しては、その感覚がありませんでした。サブスクリプションは1種類、期間も1パターンのみ。利用頻度を下げる（たとえば月4回だけ使うプラン）といった調整や、年払いで割安にするといった選択肢は用意されていませんでした。

心理学の観点から見ても、これは重要なポイントです。自己決定理論に関する研究では、「自律性」はユーザー満足度を左右する主要な要因だとされています。価格やプロダクトの制約によってユーザーが「縛られている」と感じた瞬間、たとえプロダクト自体が変わっていなくても、知覚される価値は急激に下がります。月額課金は企業側にとっては単価を上げやすい一方で、ユーザーにとっては「やめる」判断もしやすくなるのです。

隔たり5：そして、私はサブスクリプションを解約した

私はバイクに小さく謝りつつ、「月額プランなら、恋しくなったらいつでも再開できるはず」と思いながら解約手続きを進めました。

ところが、ここで少しややこしいことが起こります。スマホでログインしてみると……サブスクリプションが表示されない。ウェブサイトを確認しても……やはり何も出てこない。混乱した私は、カスタマーサポートに連絡しました。

第一印象は、とても良かったです。面倒なやり取りもなく、問題もなし。更新日の数日前でしたが、サブスクリプションはすぐに停止されました。この点については、Pelotonを本気で称賛したいです。解約をほぼ不可能にしているブランドも、私はいくつも知っていますから。名前は挙げませんが……今回は。

サブスクリプションをキャンセルするためのチャット会話

ただ、その後に私は「あるもの」を待っていました…なぜ解約したのか、理由を聞かれること。 フィードバックを求められること。

しかし、それは一切ありませんでした。もしかしたら、後で届く確認メールにアンケートが含まれているのかもしれない、そう思いました。

確認メールは届きました……それでも、アンケートはなし。

まるで、心のこもった別れのスピーチをしたのに、相手からは肩をすくめられただけ、という感覚でした。「なぜ終わりにするのか、知りたくないの？」「他に誰かいるのか、気にならないの？」と聞きたくなるような。（ちなみに言っておくと、Pelotonを裏切ったことは一度もありません。）

サブスクリプションのキャンセル確認

全体として見ると、Pelotonがうまくやっていた点も多くあります。

• アカウントが解約されたことが非常に明確に確認できる（余計な装飾やノイズがない）
• 罪悪感を煽らない表現で、理解を示している
• 変更がいつから適用されるのかが明確
• 再開やプラン変更の方法が分かりやすい

ただし、見逃された大きなチャンスがありました。それは、会話の中でも、メールの中でも、一度も「なぜ解約したのか」を聞かれなかったことです。これは、ブランドにとって非常に価値のあるフィードバックだったはずです。

教訓7：解約体験は「気持ちよく」終われるものにする

解約を隠したり、手続きを複雑にしたりしても、良い結果につながることはありません。最初に自分のアカウント上でサブスクリプションが表示されなかった理由は正直分かりませんが、おそらくデバイス間の不具合だったのでしょう。ただ、サポートに連絡してからは、すべてが丁寧に対応され、わずか2分で解約できました。

一部のユーザーはアプリストア経由で直接解約するかもしれませんが、Webでもアプリ内サブスクリプションでも、分かりやすくシンプルな解約フローを用意することが重要です。

教訓8：解約メールは「クリーン」にまとめる

良い解約確認メールには、次の内容がきちんと含まれているべきです。

• サブスクリプションが解約されたことの明確な確認
• アカウントの利用がいつまで有効か
• これまで利用してくれたことへの感謝
• まだ聞いていない場合は、フィードバックを提供できる導線

文章は短く、簡潔にまとめましょう。「行かないで！」と叫ぶようなパニック感は不要です。罪悪感をあおる表現はプロフェッショナルではありませんし、効果もありません。

さて、そのフィードバックについてですが…

隔たり6：ついにフィードバック依頼が届いた！

最終的にはアンケートが届いたのですが、それが「解約したから」送られてきたものかどうかは、正直なところ確信が持てません。内容は Net Promoter Score（NPS）アンケートでした。

NPSアンケート調査のemail

解約直後というタイミングは興味深いですよね。とはいえ、とりあえず答えてみることにしました。

質問に回答していくうちに、このタイミングはおそらく意図的ではなかったのだろう、と感じました。というのも、このアンケートは、私のサブスクリプションがすでに解約されていることをまったく把握していないようだったからです。

フィードバック調査の質問

たとえば、「Peloton のメンバーシップに満足している」という設問に対して、「メンバーシップを持っていない」という選択肢がなかったのです。

Peloton にとっての私は、SNSですべてブロックされるような“こじれた元恋人”ではなく、まだ友だち関係が続いていて、可能性も残っている元恋人のような立場だったと思います。でも、さすがにそれでも、元恋人に次のような質問はしませんよね。

• 私はあなたのニーズに合わせて進化している？
• 私は友人／パートナーとして価値がある？

正直、ちょっと……違和感がありました。もし私が本当に怒り心頭の元恋人だったら、

1. 正直、フィードバックなんて送らなかったと思います
2. むしろ、さらに苛立っていたはずです

それでも私は、社交辞令も含めて「大人の対応」をしながら、できる限り質問に答えました。「すでに解約した」という事実を選択肢で示せないにもかかわらず、です。

とはいえ、Peloton がきちんとやっていた点もありました。それは、「ユーザーが告知を見たかどうか」を確認していたことです。

どの機能を見たか尋ねる

少し唐突な質問ではありましたが、アプリが「ユーザーは当然すべて理解しているはず」と思い込んでしまうケースは少なくありません。実際、私自身も、3週間毎日使っていたアプリの中で、つい最近になって初めて気づいた主要機能がありました…。

教訓9：解約後専用のフィードバックフォームを用意する

解約理由を把握するためには、短く、そして理想的には「解約したその瞬間」に紐づいたフィードバックフォームを用意することが重要です。ユーザーが離脱する理由を正確に知ることができます。効果的な解約アンケートのベストプラクティスについては、こちらも参考になります。

Peloton を少し擁護すると（前にも言いましたが、私は“穏やかな元恋人”タイプなので）、解約の翌日にアンケートは送られてきましたし、システムの反映には72時間かかる、という注記もありました。もしかすると、その更新期間中にたまたま NPS アンケートが当たってしまっただけなのかもしれません。とはいえ……実際の「解約理由を聞くためのアンケート」は、いまだに届いていません。

クールダウン：Peloton解約後の生活

一番意外だったのは、この体験がとても感情的なものだったことです。私は Peloton を中心にした「習慣」を作っていました。インストラクター、プレイリスト、自分のために時間を取っているという感覚。こうした感情的なつながりは、どんな割引よりも長く私をサブスクに留めていました。けれど、そのつながりが薄れてしまった瞬間、価格改定は「解約を早める引き金」にすぎなくなりました。

これは他のアプリにとっても重要な示唆です。リテンションは単なる「利便性」の問題ではなく、「アイデンティティ」や「所属感」の問題でもあります。ユーザーが「見られていない」「前に進んでいない」と感じ始めた瞬間、アプリを開かなくなってしまうのです。

解約した理由は、運動をやめたからではありません。私は今も週6日トレーニングするフィットネス中毒です。解約後は、別のアプリを試していますが、これがとても気に入っています。自分をきちんと追い込んでくれて、重量や回数を記録し、目に見える成長を示してくれます。

ただし、そのアプリにはバイクのワークアウトはありません。そして、今もワークアウトスペースに置かれている Peloton のバイクは、夜が長くなり雨の日が増えるにつれて、静かに私を呼び戻してきます。

サブスクリプションなしで、久しぶりに使ってみました。短い無料クラスを2本受けただけで、懐かしさが一気に込み上げてきました。まるで、昔よく通っていたカフェで元恋人に偶然会ったような感覚です。

無料体験クラス

Peloton の話は、フィットネスアプリに限ったものではありません。すべてのサブスクリプションアプリが、同じ課題に直面しています。それは「ユーザーと一緒に進化し続けられるか」という点です。瞑想アプリでも、語学学習アプリでも、ゲームでも、学べる教訓は共通しています。

1. ユーザーがすぐに価値を感じられるようにする
2. パーソナライズがどのように機能しているかを説明する
3. ユーザーの目標の変化に合わせてプロダクトも進化させる
4. 価格を上げる前に、新たな価値をきちんと伝える
5. ロイヤルなユーザーを罰するのではなく、報いる
6. 柔軟でフェアな価格オプションを用意する
7. 解約はシンプルで、敬意ある体験にする
8. 明確で思いやりのある確認メールを送る
9. タイムリーで適切なフィードバックを収集する

ユーザーが「理解されている」と感じ、かつ「自分でコントロールできている」と思えたとき、リテンションは自然とついてきます。

今のところ、それだけでは私を引き戻すには至っていません。でも、バイクを手放す気にもなれないのです。もしかしたら、いつかまた、この高価な関係をうまく続ける方法が見つかるのかもしれません…

施行日以降、日本市場において以下の行為が禁止されました。

• アプリ内でWeb決済ページへのリンクを制限すること
• アプリ内で価格やキャンペーン情報の表示を禁止すること
• 外部決済を理由に審査を遅らせたり、検索順位を下げること </aside>

つまり、これまでは実質禁止されていた外部決済への誘導が解禁され、やり方次第では手数料を大幅に削減できる道が開けています。本投稿では、スマホ新法の要点と、アプリ事業者が今すぐ押さえるべき実務上のポイントを整理します。

スマホ新法早見表　ー施行前 vs 施行後の手数料比較

Apple Store 参照元：Apple Inc.

Google Play 参照元：Play Console ヘルプ

1. 条件により表記の手数料より減少する場合があります
2. Apple IAPもしくはGoogle Play Billingのこと
3. 外部決済SDK等
4. App → Webで決済のこと

外部決済を採用することで手数料の大幅減額が見込めるように

Apple（日本）

• アプリ内決済“最大30%”⇨ 最大26%
• リンクアウト型の外部決済は原則不可⇨可能に。手数料は 15%（条件で10%）。

Google（日本）

• アプリ内決済“の標準手数料は 30%据え置き
• リンクアウト型の外部決済は原則不可⇨可能に。手数料は 20%（条件で10%）

スマホ新法の要点

スマホ新法によりできるようになること

1. アプリ内からWeb決済への誘導

「Webで購入する」などのボタンを設置し、ブラウザでWeb決済を完了させる導線が可能になります。

2. アプリ内での価格・キャンペーン表示

Web上で提供するプランの価格や割引情報を、アプリ内で表示することが認められます。

3. ストア決済と外部決済の併存

従来のアプリ内課金（IAP）を残しつつ、外部決済を主要な購入導線として設計することも選択肢に入ります。

想定される決済フロー

施行後、以下のパターンが新たな選択肢になります。

モバイルアプリ事業者はこれからどうしていくべきか？

外部決済を前提とした設計への移行

スマホ新法の施行により、アプリ内決済（IAP）よりも外部決済・Web決済へ誘導する方が手数料面で有利になりました。これに伴い、従来の**「アプリ内決済を前提とした設計」から「外部決済を主軸とした設計」への見直し**が必要になります。

以下、実務上のポイントを整理します。

1. 課金・権限管理の設計変更

従来はAppleやGoogleのレシートを「購入の証明」として扱い、それを元に利用権限を付与する設計が一般的でした。外部決済を主軸にする場合、この前提が変わります。

購入証跡の扱い

• ストアのレシートは「購入経路のひとつ」として扱う
• 利用権限の付与は自社バックエンドで判断する
• IAP・Web決済どちらの購入でも、同一の権限IDを付与する

アカウント管理の軸

• Apple ID・Google IDではなく、アプリ内アカウント（メールアドレス等）を軸に管理する
• 端末変更、OS変更、Web→アプリの移行に対応できる構造にする
• 将来的なマルチプラットフォーム展開の土台になる

2. Web決済体験の設計

Web決済への誘導が増えると、Webストアの使いやすさが収益に直結します。特に日本市場では、違和感のない体験設計が重要になります。

UI設計

• スマホ縦画面・片手操作を前提にする
• 入力項目は最小限に抑え、決済完了までのステップを短くする
• Safari・Chrome両対応、ブラウザの「戻る」操作で破綻しない設計にする

価格・プラン表示

• 税込価格、課金周期、解約条件を明示する
• アプリ内購入との違いがユーザーに伝わる説明を入れる

決済後の体験

• 決済完了後、サーバー側で即座に利用権限を付与する
• アプリに戻った際に自動で同期される仕組みにする
• 「支払ったのに使えない」状態が発生しない設計にする

3. 計測項目の整備

外部決済の導線が増えると、どこで離脱が起きているかを把握する重要性が増します。以下の指標は最低限追えるようにしておく必要があります。

4. 地域別・段階的な展開

スマホ新法は日本国内の法律であり、他国のストア規約とは状況が異なります。一斉に切り替えるのではなく、段階的に展開できる設計が必要です。

地域制御

• まず日本のみでWeb決済導線を有効化する
• 他国のストア規約リスクを回避する

段階展開

• ユーザー属性、OS、アプリバージョン単位でON/OFFを制御できるようにする
• 問題発生時に即座にロールバックできる構造にする

サーバー側制御

• アプリのアップデートなしで導線を変更できるようにする
• 審査中でも挙動を制御可能にする
• 法改正やガイドライン変更への即応性を確保する

手数料を実質0%にする方法

ユーザーがアプリ内のリンクを経由せず、自らWebストアにたどり着いて決済を完了すれば、プラットフォームへの手数料は発生しません。以下のような方法が検討できます。

アプリ内での告知（リンクなし）

• 「『アプリ名 公式ストア』で検索」などのテキスト表示
• 「Webストアならお得に購入できます」といった案内文
• リンクが設置されていないバナーやポップアップ

アプリ外からの誘導

• メールマガジンでWebストアへ誘導
• SNS（X、LINE、Instagram等）での告知
• プッシュ通知から直接Webストアへ遷移（アプリを経由しない導線）

外部決済システム導入における課題と解決策

外部決済の導入が手数料削減に有効であることは明らかです。しかし、実際に導入しようとすると、いくつかの現実的なハードルに直面します。

課題1：実装コストと運用リスクが高い

Web決済を自前で構築する場合、以下のような開発・運用が必要になります。

• 決済UI（Checkout画面）の構築
• Stripe等の決済サービス連携
• サブスクリプション管理システム
• Web購入→アプリへの反映処理
• 再購読・復元機能
• 不正決済・二重課金・例外処理
• 分析基盤・Webhook連携

これらはすべてアプリ内決済とは別のシステムとして構築する必要があり、エンジニア工数・バグリスク・将来の保守コストを考えると、導入のハードルは決して低くありません。

課題2：ストアガイドライン違反によるリジェクトリスク

外部決済で最も怖いのは、意図せずガイドラインに抵触してしまうことです。

• 表示ルール違反
• 不適切な誘導と判断される
• 将来のルール変更への対応漏れ

リジェクトされれば、せっかく構築した決済導線が使えなくなり、結果的に購入機会を失うことになります。

課題3：売上データと顧客状態の分断

自前でWeb決済を導入すると、以下のようにデータが分断されがちです。

「誰がいくら払っているのか」「どの導線からの購入か」が把握しづらくなり、LTV分析やマーケティング施策の効果測定に支障をきたします

3つの課題を解決する「Web Purchase Button」

これらの課題をまとめて解決できるのが、RevenueCatが提供するモバイルアプリ向けWeb決済ソリューション「Web Purchase Button」 です。

RevenueCatは、モバイルアプリとWebをまたいだサブスクリプション管理を前提に設計されたインフラを提供しています。

日本でWeb決済を本格的に導入する際には、モバイルに最適化されたWeb購入体験と、購入直後からアプリを利用できる仕組みが重要になります。

Web Purchase Buttonが選ばれる3つの理由

課題1：実装・運用コストが高い → 開発負担を大幅に軽減

Web Checkoutの画面はRevenueCatがホスティングしているため、自前で決済UIを構築する必要がありません。決済完了からアプリへの反映処理もSDKが吸収してくれるので、IAP＋Web決済という二重システムを自社で抱え込まずに済みます。

課題2：ガイドライン違反のリスク → ストア準拠を前提とした設計

Apple・Googleのガイドラインに準拠することを前提に設計されています。国やOSごとの出し分けにも対応しており、Web商品が設定されていない場合は自動的にIAPへフォールバックする仕組みも標準で備わっています。

課題3：売上・顧客データの分断 → 既存の分析基盤をそのまま活用

Web経由の購入もIAP経由の購入も、RevenueCat上で統合して管理できます。すでにお使いのWebhook連携・LTV分析・解約率の計測・権限管理の仕組みをそのまま活かせるため、「Web決済を入れたら分析が壊れた」という事態を防げます。

開発者・事業者にとっての本質的な価値

Web Purchase Buttonの価値は「Web決済ができること」ではありません。**「導入コストを最小化しながら、手数料削減のメリットを最大化できること」**にあります。また、以下のような「売上に効くか分からない施策」を小さく安全に試せる環境が手に入ります。これはCFO・PM・法務との合意コストを下げるという意味でも大きなメリットです。

Web Purchase Buttonで可能な施作例

• 日本のみWeb決済を有効化
• 高LTVユーザーだけWeb誘導
• 割引プラン・年額プランだけWebで提供
• A/Bテスト（アプリ更新なし）

導入方法や料金体系など、詳しくは Web Purchase Button 公式ページ をご覧ください。

よくある質問（スマホ新法・外部決済）

Q. スマホ新法はいつから適用されますか？

2025年12月18日に全面施行されました。この日以降、Apple・Googleは日本市場において新しいガイドラインに従う義務があります。

Q. 自社アプリも対象になりますか？

デジタルコンテンツやサブスクリプションを販売しているアプリであれば対象になります。物販など物理的な商品の販売は、もともとIAPの対象外のため影響はありません。

Q. AppleとGoogle、両方に適用されますか？

はい。スマホ新法はApple・Google両社が対象です。ただし、手数料率や適用条件は各社で異なるため、それぞれのガイドラインを確認する必要があります。

Q. 外部決済を導入すれば必ず手数料は下がりますか？

導入方法によります。アプリ内にリンクを設置する場合、Appleは15%、Googleは20%の手数料が発生します。

Q. アプリ内で「Webストアで購入できます」と書くだけで大丈夫ですか？

リンクを設置しないテキストでの告知であれば、手数料は発生しません。「『アプリ名 公式ストア』で検索」のような案内文は認められています。

Q. リンクを設置した場合、手数料はいつまでかかりますか？

リンクタップ後、Appleは7日間、Googleは24時間以内のWebストア購入が手数料の対象になります。この期間を過ぎた取引には手数料はかかりません。

Q. 外部決済を導入すると審査で不利になりますか？

スマホ新法では、外部決済を理由に審査を遅らせたり、検索順位を下げたりする行為は禁止されています。ただし、セキュリティや未成年者保護を理由とした一定の制約は認められる可能性があります。

Q. 小規模事業者向けの優遇はありますか？

あります。小規模事業者の場合、Appleのリンクアウト手数料は10%、Googleも10%に軽減されます。適用条件は各社のガイドラインで確認してください。

Q. 海外展開しているアプリはどう対応すべきですか？

スマホ新法は日本国内の法律です。他国では従来のストア規約が適用されるため、地域ごとに導線を切り替えられる設計が必要です。まず日本のみでWeb決済を有効化し、段階的に展開することが推奨されます。

Q. すぐに対応しないとペナルティはありますか？

事業者側にペナルティはありません。スマホ新法はApple・Googleに対する規制であり、アプリ事業者に対応を義務付けるものではありません。ただし、対応が遅れるほど手数料削減の機会を逃すことになります。

Q. 既存のIAP課金ユーザーはどうなりますか？

既存ユーザーのIAP契約はそのまま継続されます。外部決済への移行を促す場合は、更新タイミングでの案内や、Webストアでのお得なプラン提示などを検討してください。

幸いなことに、私たちはそうではありません。そして、そろそろ誰かがこうした疑問をきちんと解き明かす時期に来ているはずです。

たとえば、こんな疑問です。

• 自分のアプリはいくらの価値があるのか？
• 買収後も自分は残る必要があるのか？
• 買収後も残ることはできるのか？
• 買い手はオーガニック流入と広告流入、どちらを好むのか？
• リテンションはどれくらい良ければ十分なのか？
• マルチプライヤーとは何で、どうすればそれを得られるのか？

これらの疑問（そして他にもいくつか）に答えることが、この記事の目的です。現在インターネット上にあるアプリ買収に関する情報の多くは、情報が古かったり、一般論に終始していたり、実際にアプリを買ったことのない人によるものだったりします。

さまざまな理由から、多くの買い手は自分たちの考えを公にしません。しかし、就職面接の準備が以前より透明になってきているように、創業者には信頼できる買収ガイダンスが与えられるべきだと私たちは考えています。そこで私たちは、情報の出どころそのものに直接あたりました。

これは、この業界を形づくっている当事者――買い手本人たちから聞いた、アプリ買収市場のリアルな現状です。

Exitを検討している創業者はもちろん、将来を見据えて準備を始めたい人にとっても、この内容は、インタビュー動画を見たり、ポッドキャストを聞いたり、1対1で話を聞いたりする時間の10倍の価値があると断言します。

取材したアプリバイヤーたち

Evelin Herrera氏は、EHVM App Capital の創業者であり、高成長アプリの創業者とともにExitや戦略的買収を支援する、モバイルアプリ専門のM&Aファームを率いています。Evelin氏は日々、創業者と買い手の双方と直接向き合い、実際のディールを成立させています。それならば、「買い手が何を求めているのか」を知るうえで、これ以上ふさわしい人物はいないでしょう。

彼女は自身のネットワークを徹底的にたどり、評価額から買収後の創業者の立ち位置に至るまで、国際的に活躍する10人の経験豊富な買い手にインタビューを行いました。私たちはその内容をもとに、これまで整理できていなかった疑問や、聞きたくても聞けなかった質問への答えを丁寧にひも解いていきます。

Evelin氏が話を聞いたのは、次の方々です。

1. 🇺🇸 Dan Novaes：Mode Mobile 共同創業者 / CEO
2. 🇫🇷 Guillaume Larrieu：Quiet 事業開発担当VP
3. 🇨🇦 Jon Walsh：Kodeon マネージングパートナー / Push Capital パートナー
4. 🇸🇰 Matej Lancaric：独立系ユーザー獲得・マーケティングコンサルタント
5. 🇪🇸 Michael McPhee：Leadtech Group 事業開発・M&A責任者
6. 🇵🇱 Paweł Pochowski：Nova Sphere 事業開発責任者
7. 🇬🇧 Ryan Thorpe：Reflective Apps グロース責任者
8. 🇺🇸 Tom Kenney：LOYAL 共同創業者 / CEO
9. 🇹🇷 Yalçın Özdemir：AppNation 創業者 / CEO
10. 🇺🇸 Zach Tobin：Product Growth LLC 創業者

彼らは現在進行形で、アプリを買収し、統合し、スケールさせている人たちです。対象となるアプリのカテゴリも、ゲーム、ヘルス＆フィットネス、生産性、ユーティリティ、ライフスタイルまで多岐にわたります。それでは、彼らの世界を少し覗いてみましょう。

要約：アプリ買収のリアルな現状（実際に「お金を出している人たち」の視点から）

要点だけを素早く押さえたい方のために、ここでは結論をまとめています。10時間以上に及ぶインタビューから、「アプリを売却したい」と考えているなら知っておくべき重要ポイントを抜粋しました。

• 大半の買い手は、買収後も元のチーム（創業者を含む）が残ることを好む：プロダクトへの深い理解、素早い改善サイクル、遅延なくスケールできる点が評価されるためです。
• アプリの評価額の起点は、EBITDAの3〜5倍が一般的です。 これは、アプリが2年以上運用されており、かつサブスクユーザーのリテンションが4か月以上ある場合に当てはまります。
• 戦略的買収（純粋な財務目的ではない買収）も存在しますが、数は多くありません。実現には、かなり綿密なマッチングが必要になります。
• 多くの企業は100%キャッシュの一括支払いを標準としていますが、アーンアウトや株式など、別の形態を提示するケースもあります。これらは最終的な評価額を上げることも下げることもあるため、慎重な検討が必要です。
• オーガニック流入を好む買い手もいれば、有料ユーザー獲得（UA）を重視する買い手もいます。オーガニックは安定した成長を示し、有料UAはスケールを可能にします。指標の強さを示し、アルゴリズム依存のリスクを下げるためにも、50/50のバランスを目指すのが一つの目安です。
• そもそも、なぜ買い手はアプリを買収するのか？50万ドル未満の買収でも、12〜18か月で売上を倍増させた事例があり、金銭的な魅力は非常に高いからです。また、多くの買収者は、ゼロから作るよりも「買う」ことで、リスクを抑え、成長を加速し、すでにプロダクトマーケットフィット （PMF）が証明されたアプリからスタートしたいと考えています。
• 買収における最大の「グリーンフラグ」は以下のとおり：高いリテンション、低い運用コスト、オーガニックによる複利的成長、ドメインオーソリティ、明確なPMF、そして市場の勢い。

アプリの評価額を本当に左右するものとは？そして「マルチプル」の真実

開発者がまず最初に抱く疑問は、ほぼ例外なくこれです。「自分のアプリはいくらで売れるのか？」しかし、アプリの評価（バリュエーション）は簡単ではありません。将来の成長可能性、トレンドよりも継続性（スティッキーさ）、技術的な参入障壁（存在する場合）、そして他にも多くの要素を反映させる必要があります。

この問いの核心に最も正確に答えられるのは、実際に資金を投じている人たちの声を聞くことです。ただし本題に入る前に、まずは基本となる2つの概念を整理しておきましょう。買収の種類とマルチプルです。

戦略的買収と財務的買収

意外に思われるかもしれませんが、すべてのアプリが「お金儲け」だけを目的に買われているわけではありません。実際には、多くの買収は戦略的判断、財務的動機、そして個人的な関心や情熱が混ざり合ったものです。とはいえ、大きく分けると買収には2つのタイプがあります。それが、財務的買収と戦略的買収です。

財務的買収では、評価額は純粋にその会社の財務パフォーマンスに基づいて決まります。

「財務指標が最優先です。ただし、私たちが構築しているものと戦略的に一致する場合は、そこも考慮します。」— Dan Novaes（Mode Mobile 共同創業者兼CEO）

戦略的買収では、そのアプリがビジネスにもたらす戦略的価値が重視されます。たとえば、アプリポートフォリオの空白を埋める存在であるか、特定市場で非常に強い価値を持っているか、といった点です。このタイプの買収は、プレミアム価格が付くことも珍しくありません。

「私たちは、生活の質を向上させる高品質なアプリのポートフォリオを構築するという戦略を前進させてくれる買収案件を常に探しています。その上で、複数の要素をもとに評価額を決定しています。」— Jon Walsh（Kodeon マネージングパートナー／Push Capital パートナー）

マルチプルは買収における決定要因なのか？

モバイルアプリの買収の世界では、「マルチプル」という言葉があちこちで飛び交います。もちろん、それに付随する数々の略語とともに、です。

簡単に言うと、マルチプルとは、買い手が中核となる財務指標をもとに事業価値を見積もるためのシンプルな方法です。「あなたのアプリは、稼いでいる金額の〇倍の価値がある」と評価する考え方であり、言い換えれば「将来どれだけ稼げるか」を織り込む指標でもあります。

多くの買収では、月次経常収益（MRR）、年次経常収益（ARR）、または EBITDA を基準指標として使います。マルチプルとは、その1単位あたりの価格です。たとえば、あるアプリが年間 10 万ドルを稼いでおり、その市場では「収益 1 ドルあたり 3〜5 ドル」が一般的な相場だとすると、そのアプリの評価額は 30 万〜50 万ドルになります。買い手がこれらの指標を基準に価値を固定するのは、規律を保ち、過剰な買い付けリスクを抑えるためです。

「評価額は常にマルチプルを基準に決まります。規律を欠けば、過払いになり、その分だけ成功が難しくなります。評価は、買い手を含むすべての関係者にとって win-win である必要があります。」— Tom Kenney（LOYAL 共同創業者兼 CEO）

多くの創業者はマルチプルに強くこだわり、それが買収のすべてだと思いがちです。しかし、Evelin がすべての買い手から聞いた実際の答えは、マルチプルはあくまで出発点であり、絶対的なルールではないというものでした。本当の評価額は、リテンション、スケーラビリティ、成長性、チーム構成など、さまざまな要因（これについてはこの後詳しく触れます）によって上下します。

たとえば AppNation 創業者兼 CEO の Yalçın Özdemir氏は、適切なアプリであれば評価額は柔軟に調整され得ると説明しています。

「私たちの強みを活かして、短期間で収益を大きく伸ばせると判断した場合には、評価額を引き上げることも厭いません。そうしたケースでは、創業者が築いたものと、私たちが提供できる価値の“噛み合い”そのものに本当の価値があると考えています。」— Yalçın Özdemir（AppNation 創業者兼 CEO）

マルチプルだけでは語れない評価の実態

Yalçın氏が述べているとおり、マルチプルは買い手の関心を左右する唯一の決定要因ではありません。より大きな全体像を見ることが重要であり、特にゲームのような一部の業界では、マルチプルへの依存度が比較的低い場合もあります。

「マルチプルは有用なツールではありますが、それだけに頼っているわけではありませんし、常に最も正確な指標というわけでもありません。たとえばゲームでは、ユーザー獲得への投資を抑えた途端に収益が落ちることがよくあります。そうしたケースでは、直近 12〜24 か月の実績だけに基づいた評価では、本来のポテンシャルを反映できないことがあります。」— Paweł Pochowski（Nova Sphere 事業開発責任者）

また、アーリーステージのアプリや新興ニッチ領域のプロダクトも、マルチプルだけでは正しく評価されにくいことがあります。Paweł氏は、こうしたカテゴリでは、まだパフォーマンス指標によって価値を十分に証明できていない場合があると説明しています。「こうしたケースでは、過去データだけで判断するのではなく、市場トレンド、戦略的な適合性、成長ポテンシャルも含めて評価します。強い勢いや独自のポジショニングが見られれば、標準を上回る評価額を提示することにも前向きです。」

「まずは財務パフォーマンスを起点にし、その後で各種パフォーマンス指標を深掘りしながら、アプリのこれまでの歩み、現在の市場での立ち位置、そして現ユーザー・過去ユーザーにとっての価値を理解するための包括的なモデルを構築します。」— Jon Walsh（Kodeon マネージングパートナー／Push Capital パートナー）

さらに Jon Walsh氏は、新しいアプリを評価する際に、自社の既存アプリポートフォリオとの関係性を考慮する買い手が多いことにも言及しています。「私たちは、そのアプリが自社ポートフォリオ全体にどれだけ補完的かを考えたうえで、最終的に支払える価格を判断します。全体戦略を加速させる資産であれば、より高いマルチプルを支払うこともありますが、あくまで財務規律に基づいた範囲内で行います。」

ハイマルチプル帯に入るための考え方

では、あなたのアプリが“あの”ハイマルチプル帯に入るための秘訣は何なのでしょうか。

一般的に、評価額は EBITDA の 3〜5 倍といったマルチプルレンジで語られます。アプリごとに評価を上下させる要因はさまざまであり、ごく一部の買い手は、その自社アプリポートフォリオにとって「より大きな価値」を解き放つと判断した場合、標準的なレンジを超える評価を行うこともあります。

その理由として挙げられるのは、たとえば次のような要素です。

• クロスセルの可能性
• 特定カテゴリにおける専門性
• ユーザー層の重なり
• ターゲット市場における実証済みの PMF
• 自社では持っていない機能セット

だからこそ、創業者は複数の買い手と話すべきなのです。最も高い評価額を提示してくれるのは、必ずしも「収益マルチプルが最も高い買い手」ではなく、あなたのアプリと自社ポートフォリオとの間に最大のシナジーを見出した買い手であることが多いからです。

Evelin が話を聞いたすべての買い手に共通していたのは、非常に明確なパターンでした。マルチプルレンジの上限を狙うのであれば、次の 3 つが不可欠です。

1. 強いリテンション：これは疑いようのないプロダクトマーケットフィットを示すシグナルであり、長期的なキャッシュフローを予測するうえで最も重要な指標です。
2. 低い運用負荷とクリーンなアーキテクチャ：買い手は、できるだけ速く、そして簡単にスケールしたいと考えています。ドキュメントの欠如、分析データの不整合、整理されていないコードがある状態では、それは実現できません。
3. オーガニック、もしくは複利的に成長するディストリビューション：これは効率的な成長エンジンを意味します。未開拓市場、機能拡張の明確な余地、カテゴリ初期段階でのトラクションなどが該当します。

大したことは求めていないですよね？

まとめ：評価額とマルチプルについて

マルチプルは理解しやすく、アプリの価値を素早く把握するための指標として有用ですが、それ以上に重要なのは「適切な買い手を見つけること」です。あなたのアプリが、買い手の目標達成をより早められるものであったり、戦略やポートフォリオとの明確なフィットがあったり、成長の勢いを持っている場合、より高いマルチプルが提示される可能性は大きく高まります。

同様に、買い手が「自分たちがどこで価値を生み出せるか」を明確に描けるほど、そのアプリは魅力的になり、結果として評価額も上がります。初期の成長軌道やカテゴリ全体の動きも、財務指標とほぼ同じくらい評価に影響します。とはいえ、忘れてはならないのは財務的な規律が最終的には重視されるという点です。ほとんどの買い手は EBITDA や MRR のマルチプルを評価の軸に据えており、過度に大きな財務リスクを取ることはありません。

アプリ買収における買い手のウィッシュリスト：買収前に創業者が最適化すべきポイント

マルチプルはオファーを得るうえで確かに重要な要素ですが、買い手が実際にディールを前に進めるかどうかを左右する要因は、それだけではありません。Evelin は、買い手に「アプリを見るうえで最も重視する上位3つのポイント」を尋ねました。では、全員が同じ3つを挙げたでしょうか？

答えは――ゼロです。つまり、万人に当てはまる正解は存在しません。

とはいえ、マルチプルに影響を与えるシグナルと同様に、ほぼすべての買い手が共通して重視していた要素は存在しました。とくに多く挙げられたのが、リテンション、そして「定着性（sticky）のあるユーザー」を持っているかどうかです。

「最終的には、買収価格は低いほうがいいし、投資回収が早いほうがいい。でも私たちは、数多くの要素と、それらがどう関係しているかを見ています」— Ryan Thorpe（Reflective Apps／Director of Growth）

買い手が注目している主なポイントは次のとおりです。

• リテンション
• オーガニック成長
• マネタイズの余地
• 評価額と ROI
• 技術インフラ
• プロダクトマーケットフィット（PMF）
• 業界への理解度、と／または戦略・ポートフォリオとの適合性
• 市場の勢い（マーケットモメンタム）

では、それぞれを詳しく見ていきましょう。

ほぼすべての買い手に共通しているのは、「純粋な売上だけ」を評価軸にしているわけではない、という点です。高いマルチプルや「欲しい」と思われるアプリは、継続率、ディストリビューション、マネタイズ、そして買い手との相性といった複数の要素がうまく噛み合ったところから生まれます。

何よりも重要なのは、そのアプリが明確なオーディエンスと市場の中で、自分の居場所を見つけているかどうかです。もしそれが、買い手にとっての戦略的なギャップやポートフォリオ上の空白を埋める存在であれば、なおさら評価は高まります。繰り返し出てきた共通認識は、「このアプリはすでにうまく機能している。だが、私たちならもっと良くできる」というものでした。

ここまでで、マルチプルが必ずしもすべてを語るわけではないこと、そして買い手が何を見ているのかは見えてきたはずです。それでは次に、アプリが評価される場面で、こうしたポイントをどのように示せばよいのかを、もう少し踏み込んで見ていきましょう。

買い手に「健全なアプリ」だと伝えるリテンションのシグナル

リテンションは、多くの買い手にとって極めて重要な指標です。それも当然で、ビジネスの成功を見込んで数年分の対価を先に支払うのであれば、有料ユーザーが長く残り続けてくれることを期待します。実際、買い手は一貫してリテンションを評価額を左右する上位3つの要因のひとつに挙げています。では、創業者はどのようにすれば、定着性を明確に示し、リスクを低く見せるリテンションのストーリーを用意できるのでしょうか。

Evelin氏が行ったヒアリングをもとにすると、リテンションのシグナルは大きく次の3つに分けられます。

1. リテンションがカテゴリのベンチマークと整合していること：買い手が見ているのは、全アプリ共通の数値ではありません。カテゴリごとの標準、価格帯、サブスクリプション期間、利用頻度などを踏まえた相対評価です。

「そのカテゴリで最大のプレイヤーは誰か？どれくらいの売上を上げているのか？どんなUAチャネルを使っているのか？それらが、私が検討しているアプリのベンチマークになります。これらすべてを意思決定マトリクスに組み込みます」— Matej Lancaric（独立系ユーザー獲得・マーケティングコンサルタント）

State of Subscription Appsレポートを見ると、カテゴリによってリテンションがどれほど大きく変わるかが分かります。自分の業界を理解し、競合が何をしているのか、そして自分のアプリがどの位置にいるのかを把握しておくことが重要です。

2. 初期チャーンの背景が明確に説明できること：サブスクリプションの約30％が初月で解約されることを考えると、チャーンがあるからといって即座に「不採用」になるわけではありません。ただし、なぜチャーンが起きたのかを理解し、それをもとに改善してきたことを示す必要があります。チャーンを説明できれば、評価額を守ることができます。

3. 時間とともに安定するコホートが存在すること：たとえ全体のチャーン率が高くても、最も重要な長期ユーザーが定着していることを示す証拠を集めることは可能です。異なるサブスクリプションプラン、ユーザーセグメント、流入元ごとに、リテンションを横断的に捉えた全体像を作りましょう。

ここで、RevenueCat のダッシュボードを見てリテンション率に不安を感じている人は、少し待ってください。「強いリテンション」とみなされる基準は、買い手によって大きく異なります。

Reflective Apps の Growth Director である Ryan Thorpe氏は次のように述べています。 「年額サブスクリプションで、25％程度のものもあれば、60％に達するものもあります。何を『健全』と定義するか、そしてどんなサブスクリプションモデルかによって大きく変わります。」

一方で、Kodeon の Managing Partner であり Push Capital のパートナーでもある Jon Walsh氏はこう語っています。「一般的には、年額サブスクリプションのリテンションは60〜70％がまずまずの水準だと言えるでしょう。もっとも、アプリのカテゴリや年数によって左右されますし、価格戦略のようにリテンションに影響する要因は他にもあります。これは、アプリが私たちにとってフィットするか、そしてその価値をどう評価するかを判断するための、多くの指標のひとつに過ぎません。」

まとめ：リテンションのシグナル

これは多くの開発者にとって朗報です。評価されるのはサブスクのリテンションだけではありません。これまでに触れてきたとおり、アプリ買収の判断では、ほかのシグナルも重要視されます。たとえば、回収期間（Payback Period）、価格モデル、LTV/CAC 比率などです。これらすべてが組み合わさって、あなたの「リテンションのストーリー」を形作ります。そして、そのうえで言えるのは、「良い」リテンションの基準は、聞く相手によって 25〜70％ と大きく幅がある、ということです。

自分のアプリの指標を正しく理解し、カテゴリごとのベンチマークを把握し、投げかけられるであろう質問に対して説明（あるいは反論）できるようにしておきましょう。「良い」とは何かを比較するうえでは、State of Subscription Appsレポートのような資料が非常に有用です。また、RevenueCat の Subscription App Healthscore calculatorを使えば、競合アプリと比べて自分の立ち位置を確認することもできます。

有料かオーガニックか？トラフィックとUAに対する買い手の嗜好

Evelin氏が頻繁に受ける質問のひとつが、「オーガニックトラフィックと有料ユーザー獲得（UA）のどちらが、バリュエーションにおいてより重要なのか？」というものです。これは彼女のインタビューの中でも、特に意見が分かれたテーマでした。完全にオーガニックを好む買い手もいれば、完全に有料を好む買い手もいる。そして多くの場合、その中間に位置しています。

オーガニック成長を強く好む買い手

オーガニックトラフィックは、リスクが低く、費用対効果が高いと見なされています。Product Growth LLC 創業者の Zach Tobin氏は、オーガニックを好む立場です。「維持にかかる労力が少ない一方で、アルゴリズム変更のリスクはあります。理想は100％オーガニックですが、損益分岐点までは有料にも投資します。結果として、だいたい80/20の比率になります。」

Reflective Apps の Growth Director である Ryan Thorpe氏もこれに同意しています。「オーガニックトラフィックは配信の信頼性が高く、年間リターンも予測しやすい。さらに、追加の高額なマーケティングコストがかかりません。」

こうした買い手は、防御力の高さと複利的な成長を重視します。オーガニック成長は、品質の高さや強固なプロダクトマーケットフィット（PMF）の証と捉えられ、将来的な信頼性を示す指標と見なされています。

「オーガニックトラフィックは多ければ多いほど良い。私たちが求めているのは、複利的に伸びている高いオーガニックトラフィックです。PMFが確立され、実質的に無料のディストリビューションで、勢いが加速している予測可能なトレンドです。」— Ryan Thorpe, Director of Growth at Reflective Apps

有料ユーザー獲得を好む買い手

一方で、別の買い手にとっては、有料UAの方が予測可能で、スケールしやすいと考えられています。

「有料トラフィックは、私たちの戦略の中核です。オーガニック施策だけで急成長を見せたものの、長期的には維持できなかった若いアプリを、私たちは何度も見てきました。長期的な収益性とスケーラビリティを考えると、有料UAが必要です。」— Guillaume Larrieu, VP of Business Development at Quiet

LOYAL の CEO 兼 Co-founder である Tom Kenney氏は、有料トラフィックを「アプリストアのノイズを突破するための手段」と表現しています。また他の買い手は、CAC、ROAS、ファネルのパフォーマンス、チャネルごとのトレンドをより明確に把握できる点を理由に、有料UAを好むと述べています。これにより、将来的に高くつく失敗を避けやすくなるというわけです。

オーガニックと有料のバランスを求める買い手

有料のみ、あるいはオーガニックのみのトラフィック構成だと敬遠する、という買い手も一部にはいましたが、大多数の買い手はミックス構成を許容しており、むしろバランスの取れた成長が期待できるとして好むケースも多く見られました。

Quiet の VP of Business Development である Guillaume Larrieu氏は、買収において 有料75％／オーガニック25％ の比率が良いと語っています。「オーガニックインストールが、ASOではなく、バイラル動画やソーシャルコンテンツのような自然な施策から生まれているなら、なお良いですね。」

Mode Mobile の Co-Founder & CEO である Dan Novaes氏のように、より均等な配分を好む買い手もいます。

「私は、強いオーガニック倍率を伴った有料トラフィックが好きです。有料は、やり方を分かっていれば予測可能でスケールできます。アルゴリズムは変わるので、オーガニックだけに頼ることはできません。理想的なのは、オーガニック／有料が50/50の世界ですね。」— Dan Novaes, Co-Founder & CEO at Mode Mobile

まとめ：オーガニックトラフィックVS有料トラフィック

どちらのトラフィックも重要ですが、指標や収益性を確認したい、あるいは過去の失敗を避けたいと考える買い手にとっては、有料UAがあることは大きなプラスであることが分かります。オーガニックは純粋な成長ストーリーを示す一方で、有料はより予測可能な手法として捉えられています。

売却前に完璧なトラフィック配分を用意する必要はありませんが、その配分を説明できることが重要です。

• オーガニックが強みであれば、その防御力を定量的に示すこと
• 有料が強みであれば、UAの収益性に加えて、失敗した実験やそこから得た学びを提示すること

どのチャネルが機能していて、どのチャネルが機能していないのか、その理由は何か、そしてどこで効率性を築いてきたのか。こうした点を、買い手に対して明確に説明できるようにしておく必要があります。

「私たちはトラフィックの種類自体に強い好みはありません。ただし、アプリが有料獲得を行っている場合は、UAの指標や、有料ユーザーのパフォーマンスを何が押し上げているのかを深く理解する必要があります。そうすることで、それがどれだけ持続可能で、スケーラブルなのかを判断できるのです。」— Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital

ディールを成立させる：買い手の見つけ方と、実際の向き合い方

買い手が何を求めているのかを理解し、数字を整理し、アプリの成功ストーリーもまとめられた。次に必要なのは、実際に買い手とつながることです。

場合によっては買い手のほうから声がかかることもありますが、すぐに動きたいのであれば、以下のステップから始めましょう。

1. 買い手のタイプをリサーチする：個人や企業がアプリを買収する理由はさまざまで、買い手のタイプによって重視するポイントも異なります。誰がアプリを買っているのか、そして自分のアプリがどのタイプの買い手に最もフィットするのかを理解するために、時間をかけて調べましょう。
2. 買い手を見つける：狙う買い手のタイプが定まったら、次はネットワーキングです。アプリを掲載できるWebサイトやマーケットプレイスを利用する方法もありますし、M&Aの専門家に相談するのも一案です。とはいえ、最も効果的なのは対面でのネットワーキングやLinkedInです。職種としては、Business Development、M&A、Partnership といった肩書きを持つ人を探すことになるでしょう。
3. ターゲットリストを作成する：買い手候補を特定したら、スプレッドシートなどで一覧化します。買い手の情報、通常の取引規模、最近の買収事例、連絡手段などを記録しておくと、アプローチの進捗管理にも役立ちます。
4. 時間を無駄にしないチャネルで連絡する：ウォーム・イントロ（他の創業者、エンジェル投資家、弁護士、会計士、UAコンサルタントなど）は、コールドコールや一斉メールよりも常に高い成果を出します。共通の知人が見つからない場合でも、適切なチャネルを通じた直接のアプローチは有効です。また、創業者向けや買い手向けのフォーラム、マーケットプレイス系のサイトを覗いてみると、表立って動いていない買い手が潜んでいることもあります。対面イベントでのネットワーキングも忘れずに活用しましょう。
5. 自分語りではなく、要点から入る：最初のメッセージは売り込みではありません。あくまで「適合性を確認するための一報」です。シンプルで、率直かつ事実ベースにまとめましょう。MRR、マージン、成長率といった主要指標、関連情報（過去に買収した類似アプリ、共通の知人など）を添え、次のステップとしてフォローアップの通話を提案します。

最初の通話に進んだ後の次の一手は、相手が誰で、何を求めているかによって変わります。事実に基づいた情報とストーリーの両方を織り交ぜて話を進めることを意識し、やり取りの勢いを保ちながら会話を続けていきましょう。

買収オファーはどのような形で提示されるのか？

求人情報で「給与」ではなく「報酬パッケージ」という表現が使われることがありますが、買収オファーもそれとよく似ています。一般的に、オファーの構成は次の3つに分かれます。

1. 現金（キャッシュ）：固定の買収価格を、ディール成立時に支払う形式です。売り手にとっては最もリスクが低く、最も一般的なオファー形態です。
2. 株式（エクイティ）：買収価格の一部、または全額が、買い手企業の株式で支払われます。支払いが買い手の将来的な成長に連動する形になります。
3. アーンアウト（成果連動型支払い）：買収後に、あらかじめ合意した売上・利益・成長目標を達成した場合にのみ、買収価格の一部が支払われる仕組みです。

Evelin氏が話を聞いた買い手のうち、66％は現金のみのオファーを提示しており、残りは現金と株式、またはアーンアウトを組み合わせた形を採用していました。なお、現金オファーであっても、一括で全額が支払われるとは限らず、多くの場合は50％ずつ、場合によっては契約から6か月後・12か月後に分けて支払われます。それでも一般的には、売り手にとって最も望ましい結果は現金オファーです。ただし、成長性の高い企業に買収される場合には、株式も大きな価値を持つ可能性があります。

ディールが早く成立する条件とは？

このセクションでは、創業者が最も気にする質問のひとつである「買い手が素早く“YES”と言うのはどんなときか？」に答えます。

インタビューを通じて、買い手たちは「リスクが高く時間がかかりそうな案件」とは対照的に、「クリーンで進めやすい」と感じるディールの特徴を語ってくれました。意思決定を早める要因は、次のとおりです。

1. 整理され、一貫性のある財務データ：スピード感のあるディールには、すべての数字がきちんと整っていることが不可欠です。売上区分が曖昧だったり、理由の説明できない急落があったり、「その他」とまとめられた項目が多かったりすると、それだけでレッドフラグになります。数字が不明瞭なだけで、プロセスは大幅に遅くなります。
2. 明確な引き継ぎドキュメント：迅速に動きたい買い手は、「このアプリを引き継いだあと、問題なく運用を続けられるか」を重視します。そのためには、アーキテクチャの概要、データ設計（タクソノミー）、分析イベント、過去のロードマップ、実験ログ、グロース施策のプレイブックなどへのアクセスが必要です。Google Driveの奥に眠っている資料も含め、すべてが対象になります。
3. 透明性のある創業者：ディールが早く決まるかどうかは、事業の強さだけでなく「信頼」も大きく影響します。創業者と相性がよく、信頼関係を築けたと感じた買い手は、多少の不完全さには目をつぶり、より早く前に進む傾向があります。
4. 納得感のある成長ストーリー：買い手が知りたいのは、「このアプリを買ったあと、何が起きるのか」です。買収後の成功イメージを明確に描いてあげることができれば、彼らは迷わず契約書にサインしたくなります。

人材タブー：アプリの買い手は創業者に残ってほしいのか？

多くの創業者は、「買い手は買収後すぐに自分を外したがる」と思いがちです。しかし実際には、その答えはもっと複雑で、買い手の運営モデルによって大きく異なります。

すべてのインタビューを通して、私たちは次の3つの共通点に気づきました。

1. これまでの学びや試行錯誤の履歴は、プロダクトのスケールを支えるうえで非常に有用である
2. 開発者（創業者）はプロダクトとビジョンを担い、買い手はマーケティングやマネタイズの専門性を持ち込む
3. 買い手は長期的な関係構築に関心を持っている

買い手は「人数」よりも「プロダクトに関する知識」を重視する傾向がある

多くの買い手が、移行期間中（あるいはそれ以上の期間）にオリジナルチームが残ることを好みます。その理由は明確で、プロダクトの歴史、ビジョン、技術的な意思決定を最も深く理解しているのが、まさにそのチームだからです。

「チームがコミットし続けてくれる限り、残ってもらえるのは理想的です。これまで何を試してきたかという履歴は、非常に価値のある文脈になりますし、そこを土台にさらに積み上げていけます。弱い部分については、こちらの専門性で補えばいいのです。」— Dan Novaes, Co-Founder & CEO at Mode Mobile

Leadtech Groupで事業開発およびM&Aを率いるMichael McPhee氏も、創業者の継続関与を「間違いなく望んでいる」と明言しています。「私たちは、買収後もアプリを作ってきたチームに関わり続けてもらうよう常に努めています。彼らはプロダクトを最もよく理解しており、その専門性は継続的な開発や迅速な改善に不可欠です。」

Nova Sphereの事業開発責任者であるPaweł Pochowski氏も同意します。「実務的な観点から見ても、オリジナルの開発者が関与し続けることで、保守はスムーズになり、変更の実装も速くなります。」

多くの買い手にとって、買収とは「創業チームのスキル」と「新しいオーナーのスキル」を組み合わせることです。Michael氏は次のように説明しています。「Leadtechでは、マーケティング、マネタイズ、UAのスケールを私たちが担い、オリジナルチームはプロダクト改善に集中します。このバランスこそが、長期的なパートナーシップを築き、成功につながる重要な要素です。」

買い手は、ゼロからプロダクトを学び直したいわけではありません。継続性を重視し、すでにある成功を最大限に活かしたいのです。

創業者の関与は“信念”のシグナルとなり、評価額にも影響する

一部の買い手は、買収後も創業者が関与し続けたいと考えているかどうかが、評価額に影響すると明確に述べています。Nova SphereのPaweł Pochowski氏は、オリジナルのクリエイターが関わり続けることを好む理由をこう語っています。

「継続的に関与したいという姿勢は、そのプロダクトを本気で信じ、成長させたいという強いシグナルになります。」 — Paweł Pochowski, Head of Business Development at Nova Sphere

創業メンバーがチームに残留を希望することは、プロダクトへの信頼だけでなく、あらゆるチームメンバーに求められる情熱やコミットメントも示しています。現金を受け取ってすぐに去るのではなく、関与し続けることで将来の成長を支え、将来的に関係を終える場合でもスムーズな引き継ぎを可能にします。

プロダクトを吸収する前提の買収もある

一方で、創業者の関与にメリットがあるとはいえ、大規模なアプリスタジオやポートフォリオ運営企業、特に自社内にプロダクト、エンジニアリング、UAチームを持つ企業は、創業者が残ることへの依存度が低い場合もあります。ただし、だからといって「すぐに出ていってほしい」という意味ではありません。

AppNationの創業者兼CEOであるYalçın Özdemir氏は、次のように説明しています。

「私たちは、買収後に創業者が必ず残ることを前提にはしていません。大規模なアプリスタジオとして、社内のチームやシステム、専門性によって、プロダクトを効率的に統合し、独立して価値を引き出すことができます。ただし、創業者がプロダクトに深く関与しており、継続性の観点で重要な場合には、数か月の移行期間として残ってもらうことをお願いするケースもあります。」

だからこそ、潜在的な買い手とは「創業者としての将来」について率直に話し合うことが重要です。残りたいのか、離れたいのか自体が必ずしも売却可否に影響するわけではありませんが、全員が同じ認識を持っていることが何より重要なのです。

まとめ：ディールを成立させるために

数値とストーリーがしっかり整ったら、ディールをクロージングするうえで重要になるのは、主に次の2点です。

1. 適切な買い手を見つけること
2. 買い手が「YES」と言いやすい状態をつくること

まずは、買い手のタイプを理解し、的を絞ったターゲットリストを作成して、ネットワーキングを始めましょう。財務情報が整理されており、引き継ぎ用のドキュメントが準備できていて、創業者がオープンかつ誠実である場合、ディールは最もスムーズに進みます。買収後に何年もコミットする必要は必ずしもありませんが、明確な移行プランは必要です。もしエグジットを目指しているのであれば、ロードマップやドキュメント、あるいはアドバイザーとしての関与などを通じて、新しいオーナーに対してプロダクトの背景やこれまでの文脈、そして自信をどう伝えるかを考えておくことが重要です。

チェックリスト：2026年に向けた「買収されるための」創業者準備リスト

「アプリを買収してもらうために、何をすればいいのか？」その問いに答えるための、シンプルなToDoリストを探しているなら、まさにここが答えです。

以下は、Evelin氏が行ったアプリ買い手へのインタビューをもとに整理した、実践的で抜け漏れのないチェックリストです。今日エグジットを考えている創業者にも、5年後を見据えて準備したい創業者にも役立つ、継続的な準備項目として捉えてください。

1. 指標（メトリクス）を準備する

メトリクスは、買い手が「このアプリに時間をかける価値があるか」を判断するための根拠です。何よりも重要なのは、明確さと一貫性です。悪い数値よりも、分かりにくい・矛盾した数値のほうが、ディールを遅らせる原因になります。

準備しておくべき主要データ：

• LTV（コホート別）および LTV/CAC 比
• リテンションカーブ（可能であれば D7、D30、D90+）
• 解約理由（任意解約と非任意解約の内訳）
• オーガニックトラフィックと有料トラフィックの比率
• UA（ユーザー獲得）の収益性（チャネル別＋主要な実験結果）
• 収益内訳（サブスクリプション／IAP／広告）
• 年間プラン利用ユーザーの割合（該当する場合）

2. プロダクトを整える

自分自身を「営業担当」だと考えてみてください。より高い評価額を得るためには、買い手がそのプロダクトを引き継ぎ、すぐに収益化できる状態にしておく必要があります。

覚えておくこと： 買い手が求めているのは完璧さではなく、摩擦の少なさです。

• 散らかったコードパスや一時的なハックの整理
• 不安定なサードパーティ依存の削減
• オンボーディングの分かりやすさ向上
• 必要に応じたペイウォールと価格ロジックの最適化
• 可能な範囲でのオーガニックトラフィックの成長（ASO、レビュー、SEO）

3. 財務情報を準備する

整理されていない、または不透明な財務情報は、ディールを最速で破談に導く要因のひとつです。買い手が数値の意味を推測しなければならない状況では、最悪のケースを想定されてしまいます。推測させないことが重要です。

買い手と話す前に：

• 不要なコストの見直しと削減（EBITDAと見え方の改善につながる）
• 損益計算書（P/L）の整理と突合
• 加算項目（add-back）や一時的費用の明確な説明
• MRRの内訳（国別、ストア別、プラン別、プラットフォーム別）
• 売上の急増・異常値・急落について説明できる準備

4. チームについて整理する

買い手が重視するのは人数ではなく、継続性と守られた知見です。買い手と話し始める前に、必ずチームと認識を揃えておきましょう。

決めておくべきこと：

• 買収後に誰が残るのか、またどのくらいの期間か
• 引き継ぐべき知識や責任範囲は何か
• 自分自身がどの形で関与し続ける意思があるか
• 更新済みの契約書、NDA、IP（知的財産）譲渡の状況

5. 引き継ぎ準備を行う

買い手があなたがいなくてもアプリを運営できると明確にイメージできるほど、ディールは速く進みます。今はあなたしか知らないこと、あるいはチームにとって有用なプロダクトの意思決定や背景をドキュメント化しましょう。

用意しておくべき内容：

• 現在および過去のプロダクトロードマップ
• 機能の制御ロジック（feature gating）
• ペイウォールのロジックと価格変更の履歴
• オンボーディングフローとファネル
• アーキテクチャ概要（簡易なもので問題ありません）
• ブランドアセットおよびプレスキット
• 使用ツール、SDK、ダッシュボード、ログイン情報をまとめたマスタードキュメント

6. ディールの準備をする

オファーが出てから考え始めるのでは遅すぎます。自分が何を望んでいるのか、買収に関する会話をどう進めるのか、そして誰に事前に共有しておくべきかは、あらかじめ整理しておく必要があります。

ここで考えておくべきポイント：

• 受け入れ可能な最低条件のオファー金額と、その構成を決める（現金／アーンアウト／株式）
• 理想とする買い手のタイプを明確にする（スタジオ、ロールアップ、戦略的買収など）
• ターゲットとなる買い手のリストを作成する
• 最終的に決める前に、少なくとも5社の潜在的な買い手と話す
• 最初のコンタクト用メッセージを用意し、ピッチを練習する
• タイミング、動機、トレードオフについて、自分自身に正直になる

このリストを一度にすべて完了させる必要はありません。やることは多いですが、ひとつひとつ事前に準備しておくことで、適切な買い手が現れたときに、迷わず素早く前に進むことができます。

最後に：2026年にアプリを売却するという現実

買い手への取材、そしてこれまで数多くの創業者と話してきた経験から、Evelin氏は「創業者が買収について抱きがちな最大の誤解は、買い手が“完璧さ”を求めていると思っていること」だと言います。

実際は、そうではありません。

買い手が求めているのは、次のような要素です。

• 予測可能な収益
• 本物のプロダクトマーケットフィット（PMF）を備えたプロダクト
• しっかりと維持されているリテンション
• 納得感のある成長ストーリー
• クリーンで透明性の高いビジネス運営

これらのシグナルを、ストーリーとしても、ハードデータとしても明確に伝えられる創業者は、結果としてより高い評価を得やすく、ディールも早く成立します。もし今後12〜24か月以内に売却を検討しているのであれば、準備は今から始めるべきです。完璧なアプリや完璧なピッチは必要ありません。必要なのは、筋の通ったストーリー、透明性のある数値、そして適切な買い手です。

関連ツール・リソース

さらに深く知りたい方へ。買収に向けた準備に役立つ関連コンテンツやツールをご紹介します。

• インタビュー全文：質問と回答をすべて読む
• RevenueCatの subscription healthscore calculator（サブスクリプション健全性スコア計算ツール）
• レポート：State of Subscription Apps （業界ベンチマークに最適）
• ブログ：アプリを売却する方法 ― David Barnard からの学び
• ポッドキャスト：どんなアプリが「買う価値がある」のか？ BlueThrone が量から価値へシフトした理由
• ポッドキャスト：実際の需要が、趣味のアプリをビジネスに変えた話
• Evelin氏のテンプレート：アプリの学び・実験ドキュメント
• Evelin のテンプレート：損益計算書（P/L）

しかし、私たちはここで立ち止まりません。2025年11月以降、特に加速した開発ペースでアップデートを続けています。すべてのアプリにとって最高のペイウォールビルダーになることを明確な目標に、最も要望が多く、最もインパクトの大きい機能改善を次々とリリースしています。

このブログは、RevenueCat Paywalls に関するすべての更新をまとめた「生きた変更履歴」として運用していきます。ぜひブックマークして、最新情報を随時チェックしてください。

Figma のデザインをそのまま Paywalls にエクスポート

デザインの引き渡しが、「最初から作り直すこと」を意味する必要はありません。そして今、それは本当に不要になりました。

Figma のモックアップを、Paywall エディターに直接エクスポートできます。レイアウトは Paywalls のネイティブコンポーネントとして取り込まれるため、すぐに次の作業が可能です。

• 構造を変えずにコピーを編集
• プロダクトやパッケージを差し替え
• テキストのローカライズ
• A/B テストの追加
• 特定のオーディエンスへのターゲティング

最大のメリットはスピードです。デザイナーは引き続き Figma で作業でき、ペイウォールのテストを出荷するチームは、最終モックからライブバリアントまで、レイアウトを手作業で作り直すことなく一気に進められます。

Figma デザインをインポート↗

Paywalls エディターのキーボードショートカット

素早く改善を重ねていると、ちょっとしたクリックの積み重ねが大きな負担になります。

Paywalls エディターでは、よく使う操作に対応したキーボードショートカットが利用できるようになりました。コンポーネントの追加、セクションの複製、変更の取り消し／やり直し、ブロックの削除などを、キーボード操作だけで行えます。作業の流れを止めることなく、スピーディな反復作業を本当に「一瞬」で進められます。

すべてのショートカットを見る ↗

より多くのデバイスでペイウォールをプレビュー

ある画面では完璧に見えても、別の画面では不自然に見える——ペイウォールではよくあることです。これまでは公開後に気づくケースもありましたが、現在はより幅広い iOS / Android のスマートフォンやタブレットで、事前にペイウォールをプレビューできるようになりました。キャンバスは実際の画面サイズに合わせて更新されるため、デバイスを数秒で切り替えながら、次の点を確認できます。

• 余白や間隔の問題を早期に発見
• フォントサイズの確認
• 画像のトリミングやメディア配置のチェック
• スクロール挙動の妥当性確認
• CTA が意図した位置に表示されているかの確認

シンプルな改善ですが、公開直前の修正作業を大幅に減らすことができます。

ペイウォールテンプレートのフィルタリング

テンプレートは、目的のものをすぐに見つけられてこそ価値があります。

テンプレートギャラリーに、購入方法・ティア・パッケージ別のフィルターが追加されました。トライアル優先のレイアウト、価格表グリッド、プロモーション向けデザインなど、最初から使いたいパターンが決まっている場合に特に便利です。探す時間を減らし、実際にリリースすることに集中できます。

テンプレートから始める ↗

ペイウォール用カウントダウンコンポーネント

プロモーションは効果的なペイウォール施策になり得ますが、その効果が最大化されるのは「緊急性」が明確で、かつ本物である場合です。そこで、任意のペイウォールにカウントダウンタイマーを追加できるようになりました。終了日時を一度設定するだけで、タイマーは自動的に更新されます。追加のコードも、手動での更新も必要ありません。

これは、ブラックフライデー、ローンチ記念プロモーション、期間限定ディスカウントなど、「タイミング」がユーザーの意思決定を後押しするあらゆるキャンペーン向けに設計されています。

カウントダウンを追加する ↗

プロジェクト単位のブランドカラー設定

プロジェクト設定でブランドカラーを定義できるようになりました。ここで設定したブランドカラーは、Paywalls エディタ内で利用可能です（今後、対応範囲はさらに拡大予定です）。プロジェクト全体で一貫したブランド表現を、より簡単に反映できるようになります。

Paywalls エディタで実際の価格を表示

これまでダッシュボードのエディタ上では、商品価格はプレースホルダー値で表示されていました。今回のアップデートにより、エディタ内で実際の価格が表示されるようになりました。これにより、作業中でもより現実に近い形でペイウォールを確認でき、デザインやコピーの調整がしやすくなります。 ※注意点として、価格を表示するには、その商品で少なくとも1回のテスト購入が行われている必要があります。

AIを使ってペイウォールを作成

アプリストアのページ情報をもとに、AIでペイウォールを生成できるようになりました。アイデア出しのインスピレーションとしてはもちろん、そこから調整・テストを重ねていくためのしっかりした出発点としても最適です。

Paywallsで動画に対応

Paywalls で、画像と同様に動画を独立したコンポーネントとして追加できるようになりました。よりリッチで伝わりやすい表現が可能になります。

動画を背景に設定

動画を、ルートのペイウォール、フッター、または任意の親コンポーネント（スタック、パッケージなど）の背景として設定できるようになりました。視覚的なインパクトを高め、より没入感のあるペイウォール体験を作成できます。

購入意図をインターセプト

ネイティブの iOS / Android SDK において、購入意図（購入CTAのタップ）をインターセプトするためのメソッドを新たに提供しました。これにより、ユーザーが購入フローへ進むかどうかを決める前に、任意のカスタムUIを表示できるようになります。この仕組みは、たとえば購入前に年齢確認や保護者の同意を求める必要があるケースでは、購入に進む前段階で年齢ゲートとして機能するUIを表示するといった用途に活用できます。また、国ごとの利用条件や法的な文言など、購入前に追加で伝える必要がある情報がある場合にも、その内容を表示し、ユーザーに確認してもらったうえで購入フローへ進ませることが可能です。

すべてのプランを表示（シート）

ボタンの遷移先として、追加コンテンツを表示するためのシートを指定できるようになりました。遷移先にシートを選択すると、コンポーネントパネル内の該当ボタンに新しく Sheet コンポーネントが表示されます。シート自体、またはその中に含まれるコンポーネントを選択すると、ペイウォールのプレビュー上でシートが表示されるようになります。シートには、他のスタックと同様に自由にコンポーネントを追加できます。

シートには独自のパッケージや購入ボタンを設定することも可能で、ユーザーはシート内に表示された選択肢から直接購入を完了できます。

詳しくはドキュメントをご覧ください ↗

個人的に私は、Web-to-Appがとても好きです。なぜなら、私が関わってきたeコマースとアプリの両方の長所を融合しているからです。Webファネルならではのストーリーテリング、実験のしやすさ、そして高いコントロール性に、アプリが持つリテンションやLTV（顧客生涯価値）の強さが組み合わさります。うまく設計できれば、理想的な成長基盤だと感じられるでしょう。ただし、当然ながら課題も存在します。本ガイドでは、そのすべてを順を追ってご紹介していきます。

Web-to-Appファネルとは？

Web-to-Appファネル（web2app と表記されることもあります）は、その名のとおりWebから始まり、ユーザーをアプリへと誘導する導線です。たとえば、アプリをダウンロードする前にWeb上でサインアップや支払いを完了するケース（技術的には web-to-web と呼ばれます）もあれば、アプリをインストールした後に支払いが行われるケース（Web-to-App）もあります。

実際のところ、多くの人はこれらをまとめて「Web-to-App」と呼んでいます。正直なところ、それで問題ありません。どちらのアプローチも、Webとアプリの間のギャップを埋めるという点では同じだからです。本ガイドでは、特にアプリ内のみのファネルと最も異なる web-to-web ファネルを中心に解説していきます。

Web-to-Appを活用するメリット

Webファネル自体は新しいものではありません。特にヘルス＆フィットネス分野では長年使われてきましたが、近年、その導入が急速に拡大しています。多くの人が「ファネルはアトリビューションを改善し、コストを削減できる」と考えていますが、もちろんWeb-to-Appファネルにはメリットとデメリットの両方があります。ここでは、その両面を見ていきましょう。

1. コスト削減（※一概には言えない）

Web-to-Appが検討される理由として、まず挙げられるのがコスト削減です。ただし、先に述べたとおり、話はそれほど単純ではありません。AppleやGoogleは15〜30％の手数料を取りますが、これは確かに大きな割合です。一方、Web決済の手数料は通常かなり低く、約2〜3％程度です（すべての手数料を加味すると、実質的には約6％になることが多いです）。

このため、Web-to-Appは「コストを抑えられる」と考えがちですが、手数料が低いという理由だけで移行を判断すべきではない点は重要です。

App Growth ConsultantのThomas Petit氏は、Sub Clubのポッドキャストで次のように述べています。「人々は、間違った理由でWeb-to-Appに移行している。」Web-to-Appファネルの構築には、時間と労力がかかります。まったく新しいフローをテストすると、アプリ内では機能していたものがWebでは必ずしも機能せず、コンバージョン率が下がることもあります。その結果、顧客獲得単価（CAC）が上昇する可能性もあります。

本当の価値は、必ずしもコスト削減にあるわけではありません。重要なのは、ユーザー1人あたりのライフタイムバリュー（LTV）を高められる可能性です。全体のコストが下がらなかったとしても、各ユーザーがもたらす価値が高まるのであれば、それは十分に意味のある結果だと言えます。

2. 継続率とLTVの向上

データを見ると、Web経由で購読したユーザーは、App StoreやGoogle Play経由のユーザーよりも更新率が高い傾向があり、その結果として継続率の向上やライフタイムバリュー（LTV）の増加につながるケースが多く見られます。その理由のひとつがフリクションです。スマートフォン上では、すべてのサブスクリプションが一か所にまとまっているため、ユーザーは複数のサービスをまとめて解約しやすくなります。特に1月にこうした動きが増えるのは、よく知られた傾向です。もうひとつの要因として、Webサブスクリプションは比較的高価格帯のオファーに寄ることが多い点も挙げられます。

また、Webユーザーは高い価格を支払うことに慣れている場合が多く、その結果として、アプリに対してもより高額な支出を受け入れやすい傾向があります。

3. トラッキングとアトリビューションの簡素化

2021年にAppleがApp Tracking Transparency（ATT）ポリシーを導入したことで、アプリ業界ではWeb-to-Appのあり方を改めて見直す動きが広がりました。Webではトラッキングが比較的シンプルであるため、キャンペーンから得られるデータ量が多く、より良いフィードバックループを構築できます。

もちろん、Web-to-Appのトラッキングが完璧というわけではありません（たとえば、購入データを7日後にMetaへ送信するのは難しいケースがあります）。それでも一般的には、購読ユーザーの行動をより深く把握できるため、キャンペーンパフォーマンスの改善につながります。たとえば、獲得元ごとに継続率やLTVへどのような影響が出ているかを簡単に確認できる点は、大きなメリットです。

4. マネタイズの自由度

返金保証？もちろん可能です。買い切り（ライフタイム）サブスクリプション？バンドル？アップセル？複数パターンの価格テスト？思う存分試せます。

時間の経過とともに、アプリストアはマネタイズやトラッキングに関して、より厳しいルールを課してきました。一方でWebはほぼ自由な実験環境です。アプリストアの制約を気にすることなく、さまざまな施策を試すことができます。もちろん、これはダークUXを推奨したり、無秩序に大量のテストを行うことを勧めるものではありません。どのチャネルであっても、ベストプラクティスを守り、倫理的なマネタイズとUXを尊重すべきです。それでもなお、この自由度こそが、Web-to-Appが選ばれる理由のひとつであることは間違いありません。

5. 複数ファネルを素早くテストできる

Web-to-Appの普及に伴い、ノーコードのWebアプリ／ファネルビルダーも大きく成長しました。その結果、エンジニアでなくても短時間でファネルを構築できるようになっています。RevenueCatでペイウォールを作るほど速くはないかもしれません（最速で4分未満！スピード構築選手権もあります）が、それでも十分にスピーディです。

アーリーステージのスタートアップの中には、Typeformのアンケートやシンプルなランディングページを、最初のWeb-to-Appファネルとして使っている例もあります。

もしプロダクトのローンチ前であれば、Web上でコンバージョンが完結するという点は大きなメリットです。メッセージング、価格、ポジショニングを早い段階からテストできます。Meta広告・アプリ成長コンサルタントのMarcus Burke氏は、次のように述べています。「30%のストア手数料を節約するためにWebへ移行するのではありません。Webに移行するのは、差別化を図り、素早く学び、プロダクトのロードマップに関係なくマーケティングを強化できるからです。」

6. キャッシュフローの改善が早い

アプリ内で新しいサブスクライバーを獲得できたら、それ自体は素晴らしいことです。……が、App Storeから実際に入金されるまで最大68日待つ必要があります。ありがとうございます、App Store。資金に余裕のないスタートアップにとっては、かなり長い期間です。

もちろん解決策がないわけではありません。たとえばRevenueCatでは、App Storeの売上に対して翌日払いを提供する「RC Capital」を立ち上げています。それでも、一般的にWeb決済はアプリストアと比べて即時、もしくは非常に短期間で入金されるケースが多く、キャッシュフローの面では大きなメリットがあります。

7. コンテンツ主導のディスカバリー

Thomas氏が指摘しているように、Web-to-Appは新規ユーザー獲得（ディスカバリー）においても非常に強力な手段になります。特に規模の大きいアプリでは、Web起点のコンテンツを活用して新しいユーザーを引き寄せることが可能です。たとえば Photoroom は、無料で使えるWebツールを提供することで認知を獲得し、そこからユーザーをアプリへと誘導しています。これにより、コンテンツを起点とした成長戦略（コンテンツドリブンなグロース）を実現しています。

Web-to-App のデメリット

Web-to-App のファネル構築を始める前に（そしてあのペイウォール高速構築記録に挑戦する前に）、いくつかの重要なデメリットも理解しておく必要があります。

多くのアプリは、Web向けにどれほど多くの変更や追加設定が必要になるかを過小評価しがちです。これまでに、追加コストやテストにかかる時間について触れてきましたが、それ以外にも考慮すべきポイントがあります。

1. Webでは無料トライアルがうまく機能しにくい

無料トライアルやフリーミアムモデルを主軸とした戦略の場合、それをそのままWebに持ち込んでもスムーズに機能しないことがあります。Webでは、残高のないカード情報が入力されるケースも多く、その結果、低価格の有料トライアル（例：1ドル）や返金保証といった代替手段が必要になることがあります。

このような違いにより、アプリに流入する無料ユーザー数が減る可能性があり、さらに Webとアプリのパフォーマンスを単純に比較することが難しくなるという課題も生じます。

2. オーガニック順位とトラフィックへの影響

多くのWeb-to-Appファネルでは、ユーザーがWeb上で直接コンバージョンするため、アプリのインストール数や評価、レビューが減少する可能性があります。一方で、アプリ内課金を前提としたキャンペーンでは、たとえその場でコンバージョンしなくても、ユーザーをApp StoreやGoogle Playに送客することになります。

インストール数・評価・レビューが減ると、ストア内でのランキングが下がり、オーガニック成長が制限されるおそれがあります。Perceptycsの創業者であるNathan Hudson氏は、このデメリットについて次のように説明しています。

「これは、目標ROASを維持しながら有料獲得をスケールさせたいアプリにとって、ASOの後押しが得られなくなるという点でも不利に働きます。ランキングが高いほどオーガニックインストールの量が増え、結果としてブレンドされた獲得単価を大幅に下げることができるのです。」

3. 財務・法務面の複雑さ

アプリストアが高い手数料を取ることについて不満を感じることは多いですが、実際には税制対応やチャージバック処理など、多くの煩雑な業務を肩代わりしてくれているという側面もあります。

一方でWebでは、これらをすべて自分たちで対応する必要があります。アプリがグローバル展開している場合、その複雑さはさらに増します。PaddleのようなMerchant of Record（MoR）を利用するといった解決策もありますが、それは追加コストであり、運用上の新たなレイヤーの複雑さを意味します。

4. アトリビューションが複雑になる

Web とアプリの両方で複数のファネルを運用すると、トラッキングやアトリビューションは一気に複雑になります。

• アプリキャンペーンは、SKAN や集計されたインストールデータに依存します
• Web キャンペーンは、ピクセルやサーバー間（server-to-server）のトラッキングを使用します

この両方を同時にテストしていると、状況はかなり混沌としがちです。ユーザー数自体は増えるかもしれませんが、それは良いことでもある一方で、「どこから来たユーザーなのか」「どのファネルに紐づくのか」が分からなくなるリスクがあります。その結果、成功を再現したり（あるいは失敗を修正したり）するのが難しくなります。この問題は、Web とアプリの両方で一貫したユーザータグ付けを行い、さらにデータを単一の「信頼できる情報源（single source of truth）」に統合することで、ある程度改善できます。

Web-to-App とアプリ内課金（In-app purchases）の主な違い

ここまで見てきたとおり、Web-to-App とアプリ内課金は、仕組みとして大きく異なります。Web-to-App には多くのメリットがありますが、「すぐにサクッと試せるもの」ではありません。App Growth Annual 2025 のワークショップで、Marketing & Growth Consultant の Gessica Bicego氏 が説明していたように、Web ファネルには追加の複雑さがあります。

「Web ファネルは一見シンプルに見えますが、実際には複数の技術レイヤーが絡み合っています。」

• MMP：ディープリンクの管理や、正確なアトリビューションのために不可欠
• CRM ツール：取得したメールアドレスを管理・活用（アクティベーション）するために必須
• 決済プロセッサ：グローバルな税制に対応できる決済基盤が必要
• 高い決済失敗率への備え：失敗率は約 50% に達することもあるが、適切なツールやリトライ設計によって承認率は大きく改善できる

以下では、Web-to-App とアプリ内課金の違いについて、知っておくべきポイントを整理して解説します。

Web-to-App ファネルをテストすべきなのはどんなアプリか？

Web-to-App は、特定の一種類のアプリだけが検討すべき手法というわけではありません。アプリのカテゴリやターゲットユーザー、そして事業フェーズによって、さまざまな形で意味を持ちます。「自分たちも試すべきだろうか？」と考えているなら、以下のようなグループは特に Web-to-App のテストを検討する価値があります。

1. アーリーステージのスタートアップ

アーリーステージのスタートアップにとって、Web-to-App は初期のファネルを検証し、ペイド獲得を試しながら素早く改善を回していくための有効な手段になり得ます。

ただし、アプリ内課金（in-app）と Web-to-App を同時にテストすることは避けるべきです。特に少人数のチームやブートストラップで運営している場合、フォーカスが分散しすぎてしまいます。事業がもう一段階成長したフェーズであれば、両方を並行して運用する判断も現実的になります。

例外として、すでにアプリ内フローからスタートしていて、「Web の方が自分たちのプロダクトに合っている」と分かった場合があります。その場合は、Web ファネルに全面的にフォーカスとリソースを移すのが賢明です。

2. ペイド獲得のリーチを拡大したいアプリ

アプリ向けキャンペーンと Web 向けキャンペーンでは、ペイド最適化の考え方は大きく異なります。Web にフォーカスすることで、これまでリーチできていなかったまったく新しいオーディエンスを開拓できる可能性があります。

よく言われているのは、Meta 上におけるアプリオーディエンスと Web オーディエンスの重なりは 約15%程度に過ぎない、という点です。つまり、Web キャンペーンを展開することで、完全に新しいユーザー層への扉が開くということです。 不思議なことに、私は仕事柄これまで何百ものアプリをダウンロードしていますが（本当に仕事です！）、Meta 上でアプリキャンペーンを目にすることはほとんどありません。そういう意味で、私は完全に「Web オーディエンス側」に属していると言えるでしょう。

3. トラッキングとアトリビューションの簡素化

2021年に Apple が App Tracking Transparency（ATT） ポリシーを導入したことで、アプリ業界では Web-to-App を改めて見直す動きが広がりました。Web ではトラッキングが比較的シンプルで、キャンペーンから得られるデータ量も多く、フィードバックループを回しやすいという特徴があります。

Web-to-App のトラッキングが完璧というわけではありません（たとえば、購入データを 7 日後に Meta へ連携するのは難しいケースがあります）。それでも一般的には、サブスクライバーの行動をより深く把握でき、キャンペーンのパフォーマンス改善に役立ちます。たとえば、どの獲得チャネルがリテンションや LTV にどう影響しているかを比較的容易に確認できるようになります。

4. Apps focusing on older audiences

App Store 手数料を回避できる点も確かにメリットではありますが、Web-to-App による本当の収益性向上は、より高い LTV（顧客生涯価値）と優れたリテンションから生まれることがほとんどです。 長く使い続ける傾向のある Web サブスクユーザーとの関係をより強固に構築することで、アプリは中長期的な収益性を大きく改善することができます。

5. Web-to-App に適したカテゴリは存在する

Web-to-App は当初、ヘルス＆フィットネスやビジネス系アプリを中心に普及しましたが、現在はその状況が変化しています。State of Subscription Apps レポート 2025 によると、ヘルス＆フィットネスは、現在では Web における成長が比較的緩やかなカテゴリのひとつとなっています。その一方で、プロダクティビティ、ユーティリティ、教育系アプリでは、web-first なファネルを採用するアプリが増え、力強い成長が見られています。これらの分野では、Web を起点としたユーザー獲得とマネタイズが、より効果的に機能し始めています。

また、ライフスタイル、エンターテインメント、金融系アプリでも、Web-to-App ファネルを採用する動きが増えています。最終的に重要なのはカテゴリそのものではなく、ユーザーにアプリを試してもらうために、何をどのように伝える必要があるかです。

Gessica氏が指摘しているように、Web ファネルで特に高い成果を出しているアプリには、共通する特徴があります。

• プロダクトの理解にさらなる説明が必要であること（数行のテキストや静的なビジュアルだけでは伝えきれない）
• 質問やストーリーテリングによって引き出される感情的なトリガーに依存している体験であること
• オンボーディング中に即時的な価値を提供できること（例：クイズ結果、パーソナライズされたプラン、無料ツールなど）
• Web 上のオンボーディングが、購入前にユーザーを教育し、エンゲージし、適切に選別できること

つまり、カテゴリは最も重要な要素ではありません。重要なのは、ユーザーを効果的にコンバージョンさせるために、そのアプリが何を伝える必要があるのかという点です。

6. 企業が支払う B2B ブランド

私自身、これまで主に B2C の世界に深く関わってきたため、このユースケースは当初あまり意識していませんでした。しかし、Sub Club で Thomas氏が説明していたように、Web-to-App は B2B ブランドにとって特に大きな価値を持つケースがあります。

アプリストアの課金は、基本的に個人のクレジットカードに直接請求されるため、企業負担のサブスクリプションには向いていません。一方で Web では、雇用主がチーム単位の請求を管理したり、全社向けサブスクリプションを設定したり、支払いプロセスを簡素化したりすることが容易です。これらはすべて、B2B における購入体験を大きくスムーズにします。

Web-to-App のテストと成果測定：無料のブループリント

これまで見てきたように、Web-to-App のファネルには追加の複雑さが伴います。そのため、焦らず、正しく設計することが重要です。一般的には、既存の in-app フローをそのまま反映したファネルから始めることが推奨されます。これにより、初期セットアップを迅速化でき、結果を比較する際の差分も最小限に抑えられます。

とはいえ、クイズ形式のファネルに安易に頼る必要はありません。クイズは確かに人気がありますが、選択肢はそれだけではありません。

そこで、ここでは最初の Web-to-App ファネルを構築するためのブループリントを紹介します。

1. 成功指標とテスト計画を定義する

Web-to-App とアプリ内課金を比較検証する際に、コンバージョン率や CAC だけを見るのは誤解を招きやすい点に注意が必要です。Web 上のコンバージョン率を最適化し、ユーザーをスムーズに Web からアプリへと移行させる仕組みを構築するには、一定の時間がかかります。

トライアルから有料への転換率が向上するケースもありますが、その一方で、他の指標が初期段階では低下することもあります。短期的な数値に一喜一憂するのではなく、Web ファネル運用に伴う追加コストも加味したうえで、ARPU（課金ユーザーあたりの平均収益）や LTV／CAC 比率を分析することが重要です。 多くのアプリにとって、これは「どちらか一方」を選ぶ話ではありません。重要なのは、Web-to-App が新しいユーザー層に対して、採算の取れる形でリーチできているかどうかです。そのためにも、テスト期間（一般的には有意なリテンションデータを得るために 3〜6 か月）と、試す具体的なアプローチをあらかじめ定義し、終わりのないテストに陥らないようにしましょう。

2. Web-to-App のセットアップを設計する

Web-to-App というと、オンボーディング用のクイズファネルを思い浮かべる人が多いかもしれません。確かにこれは定番の手法ですが、あくまで数ある選択肢のひとつにすぎません。また、Web-to-App ファネルはオンボーディングそのものの代替ではないという点も重要です。

テストを行う際は、次のような別のフローも検討してみてください。

• ランディングページ → チェックアウト
• ランディングページ → サインアップ → インストール
• スマートバナー（AppsFlyer、Adjust など）
• QRコード → アプリインストール
• メールシーケンス → Web ペイウォール → チェックアウト
• リードマグネット → アプリインストール
• ブログ記事 → インストール
• ウェビナーファネル → チェックアウト
• ランディングページ → Web アプリのデモ → チェックアウト

誤解のないように言っておくと、クイズを否定しているわけではありません。クイズはパーソナライズや教育、より複雑なユーザージャーニーを構築するうえで非常に有効な手法です。ただし、それが唯一の方法ではないということです。Nathan氏は次のように述べています。

「みんながやっていることをそのまま真似するのではなく、自分たちのプロダクトにとって何が理にかなっているのかを考えるべきです。あなたのユニークな価値提案は何か？ユーザーが抱えている課題は何か？アプリをダウンロードする前の段階で、それらを Web 上でどう伝え、どう解決できるのか？ それは、必ずしも Web オンボーディングのクイズである必要はありません。」

シンプルな出発点として、ミニランディングページを使うという方法もあります。Gessica は、複雑さを加える前に Web-to-App ファネルを検証するための最初のテストとして、ミニランディングページが理想的だと共有しています。

Credit: Gessica Bicego

Gessica氏の例が優れている点は、純粋な Web ファネルに伴ういくつかのリスク（特に決済まわり）を軽減できていることです。一方で、決済自体はアプリ内で行われるため、Meta などでの Web キャンペーンを本格的に活用できるわけではありません。

ランディングページや Web クイズを構築するためには、立ち上げを支援してくれる ノーコードツールが数多く存在します。たとえば、Unbounce、ConvertKit、Web2Wave などがあり、これらを活用すればスピーディにテストを始めることができます。

3. オファー設計を決める

多くのアプリは、ハードペイウォール、無料トライアル、フリーミアム、あるいはそれらのハイブリッドに依存していますが、Web-to-App ファネルではオファー設計を見直す必要があるケースが多くあります。その理由は次のとおりです。

• Web では不正利用や購買意欲の低いユーザーが多く、無料トライアルのコンバージョンが下がりやすい
• Web 決済には摩擦があるため、ユーザーは明確で即時的なメリットを期待する

その結果、Web-to-App では次のようなオファーがよく採用されます。

• 有料トライアル（例：7日間で $1）
• 返金保証（コンテンツ系・サービス系アプリで特に有効）
• Web 限定割引（ストア手数料分の節約をユーザーに還元）

また、Web ユーザー向けにプラン構成をシンプルにするのも有効です。

• 分かりやすさと LTV 向上のため、年額プランをメインに訴求する
• 月額プランはアプリ内に残し、望ましい行動を促す

私が特に気に入っているのが、植物識別アプリ Plantin の例です。Plantin では「最もお得なのは Web」であることを明確に打ち出しつつ、非常に短期間の無料トライアルを提供しています。これは、インセンティブと摩擦低減のバランスが非常にうまく取れた設計です。Web 経由だからこその 30% オフという表現も、「特別なディールを見つけた」という感覚をユーザーに与えます。

最適化を重ねていくと、トラフィックの意図やチャネルに応じてオファー構成を使い分けるようになります。たとえば、購買意欲の高いユーザーには年額割引が響きやすく、コールドオーディエンスにはリスクの低い入口や、返金保証の仕組みを丁寧に説明することが効果的な場合があります。

4. 初期ファネルを改善する

多くの場合、まず取り組むべきはクリエイティブの最適化です。特に Web キャンペーンを初めて実施する場合、これまでとは異なる新しいオーディエンスにリーチすることになります。そのため、クリエイティブの出来が、獲得できるユーザーの質に大きく影響します。

また、信頼の構築は Web-to-App において非常に重要な要素です。アプリ内課金では App Store や Google Play の信頼性やレビューに依存できますが、Web-to-App ではそうはいきません。機能の明確な訴求、ソーシャルプルーフや評価の表示、あるいはミニデモとして機能する動画ペイウォールの導入などを通じて、意識的に信頼を構築・最適化する必要があります。

次に、決済ページの最適化を行いましょう。Web のペイウォールはアプリ内ほど制約が厳しくないため、価値が明確に伝わっているか、Web を選ぶ十分なインセンティブがあるか、そして信頼をさらに高められているかを意識して設計します。

あわせて、以下のような一般的なベストプラクティスも押さえておきましょう。

• 決済を簡単にする（例：Apple Pay への対応）
• アプリへの引き継ぎをシームレスにする（ディープリンク、オートログインなど）
• モバイルファーストの UX を維持する
• プラン数を絞り、選択による混乱を防ぐ

こうした基本的な整理ができたら、次のステップとしてファネルをさらに改善していきます。たとえば、ランディングページのテストと改善を行ったり、クイズ形式の質問を最適化したりすることです（そう、クイズは本当に有効なツールになり得ます）。クイズ形式の質問は信頼構築に役立ちますが、パーソナライズされていない、関連性の薄い、あるいは曖昧な質問は、かえってコンバージョン率を下げる要因になる点には注意が必要です。

5. 個別ファネルをさらに最適化する

Web-to-App の大きな魅力は、オーディエンスごとにファネルをカスタマイズできることです。Plantin の Head of Marketing である Anastasiia Karlova氏は、その重要性を示す示唆に富んだ事例を共有しています。

彼らは「キノコを識別する」という広告をテストし、ユーザーが遭遇したキノコが何で、食べられるかどうかを理解できることに焦点を当てた Web ファネルを用意しました。このファネルは Web 上では非常によく機能しましたが、ユーザーがアプリに到達すると、そこにはキノコ関連のコンテンツが存在せず、多くのユーザーが離脱してしまったのです。

この事例が示しているのは、Web ファネルはアプリ内の体験ときちんと連動している必要があるということです。各チャネルごとにファネルを最適化し、Web 上でユーザーに約束した体験やコンテンツが、アプリ内でも確実に提供されている状態を作ることが重要です。

Web-to-App の次に来るものは？

Web-to-App の未来は非常にエキサイティングです。ここでは、今後起こると考えている変化をいくつか挙げます。

• アプリ内チャネルでのスケール競争が激化するにつれ、Web ファネルをテストするアプリがさらに増える
• ユーザーを Web に送るタイミングと、アプリ内ペイウォールを表示するタイミングを意識的に使い分ける、より多くのハイブリッド型ファネルモデルが登場する
• Epic対Apple 判決（米国でアプリから Web 決済へのリンクが認められたこと）をきっかけに、他の国や市場にもこの動きが広がり、Web-to-App 戦略の新たな機会が生まれる

ファネルの構築やパーソナライズが容易になることで、より細かなセグメンテーションとオーディエンスごとに最適化されたフローが増えるたとえば、ウェルネスアプリの BetterMe では、すでに少なくとも 12 種類の高度に最適化されたファネルが運用されています！

Web-to-App は、一夜にして成長をもたらす魔法の杖ではありません。自社アプリにとってのメリットとデメリットを踏まえたうえで、意識的に選択する必要があります。それでもなお、新しいオーディエンスを開拓し、アプリを成長させるための大きなチャンスを提供してくれるのは間違いありません。Web-to-App ファネルが急速に広がっているのには理由があります。すべてのアプリに適しているわけではありませんが、自社のアプリ内ファネルの代替、あるいは補完として、戦略的に Web-to-App をテストする価値があるかどうかは、すべてのアプリが一度は検討すべきでしょう。

Web-to-App ファネルに関するよくある質問

Web-to-App ファネルとは正確に何ですか？

ユーザーが Web 上（ランディングページ、クイズ、その他のフローなど）から体験を開始し、その後アプリをインストール、またはアプリ内でサブスクリプション登録に至る導線のことです。購入は Web 上で行われる場合もあれば、アプリ内で行われる場合もあります。

なぜ今、アプリは Web-to-App に移行しているのですか？

2021 年に Apple が App Tracking Transparency（ATT）を導入したことで、アトリビューションが難しくなりました。一方で Web ファネルは、よりクリーンなトラッキング、速い改善サイクル、価格やメッセージの高い自由度、そしてより高い LTV の可能性を提供します。そのため、Web-to-App に注目が集まっています。

Web-to-App は必ずコスト削減になりますか？

必ずしもそうではありません。Web の手数料は低め（平均で約 5〜6%、アプリストア経由では 15〜30%）ですが、コンバージョン率が下がる可能性や、追加ツールの導入が必要になる場合もあります。最終的な金銭的メリットは、構成や運用方法によって大きく異なります。

Web-to-App ファネルを立ち上げるのに開発者は必要ですか？

必ずしも必要ではありません。ノーコードの Web ファネルやランディングページビルダーを使えば、最小限のエンジニアリング支援でテストを始めることが可能です。ただし、ダウンロード後のリダイレクトや共有ログイン、ディープリンクの設定などには、開発者のサポートが必要になる場合があります。

Apple は Web-to-App ファネルを認めていますか？

はい。Web-to-App ファネルは以前から認められています。さらに 2025 年の Epic 判決以降、米国ではアプリから外部の購入オプションへリンクすることも可能になりました。

どのようなアプリが Web-to-App ファネルの恩恵を受けやすいですか？

Web に慣れたユーザー層を持つアプリ、価格帯が高めのアプリ、あるいはオンボーディングが比較的複雑なアプリ（ヘルスケア、教育、プロダクティビティ系など）は、特に高い成果を出しやすい傾向があります。

現在、RevenueCatのプロダクトマネジメントチームは6名のプロダクトマネージャー（PM）で構成されており、複数のポジションを募集中です。さらに、2026年に向けて今後も採用を進めていく予定です。そこで本記事では、RevenueCatでPMとして働くとはどういうことなのか、ここで成功するPMに求められるもの、そして私たちが直面している課題について、少し詳しくご紹介したいと思います。

RevenueCatのプロダクトが特別である理由

プロダクトマネージャーとして関われるプロダクトには、（あなたの両親も知っているような）誰もが使うコンシューマー向けプロダクトから、特定の業界に詳しくないと理解が難しいニッチなプロダクトまで、さまざまなものがあります。RevenueCatは間違いなく後者に属しますが、それでもなお、非常に特別なプロダクトだと私たちは考えています。

難解な課題、しかし大きなインパクト

RevenueCatの大きな特徴のひとつは、非常に複雑で、やや専門的な課題を解いている点にあります。アプリ内課金のペイロードに含まれる各フィールドが何を意味しているのか、Apple・Google・Stripeそれぞれでどのようなエッジケースが存在するのか、そしてそれらをどう扱うのが最適なのか——これらを正しく理解し、実装するのは複雑で、決して華やかな仕事ではありません。

私たちはよく「痛みを食べて生きている（eat pain for a living）」と言います。つまり、開発者が直面するつらくて厄介なインフラの問題を、私たちが代わりに引き受けて解決している、という意味です。それだけでも、RevenueCatは取り組みがいのある複雑なプロダクトだと言えます。かし、それ以上にこの仕事を意味あるものにしているのは、その先にある理由です。私たちは、アプリ開発者が自分たちのアプリをマネタイズできるよう支援しています。なぜなら……

• 私たちは、（平均すれば）より多くのソフトウェアが世界にとってプラスになると信じている
• 人々がソフトウェアを作り、それで生計を立てられるようにすることこそが、人類がより多くのソフトウェアを生み出すための最良の方法だと信じている

こうした考えに共感できるなら、RevenueCatは非常にやりがいのあるプロダクトです。私たちが解決している課題は、何万人もの開発者がアプリをマネタイズする手助けにつながっているからです。

RevenueCatのメンバーの多くは、アプリ開発のバックグラウンドを持っていたり、今でも個人でアプリをApp StoreやGoogle Playに出していたりします。だからこそ、私たちは顧客が直面している課題や、業界にもたらしている価値を実感をもって理解できます。実際に同じ立場を経験してきたからこそ、それができるのです。ここが、私たちのユニークな点でもあります。

お客様に愛されているプロダクト

RevenueCatには、多くのファンがいます。もちろん、すべてのお客様がファンというわけではありません。中にはプロダクトに対して正当な不満を持っている方もいますし、日々の業務で使う単なるツールのひとつとして捉えている方もいます。それでも、「アプリを作る」という自分の好きなことを仕事として成り立たせる手助けをしてくれる存在として、RevenueCatを心から気に入ってくれているお客様が数多くいるのも事実です。

カンファレンスで、わざわざブースを訪れてアプリについて話しかけてくれるお客様に出会ったり、App Growth Annualに参加した人たちから声をかけてもらったりすると、自分たちが携わっているプロダクトが愛されていることを実感できます。また、お客様が初めてのRevenueCat請求書について誇らしげにSNSへ投稿してくれるのを、私たちはよく目にします。これは、無料プランの枠を超え、アプリから実際に収益を得られる段階に到達したことを意味します。お客様がここまで喜んで「お金を払いたい」と思ってくれるプロダクトは、そう多くありません。

こうしたフィードバックは、RevenueCatで働くことを非常にやりがいのあるものにしてくれますし、課題に直面しているお客様をさらに支援したいというモチベーションにもつながっています。

ビジネスと顧客のインセンティブが一致していること

先ほど触れた「最初の請求書」にも関連しますが、RevenueCatとそのビジネスモデルの大きな特長のひとつは、私たちのインセンティブが顧客のインセンティブと完全に一致している点にあります。RevenueCatは、顧客の収益に対する一定割合を料金としていただいています。つまり、お客様が成長すれば私たちも成長し、お客様が収益を上げれば私たちも収益を得るという関係です。

これほど純粋なビジネスモデルは、そう多くありません。私たちは心からお客様の成功を願っています。なぜなら、お客様が成功すれば、私たちも成功するからです。両者のインセンティブが完全に揃っていることで、プロダクトの選択がビジネスとして成り立つかどうかの判断も、非常にシンプルになります。

数年前、私たちは料金体系を簡素化し、無料プランであってもエンタープライズプランであっても、すべての顧客が全機能にアクセスできる形に変更しました。これは、RevenueCatの収益が顧客の収益に比例して伸びる仕組みであるため、規模の大きな顧客ほど自然と多く支払ってくれるからです。また私たちは、成長のためのツールは、すべての開発者が等しく利用できるべきだと考えています。もし安価なプランの小規模開発者にそれらのツールへのアクセスを制限してしまえば、それは顧客の成長機会を奪うだけでなく、結果として私たち自身の成長可能性をも制限してしまうことになります。

さまざまなプロダクトの接点と、それぞれの課題

最後に取り上げたいプロダクトの大きな特徴は、RevenueCatが持つ複数の「接点（サーフェス）」と、それぞれに固有の（技術的な）課題です。

1. バックエンド：RevenueCatのバックエンドは、お客様にとってのミッションクリティカルなインフラです。お客様の収益ストリームを危険にさらさないために、何よりも信頼性を最優先する必要があります。また、非常に高いスケーラビリティも求められます。私たちのバックエンドは、毎日数十億件規模のAPIリクエストを処理しています。最も利用頻度の高いAPIエンドポイントは完全にキャッシュされていなければならず、そうでなければデータベースは一瞬で破綻してしまうでしょう。
2. SDKとAPI：SDKやAPIは、開発者がそれらを前提にアプリやバックエンドを構築するため、数年先まで安定して使い続けられる設計である必要があります。特にSDKについては品質のハードルが非常に高く、もし不具合のあるSDKがアプリに組み込まれてしまうと、そのアプリが更新されない限り、長期間にわたって問題が世の中に残り続ける可能性があります。
3. Webダッシュボード：Webダッシュボードでは、他の領域に比べてはるかに高い自由度でイノベーションや改善を行うことができます。そのため、試行錯誤を素早く回し、変更を非常に迅速にデプロイできる領域でもあります。
4. コンシューマー向けUI：近年、私たちはコンシューマー向けのUIも積極的に提供しています。Paywall、Customer Center、Webチェックアウト、Webカスタマーポータルなどは、すべてお客様の「その先のユーザー」が利用するものです。そのため、信頼感を与えるための高い完成度と洗練度が求められます。

プロダクトマネジメントへの取り組み方

RevenueCatにおけるプロダクトマネジメントのアプローチは、私たちの価値観とタレントビジョンの両方によって形作られています。RevenueCatのプロダクトマネジメントがどのように機能しているのかを理解するには、まず「何を作るか」をどのように決めているのかから説明する必要があります。

何を作るかを決める

RevenueCatでは、毎年プロダクト戦略を策定します。このプロダクト戦略が、翌年に注力すべき主要なフォーカス領域を定めます。基本的に、年次のプロダクト戦略は前年度の戦略を土台とした進化であり、革命的な転換や急激なピボットになることはほとんどありません。戦略はリーダーシップレベルで決定されますが、その策定プロセスにおいてPMは重要なインプットを提供します。

この戦略に沿って、チーム構成も見直します。RevenueCatでは比較的安定したクロスファンクショナルチームを採用しており、PMはエンジニアリングマネージャー（EM）のもとで働くエンジニアチーム、そしてデザイナーと協働します。

ロードマップは主に四半期ごとのプランニングプロセスで決定されます。このプロセスはこれまで何度も改善を重ねてきましたが、現在は以下のような流れで進めています。

各チームは、PM・EM・デザイナーを代表として、そのチームの優先事項案を提示します。それらはリーダーシップ（CEO、CTO、Head of Product）とともにレビュー・議論されます。この議論の中でロードマップに一定の調整が入ることはありますが、基本的には各チームが自らのロードマップと優先順位にオーナーシップを持ちます。このプロセスにおいて、PMは非常に重要な役割を果たします。多くの場合、PMは自分の担当プロダクト領域について最も俯瞰的な視点を持ち、プロダクト改善を通じてどのような価値を顧客に届けられるかを最も深く理解している存在だからです。

日々、そして週単位の業務においても、PMはEMやデザイナーと密に連携します。少なくとも週1回の定例ミーティングに加え、非同期コミュニケーションを通じてさらに頻繁にやり取りを行います。チーム内での機能の発見（ディスカバリー）と提供（デリバリー）はチーム全体の責任であり、緊密なコラボレーションによって実現されています。

プロダクトマネジメントにおける価値観の体現

前述のとおり、RevenueCatのプロダクトマネジメント組織を形づくるもう一つの要素が、会社としての価値観です。これらはNotionのドキュメントに書かれて放置されているような理念ではありません。日々の仕事の中で意識的に実践し、判断や行動の基準として自分たちを照らし合わせ続けている“生きた精神”です。

カスタマーオブセッション（顧客への徹底したこだわり）

RevenueCatでは、何よりもまず顧客に価値を届けることを最優先に考えています。この考え方は、私たちのプロダクトマネジメントの進め方にも明確に表れています。

• PMは顧客と頻繁に対話することが期待されています：1対1の会話やユーザーリサーチのインタビューに限らず、サポートチケット、SNS上の投稿、セールスとの会話、顧客と共有しているSlackチャンネル、カンファレンスのブースでの立ち話まで、あらゆる接点が含まれます。
• PMと顧客の間に壁はありません：より良いプロダクト判断につながるのであれば、誰の許可も必要ありません。必要だと思った会話は、すぐに設定します。
• 顧客の実体験は、プロダクト判断において非常に強い説得力を持ちます。もちろん、顧客からの要望をすべてそのまま作るわけではありません。しかし、その背後にある本質的なニーズや未解決の課題を見極めることを重視しています。一般的に、わざわざ課題や不満を伝えてくれる顧客は、それだけプロダクトを大切にしている存在です。だからこそ、耳を傾ける価値があると考えています。
• 問題の大きさに関わらず、顧客の声に向き合います。私たちにとって戦略もロードマップも重要ですが、顧客が遭遇したバグを素早く修正したり、使う上での制約を一つ取り除いたりすることで、「気にかけてもらえている」と感じてもらえることがあります。そうした小さな対応が、疑念を持っていたユーザーをファンに変え、やがてはプロダクトを広めてくれる存在（エバンジェリスト）へと変えていくことも少なくありません。

Always be shipping（常にShip続ける）

「Always be shipping」は、プロダクトマネジメントにおける私たちの姿勢に強く影響しています。具体的には、計画している内容のスコープを常にMVP（最小実用プロダクト）まで削ぎ落とすことを後押しします。その理由は主に次の2つです。

1. 顧客に価値をより早く届けられること
2. できるだけ早い段階で、顧客からのフィードバックや検証を得られること

Ship-or-dies（四半期ごとの必達リリース）

本当に「Always be shipping」を実践し、スコープを最小化するための仕組みのひとつが、社内の明確な締切設定です。私たちが採用している主な仕組みが、四半期ごとの全社的な出荷目標である「ship-or-dies」です。

ある取り組みが ship-or-die に指定されると、四半期末までに必ず出荷するために、あらゆる手段を講じます。必要であればリソースを追加し、チームのスピードを上げます。その一方で、多くの場合、痛みを伴うスコープ削減も迫られます。「必須（must-have）」だった要素を「あれば嬉しい（nice-to-have）」に落とす判断をすることもあります（ソフトウェア開発を知っている方なら分かる通り、これは往々にして「結局やらない」ことを意味します）。

興味深いのは、機能をリリースして実際に顧客の手に渡ったあと、最初に寄せられる要望が、後回しにした部分ではないことが多いという点です。むしろ、まったく別の点に関するフィードバックが来ることがよくあります。これは、素早く出荷する価値を如実に示しています。私たち自身も、顧客自身も、機能が実際にプロダクト内で使われ始めるまで、どのように使われるかを正確に予測することはできません。それを知るための唯一確実な方法は、早く出して、その後に改善を重ねることです。

Bias for action（行動バイアス）

「Always be shipping」を支えるもう一つの重要な要素が、行動を優先する姿勢（bias for action）です。私たちは常に、不完全な情報の中で意思決定をしています。完璧な情報が揃うのを待っていたら、何も決められなくなってしまいます。だからこそ、RevenueCatのプロダクトマネージャーには、不確実性がある中でも意思決定を前に進める責任があります。ほとんどの判断は、後から修正することが可能です。終わりのない議論よりも、前進することを選ぶ。話すより、動く（Act, don’t talk）——それが私たちのスタンスです。

Own it（当事者意識を持つ）

RevenueCatでは、オーナーシップを非常に重視しています。プロダクトマネージャーにとってそれは、「誰かの問題」というものは存在しない、という意味です。私たちは一緒に勝ち、一緒に負けます。もし問題に気づいたら、それが自分の担当領域でなくても、何か行動を起こすことが求められます。

もちろん、プロダクトマネージャーがすべての問題を自分で解決しなければならない、ということではありません。ただしPMは、顧客の課題から解決策の設計、技術的なアプローチまでを横断的に理解している立場であることが多く、結果として問題にいち早く気づける存在でもあります。そして、そのこと自体が期待されています。

RevenueCatのプロダクトマネージャーは、高いエージェンシー（主体的に状況を変えられる力）を持っています。私たちは、困難な状況であっても変化を起こせると信じています。PMは、目の前の問題に対処するためにできる限りのことを行い、ときにはそれ以上のこともします（たとえば、より良く解決するために新しい知識を学ぶなど）。コードベースを掘り下げてバグの根本原因を探ったり、データをより深く理解するためにデータウェアハウスへクエリを投げたり、顧客の課題をデバッグするために急きょ通話に入ることもあります。

また、AI支援開発の進展により、プロダクトマネージャー自身がコードベースに直接貢献する場面も、今では珍しくありません。変更内容が比較的シンプルな場合、エンジニアにチケットを切って対応してもらうよりも、PMが Cursor や Claude Code を使って自ら修正し、レビューを経てそのまま出荷するほうが、はるかに速いことも多くあります。

まとめると：やることはたくさんあります。そして、これはまさに 全員総出 の仕事です。

Balance（バランス）

私たちのバランスという価値観は、おそらく最も誤解されやすいものです。これは「手を抜く」という意味ではありません（むしろその逆で、RevenueCatはいまもスタートアップであり、ここでの仕事は意図的にハードです）。私たちは、スピードを維持し続けてこそ勝てると考えています。

一方で、このバリューは「速く進むこと」と「燃え尽きること」のあいだには、非常に細い境界線があることも思い出させてくれます。意欲の高い人たちとチームを組み、面白く価値のある課題に取り組めているとき、ハードワークは大きなやりがいになります。プロダクトマネージャーは、チームのモチベーションや関心を保つうえで重要な役割を担うことが多く、解いている課題と顧客へのインパクトを結びつけて伝える責任があります。たとえば、顧客からのポジティブな声（いわゆる “good feels”）を共有したり、周囲に伝播するようなワクワク感を示したりすることです。

また、Balance には、他者への共感や思いやり、そして互いを一人の人間として尊重し合える、信頼に基づいたチーム環境を築くことも含まれています。プロダクトマネージャーは、自然とリーダー的な立場に立つことが多いため、こうした振る舞いを自ら体現し、周囲に広げていく上で重要な役割を果たします。

RevenueCatのタレント・ビジョン

RevenueCatのタレント・ビジョンは、高い能力を持つメンバーによる「勝てるチーム」をつくることです。そのため、すべてのチームメンバーに高い基準を設けており、採用やパフォーマンスマネジメントのプロセスを通じて、その基準を維持しています。

この考え方は、私たちのプロダクトマネジメントの進め方にもいくつかの影響を与えています。まず、RevenueCatのチームは、比較的シニアでプロダクト志向のエンジニアやエンジニアリングマネージャーで構成されています。そのため、RevenueCatのPMは、プロジェクト管理の細部に深く入り込んだり、非常に詳細なチケットを作成したりする必要はあまりありません。むしろ、必要な背景情報や課題空間の理解を的確に伝えることが求められます。そうすることで、エンジニアがPMの意思決定によってボトルネックになることなく、スムーズに開発を進められるようになります。

また、このタレント・ビジョンは、チームが比較的リーンであることも意味しています。私たちは、才能の基準が低い大規模チームよりも、高い能力を持つ少人数のチームの方が、はるかに速く動けると信じています。

プロダクトマネジメント組織が直面している主な課題

ここでは、RevenueCatのプロダクトマネージャーとして私たちが直面している主な課題を紹介します。

やるべきことが多すぎて、時間が足りない

これはスタートアップに共通する典型的な課題かもしれませんが、RevenueCatでもまさにそのとおりです。私たちは常に、取り組みたいアイデアや解決すべき顧客課題を、実際に対応できるキャパシティ以上に抱えています。そのため、会社としても、各チームとしても、そしてPM個人としても、適切に優先順位を付け、その判断を市場、顧客、社内ステークホルダーにきちんと伝える必要があります。この課題に対しては、戦略策定とプランニングのプロセスを通じて、常に最もインパクトの大きい機会に集中できるようにしています。

カスタマー・オブセッションと戦略的優先度のバランス

上記の優先順位付けとも密接に関係していますが、私たちはしばしば、「顧客第一主義」と「戦略的な優先事項」という2つの力に引っ張られます。戦略的な取り組みは成果が出るまでに時間がかかることが多い一方で、カスタマー・オブセッションという価値観は、比較的小さな顧客リクエストにも緊急性を感じさせます。どちらか一方に極端に寄りすぎるのは望ましくありません。長期的な戦略を優先するあまり顧客の声を後回しにすれば、反応が鈍いと見なされ、これまで築いてきた顧客からの信頼や愛着を失うリスクがあります。一方で、顧客要望への対応だけを最優先してしまうと、大きな勝負に出る機会や、市場の変化に乗るチャンス、プロダクトや会社の次の成長を切り開く機会を逃してしまいます。

成長は、調整コストの増加を意味する

RevenueCatはここ数年、非常に良い成長曲線を描いてきました。チームの成長は売上の伸びほど速くはありませんが（これも「勝てるチーム」というタレント・ビジョンの一部です）、それでも確実に拡大しており、今後も成長を続ける予定です。EPD（Engineering, Product & Design）チームが大きくなると、プロダクト改善のためのキャパシティは増えますが、その一方で調整や連携に必要なコストも増加します。エンジニアリングチームを2倍にしたからといって、出荷できる変更が単純に2倍になるわけではありません。一部のリソースは、必ず調整作業に使われるからです。また、チームが増えることで、プロダクトの各所で一貫性のない体験が生まれるリスクも高まり、それを防ぐためにもさらなる調整が必要になります。

マルチプロダクト企業への転換

私たちが直面している最大の戦略的課題は、シングルプロダクトの会社からマルチプロダクトの会社へと移行することです。RevenueCatは長年にわたり、「アプリにアプリ内課金を実装するための最良の方法」であり続けてきました。その結果、現在では多くのサブスクリプションアプリが、立ち上げ時からRevenueCatを利用しています。しかし、新規サブスクリプションアプリの市場自体には限りがあります。

今後も成長を続けるためには、既存のターゲット市場に対してより多くの価値を提供することと、現在のRevenueCatプロダクトが必ずしも最適ではない顧客にもリーチできるようにすることの両方が必要です。そのためには、マルチプロダクト企業になることが不可欠です。まったく新しいプロダクトを追加するか、既存プロダクトを分解して個別に販売できる形にするか、その両方を検討しています。

これには、プロダクト意思決定のプロセスそのものを根本的に見直す必要があります。プラットフォームの一部だけを使う場合でも意味のある体験を設計し、適切な価格設定や課金モデルを整え、正しいプロダクトにたどり着き、セットアップできるオンボーディングフローを考えなければなりません。

この取り組みはまだ始まったばかりで、当面の間、私たちを忙しくさせ続けることになるでしょう。

RevenueCatにおける「良いPM」とは

ここまで読んでくれましたか？ では、RevenueCatでプロダクトマネージャーとして活躍できる人の特徴について見ていきましょう。もしかすると、あなた自身が当てはまるかもしれませんし、思い当たる誰かがいるかもしれません。

• マネージャーではなく、ビルダー：RevenueCatのPMは、自分たちを「プロダクトを作る人」だと捉えています。バックログを管理したり、ステークホルダーの調整に追われたりするのが役割ではありません。チームと協働し、最善の解決策を提案し、チームがより速く前に進めるよう支援します。
• ミッショナリー：私たちのミッションは「開発者がより多くの収益を得られるようにすること」です。PMはこのミッションを心から受け入れています。より多くのソフトウェアが世界にとって良いものであり、開発者が成功すれば、より多くのソフトウェアが生まれると信じているからこそ、私たちは顧客に徹底的に向き合います。
• 徹底したオーナーシップ：RevenueCatのPMは、顧客の課題を解決し、プロダクトを成功させるために必要なことはすべてやります。誰かを責めたり、責任を転嫁したり、失敗を受け入れて終わりにすることはありません。孤軍奮闘するのではなく、真のチームメンバーとして責任を分かち合いながら、前に進む道を見つけます。
• 不完全な情報でも決断できる：スピード感のあるスタートアップでは、完璧な情報がそろうことはほとんどありません。RevenueCatのPMは、意思決定に十分な最低限の情報を集め、素早く判断します。現時点のデータに基づいて行動し、チームを巻き込みながら前進します。そして、新しい情報が入れば、必要に応じて方向転換する柔軟さも持ち合わせています。
• 深い技術的理解：RevenueCatは複数のペルソナに向き合うプロダクトですが、その本質は「開発者向けツール」です。そのためPMには、API、分散システム、SDKの制約、データモデルといった技術的な意思決定を理解し、説明し、評価できるレベルの深い技術知識が求められます。
• 非同期コミュニケーションに強い：RevenueCatはグローバルなフルリモートチームです。そのためPMは、ドキュメント、Loom、FigJamなどを使った明確で分かりやすい非同期コミュニケーションに長けています。同時に、チームの認識を揃えるために、いつリアルタイムの会話に切り替えるべきかも理解しています。

採用中です！

RevenueCatでは、プロダクトマネジメントチームをほぼ継続的に拡大しています。意味のあるインパクトを持つ難しい課題を解くことが好きな「ビルダー」で、何万人もの開発者が自分の好きなこと（アプリ開発）で生計を立てられるよう支援したいと考えている方であれば、ぜひお話ししたいです。 現在募集中のポジションは、キャリアページからご確認ください！

この変化の背景には、米国における Epic Games 対 Apple の訴訟や、EU の デジタル市場法（DMA） といった司法判断・規制があります。これらによって、Apple と Google は、アプリ内課金（IAP）をめぐる厳格な要件を緩和せざるを得なくなりました。

アプリチームにとって、これはApp-to-Webの新たな可能性を切り開くものです。しかし一方で、App-to-Web を取り巻く規制は決して単純ではありません。ガイドラインは国やアプリのカテゴリごとに異なり、しかも継続的に追加・変更されているため、「何が許可されていて、何が許可されていないのか」を把握し続けるのは容易ではありません。

そこで本記事では、Apple App Store と Google Play Store の両方について、世界各国における外部決済の最新オプション、利用要件、そして手数料・コミッション体系を整理しました。以下で、知っておくべきポイントをすべて解説します。

App-to-Webにおける外部決済の仕組み

ここでは、外部決済がどのように機能するのか、そしてそれをアプリに組み込む主な 2 つの方法について、簡単に整理します。

Apple と Google の購入ガイドラインをすぐに確認したい場合は、こちらをクリックしてください。

1. 外部Webリンク

アプリ内にリンクやボタンを設置し、ユーザーを外部の Web サイト（または WebView）へ遷移させて、そこで購入を完了させる方法です。購入後は、通常バックエンドとの同期によって、その外部購入に基づいてアプリ内のコンテンツや機能をアンロックします。

Apple では、これを External Purchase Link の利用と呼びます。たとえば、あるストリーミングアプリでは「Web サイトでサブスクライブする」といったボタンを設け、タップすると Web のチェックアウト画面が開くようになっています。支払いが完了すると、ユーザーは新しいサブスクリプションでアプリにログインできる、という流れです。

2. サードパーティ決済（アプリ内）

Apple や Google 以外の決済ゲートウェイを、アプリの UI に直接組み込む方法です。購入自体はアプリ内で完結しますが、App Store / Google Play の課金システムは使用しません。これは 代替アプリ内決済（alternative in-app payment） と呼ばれることもあります。

代表的な例としては、アプリ内課金に Stripe を利用したり、App Store の購入ダイアログの代わりに、国別のクレジットカード入力フォームをチェックアウト画面に表示したりするケースがあります。

以前は実装のハードルが非常に高い方法でしたが、Epic Games 対 Apple の判決以降、サードパーティ決済は以前よりも使いやすくなりました。ただし、どちらの方法を選ぶ場合でも、Apple と Google には厳格なルールがあります。

Apple でサードパーティ決済を実装する場合

• いかなる外部購入フローを提供する場合でも、事前に Apple の特別なエンタイトルメントを申請する必要があります
• 実装内容に応じて、以下のいずれかを使用します
• ユーザーを Web チェックアウトへ誘導する場合
• アプリ内でサードパーティ決済フローを実行する場合
• ユーザーがアプリを離れる、または Apple 以外の方法で支払いを行う前に、Apple が用意した開示用のシートが表示され、App Store で処理される購入ではないことが明示されます
• 場合によっては、外部購入エンタイトルメントを使用すると、同じ地域・同じストアフロント内で Apple IAP を同時に提供できないことがあります。つまり、そのストアではどちらか一方のみ、という扱いになります

Google でサードパーティ決済を実装する場合

• User Choice Billing により、チェックアウト時に Google Play の課金と代替決済手段のどちらかをユーザーが選択できるようになります
• この選択肢を提示するために、開発者は Google の代替課金 API を統合する必要があります
• External Offers（EEA のみ） では、アプリから直接購入用の Web ページへリンクアウトできます（タップ時に Google から「Play を離れます」という確認表示が出ます）
• Apple と同様に、通常の Google Play Billing IAP と外部オファーを同一アプリ内で併用できないケースもあります

アプリ内課金と外部購入の違い：Apple と Google のガイドライン・規制

Apple App Store および Google Play Store 上のほとんどのアプリは、サブスクリプションやデジタルコンテンツの購入に、各プラットフォームが提供する 標準の課金システム を利用しています。原則として、以下で説明する外部購入プログラムのいずれかに 該当し、かつオプトインしていない限り、アプリ内から別の支払いフローへユーザーを誘導することは認められていません。

通常のアプリ内課金（IAP）では、各ストアが手数料を徴収します。Apple と Google Play の標準手数料はいずれも 30% ですが、IAP 収益が年間 100 万ドル未満の開発者 に対しては 15% に引き下げられます。さらに Google Play では、サブスクリプションの2年目以降の更新分 にも 15% の料率が適用されます。

これらの手数料を回避するために、アプリは 外部購入 を提供することが可能ですが、その場合は以下のガイドラインを遵守する必要があります。

Apple App Store における外部購入のガイドライン

Google Play Store における外部購入ガイドライン

アプリに Web チェックアウトを追加する

ここまで読み進めているのであれば、App-to-Webの価値についてはすでに納得しているはずです。難しいのは「なぜやるか」ではなく、どうすれば迅速にリリースでき、コンプライアンスを守りつつ、購入フローを過度に複雑化させずに実装できるかという点です。

RevenueCat Web は、サブスクリプションアプリに Web チェックアウトを追加するための最もシンプルな方法です。 決済プロバイダー、エンタイトルメント同期、ユーザー識別の紐付け、アナリティクスを個別に組み合わせて構築する必要はありません。すでにモバイルで利用している RevenueCat の構成に、そのまま接続できる 完全な Web 課金スタックを利用できます。ユーザーは Web 上で購入し、iOS や Android アプリですぐにアクセスを解放できます。サブスクライバーのレコードは 1 つ、信頼できる単一のデータソースも 1 つです。

以下は、全体の構成イメージです：

課金エンジンとしての Web Billing： Web Billing は、Web サブスクリプション向けに提供される RevenueCat ネイティブの課金エンジンです。Web 上でのサブスクリプションライフサイクルを管理し、RevenueCat のプロダクト、顧客、エンタイトルメントと完全に統合された状態を保ちます。Web 用に別の課金ロジックを構築・運用する必要はありません。

数分で立ち上げられる Web チェックアウトの表示方法：Web Billing を有効にすると、複数の方法でユーザーを Web チェックアウトへ誘導できます。

• アプリ内ペイウォールに Web Purchase Button を追加：任意の RevenueCat Paywall にボタンコンポーネントを追加できます。タップすると Web チェックアウトへ遷移します。
• Web Purchase Links：RevenueCat がホストするチェックアウト用 URL です。Web Purchase Button の遷移先として使うこともでき、どこにでも配置可能です。追加設定なしで動作し、ログイン済み／匿名のどちらのフローにも対応します。
• Web SDK を使った Web ペイウォール表示：独自の Web アプリやランディングページがある場合、Purchases.js を使って Web サイト上に RevenueCat Paywall を直接表示し、そのままチェックアウトを完了できます。

すべてが一元的に連携。すべては自動的に連携された状態を保ちます。Web Overview ダッシュボードでは、Web とモバイルの状況を 1 か所で確認できます。Web とモバイルのオファリングは同じカタログ上に存在し、エンタイトルメントは自動で同期され、イベントは共通のアナリティクス基盤に流れ込みます。

App-to-Webでのコンバージョンを高く保つ方法

チームがよく懸念するのは、「Web を挟むとネイティブチェックアウトよりコンバージョンが下がるのではないか」という点です。しかし、購入を同一ページ内で完結できる Web ペイウォールにユーザーを送ることで、この問題は簡単に回避できます（いわゆる RevenueCat の Express Purchase ボタンです）。

ブラウザで Apple Pay や Google Pay が利用可能な場合、Web ペイウォール上にウォレットボタンが表示されます。ユーザーは 1 回タップし、ウォレットで確認するだけで購入が完了します。その後、RevenueCat が自動的にアプリ側へアクセス権を同期します。

この仕組みにより、ユーザー体験は非常にシンプルに： アプリ内ペイウォール → Web ペイウォール → ウォレット確認＝アクセス解放

App-to-Webの活用例

• Web オプション付きのアプリ内アップグレード：アプリ内ペイウォールに「Web で続行」ボタンを表示します。タップすると、同じプランが選択された状態で Web ペイウォールが開き、対応している場合はウォレットボタン（Apple Pay / Google Pay）が表示されます。より速いチェックアウトを求めるユーザーは、ワンタップで購入を完了できます。
• 復帰（Win-back）向けの割引オファー：解約済みユーザーに対して、カムバック割引を含むターゲット型のアプリ内ペイウォールを表示します。Web ボタンをタップすると、割引がすでに適用された専用の Web オファーに遷移するため、ユーザーが適切なプランを探し回る必要はありません。
• 計測可能なキャンペーントラフィック：UTM パラメータを保持したまま、広告やメールで Web Purchase Link を共有します。購入後はリデンプションのステップでサブスクリプションがユーザーのアプリ内アカウントに紐づけられ、即座にアクセスが解放されます。独自のグルーコードを実装することなく、クリーンなアトリビューションを取得できます。

App-to-Web の実験を始める準備はできましたか？

App-to-Web を取り巻くガイドラインは今後も変化し続けるため、チェックアウト体験を柔軟かつコンプライアンスに準拠した状態で保つことが、成功の鍵になります。Apple や Google がポリシーを更新するたびに、このガイドも継続的にアップデートしていく予定です。次の App-to-Web 施策を検討する際には、ぜひブックマークしてご確認ください。

独自にチェックアウトコードを実装して試す場合でも、RevenueCat Web に面倒な部分を任せる場合でも、App-to-Web は効率的で柔軟な購入フローを実現できます。健闘を祈ります。ぜひ積極的にテストしてみてください。

デモグラフィックは「誰か」を示し、行動データは「何をしているか」を示します。しかし、「いつか」を決めるのはコンテキストです。移動中のユーザーと、ソファでくつろいでいるユーザーとでは、Runnaのペイウォールに直面したときの意図はまったく異なります。

コンテキストとは、タイミング・動き・心理状態の組み合わせです。ユーザーが「コミットする準備ができている瞬間」を捉えることでもあります。そのタイミングは意図を劇的に左右します。同じユーザーであっても、ある瞬間には「今じゃない」と感じ、1分後には「今ならいける」と感じることがあるのです。すべてはコンテキスト次第です。

注意が絶えず移り変わり、トライアルの82%が初日に開始される世界では、正しいメッセージを間違った瞬間に出すことが、ファネル最大の漏れになっている可能性があります。

注意と意図がピークに達する、あの貴重な数ミリ秒でペイウォールを表示する方法を学びましょう。そうすれば、「今じゃない」を「サブスクライブ」へと変えることができます。

タイミングを誤ったペイウォールのコストと、従来型ペイウォール最適化の限界

毎日、何百万人ものユーザーが「間違った瞬間」にペイウォールに直面しています。電車に乗り遅れそうで急いでいるとき、騒がしい環境で集中しようとしているとき、あるいは単純にサブスクリプションを検討する気分ではないときです。その結果はどうなるでしょうか？フラストレーション、ネガティブなレビュー、そして失われる収益です（しかも、その多くはアプリ側で計測すらされていません）。

その摩擦が、ユーザーをファネルの外へと押し出してしまいます。

この摩擦を解消するために、多くの場合はペイウォールの最適化に取り組むはずです。一般的に、ペイウォール最適化といえば、デモグラフィックによるセグメント分け、シンプルな行動トリガー、そして大量の A/B テストを指します。しかし、この 2018 年型のアプローチは、もはや通用しなくなっています。State of Subscription Apps report 2025では、平均的なアプリとトップパフォーマーの間に、次のような顕著な差が示されています。

この差の多くは、ペイウォールをいつ表示しているかに起因しています。従来の最適化では、インストール初日のユーザーをすべて同じように扱います。通勤中であろうと、ベッドで横になっていようと、カフェでくつろいでいようと関係ありません。つまり、「いつ」という要素が無視されているのです。

では、ユーザーにとって適切なタイミングでペイウォールを表示するにはどうすればよいのでしょうか。その答えが、コンテキストターゲティングです。

ペイウォールターゲティングは、特定のセグメントに合わせてペイウォールやオファーを出し分けることを可能にしますが、そこにコンテキストを加えることで、ユーザーの状況・周囲の環境・その瞬間の行動にまで最適化できるようになります。

ターゲティングの第3の軸：ユーザーのコンテキスト

従来のペイウォール最適化は、インストールからの経過時間、利用した機能、デモグラフィック情報、基本的な利用パターンなど、せいぜい5〜10程度のデータポイントに依存しています。しかし、これらのデータだけでは、ユーザーがどんな人物で、どんな生活を送り、どのようにアプリと向き合っているのかを把握するには不十分です。そこで必要になるのがコンテキストです。

スマートフォンは、毎秒300以上ものコンテキストシグナルを生成しています。モーションデータ、端末の持ち方、バッテリー残量、周囲の明るさ、接続状況など、その種類は多岐にわたります。

人間のアナリストが同時に意味のある判断を下せる変数は、せいぜい3〜4個程度ですが、機械学習モデルであれば、300以上のシグナルをリアルタイムで分析し、ペイウォールを表示する最適な瞬間を特定できます。もちろん、コンテキスト対応の機械学習が人間の直感を置き換えるわけではありません。人間では処理しきれないスケールのリアルタイムデータによって、その直感を拡張するものです。

これらの追加的なコンテキストシグナルは、デモグラフィックや行動ベースのターゲティングを置き換えるものではありません。それらに第3の次元として加わり、ターゲティングの精度を大きく高めます。たとえば、25歳のビジネスパーソンが理想的な顧客属性だったとしても、会議に向かって移動中で通話をしながらバッテリー残量が5%の状態なのか、ソファでくつろぎながら充電中のスマートフォンでTikTokを眺めているのかによって、コンバージョンの可能性は大きく変わるのです。

モバイルゲームは、コンテキストターゲティングの効果が特に分かりやすい分野です。没入感は壊れやすく、ユーザーの時間は貴重で、押し付けがましいオファーはゲームのフローを簡単に途切れさせてしまいます。しかし、自然な区切りのタイミングにプロンプトを表示することで、ユーザーのエンゲージメントを損なうことなく、そのコンテキストに寄り添うことができます。その好例が、インディーパズルゲームの Blackbox です。同作は、ペイウォールに表示する「内容」を変えたのではなく、「表示するタイミング」を最適化しただけで、ピーク時間帯の収益が50%増加し、その後数か月にわたってコンバージョンの持続的な改善を記録しました。

ペイウォールのターゲティングを改善する9つの戦略（役割別）

ペイウォールを表示するタイミングは、返金率や初期チャーンといった下流指標にも影響します。トップアプリ（ダウンロードから有料化まで4.6%）と中央値のアプリ（1.9%）のパフォーマンス差は、価格や機能だけの問題ではありません。ユーザーが受け入れやすい瞬間にプロンプトが届いているかどうかが大きく関係しています。コンテキストを意識したタイミング設計を適切に使えば、コンバージョンとユーザー満足度の両方を向上させることができます。目的はペイウォールの表示回数を増やすことではなく、より良い瞬間に表示することなのです。

グロースチーム向け：コンテキストを活用したターゲティング戦略

グロースチームは、常に相反する優先事項の中で意思決定を求められています。今四半期の数字を達成しつつ、長期的なLTVを最適化し、CACの回収期間を短縮し、そのうえで意味のある実験も回さなければなりません。コンテキストを考慮したタイミング設計は、マネタイズファネル全体の効率を高めることで、こうした課題の解決を後押しします。

1. A/Bテストを見直す：変数は「タイミング」に置く

ペイウォールの表示位置に関するA/Bテストは、結果が出るまでに数週間かかるうえ、本当のリフト要因を見逃してしまうことが少なくありません。注目すべきはどこに出すかではなく、いつ出すかです。表示される「瞬間」に焦点を移し、複数のコンテキストやセグメントに対して小規模な並行実験を行いましょう。その際、必ず真のコントロール群を維持し、評価指標はデイゼロのコンバージョンだけでなく、コホートLTV、返金率、初期チャーンまで含めて判断することが重要です。

2. その瞬間に合ったプランを提示する

State of Subscription Apps Report 2025によると、1年後のリテンションはプラン種別によって大きく異なります（年額：約44.1%、月額：約17.0%、週額：約3.4%）。であれば、ユーザーのコンテキストに応じて提示するプランを変えるという発想は自然ではないでしょうか。

たとえば、夜の落ち着いた時間帯で、端末が静止しており、セッションも長くエンゲージメントが深い状況では、年額プランやライフタイムサブスクリプションを提示する。一方、移動中で短時間のセッションでは、週額や月額といった軽い選択肢を前面に出す。その有効性は、初回コンバージョンだけでなく、リテンションや返金行動を通じて検証すべきです。

3. あえて「出さない」ことで、より多くを獲得する

直感に反するように聞こえるかもしれませんが、グロースチームが取りうる最も強力な一手のひとつは、マネタイズの提示を抑制することです。たとえば、デーティングアプリのWizzでは、提示回数を約50%削減しつつ、受け入れやすいコンテキストに合わせてオファーを出した結果、主要オファーフローで81%のリフトを達成しました。

教訓はシンプルです。意図が低い状態では抑制し、総表示回数を増やすのではなく、表示する瞬間を再配分する。その結果、ユーザーは中断されている感覚が減り、コントロール感を持てるようになります。実際、上記の実験ではLTVも約20%向上しました。

プロダクトマネージャー向け：コンテキストを活用したターゲティング戦略

プロダクトマネージャーは、体験全体のオーナーです。すべてのマネタイズ施策は、「探索を促すこと」と「体験を中断すること」のトレードオフの上に成り立っています。だからこそ、タイミングを単なるルールではなく、プロダクトの一部として扱うことが重要です。そうすることで、ユーザーのフローを守りながら、意図（購入意欲）を的確に捉えることができます。

4. タイミングをUXの一部として設計する

優れたプロダクト体験は、まるでユーザーの心を読んでいるかのように、「必要なものを、必要なタイミングで」提示します。

単一のゲートで一律に制御するのではなく、コンテキストを理解するアプリでは、アクセスやプロンプトがその瞬間に応じて変化します。たとえばフィットネスアプリであれば、夜にベッドで横になっているユーザーと、ランニング中のユーザーとでは、適切な体験はまったく異なります。静止しているタイミングでは、プラン詳細を含むフルのアップグレード画面を表示する。一方、移動中であればワークアウト自体はそのまま続行できるようにしつつ、「アップグレードで◯％節約」といった軽いナッジだけを添える。同じ機能でも、タイミングを変えることで摩擦は大きく減らせます。

5. コンテキストを尊重したプログレッシブ・ディスクロージャー

意思決定は、ユーザーがそれに向き合える状態のときに提示しましょう。明らかに検討余地の低い状態（Appleの運転集中モード中、通話中、海外滞在中など）ではあえて表示を控え、セッションが長くなったり、動きが落ち着いたり、エンゲージメントが深まったタイミングでフォローします。これは機会を減らすことではありません。機会を「ふさわしい場所」に配置しているだけです。

6. 「このアプリ、わかってる」と感じさせる瞬間を設計する

プロダクト体験の究極形は、ユーザーに「このアプリ、自分のことをちゃんとわかってる」と思ってもらえる瞬間を生み出すことです。こうした瞬間はロイヤルティを高め、口コミを生み、LTVを押し上げます。たとえば、朝のルーティン中である7時に5分間の瞑想セッションを提案し、夜ベッドに入った10時には睡眠用トラックを勧めてくる瞑想アプリは、ユーザーの生活に自然に寄り添っていると感じられます。まるで最初からそう設計されていたかのように。

ただし、時間は数あるシグナルのひとつにすぎません。セッションの深さ、ユーザーの動き、バッテリー残量、接続状況などを組み合わせて、「いつ」「何を」提示するかを判断することが重要です。こうした小さくても適切な判断を積み重ねることで、信頼が築かれ、アップグレードの提案も“割り込み”ではなく、体験の一部として受け取られるようになります。

技術リーダー向け：コンテキストターゲティング戦略

エンジニアリングリーダーが問うのは、「動くかどうか」だけではありません。「信頼できるか」「スケールするか」「継続的に保守できるか」という視点も欠かせません。

コンテキストを考慮したターゲティングは大きな価値をもたらしますが、新しい仕組みを導入する際は、複数の観点から評価することが重要です。具体的には、実装の複雑さ、保守コスト、スケーラビリティ、プライバシーへの影響、そしてプロダクト全体の戦略との整合性といった点を総合的に検討する必要があります。

7. 既存のデバイスシグナルを活用し、権限リクエストを最小限に抑える

多くの有用なシグナルは、新たな権限リクエストを必要とせず、標準APIから取得できます。たとえば、時刻、バッテリー残量、デバイスの向き、ネットワーク種別、画面の状態などです。

一方で、特定のモーションデータやフィットネスデータの取得にユーザーの同意が必要な場合は、その境界を尊重し、段階的に機能を縮退（graceful degradation）させる設計が重要です。権限の取得範囲を広げなくても、意味のあるコンテキストは十分に得られます。

8. レイテンシ・コスト・信頼性を考慮したオンデバイス推論

Core ML や ML Kit を用いてモデルをオンデバイスで実行することで、意思決定をユーザーの手元に近づけられます。レイテンシはミリ秒単位まで短縮され、セッション中にリアルタイムでタイミングを調整できます。また、中央サーバーではなく端末側で処理を行うため、サーバーコストを抑えられる点も大きな利点です。ネットワーク往復に依存しないため、Wi-Fi・モバイル通信・オフライン環境でも動作し、信頼性も向上します。

9. リリースと実験を切り離す

アプリのリリースにタイミング変更を含めると、実装、QA、審査、ストア承認、ユーザーへの配布といった工程がボトルネックになり、単純なテストでも数週間かかることがあります。

そこで、リモート設定やペイウォール管理機能を活用し、タイミングルールやモデル更新をOTA（Over-the-air）で配信しましょう。指標が悪化した場合はロールバックも可能です。この方法であれば、パフォーマンスの低いモデルをアプリ更新なしで24時間以内に検知・修正できます。 結果として、プロダクトチームはコア機能の開発に集中でき、マネタイズ施策は設定レベルで安全に高速イテレーションを回せるようになります。

直感を超えて：コンテキストは「標準」になる

手動による従来型のペイウォール最適化は、すでにパフォーマンスの限界に達しています。最も成果を出しているアプリでさえ、ダウンロードから有料化への転換率は5%未満にとどまっている現状を考えると、改善の余地はまだ非常に大きいと言えます。その解決策となり得るのが、コンテキストインテリジェンスです。

現在、全体の35%のアプリがサブスクリプションに加えて消耗型課金やライフタイム購入を組み合わせており、AIアプリはすでに他カテゴリを上回る成果を出しています。アプリの未来はハイパーパーソナライゼーションにあり、ペイウォールターゲティングの進化の方向性も明確です。

• 2020–2022：ペイウォールの文言や表示位置に対する基本的なA/Bテスト
• 2023–2025：行動データやデモグラフィックに基づくターゲティング
• 2026年以降：機械学習によるリアルタイムなコンテキスト最適化

ハイパーパーソナライゼーションが当たり前になるにつれ、ペイウォール最適化の成否は「何を見せるか」から「いつ見せるか」へと重心が移っていきます。セッションが短く、ユーザー獲得コストが高騰するモバイル環境においては、デザインやコピーを微調整すること以上に、ユーザーの意図と合致したタイミングでペイウォールを表示することが、成果を左右する決定的な要因になるのです。

この記事では、マルチラインサブスクリプションとは何かを整理したうえで、その効果的な活用戦略を紹介し、Play Billing Library を直接使った実装方法を順を追って解説します。最後に、RevenueCat を使うことで、この一連のプロセスをどのようにシンプルにできるのかを見ていきます。

マルチラインサブスクリプションとは？

Subscription with Add-ons とは、複数のサブスクリプション商品を 1 つにまとめ、単一のサブスクリプションとして購入・請求・管理できるようにする機能です。ベースとなるサブスクリプションと追加のプレミアム機能を、それぞれ別々に購入させる必要はなく、すべてを 1 回のチェックアウトフローで提供できます。

たとえば、ベースとなる「Premium」プランを提供している音楽ストリーミングアプリを考えてみましょう。これまでは、「HiFi オーディオ」や「オフライン再生」といった追加機能を有料アドオンとして提供する場合、ユーザーはそれぞれを個別に購入・管理する必要がありました。その結果、決済は複数回に分かれ、更新日もバラバラになり、サブスクリプション管理画面には複数の項目が並ぶことになります。Subscription with Add-ons を使えば、ユーザーは「Premium」プランをベースに、必要なアドオンを自由に組み合わせて選択し、1 回の購入で完了できます。表示される価格は 1 つにまとまり、チェックアウトも 1 回だけ、更新日はすべて同一の日付に同期されます。

なお、用語は少し分かりづらいかもしれません。Google では正式名称として 「Subscription with Add-ons」 を使っていますが、1 回の購入に複数の明細（ラインアイテム）が含まれることから 「マルチラインサブスクリプション」、あるいはチェックアウト体験に焦点を当てて 「マルチプロダクトチェックアウト」 と呼ばれることもあります。いずれも、同じ機能を指しています。

バンドルの仕組み

ユーザーが Subscription with Add-ons を購入すると、商品リストの先頭にあるアイテムがベースアイテムとなり、それ以降に続くすべてのアイテムはアドオンとして扱われます。この区別は重要で、ベースアイテムがバンドル全体の挙動を決定します。たとえば、ベースとなるサブスクリプションが解約されると、紐づいているすべてのアドオンも自動的に解約されます。アドオンは、ベースサブスクリプションなしでは単独で存在することはできません。

請求サイクルの調整といった複雑な処理は、Google Play が自動的に行います。既存のサブスクリプションに新しいアドオンを追加した場合、Google Play はアドオンの更新日がベースアイテムと一致するように、日割り計算による請求額を算出します。その結果、最初の調整期間が終わると、バンドル内のすべてのアイテムが同じ更新日にまとめて更新されるようになります。同様に、ユーザーがアドオンを削除した場合でも、そのアドオンは現在の請求期間の終了までは引き続き利用できますが、次回の更新は行われません。

理解しておくべき主な制約

実装に進む前に、この機能の使い方を左右する重要な制約がいくつかあります。

1. すべてのアイテムは同一の請求期間である必要があります。Subscription with Add-ons に含めるすべてのアイテムは、同じ請求期間でなければなりません。年額のベースサブスクリプションに月額のアドオンを組み合わせる、またはその逆はできません。ベースプランが月額課金の場合、すべてのアドオンも月額である必要があります。これは、Google Play がすべてのアイテムの更新日を同期させる必要があるためです。
2. 自動更新サブスクリプションのみ対応しています。この機能は自動更新型サブスクリプションでのみ利用できます。期間が固定され、自動更新されないプリペイドサブスクリプションは、ベースアイテムとしてもアドオンとしても使用できません。
3. 1 回の購入あたり最大 50 アイテムまでという上限があります。Subscription with Add-ons の 1 回の購入に含められるアイテム数は最大 50 件です。多くのアプリではこの上限に達することはありませんが、高度にモジュール化されたサブスクリプション設計を検討している場合は把握しておく必要があります。
4. すべての地域で利用できるわけではありません。現時点のドキュメントでは、インドと韓国では Subscription with Add-ons がサポートされていません。これらの地域のユーザーには、代替となる購入フローを用意する必要があります。
5. 一時停止と再開はサポートされていません。アドオンを含むサブスクリプションでは、サブスクリプションの一時停止および再開機能を利用できません。アプリがこの機能に大きく依存している場合、アドオンによるメリットがこの制約を上回るかどうかを慎重に検討する必要があります。

マルチラインサブスクリプションの活用戦略

仕組みを理解することと、この機能を効果的に活用することは別物です。実際に価値を最大化するには、マネタイズ戦略全体を踏まえて考える必要があります。ここでは、Subscription with Add-ons を活用するうえで参考になる、いくつかのアプローチを紹介します。

モジュール型機能戦略

最も分かりやすい活用方法のひとつが、ユーザーが必要な機能だけを選んで構成できるモジュール型サブスクリプションです。Basic / Standard / Premium といった事前定義された複数のプランを用意する代わりに、ベースとなるサブスクリプションと、ユーザーが自由に組み合わせられるアドオンの一覧を提供します。

たとえば、生産性向上アプリであれば、タスク管理や基本的なコラボレーション機能を含むベースサブスクリプションを用意し、アドオンとして高度なレポート機能、チーム管理機能、外部サービス連携、ストレージ容量の追加などを提供できます。高度なレポートだけが必要なユーザーはその機能のみを追加し、パワーユーザーは複数のアドオンを組み合わせる、といった使い方が可能です。このアプローチでは、「本当に必要なものにだけ支払っている」という感覚をユーザーに与えられるため、コンバージョン率の向上が期待できます。

この戦略を成功させるうえで重要なのは、ベースサブスクリプション単体でも十分な価値を提供できていることです。ベースが物足りなかったり不完全に感じられると、アドオンが柔軟性ではなく「小刻みな追加課金（ニッケル・アンド・ダイム）」として受け取られてしまう可能性があります。

プレミアムアップグレード戦略

もうひとつのアプローチは、アドオンを使ってユーザーを段階的にアップグレードしていく戦略です。まずはベースサブスクリプションで利用を開始してもらい、その後、利用状況やユーザー体験の節目に応じて、アドオンをアップセルとして提案します。

たとえば写真編集アプリの場合、ベースサブスクリプションには標準的な編集ツールを含め、利用が進むにつれて、プロ向けプリセット、高度なレタッチ機能、編集後の写真を保存するためのクラウドストレージといったアドオンを提供できます。従来のプラン階層を切り替えるアップグレードと異なり、アドオンであれば、ユーザーは既存の機能を維持したまま新しい機能を追加できます。そのため、「今のプランを失う」という感覚が生まれにくい点が大きな利点です。

この戦略は、パーソナライズされたレコメンデーションと組み合わせることで、特に効果を発揮します。ユーザー行動を分析することで、そのユーザーが価値を感じやすいタイミングで、適切なアドオンを提示できるようになります。

バンドル割引戦略（Bundle and Save）

Subscription with Add-ons では機能を個別に選択できる一方で、魅力的なバンドルを提供するという使い方も可能です。価格設定を工夫することで、アドオンを単体で購入するよりも、まとめて購入したほうがお得に感じられる構成を作れます。

たとえば、ベースサブスクリプションが月額 $9.99、アドオンがそれぞれ月額 $4.99 のものが3つある場合、個別に購入すると合計は $14.97 になります。これを、3つのアドオンをまとめたバンドルとして月額 $11.99 で提供すれば、複数の機能を求めるユーザーにとっては明確にお得な選択肢になります。このように、ユーザーはより多くの機能を割安で利用でき、事業者側は ARPU（ユーザーあたりの平均収益）を引き上げる ことができます。また、1つだけアドオンを購入するユーザーよりも高い収益を確保できる点も、この戦略のメリットです。

複雑さの管理

アドオンの活用におけるリスクのひとつは、選択肢が多くなりすぎてしまうことです。あまりにも多くのオプションが並ぶと、ユーザーは何を選べばよいのか分からなくなり、意思決定ができずに購入そのものをやめてしまう可能性があります。そのため、アドオンの数は通常 3〜5個程度の扱いやすい範囲に絞ることを検討するとよいでしょう。また、それぞれのアドオンについて「何が含まれているのか」「どのようなユーザーに向いているのか」を明確に説明することが重要です。さらに、おすすめのバンドルや「すべて選択」といったオプションを用意すれば、フル機能を求めるユーザーにとって、選択の手間を減らしつつ、スムーズに購入へ進めるようになります。

RevenueCat を使わずに Subscription with Add-ons を実装する

ここからは、Google Play Billing Library を直接使用して Subscription with Add-ons を実装する方法を順に見ていきましょう。この実装には Play Billing Library v5 以上 が必要です。ただし、すべての機能とセキュリティアップデートに確実にアクセスするために、最新バージョン（現時点では v8） を使用することをおすすめします。

Google Play Console でプロダクトの設定を行う

コードを書く前に、Google Play Console でサブスクリプションプロダクトを設定する必要があります。朗報なのは、既存のサブスクリプションプロダクトは特別な設定なしでアドオンとして提供できるという点です。別途「アドオン用」のプロダクトタイプを作成する必要はありません。自動更新サブスクリプションであれば、ベースアイテムにもアドオンにもなり得ます。

プロダクトを作成する際は、バンドルに含めたいすべてのアイテムが同じ請求期間でそろっている必要があることを忘れないでください。月額と年額の両方を提供したい場合は、請求期間ごとに別々のベースプランを作成する必要があります。

プロダクト詳細を取得する

実装の最初のステップは、Google Play から利用可能なプロダクトを問い合わせることです。提供したいすべてのサブスクリプションプロダクトの詳細を取得するために、 queryProductDetailsAsync メソッドを使用します。

class BillingManager(private val context: Context) {
    private lateinit var billingClient: BillingClient

    private val productIds = listOf(
        "premium_base_monthly",
        "hifi_addon_monthly",
        "offline_addon_monthly",
        "family_addon_monthly"
    )

    fun initialize() {
        billingClient = BillingClient.newBuilder(context)
            .setListener { billingResult, purchases ->
                handlePurchasesUpdated(billingResult, purchases)
            }
            .enablePendingPurchases()
            .build()

        billingClient.startConnection(object : BillingClientStateListener {
            override fun onBillingSetupFinished(billingResult: BillingResult) {
                if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
                    querySubscriptionProducts()
                }
            }

            override fun onBillingServiceDisconnected() {
\/\/ Implement retry logic here
            }
        })
    }

    private fun querySubscriptionProducts() {
        val productList = productIds.map { productId ->
            QueryProductDetailsParams.Product.newBuilder()
                .setProductId(productId)
                .setProductType(BillingClient.ProductType.SUBS)
                .build()
        }

        val params = QueryProductDetailsParams.newBuilder()
            .setProductList(productList)
            .build()

        billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList ->
            if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
\/\/ Store product details for later use when launching purchase flow
                handleProductDetails(productDetailsList)
            }
        }
    }
}

このクエリは、各サブスクリプションプロダクトに対応する ProductDetails オブジェクトを返します。これらのオブジェクトには、ユーザーに価格を表示したり、購入フローを開始したりするために必要なすべての情報が含まれています。具体的には、利用可能なベースプランやオファー、そのオファーに紐づくオファートークンなどが含まれます。

複数アイテムを含む購入フローの開始

ユーザーが希望するサブスクリプション構成（ベースサブスクリプション＋選択したアドオン）を選択したら、複数の ProductDetailsParams オブジェクトを指定して購入フローを起動します。ここで重要なのは、リストの先頭にあるアイテムがベースアイテムとして扱われるという点です。そのため、必ずベースとなるサブスクリプションを最初に追加する ようにしてください。

fun launchSubscriptionWithAddons(
    activity: Activity,
    baseProductDetails: ProductDetails,
    baseOfferToken: String,
    addonProductDetailsList: List<Pair<ProductDetails, String>>
) {
    val productDetailsParamsList = mutableListOf<BillingFlowParams.ProductDetailsParams>()

\/\/ Add the base subscription first - this is crucialval baseParams = BillingFlowParams.ProductDetailsParams.newBuilder()
        .setProductDetails(baseProductDetails)
        .setOfferToken(baseOfferToken)
        .build()
    productDetailsParamsList.add(baseParams)

\/\/ Add each selected add-onfor ((addonDetails, offerToken) in addonProductDetailsList) {
        val addonParams = BillingFlowParams.ProductDetailsParams.newBuilder()
            .setProductDetails(addonDetails)
            .setOfferToken(offerToken)
            .build()
        productDetailsParamsList.add(addonParams)
    }

    val billingFlowParams = BillingFlowParams.newBuilder()
        .setProductDetailsParamsList(productDetailsParamsList)
        .build()

    val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)

    if (billingResult.responseCode != BillingClient.BillingResponseCode.OK) {
\/\/ Handle error - perhaps show a message to the user
        handleBillingError(billingResult)
    }
}

リスト内の各アイテムは 一意である必要があります。同じプロダクト ID を持つ ProductDetailsParams オブジェクトを複数含めることはできません。また、オファートークンは、そのアイテムに対してどのベースプランまたはオファーを使用するかを指定するものです。 ProductDetails.subscriptionOfferDetails() メソッドから取得した 有効なオファートークン を必ず指定する必要があります。

購入の処理

ユーザーが購入フローを完了すると、 PurchasesUpdatedListener が結果を受け取ります。Subscription with Add-ons の処理は、基本的には単一のサブスクリプションを処理する場合と同じですが、ひとつ重要な違いがあります。それは、この購入によって 複数のアイテム分のエンタイトルメントが付与される という点です。

private fun handlePurchasesUpdated(
    billingResult: BillingResult,
    purchases: List<Purchase>?
) {
    when (billingResult.responseCode) {
        BillingClient.BillingResponseCode.OK -> {
            purchases?.forEach { purchase ->
                processPurchase(purchase)
            }
        }
        BillingClient.BillingResponseCode.USER_CANCELED -> {
\/\/ User canceled the purchase flow
        }
        else -> {
\/\/ Handle other error codes
        }
    }
}

private fun processPurchase(purchase: Purchase) {
\/\/ For Subscription with Add-ons, getProducts() returns all product IDsval purchasedProductIds = purchase.products

\/\/ Verify the purchase with your backend server
    verifyPurchaseWithBackend(purchase) { isValid ->
        if (isValid) {
\/\/ Grant entitlements for all purchased productsfor (productId in purchasedProductIds) {
                grantEntitlement(productId)
            }

\/\/ Acknowledge the purchase if not already acknowledgedif (!purchase.isAcknowledged) {
                acknowledgePurchase(purchase)
            }
        }
    }
}

private fun acknowledgePurchase(purchase: Purchase) {
    val params = AcknowledgePurchaseParams.newBuilder()
        .setPurchaseToken(purchase.purchaseToken)
        .build()

    billingClient.acknowledgePurchase(params) { billingResult ->
        if (billingResult.responseCode != BillingClient.BillingResponseCode.OK) {
\/\/ Handle acknowledgment failure
        }
    }
}

purchase.products プロパティには、その購入に含まれるすべてのプロダクト ID のリストが返されます。それぞれのプロダクトに対してエンタイトルメントを付与するとともに、必ずバックエンドサーバーで購入の検証を行ったうえで処理するようにしてください。

既存の Subscription with Add-ons を変更する

ユーザーは、既存のサブスクリプションに 新しいアドオンを追加したり、不要になったアドオンを削除したりしたい場合があります。既存の Subscription with Add-ons を変更する際には、現在の購入トークン（purchase token）を指定し、あわせて 置き換えモード（replacement mode） を設定する必要があります。

fun modifySubscriptionAddons(
    activity: Activity,
    currentPurchaseToken: String,
    baseProductDetails: ProductDetails,
    baseOfferToken: String,
    newAddonsList: List<Pair<ProductDetails, String>>
) {
    val productDetailsParamsList = mutableListOf<BillingFlowParams.ProductDetailsParams>()

\/\/ Include the base subscription
    productDetailsParamsList.add(
        BillingFlowParams.ProductDetailsParams.newBuilder()
            .setProductDetails(baseProductDetails)
            .setOfferToken(baseOfferToken)
            .build()
    )

\/\/ Include all add-ons (both existing ones to keep and new ones to add)for ((addonDetails, offerToken) in newAddonsList) {
        productDetailsParamsList.add(
            BillingFlowParams.ProductDetailsParams.newBuilder()
                .setProductDetails(addonDetails)
                .setOfferToken(offerToken)
                .build()
        )
    }

\/\/ Configure the subscription updateval subscriptionUpdateParams = BillingFlowParams.SubscriptionUpdateParams.newBuilder()
        .setOldPurchaseToken(currentPurchaseToken)
        .setSubscriptionReplacementMode(
            BillingFlowParams.SubscriptionUpdateParams.ReplacementMode.CHARGE_PRORATED_PRICE
        )
        .build()

    val billingFlowParams = BillingFlowParams.newBuilder()
        .setProductDetailsParamsList(productDetailsParamsList)
        .setSubscriptionUpdateParams(subscriptionUpdateParams)
        .build()

    billingClient.launchBillingFlow(activity, billingFlowParams)
}

サブスクリプションを変更する際は、変更後も有効なままにしたいすべてのアイテムをリストに含める必要があります。たとえば、ベースサブスクリプションと既存のアドオンを維持したまま新しいアドオンを追加したい場合は、その 3つすべてをプロダクトリストに含める必要があります。既存のアドオンをリストから除外すると、そのアドオンは削除されます。

置き換えモード（replacement mode） は、請求の切り替えを Google Play がどのように処理するかを決定します。 CHARGE_PRORATED_PRICE は、新しく追加されたアイテムの更新日がベースサブスクリプションと揃うように、日割り計算による請求を行います。ユースケースに応じて、 CHARGE_FULL_PRICE や WITHOUT_PRORATION といった他のモードを使用することも可能です。.

サーバーサイドでの検証とリアルタイム通知

本番環境のアプリでは、バックエンドサーバーで購入を検証し、Real-Time Developer Notifications（RTDN） を処理して、Google Play とエンタイトルメント情報を常に同期させる必要があります。

Subscription with Add-ons に関して注意すべき重要な点があります。複数アイテムを含む購入では、RTDN メッセージに subscriptionId フィールドが含まれません。これは、ひとつの購入に複数のサブスクリプションが含まれるためです。その代わりに、通知に含まれる purchaseToken を使用して Google Play Developer API に問い合わせ、付与されているすべてのアイテムの一覧を取得する必要があります。

\/\/ This is for your backend serverfun handleRealTimeNotification(notification: DeveloperNotification) {
    val purchaseToken = notification.subscriptionNotification.purchaseToken

\/\/ Query the Google Play Developer API for full purchase detailsval subscriptionPurchase = playDeveloperApi
        .purchases()
        .subscriptionsv2()
        .get(packageName, purchaseToken)
        .execute()

\/\/ The lineItems field contains all items in the subscriptionval lineItems = subscriptionPurchase.lineItems

    for (item in lineItems) {
        val productId = item.productId
        val expiryTime = item.expiryTime
        val autoRenewingPlan = item.autoRenewingPlan

\/\/ Update your entitlement database based on each item's status
        updateEntitlement(purchaseToken, productId, expiryTime, autoRenewingPlan)
    }
}

API レスポンスに含まれる lineItems リストには、各サブスクリプションアイテムの詳細が含まれています。具体的には、プロダクト ID、有効期限、更新ステータスなどの情報です。これにより、サブスクリプションバンドルを構成する 各アイテムごとにエンタイトルメントを個別に管理・追跡することが可能になります。

エッジケースの取り扱い

Subscription with Add-ons を実装する際には、いくつか注意すべきエッジケースがあります。

猶予期間（グレース期間）やアカウント保留は、サブスクリプションバンドル全体に適用されます。更新時の支払いが失敗した場合、どのアイテムで失敗が発生したかに関係なく、すべてのアイテムが同時にリカバリー期間に入ります。なお、猶予期間の長さは、アクティブなアイテムの中で 最も短い猶予期間設定を持つアイテム によって決まります。

一方で、返金や失効（revoke）はアイテム単位で処理可能です。Google Play Developer API を使用すれば、サブスクリプション全体に影響を与えることなく、特定のアドオンのみを取り消すことができます。これは、ユーザーがベースサブスクリプションは継続したまま、特定のアドオンだけの返金を希望する場合に有用です。

価格変更については、単一アイテムのサブスクリプションと同様のルールが適用されますが、複数アイテムで 未承認の価格改定（オプトイン）が存在する場合 は、追加の複雑さが生じます。未処理のオプトイン価格改定は、すべて 同じ更新日時に新価格が適用される必要があります。もし、あるアイテムにユーザーがまだ承認していない価格改定が存在する場合、その改定と整合しない他のアイテムの新たな価格改定は、無視される可能性があります。

RevenueCat で実装をシンプルにする

Play Billing Library を使って Subscription with Add-ons を直接実装すれば、確かに細かな挙動まで完全にコントロールできます。しかしその一方で、実装と運用の複雑さ、そして 時間的コスト（これも立派なリソースです） を大きく抱えることになります。請求クライアントのライフサイクル管理、クエリのキャッシュ、購入検証、エンタイトルメント管理、リアルタイム通知、そしてこれまでに触れてきた数々のエッジケースへの対応が必要です。

ここで大きな価値を発揮するのが RevenueCat です。RevenueCat は Play Billing Library の複雑さを抽象化し、複数プラットフォームにまたがるサブスクリプション管理を単一の API で提供します。特に Subscription with Add-ons においては、複数アイテム購入の扱い、エンタイトルメントの追跡、サーバーサイドでの検証といった煩雑な処理を、すべて自動で処理してくれます。

RevenueCat でのプロダクト設定

RevenueCat では、ダッシュボード上で Product を作成し、それらを Offerings に整理することでサブスクリプション商品を設定します。Google Play の各サブスクリプションのプロダクト ID は、それぞれ RevenueCat の Product に対応づけられ、関連するプロダクトをまとめて サブスクリプションの階層やバンドルを表す Offering として構成できます。

Subscription with Add-ons を利用する場合は、ベースサブスクリプション用のプロダクトと、各アドオン用のプロダクトをそれぞれ個別に作成します。そのうえで、RevenueCat の エンタイトルメント（権限）システムを使って、これらのプロダクトをアプリ内の特定の機能に紐づけます。ユーザーが購入を行うと、RevenueCat が アクティブなサブスクリプションに基づいて、どのエンタイトルメントを保有しているかを自動的に追跡してくれます。

シンプルな購入フロー

RevenueCat を使えば、購入の開始から結果の処理までを大幅にシンプルにできます。SDK が 請求クライアントの接続管理、購入の検証、エンタイトルメントの更新 をすべて自動で処理してくれます。

class SubscriptionManager(private val context: Context) {

    fun initialize() {
        Purchases.configure(
            PurchasesConfiguration.Builder(context, "your_revenuecat_api_key")
                .build()
        )
    }

    suspend fun getAvailableOfferings(): Offerings {
        return Purchases.sharedInstance.awaitOfferings()
    }

    suspend fun purchaseSubscriptionWithAddons(
        activity: Activity,
        basePackage: Package,
        addonPackages: List<Package>
    ) {
\/\/ RevenueCat handles the complexity of bundling these into a single purchaseval purchaseParams = PurchaseParams.Builder(activity, basePackage)
            .build()

        try {
            val (transaction, customerInfo) = Purchases.sharedInstance
                .awaitPurchase(purchaseParams)

\/\/ CustomerInfo automatically reflects all active entitlements
            updateUIWithEntitlements(customerInfo)
        } catch (e: PurchasesException) {
            handlePurchaseError(e)
        }
    }

    fun checkEntitlements() {
        Purchases.sharedInstance.getCustomerInfoWith { customerInfo ->
\/\/ Check which entitlements are activeval hasPremium = customerInfo.entitlements["premium"]?.isActive == true
            val hasHiFi = customerInfo.entitlements["hifi"]?.isActive == true
            val hasOffline = customerInfo.entitlements["offline"]?.isActive == true

            updateFeatureAccess(hasPremium, hasHiFi, hasOffline)
        }
    }
}

これで完了です。簡単そうに見えますよね？RevenueCat の CustomerInfo オブジェクトは、ユーザーが行ったすべての購入を通じて 現在有効なエンタイトルメントをリアルタイムで把握できるビューを提供します。どのプロダクトがどの機能に対応しているかを手動で管理したり、複数アイテム購入の複雑さを自分で処理したりする必要はありません。購入の検証、レシートの検証、エンタイトルメントの算出といった処理は、すべて SDK と RevenueCat のバックエンドが自動で行います。

クロスプラットフォームでの一貫性

RevenueCat の大きな強みのひとつは、Android・iOS など複数のプラットフォームにわたって一貫した API を提供していることです。アプリが複数のプラットフォームで提供されている場合でも、RevenueCat を使えばユーザーは 統一されたサブスクリプション体験を得られます。たとえば、Android でサブスクリプションを開始したユーザーが後に iOS に切り替えた場合でも、そのエンタイトルメントは自動的に認識され、追加の対応なしで同じ権限を利用できます。

分析とインサイト

RevenueCat のダッシュボードでは、サブスクリプションのパフォーマンスに関する詳細な分析データを確認できます。これには、サブスクリプションバンドルに特化した指標も含まれます。どのアドオンの組み合わせが最も人気なのかを把握したり、Offering ごとのコンバージョン率をモニタリングしたり、価格戦略を最適化するための改善ポイントを特定したりすることが可能です。

Webhook とサーバー連携

サブスクリプションの状態をサーバー側でも把握する必要があるアプリ向けに、RevenueCat はサブスクリプションイベントをサーバーへ通知する Webhook を提供しています。これらの Webhook は、Google Play の RTDN よりも扱いやすいのが特長です。というのも、RevenueCat がデータを正規化し、複数アイテム購入に伴う複雑さも吸収してくれるためです。詳細な実装ガイダンスについては、RevenueCat の Google Play プロダクトに関するドキュメント と、 サブスクリプション管理ガイド を参照してください。

まとめ

Subscription with Add-ons は、Android デベロッパーがサブスクリプションを設計するうえで、新たな価値をもたらします。複数アイテムをまとめて購入でき、かつ請求を同期できるようになったことで、Google は 柔軟でユーザーフレンドリーなマネタイズ戦略の可能性を広げました。ユーザーが自分に合った構成を選べるモジュール型サブスクリプションを提供する場合でも、エンゲージメントの高いユーザー向けにアドオンをアップグレード経路として活用する場合でも、あるいは ARPU（ユーザーあたり平均収益）を高める魅力的なバンドルを作る場合でも、この機能はそのビジョンを実現するための土台を提供してくれます。

一方で、Play Billing Library を使ってこの機能を直接実装するには、商品設定、購入フロー管理、エッジケース対応などに細心の注意を払う必要があります。本記事で紹介したコード例はあくまで出発点であり、本番環境では、追加のエラーハンドリングやリトライロジック、十分なテストが不可欠です。

よりスピーディーに進めたいチームや、クロスプラットフォーム対応が必要な場合には、RevenueCat は非常に有力な選択肢となります。多くの複雑さを抽象化しつつ、統合された分析機能やシンプルなサーバー連携といった付加価値も提供します。

実装を計画する際は、まず マネタイズ戦略を明確に定義することから始めてください。どの機能をベースサブスクリプションに含め、どれをアドオンにするのかを整理し、請求期間が正しく揃っているかを確認し、各オプションの価値をユーザーにどう伝えるかを検討することが重要です。丁寧な設計と確かな実装を行えば、Subscription with Add-ons は、ユーザーとビジネスの双方にとって価値のあるサブスクリプション体験を実現する強力な手段となるでしょう。この機能の公式ドキュメントについては、 Android Developers の Subscription with Add-ons ガイド および RevenueCat Offerings を参照してください。

動画は、ペイウォールの成果を高め、価値を明確に伝えるための強力な手段です。ペイウォール上の動画テストに関するデータはまだ限られていますが、動画というメディア自体が効果的であること は明らかです。短時間で情報を伝え、感情的な記憶を強める力があります。たとえば Fitness AI は、App Promotion Summitで、ペイウォールに動画を追加したことで収益が約80%増加したと共有しており、現在もペイウォールに動画を使用し続けています。

私の「風変わりなペイウォール」についての記事を読んだことがある方なら、私が少しクセのある、ユニークなデザインに弱いことをご存じでしょう。中でもお気に入りの例が、Water Llama という水分摂取を記録するアプリです。このアプリは、遊び心のある機能紹介動画を使い、画面上でかわいらしいラマの水分トラッカーが満たされていく様子を見せることで、ペイウォールに命を吹き込んでいます。

ペイウォールにラマを登場させるのはさすがにやりすぎかもしれませんが、動画を追加すること は、ペイウォールであれオンボーディングであれ、検討する価値のある一手です。

それでは、ビデオペイウォールを検討すべきケース（そしてそうでないケース）、さらに効果的にテストし、実装する方法について見ていきましょう。成功につなげるためのポイントを解説します。

クイック解説：ペイウォールに動画を追加するメリットとデメリット

動画は、特定のアプリカテゴリやオーディエンスでより一般的ではありますが、それだけを理由に検討対象から外す必要はありません。最終的に、ビデオペイウォールは4つの重要な目標を達成する手段になり得ます。動画をペイウォールに使うかどうかは、アプリのカテゴリではなく、これらの目標を達成したいかどうか を判断軸にすべきです。ただし、考慮すべきデメリットもいくつか存在します。

最終的に、動画ペイウォールがあなたのアプリに適しているかどうかは、オーディエンス、カテゴリ、そして目標によって決まります。ただし、最終判断を下す前にテストする価値は常にあります。この先では、動画ペイウォールがあなたのアプリに本当に適しているのかを、さらに詳しく掘り下げていきます。

いつペイウォールに動画を追加すべきか？

私自身の経験から、オンボーディングやペイウォールで動画をテストすることで、トライアル開始数だけでなく、トライアルから有料へのコンバージョン率も改善できることが分かっています。特に、アプリの本当の価値を理解してもらうための ハウツー動画 は効果的です。

優れた動画はペイウォールの質を引き上げ、コンバージョンを高めますが、間違った動画は表示を遅くしたり、メッセージを分かりにくくしてしまうこともあります。ここでは、あなたのアプリが動画ファーストのペイウォールから恩恵を受けられるかどうかを見極めるポイント を紹介します。

1. 感情がコンバージョンを左右する場合

フィットネス、ウェルネス、習慣形成系のアプリは、「機能」ではなく感覚や気持ちを売っていることが多く、動画はそれを捉えるのに最適です。たとえば心拍をトラッキングするアプリCardi Mateでは、アプリが実際に動いている様子をフルスクリーンの背景動画で見せながら、心の落ち着きや心拍をコントロールできている感覚といった、アプリの価値を明確に伝えています。

テキストは最小限に抑えられ、画面下部には控えめなオーバーレイが重ねられており、次の要素を伝えています：

• ソーシャルプルーフ（登録者数）
• トライアル／支払いの設定
• アプリの簡単な説明

この組み合わせにより、ユーザーはアプリの価値を即座に感じ取ることができ、コンバージョンにつながりやすくなります。「Continue」をタップすると、余分な画面を挟むことなく、そのまま支払い画面へ進めるため、摩擦もありません。もうひとつの優れた例が、睡眠アプリのLoónaです。オンボーディングではリラックスできる音楽が流れ、瞬時に落ち着いた気分を醸成します。ペイウォール上の動画はシンプルで穏やかですが、Loónaがユーザーにもたらす状態を見事に表現しています（もっとも、価格表示におけるdark UXは、正直あまり“チル”とは言えませんが）。

2. 言葉よりもビジュアルのほうが価値を早く伝えられる場合

「1枚の写真は千の言葉に値する」と言いますが、動画ならジェフ・ベゾスのポートフォリオ以上の価値があるかもしれません。まず分かりやすい例からいきましょう。写真・動画系アプリです。視覚的なコンテンツに大きく依存するアプリは、機能を見せる手段として、よりビジュアルな表現を使うことで自然と恩恵を受けます。

たとえば、ByteDance（TikTokの親会社）が提供するAI搭載の動画・画像編集アプリCapCut。Water Llamaと同様に、CapCutはペイウォール上で動画を使い、主要な機能を強調しています。短いクリップで各機能の動きを順番に表示し、それぞれがどのように機能するのかを一目で分かるようにしています。

動画は、アプリの使い方を実演したり、ダウンロード直後に主要な機能をユーザーに案内したりする場面で、非常に大きな価値を発揮します。

3. 変化や信頼を証明する必要がある場合

ここでは、私がビデオペイウォールを調査する中で出会った、少し変わった例を紹介します。私は50以上のアプリをダウンロードしてペイウォールをテストしました。というのも、アプリが最初から動画を表示するかどうかは外から分かりにくいですし、正直なところ、私の記憶も完璧ではないからです。（驚くことに、これまで見たすべてのペイウォールを覚えているわけではありません。）

その中で試したアプリのひとつが、Jacob Rushfinn氏のニュースレターで知ったDr Kegalです。最初は特に深く考えず、彼が勧めていたアプリを試してみよう、という軽い気持ちでした。ところがこのアプリは、予想外のことをしました。ペイウォールを表示する前に、30秒以上の動画視聴を強制したのです。動画の世界では、かなりの失策と言えるでしょう。

ただし、ここが重要なポイントです。私は今、女性であるにもかかわらず、勃起の持続時間を改善するためのアプリをスマートフォンに入れています……。このテーマは、多くのユーザーにとって話題にしづらかったり、本当に運動で効果があるのか不安を感じたりする分野です。このアプリのペイウォール動画では、実際にアプリの恩恵を受けた複数の男性が登場し、信頼性と説得力を築いています。動画が終わった後も、その映像はペイウォールの上部に残り、ユーザーがサブスクすることを決める前に、ソーシャルプルーフと価値を改めて強調します。

スクロール可能なペイウォールには、さらに 2本目の動画 が配置されており、アプリの裏にある科学的な仕組みや、どのように機能するのかをより詳しく解説しています。

ユーザーがそのアプリに懐疑的だったり、テーマ自体に不安を感じていたりする場面では、ペイウォール上の動画が、その決定的な瞬間に信頼を築く助けになります。もうひとつの優れた活用例は、競争の激しい市場です。動画を通じて「他とは違う価値を提供している」という信頼を構築することで、差別化につなげることができます。

4. 読まれない時代に、動画で注意をつかむ

オーディエンスのタイプは、動画を優先すべきかどうかに影響します。データによると、若い世代は テキストよりも動画による説明を好む傾向があり、こうした層に向けてはビデオペイウォールをテストする価値があります。一方で、年齢層が上がるにつれてソーシャルメディアの利用時間は減っているにもかかわらず、アプリはますますソーシャルプラットフォームを模倣するようになっています。短尺動画だけでなく、Instagramのストーリーのようなスワイプ形式や、かみ砕いたコンテンツもその一例です。正直なところ、私たちの多くは、もう文章をじっくり読まなくなっています。

このガイドではペイウォール上で動画を使うことに焦点を当てていますが、オンボーディングで動画を使ったり、2ステップのペイウォール（動画 → トライアル／支払い情報を含むペイウォール） を作ったりすることで、支払い画面に進む前に注意と理解をしっかりと獲得することもできます。

グロースコンサルタントであり、ニュースレター「Growth Gems」の著者でもあるSylvain Gauchet氏は、最近、ペイウォールとオンボーディングの境界が曖昧になりつつあるトレンドについて次のように指摘しています。

「最近、特に無料トライアルで、マルチスクリーンのペイウォールを目にすることが増えています。最も冷たい“課金タイムライン”をいきなり見せるのではなく、複数の画面に分けて説明するんです。そうすると、オンボーディングとペイウォールの境界が曖昧になります。ペイウォールの前にある画面はオンボーディングなのか？それともペイウォールの一部なのか？ただ、そのおかげで、価値を見せたり、実際の取引要素をより分かりやすく説明したり、最後のひと押しとなるピッチや要約を提示できるようになります。」

私自身、現在このアプローチをZ世代向けアプリでテストしています。従来の、画像＋テキストによる4つのテンポの速い機能紹介画面を、動画＋テキストの機能紹介画面 に置き換え、ペイウォールへとつなげることで、支払いを求める前にアプリを十分に理解してもらうことを狙っています。

どのような場合に、ペイウォールで動画の使用を避けるべきか？

動画は、他のタイプのペイウォールよりも多くの労力を必要とする点を理解しておくことが重要です。特に、テストと検証にかかる負荷が大きい という側面があります。私のおすすめは、まずメッセージングを検証し、どの機能がユーザーの支払いにつながっているのかを特定したうえで、初めて動画を導入（そしてテスト）することです。そうすることで、ペイウォールをテストした際に、変化の要因が「動画そのもの」であると判断できます。最初から動画を追加してしまうと、コピーやコア機能を先に最適化した場合と比べて、テストが遅くなり、効果も見えにくく、成功率が下がることがよくあります。

そのため、まだプロダクトマーケットフィットを見つけられていない場合や、ユーザーが本当に支払う意思があるかを把握できていない段階では、動画の追加は一旦見送ったほうがよいでしょう。ほかにも、動画があまり適さないケースはいくつかあります。

1. オーディエンスの通信環境が限られている場合

動画サイズを最適化して読み込みを高速化したとしても（RevenueCat’s Paywall Builderはこれを自動で行います）、動画が読み込み時間に影響すること自体は避けられません。ユーザーの通信速度が遅い、データ通信量に制限がある、あるいはWi-Fiが不安定な場合、動画ペイウォールは摩擦を生む可能性があります。

「でもDaphne、ユーザーの通信速度なんてどうやって分かるの？」と思うかもしれませんが、私が言いたいのはそういう意味ではありません。アプリがどんな場面で使われるのか、いつ最も利用されるのか を考えてみてください。たとえば、ハイキングやキャンプ中に使われるアプリは、通信環境がほとんどない状況でも機能する必要があります。また、オーディエンスが高齢層であれば、超高速な回線を前提とした Gen Z 向けゲーマーアプリほど通信環境が良くない可能性もあります。さらに、販売対象の市場が地方部に多い、あるいはインターネットインフラが比較的遅い国である場合も、考慮すべき要素です。

2. アプリのUSPが「シンプルで機能的」である場合

シンプルなユーティリティ系アプリでは、動画ペイウォールがかえって邪魔になることがあります。ユーザーが重視しているのがスピードである場合、動画は最終目的から注意をそらしてしまう可能性があります。たとえば、パスポートのコピーを素早くスキャンしてアップロードしたいだけの人にとって、最初に動画を見せられるのは、ただのストレスになりかねません。動画が本当にユーザーのコンバージョンを後押しするのか、それとも「効果がありそうだ」と思い込んでいるだけなのかを、慎重に見極める必要があります。ここでも重要になるのがテストです（この後で詳しく触れますので、お楽しみに）。

3. 高品質な動画を用意できない（または用意できそうにない）場合

AIによって動画制作のハードルは下がりましたが、効果的な動画を作るには、今なお時間と投資が必要 です。アニメーションであれ実写であれ、品質を妥協することはできません。ペイウォール上に低品質な動画を載せてしまうと、プラスになるどころか、逆効果になる可能性があります。

また、オーディエンスに響く形式を見つけるためには、複数のフォーマットをテストする必要があります。導入を決める前に、必要となる時間やリソースを十分に見積もっておくことが重要です。

動画ペイウォールのテストと実装

さて、メッセージングは十分に練り込まれ、ユーザーがそのプロダクトを求めていることも分かっており、ペイウォールに動画を使うのが適切だと判断できたとします。では、ビデオペイウォールをどのようにテストし、ローンチすればよいのでしょうか？

1. 動画テストの目的を明確にする

これまで、アプリがペイウォールで動画を使う主な理由を見てきました：

1. 感情を伝える
2. 機能を視覚的に説明する
3. 変化を伝え、信頼を構築する
4. 注意を引きつける

目的を明確にすることで、どのフォーマットや構成をテストすべきかが判断しやすくなります。たとえば、アプリの内容をより分かりやすく説明することが目的であれば、機能紹介のカルーセル や フルスクリーンの背景動画 をテストするのが適しているでしょう。

2. 動画フォーマットを決める

次に、設定した目的に最も適したフォーマットを特定します。これまでの例からも分かるように、ペイウォールに動画を組み込む方法はいくつか効果的な選択肢があります：

1. ペイウォールの最上部に配置：アプリが実際に動いている様子を見せ、すぐにユーザーの関心を引きつけます。
2. 背景として使用：動きと奥行きを加え、ペイウォールをよりダイナミックに感じさせます。
3. 縦に長いランディングページ内の1ブロックとして配置：機能や価値提案をより詳しく説明する必要があるプレミアムアプリに最適で、スクロール型ペイウォールでもユーザーの関心を維持できます。
4. カルーセル内で使用：短く分かりやすいクリップで、複数の機能を順番に紹介できます。
5. ペイウォールの最初の画面として表示：価格やトライアルの詳細に進む前に、注意と理解を獲得できます。

また、Dr. Kegal のように、ペイウォール全体で複数の動画を組み合わせることも可能です。もうひとつの優れた例が、AIによるフェイススワップアプリ Reface です。Refaceは、ループ再生される背景動画としても機能するカルーセルを使用し、活き活きとしたインタラクティブな体験を生み出しています。

アニメーションを見せたいアプリにとっても、動画は有効な選択肢になります。特に、使用しているペイウォールビルダーがアニメーションに対応していない場合は有効です。アニメーションはエンゲージメントを高める優れた手段です。たとえば、語学学習アプリの Duolingo では、マスコットであるフクロウの Duo の小さなアニメーションをペイウォール上で使用しています。

Refaceのようなアプリは、こうした表現をコードで実装している可能性が高いですが、同様の効果を素早くテストする方法 としては、特にペイウォールビルダーがアニメーションに対応していない場合、短いループ動画やGIFを使う という選択肢があります。ただし注意点として、コードで直接実装されたアニメーションは、一般的に動画よりも読み込みが速い という点は覚えておく価値があります。

また、設定した目的と選んだフォーマットは、動画をどこでテストするか を決める手がかりにもなります。たとえば CapCut のように、紹介している機能がすべてのユーザーに共通して重要である場合、すべてのペイウォールで同じ動画を使っているアプリもあります。一方で、目的が「新規ユーザーにアプリの価値を理解してもらうこと」であれば、最初のペイウォールのみに動画をテストする という選択も考えられます。

たとえば、フィットネスアプリの FitOn では、アップテンポな音楽、点滅するビジュアル、フルスクリーンのエネルギー感あふれる、非常にインパクトの強いペイウォール動画を使用しています。これは新規ユーザーにとっては、アプリが提供する体験を即座に理解し、ワクワク感を与える点で非常に効果的です。しかし、既存ユーザーに毎回同じ動画を強制する となると、刺激的というより煩わしく感じられてしまう可能性があります。

その後、私が再びアプリに戻ったときに表示されたペイウォールは、よりシンプルな機能紹介カルーセル になっていました。

3. 動画に含めるべき内容（そしてペイウォール全体の構成）

動画コンテンツを設計する際は、次のベストプラクティスを意識してください：

• 動画は短く保つ：多くの場合、15〜30秒以内が適切です。
• 音声なしでも成立させる：ほとんどのユーザーは音をオンにしていません。ここまで紹介してきた例も、Dr. Kegalを除いてすべて無音で機能しています（なお、Dr. Kegalも字幕を併用しています）。
• 強いビジュアルフックから始める：特に、アプリの価値を伝える目的で動画を使う場合、冒頭でユーザーの注意をつかむことが重要です。

動画、コピー、CTA（行動喚起）を組み合わせると、認知的な負荷はすぐに高くなりがちです。そのため、ほとんどの場合はシンプルさが勝ちます。実例を見ても、動画がより詳細で動きのあるものであるほど、補足するコピーはシンプルかつ最小限に抑えられている傾向があります。

どのような動画をテストすべきか迷っている場合は、アプリの使い方をシンプルに紹介するウォークスルー動画 から始めるのがおすすめです。主要な価値や機能を、分かりやすく魅力的に伝えることができます。

4. 動画の設定

動画ペイウォールを設定する際には、いくつかの重要なポイントがあります：

• ループ再生か、1回再生か：多くのペイウォール動画はループ再生されています。ユーザーはまずテキストを読んだり、マルチタスクをしていたりして、動画の冒頭を見逃すことがあるためです（あるいは、私のようにADHD気味の場合もあります）。
• 自動再生か、タップ再生か：動画を自動で再生するか、それともタップしたときだけ再生するか。自動再生は注意を即座に引けるため、一般的な選択肢です。一方で、ユーザーの声や詳細な機能説明など、任意で視聴するコンテンツ にはタップ再生が向いており、ペイウォールをすっきり保ち、注意散漫になるのを防げます。
• ミュートか、音声オンか：前述のとおり、多くのユーザーはアプリ利用時に音声をオフにしています。突然音が出たり、逆に音が出ないことで内容が分からなかったりすると、フラストレーションにつながることもあります。私のおすすめは、デフォルトはミュート にすることです。動画にセリフがある場合は、ぜひ 字幕を付けてください。エンゲージメント、アクセシビリティ、ユーザー体験のすべてを向上させます。

もちろん、例外もあります。ここで FitOn の例に戻りましょう。FitOnのエネルギッシュなフルスクリーン動画は、ユーザーを完全に没入させることを目的としているため、ループも自動ミュートもされていません。動画が終わると、スムーズにフェードアウトしながら「Subscribe」ボタンへと視線を導き、唐突な終了ではなく自然な流れを作っています。動画は長く動きも激しいため、このケースではミュートは適さず、ループさせると逆に負担になってしまいます。

さらに、読み込み時間を最適化すること も忘れないでください。アプリ内ではWebほど致命的ではないとはいえ、読み込み時間は依然としてパフォーマンスやユーザー体験に影響します。

RevenueCatの Paywall Builder を使用している場合は、その点も安心です。以下のベストプラクティスに沿って、動画が自動的に最適化されます：

1. 初期ロード：動画のサムネイルが即座に表示されます。
2. 段階的ロード：まず低解像度の動画を再生して速度を確保し、その後高画質へと切り替わります。
3. ローカルキャッシュ：動画はローカルに保存され、次回以降はより高速に再生されます。
4. 帯域幅の最適化：データ使用量を最小限に抑え、よりスムーズな体験を実現します。

一方で、ネイティブのペイウォールに自前で実装する場合は──ここが見せ場です。開発者ににっこり微笑んで、助けをお願いしましょう……彼らが輝く時間です。

テストのロードマップ

あなたが動画をテストしようとしているのには、きっと正当な理由があるはずです（そうであることを願っています）。だからこそ、動画を1本だけテストして、うまくいかなかったからといって、永遠に動画を否定しないでください。そして2年後、目を輝かせた新任のプロダクトマネージャーが「ねえ、ペイウォールに動画を試してみるのはどうでしょう？」と提案した瞬間に、「いや、2年前にテストしたよ。動画はうちには合わない」と即座に却下する──そんな事態にはならないでほしいのです。

1回のテストで、ビデオペイウォールが機能しないと結論づけることはできません。それは単に、「そのバージョンが機能しなかった」というだけです。

目的に基づいて、テストは次の3つの主要要素に集中させましょう：

• コンテンツ：動画で何を伝えるか、どのように始まるか、長さはどれくらいか
• 配置：動画をペイウォールのどこに置くか（マルチステップの場合は、どの画面か）
• 設定：これまでに触れてきた、技術的・挙動的な各種設定

この順番でテストすることをおすすめします。多くのアプリ、特に単一画面のペイウォールでは、コンテンツが最も大きな影響を与えます。

以下は、ハイレベルなテスト計画の一例です：

• ベースライン：現在の静的なペイウォールから始め、コンバージョン率やエンゲージメント指標を記録する
• 実験1：ヒーロー画像を短いループ動画に置き換える（コピーはそのまま）。効果の差分を測定する
• 実験2：機能デモ動画と感情訴求のストーリー動画など、異なるタイプをテストし、どちらがよりコンバージョンを生むかを比較する
• 実験3〜X：最も成果の良かった動画をベースに、フック、配置、長さを調整してさらなる最適化を行う

あなたのペイウォールに、動画は本当に必要？

ペイウォールは、まさに成否を分ける瞬間です。その一瞬で、ユーザーはこのアプリに価値があるかどうかを判断します。動画は、その判断を後押しするための もうひとつの次元 を与えてくれます。結果を「感じさせ」、変化を「見せ」、そしてユーザーをもう少しだけその場に留める力があります。

すべてのアプリに動画が必要というわけではありませんが、多くのアプリは 少なくとも一度はテストしてみる価値があります。特に、ペイウォール体験をこれまで以上に引き上げやすい RevenueCat Paywalls のようなツールがある今はなおさらです。

うまく設計された動画は、コンバージョンを高め、ブランドを強化し、似たようなペイウォールが並ぶ中で際立つ存在にしてくれます。

ラマが水分補給をしていくアニメーションであれ、ユーザーがフィットネスの可能性を解放する瞬間であれ、本当に価値を加える動画 で、あなたのペイウォールに命を吹き込むことを恐れないでください。

今日、まさにそれを実現します。

新しく公開された RevenueCat Figmaプラグイン を利用することで、デザインからライブのペイウォールへ一瞬で移行できるようになりました。Auto Layoutを使用したFigmaフレームを、1回のエクスポートでRevenueCat内の完全編集可能なペイウォールへ直接変換できます。

FigmaフレームからRevenueCatペイウォールへ

プラグインをインストールすると、次のことが可能になります：

• 1つのFigmaファイルから複数のペイウォールをエクスポート：迅速な反復や、A/Bテスト用のバリエーションをまとめて準備するのに最適です。
• レイアウトとスタイルを正確に保持：テキストはテキストとして、画像は画像として、フレームはスタックとして──すべて自動で正しくマッピングされます。
• 主要コンポーネントを自動検出：Button、Purchase Button、Package などのレイヤー名は、それぞれ対応するRevenueCat Paywallコンポーネントに変換されます。
• デザインをそのままPaywall Editorへ送信：グロースチームやCXチームは、コピー調整、プロダクト差し替え、ローカライズ、実験のセットアップなどを、追加のデザインやエンジニアリング作業なしで行えます。

このワークフローにより、デザイナーはアプリに自然に溶け込む、ブランドらしいリッチなペイウォールをFigmaで自由に作り込みつつ、プロダクトチームはRevenueCat内で素早く反復できる柔軟性を得られます。

なぜ重要なのか

多くのチームにとって、ペイウォールの制作はFigmaから始まります。デザイナーは、エンジニアリングやグロースチームが関わるよりも前に、レイアウト、ビジュアルの階層、ブランド表現、コンバージョンを意識したバリエーションを作り込みます。しかしこれまでは、そのデザインをライブのペイウォールに反映するには、Paywall Editorで手作業で再構築する必要がありました。

新しいプラグインは、その工程を完全に取り除きます。

これからは、デザイナーが普段作業している場所であるFigmaのままペイウォールを構築でき、小さなコピー調整から大幅なリデザインまで、あらゆるバリエーションを数秒でエクスポートできます。一方、PMやグロースチームは、エクスポートされたデザインをすぐに実験に変換し、成果を比較し、追加のデザインファイルなしで更新を公開できます。

より速く、よりシンプルで、よりコラボレーションしやすい──そんな新しいペイウォール反復のアプローチです。

チュートリアル動画を視聴し、ドキュメントを読む

フロー全体を最初から最後まで確認したい場合は、完全なウォークスルーをご用意しています：

フル動画チュートリアル

Watch on YouTube

ドキュメント https://www.revenuecat.com/docs/tools/paywalls/creating-paywalls#importing-from-figma

Figma Pluginを入手する https://www.figma.com/community/plugin/1571207414894772119

高品質でブランドらしいペイウォールを最速で作る方法──それは、デザイナーがすでに使っているツールをそのまま使うことです。プラグインを試し、複数のバリエーションを実験し、これまで以上のスピードでペイウォールを公開しましょう。

アプリのほうであって、気持ちの平穏ではありません。とはいえ、実際の“落ち着き”にお金を払えるなら、かなり払うと思いますが。

数年間、CalmとHeadspaceの間を行ったり来たりしながら、ときどき瞑想してはやめてを繰り返していた頃、どうしても断れないと感じるオファーを見つけました。Calmへの生涯アクセスです。月額料金なし、年次更新なし、支払いは一度だけ、永遠に使える。

完璧に思えました。すでに投資したと分かっていれば、もっと瞑想するようになるはず。サブスクリプションのことを二度と考えなくていいなんて最高では？　頭の中のタスクがひとつ減る。そう思ってしばらく悩んだ末に購入しました。人生で初めてのライフタイムサブスクリプションです。ちなみに2回目のライフタイムは今年の初め、今の夫と結婚したときでした。

数年後の今でもCalmは私のスマートフォンにあります。アップデートされ続け、改善され続け、今も健在です。でもここで大きな疑問が浮かびます。Calmのような巨大アプリが大規模にライフタイムサブスクリプションを提供しているなら…あなたのアプリも提供すべきなのでしょうか？

これまでに私が行ってきたサブスクリプションモデルの深掘り（年額サブスクリプションのメリット・デメリットから週次サブスクリプションが理にかなうかどうかまで）と同じように、答えは単純に「はい、やるべき」「いいえ、やめておくべき」のどちらかではありません。顧客にとってもブランドにとっても、利点と欠点があります。そして業種によっては適していません。

ということで、今日はライフタイムサブスクリプションについて深掘りします。取り上げるのは次のポイントです：

• どの業界でライフタイムオファーがどれほど一般的なのか
• 顧客とビジネス双方にとってのメリット（とリスク）
• ライフタイムサブスクリプションを検討すべきアプリと、そうでないアプリ
• 成功するライフタイムオファーの構成方法

あなたは今これをビジネスの視点で読んでいると思いますが、私はいつも顧客視点からも考えます。ライフタイムサブスクリプションをテストしたいのであれば、顧客の印象や迷いを理解しなければなりません。ライフタイムサブスクリプションは、ほとんどの場合、顧客かブランドのどちらかに有利に働き、両方に同時に有利になることはほぼありません。私がCalmで「最高のお得感」を感じられるなら、Calmは「私から最大の価値を得られた」とは思えないし、その逆もまた同じです。

本当に多くのアプリがライフタイムサブスクリプションを提供しているのか？

私は信頼するデータソース、夜寝る前に読むお気に入りのオタク的読書「State of Subscription Apps 2025 Report」を開きました。（はい、262ページすべて読んでいますし、毎回役に立っています。）

ほとんどのアプリカテゴリでは、サブスクリプションとライフタイムサブスクリプションを組み合わせて提供する形が、2番目に一般的なマネタイズ方法です。さらに一部のアプリでは、消耗型アイテム（コンシューマブル）を上乗せしています：

ライフタイムサブスクリプションが最も一般的なのはどこでしょうか？Photo & Videoアプリが群を抜いており、このモデルは「永遠のアクセス」というより「一度きりのアップグレード」として扱われることが多いです。また、EducationやTravelでも人気があり、ユーザーが長期的な価値を明確に感じられる領域です。

その他ほとんどのカテゴリでは、サブスクリプションとライフタイムの両方を提供する割合はアプリの18〜24%の範囲で推移し、その中にコンシューマブルがセットで含まれることもあります。

大きな例外は？ Businessアプリです。ここではライフタイムアクセスはほとんど理にかなっていません。ユーザー1人あたりの継続コストが高く、プロダクトの進化速度も速いためです。特にB2B領域では、ライフタイムサブスクリプションは現実的ではないことが多いのです。

ライフタイムサブスクリプションのメリット

では、なぜ月額や年額のサブスクリプションモデルから、ライフタイムの買い切りモデルへ切り替えることを検討するのでしょうか？ここでは、両方の視点から見ていきます。

顧客側の視点

人々はサブスクリプションに疲れています。テレビから歯ブラシまで、あらゆるものが月額料金を求めてきます。管理が難しく、今や何もかもがサブスクリプションのように感じられます。実際、サブスクリプションを管理するためのアプリが存在するほどです。これを“サブスクリプション疲れ”と言わずして、何と言うのでしょうか。

そこで登場するのがライフタイムサブスクリプションです。これには魅力があります：

• サブスクリプションの積み上がりがなくなる：新しい請求がひとつ増える代わりに、一度支払ってあとは忘れることができます
• 投資としての“賭け”ができる：気に入った新しいアプリを、早い段階から応援できる。多くのスタートアップは、この「長く付き合う覚悟」を促すため、年額プランより魅力的な価格でライフタイムを提供します
• 長期的な“勝ち”：アプリを損益分岐点を超えて使い続けると、「圧倒的にお得な買い物をした」と感じられます

ブランド／ビジネス側の視点

ライフタイムサブスクリプションを提供することには、いくつかの主要なビジネスメリットがあります：

• まとまった前払い収益
• リテンションの向上
• 早期のキャッシュフロー
• コミット度の高いユーザーの獲得
• リファラル効果
• 競合との差別化

ライフタイムサブスクリプションは、少なくとも5年分、場合によってはそれ以上の収益を前払いで得られます。もしユーザーがもっと早く離脱していた可能性を考えると？　むしろそれは好都合です。本来得られなかったはずの価値を先に確保できるからです。

アプリが立ち上がったばかりのタイミングで提供すれば、リテンションを高める効果もあります。初期のライフタイムユーザーからはリテンション改善に役立つデータが取れ、さらに早期収益も得られます。

この前払いキャッシュは、特にコンテンツ負荷の高いブランドにとって大きな助けになります。Calmを例にすると、新しい瞑想コンテンツ、著名人のナレーション、音楽、パートナーシップなど、すべて継続的な投資が必要です。ライフタイムサブスクリプションによる収益の波が、成長を支えたり、資金調達をせずにブートストラップで拡大する助けになったりします。

ライフタイムサブスクリプションは、戦略的なタイミングで提供することもできます。たとえば、ホリデー割引や季節のキャンペーンなど、ユーザーがオファーを期待している時期です。私の経験では、割引目当てのユーザーはエンゲージメントが低く、早く離脱する傾向があります。Airshipのブラックフライデー加入者に関する調査もこれを裏付けています。しかし、ライフタイムオファーなら、値引き目当てのユーザーではなく、コミット度の高いユーザーを引き寄せることができます。

さらに、よりニッチなメリットもあります。それがリファラルです。たとえばOriginというファイナンスアプリは、3人の友人を紹介するとライフタイムアクセスを付与しています。彼らはこれを巧みに表現しています：「2人紹介で1年分のOriginがカバーされ、もう1人紹介すればライフタイムメンバーシップを獲得できます。」無料の1か月や1年よりもはるかに魅力的で、リファラルを強力な成長エンジンに変えています。

最後に、競争の激しい業界では、ライフタイムサブスクリプションは大手との差別化の手段にもなります。大手の多くが提供していない（Calmは例外的ですが）ためです。たとえば、Duolingoと競争する語学アプリのJumpspeakは、私の経験ではコミット度の高いユーザーを獲得するために、ライフタイムサブスクリプションを積極的に推しています。

実際にJumpspeakを試したとき、私には合いませんでしたが、アプリを気に入った人ならライフタイムを選ぶのは十分にあり得ると感じました。それはユーザーをJumpspeakに“永続的に”結びつけ（うまくいけば）、ただ試してDuolingoに戻るという流れを防ぎます。Calmのライフタイムが年額の約5倍であるのに対し、Jumpspeakは3.6倍に設定しており、かなり積極的な戦略です。

ライフタイムサブスクリプションのデメリット

さて、ここからが本題です。どんな落とし穴があるのでしょうか？

顧客にとってのデメリット

私がCalmのライフタイムを購入したとき、細かい注意書きを十分に読んでいませんでした（当時の価格は、現在の約3分の1でした）。ライフタイムサブスクリプションには特定の機能に限定されているものもあり、“ライフタイム”とは通常、プロダクトの寿命、つまり会社が存続している間を意味します。これは特に新しいアプリでは大きな賭けです。

小さなスタートアップのライフタイムを購入して、その会社が1年後に事業を畳んでしまったら、“ライフタイム”は想定よりはるかに早く終わってしまいます。Calmの場合はすでに確立されたブランドだったので心配しませんでしたが、Jumpspeakのような新しいアプリ（しかもあまり使い込んでいなかったもの）には慎重になりました。本当にその価値はあるのか？と。

もうひとつの懸念点として、トライアルの提供が難しいことがあります。ライフタイムサブスクリプションは、App Storeのルール上テクニカルにはサブスクリプション扱いではないため、アプリの無料トライアルを提供できません。これによって、ユーザーがライフタイムにアップグレードする前に数か月または1年分を支払わなければならないケースが発生し、導入が進みにくくなることがあります。

ブランド／ビジネスにとってのデメリット

ここからが難しいところです。ライフタイムサブスクリプションは、一般的に年額サブスクリプションの5〜12倍に価格設定され、期待されるLTV（ユーザー生涯価値）より少し上に位置づけられます。しかし平均値はしばしば誤解を生みますし、ライフタイムサブスクリプションは将来の値上げを考慮していません。

たとえば私の場合、すでに数年間Calmを購読しており、おそらくその後も長く継続していたはずです。このケースだと、Calmはライフタイムアクセスを提供したことで、私から得られたはずの収益が少なくなっている可能性があります。ライフタイム価格の設定が常に綱引きのようになる理由はここにあります。

ちなみに、私がCalmのライフタイムサブスクリプションを購入した価格は £119.99 でした。

当時、Calmは今よりはるかに安く（私の怪しい記憶では年間約 $29.99）、現在はライフタイムが $399、年額が $79.99 です。つまり、値上げ後の今なら、Calmは私を年額ユーザーのままにしておいたほうが、はるかに高い収益を得られたはずです。

インフレ、マーケットの変化、競合価格の推移、あるいはアプリ運営コストを押し上げる将来の新機能（例：AI機能）は予測できません。そのため、ある時点では妥当だったライフタイム価格が、数年後にはアプリの価値を大幅に過小評価するものになる可能性があります。

もうひとつのデメリットが アップセル です。すでにライフタイムを購入したユーザーにアップセルするのは非常に困難です。新しいプレミアムティアなど、ライフタイムに含まれない要素を打ち出すことはできますが、正直に言って煩雑です。ライフタイムから後でサブスクリプションに戻すことは基本的に不可能です。もしティアアップグレードがマネタイズ戦略の中心なら、ライフタイムは適さないかもしれません。

さらに、運用上の問題 もあります。サブスクリプションからライフタイムに切り替えるには、既存サブスクリプションをユーザーが手動でキャンセルし、その後ライフタイムを購入する必要があります。これは混乱を生み、誤って二重請求になるケースや、返金対応、サポート負荷増加、不満を持ったロイヤルユーザーにつながることがあります。

加えて、前述の重要な技術的ポイントもあります。アプリストア上では、ライフタイムは厳密には“サブスクリプション”ではありません。非消耗型のアプリ内課金として扱われ、以下のような影響があります：

1. サブスクリプション機能が使えない：無料トライアルや通常のアップグレードパスが提供できません
2. 手動での移行が必要：月額からライフタイムに“アップグレード”するボタンはなく、ユーザーは自分でキャンセルしてから買い直す必要があります。アプリによっては支援したり明確に説明したりしますが、誤解があると二重請求・返金・サポート問題につながります

また、将来的なプロダクト構築の悩み もあります。ライフタイム購入者を新しいプレミアムバージョンへ移行させるには、別のプロダクトバージョンを維持する必要があり、再度支払いを促すのも困難です。AstropadのCEOであるMatt Ronge氏はこれを身をもって経験しており、継続コストが高い中でライフタイムユーザーをサポートしつつ新機能を開発するのが難しかったと語っています。

彼はSub Clubで「もし過去に戻れるなら、初期ユーザーにもっと寛容にしただろう」と話し、こうアドバイスしています：“ペナルティではなく、ユーザーが自発的にアップグレードしたくなるほどのプロダクトを作れ。”

投資家の視点では、ライフタイムの収益は一度きりの収入であり、サブスクリプションのように予測可能で継続的ではありません。予測可能な収益は時間とともに複利で積み上がり、企業価値を高めます。ライフタイムへの依存が大きすぎると評価額が下がる可能性があり、これがB2B SaaSでライフタイムがほとんど使われない理由です。B2Bでは運用コストが高く、継続課金による評価額の増加が成長の鍵になるためです。

ライフタイムサブスクリプションの概要

ここまで多くの内容を取り上げてきたので、さらに深掘りする前に、ライフタイムサブスクリプションの主なメリットとデメリットをまとめておきましょう：

ライフタイムサブスクリプションの概要

ライフタイムサブスクリプションを提供すべきか？

判断を簡単にするため、シンプルなチェックリストを用意しました。「はい」が多いほど、ライフタイムサブスクリプションを導入する理由が強まり、「いいえ」が多いほど、テスト前に慎重な評価が必要になります。

1. ユーザー1人あたりの継続コストは低いですか？ 継続コストが高い（例：多くのAIアプリ）場合、ライフタイムサブスクリプションの魅力は下がります。
2. 現在、バリュエーション（企業価値）は優先度が低いですか？ 投資家やイグジットに向けた準備をしていないなら、ライフタイムは賢い選択になることがあります。バリュエーションが重要な場合、投資家は先に入る単発収益より、継続的な収益を高く評価します。
3. 今後の改善やランウェイ確保のために前払いキャッシュが必要ですか？ ライフタイムサブスクリプションは、開発や成長の資金となる大きなキャッシュブーストを提供できます。
4. リテンションが弱い、または不確実ですか？ ユーザーが早期に離脱する場合、ライフタイムオファーはリテンション改善に取り組む間の価値確保につながり、学習用のユーザーベースも拡大できます。
5. ライフタイムサブスクリプションを求めるユーザーセグメントがありますか？ 特に年齢層の高いユーザーやサブスクリプション疲れのある層が継続的に要望しているなら、テストする価値があります。
6. あなたの業界でライフタイムサブスクリプションは一般的ですか？ 他社をそのまま真似る必要はありませんが、もし珍しいなら理由があるかもしれません。
7. アップセルや上位ティアがモデルの中心ではありませんか？ ライフタイムは将来の成長を阻む可能性があります。ユーザーはライフタイム購入後、追加支払いやアップグレードをしにくくなるからです。

まだ急いで判断しないでください！ライフタイムサブスクリプションを進めると決めた場合でも、導入前に検討すべき重要なポイントがまだいくつかあります。

ライフタイムサブスクリプションを計画する際の注意点

クイズの質問すべてに「はい」と答えた場合でも、ライフタイムサブスクリプションを実際に導入する前に、慎重に検討すべき重要なポイントがまだいくつかあります：

1. ライフタイムサブスクリプションの価格設定方法

価格設定は極めて重要です。低く設定しすぎればMRRを損なうリスクがあり、高く設定しすぎれば潜在顧客を遠ざける可能性があります。ライフタイムサブスクリプションの価格はアプリによって大きく異なり、プロダクトや市場によっては年額の2倍からほぼ12倍まで幅があります。

以下は、アプリごとにどのような価格設定をしているかの例です（※価格は定期的に変更され、国によって異なります。ここでは1つの市場における現在の価格を基にしています）：

ライフタイムサブスクリプションをこの価格帯のどこに位置づけるべきか判断するには、次の点を考慮してください：

• 年額価格
• 年間チャーン率
• 粗利率（グロスマージン）
• カテゴリ特性とリテンションパターン

リテンションが強く、粗利率が低い場合は、一般的に高めの価格設定が可能になります。また、平均値だけでなく、コホート別にLTVを確認することも重要です：

• 直近のユーザーはどれくらいリテンションしているのか？
• 最もアクティブなユーザーのリテンションはどうか？ そのLTVは？

このアプローチにより、低すぎる価格設定によって自らの収益を食い潰してしまうリスクを回避できます。

迷う場合は、Waking Up（瞑想アプリ）のように、高めの価格設定を選ぶことを私は常におすすめします。Waking Upのライフタイムオファーを見つけるのは難しかったのですが（なぜそれが良いことなのかは後ほど触れます）、彼らはライフタイムサブスクリプションを Wall Street Journalの報道によれば、$1,500 に設定しており、年額価格の 11倍以上 です。これにより、本当にロイヤルなユーザーだけが購入する仕組みとなり、Waking Upにとっても十分に合理的な戦略になっています。

2. どのオーディエンスを対象にし、どこでプロモーションするか

ターゲットとなるオーディエンスは、価格戦略と密接に結びついています。私の仮説としては、Waking Upは最もロイヤルなユーザーのコンバージョンを狙っており、一方Calmはライフタイムサブスクリプションをチャーン抑制やホリデー向けオファーとして活用しているため、年額の約5倍という比較的低めの価格設定にしているのだと思います。

ターゲットが誰かを理解していると、そのオファーをどこで宣伝すべきかも決めやすくなります。多くのライフタイムオファーは、アプリのペイウォールには大きく表示されません。代わりに、メールで送られたり、一度きりの特別オファーとして案内されることが一般的です。

一部のアプリでは、戦略の一環として、意図的にすべてのユーザーへライフタイムサブスクリプションを提供することもあります。これは、Placifyのようなユーティリティ系のアプリ（パーソナルマッピングアプリ）でよく見られます：

そして、月の満ち欠けとカレンダーのアプリである Moonly も同様です。価格が比較的低かったり、月ごとに利用頻度が変動しやすいタイプのアプリでは、ライフタイムサブスクリプションは期間限定プロモーションではなく、提供プランの標準的な一部として扱われることがあります。

実際のところ、私が最も多く目にし、また受け取ってきたライフタイムオファーは、Fiitというフィットネスアプリのように メール経由 のものでした：

このときは、ちょうどサブスクリプションを解約した直後だったため、復帰（win-back）を狙った施策 のように感じました。全体として、ライフタイムオファーを広くプロモーションする前に、まずは 自社チャネル（メール、プッシュ通知、アプリ内通知など） を使ってテストすることをおすすめします。もちろん、アプローチはどのオーディエンスを対象にするかによって変わります。

3. 利用規約

最もワクワクする部分ではありませんが、ライフタイムサブスクリプションが裏目に出るのを防ぐためには極めて重要です。（念のため：これは法的アドバイスではありません！ ここは法務に確認すべき領域です。）

以下の点をしっかり考えておく必要があります：

• 複数のティアがある場合、ユーザーはどのプランに含まれるのか
• 他の割引と組み合わせ可能かどうか（私は非推奨です）
• アプリの将来的な大きな変更をどう扱うのか
• サブスクリプションからライフタイムへの移行がどのように行われるのか

2つ目のポイントは特に重要です。たとえば、ライフタイムサブスクリプションにファミリープランを適用すると、ユーザーが想定以上の価値を得てしまい、収益を圧迫する可能性があります。

4. テスト戦略を決める

ここまでで、ライフタイムサブスクリプションをテストする際の基本的な戦略の感触はつかめてきたはずです：

• 価格設定：年額の5倍・8倍・12倍など、異なる倍率のA/Bテストを実施し、コンバージョンだけでなく「誰が」転換しているのかも追跡する
• 誰に見せるか：離脱ユーザーやリテンションの低いセグメントから始める
• いつ提示するか：ブラックフライデー、元旦など季節のプロモーションでテストし、常設化するかどうかを判断する

しかし、ここで残る最後の重要なポイントがあります：どう測定すれば成功といえるのか？

ライフタイムを買わなかった場合にそのユーザーがいくら使っていたかを正確に知るのはほぼ不可能で、比較対象のコホートは予測LTVに基づくことになります。

そのため、次の点を見るべきです：

• コンバージョン率：他のオファーと比べてどれくらい転換するのか、どのセグメントが転換しているのか
• ARPU（ユーザー平均収益）と類似コホートの比較：従来のサブスクリプションと比べて、収益が増えているのか減っているのか

また、次の指標を見る価値もあります：

• ライフタイム購入者のエンゲージメント：支払い済みでも利用しないユーザーはプロダクトを推薦しにくい
• 返金・サポート負荷：二重課金問題の発生有無、返金リクエスト、サポート量を監視
• 収益構成の比率：ライフタイム vs サブスクリプション収益の割合を追跡 — ライフタイム比率が高すぎると、短期キャッシュの代わりに複利で積み上がるMRRが犠牲になる可能性あり

最後に、まずは自社チャネルで小規模または期間限定のテストを行いましょう。これにより、初期データから学び、最適化し、本格展開に備えることができます。

では、Calmのライフタイムサブスクリプションは価値があったのか？

私にとっては、はい。Calmを“生涯購入”したことで、サブスクリプションがもう一つ増えるという精神的負担がなくなり、数年経った今でも「お得だった」と感じています。ただし、これこそがポイントです。ライフタイムサブスクリプションは、たいてい顧客にとっては“勝ち”に感じられますが、必ずしもブランド側の“勝ち”にはならないのです。

もしCalmが私を年額プランのまま維持していたら、今頃はもっと多くの収益を得られていたでしょう。それでもCalmは、長期的な収益を前払いのキャッシュと引き換えにしたわけで、その時点では新機能、著名人のナレーション、増え続けるコンテンツ制作の資金として合理的な選択だったのかもしれません。

これはすべてのアプリが直面するトレードオフです。ライフタイムサブスクリプションは、必要なときに資金を得る手段になり、ロイヤルティを高め、小規模アプリが大手と差別化する助けにもなります。 一方で、最も価値の高いユーザーの収益を食い潰し、アップセルの機会を減らし、長期にわたる運用上の負担を生む可能性もあります。

もしライフタイムサブスクリプションを検討しているなら、数字をしっかり確認し、慎重にテストし、誰のために提供しようとしているのかを明確にしてください。なぜなら、顧客が「すごくお得！」と思っているとき、あなたの側も本当に同じように思えている必要があるからです。

今週のSub Clubポッドキャストでは、エリックを迎え、彼の最新の「Consumer Subscription Software Report」で明らかになった知見について話を聞きました。コンシューマーサブスクリプションの未来、AIが成長をどのように再構築しているのか、そして優れたアプリが買収目的ではなく“愛されるため”に作られている理由について語り合いました。

https://www.youtube.com/watch?v=IGxuXkPXEco

サブスクリプション疲れという“神話”

サブスクリプション疲れは話題になりがちですが、Eric氏によればこれは大きく誤解されています。消費者は、実際に価値をもたらすプロダクトにはこれまで以上に進んでお金を払うようになっています。サブスクリプション管理ツールによって請求はより透明になり、AIを活用したアプリはまったく新しいユーティリティやエンターテインメントのカテゴリを生み出しています。

Eric氏が説明するように、ユーザーは使っていないサービスを解約することはあっても、“なくてはならない”サービスには支払い続けます。開発者にとってのチャンスは、数を増やすことではなく、ユーザーが本当に価値を感じる少数のアプリを作ることに集中することです。

Runna、Strava、そして“買収されるプロダクト”の作り方

Eric氏は、StravaによるRunnaの買収を支援した際の学びについても共有してくれました。彼によれば、この取引がうまくいったのは、両社が合流する前に、それぞれが強力な単独プロダクトを築き、忠実なオーディエンスを獲得していたからです。特定の買い手だけを想定してプロダクトを作るのではなく、創業者はまず“消費者が愛するもの”を作るべきであり、優れたプロダクトには自然と買収オファーが集まるということです。

Stravaにとって、Runnaの買収は“自分をアスリートとは認識していなかったランナー層”にリーチすることで市場全体を拡大させるものでした。創業者にとってこれは、インテグレーションやバンドルが新しいユーザーや新たな収益階層への扉を開く可能性を示す好例です。

AI、アプリストア、そして次の波

AIは、アプリの発見方法からプロダクト開発に至るまで、あらゆる領域を変えつつあります。ユーザーがレコメンデーションのためにチャットボットを利用するようになり、検索トラフィックのパターンが変化しているため、マーケターはSEOやアトリビューションを再考せざるを得ません。しかし同じAI技術が、チームのテスト速度を高め、コンテンツ生成を支援し、リテンションを改善する力にもなっています。

Eric氏は、もう1つの大きな追い風として、アプリストアの“解放”が進んでいる点を挙げています。GoogleとAppleが外部決済に関する制限を緩和したことで、開発者は利益率の15〜20%が自社の収益に戻る可能性があります。さらに、ペットウェルネスやスクリーンタイム管理といった新たなカテゴリに広がる機会も加わり、まだ大きな成長余地が残されていることは明らかです。

まとめ

ここで紹介したのは、Eric氏との対話で取り上げたテーマのほんの一部にすぎません。AI、買収、そしてコンシューマーサブスクリプションの未来についてさらに詳しく知りたい方は、YouTubeやお使いのポッドキャストアプリで、今週のSub Clubポッドキャストのエピソードをぜひお聴きください。

ウェブは、料金テストの実施、キャンペーンの実行、そしてリンクを置ける場所であればどこでもサブスクリプションを販売できる点が魅力です。

しかしこれまでは、RevenueCatでこれを管理するために、プロダクト設定、購入リンク、インテグレーションの各ページを行き来する必要がありました。

新しいダッシュボードのWebオーバービューは、これを変えます。セットアップ、インサイト、パフォーマンスを1つの場所にまとめ、RevenueCat内でウェブ収益を作成・分析・成長させることができるようになります。

あなたのウェブビジネス全体をひと目で把握

ダッシュボードのWebオーバービューは、RevenueCatにおける「ウェブ関連すべての拠点」です。セットアップ、パフォーマンス、最適化を、1つのオーバービューにまとめて表示します。

最上部には、ウェブ収益、アクティブサブスクリプション、MRRに関する主要指標が表示されます。各チャートはより詳細な分析ページに直接リンクしており、ワンクリックでオーバービューからインサイトへ移動できます。

その下には、すべてのWeb Purchase Linksのオーバービューが表示されます。各リンクには、インプレッション、購入数、収益、コンバージョン率が示されます。これらを並べて比較することで、どのキャンペーンが最も成果を上げているかを確認でき、またメール、ランディングページ、広告用に、新しいリンクを数秒で作成することもできます。

同じビューからWeb Settings/Configsを開き、外観、チェックアウトデザイン、接続設定を調整することも可能です。ページを離れる必要はありません。

ダッシュボードには、オンボーディング、教育コンテンツ、そしてウェブを活用してサブスクライバーを獲得・維持するための事例が組み込まれています。新しい機会を提示し、セットアップを支援し、時間とともにコンバージョン改善を促すよう設計されています。RevenueCat Webを使って新しいオーディエンスにリーチした際に何が可能になるのかを示す実践的な動画、ステップバイステップガイド、カスタマーストーリーも揃っています。

「私たちの目標は、ウェブがiOSやAndroidと同じくらいRevenueCatにとって“ネイティブ”に感じられるようにすることでした。何がうまくいっているかを理解するためにツール間を移動する必要はありません。新しいダッシュボードは、それらすべてを1つのビューにまとめています。」— Ed Shelley, Senior Product Manager

あなたがサブスクリプションアプリで、急遽ブラックフライデーキャンペーンを実施している場面を想像してみてください。ダッシュボードでは、各Web Purchase Linkごとのセットアップやコンバージョンを確認でき、メールからのリンク、広告キャンペーンからのリンクなどが一目で把握できます。

ダッシュボードのWebオーバービューは、最初のクリックから継続的なコンバージョンに至るまで、ウェブ収益の全体像を明確に示します。

今日からダッシュボードのWebオーバービューを使い始めましょう

より多くの開発者が、アプリストアの外へと拡大し、新しいオーディエンスやユースケースを取り込んでいます。RevenueCat Webを使えば、ペイウォールの公開、キャンペーンの実施、そしてウェブ上での直接販売を安心して行えます。ダッシュボードのWebオーバービューは、これらの機能をより使いやすく、理解しやすくします。

Webオーバービューは、すべてのRevenueCatユーザーにすでに提供されています。今日RevenueCatを開くと、サイドバーに「Web」が表示されているはずです。

すでにウェブで販売している場合は、あなたのセットアップとデータがそのまま反映されています。まずは、コンバージョンを最も牽引しているWeb Purchase Linksを確認し、どのオファーが成果を生み出しているかを見てみてください。

ウェブでのマネタイズが初めての場合は、オンボーディングがセットアップを案内し、最初のリンクを数分で公開する方法を示します。テンプレートやガイド付きフローが用意されており、コードは不要です。

ぜひ今日開いて、オーバービューを確認し、ウェブがより速く成長するためにどのように役立つのかを実際に体験してみてください。

でも、その認識はOKR を本当にうまく使いこなしている会社で働いたことで一変しました。OKR はただのチェックボックスではなく、長期的なビジョンを実際のアクションに落とし込むための戦略的な仕組みだったのです。単に、これまで私はうまく運用されている OKRを見たことがなかっただけでした。

今では、OKR はどの会社にもおすすめできるフレームワークだと考えています。フォーカスを研ぎ澄まし、チームを揃え、戦略を実行可能な形に変えてくれる。私は OKR を「追加の仕事」としてではなく、明確さ・コラボレーション・実際のインパクトを生み出すためのツールとして使っています。ジムに通い続けたときに得られる長期的な効果のようなものです（数回通っただけで腹筋が割れるわけではありませんが）。

この記事は、私が最近開催した「サブスクリプションアプリのための OKR と KPI」ワークショップをベースにしています。共に登壇したのは、Rosie Hoggmascall氏（『Growth Dives』著者・Fyxer.ai の Growth Lead）と、Hanna Grevelius氏（Bruce Studios CPO、元 Golf Gamebook / Fishbrain）。この記事では、彼女たちの実践的な知見――正しい KPI の設定方法から、よくある OKR の落とし穴まで――を紐解きます。データを追いかけるだけの状態から抜け出し、インパクトを生み出すための戦略的なデータ活用へ進むために。