ブログ・ 2026年3月13日

SafariのITPとトラッキング防止機能に合わせたiOS SDKの最適化 (JA)

SafariのIntelligent Tracking Prevention（ITP）やその他のプライバシー機能は常に進化しており、従来のトラッキング手法に依存するiOS SDKにとって課題となっています。この記事では、SafariのITPとトラッキング防止機能に合わせたiOS SDKの最適化方法を解説します。.

By Didit2026年3月13日更新日 2026年5月21日

ファーストパーティコンテキストの活用SafariのITPはサードパーティCookieを厳しく制限します。可能な限りファーストパーティコンテキストで動作するようにiOS SDKを設計し、サーバーサイドのソリューションや直接統合を活用しましょう。

プライバシー保護識別子の優先永続的なクロスサイト識別子から脱却しましょう。一時的またはユーザーの同意に基づいた識別子に焦点を当て、ユーザーのプライバシー設定とAppleのApp Tracking Transparencyフレームワークを尊重してください。

堅牢なフォールバックの実装一部のデータポイントやトラッキングメカニズムがブロックされる可能性があることを想定してください。ITPがアクティブな場合でもコア機能を維持できるよう、段階的な機能低下とフォールバック戦略を用いてSDKを構築しましょう。

Appleのポリシーを常に把握ITPとプライバシーポリシーは動的です。SDKが準拠し、効果的であり続けるために、Appleの開発者向けドキュメントとプライバシーアップデートを定期的に確認してください。

SafariのIntelligent Tracking Prevention（ITP）は、特にサードパーティCookieや永続的な識別子に依存する開発者にとって、ウェブトラッキングの状況を根本的に変えました。iOS SDKにとって、これは特にウェブビューとの統合やクロスドメイン通信を扱う際に、特有の課題をもたらします。App Tracking Transparency（ATT）のような機能やデータ収集に関するより厳格なポリシーによって強化された、ユーザープライバシーに対するAppleの継続的なコミットメントは、SDK開発者が機能性を確保し、データの整合性を維持し、ユーザーの同意を尊重するために、積極的に戦略を適応させる必要があることを意味します。

このブログ記事では、iOS上のSafariにおけるITPと類似のプライバシーメカニズムの複雑さに深く踏み込み、SDKを最適化するための実用的な洞察と実践的な例を提供します。私たちの目標は、信頼性の高いだけでなく、プライバシー意識が高まるデジタル世界でユーザーの信頼を育む、堅牢でプライバシーを保護するSDKを構築するお手伝いをすることです。

SafariのITPとiOS SDKへの影響を理解する

Intelligent Tracking Prevention（ITP）は、Safari（およびWebKit）に組み込まれたプライバシー強化技術のセットです。その主な機能は、サードパーティによるCookieやその他のウェブサイトデータの使用を制限することで、クロスサイトトラッキングを制限することです。長年にわたり、ITPはいくつかのイテレーションを経て進化し、それぞれがより厳格な制御を導入してきました。

サードパーティCookieのブロック: 最も重要な側面です。ITPはサードパーティCookieを積極的に分割またはブロックし、広告主や分析プロバイダーが異なるウェブサイト間でユーザーを追跡することを困難にしています。
Storage Access API: ユーザーが埋め込みコンテンツと対話したときに、そのファーストパーティストレージへのアクセスを要求するためのプライバシー保護の方法として導入されました。
リンク装飾保護: ITPは、リンク装飾によるトラッキングを防ぐために、URLからトラッキングパラメータを削除することもできます。
リファラーポリシー: Safariは、より制限的なリファラーポリシー（例：strict-origin-when-cross-origin）を送信することが多く、サードパーティサイトに渡される情報の量を制限します。
一時的なバウンストラッキング防止: トラッカーが自身のサイトを介してユーザーをリダイレクトしてファーストパーティCookieを設定する手法を特定し、軽減します。

iOS SDK、特にウェブコンテンツ（例：アプリ内ブラウザ、認証フロー、決済ゲートウェイ、埋め込み分析など）と連携するSDKにとって、ITPの影響は甚大です。SDKがWKWebView内のサードパーティドメインからCookieを設定または読み取ることに依存している場合、または特定のreferrer情報が渡されることを期待している場合、ITPはこれらのメカニズムを破壊し、次の問題を引き起こす可能性があります。

認証または支払いプロセスの失敗。
不正確なアトリビューションまたは分析データ。
状態またはセッション情報の欠落によるユーザーエクスペリエンスの破損。

ITP対策のiOS SDK開発戦略

ITPに適応するには、従来のトラッキングからプライバシー中心のデータ処理へと考え方を転換する必要があります。以下に主要な戦略を示します。

1. ファーストパーティコンテキストとサーバーサイドソリューションを優先する

サードパーティCookieに対するITPの制限を回避する最も効果的な方法は、ファーストパーティコンテキスト内で動作することです。これは、Cookieを設定したりストレージにアクセスしたりするドメインが、ユーザーが現在訪問しているドメインと同じであることを意味します。

実例: 分析のためのサーバーサイドトラッキング

独自のCookieを設定しようとするWKWebViewに埋め込まれたサードパーティの分析スクリプトに依存する代わりに、サーバーサイドのアプローチを検討してください。

SDKがデータを収集: iOSアプリ（またはWKWebView内のウェブコンテンツ）が、関連するユーザーインタラクションデータ（例：閲覧した製品、クリックされたボタン）を収集します。
データをバックエンドに送信: このデータは、独自のバックエンドサーバーに直接送信されます。
バックエンドが分析プロバイダーに転送: その後、バックエンドがこのデータを分析プロバイダーのAPIに転送します。この通信はサーバー間で発生するため、クライアントサイドのCookieに対するITPの制限を回避します。

このアプローチにより、データを完全に制御し、確実に送信され、ブラウザサイドのトラッキング防止の対象とならないようにすることができます。

2. クロスサイトのニーズにはStorage Access APIを活用する

埋め込みWKWebView内でクロスサイトCookieへのアクセスが絶対に必要となる場合（例：IDプロバイダーとのシングルサインオン）、Storage Access APIは承認されたプライバシー保護の方法です。このAPIにより、サードパーティコンテンツは、ユーザーから明示的な許可を要求して、そのファーストパーティストレージにアクセスできます。

実例: `WKWebView`でのシームレスなSSO

SDKが認証フローのためにWKWebViewを埋め込み、SSOを実現するためにIDプロバイダー（IDP）からのCookieにアクセスする必要がある状況を想像してください。Storage Access APIがなければ、SafariはこれらのCookieをブロックします。

クライアントサイド（埋め込みウェブコンテンツ内）:

document.requestStorageAccess().then(function() {
    // ストレージアクセスが許可されました。これでCookieを使用するリクエストを行うことができます
    // 例: SSO iframeを読み込むか、IDPにXHRリクエストを行う
}).catch(function() {
    // ストレージアクセスが拒否されたか、ユーザーの操作が必要です
    // 適切に処理し、完全なリダイレクトログインにフォールバックする可能性があります
});

iOS SDK（WKUIDelegateおよびWKNavigationDelegate）:

Safariが表示するユーザープロンプトを処理する必要があります。WKUIDelegateメソッドwebView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler:（または類似の許可リクエスト）が呼び出される可能性がありますが、ストレージアクセスの場合、プロンプトは通常Safari自体によって処理されます。WKWebViewConfigurationが正しく設定されていること、特にwebsiteDataStoreを確認してください。

3. プライバシー保護識別子とユーザーの同意を採用する

App Tracking Transparency（ATT）により、Appleは他の企業が所有するアプリやウェブサイト間でトラッキングを行うために、ユーザーの明示的な同意を要求しています。SDKはこれを尊重する必要があります。同意なしにトラッキング目的で永続的なデバイス識別子に依存するのをやめましょう。

実例: ATTとIDFAの処理

SDKが以前、アトリビューションやターゲティングのために広告識別子（IDFA）に依存していた場合:

ATT承認を要求: AppTrackingTransparency.frameworkを使用して、IDFAにアクセスする前にユーザーの承認を要求します。
条件付きIDFA使用: ユーザーが許可を与えた場合にのみIDFAを取得して使用します。
代替識別子: 拒否された場合は、コンテキスト固有の一時的な識別子（例：セッションID）またはサーバー生成の永続的ではないID（クロスサイトトラッキングには使用されない）に依存します。

Swiftの例:

import AppTrackingTransparency
import AdSupport

func requestTrackingAuthorization() {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
                print("IDFA: \(idfa)")
                // 同意されたトラッキングにIDFAを使用
            case .denied, .notDetermined, .restricted:
                print("ATT承認が拒否されたか、未決定です。")
                // 他のプライバシー保護方法に依存
            @unknown default:
                break
            }
        }
    } else {
        // iOS 14より前のバージョンへのフォールバック
        // ASIdentifierManager.shared().isAdvertisingTrackingEnabled を介してトラッキングが有効になっているかを確認
    }
}

Diditがどのように役立つか

DiditはオールインワンのIDプラットフォームとして、プライバシーファーストのアプローチを本質的に採用しており、ITPや類似のトラッキング防止メカニズムに対して堅牢です。私たちの核となる焦点は、クロスサイトトラッキングではなく、実際の人間を安全に検証することです。Diditのアーキテクチャは、単一の制御されたシステム内で本人確認、生体認証、不正検出、認証を処理するように設計されており、サードパーティのトラッキングCookieへの依存を最小限に抑えています。これは、次の方法で実現されています。

ファーストパーティ統合: DiditのSDKとAPIは、アプリケーションへの直接的なファーストパーティ統合のために設計されており、本人確認プロセスがアプリのコンテキスト内で発生することを保証し、クロスサイトトラッキングに関連するITPの懸念を大幅に回避します。
サーバーサイド処理: AMLスクリーニングや不正信号分析など、Diditの多くの堅牢な機能はサーバー間で動作します。これは、機密データ処理と本人確認がバックエンドで安全に行われ、クライアントサイドのトラッキングの脆弱性を排除することを意味します。
一時的な生体認証: Diditは生体認証データをメモリ内で処理し、削除し、ブール結果のみをアプリケーションに返します。この「プライバシーバイデザイン」のアプローチは、トラッキングのために永続的な生体認証識別子を保存しないことを意味し、ITPの目標と完全に一致しています。
安全な認証フロー: 生体認証再認証を含む当社の認証方法は、状態管理のためにクロスサイトCookieに依存しないチャレンジレスポンスメカニズムを使用して、安全でプライベートであるように構築されています。
コンプライアンスと信頼: SOC 2 Type II、ISO 27001、およびGDPRに準拠しているDiditは、データプライバシーとセキュリティの基盤の上に構築されており、これにより当社のプラットフォームはトラッキング防止技術の変化に対して自然に回復力があります。

始めませんか？

SafariのITPと広範なプライバシー環境にiOS SDKを適応させることは、単なるコンプライアンスの問題ではありません。それは、ユーザーとの信頼を築き、製品の寿命を確保することです。ファーストパーティコンテキストを受け入れ、Storage Accessなどの適切なAPIを活用し、ユーザーの同意を優先し、Appleの進化するポリシーについて常に情報を得ることで、堅牢でプライバシーを尊重するSDKを作成できます。

DiditのプライバシーファーストのIDプラットフォームが、コンプライアンスを簡素化し、ユーザーエクスペリエンスを向上させる方法をご覧ください。ウェブサイトにアクセスするか、技術ドキュメントを確認するか、デモをリクエストして、Diditの動作をご覧ください。