2σ Guide

本人同意取得の
適切な方法とログ

企業法務・プライバシー実務で問題になりやすい同意取得を、法的要件、文言設計、証跡管理、撤回連携、監査の観点から整理します。

8原則同意取得の設計軸
18項目同意ログの最低設計
5段階同意管理の成熟度
本ページは株式会社Dプロフェッションズ(医師/医療機関/弁護士/弁護士法人ではありません)が運営しています。
一般的な情報提供を目的としており医療上の助言や法律相談等を行うものではありません。
広告(PR)を掲載しています。広告は編集内容や推奨を意味しません。
Video

本人同意取得の 適切な方法とログ

企業法務 ・プライバシー実務で問題になりやすい同意取得を、法的要件、文言設計、証跡管理、撤回連携、監査の観点から整理します。

動画を読み込み中…
2σ GUIDE ・ VIDEO
本人同意取得の 適切な方法とログ
企業法務 ・プライバシー実務で問題になりやすい同意取得を、法的要件、文言設計、証跡管理、撤回連携、監査の観点から整理します。
動画の文字起こし(全文テキスト)

2σ GUIDE ・ VIDEO

  • 本人同意取得の 適切な方法とログ
  • 企業法務 ・プライバシー実務で問題になりやすい同意取得を、法的要件、文言設計、証跡管理、撤回連携、監査の観点から整理します。

POINT 1

  • 本人同意取得の適切な方法とログの全体像
  • 同意を取る場面、本人が判断できる説明、証跡として残すべきログを一体で整理します。
  • 同意は包括的なお守りではありません
  • 同意要否の判定
  • 判断できる説明

POINT 2

  • 本人同意取得の適切な方法とログで最初に押さえる問題点と基本用語
  • 広告・外部DMP連携
  • 電話や対面の同意
  • 担当者が同意を得たと説明しても、日時、説明文、対象範囲、本人確認、担当者記録がなければ証明が難しくなります。

POINT 3

  • 本人同意取得の適切な方法とログを支える法的枠組み
  • 1. 情報の種類を分類します:個人情報、個人データ、保有個人データ、要配慮個人情報、個人関連情報などを確認します。
  • 2. 利用目的を具体化します:本人が合理的に予測できる程度に、目的と処理内容を整理します。
  • 3. 提供・移転・取得類型を確認します:第三者提供、国外移転、個人関連情報、要配慮個人情報、委託、共同利用を切り分けます。
  • 4. 説明と証跡を設計します:文言、方法、ログ、撤回、下流連携、記録義務をまとめて設計します。
  • 5. 残る義務を管理します:利用目的、公表、通知、安全管理、委託先監督、本人対応などを継続します。

POINT 4

  • 本人同意取得の適切な方法を設計する8原則
  • 1. 変更内容を特定します:利用目的、提供先、移転先国、データ項目、AI分析、広告配信、共同利用の実態を確認します。
  • 2. 本人が合理的に予測できる範囲か確認します:既存説明の範囲を超える場合は、新たな説明と選択肢を検討します。
  • 3. 再同意を設計します:変更点、影響、同意しない場合の扱い、過去データ、撤回方法を説明します。
  • 4. 通知・公表とログを確認します:既存目的の範囲内でも、文言版、通知履歴、本人対応を残します。

POINT 5

  • 本人同意取得の適切な方法に必要な同意文言の作り方
  • 本人が理解できる文言構造、悪い例、改善例を実務目線で確認します。
  • 同意文言は、法的に正確であるだけでなく、本人が理解できる必要があります。
  • 悪い文言では、利用目的、第三者提供先、提供項目、任意性、撤回方法、国外移転、本人の能動的意思表示が不明確になります。
  • 次の比較では、どの点が証拠価値を弱め、どのように改善すると本人が判断しやすくなるかを読み取れます。

POINT 6

  • 本人同意取得の適切なログ設計と証跡管理
  • 個人情報の入れすぎ
  • 氏名、住所、クレジットカード番号、健康情報、本人確認書類画像を分析に必須でない範囲までログに入れないようにします。
  • 編集可能なCSV
  • 誰でも編集できるCSVだけでは、元データとの整合性や改ざん可能性の説明が弱くなります。

POINT 7

  • 本人同意取得の適切な方法とログを支える同意管理システム
  • 1. 中央同意台帳を参照します:本人ID、同意カテゴリ、現在状態、有効期間、文言版を確認します。
  • 2. 処理の対象に含めてよいか判定します:配信、提供、分析、外部送信の直前に有効な同意状態を確認します。
  • 3. 処理実行とログ保存:処理実行ログ、提供記録、連携結果を保存します。
  • 4. 除外と停止:キャッシュ、セグメント、広告リスト、外部アップロードリストから除外します。

POINT 8

  • 本人同意取得の適切な方法とログを場面別に確認する
  • 会員登録、B2B、採用、ヘルスケア、金融、AI、外部送信の実務対応を整理します。
  • 本人同意取得の適切な方法とログは、同じ個人情報保護法の論点でも、事業場面によって重点が変わります。
  • 読者は、自社のデータ取得経路と照らして、抜けやすい証跡を確認できます。
  • 注文ID、同意カテゴリ、配信許諾、広告許諾、撤回、外部送信同意を別々に保存します。

まとめ

  • 本人同意取得の 適切な方法とログ
  • 本人同意取得の適切な方法とログの全体像:同意を取る場面、本人が判断できる説明、証跡として残すべきログを一体で整理します。
  • 本人同意取得の適切な方法とログで最初に押さえる問題点と基本用語:「同意済み」という一言で隠れやすい論点を、用語と証跡の観点から分解します。
  • 本人同意取得の適切な方法とログを支える法的枠組み:同意が必要な場面と、同意だけでは足りない場面を順序立てて確認します。
  • 本動画は一般的な情報提供であり、法律上の助言ではありません。記載の数値・金額・期間は目安です。個別事情で結論は変わります。
Overview

本人同意取得の適切な方法とログの全体像

同意を取る場面、本人が判断できる説明、証跡として残すべきログを一体で整理します。

企業が個人情報、個人データ、個人関連情報、従業員情報、顧客データ、Cookieや広告ID、ヘルスケアデータ、金融・信用情報、位置情報、ログデータを扱うとき、「同意を取っています」という説明だけでは十分とはいえません。重要なのは、本人が何に同意したのか、どの処理範囲だったのか、同意が必要な場面だったのか、撤回や変更がどう反映されたのかを、後から説明できる状態にすることです。

このページは、2026年6月7日時点の公的資料と実務標準を前提に、本人同意取得の適切な方法とログを、個人情報保護法実務、企業法務、内部統制、情報セキュリティ、デジタルフォレンジック、リーガルオペレーションの横断領域として整理します。一般的な情報提供であり、個別案件では事業内容、データ項目、第三者提供先、国外移転先、労務関係、契約関係、システム構成によって結論が変わる可能性があります。

次の重要ポイントは、同意を「形式」ではなく「処理を説明し、選択を記録し、撤回まで管理する仕組み」として理解するためのものです。読者にとって重要なのは、同意文言、取得方法、ログ、安全管理をばらばらに見ず、同じ証跡設計の中で読み取ることです。

同意は包括的なお守りではありません

同意が不要な処理もあれば、要配慮個人情報、第三者提供、外国にある第三者への提供、個人関連情報の一定の提供・取得では、同意または確認・記録が重要になります。ログは、同意の存在、範囲、時点、表示内容、取得方法、撤回履歴を説明する中核的な証跡です。

本人同意取得の適切な方法とログを検討するときは、次の4つの結論を起点にすると全体像を把握しやすくなります。それぞれの項目は、法務、事業部、システム、監査がどこを重点的に確認すべきかを示しています。

Point 1

同意要否の判定

すべての個人情報取扱いに同意が必要なわけではありません。利用目的、データ類型、第三者提供、国外移転、個人関連情報、例外類型を先に整理します。

Point 2

判断できる説明

本人が同意対象を理解できるよう、利用目的、データ項目、処理内容、提供先、撤回方法、本人への影響を具体的に示します。

Point 3

証跡としてのログ

誰が、いつ、どの画面や文言を見て、何に同意し、その後どう変更・撤回されたかを再現できるようにします。

Point 4

ログ自体の保護

ログには個人情報や機微な技術情報が含まれ得ます。最小化、暗号化、アクセス制御、改ざん防止、保存期間、削除を設計します。

Section 01

本人同意取得の適切な方法とログで最初に押さえる問題点と基本用語

「同意済み」という一言で隠れやすい論点を、用語と証跡の観点から分解します。

現場では、会員登録画面のチェック、電話での了承、従業員情報のSaaS連携、Cookieや広告IDの外部送信、過去画面の再現不能、撤回後の処理継続、ログの散在といった相談が起きます。これらは、法律論、画面設計、契約、業務手順、データベース、ログ管理、内部統制が一体で整っていないことから発生します。

次の問題一覧は、本人同意取得の適切な方法とログで見落としやすい場面を表しています。読者にとって重要なのは、どの場面でも「同意したか」だけでなく、「何を示し、どの処理に結び付け、どの証跡で説明するか」を読み取ることです。

広告・外部DMP連携

プライバシーポリシー同意だけで、広告配信、スコアリング、外部DMP連携、グループ会社提供まで含めてよいかが問題になります。

電話や対面の同意

担当者が同意を得たと説明しても、日時、説明文、対象範囲、本人確認、担当者記録がなければ証明が難しくなります。

従業員情報の提供

委託、共同利用、第三者提供、国外移転の切り分けが曖昧だと、人事労務と個人情報保護の両面でリスクが生じます。

過去文言の再現不能

画面が何度も変わった場合、その本人が同意時に見た文言を再現できないと、同意範囲の説明が弱くなります。

撤回後の処理継続

同意撤回、利用停止、配信停止、第三者提供停止が下流システムに反映されないと、処理が継続するおそれがあります。

ログの散在

アクセスログ、CRM履歴、契約書、メール、問い合わせ記録が分散していると、監査時に同意範囲を説明しにくくなります。

基本用語は、同意取得画面やログ項目を設計する前提になります。次の表では、用語ごとの意味と、ログに残すときに注目すべき点を対応させています。

用語意味ログ設計で確認する点
本人対象となる個人情報によって識別される特定の個人です。顧客、会員、採用応募者、従業員、退職者、取引先担当者、未成年者、保護者などが含まれます。本人ID、代理人や保護者との関係、本人確認方法を整理します。
同意本人が個人情報の取扱方法に同意する意思表示です。事業者がその意思表示を認識することが重要です。同意対象、意思表示の方法、同意文言バージョン、同意しない選択肢を記録します。
取得個人情報そのものの取得と、個人情報取扱いへの同意取得は別概念です。問い合わせ情報の取得と、広告配信や第三者提供への同意を分けます。
ログシステムやネットワーク内で発生するイベントの記録です。同意ログには、取得、変更、撤回、失効、再取得、提供、文言変更などが含まれます。アクセスログ、監査ログ、アプリログ、CRM履歴、録音、スキャン、画面キャプチャを紐付けます。
証跡後日、ある事実を説明・立証するための記録です。誰が、いつ、どの方法で、どの表示を見て、どの範囲に同意したかを説明できる形にします。
注意同意は本人の意思表示です。本人が判断できない文言、同意対象を後から拡張する設計、無回答を同意扱いにする運用、同意文言の版を保存しない設計は、法的にも証拠上も弱くなりやすいです。
Section 03

本人同意取得の適切な方法を設計する8原則

書面、Web、アプリ、メール、電話、黙示の扱い、再同意まで整理します。

本人同意取得の適切な方法では、本人が判断できる情報提供、積極的な意思表示、処理前の取得、項目ごとの分離、撤回可能性、証跡性、安全性が重要です。これは画面の見た目だけではなく、事業部、法務、システム、監査が共同で決める統制設計です。

次の8原則は、同意取得方法をレビューするときの比較一覧です。読者にとって重要なのは、どの原則もログ項目や下流連携と結び付いており、文言だけ整えても十分ではない点を読み取ることです。

1

同意対象の特定

利用目的、データ項目、処理内容、提供先、国外移転、保存期間、撤回方法、本人への影響に分解します。

2

判断可能性

本人が合理的に判断できるよう、平易で具体的な説明を行い、専門用語には補足を添えます。

3

能動性

口頭、書面、メール、チェック欄、ボタン、音声入力など、本人が積極的に意思表示したと分かる方法を採ります。

4

事前性

要配慮個人情報、第三者提供、国外移転など、あらかじめ同意が必要な場面では処理前に取得します。

5

分離性

サービスに必要な処理と、広告配信、第三者提供、プロファイリング、任意マーケティングを分けます。

6

撤回可能性

撤回方法、配信停止、第三者提供停止、利用停止請求への対応を事前に設計します。

7

証跡性

取得時の画面、文言、操作、本人確認、時刻、IPアドレス、同意バージョン、撤回履歴を保存します。

8

安全性

同意ログ自体が個人情報を含み得るため、過剰な収集を避け、暗号化、権限管理、削除を設計します。

取得チャネルごとに、強みと弱み、残すべき証跡が異なります。次の一覧は、書面、Web、メール、電話の違いを表しており、読者は自社の取得経路ごとにログ項目が足りているかを確認できます。

01

書面による同意

署名、説明資料、本人控えを一体化しやすい一方、検索性、版管理、撤回連動、紛失対策が課題になります。文書番号、版番号、受付日、本人確認結果、スキャンID、原本保管方針を残します。

版管理
02

Web・アプリによる同意

操作ログを自動取得しやすく、下流システム連携にも向いています。あらかじめ選択済みのチェック欄を避け、重要処理を長文リンクだけに埋め込まず、画面、URL、アプリ版、言語、表示地域を残します。

オンライン表示再現
03

メールによる同意

送信した説明文、添付資料、宛先、送信日時、返信本文、返信日時、本人確認方法を保存します。「了解しました」だけでは対象が曖昧になりやすいため、返信文の指定が有効です。

メール対象明示
04

口頭・電話による同意

有効に成立し得ますが、証跡が弱くなりやすいです。スクリプト、本人確認手順、録音の有無、通話ID、担当者、本人回答、確認メールを残します。

電話録音・履歴

無回答を同意と扱う運用は、本人の意思表示と評価できる事情があるかを慎重に見る必要があります。次の判断の流れは、変更や追加処理が発生したときに再同意を検討する順番を表しており、変更点、本人への影響、過去データの扱いを読み取るために重要です。

再同意を検討する順番

変更内容を特定します

利用目的、提供先、移転先国、データ項目、AI分析、広告配信、共同利用の実態を確認します。

本人が合理的に予測できる範囲か確認します

既存説明の範囲を超える場合は、新たな説明と選択肢を検討します。

範囲を超える
再同意を設計します

変更点、影響、同意しない場合の扱い、過去データ、撤回方法を説明します。

範囲内
通知・公表とログを確認します

既存目的の範囲内でも、文言版、通知履歴、本人対応を残します。

重要一定期間内に本人が回答しなかったことだけをもって同意と扱う運用は、個人情報保護委員会Q&Aでも慎重に扱われています。第三者提供、国外移転、要配慮個人情報、プロファイリング、従業員監視、未成年者の場面では、明示的な意思表示と証跡を重視します。
Section 04

本人同意取得の適切な方法に必要な同意文言の作り方

本人が理解できる文言構造、悪い例、改善例を実務目線で確認します。

同意文言は、法的に正確であるだけでなく、本人が理解できる必要があります。特に、広告配信、第三者提供、国外移転、要配慮個人情報、プロファイリング、任意のマーケティングでは、対象を一つの包括文言に押し込めると説明可能性が弱くなります。

次の表は、同意文言に含めるべき基本構造を表しています。読者にとって重要なのは、各項目をログのIDや文言バージョンと紐付けることで、同意時点の内容を後から再現できるようにする点です。

構成要素本人に示す内容ログとの対応
取扱主体誰が個人情報を取り扱うのかを示します。事業者ID、共同利用管理責任者、提供元を残します。
情報項目氏名、メール、会員ID、購入履歴、閲覧履歴、端末情報などを具体化します。data_category_ids と表示文言の版を残します。
利用目的配送、決済、本人確認、問い合わせ対応、分析、広告効果測定などを分けます。purpose_id と purpose_text_version を残します。
提供先・国外移転誰に提供するか、どの国へ移転するか、どの保護措置があるかを示します。recipient_id、transfer_country、safeguards_version を残します。
任意性と影響同意しない場合に何が利用でき、何が制限されるかを示します。同意カテゴリ、必須・任意の区分、選択肢を残します。
撤回・停止方法マイページ、メール、配信停止、第三者提供停止などの方法を示します。withdrawn、updated、propagated_to などのイベントを残します。
版番号・適用日同意文言の版番号と適用日を示します。consent_text_version、text_hash、screen_snapshot_id を残します。

悪い文言では、利用目的、第三者提供先、提供項目、任意性、撤回方法、国外移転、本人の能動的意思表示が不明確になります。次の比較では、どの点が証拠価値を弱め、どのように改善すると本人が判断しやすくなるかを読み取れます。

観点曖昧な書き方のリスク改善の方向性
利用目的「サービス向上その他必要な目的」では範囲が広すぎます。配送、決済、本人確認、問い合わせ対応、レコメンド、広告効果測定を分けます。
第三者提供「必要に応じて第三者に提供します」では提供先や項目が分かりません。広告配信事業者、提供項目、国外移転の有無、詳細ページを示します。
任意性同意しない場合の影響が不明だと、本人が判断しにくくなります。任意の第三者提供に同意しなくても購入や会員機能は利用できるなど、影響を示します。
意思表示サービス利用を同意とみなすだけでは、本人の能動的な選択を説明しにくくなります。重要処理ごとに未選択のチェック欄や明確なボタンを設けます。
版管理文言版がないと、同意時点の表示内容を再現できません。AD-CONSENT-2026-06-07-v1 のような版番号、ハッシュ、画面キャプチャを保存します。

改善された文言では、データ項目、目的、任意の第三者提供、同意しない場合の影響、詳細情報、撤回方法、版番号が整理されています。読者は、同意文言を「読む文章」としてだけでなく、ログ項目に変換できる情報として確認することが重要です。

文言例広告配信事業者への広告識別子、閲覧履歴、購入カテゴリ情報の提供は任意です。同意しない場合でも、商品の購入および会員機能の利用は可能です。ただし、広告の関連性が低下する場合があります。提供先、提供項目、国外移転の有無、同意撤回方法を確認し、同意する場合は未選択のチェック欄を選択してください。
Section 05

本人同意取得の適切なログ設計と証跡管理

同意の存在、範囲、文言、撤回、下流連携を立証するための項目を整理します。

同意ログの目的は、システム監視だけではありません。本人同意の存在と範囲を立証し、取得時の説明内容を再現し、処理実行時に有効な同意が存在したことを確認し、撤回後の処理停止を保証し、監査・当局対応・紛争対応・情報漏えい対応で説明可能性を確保することです。

次の表は、同意ログの最低限の設計項目を表しています。読者にとって重要なのは、生の個人情報をそのまま増やすのではなく、参照ID、文言版、証拠ファイル、連携状態を使って、証跡性とデータ最小化を両立する点です。

区分記録項目説明
本人識別data_subject_id本人を識別する内部IDです。ログには生の氏名やメールを避け、参照ID化します。
同意者識別consenting_party_id本人、保護者、代理人、法人担当者など、同意者が本人と異なる場合に重要です。
同意単位consent_id / consent_categoryマーケティング、第三者提供、国外移転、要配慮個人情報などの単位で管理します。
目的・データpurpose_id / data_category_ids利用目的のID、文言バージョン、氏名、購買履歴、健康情報などのカテゴリを残します。
提供・移転recipient_id / transfer_country第三者提供先、共同利用先、外国第三者、移転先国、保護措置説明の版を残します。
方法・操作channel / method / actionWeb、アプリ、紙、電話、メール、API、granted、withdrawn、updated、expired などを残します。
時刻occurred_atUTCとJSTの双方、または変換可能な形式で保存します。
画面・文言notice_version / text_hash / screenshot_id同意文言、プライバシーポリシー、画面キャプチャ、ハッシュを結び付けます。
技術情報ip_address / user_agent / session_id必要最小限で保存し、リスクに応じてマスキングやハッシュ化を行います。
本人確認authentication_levelログイン、メール認証、SMS、eKYC、社員番号確認などを残します。
担当者・証拠operator_id / evidence_uri電話、対面、紙受付、録音、PDF、スキャン、電子署名ログを紐付けます。
有効性・連携status / valid_until / propagated_to有効開始、撤回、失効、CRM、MA、DMP、配信基盤への反映状態を残します。
監査created_at / hash_chainログ作成、改ざん検知、監査証跡を管理します。

構造化ログでは、同意ID、本人ID、同意カテゴリ、取得時刻、チャネル、認証レベル、目的ID、データカテゴリ、提供先、国外移転説明版、画面スナップショット、IPアドレスの切り詰め、ユーザーエージェントのハッシュ、連携先の反映結果を一つの証跡としてまとめます。次の重要点は、その証拠価値を左右する要素を表しています。

同意ログの価値は文言との結び付きで決まります

同意文言、本人または代理人の操作、処理前の取得時点、改ざん困難性、閲覧・削除権限、撤回後の停止、同意範囲外処理の不存在を説明できるほど、監査や紛争時の説明可能性が高まります。

ログは証拠であると同時に、個人情報を含む情報資産です。次の注意点は、証跡性を高めるためにログへ何でも複製すると、漏えい時の被害が拡大することを示しています。

個人情報の入れすぎ

氏名、住所、クレジットカード番号、健康情報、本人確認書類画像を分析に必須でない範囲までログに入れないようにします。

編集可能なCSV

誰でも編集できるCSVだけでは、元データとの整合性や改ざん可能性の説明が弱くなります。

管理者の直接更新

管理者権限でも直接更新できない追記型記録、ハッシュ連鎖、監査ログ付きストレージを検討します。

保存期間の未整理

同意に基づく処理継続期間、撤回後の証跡期間、第三者提供記録、民事紛争、データ最小化を踏まえて保存期間表を作成します。

改ざん防止では、追記型テーブル、イベントソーシング、レコードハッシュ、前レコードのハッシュ連鎖、WORMストレージ、オブジェクトロック、監査ログ付きストレージ、時刻同期、電子署名、タイムスタンプ、第三者認証サービス、本番DBの直接編集禁止を検討します。

Section 06

本人同意取得の適切な方法とログを支える同意管理システム

中央同意台帳、イベント記録、下流連携、文言版管理、データマッピングをつなぎます。

大規模企業では、EC、CRM、MA、CDP、DMP、アプリ、コールセンター、店舗、採用管理、従業員管理、SaaS、データウェアハウスが別々に同意フラグを持ちがちです。この状態では、撤回漏れや同意範囲外利用が起きやすくなります。

次の時系列は、同意を単なる現在状態ではなく、取得、撤回、同期成功、同期失敗、再反映のイベントとして管理する考え方を表しています。読者にとって重要なのは、撤回を受け付けただけでなく、処理停止が実際に下流へ反映されたことまで読み取れる点です。

2026-06-07 12:00

広告配信への同意取得

third_party_advertising が granted として記録され、同意文言版と画面スナップショットが紐付きます。

2026-08-01 09:30

広告配信への同意撤回

withdrawn イベントが追記され、現在状態は撤回済みとして更新されます。

2026-08-01 09:31

CRMとタグ管理へ反映

CRMとタグ管理の反映が success として記録されます。

2026-08-01 09:33

広告APIの反映失敗

failed としてアラートが出され、処理停止が未完了であることを検知します。

2026-08-01 09:40

広告APIへの再反映

再反映が success となり、撤回後の処理停止を説明できる状態になります。

下流連携は、同意取得画面よりも事故が起きやすい領域です。次の判断の流れは、配信、提供、分析を実行する前に、同意台帳と連携結果をどう確認するかを表しています。

同意ステータスを処理前に確認する順番

中央同意台帳を参照します

本人ID、同意カテゴリ、現在状態、有効期間、文言版を確認します。

処理の対象に含めてよいか判定します

配信、提供、分析、外部送信の直前に有効な同意状態を確認します。

同意あり
処理実行とログ保存

処理実行ログ、提供記録、連携結果を保存します。

同意なし・撤回済み
除外と停止

キャッシュ、セグメント、広告リスト、外部アップロードリストから除外します。

同意管理は、文言の版管理とデータマッピングが接続されて初めて機能します。次の表では、台帳、版管理、データマッピング、外部事業者管理をどうつなぐかを示しています。

領域管理すべき内容実務上のポイント
中央同意台帳本人ID、同意カテゴリ、状態、有効期間、撤回履歴、連携先を一元管理します。各システムは処理前に台帳を参照し、同意状態に応じて処理を制御します。
文言版管理文書ID、版番号、施行日、廃止日、改定理由、承認者、翻訳版、画面表示場所、文書ハッシュを残します。現在版ではなく、同意取得時点で本人に表示された文言が問題になります。
データマッピングどのシステムに、どの個人データが、何の目的で、誰により、どこへ移転され、どの期間保存されるかを一覧化します。purpose_id が実際の処理と結び付いていなければ、同意状態による制御はできません。
外部事業者連携CRM、MA、DMP、SaaS、広告配信、タグ管理、サーバーサイド送信の反映状況を残します。連携失敗時のアラート、月次突合、外部事業者への撤回通知が必要です。
Section 07

本人同意取得の適切な方法とログを場面別に確認する

会員登録、B2B、採用、ヘルスケア、金融、AI、外部送信の実務対応を整理します。

本人同意取得の適切な方法とログは、同じ個人情報保護法の論点でも、事業場面によって重点が変わります。次の一覧は、各場面で何を分けて説明し、何をログに残すべきかを表しています。読者は、自社のデータ取得経路と照らして、抜けやすい証跡を確認できます。

EC

会員登録・EC

アカウント作成、配送、決済、不正検知、問い合わせ対応などの必須処理と、メールマーケティング、広告配信、外部DMP提供、購買履歴分析、グループ会社提供を分けます。注文ID、同意カテゴリ、配信許諾、広告許諾、撤回、外部送信同意を別々に保存します。

会員広告
B2B

B2B取引・名刺情報

取引先担当者情報も個人情報となり得ます。展示会、ウェビナー、QRコード、名刺管理SaaS、共催セミナーごとに、取得経路、利用目的、共催先提供、メール配信同意、名刺画像IDを記録します。

名刺共催
HR

採用・人事労務

履歴書、適性検査、面接評価、リファレンスチェック、健康情報、在留資格、PCログ、メールログなどでは、同意の自由性と安全配慮義務が関係します。就業規則、社内規程、労使説明、アクセス制御を組み合わせます。

労務自由性
HC

医療・ヘルスケア

歩数、睡眠、心拍、服薬、検査結果、問診、メンタルヘルス、遺伝情報では、要配慮個人情報を念頭に、取得前同意、二次利用同意、撤回、削除、本人確認、保護者同意を慎重に設計します。

健康要配慮
FI

金融・与信・スコアリング

本人確認、信用情報機関、第三者提供、プロファイリング、AIモデル利用が関係します。自動判定やスコアリングでは、データ項目、判定への影響、問い合わせ先を丁寧に説明します。

金融判定影響
AI

AI・データ分析

生成AI、機械学習、レコメンド、チャットボットでは、学習利用、推論利用、第三者AIサービスへの送信、再学習、削除・撤回時の反映範囲を説明し、データセット投入や除外リストを記録します。

AI再学習
AD

外部送信・Cookie・広告

外部タグを通じて閲覧情報、Cookie ID、広告ID、IPアドレス、購入イベントが送信される場合、同意前の送信有無、撤回後の停止、タグ管理権限、サーバーサイド送信を監査します。

外部送信タグ管理
Section 08

本人同意取得の適切なログを監査・内部統制・フォレンジックで使う方法

監査項目、証拠パッケージ、事故時のログ保全を実務的に確認します。

内部監査、コンプライアンス、個人情報保護担当は、同意が必要な処理と不要な処理の整理、利用目的、文言承認、画面・書面・メール・電話スクリプトの版管理、同意ログ、撤回反映、第三者提供記録、国外移転情報、個人関連情報、ログ保護、保存期間、委託先契約を確認します。

次の表は、監査で確認する項目と、その項目から何を読み取るかを表しています。読者にとって重要なのは、同意画面だけでなく、契約、下流システム、ログ保護、保存期間まで一体で見ることです。

監査項目確認内容読み取るポイント
同意要否整理同意が必要な処理と不要な処理の整理表があるか確認します。同意に過度に依存していないかを見ます。
文言承認同意文言、画面、書面、メール、電話スクリプトの法務承認履歴を確認します。過去版と承認者を再現できるかを見ます。
ログ項目本人、同意対象、時刻、方法、文言バージョン、撤回履歴が保存されているか確認します。本人ごとの同意履歴を再現できるかを見ます。
撤回反映同意撤回がCRM、MA、DMP、広告、SaaSへ反映されているか確認します。撤回受付だけで終わっていないかを見ます。
第三者提供記録同意ログとは別に、提供記録・受領記録が作成・保存されているか確認します。法定記録と同意証跡の混同がないかを見ます。
ログ保護アクセス制御、暗号化、改ざん防止、削除、保存期間を確認します。ログ自体の漏えい・改ざんリスクを見ます。
外部事業者委託先・SaaS・広告事業者との契約と実運用を確認します。同意状態の反映、削除、再委託、漏えい対応が契約化されているかを見ます。

紛争、当局照会、本人問い合わせ、漏えい対応、外部監査では、証拠をまとめて提示できることが重要です。次の時系列は、同意取得から処理実行、撤回、証拠保全までをつなげて見るためのものです。

取得時

同意ログと画面を保存します

対象本人分のログ、同意画面、文言、プライバシーポリシー当時版、本人確認ログを保存します。

処理時

提供・配信・分析の実行ログを残します

第三者提供記録、国外移転説明資料、配信・提供・分析の実行ログを紐付けます。

撤回時

下流反映を確認します

同意撤回ログ、CRMや広告基盤への反映ログ、外部事業者への停止通知を残します。

事故・紛争時

証拠保全を行います

アクセス権限凍結、証拠保全イメージ、ハッシュ取得、チェーン・オブ・カストディ、外部事業者へのログ保全依頼を行います。

フォレンジック対応では、調査開始後にログを改変・消失させないことが重要です。次の注意点は、平時の保存期間や保全手順が短すぎると、発覚時には証拠が失われている可能性があることを表しています。

ログ保全命令

不正利用、誤送信、広告タグ誤発火が疑われるときは、関係ログの削除や上書きを止めます。

権限凍結

関係者のアクセス権限、管理者操作、外部SaaS権限を一時的に確認・制限します。

タイムライン分析

同意取得、処理実行、撤回、外部送信、削除、問い合わせの順序を分析します。

外部ログ取得

広告配信、タグ管理、SaaS、委託先のログ取得可能性を契約と運用で事前に確保します。

Section 09

本人同意取得の適切な方法とログを契約・規程・組織体制に落とし込む

委託、第三者提供、共同利用、社内規程、役割分担を整理します。

本人同意取得の適切な方法とログは、個人情報保護部門だけで完結しません。委託契約、第三者提供契約、共同利用管理、社内規程、職掌分担が整っていないと、同意ログがあっても処理実態を統制できません。

次の一覧は、契約・規程に盛り込むべき事項を表しています。読者にとって重要なのは、同意ステータスの反映、撤回・削除対応、ログ提供、監査権、契約終了時の返却・削除まで契約で担保する点です。

委託

委託契約

委託業務の範囲、利用目的外利用の禁止、再委託条件、同意ステータス反映、撤回・削除・停止依頼、ログ提供、セキュリティ、漏えい通知、監査権、終了時削除を定めます。

提供

第三者提供契約

本人同意をどちらが取得するか、同意文言を誰が承認するか、撤回情報を何日以内に通知するか、目的外利用をどう防ぐかを定めます。

共同

共同利用

共同利用者の範囲、利用目的、データ項目、管理責任者、問い合わせ窓口、変更手続、アクセス制御、ログを明確にします。

規程

社内規程

個人情報保護、プライバシーガバナンス、同意管理、第三者提供、委託先管理、外部送信、ログ管理、アクセス権限、保存・削除、インシデント対応、AI・データ利用、従業員情報取扱いを整備します。

役割分担は、同意取得の実効性を左右します。次の表は、各部門・専門職が主に担う責任を示しており、読者は自社で誰が文言、ログ、下流連携、監査、事故対応を持つかを確認できます。

役割主な責任
事業部処理目的、必要データ、ユーザー体験、外部事業者利用の説明を担います。
法務・企業内弁護士法的要否判断、同意文言、契約、リスク判断を担います。
個人情報保護担当個人情報保護法対応、PIA、本人対応、規程整備を担います。
情報セキュリティ担当ログ保護、アクセス制御、暗号化、監視を担います。
システム担当同意台帳、API、ログ実装、データ連携を担います。
マーケティング担当配信、広告、外部タグ、CMP運用を担います。
人事・労務担当従業員情報、就業規則、労使対応を担います。
内部監査担当運用監査、証跡確認、改善勧告を担います。
外部弁護士高リスク案件、当局対応、紛争、国外移転、M&Aを支援します。
デジタルフォレンジック専門家証拠保全、ログ解析、事故調査を支援します。
Section 10

本人同意取得の適切な方法とログでよくある失敗と実装チェックリスト

包括同意、過去版欠落、撤回未反映、過剰ログなどを是正策とともに確認します。

失敗例は、ほとんどが「同意を取った」という形式だけで止まり、同意対象、文言版、下流連携、ログ保護、契約、監査に接続していないことから発生します。次の一覧は、よくある失敗と是正策を示しており、読者は自社の画面・契約・ログを点検できます。

包括同意で全部済ませる

プライバシーポリシー同意だけで重要処理を包括しようとする運用は危険です。同意カテゴリを分け、必要な処理ごとに文言とログを設計します。

過去版がない

本人が見た当時の画面を再現できないと、過去同意の範囲を証明しにくくなります。文言版、画面キャプチャ、HTML、ハッシュ、承認履歴を保存します。

撤回が反映されない

マイページで停止しても、MA、広告リスト、CRM、外部SaaSに残る場合があります。中央同意台帳、連携ログ、アラート、定期突合、削除通知を整備します。

口頭同意の記録がない

営業やコールセンターの説明だけでは証明が難しくなります。スクリプト、録音、応対履歴、同意対象、日時、担当者、確認メールを標準化します。

ログに個人情報を入れすぎる

ログ漏えい時の被害が拡大します。参照ID化、マスキング、暗号化、アクセス制御、保存期間短縮を行います。

グループ共有の誤認

法人格が異なる場合、第三者提供、共同利用、委託、事業承継のいずれに当たるかを確認します。データマップと公表文、契約、アクセス制御を整理します。

同意しない選択肢を隠す

拒否に過剰な手間を課す設計は、本人の自由な判断を害し得ます。UI/UXレビューとダークパターン排除を行います。

次の表は、法務、システム、監査の3つの観点で確認する項目を表しています。読者にとって重要なのは、同意文言だけでなく、ログ項目、連携、保存、監査まで一連のチェックとして読むことです。

観点確認項目
法務同意が本当に必要な処理か、利用目的が具体的か、同意対象が利用目的・データ項目・提供先・国外移転・撤回方法に分解されているか、要配慮個人情報、第三者提供、共同利用、委託、事業承継、個人関連情報、未成年者、従業員情報を確認したかを見ます。
システム同意IDが一意か、文言版とログが紐付くか、画面キャプチャまたは再現可能なHTMLがあるか、同意・撤回が追記型か、UTC/JST時刻があるか、本人確認レベル、下流連携、失敗時アラート、アクセス・エクスポート・削除の監査ログがあるかを見ます。
監査任意の本人の同意履歴を再現できるか、同意取得時点の画面・文言を再現できるか、撤回後に配信・提供・分析が停止しているか、第三者提供記録と同意ログが整合するか、保存期間と削除実績が規程どおりかを見ます。
Section 11

本人同意取得の適切な方法とログをライフサイクルで管理する

本人対応、M&A、専門職別の視点、成熟度、結論をまとめます。

本人から「いつ同意したのか」「どの情報を提供したのか」「同意を取り消したい」「第三者提供を止めたい」「なぜ広告が届くのか」と問い合わせがあった場合、企業は迅速かつ一貫した回答を行う必要があります。問い合わせ担当者は、本人確認後、同意カテゴリ、取得日時、取得方法、文言バージョン、現在状態、撤回方法、反映予定、第三者提供先を確認できる必要があります。

M&A事業譲渡、会社分割、合併、グループ再編、SaaS移行、データ基盤刷新では、同意ログの移管が重要です。買収対象会社が同意取得済みと説明しても、同意文言、取得方法、ログ、撤回履歴、第三者提供記録が確認できなければ、買収後のデータ利用に制約が生じる可能性があります。

次の時系列は、同意管理の成熟度を5段階で表しています。読者にとって重要なのは、形式的な同意から、証跡、下流連携、継続的ガバナンスへ進むほど、データ利活用の説明可能性が高まる点です。

レベル1

形式的同意

プライバシーポリシーへの同意チェックはあるものの、同意対象、ログ、撤回連動が不十分です。

レベル2

文言整備

同意文言、利用目的、第三者提供、国外移転の記載は整っていますが、ログや下流連携が不足しています。

レベル3

証跡整備

同意ログ、文言バージョン、取得方法、撤回履歴が保存され、監査時に一定の証跡を提示できます。

レベル4

統制連動

中央同意台帳が整備され、処理前確認と撤回の自動反映が第三者提供記録、委託先管理、外部送信管理と連携します。

レベル5

継続的ガバナンス

同意管理がデータマッピング、PIA、プロダクト開発、M&A、内部監査、フォレンジック、経営報告に組み込まれています。

専門職ごとの視点を整理すると、本人同意取得の適切な方法とログは、単なるプライバシーポリシーの文言作成ではなく、企業の信頼とデータ利活用の基盤であることが分かります。次の一覧では、各専門職がどの観点を支えるかを示しています。

Legal

弁護士・法務担当

同意要否、同意文言、第三者提供、国外移転、委託、共同利用、契約、紛争、当局対応を整理します。

Privacy

個人情報保護担当

データマッピング、PIA、本人対応、委託先管理、第三者提供記録、国外移転情報、外部送信一覧を管理します。

Security

情報セキュリティ担当

ログの完全性、機密性、可用性、改ざん防止、保全、外部事業者ログ取得可能性を確認します。

Audit

内部監査・経営

規程と実運用の乖離を発見し、同意ログ、画面、提供実績、撤回処理、アクセス権限を経営課題として確認します。

最終的に、本人同意取得の適切な方法とログとは、本人が理解できる内容を、本人が選択できる方法で、処理の前に取得し、その時点の説明内容、意思表示、処理反映、撤回履歴を、改ざん困難かつ過不足のない証跡として管理することです。

結論同意は取得した瞬間に終わるものではありません。利用目的の変更、第三者提供先の追加、SaaS導入、AI分析、広告タグ変更、本人撤回、M&Aによるデータ移転まで、ライフサイクルで管理する必要があります。
FAQ

本人同意取得の適切な方法とログに関するよくある質問

個別判断ではなく、一般的な制度理解と実務上の確認観点を整理します。

Q1. 個人情報を扱う場合は、必ず本人同意が必要ですか。

一般的には、すべての個人情報取扱いに本人同意が必要とは限らないとされています。ただし、要配慮個人情報の取得、第三者提供、外国にある第三者への提供、個人関連情報の一定の提供・取得などでは、同意または確認・記録が重要になる可能性があります。具体的な整理は、データ項目、利用目的、提供先、業法、契約関係によって変わるため、弁護士等の専門家へ相談する必要があります。

Q2. 電話で同意を得た場合でも有効ですか。

一般的には、口頭や電話による同意も成立し得るとされています。ただし、後日の説明可能性を確保するには、同意を取得した方法、日時、担当者、説明文、本人確認、本人の回答、録音や応対履歴を残すことが重要です。具体的な証跡の十分性は、同意対象や処理のリスクによって変わる可能性があります。

Q3. プライバシーポリシーへの同意だけで広告配信や第三者提供まで含められますか。

一般的には、包括的な同意だけでは、本人が何に同意したか説明しにくい場面があります。広告配信、第三者提供、国外移転、プロファイリング、任意のマーケティングなどは、処理内容、提供先、任意性、撤回方法を分けて示すことが重要です。具体的な設計は、サービス内容やデータの種類によって変わります。

Q4. 同意ログにはIPアドレスや端末情報を全部残すべきですか。

一般的には、証跡性のために技術情報が役立つ場合がありますが、ログ自体が個人情報を含み得るため、必要最小限にすることが重要です。IPアドレスの切り詰め、ユーザーエージェントのハッシュ化、参照ID化、暗号化、アクセス制御、保存期間管理を検討します。具体的な保存範囲は、リスク、法令、監査要件、システム構成によって変わります。

Q5. 同意撤回を受けたら何を確認すればよいですか。

一般的には、撤回受付の記録だけでなく、CRM、MA、広告配信、DMP、SaaS、外部事業者への反映状況を確認することが重要です。撤回後もキャッシュ、セグメント、外部アップロードリストに残る可能性があるため、連携ログ、失敗時アラート、定期突合を設計します。具体的な停止範囲は、同意対象と契約関係により変わります。

Reference

この記事の参考資料

個人情報保護、ログ管理、セキュリティログ、国外移転、第三者提供記録に関する公的資料・標準資料です。

個人情報保護に関する資料

  • 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」
  • 個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」
  • 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(第三者提供時の確認・記録義務編)」
  • 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(外国にある第三者への提供編)」

ログ管理・セキュリティに関する資料

  • NIST CSRC Glossary, “Log”
  • NIST SP 800-92 Rev. 1 Initial Public Draft, “Cybersecurity Log Management Planning Guide”
  • NIST SP 800-92, “Guide to Computer Security Log Management”
  • IPA「第4章 1.ログ記録による証跡確保とログ自体の漏えい対策」

国際的な個人データ保護に関する資料

  • Regulation (EU) 2016/679, General Data Protection Regulation