簡単に言うと： CONSUMPTION_REQUEST への応答として消費データを Apple に送信する前に、顧客から有効な同意を得ている必要があり、customerConsented を true に設定する必要があります。Apple の通知は同意が存在するかどうかを教えてくれません。これは意図的な設計で、Apple はサーバーではなくアプリ側で同意を取得することを期待しています。また、あなたが送信するデータはユーザーから収集したものであるため、その同意に関する法的責任はすべて Apple ではなくあなたにあります。これを誤ると、単に API 呼び出しが拒否されるだけでなく、プライバシー法上の問題になります。
多くの開発者が見落としているギャップ
返金自動化に関するガイドは、12時間の時間枠や消費データのフィールドについて語るのが好きです。しかし、開発者が最もトラブルに陥りやすい一点について言及しているものはほとんどありません。それは、CONSUMPTION_REQUEST 通知には同意の有無を示す情報が一切含まれていないということです。
これは多くの人を驚かせます。Apple がデータを求めているのだから、共有の許可についてはすでに Apple が処理済みだろうと考えるのは自然なことです。しかし、そうではありません。Apple の立場はその逆で、送信するデータはあなたがあなたのユーザーから収集したデータであるため、それを共有する許可を得る責任はあなたにあります。Apple は customerConsented を true に設定することでその証明を求めているだけであり、設定しなければ送信は拒否されます。これが Apple Consumption API の同意要件の核心です。
つまり、このフィールドは API を満足させるために切り替えるだけのチェックボックスではありません。これは法的な証明です。実際に同意を得ていないのに true に設定することは、単なる形式上の問題ではなく、いつか発見されるコンプライアンス違反です。
なぜ同意の取得が開発者の責任なのか
誰が何を担っているかを考えてみましょう。Apple はストアと返金の判断を運営しています。しかし、ConsumptionRequest に含めるアカウントの利用期間、プレイ時間、配信状況、利用履歴などは、あなたのプライバシーポリシーのもとで収集された、あなたのユーザーに関するあなたの記録です。これらを Apple に送信することは、第三者に個人データを開示することになります。
適用されるプライバシー規制のもとでは、この開示には適切な法的根拠が必要です。Apple の API ドキュメントでは、Consumption Information API を通じて個人データを共有する前に有効な同意が必要であると明記されていますが、正確な法的要件はユーザーの管轄区域によって異なります。Apple は、適用法への準拠を判断する責任は開発者にあると述べています。
そのため、この責任は開発者にあります。規制当局からユーザーのデータを共有する許可をどのように得たのかと問われた場合、「Apple に求められたから」という言い訳は通用しません。apple の返金同意ワークフローにおいて重要なのは、データが共有される前に同意が存在していることです。
同意をどこで取得すべきか
実務的に重要なのはこの点です。同意はアプリ内で、返金フローが始まる前に取得する必要があり、通知が届いた時点でサーバー側で推測するものではありません。
CONSUMPTION_REQUEST がサーバーに届く時点では、同意を求めるにはもう遅すぎます。その場にユーザーはおらず、残された時間は約12時間だけです。同意はアプリのオンボーディングやデータ取り扱いの開示の一環として、事前にすでに取得・記録されていなければなりません。そうすれば、リクエストが届いたときに customerConsented を true に正直に設定できます。
実務上これは、アプリの利用規約、プライバシーポリシー、購入やオンボーディングのフローにおいて、返金リクエストを処理するために消費データが Apple と共有される可能性があることを明確に開示し、自信を持って説明できる形で同意を取得する必要があるということです。曖昧で、他の事項と一緒にまとめられた、あるいは埋め込まれた同意は、まさに現代のプライバシー法が排除しようとしているものです。これは apple の返金プライバシーにおいても中心的な論点であり、Apple は消費データが共有される前に有効な同意を明確に求めています。
GDPR と DPDP との関係
ユーザーが EU/UK（GDPR）、インド（DPDP）、カリフォルニア（CCPA）、またはその他増え続ける管轄区域に存在する場合、消費データの共有はまさにこれらの枠組みの対象となります。一貫して適用されるいくつかの原則を紹介します。
同意は十分な説明を受けた上での、具体的なものである必要があります。ユーザーは、返金関連のデータが Apple と共有される可能性があることを理解している必要があり、単に長文の法的文書に同意するだけでは不十分です。
同意は分離可能であるべきです。データ共有への同意を、関係のない規約と一つの必須チェックボックスにまとめてしまうのは、よく知られたアンチパターンです。
同意を証明できなければなりません。異議を申し立てられた場合、「同意は得ていた」という主張は証明可能である必要があります。つまり、同意の取得は想定ではなく、記録として残しておく必要があります。
プライバシーポリシーに実際にその旨を記載する必要があります。ポリシーに返金のために消費データを Apple と共有することが開示されていない場合、その同意は不安定な基盤の上に成り立っていることになります。
GDPR の消費データ要件を確認しているチームにとって重要な点は、Apple 自身がこの API に対して有効な同意を要求している一方で、正確な法的要件や法的根拠は管轄区域によって異なるということです。Apple のガイダンスでは、同意は自由意思に基づき、具体的で、十分な説明を受けた上での、明確なものである必要があり、適用法への準拠を判断する責任は開発者にあるとされています。
インド向けのアプリについても同様に、Apple の API 要件だけですべてのプライバシー上の義務が解決されると考えるのではなく、DPDP のアプリ返金同意について適用される要件に照らして確認する必要があります。
これは法的アドバイスではなく、具体的な義務の内容はユーザーや管轄区域によって異なりますが、方向性は明確です。customerConsented フィールドの背後にある同意は、本物であり、十分な説明を受けた上でのものであり、文書化されている必要があります。
コンプライアンスに適合した仕組みとは
これらをまとめると、防御可能な仕組みには、返金が発生する前に機能している3つの要素があります。
開示：プライバシーポリシーと利用規約に、返金リクエストを処理するために消費・利用データが Apple と共有される可能性があることを明確に記載する。
取得：アプリがユーザーから十分な説明を受けた上での、分離可能な同意を取得し、それを記録する。
証明：CONSUMPTION_REQUEST が届いたとき、応答の customerConsented に記録済みの同意を正直に反映させる。
RefundSensor はこの連鎖を念頭に構築されています。本プラットフォームは、自動化フローの一部として返金への応答と customerConsented の証明を処理し、GDPR、DPDP、CCPA に準拠したプライバシーポリシー、利用規約、DPA、クッキーポリシー、返金ポリシーからなる完全なコンプライアンス文書一式を公開しています。そのため、開示と処理の側面は即興ではなくきちんとカバーされています。アプリ内での同意取得は、当然ながらあなた自身の判断に委ねられますが、それ以降のプロセスはすべて処理されます。
返金コンプライアンスソフトウェアや Apple 返金自動化ツールを評価しているチームにとって、この切り分けは重要です。自動化が担えるのは技術的な応答部分であり、顧客の同意を創作したり想定したりすべきではありません。
よくある間違い
customerConsented をデフォルトで true に設定する。返金機能をコンプライアンス上のリスクに変える最も手早い方法です。
Apple が同意を処理してくれると思い込む。そうではありませんし、Apple もそう明言しています。
返金のタイミングで同意を取得しようとする。その場にユーザーはおらず、時間の余裕もありません。同意は事前に存在している必要があります。
プライバシーポリシーで何も開示しない。ポリシーが Apple とのデータ共有について何も触れていない場合、その背後にある同意を守ることは困難です。
一つの必須チェックボックスにまとめてしまう。分離可能な同意が標準であり、まとめてしまうとそれが損なわれます。
App Tracking Transparency を同意の仕組みとして利用する。Apple のドキュメントには、Consumption Information API に必要な同意は App Tracking Transparency とは別のものであると明記されています。
公式情報源
要件も規制も変化するため、以下を最終的な根拠としてください。
同意の連鎖を尊重する返金自動化。RefundSensor は、GDPR/DPDP/CCPA に準拠した完全なコンプライアンス文書一式に支えられ、自動化フローの一部として返金への応答と customerConsented の証明を処理します。アプリの返金自動化を探しているチームにとって、同意の連鎖は実装の一部であることに変わりはありません。 無料で始める
よくある質問
はい。有効で十分な説明を受けた上での同意を得て、customerConsented を true に設定する必要があります。Apple はこの証明を必須とし、それがない応答を拒否します。また、同意を取得していたことについての法的責任はあなたにあります。
アプリ内で、返金フローが始まる前に取得する必要があります。CONSUMPTION_REQUEST がサーバーに届いた時点では、ユーザーはその場にいませんし、残り時間は約12時間しかありません。そのため、同意はすでに存在し、記録されていなければなりません。
いいえ。通知には同意の有無を示す情報は含まれていません。Apple は、アプリ側で同意を取得していることを前提としており、応答の中でそれを証明することを求めています。
同意の連鎖が適切に行われていれば準拠可能です。具体的には、ポリシーでの明確な開示、アプリ内で取得・記録される十分な説明を受けた上での分離可能な同意、そして API への応答における正直な証明が必要です。自動化は応答部分を処理しますが、アプリ内での同意取得はあなたの責任です。
Apple は消費データを処理しないため、その返金判断に情報を反映させる機会を失います。正しい方法は、同意なしにデータを送信するのではなく、事前に実際の同意を取得することです。
