障害発生後、Apple も Google もサブスクリプションの更新日を延長できる。ただし制限はまったく違う

ダウンタイムは、すべてのサブスクライバーにとって最も筋の通った返金理由になり、それを止めることはできません。できるのは、誰かが求める前に失われた日数を返すことです。どちらのアプリストアでもサブスクリプションの更新日を延長でき、顧客は現金の代わりに無料の期間を受け取れます。Apple は 1 回の延長を最大 90 日とし、年に 2 回まで認めています。Google は 1 回の呼び出しで最大 1 年まで請求を延期できます。手続き、通知、そしてその裏にあるコストは大きく異なるため、ひとつの障害対応計画で両方をカバーすることはできません。

障害が返金リスクに与える影響

返金を決めるのはストアであり、あなたではありません。App Store では、顧客が Apple に申請し、Apple が判断します。CONSUMPTION_REQUEST 通知を受け取り、Send Consumption Information を通じて 12 時間以内に消費データを送ることができる場合があります。あなたが口を挟めるのはそれだけです。

Google Play では、購入者は購入から 48 時間以内であれば、あなたに確認されることなく返金を受けられます。それ以降のリクエストはあなたのもとに届きます。Google があなたの証拠を求める唯一のフローは、デベロッパーによる審査対象としてフラグが付いたチャージバックで、orders.reviewrefund を通じて 24 時間以内に回答します。チャージバックに対する銀行の判断は最終的なものです。

つまり、どちらのストアも返金を阻止する手段は与えてくれません。あなたがコントロールできるのは、サービスが復旧したときにサブスクライバーが損をしたと感じたままかどうかです。素早く付与し、はっきり伝えるサブスクリプションの追加期間こそ、両ストアがまさにそのために用意したツールです。

App Store でサブスクリプションの更新日を延長する方法

App Store Server API には、このためのエンドポイントが 2 つあります。Extend a Subscription Renewal Date は 1 件のサブスクリプションを対象とし、originalTransactionId で指定します。Extend Subscription Renewal Dates for All Active Subscribers は 1 つの productId の対象となるサブスクライバー全員に作用し、障害が一部の地域だけに影響した場合は storefrontCountryCodes で範囲を絞り込めます。

各リクエストには 3 つの項目を含めます。1 から 90 までの数値を取る extendByDays、extendReasonCode、そして自分で生成する requestIdentifier です。理由コード 3 はサービスの問題または障害を意味します。コード 1 は顧客満足、コード 2 はその他の理由、コード 0 は未申告です。

Apple が延長するサブスクリプション

対象になるのは、少なくとも 1 回の有料期間を経た、有効な自動更新サブスクリプションだけです。Apple は次のものをスキップします。

• 無料トライアルなど、無料オファー期間中のサブスクリプション。
• 請求の再試行状態にある無効なサブスクリプション。
• 請求の猶予期間中で、有効期限がすでに過ぎているサブスクリプション。
• 過去 365 日以内にすでに 2 回の更新日延長を受けたサブスクリプション。
• 期限切れのサブスクリプション。

ファミリー共有は自動的についてきます。ファミリー共有に対応した購入済みサブスクリプションを Apple が延長すると、ファミリーメンバーのサブスクリプションも延長されます。ファミリーメンバーのサブスクリプションを直接指定することはできません。

一括リクエストは時間がかかるので、通知を見守る

Apple によると、有効なサブスクライバー全員を延長するリクエストは、サブスクライバー数によって数時間、場合によっては数日かかることがあります。200 レスポンスは、Apple が処理中であることを示すだけです。結果は App Store Server Notifications V2 で知らされます。

FAILURE ごとに、ペイロード内の署名付きトランザクションから originalTransactionId を取り出し、単一サブスクリプション用のエンドポイントで再試行します。ポーリングを選ぶなら、Get Status of Subscription Renewal Date Extensions がリクエストの完了状況と、延長の成功数と失敗数を返します。

Google Play の請求延期の仕組み

Google 側の手段は purchases.subscriptionsv2.defer で、購入トークンごとに 1 回呼び出します。リクエスト本文には 3 つのフィールドを持つ deferralContext が入ります。etag は purchases.subscriptionsv2.get から取得し、サブスクリプションの最新の etag と一致しなければ呼び出しは失敗します。deferDuration は日付をどれだけ後ろにずらすかを指定します。そして validateOnly を true にすると、サブスクリプションに手を付けずにドライランとして実行されます。

Google の請求ガイドでは、1 回の API 呼び出しあたりの範囲を 1 日から 1 年と定めています。さらに延ばすには、新しい有効期限が来る前にもう一度呼び出します。自動更新サブスクリプションでは、延期によって次回の更新日が動きます。プリペイドプランでは有効期限が動きます。アドオン付きのサブスクリプションでは、すべてのアイテムが同じ期間だけ延期されます。レスポンスには各アイテムの新しい expiryTime が含まれます。

延期期間中、ユーザーはサブスクリプションを維持したままフルアクセスでき、追加期間に対して課金されません。Google は SUBSCRIPTION_DEFERRED のリアルタイム デベロッパー通知を送信します。旧来の purchases.subscriptions.defer は非推奨のため、新しいコードでは v2 のメソッドを使いましょう。

Google は顧客に知らせないので、自分で知らせる

Apple は延長が成功するたびに顧客へメールを送ります。Google の請求ガイドには、ユーザーへのメッセージについての記載がまったくありません。返金リクエストを未然に防ぐことが目的なら、サブスクライバーが追加期間の存在を知っている必要があります。アプリ内とメールの両方で自分から伝え、何日分なのか、なぜなのかを説明しましょう。

Apple と Google の比較

延長のコストを返金と比べる

返金と延長では、お金が出ていく場所が違います。返金では、その期間に顧客が支払った金額が戻されます。その顧客へのサービス提供にすでに使ったものはすべて使ったままです。セッションごとのコンピューティング、モデルの API 呼び出し、ストレージ、そして顧客が利用したコンテンツのクリエイターへの支払いなどです。

延長では支払いは手元に残ります。そのコストは、更新収入のないまま提供するサービスです。追加された日ごとに、アクティブなサブスクライバーは同じ請求を発生させ続けます。ライトユーザーならほぼゼロです。AI 機能のヘビーユーザーなら、30 日の追加は収入のない 30 日分のモデル呼び出しを意味しかねません。延長日数は、示したいお詫びの大きさではなく、障害の長さに合わせて決めましょう。

Apple での手数料コスト

Apple は、サブスクライバーの有料サービス 1 年目には各更新の 70% を、それ以降は 85% を支払います。Apple のサブスクリプションのページには、更新延長の日数は有料サービスの日数から除外されると書かれています。つまり 30 日の延長は、そのサブスクライバーが 85% に移行する時期を 30 日遅らせます。App Store Small Business Program に参加しているなら、すでに 85% を受け取っているため、このコストは当てはまりません。

Google Play でのチャージバックコスト

2026 年 8 月 3 日以降の注文では、カード保有者が勝ったチャージバックにより、Google Play のデベロッパーは購入価格から Play のサービス手数料を差し引いた額に加え、銀行の手数料を負担します。障害は、不満を抱えた顧客を銀行へ向かわせるまさにその種の出来事です。先回りして届く延期は、覆せない異議申し立てよりも安く済みます。

延長が適切な手段ではない場合

購入がサブスクリプションではなかった

更新日の延長はサブスクリプションにしか使えません。障害で消耗型アイテムや買い切りのアンロックが壊れたなら、アイテムを再配信してください。それについて Apple から CONSUMPTION_REQUEST が届いたら、起きたことを報告します。Apple の deliveryStatus フィールドにはこのための値 UNDELIVERED_SERVER_OUTAGE があり、Apple は DELIVERED 以外のステータスでは consumptionPercentage を 0 にしなければならないとしています。

顧客がすでに Apple の延長を 2 回とも使っている

Apple の上限は、顧客 1 人あたり 365 日以内に 2 回の延長です。1 年に 2 回障害があれば両方を使い切り、3 回目にはストアを通じて提供できるものが何も残りません。originalTransactionId ごとに使用した延長の回数を記録しておけば、一括リクエストの FAILURE 通知に驚かされることはありません。

顧客が無料トライアル中

Apple は無料オファー期間中のサブスクリプションを延長しません。トライアルユーザーが失ったのは無料の日数であって有料の日数ではないので、返金リスクは低めです。埋め合わせをしたいなら、アプリ内メッセージのほうがどんな API 呼び出しよりも安上がりです。

次の障害に備えるチェックリスト

• 障害の開始時刻と終了時刻、影響を受けたプロダクトと地域を記録する。
• 失われた時間をカバーする日数を決める。Apple では理由コード 3 を使い、1 日から 90 日の範囲に収める。
• Apple では productId ごとに一括リクエストを 1 回送り、一部の地域だけが影響を受けた場合は storefrontCountryCodes で絞り込む。
• RENEWAL_EXTENSION FAILURE を受け取り、それぞれを単一サブスクリプション用のエンドポイントで再試行する。
• Google Play では有効な購入トークンを順に処理し、各 etag を読み取り、まず validateOnly で実行してから本番の延期を行う。
• Google は知らせないので、Google Play のサブスクライバーには追加期間を自分で伝える。
• 利用権の有効期限は、自前の日付計算ではなく RENEWAL_EXTENDED と SUBSCRIPTION_DEFERRED に基づいて更新する。
• アカウントごとに利用ログを残しておく。そうすれば返金リクエストやチャージバックが届いても、Apple なら 12 時間以内、Google なら 24 時間以内に証拠を用意できる。