サイトの表示を軽くするために、ドメインのネームサーバを別のサービスへ切り替えた。作業自体は数分で終わり、表示も問題ない。ところが後日、ブラウザの開発者ツールを開いた担当者から「知らないスクリプトが読み込まれています」と連絡が来る。
HTML は誰も触っていません。 制作会社も、社内の担当者も、CMS の管理画面も。それでも読み込まれているファイルは増えている。
2026年8月、JavaScript を使わない静的サイトの運営者が、ネームサーバを Cloudflare に切り替えた直後に計測用のスクリプトが自動で挿入されていたと報告し、議論になりました。特殊な事故ではなく、仕組みとして起こり得る挙動です。
HTML を触っていないのに増える理由
Web ページが利用者に届くまでには、サーバーが生成した HTML が、途中の配信経路をいくつか通ります。ネームサーバを切り替えるということは、その経路そのものを別の会社に預けるということです。
経路を預かった側は、通過する HTML に手を入れられる位置にいます。実際、CDN の機能の多くはこの位置で動いています。画像を変換する、キャッシュを差し替える、圧縮する。そのなかに「計測用のタグを挿入する」という機能も含まれます。
今回話題になったのは、Cloudflare の Web Analytics が使う beacon.min.js が、ゾーン配下のページに自動で挿入される挙動です。Cloudflare の説明では、この機能を有効にすると対象のゾーン配下の全ページとサブドメインにスクリプトが自動挿入され、対象を絞るには別途ルールを設定する必要があるとされています。「サイトに埋め込む」のではなく「通過するときに差し込む」ため、ソースコードのどこを探しても見つかりません。
同種の報告は Cloudflare Pages でも出ており、Web Analytics を無効にしているつもりでもスクリプトが挿入され、管理画面に停止するための項目が見当たらないという事例が共有されています。
気づきにくいのは、探す場所が違うから
この手の追加が厄介なのは、確認の手順が普段と違うところです。
サイトに何が入っているかを調べるとき、多くの担当者はまず CMS のプラグイン一覧やタグマネージャの管理画面を見ます。しかし配信経路で差し込まれたものは、そのどちらにも出てきません。ブラウザで実際に読み込まれたファイルの一覧を見るまで、存在に気づけません。
そして、気づいたときには「誰が入れたのか」で話が止まります。制作会社は入れていないと言い、社内の担当者も覚えがない。DNS の切り替えを別の担当者やホスティング業者が行っていた場合、そもそも切り替えたこと自体が共有されていないこともあります。
発注側と保守側、どちらの範囲なのか
責任の所在があいまいになりやすいので、先に線を引いておくのが実務的です。
| 範囲 | 誰が触るか | 今回のスクリプトの扱い |
|---|---|---|
| HTML・CMS・タグマネージャ | 制作・保守を請け負う側 | ここには存在しない |
| DNS・ネームサーバ・CDN の設定 | 発注側またはインフラ担当 | ここで挿入されている |
多くの契約で、DNS の管理は発注側に残ります。ドメインは会社の資産なので当然の分担ですが、その結果として 配信経路の設定変更が、制作会社に共有されないまま行われる構造ができます。サイトの中身に責任を持つ側が、サイトに何が入っているかを把握できない状態です。
これは今回のスクリプトに限りません。更新したのに古いページが出る症状も、原因が配信経路側にあるために切り分けが長引く典型例です。
三つの場所で実害になる
「軽い計測タグが一つ増えただけ」で済まない理由が三つあります。
納品仕様との食い違い。 JavaScript を使わない構成、あるいは読み込む外部ドメインを限定する構成で作られたサイトでは、この追加が仕様違反そのものになります。表示速度を売りにして作ったサイトで、計測されるはずのない外部リクエストが増えていれば、測定値も変わります。
外部への送信について説明していない状態。 自社サイトが利用者の情報をどこへ送っているかは、プライバシーポリシーや同意取得の設計と結びついています。Cloudflare は Web Analytics について Cookie を使わないと説明していますが、説明する側が把握していない送信先があるという状態自体が、外部送信規律とCookie同意の設計で整理した前提を崩します。ポリシーに書いていない挙動が実際に動いていることが、後から問題になります。
CSP と計測の二重化。 コンテンツセキュリティポリシーを設定しているサイトでは、許可していないドメインのスクリプトは実行がブロックされ、コンソールにエラーが出ます。逆に CSP を設定していないサイトでは、何も起きずに動き続けます。エラーが出るサイトのほうが早く気づけるという、少し皮肉な状況になります。また、既存の解析ツールと並行して動くため、ページビューの数え方が二系統になります。数字の食い違いに気づいたときの原因追跡は、広告ブロックによる計測欠損と同じくらい厄介です。
確認と停止の手順
まず、自社サイトで実際に何が読み込まれているかを確認します。
- ブラウザでサイトを開き、開発者ツールのネットワークタブを表示する
- ページを再読み込みし、読み込まれたファイルの一覧を出す
- 自社のドメイン以外から取得されているファイルを書き出す
- 書き出したドメインを、社内で把握している解析ツール・広告タグの一覧と突き合わせる
突き合わせて残ったものが、把握していない送信先です。この作業は月に一度、担当者が5分で終えられます。 変更を検知する仕組みを作るより、定期的に目視するほうが定着します。
止め方は挿入元によって変わります。今回の Cloudflare のケースでは、Web Analytics のダッシュボードで対象のサイトを登録したうえで、その計測を無効にするという手順が報告されています。有効化した覚えがなくても、止めるにはいったん管理対象として登録する必要があるという点が直感に反するので、ここで詰まりがちです。ホスティング側の機能として挿入されている場合は、そのサービスの設定を確認することになります。
次にやること
自社サイトのネームサーバをどこに向けているか、そして直近1年でその設定を変更したかどうかを確認してください。変更した記憶がない場合でも、ドメインの管理を誰が持っているかを一度はっきりさせておく価値があります。 移管や更新のタイミングで、把握していない設定が入ることがあります。
そのうえで、開発者ツールで外部ドメインの一覧を取り、把握していないものがないかを見てください。一つでも説明できないものが出てきたら、それはプライバシーポリシーに書かれていない送信先である可能性があります。
サイトの配信構成の整理、DNS と CDN の設定を含めた保守の分担、既存サイトの外部送信の棚卸しについては、グリームハブのHP制作・リニューアル相談で承っています。現在の構成と契約状況によって取れる手段が変わるため、個別にご相談ください。お問い合わせからどうぞ。
