公開2025.01.30更新2026.09.27 広告

IDFAとは？個人情報との関係とATTの同意・確認方法

IDFAはAppleがiOSデバイスに1つだけ割り当てる広告用の識別子です。iOS 14.5以降はATT（アプリのトラッキングの透明性）で許可を得ていないアプリには全ゼロの値しか返らないため、「IDFAは個人情報なのか」「どの状態なら取得できるのか」を正確に押さえないと、同意設計も計測設計も組めません。この記事ではApple公式ドキュメントと日本の条文・ガイドラインだけを根拠に整理します。

まとめ：IDFAの要点

IDFAは端末ごとに固有のUUIDで、iOS 6.0から提供されている広告専用の識別子です。
ATTの認可状態がauthorizedのときだけ固有のUUIDが返り、それ以外は00000000-0000-0000-0000-000000000000になります。
IDFAは、それ自体で特定の個人を識別できず、他の情報との容易な照合によっても識別できない場合には個人情報に該当しませんが、個人情報保護委員会のガイドラインは端末識別子を通じて集めた閲覧履歴を「個人関連情報」の事例に挙げています。
広告ネットワークなど第三者へ渡す構成では、ATTの許可とは別に個人情報保護法31条の確認義務を検討する必要があります。
総務省の外部送信規律FAQは「広告ID等の識別符号」を明示的に規律の対象情報に含めています。ただし義務の名宛人は電気通信事業者と省令で定める役務の提供者に限られます。
アプリ内でユーザーを区別するだけならIDFVを使えばATTの許可は不要です。

以下では定義、法的な位置づけ、ATTの挙動と実装、確認方法の順に解説します。

IDFA（Identifier for Advertisers）の定義と用途

IDFAの正式名称はIdentifier for Advertisersです。Appleの公式ドキュメントはadvertisingIdentifierを「The UUID that is specific to a device.」と定義しており、端末ごとに一意な英数字の文字列を広告目的だけに使うものと説明しています。IDFAはiOS 6.0から提供されています。

公式ドキュメントが挙げている用途は6つです。フリークエンシーキャップ、アトリビューション、コンバージョンイベント、ユニークユーザー数の推定、広告詐欺の検出、デバッグです。値の形式はハイフンで区切られた32桁の16進数（UUID）で、アプリをまたいで同じ値が読めるため、複数アプリ間での効果測定に使われてきました。

Appleは同じドキュメントで「As a best practice, don't store the advertising identifier value」と述べ、値を保存せず必要なときにadvertisingIdentifierへアクセスするよう求めています。ユーザーは設定でいつでも許可を変更できるため、キャッシュした値は許可の取り消しに追随できません。

IDFAとIDFVの違い

識別子	発行元	単位	取得API	ATTの許可
IDFA	Apple（iOS）	端末に1つ	`ASIdentifierManager.advertisingIdentifier`	必要
IDFV	Apple（iOS）	ベンダー×端末	`UIDevice.identifierForVendor`	不要

IDFVは「同じベンダーの複数アプリで同じ値、別ベンダーでは別の値」になる識別子です。Appleは値が変わる条件を「The value changes when the user deletes all of that vendor's apps from the device and subsequently reinstalls one or more of them.」と明記しています。通常は同一ベンダーのアプリが端末に残っている間は値が維持されます。ただし、Xcodeによるテストビルドやアドホック配布のインストールでも変わる場合があります。またベンダーの判定は通常App Storeのデータで行われ、App Store経由でない配布ではバンドルIDの最後の要素を除いた部分から算出されます。端末の再起動直後でロック解除前などはnilが返るため、時間を置いて取り直す実装が必要です。

AAID側の確認・リセット手順とIDFAとの比較表はAAIDとは？Androidの広告ID（ADID）の確認・リセット方法とIDFAとの違いで扱っています。

IDFAの個人情報該当性と法的な取扱い

IDFAの識別可能性と個人関連情報の判断基準

個人情報保護法2条7項は「この法律において「個人関連情報」とは、生存する個人に関する情報であって、個人情報、仮名加工情報及び匿名加工情報のいずれにも該当しないものをいう。」と定めています。個人情報保護委員会のガイドライン（通則編）2-8は、この個人関連情報に該当する事例の第1号として「Cookie等の端末識別子を通じて収集された、ある個人のウェブサイトの閲覧履歴」を挙げています。

つまり、このガイドラインの事例が示しているのは識別子そのものではなく、識別子を通じて集めた履歴です。IDFA自体の扱いは、それ単体で、あるいは他の情報と容易に照合することで特定の個人を識別できるかどうかで決まります。氏名と紐づけて保有していれば個人情報ですし、会員IDと紐づけている場合はその会員IDから個人を識別できるかで判断します。ガイドラインも「個人情報に該当する場合は、個人関連情報に該当しないことになる」と注記しています。自社ではIDFAを単独のキーとして管理しているつもりでも、社内の別のデータベースと容易に照合できる状態なら個人情報として扱う必要があります。

個人関連情報の第三者提供と31条の確認義務

問題になるのは提供です。個人情報保護法31条1項は、個人関連情報取扱事業者は「第三者が個人関連情報を個人データとして取得することが想定されるとき」は、本人の同意が得られていることを確認しないで提供してはならないと定めています。広告ネットワークやDMPがIDFAと行動履歴を受け取り、自社が持つ会員データと突合して個人データとして扱う構成は、この「想定されるとき」に当たり得ます。提供先が同項2号の対象となる外国にある第三者の場合は、同意取得に先立ち、当該国の制度などの情報が本人に提供されていることも確認します。同等水準国や基準適合体制を整備した提供先については、適用される規律が異なります。

ここで混同しやすいのが、ATTの許可と31条の同意は別物だという点です。ATTはAppleがプラットフォームのルールとして課す許可で、日本法の同意要件を満たすものではありません。ATTで許可を得たからといって31条の確認が不要になるわけではなく、逆にATTで拒否された端末ではIDFAが全ゼロになるため提供する識別子自体が存在しません。同意設計は両方を並べて組む必要があります。

広告IDの外部送信規律と対象サービス

もう1つの規律が電気通信事業法27条の12（情報送信指令通信に係る通知等）です。総務省の外部送信規律FAQ問1-15は、規律の対象となる「利用者に関する情報」について「具体的には、Cookieや広告ID等の識別符号、利用者の氏名等、利用者以外の者の連絡先情報等、幅広い情報が含まれます」と答えています。同FAQ問1-3も、アプリに組み込まれた情報収集モジュールによって「Cookieや広告ID等の識別子、閲覧履歴・行動履歴」が送信される状況を導入理由として挙げており、アプリのSDK経由の送信が視野に入っていることがわかります。

対応方法は、通知、利用者が容易に知り得る状態に置くこと（公表）、同意取得、オプトアウト措置の提供のいずれかです。条文のただし書は4つの除外を置いていますが、2号の除外は「当該電気通信事業者又は第三号事業を営む者が当該利用者に対し当該電気通信役務を提供した際に当該利用者の電気通信設備に送信した識別符号」であって、かつ自社の設備を送信先とするものに限られます。いわゆるファーストパーティCookieのIDが典型で、OSが発行するIDFAを第三者の広告ネットワークへ送る構成はこの除外に当てはまりません。

ただし義務の名宛人は広くありません。27条の12柱書は「電気通信事業者又は第三号事業を営む者（内容、利用者の範囲及び利用状況を勘案して利用者の利益に及ぼす影響が少なくないものとして総務省令で定める電気通信役務を提供する者に限る。）」と限定しています。メッセージ媒介、SNSや掲示板・動画共有・オンラインショッピングモール、検索、ニュース配信などの省令で定める役務が対象で、アプリを出していれば自動的に規律の対象になるわけではありません。自社の役務がどれに当たるかを先に確定してから、通知文の設計に入るべきです。

ATT（アプリのトラッキングの透明性）による取得条件の変更

Appleのサポート記事は「iOS 14.5、iPadOS 14.5、tvOS 14.5以降では、アプリが他社のアプリやWebサイトを横断してお客様の行動を追跡（トラッキング）する場合、事前にお客様ご本人の許可を得ることが義務付けられています」と説明しています。開発者側から見ると、許可を取っていないアプリはIDFAを読めなくなりました。

ATTの認可状態とIDFAの戻り値

AppleのadvertisingIdentifierのドキュメントは、固有のUUIDが返る場合と全ゼロが返る場合を明示的に列挙しています。

状態	IDFAの戻り値
ATTで許可済み（`authorized`）	端末固有のUUID
ATTで拒否（`denied`）	全ゼロ
未要求（`notDetermined`）	全ゼロ
システムが制限（`restricted`）	全ゼロ
シミュレータ・macOS・visionOS上のiPhone/iPadアプリ	全ゼロ

全ゼロの具体的な値は00000000-0000-0000-0000-000000000000です。シミュレータでは設定に関係なく全ゼロになるため、実機でしか挙動を確認できません。なお許可後にユーザーが設定の「アプリからのトラッキング要求を許可」をオフにしても、個別アプリの許可がオンのまま残っている場合は固有のUUIDが返り続ける、というケースも同じドキュメントに記載されています。

ATTによるメールアドレス等の代替識別子の制限

Appleのサポート記事は「「アプリにトラッキングしないように要求」を選択した場合、アプリのデベロッパはシステムの広告ID（IDFA）にアクセスできません。このIDFAは、トラッキングによく使われます。また、個人やそのデバイスを特定するその他の情報（メールアドレスなど）を使って、アクティビティを追跡することも、アプリには認められません」と述べています。

ATTの制限はIDFA以外の識別情報にも及びます。IDFAが取れないからメールアドレスのハッシュ値で代替する、という設計はATTの回避にあたり、Appleのルール上は認められていません。拒否された端末については、横断的な個人単位の追跡そのものを前提から外し、後述の集計型の計測に切り替えるのが筋です。

ATTの実装手順とInfo.plistの設定

以下はiOS 14.5以降を対象とする初回要求の例です。アプリがアクティブで、別の許可要求が保留されていないタイミングで呼び出します。ATTの許可要求にはNSUserTrackingUsageDescriptionキーが必須です。Appleは「To use this method, add the NSUserTrackingUsageDescription key to your app's target properties in Xcode.」と明記しており、この説明文を設定せずに許可プロンプトを表示しようとすると、アプリがクラッシュします。

<key>NSUserTrackingUsageDescription</key>
<string>広告の効果測定のために、他社のアプリやサイトでの行動と関連付けます。</string>

import AppTrackingTransparency
import AdSupport

if ATTrackingManager.trackingAuthorizationStatus == .authorized {
    let idfa = ASIdentifierManager.shared().advertisingIdentifier
    // idfa を計測SDKへ渡す
} else if ATTrackingManager.trackingAuthorizationStatus == .notDetermined {
    ATTrackingManager.requestTrackingAuthorization { status in
        guard status == .authorized else { return }
        let idfa = ASIdentifierManager.shared().advertisingIdentifier
        // idfa を計測SDKへ渡す
    }
}

認可状態はATTrackingManager.AuthorizationStatusの4値です。notDeterminedは未回答、authorizedは許可、deniedは拒否、restrictedはシステムが制限している状態を表します。Appleはrestrictedについて「プロンプトを提示したかどうかに関係なく」返ると説明しているため、要求を出す前に状態を見てnotDeterminedのときだけ要求する実装にします。

ATTのプロンプトが表示されない5つの条件

プロンプトが表示されない場合は、まずAppleが公式に列挙している次の非表示条件を確認してください。

端末でトラッキングが制限されている（trackingAuthorizationStatusがrestricted）
設定の「アプリからのトラッキング要求を許可」がオフになっている
別の許可要求が保留中である
App Extensionからこのメソッドを呼んでいる
アプリの状態がUIApplicationStateActive以外である

いずれの場合もシステムはプロンプトを出さず、completion handlerを即座に実行します。実装側から見ると「一瞬で結果が返ってきた」ように見えるため、非表示条件を疑わずにSDKの不具合として調査してしまうことがあります。まずtrackingAuthorizationStatusの値と設定画面のトグルを確認してください。

EU向けATTの表示形式と再要求条件

Appleは地域差も明記しています。以下はiOS 14.0以降で提供されている標準の許可要求API（requestTrackingAuthorization(completionHandler:)）のドキュメントに書かれている内容で、特定のバージョン以降に限った話ではありません。フランス、ドイツ、イタリア、ポーランド、ルーマニアではシステムがアラートではなくフルページシートを表示します。設定項目の名称もEUでは異なり、「Allow Apps to Request to Track」が「Allow Apps to Request to Link Your Activity Across Companies」と呼ばれます。

再表示の扱いも独自です。「In the European Union, if a person answers the prompt, the system notes the date and doesn't allow the prompt to display again until a year passes.」とあり、EUではユーザーが回答した日から1年間は再要求できません。許可・拒否のどちらでも1年経過後に再要求できますが、ユーザーが設定でトラッキングを無効にしている場合は対象外です。EU向けに配信しているアプリで「拒否されたので数週間後にもう一度聞く」という設計は成立しません。

さらに、2026年9月22日時点でApple公式がベータとして掲載しているiOS 27.2向けAPIとして、requestTrackingAuthorization(usingExpandedInterface:additionalInformationAction:completionHandler:)が追加され、NSUserTrackingMarkdownUsageDescriptionに書いたMarkdown書式のテキストをフルページシートで表示し、任意で「詳細情報」ボタンを付けられるようになりました。この拡張はEU圏の国に所在し、対象国のApple Accountでサインインしている端末でのみ機能し、EU圏外では従来のNSUserTrackingUsageDescriptionによるアラートが表示されます。

IDFAの確認方法（利用者の設定と開発者のAPI）

利用者側の確認箇所はApple公式のiPhoneユーザガイドに書かれています。「「設定」＞「プライバシーとセキュリティ」＞「トラッキング」と選択します。」で、トラッキングの許可を要求したアプリの一覧が表示され、アプリごとに許可をオン・オフできます。すべてのアプリからの要求を止めるには、画面上部の「アプリからのトラッキング要求を許可」をオフにします。

注意点として、この画面にIDFAの値そのものは表示されません。iOSにIDFAを確認する設定項目は用意されていないため、値を見たい場合はアプリ側でASIdentifierManager.shared().advertisingIdentifierを読んで表示する必要があります。macOSでこのAPIを呼ぶと常に全ゼロが返ります。

IDFAをリセットする操作、Android側の広告IDの削除、リセットと削除の挙動の違いは広告識別子とは？IDFA・AAIDの違いとリセット方法を解説に手順としてまとめています。

IDFAが取れない前提の広告計測

ATT下では端末単位の許可率に計測が依存します。そこで、個人を特定しない集計型のアトリビューションへ寄せるのがAppleの想定です。中心になるのはSKAdNetworkと、iOS 17.4以降で提供されているAdAttributionKitです。

AdAttributionKitについて、公式ドキュメントは広告ネットワーク、広告を表示するパブリッシャーアプリ、広告対象アプリの3者が関与するAPIだと説明しています。広告ネットワークがAppleに登録してad network IDを取得し、コンバージョン発生後にポストバックを受け取る仕組みです。App Storeに加えて代替アプリマーケットプレイスの広告も扱えます。SKAdNetwork自体の仕組みとポストバックの読み方はSKAdNetworkとは？概要と広告業界における役割で解説しています。

実務上の判断としては、IDFAの許可率を上げる工夫に投資するより、許可が取れない端末を標準ケースとして計測設計を組み直すほうが確実です。許可率は地域やアプリカテゴリで大きく変わり、EUのように再要求が1年に1回しかできない地域もあるため、全利用者をIDFAで計測できることを前提にしたKPIは、拒否された利用者の成果を捉えられません。ポストバックの変換値の設計とファーストパーティデータの整備を先に済ませ、IDFAは取れたら精度が上がる補助的な入力として扱うのが現実的です。

よくある質問

IDFAは個人情報ですか？

IDFAは、それ自体で特定の個人を識別できず、他の情報との容易な照合によっても識別できない場合には、個人情報に当たりません。ただし個人情報保護委員会のガイドライン（通則編）は、端末識別子を通じて収集した閲覧履歴を「個人関連情報」の事例として挙げています。第三者がそれを個人データとして取得することが想定される提供は、個人情報保護法31条の確認義務の対象になり得ます。

IDFAが00000000-0000-0000-0000-000000000000になるのはなぜですか？

ATTの未要求、拒否、システムによる制限などが原因です。ただし、許可状態だけでは決まらず、シミュレータ、macOS、visionOS上で動くiPhone/iPad互換アプリでも常に全ゼロが返ります。実機で許可済みかどうかはtrackingAuthorizationStatusで確認してください。