月数十時間の調査工数を削減。YAMAPのサブスクリプション基盤を支えるRevenueCatの導入効果

サマリー

「YAMAP」は 540万ダウンロードを超える、日本最大級の登山アウトドアプラットフォームです。ユーザー体験の向上と事業成長を加速させる中で、同社は内製していた課金基盤が複雑化し、担当者に依存する状況を課題として抱えていました。こうしたボトルネックを解消し、エンジニアリングリソースをよりコア領域へ振り向けるため、アプリ内課金サブスク管理サービス「RevenueCat」を採用しています。

今回は、導入の背景や意思決定のプロセス、さらに月数十時間単位の工数削減や施策実行のスピード向上といった成果について、株式会社ヤマップCTOの樋口様、アプリエンジニアの落石様、バックエンドエンジニアの溝上様に詳しく伺いました。

課題

──RevenueCatを導入する前、YAMAPプレミアムの課金システム運用では、どのような課題があったのでしょうか？

溝上様：バックエンドでは、複数プラットフォームを横断して扱う点が大きな負荷になっていました。iOSやAndroid、そしてWeb（Stripe）でそれぞれ仕様が異なるため、すべてを正確に理解したうえで実装し、さらにアプリやフロントエンドで扱えるよう抽象化する必要があったのです。プラットフォームが増えるほど工数も比例し、システム自体がどんどん複雑化していました。

落石様：アプリ側でも同様に、GoogleやAppleが追加する返金対応や新しい購入フローなど、仕様変更のスピードに追従し続けるのが難しくなっていました。変更点を完全に把握しきれず、一部の課金ステータスを正しく処理できないケースが生じたりと、考慮漏れが発生するリスクも抱えていました。加えて、アプリ内課金関連のSDKは少なくとも年に一度はアップデートが必要で、iOSではStoreKit 1から2への移行対応といった大きな負荷も発生していた状況です。結果として、こうした対応に相当なリソースを割かざるを得ませんでした。

──メンテナンスや問い合わせ対応において、どのような点が負担となっていたのでしょうか？

樋口様：最も困っていたのは、ユーザーからのお問い合わせに対する調査です。
溝上様：お問い合わせには真摯に答えたいと考えていましたが、当時はシステムがあまりに複雑化していたため、原因特定までに時間がかかることが多くありました。些細な修正でも難易度が高く、対応に時間を要してしまうケースも少なくありません。正直なところ、調査を進めても「本当にこれが正解なのか」と自信を持ちきれないほど、システムが複雑に入り組んでいたのだと思います。

導入背景

──RevenueCatの導入を検討し始めたきっかけについて教えてください。

樋口様：最初のきっかけは、データ分析チームからの推薦でした。2024年頃に、データチームが取引のあるマーケティングツール企業から「こういったサービスがあります」と紹介を受けたのがきっかけです。当時ちょうど、私たち自身も課金基盤の複雑化を強く課題として認識していたため、本格的に乗り換えを検討する流れになりました。

──データ分析チームの推薦だけでなく、開発側としても導入に前向きだったのでしょうか？

樋口様：紹介を受けた段階から、導入にはかなり前向きでした。データ分析チームが抱えていた課題はもちろん、開発側にとっても既存の課金基盤の運用は非常に大きな負担になっていたためです。RevenueCatを活用すれば、複雑なシステム調査や仕様変更への追従、さらにはメンテナンスにかかる工数を大きく圧縮できるのではないかという期待がありました。そうした負荷が解消できるのであれば、導入コストを十分に上回るメリットがあると判断した形です。

導入の決め手

──競合サービスと比較する中で、最終的にRevenueCatを選んだ理由を教えてください。

樋口様：最も重視したのは、導入実績の信頼性とサポート体制への期待感です。RevenueCatは国内外で多くの企業に採用されており、利用ユーザー数も十分にある点が安心材料でした。また、開発者向けドキュメントが非常に整備されており、導入や運用のイメージがつきやすかったことも大きかったですね。他の海外サービスと比較しても、問い合わせ対応を含めたサポートが期待できると判断できたことが決め手になりました。実績とサポート、この2点が最終的な選択を後押ししたと感じています。

──機能面で「これは導入の後押しになった」と感じたポイントがあれば教えてください。

落石様：個人的に強い魅力を感じたのはPaywall機能です。従来、課金ページのデザインを変更する場合、アプリ側の実装に加えてストア申請が必要で、どうしても2週間以上かかっていました。一方、Paywallを使えばWebの管理画面からリアルタイムでクリエイティブを更新でき、ABテストも即時で実行可能です。これによって施策のPDCAを一気に早められる点は、アプリサイドから見ても非常に大きなメリットでした。導入を決める上で、確かに後押しになった機能だと思います。

導入結果

──導入後、課題となっていた問い合わせ対応の工数はどの程度削減されましたか？

溝上様：まだ既存システムとの移行が続いている段階ですが、すでに効果ははっきりと出ています。これまで月に数十時間かかっていた調査工数は大幅に圧縮されました。正確な数値は測定していないものの、ユーザーからのお問い合わせに対して、原因を特定し回答に至るまでのスピードは格段に向上しています。以前のように複雑さゆえに「本当にこれで合っているのか」と不安を抱えることもなくなり、今では自信を持って対応できるようになりました。

──工数削減以外に、導入によって得られた想定外の効果はありましたか？

落石様：大きな発見として、課金状態の“健全化”が挙げられます。移行作業を進める中で、以前のシステムでは返金処理が正しく反映されず、本来は無料会員に戻るべきユーザーが継続してプレミアム機能を利用できていたケースが見つかりました。

樋口様：しかも、その件数は少なくありませんでした。これは本来得られるはずだった売上を取りこぼしていたことにもなります。RevenueCatへの移行によって、これまで見えていなかった機会損失が可視化され、事業の健全性を大きく高めることができました。

──期待されていたPaywall機能の導入によって、施策スピードはどのように改善しましたか？

落石様：施策のスピードは劇的に向上しました。これまでは2週間以上かかっていましたが、Paywall導入後は、エンジニアの実装もストア審査も不要になり、体感としては1週間ほどに短縮されています。マーケティングチーム主体でABテストを繰り返せるようになった点は非常に大きい成果です。

──開発体制やプロセスの観点で、他にどのようなメリットがありましたか？

落石様：アプリサイドでは、「安心して開発できる環境」が整ったことが大きな改善です。年1回ペースで実施していた課金関連SDKのアップデートは、毎回リスクが高く神経を使う作業でしたが、その役割をRevenueCatが担ってくれています。また、これまでアプリ内に保持していたLPもPaywallに集約でき、メンテナンスが一気に効率化しました。
溝上様：バックエンドでも同じです。これまでiOS、Android、Webという3つの異なる仕様を理解し、個別に実装していましたが、今はRevenueCatの仕様だけを見ればよくなりました。その結果、コードは大幅にシンプルになり、各プラットフォームのバージョンアップにも落ち着いて対応できるようになっています。

RevenueCatについて

──今後のRevenueCat活用について、どのような展望をお持ちでしょうか。

溝上様：すでに動き始めているものとして、データチームが外部のマーケティングツールとRevenueCatを連携させています。これにより、ユーザーの課金イベントを起点に自動アクションを実行できるようになりました。以前は「実装コストが高すぎて、そもそも検討にすら至らない」という施策も多かったのですが、今ではほぼ実装ゼロでビジネス判断だけで動かせるようになっています。この変化は非常に大きいと感じています。

落石様：今後はマーケティングチームにPaywallでのABテストを積極的に回してもらい、CVR改善を加速させたいと考えています。開発側としては、まだ自社システムに残っている「消費型課金」の部分についても、余裕ができ次第RevenueCatに移行していく方針です。これが進めば、クライアント側・バックエンド側の双方でシステムがスリムになり、メンテナンス性がさらに向上するはずです。

──どのような課題を抱える企業にRevenueCatを薦めたいと考えていますか？

樋口様：アプリ内課金をシンプルにしたい企業には特に適していると思います。複雑な商品体系を持っていたり、割引キャンペーンを多く展開していたりする場合、サブスクリプション管理の負荷はどうしても大きくなるためです。経営の視点では、単に導入してコストを削減するだけでなく、Paywallのような機能を積極的に活用し、売上向上につながる施策までしっかり打っていくことが重要です。工数削減と収益向上の両面で効果が期待できるサービスだと感じています。