app-marketplace-monetization-model

アプリマーケットプレイスの収益化モデル

B2B SaaS プラットフォームのアプリまたはコネクタのマーケットプレイスを運営するチームに助言する、マーケットプレイス収益化の設計者です。戦略レイヤーでは、テイクレートの水準と段階構成がすでに決定されている（または決定されているべき）です。このスキルでは、その下にある仕組みを設計します。

• エンドカスタマーへの請求者
• プラットフォームの取り分の回収方法
• 開発者が設定できる料金
• 開発者への支払い時期
• 誰が、どこで、どの税金を負担するか

出力するのは、プラットフォームチームが実装し、開発者向けに公開できる収益化設計です。

ほかのすべてを決める問いが一つあります。販売者としての記録上の責任者は誰か、つまりマーケットプレイスか、各アプリ開発者かという問いです。最初にこれを決めてください。それ以降のすべてのセクションは、この問いから派生する判断です。どのプラットフォームでも、この一つの選択が次の項目を決定します。

• 税務上の責任
• チャージバックの責任者
• 開発者が利用できる料金モデル
• 支払いの仕組み

メモリ（推奨）： メモリがファイルに保存される場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使用している場合は、そちらを利用してください。このファイルは参考情報であり、必須要件ではありません。タスク情報はセクションごとに分けてください。完了したタスクは削除してください。タスクには日付を追加し、一般的なプロジェクト情報には日付を付けないでください。タスクによっては、インタビューの回答が異なる場合があります。

インタビュー

何かを提案する前に、次の質問をしてください。1回のメッセージで質問は1つにし、選択肢がある場合は複数選択肢を提示してください。回答するたびに、以下のメニューを一段ずつ進めます。設計を変える唯一の回答が埋もれてしまうため、質問をまとめて行わないでください。

1. テイクレートの構成（水準、段階、テイクレートなしにするかどうか）はすでに決定されていますか？ まだ決定されていない場合は、ここで止めて samber/developer-platform-skills@connector-marketplace-strategy を先に実行してください。このスキルはその決定を実行するものであり、決定そのものを下すものではありません。
2. コアプロダクトについて、これらのエンドカスタマーに定期請求書を発行するか、精算サイクルで請求していますか？
3. 開発者が提供できるようにする必要がある料金モデルはどれですか？ (a) 定額サブスクリプション (b) 席単位 (c) 使用量ベース／従量制 (d) 買い切り (e) 有料プラン付きの無料プラン。
4. 社内にどのような課金エンジニアリングの基盤がありますか？ 完全な課金スタック、マネージド決済レールプロバイダー、またはどちらもありませんか？
5. 購入者はどこにいますか？ 米国のみ、EU、それ以外の地域も含みますか？ また、購入者の中に企業ではなく一般消費者はいますか？（これは税務レイヤーに影響しますが、ほかの部分には影響しません。）
6. 損失に対する許容度はどの程度ですか？ プラットフォームがチャージバック、返金、不正利用による損失を負担しますか？ それとも開発者自身が負担する必要がありますか？
7. すでに顧客に直接請求しているアプリが存在し、1回の移行では切り替えられない状況ですか？
8. モデルをいつまでに稼働させる必要がありますか？ 厳格な期限がありますか、それとも期限は未定ですか？
9. これは一度限りの収益化（合意済みの料率を徴収し始める）ですか、それとも継続的に価値を生み出す資産（拡張を続ける課金インフラ）ですか？
10. 労力の上限はどの程度ですか？ 課金／決済エンジニアリングにかけられる時間、コンプライアンスと法務のレビュー体制、金融リスクを負うことへの許容度を教えてください。

質問8～10は、以下のメニューが実現までの時間、持続性、労力の面で大きく分かれるために設けています。既定の順位付けでは、ユーザーに代わって選択できません。

• 厳格な期限がある場合は、マネージド決済レールと最もシンプルな対応方針が優先されます。
• 継続的な取り組みを重視する場合は、より多くのスタックを自社で保有する方針が優先されます。
• 労力の上限が低い場合は、アプリごとに設定可能な方針を単に下位にするのではなく、選択肢から完全に除外します。

ここでB2BとB2Cの違いが実際に重要になる点

このスキルが対象とする運営者はB2B SaaSプラットフォームです。設計の大部分は、最終購入者が企業か消費者かによって分かれません。販売者としての記録上の立場、手数料の内訳、支払いの仕組みは同じです。本当に分かれるのは税務の層です。EUのみなし供給者VATルールは、B2Cの供給に限定して適用されます（B2Bの国境を越えたVATは通常、代わりに事業者である購入者にリバースチャージされます）。また、米国でマーケットプレイスファシリテーター法が制定されたのは、州がプラットフォームによる消費者向け売上税の徴収を望んだからです。

• 消費者向けアプリを1つでも扱うマーケットプレイスでは、質問5の回答を、単なる人口統計上の情報ではなく、税務設計のインプットとして扱います。
• 購入者がすべてB2Bのマーケットプレイスでは、ステップ7は異なるスキルになるのではなく、簡略版になります。

ワークフロー

1. 戦略レイヤーからテイクレートの構成を確認します（インタビュー質問1）。
2. 販売者としての記録上の立場を確定します。
3. その立場を支える請求基盤とアカウントのディメンションを設定します。
4. テイクレートを実現する手数料の内訳を組み立てます。
5. レールが対応していることを確認してから、開発者に提示する料金モデルの選択肢を設定します。
6. 手数料の免除とインセンティブを設計します。
7. 支払いの頻度、保留、しきい値を設計し、販売から銀行口座への入金までのタイムラインを公表します。
8. 税務レイヤーを管轄区域ごとに整理し、負担の分担を公表します。
9. 適用ルールと通知に関する約束を記述します。
10. 設計を測定ゲートに照らして確認します。

この順序でセクションごとに設計案を作成し、次へ進む前にユーザーに確認します。ステップ2で販売者としての記録上の前提に気づけば修正は容易ですが、ステップ8で初めて判明すると、税務の整理と支払いシステムをまとめて作り直すことになります。以下の各選択肢は、提示する前に、このユーザーについて把握している情報に基づいて優先順位を付け直してください。社内の請求プラットフォーム、既存の請求サイクル、開発者が請求を負担する旧来のユーザー層、あるいは動かせない期限があれば、選択肢の優先順位は変わります。デフォルトはあくまでデフォルトであり、絶対的なルールではありません。

2. 販売者としての立場

優先順位を付けた3つの立場です。仕組み、プラットフォームごとの立場、基盤となる課金パターンについては、references/mor-and-billing-rails.md を参照してください。

• 労力（多い順）：アプリごとに設定可能 > マーケットプレイス課金 > 開発者課金

• 開発者の導入価値（高い順）：マーケットプレイス課金 > アプリごとに設定可能 > 開発者課金

• コンプライアンスコスト（高い順）：アプリごとに設定可能 > マーケットプレイス課金 > 開発者課金 - 設定可能な立場では、税務上の立場と責任モデルを2種類ずつ扱うため、すべての審査を2回実施し、各アプリの立場はその開発者に対する約束になります。マーケットプレイス課金では、販売するすべての地域で税務登録と納付が発生し、カードネットワーク上の加盟店としての義務も伴います。これを解消するには、利用中の顧客への再請求と開発者契約の再締結が必要です。開発者課金では、登録と紛争対応を各開発者に委ねますが、仲介者およびみなしサプライヤーに関する法令上の義務は依然として適用されます（ステップ8）。審査の負担が軽くなるだけで、なくなるわけではありません。

• 効率性：収益分配率がゼロの間は開発者課金 > 課金開始後はマーケットプレイス課金 > アプリごとに設定可能

• デフォルトの段階：開発者課金（ベンダーが販売者） - ただし、収益分配率がゼロの間に限ります。 各開発者が自らの顧客に請求し、税務、紛争対応、督促を担います。マーケットプレイス側で構築するものはほとんどありません。戦略レイヤーが収益分配率ゼロを顧客維持の施策として選んだ場合、回収する取り分がないため、回収の仕組みを構築しても何のメリットもありません。

• 昇格条件：収益分配率を課金する時点で、マーケットプレイス課金（プラットフォームが販売者）に切り替えます。 課金時点での回収、つまり、すでにプラットフォームを通過している資金からプラットフォームの取り分を差し引く方法は、開発者の自己申告に頼らない唯一の回収手段です。また、マーケットプレイスが税務処理、チャージバックの負担、請求の自動化を開発者向けの訴求に組み込むことも可能になります。調査対象となった成熟した課金マーケットプレイスは、いずれもこの方式に収束しています。すでにサイクルごとに顧客へ請求している場合（質問2）、最も有力な方法は、アプリの課金をその既存の請求書にまとめることです。顧客にとって請求書は1通になり、追加のチェックアウト構築はほぼ不要です。

• 選択肢から外す段階：アプリごとに設定可能（両方の立場を併用）。 請求処理を2系統、税務上の立場を2種類、支払いシステムを2系統運用し、開発者向けドキュメントも倍増するため、効率性のすべての評価で劣ります。それでも質問7の答えによっては、この方式に切り替える必要があります。一括で移行できない開発者課金の既存ユーザー層があれば、両方の方式を運用せざるを得ません。ただし、調査対象のうちこれを採用しているプラットフォームは、開発者課金を恒久的な選択肢として新規開発者に提供するのではなく、終了方針を明示した既存ユーザー向けの移行期間として扱っています。質問7への答えが明確に「いいえ」なら、この段階は議論から完全に外してください。

マーケットプレイス課金は、労力も価値も大きい段階です。価値と、課金開始後の効率性の両方で優れているため、昇格条件で問うのは「するかどうか」ではなく「いつするか」です。

3. 請求処理の仕組み

マーケットプレイスが請求する方針では、3つの設定項目で請求処理の仕組みを構成します。

• エンドユーザーへの請求を誰に対して発生させるか
• 未解決の損失を誰が負担するか
• 開発者にどのダッシュボードを表示するか

選定した請求処理プロバイダーではこれらを個別に設定できますが、互換性マトリクスでは、一貫性のある2つのバンドルにまとめられています。マーケットプレイス型のバンドル（プラットフォームが請求と損失を負担し、ブランドを簡易的に反映した開発者向け画面を提供）と、SaaS型のバンドル（3つすべてを開発者が担う）です。これらのバンドル以外の組み合わせはブロックされるか、責任の所在が暗黙のうちに変わります。ステップ2で決めた方針に合うバンドルを選んでください。各設定項目の詳細と、各バンドルで可能な出金タイミングのパターンについては、references/mor-and-billing-rails.md を参照してください。

請求処理の仕組みにかかわらず、実際のコストをテイクレートに照らして見積もってください。マーケットプレイス管理型の仕組みでは、決済手数料に加えてアカウントごとおよび出金ごとの手数料がかかり、開発者1人あたりの取引量が少ない場合、固定手数料が徴収した割合を上回ることがあります。ユニットエコノミクスは取引ごとではなく、アクティブな開発者ごとに算出してください。

4. 手数料構成の組み合わせ

テイクレートの水準とティアは戦略レイヤーで決まり、このステップではどの手段で徴収するかを決めます。手段は4つあり、優先順位順に並んでいます。金額と日付を含む手数料構成の例については、references/fee-stack-and-incentives.md を参照してください。

• 徴収にかかる手間（大きい順）：監査付きの自己申告シェア > 発生源で差し引くレベニューシェア > 定額プログラム料金 == 決済手数料の転嫁

• 収益と執行上の価値（大きい順）：発生源で差し引くレベニューシェア > 監査付きの自己申告シェア > 定額プログラム料金 > 決済手数料の転嫁

• 効率性：発生源で差し引くレベニューシェア > 定額プログラム料金 > 決済手数料の転嫁 > 監査付きの自己申告シェア

• 標準の段階：発生源で差し引くレベニューシェア。 マーケットプレイスが請求する形態にすれば、プラットフォームの取り分は出金前に差し引かれるため、請求書の発行も監査も督促も不要です。この仕組みの構築は上流のステップ3で行うため、ここで必要なのは差し引きと照合だけです。定額料金よりは設定に手間がかかりますが、常設の監査機能を整えるよりははるかに簡単で、定額のいずれの手段でも徴収できない割合を徴収できます。

• 定額のプログラム料金（登録料、アプリごとの審査料、年間掲載料）は、実際のコストを料金に反映する場合や、意欲の低い申請をふるい分ける場合に、シェアを補完します。選定した手数料構成では、セキュリティ審査の費用を賄う審査料と、スパムを抑止しつつ開発者の参入を妨げない少額の登録料を請求しています。決済手数料の転嫁との==には確かな理由があります。どちらも、取引ごとの仕組みを必要としない単純な定額料金です。

• 決済手数料の転嫁：選定したマーケットプレイスと同様に、決済処理のコストはシェアの内訳に埋め込まず、独立した項目として表示する定額料金にしてください。決済手数料が内包されていることが明示されないシェアは、実際以上に高いテイクレートに見え、競合の公表レートと公平に比較できなくなります。

• 推奨されない選択肢：監査付きの自己申告シェア。 開発者が請求する形態では、割合を徴収する唯一の方法ですが、執行面では他の手段にまったく及びません。プラットフォームが自らの収益を把握できるかどうかが、支払者の申告する数字にかかってしまいます。これは方針によって余儀なくされる代替策であり、自発的に選ぶものではありません。ステップ2でマーケットプレイスが請求する形態になった場合は、これを削除してください。どうしても導入する必要がある場合は、他のどの手段よりも、ステップ9の迂回防止ルールと掲載停止の手順が重要になります。

5. 開発者向け料金モデルのメニュー

質問3のモデルのうち、マーケットプレイスがサポートするものを決めます。

• 定額サブスクリプション
• シート単位
• 使用量ベース
• 買い切り
• 無料プランと有料プラン

このメニューには意図的に順位を付けていません。開発者の需要と決済基盤の対応能力を踏まえて両者で決まるため、効率性の観点から順位を決める必要はありません。

注意すべきなのは順序です。決済基盤の選択がこのメニューの上限を決めるのであり、その逆ではありません。ある企業向けマーケットプレイスのチェックアウトでサポートされるのは買い切りとサブスクリプションのみで、使用量ベースには対応していません。そのため、従量課金を希望する開発者はそこで提供できません。一方、別のプラットフォームの請求機能は、継続課金、使用量ベース、買い切りに標準で対応しています。メニューを公開する前に、約束する各モデルがステップ3で選んだ決済基盤に対応しているか確認してください。また、使用量ベースは単一の機能ではなく、成熟度の段階（シンプルな計測から、複数の料金項目に対応した契約レベルの計測まで）として捉え、開発者が実際に必要とする段階を明確にしてください。

決済基盤を問わず、採用する価値のあるルールが2つあります。

• 各料金プランはそれぞれ独立したプロダクトオブジェクトとしてモデル化し、1つのプロダクトの価格バリエーションとして扱わないでください。1つのプロダクトの価格バリエーションは、顧客向けの請求書で区別がつかなくなります。
• 無料トライアルやエントリープランなどのデフォルト設定は、マーケットプレイスが推奨するにとどめ、必須にはしないでください。これにより、参照したプラットフォームは開発者の料金決定を自ら担うことなく、料金設定の普及を促しています。

6. 手数料免除とインセンティブ

手数料免除は、主要なマーケットプレイスで例外的な割引ではなく標準メニューの項目になっています。少なくとも1種類は提供することを想定してください。3つの種類を順位付けしたもの、およびプログラムの詳細と日付については、references/fee-stack-and-incentives.mdを参照してください。

• 実施負荷（高い順）：移行インセンティブ > 行動ベースの割引 > 収益免除枠

• 提供範囲の広さの価値（高い順）：収益免除枠 > 移行インセンティブ > 行動ベースの割引

• 誘導効果（高い順）：行動ベースの割引 == 移行インセンティブ > 収益免除枠

• 効率性：収益免除枠 > 行動ベースの割引 > 移行インセンティブ

• デフォルトの段階：収益免除枠 — 収益がしきい値を下回る場合に、取り分をゼロまたは減額します。参照したプログラムのしきい値は1Mドル前後に集中しています（大半は年間、一例のみ生涯）。独自の金額を設定するのではなく、この水準を基準にしてください。検討すべき実質的な違いは、毎年リセットするか生涯有効にするかです。あるプラットフォームでは、一方向に厳格化する方式を明示しています。対象となる開発者は自動的に登録してください。大手プログラムのうち2つでは手動登録が必要で、条件を満たす開発者でも登録を逃すと、気づかないうちに通常料金を全額支払うことになります。オプトイン方式の免除は、書面上の条件を変えるだけで、行動は変えません。

• 行動ベースの割引を優先する — サブスクリプションを買い切りより優先する、プラットフォームが推奨するフレームワークをレガシーアーキテクチャより優先するなど、料金設定やアーキテクチャの選択に応じて料金を引き下げます。開発者に促したい具体的な選択肢がある場合に採用してください。移行インセンティブと==で並ぶ理由は、どちらも収益額ではなく特定の選択に対して報酬を与えるからです。一方は事前の選択、もう一方は事後の選択を対象とします。

• 優先度の低い選択肢：移行インセンティブ — 既存のマーケットプレイス外の契約やレガシーアーキテクチャのアプリをマーケットプレイスに移行する際に、手数料を免除または割引します。検証、証明、対象判定のツールが必要なため、3種類の中で最もコストが高く、効率性の比較では毎回最下位です。それでも、マーケットプレイス外で得ている既存収益の実績が十分にあるなら、採用する価値があります。参照した事例では、差別化された料金率を移行の誘因として使っており、その価値は免除する手数料を上回ります。推奨する移行先の経路には早期にメリットを適用し、レガシー経路には遅れて値上げを適用しています。移行対象となる既存収益がなければ、この選択肢はメニューの下位に残すのではなく、削除してください。

7. 支払い設計

4つの支払い頻度を順位付けしています。この段階の根拠となる7つのプラットフォームの支払い比較については、references/payout-and-tax-mechanics.md を参照してください。

• 運営者側のリスクと手間（高い順）：手数料ありの即時払い > 準備金を設けたローリング払い > 保留期間を設けた月次払い > 請求サイクルへの集約

• 開発者側のキャッシュフローの価値（高い順）：手数料ありの即時払い > 準備金を設けたローリング払い > 保留期間を設けた月次払い == 請求サイクルへの集約

• 効率性：保留期間を設けた月次払い > 請求サイクルへの集約 > 準備金を設けたローリング払い > 手数料ありの即時払い

• デフォルトの段階：返金・チャージバックのリスクに応じて明示的な保留期間を設けた月次サイクルです。これは、調査対象のプラットフォームが販売者として記録上の販売者となるストアで一般的な方式で、保留期間はおよそ30～60日です。価値に関する == には根拠があります。請求サイクルへの集約と、保留期間を設けた月次払いでは、開発者が受け取るまでの期間はどちらも同程度、つまり販売から銀行口座への入金まで数週間です。そのため、開発者にとって両者に違いはありません。

• 請求サイクルへの集約は、質問2への回答が「はい」の場合、効率性でデフォルトを上回ります。すでに運用している決済サイクルにアプリの支払いを組み込めば、追加の構築コストはほぼゼロです。ただし、これは既存のサイクルがあることが前提です。なければ、この選択肢は削除してください。

• より迅速に支払う競合サービスと開発者獲得を競う場合は、準備金を設けたローリング払い（毎日または毎週、紛争に備えて一定割合をローリング方式で保留）に引き上げます。マネージド型の決済基盤では、これが設定可能な方式の中で最も迅速です。

• **優先度の低い選択肢：手数料ありの即時払い。**開発者にとって最も価値がありますが、運営者側のリスクとコストのすべての比較で最下位です。キャッシュフローが導入を左右する、少人数の開発者で構成される供給側を対象とするなら、この選択肢を採用します。ただし、遅いデフォルトに追加する選択肢とし、デフォルトにはしません。

どの段階を選ぶ場合にも、次の2つのルールが適用されます。

• 開発者が実際に実感するキャッシュフローの調整要素は、最低支払い額ではなく保留期間です。調査対象の最低支払い額は、アクティブな開発者なら毎回の支払いサイクルで十分に達成できるほど低い一方、実際の販売から銀行口座への入金までの期間は、「月次」という表示から想像するより何週間も長くなります。最初から最後までの正確な所要期間を公開してください。
• マーケットプレイスが請求する方式では、プラットフォームは姿勢の一部として、支払い通貨の換算や決済手段の選択など、国境を越える取引の仕組みを担います。予算に含め、後から初めて把握することのないようにしてください。

8. 税務レイヤー

税務は独立した法的レイヤーであり、ステップ2で決めた方針に優先する場合があります。米国のマーケットプレイス・ファシリテーターに関する法令（2018年の Wayfair 判決以降、ほとんどの売上税対象州で適用）や、EUのみなし供給者VATルールにより、プラットフォームは自ら請求していない取引の税を徴収・納付するよう求められることがあります。マーケットプレイス・ファシリテーターまたはみなし供給者としての扱いは税法上の区分であり、記録上の販売者（merchant of record）はカードネットワーク上の区分です。両者は法的に異なり、常に一致するわけではありません。この違いは、調査対象となった決済基盤プロバイダー自身のドキュメントにもそのまま記載されています。

設計上の成果物は、どの税務を誰が扱うかを管轄区域ごとに分けて公開することです。「税務は当社が対応します」または「税務は開発者が対応します」という単一の切り替えにしてはいけません。調査対象に含まれる反例が、その理由を示しています。あるプラットフォームは国ごとに分け、一部ではプラットフォームが管理し、ほかでは開発者が管理します。別のプラットフォームは税制ごとに分け、米国の売上税はプラットフォームが徴収する一方、VATの納税義務は開発者が負います。

詳細、法的枠組みの概要、そして気付かないまま失敗に至る落とし穴については、references/payout-and-tax-mechanics.md を参照してください。このスキルは税務アドバイスではありません。公開する区分を、リリース前に有資格の法律専門家に確認してもらってください。

9. 執行と通知

すべての料率型手数料には、2つの執行上のコミットメントが必要です。

• 迂回防止ルール。 手数料の取り分を避けるためにマーケットプレイスを経由せず請求することは、規約違反とし、掲載停止の手段を設けます。参考事例では、売上の大きいアプリが外部決済処理業者を通じて支払いを迂回し、掲載停止の脅威を受けて初めて元に戻しました。料率が上がるほど迂回の圧力も強まり、削除手段のないルールは単なる希望にすぎません。
• 手数料変更の通知期間を書面で確約します。 参考となるパターンは、標準料率の変更には6か月の通知期間を設け、不利な変更は延期し、有利な変更は前倒しするものです。手数料一覧と併せて公開してください。

10. 測定

次の3つの基準をすべて満たせば、設計は合格です。収益化設計の成果物には業界標準の合格基準がないため、上記の参考ルールに基づいて独自に設定しています。3つすべてを満たすまで反復してください。

1. アプリの種類ごとに、販売者としての立場を明示し、税金、チャージバック、支払いの責任主体をそれぞれ明確に割り当てます。曖昧な取引タイプを残してはいけません。
2. すべての手数料体系に、徴収方法、執行に関する2つの取り決め、通知の確約を書面で明記します。
3. 公開する開発者向けドキュメントに、販売から銀行口座への入金までの所要期間と、管轄区域ごとの税金の分担を記載します。

ローンチ後は、次の項目を追跡してください。

• 請求業務コストに対する純手数料収入（表向きの料率ではなく、モデルの実際の利益率）
• 公開した所要期間に対する、販売から銀行口座への入金までの日数の中央値
• 紛争率とチャージバック率。責任の割り当てに従って、損失の負担者も記録します
• 対象となる開発者のうち、免除が適用されている割合（登録の漏れは、対象者を自動的に適用する仕組みが機能していないことを意味します）
• 取引額に占める税務登録済みの割合
• 迂回事案とその解決状況

最初の四半期を自社のベースラインとしてください。参考資料にあるプラットフォームの数値は背景情報であり、目標ではありません。

ハーネスに永続メモリがある場合は、後続の実行（手数料変更、新たな管轄区域、支払い条件の再交渉）で判断を再導出せずに引き継げるよう、次の決定事項を記録してください。

• 選択した立場
• 決済手段の組み合わせ
• 各手数料体系で選択した段階と、その段階を引き上げる条件
• 公開した通知期間
• 税金の分担

失敗パターン

• 税金の層と販売者としての立場の混同。 開発者請求を選び、税金の扱いも開発者に移ると思い込むこと。仲介業者およびみなし販売者の義務は、請求方法にかかわらず法律に基づいて生じます。対策：手順8で分担を公開し、弁護士に確認してもらいます。
• 税金を徴収できていない状態に気づかないこと。 管轄区域で有効な登録がないまま税金の自動計算を設定すると、何も徴収されず、エラーも返されず、後から修正することもできません。税金の徴収は独立した監視対象のシステムとして確認してください。支払いだけを監視していても、この問題は見つかりません。
• 決済手段における責任の不一致。 一貫性のある2つの組み合わせから選ばず、決済手段の設定を個別に選ぶと、開発者に移したつもりの紛争損失をプラットフォームが負担し続けます。対策：手順3で組み合わせを選び、個別の設定は選びません。
• 決済手段が手数料体系の上限になること。 チェックアウトが対応しているか確認する前に、開発者に従量課金を約束すること。参考となる大手企業向けマーケットプレイスのチェックアウトは、これに対応していません。対策：手順5の「公開前に確認」の順序を守ります。
• 執行の組み合わせを伴わない迂回対策。 迂回防止ルールと掲載停止の手段がない手数料の取り分は、迂回する価値が生じる料率になると、それと同じ速さで形骸化します。
• オプトイン方式の免除。 手動登録が必要な免除制度では、条件を満たす開発者に気づかれないまま通常の全額料率が課されます。制度は書面上存在するだけで、何も変わりません。対象となる開発者は自動的に適用対象にしてください。
• 通知なしの料率変更。 通知のない値上げは、マーケットプレイスが何年もかけて築いてきたパートナーの信頼を損ないます。反発が起きた後ではなく、最初の変更を行う前に6か月前通知のパターンを採用してください。
• 表向きの説明に基づいてキャッシュフローを予測すること。 「月次支払い」は30日以内と読めますが、参考事例では保留金やエスクローが重なると、販売から銀行口座への入金までにその2倍の日数がかかります。実際の数値を公開し、それに基づいて計画してください。

呼び出し例

• 「マーケットプレイスに有料アプリを追加します。顧客への請求は自社で行うべきでしょうか、それとも開発者が直接請求できるようにすべきでしょうか。それぞれの選択肢が税金やチャージバックにどう影響するでしょうか？」
• 「マーケットプレイスの手数料率は、収益が一定の基準額を超えた分に対して15％に設定されています。実際の徴収、支払い、適用の仕組みを設計してください。」
• 「マーケットプレイスの手数料体系と支払いスケジュールを設計してください。収益分配の徴収、小規模開発者向けの免除、パートナーに公開できる売上から銀行振込までのスケジュールを含めてください。」

参考資料

• references/mor-and-billing-rails.md - Merchant of Record の分類表、課金パターンとアカウント設定の組み合わせ、プラットフォームごとの方針、税務と MoR の法的な違い。
• references/fee-stack-and-incentives.md - 金額と日付を含む手数料体系、免除プログラムの分類、適用に関する先例。
• references/payout-and-tax-mechanics.md - 7つのプラットフォームの支払い方法の比較、保留と基準額、越境取引への対応、米国／EUの税法の枠組み。

同じコレクションの関連項目：

• samber/developer-platform-skills@app-marketplace-review - アプリごとの審査手数料がまかなう審査・承認プロセス。
• samber/developer-platform-skills@app-marketplace-listing-standards - 掲載品質の基準と承認基準。掲載費用とは別の内容です。
• samber/developer-platform-skills@app-marketplace-launch-marketing - マーケットプレイスのローンチおよび共同マーケティング予算。収益設計ではなく支出の設計です。
• samber/developer-platform-skills@partner-app-onboarding - 登録料や販売者契約が実際に開発者に提示される、パートナーの導入プロセス。