Chromeブックマーク整理事故を徹底検証：なぜ今回はログイン状態も拡張機能の状態も一緒に吹っ飛んだのか

汎用
,
1

これは自分用のアーカイブとして残す、事故の完全記録。

背景

今回の事故は、Codex に Chrome のブックマーク整理を手伝わせたあとに起きた。最初の直感は「profile を切り替え間違えた？ それとも Chrome の設定ディレクトリを丸ごと差し替え間違えた？」だった。けれど、手元マシンの profile メタデータ、重要な DB ファイル、事故スナップショット、そして Codex のセッションログを全部突き合わせた結果、結論はもう確定できる。

直接結論

profile の切り替えミスではないし、新しい空の profile に切り替わったわけでもない。

本当の原因は、Codex に「使用中の Default profile の live ブックマークファイル」を直接操作させ、その後も同じ live profile 上で再編成/復元を続けたことで、この古い profile を Crashed 状態に入れてしまったこと。ログイン Cookie、サイトのログイン状態、拡張機能の実行状態は、この過程でまとめて壊れた。

一言版：「ブックマーク内容が cookie を上書きした」のではなく、「動作中の Chrome profile へのその場書き込み + その後の異常終了/クラッシュ復旧によって、同じ古い profile のローカル状態 DB を壊した」。

重要な証拠

  1. profile の誤切り替えではない。

    • Local State にあるのは Default だけ。
    • last_active_profiles と profiles_order も Default だけ。
    • つまり事故の全期間を通じて、Chrome が見ていたのは同一の既定 profile で、新 profile や別 profile ではない。

  2. 新規の空 profile ではない。

    • Preferences
    • Secure Preferences
    • Login Data
    • Network/Cookies
      これら重要ファイルの作成日時がいずれも 2025-05-27 のまま。
      つまり事故後に急造された空設定ではなく、長期間使われてきた同一の古い profile のもの。

  3. live の Default\\Bookmarks に対して、その場書き込みが実際に行われた。

    • Codex セッションログ rollout-2026-04-14T05-49-37-019d88d2-50fd-72e3-8a0a-9f41e4e46637.jsonl に、インライン Python があり、直接読み取り・再書き込みしている：
      • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
    • そのコードはテスト用のエクスポートではなく、write_text(...) で live ブックマークファイル本体へ回書きしている。

  4. その後、ブックマーク再編成専用スクリプトも生成されている。

    • scripts\\reorganize_chrome_bookmarks.ps1
    • このスクリプトの既定ターゲットも同じ：
      • C:\\Users\\1\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Bookmarks
    • さらに危険分岐があり、-CloseChrome を渡すと、次を直接実行する：
      • Get-Process chrome | Stop-Process -Force
    • つまりこのスクリプト自体が live profile ファイルを直接いじる設計で、かつ Chrome を強制終了できる。

  5. 事故スナップショットが、profile がクラッシュ状態に入ったことを明確に示している。

    • 事故スナップショットディレクトリ：
      • backups\\chrome-cookie-incident-20260414-0728
    • その中の Default\\Preferences に記録：
      • profile.exit_type = Crashed
    • これは「正常終了して再起動」ではなく、同一 profile が異常中断されたあとの状態。

  6. 拡張機能の実行状態は途切れたが、拡張機能メタデータは残っている。

    • 同じ事故スナップショットで：
      • Preferences の extensions.settings = 0
      • Secure Preferences の extensions.settings = 78
    • この組み合わせが非常に重要。
    • 拡張機能のメタデータが全部消えたわけではない一方で、実行状態 / 現在状態が落ちているため、「プラグイン数が明らかに合わない」「少ししか残っていないように見える」という異常が当時起きた。

  7. ログイン状態 DB が明らかに縮んでいる。

    • 事故スナップショットで：
      • Network\\Cookies が Cookie 44 件、host 13 個まで減少
      • Login Data の logins = 0
      • Login Data For Account の logins = 0
    • これが、サイトのログイン状態、Cookie、ローカルログインの多くが一緒に消えた理由。

  8. ただし同じスナップショットに、大量の IndexedDB / Local Storage / Sessions は残っている。

    • これはさらに「新 profile に切り替わったわけではない」ことを示す。
    • 新 profile なら、旧サイトのローカルストレージ痕跡がこんなに残るはずがない。
    • 今見えているのは「同一の古い profile が部分復旧され、残った DB と、認証系の重要 DB が欠損した」状態。

タイムライン

手元のファイル時刻と事故スナップショット時刻を突き合わせると、最重要区間は 2026-04-14 07:16 - 07:20。

  1. 2026-04-14 05:49 頃

    • セッションログに、Codex がすでに live の Default\\Bookmarks にその場書き込みを行っていた記録がある。

  2. 2026-04-14 07:00:11

    • scripts\\reorganize_chrome_bookmarks.ps1 作成。

  3. 2026-04-14 07:09:15

    • このスクリプト最終更新。

  4. 2026-04-14 07:11:58

    • Bookmarks-pre-final-reorg-20260414-071158.json 生成。

  5. 2026-04-14 07:16:04

    • Bookmarks-before-restore-20260414-071604.json 生成。

  6. 2026-04-14 07:16:25

    • 事故スナップショット内 Login Data 最終書き込み。

  7. 2026-04-14 07:17:43

    • Secure Preferences 最終書き込み。

  8. 2026-04-14 07:19:36

    • Cookies 最終書き込み。

  9. 2026-04-14 07:19:52

    • Preferences 最終書き込み。

  10. 2026-04-14 07:20:03

  • Sessions ファイル最終書き込み。

この時刻列が示すことは2つ：

  • ログイン状態が本当に吹き飛んだ窓は 07:16 - 07:20 の数分。
  • 「再編成 + 復元 + 異常終了/クラッシュ復旧」が連続して起きた事故に見え、単発の通常ファイル書き込み1回で起きたものではない。

真の根因

「表面の操作」と「実際の破壊メカニズム」は分けて考える必要がある。

表面の操作

表面上は、ブックマーク整理、ブックマーク再編成、ブックマーク復元。

実際の破壊メカニズム

本当に災害を引き起こしたのは「ブックマーク内容そのもの」ではなく、次の組み合わせ：

  • 動作中の Chrome profile へのその場書き込み
  • その後も同じ live profile 上で操作を継続
  • その間に profile が異常中断 / クラッシュ復旧状態に入る
  • Chrome 再起動後、profile の一部しか復元されない

その結果、典型的に次が同時発生した：

  • ブックマークは一部残る
  • 旧サイトの IndexedDB / Local Storage も一部残る
  • Google アカウント同期後、拡張機能とブックマークがまたかなり戻る
  • しかしサイト Cookie、ログイン状態、保存済みログイン情報は一緒には戻らない

なぜ profile の切り替えミスではないのか

最初はこれが一番それっぽかったので、ここは別立てで明確にしておく。

profile を切り替え間違えた場合、通常は：

  • Local State に複数 profile が出る、または最近アクティブな profile が書き換わる
  • 重要 DB ファイルの作成日時が新しい
  • 旧サイトのローカル DB 痕跡が大量に消える

しかし今回の実態は：

  • Local State が Default しか認識していない
  • 重要ファイルの作成日時が古いまま 2025-05-27
  • 事故スナップショットに旧サイトのローカルストレージ痕跡が大量に残っている

よってこれは「別 profile を開いた」のではなく、「元のこの profile を壊した」。

なぜ Google に再ログインしても一部しか戻らないのか

この現象も証拠と整合する。

Google Sync が復元を手伝えるものは、たとえば：

  • ブックマーク
  • 一部の拡張機能インストール情報
  • 一部のアカウント関連設定

Google Sync が直接復元できないものは、たとえば：

  • ローカルのサイト Cookie
  • 大半のサイトのログインセッション
  • ローカルのログイン DB 内の状態
  • 拡張機能のランタイム即時状態

だから Google アカウントに再ログインすると見た目としては：

  • プラグイン数がかなり戻った
  • ブックマークもかなり戻った
  • でもサイトのログイン状態は戻らない

これは「二度目の事故」ではなく、事故後の同期が補えるのは一部で、Cookie / session は補えないだけ。

影響範囲

今回の事故で主に影響したのは：

  • サイトのログイン Cookie
  • 各サイトのログイン状態 / セッション
  • 保存ログイン DB の内容
  • 拡張機能の現在の実行状態

比較的、完全には消えなかった/同期で戻せたのは：

  • 同一 Default profile の主体構造
  • 一部のローカルサイトストレージ
  • 一部のブックマーク
  • 一部の拡張機能インストール情報

いま復旧手段はあるか

正直、より古い完全な Cookies / Login Data バックアップが見つからない限り、自動復旧はほぼ無理。

つまり：

  • ブックマークと拡張機能は、今後も同期で一部戻せる
  • 各サイトのログイン状態は、基本的に再ログインするしかない

だから今回一番痛いのは「ブックマークを壊した」ことではなく、「全ログイン状態をまとめて殺した」こと。

責任帰属

今回の責任は非常に明確。

Chrome が勝手に爆発したわけでも、ユーザーが profile を切り替え間違えたわけでもなく、私が Codex に「使用中の Chrome profile ファイル」を直接触らせたのが間違いだった。その後も同一 live profile で再編成と復元を続け、最後に異常中断の窓を踏んだ。

今後のハード制約

この件以降、Chrome のような live profile データは必ず以下を守る：

  1. 動作中の User Data\\Default を直接操作しない。
  2. どうしても変更するなら、Chrome 完全終了後にオフラインコピーを編集し、厳密に差分確認する。
  3. Chrome プロセスを強制終了してから profile ファイルへ書き戻すことを禁止する。
  4. ブックマーク整理は必ず profile 全体のバックアップを先に取り、Bookmarks だけのバックアップにしない。
  5. 以後はテスト用 profile で検証してから、メイン profile に触る。

最後に一言

これは「小さなミス」ではなく、「使用中のブラウザ profile を普通の設定ファイルとして改変する」ことで起きる、典型的な災害事例。責任も根因もはっきりしていて、原因調査も終わっている。