Cookie IDや広告IDを使うだけで一律に同意義務が決まるわけではありません。提供先で個人データとして取得されるか、提供か直接取得か、確認と記録をどう残すかを、企業法務の実務順に整理します。
Cookie IDや広告IDを使うだけで一律に同意義務が決まるわけではありません。
Cookieそのものより、誰がどの時点で個人データとして取得するかを先に整理します。
Cookie利用と個人関連情報提供規制で最初に避けたい誤解は、Cookieを使うこと自体が常に同意バナーの義務へ直結すると考えることです。日本法では、Cookie ID、広告ID、端末識別子、閲覧履歴、購買履歴、位置情報、興味関心セグメントが、どの主体にとって、どの時点で、どのデータベース上で、誰を識別できる状態にあるかを分けて検討します。
個人関連情報は、生存する個人に関する情報で、個人情報、仮名加工情報、匿名加工情報のいずれにも該当しないものです。Cookie等の端末識別子を通じて収集された閲覧履歴は典型例になり得ますが、会員ID、氏名、メールアドレスなどと容易に照合できる場合は、個人情報または個人データの問題へ移ります。
次の5つの問いは、検討の順番を表します。なぜ重要かというと、表示や同意の要否だけを先に決めると、個人データ第三者提供、外国第三者提供、外部送信規律、広告規約の論点を落としやすいからです。順番どおりに読むと、当社側の分類、提供行為、提供先の取得態様、必要な証跡、周辺規律を切り分けられます。
Cookie等に紐づく情報が、当社にとって個人情報、個人データ、個人関連情報、統計情報のどれに近いかを確認します。
当社が第三者へ情報を渡しているのか、第三者がタグ等を通じて利用者から直接取得しているのかを確認します。
提供先が自社の会員情報や広告アカウントに付加し、個人データとして取得することが想定されるかを確認します。
31条が適用される場合、本人同意、提供元の確認、記録、外国にある第三者への情報提供を整理します。
識別子の名称ではなく、照合可能性とデータベース上の扱いで分類します。
以下の一覧は、Cookie周辺で登場する技術と法務上の注意点を整理したものです。重要なのは、名称がCookieかどうかではなく、端末識別、行動把握、広告計測、データ連携に使われる情報かどうかです。各行では、どの技術がどの実務場面で問題になりやすいかを読み取れます。
| 技術・識別子 | 典型例 | 法務上の注意点 |
|---|---|---|
| ファーストパーティCookie | ログイン維持、カート保持 | 自社が会員ID等と紐付ければ個人データになり得ます。 |
| サードパーティCookie | 広告配信、リターゲティング | ブラウザ制限、広告規約、個人関連情報提供規制、外部送信規律、海外法を併せて確認します。 |
| タグ・ピクセル | 広告計測タグ、アクセス解析タグ | サイト運営者が情報を取り扱うのか、タグ提供者が直接取得するのかを区別します。 |
| SDK | アプリ内広告、アクセス解析、クラッシュ解析 | Cookieではなくても、端末識別子、利用履歴、位置情報等を送信し得ます。 |
| 広告ID | IDFA、AAID等 | ユーザー設定、OSポリシー、広告事業者規約、個人情報保護法をまとめて確認します。 |
| ローカルストレージ等 | ブラウザ保存領域 | Cookieという名称でなくても、利用者端末に情報を記録・送信させる場合があります。 |
| ハッシュ化メールアドレス | 広告マッチング、顧客リスト広告 | ハッシュ化だけで個人データ性が当然に消えるわけではなく、照合可能性と提供先での紐付けを確認します。 |
次の比較は、似た用語の違いを表します。この区別が重要なのは、同じ閲覧履歴でも、当社側で個人データになる場合と、提供先で個人データ化される個人関連情報になる場合で、必要な対応が変わるためです。列を左から右へ読むと、一般的な意味とCookie実務での見方を対応づけられます。
| 用語 | 平易な説明 | Cookie実務での意味 |
|---|---|---|
| 個人情報 | 生存する個人に関する情報で、特定個人を識別できるもの、または個人識別符号を含むものです。 | 会員ID、氏名、メールアドレス等と容易に照合できる閲覧履歴は、全体として個人情報になり得ます。 |
| 個人データ | 個人情報データベース等を構成する個人情報です。 | CRM、会員DB、広告配信DBで検索可能に管理される情報は、第三者提供規制、記録義務、安全管理措置の対象になり得ます。 |
| 個人関連情報 | 個人情報、仮名加工情報、匿名加工情報のいずれでもない、生存する個人に関する情報です。 | 単体では特定個人を識別できないCookie IDに紐づく閲覧履歴、購買履歴、興味関心、位置情報などが典型例です。 |
| 統計情報 | 特定個人との対応関係が排斥された集計情報です。 | 個人ごとの履歴へ戻れない集計値であれば、個人関連情報にも該当しないことがあります。 |
個人関連情報データベース等は、Cookie IDや広告IDをキーとして履歴や属性を検索できる形で保持する場面で問題になりやすいです。広告配信、アクセス解析、CDP、DMP、マーケティングオートメーション、アプリ解析では、この点を最初に確認します。
提供先で個人データとして取得されるか、提供時点で客観的に確認します。
31条の判断は、提供先が個人関連情報を個人データとして取得することが想定されるかに集中します。なぜ重要かというと、個人関連情報の第三者提供一般を禁止する制度ではなく、提供先の取得態様によって対応が変わるからです。次の判断の流れでは、提供、直接取得、個人データ化、同意確認の順番を読み取れます。
当社がCookie IDや閲覧履歴を取得、加工、保持しているかを確認します。
当社からAPI、ファイル、サーバーサイド計測等で渡しているかを確認します。
提供先が会員DB、広告アカウント、CRM等へ付加し、個人データとして取得するかを確認します。
本人同意、確認方法、記録保存、外国第三者提供の情報提供を設計します。
31条以外に、外部送信規律、表示、契約、広告規約、海外法を確認します。
提供時点基準も重要です。提供時点で個人データとして取得することが想定されないのであれば、後日に提供先の利用が変わっただけで提供元が当然に31条違反になるわけではありません。ただし、提供先が実際には個人データ化する事情がうかがわれる場合は、契約文言だけで終わらせず追加確認が必要です。
タグ設置では、A社がB社タグで収集される閲覧履歴を取り扱っていなければ、A社からB社への提供ではなく、B社が利用者から直接取得したものと整理される場合があります。一方で、A社サーバーで取得・加工・保持してからB社へ連携する場合や、A社がダッシュボードで抽出・再利用できる場合は、実態確認が必要です。
自社ログイン、解析、広告、CDP、サーバーサイド計測では確認点が変わります。
次の一覧は、Cookie利用の類型ごとにリスクの強さを比較するものです。重要なのは、同じ識別子でも、自社ログインとの紐付け、広告事業者の独自利用、顧客DBへの付加、サーバーサイド送信があるほど確認項目が増える点です。横棒の長さは、31条、個人データ第三者提供、外国提供、外部送信規律が重なりやすい度合いを表します。
類型ごとの要点は、次のように整理できます。なぜ重要かというと、導入時に同じ「広告・解析ツール」として扱うと、提供か直接取得か、委託か共同利用か、個人データ化されるかの区別が埋もれるためです。各項目では、実務で最初に確認すべき情報を読み取れます。
閲覧履歴や購買履歴を会員ID、メールアドレス、配送先等と容易に照合できる場合、当社側で個人データとして扱う可能性があります。
利用目的第三者提供広告会社や広告主の顧客データへ付加される場合、提供先で個人データとして取得される可能性があります。
同意確認広告規約購入日時、商品、金額、ハッシュ値、IPアドレス、広告クリックID等を送る場合、提供、委託、共同利用、外国提供を個別に確認します。
送信ログ越境確認識別子を介した顧客データの結合、属性推定、セグメント作成では、照合可能性と再識別リスクを具体的に確認します。
照合制御再提供31条が適用される場合は、同意取得主体、確認方法、同意範囲、証跡保存を分けます。
31条の本人同意は、個人関連情報が第三者へ提供され、その第三者が本人を識別する個人データとして取得することを本人が承諾する意思表示です。単にウェブサイトへ記載するだけでは足りず、合理的かつ適切な範囲の内容を明確に示し、ボタン操作などで同意意思を確認できる必要があります。
次の表は、同意、確認、記録で残すべき証跡をまとめています。重要なのは、提供元が「同意取得済み」と聞くだけで終わらせず、同意画面、対象情報、利用目的、IDリスト、誓約、契約、ログを組み合わせて説明できる状態にすることです。左列が確認対象、右列が保存・確認する具体資料です。
| 確認対象 | 実務で残す資料 |
|---|---|
| 同意取得画面 | 同意文言、表示画面、取得日時、文言バージョン、撤回方法を保存します。 |
| 対象情報 | Cookie ID、広告ID、閲覧履歴、購買履歴、ハッシュ値など、提供される項目を特定します。 |
| 提供先の主体 | 個人データとして取得する主体、取得後の利用目的、広告・分析・レコメンド等の用途を示します。 |
| 確認方法 | 申告、誓約書、同意書面、IDリスト、提供元による同意取得代行のいずれかを明確にします。 |
| 同意範囲 | 閲覧履歴の同意で商品購買履歴まで含まれるかなど、対象情報と目的の範囲を確認します。 |
| 外国第三者 | 提供先国、保護制度、提供先が講じる措置、変更時の確認方法を整理します。 |
| 監査・是正 | 契約、DPA、仕様書、抽出条件、API送信ログ、削除証跡、照会・是正記録を保存します。 |
個人情報保護法31条だけでなく、外国提供と電気通信事業法の確認も並行します。
外国にある第三者へ個人関連情報を提供し、その第三者が個人データとして取得する場合は、本人への情報提供、当該外国の制度、提供先が講じる保護措置、継続的確認が問題になります。海外広告プラットフォーム、海外SaaS、グローバルCDP、アプリSDKでは、保存国、処理国、再委託国まで確認します。
次の比較は、個人情報保護法31条と電気通信事業法の外部送信規律の違いを表します。重要なのは、31条が適用されないタグ設置でも、外部送信規律では利用者端末から外部へ情報が送信されること自体が問題になり得る点です。各行を比較すると、対象情報、中心義務、タグ設置の評価が異なることが分かります。
| 観点 | 個人情報保護法31条 | 電気通信事業法の外部送信規律 |
|---|---|---|
| 主な関心 | 個人関連情報が提供先で個人データ化されることです。 | 利用者端末から外部へ利用者情報が送信されることを利用者が認識しにくいことです。 |
| 対象情報 | 個人関連情報データベース等を構成する個人関連情報です。 | 個人情報に限らず、Cookie ID、閲覧URL、行動履歴等を広く含み得ます。 |
| 中心義務 | 本人同意が得られていること等の確認と記録です。 | 通知・公表、同意、オプトアウト等による確認機会の付与です。 |
| 提供概念 | 提供元から第三者への提供が問題になります。 | 利用者端末から外部設備への送信指令が問題になります。 |
| タグ設置 | サイト運営者が閲覧履歴を取り扱わなければ、提供でない場合があります。 | 31条が適用されなくても、対象になり得ます。 |
| ファーストパーティ送信 | 通常は第三者提供でないため、31条問題になりにくいです。 | 利用者端末の外への送信であれば、一定の場合に対象になり得ます。 |
情報の流れを描き、主体ごとに分類し、提供形態と客観的事情を確認します。
次の表は、Cookie実務でよく出るデータを、当社側と提供先側で分類し直すためのものです。なぜ重要かというと、当社では個人関連情報でも、提供先では個人データとして取得されることがあるためです。列を横に読むと、同じデータでも主体によって注意点が変わることが分かります。
| データ | 当社での分類 | 提供先での分類 | 注意点 |
|---|---|---|---|
| Cookie ID単体 | 個人関連情報の可能性があります。 | 提供先で個人データに付加される可能性があります。 | 31条の中心論点になりやすいです。 |
| 会員ID付き閲覧履歴 | 個人データの可能性があります。 | 個人データとして受領される可能性があります。 | 個人データ第三者提供、外国提供、委託、共同利用を検討します。 |
| 広告セグメント | 個人関連情報の可能性があります。 | 広告アカウントと紐付く可能性があります。 | 提供先の利用実態確認が重要です。 |
| 集計レポート | 統計情報の可能性があります。 | 統計情報の可能性があります。 | 再識別、小集団、粒度に注意します。 |
| ハッシュ化メール | 個人データの可能性があります。 | 照合キーの可能性があります。 | ハッシュ化だけで匿名とは扱えません。 |
判断では、提供か直接取得か、委託か共同利用か、個人データ第三者提供か、外国第三者提供かを分けます。客観的事情として、契約、仕様書、管理画面、営業資料、API仕様、データ項目、突合キー、再提供先、広告プラットフォームの利用目的を確認します。
「31条の対象です」「対象ではありません」と結論だけを残すのではなく、提供時点でどの資料を見て、どの主体で、どの分類をしたかを判断メモとして残すことが、後日の説明可能性を高めます。
契約条項、利用者向け表示、タグ承認、証跡管理を一体で運用します。
次の一覧は、データ提供契約で確認すべき項目を表します。重要なのは、個人データ化しない場合とする場合で、禁止事項、同意確認、監査、違反時対応を分けることです。各項目を読むと、契約審査で落としやすい論点を把握できます。
Cookie ID、広告ID、閲覧履歴、購買履歴、ハッシュ値などを定義し、広告、分析、レコメンド、不正検知などの目的を特定します。
個人データとして取得するかを明記し、取得しない場合は照合、結合、再識別、顧客DBへの付加を禁止します。
同意取得主体、同意文言、対象情報、提供先、利用目的、IDリスト、証跡提供を定めます。
提供先国、処理国、保存国、再委託国、本人への情報提供、保護措置、変更通知を整理します。
アクセス制御、暗号化、ログ管理、削除、インシデント通知、監査報告、第三者認証を確認します。
目的外利用、無断個人データ化、再提供、漏えい、不適正取得が判明した場合の停止、削除、通知、解除、当局対応協力を定めます。
利用者向け表示は、プライバシーポリシー、Cookieポリシー、外部送信一覧の3層で整理します。プライバシーポリシーでは個人情報全体、Cookieポリシーでは種類・目的・管理方法、外部送信一覧ではタグ・SDKごとの送信情報、送信先、利用目的、保存期間、オプトアウトを示します。
次の一覧は、社内部門ごとの役割を表します。重要なのは、法務だけでなく、マーケティング、IT、セキュリティ、調達、内部監査、経営層が同じ情報を見て判断できることです。各行を読むと、どの部門がどの証跡を持つべきかが分かります。
| 部門・職種 | 主な役割 |
|---|---|
| 法務担当・企業内弁護士 | 法的分類、31条適用判断、契約審査、同意文言、当局対応を担います。 |
| 個人情報保護・プライバシー担当 | データマッピング、ポリシー、本人対応、教育を担います。 |
| マーケティング部門 | 広告目的、タグ導入、キャンペーン要件、効果測定を管理します。 |
| IT・セキュリティ部門 | タグ管理、SDK管理、ログ、アクセス制御、脆弱性管理を担います。 |
| 調達・購買部門 | ベンダー審査、DPA、セキュリティチェックを担います。 |
| 内部監査・内部統制 | 運用状況、証跡、承認手順、例外管理を監査します。 |
| 経営層・リスク管理 | 事業インパクト、ブランドリスク、重大方針決定を担います。 |
ケースごとの結論は、情報の取扱い、提供先の取得態様、周辺規律で変わります。
次の4つの事例は、典型的な分岐を表します。重要なのは、同じ広告タグや閲覧履歴でも、当社が取り扱うか、提供先が個人データ化するか、統計情報に戻れないかで評価が変わることです。各項目では、一般的に確認すべき方向性を読み取れます。
サイト運営者が詳細閲覧履歴を取り扱わず、タグ提供者が直接取得する整理になり得ます。ただし、外部送信規律や表示対応は別途確認します。
広告主がCookie IDに紐づく閲覧履歴を自社会員IDへ付加する場合、31条に基づく同意確認が問題になりやすいです。
契約上の誓約は31条非適用の方向に働きますが、実際の利用から個人データ化がうかがわれる場合は追加確認が必要です。
個人単位のIDや履歴へ戻れない統計情報なら個人関連情報に該当しない可能性があります。小集団や再識別可能性には注意します。
一般的には、単体で常に個人情報とは限らないとされています。ただし、他の情報と容易に照合して特定個人を識別できる場合は、全体として個人情報に該当する可能性があります。具体的な分類は、管理方法や照合可能性を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、日本の個人情報保護法だけを見れば、すべてのCookie利用で一律に同意バナーが必要になるわけではないとされています。ただし、31条、個人データ第三者提供、外国第三者提供、外部送信規律、海外法、広告規約によって対応が変わる可能性があります。
一般的には、サイト運営者が閲覧履歴を取り扱わず、タグ提供者が利用者から直接取得する整理になる場合があります。ただし、取得・加工・保持・再利用の実態によって結論は変わります。
一般的には、契約上の誓約は重要な事情になります。ただし、提供先の実際の利用、管理画面、仕様、営業資料、過去運用から個人データ化がうかがわれる場合は、追加確認が必要です。
一般的には、31条の同意確認と、個人データ第三者提供のオプトアウト制度や外部送信規律上のオプトアウトは別の制度です。どの規律に基づく措置なのかを分けて確認する必要があります。
一般的には、ハッシュ化は安全管理や照合制御の手段になり得ますが、それだけで個人情報性や個人データ性が当然に消えるわけではないとされています。ソルト、辞書攻撃可能性、照合キー共有、提供先での突合可能性を確認します。
一般的には、法人担当者の閲覧履歴、メールアドレス、役職、資料請求履歴、IPアドレス、広告ID等が、生存する個人に関する情報として問題になる可能性があります。具体的な対応は、取得情報と利用実態を整理して確認する必要があります。
初期調査、契約審査、表示・同意、改正動向監視を短期計画に落とします。
次のチェック項目は、初期調査、契約審査、表示・同意の3段階を表します。重要なのは、タグを見つけるだけでなく、送信先、利用目的、保存期間、再提供先、同意証跡まで一つの管理表で追えるようにすることです。上から順に確認すると、未整備の場所を発見しやすくなります。
| 段階 | 確認項目 |
|---|---|
| 初期調査 | サイト・アプリごとのCookie、タグ、SDK、API連携、送信情報、送信先、利用目的、保存期間、再提供先を一覧化します。 |
| 分類判断 | 自社と提供先のそれぞれで、個人情報、個人データ、個人関連情報、統計情報のいずれかを分類します。 |
| 提供形態 | タグ経由の直接取得か、自社からの提供か、委託か、共同利用か、外国第三者提供かを整理します。 |
| 契約審査 | 個人データ化の有無、照合禁止、同意取得主体、外国提供、再委託、安全管理、ログ、監査、事故通知、改正対応条項を確認します。 |
| 表示・同意 | 提供先、送信情報、利用目的、個人データとして取得される点、拒否・撤回方法、同意ログ、外部送信一覧への導線を整備します。 |
次の日程は、90日で着手する順番を表します。重要なのは、最初の30日で全体像を可視化し、次の30日で法的判断と契約補正を進め、最後の30日で表示、ログ、承認手順、研修へ落とすことです。時系列で読むと、何を先に固めるべきかが分かります。
全サイト・アプリのタグ・SDKを棚卸しし、送信先、送信情報、利用目的を一覧化します。高リスク連携として、個人データ化、外国第三者、広告プロファイリング、再提供、独自利用を抽出します。
プライバシーポリシー、Cookieポリシー、外部送信一覧を更新します。タグマネージャー権限、同意管理、監査ログ、提供記録、研修、半期ごとのタグ監査を制度化します。
令和8年改正法案として、2026年4月7日に個人情報保護法等の一部を改正する法律案が閣議決定されたことも、継続監視が必要です。改正法の成立状況、公布日、施行日、政令、委員会規則、ガイドライン、Q&A、課徴金制度、統計等作成目的の第三者提供に関する同意不要措置、広告・プロファイリングに関する新解釈を確認します。
公的資料と中立的な実務資料を、URLなしで整理します。