4回目の返金を求めるユーザーは、不満を抱いた顧客ではありません。手口を繰り返しているだけであり、返金された売上に加えて、注文の履行に費やしたすべてのコストも失うことになります。AppleとGoogleはそれぞれ、一方はappAccountToken、もう一方はobfuscated account idという識別子フィールドを公開しており、これらの個別の事象を目に見えるパターンへと変えてくれます。
重要なポイント
あなたからの証拠がストアに届く状況は、正確に2つだけです。AppleのCONSUMPTION_REQUEST(12時間以内に回答可能)と、Review Refund API経由のGoogle Playのchargeback review(24時間以内に回答可能)です。それ以外のケースは、あなたの関与なしに判断が下されます。
Appleでは、自分で生成したUUIDがappAccountTokenとして購入に付随します。StoreKitがそれをトランザクションに固定するため、後の返金はすべて、自社の記録内で特定可能な1つのアカウントに結びつきます。
Googleにおける対応物は、64文字以内のハッシュ化された文字列です。Google自身がこの値を読み取り、短期間に1つのアカウントが不自然なほど多くのデバイスで購入を行うといった、異常な行動を検出するために使用します。
このGoogleのフィールドに平文の個人データを含めると、購入が即座にブロックされます。暗号化された値または一方向ハッシュが必要であり、生のメールアドレスは認められません。
PlayのvoidedReasonは、friendly_fraudやfraudを、単なる気が変わったことによる通常の返金から区別します。これにより、常習的な不正利用者を、デフォルトの「返金して終わり」という対応ではなく、レビューキューに送る根拠が得られます。
Googleは、2022年中に20億ドルを超える不正・悪用トランザクションを阻止したと報告しています。これらの防御策は、購入データが識別子を含んでいる場合にのみ機能する識別信号の上に成り立っています。
返金後も残り続けるアクセス権は、もはや対価を得ていないストレージ、コンピュート、APIの予算を消費し続けます。意図的に返金を行う人物は、まさにこの結果を繰り返し作り出そうとしているのです。
はじめに
返金は発生するものであり、1回限りであれば単なるコストにすぎません。状況が変わるのは、過去に毎回商品を消費してきた同じアカウントが、4回目として再び現れたときです。この行動が見えるようになるのは、すべてのトランザクションに自分が割り当てた識別子が含まれている場合だけです。両プラットフォームとも、そのための手段を用意しています。また、結果が確定する前に回答できる狭い時間枠も設けています。識別子を省略するか、その時間枠を逃せば、仕組みを悪用している人物と、本当に不満を持つ初めての利用者とを区別することはできません。この2者の違い、そしてその違いが金銭的にどれほどの価値を持つのかを、以下で見ていきます。
返金の不正利用は、実は「返金」という衣をまとった識別の問題である
返金の判断はストアに属します。顧客が返金を求めれば、ほとんどのフローではストアがそれに応じ、あなたが入力できる余地はありません。あなたの影響力が及ぶのは別の部分、つまり、この特定のアカウントにこれまでそうした履行歴があるかどうか、そして購入したものが実際に配信され使用されたかどうかを立証することです。どちらの問いも、識別の問いです。このトランザクションの背後にいるのはどのユーザーで、これまで何をしてきたのか。自社のユーザーレコードへの安定したリンクを持たない購入は、どちらの問いにも答えられないまま、すべての返金が文脈を欠いた状態で処理されてしまいます。
これこそ、埋める価値のあるギャップです。仕組み自体はポリシーによって固定されており、あなたが動かすことはできません。しかし、証拠を組み立てるのはあなた自身の役割であり、その組み立てはチェックアウト時に始まるのであって、返金時に始まるわけではありません。
送った内容が実際に意味を持つ、2つの時間枠
あなたの入力を入力として扱ってくれるフローは、2つしかありません。顧客が消費型アイテムや自動更新サブスクリプションの返金を求めると、AppleのCONSUMPTION_REQUESTが発生し、12時間以内に回答する必要があります。顧客が銀行に決済の異議を申し立てると、Google Playのchargeback reviewが発生し、Review Refund API経由で24時間以内に回答できます。この2つ以外では、判断はあなたの関与なしに行われます。Playの48時間セルフサービス返金、サポートによる返金の承認、確認すらしていない購入に対する自動返金などがこれに当たります。
トランザクションにすでに識別子が含まれていれば、どちらの経路も精度が大きく高まります。Appleに送信する消費情報には、appAccountTokenをそのアカウントの購入履歴とともに含めることができ、一方Googleのレビューは、購入完了時から観測し続けているobfuscated account idを基に行われます。識別子がなければ、提出すべき履歴そのものが存在しません。
2つの識別子フィールドの比較
両社は、異なる名前と異なる制約のもとで、ほぼ同一の解決策に行き着いています。どちらも、自社のユーザーレコードに戻って解決できる値を購入に付与できる仕組みです。どちらもデフォルトで有効になってはいません。そして、どちらも購入処理の最中に設定しなければ意味がありません。
Apple:appAccountToken
UUIDを生成し、購入開始時に渡すと、StoreKitがそれを結果として生成されるトランザクションに紐づけます。その値は、サーバーが検証するトランザクションデータに現れ、さらにCONSUMPTION_REQUEST時に返送する消費情報にも再び現れます。この値は自分自身が発行したものなので、名前やメールアドレスを一切介さずに、ストアのトランザクションをデータベースの1行に結びつけることができます。有効なのは本物のUUIDのみで、それ以外は拒否されます。Appleはその後、すでに発生したトランザクション(オファーコードの引き換えやアプリ外購入なども含む)に対してトークンを書き込んだり更新したりできるSet App Account Tokenエンドポイントを提供しました。
Google Play:obfuscated account id
setObfuscatedAccountIdはGoogle版の仕組みで、購入アカウントに紐づく任意の文字列です。Googleのドキュメントはその目的をはっきりと述べています。Playはこの値を使って異常な活動を検出し(例として挙げられているのは、短時間のうちに1つのアカウントで多数のデバイスが取引を行うケースです)、一部の不正な購入を完了前に阻止します。上限は64文字で、平文の個人データは禁止されています。生のメールアドレスをそこに入れると購入がブロックされます。なぜなら、このフィールドが期待しているのは暗号化された値か一方向ハッシュだからです。1つのアカウントに複数のプロファイルが含まれるアプリには、setObfuscatedProfileIdという対となるフィールドが用意されています。
appAccountTokenはAppleのフィールドです。UUIDでなければならず、他の形式は受け付けられません。チェックアウト時に自分のコードで設定し、追加しない限り存在しません。Appleはこれを使ってトランザクションをユーザーに結びつけ、トランザクションと消費情報のペイロードの両方に再び現れます。
obfuscatedAccountIdはGoogle Playのフィールドです。最大64文字のハッシュ化された文字列を受け取り、チェックアウト時に自分のコードで設定します。こちらもデフォルトでは存在しません。Googleはこれを異常な活動の検出に利用し、一部の不正な購入を完了前に阻止するために使用します。
ここで非常に重要な非対称性があります。Googleには一切のバックフィル手段がありません。識別子なしで完了したPlayの購入は永久に匿名のままであり、今後の購入にタグを付けることだけが唯一の対処法です。AppleのSet App Account Tokenエンドポイントは履歴を修復できるため、これは標準的なパターンではなく例外にあたります。
常習者による返金のコストを算出する
返金された売上は目に見える部分であり、同時に小さい方の部分でもあります。返金を承認すると販売価格が戻され、それが帳簿に記録されます。しかし、その行には、顧客が今無償で手にしているものを生み出すために費やしたすべてのコストが含まれていません。
実際の処理を動かす消費型アイテムを考えてみてください。画像の生成、モデルプロバイダーへの一連の呼び出し、動画の書き出し、クリエイターへの支払いなどです。そのコンピュート資源は、使用された時点で購入されています。返金によって販売価格は取り戻されますが、プロバイダーへの請求額はそのまま残ります。商品が返金後も残り続けることを見抜いた人物は、購入、消費、返金というサイクルを単純に繰り返すだけで、その度にあなたに配信コストを再び負わせることになります。
さらに、プラットフォーム側がコストをあなたに転嫁するという側面もあります。2026年8月3日以降、Google Playはその日以降に行われた注文について、購入価格と銀行のchargeback手数料の両方を開発者に課すようになります。これまで大部分がGoogleの負担であった異議申し立てが、あなたの失われた売上に手数料が加わった形に変わり、常習的にchargebackを行う人物は、その試みごとにこの金額をさらに引き上げていきます。識別子フィールドは、24時間の時間枠内にReview Refund APIへ読む価値のある情報を渡すことを可能にするものです。
Googleは、この問題の規模について具体的な数字を示しています。2022年中に20億ドルを超える不正・悪用トランザクションが阻止されたというものです。この数字が成り立つのは、obfuscated account idを含む基盤となる識別信号が実際に入力されていたからです。これらのフィールドを空のまま購入を処理することは、その保護の外に自ら身を置くという選択にほかなりません。
ストアが判断を下す前に、常習的な返金者を察知する
すべての購入に、自分で管理する識別子を付与する
どちらのプラットフォームにも、識別子のない購入を見せるべきではありません。StoreKitの購入にはappAccountTokenを、Play Billingの購入にはsetObfuscatedAccountIdを付与し、どちらの値も自社のユーザーレコードに由来するものとします。Appleはそのアカウントに対応する本物のUUIDを期待し、Googleは個人情報が平文で流れないようにハッシュ化されたアカウントキーを期待します。どちらも、そのタイミングはチェックアウトの瞬間であり、Googleの場合、後からそのタイミングを交渉し直すことはできません。
その識別子をキーにした台帳を維持する
配信、消費イベント、購入、返金のすべてを、その識別子のもとに記録してください。そうすれば、CONSUMPTION_REQUESTやchargeback reviewが発生した際、過去の返金履歴も含めたそのアカウントの全履歴を、1回の問い合わせで取得できるようになります。Appleの消費情報には、まさにこうした情報のための専用フィールドが用意されています。consumptionStatus、deliveryStatus、playTime、accountTenure、lifetimeDollarsPurchased、そして自分自身で設定するrefundPreferenceです。
voidedReasonを振り分けの判断材料として扱う
無効化されたPlayの購入には、原因を説明するvoidedReasonが付与されており、friendly_fraudとfraudは、単なる気が変わったことによる返金とは別に記録されます。これらは、初回の返金が受ける自動処理ではなく、レビューキューとより厳格なポリシーに値します。Googleのガイダンスは、段階的に強化される対応を示しています。最初は警告、繰り返された場合はより厳しい対応、そして続く場合はそのアカウントの購入を無効化する、という流れです。
時間枠を絶対に逃さない
期限後に提出された証拠は、存在しないも同じです。CONSUMPTION_REQUESTへの返信は余裕を持って12時間以内に送信されるよう自動化し、chargeback reviewは24時間以内に行うようにしてください。期限後に提出された完璧なアカウント履歴は、ストアの誰も開くことのない履歴にすぎません。
1つのアカウントが同時に不自然なほど多くのデバイスで取引していることを察知するには、obfuscated account idを読み取るGoogle Playの異常活動検出を活用してください。
このアカウントの過去の返金履歴を確認するには、自社の記録、つまりどちらかのプラットフォームの識別子をキーにした台帳を活用してください。
商品が実際に購入者に届き、使用されたことを確認するには、consumptionStatusとdeliveryStatusが消費情報内に存在するAppleを活用してください。
実際には購入者があなたを欺いている異議申し立てを見抜くには、voidedReasonがfriendly_fraudとして返ってくるGoogle Playを活用してください。
プラットフォームが助けてくれる部分と、そこで止まる部分
責任の分担について正確に理解しておくことには価値があります。ストアが不正利用への対応をすべて行ってくれると思い込みがちですが、ストアがどこで対応を止めるのかはほとんど明示されません。Googleは確かにobfuscated account idを読み取って購入前に一部の不正を阻止しており、プラットフォームレベルのシステムはかなりの量を食い止めています。Appleはすべての返金判断を自身に留保し、あなたの消費情報を投票としてではなく証拠として扱います。どちらのストアも行わないことがあります。それは、あなたに代わって不正利用者のリストを保持すること、返金された消費型アイテムをあなたの残高に戻すこと、常習的な返金者をあなたの代わりに拒否することです。境界線上では、識別子はストアが行動するためのものです。それ以外のすべての場面では、それはあなた自身のものです。
Refund Sensorが同じ識別子を軸に設計されているのも、まさにこの理由によるものです。1つのアカウントに属する返金、chargeback review、消費リクエストは1つの履歴に統合され、繰り返しパターンは4回目の請求がすでに支払われた後ではなく、2回目の発生時点で見えるようになります。
これらのルールが記載されている場所
よくある質問
購入した商品を受け取り、使用した後に繰り返し返金を要求し、利益を得たまま支払いを回収する顧客の行為を指します。アプリストアの文脈では、典型的には1つのアカウントが消費型アイテムやサブスクリプションの返金を何度も繰り返すケース、あるいは正当な決済を銀行経由で異議申し立てする「フレンドリーフラウド」として現れます。
Appleの場合は、UUIDを生成して購入開始時にappAccountTokenとして渡すと、StoreKitがそれを結果として生成されるトランザクションに紐づけ、トランザクションデータと消費データの両方に再び現れます。Googleの場合は、そのアカウントから導出したハッシュ値を使ってsetObfuscatedAccountIdを呼び出します。どちらの方法も、個人情報を一切公開することなく、ストアのトランザクションを自社のユーザーレコードに結びつけることができます。
少なくとも直接的には、どちらも教えてくれません。Googleはobfuscated account idを読み取って異常な活動を特定し、購入前に一部の不正を阻止しますが、Appleは消費リクエスト時に送信されたアカウント履歴を受け取るだけです。どちらの企業からも、常習的な不正利用者の一覧が返ってくることはありません。その一覧を作成するのはあなた自身の役割であり、これらの識別子のもとに記録したデータから構築する必要があります。
obfuscated account idに平文の個人データが含まれていることが通常の原因です。生のメールアドレスのようなものをそこに設定すると、Playは購入を即座にブロックします。代わりに、64文字の上限内で、暗号化された値または一方向ハッシュを指定してください。
止めるというより、減らす効果があります。CONSUMPTION_REQUESTは、あなたの証拠が判断前に届く2つの経路のうちの1つであり、アカウント履歴と配信・消費データを組み合わせることで、Appleが返品の不正利用やフレンドリーフラウドを認識する助けになります。ただし、最終的な判断はAppleが行うため、あなたが異議を申し立てられない経路を通じて発生する不正利用は手つかずのまま残ります。
