Apple の DeviceCheck は、返金悪用者が新しいアカウントで登録し直しても、その背後にある端末を覚えている

アカウントを停止しても、同じ端末で登録し直す返金悪用者は止められません。Apple の DeviceCheck と Google Play のデバイスリコール（device recall）は、まさにその隙間を埋めるために存在します。どちらも、自社で意味を決めた数ビットをサーバーから物理端末に紐付け、ストアのサーバーに保存できます。そのため、背後の人物が新しいメールアドレスで戻ってきても、フラグは残っています。どちらのツールも端末 ID は渡してくれず、返金を止めることもできません。できるのは、登録時やペイウォールで、この端末が以前に損害を与えたことを知らせることです。

ここでは、各ストアが実際に何を保存するのか、フラグを設定できるかどうかを左右するタイミングの落とし穴、そして気付くまでに常習的な悪用者がどれだけのコストを生むのかを説明します。

新しいアカウントがアカウント単位の防御をすべてすり抜ける理由

返金対策の多くはアカウントをキーにしています。Apple の appAccountToken は取引を自社データベースのユーザーに紐付けます。Google Play の難読化アカウント ID は Android で同じ役割を果たします。どちらもすべての購入で設定すべきものですが、表しているのは人のアカウントであって、手元のハードウェアではありません。アカウントを削除し、新しいメールで登録すれば、その人物の履歴はゼロからやり直しになります。

ストアはこの隙間を埋めてくれません。App Store の返金通知が伝えるのは、どの取引が返金されたかです。Google Play の無効化された購入が伝えるのは、購入トークン、注文 ID、voidedReason です。どれにも端末識別子は含まれません。あるマッチングアプリの開発者は Apple Developer Forums のスレッドでその結果を報告しています。詐欺プロフィールがプレミアム会員を購入しては返金を受けることを繰り返し、開発者独自の方法で端末を停止しても効果がなかったというものです。

新しいアカウントでストア自体のトライアルはリセットされるか

同じ Apple アカウントであればリセットされません。Apple のドキュメントによれば、無料トライアルを含むお試しオファーは、その製品または同じサブスクリプショングループ内のいずれの製品でもまだ受け取っていない顧客が対象です。したがって、アプリ内で別のログインを使っても Apple のトライアルが再び得られるわけではありません。新しい Apple アカウントなら得られます。自社で配布するものも同様です。登録クレジット、サーバー負担のトライアル、紹介ボーナスなどです。これらこそ端末フラグが守る特典です。

Apple の DeviceCheck が実際に保存するもの

DeviceCheck は 2 つの部分から成ります。アプリ側では、DCDevice クラスが端末を識別する一時トークンを生成します。サーバー側では、そのトークンを、デベロッパーアカウントの鍵で署名した JSON Web Token とともに Apple に送信します。すると Apple はその端末の 2 つのビットを照会または更新させてくれます。照会のレスポンスは bit0、bit1、last_update_time を返し、last_update_time は年と月で示されます。Apple 自身が挙げる用途例は、すでにプロモーションオファーを利用した端末と、不正と判断した端末です。

ビットは Apple が保持しますが、意味を決めるのは自社です。ドキュメントには、ビットの意味を管理し、いつリセットするかを判断するのは開発者の責任だと書かれており、例として端末の売却が挙げられています。2 ビットで 4 つの状態を表せるので、シンプルな方式としては、1 ビットを大量使用後の返金に、もう 1 ビットを無料クレジット受領済みに割り当てます。

• トークンは一回限りです。Apple はリクエストを再試行できる程度の時間は有効だとしていますが、呼び出しごとに新しいトークンを生成すべきです。
• 開発ビルドは api.development.devicecheck.apple.com と通信します。本番環境では api.devicecheck.apple.com を使う必要があり、そうしないとフラグが誤った場所に書き込まれます。
• Apple は DeviceCheck を、結論ではなく総合的なリスク評価の入力の一つと位置付けています。ビットが立っていることは、詳しく調べる理由として扱ってください。

Google のデバイスリコールが Android で加えるもの

Google 版は Play Integrity API の中にあり、まだベータ段階で、関心表明フォームからの申請が必要です。承認され、Play Console で有効にすると、すべての完全性判定に端末の 3 つのカスタムビットが付きます。書き込みは、検証済みの完全性トークンを使って、サーバーから deviceRecall:write エンドポイントを呼び出して行います。Google によれば、データは Google のサーバーにあるため、アプリの再インストールや端末のリセット後も残ります。

Google のドキュメントは用途について珍しく率直です。深刻な悪用の証拠がある端末、無料トライアルなどの高価値アイテムをすでに引き換えた端末、悪用目的で新しいアカウントの作成に繰り返し使われる端末が挙げられています。制限についても同様に率直です。デバイスリコールはアプリのセキュリティ保護と、悪用、不正行為、不正アクセスへの対策にのみ使用でき、個々のユーザーのフィンガープリンティングや追跡には決して使えず、年齢、性別、位置情報などの機密属性を保存することもできません。

タイミングの問題：返金が届く頃にはトークンがない

どちらのツールも、端末にフラグを付ける前に端末自体から何かを受け取る必要があります。Apple には新しい DCDevice トークンが必要です。Google には、その端末から得た 14 日以内の完全性トークンが必要です。一方で返金は、端末について何も知らないストア通知を通じてサーバーに届きます。つまり問題は端末にフラグを付けるかどうかではありません。返金が届いたときに、その端末にまだ到達する手段があるかどうかです。

Google の 48 時間返金は 14 日間の範囲に収まる

Google Play のセルフサービス返金は購入から 48 時間以内しか利用できず、完全性トークンを書き込みに使える 14 日間に十分収まります。購入時に完全性チェックを実行し、検証済みトークンを注文 ID とともに保存しておけば、その注文の無効化された購入が届いた時点ですぐにビットを書き込めます。難しいのはチャージバックです。銀行の異議申し立ては 14 日目をはるかに過ぎてから届くことがあります。

Apple の返金は端末が戻ってくるのを待つ必要がある

Apple の返金は購入から数週間後に届くことがあり、保存した DeviceCheck トークンは再利用を前提としていません。現実的な答えは、まずアカウントに、次に端末に印を付けることです。返金通知が届いたら、データベースでそのアカウントにフラグを付けます。そのアカウントが次にアプリを開いたときに DeviceCheck トークンを要求し、ビットを設定します。返金後もコンテンツを手元に残す悪用者は、たいてい実際に戻ってきます。使うことが目的だったからです。

• 購入時に、appAccountToken または難読化アカウント ID を通じて、取引を自社アカウントに記録します。
• 返金または無効化が発生したら、サーバーでそのアカウントにフラグを付けます。
• フラグ付きアカウントの次のセッションで、端末トークンを取得してビットを設定します。
• すべての登録時に、費用が発生するものを付与する前にビットを照会します。

常習的な返金悪用者がもたらすコスト

返金額は目に見える部分にすぎません。残りは、その購入がすでに動かしたすべてです。アプリが販売物を提供するのに費用がかかる場合、購入、消費、返金のサイクルを繰り返すたびにその費用は使われたままになります。画像生成の GPU 時間、モデルやデータ API への有料呼び出し、顧客が保持するエクスポートのストレージ、売上に基づいて計算されたクリエイターへの支払いなどです。新しいアカウントはこのループを再開し、帳簿にはまったく新しい顧客として記録されます。

無料の特典も、返金がまったくなくても同じように漏れていきます。10 個のアカウントで登録クレジットを荒稼ぎする端末は、1 回のトライアルに想定した計算資源の 10 倍を消費します。Google Play では、2026年8月3日以降の注文に対するチャージバックで、Google のサービス手数料を差し引いた購入価格に加えて銀行手数料も負担することになります。そのため、毎回新しいアカウントから異議申し立てをする人物は、そのたびに異議申し立ての全コストを発生させます。

フラグ付き端末への対応

フラグが答えるのは一つの問いだけです。この端末にもう一度何かを無料で与えるべきか。対応は釣り合いの取れたものにしてください。ビットが立っていることは証拠であって、証明ではないからです。スマートフォンは転売され、家族は iPad を共有します。Google もまさにその理由から、古いデータを無視またはリセットすることを検討するよう明示しています。

• フラグ付き端末では、登録クレジット、サーバー負担のトライアル、紹介ボーナスを提供せず、代わりに有料プランを案内します。
• フラグ付き端末にはプロモーションオファーの署名を行わないでください。App Store では、プロモーションオファーを有効にする署名は自社サーバーが生成するため、判断は自社に委ねられています。
• フラグ付き端末に高額な消耗型アイテムを提供する前に、支払いの確定を求めます。
• タイムスタンプを活用します。先月設定されたフラグは、2 年前に設定されたものより重みがあります。
• サポートへの連絡手段を用意します。中古端末を購入して誤ってフラグを付けられた人には回答を返すべきで、ビットはリセットできます。

端末をそのまま締め出してもよいか

自社の無料特典を断ることはできますし、そこが端末フラグの効果が出るところです。完全な締め出しはリスクが高くなります。今その端末を持っている人が、悪用した本人とは限りません。また Google 自身の規約は、デバイスリコールの用途を悪用防止に限定しており、人の追跡は認めていません。費用がかかるものを制限し、有料の経路は開けたままにしてください。

Keychain（キーチェーン）や端末識別子はどうか

開発者からは、Keychain のマーカーやハードウェア ID で同じことができないかという質問がよく寄せられます。アプリが端末に保存したマーカーは端末をリセットすると消えますし、Apple はこの目的でアプリに安定したハードウェア識別子を提供していません。DeviceCheck とデバイスリコールがストア公認の答えであるのは、まさにビットが端末ではなく Apple と Google のサーバーにあるからです。

それでもストアが判断するもの

端末フラグが変えるのは、アプリが次に何を提供するかです。目の前の返金には影響しません。ストアが判断する前に証拠を提出できる返金フローは 2 つだけです。Apple は CONSUMPTION_REQUEST を送信し、12 時間以内に消費データを求めます。Google Play はチャージバック審査を開始し、開発者は 24 時間以内に orders.reviewrefund で応答します。それ以外のすべて、つまり Google Play の 48 時間返金からサポート経由の返金、未承認購入の自動返金までは、開発者の関与なしに判断されます。チャージバックは銀行が裁定した時点で確定します。

RefundHalt は、すべての CONSUMPTION_REQUEST と Google Play のチャージバック審査に、期限内に実際の利用データで応答します。さらに各返金を、それを行ったアカウントに紐付けるため、サーバーは次回のチェックイン時にどの端末にフラグを付けるべきかを把握できます。