LASSIC Media らしくメディア
アプリ内課金・サブスク（StoreKit/Google Play Billing）を実装する外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- iOSはStoreKit 2、AndroidはGoogle Play Billing Libraryの使用がストアポリシー上求められており、実装の難所はサーバー側検証・サブスク状態管理にあります。
- ストア手数料は初年30%→13か月目以降15%の構造で、Googleには小規模事業者向け優遇があります。
- 外注で進める際は商品定義・購入フロー・復元・解約対応の5つの工程を外注先と明確に分担することが大切です。
目次
アプリ内課金とは何か — 種類とApple Pay等との違い
アプリ内課金（In-App Purchase）とは、スマートフォンアプリの画面内で行われるデジタルコンテンツ・サービスの課金機能を指します。iOSではAppleのStoreKit、AndroidではGoogleのPlay Billing Libraryを通じて実装するもので、物理商品の決済に使うApple Pay・Google Payとは別の仕組みです。
アプリ内課金には主に3種類があります。消耗型（コインや追加ステージなど1回使い切り）、非消耗型（広告除去などの永続機能解除）、サブスクリプション（月額・年額の定期購読）です。
Apple PayやGoogle Payは、物理商品・サービスの代金をアプリ経由で支払う仕組みで、Appleストア外の決済サービスです。デジタルコンテンツやサブスクをアプリ内で販売する場合は、StoreKit（iOS）またはGoogle Play Billing Library（Android）を通じた課金が求められます。この区別を押さえておくことが、外注先への要件説明の第一歩になります。
StoreKit 2とGoogle Play Billing Libraryの実装概要と手数料
iOSのアプリ内課金はAppleのStoreKit（ストアキット）APIで実装します。2021年以降はSwiftのasync/awaitに対応したStoreKit 2が主流で、iOS 15以上が対象です。Appleは2024年にiOS 18でStoreKit旧バージョン（Original API）を非推奨にしており、新規開発ではStoreKit 2への対応が前提となっています。また、iOS 17からはSubscriptionStoreView（サブスクリプションストアビュー）というSwiftUI製コンポーネントが使えるようになり、サブスク購入画面の構築が簡略化されました。
AndroidはGoogle Play Billing Library（グーグルプレイ ビリングライブラリ）を使います。Kotlin/Javaいずれからも呼び出せるクライアントライブラリで、Google Play Consoleでの商品設定と組み合わせて動作します。
| 比較項目 | iOS（StoreKit 2） | Android（Play Billing） |
|---|---|---|
| APIの名称 | StoreKit 2（iOS 15+） | Google Play Billing Library |
| 対応言語 | Swift（async/await） | Kotlin / Java |
| 商品管理画面 | App Store Connect | Google Play Console |
| 手数料（サブスク）初年 | 30% | 30% |
| 手数料（サブスク）13か月目〜 | 15% | 15% |
| 小規模事業者優遇 | Apple Small Business Program（条件あり） | 年間デジタル売上100万ドル未満は15% |
| サブスク画面コンポーネント | SubscriptionStoreView（iOS 17+） | 独自UI実装が基本 |
手数料はApple・Google共にサブスクリプションの場合、利用者1人あたり初年度は30%で、契約開始から13か月目以降は15%に下がります。Googleには年間デジタル売上が100万ドル未満の小規模事業者向けプログラムがあり、条件を満たせば15%が適用されます。手数料の構造は収益計画に直接影響するため、外注先と共有しておく必要があります。
実装の5工程 — 商品定義から解約対応まで
アプリ内課金の実装は、ストア管理画面の設定からサーバー側の監視まで複数工程に分かれます。外注時に認識のずれが生じやすいのはサーバー側検証とサブスク状態の同期の2点です。
①商品・サブスクの定義（App Store Connect / Play Console）
課金対象の商品をAppleのApp Store ConnectまたはGoogleのPlay Consoleで登録します。商品ID・価格・サブスクの更新間隔・無料トライアル期間などをここで設定します。設定ミスはリジェクトやストア審査遅延の直接原因になるため、開発着手前に完了させることが大切です。
②購入フロー（クライアント実装）
商品一覧の表示から購入ボタン押下・決済完了通知の受け取りまでのUI・ロジックをアプリ側に実装します。StoreKit 2ではTransaction（トランザクション）オブジェクトをasync/awaitで扱えるため、旧APIと比べてエラー処理が整理しやすくなっています。
③レシート／JWSのサーバー側検証
クライアントから送られた購入情報をバックエンドサーバーでApple・GoogleのAPIに問い合わせ、改ざんや不正課金がないか検証します。StoreKit 2ではJWS（JSON Web Signature）形式の署名付きトランザクションを直接検証できます。サーバー検証を省略すると不正アクセスで商品が無料取得されるリスクがあり、この工程は外注スコープに含まれているかを明確に確認する必要があります。
④購入の復元（Restore）
ユーザーが機種変更や再インストールをした際に、過去の非消耗型購入やアクティブなサブスクを復元する機能です。ストアガイドラインでは復元ボタンの設置が求められており、実装漏れはApple審査のリジェクト事由になります。
⑤サブスク状態の同期・解約・支払い猶予期間（Grace Period）対応
サブスクリプションは更新・解約・支払い失敗（支払い猶予期間（Grace Period））・返金など、多様な状態変化が発生します。Appleはサーバー通知（App Store Server Notifications）、GoogleはDeveloper NotificationsをPubSubで配信しており、これらをサーバー側で受け取りDB同期する仕組みが必要です。支払い猶予期間（Grace Period）（支払い猶予期間）中にサービスを正しく継続提供できるかどうかは、設計段階から明示しないと後から手戻りが発生します。
外注で進める手順 — 要件整理から検収まで
アプリ内課金・サブスク実装を外注する場合、発注者側が事前に用意すべき情報と、外注先に委ねる作業範囲の切り分けが成否を分けます。
ステップ1：対象プラットフォームと課金種別の確定
iOS・Android両対応か片側のみか、消耗型・非消耗型・サブスクのどれを扱うかを明確にします。サブスクリプションは他の課金種別より実装工数が大きくなるため、種別によって見積もりが変わります。
ステップ2：商品IDと価格体系の設計
販売する商品のID体系・価格・無料トライアル期間・プランの階層（例：月額プラン・年額プラン）を発注者側が決めます。商品定義は開発の前提になるため、外注先の作業開始前に固めておきます。
ステップ3：スコープ確認書・API仕様の共有
クライアント実装・サーバー検証・サブスク状態管理・Webhookの受け取りなど、どこまでを今回の外注スコープに含むかを文書で合意します。「サーバー検証は含むか」「通知はどのエンドポイントで受け取るか」を曖昧にすると、後から追加費用が発生します。
ステップ4：Sandbox環境でのテスト
Apple・GoogleともにSandbox（テスト環境）が用意されており、本番に課金せずに購入フロー全体を検証できます。更新速度が短縮されているため、サブスクの更新サイクルも短時間でテスト可能です。外注先がSandboxテストの実施・結果共有まで担う契約になっているかを確認します。
ステップ5：ストア審査対応と検収
アプリ内課金を含むアップデートはストア審査を経る必要があります。審査フィードバックへの対応が外注スコープに含まれているか確認します。検収条件として、実機での購入・復元・解約フロー一式の動作確認を含めることを推奨します。
費用を左右する要素と依頼前の確認ポイント
アプリ内課金・サブスク実装の外注費用は、対象プラットフォーム数・課金種別・サーバー側要件によって変わります。市場参考値として、iOS単独の消耗型・非消耗型のみの実装であればクライアント実装に数十万円規模、iOS+Androidのサブスクリプション実装にサーバー検証・状態管理・通知Webhookを加えると数百万円規模になるケースが見られます（いずれも市場参考値・一次資料ではありません）。
費用を大きく左右する要素を下表に整理します。
| 要素 | 費用への影響 | 留意点 |
|---|---|---|
| 対応プラットフォーム | iOS+Androidは概ねiOS単独の1.5〜2倍 | StoreKitとPlay Billingは別実装のため工数が増加します。 |
| 課金種別 | サブスクは消耗型・非消耗型より高い | 状態管理・更新通知・支払い猶予期間（Grace Period）対応が追加されます。 |
| サーバー検証の有無 | バックエンド工数が増加 | 省略すると不正課金リスクが残るため、外注スコープに含めることが大切です。 |
| 既存アプリへの組み込み | 新規開発より調査・影響範囲確認コストが増加 | 既存コードベースの品質によって工数が変動します。 |
| 審査対応・修正対応 | リジェクト時の修正が追加コストになる場合あり | 審査対応の回数上限や追加費用の有無を契約前に確認します。 |
依頼前に確認しておくべきポイントとして、既存のバックエンド言語・フレームワーク、App Store ConnectおよびPlay Consoleのアカウント権限、将来的なプラン追加の予定があります。特にアカウント権限は開発着手後に問題が発覚すると、審査提出が遅延する直接原因になります。
外注先の選び方 — 確認すべき3つの軸
アプリ内課金・サブスク実装は、クライアントとサーバーにまたがる知識が必要です。外注先を選ぶ際は次の3つの軸で確認します。
軸1：iOS・Android両対応の実装実績があるか
StoreKit 2とGoogle Play Billing Libraryはそれぞれ仕様が異なるため、両方の実装経験を持つ開発者またはチームかどうかを確認します。過去に同様のサブスク実装を行ったアプリの実例を聞くことが判断の基準になります。
軸2：サーバー側検証・Webhook設計まで担えるか
クライアント実装のみ対応でサーバー側は別途調達という分断体制は、スコープの境界でトラブルが起きやすいです。レシート検証APIの呼び出しからサブスク状態のDB管理まで一貫して担えるかを確認します。自社にバックエンドチームがある場合は、その言語・フレームワークとの相性も確かめます。
軸3：ストア審査の経験とリジェクト対応の体制
アプリ内課金を含む申請はAppleの審査でリジェクトされるケースがあります。審査ガイドラインへの準拠確認、リジェクト時の修正対応が契約範囲に含まれているかどうかが、最終的な納期と品質を左右します。元請（プライムベンダー）として責任をもって審査対応まで完遂できる体制かを確認することが大切です。
まとめ：外注成功のための3つの判断軸
本稿では、アプリ内課金・サブスクリプションの実装をStoreKit 2・Google Play Billing Libraryを中心に整理し、外注で進める手順を説明しました。要点を3つに集約します。
第一に、iOS・Androidともにデジタルコンテンツ・サブスクにはApple Pay/Google Payではなく専用のストアAPIが求められており、この区別を要件定義の出発点にすることが大切です。
第二に、実装の難所はサーバー側検証とサブスク状態管理にあります。クライアント実装だけをスコープに含めると、後からサーバー側を別途調達する手戻りが発生します。外注先との契約時に5工程すべてのスコープを文書で確認することが有効です。
第三に、ストア手数料（初年30%→13か月目以降15%）と小規模事業者向け優遇の適用可否は収益計画に直接影響します。外注先選定の前に自社の手数料区分を確認した上で、費用を左右する要素を整理してから見積もりを依頼することを推奨します。
よくある質問
StoreKit 2とStoreKit旧バージョン（Original API）は使い分けが必要ですか？
新規開発であればStoreKit 2（iOS 15以上対象）を選択することを推奨します。Appleは2024年にiOS 18でOriginal APIを非推奨にしており、中長期の保守を考えるとStoreKit 2への移行が前提となっています。ただし既存アプリがOriginal APIで動作している場合は、段階的な移行計画を立てた上で外注先と進め方を相談することが大切です。
サーバー側検証を省略した場合のリスクはどの程度ですか？
サーバー側検証を省略すると、改ざんされた購入レシートを送りつけてコンテンツを不正取得する攻撃に対して無防備な状態になります。クライアント側だけで購入の正当性を判断すると、レシートの偽造や再生攻撃が可能になるため、StoreKit 2のJWS検証またはApple・GoogleのVerification APIを呼び出すサーバー処理をスコープに含めることが大切です。
Googleの小規模事業者プログラムの対象になるかどうかはどこで確認できますか？
Google Play Console内の「お支払いプロファイル」または「政策センター」から申請状況を確認できます。年間デジタル売上100万ドル未満（約1.5億円相当）の事業者が対象で、条件を満たす場合は30%ではなく15%の手数料が適用されます。Appleも同様の「スモールビジネスプログラム（Apple Small Business Program）」を提供しており、App Store Connectから申請できます。最新の申請条件は各社公式ページで確認することをお勧めします。
iOS・Android両対応の外注は、片方ずつ分けて発注するべきですか？
サーバー側検証や状態管理のロジックはiOS・Android共通で設計できるため、両対応を同一の外注先に委ねることで設計の一貫性を保ちやすくなります。片方ずつ異なる外注先に分けると、サーバーAPIの仕様統一やテスト工程の調整に追加コストが発生します。ただし既存のiOSアプリを先行リリース後にAndroid対応を追加するフェーズ型の場合は、分けて発注することが現実的なケースもあります。
ストア審査でリジェクトされる主な原因は何ですか？
アプリ内課金に関連するリジェクトの主な原因は、復元（Restore）ボタンの未設置、サブスクの自動更新に関する説明文の不足、無料トライアル終了後の課金タイミングの説明漏れなどです。Appleガイドライン（3.1.1・3.1.2）ではサブスクの購入画面に更新条件・価格・キャンセル方法の明示が求められており、外注先が審査ガイドラインに精通しているかどうかを事前に確認することが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Inc.「App Store Review Guidelines 3.1.1 – 3.1.2」https://developer.apple.com/app-store/review/guidelines/（最終確認2026年6月）
- *2 出典：Apple Inc.「StoreKit – Meet StoreKit 2」https://developer.apple.com/storekit/（最終確認2026年6月）
- *3 出典：Google「Google Play Billing Library overview」https://developer.android.com/google/play/billing（最終確認2026年6月）
- *4 出典：Google「Google Play’s billing system – Service fees」https://support.google.com/googleplay/android-developer/answer/112622（最終確認2026年6月）
