Cookie とは？ブラウザ Cookie の解説

TL;DR：Cookie とは、ウェブサイトがあなたのブラウザに保存する小さなデータ（通常は数百バイト）で、リクエストをまたいで情報を記憶するためのものです。Cookie はログイン、買い物カゴ、分析を支え、同時に、ブラウザが今まさに収束させつつあるクロスサイト追跡の時代も生み出しました。

Cookie とは、ウェブサイトが Set-Cookie HTTP レスポンスヘッダーであなたのブラウザに設定する name-value のテキスト記録で、ブラウザは同じドメインへのその後のリクエストに Cookie リクエストヘッダーでそれを自動的に付加します。Cookie は本来ステートレスな HTTP ウェブにおける状態の最初の仕組みです——localStorage、IndexedDB、service worker、その他あらゆる現代のクライアントストレージより前から存在します。あなたが出会ったすべての Cookie は、「ログインを保持」から EU の同意バナーまで、この 1 つの小さなプロトコルに支配されています1。

要点：Cookie は HTTP の上に乗る薄い層です。サーバーが Set-Cookie: name=value レスポンスヘッダーで設定し、ブラウザがドメイン単位の Cookie 入れに保存し、その後の一致するリクエストごとにブラウザが Cookie: name=value を送り返します。クライアント側のハンドシェイクはありません——ブラウザは RFC 6265 の制約内でサーバーの指示に従います。

Cookie の仕組みは、1994 年に電子商取引クライアント MCI Net のために「ページ間で買い物カゴを記憶する」問題を解決するために導入した Netscape のエンジニア Lou Montulli に広く帰せられます2。30 年後、基盤プロトコルはほぼ変わっていません。正式仕様は IETF RFC 62651で、セキュリティとプライバシーの境界を厳しくする改訂が IETF ドラフト3で進行中です。

最小限の Cookie のやり取りはこうなります:

# サーバーのレスポンス
HTTP/1.1 200 OK
Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

# クライアントの同一サイトへのその後のリクエスト
GET /account HTTP/1.1
Cookie: sid=abc123

ブラウザは値 abc123 を解釈しません——ブラウザにとっては不透明です。解釈するのはサーバー（通常はデータベースのセッションキーとして）です。ブラウザの仕事は、Cookie の Domain、Path、Secure、SameSite、有効期限の属性に基づいて、各リクエストにどの Cookie を付けるかを決めることです。

要点：Cookie はサーバーが設定し、ブラウザが保存し、その後の一致するリクエストごとにサーバーが読みます。ブラウザは運び手であって、作者ではありません。

要点：Cookie には必須の部分（name=value）が 1 つと、サーバーが設定できる 7 つの属性があります:Domain、Path、Expires、Max-Age、Secure、HttpOnly、SameSite。各属性は、ブラウザがいつ Cookie を送り返すかを狭めたり制限したりします。

RFC 62651 とその bis 改訂3 が定義する完全な属性セット:

  • Name と Value —— 唯一の必須ペア。ASCII テキスト。合計でおよそ 4 KB に収める必要があります4。
  • Domain —— 既定は Set-Cookie を送ったホスト。Domain=example.com と設定すると、Cookie は example.com とそのすべてのサブドメインに適用されます。
  • Path —— 既定はリクエストパスのディレクトリ。Path=/account は Cookie を /account 配下の URL に限定します。
  • Expires / Max-Age —— 日付または期間。両方を省略すると Cookie はセッション Cookie になります（ブラウザのセッション終了時に削除）。Max-Age=0 は Cookie を即座に削除します。
  • Secure —— 設定すると、ブラウザは HTTPS でのみ Cookie を送ります。平文 HTTP のリクエストには見えません。
  • HttpOnly —— 設定すると、ページ内の JavaScript は document.cookie 経由で Cookie にアクセスできません。XSS によるセッション Cookie 窃取への主要防御です。
  • SameSite —— Strict / Lax / None。クロスサイトリクエストの挙動を支配します（後述）。
  • Priority（Chrome 固有の拡張）—— Low / Medium / High。ドメイン単位の Cookie 入れが満杯のとき、どの Cookie を先に退避するかをブラウザに示唆します。

要点：Cookie は 2 つの直交する軸で分類されます——ライフタイム（セッション vs 永続）と出所（ファーストパーティ vs サードパーティ）。1 つの Cookie は各軸で常に 1 つの値を持ちます。プライバシー規制とブラウザ設定は、その上に用途ベースの分類（厳密に必要 / 機能 / 分析 / 広告）を重ね、これが同意バナーで目にするものです。

ユーザーと規制当局が話す 6 つの一般的なカテゴリを、基盤プロトコルに対応づけます:

カテゴリライフタイム出所典型的な用途ブラウザ既定ポリシー（2026）
セッション Cookieセッションファーストパーティログインセッション、現在のカゴ既定で許可
永続ファーストパーティ永続ファーストパーティ「ログイン保持」、言語設定既定で許可
厳密に必要どちらもファーストパーティ認証、不正防止同意不要（GDPR）
機能 / 設定永続ファーストパーティUI テーマ、フォントサイズ同意推奨（GDPR）
ファーストパーティ分析永続ファーストパーティファーストパーティ分析EU では同意必須
サードパーティ広告永続サードパーティ広告ターゲティング、再ターゲ、クロスサイト IDSafari / Firefox はブロック;Chrome は制限5

英国情報コミッショナー事務局（ICO）はこの区別をこう簡潔にまとめています6:

厳密に必要な Cookie とは、ユーザーが要求したオンラインサービスを提供するために不可欠なものです。それ以外のほとんどの Cookie は、設定前に十分な情報に基づく同意を必要とします。

要点：プロトコルレベルでは Cookie は汎用の name-value ストレージです。実際には、ウェブは Cookie を 6 つの異なる仕事に使います。ユーザー体験への重要度がおおむね高い順に並べます。

現代のウェブにおける Cookie の 6 大用途:

  1. 認証とセッション管理 —— リクエストがどのログインユーザーのものかをサーバーに伝えるセッション ID Cookie。ほぼ常に HttpOnly、Secure、SameSite=Lax か Strict。
  2. CSRF 防止トークン —— 状態を変えるリクエストでサーバーが検証するランダムな偽造防止値。通常は隠しフォームフィールドと対。
  3. 買い物カゴと未完了の作業 —— ページ読み込みをまたいでカゴの中身やフォームの下書きを保持。多くはサーバー側の状態を指す 1 つの ID。
  4. ユーザー設定 —— 言語、テーマ、レイアウト密度、アクセシビリティ設定。Max-Age が数か月〜数年の小さな永続 Cookie。
  5. ファーストパーティ分析 —— Plausible、Fathom、自己ホストの PostHog（Cookie ベースで設定した場合）などのための訪問者識別とセッション計測。日本でも、第三者追跡を避けるため第一者分析を自己ホストするチームが増えています。
  6. 広告とクロスサイト追跡 —— 複数サイトで同一ユーザーを識別する必要がある広告ネットワーク、再ターゲ業者、分析プラットフォームが設定するサードパーティ Cookie。ブラウザが今まさに収束させているカテゴリ。

開発者にとっての実務的な含意は、設定する Cookie のほとんどはファーストパーティで、現在のサイトに限定し、HttpOnly と Secure を付け、None が必要な特定のクロスサイトフローがない限り SameSite=Lax を与えるべき、ということです。

SameSite、HttpOnly、Secure —— 3 つのセキュリティ属性

要点：3 つの Cookie 属性——SameSite、HttpOnly、Secure——はそれぞれ異なる種類の攻撃を防ぎます。この 3 つを正しく設定することが、サーバーができる単一で最もレバレッジの高い Cookie セキュリティ改善です。

この 3 属性は現代の Cookie セキュリティの基準線を成します。各々が特定の攻撃クラスを防ぎます:

  • Secure は受動的なネットワーク盗聴を防ぎます。ブラウザは平文 HTTP では Cookie を送りません。セッション状態を持つ Cookie には必須です。さもないと開放 Wi-Fi 上でのセッション窃取が容易だからです。
  • HttpOnly は XSS によるセッション窃取を防ぎます。クロスサイトスクリプティングの脆弱性経由でページに注入された JavaScript は、document.cookie 経由で HttpOnly Cookie を読めません。サーバーには見えますが、攻撃者のスクリプトには見えません。
  • SameSite は CSRF とクロスサイト追跡を防ぎます。3 つの値:
    • SameSite=Strict —— Cookie は同一サイトのリクエストでのみ送られます。最大の防御;時に不便（別サイトからあなたのドメインへ進んだユーザーは最初のリクエストで未ログインに見える）。
    • SameSite=Lax —— Cookie は同一サイトのリクエストに加え、トップレベルのクロスサイト GET ナビゲーション（リンククリック）で送られます。Chrome では 2020 年以降の現代の既定値7。
    • SameSite=None —— Cookie はあらゆるクロスサイトリクエストで送られます。正当なサードパーティ Cookie（シングルサインオン、埋め込み決済ウィジェット）に必要。Secure と対で使う必要があります。

Google の web.dev ガイドは優先順位について明確です7:「今日 1 つだけやるなら、すべてのセッション Cookie に SameSite=Lax を設定せよ。」

要点：ファーストパーティ Cookie はアドレスバーのサイトが設定;サードパーティ Cookie はそのサイト上でコードが動く別ドメインが設定します。サードパーティ Cookie は現代の広告追跡経済を築き、現代のブラウザはそれを体系的に制限または排除しています。

サードパーティ Cookie の収束は、プロトコル誕生以来 Cookie エコシステムに対する最も影響の大きな変化です。2026 年半ば時点のブラウザ別の状況:

  • Safari —— Safari 11（2017）の Intelligent Tracking Prevention（ITP）以降、サードパーティ Cookie を既定でブロックし、段階的に強化。
  • Firefox —— 2022 年以降、Total Cookie Protection（TCP）の下でサードパーティ Cookie を既定で分割し、クロスサイト追跡を事実上排除。
  • Chrome —— サードパーティ Cookie 全廃を複数回延期した後5、ユーザー選択方式へ落ち着き、広告ターゲティング・アトリビューション・不正防止の代替として Privacy Sandbox API を提案。

正当なクロスサイト用途（フェデレーションログイン、埋め込み決済 iframe）には、現代の代替が CHIPS —— Cookies Having Independent Partitioned State8 です。Partitioned 属性を持つ Cookie はトップレベルサイトごとに別の入れに保存されるため、2 つの異なる親サイトの下で読み込まれた同じ iframe は同じ Cookie を読めません。CHIPS は「このウィジェット内で設定を記憶する」正当な用途を保ちつつ、クロスサイト識別子の流れを断ち切ります。

今日サードパーティ Cookie に依存するサービスを運用しているなら、当面の作業は Cookie の棚卸しです:どれがクロスサイトの可視性を必要とするか（CHIPS を使う）、どれが設計上の追跡だったか（Privacy Sandbox かファーストパーティデータで作り直す）。

要点：現代のどのブラウザも設定かデベロッパーツールで Cookie を表示できます。繰り返すワークフロー——セッションのバグのデバッグ、Cookie をテストフィクスチャとしてエクスポート、サイトが何を保存したかの監査——には CookieVault Editor のような Manifest V3 拡張機能が標準ツールです。下の 8 ステップの検査フローはどの Chromium 系ブラウザでも使えます。

Chrome で Cookie を表示・編集する 8 ステップのクイックリファレンス（Edge、Brave、Opera、Vivaldi、Arc も同一;Firefox はメニュー配置が異なるが類似）:

  1. 対象サイトをタブで開く。
  2. F12 を押してデベロッパーツールを開く。
  3. Application タブをクリック。
  4. 左サイドバーの Storage 下で Cookies をクリック。
  5. ドメインをクリックして範囲内のすべての Cookie を表示。
  6. セル（Value、Expires、SameSite など）をダブルクリックしてその場で編集。
  7. Enter で確定;ブラウザは即座に適用。
  8. ページを再読み込みすると、次のリクエストで変更後の Cookie が送られる。

Cookie の一括削除は Chrome の Cookie 削除ガイド が 3 つの方法を扱います。ログインを保ちつつ追跡を消すには Cookie を消してもログイン状態を保つ を参照。多数のサイトでワンクリックの繰り返し編集には、当社が維持するオープンソース Manifest V3 ツール CookieVault Editor があります。

ネットで見かけるかもしれない、事実でない言説の簡単な整理:

  • 「Cookie はウイルス」 —— 誤り。Cookie は受動的なテキスト記録で、ソフトのインストール、コードの実行、ブラウザの Cookie ストア外のファイルへのアクセスはできません。
  • 「Cookie はパスワードを保存する」 —— ほぼ常に誤り。ログイン Cookie が持つのはセッション ID であってパスワードではありません。パスワードは一度サーバーに送られてハッシュ化され、サーバーがセッション ID Cookie を返します。パスワード自体は Cookie にありません。
  • 「Cookie を無効にすれば匿名になれる」 —— 誤り。ブラウザは Cookie に依存しない多くの経路（User-Agent、画面解像度、フォント、WebGL ハッシュ、IP アドレス）で指紋採取されます。
  • 「すべての Cookie がサイトをまたいで追跡する」 —— 誤り。訪れているサイトが設定するファーストパーティ Cookie は他のサイトであなたを見ません。クロスサイト追跡は特にサードパーティ Cookie の問題です。
  • 「Cookie は GDPR の下で違法」 —— 誤り。Cookie は合法です。GDPR（および ePrivacy 指令）が規制するのは、非必須 Cookie の同意要件です。厳密に必要な Cookie は同意を要しません。
  • 「Cookie を消せばあらゆるブラウザ問題が直る」 —— 部分的に正しい。Cookie を消すとセッションと設定の状態はリセットされますが、キャッシュされたリソース、service worker のバグ、拡張機能の競合は直りません。

関連項目

Footnotes

  1. 現行の IETF 仕様は RFC 6265 ——「HTTP State Management Mechanism」、https://datatracker.ietf.org/doc/html/rfc6265 で入手可能。この文書は Set-Cookie と Cookie ヘッダー、Cookie 属性の意味、ストレージモデル、Cookie の一致規則を定義します。 ↩ ↩2 ↩3

  2. Mozilla Developer Network の HTTP cookies リファレンス https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies は現代の Cookie 属性セットとブラウザ側の処理規則をまとめています。1994 年の起源の話はウェブ史の各所で広く引用され、Netscape での Lou Montulli の「買い物カゴ」機能の仕事に遡ります。 ↩

  3. Cookie 仕様の進行中の改訂版は「RFC 6265bis」——正式名 draft-ietf-httpbis-rfc6265bis、IETF HTTP ワーキンググループにて https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ で公開。プレフィックス規則（__Host-、__Secure-）を厳格化し、SameSite を正式化し、分割の意味を精緻化します。 ↩ ↩2

  4. Cookie あたり 4 KB、ドメインあたり 50 個という数字は RFC 6265 §6.1 の推奨です。実際のブラウザ制限は推奨下限のおよそ 2 倍ですがブラウザによって異なります;Chrome チームの chrome.cookies API リファレンス https://developer.chrome.com/docs/extensions/reference/api/cookies が Chrome の実際の制限を記載しています。 ↩

  5. Chrome のサードパーティ Cookie の立場は何度も変わっています。現在の方針は Privacy Sandbox https://developer.chrome.com/docs/privacy-sandbox/ に記載。そのルート配下のステータスページと各 API ドキュメントが進行中の変更を追っています。 ↩ ↩2

  6. 英国情報コミッショナー事務局（ICO）は、プライバシー・電子通信規則（PECR）の下で Cookie と同意に関する実務指針を公開しています。ICO はこの指針ページを何度か再構成しており URL は不安定です;「ICO PECR cookies guidance」で検索するか、https://ico.org.uk から「For organisations → Online tracking」へ進んでください。上の表の注釈で言い換えた「厳密に必要」の定義は ICO の表現に従います。 ↩

  7. Google の web.dev 入門「SameSite cookies explained」https://web.dev/articles/samesite-cookies-explained は、SameSite の既定値と Chrome の展開履歴に関する実務者向けの定番リファレンスです。 ↩ ↩2

  8. CHIPS 仕様——「Cookies Having Independent Partitioned State」——は https://developer.chrome.com/docs/privacy-sandbox/chips に記載。CHIPS はクロスサイト Cookie をトップレベルサイト単位の分割に入れ、クロスサイト追跡を可能にせずにサードパーティ Cookie ブロックの下でも存続させます。 ↩

最終更新:

著者: Lena Park · レビュー: Marcus Reiter