LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリ内課金・サブスクリプションとは — 課金種別と適用ルールの概要

アプリ内課金・サブスクリプション実装の外注とは、モバイルアプリ（iOS・Android）においてストア経由で収益を得るための課金機能を、Apple/Googleの公式フレームワークを使って設計・開発・検証する作業を外部のパートナーに委託する取り組みを指します。

アプリ内課金には大きく4つの種別があります。Apple・Googleともに同様の分類を設けており、仕組みと適用ルールを正確に把握することが実装の前提となります。

• 消耗型（Consumable）：購入後に使い切るアイテム（ゲームコイン・スタミナ等）。複数回購入できます。
• 非消耗型（Non-Consumable）：一度購入すれば永続的に利用できる機能解除（広告非表示・追加レベル等）。復元処理の実装が必要です。
• 自動更新サブスクリプション（Auto-Renewable Subscription）：月次・年次など周期的に課金される。解約・更新失敗・猶予期間など状態管理が複雑です。
• 非更新サブスクリプション（Non-Renewing Subscription）：一定期間の利用権を都度購入する形式。自動更新はされません。

アプリ内でデジタルコンテンツを提供・販売する場合、Apple・Googleのデベロッパーポリシーにより原則としてアプリ内課金の利用が求められます。物理商品の購入や実店舗サービスの予約など、アプリ外でも提供できる商材については外部決済を利用できますが、デジタルコンテンツには基本的にストア課金が求められます。

この原則を誤解したまま開発を進めると、審査で却下されるリスクがあります。実装着手前に自社サービスの課金種別と対象コンテンツを整理しておくことが、外注の手戻りを防ぐ第一歩になります。

StoreKit（iOS）とGoogle Play Billing Library（Android）の違い

iOSとAndroidでは課金フレームワークが完全に異なります。両OS対応を外注する場合は、それぞれの仕様の違いを理解した上で実装範囲を整理することが重要です。

StoreKit 2（iOS 15以降）はSwift Concurrency（async/await）を前提とした新しいAPIで、購入フローの記述が簡潔になっています。ただしiOS 14以前のサポートが必要な場合はStoreKit 1との併用が求められるため、対応OSバージョンの確認が実装設計の起点になります。

Google Play Billing Libraryはバージョンアップのペースが速く、古いバージョンを使い続けるとPlay Consoleの要件を満たせなくなるケースがあります。外注先に「現在サポートされているバージョンで実装するか」を事前に確認しておくことをお勧めします。

両OSのストア手数料率はそれぞれ中小事業者向けの優遇プログラムや収益規模によって変動します。実装時点の最新の料率は各ストアの公式ドキュメントで確認してください。本記事では具体的な料率を断定しません。

実装で押さえるべき4つの技術ポイント：検証・状態管理・手数料・テスト

アプリ内課金・サブスク実装が難しいとされる主な理由は、課金フローの完了をクライアント側だけでは正確に確認できない点にあります。外注先に任せる場合でも、発注者側がリスク箇所を把握しておくことで、仕様漏れを防げます。

レシート検証はサーバー側で行う

購入完了後にAppleまたはGoogleが発行するレシート（購入証明）を、アプリ側だけで検証するのはリスクがあります。クライアント側のレシートは改ざんの余地があるため、サーバー側でストアAPIに問い合わせて検証する「サーバー側検証」が推奨されています。

サーバー側検証を実装しない場合、不正な課金回避（偽レシートの利用）に対して無防備になります。デジタルコンテンツを提供するアプリでは、サーバー側検証を実装範囲に含めるかどうかを外注仕様書に明示することが大切です。

サブスクリプションの状態管理は複雑

自動更新サブスクリプションは、購入・更新・解約・更新失敗・猶予期間（Grace Period）・請求問題による一時停止など、複数の状態遷移を管理する必要があります。

AppleはApp Store Server Notificationsを通じて、GoogleはReal-time Developer Notificationsを通じてサブスク状態の変化をサーバーに通知します。これらの通知を受け取ってDBの状態を更新するサーバー側の実装も、課金機能の一部として設計範囲に含める必要があります。

また、ユーザーがアプリを再インストールした際に購入済みコンテンツを復元する「購入復元」機能も実装が必要です。非消耗型アイテムや非更新サブスクリプションについては、AppleはApp Store Connectのガイドラインで復元機能の実装を求めています。

テストは専用環境（Sandbox・ライセンステスト）で行う

本番の課金処理を使ってテストすると実費が発生します。iOSにはSandbox環境、Androidにはライセンステストアカウントが用意されており、これらを使って課金フローを検証します。

Sandbox環境でのサブスクリプションは更新間隔が短縮（例：月次→数分）されるため、更新・解約・更新失敗などのシナリオを短時間でテストできます。外注先がテストシナリオを網羅しているかを確認することが、リリース後の不具合防止につながります。

ストア審査への対応

課金機能を含むアプリは、Apple App StoreとGoogle Play Storeそれぞれの審査プロセスを経る必要があります。課金UIに求められる表示要件（価格表示・サブスク条件の明示等）や、復元ボタンの設置といった要件を満たさないと審査で却下されます。

過去に課金機能で審査却下を経験した外注先は、審査通過のノウハウを蓄積しています。審査対応まで含めて依頼できるかどうかも、外注先選定の重要な確認項目です。

外注費用の相場：課金種別・OS対応・サーバー連携が費用を決める

アプリ内課金・サブスクリプション実装の外注費用は、課金種別・対応OS数・サーバー側処理の有無によって大きく変わります。以下に示すレンジは市場参考値であり、一次資料に基づく確定値ではありません。実際の費用は複数社への個別見積もりで確認してください。

費用を左右する主な要素を整理すると、①課金種別の数と複雑さ（消耗型のみか自動更新サブスクか）、②対応OS数（iOS単体か両OS対応か）、③サーバー側検証・状態管理の有無、④既存アプリへの組み込みか新規開発か、⑤テスト・審査対応の範囲の5点です。

また、RevenueCat（サブスクリプション管理を一元化するSaaS）のような外部ライブラリを活用することで、両OS対応のサーバー側処理を自前で実装する工数を削減できる場合があります。ただし外部サービスのランニングコストが発生するため、総コストを比較して判断することをお勧めします。

なお、ストア手数料はアプリの収益から差し引かれる継続コストです。開発費とは別に、収益モデルの設計段階で織り込んでおく必要があります。最新の手数料率は各ストアの公式ページで確認してください。

外注の進め方：要件整理→PoC→本実装→検証・審査対応の4ステップ

アプリ内課金実装を外注する際は、発注側が「何をどこまで任せるか」を事前に整理しておくと、見積もりのブレや手戻りを防げます。以下の4ステップが実務上の標準的な流れです。

ステップ1：要件整理とRFP作成 — 課金種別・OS・サーバー構成を明確にする

最初に行うべきは、実装する課金種別・対応OS・サーバー側処理の要否の明確化です。「消耗型のゲームコインのみ・iOS先行リリース・サーバー検証は後回し」と「自動更新サブスク・両OS同時・S2S通知対応あり」では、必要な工数が大きく異なります。

要件が曖昧なまま発注すると、後から仕様追加として追加費用が発生しやすくなります。RFP（提案依頼書）を作成し、課金フロー図・既存システム構成・対応OSバージョンを明示して複数社に見積もりを依頼することをお勧めします。

ステップ2：PoC（概念実証）— Sandbox環境で基本フローを先行確認する

本実装の前に、Sandbox環境を使った簡易な購入フローのPoCを外注先に依頼することで、APIの理解度と実装品質を事前に確認できます。特に自動更新サブスクリプションでは、更新・解約・更新失敗の各状態遷移をPoCで動作確認しておくことが後工程の品質を高めます。

PoCを省略して本実装に進むと、設計の認識ずれが後半になって発覚しやすくなります。コストと時間のバランスを考慮しつつ、リスクの高い部分だけでも先行検証する判断が有効です。

ステップ3：本実装 — 課金UI・購入処理・サーバー連携・状態管理を一体で設計する

本実装フェーズでは、課金UI（商品一覧・購入確認画面）・購入処理ロジック・レシート検証・サーバーへの課金ステータス反映・サブスク状態管理を、分離せず一体として設計することが重要です。

クライアント側とサーバー側を別の外注先に分けて発注すると、責任範囲の境界が曖昧になり不具合発生時の原因特定が困難になります。可能であれば、一気通貫で対応できる外注先に依頼することでリスクを減らせます。

ステップ4：検証・審査対応 — テストシナリオの網羅とストア提出まで含める

最終フェーズでは、課金フローの全シナリオ（正常購入・キャンセル・更新・解約・復元・更新失敗）を網羅したテストと、Apple/Googleの審査提出を行います。課金機能はストア審査でリジェクト（却下）されやすい領域のひとつです。

審査リジェクトが発生するとリリーススケジュールが数週間単位でずれることがあります。過去の審査対応経験を持つ外注先であれば、審査要件を満たした実装を最初から設計に組み込んでくれるため、リジェクトリスクを低減できます。

外注先の選び方：両OS実績・検証設計・状態管理経験で見極める

アプリ内課金・サブスク実装の外注先を選ぶ際は、一般的なアプリ開発の実績だけでなく、課金固有の技術経験を持つかどうかを確認することが重要です。

確認すべき5つのポイント

• 両OS課金APIの実案件実績：StoreKit（2を含む）とGoogle Play Billing Libraryの両方を使った実案件があるかを確認します。「iOS開発は得意だが課金実装はiOS単体のみ」という会社は少なくないため、両OS対応が必要な場合は明確に確認が必要です。
• サーバー側レシート検証の実装経験：クライアント側のみで検証を完結する実装では不正対策が不十分です。App Store Server APIやGoogle Play Developer APIを使ったサーバー側検証の実装経験を確認してください。
• サブスク状態管理のサーバー設計経験：S2S通知（App Store Server Notifications・Real-time Developer Notifications）を受け取ってDBを更新する実装経験があるかを確認します。この部分を「後から追加でいい」とする外注先は、サブスク実装の全体像を把握していない可能性があります。
• ストア審査通過の実績：課金機能を含むアプリのストア審査を通過した実績を持つかを確認します。審査の否認理由とその対処法を説明できるかどうかがひとつの判断材料になります。
• テスト設計の粒度：Sandboxでの更新・解約・更新失敗・復元シナリオを含むテストを設計・実施できるかを確認します。テスト仕様書の例を提示してもらうと、品質管理レベルを事前に把握できます。

開発形態（請負か準委任か）と責任範囲

外注の契約形態には大きく請負と準委任（SES）があります。課金機能のような仕様が変化しやすい領域では、途中の仕様変更に柔軟に対応できる準委任の方が適していることもあります。

請負契約の場合は成果物の品質保証が明確になる一方、仕様変更時の追加費用交渉が発生しやすいです。プロトタイプ段階は準委任、本実装以降は請負、といったフェーズごとの使い分けも選択肢のひとつです。契約形態と責任範囲をRFP段階で明確にしておくことをお勧めします。

内製との比較：必要スキルと工数の目安

内製でiOS＋Android両対応の自動更新サブスク実装を行う場合、Swift/Kotlinの両言語スキル・StoreKit 2およびPlay Billing Library 6の知識・バックエンド（サーバー側検証・Webhook受信・DB設計）の知識が必要になります。

これらを一人のエンジニアが網羅するのは難しく、複数名での分業体制が現実的です。社内に該当スキルを持つエンジニアがいない場合、採用・育成よりも外注の方が時間的コストを抑えられます。

まとめ：アプリ内課金・サブスク実装外注を成功させる3つの判断軸

本稿では、アプリ内課金・サブスクリプション実装を外注する際のポイントを整理しました。要点を3点に集約します。

第一に、課金種別と対応OS・サーバー構成を要件整理の最初に確定することです。消耗型のみか自動更新サブスクかで実装難易度が大きく変わります。サーバー側検証・S2S通知対応の要否も早期に決めることで、見積もりのブレを抑えられます。

第二に、StoreKitとGoogle Play Billing Libraryの違いを踏まえた外注先を選ぶことです。両OSの課金フレームワーク・レシート検証・サブスク状態管理の実案件経験を持つ外注先は限られます。実績確認を怠ると、実装途中で仕様の認識ずれが発覚するリスクがあります。

第三に、審査対応まで含めた一気通貫の発注を検討することです。課金機能はストア審査でリジェクトされやすく、審査対応を外注先に任せられるかどうかがリリーススケジュールに直結します。開発のみの外注は費用が抑えられますが、審査対応が自社の負担になる点を事前に把握しておくことが大切です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

Tweet