簡単に言うと：CONSUMPTION_REQUESTとは、顧客が対象のアプリ内購入またはサブスクリプションに対して返金をリクエストした際に、Appleがサーバーに送信する通知です。これに応答するには、構造化されたConsumptionRequest（顧客が購入したものをどのように使用したか、同意の有無、そして返金に関する希望を示すフィールド群）を返送します。Appleはこれらのフィールドを判断材料として重視します。このガイドでは、各フィールドの意味とその重要性について解説します。
この通知とは
顧客がAppleに返金を依頼すると、App StoreはApp Store Server Notificationsを通じてサーバーにCONSUMPTION_REQUESTを送信します。これは、Appleが「この顧客がこの購入をどのように利用したか知っていることを教えてください。それを判断の材料にします」と伝えているということです。
応答するには、ConsumptionRequestのボディを返送します。すべての値がシグナルとなります。正確で完全なApple返金データを送信すれば、Appleは判断のための背景情報を得られます。フィールドを空欄のままにすると、Appleはより少ない情報で判断することになります。返金を承認・拒否するのはあなた自身ではなく、最終的な判断は常にAppleが行いますが、送信する内容の質によってその可能性は変わります。完全な流れについては、Apple返金リクエストを自動化する方法をご覧ください。
Appleが受け付けるフィールド
ConsumptionRequestに含まれる内容と、各フィールドがAppleに伝える情報を以下にまとめます。これらのConsumptionRequestのフィールドは、Consumption APIのワークフローで使用される構造化データを提供します：
フィールド | 表す内容 | 重要な理由 |
customerConsented | 顧客がこのデータの共有に同意したかどうか | 必須。trueでなければAppleは応答を処理しません。 |
consumptionStatus | 未消費／部分的に消費／完全に消費のいずれか | 完全に消費された購入は、まったく使用されていない購入とは大きく異なるケースです。 |
deliveryStatus | 価値またはサービスが正常に提供されたかどうか | 「提供済みで顧客が使用した」場合と、実際の配信失敗とを区別します。 |
refundPreference | あなたの推奨：undeclared（未指定）／prefer grant（承認を推奨）／prefer decline（拒否を推奨） | Appleが判断に用いる入力の1つです。根拠がある場合、これが判断におけるあなたの意見となります。 |
accountTenure | 顧客があなたのサービスでアカウントを保有している期間 | 長期にわたるアカウントは、新規アカウントとは異なる印象を与えます。 |
playTime | 顧客があなたのアプリで過ごした時間 | 返金対象の購入に対するエンゲージメントを示す直接的な証拠です。 |
lifetimeDollarsPurchased | 顧客があなたのアプリ全体で支払った合計金額 | 一回限りの顧客なのか、価値のある既存顧客なのかを判断する背景情報です。 |
lifetimeDollarsRefunded | この顧客に対して過去に返金された合計金額 | 繰り返し返金が発生しているパターンは、重要なシグナルです。 |
sampleContentProvided | 顧客が購入前に試すことができたかどうか | その購入が十分な情報に基づいて行われたかどうかを示します。 |
userStatus | 現在のアカウントステータス（有効、停止など） | リクエスト時点での顧客の状況を示す枠組みとなります。 |
Appleはこれらの大半を、定義済みの値セットにマッピングします（例えば、consumptionStatusとdeliveryStatusは特定の列挙コードを使用します）。正確なコードは以下にリンクしているAppleのドキュメントに記載されており、変更される可能性があります。そのため、応答を最新の状態に保つことは一度構築すれば終わりではなく、継続的な作業となります。
最も重要な3つのフィールド
何かに注力するなら、ここに注力してください：
customerConsented：これは重要というだけではなく、関所（ゲート）です。trueでなければAppleは送信全体を拒否し、データを送信する前にアプリ内でその同意を得ておく法的責任はあなたにあります。これは技術的なフィールドであると同時に、コンプライアンス上のフィールドでもあります。同意の要件については、 顧客同意 & Consumption APIで詳しく解説しています。
refundPreference：これは、あなたが持つ「投票」に最も近いものです。根拠が本当に拒否を支持している場合、その希望を表明することはAppleが検討する入力の1つとなります。根拠がない場合、拒否の希望を無理に設定しても魔法のような上書き効果はなく、Appleが最終的に判断します。
consumptionStatus：顧客が実際に購入したものを使用したかどうかは、しばしばケースの核心となります。また、リクエストが届いた時点で利用データが正確かつ最新でない場合、最も誤りやすいフィールドの1つでもあります。
これらを正しく入力することが、見た目より難しい理由
フィールドの表を見ると、これは午後のうちにすぐ終わる作業のように見えるかもしれません。しかし実際には、適切に応答するには次のことが必要です：
リクエストが届いた瞬間に、各顧客について正確かつ最新の利用データと請求データを取得すること（前日のスナップショットではなく）。
社内データをAppleの正確な値セットにマッピングし、Appleがそれらを改訂しても、そのマッピングを正しく保ち続けること。
担当者が監視していなくても、どの時間帯でも約12時間のウィンドウ内でこれを行うこと。
同意の状態、リトライ、失敗、ログ記録を処理し、送信した内容を証明でき、うまく機能しているかどうかを確認できるようにすること。
これらはどれも概念的に難しいものではありません。しかしそのすべてが、あなたの製品そのものではないワークフローのために、自分で構築・維持しなければならないインフラです。これは、ほとんどのチームが最終的に行き着く計算です。フィールドの内容は把握可能ですが、信頼性があり、期限を守り、コンプライアンスに準拠した応答システムを構築・維持することは、実際のアプリには何のメリットもない継続的なコストとなります。
そのギャップを埋めるのがRefundSensorです。あなたのデータからすべてのフィールドをマッピングし、Appleの変更に常に対応し、ウィンドウ内で自動的に応答します。これにより、返金を左右する正確性が、あなたが構築したり監視したりすることなく処理されます。Apple返金自動化ソフトウェアを比較検討しているチームにとって、これはワークフローからインフラの負担を取り除くものです。
公式ソース
Appleの値セットや要件は変更されるため、同社のドキュメントを最終的な権威として扱ってください：
フィールドの内容は把握可能です。しかし、そのための応答システムを維持することはあなたの仕事ではありません。RefundSensorは、あなたのデータからすべてのConsumptionRequestフィールドをマッピングし、Appleのウィンドウ内で自動的に、正確かつ最新でコンプライアンスに準拠した形で応答します。 無料で始める
よくある質問
これは、顧客が対象の購入に対して返金をリクエストした際に、Appleが送信するApp Store Server Notificationです。これにより、Appleが返金の判断において重視する消費データを返送するよう求められます。
同意、消費状況、配信状況、アカウントの保有期間、プレイ時間、累計支払額と返金額、サンプルコンテンツ、アカウントステータス、そして返金に関する希望を示すフィールドです。それぞれがAppleの判断に影響するシグナルとなります。
customerConsentedは厳格な関所（ゲート）であり、これがなければ応答は拒否されます。refundPreferenceとconsumptionStatusは、根拠があなたの主張を支持している場合に、結果を最も直接的に左右します。
希望は、正確な消費データや配信データに裏付けられている場合に、より大きな重みを持ちます。情報が少ない応答では、Appleが判断に使える材料が減るため、希望だけを送るよりも根拠を伴う希望を送るほうが効果的です。
いいえ。最終的な判断は常にAppleが行います。正確なデータは可能性を高めますが、拒否権を与えるものではありません。
