AdMobを使用したスマホアプリの地域別プライバシー同意実装ガイド

近年、Webもそうですが、スマホアプリで広告を配信する場合は、個人情報の取扱について厳格化されてきています。しかしながら、日本・米国・欧州の法律の違いにより、実装は複雑化しています。
そこで同意取得・管理についての考え方を整理するとともにAndroidアプリ、iPhoneアプリでAdMobを使う場合の実装ガイドをまとめました。
最後には、プレゼン資料もＰＤＦで添付してあります。
ご参照いただければ幸甚です。

ご注意

本資料は、一般的な情報提供のみを目的として作成したものであり、法的助言または同等の専門的助言を構成するものではありません。内容の正確性・完全性・最新性については万全を期しておりますが、その保証を行うものではなく、本資料の利用によって生じたいかなる損失・損害についても、当社は一切責任を負いません。実際の法的対応・技術実装につきましては、必ず最新の法令・ガイドラインを確認のうえ、専門家（弁護士・公認会計士・ITコンサルタント等）へご相談ください。

1. はじめに

アプリ内広告を搭載したスマートフォンアプリでは、ユーザーデータの取り扱いに関する各国・地域のプライバシー規制に対応することが重要です。本ガイドでは、 欧州 (GDPR) 、 米国 (CCPAなど) 、日本 (個人情報保護法)の3地域それぞれについて、アプリ開発者が知っておくべきプライバシー同意の取得・管理方法を解説します。特に本ケースでは、AdMobによる広告配信を行いつつ、アプリ内課金で広告を停止できる機能があります。このシナリオを踏まえ、初回起動時のユーザー同意取得フローから、ユーザーが後から同意設定を変更する方法、データ開示・削除要求への対応、地域別の規制要件比較、AdMobの提供するConsent SDK（User Messaging Platform）の活用、さらにAndroid/iOSプラットフォーム固有の注意点まで、実務的・技術的な観点から総合的に説明します。

2. 初回起動時の同意取得フローの設計

アプリを初めて起動する際、ユーザーに対して適切なプライバシー同意（コンセント）を求めるUIを表示します。ユーザーの居住地域に応じて、表示内容や選択肢を変えることがポイントです。
**欧州（GDPR 対象地域）**ではパーソナライズド広告利用のために明示的なオプトイン同意が必要です。
**米国（CCPA 対象州）**ではデフォルトでデータ収集が許容されますが「個人情報を販売しない（オプトアウト）」選択肢を提示することが求められます。
日本では法令上、広告目的のデータ利用について欧州ほど厳格な事前同意は要求されませんが、第三者提供に該当する場合は本人の同意が必要であるため（個人情報保護法第27条）、初回起動時にプライバシーポリシーの提示と包括的な同意取得（利用規約への同意に含める等）を行うことが望ましいです。

初回起動時に表示するプライバシー同意ダイアログの一例（GDPR向け、日本語表示）を考えます。
ユーザーに対し、アプリが収集・利用するデータ目的（パーソナライズ広告や測定等）を明示し、**「同意」「同意しない」「オプションを管理」**といった選択肢を提供します。
欧州経済領域のユーザーに対しては、このようにパーソナルデータ利用への事前同意を取得することが法的に必要です。
**同意しない（オプトアウト）が選ばれた場合は、後述するようにAdMobでは非パーソナライズド広告（文脈に基づく限定的な広告）のみ配信するモードに切り替わります。
逆にユーザーが「同意」**を選択した場合、パーソナライズド広告配信が可能となります。

各地域に応じた具体的な実装例として、Googleが提供する User Messaging Platform (UMP) SDK を利用する方法があります。
UMP SDKはAdMobの「プライバシーとメッセージ」設定であらかじめ作成した同意メッセージをユーザー端末の地域と言語に応じて表示してくれます。
例えばEU圏内のユーザーにはGDPR用の同意フォームを、米国カリフォルニア州のユーザーにはCCPAオプトアウト用のメッセージを自動判別して提示可能です。
UMP SDKを用いると、**アプリ起動時に広告ロードを行う前に自動で同意画面を表示できます。
**コード上は、アプリ起動時に `ConsentInformation.requestConsentInfoUpdate(…)`
でユーザーの規制対象地域かを確認し、 `UserMessagingPlatform.loadAndShowConsentFormIfRequired(…)`
で必要に応じフォームを即時表示します。
この処理により、同意取得が完了するまで広告リクエストを保留することができます。
なお、UMP SDKは内部でユーザー所在地や過去の同意状況を考慮しており、 既に同意取得済みであればフォームは表示されず直ちに広告配信を再開 できます。

特に欧州ユーザー向けには、2024年以降Googleが IAB TCF規約に準拠したCMPの使用を義務化 している点に注意が必要です。
UMP SDK＋AdMobの標準CMPはIAB TCF v2.2に対応したGoogle認定CMPであり、これを使えば規制要件を満たしやすくなります。
万一、自前で同意管理を行う場合も、Google認定CMP（IAB承認済みの市販CMP）を導入することが推奨されます。

米国CCPA対応として、初回起動時に必ずしもポップアップで同意を求める必要はありませんが、「Do Not Sell My Personal Info（個人情報の販売停止）」に相当するオプトアウト方法をユーザーに提供する義務があります。アプリでは、初回起動時にCCPA対象ユーザー（例: 端末の地域設定やIPからカリフォルニア州と判定されるユーザー）に対し、「当アプリは広告のためにお客様のデータを収集します。カリフォルニア州法に基づき、いつでもデータの販売を停止（オプトアウト）できます。」等の通知を表示し、「続行」（同意して進む）や「オプトアウト設定へ」のボタンを用意する方法があります。
UMPを使う場合、AdMob側で「米国の州法メッセージ」を作成・有効化しておけば、対象ユーザーにオプトアウト用のフォームが表示されます。このフォームでは、「カリフォルニア州プライバシー法に基づき、個人データを広告目的で使用してよいか」「NOであればオプトアウトします」といった選択肢が提示されます。
ユーザーがオプトアウトを選択すれば、以後AdMob SDKは**「制限付きデータ処理（Restricted Data Processing）」**モードとなり、パーソナライズド広告を停止してコンテキスト広告のみ配信するようになります。
開発者側でも、AdMobに対しユーザーのオプトアウト状態を反映することが可能です（たとえば独自にオプトアウトUIを実装する場合、Mobile Ads SDKの設定で `npa=1` 等を付与して非パーソナライズド広告をリクエストする方法があります）。

日本においては、初回起動時に欧米のような細かい選択肢をユーザーに提示する事例はまだ多くありません。ただし法的には、アプリが利用者情報を第三者（ここではGoogle/AdMob）に提供する場合、本人の同意取得が必要 と解釈されます。
実務上は、初回起動時に**「プライバシーポリシーに同意して続行」ダイアログを表示**し、その中で 広告目的で端末識別子等をAdMobに送信する旨を明記するのが望ましいでしょう。
また、「同意しない場合は広告を表示しません（または本サービスの利用を継続できません）」等の選択肢を設けることも考えられます。
ただし、ユーザーが同意しない場合でも アプリの基本機能は提供し、広告は非表示にするか、非パーソナライズド広告のみ出すなどの措置が必要です。
幸い日本の個人情報保護法では、利用者が同意しなかったからといってサービス提供を一方的に拒否することまでは規定されていないため（差別的取扱い禁止の規定は特にありません）、上記のような対応は可能ですが、ユーザー体験と収益のバランスを考慮して決定しましょう。

初回起動時の同意取得フロー

3. ユーザーによる同意設定の変更（プライバシー設定画面）

アプリ提供後も、ユーザーが自分のプライバシー設定や同意状態を閲覧・変更できる仕組みを用意する必要があります。
GDPRではユーザーに同意の撤回（withdraw consent）権が保障されており、一度許可したデータ利用でも後から停止を求めることができます。CCPA/CPRAでも「販売のオプトアウト」はいつでも可能です。
日本法でも、明確な同意撤回の概念はないものの、ユーザーから利用停止を求められた場合にはできる限り応じる姿勢が望ましいでしょう（※日本の個人情報保護法では、違反があった場合に限り利用停止・削除請求権が認められていますが、ユーザー体験向上のため自主的に応じる企業も増えています）。

実装面では、アプリ内に**「プライバシー設定」画面**を用意し、以下のような項目を提供します。

広告個人最適化の許可/拒否トグル
ユーザーが後から広告のパーソナライズをオプトアウトできるスイッチです。
EU圏ユーザーの場合は初期状態で「許可していない」(＝パーソナライズ無効)になり、ユーザーが設定画面で有効に切り替えることで同意取得とみなすことができます。
米国のユーザーには「データを第三者と共有しない（Do Not Sell）」オプションとして表示し、オフにすればパーソナライズ停止となります。
日本のユーザーにも「興味関心に基づく広告を表示する/しない」の設定を設け、オフにした場合は可能な限り広告を非パーソナライズドに切り替えると良いでしょう（この対応自体は義務ではありませんが、ユーザーに選択権を与える姿勢として有用です）。
**同意メッセージの再表示
**一度選択した同意オプションを再設定するUIです。
UMP SDKを利用している場合、 `ConsentInformation.getPrivacyOptionsRequirementStatus()`
でプライバシーオプションが REQUIRED かどうか確認し、必要に応じてボタンを有効化します。
ユーザーが「プライバシー設定」画面内の「同意設定を管理」ボタンを押すと、
`UserMessagingPlatform.showPrivacyOptionsForm(…)`
を呼び出して同意管理フォーム（UMPによる標準UI）を再度表示できます。
このフォームでユーザーが設定を変更すると、新たな同意ステータスが適用され、以降の広告配信設定が自動的に更新されます。
例えば、最初はパーソナライズを許可したユーザーが後で許可を取り消した場合、UMPを通じてAdMobネットワークにその変更が共有され、以降は個人に最適化されない広告のみ配信されます。
**「Do Not Sell」リンク
**CCPA対象の場合、アプリの設定内に「📵個人情報の販売停止」リンクを明示することも必要です。
これは上記トグルと同義ですが、規制上ウェブサイトではフッターに「Do Not Sell My Info」のリンクを置くことが義務化されている流れから、アプリでも分かりやすい文言でオプトアウト方法を示すことが推奨されます。
リンクをタップすると前述のトグルにスクロールするか、詳細説明ダイアログを出すなどしてユーザーがオプトアウトを完了できるようにします。
プライバシーポリシーへの導線
同意状況の変更とは少し異なりますが、設定画面には必ず最新のプライバシーポリシー文書へのリンク（Webビューやブラウザ表示）を設置します。
ユーザーが自分のデータ取り扱いについて詳しく確認できるようにするためです。
特にGDPRでは プライバシー通知の透明性 が重要であり、どのデータを誰がどの目的で処理しているかをユーザーがいつでも閲覧できる状態にしておく必要があります。

以上のUI要素を備えることで、ユーザーは初回の選択に縛られずいつでもプライバシー設定を見直せます。
実装時は、同意状態をアプリ内で保持する必要があります。
UMP SDKを使う場合、同意情報（TCF文字列やUS Privacy文字列）はSDK内部やSharedPreferencesに保存されており、フォーム呼び出しで自動管理されます。
独自実装の場合は、ユーザーの選択を安全にストレージへ保存し（例: `SharedPreferences` やiOSのUserDefaults）、広告リクエスト時にその設定を参照して挙動を切り替えるロジックを組み込みます。

プライバシー設定画面の操作フロー

4. ユーザーデータの開示・削除要求への対応設計

各地域の法律はユーザーに自分の個人データに関する一定の権利を認めています。アプリ開発者は、ユーザーから**「自分のデータを見せてほしい」「削除してほしい」**といったリクエストを受け取った場合に対応できるよう、アプリおよびバックエンドを設計しておく必要があります。
以下、地域別のポイントと実装例を挙げます。

**欧州 (GDPR)
**GDPRではデータ主体（ユーザー）の権利として アクセス権（データの写しの入手） 、 訂正権 、 消去権（忘れられる権利） 、 データポータビリティ権 などが明記されています。
ユーザーがアプリ提供者に対し、自分のデータがどのように収集・利用されているかの説明や、そのデータの提供・削除を要求した場合、原則として1ヶ月以内に対応する義務があります。
実装上は、 問い合わせフォーム や 電子メールでのリクエスト受付 をアプリ内に用意する方法があります。
例えば「個人データの開示・削除リクエスト」ボタンをアプリのヘルプ画面等に配置し、タップするとサポート用メール（件名にユーザーIDが含まれる等）を起動する仕組みにすることが考えられます。
または、アプリ内に専用フォームを設け、サーバーにリクエストを送信して処理する方法もあります。
ユーザーから要求があったら、開発者は バックエンドのデータベースから該当ユーザーの保存データを抽出 し、ユーザーに提供します。
AdMob等広告パートナーが収集したデータ（広告閲覧履歴など）は開発者が直接アクセスできないケースもありますが、その旨をユーザーに説明し、Googleのプライバシーダッシュボード等を案内することも可能です（Googleはユーザー向けに広告設定画面や広告パーソナライズのオン/オフ機能を提供しています）。
削除リクエストがあった場合、アプリ側で保持しているユーザー識別子やプロフィール情報を消去し、広告IDなど端末識別情報の追跡も停止する措置を取ります。
GDPRでは 違反がなくてもユーザーは削除を請求可能 であり、同意を撤回された場合やデータがもはや必要でなくなった場合には開発者は遅滞なくデータを消去しなければなりません。
**米国 (CCPA/CPRA)
**CCPAではカリフォルニア州消費者に対し、 自分の個人情報が企業にどのように収集・利用・共有されているかを知る権利 、 そのコピーを受け取る権利 、 削除を求める権利 などが保障されています。
開発者は、カリフォルニア州在住と確認できるユーザーからこれらの請求があった場合、対応する必要があります。
実装としては、上記GDPRと同様に問い合わせフォームやメール連携を用意することが考えられます。
またCCPAでは、ウェブサイトなら「Do Not Sell My Personal Information」のリンク設置義務がありますが、アプリでも プライバシーポリシー内にデータ権利の行使方法を記載 したり、設定画面に「個人データの開示・削除をリクエストする」オプションを設けたりすると良いでしょう。
ユーザーから削除請求があれば、保有する該当ユーザーデータを削除します。
ただしCCPAには削除要求を拒否できる例外事項もいくつかあります（例: サービス提供のために必要な場合等）ので、対応時には法律専門家と相談しつつケースバイケースで判断します。
一般に、広告IDなど デバイス固有IDは本人確認が難しい 点に留意しましょう。
メールなどで削除依頼を受け取った場合、開発者はユーザーにアプリ内のユーザーIDや登録情報を確認したり、デバイスIDを送ってもらうことで、データベース上の対象データを特定します。
CCPAでは本人確認手続も義務付けられているため、 リクエストしたのが本当にそのユーザー本人か を合理的に確認するプロセス（例えば登録メールアドレス宛に確認の返信を要求する等）を実装しておきましょう。
**日本 (改正個人情報保護法)
**日本では、利用者は事業者に対し 保有個人データの開示 や 利用目的の通知 、 訂正・追加・削除 、 利用停止・第三者提供停止 を求めることができます。
ただしGDPRやCCPAと比べると、ユーザー側が請求できる条件や事業者側の拒否要件が細かく規定されています。
例えば 利用停止・削除 は「事業者が法令に違反して個人情報を扱っている場合」等に限り請求できます。
したがって、日本のユーザーから「自分のデータを削除してほしい」と依頼があった場合、法的義務としては即対応が必要になるケースは限定的ですが、 企業の自主的な顧客対応 として柔軟に応じることが望まれます。
実装面では、他地域と同様に問い合わせフォームやメール窓口を設けます。
プライバシーポリシー上に「開示等の請求方法」として連絡先や手順を明記することも必須です。
ユーザーから開示請求が来たら、登録情報やログデータから 本人に関するデータを抽出して紙または電子データで提供 します。
削除依頼も受けたら、特段の支障が無い限り応じるのが良いでしょう（実際には、対応しないことでユーザーからの信頼を失いかねないため、違反でなくとも削除してあげる企業も増えています）。
なお、日本法では データポータビリティ （機械可読な形でのデータ移行権）は明文化されていませんが、ユーザーが希望すればCSVやJSONでデータを書き出して提供するなどの対応を検討しても良いでしょう。

これらの要求への対応を円滑に行うには、 バックエンド側でユーザーデータを一元管理 しておき、特定ユーザーのデータ抽出・削除処理が容易に実行できるように設計しておくことが重要です。
例えばユーザーID毎に関連データベースを参照して削除するスクリプトを用意したり、広告SDKに送信したデータのログを可能な範囲で保持・検索できるようにしたりします。
ただし、広告ID（AAID/IDFA）の履歴など 開発者が直接取得していないデータ については限界もあります。
その場合、「該当の広告識別子に関するデータは当社では保有していません。��告配信事業者（Google等）のプライバシーポリシーをご参照ください。」と案内する形になります。
また、**同意管理プラットフォーム(CMP)**を導入している場合、CMPから得られる同意記録（コンセントスリングなど）を保存しておき、ユーザーの要求があれば「○月○日にパーソナルデータ利用に同意いただきました」等の履歴も提示できるとなお丁寧です。

開示・削除要求対応フロー

5. 地域別の法規制要件・ユーザー権利の比較表

各地域におけるプライバシー規制の相違点をまとめると次の通りです。実装の際の優先事項や、ユーザーに付与すべき権利の範囲を把握するために比較表を確認しましょう。

地域別の法規制要件・ユーザー権利の比較表

※上記は簡略化した比較です。実際の法令要件は詳細条文やガイドラインを確認してください。特に2023～2025年にかけ、米国では他州のプライバシー法（CPRAはCCPA改正、他にバージニア州等）、日本も改正法施行など変化があるため最新版の情報に留意しましょう。

6. AdMobにおけるConsent SDK（User Messaging Platform）の活用法

上述したように、Google AdMobでは開発者が規制対応できるようプライバシーとメッセージという仕組みを提供しています。
AdMobのコンソール上で各種プライバシーメッセージ（欧州規制メッセージ、米国州法メッセージ、IDFA説明メッセージなど）を作成・カスタマイズし、アプリ側に User Messaging Platform (UMP) SDK を導入することで、ユーザーに対する同意取得を半自動化できます。
UMP SDK（旧称: Consent SDK）は、GoogleがホストするIAB準拠の同意フォームをアプリに表示し、ユーザーの選択結果を取得・保存するためのライブラリです。

導入手順（概要）

AdMob管理画面でのメッセージ設定
AdMobアカウントの「プライバシーとメッセージ」セクションに移動し、対象アプリについて必要なメッセージを作成・公開します。
例えばGDPR向けには「欧州の規制」カードからメッセージを新規作成し、言語（多言語設定可）、ユーザーの選択肢（「同意しない」を表示させるか等）、ターゲット地域（EEA+UKのみか全世界か）を設定します。
メッセージ本文やデザイン（色やロゴ）は必要に応じてカスタマイズ可能です。
また各メッセージにプライバシーポリシーのURLを登録する項目があるので、アプリの公開ポリシーのURLを必ず指定します。
米国州法メッセージ も同様に、対象とする州を選択（例: カリフォルニア州など該当州をチェック）してメッセージを作成します。
IDFAメッセージ（ATT用の事前説明）についてはiOSアプリ向けに別途設定できます。
**UMP SDKの実装
**AndroidではGradle経由、iOSではCocoaPodsやSwift Package経由で `Google User Messaging Platform` を追加します。
最新のSDKを使用してください（例: UMP SDK 2.0+でGDPR/CCPA両対応、2.7.0以降で米国GPPデバッグ機能対応）。
アプリ起動時に、UMPの `ConsentInformation` オブジェクトから `requestConsentInfoUpdate` を呼び出し、非同期でメッセージの必要性をチェックします。
成功コールバックで `UserMessagingPlatform.loadAndShowConsentFormIfRequired`
を実行すれば、必要な場合に自動的に同意フォームがその場で表示されます。
たとえばAndroid Kotlinの場合、上記により、もしユーザーが規制対象地域なら `isConsentFormAvailable` がtrueとなり、UMPが内部で適切なフォーム（GDPRやCCPA）をロード&表示します。ユーザーの操作後、自動的にSDK内に同意状態が保存され、 `formError` コールバックで処理再開できます。
**ユーザーの選択内容の反映
**UMP SDK経由で得られる同意内容は、Googleモバイル広告SDKにも共有されます。
GDPRの場合はIAB TCF文字列が生成され、CCPAの場合はUS Privacy文字列（Global Privacy Controlに準拠）として記録されます。
開発者が個別に広告リクエストにパラメータを付与しなくても、Google提供の広告ユニットであればSDKが自動でユーザーのプライバシー選択を適用します。
たとえばユーザーが「カスタマイズされた広告を許可しない」を選択すれば、以降AdMobはそのデバイスにはパーソナライズしない広告（コンテキストターゲティングのみ、またはGoogleの Limited Ads モード）を配信します。
一方、開発者が独自に複数の広告ネットワークを使っている場合、それぞれにユーザー選択を伝える必要があります。
GoogleのUMPはIAB標準に従っているため、他社SDKがIAB TCFやUS Privacy stringを読み取る実装であれば連携可能です。
**プライバシーオプションのエントリポイント実装
**前述の「プライバシー設定」画面で再同意フォームを表示するには、UMPの
`ConsentInformation.getPrivacyOptionsRequirementStatus()`
をチェックし、 `REQUIRED` であれば設定画面に「プライバシー設定を管理」ボタンを表示、押下時に `UserMessagingPlatform.showPrivacyOptionsForm(…)`
を呼び出します。
このメソッドで表示されるフォームは、ユーザーが最初に見た同意画面とは異なるUI（例えば「プライバシー設定を管理」というタイトルで、以前の選択を変更できる画面）になることがあります。
これによって、ユーザーは後からいつでもオプトアウトや同意変更ができます。

**UMP SDKを使うメリット
**上記のとおり、GoogleのConsent SDKを使えば 実装の手間が大幅に軽減 されます。
自前で各地域の法規制に合わせたフォームやロジックを実装・アップデートする代わりに、Googleが提供するテンプレートに沿って利用できるからです。
特にGDPR対応ではIAB欧州のCMP認定が必要ですが、Google UMP SDK＋AdMobメッセージを使えば2024年以降も要件を満たせます。
また、多言語対応（GDPRメッセージは日本語を含む多数の言語に自動翻訳可能）や、フォームのデザインカスタマイズ機能（AdMob管理画面上でボタン色やロゴを変更可能）も備わっているため、ユーザー体験を損ねずに同意を取得できます。
注意点として、UMP SDKは アプリのAdMobアプリIDに紐づいたメッセージ を取得するため、AdMob側でメッセージを公開していないと何も表示されません。
実装後はテストデバイスをEEAやカリフォルニア扱いに強制するデバッグ設定も利用し、正しくフォームが出るか確認しましょう。

なお、GoogleのCMPを使わず 独自の同意画面 を実装する場合は、そのCMPが Google認定 （IAB TCF準拠）であるかを確認しましょう。
独自実装の際は、AdMobの広告リクエストにパラメータでユーザーの同意ステータスを渡す（例: `MobileAds.setRequestConfiguration` で設定）ことができます。
GDPRなら `npa` フラグ、CCPAならIABのUS Privacy文字列を送信しますが、これらの詳細実装は煩雑になるため可能な限りUMP等の利用が推奨されます。

7. Android・iOSプラットフォーム別の実装上の注意点

モバイルアプリにおけるプライバシー対応では、各プラットフォーム（AndroidとiOS）のポリシーや技術的制約にも留意しなければなりません。ここでは、App Tracking Transparency (ATT) や Google Playのデータ安全性ポリシーなど、プラットフォーム固有の重要事項をまとめます。

**iOS (App Store) における注意点
**Appleはユーザーのトラッキングに対して厳しいポリシーを課しています。iOS 14.5以降、**App Tracking Transparency (ATT) フレームワークにより、アプリはユーザーの許可なくIDFA（広告識別子）等による追跡を行うことができません。したがって、AdMobのように他社サービスとユーザーをまたいでデータを共有する場合、必ずATTの許可をユーザーに求めるシステムプロンプトを表示する必要があります。
**このプロンプトはアプリ起動時や広告表示前に、AppleのAPI
`ATTrackingManager.requestTrackingAuthorization(…)`
を呼ぶことで表示され、「“App名”が他社のアプリやWebサイト越しにあなたを追跡する許可を求めています」といったメッセージと「許可しない」「許可」の選択肢がユーザーに提示されます。
ユーザーが「許可しない」を選択した場合、その後は IDFAはゼロ値となり取得不能となります。
またAppleの規約上、この選択に反して独自の手段で指紋付け追跡すること（いわゆるfingerprinting）は禁止されています。
従って ユーザーがATTで拒否した場合は、AdMobもパーソナライズド広告を諦めて文脈広告にフォールバック することになります（AdMob SDKは自動的にIDFA未取得時はコンテキストターゲティングに切り替えます）。
iOS 14.5以降に表示されるApp Tracking Transparency (ATT) の許可ダイアログ例では、アプリはこの標準プロンプトでユーザーから 他社によるトラッキング許可 を取得する必要があります。
ユーザーが「Ask App Not to Track（アプリにトラッキングしないよう要求）」を選ぶと、そのアプリには追跡用ID（IDFA）が提供されず、AdMobを含む広告SDKは精細なターゲティングができなくなります。
逆に「Allow（許可）」された場合でも、別途GDPR等の同意が得られていなければパーソナルデータ利用はできない点に留意してください。
iOSではさらに、 プライバシー“栄養ラベル” （App Privacy Details）として、開発者がApp Store Connect上でアプリが収集するデータカテゴリとその用途を申告する必要があります。
AdMobを組み込んでいる場合、 `Advertising Data` （広告目的のデータ）や `Identifiers` （例えばデバイスID）等を収集している旨を申告し、「ユーザーのトラッキングに利用するか」を“Yes”にします。
これらはApp Storeでユーザーに公開される情報であり、実態と相違があるとリジェクトされる可能性があります。
特に、 ATT許可を得ていないのにトラッキング目的でデータを使用している と判断されると、Appleの審査で問題になります。
実装上は、ATT許諾後にのみAdMobの広告ロードを行う、許諾前は一切AdMobにアクセスしない、といったフローにしておくと安全です。
また、iOSでは NSUserTrackingUsageDescription というキーをInfo.plistに設定し、ATTプロンプトで表示する説明文（なぜ追跡許可が必要か）を記載する必要があります。
この文言はユーザーに許可を促すためにも分かりやすく記述し、例えば「広告パーソナライズのために他社とデータを共有します」等とします。

最後に、Apple独自の広告についても触れておきます。
AppleはIDFAとは別に、Apple広告（App Store検索広告等）向けに SKAdNetwork や ATTとは別枠の個人広告設定 を提供しています。
ユーザーがiOS設定で「パーソナライズされた広告」をオフにすることもできますが、これはAppleの広告配信に影響する設定で、AdMobのようなサードパーティには直接関係しません。
ただ、包括的にユーザーに配慮するなら、アプリのヘルプなどで「iOSデバイスの設定で広告トラッキングを制限する方法（設定 > プライバシー > トラッキングをオフにする等）」も案内してあげると親切です。
**Android (Google Play) における注意点
**AndroidではOSレベルでのトラッキング許諾プロンプトはありませんが、 広告ID (Google Advertising ID/AAID) の取り扱いに関するユーザー設定が存在します。
Android 12以降、ユーザーが「広告IDを無効化（オプトアウト）」設定を有効にすると、アプリから広告IDを取得しようとした際に一連のゼロ（「000…」）が返る仕様になりました。
これはiOSのATT拒否と同様、広告目的のトラッキングをオプトアウトする仕組みです。
したがって、アプリ側ではAdvertising IDが有効かどうかチェックし、無効ならばパーソナライズ設定をオフにしたAdMobリクエストを送るか、あるいは広告配信自体を控える対応が考えられます。
ただし、多くの場合AdMob SDKが自動的にこれを検知し非パーソナライズド運用に切り替えてくれます。
またAndroid 13では、実行時権限として通知許可が追加されましたが、広告表示（BannerやInterstitial）には直接関係ありません（プッシュ通知広告をする場合は別途注意）。
Google Playのポリシーとして注目すべきは データセーフティセクション（Data Safety) の公開義務です。
開発者はアプリ内で収集・共有するユーザーデータ全項目をGoogle Play Developer Console上で申告しなければなりません。
たとえ「広告を載せているだけ」であっても、AdMob SDKがデバイス情報やIPアドレス等を収集するため適切な項目を申告する必要があります。
AdMob利用時の一般的な申告例としては、「収集されるデータ: デバイスまたはその他のID（広告ID等）。用途: アプリの機能（必須）および広告/マーケティング。データの共有先: Googleなど第三者。データは送信時に暗号化される。ユーザーはこのデータ収集をオプトアウト可能か: はい（例えば広告IDリセットやオプトアウト設定により）」。
実際には2022年以降、Googleが用意した質問に答える形式で進めます。
AdMob以外に取得している個人情報（ユーザー登録情報など）があればそれも含めて申告してください。これら申告内容はアプリ公開ページに表示され、虚偽があるとリジェクトや削除のリスクがありますので、 実装と申告内容を常に一致 させておくことが重要です。
また、Androidアプリにおける パーミッション にも注意しましょう。例えばAdMobが位置情報を利用する設定にしている場合（現在はデフォルトで精細位置情報は利用しないはずですが、以前は位置情報APIと連携できました）、必要に応じてRuntime Permissionでユーザーに許可を取らねばなりません。
現在のAdMobでは通常そこまでの個人情報は扱いませんが、他のSDKで連携して個人情報を収集する場合は 権限要求時の説明 （Why this permission is needed）を適切に表示するなど、ユーザーに不信感を与えない工夫が必要です。
最後に、日本のAndroidアプリ特有の留意点として、 Androidプラットフォーム標準のプライバシーポリシーの提示 があります。
Android 11から、アプリの設定内に「利用者データの取り扱い」としてプライバシーポリシーへのリンクを表示するUIが提供されています（Google PlayにプライバシーポリシーURLを登録している場合、自動でOS設定に表示されることがあります）。
開発者としては、このOS標準の導線も活用し、 ユーザーが容易にプライバシーポリシーと設定画面にアクセスできるよう配慮しましょう。

8. UI実装例とフローチャートによる解説

最後に、プライバシー同意フローのUI設計例や処理フローを図解してみます。以下の図やモックは実際の実装をイメージする助けとなるでしょう。

1. 初回起動時のフロー
ユーザーがアプリを起動 -> 地域判定 (例: IPやLocaleよりEEAか?) ->

[EEAの場合]
UMP SDKによりGDPR同意フォームを表示
-> ユーザーが「同意」か「同意しない」を選択
-> AdMobは対応する広告配信モードに設定（同意なしなら非個人化広告）。
**[カリフォルニア州の場合]
**UMP SDKによりCCPAオプトアウトフォーム表示（または独自UI通知）
-> ユーザーが「データ販売を許可しない」を選んだらAdMobをRDPモードに。選ばなければ通常通り。
**[日本やその他地域]
**GDPR/CCPAフォーム不要なのでUMPから即処理復帰
-> アプリ内で独自のプライバシー同意確認（例えば利用規約同意ダイアログ）を出すかスキップ
-> 広告配信開始。

上記フローにおいて、 ユーザーがアプリ内課金で「広告削除」を購入した場合 は、以降のフローから広告表示およびデータ収集部分が取り除かれます。
具体的には、購入状態をアプリ内に保持し、広告ロード処理（ `MobileAds.initialize` や `AdView.loadAd` 等）を呼ばないようにします。
もし初回起動時点で既に購入済みがわかっている場合（購入の復元情報がある場合）は、最初から同意フロー自体をスキップできるケースもあります。
この場合でもプライバシーポリシーの周知自体は行い、ユーザーがデータ開示を求めた際などに備えておきます。

2. プライバシー設定画面UI例
設定画面に「プライバシーと広告設定」というセクションを設け、以下のコンポーネントを配置

「パーソナライズド広告を許可」トグルスイッチ
– 有効時は現在同意済みであることを示す。
ユーザーがこれを無効にすると確認ダイアログを出し、「今後広告は内容に関係なく表示されます。それでもよろしいですか？」などと念押し
-> OKで反映しAdMobを非個人化モードに切替え。
「同意設定を管理」ボタン
– タップするとUMPのプライバシーオプションフォームを表示。
ユーザーが各目的ごとの同意を細かく閲覧・変更できる。
「データの開示・削除をリクエスト」ボタン（またはリンク）
– タップするとお問い合わせ画面やメールを起動し、ユーザーが自由記述で依頼できる。
「プライバシーポリシー」リンク
– タップでWebビューにポリシー全文を表示。

これらのUIはシンプルながら、ユーザーに安心感を与えます。「自分でコントロールできる」ことを示すだけでも、プライバシーへの配慮として評価されるでしょう。

3. iOSにおけるATTと同意取得の連携
iOSではATT許諾を得るタイミングとGDPR同意のタイミングの調整が必要です。
推奨順序は、 まずアプリ独自の同意フォーム （UMPのGDPRフォームなど）で「このアプリは広告のために追跡許可とデータ利用の同意を求めます…」と説明し、ユーザーがOKしたら、次に システムのATTプロンプト を表示する流れです。
こうすることで、いきなりシステムダイアログが出るのを避け、ユーザー理解を助けられます。
実装例として、Funding Choices設定で「IDFAメッセージ（ATT前の説明）」と「GDPRメッセージ」の両方を設定している場合、UMP SDKは EU圏ユーザーにはまずGDPRメッセージを表示し、その後自動でATT許諾ダイアログを表示 することも可能です。
この連携により、ユーザーはスムーズに許諾フローを進めることができます。

最後に、実装後は 必ず包括的なテスト を行いましょう。
EU圏のテストにはUMPのDebugGeography（EEAモード）を使い、米国のテストにはVPNやDebugGeography（仮想的に規制州に設定）を使います。
ユーザーの選択によって正しく広告配信の挙動が変わるか、同意を拒否してもアプリがクラッシュしたり重要機能が使えなくなったりしないかなど、細心の注意を払って確認します。
また新たな法律施行やプラットフォームルール変更にも対応できるよう、情報をアップデートし続けることも肝心です。
プライバシー対応は一度実装して終わりではなく、 継続的なメンテナンス とユーザーとの信頼関係構築が重要と言えるでしょう。

以上、AdMob搭載アプリにおける地域別プライバシー同意取得・管理の実装ガイドでした。
適切な実装によって、ユーザーの権利を尊重しつつ収益化も両立する健全なアプリ運営を目指してください。
今後も法律やプラットフォームポリシーの変更に注意し、都度アップデートを行うようにしましょう。

参考文献・資料: 本ガイド作成にあたり、Google AdMob公式ドキュメント、各地域の法規制解説、および開発者向けブログ記事等を参照しました。各種引用は該当箇所に記載していますので、詳細はそちらもご確認ください。

9. 参考：プレゼンテーション資料PDFファイル

admob_privacy_consent_guide_20250613043101.pdf 12.4 MB ファイルダウンロードについてダウンロード