iOS 27 は、Apple と数を増やし続ける各地域の法律に対して、データ収集を始める前にユーザーの年齢をアプリに伝える正式な手段を与えます。未成年から何らかのデータを収集しているアプリ、そしてほとんどの一般消費者向けアプリはそう意識せずにそれを行っていますが、同意取得の方法と収集内容の記録方法は変える必要があります。いずれではなく、対象地域が増え続けるいま、すぐにです。
コンプライアンスに関わる話題なので最初にお断りしておきます。この記事はマーケティング・プロダクトチーム向けの実務的な整理であり、法律アドバイスではありません。具体的な義務はユーザーの所在地域とアプリの仕様によって変わるため、詳細は弁護士の確認が必要です。本ガイドでは iOS 27 が導入する内容、それが既存のトラッキングとセグメンテーションに与える影響、そして App Store の審査基準がさらに厳しくなる前に確認すべきチェックリストを整理します。Pushwoosh はカスタマーエンゲージメントプラットフォームであり、同意管理やデータ収集が Pushwoosh の設定に関わる部分については、該当箇所を明示します。
iOS 27 が実際に導入するもの
中心となるのは 2 つの API で、両者は連携して動作します。
Declared Age Range API は、生年月日を一切問い合わせたり保存したりすることなく、アプリがユーザーの年齢区分（例：13+、16+、18+）を取得できるようにします。Apple が区分を提供し、開発者側が受け取るのは日付ではなく信号です。このフレームワーク自体は iOS 26 から存在しますが、iOS 27 でその周辺要件と適用が強化されます。
PermissionKit は保護者同意の側を担います。アプリが未成年ユーザーの利用方法に影響する重大な変更を行う際、PermissionKit はユーザーに通知し、規制対象地域では未成年ユーザーが利用を続ける前に保護者の承認を求めるフローです。
重要な設計上のポイントは、システム自身がいつ適用されるかを教えてくれる点です。isEligibleForAgeFeatures や requiredRegulatoryFeatures のような信号を通じて、OS は特定のユーザーに年齢関連の義務が適用されるか、年齢区分や保護者同意を求める必要があるかを示します。ユーザーごとに推測する必要はなく、プラットフォームが適用可否をそのまま渡してくれます。
「9月から義務化」という見出しが誤って伝えていること
ここは正確に理解しておく価値があります。この義務はグローバル共通の一つのスイッチではなく、「9月から義務化」という表現自体、Apple が実際に使っているものではありません。実際には別々の 2 つの事象が進行しており、報道はそれを一つの期限にまとめて語りがちです。
1 つ目は App Store の審査基準です。Apple はプライバシー文書と年齢処理が示すべき内容を段階的に強化しており、ソーシャル機能やユーザー生成コンテンツ機能を持つアプリには、Declared Age Range API に基づくユーザー向けの年齢ゲート実装が期待されています。これは特定の日に一斉に切り替わるものではなく iOS 27 のサイクル全体を通じて厳格化していくものですが、ソーシャル機能があるアプリであれば、次のリリースまでに終わらせるべき作業として扱うべきです。
2 つ目、確定した期日があるのは地域法で、すでに複数の地域で施行されています。Apple 自身が Declared Age Range に関する義務を具体的な司法管轄と結び付けています。ユタ州では 2026年5月6日から、ルイジアナ州では 2026年7月1日から新規 Apple アカウントに年齢カテゴリが共有され、Apple はオーストラリア、ブラジル、シンガポールで 2026年2月24日から 18+ アプリのダウンロードブロックを開始しました。他の法律もそれぞれ独自のスケジュールで進んでおり、すでに施行されているものも、延期されたものもあります。システムの規制関連信号が存在するのは、まさに「このユーザーに対してこれを行う必要があるか」という問いへの答えが、そのユーザーの地域とその地域の法律の現状次第だからです。
実務的に言えば、ソーシャル機能や UGC 機能がある、あるいは規制対象地域で未成年からデータを収集している場合、これは今すぐ取り組むべき作業であり、将来の課題ではありません。どちらも当てはまらない場合でも、プライバシー文書を最新に保つことは引き続き期待されており、対象地域のマップは拡大し続けています。したがって、今のうちに対応力を整えておく方が、後で期限に追われて対応するより安く済みます。
これが法務だけでなくマーケティングの課題になる理由
年齢確認は法務とエンジニアリングの課題に見えますが、それが実際にどこへ波及するかを追うと、トラッキングとセグメンテーションに直接突き当たります。
広告識別子を収集していたり、自動的な行動イベントを発火させていたり、アプリ内行動でセグメントを構築していたりする場合、年齢の信号は「何を」「誰について」収集してよいかを変えます。保護対象の年齢区分にいるユーザーを、成人と同じ行動トラッキングや広告 ID 収集にそのまま含めることはできません。OS が規制対象地域のユーザーが未成年であることを教えてくれる時点で、「全員を同じ方法でトラッキングする」ことはもはや擁護できる標準ではなくなります。
これは多くのアプリが抱えているギャップを解消する機会でもあります。それは、広告識別子（iOS の IDFA、Android の GAID）の扱いが不明確、あるいは文書化されていないという問題です。どの広告識別子を何のために収集しているかがデータ文書で明確に示されていない場合、そのギャップはすでにリスクでした。iOS 27 のサイクルを通じて審査基準が厳格化するにつれ、それは審査落ちのリスクへと変わります。年齢収集まわりと広告 ID の文書化を同じタイミングでまとめて修正するのが効率的です。両者は同じプライバシー開示の中に存在しているためです。
コンプライアンスチェックリスト
法務・エンジニアリングのパートナーと一緒に確認してください。
- 未成年ユーザーがどの地域にいるかを把握する。 すでに年齢確認関連の法律が施行されている運用地域を特定し、地域を問わず App Store の年齢ゲートを発動させるソーシャル機能や UGC 機能がアプリにあるかを確認する。
- 適用可否シグナルを採用する。 特定のユーザーに年齢関連の義務が適用されるかを自前で推測するのではなく、OS が提供するシグナルを利用する。年齢区分や同意をいつ求めるべきかはプラットフォームに判断させる。
- 生年月日ではなく年齢区分を要求する。 年齢シグナルが必要な箇所では Declared Age Range API を使い、区分だけを取得して、以後保護が必要になる生年月日を一切収集・保存しない。
- 重大な変更に対する保護者同意フローを組み込む。 未成年がアプリを利用している場合、それを要求する地域向けに重大変更同意フローが整備されていることを確認する。
- 年齢区分でトラッキングをセグメントする。 保護対象の年齢区分にいるユーザーが、未成年には許可されない広告 ID 収集や行動トラッキングから除外されるようにする。これはユーザーごとの手動確認ではなく、データ収集と同意の設定の問題である。
- プライバシー文書を更新する。 App Store のプライバシー開示を最新化し、あわせて 広告 ID 文書化のギャップも埋め、IDFA と GAID の扱いを明確に記載する。これは審査基準が最初に確認する項目である。
- 同意文言を見直す。 未成年や保護者が目にする同意文言が、実際に収集している内容と一致しているかを確認する。GDPR 準拠の同意運用と同じ考え方で点検するとよい。
Pushwoosh で年齢配慮型のデータ収集をクリーンに運用する
Pushwoosh は同意管理とデータ収集コントロールを提供し、年齢区分でのトラッキングセグメント、保護対象ユーザーを対象外の収集から除外、広告 ID の扱いを文書化しクリーンに保つことを可能にします。Pushwoosh は SOC 2 Type I と ISO 27001:2022 を取得し、GDPR と HIPAA に準拠し、データセンターは EU と米国に設置されています。第三者認証やデータ所在地、委託先管理といった情シス審査で問われる論点にも先回りして応えられる体制です。コンプライアンス対応にゼロコストはありませんが、データ側がその中で最も難しい部分になる必要はありません。
