はじめに
こんにちは！Androidアプリ開発を担当している冨田です。
今回は、アプリ内で「〇〇日間だけ定期購入を割引で提供したい」という要件を実装した際の話を共有します。 Google Play Billing Libraryの機能をうまく使うことで、運用の手間を最小限に抑える設計ができたので、その知見をまとめました。
この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/3の記事です。
やりたかったこと
要件はシンプルです。
- 対象: 特定期間内のユーザー
- 特典: 定期購入を割引価格で提供する
- 判定: 期間判定はバックエンド側で行う
これを実現するために、Google Play Consoleの「デベロッパー指定」の特典機能を使うことにしました。
初期課題：どうやって対象オファーを探すか
実装を進める中で、最初にぶつかったのが「アプリ側で、どうやって割引対象のオファー（商品）を特定するか？」という課題です。
Billing Library 5系以降、1つの商品ID（SKU）の中に、通常価格や割引価格など複数の「オファー」が含まれる構造になりました。アプリで購入フローを起動するには、その中から「今回の決済に使いたいオファーのID」を選んで渡す必要があります。
解決策１：「オファーID」を使う
最初はシンプルにこう考えました。
「対象となるオファーIDを保持しておいて対象者に対して使えばいいのでは？」
しかし、これには様々な問題があります。
- 管理しにくい：オファーIDはランダム文字列なので意味が読み取れない。
- IDは変わる: もし将来追加で新しいオファーを作った場合、当然オファーIDも変わります。
- アプリ修正が必要: IDが変わるたびに、アプリ内の定数を書き換えるか、BE側が返すIDを変更する運用が発生します。
セールの内容を変えるたびに、アプリのアップデートや複雑なID管理が必要になる…
管理したくてもハードコーディングされたIDはランダムだからよくわからない…
これは運用コストが高すぎると判断し、別の方法を探ることにしました。
解決策２：「タグ」を使って抽象化する
そこで目をつけたのが、Google Play Consoleにある「Offer Tags（特典タグ）」という機能です。オファーに対して、自由な文字列のタグを設定できる機能です。
これを使って、設計を以下のように変更しました。
- 変更前: 「IDが
offer_123の商品をくれ」と指定する。 - 変更後: 「タグ
campaign-new-userが付いている商品をくれ」と指定する。
こうすれば、具体的なIDが何であるかをアプリが知る必要はありません。
将来セール内容が変わっても、Console上で新しいオファーを作り、同じタグを付け替えるだけで済みます。アプリ側の修正は一切不要です。
検索につかうタグを見ても意味がわかるのでいいですね。
オファー選定フロー
実際のイメージはこんな感じです。
ポイント：安全なフォールバック
この実装で一番意識したのは、「タグなし＝通常プラン（定価）」というルールを徹底したことです。
もしバックエンドの設定ミスやGoogle Play Consoleの設定ミスでオファーが見つからなかったりしても、このロジックなら自動的に「通常プラン」に倒れます。
「意図せずセールしてしまう」や「購入できずにクラッシュする」といった事故を未然に防げる、もしくは発生してもアプリリリースなく切り戻せる安全な設計になりました。
まとめ
今回の実装での学びは以下の通りです。
- Offer IDに依存しない: 変更不可能なIDではなく、付け替え可能な「タグ」でオファーを管理する。
- 運用が楽になる: 割引率や期間の変更はPlay Consoleの設定変更だけで完結し、アプリのリリースが不要になる。
- 安全なデフォルト: 「タグなし＝定価」とすることで、予期せぬトラブルにも強くなる。
Billing Libraryの機能を少し工夫して使うだけで、ビジネスの変化に強い柔軟な決済基盤が作れました。
決済部分の設計は事故が起きないように、実装だけでなく運用まで視野に入れて安全な設計となるような方針で進められました。
※本ページで取り上げた割引は検証段階のため、予告なく終了となる場合があります。
採用について
askenではエンジニアを絶賛募集中です。
まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください！
https://hrmos.co/pages/asken/jobs
