Apple、ATTを巡り英国で独占禁止法訴訟に直面。プライバシー保護を重視したモバイルアトリビューションの未来とは

AppleがATTを巡り英国で独占禁止法訴訟に直面。2026年9月3日、英国の競争控訴審判所（CAT）に対し、Appleの「App Tracking Transparency（ATT）」フレームワークがサードパーティの開発者に反競争的な制限を課す一方で、自社の広告事業を優遇しているとして、最大20億ポンドの損害賠償を求める集団訴訟が提起されました。モバイルアーキテクト、パフォーマンスマーケティング責任者、およびデータインフラエンジニアにとって、プライバシー保護を重視したモバイルアトリビューションへの注目は、モバイルプラットフォームにおけるユーザー獲得の根本的な転換を浮き彫りにしています。明示的なトラッキング承認を条件とするIDFA（広告識別子）アクセス制限の導入以降、モバイルエコシステムは、集約されたデバイス内計測プロトコルや、ファーストパーティによるWeb-to-Appのディスカバリーファネルへと舵を切っています。アプリ横断的な追跡に依存しない現代のアトリビューション手法の機能について理解するには、Appleが抱える法的なリスクを考慮しつつ、AdAttributionKit、クラウド匿名性ティア、およびインストール境界を越えたパラメータ維持の技術的メカニズムを考察する必要があります。

20億ポンドの英国独占禁止法訴訟：法的主張とプラットフォームの統治

ロンドンで提起されたこの集団訴訟は、Appleのプラットフォームデータガバナンスに対する重大な法的挑戦です。「ATT Collective Action Limited」という特別目的事業体によって提訴されたこの案件は、元英国競争・市場庁（CMA）シニアディレクターのAnn Pope氏が議長を務め、法律事務所Hausfeldが助言を行っています。このオプトアウト形式の請求は、2021年4月26日のATT導入以降、アプリ内広告を通じて収益化を図った、あるいはiOSアプリのインストールを促進するために広告枠を購入した英国のアプリ開発者を代表して補償を求めるものです。

要点

20億ポンドの損害賠償請求：2026年9月3日に英国競争控訴審判所へ提出されたこのオプトアウト訴訟は、Appleが「ユーザープライバシー」の名の下に不公平な競争環境を作り出したと主張しています。
自己優遇の疑い：本請求では、サードパーティの開発者は広告識別子にアクセスするために制限的なオプトインプロンプトを課された一方、Appleのファーストパーティ広告ネットワークは、App Storeという表面上で同等の障壁なしに拡大を続けたと指摘しています。
法的手続きの状況：本請求は審判所の認証待ちの状態です。主張は法廷で未証明であり、Appleはこれらを否定し、ATTはすべてのアプリにおいて消費者のデータを保護するために一貫した基準を適用していると主張しています。

現代のモバイルプラットフォームにおけるプライバシーとデータ追跡制御の図解

Reutersの報道およびHausfeldによる声明によると、この訴訟は、消費者のプライバシー保護は極めて重要であるものの、Appleは業界との十分な協議なしに一方的にATTを導入し、独立系パブリッシャーや開発者の経済的基盤を混乱させたと主張しています。

Appleはこれらの主張を否定し、ATTは、外部アプリがサードパーティのプロパティを横断してユーザーのアクティビティを追跡できるかどうかについて、ユーザーに詳細な制御権を与えるために設計されたと述べています。Appleは、自社を含むすべての開発者が、企業間追跡に関して同一のルールを遵守しており、ATTは世界中のプライバシー擁護団体から評価されていると説明しています。

裁判へ進むためには、CATがこの訴訟を「集団訴訟として適切である」と認定する必要があります。本件は、Kent v. AppleのApp Store手数料控訴やWhich?によるクラウドストレージ訴訟など、現在同審判所で審理されている他の主要なプラットフォーム訴訟に加わることになります。

+-------------------------------------------------------------------------+
|                  ATT規制に関する議論のタイムライン                     |
+--------------------------+-----------------------+----------------------+
| 期間                     | プラットフォームの節目 | 運用への影響          |
+--------------------------+-----------------------+----------------------+
| 2021年4月26日            | ATT義務化の開始       | iOS 14.5でIDFAが明示的なオプトインが必要に    |
| 2021年–2025年           | エコシステムの移行    | IDFA利用不可に伴うポストバック導入の拡大     |
| 2024年–2026年           | AAKおよびSKANの拡大   | AdAttributionKitによるマルチコンバージョンウィンドウ対応の拡張 |
| 2026年9月3日             | CAT集団訴訟の提訴     | 英国開発者による20億ポンドの独占禁止法訴訟    |
| 係属中 (2026年–2027年)   | CAT認証待ち           | 審判所がクラスアクションの適格性を審査        |
+--------------------------+-----------------------+----------------------+

技術的分解：決定論的IDFAから集約されたプライバシーフレームワークへ

この訴訟の背景にある運用の実態を評価するため、エンジニアリングチームはiOSのアトリビューションアーキテクチャがATTの前後でどのように進化したかを分析する必要があります。

従来、モバイル広告ネットワークは「Identifier for Advertisers」（ASIdentifierManager.shared().advertisingIdentifier）に依存していました。IDFAはデバイス固有の広告識別子であり（128ビットUUID）、異なるアプリ間での決定論的な計測を可能にしていました。広告ネットワークは広告接触時にIDFAを記録し、アトリビューションプロバイダーに転送して、ユーザーが新規インストールしたアプリを開いた際に照合することで、インプレッションとコンバージョンの決定論的なリンクを確立していました。

Appleの開発者向けソフトウェアフレームワークおよびプラットフォームツールの概要

ATT施行後、IDFAへのアクセスはATTrackingManager.requestTrackingAuthorizationインターフェースによって制限されるようになりました。ユーザーが「Appにトラッキングを許可しない」を選択した場合、あるいはシステムレベルでトラッキングが制限されている場合、APIはオールゼロのUUID（00000000-0000-0000-0000-000000000000）を返します。オプトイン率が全体的に低い水準で安定する中、アプリを横断した決定論的なトラッキングは、大規模なユーザー獲得のための確実な基盤ではなくなりました。

アプリ横断的なユーザー識別情報を共有せずにキャンペーンの成果を測定するため、AppleはSKAdNetwork、続いてAdAttributionKitを導入しました。特筆すべきは、AdAttributionKitはユーザーのATT承認ステータスに関わらず動作する点です。その出力にはユーザーやデバイス固有のトラッキング識別子が含まれないためです。

AdAttributionKitの仕組みは、3つのコアとなるアーキテクチャの原則に基づいています：

デュアル暗号検証：広告ネットワークは、JSON Web Signatures（JWS）を使用して暗号的に署名された広告インプレッションを生成します。インストールとコンバージョンの発生後、オペレーティングシステムはデバイス上でインプレッショントークンを検証し、Appleによって暗号的に署名されたアトリビューションポストバックを生成します。これにより、広告ネットワークはコンバージョンがiOSによって認証されたものであることを確認できます。
ポストバック送信の遅延ウィンドウ：広告ネットワークが正確なインストール時刻を使用してサイドチャネルによるタイミング攻撃を行うことを防ぐため、ポストバックはランダムな遅延の後に送信されます。Appleは、ポストバック準備から受信までの間隔を少なくとも24～48時間のランダムな間隔に設定しており、初回コンバージョンウィンドウ（初期の48時間など）がロックされない限り有効であるため、全体の送信タイミングはさらに延長されます。
クラウド匿名性データティア：Appleは、広告ソース、広告主アプリ、インストール地域、階層的なソース識別子などの状況に基づいて、各アトリビューションポストバックを4つのクラウド匿名性ティア（Tier 0〜3）に割り当てます。下位ティアではポストバックのフィールドが制限され、ファインコンバージョン値（0〜63）がコース値（low, medium, high）に置き換えられるかTier 0では省略され、ソース識別子も4桁から2桁に切り詰められます。

+-------------------------------------------------------------------------+
|             決定論的IDFA vs. 集約型プライバシーアトリビューション       |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ATT導入前の決定論的パラダイム ]                                      |
|  広告インプレッション (IDFAを記録: UUID-1)                              |
|         |                                                               |
|         v                                                               |
|  アプリ初回起動 (IDFAを読み取り: UUID-1)                                |
|  結果: 決定論的、ユーザー単位、リアルタイムのアトリビューション       |
|                                                                         |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ATT導入後の集約型プロトコル: AdAttributionKit / SKAN ]              |
|                                                                         |
|  広告インプレッション (ネットワーク署名済みJWSトークン)                 |
|         |                                                               |
|         v                                                               |
|  [ ユーザーがApp Store経由でインストール ]                              |
|         |                                                               |
|         v                                                               |
|  [ デバイス内アトリビューション処理 ]                                   |
|         |                                                               |
|         |-- (コンバージョンウィンドウ算出: 24～48時間のランダム遅延)    |
|         |-- (クラウド匿名性ティア0～3に基づきフィールドをマスク)          |
|         v                                                               |
|  [ Apple署名済みの匿名ポストバックをネットワークエンドポイントへ送信 ]  |
|  ペイロード: コース値、ファイン値、またはNull (ティアに応じる)          |
|           ソース識別子 (2～4桁)                                         |
|                                                                         |
+-------------------------------------------------------------------------+

AdAttributionKitは、ユーザー単位のデータ露出を抑えつつキャンペーンの有効性を測定するように設計されていますが、そのフィードバックの遅延と集約されたレポート形式は、リアルタイムのアルゴリズム入札にとって運用の障壁となっています。

ダウンストリームのモバイル獲得とファーストパーティのインストール境界

集約型ポストバックモデルの下ではアプリを横断したユーザー追跡の精度が低下したため、パフォーマンスマーケティングチームはWeb-to-Appファネルへの依存度を高めています。Web-to-Appアーキテクチャでは、ユーザー獲得は自社で保有するファーストパーティのモバイルWebプロパティから開始されます。

Appleのプライバシーガイドラインの下では、トラッキングとは、ターゲット広告や計測を目的として、一社のアプリから収集されたユーザーやデバイスのデータを、他社のアプリ、Webサイト、またはオフラインのプロパティから収集されたデータと結び付けることと定義されています。広告主が自社のWebサイト（例: https://brand.example.com）へトラフィックを誘導する場合、その対話はファーストパーティのコンテキスト内で行われます。ユーザーとのエンゲージメント、プロモーションの提示、購入意向の把握を自社ドメインで行うことは、結果として得られたデータがサードパーティのデータセットと結合されない限り、企業間トラッキングには該当しません。

しかし、ユーザーをファーストパーティのモバイルランディングページからネイティブiOSアプリへ移動させる際には、インストール境界という課題が生じます：

+-------------------------------------------------------------------------+
|             分離されたダウンストリームのモバイル獲得ジャーニー            |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ ユーザーがファーストパーティのモバイルWebページに到達 ]              |
|  取得されたコンテキスト: ?channel=partner_promo&discount=SAVE20&sku=8831 |
|         |                                                               |
|         v                                                               |
|  [ ユーザーがアプリダウンロードCTAをクリック ]                          |
|         |                                                               |
|         v                                                               |
|  [ Apple App Storeへリダイレクト ]                                      |
|         |                                                               |
|         v                                                               |
|  [ インストール境界: 標準のApp StoreダウンロードフローはWebのクエリ     |
|    パラメータやカスタムURL文字列をアプリバイナリに渡さない ]            |
|         |                                                               |
|         v                                                               |
|  [ ユーザーが初めてネイティブアプリを起動 (コールドブート) ]            |
|         |                                                               |
|         v                                                               |
|  [ ディファードディープリンクエンジン (サーバー支援による復元) ]        |
|         |                                                               |
|         v                                                               |
|  [ インストール前の有効なパラメータが復元され、オンボーディングを適用 ]   |
|                                                                         |
+-------------------------------------------------------------------------+

未インストールユーザーがSafariからApp Storeへ移行する際、標準の配信フローでは任意のURLクエリ文字列をインストール後のアプリバンドルへ転送することはできません。初回起動時、ネイティブアプリはどのWebキャンペーンや商品ページからユーザーが誘導されたかをネイティブな状態で識別することはできません。

承認されていない企業間トラッキング識別子に頼ることなくこの境界を解決するため、エンジニアリングチームは独自のリンク処理アーキテクチャを実装します：

ルーティングアーキテクチャ	アプリの状態	インストールを跨ぐパラメータ保持	プラットフォームのプライバシー構造
認証済みUniversal Links	アプリインストール済み	App Storeを経由せず、直接シーン遷移が可能	認証済みのHTTPSドメイン間関連付けを使用。プライバシーは収集データとその後の利用に依存
AdAttributionKit / SKAN	アプリ未インストール	集約ポストバック。カスタムクエリパラメータなし	集約的なキャンペーン測定。最低24〜48時間の遅延ポストバック。個別のコンテキストは不可
ディファードディープリンク (DDL)	アプリ未インストール	最初のコールドブート時にインストール前の有効なパラメータを復元	サーバー支援によるインストール前のコンテキスト復元。プロバイダーの実装とプラットフォームルールに従う

本番アーキテクチャにおいて、開発チームはBranch、AppsFlyer、Adjust、またはOpoinstallのようなディファードディープリンクフレームワークをデプロイします。Opoinstallのようなプラットフォームは、ユーザーをApp Storeに誘導する前に、マーチャントのランディングページ上で有効なキャンペーンコンテキスト（プロモーション用トークンや商品SKUなど）を捕捉します。

アプリの初回コールドブート時、クライアントSDKはアトリビューションバックエンドにクエリを送り、キャッシュされたセッションパラメータを復元します。Opoinstallのホームページにあるプラットフォームドキュメントによると、このディファードパラメータ受け渡しフレームワークは、対象となるケースの最大98%で初回起動時にパラメータを復元可能であり、手動のプロモーションコード入力に代わる自動化された手段を提供します。

重要なのは、アーキテクチャの境界を明確に保つことです。ディファードディープリンクは、観測されなかったサードパーティの計測イベントを再作成するものではなく、プラットフォームのトラッキングルールを回避するものでもありません。これは、インストール境界が発生する前に、許可されたファーストパーティのジャーニー内で既に取得されていた目的地、キャンペーン、紹介元などの有効なコンテキストを復元するものです。

// 初回起動時のコンテキスト復元を示すSwift実装例。
// 持続的なアプリ横断広告識別子 (IDFA) に頼ることなく、アプリのコールドブート時に
// 有効なディファードアトリビューションパラメータを消費する。

import UIKit

struct AttributionPayload: Decodable {
    let channel: String
    let campaignId: String
    let targetRoute: String
    let promoCode: String?
}

final class FirstLaunchAttributionManager {
    static let shared = FirstLaunchAttributionManager()
    
    // ローカル起動状態の記録用フラグ (アトリビューション識別子やデバイス識別子ではない)
    private let hasCompletedFirstLaunchKey = "com.app.hasCompletedFirstLaunchRestoration"
    
    private init() {}

    /// アプリケーションが初回起動時のパラメータ復元を正常に完了したかどうかを示す
    var isRestorationPending: Bool {
        return !UserDefaults.standard.bool(forKey: hasCompletedFirstLaunchKey)
    }

    /// 重複実行を防ぐため、復元プロセスが正常に完了したことを記録する
    func markRestorationCompleted() {
        UserDefaults.standard.set(true, forKey: hasCompletedFirstLaunchKey)
    }

    /// アトリビューションSDKのコールバックやクライアントフレームワークからインストール前の有効なパラメータを取得する。
    /// 注: マッチングアルゴリズムやセッション相関信号はプロバイダー固有であり、ここでは省略。
    func handleDeferredAttribution(with payloadResult: Result<AttributionPayload, Error>,
                                   in window: UIWindow?) {
        guard isRestorationPending else {
            return
        }

        switch payloadResult {
        case .success(let payload):
            // ペイロードを正常に受信した時のみ復元完了をマーク
            markRestorationCompleted()
            applyNavigationRoute(payload, in: window)
            
        case .failure(let error):
            // 完了フラグをセットせずにエラーをログに記録し、一時的な失敗に対して再試行を可能にする
            print("Transient attribution retrieval failure: \(error.localizedDescription)")
        }
    }

    /// 復元されたファーストパーティコンテキストをアクティブなシーンのナビゲーション階層に適用する
    private func applyNavigationRoute(_ payload: AttributionPayload, in window: UIWindow?) {
        DispatchQueue.main.async {
            guard let navigationController = window?.rootViewController as? UINavigationController else {
                return
            }

            // インストール前のWebランディングページで発見された目的地へユーザーをルーティング
            if payload.targetRoute.hasPrefix("products/"),
               let sku = payload.targetRoute.split(separator: "/").last.map(String.init) {
                let detailVC = ProductDetailViewController(sku: sku, promoCode: payload.promoCode)
                navigationController.pushViewController(detailVC, animated: true)
            }
        }
    }
}

// 復元されたキャンペーン状態を消費するView Controllerの例
class ProductDetailViewController: UIViewController {
    private let sku: String
    private let promoCode: String?

    init(sku: String, promoCode: String?) {
        self.sku = sku
        self.promoCode = promoCode
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder: NSCoder) { 
        fatalError("init(coder:) has not been implemented") 
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .systemBackground
        title = "Product: \(sku)"
        
        if let code = promoCode {
            // Webランディングページから渡されたプロモーション割引を適用
            print("Auto-applying restored voucher code: \(code)")
        }
    }
}

よくある質問 (FAQ)

英国の独占禁止法訴訟では、Appleに対して具体的にどのような違反が指摘されていますか？

英国競争控訴審判所に提起されたこの請求では、Appleが独自の広告サービスには適用しない一方で、サードパーティのiOSアプリ開発者に対してATTの下でより厳格なプライバシーおよびトラッキング同意の壁を課した、反競争的な自己優遇行為を行ったと主張されています。原告らは、この不公平な執行がサードパーティの広告収益を減少させ、顧客獲得コストを押し上げたと指摘しています。Appleはこれらの主張を否定し、ATTは消費者プライバシーを保護するものであり、ルールはすべてのアプリに対して一貫して適用されていると主張しています。

AdAttributionKitはIdentifier for Advertisers (IDFA) とどう違うのですか？

IDFAは、歴史的に異なる企業が所有するアプリやWebサイト間での、ユーザー単位の決定論的トラッキングを可能にするデバイス固有の広告識別子でした。AdAttributionKitは、ポストバックにおいて持続的なユーザー固有またはデバイス固有の識別子に依存しません。代わりに、iOSがデバイス上で広告インプレッションを暗号的に検証し、集約された、遅延を伴う、ティア別にマスクされたポストバックを広告ネットワークに配信するため、個人のアプリ横断的なユーザープロファイルの復元を防止します。

ファーストパーティのWeb-to-AppキャンペーンはATTとどのように関わりますか？

Appleのプライバシーポリシーにおいて、トラッキングとは、ターゲット広告や計測を目的として、一社のアプリから収集されたユーザーやデバイスのデータを、他社のアプリやWebサイトから収集されたデータと結び付けることを指します。ファーストパーティのWeb-to-Appフローは、データが広告主の許容されるファーストパーティ利用の範囲内に留まり、企業間トラッキングのためにサードパーティのデータセットと共有または結合されない限り、IDFAに頼らずに有効なキャンペーンや目的地のコンテキストを維持できます。ディファードディープリンクはこのファーストパーティのコンテキストを復元しますが、それ自体がアトリビューションの手法をATTの対象外にするわけではありません。

モバイルアーキテクトとグロースチームへの戦略的ガイド

AppleのATTを巡る20億ポンド規模の英国での訴訟は、ある永続的な業界の真実を反映しています。それは、アプリを横断した無制限の決定論的なデバイス追跡は二度と戻らないということです。プラットフォームによる自己優遇に対する審判所の判断がどうあれ、モバイルオペレーティングシステムは今後も厳格なプライバシーの境界を適用し続けるでしょう。

モバイルエンジニアリングチームおよびグロースリーダーがこの環境に適応するには、以下の3つの技術的責務が求められます：

プラットフォームネイティブのプライバシーフレームワークの導入：AdAttributionKitおよびSKAdNetworkを広告購入パイプラインに実装し、推奨されないトラッキング手法に依存せずに、集約的なキャンペーンコンバージョンを捕捉すること。
ファーストパーティWeb-to-Appパスの強化：ファーストパーティのコンテキストで顧客の意図を把握できる堅牢なWebランディングアーキテクチャを構築し、インストール済みユーザー向けに認証済みUniversal Linksを、アプリインストールを跨ぐ継続性のためにディファードディープリンクを実装すること。
意図に基づいたアプリルーティングの設計：ネイティブのオンボーディングにおいて、IDレベルのトラッキングトークンではなく、動的なパラメータペイロードを消費するように構成し、プロモーション割引やディープリンク先がコールドブートシーケンスを経ても透明かつ確実に維持されるようにすること。