ストアの落とし穴 #3：寄付とは呼べない
2026-05-30
Tags: Windows · Microsoft Store · ストアの落とし穴
また別のストアの落とし穴。今回は予想外でした。
何が起きたか
無料の Windows ツールアプリがあります。開発を支援する手段をユーザーに提供したくて、アプリ内アドオンを作成しました——シンプルな "Support the Author" 購入項目です。ストア掲載情報ではスポンサーオプションとし、アプリ内 UI には「開発者にコーヒーをおごってみませんか」と書き、購入は Microsoft Store の IAP システムを通じて処理されるようにしました。
認証結果が戻ってきました：
Status: Attention needed
10.8.2 Third-Party In-Product Purchases
Any developer donations must only be made through a secure third-party purchase processing API. Please use one of those methods or remove any donation options that use the Microsoft API.
待って——アプリ内購入 API で寄付を集めたから却下？
ポリシー原文
Microsoft Store ポリシー 10.8.2 では次のように規定されています：
You must use the Microsoft payment request API or a secure third-party purchase API to receive voluntary donations from users. However, if the user receives digital goods or services in return, including but not limited to additional features or removal of advertising, you must use the Microsoft Store in-product purchase API instead.
意訳：ユーザーからの自発的な寄付を受け取るには、Microsoft 決済リクエスト API または安全なサードパーティ購入 API を使用しなければなりません。ただし、ユーザーが見返りとしてデジタル商品やサービス（追加機能や広告の削除など、これらに限定されない）を受け取る場合は、代わりに Microsoft Store アプリ内購入 API を使用しなければなりません。
ここで 2 つの異なるマイクロソフト API を区別する必要があります：
- Microsoft Payment Request API：一般的な決済リクエストに使用。寄付を受け取ることができる
- Microsoft Store In-Product Purchase API：デジタル商品やサービスのアプリ内購入に使用。寄付の受け取りには使用できない
どの API を使うべきか
【必須】マイクロソフトアプリ内購入 API を使うケース
ユーザーがお金を払い、アプリ内で何らかのデジタルなメリット（以下に限定されない）を得た場合、アプリ内購入 API を使わなければなりません：
- 機能のアンロック：無料版から Pro へのアップグレード、高度なツールのアンロック、VIP 特権の有効化
- 広告の削除：アプリ内広告を永続的または期間限定で削除する課金
- デジタル通貨/アイテム：ゲーム内のコイン、ダイヤ、スキン、またはアプリ内のトークン/ポイント
- サブスクリプションサービス：月額または年額のメンバーシップ
注意：これらを「スポンサー」「チップ」「寄付」と包装しても、ユーザーが支払い後に上記のいずれかのデジタルな変化（VIP 専用バッジの付与、ポップアップの削除など）をトリガーした時点で、マイクロソフトはこれを「デジタル製品の購入」とみなし、アプリ内購入 API を使用しなければなりません。
【絶対に使ってはいけない】マイクロソフトアプリ内購入 API のケース
以下のシナリオでは、アプリ内購入 API を使用すると却下されます：
- 物理商品：服、本、ハードウェアの販売
- 現実世界のサービス：映画チケットの予約、デリバリー、タクシー、ホテルの予約
- 純粋な慈善寄付/リアルマネーギャンブル：適法な慈善団体への募金、または法律で許可されたリアルマネーゲーム
- 純粋な個人的チップ（見返りなし）：ユーザーが純粋にコードを書くのが大変だと思って少額を渡すが、アプリ内に機能や UI の変化がない場合。これらはサードパーティ決済または Payment Request API を使用しなければならない
簡単な判断基準
ユーザーが支払いを完了した後、アプリ内のコードロジック（またはデータベースフィールド）を変更する必要があるか？
- 必要（例：
isProがtrueになる、またはadCountが0になる）→ マイクロソフトアプリ内購入 API を使用 - 不要（コードに全く変化がなく、ユーザーは純粋に応援しているだけ、または商品の配送を待っているだけ）→ サードパーティ決済または Microsoft Payment Request API を使用
今回のケース
私のアドオンは "Support the Author" という名前で、キャッチコピーは「開発者にコーヒーをおごってみませんか」——言葉遣いとしては純粋なチップです。しかし Store アプリ内購入 API を使用しており、ポリシーは純粋なチップにアプリ内購入 API を使用することを明確に禁止しています。
しかし実際には、このアドオン自体がユーザーにサポーターバッジのような変化をもたらすものでした——つまり、すでに一種のデジタル商品です。上記の判断基準によれば、変化がある = デジタル商品であり、デジタル商品にはアプリ内購入 API を使うべきです。つまり、この支払いは理論上、アプリ内購入 API のみで処理すべきであり、Payment Request API やサードパーティ決済は使えません。
したがって、問題は支払い方法ではなく、説明に問題があったのです。"Support the Author" を "Upgrade to Pro" に変更し、「開発者にコーヒーをおごってみませんか」を具体的な見返りを説明するテキストに変更したら、審査に通りました。
まとめ
- マイクロソフトアプリ内購入 API はデジタル商品やサービスの取引にのみ使用できる——ユーザーが支払った後、アプリ内に実質的な変化が必要
- 純粋なチップ（アプリ内に変化がない場合）にはアプリ内購入 API を使用できない——Payment Request API またはサードパーティ決済を使用すること
- 判断基準：ユーザーが支払った後、コード/データベースを変更する必要があるか？変更あり→アプリ内購入 API；変更なし→サードパーティ決済
- 名前と説明は実際の行動と一致させるべき——支払い後に変化がある場合、明確な見返りで説明し、寄付、スポンサー、チップという言葉を避ける
「ストアの落とし穴」シリーズの一部。