--- title: "App-to-Web：iOS／Androidアプリにおける外部決済の最新動向と対応ガイド" description: "App-to-Web に関する判決や規制について知っておくべきすべて" language: "jp" publishedAt: "2025-12-25T01:59:45Z" updatedAt: "2025-12-25T01:59:45Z" authors: - name: "Cameron McAllister" url: "https://www.revenuecat.com/jp/blog/author/cameron-mcallister" category: "[ エンジニアリング ]" categoryUrl: "https://www.revenuecat.com/jp/blog/engineering" readingTime: 4 canonical: "https://www.revenuecat.com/jp/blog/engineering/app-to-web-purchase-guidelines" --- # App-to-Web：iOS／Androidアプリにおける外部決済の最新動向と対応ガイド App-to-Web に関する判決や規制について知っておくべきすべて ## Table of contents - [App-to-Webにおける外部決済の仕組み](#app-to-web) - [1. 外部Webリンク](#1-web) - [2. サードパーティ決済（アプリ内）](#2) - [アプリ内課金と外部購入の違い：Apple と Google のガイドライン・規制](#apple-google) - [Apple App Store における外部購入のガイドライン](#apple-app-store) - [Google Play Store における外部購入ガイドライン](#google-play-store) - [アプリに Web チェックアウトを追加する](#web) - [App-to-Webでのコンバージョンを高く保つ方法](#app-to-web-2) - [App-to-Webの活用例](#app-to-web-3) - [App-to-Web の実験を始める準備はできましたか？](#app-to-web-4) Apple と Google は現在、特定の地域やアプリカテゴリにおいて外部購入フローを認めており、適用条件、必要なエンタイトルメント、手数料体系は市場ごとに異なります。開発者は、外部の Web リンクやサードパーティ決済を利用できますが、その要件は地域によってさまざまです。RevenueCat Web を使えば、Web チェックアウトの同期、アトリビューションの計測、そしてポリシーに準拠した App-to-Web のサブスクリプション購入を実現できます。 ここ数年で、Apple と Google はApp-to-Webの道を開き、アプリ内サブスクリプションにおいて外部の購入フローを利用できるようになりました。これにより、**App Store 手数料を回避**しつつ、**価格設定**や**プロモーション**、**チェックアウトの実験**において、より高い柔軟性を持てるようになっています。 この変化の背景には、[米国における Epic Games 対 Apple の訴訟](https://www.revenuecat.com/blog/growth/apple-anti-steering-ruling-monetization-strategy/)や、EU の デジタル市場法（DMA） といった司法判断・規制があります。これらによって、Apple と Google は、アプリ内課金（IAP）をめぐる厳格な要件を緩和せざるを得なくなりました。 アプリチームにとって、これは[App-to-Web](https://www.revenuecat.com/app-to-web/)の新たな可能性を切り開くものです。しかし一方で、App-to-Web を取り巻く規制は決して単純ではありません。ガイドラインは国やアプリのカテゴリごとに異なり、しかも継続的に追加・変更されているため、「何が許可されていて、何が許可されていないのか」を把握し続けるのは容易ではありません。 そこで本記事では、Apple App Store と Google Play Store の両方について、世界各国における外部決済の最新オプション、利用要件、そして手数料・コミッション体系を整理しました。以下で、知っておくべきポイントをすべて解説します。 ## **App-to-Webにおける外部決済の仕組み** ここでは、外部決済がどのように機能するのか、そしてそれをアプリに組み込む主な 2 つの方法について、簡単に整理します。 *Apple と Google の購入ガイドラインをすぐに確認したい場合は、*[*こちら*](https://www.revenuecat.com/blog/engineering/app-to-web-purchase-guidelines/#h-in-app-purchases-vs-external-purchases-guidelines-and-regulations-for-apple-and-google)*をクリックしてください。* ### **1. 外部Webリンク** アプリ内にリンクやボタンを設置し、ユーザーを外部の Web サイト（または WebView）へ遷移させて、そこで購入を完了させる方法です。購入後は、通常バックエンドとの同期によって、その外部購入に基づいてアプリ内のコンテンツや機能をアンロックします。 Apple では、これを [External Purchase Link](https://developer.apple.com/documentation/storekit/externalpurchaselink) の利用と呼びます。たとえば、あるストリーミングアプリでは「Web サイトでサブスクライブする」といったボタンを設け、タップすると Web のチェックアウト画面が開くようになっています。支払いが完了すると、ユーザーは新しいサブスクリプションでアプリにログインできる、という流れです。 ### **2. サードパーティ決済（アプリ内）** Apple や Google 以外の決済ゲートウェイを、アプリの UI に直接組み込む方法です。購入自体はアプリ内で完結しますが、App Store / Google Play の課金システムは使用しません。これは **代替アプリ内決済（alternative in-app payment）** と呼ばれることもあります。 代表的な例としては、[アプリ内課金に Stripe を利用](https://www.revenuecat.com/blog/engineering/can-you-use-stripe-for-in-app-purchases/)したり、App Store の購入ダイアログの代わりに、国別のクレジットカード入力フォームをチェックアウト画面に表示したりするケースがあります。 以前は実装のハードルが非常に高い方法でしたが、Epic Games 対 Apple の判決以降、サードパーティ決済は以前よりも使いやすくなりました。ただし、どちらの方法を選ぶ場合でも、Apple と Google には厳格なルールがあります。 #### **Apple でサードパーティ決済を実装する場合** - いかなる外部購入フローを提供する場合でも、事前に Apple の特別なエンタイトルメントを申請する必要があります - 実装内容に応じて、以下のいずれかを使用します - ユーザーを Web チェックアウトへ誘導する場合 - アプリ内でサードパーティ決済フローを実行する場合 - ユーザーがアプリを離れる、または Apple 以外の方法で支払いを行う前に、Apple が用意した開示用のシートが表示され、App Store で処理される購入ではないことが明示されます - 場合によっては、外部購入エンタイトルメントを使用すると、同じ地域・同じストアフロント内で Apple IAP を同時に提供できないことがあります。つまり、そのストアではどちらか一方のみ、という扱いになります #### **Google でサードパーティ決済を実装する場合** - User Choice Billing により、チェックアウト時に Google Play の課金と代替決済手段のどちらかをユーザーが選択できるようになります - この選択肢を提示するために、開発者は Google の代替課金 API を統合する必要があります - External Offers（EEA のみ） では、アプリから直接購入用の Web ページへリンクアウトできます（タップ時に Google から「Play を離れます」という確認表示が出ます） - Apple と同様に、通常の Google Play Billing IAP と外部オファーを同一アプリ内で併用できないケースもあります ## **アプリ内課金と外部購入の違い：Apple と Google のガイドライン・規制** Apple App Store および Google Play Store 上のほとんどのアプリは、サブスクリプションやデジタルコンテンツの購入に、各プラットフォームが提供する 標準の課金システム を利用しています。原則として、以下で説明する外部購入プログラムのいずれかに 該当し、かつオプトインしていない限り、アプリ内から別の支払いフローへユーザーを誘導することは認められていません。 通常のアプリ内課金（IAP）では、各ストアが手数料を徴収します。Apple と Google Play の標準手数料はいずれも 30% ですが、IAP 収益が年間 100 万ドル未満の開発者 に対しては 15% に引き下げられます。さらに Google Play では、サブスクリプションの2年目以降の更新分 にも 15% の料率が適用されます。 これらの手数料を回避するために、アプリは 外部購入 を提供することが可能ですが、その場合は以下のガイドラインを遵守する必要があります。 ### **Apple App Store における外部購入のガイドライン** | **地域／プログラム** | **対象アプリ** | **外部決済として許可されている内容** | **手数料／コミッション** | **補足・参照情報** | | --- | --- | --- | --- | --- | | 米国：External Purchase Links | 米国 App Store に配信されているすべてのアプリ（ゲームを含む） | アプリ内に、Web チェックアウトへ遷移する外部決済リンクを設置可能 | 0% App 内課金（IAP）経由で行われた購入については、通常の App Store 手数料（15〜30%）が引き続き適用 | *[App Store Review Guidelines（米国）](https://developer.apple.com/app-store/review/guidelines/#link-to-other-purchase-methods)* | | EU／EEA：オファーの告知・プロモーション（別称／StoreKit External Purchase Link） | EU または EEA のストアフロントで提供されるすべてのアプリ | リンクアウト、またはサードパーティ決済による外部購入／支払いが可能 | IAP を使用する場合： 10〜17% のコミッション＋3% の決済処理手数料 外部購入を使用する場合： 2% 初回獲得手数料 ＋5〜13%（利用する任意のストアサービスにより変動） ＋年間インストール数が 100 万件を超えた分について、初年度インストールごとに €0.50 の Core Technology Fee | EU 向け Alternative Terms Addendum へのオプトイン、または EU ストアフロント用の StoreKit External Purchase Link エンタイトルメントが必要 *[Communication and promotion of offers on the App Store in the EU](https://developer.apple.com/support/communication-and-promotion-of-offers-on-the-app-store-in-the-eu/)* | | EEA：音楽ストリーミングサービス向けエンタイトルメント | 音楽ストリーミングアプリ | Web サイトへの外部サブスクリプションリンク／ボタンの設置が可能 | 最大 約27%（通常の 30% 手数料から、約 3% の決済処理費用を差し引いた水準） EU Alternative Terms を選択した場合、外部購入には上記 EU の手数料体系（2% + 5〜13% + 追加費用など）が適用され、固定の 27% にはならない | *[Music streaming services entitlement (EEA)](https://developer.apple.com/support/music-streaming-services-entitlement-eea/)* | | オランダ：出会い系アプリ | オランダ（NL）ストアフロント専用の出会い系アプリ | Apple IAP と併用して、代替のアプリ内決済および／または Web 購入への外部リンクが可能 | 通常の App Store 手数料 − 3%（例：30% → 27%、小規模事業者／長期サブスクの場合は 15% → 12%） | *[Distributing dating apps in the Netherlands](https://developer.apple.com/support/storekit-external-entitlement/)* | | 韓国：StoreKit External Purchase Entitlement | 韓国 App Store のみで配信され、要件を満たすサードパーティ PSP を利用するすべてのアプリ | 代替のアプリ内決済プロバイダーの利用が可能（Apple IAP は必須ではない） 同一アプリ内で Apple IAP を併用することは不可 | 26% | *[Distributing apps using a third‑party payment provider in South Korea](https://developer.apple.com/support/storekit-external-entitlement-kr)* | | グローバル：リーダーアプリ (External Link Account Entitlement) | 雑誌、新聞、書籍、音声、音楽、動画の提供を主目的とし、既存購入済みコンテンツへのサインインを許可する「リーダー」アプリ | アカウント作成および管理のために、Web サイトへのリンクを 1 つ設置可能 リンクは必ずブラウザで開く必要あり 同一アプリ内で IAP を提供することは不可 | 0% | *[Distributing reader apps with a link to your website](https://developer.apple.com/support/reader-apps/)* | | 日本：モバイル・ソフトウェア競争促進法（MSCA） | 必要なエンタイトルメントを取得した、日本 App Store 上のすべての iOS アプリ（全カテゴリ） | Out-of-App Offers による App-to-Web 購入（Web チェックアウトへの外部リンク） Alternative Payment Processing（Apple 以外の PSP）による代替アプリ内決済 Web 購入に関する価格やプロモーションのアプリ内表示 Apple IAP と外部決済オプションを並列で表示・併存させることが必須 | Alternative Payment Processing：21%（軽減ケースでは 10%） Out-of-App Offers（Web）：15%（軽減ケースでは 10%、更新時にも適用） Apple IAP：21% ＋ 5% 決済処理手数料（軽減ケースでは 10% ＋ 5%） 代替アプリマーケットプレイス：5% Core Technology Commission | MSCA に基づく外部決済を、Apple はエンタイトルメント、StoreKit API、開示画面、UI の同等性、既定ブラウザリンク、年齢制限などを通じて実装 [Apple の公式発表](https://www.apple.com/newsroom/2025/12/apple-announces-changes-to-ios-in-japan) | ### **Google Play Store における外部購入ガイドライン** | **地域／プログラム** | **対象アプリ** | **外部決済として許可されている内容** | **手数料／コミッション** | **補足・参照情報** | | --- | --- | --- | --- | --- | | User Choice Billing（UCB）：オーストラリア、ブラジル、インドネシア、日本、南アフリカ、英国、米国、EEA | オーストラリア、ブラジル、インドネシア、日本、南アフリカ、英国、米国の*非ゲーム*アプリ EEA、韓国、インドでは*すべての*アプリ | User Choice Billing（UCB）：チェックアウト時に、Google Play の請求システムと代替のアプリ内請求手段のどちらを利用するか、ユーザーに選択肢を提示できる | Google Play 請求（IAP）を使用する場合： 年間売上 100 万ドルまで：15% 100 万ドル超：30% 外部請求システムを使用する場合： 通常の Google Play サービス手数料から 4% 減（例：15% → 11%、30% → 26%） | *[User choice billing on Google Play](https://support.google.com/googleplay/android-developer/answer/13821247)* | | EEA：代替請求のみ（Google Play 請求をアプリ内で使用しない） | EEA のユーザーを対象とし、Google Play Billing を完全に排除して、独自または第三者のアプリ内請求システムのみを使用したいアプリ | 自社（または第三者）の請求システムによるアプリ内取引のみを実施 同一アプリ内で Google Play Billing を併用することは不可 | 通常の Google Play サービス手数料から 3% 減（例：15% → 12%、30% → 27%） | *[EEA alternative‑billing program](https://support.google.com/googleplay/android-developer/answer/14659200?hl=en)* | | EEA：External Offers Program（リンクアウト・プログラム） | EEA において、アプリ内でオファーを訴求し、購入やサブスクリプションのためにアプリ外（ブラウザ、他ストア、WebView など）へユーザーを送客したいアプリ | アプリ内にプロモーションユニットやハイパーリンク（リンクアウト）を表示し、 デジタル商品やサブスクリプション購入のために自社サイトなどへ遷移させることが可能 | 3% 初回獲得手数料（Initial Acquisition fee） ＋10%（必須）Tier 1 サービス手数料 ＋3% / 10%（任意）Tier 2 手数料 (IAP：10%、サブスクリプション：＋3%) ＋アプリカテゴリに応じたインストール単価ベースの可変手数料 | ※手数料は加算方式のため、Tier 1 のみの場合でも外部売上に対して 約 13%、Tier 1 + Tier 2 を組み合わせると、オファーによっては 20% 台半ばに達することがあります。 *[EEA ユーザー向け External Offers Program の変更内容](https://support.google.com/googleplay/android-developer/answer/16505463?hl=en)* (初回獲得率、Tier 1 / Tier 2 手数料、インストール単価手数料表を含む) | | 日本：モバイル・ソフトウェア競争促進法（MSCA） | 日本向け Google Play に配信されるすべてのアプリ（ゲーム／非ゲーム）、所定のプログラムへの参加が必要 | User Choice Billing（UCB）：すべてのアプリに対して、Google Play 請求と代替のアプリ内請求を並列表示 App-to-Web 購入：新しい Google Play のリンクアウト・プログラムを通じて Web 購入が可能 Web 購入向けの価格表示やプロモーションをアプリ内で表示可能 Google Play 請求と外部決済オプションは併存可能 | Google Play 請求 年間売上 100 万ドルまで：15% 100 万ドル超：30% 代替アプリ内請求（UCB） 標準サービス手数料から 約 4% 減 App-to-Web 購入 Google プログラムに基づく競争力のある手数料（具体的な率は Google が定義） | MSCA 対応は、UCB の拡張および新しい App-to-Web プログラムを通じて実施、参加には API、セーフティ／セキュリティ要件の遵守が必要 [Google の公式発表を参照](https://blog.google/around-the-globe/google-asia/complying-with-mobile-software-competition-act/) | ## **アプリに Web チェックアウトを追加する** ここまで読み進めているのであれば、App-to-Webの価値についてはすでに納得しているはずです。難しいのは「*なぜ*やるか」ではなく、どうすれば迅速にリリースでき、コンプライアンスを守りつつ、購入フローを過度に複雑化させずに実装できるかという点です。 [RevenueCat Web](https://www.revenuecat.com/blog/company/introducing-revenuecat-billing/) は、サブスクリプションアプリに Web チェックアウトを追加するための最もシンプルな方法です。 決済プロバイダー、エンタイトルメント同期、ユーザー識別の紐付け、アナリティクスを個別に組み合わせて構築する必要はありません。すでにモバイルで利用している RevenueCat の構成に、そのまま接続できる 完全な Web 課金スタックを利用できます。ユーザーは Web 上で購入し、iOS や Android アプリですぐにアクセスを解放できます。サブスクライバーのレコードは 1 つ、信頼できる単一のデータソースも 1 つです。 以下は、全体の構成イメージです： **課金エンジンとしての **[**Web Billing**](https://www.revenuecat.com/billing/)**： **[Web Billing](https://www.revenuecat.com/blog/company/introductory-offers-for-revenuecat-web-billing/) は、Web サブスクリプション向けに提供される RevenueCat ネイティブの課金エンジンです。Web 上でのサブスクリプションライフサイクルを管理し、RevenueCat のプロダクト、顧客、エンタイトルメントと完全に統合された状態を保ちます。Web 用に別の課金ロジックを構築・運用する必要はありません。 **数分で立ち上げられる Web チェックアウトの表示方法**：Web Billing を有効にすると、複数の方法でユーザーを Web チェックアウトへ誘導できます。 - **アプリ内ペイウォールに **[**Web Purchase Button**](https://www.revenuecat.com/web-purchase-button/)** を追加**：任意の RevenueCat Paywall にボタンコンポーネントを追加できます。タップすると Web チェックアウトへ遷移します。 - **Web Purchase Links**：RevenueCat がホストするチェックアウト用 URL です。[Web Purchase Button](https://www.revenuecat.com/blog/growth/introducing-web-paywall-buttons/) の遷移先として使うこともでき、どこにでも配置可能です。追加設定なしで動作し、ログイン済み／匿名のどちらのフローにも対応します。 - **[Web SDK を使った Web ペイウォール表示](https://www.revenuecat.com/docs/web/web-billing/paywalls#presenting-a-paywall-from-the-web-sdk)**：独自の Web アプリやランディングページがある場合、Purchases.js を使って Web サイト上に RevenueCat Paywall を直接表示し、そのままチェックアウトを完了できます。 すべてが一元的に連携。すべては自動的に連携された状態を保ちます。[Web Overview ダッシュボード](https://www.revenuecat.com/blog/company/web-overview-dashboard/)では、Web とモバイルの状況を 1 か所で確認できます。Web とモバイルのオファリングは同じカタログ上に存在し、エンタイトルメントは自動で同期され、イベントは共通のアナリティクス基盤に流れ込みます。 ### **App-to-Webでのコンバージョンを高く保つ方法** チームがよく懸念するのは、「Web を挟むとネイティブチェックアウトよりコンバージョンが下がるのではないか」という点です。しかし、購入を同一ページ内で完結できる [Web ペイウォール](https://www.revenuecat.com/docs/web/web-billing/paywalls#using-a-paywall-in-a-web-purchase-link)にユーザーを送ることで、この問題は簡単に回避できます（いわゆる RevenueCat の Express Purchase ボタンです）。 ブラウザで Apple Pay や Google Pay が利用可能な場合、Web ペイウォール上にウォレットボタンが表示されます。ユーザーは 1 回タップし、ウォレットで確認するだけで購入が完了します。その後、RevenueCat が自動的にアプリ側へアクセス権を同期します。 この仕組みにより、ユーザー体験は非常にシンプルに： アプリ内ペイウォール → Web ペイウォール → ウォレット確認＝アクセス解放 ### **App-to-Webの活用例** - **Web オプション付きのアプリ内アップグレード**：アプリ内ペイウォールに「Web で続行」ボタンを表示します。タップすると、同じプランが選択された状態で Web ペイウォールが開き、対応している場合はウォレットボタン（Apple Pay / Google Pay）が表示されます。より速いチェックアウトを求めるユーザーは、ワンタップで購入を完了できます。 - **復帰（Win-back）向けの割引オファー**：解約済みユーザーに対して、カムバック割引を含むターゲット型のアプリ内ペイウォールを表示します。Web ボタンをタップすると、割引がすでに適用された専用の Web オファーに遷移するため、ユーザーが適切なプランを探し回る必要はありません。 - **計測可能なキャンペーントラフィック**：UTM パラメータを保持したまま、広告やメールで Web Purchase Link を共有します。購入後はリデンプションのステップでサブスクリプションがユーザーのアプリ内アカウントに紐づけられ、即座にアクセスが解放されます。独自のグルーコードを実装することなく、クリーンなアトリビューションを取得できます。 ## **App-to-Web の実験を始める準備はできましたか？** App-to-Web を取り巻くガイドラインは今後も変化し続けるため、チェックアウト体験を柔軟かつコンプライアンスに準拠した状態で保つことが、成功の鍵になります。Apple や Google がポリシーを更新するたびに、このガイドも継続的にアップデートしていく予定です。次の App-to-Web 施策を検討する際には、ぜひブックマークしてご確認ください。 独自にチェックアウトコードを実装して試す場合でも、RevenueCat Web に面倒な部分を任せる場合でも、App-to-Web は効率的で柔軟な購入フローを実現できます。健闘を祈ります。ぜひ積極的にテストしてみてください。