Webページの作られ方

手始めに、一度クッキーの話題から離れ、普段ご覧になっているWebページがどのように作られているかを確認してみます。

ご存知の方も多いかもしれませんが、1枚のWebページを構成している文章・画像・動画等々の構成要素は、必ずしも同じ1つのサーバーから送られている訳ではありません。

例えば弊社ホームページの場合、お問い合わせページの一部（図の青枠あたり）は、Googleのサービスを利用して表示しています。

つまりこの部分だけは、弊社のドメイン（hotsoul.jp）に所属しているサーバーではなく、Googleのサーバーから送られてきています。

（ドメインというのは、インターネット上での住所に近いものです。例えば「hotsoul.jp」ですと、『日本』の『株式会社ホットソウル』が管理する土地、といったイメージになります。）

他によくある例としては、アフィリエイト広告と呼ばれる、Webページの端などに表示される広告があります。

アフィリエイト広告は、広告を配信する専門事業者（ASP：アフィリエイトサービスプロバイダー）のサーバーから送られてきます。

ご自身のホームページやブログにアフィリエイト広告を配置したい方は、ASPに申請を行って、『広告を配信する仕掛け』をホームページやブログに設置します。

なお、アフィリエイト広告についての説明は、こちらのページが分かりやすかったです。

アフィリエイト広告の種類は3種類だけ！？それぞれの特徴と効果を徹底解説！

話が少しそれましたので、元に戻しますと、

Webページの作り方としては、文章・画像・動画等々の構成要素ごとに、別々のサーバーから送ることも可能である。

という事です。

ここに、閲覧履歴などを外部の広告会社等に提供するための接点、ができます。

つまり、

■ ユーザーがとあるA社のWebページだと思って見ていると、

■ 実はその中には、B社、C社から送られている部分もあり、

■ ユーザーが意識しないうちにB社、C社のサーバーとも通信が行われている、

ということです。

クッキーの送り先

前項で、1枚のWebページは複数の会社が管理するサーバーから送られている場合がある、というお話をしました。

では、このときクッキーは、どうなのでしょうか？

実はクッキーも、複数の会社が管理するサーバーから送られている場合があります。

冒頭でも振り返ったように、クッキーは、

② 最初は、ホームページページ等を配信しているサーバー側から送られ

④ 次に同じサーバーにアクセスする際に、ブラウザーからサーバーに返送します。

という動きになります。

イメージ的には、ブラウザー内のクッキー保管棚には、色々なサーバーからもらったクッキーが沢山つまっている感じです。

A社のサーバーからもらったクッキーを、B社のサーバーに送ってしまっては、色々とまずいことになります。

そこで、クッキーの中には、送り先のサーバーを判別するための情報が用意されてます。

前回も引用させて頂いたMDN Web Docs より、再び抜粋引用させて頂きます。

（出典）MDN Web Docs - HTTP Cookie の使用

“ Cookie の送信先の定義

Domain および Path 属性は、Cookie のスコープ、つまり Cookie を送信する対象の URL を定義します。 ”

ざっくり言いますと、クッキーの中には『ドメイン（Domain）』と『パス（Path）』と呼ばれる情報が含まれていて、それがクッキーを送り返す宛先を表しています。

このとき『同じサーバー』かどうかを判別するための情報が、『ドメイン（Domain）』と『パス（Path）』ということになります。

“ Domain 属性

Domain 属性は、Cookie を受信することができるホストを指定します。 ”

ホストとは、サーバーと同じ意味合いです。

“ Path 属性

Path 属性は、 Cookie ヘッダーを送信するためにリクエストされた URL の中に含む必要がある URL のパスを示します。 ”

このPath 属性によって、もっと細かい制御ができるのですが、話が複雑になってしまうので、またの機会に。

行動履歴収集の仕組み

最後に、クッキーを利用してユーザーの行動履歴を集める仕組みについて、大枠を整理したいと思います。

別々の管理者が運営している、

①居酒屋ライターの飲み歩きブログ

②飲食店検索サイト

③お取り寄せ品まとめサイト

の3つがあったとします。

この3つは、管理者同士に接点もなく全くの無関係なのですが、1つだけ共通点があります。

それは、3つとも、とあるASP（広告を配信する専門事業者）・A社が配信する広告を表示しているのです。

あるときBさんが、① ⇒ ② ⇒ ③ の順にネットサーフィンを楽しんだとします。 （ネットサーフィンって最近聞かないですね。）

このとき、Bさんが意識しないうちに、ASP・A社サーバーとのやり取りも発生しており、

①のときに、とある識別情報を渡され、

②、③では、その識別情報をASP・A社サーバーに通知している、

といった事が起きます。

これを、ASP側の視点でみると、

①でアクセスしてきた人が、

②、③でもアクセスしてきた、

という事が分かります。

さらに、HTTPというWebサイトを見るときに使われている通信ルールに含まれる『リファラ』という仕組みなどを利用することで、どのWebサイトに表示している広告を見たのか、ということが分かってしまいます。

つまり、ASP側には、

■ ①居酒屋ライターの飲み歩きブログ　を見た人が、

■ 次に、②飲食店検索サイト　を見て、

■ 更にその後、③お取り寄せ品まとめサイト　も見た

ということが分析できる情報が蓄積されていきます。

これだけの情報では『Bさん個人』は特定されないものの、同じブラウザーからのアクセスが、① ⇒ ② ⇒ ③ の順に行動したという履歴が残ります。

リファラについては、更に長くなってしまいますので、また別の機会に。

MDN Web Docs – Referer

気になる方は、こちらのサイトの説明が分かりやすかったですので、ご参考にどうぞ。

「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 - リファラ

もしこのような行動履歴の情報を膨大に持っているとしたら、それを分析することで、『Bさん個人』は特定できずとも、年齢層や性別、趣味趣向、住んでいる地域、なども推定できるものと思われます。

これは、広告を出す側としては、狙いを定めて広告を出す事にもつながりありがたい訳ですが、一般のユーザー側（消費者側）の立場としては何だかモヤモヤしますよね。

今回のまとめ

●1つのWebページは複数のサーバーから送られている場合がある。

●それぞれのサーバーとは混線せずにクッキーのやり取りができる。

●クッキーを使った行動履歴収集の仕組みついて大枠を整理した。

ここまでお読みいただきありがとうございました。

前回に引き続き、技術寄りの話が続きましたので、次回は視点を変え、なぜ近年トラッキング目的のクッキー利用が問題視されるようになってきたか、その根拠となる法令等に焦点を当てていきたいと思います。

次回もお楽しみに！