Cookieだけでなく、タグ、SDK、広告ID、端末情報、閲覧URLなど、利用者端末からの情報送信をどう把握し、表示し、運用するかを企業法務・データ法務向けに整理します。
Cookieバナーの有無ではなく、利用者端末からどの情報が誰に送られるかを確認する制度です。
Cookieバナーの有無ではなく、利用者端末からどの情報が誰に送られるかを確認する制度です。
電気通信事業法改正による外部送信規律のポイントは、Webサイトやアプリを通じて、利用者の端末から利用者に関する情報を外部へ送信させる仕組みについて、利用者が確認できる機会を設ける点にあります。単にCookieを使うかどうか、バナーを出しているかどうかだけで判断する制度ではありません。
典型例は、アクセス解析ツール、広告配信タグ、アフィリエイトタグ、SNSプラグイン、地図・動画・チャット等の外部サービス埋込み、アプリ内SDK、計測モジュールなどです。Cookie ID、広告ID、閲覧URL、アプリ利用履歴、端末情報、ログ、位置情報、入力情報などが広く問題になり得ます。
次の重要ポイントは、外部送信規律を形式対応ではなくデータガバナンスとして見るための要点を示しています。読者にとって重要なのは、表示文言を作る前に、サービス該当性、送信実態、更新運用を同時に確認する必要がある点です。
外部送信規律は、利用者に関する情報が利用者以外の者の設備へ送られる場面で、送信情報、取扱者名、利用目的を分かりやすく示すことを求める制度として整理できます。
次の一覧は、企業が最初に確認すべき6つの論点を並べたものです。どれか一つだけで結論を出すのではなく、上から順に確認することで、対象外と思い込むリスクと過剰な表示で運用不能になるリスクの両方を抑えられます。
電気通信事業者又は第三号事業を営む者に関係するサービスかを確認します。
メッセージ媒介、投稿の場、検索、ニュース・動画・地図等の情報提供に当たるかを確認します。
ブラウザ又はアプリケーションを通じて利用者に提供されているかを確認します。
タグ、Cookie、SDK、JavaScript、ピクセル、外部埋込み等で端末から送信が起きるかを確認します。
送信される情報、情報を取り扱う者、利用目的をツールやモジュールごとに示せるかを確認します。
新規ツール導入、SDK更新、ベンダー変更、送信先・利用目的変更のたびに表示を更新できるかを確認します。
外部サービスへの自動送信が見えにくいからこそ、制度の射程をCookieだけに狭めない理解が必要です。
現代のWebサイトやアプリでは、利用者がページを閲覧したりアプリを起動したりするだけで、事業者のサーバだけでなく、アクセス解析、広告配信、CDN、SNS、動画配信、地図表示、チャットサポート、A/Bテスト、レコメンド、クラッシュ解析等の外部サービスに情報が送信されることがあります。
利用者から見ると、どの会社に、どの情報が、どの目的で送信されているかは分かりにくいものです。外部送信規律は、このような情報送信について、利用者が事前に確認できる機会を確保することを目的とします。
「日本版Cookie規制」と呼ばれることがありますが、法令上の射程はCookieそのものに限られません。Cookieに保存されたID、広告ID、閲覧したWebページのURL、端末情報、氏名等の情報も検討対象になり得ます。Cookieを使っていなくても、アプリSDKやJavaScript、ピクセルタグが利用者に関する情報を送信する場合は確認が必要です。
次の基本概念の一覧は、外部送信規律の判断で混同しやすい用語を整理したものです。読者にとって重要なのは、登録・届出のある通信会社だけでなく、一般企業のWebサービスやアプリにも波及し得る点を読み取ることです。
電気通信役務を他人の需要に応ずるために提供する事業をいいます。自社の本来業務の遂行手段にとどまるか、他人向けの場や情報配信として提供しているかが重要です。
登録・届出が不要な形で提供される電気通信事業も含まれ得ます。Webサービス、アプリ、オンラインプラットフォーム、情報提供サイト等も検討対象になります。
利用者の端末に記録された利用者に関する情報を、利用者以外の者の設備に送信する機能を起動する指令を与える通信です。
個人情報より広く、Cookie ID、広告ID、閲覧URL、検索履歴、アプリ利用履歴、IPアドレス、User-Agent、位置情報、入力情報等が含まれ得ます。
第三者サーバだけでなく、利用者が認識しているかを問わず、Webサイト運営者やアプリ提供者のサーバも含まれ得ます。
原則は通知又は容易に知り得る状態に置くことです。同意取得やオプトアウト措置は、利用者に確認機会を与える設計として検討します。
全てのWebサイト・アプリが無条件に対象となるわけではなく、サービス単位で4類型への該当性を検討します。
電気通信事業法第27条の12の外部送信規律は、すべてのWebサイトやアプリに一律に適用されるものではありません。施行規則上、利用者の利益に及ぼす影響が少なくない電気通信役務として、主に4つの類型が示されています。
次の比較表は、対象役務の4類型と典型例を整理したものです。読者にとって重要なのは、自社サイトの名称ではなく、利用者間通信、投稿の場、検索、情報提供という機能面から読み取る点です。
| 類型 | 典型例 | 実務上の着眼点 |
|---|---|---|
| 他人の通信を媒介する役務 | メール、ダイレクトメッセージ、宛先を指定するWeb会議等 | 利用者間の通信を、内容を変更せず取り次ぐかを確認します。 |
| 投稿・入力情報を不特定利用者に送信する場 | SNS、掲示板、動画共有、オンラインモール、シェアリング、マッチング、ライブ配信、オンラインゲーム等 | 利用者が投稿・出品・募集等を行い、不特定利用者が閲覧できるかを確認します。 |
| 全Web検索サービス | インターネット上の全Webページを検索対象とする検索サービス | 特定分野の検索は、情報提供サービス側で検討する場合があります。 |
| 不特定利用者への情報提供サービス | ニュース、気象、動画配信、オンライン地図、求人情報、各種情報メディア等 | 独立した情報配信事業か、自社本来業務の遂行手段にすぎないかを確認します。 |
対象可能性はサービスの機能によって変わります。次の比較表は、一般的な検討例を高低で整理したものです。あくまで出発点であり、個別事情によって結論が変わるため、どの機能があると対象に近づくかを読み取ることが重要です。
| サービス | 対象可能性 | 理由・留意点 |
|---|---|---|
| SNS、掲示板、口コミサイト | 高い | 利用者投稿を不特定利用者が閲覧する場を提供するためです。 |
| オンラインモール、フリマ、シェアリング | 高い | 複数出品者・利用者間の取引や投稿の場を提供するためです。 |
| ニュース、動画、地図、求人情報メディア | 高い | 不特定利用者への情報提供サービスに該当し得るためです。 |
| メール、チャット、DM、Web会議 | 高い | 他人の通信を媒介する役務に該当し得るためです。 |
| オンラインゲーム | 中〜高 | リアルタイム送信、投稿、チャット、ランキング等の機能により対象となり得ます。 |
| 自社商品のみを販売するEC | 低〜中 | 自社本来業務の遂行手段にとどまる場合は対象外寄りですが、モール化・投稿化・情報配信化している場合は検討が必要です。 |
| 企業の会社案内サイト | 低 | 自己の情報発信のためのホームページは、電気通信事業に該当しないと整理される場面があります。 |
| 採用情報のみのページ | 低〜中 | 自社採用情報の掲載なら対象外寄りですが、求人情報メディアを独立事業として提供する場合は検討が必要です。 |
| 社内限定ポータル | 低 | 閉域・特定利用者向けで、不特定利用者への提供ではない場合が多いです。 |
同一ドメイン内に複数の性質のページが混在することもあります。ニュース配信サイトの中の会社概要ページなどでは、対象範囲を保守的に広く捉えて外部送信ポリシーを全体表示する選択もあり得ますが、表示内容は実際の送信実態と整合させる必要があります。存在しない送信先や利用していない目的を列挙すると、透明性を損ないます。
過剰対応と過少対応を避けるには、サービス単位で段階的に確認することが重要です。
外部送信規律への対応では、すべての企業ホームページや自社ECを一律に対象と決めつける過剰対応と、通信会社ではない、届出をしていない、Cookieは個人情報ではないと考えて検討を打ち切る過少対応の両方が起こりがちです。
次の判断の流れは、適用要否をサービス単位で確認する順番を表します。読者にとって重要なのは、前半で対象役務性を確認し、後半で実際の送信と適用除外、表示方法を確認するという読み方です。
他人の需要に応ずるために電気通信役務を提供する事業かを確認します。
電気通信事業者又は第三号事業を営む者に該当し得るかを確認します。
メッセージ媒介、投稿の場、全Web検索、情報提供サービスに当たるかを確認します。
ブラウザ又はアプリケーションを通じ、情報送信指令通信が行われているかを確認します。
通知・公表、同意、オプトアウト措置の設計へ進みます。
判断根拠を記録し、機能追加時に再確認します。
次の注意点の一覧は、判断時に起こりやすい偏りを整理したものです。なぜ重要かというと、どちらの偏りも表示漏れや運用不能につながるためで、読み取るべき点は「対象外と決めつけない」「実態と合わない表示を増やさない」の両立です。
会社案内、採用ページ、自社ECを一律に対象扱いすると、表示の粒度が粗くなり、更新負荷も過大になります。
第三号事業を営む者も対象になり得るため、Webサービスやアプリ運営者でも検討が必要です。
SDK、広告ID、閲覧URL、端末情報、ピクセル、外部埋込みによる送信を見落とすおそれがあります。
送信される情報、送信先、利用目的、適用除外、表示導線まで確認しなければ実務対応として不足し得ます。
情報送信指令通信ごとに、送信情報、取扱者名、利用目的を利用者が確認できる状態にします。
外部送信規律の原則的な対応は、利用者に対し必要事項を通知し、又は利用者が容易に知り得る状態に置くことです。実務では、外部送信ポリシー、Cookieポリシー、プライバシーポリシー内の独立項目、アプリ内表示等により対応する例が多く見られます。
公表の場合、情報送信指令通信を行うWebページ又はそこから容易に到達できるWebページに通知事項を表示する方法が考えられます。アプリでは、最初に表示される画面又はそこから容易に到達できる画面に表示する方法が問題になります。容易に到達できるとは、1回程度の操作で到達でき、リンク先に表示があることを利用者が理解できる配置であることが目安です。
次の比較表は、通知・公表の必須事項をツール別に整理した記載イメージです。読者にとって重要なのは、ツール名だけでなく、送信される情報、情報を取り扱う者、自社と送信先の利用目的まで具体的に読み取れる粒度にする点です。
| ツール・タグ・SDK | 送信される情報 | 情報を取り扱う者 | 利用目的 |
|---|---|---|---|
| アクセス解析ツール | Cookie ID、閲覧ページURL、閲覧日時、端末・ブラウザ情報、リファラ、IPアドレス等 | 解析ツール提供会社 | アクセス解析、サービス改善、利用状況分析 |
| 広告配信タグ | Cookie ID、広告ID、閲覧URL、クリック情報、コンバージョン情報等 | 広告配信事業者 | 広告配信、広告効果測定、興味関心に応じた広告表示 |
| SNS埋込み | 閲覧ページURL、IPアドレス、ブラウザ情報等 | SNSサービス提供会社 | SNSコンテンツ表示、利用状況把握 |
| 地図埋込み | IPアドレス、位置に関する情報、閲覧ページ情報等 | 地図サービス提供会社 | 地図表示、サービス提供、品質改善 |
| アプリ解析SDK | 広告ID、端末情報、アプリ利用イベント、クラッシュログ等 | SDK提供会社 | アプリ利用状況分析、不具合解析、広告効果測定 |
表示では、「等」「その他」を多用しすぎると、利用者がどのような情報が送信されるのかを把握しにくくなります。抽象的に「利用者情報等をサービス改善等のために外部送信します」と書くのではなく、Cookie ID、閲覧ページURL、閲覧日時、端末・ブラウザ情報、IPアドレスなど、利用者が理解できる粒度で示すことが望ましいです。
次の一覧は、通知・公表を読みやすくするための設計要素をまとめたものです。なぜ重要かというと、形式的にリンクを置くだけでは確認機会として不十分になり得るためで、読み取るべき点は「日本語」「到達しやすさ」「情報の具体性」「送信先名の分かりやすさ」です。
外国語のベンダーポリシーへのリンクだけで済ませず、一般利用者が読める表現にします。
フッター、ヘッダー、設定画面、アプリ内ヘルプなどから内容が分かるリンク文言で到達できるようにします。
法人名よりサービス名が認知されやすい場合は、正式名称とサービス名を併せて記載します。
広告効果測定などの自社目的に加え、送信先が広告配信最適化、不正検知、サービス改善等に用いる場合も整理します。
すべての送信が表示対象になるわけではありませんが、First Party Cookieや同意取得を短絡的に扱うのは危険です。
外部送信規律には、通知等を行う必要まではないと考えられる情報について適用除外があります。もっとも、適用除外は送信先が自社か第三者かだけで決まるものではなく、送信される情報の性質、目的、必要性、利用者が通常想定できるかを確認する必要があります。
次の比較表は、適用除外として検討される代表的な目的と注意点を整理したものです。読者にとって重要なのは、サービス提供に真に必要な情報か、それを超えて広告・解析・プロファイリング目的が混在していないかを読み取る点です。
| 目的 | 例 | 留意点 |
|---|---|---|
| ページ・アプリの適正表示 | 画像・動画・CSS・JavaScript等の表示に必要な通信 | 広告・解析目的が混在する場合は別途検討します。 |
| フォーム入力の保持 | 入力途中の内容を再表示するための情報 | 必要範囲を超える利用は除外されない可能性があります。 |
| ログイン状態の維持 | セッションID、認証状態保持 | 第三者広告利用等に転用される場合は別に検討します。 |
| 不正検知・セキュリティ | 不正ログイン検知、Bot対策、攻撃検知ログ | 目的と必要性を説明できるようにします。 |
| 負荷分散・運用 | ロードバランシング、CDN、障害対応ログ | CDNや外部ベンダー利用時は送信内容を確認します。 |
First Party Cookieは、対象事業者が自ら利用者に付与し、自社サーバに送信される識別符号として扱われることがあります。しかし、First Party Cookieであれば常に対象外というわけではありません。第三者への送信、広告・解析・プロファイリング目的での利用、ID以外の情報送信がある場合は、原則どおり通知等が必要になり得ます。
次の一覧は、同意取得とオプトアウト措置を採る場合の実務上の注意点をまとめたものです。なぜ重要かというと、同意や停止手段を置くだけで詳細表示が不要になるとは限らないためで、読み取るべき点は利用者が何に同意し、何を止められるのかを確認できることです。
自社Cookieでも、広告・解析・プロファイリングへの転用があれば通知等の要否を検討します。
対象となる情報、送信先、利用目的を確認できる状態で、あらかじめチェックされた選択欄などは避ける設計が望ましいです。
送信を止めるのか、送信先での利用を止めるのか、受付方法や利用制限の有無を整理します。
オプトアウト措置では、停止対象、受付方法、利用制限が生じる場合の内容、送信情報、取扱者名、利用目的等を利用者が容易に知り得る状態に置く必要があります。単に「ブラウザのCookie設定で拒否できます」と書くだけでは足りない場合があるため、ツールごとの停止可否、ベンダー側の設定ページ、CMP設定、アプリ内設定等を整理します。
外部送信規律は個人情報保護法とは異なる観点の制度であり、両方を二層で整理します。
外部送信規律は、個人情報保護法とは異なる観点から、利用者の端末からの情報送信について確認機会を与える制度です。送信される情報が個人情報に該当する場合には、個人情報保護法上の利用目的の特定・通知又は公表、第三者提供、委託、外国第三者提供、安全管理措置、個人関連情報の第三者提供等も併せて検討します。
次の比較表は、電気通信事業法と個人情報保護法の確認事項を分けたものです。読者にとって重要なのは、個人情報に該当しない情報でも外部送信規律上の利用者に関する情報として表示対象になり得る点を読み取ることです。
| 観点 | 主な確認事項 |
|---|---|
| 電気通信事業法・外部送信規律 | 対象役務か、情報送信指令通信があるか、通知・公表事項を満たすかを確認します。 |
| 個人情報保護法 | 個人情報・個人データ・個人関連情報に該当するか、第三者提供・委託・共同利用・外国提供等の整理が必要かを確認します。 |
プライバシーポリシーは、個人情報の取得、利用目的、第三者提供、委託、安全管理、開示請求窓口等を説明する文書です。外部送信ポリシーは、利用者の端末から送信される情報、取扱者、利用目的を、タグ・SDK等の単位で説明する文書です。両者を一体化することは可能ですが、外部送信規律の表示事項が埋もれないよう、見出しや導線で明確に分ける必要があります。
海外法対応との関係では、日本法上の外部送信表示、GDPR/ePrivacy型の同意、米国州法のオプトアウト表示を混同しない設計が必要です。日本法対応として通知・公表で足りる場合でも、EU・英国、カリフォルニア、その他海外のプライバシー法制が適用されるサービスでは、Cookie同意、Do Not Sell/Share、GPC、広告オプトアウト、越境移転、データ処理契約等を別途検討します。
法務だけでも開発だけでも完結しないため、棚卸し、技術調査、法的評価、表示、導線、運用まで分けて進めます。
最初に行うべきは、Webサイト、アプリ、サブドメイン、LP、キャンペーンページ、オウンドメディア、会員サイト、管理画面、アプリ内WebView等の棚卸しです。サービス名、URL、アプリ名、運営部署、利用者層、投稿・DM・検索・情報配信・マーケットプレイス等の機能、利用しているタグやSDK、送信情報、送信先、表示済みポリシーを収集します。
次の時系列は、企業法務で外部送信規律対応を進める標準的な段階を示しています。読者にとって重要なのは、技術調査と法的評価を分離しつつ、最後に運用・監査へつなげる順番を読み取ることです。
サイト、アプリ、サブドメイン、LP、管理画面、外部埋込み、タグ、SDK、ベンダー、既存ポリシーを一覧化します。
タグマネージャー、ブラウザ開発者ツール、Cookieスキャン、SDK一覧、通信ログ、広告代理店・制作会社へのヒアリングで送信実態を確認します。
対象役務、情報送信指令通信、適用除外、通知・公表、同意、オプトアウト、個人情報保護法や海外法対応を評価します。
対象サービス、ツール・タグ・SDK一覧、送信情報、取扱者名、利用目的、停止方法、問い合わせ先、改定履歴を整えます。
フッター、ヘッダー、Cookieバナー、設定画面、アプリ内ヘルプなどから容易に到達できるようにします。
タグ追加、SDK更新、ベンダー変更、表示更新記録、定期スキャン、内部監査を継続します。
次の比較表は、初回整備後に必要となる統制項目を整理したものです。なぜ重要かというと、広告タグやSDKは頻繁に変わるためで、読み取るべき点は、導入前承認、権限管理、定期確認、証跡化を組み合わせることです。
| 統制項目 | 内容 |
|---|---|
| 新規タグ導入申請 | マーケティング・開発が新規タグを入れる前に、法務・プライバシー確認を行います。 |
| SDK導入レビュー | アプリSDK追加時に、送信情報、送信先、利用目的、オプトアウト可否を確認します。 |
| タグマネージャー権限管理 | 誰がタグを追加・変更できるかを限定し、承認手順を設けます。 |
| 定期スキャン | 四半期又は半期ごとにCookie・タグ・通信先をスキャンします。 |
| 契約更新レビュー | ベンダーのデータ利用目的・サブプロセッサ・海外移転変更を確認します。 |
| 表示更新記録 | ポリシー更新日、変更内容、承認者、画面キャプチャを保存します。 |
| 内部監査 | 表示内容と実際の送信実態の一致を監査します。 |
利用者に分かりやすく、法務レビューや監査にも耐える粒度で、ツールごとの情報を整理します。
外部送信ポリシーは、利用者にとって読みやすく、かつ監査・法務レビューに耐える文書である必要があります。外部送信の概要、対象サービス、ツール・タグ・SDK一覧、各ツールごとの送信情報、取扱者名、利用目的、オプトアウト又は停止方法、問い合わせ先、改定日・改定履歴を整理します。
次の一覧は、外部送信ポリシーの構成要素を実務順に並べたものです。なぜ重要かというと、利用者向けの説明と社内管理用の情報を分けずに作ると更新漏れが起きやすいためで、読み取るべき点は、表示項目と運用項目を一体で管理することです。
どのサービスで、どのような目的で外部送信が行われるかを冒頭で説明します。
導入利用している外部サービスを正式名称とサービス名で一覧化します。
一覧必須3項目をツールごとに具体的に記載し、自社目的と送信先目的を分けて整理します。
必須オプトアウト可否、設定方法、問い合わせ窓口、改定履歴を利用者が確認できるようにします。
運用次の比較表は、外部送信ポリシーの記載例を簡略化したものです。読者にとって重要なのは、ツール名だけで終わらせず、送信される情報、取扱者、自社側と送信先側の利用目的、停止手段を横並びで確認できる点です。
| ツール等の名称 | 送信される情報 | 情報を取り扱う者 | 利用目的 | 停止方法等 |
|---|---|---|---|---|
| ○○ Analytics | Cookie ID、閲覧ページURL、閲覧日時、端末・ブラウザ情報、IPアドレス等 | ○○ LLC | 自社の利用目的 ― 利用状況の分析、サービス改善。送信先の利用目的 ― サービス提供、利用状況分析、不正防止等 | 提供会社の設定ページ又はブラウザ設定を確認 |
| △△ Ads | Cookie ID、広告ID、閲覧URL、クリック情報、コンバージョン情報等 | △△株式会社 | 自社の利用目的 ― 広告効果測定、広告配信最適化。送信先の利用目的 ― 広告配信、広告効果測定等 | 広告設定ページ又はCMP設定を確認 |
オプトアウト、保存期間、問い合わせ先、送信先国・地域などは、法令上必須ではない場合でも、利用者への適切な確認機会という観点から記載が望ましい場合があります。実際のサービス・送信実態、ベンダー文書、契約、管理画面、通信ログを確認し、自社の利用実態に合わせて記載します。
ニュースメディア、自社EC、オンラインモール、SaaS、スマートフォンアプリでは、確認すべき送信実態が異なります。
対象役務該当性は、サービス名ではなく機能と送信実態で変わります。特に、広告配信、レコメンド、SNS埋込み、チャット、アプリSDK、投稿・レビュー・出品などがある場合は、事業部門と技術部門から情報を集めて確認します。
次の事例別一覧は、代表的なサービスごとの確認ポイントを整理したものです。読者にとって重要なのは、同じ会社の中でもサービスの機能によって対象可能性や表示内容が変わる点を読み取ることです。
不特定利用者にニュース情報を配信するサービスとして対象役務に該当する可能性が高いです。アクセス解析、広告配信、レコメンド、SNS埋込み、動画プレーヤー、コメント欄等を確認します。
自社商品を自社で販売するだけなら対象外寄りですが、レビュー投稿、ユーザー間売買、複数店舗の出品、マーケットプレイス機能、独立した情報メディア等があれば再検討します。
複数の出品者・利用者が投稿し、不特定利用者が閲覧できる場を提供するため対象役務に該当する可能性が高いです。決済、本人確認、レビュー、配送、広告、SDK等も整理します。
閉域的・特定利用者向けの業務ツールでは対象外寄りの場面もありますが、メッセージ、共有、外部公開、コミュニティ、マーケットプレイス等の機能があれば慎重に検討します。
広告SDK、解析SDK、クラッシュ解析SDK、プッシュ通知、地図、決済、SNSログイン、MMP、A/Bテスト、リモート設定等を確認します。
アプリではSDKが外部送信の中心になりやすいため、次の追加項目を確認します。なぜ重要かというと、アプリストア表示、OS側の広告ID・トラッキング設定、SDK更新時の差分管理と外部送信表示がずれると、利用者説明と実態が一致しなくなるためです。
Gradle、CocoaPods、Package依存関係、管理画面のSDK一覧を確認します。
広告ID、端末情報、アプリ利用イベント、位置情報、クラッシュログを確認します。
初回起動画面、設定画面、ヘルプ画面から外部送信表示へ到達できるかを確認します。
未成年者・子ども向けアプリでは、利用者層に応じた追加配慮を検討します。
外部送信表示の正確性は、ベンダー情報の取得、代理店管理、台帳、監査証跡で支えます。
外部送信表示を正確に行うためには、ベンダーがどの情報を、どの目的で、どの国・地域で、どのサブプロセッサとともに取り扱うかを把握する必要があります。広告・解析・SDKベンダーとの契約又は利用規約に、情報取得に必要な条項・資料があるかを確認します。
次の一覧は、ベンダー契約や利用規約で確認すべき事項を整理したものです。読者にとって重要なのは、表示項目を作るための情報提供義務と、仕様変更時の通知・協力義務を契約上も確保する点です。
送信される情報の項目、ベンダーの正式名称、サービス名を確認します。
表示事項ベンダーの利用目的、第三者提供、共同利用、委託、サブプロセッサの有無を確認します。
利用目的データ保存地域、外国での取扱い、保存期間、DPA、セキュリティ措置を確認します。
越境仕様変更時の通知、削除・停止方法、法令遵守協力義務を確認します。
運用広告代理店、制作会社、解析会社が管理するタグも見落とされやすい領域です。代理店が追加した広告タグ、リターゲティングタグ、コンバージョンタグ、ヒートマップ、セッションリプレイ等について、タグ追加前承認、送信情報・送信先・利用目的の提供、法令対応協力、不要タグ削除、権限返還、定期棚卸しを契約や運用で定めます。
M&Aや事業譲受では、対象会社・対象事業のWebサイトやアプリにどの外部送信があるかをデューデリジェンスで確認します。広告タグ、アプリSDK、DMP、過去のキャンペーンLP、サブドメイン、古いアプリ、外部制作会社管理のタグマネージャーは見落とされがちです。PMIでは、グループ共通プライバシーポリシーへの統合、タグ統廃合、ベンダー契約の整理、外部送信表示の改定、CMP導入方針、海外法対応の統一を行います。
次の比較表は、外部送信台帳に含めるべき項目を整理したものです。なぜ重要かというと、表示内容と実際の通信先の一致を監査するためには、サービス、タグ、送信情報、適用除外判断、証跡を一つの台帳で追える必要があるためです。
| 項目 | 内容 |
|---|---|
| サービス名・URL・アプリ名 | 対象サービスの範囲を明確化します。 |
| 管理部署・責任者 | 法務、開発、マーケティング、プロダクト等の責任者を記録します。 |
| タグ・SDK名 | 正式名称、サービス名、バージョンを記録します。 |
| 導入目的 | 解析、広告、改善、セキュリティ等の目的を記録します。 |
| 送信情報 | Cookie ID、広告ID、閲覧URL等の項目を記録します。 |
| 送信先・取扱者 | 法人名、サービス名、国・地域を記録します。 |
| 送信先利用目的 | ベンダーポリシー・契約から確認した目的を記録します。 |
| 適用除外判断 | 真に必要な情報等に該当するかを記録します。 |
| 表示文言 | 外部送信ポリシー上の記載を記録します。 |
| オプトアウト | 有無、方法、利用制限、設定画面を記録します。 |
| 最終確認日 | スキャン日、レビュー日を記録します。 |
| 証跡 | スクリーンショット、通信ログ、承認履歴を保存します。 |
内部監査では、外部送信台帳と実際の通信先が一致しているか、未承認タグがないか、未掲載SDKがないか、廃止ツールのタグが残っていないか、LPやキャンペーンページにも導線があるか、アプリの最新バージョンでSDK一覧が更新されているかを点検します。
次のリスク一覧は、監査で優先して確認すべき兆候をまとめたものです。読者にとって重要なのは、表示文言だけでなく、問い合わせ、苦情、炎上、不正タグ混入、委託先ミス、M&A確認の場面で説明できる証跡を残す点です。
タグマネージャーに、法務・プライバシー確認を経ていないタグが残っている状態です。
外部送信ポリシーに掲載されていないSDKや、廃止済みツールのタグが見つかる状態です。
LP、キャンペーンページ、アプリ内画面から外部送信表示へ到達できない状態です。
法務レビュー記録、ベンダー回答、通信ログ、画面キャプチャ、改定履歴が保存されていない状態です。
一般的な制度理解として、Cookie、個人情報、自社サーバ、同意バナー、代理店管理に関する誤解を整理します。
ここでは、外部送信規律の実務でよく出る誤解を一般情報として整理します。具体的な適用要否は、サービスの性質、送信情報、送信先、目的、契約、利用者層、海外展開の有無等により変わる可能性があります。
一般的には、その理解だけでは足りない可能性があります。外部送信規律はCookieだけを対象とする制度ではなく、広告ID、端末情報、閲覧URL、アプリイベント、SDK通信等も検討対象になり得ます。具体的には、実際の送信実態を確認したうえで専門家へ相談する必要があります。
一般的には、外部送信規律の対象となる利用者に関する情報は、個人情報保護法上の個人情報に限られないとされています。ただし、送信情報の性質や利用目的によって個人情報保護法上の論点も生じ得ます。具体的な整理は、資料を確認したうえで専門家へ相談する必要があります。
一般的には、自社サーバへの送信だけで直ちに表示不要と整理できるとは限りません。利用者以外の者の設備には自社サーバも含まれ得ます。ただし、サービス提供に真に必要な情報等として適用除外となる可能性があります。結論は送信情報、目的、必要性によって変わります。
一般的には、日本語で平易に、利用者が容易に確認できる表示が必要とされています。外国語文書へのリンクだけでは、確認機会として不足する可能性があります。リンクを置く場合でも、送信情報、取扱者名、利用目的を利用者が理解できる形で示す必要があります。
一般的には、初回整備だけで十分とはいえない可能性があります。タグ、SDK、広告、SaaS、ベンダー仕様は変わり得るため、継続的な棚卸し、承認手順、定期監査、表示更新記録が必要になります。運用体制の設計はサービスの規模や変更頻度に応じて検討します。
一般的には、同意バナーの内容次第です。同意の対象となる情報、送信先、利用目的を利用者が容易に確認できなければ、適切な確認機会を付与したとはいえない可能性があります。具体的な画面設計は、同意取得の方法と表示内容を合わせて確認する必要があります。
一般的には、自社サービス上でタグ等により情報送信指令通信が行われる場合、自社側の法令対応も問題になり得ます。代理店・制作会社の管理下にあるタグも台帳化し、契約上の協力義務や削除・変更時の手順を確保することが望ましいです。
対象サービスの見極め、送信実態の把握、具体的な表示、継続運用を一体で設計します。
外部送信規律は、Cookieだけの規制ではありません。タグ、SDK、ピクセル、広告ID、端末情報、閲覧URL、アプリ利用履歴等を含む、利用者端末からの情報送信全体を把握する必要があります。
次の重要ポイントは、企業法務として最後に確認すべき整理をまとめたものです。読者にとって重要なのは、法令上最低限の表示を置くだけでなく、利用者に分かりやすく、社内にとって運用可能で、監査に耐える仕組みに落とし込む点です。
外部送信規律対応は、表示文言の作成だけでなく、棚卸し、技術調査、法的評価、画面導線、ベンダー管理、内部監査をつなげる継続的な仕組みです。