Cookie同意バナーは必須？外部送信規律の対象・通知・オプトアウトを整理

画面には何も出ていないのに、記事を開いただけで端末から解析会社、広告会社、動画配信基盤へ通信が走る。外部送信規律が扱うのは、ブラウザにCookieが保存されたかだけではなく、利用者の端末から第三者へどんな情報を送らせるプログラムを提供したかです。

結論からいえば、日本の外部送信規律は、あらゆるWebサイトへ同じCookie同意バナーを必須にする制度ではありません。電気通信事業を営む者が対象となる電気通信役務を提供しているか、外部送信を指示するプログラムがあるか、送る情報が例外に当たるかを確認し、対象なら通知・公表、同意取得、オプトアウト措置などの方法を選びます。

「Cookieを使っています」とだけ表示しても送信の全体像は説明できません。誰の端末から、何を、誰へ、何のために送るかをタグ・SDK単位で示すのが出発点です。

本記事は2026年9月8日に、総務省の外部送信規律ページ・FAQ・パンフレット、電気通信事業法・施行規則、個人情報保護委員会の電気通信分野ガイドラインと解説を確認しました。サービス形態、通信の秘密、個人情報、広告同意は別の規律も関わるため、自社実装と利用者層を示して判断してください。

Cookieという名前から離れて実通信を見る

Cookie以外のタグ・SDK通信まで測定します。

外部送信はCookieだけで起きません。URL、閲覧ページ、端末識別子、広告ID、IPアドレス、ブラウザ、OS、画面サイズ、操作時刻、クリック、検索語、位置情報などが、JavaScript、画像タグ、埋め込み動画、チャット、SNSボタン、アプリSDKから送られます。

逆にCookieがあっても、外部送信規律上の通知・公表が常に必要とは限りません。サービス提供に真に必要な情報、入力情報の保持、認証、セキュリティ、ネットワーク管理に必要な情報や、サービス提供者が利用者へ送信した一定の識別符号など、制度上の例外を一送信ずつ確認します。

プライバシーポリシーの文章を起点にすると、実装済みタグの書き漏れを見つけられません。トップ、記事、検索、会員登録、購入、問い合わせ、エラー画面を操作し、同意前、拒否後、ログイン前後で通信ログを採取します。

台帳の正解は契約中のツール一覧ではなく、利用者の端末が実際に接続した送信先と、送った項目を再現できる通信記録です。

自社サイトだから対象外とは限らず対象とも限らない

サイト名ではなく提供する役務を分けます。

総務省の制度ページは、メッセージ媒介、SNS、検索、ニュースサイトなど各種情報のオンライン提供を主な対象例に挙げています。一方、自社商品等のオンライン販売や企業ホームページ、個人ブログは、示された例では電気通信事業に該当しないため対象外と説明されています。

しかし、会社案内ページの一部に、利用者同士の投稿、検索、第三者情報の継続的な提供など別の役務があれば、サイト全体を「企業ホームページ」の一語で片付けられません。機能、提供相手、他人の通信を媒介するか、登録・届出の要否を役務単位で見ます。

オンライン販売サイトが外部送信規律の対象外でも、個人情報保護法、通信の秘密、不正アクセス対策、広告プラットフォームの条件、海外利用者向けの法令が消えるわけではありません。「この法律の対象外」と「同意も説明も不要」を同義にしません。

送信情報・送信先・利用目的を三点セットにする

一つの通信が何を誰へ送るかを示します。

通知または公表では、送信される利用者に関する情報の内容、その情報を取り扱う者の氏名または名称、利用目的を示します。「アクセス情報を外部事業者へ送信します」では粒度が粗く、利用者が何をされるか判断できません。

送信先が解析会社でも、自社だけが統計を見る場合、送信先企業が自社サービス改善へ利用する場合、複数サイトを横断して広告へ使う場合では意味が違います。契約書、管理画面、技術仕様、データ処理条件を照合し、自社の利用目的と送信先側の利用目的を分けます。

動的な広告オークションやCDNでは、通信先が増える場合があります。代表会社名だけを一行にせず、送信経路、再委託、地域、目的を説明できる範囲へ分解します。ドメインの所有者が不明なら、タグ提供会社へ確認するまで本番発火を止めます。

外部送信表示は送信先企業の説明を丸写しせず、自社ページから送る情報と、自社がそのタグを置く目的を対応させます。

通知・公表・同意・オプトアウトを目的別に選ぶ

一律バナーではなく送信ごとの方法を決めます。

対象情報について、制度は通知または利用者が容易に知り得る状態に置く方法を基本に示しています。通知はポップアップなどで事項またはリンクを表示し、公表は外部送信が起きるページか、そこから容易に到達できるページなどへ掲載します。

日本語、平易な表現、専門用語を避けること、拡大・縮小せず適切な文字サイズで確認できることも示されています。フッターの薄い文字から何階層も進む、スマホで表が切れる、検索できないPDFだけを置く設計は、容易に知り得るかを実機で確かめます。

利用者の同意を取得する方法もありますが、あらかじめチェックを入れた状態など、能動的な同意とはいえない方法を使いません。オプトアウトを採る場合は、送信と利用のどちらが止まるか、申込方法、機能制限、送信情報、取扱者、利用目的を容易に知り得る状態へ置きます。

同意バナーを付けるかではなく、目的ごとに「同意前は送らない」「表示して送る」「拒否で送信を止める」のどれを実装したかを検証します。

必要情報の例外を広告タグへ広げない

利用者への役務に真に必要かを試します。

画面表示に必要なOS・ブラウザ情報、入力内容の保持、ログイン認証、セキュリティ対策など、役務提供のため真に必要な情報は例外となり得ます。ただし、サイト運営者に売上上の利益があることと、利用者へ役務を提供するために真に必要であることは別です。

行動広告、他サービス横断計測、広告の効果帰属を「サイト運営に必要」と一括分類すると、例外を広げ過ぎます。タグを止めたときに記事閲覧、購入、認証、セキュリティが成立するかをテストし、必須と任意を区分します。

First Party Cookieという呼び方も免罪符ではありません。誰が識別符号を送り、どこへ返送されるか、第三者タグが読み取るか、別目的に利用するかを実装で確かめます。ブラウザ上のCookie分類名だけで法的判断を終えません。

タグマネージャーは公開後に台帳を変える

タグ公開も正式なリリースとして審査します。

タグマネージャーはアプリ本体を再公開せず外部送信先を追加できます。マーケティング担当者が新しい計測タグを公開すると、法務が確認した表示と実通信が同日にずれるため、タグ公開を正式なリリースとして扱います。

新規タグの申請には、所有者、提供会社、目的、送信項目、送信先、発火ページ、同意区分、保存期間、停止手順、表示文案を必須にします。公開者と承認者を分け、緊急停止できる担当者を置きます。

定期監査では、台帳にあるが通信しないタグ、通信しているが台帳にないタグ、同意拒否後も発火するタグを洗い出します。データクリーンルーム比較のような広告計測基盤を使う場合も、匿名化という製品説明だけで送信項目の確認を省きません。

外部送信表示の改定日は文書を直した日ではなく、実装、表示、拒否制御、台帳の四つが同じ版になった日です。

情報項目は「識別子」より細かく書く

実際に送る値と目的を通信ログへ結びます。

台帳に「Cookie」「端末情報」「閲覧情報」とだけ書くと、実通信との差分を判定できません。Cookie名、広告ID、IPアドレス、閲覧URL、参照元、イベント名、購入金額、会員ID、ハッシュ化メールアドレスなど、実際に送る単位へ分解し、送信先ドメインと事業者名へ結びます。

利用目的も「サービス改善」だけで終えません。不具合解析、アクセス分析、広告配信、広告効果測定、不正防止、決済、動画再生のどれかを区別します。一つのSDKが複数目的を持つ場合は、目的ごとに送信項目と停止可否を分け、説明文と同意設定が同じ粒度になっているかを見ます。

公開文とタグ台帳は、送信先、情報項目、利用目的を同じ単位で照合できて初めて差分監査ができます。

アプリSDKは画面遷移と初回起動を分けて測る

同意前と拒否後の通信を端末別に確認します。

アプリは初回起動時に、クラッシュ解析、プッシュ通知、広告、位置、ソーシャルログインなど複数SDKが同時に通信することがあります。設定画面へ到達する前に送信すれば、後から拒否しても初回データは既に出ています。

新規インストール、アップデート、ログアウト、権限拒否、圏外からの復帰を試し、いつSDKが初期化されるかを測ります。iOSとAndroid、OS版、無料・有料プランで挙動を分けます。SDK名が同じでも版更新で送信項目や送信先が変わるため、依存関係の更新を台帳改定の起点にします。

通知・公表は、アプリの最初の画面や、そこから容易に到達できる画面などで確認できるようにします。ストア説明だけ、Webサイトだけ、利用規約の深い節だけに置かず、実際の利用者がアプリ内で再確認できる導線を用意します。

海外法令と個人情報を別レイヤーで重ねる

外部送信表示だけで他法令を満たしたことにしません。

外部送信規律の対象・例外を判定しても、送信情報が個人情報、個人関連情報、通信の秘密に関わる場合は、別の要件を確認します。外部送信規律の表示があることだけで、取得、第三者提供、越境移転、安全管理の条件を満たすわけではありません。

海外居住者へサービスを提供する場合、地域別同意や拒否が必要になることもあります。全世界へ一つのバナーを表示するか、IP判定で隠すかを先に決めず、対象者、データ、目的、受領者、法的根拠を地域ごとに整理します。

子ども向け、位置情報、医療・金融に近い情報では、説明の理解可能性と被害を厳しく見ます。プロファイリングで表示内容や価格を変える場合は、その影響も利用者へ説明できるようにします。

同意管理画面を置いても先に送れば失敗する

同意前・拒否後・撤回後の実通信を止めます。

同意ボタンが表示されても、その背後で広告タグや解析SDKが先に通信していれば、画面と実装が一致しません。初回訪問、拒否、選択同意、撤回、再訪、保存期限切れを別シナリオにし、操作前後の通信先と送信値を採取します。

同意管理プラットフォームの分類名と実際のタグ用途がずれる例もあります。広告効果測定タグを「必須」に入れたり、用途不明のカスタムHTMLが同意状態を参照しなかったりすると、設定画面だけでは発見できません。タグマネージャー、HTML直書き、CDN挿入、アプリSDKを一つの通信一覧へまとめます。

撤回後は新規送信が止まるかだけでなく、保存済み識別子が再生成されないか、ページ遷移で設定が戻らないかを見ます。リリース判定には、同意前通信0、拒否後の対象通信0、説明外ドメイン0という機械的な停止条件を置きます。

同意状態を保存する期間も試験条件です。保存期限を過ぎた再訪、ブラウザのストレージ削除、別端末、ログイン前後で選択がどう引き継がれるかを確認し、利用者が撤回できる入口を初回画面と同じ分かりやすさで残します。

リリースゲートは通信差分で止める

未知送信先と拒否後送信を公開前に止めます。

本番前に、基準版の送信先・項目・発火回数と新しい版を比較します。未知ドメイン、同意前の任意タグ、拒否後の送信、表示にない目的、不要になったタグが一つでもあれば公開を止めます。

リテールメディア導入では購買データを使う広告の責任分界を扱います。外部送信の台帳は広告商品名ではなく実通信でつなぎ、事故時は個人データ漏えいの報告・本人通知と照らして、送った情報が個人情報に当たるか、報告や通知が必要かを別に判定します。

ページ追加だけでも埋め込み地図、動画、フォームが新しい送信を生みます。CMS編集者が貼り付ける外部コンテンツも検査対象にし、許可済みプロバイダーと用途を限定します。障害時には、タグを止めても主要機能が動く設計にします。

KPIは同意率だけでなく、未登録送信先、同意前送信、拒否後送信、表示到達性、台帳更新遅延、SDK版差分、停止時間を置きます。利用者の選択を売上指標だけで評価すると、拒否導線を見えにくくする誤った改善へ向かいます。

公開可否はプライバシーポリシーのレビュー完了ではなく、実通信と表示が一致し、拒否操作が約束どおり送信を止めることを自動検査して決めます。

参考情報

外部送信規律の対象・方法・例外を支える公式資料です。

以下は2026年9月8日に内容と到達性を確認する一次情報です。

• 外部送信規律（総務省）
• 外部送信規律FAQ（総務省）
• 外部送信規律のパンフレット（総務省）
• 電気通信事業法（e-Gov法令検索）
• 電気通信事業法施行規則（e-Gov法令検索）
• 特定分野ガイドライン一覧（個人情報保護委員会）
• 電気通信事業における個人情報等の保護に関するガイドライン（個人情報保護委員会）
• 同ガイドラインの解説（個人情報保護委員会）