外部送信規律 公表事項 — 公表事項を無料で確認

日本のWeb制作会社が納品した54行の採用サイトHTMLを点検したら、公表もれが6件出た。行番号つきで並べるとこうなる。L18にGoogleタグマネージャーのコンテナ（GTM-MX93VQ7）。中で配信しているタグは一つも公表されていない。L24にMeta ピクセル、L31にLINE Tag、L36にYahoo!広告のタグ。ページ下部の「外部送信について」には、送信先としてGoogle アナリティクスの1行しか書かれていない。L43では公表4項目の④、オプトアウト（送信の停止）の方法が丸ごと抜けている。同じL43に最終更新日もない。

このHTMLは架空の会社の見本だが、形はどこの制作会社の納品物にもある。最初の納品のときは公表ページを真面目に書く。半年後に広告代理店から「LINEのタグを足してください」と言われ、headに1行貼る。公表ページは誰も触らない。ずれはその日から始まる。

日本の外部送信規律は、電気通信事業法27条の12として2023年6月16日に施行された。利用者の端末から外部の事業者へ情報を送信する仕組み（いわゆるタグ）を使うとき、送信されることを利用者に分かるようにしておく、という規定である。求められるのは4項目だ。①送信される情報の内容 ②送信先の名称 ③送信先での利用目的 ④オプトアウト（送信の停止）の方法。この4つを、タグごとに書く。

ここで多くの現場がつまずくのは、EUのCookie同意と混ざるからだ。生成AIに「日本のサイトにGA4を入れるときの法対応は？」と聞くと、たいていGDPR風の同意バナーが返ってくる。学習した文章の量では、同意バナーの話のほうが圧倒的に多いからだ。だが日本の外部送信規律は同意ではなく、通知または公表が原則である。同意バナーを入れただけでは、公表4項目は一つも満たされない。逆に、同意バナーがなくても公表4項目が揃っていれば筋は通る。この食い違いが、納品後の手戻りとして返ってくる。

そこで、HTMLを開いて15 checksで照合する拡張を作った。中身は3種類に分かれている。送信タグ検出が6つ（GA4・Meta ピクセル・LINE Tag・Yahoo!広告・X広告・行動ログ計測のClarityとHotjar）、公表4項目の照合が4つ、運用の穴が5つ（公表への導線なし・同意バナーだけで公表なし・GTMコンテナ名だけの記載・オプトアウト手順なし・最終更新日なし）。合わせて15。

判定には一つだけ作法がある。タグの検出はHTMLソースの全文を見るが、公表されているかどうかの判定は「人が読める本文」だけを見る。scriptのURLに connect.facebook.net と書いてあることを「Meta ピクセルを公表した」と数えてしまうと、全部のページが合格になってしまうからだ。本文を作るときは、scriptブロックとHTMLコメントとタグの属性を落としてから探している。この一手間が、この道具の判定を人の目に近づけている。

GTMコンテナは、この規定といちばん相性が悪い。HTMLに残るのは GTM- で始まるコンテナIDの1行だけで、中で何本のタグが配信されているかはHTMLを読んでも分からない。管理画面を開ける人だけが知っている。だから公表ページに「Googleタグマネージャー」と1行書いて済ませてしまう例が多い。公表すべきなのはコンテナではなく、コンテナが動かしているタグのほうだ。この拡張はコンテナIDを見つけた時点で、個別の公表があるかどうかを別の項目として立てる。

誰がこれを読むのか、という話もしておきたい。利用者が公表ページを熟読することは、正直あまりない。実際に読むのは、取引先の情報セキュリティ担当と、監査のチェックリストを持った人と、同業の制作会社である。彼らは文面の美しさではなく、貼ってあるタグと書いてある送信先が一致しているかを見る。一致していなければ、その一点で「管理されていないサイト」に分類される。技術的にはHTMLを3行直すだけの話が、取引の信用の話になる。

2026年の現場には、もう一つ事情がある。ページのheadを書いているのが人間とは限らない。生成AIに「計測タグを入れて」と頼めば、gtag.jsもfbeventsも一度に貼ってくれる。速いが、公表ページのほうは誰も頼んでいないので更新されない。AIが書いたコードがこの規定を守っているか、という問いに答えられる場所が、リポジトリの中に一つも無い状態になりやすい。行番号を返す点検を、コードのある場所に置いておく理由はそこにある。

使い方は短い。HTMLファイルを開いて、コマンドパレットから「外部送信規律: このファイルを点検」を選ぶ。結果パネルに、行番号・規則ID・直し方が並ぶ。直したらもう一度叩く。0件になったら、そのときの日付を公表ページの最終更新日に書く。この順番でやると、最終更新日が嘘にならない。

同梱の見本で測った数字を書いておく。汚いほうの _fixtures/dirty.html は54行、外部送信タグ4本とGTMコンテナ1つ。結果は6件で、内訳は上に並べたとおりだ。直したほうの _fixtures/clean.html は、送信先の表に4本すべてを書き、オプトアウトの停止URLを各行に入れ、見出しに最終更新日: 2026-09-14 を足してある。こちらは0件になる。どこを直せば0件になるのかが、2つのファイルの差分として残る形にした。

人にやらせた場合の目安も書いておく。1ページあたりタグ4本×公表4項目で16か所、これを目視で突き合わせる。ページ数ぶんの掛け算になり、タグを1本足すたびにやり直しになる。しかも見落とすのは、たいてい「足したタグ」ではなく「公表ページの最終更新日」のほうだ。日付が古いままだと、タグを足した日以降の記載が正しくないことが、誰の目にも分かってしまう。

無料版は、開いているHTML1ファイルの照合がそこで終わる。件数を伏せたり、N回で止めたり、結果に透かしを入れたりはしない。ブラウザ版（index.html）も同じ ext/engine.js を読み込んで動く。説明ページではなく、HTMLを貼れば同じ15 checksが走る実物である。

有料版で増えるのは、判定の強さではなく範囲と持ち出しだ。ワークスペース全体を一括で回し、タグ×公表項目の突き合わせ表をMarkdown/CSVに書き出す。制作会社が納品物として添える、あるいは取引先の監査回答として外に出す。そのときに必要なのは、画面の中の結果ではなくファイルになった表のほうだ。価格は$29。

最後に、この道具が答えられないことも書いておく。公表の文面が法的に十分かどうかは、この拡張は判定しない。判定しているのは、①〜④の4項目がそのページに書かれているか、検出したタグが送信先として名指しされているか、最終更新日があるか、という機械的に確かめられる範囲だけである。文面の妥当性は法律の専門家の仕事で、その手前にある「そもそも書き漏らしている行」を潰すのが、15 checksの役割だ。

納品したサイトを開いて、コマンドを1回叩く。6件出るか0件出るかは、たいてい公表ページを最後に触った日で決まる。