ログインがループしたり、決済画面が進まなかったり、A/Bテストのバナーが消えなかったり——
こうした現象の裏側で鍵を握るのがCookieです。
本記事はCookieの確認手順・見方・編集／削除の作法・セキュリティ属性の読み解きを、Google Chromeのデベロッパーツール（DevTools）中心に深掘り解説します。
関連で聞かれやすい以下の質問にも答えます。
- ChromeのデベロッパーツールでCookieを確認する方法は？
- ChromeでCookieを確認するツールは？
- 開発者ツールでCookieを確認するには？
- Google Chromeのクッキーの確認方法は？
少しでもご参考になれば幸いです！
Contents
まずは結論（最短チェック）
- 最短の確認手順：
①対象サイトを開く
→ ②DevToolsを開く（Windows/Linux：F12またはCtrl+Shift+I、macOS：⌥⌘I）
→ ③上部タブApplication（新UIではStorage表記の場合あり）
→ ④左ペインCookies
→ ⑤対象ドメインを選択。 - 見るポイント：Name / Value / Domain / Path / Expires / HttpOnly / Secure / SameSite。
- 編集/削除：表のセルをダブルクリックで編集、Deleteキーで削除、または右クリックメニュー。
- Networkパネルでもリクエスト/レスポンス単位のCookiesを確認可能（Request Cookies / Response Cookies / 3rd-partyの有無）。
- 安全運用：Cookieはサイト単位で必要最小限に削除、サードパーティ制御や例外登録で利便性を保ちつつトラブルを解消。
Cookieの基本とDevToolsで見る理由
Cookieは、サイトごとに小さなテキスト情報（ログイン状態・表示設定・トラッキング同意・カートの中身など）を保存する仕組みです。
DevToolsを使うと、ブラウザが実際に保持しているCookieの一覧がドメインごとに見え、属性（Secure/SameSite/HttpOnly…）や有効期限まで正確に確認できます。
UIから「それらしく」設定しても、現場では“実際に何がブラウザに入っているか”が最重要なので、DevToolsが基本ツールになります。
図解イメージ：
Application/Storageパネル左に「Cookies」ツリー、右に表形式で各Cookieの行。
Nameは「箱のラベル」、Valueは「中身」、属性列は「扱いのルール」。）
ChromeのデベロッパーツールでCookieを確認する方法（王道）
手順（共通）
- 対象サイトを表示
- DevToolsを開く
- Windows/Linux：F12 または Ctrl + Shift + I
- macOS：⌥ + ⌘ + I
- 上部タブのApplication（一部のバージョンや設定ではStorage）を選択
- 左ペインのCookiesを展開 → 対象のドメインをクリック
- 右側に**表（グリッド）**でCookie一覧が表示
- 列で詳細を確認：Name / Value / Domain / Path / Expires/Max-Age / Size / HttpOnly / Secure / SameSite / Priority など
代表的な列の読み方（要点表）
| 列 | 見る理由 | 例と解釈のコツ |
|---|---|---|
| Name | 何のCookieか識別する要。 | sessionid、csrftoken、__Host-*、__Secure-* など命名規則に意味がある場合あり。 |
| Value | 実データ。セッションIDなどが入る。 | セキュリティの都合で実運用では秘匿。第三者に共有しない。 |
| Domain | どのドメインに適用か。 | example.com／.example.com（サブドメイン可）。**第三者（3rd-party）**有無の判定にも。 |
| Path | 適用パス。 | /ならサイト全体。 |
| Expires/Max-Age | 期限。 | セッションCookieは期限なし（ブラウザ閉じると無効）。長期は追跡/利便性のバランスに注意。 |
| HttpOnly | JSから参照不可。XSS対策。 | Trueならdocument.cookieでは見えない。DevToolsなら見える。 |
| Secure | HTTPSのみ送信。 | SameSite=NoneのCookieはSecure必須。 |
| SameSite | 送信コンテキスト制御。 | 既定はLax。交差サイト(SameSite=None)は厳しめに扱われる潮流。 |
| Priority | 競合時の優先度。 | High/Medium/Low。容量超過時の振る舞いに関与。 |
ヒント：
__Host-/__Secure-というプレフィックスが付くCookieはセキュリティ要件が強化されています（例：__Host-はSecureかつPath=/かつDomainなし等）。挙動の検証時に手掛かりになります。
Cookieを編集・削除する（安全なやり方）
- 編集：表の該当セル（Valueなど）をダブルクリック → 値を変更 → Enterで確定。
- 削除：行を選んでDeleteキー、または右クリック → Delete。
- 一括削除：ドメインを選択した状態で右クリック → 「Clear」（またはClear storage機能を併用）。
- 再読込：変更後はページをリロードして挙動を確認。
注意
- 運用本番のサイトでは、誤削除でログアウトやカート空など影響が出ます。検証用プロファイルやステージング環境で試すのが安全。
- HttpOnlyはJSから触れませんが、DevToolsでは閲覧/編集が可能です。取り扱いは慎重に。
- 値の共有は厳禁（セッション乗っ取りリスク）。
NetworkパネルでCookieを確認する（リクエスト/レスポンス単位）
Networkタブでは、個々の通信でどのCookieが送受信されたかを確認できます。
- Networkを開く → 対象のリクエストをクリック
- パネル内のCookiesタブ（またはHeaders → Request Headers / Response Headersの
Cookie/Set-Cookie）を表示 - Request Cookies（ブラウザ→サーバへ送信）とResponse Cookies（サーバ→ブラウザ設定）の差分を把握
- 第三者（3rd-party）Cookieが送受信されているか（他ドメインの
Set-Cookie）も把握可能
図解イメージ：
Network内リクエスト詳細のタブにCookiesがあり、上段がRequest、下段がResponse。
隣のHeadersにはSet-Cookieが整形されて並ぶ。
活用例：
- ログインループ：
Set-Cookieが返っているか／属性（SameSite=None; Secureなど）が適正か。- 外部IDプロバイダ（SSO）：クロスサイトの
Set-Cookieがブロックされていないか。- A/Bテスト：実験割当のCookieがRequestに正しく乗っているか。
目的別：Cookie確認のショートカット＆導線
| 目的 | 操作 |
|---|---|
| すぐにCookie一覧を見たい | DevTools → Application/Storage → Cookies |
| 通信ごとに送受信を追いたい | DevTools → Network →（リクエスト）→ Cookies |
| 現在のサイトだけ消したい | アドレスバーのサイト情報（錠/コントロール） → サイトの設定 → Cookie／またはDevToolsで該当ドメインをClear |
| サードパーティを抑えたい | 設定 → プライバシーとセキュリティ → Cookie と他のサイトデータ → サードパーティ制御＋例外サイト登録 |
| プロファイルを分けたい | プロファイルメニューから業務/私用/検証を分離（Cookie衝突を回避） |
よくある詰まりと解決の型（トラブルシュート）
- ケース1：ログインが無限ループ
- Networkで
Set-Cookieの属性確認（SameSite=None; Secure、Domain/Pathの整合性、期限など）。 - Application/Storageで該当Cookieを一度削除→再ログイン。
- サードパーティCookie制御やITP/トラッキング保護の影響を疑い、例外サイト登録で回避。
- Networkで
- ケース2：特定のウィジェットだけ動作しない
- そのウィジェットのドメインのCookieが3rd-party扱いでブロックされていないかをNetworkで確認。
- 必要なドメインを例外登録し、Application/Storageで当該Cookieを再取得させる。
- ケース3：カートが勝手に空になる
- Expires/Max-Ageが極端に短くないか／サブドメイン跨ぎの
Domain指定が適正か。 - Pathが狭すぎて別URLで参照できていない可能性も検討。
- Expires/Max-Ageが極端に短くないか／サブドメイン跨ぎの
- ケース4：SameSiteの理解不足で実装が迷子
- 既定はLax。他サイトコンテキストで必ず送信したい場合は**
SameSite=None; Secureが必須**。 - セキュリティと要件のバランス設計を。
- 既定はLax。他サイトコンテキストで必ず送信したい場合は**
- ケース5：検証の度に状態が変わる
- シークレットウィンドウはCookieがセッション限定。検証環境では通常ウィンドウとシークレットを使い分け、状態管理を明確に。
セキュリティ属性をCookieから読み解く（実務の目）
- HttpOnly：XSSからセッション窃取されにくくする基本。True推奨（JSから読めない）。
- Secure：HTTPS通信のみで送信。
SameSite=Noneとセットで必須。 - SameSite：クロスサイト送信の可否。既定Lax、Noneは慎重に。
__Host-/__Secure-：命名規則で誤設定を防ぐ。__Host-は**Domain指定不可**・Path=/必須・Secure必須。- 有効期限：長期化は便利だがリスクも増える。短期+リフレッシュ設計も検討。
図解イメージ：Cookieの「名札」に緑の鍵（Secure）、盾（HttpOnly）、矢印の向き（SameSite）などの“バッジ”が付いていて、通信の場面ごとに送る/送らないを自動で判断している。
よくある質問
Q. ChromeのデベロッパーツールでCookieを確認する方法は？
A. 対象サイトを開き、DevTools → Application（またはStorage）→ Cookies → ドメイン選択で一覧表示。
Networkでもリクエスト/レスポンス単位のCookieを確認できます。
Q. ChromeでCookieを確認するツールは？
A. Chrome標準のDevToolsが最も確実です。Application/StorageとNetworkの2視点を使い分けると、保持状態と通信実態が両方わかります。
Q. 開発者ツールでCookieを確認するには？
A. F12（⌥⌘I）→ Application/Storage → Cookies。
値の編集・個別削除・一括削除が可能。
HttpOnlyはJSからは読めませんがDevToolsでは閲覧可です。
Q. Google Chromeのクッキーの確認方法は？
A. DevToolsが基本。
併せて、設定 → プライバシーとセキュリティ → Cookie と他のサイトデータから全体ポリシー（サードパーティ制御・例外登録）を確認するとトラブルシュートが速くなります。
実務で効くチェックリスト（保存版）
- Application/Storage → Cookiesで保持中のCookieを確認
- Network → Cookiesで送受信の有無・属性を確認
- SameSite/Secure/HttpOnlyの基本ポリシーを理解
- サードパーティCookie制御と例外サイト登録で必要十分の許可に
- 直らない時は該当ドメインのCookieをいったん削除→再取得
- 検証用プロファイル/シークレットを使い分け、状態汚染を避ける
まとめ（要点整理＋ひとこと）
- CookieはDevToolsで“実物”を見るのが最短。Application/Storageで保持、Networkで送受信を可視化。
- 編集/削除は簡単だが、本番環境では慎重に。まずは検証用プロファイルで。
- **属性（Secure/HttpOnly/SameSite）**の理解が、ログインループやSSO不調の原因特定に直結。
- サードパーティ制御＋例外登録で安全と利便のバランスを取る。
ひとことアドバイス：
困ったら**「Applicationで保持を確認 → Networkで送受信を確認 → 属性を見直し → 必要ならサイト単位で削除」**の順に進めると、解決までの道のりが最短になります。
参考リンク
- Chrome ヘルプ：Cookie の削除・許可・管理
- Chrome DevTools ドキュメント：Application/Storage パネルの Cookies
- Chrome DevTools ドキュメント：Network での Cookies の確認
- Chrome ヘルプ：サイトのアクセス許可（Cookie など）
- Chrome ヘルプ：シークレットモード（閲覧データの扱い）
