Apple CONSUMPTION_REQUEST：App Storeの返金リクエストへの対応方法

誰かが「問題を報告」を開き、あなたのアプリを選んで、Appleに返金を求めます。Appleはすぐには判断しません。まずあなたのサーバーに通知を送り、その購入について何を知っているかを尋ね、約12時間、回答を待ちます。

その通知がApple CONSUMPTION_REQUESTです。実際にIAP収益を上げているチームでも、聞いたことがないところは少なくありません。ログで一度見かけたきり放置しているチームはさらに多いでしょう。心当たりがあるなら、こちらの
Apple CONSUMPTION_REQUEST解説記事で「何か」と「なぜ」を押さえてください。この記事は「答える」パートです。何を送るべきか、何を送るべきでないか、そして実際に試した人たちに何が起きたかをまとめます。

重要ポイント

• 顧客が返金を求めると、AppleはCONSUMPTION_REQUESTを送信します。猶予は約12時間。それを過ぎると、Appleはあなた抜きで判断します。

• 返信はフィールド5つです。50ではなく、5つです。

• 返金の希望（refund preference）は文字どおり「希望」にすぎません。Appleはこれまでも覆してきましたし、今後も覆します。

• 顧客の同意がなければ、返信はしません。私たちではなく、Appleがそう言っています。

• あるアプリは、返信を始めただけで、約2週間で返金率が3%から1.9%に下がりました。Appleに却下を求めたことは一度もありません。

• 手作業で長く続けられる人はいません。猶予は短すぎ、リクエストは都合の悪い時間に届きます。

そもそもApple CONSUMPTION_REQUESTとは何か

これはサーバー通知で、AppleがApp Store Server Notifications V2を通じて送る多くの通知のひとつです。誰かがアプリ内課金の返金をリクエストすると発火します。以前は消耗型のみが対象でしたが、WWDC24以降は自動更新サブスクリプションも対象になりました。売上の大半はそこにあります。

ペイロードの中身は、署名付きトランザクション、プロダクトID、そして顧客が選んだ理由です。Appleの
consumption Request Reasonのドキュメントには5つが列挙されています。UNINTENDED_PURCHASE、FULFILLMENT_ISSUE、UNSATISFIED_WITH_PURCHASE、LEGAL、OTHERです。

含まれていないのは、名前やApple IDです。あるのはトランザクション識別子だけ。それを「これはユーザー48213で、購入後にアプリを40回開いている」に変換するのはあなたの仕事で、チェックアウト時にappAccountTokenを付けていた場合にしか成立しません。あまりに多くの人が省略しているため、
appAccountTokenだけを扱った記事 を書きました。

Appleが尋ね、あなたが答え、Appleが決める。それが開発者にとってのApple返金リクエストの構図です。

Apple CONSUMPTION_REQUESTへの返信方法

AppleのSend Consumption Informationエンドポイントに、パスにトランザクションIDを含めて小さなJSONボディをPUTします。このボディが、返金システムが読み取るApple consumption information（消費情報）です。

最初はcustomerConsentedです。trueかfalse。falseなら、そこで止めてください。何も送らないでください。Appleのドキュメントには、同意がない場合は一切返信すべきでないと書かれています。奇妙ですが、それがルールです。

次にdeliveryStatusです。正常に配信できていればDELIVERED。そうでなければ、品質の問題、誤ったアイテム、サーバー障害、その他に対応するUNDELIVERED系の値があります。

sampleContentProvidedは、購入前に顧客が試せたかどうかのyes/noです。無料トライアルがあればyes。コンテンツのプレビューがあればyes。箇条書き3行だけのペイウォールなら、おそらくnoです。

consumptionPercentageでつまずく人が多いです。単位はミリユニットで、100000が完全消費、50000が半分を意味します。自動更新サブスクリプションでは省略してください。Appleが請求期間から算出します。

最後にrefundPreferenceです。DECLINE、GRANT_FULL、GRANT_PRORATEDのいずれか。任意項目です。そして、あなたの希望を伝えられる唯一の場所でもあります。

すでに使い切られたコインパックへの返信例：

Appleは202を返すだけで、それ以外は何もありません。判定はなし。2021年にAppleのエンジニアが開発者フォーラムで述べたとおり、202は送ったデータが「考慮される」という意味です。約束はそれだけです。

すべてにDECLINEを送ってはいけない

気持ちはわかります。でも我慢してください。

まず理由を読んでください。FULFILLMENT_ISSUEなら配信ログを確認します。本当に購入が届いていなかったなら、該当するUNDELIVEREDステータスとGRANT_FULLを送って次へ進みましょう。その案件では勝てませんし、争えば後のDECLINEの説得力が弱まります。

UNINTENDED_PURCHASEは利用状況が鍵です。9:02に購入、9:05に返金リクエスト、その間のセッションはゼロ？ おそらく誤タップです。手放しましょう。1週間毎日使っていた？ 実際の消費率を添えてDECLINEです。

UNSATISFIED_WITH_PURCHASEでは、sampleContentProvidedが真価を発揮します。トライアルがあって80%使っていたなら、却下。ほとんど開いていないなら、GRANT_PRORATEDが公平な落としどころです。

LEGALとOTHERについては、正確なデータを送り、記録から判断が明らかな場合を除いて希望は省略してください。

消費率95%と無料トライアルの裏付けがあるDECLINEは強い返信です。90秒しか使われていないものへのDECLINEは、反射的に見えます。

実際にやった人たちに何が起きたか

Dipseaは、RevenueCatが2024年9月に買収したオーディオアプリで、自社の返金ハンドラーのテストに使われました。10月23日、彼らは希望を「Appleに任せる」に設定してconsumption requestへの返信を始めました。DECLINEなし。データだけです。約15日で、返金率は横ばいの3%から1.9%に下がりました。
グラフも公開されています。私にとっては、このテーマで最も有用なデータポイントです。データだけで数字が動いたのです。

次は反対側の話です。2024年3月、あるゲームスタジオがApple Developer Forumsに投稿しました。consumption情報を送っているのに、プレイヤーがすでに使ったコインの返金を、Appleが「ほぼすべて」承認しているというのです。消耗型は難しいケースです。コインが消えてしまえば、Appleは取り戻せません。REFUND通知の後に自分で残高を取り消さなければ、お金もコインも失います。

そして2025年5月、r/iOSProgrammingのスレッドが、「常に却下を希望」に設定していたのに突然すべての返金が承認されるようになったというRevenueCatユーザーで埋まりました。RevenueCatは、Apple側のポリシー変更だと説明しました。原因が何であれ、これで長年の議論に決着がつきました。refundPreferenceはスイッチではありません。一律DECLINEはパターンであり、Appleはそれを無視できるのです。

400が返ってくるパターン

Appleはボディに厳格です。繰り返し目にするのは次のものです。

ミリユニットの問題。「パーセンテージ」と読んで100を送り、顧客が0.1%しか使っていないとAppleに伝えてしまうケース。範囲は0から100000です。

未配信アイテムにゼロ以外の割合を送る。deliveryStatusがDELIVEREDでない場合、consumptionPercentageは0でなければリクエストは弾かれます。

自動更新サブスクリプションに割合を送る。Appleには専用のエラーがあります。省略してください。

キーの取り違え。この呼び出しに必要なのはIn-App Purchaseキーで、App Store Connectの「ユーザーとアクセス」から「統合」で生成します。App Store Connect APIキーではありません。見た目は同じでも別物です。間違えると401が返り、1時間JWTを疑うことになります。

同意の省略。HTTPエラーではなく、コンプライアンス上のエラーです。本番稼働の前に、利用規約に文言を入れておいてください。

まずsandboxでテストしてください。ひとつ注意点があります。Appleのテストに関するドキュメントによると、sandboxでの猶予は12時間ではなく5分です。サーバーが6分かかると、テストはデータを無視します。強制的に却下させるには、返金シートで「その他」を選び、DECLINEと入力します。

リクエストが大量にあるとき、開発者はApp Storeの返金リクエストをどう処理しているか

率直に言えば、ほとんどは処理していません。リクエストは午前3時に届きます。あるいは土曜日に。あるいは、パイプラインを理解している唯一の人がオフラインの休日に。12時間が過ぎ、Appleは顧客の言い分だけで裁定します。

開発者としてAppleの返金リクエストをどう処理するかは、ひとつの決断に集約されます。一連の処理を自分で構築し（JWSの検証、ユーザーの照合、利用状況の取得、割合の計算、JWTの発行、エンドポイントの呼び出し、ログ記録、リトライ）、永久に動かし続けるか。それとも、それをすでにやってくれるApple返金管理ソフトウェアを組み込むか。

Refund Sensorは後者の選択肢のひとつです。私たちの通知URLをApp Store Connectに貼り付け、キーを接続すれば、返信は数秒で送信されます。現在導入中のアプリ全体では、対象リクエストの77%が防御され、1件あたり約$33が保護されています。特別なことは何もしていません。実データを含む返信が、毎回、期限前に送られるだけです。他と比較したいなら、Apple返金管理ツール
ガイドで確認すべき点をまとめています。

だからこそ、開発者向けのApple返金自動化が繰り返し話題になるのです。12時間以内、すべてのリクエスト、毎週。これは人間の仕事ではありません。何を選ぶにせよ、何かを選んでください。沈黙は、Appleが片方の言い分しか聞かないことを意味します。