ウェブビーコンとは、WebページやHTMLメールを読み込むときに発生する通信を、ページ表示やメール開封の計測に使う仕組みです。
画面では見えない1ピクセル四方の画像は、代表的な実装の一つにすぎません。
ブラウザやメールクライアントが画像などを取得すると、指定されたサーバーへリクエストが送られます。計測システムは、その通信をURL内の識別子やCookieなどと結び付け、ページ表示やメール開封の手がかりにします。
ただし、通信を記録できることと、その記録から利用者の関心や行動理由を判断できることは別です。また、ページ運営者とは別の事業者へリクエストが届けば、第三者トラッキングにつながる場合があります。
この記事では、ウェブビーコンの仕組み、送信され得る情報、メール開封計測の限界、第三者送信、規制とプライバシー保護、Web担当者が確認すべき項目を見ていきます。
ウェブビーコンは通信を計測する仕組み
WebページやHTMLメールのHTMLには、外部サーバー上にある画像などのURLを記述できます。ブラウザやメールクライアントがその画像を表示しようとすると、URLで指定されたサーバーへリクエストが送られます。
サーバーは画像を返すと同時に、リクエストが届いた時刻やURLなどを記録できます。この通信を計測に使う仕組みが、ウェブビーコンやトラッキングピクセルと呼ばれます。
英国の情報コミッショナー事務局（ICO）も、トラッキングピクセルを、Webサイトやメールに埋め込まれ、利用者側のクライアントとサーバーの間に通信を作るコードとして説明しています。詳しくは、ICOのStorage and Access Technologiesガイダンスで確認できます。
通信の流れを単純化すると、次の4段階です。
- サイト運営者やメール配信事業者が、WebページやHTMLメールに計測用URLを指定した画像やコードを埋め込む
- ブラウザやメールクライアントが、そのURLへリクエストを送る
- 受信したサーバーが、時刻、URL、HTTPヘッダなど、利用できる情報を記録する
- 計測システムが、URL内の識別子やCookieなどを使い、特定の配信、セッション、端末などと記録を結び付ける
関連する用語は同じ意味ではない
1ピクセル画像、トラッキングピクセル、スクリプト、Cookieには重なる部分があります。ただし、すべてを同じものとして扱うと、実際の実装を見落とします。
| 言葉 | 主な意味 | 注意点 |
|---|---|---|
| 1ピクセル画像、透明GIF | 目立たない小さな画像を読み込ませる古典的な実装 | ウェブビーコンは必ず1ピクセルとは限らない |
| ピクセルタグ、トラッキングピクセル | 画像などの読み込みに伴う通信を計測へ使う仕組み | メールにもWebページにも使われる |
| スクリプト、タグ | ブラウザでコードを実行し、イベントや端末情報などを取得・送信する実装 | すべてのスクリプトが追跡用ではない。画像より多くの処理を行える場合がある |
| Cookie | ブラウザが保存し、条件に合うリクエストでサーバーへ返す情報 | ビーコンそのものではないが、通信を継続的な識別子と結び付けるために併用される |
ウェブビーコンの本質は、画像の大きさではなく、その読み込みで発生する通信を計測に使う点にあります。一方で、ページ表示に必要な通常の画像や機能用スクリプトまで、すべてウェブビーコンと呼ぶのも適切ではありません。実装の目的と、実際の送信内容を確認する必要があります。
送信される情報は実装と利用環境で変わる
Web担当者は、仕様上送れる情報と、個々の環境で実際に送られる情報を分けて確認します。ブラウザやメールクライアントの設定、プライバシー保護機能、プロキシ、同意状態も送信内容へ影響します。
次の情報が、常にすべて送られるわけではありません。
| 情報 | どこから生じるか | 読む際の注意点 |
|---|---|---|
| リクエスト時刻 | サーバーが通信を受けた時刻 | 人が実際に読み始めた時刻とは限らない |
| リクエスト先のURLとクエリ文字列 | HTMLやスクリプトに指定された取得先 | URLに固有ID、配信ID、ページIDなどを含められる |
| IPアドレス | 通信を受けるサーバーから見える接続元 | プロキシやプライバシー保護機能のアドレスになる場合があり、個人や正確な場所を直接示すとは限らない |
| User-AgentなどのHTTPヘッダ | ブラウザやメールクライアントが送るリクエスト情報 | 製品名やOSの推定に使える場合があるが、省略、縮小、置換されることもある |
| 参照元 | Referer ヘッダなど |
ポリシーや環境によって送られない、またはオリジンまでに短縮される場合がある |
| Cookie | 対象ドメイン、ブラウザ設定、同意状態などの条件に合う場合 | Cookieがなければ通信も起きない、という意味ではない |
| 画面寸法、イベント、購入情報など | ページ上のスクリプトや実装が収集して送る | 単純な画像リクエストだけで自動的に得られる情報ではない |
HTTPでは、取得対象を示す情報や、利用者側のソフトウェア、参照元などに関するヘッダを扱えます。技術仕様はIETFのRFC 9110で確認できます。
ただし、Web担当者は、仕様に書かれていることだけで個々の通信を判断しません。開発者ツールや配信システムの設定を使い、実際に何が送信されているかを確認します。
URLの固有IDはCookieがなくても使える
メール配信事業者は、受信者や配信ごとに異なる画像URLをHTMLメールへ割り当てられます。どのURLへリクエストが届いたかを見れば、どの配信に反応があったかを推定できます。Webページでも、リンクやリクエストURLへ識別子を付ける方法があります。
そのため、Cookieを拒否しても、外部サーバーとの通信がすべて止まるとは限りません。ページが画像やスクリプトを読み込めば、リソースを取得するリクエストは発生し得ます。
反対に、同意管理の仕組みが、許可前に対象タグや外部リソースの読み込みを止めていれば、リクエストも抑えられます。Web担当者が確認すべきなのは、Cookieの有無だけではありません。どの通信が、どの送信先へ、どの条件で発生するかを見ます。
メールの「開封」は画像リクエストからの推定
HTMLメールの開封計測で記録されるのは、原則としてリモート画像へのリクエストです。本文を読んだことや、内容を理解したことを直接測っているわけではありません。
メール配信事業者は、受信者や配信ごとに異なるURLの小さな画像をHTMLメールへ埋め込めます。メールクライアントがその画像を取得し、配信システムへリクエストが届くと、「開封」として記録されます。
この記録は、テキストメールにはない反応の手がかりになります。当社でも、HTMLメールの開封やクリックを、配信先リストの状態を見る材料として使ってきました。ただし、現在は開封率だけを閲読の証拠にできません。
開封は閲読を意味しない
計測システムが分かるのは、画像へのリクエストがあったことです。本文を読んだか、内容を理解したか、何秒見たかまでは分かりません。
メールクライアントのプライバシー保護機能も、記録へ影響します。Appleは、Mail Privacy Protectionを有効にすると、IPアドレスを送信者から隠し、メッセージを表示した時点ではなく、受信時にリモートコンテンツを背景で取得すると案内しています。一方で、すべてのリモートコンテンツを利用者がブロックする設定もあります。現在の動作は、AppleのMailプライバシー保護に関する公式ガイドで確認できます。
このため、読んでいないメールでも画像リクエストが発生する場合があります。反対に、本文を読んでも画像が取得されず、開封として記録されない場合もあります。
| 指標 | 判断の手がかりになること | その指標だけでは判断できないこと |
|---|---|---|
| 配信成功・不達 | メールサーバーが受け付けたか、エラーになったか | 受信者が本文を読んだか |
| 開封 | リモート画像のリクエストが観測されたか | 人が読んだか、関心を持ったか、実際の開封回数 |
| クリック | メール内リンクへのアクセスが観測されたか | 内容を理解したか、購入や相談の意思があるか |
| 返信、申込み、購入 | 受信後に具体的な行動があったか | メールだけが行動の原因だったか |
配信先リストを見直すときは、開封の有無だけで機械的に削除しない方が安全です。当社の運用では、単発の未開封だけで配信対象から外しません。複数回にわたり開封もクリックも確認できない場合に継続意思を確かめ、それにも反応がなければ配信を止めています。
これは普遍的な回数基準ではありません。誤判定を減らし、再登録の経路を残すための運用例です。
当社は、配信先を判断するときに、不達、迷惑メール報告、クリック、返信、直近の取引や問い合わせも使います。到達状況を確認せずに開封率だけを見ると、本当は届いていないのに、件名や内容への関心が下がったと誤解する場合があるためです。具体的な見直し方は、メールの到達・開封とリストクリーンアップの考え方でも扱っています。
Webページでは第三者に情報が届く場合がある
一つのWebページは、運営者のサーバーだけから構成されるとは限りません。アクセス解析、広告、SNS、動画、フォントなど、複数の事業者のサーバーから資源を読み込むことがあります。
ページを訪れた人を運営者自身が追跡する場合は、ファーストパーティートラッキングと呼ばれます。別の事業者が追跡できる状態にする場合は、第三者トラッキングと呼ばれます。
米国の連邦取引委員会（FTC）は、Cookie、ピクセル、デバイスフィンガープリンティングをオンライン追跡の技術として挙げています。ファーストパーティーと第三者の違いは、FTCの2023年9月の消費者向け資料で説明されています。
第三者のサーバーへリクエストが届けば、その第三者はリクエストに含まれる情報を受け取れます。同じ識別子が複数のサイトで使われるなどの条件がそろうと、別々のサイトで起きた行動を結び付けられる可能性があります。
100万サイト超の研究が示すのは実装の傾向
2025年にJournal of Network and Computer Applicationsで公開された「Large-scale web tracking and cookie compliance」は、Trancoの上位リストから100万サイト超を自動評価しました。
研究は、Cookie、ピクセルトラッキング、ブラウザフィンガープリンティングを対象としています。有効な同意前にトラッキングCookieを使うサイトが半数近く、ピクセルトラッキングを使うサイトが半数を超えたと報告しました。
この資料は、FTCのような消費者向け概説でも、ICOの法的ガイダンスでもありません。欧州のGDPRとePrivacyを評価軸とし、研究者が定めた検出方法と同意判定を使った大規模測定です。
研究結果は、追跡技術がWeb上で広く実装されている傾向を示します。ただし、この結果だけで個々のサイトの法令違反を確定することはできません。すべての訪問者が個人として識別されたと結論付けることもできません。
法規制、同意管理、保護機能は役割が異なる
第三者へ通信が届く場合は、技術的な実装だけでなく、同意、利用目的、委託先、対象地域の規制も確認対象になります。ただし、法規制、サイト側の同意管理、利用者側の保護機能は、それぞれ役割が異なります。
| 資料 | 管轄・発表時期 | 主に示す範囲 |
|---|---|---|
| FTCの消費者向け資料 | 米国、2023年9月 | オンライン追跡の代表技術、用途、利用者が取れる一般的な対策 |
| ICOの最終ガイダンス | 英国、2026年4月29日 | PECRと、必要に応じたUK GDPRがCookie、トラッキングピクセル、フィンガープリンティングなどへどう適用されるか |
| 100万サイト超の査読研究 | 欧州法を評価軸とする研究、2025年 | 自動測定で観測した追跡技術と同意状態の大規模な実装傾向 |
ICOは、2026年4月29日に公開した最終ガイダンスの告知で、Cookieだけでなく、トラッキングピクセル、デバイスフィンガープリンティング、同様の技術も対象に含めています。
英国のPECRでは、端末への情報保存や端末内情報へのアクセスについて、適用できる例外がなければ有効な同意が必要になるとICOは説明しています。利用目的、第三者、保存・アクセス期間などを知らせる要件もあります。
例外の有無やUK GDPRとの関係は、目的と実装によって変わります。この説明は、2026年8月10日に確認した英国の一般情報です。日本を含む他国・地域の法的助言ではありません。
運用事業者は、対象地域、利用目的、扱う情報、委託先との関係を明らかにします。必要に応じて専門家へ確認します。
保護機能は計測値の意味も変える
利用者側では、ブラウザのトラッキング防止、広告ブロッカー、メールのリモート画像遮断、IPアドレスを隠すプロキシなどが、通信や送信情報を制限します。Webサイト側では、同意管理の仕組みにより、許可前のタグ実行や外部リソースの読み込みを止められます。
これらはプライバシーを守る仕組みです。同時に、計測データの欠損や置換を生む要因でもあります。
Web担当者は、計測値が減った、または増えた理由を利用者の関心だけに求めません。ブラウザ、メールクライアント、計測方法の変化も候補に含めます。
計測値を事業判断に使うときの注意
ここからは、外部資料が示す事実ではなく、当社が2013年以降、アクセス解析やメール配信を扱う中で更新してきた実務上の見解です。
取得できる値と、知りたい事実を分ける
当社は2013年、アクセス解析ツールを開く前に、施策の目的と変化するはずの数字を決める必要があると述べました。
数字が無価値という意味ではありません。担当者は、その数字が何を直接観測しているのか、何の代理指標として使うのか、何を観測していないのかを言葉にします。利用者の「なぜ」は、アクセス解析だけで断定せず、仮説検証や実地調査で補います。
2018年には、当社の見解としてWeb上の個人トラッキングは、いつできなくなってもよい前提で扱うとしました。規制、ブラウザ、メールクライアント、配信事業者の変更によって、同じ条件で計測を続けられるとは限らないためです。
計測環境の変化に備えるには、顧客との直接接点や別の情報源を持つ必要があります。Webサイトを見た人が、フォームを使わずに電話をかける場合もあります。以前から知っている営業担当へ連絡する、店舗や展示会で話す、紹介元を通じて相談することもあります。
オンライン計測に現れないからといって、Webページやメールが役立たなかったとは限りません。
| 知りたいこと | ウェブビーコンなどで得られる手がかり | 一緒に見る情報 |
|---|---|---|
| メールが関心を持たれたか | 開封リクエスト、リンクのクリック | 返信、継続意思、問い合わせ、購入、不達や迷惑メール報告 |
| ページが施策に関わったか | ページ表示、イベント、広告への接触 | 問い合わせ時の聞き取り、電話、商談、紹介、受注・失注理由 |
| 広告が成果に寄与したか | 識別子を使った接触・コンバージョン記録 | 広告を見ていない層との比較、利益、顧客の申告、ほかの接点 |
| 顧客像を理解できたか | 閲覧ページ、端末、反応の集計 | 顧客との会話、質問、苦情、営業・サポートの記録 |
「計測できるから取る」「取れないから捨てる」を避ける
ウェブビーコンで追えるものだけを成果とすると、電話、商談、紹介、後日の指名検索などが判断から抜けます。
反対に、技術的に取得できるという理由だけで個人単位の履歴を増やすと、目的に不要な情報まで集めることになります。第三者送信や保管の範囲も広がります。
Web担当者は、実装範囲を計測できるかどうかだけで決めません。利用目的、その判断に必要な情報、利用者への影響、送信先、保存期間、代替手段を先に確認します。
Web上で直接計測できない成果には、問い合わせ時の聞き取り、営業記録、紹介元、受注・失注理由など、別の確認方法を用意します。計測できる指標も、欠測やメールクライアントによる背景取得が起こる前提で扱います。配信成功・不達、クリック、返信、申込みなど、複数の情報を組み合わせます。
通信記録だけで、利用者が内容を理解した、好意を持った、購入を決めたとは判断できません。ウェブビーコンは、行動の一部を観測する手段です。
Web担当者が確認する項目
Web担当者は、実装を確認するときに、Cookieバナーが表示されているかだけで判断しません。次の順序で確認します。
1. 通信の確認
- WebページとHTMLメールが、どのドメインへリクエストを送っているか
- それぞれの画像、タグ、スクリプトを何の目的で使っているか
- URL、Cookie、HTTPヘッダ、イベントデータに、どの識別子や情報が含まれるか
2. 管理の確認
- 自社と委託先のどちらが情報を受け取り、ほかの目的にも使うか
- 同意前、拒否後、同意撤回後に、対象の通信が実際に止まるか
- データの保存期間、削除手順、アクセス権、委託先との契約が決まっているか
3. 判断の確認
- メールクライアントの背景取得や画像遮断が、開封率へどう影響するか
- 計測値をどの判断に使い、電話、商談、紹介などの情報でどう補うか
- 対象地域の現行法とガイダンスを、公開・改修前に確認したか
ブラウザの開発者ツールにあるNetworkパネル、タグ管理画面、同意管理ツール、メール配信システムの設定を照らし合わせると、文書上の説明と実際の通信が一致しているかを確認しやすくなります。
Web担当者は、確認を導入時だけで終えません。タグや委託先を変更した後にも、同じ手順で見直します。
まとめ
ウェブビーコンの本質は、1ピクセル画像そのものではなく、クライアントからサーバーへ届くリクエストを計測に使う点にあります。URLの固有IDやCookieを使えば、通信を配信、セッション、端末などと結び付けられる場合があります。
ただし、Cookieを拒否しても外部リソースの読み込みまで止まるとは限りません。HTMLメールの開封も画像リクエストからの推定であり、閲読や関心の証明ではありません。
Web担当者は、Webページから第三者へ通信が送られる場合、送信内容、利用目的、同意、委託先、保存期間、対象地域の規制を確認します。ブラウザやメールクライアントの保護機能によって、取得できる情報と計測値の意味も変わります。
取得できる値と知りたい事実を分け、複数の指標と顧客との直接接点を組み合わせることが重要です。追跡だけに依存しないことが、現在のWeb運用でウェブビーコンを扱う基本です。
参考資料
- Federal Trade Commission, How Websites and Apps Collect and Use Your Information, 2023年9月
- Information Commissioner’s Office, Final storage and access technologies guidance published, 2026年4月29日
- Information Commissioner’s Office, What are storage and access technologies?, 2026年8月10日確認
- Information Commissioner’s Office, What are the PECR rules?, 2026年8月10日確認
- Martínez, D.ほか, Large-scale web tracking and cookie compliance: Evaluating one million websites under GDPR with AI categorization, Journal of Network and Computer Applications, Vol. 242, 2025
- Apple, Protect email privacy in Mail on Mac, 2026年8月10日確認
- Internet Engineering Task Force, RFC 9110: HTTP Semantics, 2022年6月
