顧客がAppleに返金を申請します。その12時間後、あなたのサーバー側で一つの受付期間が閉じます。しかし、ほとんどのチームはその期間が開いていたことにすら気づいていません。
この期間こそがApple CONSUMPTION_REQUESTに関わるものです。これは、App Storeが返金リクエストを審査する際に、開発者からの情報を求めて送信する通知です。返金そのものではありません。決定でもありません。最終的な返金の判断はいずれにせよAppleが下します。この通知が提供するのは、その購入で実際に何が起きたのかを説明できる限られた機会です。
これを適切に処理するのはバックエンドの課題であり、サポートの課題ではありません。通知が確実に届き、取引を特定でき、同意状況を把握し、期限内に回答を送信する必要があります。
この記事では、この通知の意味、Appleが現在求めている情報（フィールドの一覧は以前よりはるかに短くなっています）、そしてそれを中心としたワークフローの構築方法を解説します。全体的なプロセスについては、 App Store返金管理のガイドで背景を説明しています。
重要なポイント
• CONSUMPTION_REQUESTは、返金審査中にAppleが情報を求める通知です。返金の通知ではありません。
• 最終的な返金の判断はAppleが下します。開発者の回答は複数ある判断材料の一つです。
• 現行のエンドポイントで扱うフィールドは5つで、そのうち3つが必須です。旧バージョンの12から減りました。
• 同意は必須です。customerConsentedがtrueでないリクエストはAppleに拒否されます。
• Appleは通知から12時間以内の回答を求めています。
• 期限が短く、通知が時間を問わず届くため、このステップは人手による処理よりも自動化に向いています。
Apple CONSUMPTION_REQUESTとは
CONSUMPTION_REQUESTはApp Store Server Notificationの一種で、顧客がAppleに返金を申請したこと、そしてApp Storeがその購入に関する消費情報の送信を開発者に求めていることを知らせるものです。
開発者向けのApple consumption requestが存在するのは、情報のギャップがあるためです。Appleには取引、アカウント、購入履歴が見えています。しかし、アプリの内部で何が起きたか——コンテンツが配信されたか、正常に動作したか、顧客が実際にどれだけ使用したか——は見えません。それが分かるのは開発者だけです。
一つはっきりさせておくべきことがあります。これは拒否権ではありません。回答が返金を阻止することはなく、Appleはさまざまな要素を考慮して判断すると明言しています。
Apple CONSUMPTION_REQUESTの仕組み
流れは次のとおりです。
顧客が返金を申請する
↓
Appleがリクエストの審査を開始する
↓
CONSUMPTION_REQUESTが通知エンドポイントに届く
↓
通知を検証し、取引を特定する
↓
同意を確認し、実際の使用データを収集する
↓
要件を満たしていれば、消費情報を送信する
↓
Appleが返金の判断を下す
↓
REFUNDまたはREFUND_DECLINEDが届き、状態を更新する
注目すべき点として、Appleの現行エンドポイントでは、あらゆるプロダクトタイプ——消耗型、非消耗型、非更新型サブスクリプション、自動更新型サブスクリプション——の返金リクエストがこの通知のトリガーになります。古いドキュメントや多くのサードパーティの解説記事は、いまだに消耗型と自動更新型サブスクリプションのみが対象と説明しています。ハンドラーがその前提でプロダクトタイプによるフィルタリングを行っている場合、リクエストを取りこぼしています。
Appleが開発者に求める情報
以前よりも少なくなりました。既存の解説の多くがここを誤って伝えているため、正確に述べておく価値があります。Appleの現行の Send Consumption Informationエンドポイントが受け付けるフィールドは5つで、必須が3つ、任意が2つです。
フィールド | 必須 | 開発者にとっての意味 |
customerConsented | はい | trueである必要があります。そうでない場合、Appleはリクエストを拒否します。 |
deliveryStatus | はい | アプリが正常に動作する購入品を問題なく配信したかどうか。 |
sampleContentProvided | はい | 購入前に顧客がサンプルコンテンツを受け取ったかどうか。 |
consumptionPercentage | いいえ | 購入品がどれだけ消費されたか（ミリ単位）。 |
refundPreference | いいえ | 希望する結果：全額返金、拒否、または按分返金。 |
つまずきやすい制約が2つあります。deliveryStatusがdelivered以外の場合、consumptionPercentageはゼロでなければならず、そうでないとリクエストは失敗します。また、ミリ単位はパーセントではありません。半分消費した場合は50ではなく50000です。
任意のrefund preferenceは比較的新しく、理解しておく価値があります。全額返金、拒否、按分返金のどれを希望するかを示せます。これは希望であって指示ではありません。Appleは他のすべての要素とあわせて考慮するため、結果が希望と異なることもあります。
Appleが按分返金を承認した場合、取り消された部分は取引ペイロードで返されます。そのため、すべての返金を全か無かとして扱うのではなく、部分的な取り消しに対応できるエンタイトルメントのロジックが必要になる場合があります。
Appleが消費情報を必要とする理由
Appleは、一部しか見えないものについて判断を下しているからです。
Appleは、何が、いつ、どのアカウントで購入されたか、そのアカウントの履歴がどのようなものかを把握しています。しかし、サーバーがコインを配信したか、アンロックした機能が動作したか、顧客が返金を求める前にプロダクトを多く使用していたかは分かりません。そうした背景情報は開発者のシステムにあります。
CONSUMPTION_REQUESTによるAppleの返金フローは、判断の前にその背景情報を取り込むためのAppleの仕組みです。だからこそ、主張よりも正確さが重要になります。データは何が起きたかを記述するものです。開発者が主張を展開する場ではなく、そのように扱うことは確かなリターンのないまま実質的なリスクを伴います。
開発者によるCONSUMPTION_REQUESTへの対応方法
8つのステップがあります。作業の大半は、リクエストが届く前に行うものです。
1. 通知を受信する
App Store CONSUMPTION_REQUEST通知は、App Store Server Notifications V2用に設定したサーバーURLに届きます。そのエンドポイントが未設定、未検証、または気づかれないまま失敗している場合、リクエストは届きません。Appleの App Store Server Notificationsのドキュメントで、設定方法とペイロードの形式が説明されています。
2. 通知を検証する
通知は署名付きJWSペイロードとして届きます。内容に基づいて処理を行う前に、Appleの証明書チェーンに対して署名を検証し、バンドルIDが自分のアプリと一致することを確認してください。送られてきたものを何でも受け入れる未検証のエンドポイントは、第三者が返金ロジックを操作する経路になります。
3. 取引を特定する
デコードしたペイロードには取引識別子が含まれています。それと照合するための購入記録を保存しておく必要があります。記録がなければ照合はできず、消費について有用な情報を伝えることもできません。
4. 取引を正しいユーザーに紐付ける
どの顧客なのかが分からなければ、その顧客の使用状況を説明することはできません。この紐付けのために存在するのが appAccountTokenです。購入時にアプリが付与するUUIDで、通知ペイロードに含まれて返ってきます。これがないと、チームはタイミングやヒューリスティックによる照合に頼ることになり、まさにスピードが重要な場面で時間がかかり、信頼性も低くなります。
5. 適用される同意要件を確認する
この点についてAppleの姿勢は明確です。顧客のデータを共有する前に有効な同意を取得しなければならず、その取得はAppleではなく開発者の責任です。通知には同意フラグが含まれないため、自社の記録から把握する必要があります。
顧客が同意していない場合、Appleのガイダンスでは回答自体を行わないこととされています。同意をfalseに設定してリクエストを送信しても機能せず、App Storeに拒否されます。また、App Tracking Transparencyのプロンプトはこの目的の仕組みではないとAppleは明言しています。これはアプリ内で取得する別個の同意です。
6. 実際の使用情報を収集する
配信状況と消費量は実際の記録から取得してください。サーバーで消耗型アイテムの残高を管理していれば、どれだけ使われたかはすでに分かっています。機能のアンロックが失敗した場合も、ログに記録されているはずです。推測はしないでください。作り上げた消費量の数値は、正確なデータのために取得した同意のもとでAppleに送る不正確なデータになります。
7. 適切な情報を送信する
通知に含まれる元の取引識別子を使用して、consumptionエンドポイントにPUTで回答します。送りっぱなしにせず、エラーレスポンスを処理してください。バリデーションの失敗は特定のエラータイプを伴うHTTP 400を返しますが、誰も確認しなければ、静かに失敗した呼び出しは成功した呼び出しと見分けがつきません。
8. 結果を記録する
リクエスト、取引、送信した内容、送信日時、そしてAppleの最終的な判断をログに残してください。この記録があれば、数週間後のサポートの問い合わせに答え、返金全体のパターンを把握し、エンタイトルメントの状態が正しいことを確認できます。返金が確定したら 返金後にアクセスを取り消し、Appleが後に判断を覆した場合には復元できるよう備えておいてください。
CONSUMPTION_REQUESTを見逃すとどうなるか
劇的なことは何も起きません。それこそが問題の一部です。
回答を逃すということは、そのワークフローでAppleが提出を認めた追加情報を提供しないということです。判断は変わらずAppleが下します。Appleがすでに持っている情報に基づいて、返金は承認されることも拒否されることもあります。エラーも、アラートも、何かが抜け落ちたことを示す明確なサインもありません。
見逃し方はごくありふれています。通知が午前2時に届く。ハンドラーの担当エンジニアが不在。識別子があるシステムと使用データがあるシステムが別で、取引の照合に時間がかかる。誰かが月曜日に気づいたときには、期限はとっくに過ぎている、といった具合です。
CONSUMPTION_REQUESTの手動処理が難しい理由
このワークフローのあらゆる制約が、手動処理には不向きであることを示しています。
通知は24時間いつでも届きます。期限は12時間です。各リクエストには、取引の照合、ユーザーの紐付け、同意の確認、使用量の計算、署名付きAPI呼び出し、結果の記録が必要です。7つのステップはどれも面白みがなく、すべてに時間制限があります。
週に1件なら煩わしい程度です。1日に30件になると誰かの仕事になります。うまくやっても何も生まず、遅れれば静かに損失が出る仕事です。
自動化が返金ワークフローをどう変えるか
自動化によってAppleに影響を与えられるわけではありません。多くのマーケティングがそう匂わせているため、繰り返しておく価値があります。判断はあくまでAppleのものです。
自動化がもたらすのは、開発者側の対応の一貫性です。通知は監視・検証され、関連するリクエストはストリームの他の通知から切り分けられます。取引はアカウントに紐付けられ、回答データは実際の記録から組み立てられ、期限は追跡され、回答は送信・記録され、結果はエンタイトルメントの更新に反映されます。
これらのステップに判断は不要です。必要なのは適切なタイミングで注意を向けることであり、それは人よりもソフトウェアの方が得意です。
App Store返金管理ソフトウェアが担うべきこと
App Store返金管理ソフトウェアを検討しているなら、問うべきは上記の具体的なギャップを埋められるかどうかです。
App Store Server Notificationsを監視・検証し、失敗しているエンドポイントにイベントが消えてしまわないようにすること。CONSUMPTION_REQUESTイベントは返金結果とは異なる処理が必要なため、区別して追跡すること。手作業の時間が最もかかるのは取引とアカウントの紐付けなので、それを行うこと。人が見逃すのは期限なので、回答期限を追跡すること。
さらに、同意状態を尊重した消費データのワークフロー、検索可能な返金履歴、結果の追跡、部分的な取り消しを含むエンタイトルメントの同期、パターンが分かる明確なレポート。重要なのは機能一覧の長さではなく、ワークフローをどれだけカバーしているかです。
これらのルールが記載されている場所
上記の内容はすべて、Appleの3つの資料でカバーされています。直接読んでください。この領域は最近変更されており、二次的な解説の多くは古いバージョンのAPIを説明しています。
Send Consumption Information — 現行のエンドポイントです。同意要件、12時間の期限、5フィールドのリクエストボディ、そして消費情報がすべてのプロダクトタイプに適用されることが記載されています。標準的なIn-App Purchaseの実装はこれを基準にしてください。
App Store Server Notifications — 通知がバックエンドに届く仕組み、署名付きペイロードの形式、そしてCONSUMPTION_REQUEST、REFUND、REFUND_DECLINEDを含む通知タイプについて記載されています。
Send Consumption Information V1 — 以前のエンドポイントで、12フィールドのリクエストボディを持ち、一部のチームは今もこれに接続しています。Apple自身がこのページの注記で、標準的なIn-App Purchaseは現行エンドポイントを使用するよう案内し、V1の対象をAdvanced Commerce APIを使用する購入に限定しています。自社の連携がどちらを使っているかを確認するのには役立ちますが、実装の基準にすべきものではありません。
まとめ
CONSUMPTION_REQUESTはAppleの返金の判断ではありません。開発者のシステムが知っていてAppleが知らないことを伝えるための、短く時間の限られた機会です。
これを確実に処理するワークフローには、検証済みの通知エンドポイント、特定可能な取引、紐付け可能な顧客、実際に取得した同意、実際の使用データ、期限内の回答、そして後からエンタイトルメントを更新できる十分な結果の記録が必要です。
この記事を読んで一つだけ行動するなら、自社の連携がどのエンドポイントを呼び出しているかを確認してください。標準的なIn-App Purchaseに対していまだにV1のパスへ12フィールドを送信しているなら、それが最初に埋めるべきギャップです。
返金件数が手動処理の限界を超えているなら
返金が頻繁になり、通知を手作業で監視するのが現実的でなくなったら、専用のシステムでイベントを監視し、期限内に回答を準備・送信し、結果を追跡し、エンタイトルメントを常に最新の状態に保つことができます。 RefundSensorは、そのワークフローの開発者側を自動化します。Appleの判断ではなく、開発者が責任を負う部分だけです。
よくある質問
顧客が返金を申請し、Appleが消費情報を求める可能性があることをサーバーに知らせるApp Store Server Notificationです。返金の決定ではありません。
顧客が返金を申請した後、Appleがそのリクエストを審査している間に送信されます。さまざまなApp Storeのプロダクトタイプが対象になり得ます。
サーバーが通知を受信・検証し、取引と顧客を特定し、同意を確認したうえで、回答期限内に必要な消費情報をAppleに送信します。
通知を検証し、顧客の同意を確認し、正確な使用状況と配信データを用意してAppleに送信し、回答内容と最終結果を記録しておきます。
Appleの現行ドキュメントでは12時間の回答期限が定められています。実装前にAppleの最新要件を確認してください。
顧客がその購入をどのように使用したかに関する情報です。現行エンドポイントでは、同意、配信状況、サンプルコンテンツの有無、消費データ、希望する返金結果が含まれます。
いいえ。最終的な判断はAppleが下します。開発者は消費情報を提供し、返金に関する希望を示すことはできますが、最終決定はAppleが行います。
はい。通知の検証、取引の照合、同意の確認、データの準備、期限の追跡、回答の記録を自動化できます。
