• ノウハウ
  • |Remogu(リモグ)" />

    外部送信規律の遵守は同意バナーだけで済む?義務の4つの形と実装で先にやることの実態

    監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

    「最低限は通知か公表にある」を示す図です。通知/公表/同意取得/オプトアウト手段を並べています。強調しているのは公表です。最低限の線と添えています。

    📘 この記事でわかること

    • 送信していること自体が対象になるかどうかを決めることと、義務は4つの形のうち通知又は公表が最低限とされていること
    • 対象になる仕組みは計測用のHTMLタグやアプリ内の情報収集モジュールという具体的な単位で示されていること
    • 法令遵守事項と一歩進んだ取組は異なるレイヤーにあることと、守る線とやるとよい線を分けて考える整理の仕方

    外部送信規律という言葉を聞くと、まず同意バナーの実装を思い浮かべます。総務省の報告書案を確認すると、義務の入り口は同意の有無より手前にあり、送信していること自体が対象を分ける線になっています1。フロントエンドで計測タグや情報収集モジュールを扱ってきた経験は、この線引きを言葉にする場面で生きてきます。この記事では、対象の範囲、義務の形、実装の順番を、報告書案の記述に沿って整理します。

    リモートワーク案件特化のエージェント|Remogu(株式会社LASSIC運営) フロントエンドやプライバシー配慮の実装に関わるリモート案件を、条件から探す フルリモートの案件を見る

    1. 何が対象になるのか

    対象を分けるのは同意の有無ではなく送信の事実

    外部送信規律は電気通信事業法第27条の12で定められています1。計測タグを実装してきた立場からすると、規律と聞いてまず気になるのは、同意バナーを置くかどうかという実装上の要否かもしれません。ただ報告書案の記述を辿ると、義務が発生する起点は同意バナーの有無ではなく、もう少し手前の段階に置かれています。最初に確認するのは、送信という行為そのものが起きているかどうかです。この順番を取り違えると、必要のない実装に時間を使うことにもなりかねません。

    規律の対象になるのは、利用者の端末に保存された情報を、広告配信や利用者の行動分析、利便性向上等の目的で外部へ送信している事業者です2。目的が明記されているため、同じHTMLタグや情報収集の仕組みを使っていても、送信の目的が異なれば対象の外に置かれる場合があります。逆に言えば、目的を確認しないまま、自社の実装は対象外だと決めつけることはできません。まず目的を言葉にすることが、最初の一歩になります。

    つまり判断の起点は、送信しているかどうかであり、同意を取っているかどうかではありません。実装を棚卸しするときは、まず送信の有無から数え始めると、後段で必要になる通知や公表の検討がぐっと進めやすくなります。同意の要否は、その先に出てくる論点だと捉えておくと、確認する順番を見誤りにくくなります。

    令和4年の改正で導入された規律という背景

    この規律は、令和4年の電気通信事業法の改正によって導入されたものです4。改正から一定の時間が経ち、実装がすでに本番環境で稼働している案件ほど、後からまとめて棚卸しをする負担は大きくなりがちです。早い段階で全体像を把握しておくほうが、後々の見直しは軽く済みます。

    フロントエンドの実装を担当してきた経験は、送信の目的や送信先を整理する場面でそのまま役立ちます。タグ管理ツールに並ぶ設定を一つずつ読み解き、何がどこへ送られているかを言葉にできる立場は、規律への対応が進むほど重宝されやすくなります。これまで積み上げてきた実装の経験が、そのまま実務の言葉に変わる場面です。

    次章では、対象になった場合に課される義務の中身を整理します。義務はひとつではなく4つの形で示されており、どれを選ぶかによって実装の負担も変わってきます。まず全体の形を押さえておくことが、実装の順番を決める助けになります。

    図1:規律の対象になるかどうかを分けるのは、送信していること自体
    規律の対象になるかどうかを分ける線 目的に沿った外部送信を していない 広告配信・行動分析等の目的ではない 広告配信や行動分析等の 目的で外部送信している 送信していること自体が要件 規律の対象外 規律の対象になる

    出典:総務省 利用者情報ワーキンググループ第2次報告書(2026年8月)をもとに作成

    2. 義務は4つの形で示されている

    通知・公表・同意取得・オプトアウトという4つの選択

    規律の対象になった場合に課される義務は、ひとつではありません。総務省の報告書案では、通知、公表、同意取得、オプトアウト手段の提供という4つの対応が挙げられており、このいずれかの対応を行うことが義務付けられています3。4つのどれを選ぶかは事業者に委ねられており、一律にすべてを揃える必要はありません。

    4つのうち、どれを選ぶかは実装のコストや事業の形によって変わります。同意取得やオプトアウト手段の提供は、利用者との個別のやり取りを伴う分、実装の負担も相応に大きくなります。通知や公表は、外部への送信の目的や送信先を文章で示す対応であり、比べると着手のハードルは低めです。どちらを選ぶにしても、書く内容の正確さが問われる点は変わりません。

    どの形を選ぶにしても、送信の実態を正しく把握していることが前提になります。実態の把握が曖昧なままでは、通知の文章にも公表の文章にも、正確な記載を落とし込めません。表1に、4つの対応を整理しました。

    4つの対応を表で整理する

    4つの対応は、それぞれ利用者に情報が届く経路が異なります。表1では、通知、公表、同意取得、オプトアウト手段の提供について、対応の内容と位置づけを整理しました。実装を検討するときは、まずこの4つがどう並んでいるかを確認すると進めやすくなります。

    通知や公表は、外部送信の目的や送信先を文章として示す対応です。同意取得は利用者からの意思表示を伴い、オプトアウト手段の提供は拒否の手段を用意する対応です。4つとも利用者に伝えるという点は共通していますが、伝え方の重さが異なります。

    位置づけの違いを踏まえたうえで、次章では最低限求められる線がどこにあるのかを確認します。同意バナーを置くかどうかで悩む前に、この位置づけを知っておくと判断が整理しやすくなります。

    図2:義務は4つの形で示されている
    義務の4つの形 通知 公表 同意取得 オプトアウト 手段の提供 通知又は公表が最低限求められる いずれかの対応を義務付け

    出典:総務省 利用者情報ワーキンググループ第2次報告書(2026年8月)をもとに作成

    義務の形対応の内容位置づけ
    通知利用者へ個別に知らせる対応4つの対応のひとつ
    公表送信の目的や送信先等を外部に開示する対応通知とあわせて最低限とされる対応
    同意取得利用者から同意を得る対応選択肢のひとつ
    オプトアウト手段の提供拒否の手段を用意する対応選択肢のひとつ

    3. 最低限の線は通知又は公表にある

    同意バナーは選択肢のひとつという位置づけ

    同意バナーの実装は、4つの対応のうち同意取得にあたります。ただし報告書案が示す最低限の線は、同意取得ではなく通知又は公表に引かれています3。同意バナーを設置していない実装が、それだけで規律に沿っていないと判断されるわけではありません。

    通知や公表だけで対応を終えるという選択肢よりも、同意バナーを設置して同意取得まで進める選択肢のほうが手厚く見えるかもしれません。ただ手厚さと最低限の基準は別の話です。求められているのはいずれかの対応であって、すべての対応ではありません。

    この整理は、実装の優先順位を考えるうえで役立ちます。何を最初に満たす線として扱い、何を上乗せの選択肢として扱うかが見えてきます。図3で、最低限のラインと同意バナーの位置づけを確認します。

    図3:最低限のラインと、同意バナーの位置づけ
    最低限のラインと同意バナーの位置づけ 通知又は公表=最低限のライン 同意バナーは選択肢のひとつ

    出典:総務省 利用者情報ワーキンググループ第2次報告書(2026年8月)をもとに作成

    最低限を満たす対応から検討する

    実装を新しく検討する場面では、まず通知又は公表で最低限を満たせるかどうかを確認する進め方があります。既存のプライバシーポリシーやヘルプページに、外部送信の目的と送信先を書き足す対応は、比較的着手しやすい部類に入ります。文章を整える作業から始めれば、実装そのものを大きく変えずに対応を進められます。

    そのうえで、事業の形や利用者との関係によっては、同意取得やオプトアウト手段の提供まで進める判断もあります。どこまで対応するかは、最低限の線を把握したうえで、実装の負担と照らして決める話になります。判断の材料が揃っていれば、社内での合意も取りやすくなります。

    次章では、この判断の前提になる棚卸しの進め方を確認します。何がどこへ送られているかが分からなければ、通知にも公表にも正確な内容を書けません。実装の現場では、この棚卸しこそが最初の関門になります。

    4. 実装は棚卸しから始まる

    対象になる仕組みはタグとモジュール

    対象になる仕組みは、抽象的な言い方ではなく具体的な単位で示されています。報告書案では、ウェブページに設置され利用者の行動や広告成果等を計測するために埋め込むHTMLタグと、アプリ内に設置される情報収集モジュールが挙げられています5

    フロントエンドの実装を担当してきた立場であれば、タグ管理ツールに並ぶ設定や、アプリのSDKの一覧をすぐに思い浮かべられるはずです。棚卸しの対象は、この単位で一つずつ数えていくことになります。抜け漏れがあると、通知や公表の記載も実態からずれてしまいます。

    表2に、棚卸しの対象と確認する項目を整理しました。何を、何のために、どこへ送っているかを一覧にできれば、通知や公表の文章を書く土台ができます。逆にこの一覧が無いまま文章を先に書いてしまうと、後から内容を直す手間が増えていきます。

    対象の種類具体例確認すること
    計測用のHTMLタグウェブページに埋め込み、利用者の行動や広告成果等を計測する仕組み送信先と送信目的
    情報収集モジュールアプリ内に設置され、情報を収集して送信する仕組みどのモジュールが何を集めているか
    棚卸しの進め方既存の実装を一覧化し、送信の有無から並べ直す作業通知や公表の文章に落とし込む前段の整理

    棚卸しは通知・公表の前段の作業

    棚卸しを終えないまま通知や公表の文章を書き始めると、記載が実態と合わなくなる場面が出てきます。既存の実装ほど、過去に追加されたタグが積み重なっており、洗い出しに時間がかかる傾向があります。関わった担当者が入れ替わっていると、洗い出し自体に手間がかかることもあります。

    洗い出しの単位は、ページ単位よりもタグ単位・モジュール単位で進めるほうが、送信先や目的の対応関係を追いやすくなります。ひとつのページに複数のタグが設置されている場合は、それぞれの送信先を分けて確認します。単位を細かく分けておくほど、後から見直すときの確認が早くなります。

    前提として、送信の扱い自体も動いています。棚卸しを終えた実装がそのまま同じ形で動き続けるとは限らず、次章では、ブラウザ側の対応が実装にどう影響するかを確認します。一度整えた一覧も、時間が経てば見直しが必要になります。

    5. 前提が動いている

    ブラウザによって遮断の扱いが異なる

    サードパーティCookieを取り巻く前提は、実装した時点から変わっていく可能性があります。報告書案には、Firefoxではブラウザの機能として即時に遮断されるという記述があります6。実装した時点で問題なく動いていた計測が、その後の環境の変化で動かなくなることも起こり得ます。

    遮断の扱いがブラウザによって異なるということは、同じタグを設置していても、動作の実態は環境によって違って見えるということです。棚卸しの結果を通知や公表に反映するときは、この前提が動く可能性を踏まえておくことになります。一度書いた文章を固定的なものと捉えず、更新を前提に運用する視点が求められます。

    図4に、ブラウザによって遮断の扱いが異なる状況を整理しました。同じタグを設置していても、環境によって動作の結果が変わりうるという前提を、図で確認しておきます。実装した瞬間の挙動がずっと続くと考えないほうが安全です。

    図4:ブラウザによって遮断の扱いが異なる
    ブラウザによる遮断の扱いの違い Firefox ブラウザの機能として 即時に遮断される その他の環境 遮断の扱いが 異なる場合がある

    出典:総務省 利用者情報ワーキンググループ第2次報告書(2026年8月)をもとに作成

    前提の変化を実装の見直しに反映する

    ブラウザ側の対応が変わると、計測できていた情報が計測できなくなる場面が出てきます。実装を見直す機会は、規律への対応を洗い出すタイミングと重なることが多く、棚卸しを一度で終わらせず、定期的に見直す運用のほうが実態に合います。見直しの周期をあらかじめ決めておくと、対応が後手に回りにくくなります。

    送信の扱いが変わるたびに通知や公表の文章を全面的に書き直すよりも、棚卸しの一覧を先に整えておき、変化があった部分だけを更新する進め方のほうが、負担を抑えやすくなります。一覧を台帳のように保っておくことが、見直しの回数を重ねるほど効いてきます。

    この視点は、次章で扱う法令遵守事項と一歩進んだ取組の区別にもつながります。前提が動くからこそ、守る線とやるとよい線を分けて考える意味があります。動く部分と動かない部分を切り分けておくと、見直しのたびに全体を作り直す必要がなくなります。

    6. 守る線とやるとよい線を分ける

    法令遵守事項と一歩進んだ取組という2層

    報告書案が示す手引きは、法令遵守事項に加えて、一歩進んだ取組を示す形で作られています7。法令遵守事項は電気通信事業法に基づく義務そのものであり、一歩進んだ取組はそれを超えたベストプラクティスにあたります。

    法令遵守事項と一歩進んだ取組は、異なるレイヤーにあるとされています8。すべてが推奨のように受け取られないよう留意する必要がある、という趣旨の記述も見られます。手引きを読むときは、どちらのレイヤーの話をしているのかを区別しながら読み進めることになります。

    表3に、2つのレイヤーの内容と位置づけを整理しました。どちらの話をしているのかを区別しておくと、社内での説明もぶれにくくなります。実装の担当者だけでなく、事業側の判断者にも伝わりやすい整理になります。

    レイヤー内容位置づけ
    法令遵守事項電気通信事業法に基づく義務そのもの対応が求められる範囲
    一歩進んだ取組法令を超えたベストプラクティス推奨であり義務ではない
    両者の関係異なるレイヤーにあるとされる整理混同しないことが優先順位を決める

    実装の優先順位に落とし込む

    法令遵守事項ではありません。むしろ一歩進んだ取組のほうに位置づけられる対応まで、法令上の義務と同じ重さで進めようとすると、実装の優先順位がぼやけてしまいます。まず法令遵守事項を満たし、そのうえで一歩進んだ取組をどこまで取り入れるかを、実装の負担と照らして判断する進め方が現実的です。

    この区別は、フロントエンドの実装を担当してきた経験があるほど、社内での説明や優先順位の調整の場面で活きてきます。守る線とやるとよい線を分けて説明できることは、実装を任せる側にとっても分かりやすい判断材料になります。曖昧なまま進めるよりも、区別を言葉にできる分だけ、話が早く進みます。

    次章では、ここまでの内容をよくある質問の形で確認します。実装を進めるうえで迷いやすい点を、あらためて整理します。ここまでの内容を振り返る形で読んでいただくと、実装の順番がより頭に入りやすくなります。

    7. よくある質問

    外部送信規律の対象になるのは、どのような事業者ですか

    対象になるのは、利用者の端末に保存されている情報を、広告配信や利用者の行動分析、利便性向上等のために活用することを目的として外部へ送信している事業者です2。根拠になっているのは電気通信事業法第27条の12です1。この規律は、令和4年の電気通信事業法の改正によって導入されました4。改正の経緯を知っておくと、なぜ今この対応が必要なのかを社内で説明しやすくなります。

    送信の目的が明記されているため、同じ技術を使っていても、目的が異なれば対象の外に置かれる場合があります。まずは自社の実装が、どのような目的で情報を送っているかを確認するところから始めることになります。目的を一つずつ言葉にしていく作業が、結果として一番の近道になります。

    同意バナーを設置すれば規律には対応したことになりますか

    同意バナーの設置は、4つの対応のうち同意取得にあたります。ただし最低限求められているのは通知又は公表であり、同意取得はそれよりも手厚い選択肢のひとつという位置づけです3。設置していれば十分、という単純な話ではありません。

    同意バナーを設置していないこと自体が、規律に沿っていないと判断される理由にはなりません。どの対応を選ぶかは、実装の負担や利用者との関係を踏まえて判断する話になります。通知や公表で最低限を満たしたうえで、必要に応じて手厚い対応を足していく順番が現実的です。

    計測タグの棚卸しは何から始めればよいですか

    対象になる仕組みは、ウェブページに設置される計測用のHTMLタグと、アプリ内に設置される情報収集モジュールという単位で示されています5。まずはこの単位で、現在稼働している実装を一覧にするところから始めます。大きな作業に見えても、単位を分ければ一つずつ着実に進められます。

    一覧化ができれば、何を、何の目的で、どこへ送っているかが整理でき、通知や公表の文章を書く土台になります。棚卸しは一度で終わらせず、実装を追加・変更するたびに見直す運用が実態に合います。一覧を更新履歴とあわせて残しておくと、後から振り返るときにも役立ちます。

    手引きに書かれている内容は、すべて対応が必須ですか

    手引きは法令遵守事項と一歩進んだ取組を分けて示す形で作られています7。両者は異なるレイヤーにあるとされており、一歩進んだ取組はベストプラクティスという位置づけです8。手引きに書かれているからといって、すべてを義務と同じ重さで受け止める必要はありません。

    まず法令遵守事項を満たすことを優先し、そのうえで一歩進んだ取組をどこまで取り入れるかを検討する進め方が現実的です。フロントエンドの実装経験は、この判断を社内で説明する場面でも活きてきます。自分の経験がどの案件で活きるかを確かめたい場合は、Remoguに登録し、案件の傾向を確認しながら参画の条件をクライアントと協議する道もあります。

    リモートワーク案件をお探しの方へ

    Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。

    送信の棚卸しから語れる人は、案件の入口に立てます。まずはどんな条件の案件が並んでいるか見てみてください。

    フルリモートの案件を見る30秒で無料登録

    会員登録無料 / 案件閲覧・相談は無料

    ※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

    出典・参考情報

    *1 総務省「利用者情報ワーキンググループ第2次報告書」規律の根拠(2026年8月)
    *2 総務省「利用者情報ワーキンググループ第2次報告書」対象(2026年8月)
    *3 総務省「利用者情報ワーキンググループ第2次報告書」義務の内容(2026年8月)
    *4 総務省「利用者情報ワーキンググループ第2次報告書」経緯(2026年8月)
    *5 総務省「利用者情報ワーキンググループ第2次報告書」対象の技術(2026年8月)
    *6 総務省「利用者情報ワーキンググループ第2次報告書」前提の変化(2026年8月)
    *7 総務省「利用者情報ワーキンググループ第2次報告書」手引きの構成(2026年8月)
    *8 総務省「利用者情報ワーキンググループ第2次報告書」注意点(2026年8月)