Cookieとは？ 10分でわかりやすく解説

UnsplashのPietro De Grandiが撮影した写真 

Cookieは、Webサイトがログイン状態、表示設定、カート情報、計測用の識別子などを扱うための基本技術です。ブラウザに保存された小さなデータを、条件に合うリクエスト時に送信することで、HTTP通信だけでは保持しにくい状態管理を補います。

一方で、CookieはセッションIDの窃取、クロスサイト攻撃、過剰な追跡、外部送信の説明不足といったリスクにも関係します。企業がCookieを使う場合は、利便性だけでなく、保存する値、属性設定、保存期間、同意・通知、外部タグ管理を目的別に整理する必要があります。

Cookieとは何か

Webサイトを閲覧するとき、ブラウザとサーバーはHTTPまたはHTTPSで通信します。HTTPは状態を保持しない設計であるため、通信ごとにユーザーの状態をそのまま記憶することはできません。Cookieは、この制約を補い、ログイン状態や設定情報などを扱えるようにする仕組みです。

Cookieの定義と役割

Cookieとは、Webサイトのサーバーがブラウザに保存させる小さなデータです。サーバーはレスポンスヘッダーのSet-CookieでCookieを設定し、ブラウザは条件に合う次回以降のリクエストでCookieを送信します。サーバーはその値を使って、ユーザーや状態を識別します。

Cookieが担う代表的な役割は次のとおりです。

1. ユーザー認証の補助：ログイン後の状態維持、セッションIDの管理
2. ユーザー設定の保持：言語、テーマ、表示形式、同意状態などの記録
3. ECの状態保持：カート、最近見た商品、配送先候補などの維持
4. 計測・分析：アクセス解析、コンバージョン計測、A/B テストの振り分け

Cookieには、IDやパスワードそのものを保存しない設計を採用します。認証用途では、サーバー側のセッションや認証状態に紐づく識別子をCookieに保存し、実際の権限や機密情報はサーバー側で管理します。

Cookieの仕組みと動作原理

Cookieの基本的な動作は、次の流れで整理できます。

1. ユーザーがWebサイトにアクセスすると、サーバーはSet-CookieヘッダーでCookieを設定する
2. ブラウザはCookieを、ドメイン、パス、有効期限などの条件に従って保存する
3. 条件に合うリクエスト時に、ブラウザはCookieヘッダーでCookieを送信する
4. サーバーはCookieの値を読み取り、ログイン状態の確認や表示制御を行う

Cookieには、保存と送信を制御する属性があります。代表的な属性は次のとおりです。

• Expires / Max-Age：Cookieの有効期限を指定する
• Domain / Path：Cookieが送信される対象範囲を指定する
• Secure：HTTPS通信時にだけCookieを送信する
• HttpOnly：JavaScriptからCookieを参照できないようにする
• SameSite：クロスサイトリクエスト時のCookie送信を制御する

ExpiresまたはMax-Ageを指定しないCookieは、通常はセッションCookieとして扱われます。ただし、ブラウザのセッション復元機能によって、ブラウザ終了後も復元される場合があります。そのため、認証に使うCookieでは、サーバー側の有効期限や失効処理も合わせて設計します。

Cookieを使うメリットとデメリット

Cookieの主なメリットは、Webサイトで状態管理ができる点です。ログイン状態を維持し、表示設定を記憶し、カートや入力途中の情報を扱えるようになります。分析やA/Bテストにも使えるため、サイト改善の判断材料を集める手段にもなります。

デメリットは、セキュリティとプライバシーの2系統に分かれます。

• セキュリティ：Cookieが盗まれたり悪用されたりすると、なりすましやセッションハイジャックにつながる場合がある
• プライバシー：識別子として使われると、ユーザーの行動が本人の認識しにくい形で記録される場合がある

Cookieは、目的ごとに使い分ける必要があります。ログイン維持に必要なCookie、表示設定のCookie、分析用Cookie、広告用Cookieを同じ扱いにすると、説明責任とリスク管理が曖昧になります。

Cookieとセッション管理の違い

Cookieとセッションは混同されがちですが、役割は異なります。セッションはサーバー側でユーザー状態を管理する仕組みです。Cookieは、そのセッションに紐づく識別子をブラウザからサーバーへ送るために使われることが多い手段です。

実務では、サーバー側でセッションを管理し、CookieにはセッションIDだけを入れる構成が一般的です。Cookie自体に機微情報を保存しないことで、漏えい時の影響を抑えやすくなります。

Cookieの種類と用途

Cookieは、保存期間、発行元、利用目的によって分類できます。分類を分けておくと、属性設定、同意取得、外部送信、保存期間の管理を設計しやすくなります。

セッションCookieと永続Cookieの違い

• セッションCookie：ExpiresやMax-Ageを指定しないCookie。通常はブラウザのセッション中だけ使われ、ログイン中の状態管理などに使われる。
• 永続Cookie：ExpiresまたはMax-Ageで有効期限を指定したCookie。ブラウザを閉じた後も一定期間残り、表示設定や同意状態の保持などに使われる。

永続Cookieは便利ですが、盗まれた場合の影響期間も長くなります。設定保持用Cookieと認証維持用Cookieでは、保存期間と失効条件を分けます。認証に関係するCookieでは、短い有効期限、再認証、セッションIDの再発行、サーバー側の失効処理を組み合わせます。

ファーストパーティCookieとサードパーティCookieの違い

• ファーストパーティCookie：ユーザーが訪問しているサイトのドメインが設定するCookie。ログイン維持、カート保持、サイト内分析などに使われる。
• サードパーティCookie：訪問中のサイトとは異なるドメインが設定または利用するCookie。広告配信、外部タグ、複数サイトをまたぐ計測などに使われてきた。

サードパーティCookieは、プライバシーと広告計測の両面で扱いが変化してきました。Chromeでは、2025年4月時点でサードパーティCookieを一律に廃止する方式ではなく、ユーザーがChromeのプライバシー設定で選択する方式を維持する方針が示されています。一方、ブラウザや地域によって制限や要件は異なるため、広告・分析用途では、Cookieだけに依存しない計測設計を検討します。

Cookieを使ったパーソナライズの例

Cookieは、ユーザーの設定や直近の行動に応じて表示を変えるために使われます。

• 言語・地域設定：初回選択を保持し、次回以降の操作を減らす
• UI設定：ダークモード、表示密度、絞り込み条件などを保持する
• 同意状態：Cookie同意の選択内容を保存し、毎回同じ確認を出さないようにする
• 軽量なレコメンド：最近見たカテゴリや商品を短期間だけ保持する

パーソナライズでは、保存する値を必要最小限にします。ユーザー体験の改善に不要な識別子や属性情報を増やすほど、説明責任と管理負荷が増えます。

Cookieを使ったトラッキングの仕組み

Cookieは、アクセス解析や広告計測にも使われます。典型的には、次の流れで行動をつなげます。

1. ブラウザに識別子を保存する
2. アクセスのたびに識別子を送信する
3. 同じ識別子に紐づく閲覧、クリック、CVなどを集計する
4. 分析結果をサイト改善、広告評価、A/Bテストに使う

同じサイト内の分析であれば、ファーストパーティCookieで成立しやすい場合があります。複数サイトをまたぐ計測や広告配信では、サードパーティ、外部タグ、広告プラットフォームへのデータ送信が関係しやすくなります。

Cookieの利用目的は、必須、機能性、分析、広告などに分けます。必須Cookieはログインやカートなどサービス提供に必要なものです。分析や広告に使うCookieは、地域、法令、送信先、取得するデータ、個人との結びつき方によって、説明、同意、オプトアウトなどの要件が変わります。

Cookieのセキュリティとプライバシー

Cookieは状態管理に必要な技術ですが、攻撃者に狙われやすい要素でもあります。セキュリティ設定、サーバー側検証、保存内容の最小化、法令対応を分けて設計します。

Cookieに関連するセキュリティリスク

• クロスサイトスクリプティング：悪意あるスクリプトを実行され、JavaScriptから参照可能なCookieが盗まれる場合がある
• クロスサイトリクエストフォージェリ：ブラウザがCookieを自動送信する性質を悪用し、本人の意図しない操作を実行させる攻撃
• セッションハイジャック：セッションIDが漏えいし、ログイン状態を奪われる状態
• 過剰な保存：Cookieに機微情報や過度な識別情報を入れ、漏えい時の影響を大きくする設計
• 改ざん：クライアント側に保存された値を信用し、サーバー側で検証しない設計

Cookieそのものが危険なのではありません。何を保存し、どの属性で送信し、サーバー側でどう検証し、いつ失効させるかが安全性を左右します。

Cookieの安全な使い方

1. HTTPSを前提にする：認証や個人に関係するCookieを扱うページでは、平文HTTPを残さない。
2. Secure属性を付ける：CookieをHTTPS通信時だけ送信させる。
3. HttpOnly属性を付ける：JavaScriptから参照する必要がないCookieにはHttpOnlyを付け、XSS時の窃取リスクを下げる。
4. SameSite属性を設計する：クロスサイト送信の要件を確認し、CSRF対策と外部遷移時の動作を両立させる。
5. 有効期限を短くする：認証用途では、長期間残るCookieを避け、再認証やサーバー側失効を組み合わせる。
6. サーバー側で検証する：Cookieの値は改ざんされ得る前提で、署名検証、セッション照合、権限確認を行う。
7. 機微情報を入れない：パスワード、秘密鍵、不要な個人識別情報をCookieへ保存しない。

特にセッションIDを扱うCookieでは、Secure、HttpOnly、SameSite、有効期限、セッションIDの再発行、ログアウト時の失効を組み合わせます。属性設定だけではなく、サーバー側のセッション管理まで含めて設計します。

Cookieに関連するプライバシー規制と対応

Cookieの規制対応は、国や地域、サイトの提供先、Cookieの目的、外部送信の有無、個人との結びつき方によって変わります。すべてのCookieで同じ同意方式を取れば足りる、という整理は危険です。

日本では、Cookie等の端末識別子は、個人情報に該当しない場合でも、通常は個人関連情報に該当し得ます。また、提供先で個人データとして取得されることが想定される個人関連情報を第三者提供する場合、本人同意が得られていること等の確認が論点になります。

さらに、Webサイトやアプリで外部タグを使い、利用者に関する情報を外部へ送信する場合は、電気通信事業法の外部送信規律も確認対象になります。対象となるサービスでは、送信される情報の内容、送信先、利用目的などを、利用者が確認できるようにする対応が必要になります。

運用側は、Cookieを次の観点で棚卸しします。

• 利用目的：必須、機能性、分析、広告、A/Bテストなど
• 発行元：ファーストパーティか、外部事業者か
• 送信先：自社サーバーか、外部事業者か
• 保存期間：セッションCookieか、永続Cookieか
• 個人との関係：単独で個人識別できるか、他の情報と照合されるか
• ユーザー選択：同意、拒否、撤回、オプトアウトの導線があるか

ユーザーがCookieを管理する方法

ユーザーは、ブラウザ側でCookieを削除、制限、ブロックできます。サイト側は、ユーザーがCookieを拒否または削除した場合に、どの機能へ影響するかを説明できるようにします。

ブラウザ設定では、一般に次の操作ができます。

1. 保存済みCookieやサイトデータを削除する
2. サイトごとにCookieを許可またはブロックする
3. サードパーティCookieを制限する
4. 閲覧終了時にCookieを削除する設定を選ぶ

企業サイトでは、Cookieポリシーや同意管理画面で、拒否しても閲覧できる範囲、ログインやカートなどに必要なCookie、分析や広告に使うCookieを分けて説明します。

企業におけるCookieの活用方法

企業サイトでは、CookieをUX改善、ログイン維持、サイト分析、広告計測、A/Bテストなどに使います。目的が増えるほど、技術管理、外部タグ管理、同意管理、法務確認の負担も増えます。

Cookieを使ったWebサイト最適化

• 表示設定の保持：言語、地域、UI設定、同意状態などを必要最小限で保存する
• フォーム入力の補助：途中離脱時の復帰や入力補助に使う
• ログイン体験の改善：セッション設計と期限設計により、利便性と安全性を両立させる
• サイト改善：ページ閲覧、クリック、CVなどを集計し、改善箇所を特定する

最適化では、必須機能と任意機能を分けます。ログインやカートに必要なCookieと、分析・広告のためのCookieを同じ扱いにしないことで、ユーザー説明と同意管理が明確になります。

Cookieを使ったマーケティング施策

• コンバージョン計測：広告クリック後の成果を計測し、施策の費用対効果を評価する
• サイト分析：離脱率、閲覧経路、導線を把握し、改善仮説を作る
• 広告最適化：リターゲティングや類似配信を行う場合、外部事業者とのデータ連携も整理する

広告・外部タグ領域では、ブラウザ制限、外部送信規律、個人関連情報、海外規制の影響を受けやすくなります。企業は、タグを追加する前に、送信先、送信項目、利用目的、契約、同意管理の要否を確認します。

Cookieを使ったA/Bテスト

A/Bテストでは、同じユーザーに同じパターンを継続して表示するためにCookieを使う場合があります。基本の流れは次のとおりです。

1. 比較する要素を決める：コピー、導線、フォーム、UIなど
2. ユーザーをランダムに振り分ける：Cookieで割り当てを保持する
3. 指標を計測する：CVR、CTR、滞在時間、離脱率など
4. 結果を評価する：統計的な差と業務上の影響を確認し、採用・再検証を判断する

A/Bテスト用のCookieは、目的をA/Bテストに限定し、保存期間を必要な範囲に抑えます。個人を直接特定する値を入れず、分析や広告用途へ転用する場合は別途説明と同意管理を確認します。

Cookieに関する社内ポリシーの策定と管理

企業でCookieを扱う場合、技術設定だけでなく社内ルールが必要です。ポリシーには、少なくとも次の内容を含めます。

• Cookieの分類：必須、機能性、分析、広告、A/Bテストなど
• 利用目的：何のために使い、どの機能へ影響するか
• 保存する値：識別子、設定値、同意状態などの範囲
• 外部送信：送信先、送信項目、送信先での利用目的
• 同意・拒否・撤回：ユーザーが選択できる導線
• セキュリティ基準：Secure、HttpOnly、SameSite、期限、レビュー手順
• 変更管理：新しいタグやCookieを誰が申請し、誰が承認し、誰が棚卸しするか

Cookie運用で問題になりやすいのは、マーケティング部門が外部タグを追加し、開発部門や法務・コンプライアンス部門が後から把握する状態です。タグ追加の申請、レビュー、公開後の棚卸しをワークフロー化しておくと、説明漏れや不要なCookieの残存を防ぎやすくなります。

Cookieの導入・見直しに適しているケース

Cookie利用に適しているケース

Cookieは、次のような用途に適しています。

• ログイン状態やセッションIDを管理する
• 表示言語、テーマ、同意状態など、ユーザー設定を保存する
• ECサイトでカートや最近見た商品を保持する
• 同一サイト内の利用状況を分析し、導線改善に使う
• A/Bテストの割り当てを一定期間維持する

これらの用途でも、保存する値、保存期間、属性設定、同意・通知の要否を用途ごとに分けます。

慎重に扱うべきケース

次の用途では、Cookieの設計を慎重に行います。

• 認証状態を長期間維持するCookie
• 外部事業者へ送信される広告・分析Cookie
• 複数サイトを横断して行動をつなげるCookie
• 個人情報や機微情報と容易に紐づく識別子
• ユーザーが拒否・撤回しにくい同意設計

このような用途では、セキュリティレビュー、法務・コンプライアンス確認、同意管理、外部タグ棚卸しを先に行います。

まとめ

Cookieは、Webサイトの状態管理を支える基本技術です。ログイン維持、設定保存、カート管理、分析、A/Bテストなどに使われ、ユーザー体験とサイト改善の両方に関わります。

一方で、Cookieは自動送信される性質を持つため、セッションハイジャック、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ、過剰な追跡といったリスクにも関係します。Secure、HttpOnly、SameSite、有効期限、サーバー側検証、セッション失効を組み合わせて設計します。

企業がCookieを運用する際は、目的別の棚卸しが出発点です。必須、機能性、分析、広告、A/Bテストに分類し、保存する値、送信先、保存期間、同意・通知、外部タグ管理を確認します。Cookieは小さなデータですが、利便性、セキュリティ、プライバシー、法令対応をつなぐ重要な設計対象です。

Cookieに関するよくある質問（FAQ）