iOS 27.2 ATTのEU新しい提示をどう検収する？2026年チェックリスト

ATTの適用判定

iOS 27.2のATTのEU提示では、どこが変わりますか。
Appleのリリースノートが示すのは、EU向け代替提示と、EUユーザーが年次で再リクエストできる機能です。これは追跡の定義や、ATTを利用すべき条件そのものが変わったという意味ではありません。変更点は27.2 Betaのリリースノートで確認し、Betaの記述を正式版にも恒久的に適用される仕様として扱わないでください。

アプリの配信地域と、ATTによる許可リクエストが必要かどうかは別々に判定します。広告文やプライバシー表示の説明だけで決めず、アプリやSDKが取得したデータを、他社のアプリ・ウェブサイトのデータと結び付けて広告や計測に使うか、実際のデータフローを追ってください。AppTrackingTransparencyの概要とAppleの追跡の定義を照合し、該当しない場合は「EUで配信するから」という理由だけで許可画面を出さないようにします。

自社サービス内だけの利用状況分析と、他社サービスをまたぐ追跡も区別が必要です。SDKを追加した後にデータ共有の範囲が変わることがあるため、実装担当者だけでなく、広告・分析SDKの設定を管理する担当者も確認対象に含めます。

地域別の提示と配信条件

ATTのEU代替提示が表示対象となる国はどこですか。
Appleのプライバシー資料では、フランス、ドイツ、イタリア、ポーランド、ルーマニアについて、適用対象に提供されるシステム提示は代替版のみと説明されています。その他のEU地域では、代替提示を利用できる条件が異なるため、全EUで同じ画面が出ると想定せず、Appleの地域別案内を確認します。

国名だけをテスト条件にしても、実利用者への表示を完全には再現できません。アプリの配信範囲、端末やアカウントの状態、OSのBetaかどうかを記録し、「端末の所在地」「アカウントの地域」「App Storeでの配信地域」を同じ条件として扱わないことが重要です。Appleが示す地域の適用条件に照らし、テスト端末で画面表示を確認してください。

以下の比較表を使い、地域・提示の種類・実際の表示を別々に記録します。地域条件を確認できない場合は、判定を推測で埋めず、未確認として残します。

説明文とシステム画面の分離

ATTを利用するアプリは、既存のATTrackingManager.requestTrackingAuthorizationの呼び出しと、NSUserTrackingUsageDescriptionの内容を確認してください。システムが表示する許可画面にアプリ独自の事前説明を足す場合も、その説明をATTの正式なシステム提示と混同しないようにします。許可リクエストAPIとNSUserTrackingUsageDescriptionの設定要件に沿って、呼び出し条件と説明文を点検します。

ATTのEU代替提示には、どの説明文を追加すればよいですか。
追加説明を使う場合は、NSUserTrackingMarkdownUsageDescriptionが提供する役割と書式をAppleの現行資料で確認します。これはすべてのアプリに必須の新しい許可理由ではありません。追跡の目的を具体的に説明し、許可しなければ基本機能が使えないと誤認させる表現や、同意を誘導する文言は避けてください。

Markdownの表現や翻訳を更新したときは、ソース上の文字列だけでなく、対象言語の端末で実際の表示を確認します。改行、リンク、強調表示が読めるか、追跡目的の説明が広告・分析SDKの実際の動作と一致するかも、文案の責任者と実装担当者で照合します。補足説明の表示と許可の判断は別の操作として記録してください。

ユーザー状態別の再現確認

「画面が表示されなかった」だけでは、テスト合格とは判断できません。未決定、許可、拒否、端末側の制限、アプリからの許可リクエストを無効にする設定を分け、ATTの許可状態と画面表示、コールバックを照合します。

ATTを拒否したユーザーには、1年以内に再度リクエストできますか。
AppleはEUユーザー向けに年次の再リクエスト能力を案内していますが、「拒否されたら、アプリが任意のタイミングで再表示できる」という意味ではありません。適用条件と現在のAPI動作は27.2 BetaリリースノートおよびATT API資料で確認し、状態・地域・OSを記録して実機でも検証してください。

許可画面が出ない場合は、状態がすでに決まっているのか、端末の制限や設定が影響しているのかを切り分けます。テスト前に状態をリセットしたつもりでも、端末やアカウントの条件が実利用者と一致するとは限りません。シミュレーターの結果だけで地域資格や実機の表示を証明した扱いにしないでください。

Xcodeでの公開前検収

以下の順に進めると、実装不備とテスト環境の違いを分けて記録できます。

• データフローを洗い出し、広告・分析SDKを含めてAppleの追跡定義に該当するか判定します。判断理由と参照資料を残します。
• 対象地域ごとに、配信範囲とテスト端末の条件を整理します。アカウント地域、端末の所在地、配信地域を別項目にします。
• NSUserTrackingUsageDescription、任意の補足説明、翻訳、許可リクエストの呼び出し位置を確認します。文言と実際のデータ利用に食い違いがないか照合します。
• 未決定・許可・拒否・制限状態を分けて動作させ、画面、状態値、コールバックを一緒に記録します。年次の再リクエスト条件はApple資料の現行記述と照らし、状態だけから可否を推定しません。
• Xcodeのビルド環境と実行OSを記録します。Xcode 27.2はAppleのリリースノートでBetaか正式版かを確認し、異なるビルド環境の結果を混ぜないようにします。
• 公開前に、地域別の表示、許可状態の遷移、説明文の表示を再確認します。記録にはビルド識別情報、テスト条件、画面、ログ、文案の版を含めます。

ビルド環境を揃える際は、たとえば次のようにXcodeの情報を記録できます。出力例のバージョン番号は固定せず、実際に検証した環境の結果を保存してください。

xcodebuild -version

Xcode <実際に確認したバージョン>
Build version <実際に確認したビルド番号>

Xcodeのバージョン確認だけで、EU地域の表示資格やATTの挙動まで再現できるわけではありません。シミュレーター、実機、アカウント条件のどれで確認したのかをテスト記録に明記します。

検収記録と環境選択

公開前の記録は、単に「表示された／されなかった」と残すのではなく、追跡該当性、地域条件、OS、許可状態、説明文、API結果に分けます。特にBetaで確認した項目は、正式版で再確認が必要なものとして分離しておくと、仕様変更時に再検証の対象を絞れます。

ローカルのMacだけで運用する方法は、手元の端末と実機を使った確認に向いています。一方、常時稼働するビルド環境を維持する手間、ローカルストレージや作業環境との競合、複数担当者で同じ条件を再現する難しさは残ります。リモートMacはXcodeの実行環境として検討できますが、サービスが利用者のEU地域資格やATTのシステム挙動を決めたり、単独で実ユーザーの地域条件を再現したりするものではありません。

Xcodeのビルドやテストを分離したMac環境で行う必要がある場合は、まず必要なmacOSとテスト方法を確定してください。そのうえで、NodeMiniのMac環境やMac miniの利用案内を確認し、短期の検証環境が適するか判断できます。端末を常設して物理接続が必要な運用や、長期にわたる安定した高負荷作業では、自前のMacを含めて比較するのが現実的です。