クッキーについて(2)

記事
IT・テクノロジー
※本ブログは弊社Webサイトのコラムとして掲載したものをココナラ用に再編集したものです

こんにちは。 小さな会社のためのデジタル戦略室、株式会社ホットソウル代表・若杉です。

前回に引き続き、

最近、一部企業のホームページページやニュースなどで目にする機会が増えた「クッキー」というものについて、特に小さな会社ではどのように考えれば良いのかという観点で考えていきたい思います。

「うちの場合はどうしたら良いのだろう?」と不安を抱えていらっしゃる経営者様の、不安解消の一助になれば幸いです。

少し振り返り

前回は、そもそも「クッキー」とは何者か?!という、話の大前提となる部分について整理してみました。

一部再掲しますと、

① クッキーとは、小さなデータのことです。
② 最初は、ホームページページ等を配信しているサーバー側から送られてきます。
③ それを、ブラウザーが保存します。
④ 次に同じサーバーにアクセスする際に、ブラウザーからサーバーに返送します。

そして、以下3つの用途で使用されます。

□ セッション管理
ログイン、ショッピングカート、ゲームのスコア、またはその他のサーバーが覚えておくべきもの

□ パーソナライゼーション
ユーザー設定、テーマ、その他の設定

□ トラッキング
ユーザーの行動の記録及び分析

近年、このトラッキング目的で使用されるクッキーにより、Webサイトの閲覧履歴などを外部の広告会社等に同意なく提供すること、が問題視されています。

具体的になにが問題なのかを理解するため、
どのような仕組みで、閲覧履歴などが外部の広告会社等に提供されるのか、
を整理していきたいと思います。

Webページの作られ方

#13-image2.png

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

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

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

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

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

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

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

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

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

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 属性によって、もっと細かい制御ができるのですが、話が複雑になってしまうので、またの機会に。


行動履歴収集の仕組み

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

#13-image3.png
別々の管理者が運営している、
①居酒屋ライターの飲み歩きブログ
②飲食店検索サイト
③お取り寄せ品まとめサイト
の3つがあったとします。

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

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

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

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

①のときに、とある識別情報を渡され、
②、③では、その識別情報をASP・A社サーバーに通知している、

といった事が起きます。

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

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

という事が分かります。

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

つまり、ASP側には、

■ ①居酒屋ライターの飲み歩きブログ を見た人が、
■ 次に、②飲食店検索サイト を見て、
■ 更にその後、③お取り寄せ品まとめサイト も見た

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

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

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

今回のまとめ

●1つのWebページは複数のサーバーから送られている場合がある。
●それぞれのサーバーとは混線せずにクッキーのやり取りができる。
●クッキーを使った行動履歴収集の仕組みついて大枠を整理した。

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

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

次回もお楽しみに!


サービス数40万件のスキルマーケット、あなたにぴったりのサービスを探す