ObservePointで実現する次世代Web監査とROI最大化 – 第5回「知らない通信」が発生している – ピギーバックとデイジーチェーンの脅威

「このタグ、誰が入れたんだっけ？」「なぜこのドメインに通信が発生しているの？」

Webサイトを運用していると、こうした「身に覚えのない通信」に遭遇することがあります。

しかし、それはハッキングでも設定ミスでもなく、通常のフローで実装したタグが、知らない別の通信を起こしているのかもしれません。

外部スクリプトは何でもできてしまう

タグをサイトに追加するとはどういうことでしょうか。

それは「vendor-a.comのサーバーが返すコードを、うちのサイトで毎回実行していいです」という許可を与えることです。ページが読み込まれるたびに、ブラウザはvendor-a.comのサーバーにリクエストを送り、そのとき返ってきたコードをそのまま実行します。

技術的には、vendor-a.comはサイトに返すコードをいつでも変更できます。タグを導入した翌日でも、1年後でも。リクエストのたびに動的に生成してユーザーごとに違うコードを返すことも可能です。もちろん、あなたがサイトに実装したコードは何も変わっていないのに、です。

ピギーバックとデイジーチェーン

このリスクをさらに複雑にするのが「ピギーバック」と「デイジーチェーン」です。

ピギーバック（相乗り）： TMSで実装したvendor-a.comのタグが、その内部でpartner-b.comの別のスクリプトを呼び出す現象です。あなたはvendor-a.comのタグを実装したことは認識していますが、実際にはユーザーのブラウザでまったく知らない別のスクリプトがロードされ実行されてしまうのです。

デイジーチェーン（連鎖）： ピギーバックが多段になったものです。AがBを呼び、BがCを呼び、CがDを呼ぶ——という連鎖に制限はありません。しかも、vendor-a.comも自身が利用しているライブラリやパートナー経由で追加通信が発生していれば、結果として依存関係の全体像を十分把握できていないケースもあります。

これらの通信はサーバーログに残らず、サイト訪問者のブラウザ上でのみ起きているため、なかなかサイト運営側では気づくことが難しいでしょう。

「悪意」がなくても起きている——広告系タグが抱える構造的リスク

ピギーバックと聞くと、悪意があるイメージを持つかもしれません。しかし広告タグの構造上、悪意の有無にかかわらず意図しない通信が発生しうるパターンがあります。

オーディエンス共有： 一部の広告・マーケティングプラットフォームでは、パートナー企業とのデータ連携やオーディエンス共有機能が提供されており、実装や契約内容によっては複数ドメインへの通信が発生する場合があります。契約・規約上は許容されていても、自社の担当者レベルで把握できていなければ、ユーザーへの説明責任を果たせません。

リターゲティングの「拡張」： 「精度の高いリターゲティング」を売り文句とするベンダーのネットワーク経由で、データが複数社に共有されうる構造になっているケースがあります。規約のどこかに記載があっても、担当者レベルでは把握していないことも少なくありません。

これらは「必ずこうなっている」という断定ではありません。しかし問題は、把握していないこと自体にあります。改正個人情報保護法やGDPRの観点では、個人データの取得・利用・第三者提供に関しては、サイト運営者側にも一定の管理責任や説明責任が求められます。「知らなかった」だけでは十分な説明にならず、管理体制や委託先管理の妥当性が問われる可能性があります。

誰が悪いのか

正直なところ、一概には言えません。

ベンダーのビジネス慣行によるものもあれば、複数の代理店・開発チームがTMSに関与する環境で、承認フローを経ずにタグが追加されているケースもあります。また、ベンダーが利用しているCDNやサードパーティライブラリ経由で、ベンダー自身も把握していない通信が発生しているケースもあります。

重要なのは犯人を特定することではなく、自社のサイトで何が起きているかを把握し、管理できる状態にすることです。改正個人情報保護法やGDPRの観点では、発生源がどこであれ、ユーザーデータを扱う企業側の責任は免れません。大手企業であるほど、この説明責任の重さは増します。

見つけたらどうするか

ObservePointのInitiatorsツリーでピギーバックやデイジーチェーンを発見したら、以下のステップで対処します。

Step 1 — 親タグを特定する ツリーを遡り、未知の通信を呼び出している「親」のタグを特定します。どのベンダーのタグが起点になっているかが明確になります。

Step 2 — ベンダー・代理店に確認する 「このドメインへの通信はどういう目的で、何のデータを送っているか」をベンダーや実装を担当している代理店に問い合わせます。意図的なものか把握していないものかを確認します。

Step 3 — 再スキャンで因果関係を検証するObservePointには複数の検証手段があります。対象タグがObservePointに登録済みであればタグブロック機能で指定して再スキャン。未登録の不明なスクリプトはFile Substitutionsでリクエスト単位でブロックできます。また「TMS自体をブロックして実行」するモードでは、TMSをブロックした状態で再監査することで、TMS非依存の通信と比較検証することができます。いずれも本番環境に影響を与えずに検証できます。

Step 4 — 必要に応じてタグを削除・ドメインをブロック 不必要・不正な通信と判断されれば、該当タグを削除します。コンセント管理ツール（CMP）側でそのドメインをブロックリストに追加することも有効です。

「まず把握する」ことから始める

ピギーバックは、セキュリティインシデントや不正アクセスとは無関係に発生します。複数のベンダー・代理店が関与する大規模サイトであれば、今この瞬間にも発生している可能性があります。

「自社サイトで何が通信されているかを把握し、説明できる状態にあること」——それ自体が、現代のデジタルガバナンスの基本要件になっています。

【ObservePoint無料トライアルのご案内】

貴社サイト（50ページ程度）を対象に、ObservePointのAuditを実施し、実際に生成されたレポートをご覧いただきながら、ObservePointのご説明をいたします。ご希望の方は以下の内容を添えて sc-observepoint@ex-ture.jp までご連絡ください。

件名：ObservePointトライアル

本文：
・貴社名
・お名前
・メールアドレス
・URL
・ 気になっている課題（例：タグが管理できていない、アクセシビリティ対応ができていない など）