サブスクリプションの解約理由は返金リクエストより先に届くことが多く、Google Play は Apple よりはるかに多くの情報を渡してくれる

最終的に返金を受けるサブスクライバーの多くは、まず解約します。その解約には理由がついていますが、2 つのストアが渡してくれる情報量は大きく異なります。Google Play は短いアンケートを実施し、自由記述も含めた回答をサーバーに渡します。Apple が送るのは数値コードだけで、それが示すのはサブスクリプションがどう終わったかであり、顧客がなぜやめたかったかではありません。両方を正しく読めば、まだ手を打てるうちに返金リクエストの兆しに気づけます。

Google Play が教えてくれるサブスクリプションの解約理由

ユーザーが Play の定期購入センターで解約すると、Google は理由を尋ねます。回答は purchases.subscriptionsv2.get で取得するサブスクリプションリソースの canceledStateContext に入ります。このオブジェクトはサブスクリプションが解約済みまたは期限切れの状態のときだけ存在し、誰がサブスクリプションを終了させたかを示します。ユーザー、Google のシステム、開発者、またはプラン変更などによる置き換えのいずれかです。

ユーザーが解約した場合、userInitiatedCancellation オブジェクトには 2 つのフィールドがあります。cancelTime は解約日時、cancelSurveyResult はアンケートの回答です。

右端の列は私たちの解釈であり、Google の見解ではありません。最初の 2 列は API リファレンスからそのまま引用しています。

通知には理由が含まれない

サブスクリプションが解約されると、SUBSCRIPTION_CANCELED のリアルタイム デベロッパー通知（type 3）が送られます。Google は、この通知が伝えるのは購入状態が変わったことだけだと明言しています。ペイロードには購入トークン以外に役立つ情報がないため、アンケートの回答を読むにはハンドラーから purchases.subscriptionsv2.get を呼び出す必要があります。

Play Console での確認

合計を見るだけならコードは不要です。Play Console の定期購入レポートには、解約を自発的、非自発的、その他に分ける「解約」カードと、回答を選んだユーザーの「解約アンケートの回答」カードがあります。「その他」を選んだユーザーの自由記述は、「その他の回答」カードから CSV でダウンロードできます。ダウンロードには View financial data の権限が必要で、注文を読み取るツールに付与するものと同じ権限です。

Apple が教えてくれること、教えてくれないこと

Apple には、開発者に結果が届く解約アンケートがありません。最も近いのは署名付き更新情報の expirationIntent ですが、これが表すのはサブスクリプションがどう終わったかであり、顧客がどう考えたかではありません。

顧客自身の選択を表すのはコード 1 だけで、その動機については何もわかりません。アプリのクラッシュが続いて離れた顧客も、単にプロジェクトを終えただけの顧客も、まったく同じに見えます。

AUTO_RENEW_DISABLED に隠れたシグナル

Apple の通知の中に、注意深く見る価値があるものが 1 つあります。サブタイプが AUTO_RENEW_DISABLED の DID_CHANGE_RENEWAL_STATUS は、通常は顧客が自動更新をオフにしたことを意味します。しかし Apple のドキュメントには 2 つ目のケースも書かれています。顧客が返金をリクエストしたあと、App Store も自動更新をオフにするのです。

つまり iOS では、自動更新オフのイベントが返金リクエストの最初の痕跡になることがあります。購入が消耗型アイテムや自動更新サブスクリプションであれば、続いて CONSUMPTION_REQUEST が届く可能性があり、その時点から消費データを送るまでの猶予は 12 時間です。アプリ内で目立った操作がないのに自動更新オフのイベントが届いたら、そのアカウントの利用データを準備しておく合図として扱う価値があります。

Apple と Google の比較

解約が返金に変わるところ

解約で止まるのは次回の請求です。前回の請求が戻るわけではありません。お金が戻るかどうかは、顧客が次にどの返金フローにたどり着くかで決まり、そのほとんどは開発者の関与なしに進みます。

• Google Play では、購入者は購入から 48 時間以内なら自分で返金を受けられ、判断するのは Google です。
• Google や Apple のサポート経由の返金は、ストアが判断します。
• Apple の CONSUMPTION_REQUEST は消費データを求めてきます。回答期限は 12 時間です。
• Google Play のチャージバック審査は orders.reviewrefund を通じて証拠を求めてきます。回答期限は 24 時間です。チャージバックに関する銀行の判断は最終的なものです。

解約理由によって、これらのルールが変わることはありません。変わるのは、どの顧客が不満を抱えているかに気づくタイミングと、証拠を求める 2 つのフローのどちらかが届いたときに証拠が準備できているかどうかです。

理由ごとのコスト

アンケートの回答は、そのアカウントにすでにどれだけの提供コストがかかったかの目安にもなります。それは返金されたときに開発者の手元に残る負担額です。

技術的な問題

これが最も高くつくケースです。問題に遭遇するほど製品を使っているということは、セッションのためのコンピューティング、リクエストによるモデル API の呼び出し、作成されたもののストレージ、そして利用したコンテンツのクリエイターへの支払いまで、すでにコストを負担しているということです。そのうえで返金されれば、代金は戻り、コストはそのまま残ります。Google Play で銀行に申し立てられた場合、2026 年 8 月 3 日以降の注文では、購入価格から Play のサービス手数料を引いた額に加えて銀行の手数料を負担することになります。

料金関連

価格への不満は、見た目ほどコストがかかりません。ただし、予期しない更新が隠れている場合は別です。それはチャージバックの典型的なパターンなので、解約が更新の請求直後だったか、更新のリマインダーが送られていたかを確認してください。

利用頻度が低い

利用が少なければ提供コストも小さいので、この場合の返金は、あまりコストをかけずに得たお金を返すことがほとんどです。Apple から消費データを求められた場合も、正直なデータが、顧客が何を使い何を使わなかったかを正確に示してくれます。

より良いアプリが見つかった

このタイプの顧客が争いを起こすことはまれです。競合に移っただけです。この理由はプロダクトの判断には役立ちますが、返金への対策にはほとんど役立ちません。

解約理由を読み取るためのルーチン

• Google Play の SUBSCRIPTION_CANCELED を受け取るたびに purchases.subscriptionsv2.get を呼び出し、canceledStateContext を購入トークンと cancelTime と一緒に保存します。
• 理由が「その他」の場合は、reasonUserInput をそのまま保存します。どちらのストアでも、得られる自由記述はこれだけです。
• Apple の DID_CHANGE_RENEWAL_STATUS（AUTO_RENEW_DISABLED）を受け取るたびにイベントを記録し、CONSUMPTION_REQUEST が続く場合に備えてそのアカウントの利用データを取り出しておきます。
• Apple の EXPIRED 通知を受け取るたびにサブタイプと expirationIntent を記録し、自発的な解約と請求の失敗が混ざらないようにします。
• 技術的な問題を理由にした Google Play の解約については、そのアカウントのエラーログを確認し、顧客が銀行に連絡する前にこちらから連絡します。
• アカウントごとの利用ログを残しておき、CONSUMPTION_REQUEST には 12 時間以内、チャージバック審査には 24 時間以内に回答できるようにします。