Cookie、ローカルストレージ、キャッシュ、ブラウザーフィンガープリントの解説

これらの概念は、プライバシー設定、デバッグ手順、ブラウザープロファイル製品でよく一緒に現れます。しかし動作が十分に異なるため、「ブラウザーを消去する」という指示だけでは不完全です。

実用的な考え方

仕組み	作成または管理する主体	通常の適用範囲	一般的な目的	リクエストとともに自動送信されるか
HTTP Cookie	サーバーが設定し、ブラウザーが適用範囲の規則に従って保存・返送	ホストまたはドメイン、パス、存続期間、接続条件	セッション識別子、設定、不正利用対策の状態	はい。リクエストが適用範囲に一致する場合
localStorage	サイトのJavaScript	オリジン。ブラウザーのパーティショニングとポリシーの影響を受ける	永続的なキー・値形式のアプリケーション状態	いいえ
sessionStorage	サイトのJavaScript	トップレベルの一つの閲覧セッション内のオリジン	一時的なタブまたは業務状態	いいえ
HTTPキャッシュ	ブラウザーとHTTPキャッシュ規則	キャッシュキー、応答指示、ブラウザーポリシー	応答を再利用し、遅延と通信量を減らす	リクエストをキャッシュで満たすか、再検証する場合がある
Cache Storage API	サイトまたはService WorkerのJavaScript	オリジンまたはストレージパーティション	オフラインリソースとアプリケーション管理の応答	自動添付なし。スクリプトが利用を管理
ブラウザーフィンガープリント	サイトまたは別の観察者が信号を測定	観察者と信号によって異なる	セキュリティ、不正検知、アクセス解析、追跡	一部の信号はリクエストで見え、その他は能動的コードが必要

最初の五行は保持される状態を扱います。最後の行は観察と相関の方法ですが、保持された状態もその入力の一つになり得ます。

Cookie：適用範囲の規則を持つサーバー向け状態

HTTPは基本的に状態を持ちません。Cookieにより、サーバーはブラウザーへ名前と値の組を渡し、後の一致するリクエストで受け取れます。RFC 6265は、Set-Cookie応答ヘッダー、Cookieリクエストヘッダー、ブラウザーの保存モデルを定義しています。

Cookieには次のような種類があります。

• セッション単位： ブラウザーが定義するセッションの終了まで保持。
• 永続： 有効期限または最大存続期間を持つ。
• ホスト限定： 設定したホストにのみ返送。
• ドメイン単位： 指定ドメインと一致するサブドメインへ送信可能。
• パス単位： 一致するリクエストパスにのみ返送。
• Secure： ブラウザーが定義する安全なチャネルでのみ返送。
• HttpOnly： HTTPリクエストには利用できるが、スクリプト向けCookie APIからは非表示。

これらの属性は送信とスクリプトアクセスに影響します。しかし、Cookieの値を独立したセキュリティ境界へ変えるものではありません。RFC 6265は、特にPath属性をセキュリティのために依存すべきでないと警告し、機密性の高いCookie内容には安全な通信と追加の保護を推奨しています。

Cookieを削除するとサインアウトする理由

多くのサービスは、Cookieにランダムなセッション識別子を保存し、アカウント記録とセッション詳細をサーバー側に保持します。そのCookieを削除するとブラウザー側の識別子が消えるため、次のリクエストでは同じセッションを提示しなくなります。サーバー側のアカウントと他のセッションは残る場合があります。

これは認証Cookieのコピーが機密性を持つ理由でもあります。利用可能なセッション識別子は認証情報と同様に機能します。生のCookieをチケット、ログ、自動化出力、チームチャットへ貼り付けないでください。

ローカルストレージ：一つのオリジン向けのスクリプト管理状態

HTML Standardは、localStorageをオリジンのローカルストレージ領域へアクセスする仕組みと定義しています。複数のウィンドウにまたがり、現在のセッションより長く存続することを意図しています。文字列のキー・値の組を保存し、そのオリジンの権限で動くスクリプトから利用できます。

通常、オリジンはスキーム、ホスト、ポートの組み合わせです。したがって、次の各URLは異なるストレージ範囲です。

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

URLのパスはオリジンの一部ではありません。同じオリジンにある/billing/と/support/のページは、アプリケーションが独自の論理分離を作らない限り、同じローカルストレージ領域へアクセスできます。

Cookieと異なり、localStorageの項目はHTTPリクエストへ自動添付されません。サイトのスクリプトが読み、何をするか判断します。そのため、インターフェース設定、草稿状態、アプリケーションデータに適しますが、そのオリジンの権限で実行するどのスクリプトからもアクセスできる場合があります。機密性の高いセッション設計では、「ローカル」は秘密であるという意味だと想定せず、スクリプト侵害を考慮してください。

ここでの永続性は、データが閲覧セッションを越えて残れるという意味です。永久保持ではありません。利用者は消去でき、ブラウザーポリシーが制限でき、ブラウザーがストレージおよび退避規則を適用できます。

sessionStorageは存続期間が異なる

sessionStorageは、オリジンとトップレベルの閲覧セッションに関連づけられます。タブまたはウィンドウで業務が続く間だけ保持し、そのセッションとともに終了すべき状態に適します。複製または復元されたタブにはブラウザー固有のライフサイクル詳細があり得るため、アプリケーションは重要業務の唯一の記録として使うべきではありません。

ローカルストレージはサイトデータの一種類にすぎない

現代のWebアプリケーションは、IndexedDB、Cache Storage、Service Worker登録、Origin Private File System、権限、その他のブラウザー管理ストアにもデータを保持できます。開発者ツールでlocalStorageだけを消しても、別の状態は残ります。

HTML Standardのプライバシー指針は、あるストアを使って別のストアから削除した識別子を再作成できないよう、永続ストレージの仕組みをまとめて消去できるようにすることをブラウザーへ推奨しています。

キャッシュ：複数の仕組みを指す一語

HTTPキャッシュ

RFC 9111は、HTTPキャッシュを、応答メッセージの保存場所と、その保存、取得、削除を管理するシステムとして定義しています。ブラウザーキャッシュは、新しい応答を再利用したり、古い応答を再検証したりして、遅延とネットワーク転送量を減らします。

キャッシュキーには少なくともリクエストメソッドと対象URIが含まれ、応答ヘッダーが、応答を再利用できるか、どのくらいの期間再利用できるかに影響します。HTTPキャッシュは最適化層です。画像やスクリプトがキャッシュされていても、通常は利用者がサインインしているという意味ではありません。

それでも、キャッシュ状態がプライバシーへ影響する場合があります。脅威モデルによっては、処理時間やリソースがすでに利用可能かどうかから情報を推測できます。W3Cのフィンガープリンティング指針も、キャッシュ済みリソースの観察を、ブラウザーまたは利用者の構成を推測する方法の一つに含めています。

Cache StorageとService Worker

Cache Storage APIは、サイトに明示的でスクリプト管理のCacheオブジェクトを提供し、オフラインWebアプリケーションによく使われます。Service Workers仕様では、これらのキャッシュはブラウザーのHTTPキャッシュとは別で、オリジンごとに分離され、通常のHTTP鮮度規則ではなくアプリケーションロジックで更新または削除されると説明しています。

この違いはデバッグ時に重要です。

• 「キャッシュされた画像とファイル」の消去は、ブラウザーの通常キャッシュを対象にします。
• サイトデータを消去すると、Cache StorageとService Workerの状態も削除できる場合があります。
• HTTPキャッシュを迂回して再読み込みしても、稼働中のService Workerがリクエストを制御している場合があります。

調査または消去方法を決める前に、どのキャッシュを指すか明確にしてください。

ストレージパーティショニングは別のキーを加える

以前のオリジン範囲では、埋め込まれた第三者が多くのトップレベルサイト内で同じストレージを読めました。現代のブラウザーは、トップレベルサイトまたは関連コンテキストをストレージキーに加えるようになっています。

Chromeは、ストレージパーティショニングによって、example.comのフレームがa.com内に埋め込まれたときに、b.com内に埋め込まれた同じフレームとLocal Storage、IndexedDB、Cache Storage、Service Worker、特定の通信機構を自動共有しないようにすると説明しています。Chromeによると、これはChrome 115以降すべての利用者に有効で、後に一部の追加APIにも変更が加わっています。

パーティショニングは、同じ埋め込みオリジンが、周囲のサイトによって異なるストレージを見るという意外な結果を説明します。ただし、あらゆる場所のストレージが一つの普遍的な二重キーを持つという意味ではありません。ブラウザーバージョン、トップレベルと埋め込みのコンテキスト、ストレージアクセス許可、企業ポリシー、拡張機能、API固有規則で結果が変わります。

ドメイン名だけから推測せず、正確なコンテキストをテストしてください。

ブラウザーフィンガープリント：フォルダーではなく観察される信号

W3Cはブラウザーフィンガープリンティングを、構成設定などの観察可能な特性によって、利用者、ユーザーエージェント、端末を識別または再識別できることと定義しています。2025年のガイダンスは複数の方式を区別しています。

• 受動的フィンガープリンティングは、リクエストヘッダーやIPアドレスなど、リクエストまたはネットワークですでに観察可能な情報を使います。
• 能動的フィンガープリンティングはコードを実行し、ウィンドウサイズ、フォント、接続機器、性能、センサー、グラフィック描画などを観察します。
• 一時的事象の相関は、ほぼ同時に起きる端末または環境の変化を通じてコンテキストを結びつけます。
• Cookieに似た手法は、通常のCookieより長く残る、またはCookieを再作成できる仕組みで状態を保存・取得します。

フィンガープリントは、ブラウザーが保存する一つの不変値であることはほとんどありません。観察者が信号を選び、組み合わせ、以前の訪問とどの程度一致するかを判断します。ブラウザー更新、ウィンドウ変更、フォント追加、機器接続、ネットワーク経路の移動で結果は変わり得ます。多くの基礎信号が変わらなければ、Cookieを消した後も似たままになることがあります。

フィンガープリントはIDの証明ではない

一組の信号が多数の利用者に共通する場合も、一人の利用者について変動する場合もあります。サイトはフィンガープリントをログイン、サーバー側のアカウント履歴、ネットワーク評価、保存済み識別子と組み合わせることもできます。したがって、データ消去後に認識されたからといって、フィンガープリンティングだけが原因だったとは証明できません。

同じ理由で、一つの目に見える設定を変えても新しいIDは保証されません。一貫した一般的な構成は一部の固有性を減らせますが、多数の珍しい独立した変更は、より希少な組み合わせを作ることがあります。これらの信号から、見えなくなることや第三者による受け入れを保証することはできません。

一般的な消去操作が実際に変えるもの

操作	起こり得る効果	重要な残存物
サイトのCookieを削除	一致するブラウザー保管のCookie状態を削除し、多くの場合そのプロファイルをサインアウト	サーバー側アカウントデータ、他の端末、Cookie以外のストアは残る場合がある
Cookieとその他のサイトデータを削除	ブラウザーUIと範囲によって、Cookie、Web Storage、IndexedDB、Service Worker、関連サイト状態を削除可能	パスワード管理ツール、ダウンロード、アカウント側データ、観察可能な端末信号は別
キャッシュされた画像とファイルを削除	通常のキャッシュ済み応答内容を削除	Cookie、ローカルストレージ、Cache Storageは別の選択が必要な場合がある
履歴を消去	選択範囲の訪問URL記録と関連候補を削除	ダウンロード済みファイルとサイト保有記録は残る
ブラウザープロファイルを削除	その端末からローカルのブックマーク、履歴、パスワード、その他の設定を削除	同期済みアカウントデータ、ダウンロード・エクスポート済みファイル、バックアップ、サーバー側データは残る場合がある
新しいプロファイルを開始	異なるプロファイル状態の集合から開始	端末、OS、ブラウザービルド、ネットワークは関連するものとして引き続き観察可能な場合がある

Chrome自身の閲覧データガイドは、履歴、Cookieとその他のサイトデータ、キャッシュされた画像とファイル、ダウンロード履歴、AutoFill、サイト設定、ホスト型アプリのデータを別々の区分として扱います。また、ダウンロード履歴を削除してもファイル自体はコンピューターに残り、サインイン済みデータの削除がGoogle Accountと他の同期端末に影響する場合があると説明しています。

正確な効果は、選択期間、プロファイル、アカウント状態、ブラウザーバージョン、企業ポリシーによって変わります。復旧しにくいデータを削除する前に、確認文を読んでください。

別々のブラウザープロファイルが各仕組みに与える影響

正しく分離された永続プロファイルは、独自のCookie jar、Web Storage領域、サイトデータベース、Cache Storage、HTTPキャッシュの所有権、履歴、サイト権限、拡張機能状態を持つ必要があります。これにより、プロファイルBがプロファイルAの保存済みセッションをそのまま継承することを防ぎます。

一方、次の信号は共通のままになり得ます。

• ブラウザーエンジンとバージョン。
• OSとハードウェア。
• システムにインストールされたフォントとディスプレイ特性。
• ホストから継承する言語、タイムゾーン、アクセシビリティ設定。
• 別の経路を構成しない場合のIPアドレスとネットワーク経路。
• アプリケーション層で活動を結びつける担当者の行動またはログイン。

拡張機能、権限、ウィンドウサイズ、言語設定、プロキシ経路によって、別のプロファイルが異なる信号を露出する場合もあります。総合的な効果は実装と文脈に依存します。プロファイル分離は状態分離として評価し、フィンガープリントの保証として扱わないでください。

すべてを消去する前に症状を診断する

「サインアウトしていた」

まずCookieを確認します。セッションCookieが期限切れ、削除、ブラウザーポリシーによる拒否、サーバーによる無効化のいずれかかもしれません。ローカルストレージはインターフェースを支えられますが、通常はHTTPリクエストの認証に自動送信されるCookieではありません。

「サイトが草稿またはオフラインデータを忘れた」

ローカルストレージ、IndexedDB、Cache Storage、Service Workerの状態を調べます。パーティショニングによって利用可能なストレージが変わるため、オリジンと、ページがトップレベルか別サイト内に埋め込まれているかを確認してください。

「最初の再読み込みが遅い」

空または古いHTTPキャッシュが原因の可能性があります。ネットワーク、サーバー、Service Workerも同じ症状を起こすため、結論を出す前にリクエスト時間とキャッシュ状態を記録してください。

「データを消してもサイトが環境を認識する」

複数の説明が残ります。別の場所でアカウントにサインインしたまま、サーバーがアカウントまたはネットワークデータで訪問を結びつけた、別のブラウザーストアが残った、観察可能な特性からセッションが相関された、などです。フィンガープリンティングを一つの仮説として扱い、自動的な答えにはしないでください。

判断の要点

仕組みに合わせて対処を選びます。

• サーバーセッションが問題なら、Cookieを調査または消去する。
• Webアプリケーションがローカル状態を保持する場合は、オリジン単位のサイトストアを調べる。
• 古い内容やオフライン内容を診断するときは、HTTPキャッシュとCache Storageを区別する。
• 保存済み業務状態を独立させる必要がある場合は、別の永続プロファイルを使う。
• フィンガープリンティングを観察可能な信号の相関として扱い、データ消去または一設定の変更で消せない限界を理解する。

このモデルは、必要以上の状態を削除することと、空のCookieストアによって新しい端末IDが作られると想定することの、二つの高くつく誤りを避けます。

限界

Webストレージとプライバシーの動作は、ブラウザーやリリースによって変化します。第三者Cookieの規則、ストレージパーティショニング、退避、同期、企業ポリシー、拡張機能、プライベートブラウジングモードが、ここで説明した動作を変える場合があります。このガイドは参照日時点の標準とChrome文書を説明するもので、すべてのブラウザーまたはWebサイト実装を特徴づけるものではありません。