個人開発で一番怖かったのは、技術選定でも実装でもなく、課金実装だった。 サブスクのレシート検証? 復元処理? エッジケース? ──全部、RevenueCatに丸投げで解決しました。
前回の記事はこちら 【SÉtelier開発記 第3回】未経験者がぶつかった4つの実装地雷
↑前回 では、React Native移行後にぶつかった4つの実装地雷をまとめました。アプリ自体は形になったけれど、リリースに向けてまだ大きな山が残っていました。
『マネタイズ』です。
ここは連載の中でも『個人開発で挫折する人が特に多そうな関門』かもしれません。技術的な詰まりは「動かない」で済むけれど、課金まわりは「動いているように見えるけど、実は壊れている」が起こる。お金の話なので、間違うとユーザーに被害が及ぶ。
未経験者の僕が、この関門をどう抜けたかをまとめます。
※まだリリースして間もなく実成果がない状態ですが、今回の連載は備忘録的立ち位置のため、参考程度に…。
個人開発で一番怖かったのは課金実装だった
アプリを作っているときは『使ってもらえる嬉しさ、開発の楽しさ』だけを考えていました。でも、いざリリースを意識し始めて、課金実装のことを調べた瞬間に頭が真っ白になりました。
調べると出てくる単語たち:
- StoreKit 2(iOS)
- Google Play Billing Library(Android)
- レシート検証サーバー
- サブスクリプションの状態管理
- 購入復元処理
- 期限切れの判定
- 返金処理への対応
個人開発者一人にはやることが多すぎる！
しかも、お金が絡むのでバグが許されません。「ユーザーが課金したのに、Pro機能が解放されない」とか「サブスクをキャンセルしたのに、まだ課金され続ける」とか、そういう事故は致命的です。レビュー欄が炎上するし、最悪、Appleからアプリを止められる可能性もある。
技術以前に、開発における責任の重さをダイレクトに認識しました。
救世主:RevenueCatというサービス
調べる中で見つけたのが、『RevenueCat』というサービスでした。
ざっくり言うと、『課金まわりの面倒なことを全部代行してくれるバックエンド + SDK』です。月額・年間・買い切りの管理、レシート検証、購入復元、サブスク状態の追跡――個人開発者がゼロから書こうとすると死にそうな処理を、SDK経由で一気に解決してくれる。
StoreKit/Billing 直接実装との比較
未経験者目線で並べてみると、こんな違いがあります。
| 観点 | StoreKit/Billing 直接 | RevenueCat |
|---|---|---|
| iOS/Android対応 | それぞれ別SDK | 統一API |
| レシート検証 | 自前でサーバー実装 | 代行 |
| 購入復元・サブスク管理 | 手動実装、エッジケース多数 | restorePurchases() 1行 |
| 追加コスト | なし | 月$2.5K MTR(月間追跡収益)まで無料 |
『追加コストはあるけど、開発コストを大幅に削減できる』という、個人開発と相性の良いサービスでした。
しかも、年間収益が$10,000(月収$833相当)を超えるまで完全無料という料金体系。『個人開発者が個人開発者であるうちは、実質0円』と言って差し支えないです。
「楽に倒れる」方向を選んだ
個人開発で大事かもって思ったのは『楽に倒れる』ことです。
つまり、『どこで失敗しても、リカバリしやすい構造を選ぶ』。これは第2回で書いた「早く諦める」とも、第3回で書いた「引き算する」とも、根っこは同じ判断軸です。
StoreKit直接実装は、上手くいけばコストが下がる。でも、未経験者が一発で完璧に書ける可能性は低くて、バグれば取り返しがつかない。
一方RevenueCatは、初期コストはかかる(といっても無料枠で済む)けど、SDKが堅牢にメンテされていて、未経験者でも事故りにくい。
『リスク対費用』の観点で、RevenueCatは個人開発者にとって明確に優れた選択でした。
学び:個人開発のマネタイズは『楽に倒れる』設計を最優先する。 自分で書けるかではなく、事故ったときのリカバリを考える。
月額・年間・買い切りの3本立てにした理由
価格設計でも色々悩みました。一般的なアプリは『月額のみ』とか『買い切りのみ』のシンプルな形が多いですが、SÉtelierでは『月額・年間・買い切り』の3つを用意することにしました。
価格と用途
| プラン | 価格 | 想定ユーザー |
|---|---|---|
| 月額 | ¥300/月 | 気軽に試したい / 短期集中 |
| 年間 | ¥1,800/年(月150円相当) | 継続的に使う / お得感重視 |
| 買い切り | ¥4,800 | サブスク回避層 / ずっと使いたい |
なぜ3本立てにしたか
『1つだけにすれば、判断が簡単になるのでは?』と最初は思いました。
たとえば月額¥300だけ、とか。
でも、SÉtelierのターゲット(リラックスしたい人、作業用BGMを求めている人)を考えると、ユーザーの『お金の払い方の好み』にバラつきがあるはずだと思います。
- 『試しに使ってみたい』人 → 月額が一番ハードル低い
- 『気に入ったから長く使いたい』人 → 年間でお得感を享受できる
- 『サブスクが嫌い、一発で買いたい』人 → 買い切りがフィット
『一つに絞ると、絶対に取りこぼす層が出る』という可能性を考慮し、3本立てにしました。
サブスク嫌いへの誠意
特に意識したのが『買い切り¥4,800』の存在意義です。
最近のアプリは、ほぼ全部サブスクモデルです。「Spotify、Adobe、Notion、Netflix…」と、月額課金で生活が圧迫されている感覚を持っている人は多い。
僕自身、『これ以上サブスクを増やしたくない』と感じる場面があります。だから『サブスクが嫌いな人にも、買い切りという選択肢を渡す』ことは、ユーザーへの誠意だと考えました。
¥4,800はぱっと見高く感じるかもしれませんが、月額換算すると16ヶ月分(約1年4ヶ月)。年間プランより少しお得になるくらいの設定です。長く使う人には買い切りが結局得になる。
学び:価格は『戦略』だけで決めるものではなく、ユーザーの『払いたい形』に応える誠意でもある。
無料/Proの線引き:5つの設計判断
3本立ての価格を決めても、『無料で使える範囲をどこまでにするか』はもうひとつの大きな判断ポイントです。
線引きで意識した原則
設計で大事にしたのは、ひとつのシンプルな原則です。
『無料でも、完成品として成立する体験を提供する』
これは『無料を物足りなくして課金を強制する』とは正反対の考え方です。理由は2つあります:
- 物足りない無料アプリは、口コミが広がらない(評価が低くなる)
- 『完成品』として満足してもらった上での課金の方が、ユーザーの満足度が高い
たとえばオトダマ配置数の制限。12個に絞っていますが、これは『12個でも十分に楽しめる』ラインだと判断したからです。
家のリビング全体に音をばらまくような『複雑な配置』をしたい人だけが課金する。普通に作業用BGMとして使う分には、12個で十分にチルな空間が作れます。
5つの主要な線引き
| 機能 | 無料 | プレミアム | 線引きの理由 |
|---|---|---|---|
| オトダマ配置数 | 12個 | 無制限 | 量的制限。12個で十分使える |
| 音階モード | ペンタトニック | + 全音階 | UX的優位は無料側、自由度はPro |
| プリセット保存 | 2個 | 50個 | 『気に入った設定を保存できる』のは無料、量はPro |
| 演奏モード | ロック | 利用可 | 『遊び方の拡張』はPro |
| バックグラウンド再生 | 自動停止 | 継続 | 『深く使う人向け』機能はPro |
全音階モードを「Pro機能」にした思想
第3回で書いた『ペンタトニックスケール』の話を覚えていますか?
無料ユーザーには『どう置いても気持ちいい音楽が作れる』ペンタトニックを提供。
Proユーザーには『自由度の高い全音階』を解放。
これは『初心者には安全な道、慣れた人には自由を』という、UXとマネタイズを綺麗に重ねた設計でした。
『Pro機能=便利機能』ではなく『Pro機能=深く使う人向けの拡張』というポジショニングを徹底しています。
学び:無料の役割は『お試し』ではなく『完成品』。 Proの役割は『深く使う人への拡張』。両者は競合ではなく補完。
AdMobとリワード広告:「15分Pro体験」のアイデア
もうひとつのマネタイズ要素が広告です。AdMobを使ったバナー広告と、リワード広告(動画広告を見ると報酬がもらえる仕組み)を組み合わせています。
バナー広告:無料ユーザーへの最低限の収益化
下部のコントロールバーの下に、薄めのバナー広告を1つだけ表示しています。
プレミアムユーザーには表示しません。
アンビエントBGMという用途を考えると、画面を見ない時間も多いはずなので、邪魔にならない位置にしています。
リワード広告:「動画を見てPro機能を15分体験」
これは個人的にちょっと工夫したポイントです。
設定メニューの中に『広告を見てPro機能を15分体験』というボタンを置きました。動画広告を1本見ると、15分間だけPro機能(全音階・無制限配置・スリープタイマーなど)が解放されます。1日3回まで利用可能。
このアイデアの狙い
『お金は払いたくないけど、Pro機能を試してみたい』というユーザーに、自然な体験を提供するためです。
普通のアプリだと:
- 無料で使う(Proの存在は知ってるけど試せない)
- ある日いきなり課金する
という二択ですが、SÉtelierでは:
- 無料で使う
- リワード広告でPro機能を体験する
- 『便利だな、おもしろい』と気付いて課金する
という3段階のジャーニーが用意できる。
ユーザーから見れば『試してから払える』、開発者から見れば『広告収益と課金転換率の両方が上がる』。Win-Winです。
実装的(コード)には、リワード広告を見終わった瞬間に ”isPremium” を “true” にして、15分後に “setTimeout” で “false” に戻すだけ。難しくない。
学び:広告は『邪魔者』ではなく『マネタイズの選択肢を増やす道具』。 工夫次第でユーザー体験を高められる。
ただ、正直ここの配分は難しい。「一日15分×3回」って、無料トライアルだけでプレミアム機能を毎日十分に使えうる。つまり、課金する必要性を希薄させているとも考えられます。
しかし、以下の2点から今回は甘めに設定しました。
（１）当アプリは作業用や睡眠用で長時間継続して使われる前提である
⇒15分×3回＝45分でも、ユーザーが時間的不足を感じる可能性は十分ある
（２）アプリ自体も僕自体も無名である、実績も信頼もまだない
⇒ユーザーがプレミアム機能まで十分に扱ってくれることで、アプリのレビューや定着を必然と促せる
API Key未設定でも動かす:フォールバック設計
最後にひとつ、地味だけど大事な設計判断を共有します。
RevenueCatもAdMobも、外部サービスのAPI Keyが必要です。SÉtelierではこれらのサービス連携の前にコード自体は完成させていたので、開発期間中は『API Keyがまだ設定されていない状態』が続きました。
このとき問題になるのが、『API Keyが空のままだとアプリがクラッシュする』ということ。SDKの初期化失敗で、最悪起動すらしない。
ここでもClaudeから提案を受けて、『API Key未設定時はフォールバック表示する』設計を採用しました。
具体的には:
purchases.tsで API Keyのチェックを最初に入れる- 未設定なら
console.warnを出して、固定価格テキストを表示 - 直接
unlockPremium()を呼べるダミー機能を提供(開発時のみ)
これで:
- API Key設定前でも、アプリは正常に動く
- プレミアム比較モーダルなどUIの確認ができる
- 後からAPI Keyを入れるだけで、本番動作に切り替わる
未経験者にとって、『外部サービスのAPI Keyを後から設定する』というフローは普通に不安なんですよね。
「もし入れ忘れたらリリース時にクラッシュする」とか、「テスト時に本番のキーを使ってお金が動いたらどうしよう」とか。
フォールバック設計があれば、そういう不安が一気に消えます。
学び:外部サービス連携には必ずフォールバックを用意する。 未経験者は『動かない状態』で時間を溶かしがち。
まとめ:マネタイズも『楽に倒れる』設計で
第4回の話を一言にまとめると、
『個人開発のマネタイズは、自分で全部書こうとしない』
技術的に書けるかどうか以前に、お金が絡む処理は『一度の事故が致命的』です。だから:
- 課金は RevenueCat に丸投げ
- 広告は AdMob を使う
- API Keyが入っていない時もアプリが動くようにする
- 価格は『ユーザーの払い方の好み』に合わせて3本立て
- 無料/Proの線引きは『無料でも完成品』を原則に
ここまでを徹底すれば、未経験者でも『安全に・誠実に』マネタイズへの導線が引けます。
…といってもまだ課金実績ないんですが！！！(2026/05/09時点)
第2回・第3回・第4回を通して見えてきたパターンは、結局すべて『楽に倒れる設計』に行き着きます。
AIに従って始める、AIが詰まったら撤退する、AIに先回りされたら素直に従う、面倒な処理はサービスに任せる。（ただし、セキュリティ面は逐一確認すること）
これが僕の歩んだ、未経験者+AIで作るアプリの道です。
次回予告
最終回予定の第5回は『Mac無しでApp Store公開編 — EAS Buildで本当に出せるのか』です。
連載の冒頭で約束した『Windows一台でiOSアプリを公開する』のゴールに辿り着きます。Apple Developer登録の手続き、EAS Buildの仕組みと料金、TestFlight、審査で引っかかりやすいポイント、アイコン・スプラッシュ・プライバシーポリシーまで――この連載で語ってきた全工程の集大成です。
追記：更新しました↓
iOSアプリ開発備忘録（もとい、SÉtelier 開発記） 第4回 / 全5回
↓公開したアプリのリンクです（興味あれば！フィードバックも大変有難いです！）↓
コメント