Cookie を消してもログイン状態を保つ

TL;DR：信頼するサイトからログアウトせずに Cookie を消すには、まず Manifest V3 の Cookie マネージャーでそのドメインをホワイトリスト化し、それ以外をすべて削除します。CookieVault Guardian なら 2 クリックの操作です;Chrome 標準ツールでは各サイトを手動で保護する必要があります。

Cookie を消してもログイン状態を保つとは、信頼するドメインのセッション Cookie を残しつつ、追跡や分析の Cookie を削除する選択的削除のワークフローです。標準の「すべての Cookie を消去」は、銀行、メール、プロジェクトツールなど、無差別にすべてのサイトからログアウトさせます。選択的削除は、欲しい Cookie（認証セッション）と欲しくない Cookie（サードパーティトラッカー、分析識別子、広告ネットワークのピクセル）の間に線を引いてこの問題を解きます。Chrome にはこの用途の標準ホワイトリストはありませんが、Manifest V3 拡張機能がこの隙間を埋めます¹。

なぜ選択的削除が重要か

要点：平均的な閲覧セッションでは、数十ものサードパーティドメインから Cookie が蓄積されます。全部消せばログインが消え、何も消さなければトラッカーが残ります。選択的削除はその中道です —— トラッカーを消し、セッションを残す。

8 万以上のウェブサイトを分析したアイオワ大学と UC デイビスの 2024 年の研究では、サイトの中央値で 20 個の Cookie が設定され、上位 10 ％ のサイトは 60 個超を設定し、その大半がサードパーティの広告・分析ドメイン由来であることが判明しました²。この増殖は、「全消去」操作がほとんどのユーザーが意図する以上のセッション状態を破壊することを意味します。

選択的なアプローチが機能するのは、認証 Cookie と追跡 Cookie が別のドメインに住んでいるからです。Gmail のセッション Cookie は「accounts.google.com」にあり、靴の広告から追ってきた追跡ピクセルは「doubleclick.net」にあります。「accounts.google.com」をホワイトリスト化し「doubleclick.net」を削除すれば、Gmail にログインしたままトラッカーは除去できます。

選択的削除を採用する主な理由:

• メール、銀行、業務ツールのアクティブなセッションを保つ
• サイトをまたいで追うクロスサイト追跡 Cookie を除去する
• ブラウザの Cookie 入れのサイズを小さくし、ページ読み込みを改善しうる
• 至るところで再認証する手間なしに個人のプライバシー基準に合わせる
• 信頼する EC サイトのカートや下書きを保つ
• サードパーティの ID プロバイダーに依存するフェデレーションログインを壊さない

比較：Chrome での選択的削除の方法

要点：Chrome の設定はサイト別の削除はできますがホワイトリストはありません。DevTools は Cookie 単位の精度を持ちますが、ドメインごとに手作業が必要です。Manifest V3 拡張機能だけがホワイトリストと一括クリーンアップを両立する唯一の選択肢です。

Chrome の標準プライバシー機能は「すべて消去」のシナリオに向けて設計されています。Chrome DevTools のドキュメントが指摘するとおり、Application パネルの Cookie ビューは検査とデバッグのためのもので、日常的なプライバシー保守のためではありません¹。拡張機能はまさにこのワークフローの隙間を埋めるために存在します。

方法 1：CookieVault Guardian（推奨）

要点：Guardian のホワイトリスト＆クリーンのワークフローは、初期セットアップ後は 2 クリックです。保護対象ドメインを一度追加すれば、以降のクリーンアップは自動的にそれらを残します。タブクローズ時の自動クリーンを有効にすれば完全にハンズフリーです。

CookieVault Guardian での 8 ステップの選択的削除ワークフロー:

1. 保護対象サイトを特定する —— セッションを失うと困るドメインをすべてリストアップします:メールプロバイダー、ネットバンキング、プロジェクト管理ツール、クラウドストレージ、日常的に使うソーシャルアカウント。
2. 保護対象サイトで DevTools を開く —— F12 → Application → Cookie でセッション Cookie の正確な名前（「SID」「SSID」「PHPSESSID」「jsessionid」「_session_id」）を確認します。これでどのドメインがセッション Cookie を保持しているかが分かります —— サブドメインやフェデレーション ID ドメインで、メインドメインでないことがあります。
3. CookieVault Guardian をインストール —— Chrome ウェブストアからインストールします。Guardian は「chrome.cookies」API を使って JavaScript が触れない HttpOnly Cookie にも特権アクセスする Manifest V3 拡張機能です。
4. 保護対象ドメインをホワイトリストに追加 —— Guardian → 設定 → ホワイトリストを開きます。1 行 1 ドメインで貼り付けるか、各サイトを訪れてツールバーのポップアップから「現在のサイトをホワイトリストに追加」をクリックします。
5. Cookie の一覧を確認する —— Guardian のダッシュボードを開きます。広告ネットワーク、分析プロバイダー、追跡ピクセルからのホワイトリスト外の Cookie には赤いインジケーターが付きます。ホワイトリストの Cookie にはシールドアイコンが付きます。
6. 選択的クリーンアップを実行 —— 「今すぐクリーンアップ」をクリックします。Guardian はホワイトリストに属さないすべての Cookie を削除します。「サイトデータの完全クリーンアップ」が有効ならホワイトリスト外のオリジンの localStorage、IndexedDB、Cache Storage も消去されます。
7. 保護対象セッションを確認 —— 各保護対象サイトを新しいタブで開きます。まだログインしているはずです。予期せずログアウトされたサイトがあれば、その認証は別ドメインの Cookie に依存しています —— そのドメインをホワイトリストに追加します。
8. 定期クリーンアップをスケジュール —— 「タブクローズ時に自動クリーン」を有効にするか、タイマー間隔（毎日、12 時間ごと）を設定します。これで手作業なしに Cookie 入れがクリーンに保たれます。

方法 2：Chrome 設定（手動）

要点：Chrome の設定ではサイト別に Cookie を削除できますが、ホワイトリストはありません。各保護ドメインを手動で検索してスキップする必要があります。一回限りのクリーンアップには使えますが、スケールしません。

Chrome 標準 UI 経由の手動ワークフロー:

1. Chrome の設定（「chrome://settings」）を開く → プライバシーとセキュリティ → Cookie と他のサイトデータ
2. 「すべての Cookie とサイトデータを表示」をクリック —— Chrome はデータを保存しているすべてのドメインのアルファベット順リストを表示します
3. 検索ボックスで追跡ドメインを探す（例えば「doubleclick.net」）
4. 横のゴミ箱アイコンをクリック —— Chrome はそのオリジンのすべての Cookie とサイトデータを削除します
5. 削除したい追跡ドメインそれぞれで繰り返します
6. 「すべて削除」はクリックしないでください —— これは保護対象セッションを含めてすべてを削除します
7. より速い一括方式には「Ctrl+Shift+Delete」（Mac は Cmd+Shift+Delete）→「Cookie と他のサイトデータ」を選択 → 期間を選択 —— ただしこの方式は期間内でオール・オア・ナッシングです
8. 各重要サイトを訪れて保護対象セッションを確認します

手動方式の主な限界は、どのドメインを削除しどれをスキップするかを知っている必要がある点です。ほとんどのユーザーはすべてのサードパーティトラッカーをドメイン名で識別できません。だからこそ、日常的な利用にはホワイトリストベースのツールのほうが実用的です。

保護すべきよくあるセッション Cookie 名

要点：ほとんどのウェブフレームワークは予測可能なセッション Cookie 名を使います。それらを知っておくと、ホワイトリストが正しい Cookie を守っているか確認できます。

クリーンアップ前に Cookie 一覧を確認するとき、保護対象ドメインで以下のよくあるセッション識別子を探します:

• 「SID」「SSID」「HSID」「APISID」 —— Google サービス（Gmail、YouTube、Drive、カレンダー）
• 「PHPSESSID」 —— PHP ベースのサイト（WordPress、Magento、多くのカスタムアプリ）
• 「jsessionid」または「JSESSIONID」 —— Java ベースのエンタープライズアプリ（Jira、Confluence、Jenkins）
• 「_session_id」 —— Ruby on Rails アプリ（GitHub、Shopify 管理画面、Basecamp）
• 「connect.sid」 —— Node.js Express アプリ
• 「ASP.NET_SessionId」 —— .NET ベースのサイト（Azure DevOps、多くの企業ポータル）
• 「csrftoken」＋「sessionid」 —— Django アプリ
• 「laravel_session」 —— Laravel（PHP）アプリ

サイトがフェデレーションログイン（Google でログイン、Apple でログイン）を使っている場合、セッション Cookie はサイト本体ではなく ID プロバイダーのドメインに住んでいることがあります。例えば Google 経由でサイトにログインするには「accounts.google.com」の Cookie が必要です —— サイトと ID プロバイダーの両方をホワイトリストに入れてください。

誤って保護対象 Cookie を消してしまった場合

要点：セッション Cookie を失うとログアウトされますが、アカウントデータは削除されません。再認証すれば新しいセッション Cookie が得られます。事前に Cookie をエクスポートしていれば、それを再インポートしてパスワードなしでセッションを復元できます。

セッション Cookie を誤って削除したときに起きる 6 つのこと:

• そのサイトへの次のリクエストにセッション識別子が含まれない
• サーバーはあなたを新規・未認証の訪問者として扱う
• ログインページか「セッションが切れました」メッセージが表示される
• 再認証すると新しいセッション Cookie が作られる —— アカウントデータ、設定、履歴はサーバー側で無事
• ウェブアプリでフォームの下書きや未保存の作業があった場合、失われることがある（アプリが localStorage を使うかサーバー側自動保存か次第）
• サイトの「このデバイスを記憶」が別の Cookie として保存されていてそれも消した場合、二要素認証が再要求される

最も安全なアプローチは、一括削除の前に Cookie をエクスポートすることです。CookieVault Editor の JSON エクスポートは復元経路を提供します —— ファイルをインポートすればパスワードを再入力せずにセッション Cookie を復元できます。完全なワークフローは Cookie を JSON にエクスポートする方法 のガイドを参照してください。

関連ページ

• Chrome で Cookie を削除する方法 —— すべてを消したいときの完全な削除ガイド
• Chrome で Cookie をホワイトリスト化する方法 —— Chrome 設定と拡張機能の詳細なホワイトリスト設定
• タブを閉じたら Cookie を自動削除 —— 選択的削除の自動版
• Cookie を JSON にエクスポートする方法 —— 消去前にセッションをバックアップ
• CookieVault Editor —— Cookie の閲覧、編集、エクスポートのオープンソース Manifest V3 マネージャー
• CookieVault Guardian —— ホワイトリスト対応の自動クリーンアップ拡張機能