Apple の Retention Messaging API は解約画面にあなたの言葉を載せられる。ただし返金リクエストはそこを通らない

iPhone で解約をタップしたサブスクライバーに、確定する前に、あなたが選んだメッセージ、より安いプラン、または割引を見せられるようになりました。それが Apple の Retention Messaging API で、開発者が Apple 自身の解約画面に口を出せるのはこれが初めてです。今もプレリリースで、参加には申し込みが必要です。そして返金を気にするなら重要な、明確な境界があります。この API が語りかけるのは支払いをやめようとしている人であって、お金を返してほしい人ではありません。そうしたリクエストは別の道を通って Apple に届きます。

Apple の Retention Messaging API でできること

Retention Messaging API はサーバー間のサービスです。メッセージのテキストと画像を事前に Apple にアップロードし、Apple が審査します。そのうえで、自動更新サブスクリプションを解約しようとしているサブスクライバーに、承認済みのどのメッセージを見せるかを選びます。Apple のドキュメントには4種類のメッセージが挙げられています。

• テキストメッセージ。箇条書きを含められます。
• 画像付きのテキストメッセージ。
• プラン変更メッセージ。同じサブスクリプショングループ内の別のサブスクリプションを提案します。
• プロモーションオファーメッセージ。同じまたは別のレベルで割引価格を提示します。App Store Connect で設定し、サーバーで署名したプロモーションオファーを使います。

メッセージは、顧客がサブスクリプション詳細ページで Cancel Subscription をタップした後に表示されます。その後 Apple は Confirm Cancellation（キャンセルの確認）ページを表示します。顧客はそのまま解約することも、Keep Subscription（サブスクリプションを継続）をタップすることも、提案されたオファーやプランを受け入れることもできます。出口を隠すことはできず、Apple は誤解を招く内容や不正確な内容をアップロードしないよう開発者に求めています。

デフォルトメッセージとリアルタイムフロー

運用方法は2つあります。シンプルなのはデフォルトメッセージで、製品とロケールごとにテキストを割り当てます。画像や箇条書きは付けても付けなくても構いません。より高機能なのはリアルタイムフローで、Apple があなたのサーバーの Get Retention Message エンドポイントを呼び出し、あなたはメッセージ ID で応答します。プラン変更とプロモーションオファーのメッセージを表示できるのはリアルタイムフローだけです。

実際には、デフォルトメッセージは省略できません。リアルタイム呼び出しが失敗したとき、Apple は常にデフォルトを代わりに使います。そしてデフォルトがないロケールでは、その製品にリテンションメッセージを一切表示しません。

リアルタイム呼び出しで Apple がサーバーに伝える内容

リクエストは App Store が署名した JWS です。デコードすると、originalTransactionId、appAppleId、productId、userLocale、requestIdentifier（UUID）、環境、signedDate が含まれています。Apple は、appAppleId が自分のアプリと一致するか確認し、一致しなければ応答しないよう求めています。役に立つのは originalTransactionId です。何を伝えるかを決める前に、このサブスクライバーがアプリで実際に何をしていたかを調べられるからです。

リテンションメッセージが表示される場所、表示されない場所

Apple がメッセージを置くのは1つの画面だけです。顧客が Cancel Subscription をタップした後の Confirm Cancellation のステップで、たとえば Apple Account > Subscriptions や App Store 上のサブスクリプションのページから進んだ先です。この画面で問われるのは次の更新が行われるかどうかです。すでに受け取ったお金には触れません。

返金リクエストは別の行為です。Apple のサポートページは顧客を reportaproblem.apple.com に案内し、顧客はそこで Request a refund（返金をリクエスト）を選び、理由と項目を選んで、24 から 48 時間後の更新を待ちます。アプリ内では、StoreKit の beginRefundRequest が Apple の返金シートを開き、App Store が承認または却下するまで最大 48 時間かかると Apple は説明しています。どちらの経路も Confirm Cancellation 画面を通りません。

リテンションメッセージで返金リクエストを止められるか

止められません。返金リクエストは、メッセージが表示される画面にそもそも届かないからです。Apple の通知ドキュメントには、これを具体的に示す細かな点があります。顧客があなたのアプリから返金リクエスト API で返金を求めると、Apple は自ら自動更新をオフにし、サブタイプ AUTO_RENEW_DISABLED の DID_CHANGE_RENEWAL_STATUS を送信します。「サブスクリプション」設定ページから解約した顧客も、同じタイプとサブタイプを生みます。あなたのサーバーはまったく異なる2人の顧客について同じ通知を1つ受け取り、そのうちリテンションメッセージを見たのは1人だけです。

返金リクエストが進んだ場合、証拠を伝える経路は CONSUMPTION_REQUEST です。Apple はあらゆる製品タイプの返金リクエストに対してこれを送り、あなたには Send Consumption Information で応答する時間が 12 時間あります。応答できるのは顧客が同意した場合だけです。その後、Apple の判断は REFUND 通知として届きます。顧客がアプリ内で始めた返金を Apple が却下した場合は REFUND_DECLINED として届きます。

Google Play に解約メッセージの API はあるか

Google のサブスクリプションのライフサイクルに関するドキュメントにはありません。Google Play のサブスクライバーは Play の定期購入センターから解約し、現在の請求期間の終わりまでアクセスを維持し、それまでに Resubscribe（再登録）をタップすれば取り消せます。Google はこれを復元と呼んでいます。あなたは事後に SUBSCRIPTION_CANCELED 通知で知り、サブスクリプションリソースの userInitiatedCancellation フィールドでユーザーが離れた理由がわかります。一時停止は、Google によればすべてのサブスクリプションでデフォルトで有効になっており、自発的な解約を減らすための主な組み込み手段です。

返金の側では、Google Play に独自の証拠の経路があります。チャージバックに開発者の確認が必要なときは PendingRefundReviewNotification が届き、orders.reviewrefund を通じて応答する時間が 24 時間あります。2026年8月3日より後に行われた注文では、チャージバックが成立すると、Google は購入価格から Play のサービス手数料を差し引いた額と、銀行のチャージバック手数料を開発者に転嫁します。

解約画面にかかるお金

リテンションメッセージは無料に見えます。実際はそうではなく、請求は3か所に発生します。

ページ表示のたびにかかるコンピューティング

Apple があなたのエンドポイントを呼び出すのは、解約したときだけではなく、有効なサブスクライバーが解約ボタンのあるサブスクリプション詳細ページを表示したときです。訪問のたびに、サーバーは認証、照会、応答を 700 ms 以内に済ませる必要があり、間に合わなければ Apple はデフォルトに切り替えます。これでは、ときどき2秒かかるコールドスタートの関数は使えません。常にウォームな状態を保つキャパシティに加え、判断ロジックがリクエストごとに行うデータベースの読み取りや有料のサードパーティ API 呼び出しにも費用がかかります。

割引は自ら受け取らないことにした収益

サブスクライバーを引き留めたプロモーションオファーは、実際に守れたお金です。どうせ残っていた人に渡したオファーは、ただの値引きです。以下はベンチマークではなく例示です。月額 $9.99 のプランを3か月間半額で提供すると、オファーが受け入れられるたびに $14.99 を手放します。受け入れた人の3人に1人が定価でも残っていたなら、1,000 件の受け入れで、必要のなかった人に約 $5,000 の割引を渡したことになります。帳簿の反対側にいるのは、本当に離れようとしていたサブスクライバーです。

不快な出口が招く返金

Apple は Cancel Subscription ボタンをページに残すので、誰かを閉じ込めることはできません。それでも、うっとうしくすることはできてしまいます。押し付けられたと感じた顧客には、もう1つの選択肢があります。直近の請求を Apple に返してもらうことです。返金が実際に起きればお金は戻り、そのサブスクライバーに紐づくコンピューティング、ストレージ、API 呼び出し、アフィリエイトの支払いは使ったままです。どのリテンションメッセージでも取り戻せないコストです。

返金率を上げずにリテンションメッセージを使う方法

解約画面は、うまく立ち回る場ではなく、正確であるべき場だと考えてください。いくつかのルールを守れば、返金の境界線の安全な側にとどまれます。

• サブスクライバーごとに判断する。Apple のリクエストに含まれる originalTransactionId で最近の利用状況を調べます。製品を使っている人には割引や安いプランを提示します。何週間も開いていない人には、短く正直なメッセージを返します。
• 応答を速く保つ。利用データが変わった時点で判断を事前に計算しておき、リクエスト自体は 700 ms に余裕で収まる1回の照会で済むようにします。
• すべての製品とロケールにデフォルトメッセージを書く。デフォルトがなければ、呼び出しの失敗はメッセージなしを意味します。
• AUTO_RENEW_DISABLED を注意深く見る。同じ originalTransactionId に対して CONSUMPTION_REQUEST が続いたら、それは解約ではなく返金リクエストで、12 時間のカウントダウンはもう始まっています。
• 応答が許される CONSUMPTION_REQUEST にはすべて応答する。RefundHalt は 12 時間の期限内に正確な消費データを Apple に送り、Google Play のチャージバック確認には 24 時間以内に応答します。どちらのストアにとっても、あなたの言い分を求めるのはこの2つの場面だけだからです。

Apple にアクセスを申し込む価値はあるか

自動更新サブスクリプションを販売していて、すでに App Store Server Notifications V2 を扱っているなら、おそらくあります。解約画面は、サブスクライバーが去る前に届く最後の場所で、プラン変更のほうが完全に失うよりコストは小さく済みます。ただし、サブスクリプションページが表示されるたびに応答するエンドポイントの予算を確保し、返金への備えは返金が実際に起きる場所に置いておいてください。