本記事は、購入導線に関するポリシーの事実確認と整理を目的としています。

確認日: 2026年7月24日

この日付は重要です。アプリ内からWeb購入へつなぐ条件は、国・地域、ストアフロント、OS、アプリ種別、参加プログラム、契約への同意状況によって変わります。この記事は2026年7月24日にApple、Google、Stripeの公式情報を確認して作成したものであり、審査結果、法令適合、将来の料率を保証するものではありません。実装や契約変更の直前には、対象国の最新版を公式ページと契約画面で確認してください。

先に結論: 「Web決済なら手数料が消える」ではない

Webから購入してもらい、購入済みの権利をアプリで使えるようにする設計には、利益を残せる可能性があります。ただし、単純に「ストアの決済を外せば、その分だけ利益が増える」とは限りません。

AppleやGoogleのプログラムによっては、外部リンク経由の取引にもストア側の手数料、報告義務、専用API、表示要件が残ります。さらにWeb決済側では、決済事業者の処理手数料、決済失敗の回収、返金、チャージバック、カスタマーサポート、税の判定・徴収・申告、購入権限の同期が開発者側へ移ります。アプリからブラウザへ移ることで、購入完了率が下がる可能性も別に計測しなければなりません。

したがって判断単位は「決済手数料の率」ではなく、次の式です。

手元に残る額 = 売上 - ストア関連手数料 - 決済処理費 - 返金・不審請求損失 - 税務費 - サポート費 - Web遷移で失った購入の粗利

本稿の目的は規約の抜け道を示すことではありません。正規の制度を使う場合に、個人開発者が何を比較し、何を運用し続ける必要があるかを一枚の設計にまとめることです。

なぜ個人開発者に需要があるのか

内部の調査素材では、「Webからアプリへ購入導線を作り、手数料差を利益へ変えた事例」が出発点になりました。ただし、個別事例の成功をそのまま再現できるとは扱いません。需要の裏付けとして公開情報を確認すると、問題は手数料だけではなく、継続課金、決済失敗、解約、計測まで連結しています。

RevenueCatの「State of Subscription Apps 2026」は、月間の新規サブスクリプションアプリ公開数が2022年1月の約2,000本から2026年1月には14,700本超へ増えた一方、2020年より前に公開されたアプリがサブスクリプション売上の69%を占めると報告しています。また、Google Playではサブスクリプション解約の31%が非自発的な請求失敗で、App Storeの14%より高いという集計も示しています。これは「作ること」だけでなく、決済と継続を管理する需要が大きいことを示す業界データです。

Stripeは継続課金向けに、失敗率、回収率、未回収額を確認するRevenue Recovery Analyticsと、自動再試行や顧客通知を案内しています。PaddleもMRR、解約率、LTV、ARPU、コホートをまとめて見るサブスクリプション分析を提供しています。決済事業者がこれらを独立した機能として用意している事実からも、課金開始後の運用が一回限りの実装ではないと分かります。

需要の根拠:

RevenueCat State of Subscription Apps 2026: https://www.revenuecat.com/state-of-subscription-apps-2026-business
Stripe Revenue Recovery Analytics: https://docs.stripe.com/billing/revenue-recovery/recovery-analytics
Paddle ProfitWell Metrics: https://developer.paddle.com/concepts/retain/metrics/

サイト運営で広告の表示回数だけを見ても収益の原因が分からないのと同じです。当サイトのAdSenseのCPC変化を切り分ける方法では、単一指標で結論を出さない考え方を説明しています。アプリ課金でも、訪問、クリック、購入開始、決済成功、継続、返金を分けて観測します。

最初に分ける四つの問い

アプリの画面を作る前に、次の四つを順番に分けます。

誰が買うか: ユーザーが利用するストアフロントと居住地域はどこか。
何を買うか: デジタル機能、デジタル教材、物理商品、対面サービスのどれか。
どこで買うか: ストア課金、アプリ内の代替決済、アプリからリンクしたWeb決済、アプリ外で独立して見つけたWeb決済のどれか。
誰が購入後を担当するか: 返金、税、領収情報、決済失敗、不審請求、問い合わせ、権限復元を誰が処理するか。

この四つを混ぜると、「米国で許される表示を日本でも出した」「物理サービスの例外をデジタル教材へ当てはめた」「決済処理手数料だけ比較し、ストア側の外部取引手数料を落とした」といった設計事故が起きます。

比較表1: 地域と制度を先に固定する

対象	2026年7月24日時点の公式情報	実装前の確認
Apple米国ストアフロント	App Review Guidelines 3.1.1(a)は、米国ストアフロントでは外部購入方法へのボタン、リンク、行動喚起にエンタイトルメントが不要と説明	最新ガイドライン、アプリ種別、表示内容、審査用説明を再確認
Apple日本ストアフロント	iOS 26.2以降のiPhone向けに、代替決済やリンクを扱うStoreKit External Purchases or Offers Entitlementと開示シート等の条件を公式ページが案内	契約同意、対象OS、エンタイトルメント、手数料、報告方式、PSP要件
Apple EU・EEA等	地域・アプリ種別に応じたエンタイトルメントとExternal Purchase APIがある	対象国コード、利用できるAPI、契約条項、取引報告
Google Play米国	External Content Links Programへの登録・承認、専用API、リンク先要件、返金・サポート等が必要	2026年10月1日からの報告・手数料開始予定を含め、実施日時点の制度
Google Play EEA	External Offers Programへの登録、専用API、取引報告、料率等がある	EEA対象ユーザー、参加条件、リンク後24時間の取引帰属、併用可能な課金方式
Google Playその他	Payments policyのSection 3、8、9等に該当しない限り、アプリ内購入はPlay Billingが原則	対象国の代替課金・外部リンクプログラム有無
Webだけで販売	ストア審査とは別でも、決済、消費者保護、プライバシー、税、サポートの責任は残る	販売国、事業者表示、利用規約、返金方針、税登録、決済事業者の対応国

Appleの基準では、アプリ内の機能やデジタルコンテンツを解除する場合、原則としてIn-App Purchaseを使うと3.1.1に書かれています。その上で3.1.1(a)や地域別制度が外部購入リンクを扱います。米国以外の多くのストアフロントでは、該当する制度がなければ、外部購入へ誘導するボタン、リンク、行動喚起を置けないという構造です。

Google PlayのPayments policyも、Play配布アプリでアプリ内機能やデジタルコンテンツへ支払いを受ける場合は、Section 3、8、9等の例外や対象プログラムがない限りPlay Billingを求めています。WebView、ボタン、リンク、広告、登録フローを使った外部決済への誘導も明示的に対象です。

「Webに価格表があるから、アプリからそこへリンクしてよい」とは判断できません。リンクを表示する前に、ユーザーの地域、ストアフロント、アプリの種類、参加制度をサーバー側の設定とアプリ側の適格性APIで確認する必要があります。

Appleの設計ポイント

App Review Guidelinesの基本線

Apple App Review Guidelines 3.1.1は、サブスクリプション、プレミアムコンテンツ、完全版解除など、アプリ内の機能やデジタルコンテンツの解除にIn-App Purchaseを使うことを原則としています。3.1.3には、Readerアプリ、マルチプラットフォームサービス、企業向けサービス、1対1のリアルタイムサービス、アプリ外で消費する物理的な商品・サービスなど、別の扱いも記載されています。

特に区別したいのは次の二点です。

1対1のリアルタイムサービスは3.1.3(d)の例に含まれますが、1対少数や1対多数はIn-App Purchaseが必要と記載されています。
アプリ外で消費する物理商品・サービスは3.1.3(e)で、Apple Payや通常のカード入力などIn-App Purchase以外を使うと記載されています。

デジタル教材を「教育だから物理サービス」と扱ったり、録画講座を「個別指導」と扱ったりはできません。提供形態を正確に分類します。

日本のApp Storeにおける新しい選択肢

Appleの日本向け公式ページは、iOS 26.2以降のiPhone、日本のストアフロント向けに、アプリ内の代替決済プロセッサと、アプリ外のオファーを案内しています。利用するにはStoreKit External Purchases or Offers Entitlementを含め、対象地域にjpを設定し、購入フロー前の適格性確認と開示シートなどの要件を満たす必要があります。

同ページは、代替決済プロバイダを使う場合に、審査用コメントへプロバイダ名を記載し、プロバイダがPCI Level 1への対応と、未承認取引の異議申し立て、サブスクリプション管理、返金リクエストを含むカスタマーサービスを用意することも求めています。

2026年7月24日時点で日本向けページに示された主な料率は、App Storeの手数料が対象プログラム参加者と自動更新サブスクリプションの1年目以降で10%、それ以外の対象取引で21%、AppleのIn-App Purchaseを使う場合の決済処理手数料が5%です。外部決済を使えばApple関連費用がゼロになる、という制度ではありません。さらに、代替決済の税の徴収・納付、返金等を含む取引報告の責任が開発者側に置かれます。

この料率は日本向けの新しい事業条件です。App Store Small Business Programの一般説明にある「有料アプリとIn-App Purchaseの15%」と、文脈を混ぜて計算しないでください。実際の契約、地域、対象取引、プログラム参加状態で適用値を確定します。

Appleで記録すべきもの

AppleのExternal Purchase APIは、対象地域やエンタイトルメントに応じて、外部購入トークンの取得、開示表示、関連取引のサーバー報告を扱います。日本ではiOS 26.4以降についてExternal Purchase Server APIによる関連取引報告が案内されています。購入成功だけでなく、返金、修正、更新、一回限りの購入、購入に至らなかった取引の報告要件も日本向けページに記載されています。

内部の売上台帳には最低でも次を分けて持ちます。

ストアフロントと国コード
OSとアプリ版
表示した購入方法
外部購入トークンまたはストア取引ID
商品ID、価格、通貨、税区分
購入開始、成功、失敗、取消、返金、チャージバック
権限付与、権限取消、復元
ストアへの報告状態と報告時刻
サポート事案ID

機械的な完了証拠を残す考え方は、AIエージェントの完了証拠チェックにも通じます。決済では「APIが200を返した」だけでなく、台帳、権限、報告が同じ取引へ結びつくことが完了条件です。

Google Playの設計ポイント

Payments policyの基本線

Google PlayのPayments policyは、Playから有料ダウンロードを販売する場合と、アプリ内のデジタル機能・コンテンツへ支払いを受ける場合の原則を示しています。外部の決済方法へ導くUIは、対象プログラムへ登録して条件を満たす場合に限って設計します。

対象国の制度がなければ、Web決済のページが自社サイトにあっても、アプリから購入を促すリンクを出す根拠にはなりません。アプリ外で取得した既存顧客がログインして購入済み機能を使えるか、アプリ内で購入を促してよいかも別の問いです。

米国のExternal Content Links Program

2026年7月24日に確認したGoogle公式ページでは、米国とその領土のユーザー向けにExternal Content Links Programが案内されています。登録と承認、External Links APIの統合、リンク先の目的表示、誤認させない遷移、個人情報を含むURLの安全な扱い、サポート、未承認取引の異議申し立て、返金手段などが条件です。

同ページの2026年7月22日更新では、プログラム参加者に対する取引・成功ダウンロードの報告と関連手数料は2026年10月1日から始まる予定とされています。米国の外部リンクに関する制度を設計するときは、実装日だけでなく運用開始日と課金開始日も分けて確認します。

EEAのExternal Offers Program

EEA向けExternal Offers Programでは、登録、External Offers APIの統合、取引報告などが必要です。2026年6月4日からの公式表は、外部リンク後24時間以内の対象取引について、標準の継続課金10%、その他のアプリ内デジタル商品20%、対象プログラム参加時はその他15%、最初の年間100万米ドル枠では10%と案内しています。

ここでも、Stripe等の決済処理手数料に加えてGoogle Playのサービス手数料があり得ます。「外部決済3.6%だけ」という比較は不完全です。

Googleで記録すべきもの

Googleの外部リンク制度では、取引をどのリンクに帰属させるか、いつまでに報告するか、どの取引種別かが重要です。EEAのExternal Offers Program公式ページは、該当する承認済み取引を外部取引後24時間以内にGoogle Playへ報告すると案内しています。米国のページは、購入、レンタル、更新、チャージ、アップグレード、ダウングレード、無料トライアルの0ドル取引まで報告対象になり得ると説明しています。

そのため、売上だけのCSVでは足りません。クリック時点の制度・地域・リンク識別子と、後続の取引イベントを結びつける台帳が必要です。

比較表2: ストア課金とWeb決済で誰の仕事が増えるか

項目	ストア課金中心	Web決済・外部リンク中心	個人開発者の確認
購入UI	ストアの標準画面	自社Web、Checkout等	ブラウザ遷移後の離脱と表示崩れ
決済処理	ストアが処理	決済事業者が処理	料金、対応手段、3Dセキュア
ストア関連手数料	対象料率	地域制度により残る	外部取引にもかかる料率
税	ストアが支援・処理する範囲がある	開発者責任が増える	登録、徴収、申告、請求情報
返金	ストアの仕組みが中心	自社方針と決済事業者	期限、部分返金、権限取消
決済失敗	ストアの再試行等	自社で再試行・通知を設計	ハード拒否と一時失敗の区別
不審請求	ストア側の枠組み	開発者が証拠・期限を管理	利用記録、規約同意、連絡履歴
サポート	ストアと開発者で分担	開発者側が一次窓口	返金、解約、領収、権限復元
購入権限	ストアレシート等	Web取引から自社権限へ同期	二重付与、遅延、取消、復元
計測	ストア分析	Web分析とアプリ分析を結合	同意、識別子、重複、帰属期間

売上と手元に残る現金は、分けて考えます。利益率が良く見えても、返金や税の支払い、決済事業者からの入金時期で資金繰りは変わります。

Stripeを例にしたWeb決済の費用と責任

Stripe日本向け料金ページは、標準料金で国内カードの成功取引1件あたり3.6%、初期費用・月額料金なしと案内しています。Stripe BillingはBilling取引額の0.7%、Stripe Taxの組み込み型は税登録済み地域の取引ごとに0.5%という表示があります。いずれも利用する製品、支払い方法、通貨換算、個別契約によって追加費用が変わります。

標準料金の返金について、Stripe料金ページは、銀行振込を除く決済手段では返金自体の追加手数料はない一方、元の決済処理、Connect、通貨換算の手数料は返金されないと説明しています。Stripeの返金文書は、顧客への反映が銀行によって約5〜10営業日かかり、失敗時には最大30日かかる場合があるとしています。

不審請求では、日本向け料金ページに申立て受領手数料1,500円が記載されています。返金とチャージバックは同じではありません。正式な不審請求が開かれた後は、その手続きの中で証拠提出や対応期限を管理します。

税については、Stripe Taxを有効にしただけで納税義務が消えるわけではありません。Stripeの公式文書は、事業者が義務のある国・地域を特定し、現地税務当局へ登録した上で、その登録をStripeへ設定すると説明しています。税務判断は税理士等の専門家へ確認してください。

比較表3: 料金を見るときの分解

費用	発生点	見落としやすい点
ストアのサービス手数料	ストア配布・取引	外部リンク取引にも制度上残る場合
決済処理手数料	決済成功時	国内外カード、通貨換算、支払方法差
継続課金製品料	サブスクリプション請求	Paymentsとは別率の場合
税計算製品料	税計算対象取引	税登録と申告は別の責任
返金で戻らない費用	返金時	元の処理手数料が戻らない場合
不審請求手数料	チャージバック時	売上取消と手数料が同時に出る
サポート原価	問い合わせ時	ブラウザ購入の説明、領収、復元
転換率損失	アプリからWebへ移る時	率ではなく失った粗利で評価
開発・保守費	初期と継続	地域別UI、API更新、取引報告

計算例: 率ではなく手元額で比べる

以下は判断方法を示す架空の計算です。実際の適用料率ではありません。税は簡略化のため含めず、各例に明記した仮定だけを使います。対象ストア、契約、商品、販売国で必ず置き換えてください。

計算例1: 1,000円を100件、単純な処理率だけ比較

売上: 1,000円 × 100件 = 100,000円
仮にストア関連費を15%と置く: 100,000円 × 15% = 15,000円
Stripe国内カード3.6%だけを置く: 100,000円 × 3.6% = 3,600円
表面的な差: 15,000円 - 3,600円 = 11,400円

この11,400円は利益の確定値ではありません。外部リンクにもストア手数料が残る制度、Billing、税、返金、サポート、転換低下をまだ引いていないからです。

計算例2: Web遷移で購入件数が100件から88件へ下がる

ストア経路: 1,000円 × 100件 × (1 - 15%) = 85,000円
Web経路: 1,000円 × 88件 × (1 - 3.6%) = 84,832円
差: 84,832円 - 85,000円 = -168円

手数料率は低くても、購入件数が12%減るとこの仮定では逆転します。転換率を計らずに「Webの方が得」と結論できない理由です。

計算例3: 日本向けAppleの架空月次で処理差を見る

日本向け公式ページにある対象プログラム参加者のApp Store手数料10%と、Apple決済処理5%を入力値として使います。外部決済でもApp Store手数料10%が残り、Stripe国内カード3.6%がかかると仮定します。

売上: 1,200円 × 200件 = 240,000円
Apple In-App Purchase側: 240,000円 × (10% + 5%) = 36,000円
外部決済側: 240,000円 × (10% + 3.6%) = 32,640円
差: 36,000円 - 32,640円 = 3,360円

表面的な改善幅は売上の1.4%です。外部決済運用が月3,360円を超えるなら、この仮定では費用面の優位が消えます。

計算例4: 日本向けAppleの21%区分を仮定

売上: 3,000円 × 80件 = 240,000円
Apple In-App Purchase側: 240,000円 × (21% + 5%) = 62,400円
外部決済側: 240,000円 × (21% + 3.6%) = 59,040円
差: 62,400円 - 59,040円 = 3,360円

決済処理差が5%対3.6%なら、売上が同じ限り差はやはり1.4%です。App Store手数料部分を誤ってゼロにすると、節約額を大きく見積もってしまいます。

計算例5: EEAのGoogle継続課金を外部リンクで販売

External Offers Programの継続課金10%とStripe国内カード3.6%を入力値とする架空例です。実際にはカード所在地や通貨等でStripe料金が変わるため、国内カード3.6%は比較用の仮定にすぎません。

売上: 1,500円 × 100件 = 150,000円
Google関連: 150,000円 × 10% = 15,000円
決済処理: 150,000円 × 3.6% = 5,400円
合計: 20,400円、売上比13.6%
手元の単純値: 150,000円 - 20,400円 = 129,600円

「外部リンクだから3.6%」ではなく、制度料率と決済処理率を足して比較します。

計算例6: Stripe Billingも使う架空の定額アプリ

月商: 980円 × 300人 = 294,000円
Stripe Payments 3.6%: 10,584円
Stripe Billing 0.7%: 2,058円
合計: 12,642円、月商比4.3%
単純手元: 281,358円

ここにストア関連手数料、税機能、返金、不審請求、サポート費が加わる可能性があります。

計算例7: 返金5件と不審請求2件

1件2,000円、100件、Stripe国内カード3.6%、返金時に元の決済処理手数料は戻らず、不審請求受領手数料を1件1,500円とします。

初期売上: 2,000円 × 100件 = 200,000円
決済処理: 200,000円 × 3.6% = 7,200円
返金元本: 2,000円 × 5件 = 10,000円
不審請求元本: 2,000円 × 2件 = 4,000円
不審請求手数料: 1,500円 × 2件 = 3,000円
単純残額: 200,000円 - 7,200円 - 10,000円 - 4,000円 - 3,000円 = 175,800円

サポート工数と税調整は含めていません。返金率だけでなく、不審請求を分けて予算化します。

計算例8: 購入完了率の損益分岐

ストア経路の購入100件、単価1,000円、手数料15%に対し、Web経路は決済処理3.6%のみという単純仮定にします。

ストア経路の手元: 100件 × 1,000円 × 85% = 85,000円
Web経路で同額を残す必要件数: 85,000円 ÷ (1,000円 × 96.4%) = 約88.18件

整数では89件以上が必要です。この単純仮定では、Web移行後の購入件数が88件以下なら手数料差を失います。外部リンクにもストア料が残る制度なら損益分岐はさらに高くなります。

計算例9: 決済失敗の回収

月額1,000円の定額アプリで、更新対象500人のうち30件が最初の決済に失敗し、その半分の15件を再試行と案内で回収できた架空例です。

失敗額: 1,000円 × 30件 = 30,000円
回収額: 1,000円 × 15件 = 15,000円
未回収額: 15,000円
初回失敗に対する回収率: 15件 ÷ 30件 = 50%

決済成功率は売上に直結します。Stripe公式はSmart Retries、失敗メール、カード更新等を案内していますが、回収率50%はこの例の仮定であり、Stripeの保証値ではありません。

計算例10: 広告収益と購入導線の干渉

購入案内ページが月10,000閲覧、購入リンクのクリック率10%、購入完了率8%、単価2,000円、決済後の手元率90%という架空例です。

クリック: 10,000 × 10% = 1,000件
購入: 1,000 × 8% = 80件
購入の手元: 80 × 2,000円 × 90% = 144,000円

広告配置を増やしてクリック率が10%から8%へ下がり、他条件が同じなら、購入は64件、手元は115,200円です。差は28,800円です。広告収益が増えても、購入粗利の減少を上回るかを同じ期間で比較します。

継続収益を比べる場合は、一定割合で積み上がる計算の考え方が使えます。ただし、サブスクリプションは預金利息ではありません。解約、決済失敗、返金があるため、単純な一定成長率では見積もらないでください。

比較表4: 四つの架空アプリで判断する

架空例	商品分類	第一候補	Web導線で見る点	継続運用
定額アプリ「習慣ノートPlus」月980円	アプリ機能とクラウド同期の継続提供	地域ごとのストア課金を基準に、対象制度があればWeb経路も比較	継続課金料、決済失敗、解約、権限同期、ストア関連料	再試行、期限切れカード、プラン変更、日割り、復元
買い切りアプリ「写真整理Pro」2,400円	アプリ機能の永続解除	Non-Consumable IAPを基準に、対象地域制度を別案として比較	Web遷移による購入減、返金後の権限取消、端末変更	購入復元、二重購入防止、家族共有の扱い
デジタル教材「動画で学ぶ表計算」4,800円	録画動画とPDFのデジタルコンテンツ	デジタル商品としてストア規約を確認	「教育」だけで物理サービス例外にしない、Webとアプリの閲覧権限	コンテンツ更新、返金、視聴履歴、問い合わせ
物理サービス「訪問自転車整備」8,000円	アプリ外で実施する物理サービス	Apple 3.1.3(e)等を確認し、カードやApple Pay等	予約金、キャンセル、現地不履行、地域税	日程変更、返金、担当者連絡、領収

例1: 定額アプリ

「習慣ノートPlus」は、同期、分析、継続的な機能更新を月980円で提供する架空アプリです。定額モデルでは、初回購入率だけでなく、更新成功率、月次解約率、再開率、サポート時間を追います。Appleは自動更新サブスクリプションについて継続的な価値を求め、Googleもサブスクリプションをデジタル機能の例としてPayments policyに挙げています。

Web決済へ移す場合、毎月のストア関連料と決済処理費だけでなく、Stripe Billing等の製品料、失敗回収、顧客ポータル、解約・プラン変更、アプリ権限の即時反映が必要です。失敗した更新を有料状態のまま放置すると提供過多になり、即時停止すると一時的なカード障害で顧客を失います。猶予期間を商品方針として決めます。

例2: 買い切りアプリ

「写真整理Pro」は2,400円で機能を永続解除する架空アプリです。継続課金より請求失敗の回数は少ない一方、端末変更時の復元、同じ利用者の二重購入、返金後の解除、購入証明の保持が中心課題になります。

Apple App Review Guidelinesは、復元可能なIn-App Purchaseに復元機構を用意することを求めています。Web購入でも、メールアドレスだけに依存せず、アカウントと取引を安全に結びつけ、返金・不審請求後に権限を整合させます。

例3: デジタル教材

「動画で学ぶ表計算」は、録画動画とPDFを4,800円で提供する架空商品です。これはアプリ内で消費するデジタルコンテンツなので、「講師が作った教材」「教育分野」という理由だけで、1対1リアルタイムサービスや物理サービスの扱いにはなりません。

ライブの1対1指導、録画講座、少人数ライブ、教室での対面講座は別々に分類します。Apple 3.1.3(d)は1対1のリアルタイムサービスを例示する一方、1対少数と1対多数はIn-App Purchaseが必要と明記しています。混合商品は、各構成要素とアプリ内で提供される価値を審査説明へ明記します。

例4: 物理サービス

「訪問自転車整備」は、アプリ外の現地で提供される物理サービスです。Apple 3.1.3(e)は、アプリ外で消費する物理商品・サービスについてIn-App Purchase以外を使うとしています。GoogleのPayments policyにも、物理的な商品やサービスなどの扱いに関する例外説明があります。

ただし、物理サービスなら何も管理しなくてよいわけではありません。予約枠、キャンセル期限、返金、移動費、役務提供の証拠、領収、問い合わせを設計します。追加のデジタル会員機能を同じ料金に含めるなら、再びデジタル部分の分類が必要です。

比較表5: リンク表示の設計

画面要素	安全な設計の方向	避ける設計
表示条件	ストアフロント、地域、OS、制度参加、API適格性を確認	言語設定だけで国を判定
ボタン文言	遷移先と目的を明確にする	無料と誤認させて決済へ送る
価格	税、通貨、更新条件を購入前に表示	アプリとWebで条件を隠して比較
開示	ストア指定の開示シートや情報画面を正しく表示	警告を小さくする、迂回する
URL	自社管理ドメイン、HTTPS、意図した着地先	多段リダイレクト、別商品への誘導
個人情報	URLへ平文の個人情報を入れない	メールアドレスや会員IDを露出
戻り先	決済成功・取消・失敗を分けて戻す	すべて成功画面へ戻す
障害時	ストア課金や購入なしの利用を壊さない	外部決済障害でアプリ全体を停止

審査をすり抜ける目的で、レビュー時だけリンクを消す、遠隔設定で審査後に表示する、文言を曖昧にして実質的な購入誘導を隠す、といった方法は扱いません。Appleはエンタイトルメントに関する詐欺的・誤認的なマーケティングに対してアプリ削除やプログラム除名の可能性を示しています。Googleもリンク先が示した内容と異なる場所へリダイレクトしたり、誤認させたりしないことを求めています。

決済失敗を独立した状態として扱う

決済結果を「成功」と「失敗」の二つだけにすると、継続課金の運用が壊れます。最低でも次の状態を分けます。

購入開始前
購入開始
追加認証待ち
処理中
成功
一時的な失敗
恒久的な拒否
取消
返金処理中
返金完了
不審請求中
不審請求確定

StripeのSmart Retries文書は、カード番号誤り、盗難カード、認証必須など一部のハード拒否では、新しい支払方法がない限り自動再試行で回収できないと説明しています。再試行回数を増やすだけでは解決しません。顧客へ安全な更新画面を案内し、未払い期間の権限をどうするかを決めます。

構造化されたイベントの考え方は、AIのJSON構造化出力ガイドも参考になります。決済Webhookも、文字列ログではなく、取引ID、イベント種別、発生時刻、処理結果を構造化して重複処理を防ぎます。

返金とサポートを同じ台帳へつなぐ

返金はお金を戻す処理だけではありません。購入権限、請求書、税、ストア報告、顧客通知も整合させます。

返金時の処理順

対象取引と本人確認方法を確定する。
返金方針と法令上の義務を確認する。
全額・一部・取消のどれかを決める。
決済事業者で処理する。
返金処理中の状態を顧客へ示す。
商品の利用権限を方針に沿って変更する。
税額・売上台帳・ストア報告を調整する。
完了通知と参照番号を保存する。

Stripeはカード返金の顧客反映に約5〜10営業日かかる場合があると説明し、追跡にARN、STAN、RRN等の参照番号を使える場合があると案内しています。「返金ボタンを押したので終わり」ではなく、顧客が確認できるまでの案内を用意します。

Googleの米国External Content Links Programは、外部取引の顧客サポート、未承認取引の異議申し立て、原則として返金方法を提供することを条件に挙げています。Apple日本向けページも、代替決済プロバイダに返金リクエスト等を含む顧客サービスの用意を求めています。

税を「決済画面の設定」だけで終わらせない

税は次の四層に分けます。

どの国・地域で登録義務があるか
商品の税区分は何か
購入時にいくら計算・徴収するか
いつ、どこへ申告・納付するか

Stripe Taxは計算と徴収を支援しますが、公式文書は事業者自身が義務のある地域を特定し、必要な登録を行う前提を示しています。日本の消費税、海外のVATや売上税、デジタルサービスの越境課税は条件が異なるため、この記事だけで税務判断をしないでください。

Appleの日本向け代替決済では、Apple In-App Purchaseを使わないデジタル商品・サービスの取引について、適用される税の徴収・納付責任が開発者にあると案内されています。ストア課金からWeb決済へ移す判断は、税務の仕事がどちらへ移るかも含めます。

固定費は、年額、利用頻度、解約条件の順に並べて洗い出します。決済サービスの月額がゼロでも、税務、問い合わせ、監視の固定作業はゼロではありません。

計測: Webへ送った後を見失わない

Web購入導線の評価に必要な最小イベントは次の通りです。

対象画面表示
外部購入ボタン表示
外部購入ボタンクリック
ストア指定の情報画面・開示シート表示
ブラウザ到達
Checkout開始
追加認証開始
決済成功
アプリへ復帰
権限付与
初回利用
更新成功・失敗
解約
返金
不審請求

個人情報をURLへ入れて追跡しません。Googleの米国向け制度も、十分な保護なしにURLへ個人識別情報を含めないことをリンク先要件に挙げています。ランダムなセッションIDやストア提供トークンを用い、サーバーで期限と用途を制限します。

比較表6: 主要KPI

KPI	計算	意味
リンク表示率	リンク表示人数 ÷ 対象人数	地域・制度判定が想定どおりか
クリック率	クリック人数 ÷ リンク表示人数	文言と価値が伝わったか
Web到達率	Web到達人数 ÷ クリック人数	開示やブラウザ遷移で落ちていないか
Checkout開始率	開始人数 ÷ Web到達人数	着地ページと価格の納得度
決済成功率	成功人数 ÷ Checkout開始人数	認証、カード、決済障害の影響
権限付与成功率	権限付与人数 ÷ 決済成功人数	Webとアプリの同期品質
初月継続率	翌月有効人数 ÷ 初月購入人数	商品価値と決済維持
返金率	返金件数 ÷ 成功取引件数	説明不足、品質、誤購入
不審請求率	不審請求件数 ÷ 成功取引件数	明細認知、不正、サポート
取引後手元率	全費用控除後額 ÷ 売上	経路の実質効率

割合だけでなく母数も併記します。10件中1件と1,000件中100件は同じ10%でも、判断の安定性と影響額が違います。AIベンチマーク結果の読み方で説明しているように、測定条件と母数が違う数字を一列に並べないことが大切です。

ストア転換低下をどう検証するか

外部リンクの導入前後を、同じ期間の売上だけで比べないでください。季節、広告流入、アプリ更新、価格変更が混ざります。可能なら対象地域、OS、アプリ版、流入元、既存・新規を分けます。

最小の比較票は次の形です。

条件	ストア課金経路	Web購入経路
対象ユーザー数	記録	記録
購入案内表示数	記録	記録
購入開始数	記録	記録
成功数	記録	記録
平均単価	記録	記録
全手数料	記録	記録
返金・不審請求	記録	記録
サポート時間	記録	記録
30日後の有効顧客	記録	記録
手元額	記録	記録

経路変更と広告変更を同じ日に行わない方が原因を分けやすくなります。サイトの広告指標については、AdSense更新の影響を検証する方法でも、変更日と指標の基準線を保存する考え方を扱っています。

広告と購入リンクを同じページに置く場合

この記事はアフィリエイトリンクを含まず、frontmatterもaffiliate: falseです。将来広告を置く場合でも、広告と自社購入ボタンを誤認させないことが必要です。

具体的には次を守ります。

自社商品の購入ボタンと広告枠を視覚的に区別する。
広告クリックを購入手順の必須工程にしない。
「続ける」等の曖昧なボタンで広告へ送らない。
購入、キャンセル、戻る操作を広告で妨げない。
購入後画面に過度な広告を置き、完了確認を隠さない。
広告収益と購入粗利を別の指標で記録する。

無料サイトの配信基盤を検討する場合は、月0円で静的サイトを持つ手順とWordPressと静的Astroの比較が参考になります。ただし、静的サイトだけでは、秘密鍵を使う決済処理、Webhook受信、購入権限同期は完結しません。秘密をブラウザへ置かず、サーバー側の安全な処理が必要です。

比較表7: リスクと停止条件

リスク	早期検知	停止条件	復旧
対象外地域にリンク表示	地域別表示ログ	対象外表示を1件確認	リモート設定でリンク停止、修正版審査
二重課金	同一顧客・商品・期間の重複検知	重複疑い	新規請求停止、取引調査、返金判断
成功後に権限未付与	決済成功と権限付与の突合	未付与が閾値超過	自動再同期、手動救済窓口
返金後も利用可能	返金イベントと権限の突合	不整合	権限再計算、監査ログ保存
報告期限超過	未報告キューの経過時間	制度の期限接近	外部リンク停止、報告復旧
決済失敗急増	決済手段別成功率	基準線から急変	新規Web案内停止、ストア経路維持
Web転換率低下	到達・開始・成功の段階計測	手元額が基準経路を下回る	表示・価格・経路を見直す
問い合わせ急増	100取引当たり件数	対応能力超過	対象人数制限、説明改善
規約変更	公式ページの確認日	適用条件不明	対象リンクを停止し再審査

外部決済を一度公開したら戻せない構造にしないことが大切です。ストア経路、Web経路、購入なしの無料利用を機能フラグで分け、対象地域ごとに停止できるようにします。ただし、審査後に隠れた機能を有効化する用途ではなく、障害・規約変更時の安全停止に限定します。

導入前チェックリスト

商品と地域

商品がデジタル機能、デジタルコンテンツ、1対1サービス、物理サービスのどれか説明できる。
販売対象の国・ストアフロントを列挙した。
各地域で使う制度と公式URLを記録した。
対象OSとアプリ版を決めた。
アプリ内表示とアプリ外マーケティングを分けた。

契約と審査

最新のApple、Googleの契約とガイドラインを担当者が確認する。
必要なプログラム登録、エンタイトルメント、審査が分かっている。
審査用コメントに決済経路、PSP、テスト方法を説明できる。
開示シート、情報画面、リンク先要件を実装仕様へ落とした。
レビュー時だけ挙動を変える仕組みがない。

お金

ストア関連料と決済処理料を別々に計算した。
Billing、Tax、通貨換算、不審請求等の追加費用を確認した。
返金で戻らない費用を確認した。
税の登録、徴収、申告、納付の責任者を決めた。
最悪月の資金繰りを計算した。

資金の余裕は「何か月分の支出を現金で持つか」という形で設計します。事業では、返金、不審請求、入金保留に備える運転資金として読み替えてください。

技術と運用

購入、更新、失敗、返金、不審請求を別イベントとして保存する。
Webhookの重複、順序逆転、遅延を処理できる。
決済成功と権限付与を定期突合できる。
地域ごとに外部リンクを停止できる。
顧客が支払方法、解約、返金、領収を確認できる。
ストアへの取引報告を期限内に行える。
サポート事案と取引IDを結びつけられる。
秘密鍵をアプリや公開Webへ埋め込まない。

計測

経路別の対象数、表示数、クリック数、成功数を保存する。
転換率だけでなく手元額を比較する。
広告と購入導線の変更日を分ける。
地域、OS、アプリ版、流入元で分解できる。
返金・不審請求・サポート時間を原価へ含める。

よくある質問

1. 自社サイトで先に販売し、アプリではログインだけなら常に許されますか

常にとは言えません。AppleのReaderアプリ、マルチプラットフォームサービス、無料のコンパニオンアプリ等には個別条件があり、Google PlayにもPayments policyと地域別プログラムがあります。アプリ内に購入誘導を置くか、購入済み権利へアクセスするだけかを分け、該当する公式条項を確認してください。

2. アプリから価格を書かずに「詳しくはこちら」とWebへ送れば外部購入リンクではありませんか

文言を曖昧にしても、実際に購入方法へ導くなら規約上の評価対象になり得ます。Googleはボタン、リンク、広告、WebView、登録フロー等を列挙しています。表示の偽装ではなく、対象制度へ正規に参加します。

3. 米国で許されるリンクを全世界へ表示できますか

できません。Appleは米国ストアフロントと他のストアフロントを分けて記載し、Googleの米国External Content Links Programも米国とその領土に限定しています。ユーザーの言語ではなく、制度が指定する地域・ストア条件で制御します。

4. 日本のiPhoneアプリなら、Web決済にするとApple手数料はゼロですか

ゼロとは限りません。2026年7月24日時点のApple日本向け公式ページは、代替決済にもApp Store手数料と取引報告等を案内しています。対象プログラム、取引、サブスクリプション年次、Apple決済処理の有無で率が変わります。

5. Stripeの3.6%だけをストア手数料と比べればよいですか

不十分です。Stripe Billing、Tax、通貨換算、返金で戻らない処理費、不審請求、ストア側の外部取引手数料、税務、サポート、転換率低下を加えます。

6. デジタル教材は教育サービスなので外部決済にできますか

教育という名称だけでは決まりません。録画動画やPDFはデジタルコンテンツです。Appleは1対1リアルタイムサービスと、1対少数・1対多数を分けています。提供形態を正確に分類します。

7. 訪問修理や配車など物理サービスはどうなりますか

Apple 3.1.3(e)は、アプリ外で消費する物理商品・サービスにIn-App Purchase以外の決済を使うとしています。ただし、キャンセル、返金、税、予約、サポートは別途必要です。Googleの該当条項も同時に確認してください。

8. 外部リンクを出す地域判定はIPアドレスだけで十分ですか

十分とは限りません。ストアフロント、制度のAPI適格性、アカウント設定、OS等が関係します。AppleはExternalPurchaseCustomLinkのisEligible確認を案内しています。IPだけで決めず、公式APIと契約上の判定条件を使います。

9. 決済成功Webhookを受けたら権限を付与して終わりですか

終わりではありません。重複、遅延、順序逆転、返金、不審請求、更新失敗、権限復元を処理し、定期的に決済台帳と権限台帳を突合します。

10. 返金したらStripeの手数料も戻りますか

Stripe日本向け料金ページは、標準料金では多くの決済手段で返金自体の追加手数料はない一方、元の決済処理、Connect、通貨換算の手数料は返金されないと説明しています。支払方法と契約を確認してください。

11. 返金は顧客へすぐ表示されますか

Stripeの公式文書では、カード等の返金が顧客側へ見えるまで銀行により約5〜10営業日かかる場合があります。失敗時にはさらに時間がかかる場合があるため、参照番号と案内窓口を用意します。

12. 決済失敗は自動再試行を増やせば解決しますか

解決しない失敗があります。Stripeは盗難カード、認証必須などのハード拒否では新しい支払方法がない限り再試行できないと説明しています。一時失敗と恒久拒否を分けます。

13. Stripe Taxを有効にすれば税務は完了ですか

完了しません。Stripeの公式文書は、事業者が納税義務のある地域を特定し、必要な税登録を行う前提を示しています。計算・徴収支援と、法的な登録・申告・納付は分けてください。

14. Webへ移した後に購入率が下がっても、手数料が安ければ得ですか

購入件数の減少額が手数料差を上回れば損になります。クリック、Web到達、Checkout開始、成功を段階計測し、返金等を引いた手元額で比較します。

15. ストア課金とWeb決済を同じ価格にすべきですか

制度と地域によります。Appleのエンタイトルメントでは比較的低い価格を知らせられる場合があり、Googleも地域別制度に価格・表示条件があります。一方、税、手数料、顧客説明、公平性も考慮が必要です。実施時点の規約を確認して決めます。

16. 価格を変えると既存サブスクリプションは自動で移行しますか

一律ではありません。Appleは国・地域ごとの価格設定、既存顧客の価格維持、値上げ時の通知・同意条件を案内しています。Web決済では決済事業者の請求設定と顧客への通知を自分で設計します。

17. 外部購入リンクを一度導入したら、ストア課金を消すべきですか

すぐに消す必要はありません。制度が併用を認めるかを確認し、購入完了率、手元額、障害時の復旧を比較します。Googleの米国制度は条件を満たせばPlay Billingとの併用を案内していますが、EEA制度は併用条件が異なります。

18. 広告付き無料版からWeb購入へ送る設計は問題ありませんか

広告の有無だけでは決まりません。デジタル機能の購入誘導ならストア規約の対象です。また、広告と購入ボタンの誤認、戻る操作の妨害、計測の混同を避けます。

19. 外部リンク先に会員IDをクエリ文字列で付けてもよいですか

平文の個人情報や推測可能なIDは避けます。Googleの米国制度は、十分な保護なしにURLへ個人識別情報を含めないよう求めています。短寿命で用途限定のランダムなトークンを使います。

20. 個人開発者が最初に作るべきものは決済画面ですか

先に地域・商品分類・費用表・返金方針・権限台帳・停止条件を作る方が安全です。決済画面を先に作ると、制度対象外や運用不能が後から判明し、作り直しが増えます。

実装判断の順番

最後に、個人開発者向けの判断順をまとめます。

商品をデジタル、1対1リアルタイム、物理サービスへ分類する。
対象国とストアフロントを固定する。
AppleとGoogleの当日公式情報で、利用可能な制度を確認する。
ストア課金、外部リンク、アプリ外Web販売を別案として比較する。
ストア関連料、決済処理、税、返金、不審請求、サポート、転換低下を計算する。
購入、更新、失敗、返金、権限、報告を結ぶ台帳を設計する。
地域別の表示と停止スイッチを作る。
審査用説明と顧客向け説明を整える。
小さい対象で転換率と手元額を検証する。
規約確認日を更新し、制度変更時に停止できるようにする。

利率やローンの比較で名目値だけを見ないのと同様に、決済でも表示された率だけで決めません。「費用を同じ土俵へそろえる」考え方を応用し、すべての費用と失った購入を一つの期間へそろえて比較してください。

Sources

以下は2026-07-24 時点で確認した公式情報です。制度、料金、API、対象地域は変更されることがあるため、導入前に各公式サイトでご確認ください。

確認日: 2026年7月24日。最新の適用条件、契約、料金、税務は各公式ページと専門家へ確認してください。