App Monetization & Revenue Protection

Apple返金リクエストとは:開発者がアプリの収益を守る方法

Apple返金リクエストがアプリの収益にどのような影響を与えるか、そして開発者が返金を管理し、損失を減らし、収益を守るためにできることを解説します。

5 min read
Apple返金リクエストとは:開発者がアプリの収益を守る方法

開発者がApp Storeの入金額を確認したとき、売上ダッシュボードが約束していた金額より数パーセント少ないことに気づく瞬間には、独特の静けさがあります。誰からもメールは届かず、何も壊れていません。Appleが黙ってあなたに代わって返金を行い、そのまま先へ進んだだけです。

そのギャップは、多くの人が思っているよりも大きなものです。それが実際の金額へとどうつながっていくかについては、 App Storeの返金と収益漏れの記事で取り上げました。今回は実践編です。Apple返金リクエストがシステム内でどのように処理され、収益がどこへ流れ、開発者が実際に何をできるのか、という話です。それは思っている以上に多いものの、ベンダーが謳うほどではありません。

重要なポイント

  • App Storeの返金はすべてAppleが決定します。開発者に拒否権はありませんが、2021年以降は意見を求められるようになり、回答までの時間は約12時間です。

  • 文書化されたApp Store返金ポリシーは簡潔なものですが、実際の運用を決めているのはAppleの判定システムであり、顧客の履歴と開発者から送られた情報を考慮します。

  • 返金は取引全体を取り消すものですが、アクセス権を取り消さなければ、顧客はコンテンツもそのまま保持できてしまいます。

  • 返金の不正利用はリクエスト全体の一部にすぎませんが、消耗型アイテムや繰り返しの利用アカウントに集中しており、開発者が対抗できる部分でもあります。

  • Dipseaは、Appleへの返信を始めただけで返金率を約3分の1削減しました。

Appleの返金プロセスは実際どのように機能するのか

顧客が開発者のもとへ直接来ることはありません。顧客はreportaproblem.apple.comにアクセスし、「返金をリクエスト」を選択し、理由を選んで送信します。 Appleのサポートページでは24〜48時間待つよう案内されており、返金の対象となるかどうかは「国や地域によって異なる場合がある」と記載されています。これはAppleが、EUやオーストラリアなどの消費者法が利用規約に加えて追加の権利を顧客に与えていることを認めているものです。利用規約自体には取引は最終的なものであると記載されていますが、それでも多くのケースで返金が行われています。

その48時間のどこかの時点で、App Store Server Notificationsを設定していれば、Appleは開発者のサーバーにCONSUMPTION_REQUESTを送信し、顧客が購入したものを実際に使用したかどうかを尋ねます。開発者に与えられる時間は12時間です。Appleのエンジニアは 返金対応に関するTech Talkの中で、判定システムは開発者から送られた情報とあわせて「顧客の購入履歴および返金履歴」を考慮すると説明しています。その後、REFUNDまたはREFUND_DECLINEDの通知が届きます。フィールドごとの詳細については、当社の CONSUMPTION_REQUEST解説記事をご覧ください。

これについて多くの人が驚く点が2つあります。Appleは顧客が誰であるかを一切教えてくれず、トランザクションIDのみが提供されます。そして12時間以内に回答しなかった場合、Appleは開発者側の情報が空欄のまま判断を下すことになります。この点についてRevenueCatの記事は、Appleは「デフォルトで返金を承認することが多い」とまとめています。

Apple返金リクエストがアプリの収益に与える影響

直接的なコストは単純です。Appleが取引を取り消すと、開発者の取り分は次回の入金額から差し引かれます。返金率が4パーセントの場合、月に$50,000の売上を上げているアプリは、その返金が妥当だったかどうかを誰も検証しないまま、約$2,000を返還していることになります。

本当に積み重なっていくのは間接的なコストのほうです。コインが使われた後に返金された消耗型アイテムは、商品を提供したにもかかわらず対価を得られなかったことを意味します。REFUND通知を処理しないまま返金されたサブスクリプションは、顧客が残りの期間もアクセスを保持し続けることを意味し、結果として二重に支払ったことになります。Refund Sensorを利用しているアプリ全体で見ると、1件あたりの平均額は$33.31です。これは小さな金額に思えますが、2,870件を掛け合わせると10万ドル近くになります。内側から見ると、まさにそのような感覚です。誰の責任にもならない小さな金額が積み重なっていくのです。

App Storeの返金不正利用はどこに現れるのか

返金リクエストのほとんどは、ごく普通のものです。子どもがジェムを購入してしまった、トライアルの解約を忘れていた、古いiPadでアプリがクラッシュした、といったケースです。Appleがそう扱っているように、これらはカスタマーサービスの一環として対応すべきです。

不正利用は全体の中では小さな割合ですが、その形にはわかりやすい特徴があります。消耗型アイテムを購入し、1日以内に使用して返金する、同じアカウントが複数のアプリで同じことを繰り返す、毎月期間の最終日にサブスクリプションを返金する、といったパターンです。Appleはどの開発者よりも多くこうしたケースを目にしています。Appleの 2026年不正利用レポートによると、2025年には潜在的な不正取引として$2.2 billionをブロックし、不正・悪用を理由に40.4 million件の顧客アカウントを停止したとされています。返金の不正利用はそのさらに小さな部類であり、開発者のもとまですり抜けてくる部分です。

これに対してできることは、期待されているよりも限られています。顧客がリクエストすること自体を止めることはできません。しかし、コインが使用済みであることをAppleに伝えることはでき、これがまさに消費リクエストの目的です。また、返金が承認された際にコンテンツが実際に削除されるようにすることもできます。ジェムを保持したままの不正利用者は、同じことを繰り返すからです。多くのアプリでは、この部分がそもそも実装されていません。

12時間以内に開発者ができること

その多くは、ただ回答することに尽きます。サブスクリプション型の音声アプリであるDipseaは、2024年後半に消費リクエストへの返信を開始し、約2週間で返金率が3パーセントから1.9パーセントへと下がりました。Appleに何かを拒否するよう求めたわけではありません。フォームを空欄のままにするのをやめただけです。

多くのアプリを観察してきた中で得たいくつかの気づきがあります。購入時にappAccountTokenを付与しておかないと、Appleが指定するトランザクションを自社データベース内のユーザーと紐づけることができません。利用状況データの共有に関する同意は利用規約に盛り込んでおく必要があります。Appleは、同意なしには何も送信しないよう求めているためです。返金の希望は正直に送信してください。Appleはそれをあくまで「希望」として扱うため、明らかな引き延ばしと判断されれば覆されます。そして、すべてのリクエストをタイムスタンプ付きで記録してください。見逃してしまうリクエストは、決まって土曜日の午前3時に届くものです。

次に、その上流にも目を向けましょう。Appleの理由リストにはUNINTENDED_PURCHASEやUNSATISFIED_WITH_PURCHASEが含まれており、いずれも返金の問題である以前にプロダクトの問題です。トライアルが本契約に切り替わる前日のリマインダー、価格をメリットと同じ大きさで表示するペイウォール、子ども向けゲームにおける消耗型アイテムの確認ステップ。こうした一つひとつの施策が、リクエストが発生する前にそれを取り除いてくれます。それは、リクエストに勝つことよりも優れた対策です。

App Store返金管理ソフトウェアは必要か

これは自社で構築することも可能です。通知を受け取るエンドポイント、トランザクションIDからユーザーを検索する仕組み、Appleのconsumptionエンドポイントへのリクエスト送信、そして8時間放置されたものがあれば警告を出すジョブ。腕の良いバックエンド開発者であれば1週間で構築できますが、その後はずっとそれを保守し続けることになり、それこそが本当のコストです。

すでにRevenueCatやAdaptyを利用しているのであれば、どちらもSDKが収集する利用状況データを使って消費リクエストに回答してくれます。もともとアプリにSDKを組み込んでいるのであれば、それは妥当なデフォルトの選択肢です。

Refund Sensorは、単独で利用できる選択肢です。App Store Connect APIキーと通知用URLを接続するだけでSDKは不要で、AppleとGoogleの両方を1か所でカバーします。800を超えるアプリにおいて、対象となるリクエストの77パーセントを防御してきた実績があります。料金は定額制で、無料プランのほか、月額$39.99または$79.99のプランがあり、回収額からの手数料は一切かかりません。導入の詳細は Apple返金防御ページをご覧ください。

ここで一つ、当社を含むすべてのツールに当てはまる注意点があります。App Store収益保護ソフトウェアとして販売されているものは、返金そのものを防ぐことはできず、Appleの判断を思い通りに変えることもできません。それが実現するのは、毎回、期限内に、正確なデータとともに、Appleに開発者の声を確実に届けることです。それが実際には大きな価値を持つのであり、これらのツールが行っていることのすべてです。

まとめ

Apple返金リクエストがなくなることはなく、開発者に拒否権もありません。2021年に変わったのは、Appleが意見を求めるようになったことですが、いまだに多くの開発者が回答していません。Appleの返金プロセスは、12時間以内にAppleへ届いた情報によって動いており、空欄のフォームは顧客の主張に負けてしまいます。

したがって、収益は次の順序で守ってください。まずリクエストに回答し、返金時にはアクセスを取り消して不正利用が割に合わないようにし、そのうえでリクエストの発生源となっているペイウォールやトライアルのフローを改善します。その回答作業を自社で構築するか、サブスクリプションプラットフォームに任せるか、専用ツールに委ねるかは、実際に行うこと自体に比べれば重要ではありません。

よくある質問

いいえ。決定を下すのはAppleです。12時間以内に消費データと返金の希望を送信することはできますが、Appleはそれを考慮した上で、開発者の意向を覆すことができますし、実際にそうすることもあります。

Appleは顧客に24〜48時間待つよう案内しています。開発者側の対応期限はCONSUMPTION_REQUESTを受け取ってから12時間で、これは通常その期間の早い段階で届きます。

ほとんど教えてくれません。REFUND通知にはrevocationReasonが含まれますが、これは「app issue」か「other」のいずれかです。リクエスト自体には顧客が選択した理由が含まれており、こちらの方が有用です。

意図的に購入・消費・返金を行うことで、通常は消耗型アイテムが対象となり、複数のアプリにまたがって繰り返されることもよくあります。Appleの判定システムはすでに返金履歴を考慮しているため、開発者の役割は消費を確認し、返金が確定した際にアクセスを取り消すことです。

消費リクエストに12時間以内に手動で確実に対応できない場合にのみ必要です。週に数件程度のリクエストであればチェックリストで対応できるかもしれません。それ以上の場合は、自社コード、サブスクリプションプラットフォーム、専用ツールのいずれであれ、自動化することをおすすめします。

#Apple Refund Requests#App Revenue Protection#Apple App Store#App Store Refunds#iOS App Developers#App Monetization
Refund SensorRefund Sensor TeamRefund defense for App Store and Google Play developers