Microsoft Edge で特定サイトの既存 Cookie だけをきれいに削除し、それ以外のサイトのログイン状態や設定は残したい──企業環境ではよくある要望です。本記事では「特定サイトの Cookie ブロック GPO は既に適用済み」という前提で、残ってしまった既存 Cookie を PowerShell や DevTools Protocol を使って安全かつ効率的に削除する方法を詳しく解説します。
前提:GPO だけでは「既に保存済みの Cookie」は消せない
まず押さえておきたいポイントは、Microsoft Edge の GPO(グループポリシー)はあくまで「今後 Cookie を保存させるかどうか」を制御する仕組みだという点です。
たとえば、特定サイトの Cookie をブロックする GPO を設定しても、ポリシー適用前にブラウザーに保存されていた Cookie はそのまま残り続けます。結果として、以下のような状況が発生します。
- GPO ではブロックしているはずのサイトに、なぜか以前のログイン状態が残っている
- 古いセッション情報が原因で、アプリ更新後に画面表示や認証で不具合が出る
- セキュリティインシデント対応の一環として特定ドメインの Cookie を消したいが、全 Cookie を削除すると業務影響が大きい
このギャップを埋めるには、「既存 Cookie の掃除」専用の仕組みを別途用意する必要があります。本記事では、規模や運用方針に応じて選択できる 3 つのアプローチを整理します。
3 つのアプローチの比較
本記事で扱う方法は次の 3 つです。
- Edge の UI から対象サイトの Cookie を手動で削除する
- PowerShell で Edge の Cookie SQLite データベースを直接編集する
- PowerShell から Edge DevTools Protocol を呼び出して Cookie を削除する
特徴を一覧にした表がこちらです。
| 手段 | 概要 | 適用規模 | 長所 | 注意点 |
|---|---|---|---|---|
| Edge UI から手動削除 | Edge の設定画面(設定 › Cookie とサイトのアクセス許可 › すべての Cookie とサイトデータ)で対象ドメインを検索して [削除] を実行する。 | PC 台数が少ない環境、スポット対応 | 追加ツール不要。ユーザー側でも対応可能。 | 完全に手作業。案内ミス・操作ミスのリスクがある。 |
| SQLite データベースを PowerShell で編集 | Cookie は %LocalAppData%\Microsoft\Edge\User Data\Default\Network\Cookies の SQLite DB に保存されている。PowerShell + System.Data.SQLite を使い、DELETE FROM cookies WHERE host_key='.example.com' などで対象ドメインの行を削除する。 | 数十〜数百台(ログオンスクリプトなどで展開) | 仕組みがシンプルで高速。処理内容も見通しやすい。 | Edge 起動中は DB がロックされる。将来のスキーマ変更で動かなくなる可能性がある。 |
| Edge DevTools Protocol を PowerShell から呼び出す | PowerShell から DevTools セッションを開き、Network.GetAllCookies で取得 → フィルター → Network.DeleteCookies で削除する。 | 大規模展開(Intune / GPO スクリプトで全社展開) | Edge の内部構造に依存しづらく、API として正式にサポートされているため将来的に安定しやすい。 | Edge 109 以降が前提。DevTools 用のライブラリ配置など、初期セットアップがやや重い。 |
次のセクションから、それぞれの方法を詳しく解説していきます。
方法 1:Edge の UI から特定サイトの既存 Cookie を手動削除
この方法が向いているケース
- 端末数が少なく、IT 管理者が一台ずつ対応できる
- 影響範囲が限定的で、一時的なスポット対応で済ませたい
- エンドユーザーに「自分で削除してもらう」運用を採用している
操作手順
ユーザーに案内する場合を想定した具体的な手順は次の通りです。
- Microsoft Edge を起動する。
- 右上の「…」メニューから [設定] を開く。
- 左メニューから [Cookie とサイトのアクセス許可] を選択する。
- [すべての Cookie とサイトデータ] をクリックする。
(直接edge://settings/siteDataをアドレスバーに入力してもよい。) - 画面上部の検索ボックスに、削除したいサイトのドメイン名(例:
example.com)を入力する。 - ヒットした項目の右側にあるゴミ箱アイコンまたは [削除] をクリックする。
- 念のため Edge を再起動し、対象サイトへアクセスしてログイン状態などがリセットされていることを確認する。
長所・短所・運用上のポイント
| 観点 | ポイント |
|---|---|
| 導入コスト | 追加ツールが不要で、今すぐ実行できる。 |
| スケール | 台数が増えると人手では回しきれないため、10〜20 台程度までが現実的。 |
| ユーザー依存 | ユーザーに作業させる場合、誤って別サイトの Cookie を削除されるリスクがあるため、画面付きマニュアルの整備が望ましい。 |
| 再現性 | 同じ操作を繰り返すのが難しく、監査ログにも残りにくい。 |
小規模な環境であればこの方法で十分ですが、企業全体で同じポリシーを適用したい場合は、後述する自動化手段の検討がおすすめです。
方法 2:PowerShell から SQLite Cookie データベースを直接削除
仕組みの概要
Edge の Cookie は、ユーザープロファイルごとに次の場所にある SQLite データベースに保存されています。
%LocalAppData%\Microsoft\Edge\User Data\Default\Network\Cookies
複数プロファイルを使っている場合は Default の代わりに Profile 1、Profile 2 といったフォルダーにも同様のファイルが存在します。
この DB 内の cookies テーブルに、各サイトの Cookie が 1 行ずつ保存されています。host_key 列が Cookie のドメイン、name 列が Cookie の名前に相当します。したがって、特定ドメインの既存 Cookie を削除したい場合は、次のような SQL を発行すればよいことになります。
DELETE FROM cookies WHERE host_key = '.example.com';
これを PowerShell から実行することで、ユーザーの操作なしに対象ドメインの Cookie だけを一括削除できます。
サンプルスクリプト例(基本形)
以下は 1 プロファイル(Default)の Cookie DB から、特定ドメインの Cookie を削除するシンプルなサンプルです。実行前に System.Data.SQLite の DLL を用意し、パスを調整してください。
$targetDomain = ".example.com" # 削除したいドメイン
$userDataDir = Join-Path $env:LocalAppData "Microsoft\Edge\User Data"
$dbPath = Join-Path $userDataDir "Default\Network\Cookies"
# Edge が起動しているとファイルロックされるため、事前に終了させる
Get-Process msedge -ErrorAction SilentlyContinue | Stop-Process -Force
# SQLite プロバイダーの読み込み(配置した DLL のパスに変更する)
Add-Type -Path "C:\Tools\System.Data.SQLite.dll"
# バックアップ作成(念のため)
Copy-Item $dbPath "$dbPath.bak" -Force
# SQLite 接続文字列
$connectionString = "Data Source=$dbPath;Version=3;"
$connection = New-Object System.Data.SQLite.SQLiteConnection($connectionString)
$connection.Open()
$command = $connection.CreateCommand()
$command.CommandText = "DELETE FROM cookies WHERE host_key = @host OR host_key = @hostNoDot"
$command.Parameters.AddWithValue("@host", $targetDomain) | Out-Null
$command.Parameters.AddWithValue("@hostNoDot", $targetDomain.TrimStart('.')) | Out-Null
$deleted = $command.ExecuteNonQuery()
$connection.Close()
Write-Output "削除した Cookie 行数: $deleted"
ポイントと注意事項
- Edge は事前に終了させる
Cookie DB は Edge 起動中にロックされるため、必ずStop-Processなどで事前に終了してから実行します。 - バックアップを必ず取る
誤って他の Cookie を消してしまった場合に備え、実行前に DB ファイルをコピーしておくことをおすすめします。 - 将来のバージョン変更リスク
DB スキーマ(テーブル構成やカラム名)は将来の Edge バージョンで変更される可能性があります。変更が入るとスクリプトの改修が必要です。 - 複数プロファイルへの対応
実運用ではDefault以外に複数のプロファイルを持つユーザーもいるため、「User Data 配下のすべてのプロファイルを列挙して同じ処理を行う」よう拡張するのが無難です。
ログオンスクリプトや Intune での一括展開例
この方法は単体の PC だけでなく、以下のように管理ツールと組み合わせることで数十〜数百台規模までスケールさせられます。
- Active Directory GPO の「ユーザーのログオン スクリプト」として登録する
- Intune の「デバイス構成プロファイル」や「スクリプト」機能から配布する
実運用では、次のような工夫を入れるとトラブルを避けやすくなります。
- 初回ログオン時のみ実行するよう、レジストリやファイルでフラグ管理を行う
- 削除件数をログファイルに出力し、監査やトラブルシュートに使えるようにする
- エラー時は DB をロールバック(バックアップから戻す)する処理を入れておく
DB を直接触る方法はシンプルかつ高速ですが、長期的にはバージョン依存・スキーマ依存のリスクがある点を理解したうえで採用するのがよいでしょう。
方法 3:Edge DevTools Protocol を PowerShell から利用する
DevTools Protocol を使う理由
Edge DevTools Protocol は、本来開発者がブラウザーをデバッグするための API です。ネットワーク通信の内容取得や、DOM の操作、Cookie 管理などを外部ツールから行えるようになっています。
Cookie 削除の観点では、次のようなメリットがあります。
- Edge の内部 DB 構造(SQLite のスキーマ)に依存しない
- 公式 API として提供されているため、将来のバージョンでも挙動が安定しやすい
- GUI に依存せず、完全にスクリプトだけで完結できる
一方で、DevTools 用のライブラリ配置など事前準備がやや多い点と、Edge 109 以降が前提になる点には注意が必要です。
準備:DevTools Protocol ライブラリを PowerShell から使えるようにする
PowerShell から DevTools Protocol を扱うには、.NET 向けのライブラリ(例:Microsoft.Edge.DevTools.Protocol.dll)をあらかじめクライアントに配置し、Add-Type で読み込めるようにしておきます。
- 社内ファイルサーバーやソフトウェア配布ツールで DLL を展開
- 固定パス(例:
C:\Tools\Microsoft.Edge.DevTools.Protocol.dll)に配置 - バージョンアップ時には DLL の差し替えだけで済むようにしておく
これらを自動化しておけば、スクリプト本体は比較的長期にわたって使い回すことができます。
DevTools Protocol で Cookie を削除するサンプルスクリプト
以下は、DevTools Protocol を利用して特定ドメイン(+必要に応じて特定の Cookie 名)を削除する PowerShell サンプルです。
param(
[string]$TargetDomain = "example.com", # 対象ドメイン
[string]$TargetCookieName = "" # 空ならドメイン配下のすべての Cookie
)
# DevTools Protocol ライブラリの読み込み
Add-Type -Path "C:\Tools\Microsoft.Edge.DevTools.Protocol.dll"
# DevTools 用に Edge を起動 (--remote-debugging-pipe)
$launcher = New-Object Microsoft.Edge.DevToolsProtocol.DevToolsLauncher
$edgeArgs = "--remote-debugging-pipe --headless"
$session = New-Object Microsoft.Edge.DevToolsProtocol.DevToolsProtocolSession(
$launcher.LaunchEdge($edgeArgs))
# Network ドメインを有効化
$session.Network.Enable() | Out-Null
# すべての Cookie を取得
$cookies = $session.Network.GetAllCookies().Cookies
# ドメインと Cookie 名で絞り込み
$targetCookies = $cookies | Where-Object {
$_.Domain -like "*$TargetDomain" -and
(
[string]::IsNullOrEmpty($TargetCookieName) -or
$_.Name -eq $TargetCookieName
)
}
# 対象 Cookie を削除
$targetCookies | ForEach-Object {
Write-Output "Delete Cookie: $($_.Domain) $($_.Name)"
$session.Network.DeleteCookies($_.Name, $_.Domain)
}
# Edge (DevTools セッション) を終了
$launcher.Close()
ユーザー提供のサンプルと同様に、基本的な流れは次のようになります。
- DevTools 用の Edge セッションを
--remote-debugging-pipeオプション付きで起動する。 Network.GetAllCookies()でブラウザーが保持している全 Cookie を取得する。- 対象ドメイン(+必要なら Cookie 名)で絞り込む。
Network.DeleteCookies()を呼び出して対象 Cookie を削除する。- セッションを閉じる。
実行時のポイント
- 既存の Edge セッションと分けて実行する
通常利用中の Edge とは別に、DevTools 用インスタンスを起動して操作します。Edge を完全に閉じてから実行しても問題ありません。 - 削除後はユーザーに再起動を促す
Cookie とキャッシュの整合性を取るため、ユーザーには「Edge を一度すべて閉じて再度開き直してください」と案内すると安全です。 - Edge バージョン要件
DevTools Protocol の仕様は基本的に後方互換ですが、古い Edge では一部メソッドが存在しない可能性があるため、少なくとも 109 以降を前提にするのが無難です。
大規模展開のイメージ(Intune / GPO)
DevTools Protocol 方式は、企業内での大規模展開にも向いています。
- Intune のスクリプト機能で定期的に実行する(例:1 回だけ、または月 1 回)
- GPO のユーザーログオンスクリプトとして登録し、初回ログオン時に Cookie を掃除する
- 削除対象ドメインを変数化し、複数ドメインに対応できるようにする
SQLite 直接削除方式と比べると初期セットアップは重いものの、将来の Edge の内部仕様変更による影響を受けにくいため、長期運用を前提とした環境ではこの方式がもっとも「安全寄り」と言えます。
GPO では何ができて、何ができないのか
ここまで「GPO だけでは既存 Cookie を削除できない」という話をしてきましたが、誤解を避けるために、GPO でできること・できないことを整理しておきます。
| 項目 | GPO で制御できるか | 概要 |
|---|---|---|
| 今後の Cookie 保存可否 | 可能 | 特定ドメインの Cookie をブロック/許可する設定が可能。 |
| 既に保存済みの Cookie の削除 | 不可 | 今回のテーマ。GPO ではデータベース内の既存行を削除できない。 |
| Cookie の保存先パス | 不可 | Edge が内部的に利用するファイル構成は GPO から変更できない。 |
| ブラウザー終了時に全 Cookie 削除 | 一部可能 | ポリシーにより「終了時に閲覧データを削除」することは可能だが、特定サイトだけを残す/消すといった細かい制御は難しい。 |
このため、「特定サイトだけ既存 Cookie を掃除したい」という要件は、どうしても今回のような別手段(PowerShell や DevTools Protocol)で補う必要があります。
どの方法を選ぶべきか:判断の目安
3 つの方法のどれを採用するかは、環境規模や運用方針、将来のメンテナンスコストをどう考えるかによって変わります。ざっくりとした判断の目安をまとめると次の通りです。
| 環境条件 | 推奨手段 | コメント |
|---|---|---|
| 数台〜十数台、スポット対応中心 | Edge UI からの手動削除 | 管理者が直接作業できる規模なら、シンプルさを優先して手動対応が現実的。 |
| 数十〜数百台、短期運用または一度きりの移行 | SQLite 直接削除 + ログオンスクリプト | 一度だけ既存 Cookie を掃除したい移行案件で有効。将来のバージョン変更リスクは受け入れる前提。 |
| 数百〜数千台、長期運用前提 | DevTools Protocol + PowerShell | 初期構築はやや複雑だが、Edge の内部仕様に依存しない構成にでき、長期的に安定しやすい。 |
「今だけ乗り切れればいい」のか、「今後も同様の要件が繰り返し出てきそうか」を一度整理し、将来のメンテナンスコストまで含めて選ぶと失敗が少なくなります。
実運用での注意点・ベストプラクティス
対象ドメインの洗い出しと影響範囲の確認
Cookie 削除は、対象ドメインのサービスだけでなく、同一ドメイン配下の別サービスにも影響する可能性があります。
portal.example.comとapp.example.comが同一ドメインのアプリとして共存している- シングルサインオン(SSO)でドメイン全体の Cookie を共有している
このような場合、Cookie を削除することで一部アプリのログイン状態やセッション情報がまとめて失われることになります。事前に関係者へ影響範囲を説明し、切り戻し手順(ログイン方法の案内など)も用意しておくと安心です。
テスト環境での検証は必須
本番環境に適用する前に、必ず次のような流れでテストを行ってください。
- テスト用ユーザー/端末に対してスクリプトを実行
- 対象サイトへのログインや画面遷移、SSO 連携が期待通り動作するか確認
- 想定外のサイトのログイン情報が失われていないか確認
- 必要に応じてバックアップから Cookie DB を戻す手順をリハーサル
特に、「複数サービスが同じドメインを共有している」場合はテストパターンを多めに用意しておくことをおすすめします。
ユーザー向けの周知とサポート体制
Cookie 削除後は、ユーザー側で次のような事象が起こり得ます。
- 対象サイトへの再ログインが必要になる
- 「このブラウザーを信頼する」などのワンタイム設定が出直す
- 一部の個人設定(ダークモードや表示言語など)が初期化される
これらは正常な挙動ですが、事前に説明がないとユーザーは「エラーが出た」「設定が勝手に変わった」と感じてしまいます。事前通知メールやポップアップ、社内ポータルでの告知などを活用し、次のような内容を周知しておくとトラブルを減らせます。
- いつ Cookie の削除が行われるのか(日付と時間帯)
- どのサイトへの影響が想定されるのか
- どのような再設定が必要になるのか(例:再ログインの手順)
ログと監査の整備
セキュリティや監査の観点から、Cookie 削除の実行ログを残しておくことも重要です。
- 「いつ」「どの端末(もしくはユーザー)に対して」「どのドメインの Cookie を何件削除したか」をログに出力する
- ログを Event Log や中央のログサーバーに集約しておく
- 必要に応じて、ログオンスクリプトの実行状況をレポート化する
特に組織規模が大きくなるほど、後から「この端末だけ Cookie が残っていた」「特定部署だけ処理が漏れていた」といった事象の原因調査にログが役立ちます。
まとめ:環境に合った方法で「特定サイトの既存 Cookie だけ」をきれいに掃除する
本記事では、Microsoft Edge に対して既に「特定サイトの Cookie をブロックする GPO」を適用済みという前提で、以下の 3 パターンの解決策を紹介しました。
- Edge UI からの手動削除:少数端末向け。追加ツール不要だが、人手と手順の徹底が必要。
- SQLite データベースを PowerShell で直接編集:数十〜数百台のスポット的掃除に有効。シンプルかつ高速だが、Edge の内部構造に依存するリスクがある。
- DevTools Protocol を PowerShell から利用:長期運用や大規模環境向け。初期構築はやや重いものの、将来的に安定しやすいアプローチ。
いずれの方法でも、次のポイントを押さえておけば「特定サイトの既存 Cookie だけを削除し、他の Cookie は残す」という要件を満たしながら、業務影響を最小限に抑えることができます。
- GPO だけでは既存 Cookie は消せないため、別途スクリプトや手順を用意する必要がある
- 対象ドメインと影響範囲を事前に洗い出し、テスト環境で十分に検証する
- ユーザーへの周知とサポート体制、ログ・監査の仕組みをセットで設計する
組織の規模や運用体制に合わせて、ここで紹介した 3 つの方法を組み合わせれば、Microsoft Edge の Cookie 管理をより安全かつ柔軟にコントロールできるようになります。

コメント