Apple社がEpic Gamesとの侮辱罪判決を不服とし、最高裁判所で争う構えです。2026年9月14日、Appleは米国最高裁判所に対し、同社の外部決済誘導に関するコンプライアンス体制を罰した民事侮辱罪の判決を破棄または取り消すよう求める上訴理由書を提出しました（事件番号 No. 25-1311）。今回の訴訟は、2021年の独占禁止法訴訟そのものを再審理するものではなく、司法による侮辱罪権限の制限、具体的には第9巡回区控訴裁判所が「差止命令の明示的な文言」ではなく「命令の精神」に基づいて民事侮辱を認定したことが適切であったかを問うものです。モバイルアプリ設計者、決済エンジニア、およびユーザー獲得チームにとって、「アプリからWebへの支払いルーティング（App-to-Web Payment Routing）」をめぐるこの法的な論争は、アーキテクチャの観点から極めて重要です。開発者が標準のアプリ内課金（IAP）以外の代替決済手段を提供するために外部決済フローを実装する場合、エンジニアリングチームは、ユニバーサルリンクを通じてバックエンドの課金サービスから信頼できる取引状態をアプリ側で再取得できるよう、堅牢で双方向のルーティングパイプラインを設計する必要があります。
最高裁への上告：侮辱罪の権限と75語の差止命令
最高裁での争点は、連邦民事訴訟規則第65条(d)および確立された連邦衡平法理に基づき、民事侮辱を認定するために必要な法的基準にあります。
2021年9月、米国カリフォルニア州北部地区連邦地方裁判所は、Appleが連邦独占禁止法の下で不法な独占企業であるとは認めなかったものの、開発者がアプリ内での誘導を禁止するガイドラインは「情報提供の弊害」を生じさせ、カリフォルニア州の不正競争防止法（UCL）に違反すると結論付けました。この是正措置として、地裁はAppleに対し、「アプリ内課金に加え、顧客を外部決済メカニズムへと誘導するボタン、外部リンク、その他のアクションへの誘導を禁止してはならない」という75語の恒久的な差止命令を出しました。
要点
- 最高裁への上訴理由書提出: 2026年9月14日、Appleは「Apple Inc. v. Epic Games, Inc.」（No. 25-1311）において、侮辱罪の認定根拠として「命令の精神」を用いた第9巡回区控訴裁判所の判断を不服とし、裁量上告理由書を提出。
- 主要な法的問い: 最高裁は第1の論点のみについて審理を許可。すなわち、命令が対象行為について沈黙している場合に、命令の「明示されていない目的」に基づいて民事侮辱を認定できるのか、それとも「Taggart v. Lorenzen」判例が示す「正当な疑いの余地がない」という明示的な通知が必要なのかが問われます。
- 運用のトリガー: 侮辱罪の認定は、Appleが2024年1月に導入したコンプライアンスプラン（外部決済リンクを許可する一方、リンク経由の取引に対して7日以内の12%～27%の手数料を課し、ボタン表示を制限する内容）に起因しています。
- 控訴審の判断: 第9巡回区控訴裁判所は、「精神」に基づく侮辱認定を支持しましたが、リンクアウト時の手数料徴収を恒久的に禁止する地裁判決は取り消し、手数料の再検討を指示しました。地裁での差し戻し審が続く中、今回のAppleの上告は、侮辱罪判決とその差し戻し指示の完全な破棄を求めています。
MacRumorsやAppleInsiderの報道によると、Latham & Watkins法律事務所のGregory G. Garre氏が作成したAppleの訴状では、元の75語の差止命令にはリンクアウトの手数料や特定のボタン表示に関する言及はなかったと主張しています。Appleは外部への誘導に対する一律の禁止を撤廃し、外部決済リンクのガイドラインを策定してリンクの使用を認めたにもかかわらず、下級裁判所は命令のより広範な競争目標を阻害したとして侮辱罪を認定しました。
Appleは、明確な文言による命令から切り離された民事侮辱認定は、規則65(d)の具体性要件に違反し、規制対象当事者から公平な通知の機会を奪うものだと主張しています。公式の最高裁判所ドケットによると、Epic Gamesは2026年11月13日に回答書を提出予定であり、その後2027年に法廷弁論が行われる予定です。
Epic対Apple 反ステアリング訴訟タイムライン
| 日付 / 期間 | 手続きの出来事 | 運用のコンテキスト |
|---|---|---|
| 2021年9月10日 | 地裁判決 | UCL差止命令によりリンクアウト禁止が撤廃される |
| 2024年1月16日 | コンプライアンス計画提出 | Appleが外部購入リンクルールを導入 |
| 2025年4月30日 | 民事侮辱罪命令 | 地裁が侮辱罪を認定、手数料徴収を禁止 |
| 2025年12月11日 | 第9巡回区控訴審判決 | 「精神」による侮辱認定を支持、0%手数料ルールを取り消し |
| 2026年6月30日 | 最高裁審理 | 民事侮辱罪（Q1）に限定して裁量上告を許可 |
| 2026年9月14日 | 上訴理由書提出 | Appleが最高裁に上訴理由書を提出（No. 25-1311） |
| 2026年11月13日 | 回答書提出期限 | Epic Gamesが回答書を提出予定 |
アプリ・Web間決済ループの構築
最高裁が民事侮辱罪の境界線をどう判断するかにかかわらず、開発者が外部決済リンクを実装してユーザーをWeb決済へ誘導できるという実務上の現実は変わりません。しかし、このハンドオフを実行するには、ストアフロント固有のフレームワークとモバイルWeb決済エンジニアリングの一般的な要件を区別する必要があります。
ストアフロントフレームワーク：米国ポリシーと地域のStoreKit外部購入フレームワーク
すべての外部決済リンクが同一のシステムAPIに依存しているという認識は、よくあるアーキテクチャの誤解です。開発者はストアフロントの地域や適用されるプログラムに基づいて実装を切り分ける必要があります：
- 米国ストアフロントフレームワーク: 2021年の差止命令以降、Apple App Store審査ガイドラインでは、米国のストアフロントを利用するアプリについて、特別な「StoreKit External Purchase Link Entitlement」プロファイルを必要とすることなく、IAP以外の決済手段へユーザーを誘導するボタンやリンクを許可しています。商業的条件、ティア評価、報告メカニズムは、適用される開発者契約に準拠します。
- 地域のStoreKit外部購入フレームワーク: 米国以外では、実装モデルは管轄区域やAppleのプログラムによって異なります。特定のストアフロント（欧州経済領域の一部やロシアの外部リンクプログラムなど）では、
ExternalPurchaseLink.open()を呼び出す際に継続シートを表示し、監査のためにApple生成の外部購入トークンをURLに付与する特定のStoreKit権利を使用します。韓国の代替決済やEUのビジネス条件など、その他の管轄区域やプログラムでは、個別のStoreKit API、通知シート、報告パイプラインが採用されています。さらに、EUにおいてAppleは2026年10月1日付で統合されたビジネス条件への移行を発表しており、実装時には適用されるストアフロントや契約に基づいて権利、API、手数料、報告要件を評価する必要があります。
双方向Web決済ループの構築
以下のアーキテクチャは、加盟店が設計した一般的な外部リンクフローを示しています。特定のプラットフォームプログラムの対象となるストアフロントでは、必要に応じて地域固有のStoreKit APIがアウトバウンド・ディスパッチステップを置き換えるか、ラップする場合があります。
- ブラウザへのアウトバウンド・ディスパッチ: アプリは対象となるコール・トゥ・アクション（CTA）やリンクボタンを表示します。ユーザー操作後、アプリは標準のシステムハンドラ（または地域の権利APIで義務付けられている場合はStoreKitシート）を使用して外部URLをディスパッチします。アプリは、ユーザーの意図を紐付けるために不透明で短命な決済セッション参照（例:
https://checkout.example.com/pay?session_ref=chk_99182）を付与します。機密性の高い個人データやアカウント認証情報をURLクエリ文字列で平文で渡すことは決して行ってはなりません。 - Web側での決済処理: Web決済ゲートウェイはセッション参照を取り込み、顧客認証を処理し、外部の決済代行業者（StripeやAdyenなど）を通じて決済を実行します。
- 加盟店バックエンドによる確認: 外部プロセッサが決済を完了すると、加盟店バックエンドはデータベース上で注文を「履行済み」とマークし、完了レシートを記録します。
- インバウンドの帰還ナビゲーション（ユニバーサルリンク）: 決済完了後、Webの完了ページは検証済みのAppleユニバーサルリンク（例:
https://checkout.example.com/payment-complete?order_ref=ord_8812）を使用してネイティブアプリへの帰還フローを開始します。 - デバイス上のシーン処理と権利の更新: OSはHTTPSユニバーサルリンクをインターセプトし、
scene(_:continue:)またはscene(_:willConnectTo:options:)を介してUIWindowSceneDelegateにペイロードを配信します。ネイティブアプリは不透明な注文参照を解析し、認証済みAPIを通じてバックエンドへクエリを行い、取引所有権を検証してユーザーの権利を更新します。
+-------------------------------------------------------------------------+ | 双方向アプリ・Web間決済パイプライン | +-------------------------------------------------------------------------+ | | | [ ネイティブiOSアプリ: ユーザーが外部決済オプションを選択 ] | | | | | |-- (UIApplication.shared.open経由でリンクをディスパッチ) | | v | | [ Safari / デフォルトWebブラウザ: 決済ポータルを開く ] | | URL: https://checkout.example.com/pay?session_ref=CHK_99182 | | | | | v | | [ Web決済ゲートウェイ: 外部取引を処理 ] | | | | | |-- (加盟店バックエンドが支払いを確認し、レシートを記録) | | v | | [ Web決済完了ページ: 検証済みユニバーサルリンクによる帰還フロー開始 ] | | URL: https://checkout.example.com/payment-complete?order_ref=ORD_8812 | | | | | v | | [ iOSがHTTPSドメインの関連付けをインターセプト (AASA検証済み) ] | | | | | +---------------------------------------+ | | | (アプリ起動済み) | (アプリ冷起動) | | v v | | [ scene(_:continue:) ] [ scene(_:willConnectTo:) ] | | | | | | +-------------------+-------------------+ | | | | | v | | [ アプリが加盟店バックエンドにクエリし、正当な権利を再取得 ] | | | | | v | | [ シーン階層で確認画面を表示し、デジタルアイテムをアンロック ] | | | +-------------------------------------------------------------------------+
このアーキテクチャは不可欠なセキュリティ境界を強化するものです：URLクエリパラメータを購買の正当な証明として決して使用してはなりません。 ユニバーサルリンクはあくまで帰還ルーティングのコンテキストを提供するものであり、デジタルコンテンツの履行については、常に加盟店のバックエンド課金サービスから直接再取得する必要があります。
// 外部Web決済からの安全な帰還ルーティングを示すSwiftの実装例。
// UIWindowSceneDelegate内でユニバーサルリンクを検証し、注文参照を解析し、
// ブラウザCookieに依存せず、セキュアなバックエンドを通じて権利を更新します。
import UIKit
struct CheckoutCompletionPayload {
let orderRef: String
}
final class PaymentReturnRouter {
static let shared = PaymentReturnRouter()
// ルーティングの防御境界を強制するためのホワイトリスト化されたホスト
private let authorizedHost = "checkout.example.com"
private let authorizedPathPrefix = "/payment-complete"
private init() {}
/// ユニバーサルリンクを解析し、決済完了の手がかりを抽出します
func parseReturnURL(_ url: URL) -> CheckoutCompletionPayload? {
guard let components = URLComponents(url: url, resolvingAgainstBaseURL: true),
components.scheme == "https",
components.host == authorizedHost,
components.path.hasPrefix(authorizedPathPrefix),
let queryItems = components.queryItems else {
return nil
}
guard let orderRef = queryItems.first(where: { $0.name == "order_ref" })?.value else {
return nil
}
return CheckoutCompletionPayload(orderRef: orderRef)
}
/// ビュー階層ナビゲーションを管理し、バックエンドへ取引検証を委任します
func handlePaymentCompletion(payload: CheckoutCompletionPayload, in window: UIWindow?) {
// 注意: URLクエリパラメータは購買の証明にはなりません。
// ネイティブアプリはクエリパラメータに関わらず、認証済みチャネルでバックエンドをクエリします。
BackendBillingService.shared.verifyExternalOrder(orderRef: payload.orderRef) { result in
DispatchQueue.main.async {
guard let nav = window?.rootViewController as? UINavigationController else { return }
switch result {
case .success(let orderState):
if orderState.isPaid {
let successVC = OrderSuccessViewController(orderRef: payload.orderRef, entitlements: orderState.entitlements)
nav.pushViewController(successVC, animated: true)
} else {
let pendingVC = OrderPendingViewController(orderRef: payload.orderRef)
nav.pushViewController(pendingVC, animated: true)
}
case .failure(let error):
print("正当な注文検証に失敗しました: \(error.localizedDescription)")
let failureVC = OrderFailureViewController()
nav.pushViewController(failureVC, animated: true)
}
}
}
}
}
// 冷起動および起動中のライフサイクルをまたいでユニバーサルリンクをキャプチャするSceneDelegate
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
var window: UIWindow?
// シナリオ 1: 起動時またはSafariから帰還時のシーン接続
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
guard let windowScene = scene as? UIWindowScene else { return }
let window = UIWindow(windowScene: windowScene)
let navigationController = UINavigationController(rootViewController: StorefrontViewController())
window.rootViewController = navigationController
self.window = window
window.makeKeyAndVisible()
if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
let incomingURL = userActivity.webpageURL,
let payload = PaymentReturnRouter.shared.parseReturnURL(incomingURL) {
PaymentReturnRouter.shared.handlePaymentCompletion(payload: payload, in: window)
}
}
// シナリオ 2: メモリ内で動作中の既存のシーンへのユニバーサルリンク配信
func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
let incomingURL = userActivity.webpageURL,
let payload = PaymentReturnRouter.shared.parseReturnURL(incomingURL) else {
return
}
PaymentReturnRouter.shared.handlePaymentCompletion(payload: payload, in: self.window)
}
}
struct OrderState {
let isPaid: Bool
let entitlements: [String]
}
final class BackendBillingService {
static let shared = BackendBillingService()
private init() {}
func verifyExternalOrder(orderRef: String, completion: @escaping (Result<OrderState, Error>) -> Void) {
// 取引状態と権利資格を確認するためにセキュアなAPIでバックエンドをクエリします
completion(.success(OrderState(isPaid: true, entitlements: ["unlimited_access", "premium_tier"])))
}
}
class StorefrontViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
title = "ストアフロント"
view.backgroundColor = .systemBackground
}
}
class OrderSuccessViewController: UIViewController {
let orderRef: String
let entitlements: [String]
init(orderRef: String, entitlements: [String]) {
self.orderRef = orderRef
self.entitlements = entitlements
super.init(nibName: nil, bundle: nil)
}
required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") }
override func viewDidLoad() {
super.viewDidLoad()
title = "注文完了"
view.backgroundColor = .systemGroupedBackground
}
}
class OrderPendingViewController: UIViewController {
let orderRef: String
init(orderRef: String) {
self.orderRef = orderRef
super.init(nibName: nil, bundle: nil)
}
required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") }
override func viewDidLoad() {
super.viewDidLoad()
title = "注文処理中"
view.backgroundColor = .secondarySystemBackground
}
}
class OrderFailureViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
title = "決済失敗"
view.backgroundColor = .systemGroupedBackground
}
}
ダウンストリームのモバイル獲得とインストールの境界
アプリ・Web間ルーティングは、インストール済みアプリからユーザーがWebへ抜けて決済を完了させるフローを制御するものですが、デジタルマーチャントはしばしば逆の課題に直面します。つまり、Webで新規顧客を獲得し、ネイティブアプリへと引き込むフローです。
マルチチャネルマーケティングキャンペーンにおいて、見込み客はSNSやコンテンツマーケティング、Web検索広告を通じてWebストアフロントやLPに頻繁に遭遇します。これらのページで、顧客がアカウント登録、サブスクリプション構成、あるいはプロモーションを選択してからネイティブアプリをインストールするケースがあります。
+-------------------------------------------------------------------------+ | 個別のダウンストリーム・モバイル獲得ジャーニー | +-------------------------------------------------------------------------+ | | | [ 外部接点: Webストアフロント / プロモーションLP ] | | キャプチャされたコンテキスト: ?campaign_id=fall_sale&promo_code=SAVE20&sku=8831 | | | | | v | | [ ユーザーがキャンペーンを操作 / 「モバイルアプリを入手」をクリック ] | | | | | v | | [ Apple App Storeへリダイレクト ] | | | | | v | | [ インストールの境界: App Storeの標準ダウンロードフローは | | 最初の起動時に任意のWebコンテキストを自動復元しない ] | | | | | v | | [ ユーザーが初回起動 (コールドブート) ] | | デフォルト動作: 標準ホーム画面を表示; Webキャンペーンコンテキストが消失 | | | | | v | | [ 遅延ディープリンク（DDL）エンジン: サーバー支援型の信号マッチング ] | | | | | v | | [ 復元されたコンテキスト: ログイン画面や特定の製品へルーティング ] | | | | | v | | [ アプリがユーザーを認証し、バックエンドが個別に権利を確定 ] | +-------------------------------------------------------------------------+
未インストールユーザーがモバイルWebストアからApp Storeに遷移する場合、OSの標準的な配信チャネルでは、キャンペーンタグ、アフィリエイトトークン、未完了注文参照などの任意のWebクエリパラメータが新しくインストールされたアプリバイナリに渡されることはありません。最初のコールドブート時、アプリはどのプロモーションやWebカタログがダウンロードの動機付けとなったかをネイティブに識別できません。
このインストールの境界を埋めるため、エンジニアリングチームは顧客ジャーニー全体にわたっていくつかのリンク処理フレームワークを評価します：
| ルーティングアーキテクチャ | ターゲットアプリの状態 | インストールを超えたパラメータ保持 | 運用保守モデル |
|---|---|---|---|
| カスタムURIスキーム | インストール済み | アプリ不在時に宛先なし; 個別のフォールバックが必要 | アプリ所有型 (高保守負荷) |
| 検証済みユニバーサルリンク | インストール済み | フォールバックWebページに解決; インストール後にWebコンテキストを自動復元しない | ドメイン+アプリ所有型 (AASAホスティングが必要) |
| 地域固有StoreKit外部購入API | インストール済み | ストアフロントとプログラムに依存; Appleの権利やシステム開示が必要 | プラットフォーム管理型 (地域ルールに従う) |
| 遅延ディープリンク (DDL) | 不在 | 初回の冷起動時にインストール前のパラメータを復元 | SDK支援型 (属性管理およびルーティングエンジン) |
実稼働中のモバイルアーキテクチャにおいて、開発チームはBranch、AppsFlyer、Adjust、または Opoinstall といった遅延ディープリンク（DDL）フレームワークを展開しています。Opoinstallのようなプラットフォームは、ユーザーがApp Storeに遷移する前に、キャンペーンIDや商品SKU参照などの適格なインストール前Webクリックメタデータを記録します。
アプリの初回コールドブート時、クライアントSDKは属性バックエンドをクエリし、初回起動のインスタンスと以前のWebクリックセッションをマッチングします。Opoinstallのホームページにある公式ドキュメントによると、この遅延パラメータ受け渡しフレームワークは、最大98%の適格なインスタンスで初回起動時にパラメータを復元でき、プロモーションコードの手動入力や一般的な初回起動ナビゲーションに代わる自動化された手段を提供します。
正確なアーキテクチャ境界を維持することは極めて重要です：遅延ディープリンクはユーザーアカウントを認証したり、支払いの所有権を証明したり、プラットフォームの審査ポリシーを回避したりするものではありません。 それはあくまで非正規のインストール前コンテキスト（注文参照やリファラルタグなど）を復元するものであり、アプリがユーザーを適切なログイン画面や引換画面へと案内するためのものです。バックエンドでの本人確認および権利の解放については、別途独立して実行されなければなりません。
よくある質問 (FAQ)
「Apple対Epic Games」訴訟で最高裁が決定することになった主要な争点は何ですか？
iOS上のすべての外部購入リンクには「StoreKit外部購入リンク権利」が必要ですか？
外部のWeb決済から戻る際、モバイルアプリはどのようにして状態を保持しますか？
モバイルエンジニアリングチームへの戦略的ガイダンス
「Apple対Epic Games」の最高裁審理は、モバイルアプリ市場を統治する法規制が絶えず進化していることを浮き彫りにしています。しかし、ソフトウェアアーキテクトや課金エンジニアは、司法判断を待つ間、決済ルーティングを後回しにする余裕はありません。
グローバルなiOSアプリを運用するエンジニアリング組織は、以下の3つのアーキテクチャ原則を基盤とすべきです：
-
地域別の決済ロジックの分離: 米国の標準的な外部リンクルールと、地域固有のStoreKit権利フレームワークの間で決済ルーティングの実装を分離し、多様な法的ストアフロント全体でのコンプライアンスを確保してください。
-
インバウンド・ユニバーサルリンクの強化:
UIWindowSceneDelegate内で、予期されるスキーム、ホスト、パスを検証するレジリエント（堅牢）なユニバーサルリンクハンドラーを構築し、受信するクエリパラメータは正当な取引レシートではなく「ルーティングのヒント」として扱ってください。 -
属性コンテキストと決済権限の分離: 遅延ディープリンクを活用してアプリインストールファネル全体でユーザーの意図を保持しつつ、アカウント認証やデジタル権利の付与については、セキュアで信頼のおけるバックエンドサービスによって厳格に強制されるようにしてください。
参考文献
-
米国最高裁判所. (2026). Docket for No. 25-1311, Apple Inc., Petitioner v. Epic Games, Inc..
-
米国最高裁判所. (2026). Brief for Petitioner Apple Inc., No. 25-1311.
-
米国第9巡回区控訴裁判所. (2025). Epic Games, Inc. v. Apple, Inc., No. 25-2935, 161 F.4th 1162.
-
Apple Developer. (2026). App Store審査ガイドライン. Apple Documentation.
-
Apple Developer. (2026). StoreKit外部購入リンク権利. Apple Documentation.
-
Apple Developer. (2026). アプリでのユニバーサルリンクのサポート. Apple Documentation.
-
Apple Developer. (2026). UIWindowSceneによるアプリのライフサイクル管理. Apple Documentation.
-
MacRumors. (2026). Apple Asks Supreme Court to Throw Out App Store Contempt Ruling.
-
AppleInsider. (2026). Apple standing its ground in Epic’s App Store fee suit.
-
Opoinstall. (2026). 遅延ディープリンクとパラメータ化されたアプリインストールの概要.
Share this article
