資金について：CypherpunkGuideは監視型広告を一切載せない——広告ネットワークも、トラッキングピクセルも、スポンサー記事もない。現在は読者からの寄付で運営し、将来は購読と編集方針に沿うアフィリエイト収入も充てる。私たちは広告主ではなく、読者に向き合う。
ブラウザ内蔵のパスワードマネージャー（アカウントの秘密情報を保存し、ログイン画面へ入力するソフトウェア）自体が、ただちに危険というわけではない。NIST SP 800-63B-4は、利用者が強力でサービスごとに異なるパスワードを使いやすくなるよう、NISTに準拠する認証サービスにパスワードマネージャーと自動入力を認めることを求めている。移行する理由はもっと具体的である。何を誰から守るか、どの障害で締め出されるおそれがあるかを整理した脅威モデルによっては、一つのブラウザアカウントから独立した保管庫（vault、認証情報をまとめて守るデータ置き場）、複数ブラウザへの対応、別系統の復旧方法、または暗号化データベースを自分で管理できる仕組みが必要になる。
注意すべきなのは、製品名よりも移行作業そのものだ。私は2026年8月3日、Google検索の上位5件、本文を読めた競合記事4本（平均2,512語）、そしてChrome、Edge、Firefox、Bitwarden、KeePassXC、NIST、FIDOの移行・認証・認証情報交換に関する公式資料を確認した。Google AI Modeは、CSV（項目をカンマで区切る表形式のファイル）へ書き出し、読み込み、行数を比べてファイルを消すという、一見十分な3段階の回答をすでに返していた。しかし、その手順は肝心な失敗を見逃している。
そこで、架空の認証情報だけを入れた12件の保管庫を二つ作り、パスワードを表示しない監査ツールで比較した。両方とも12行だったが、一致したのは11件だけである。移行先では、移行元の認証情報が1件欠け、その代わりに別の認証情報が1件重複していた。照合率は91.7%、判定はHOLD。URL、ユーザー名、パスワード、秘密情報から作ったフィンガープリント（照合用の要約値）は一つも出力していない。この結果をもとに、移行手順を7段階に組み直した。ツールの使い方を覚えるときは架空データを使い、切り替え中は移行元の保管庫を残し、実際のパスワード書き出しファイルをオンライン変換サイトやAIアシスタントへ渡してはいけない。
問題は「ブラウザだから危険」ではない#
パスワードマネージャーは、アカウントの秘密情報を保存して入力するソフトウェアである。「ブラウザなら危険、専用アプリなら安全」という分け方では足りない。信頼先、同期、復旧、締め出しの条件が、自分の脅威モデルに合う製品を選ぶ必要がある。
ブラウザに保存したパスワードも、各社が公開している端末とアカウントの保護機能で守られる。ただし、復旧方法や端末内で読める条件はブラウザごとに異なる。専用マネージャーへ移せば、同期の運用者、復旧方法、保管庫を共有できるブラウザと端末の範囲、自分で暗号化ファイルを管理するかどうかが変わる。一方で、侵害を受けたロック解除済み端末まで安全になるわけではない。どのマネージャーも、ログイン時には認証情報を使える状態にする必要があるからだ。
移行するなら、理由を具体的に決める。
- ブラウザからの独立： 複数のブラウザを使っている。または、ブラウザを替えるたびに認証情報を移したくない。
- 復旧経路の分離： Google、Microsoft、Mozillaの同じアカウントに、閲覧データとパスワード復旧の両方を握らせたくない。
- ローカルでの管理： 暗号化データベース、バックアップ、同期方法を自分で管理したい。
- 家族・チームでの共有： チャットやメールでパスワードを送らず、権限を管理できる共有機能を使いたい。
- 監査しやすさ： 認証情報の一覧や状態レポート、移行用の書き出しデータを使って、復旧計画を検証したい。
「ブラウザのパスワードはメモリ上で平文になる」という見出しだけで移行してはいけない。ロック解除済みのパソコンやスマートフォンでパスワードを使う以上、どこかでは復号される。保管庫の製品を替えても、マルウェア、画面キャプチャ、悪意ある拡張機能、端末への物理アクセスは残る。移行の目的は、特定の依存関係を減らすことだ。あらゆる攻撃を無効にすることではない。
パスキーも、パスワードとは別に棚卸しする必要がある。パスキーはウェブサイトごとに結びついた暗号学的な認証情報であり、CSVのパスワード行ではない。マネージャーを替える前に、パスキーの復旧手順を使い、どのパスキーが同期型か、端末固定型か、利用先サイトから復旧できるかを記録しておく。
BitwardenとKeePassXCは、どの失敗に備えるかで選ぶ#
Bitwardenは、複数端末の自動同期と公式モバイルアプリを重視する人に向く。KeePassXCは、KDBX形式の暗号化データベースをローカルで管理したい人に向くが、同期、バックアップ、競合処理、復旧も自分の責任になる。
Bitwardenは、ウェブ版、ブラウザ拡張機能、デスクトップ版、モバイル版、コマンドライン版からブラウザデータを読み込める。ChromeとEdgeからのインポート手順によると、読み込んだデータはサーバーへ送信される前に端末内で暗号化される。サーバー側から見える情報を減らす設計だが、Bitwardenアカウント、利用端末、マスターパスワードの扱い、二つ目の認証要素、サービスの稼働状況は復旧経路に残る。
対応するデスクトップ版には、手動でCSVを書き出さず、互換性のあるChromium系ブラウザから直接読み込む機能もある。対象は公式サイトから入手したWindows版とmacOS版、Linux向けの単体実行形式AppImageであり、アプリストア版は対象外だ。Windowsでは、資料に記載されたbitwarden_chromium_import_helper.exeに対し、ユーザーアカウント制御（UAC、OSが管理者権限を確認する画面）やEDR（端末上の不審な動作を監視するセキュリティ製品）が警告を出すことがある。先にインストーラーと署名を確認し、自分で操作を開始せよ。予期しない確認画面が出たら、プロセス名だけを信じず中止せよ。
KeePassXCは、認証情報を暗号化されたKDBX形式のデータベースファイルへ保存し、独自のクラウド同期サービスを持たない。公式マニュアルでは、ファイルをローカルに置く方法と、自分で選んだ同期先へ置く方法を説明している。事業者の同期アカウントを必須にしない代わりに、ファイルの競合、バックアップ、端末外の複製、データベースを開く鍵の復旧を自分で運用しなければならない。
| 判断項目 | Bitwarden | KeePassXC | 備えるべき故障 |
|---|---|---|---|
| 同期方式 | 事業者が暗号化同期を運用 | 利用者がKDBXファイルと任意の外部同期を運用 | サービス／アカウントの復旧、またはファイル喪失／同期競合 |
| 向く使い方 | 複数端末、モバイル利用、共有、手間の少ない運用 | デスクトップ中心、ローカル管理、独自のバックアップ設計 | 利便性か自己管理の利点だけを見て、必要な運用負担を見落とすこと |
| 移行時の読み込み | ブラウザ別CSV。対応環境では直接読み込み | CSVの列をプレビューし、項目を明示的に対応づけるウィザード | 重複作成、または列の対応ミス |
| 復旧で最後に頼るもの | アカウント情報、二つ目の認証要素、復旧計画 | KDBXファイル、マスターキー、任意のキーファイル／ハードウェア認証、バックアップ | 復旧に必要なものをすべて同じ端末へ置くこと |
| パスキーと時間ベースのワンタイムパスワード（TOTP、一定時間ごとに変わる認証コード） | 機能の対応状況とプラン制限を別々に確認。ブラウザCSVだけではどちらも確認できない | 機能の対応状況と利用先サイトとの互換性を別々に確認。ブラウザCSVだけではどちらも確認できない | パスワード行だけで、パスワード以外も移ったと判断すること |
| 日常の運用負担 | 同期基盤は事業者が運用 | 保存、同期、バックアップ、競合処理を自分で運用 | 「ローカル保存」を「自動バックアップ済み」と取り違えること |
監査を設計する前に、私は2026年3月10日公開の公式KeePassXC 2.7.12ポータブル版もダウンロードした。ファイル照合に使うZIPのSHA-256値は、配布元が公開した86718f7f47d7ca7f287de0260c567644c846e2a3e51ad2f93a76605178be9850と一致した。展開したKeePassXC.exeをWindowsのコード署名検証（Authenticode）にかけると、DroidMonkey Apps, LLCによる有効な署名と判定された。確認できるのは、私が調べたこのファイルだけである。すべてのミラー、将来の版、設定まで保証するものではない。同じ2.7.12のリリースノートには、パスキーのフラグを修正した影響で、既存の一部パスキーを利用先サイトが拒む可能性があるとの警告もある。パスキーも移行対象なら、移行元のログイン経路を残したまま、一つずつ動作を確かめる必要がある。
本番の切り替え前なら、選択はやり直せる。公式配布元から移行先のアプリをインストールし、架空の項目を一つだけ作って、ロック、解除、復旧を練習しておく。ほかの端末でも想定どおり動くか確認する。試験のためだけに、ブラウザの認証情報を消してはいけない。
ブラウザのCSVで移せるもの、証明できないもの#
ブラウザが書き出すCSVは、暗号化されていない受け渡し用ファイルである。ログイン項目は運べるが、パスキー、TOTPの秘密値、添付ファイル、カード、本人情報、独自項目、変更履歴、復旧情報、製品固有のメタデータまで移ったとは証明できない。
Googleは、ChromeのCSVに最低限入る列をurl、username、passwordと説明し、削除せずに残したファイルを手にした人は誰でもパスワードを読めると警告している。これらはパスワード行の項目であり、パスキーや移行先の読み込み結果を保証しない。MicrosoftもEdgeの書き出しに同じ平文の警告を出している。MozillaはFirefoxの書き出しファイルをアップロード、メール送信、共有しないよう求めている。
受け渡しファイルの限界と、移行先製品の限界は同じではない。Bitwarden独自のCSVにはlogin_totp列を入れられるが、カスタムファイルの読み込み資料によると、CSVが扱うのはログイン情報とセキュアノート（保管庫内で守るメモ）である。本人情報とカードにはJSON形式のファイルが必要で、添付ファイルは別に扱う。KeePassXCも、自身が書き出すCSVでは添付ファイル、高度な属性、自動入力（Auto-Type）の設定、独自アイコンを表現できないと警告している。そもそもブラウザがファイルへ入れていない情報を、移行先が読み込むことはできない。
| 棚卸しする種類 | パスワードCSVから確認できること | 別に確認すること | 秘密を漏らさない確認方法 |
|---|---|---|---|
| パスワードによるログイン | URL、ユーザー名、パスワード。場合により名前／メモ | 重複、空欄、URLの変化、移行元独自の項目 | 秘密情報を表示しない内容照合 |
| パスキー | 確認できない。パスワード行から網羅率を推測してはいけない | 保管元の事業者、利用先サイト、同期型／端末固定型、持ち出し可否 | 保管元と利用先サイトの認証情報一覧 |
| TOTPの秘密値 | 移行元が書き出し、移行先が対応づけた場合だけ | 読み込み後のコード生成、端末の時刻、復旧コード | 重要度の低いアカウントで、設定を壊さない形で確認 |
| 添付ファイル／独自項目 | 入らないか、情報が限られることが多い | 件数、種類、手動移行 | 移行先の項目を直接確認 |
| カード／本人情報／セキュアノート | ブラウザの書き出しには入らない場合がある | 製品独自のJSONまたは直接転送への対応 | 種類ごとに件数を分けて確認 |
| 復旧情報 | 保管庫に含まれると決めつけてはいけない | 二つ目の認証要素、復旧コード、緊急アクセス、データベースのバックアップ | 移行元を残したまま、新しいブラウザで復旧経路を確認 |
**Credential Exchange Protocol（CXP）**は、製品間で認証情報を直接交換するFIDOの仕様である。移行元と移行先の両方が対応していれば、平文ファイルを作る段階をなくせる。Bitwardenの現行資料には、対応するモバイル環境で、互換性のあるアプリからパスワードとパスキーを移すFIDO CXPの経路が記載されている。歓迎すべき改善だが、デスクトップ上のChrome、Edge、FirefoxとBitwarden、KeePassXCのどの組み合わせでも使える共通手順ではない。実際に使う移行元アプリ、移行先アプリ、OSがそろって対応しているか確かめる必要がある。
CXPが使えるなら利用し、それでも認証情報の種類ごとに棚卸しせよ。「CSVを使わない」ことで平文ファイルそのものを作らずに済むが、すべての種類と復旧経路が移った証明にはならない。
12件対12件でも、移行は完了していなかった#
行数が同じでも、保管庫の中身は一致しないことがある。移行先で1件が欠け、別の1件が重複すれば、合計は移行元と同じままだ。移行の確認では、総数だけでなく内容と認証情報の種類を比べなければならない。
同梱した実験データには、例示用に予約されたドメインと明らかな架空パスワードだけを使っている。ブラウザ形式の移行元には、重複のないログイン情報が12件ある。Bitwarden形式の移行先にも12行あるが、管理者用ログインを意図的に1件省き、別の項目を重複させた。
二つのファイルは、migration-audit.pyで比較した。このスクリプトは、対応するブラウザ、Bitwarden、KeePassXCのCSV見出しを共通形式へ整え、URL・ユーザー名・パスワードの組をメモリ内のSHA-256フィンガープリントとして比較する。フィンガープリントをファイルへ書かず、画面にも出さない。ただし、メモリを安全にゼロで上書きする機能はなく、使用したメモリはプロセス終了時にOSへ戻される。公開した監査結果には集計値しか含めていない。
このツールのPASSは、URL・ユーザー名・パスワードの組が一致したことだけを意味する。メモ、フォルダー、独自項目、パスキー、TOTP、添付ファイル、本人情報、カード、復旧情報まで移ったことは証明しない。
| 監査項目 | 結果 | 行数だけならどう見えるか |
|---|---|---|
| 移行元の行数 | 12 | 完了に見える |
| 移行先の行数 | 12 | 完了に見える |
| 完全に一致した認証情報 | 11/12（91.7%） | 見えない |
| 移行先にない認証情報 | 1 | 見えない |
| 移行先にだけある認証情報 | 1 | 見えない |
| 移行先で完全に重複した項目 | 1 | 見えない |
| 監査判定 | HOLD | 誤ってPASSになる |
この実験は、各社の読み込み機能をすべて再現したものではない。示しているのは検証方法の論理的な欠陥である。総数が同じでも、欠落は起こりうる。Bitwardenでは、重複が起きる可能性も無視できない。公式のインポートFAQによると、一致する項目がすでに存在しても、読み込みのたびに新しい項目が作られるからだ。
スクリプトはローカルだけで使う。実際のCSVには、アカウントへログインするための秘密情報が入っている。サポートへの添付、AIチャットへの貼り付け、このリポジトリへの保存、ウェブ上の「移行チェッカー」への送信はしてはいけない。実データを比較スクリプトへ読ませたくないなら、オフライン端末で少数を手作業で照合し、移行元を長めに残す。
パスワードマネージャーを移す7段階#
安全な移行は、順序を管理した切り替え作業である。認証情報を種類別に棚卸しし、復旧手段を準備し、移行先を検証し、一度だけ転送する。その後で内容を比較し、通常ログインと復旧を試し、最後に平文ファイルを消して古いマネージャーを退役させる。
- 総数ではなく種類ごとに棚卸しする。 パスワードによるログイン、パスキー、TOTP、セキュアノート、添付ファイル、本人情報、カード、復旧コードを分けて記録する。最初に見るのは、主要メール、パスワードマネージャー自体、携帯電話会社、金融、ドメイン登録事業者、クラウドストレージなど、失ったときの影響が大きいアカウントだ。SNSのセルフ監査と同じく、用途の異なる身元は分けて扱う。
- 製品を選ぶ前に、復旧が最後に何へ依存するかを特定する。 Bitwardenでは、アカウントのメールアドレス、マスターパスワード、利用できる二つ目の認証要素、2段階ログイン（2FA）の復旧コードを記録する。このコードで無効にできるのは2段階ログインだけであり、その後もマスターパスワードが必要だ。マスターパスワードを忘れた場合の資料によると、事前設定した代替手段が残っていなければ、Bitwardenの担当者が個人の保管庫を取り戻すことはできない。代替アクセスを当てにする前に、その手段が機能することを確認する。KeePassXCでは、KDBXの保存場所、マスターキー、任意で設定したキーファイルまたはハードウェア認証、端末外に置くバックアップ1つ以上、ファイル競合時の手順を記録する。すべてを持ち歩くノートパソコン1台に置いてはいけない。
- 移行先のインストーラーを検証し、架空データで練習する。 公式ドメインまたは署名付きリリースから入手し、配布元が示すチェックサムまたは署名を確認する。架空の保管庫を作り、実データを書き出す前に、ロック、解除、ブラウザ連携、バックアップからの復元を確かめる。
- 平文データに触れる範囲が最も小さい公式手順を選ぶ。 移行元、移行先、インストール経路、認証情報の種類、実際に使うOSのすべての条件がそろうときは、確認済みの直接読み込みまたはCXPを優先する。Bitwardenの対応デスクトップ版による直接読み込みなら、ブラウザCSVを手動で作らずに済む。ただし、パスキーや他のすべての種類まで移ったとは証明できない。ファイルが必要なら、信頼できる端末上の、自動同期されない暗号化ローカルストレージへ一度だけ作る。コピーを生みそうなチャット、クラウドドライブ、バックアップ、索引作成、エディターを閉じ、正確な保存先を記録する。Coraの調査に使うブラウザ、AIの入力欄、オンライン変換サイトへ実際の秘密情報を渡してはいけない。
- 転送は一度だけ行い、結果を確認する。 正しい移行元または直接読み込み経路を選ぶ。KeePassXCでは、確定前にCSV列のプレビューと項目の対応を確認する。CSV自体は暗号化されていない。Bitwardenは、直接読み込みでもファイル読み込みでも重複を検出しない。エラーが出たら止める。「今度は入るかもしれない」と何度も実行してはいけない。
- 内容と種類を確かめる。 認証情報を画面やログへ出さずに内容を比較し、影響の大きいアカウントはすべて手作業でも確認する。パスキー、TOTP、添付ファイルは別々に数える。行数の一致は一つの参考値にすぎない。移行元の認証情報が一つでも欠ける、予期しない重複がある、パスワード以外の種類について確認済みの移行経路がない——どれかに当てはまれば判定は
HOLDだ。 - ログインと復旧を試し、観察してから旧環境を退役させる。 新しいブラウザプロファイルを使い、重要度の低いアカウントをいくつか試し、影響の大きいアカウントをすべて確認する。移行元を消さず、既存のログイン済みセッションからもログアウトせず、繰り返せる復旧手順を実行する。1回限りのコードは、保管した複製を取り出せることと、公式手順を参照できることを確認する。意図的に使用し、再発行または交換後のコードを保存した場合に限り、機能まで確認済みと呼べる。短い観察期間には、古い保管庫を読み取り専用で残す。成功を確認してから、ブラウザの保存機能を無効にし、移行元の項目を消す。ファイルで移した場合は、見つけられる平文の複製をすべて削除する。
この順序は、ログインできる状態を守る。読み込みが誤っていれば、移行元へ戻れる。復旧に問題があれば、既存のログイン済みセッションから修復できる。CSVが同期フォルダーへ複製されていても、ローカルの1ファイルを消しただけで完了と考える前に発見できる。
同じ移行中に、復旧用の電話番号まで軽い気持ちで変更してはいけない。日常ログインに使わなくなった番号でも、アカウント復旧には残っている場合がある。電話番号のプライバシーモデルで、その依存関係を先に整理しておく。
CSVを消しても、完全消去とは限らない#
平文CSVの削除は露出を減らすが、削除操作だけでは、物理媒体、同期先、検索用索引、バックアップ、プレビューに複製が残っていないと証明できない。最も有効なのは、書き出す前に余計な複製を防ぎ、ファイルが存在する時間を短くすることだ。
Google、Microsoft、Mozilla、Bitwarden、KeePassXCはいずれも、パスワードの書き出しファイルは平文で読めると警告している。MicrosoftはEdgeからの移行後にSHIFT+DELETEを使うよう具体的に勧めている。Windowsのごみ箱を経由しない削除方法だが、SSD、クラウド同期の履歴、バックアップ、自分で管理できないストレージから、デジタル鑑識でも復元できないほど完全に消えたことを保証するものではない。
削除時は、次の場所を確認する。
| 場所 | 確認すること | 対応 |
|---|---|---|
| 指定した書き出し先 | 正確なファイル名と更新日時 | 監査と復旧試験の成功後に削除 |
| ダウンロード／デスクトップ／ドキュメント | 誤って2回目を書き出していないか | 確認できた複製だけを削除 |
| クラウド同期フォルダーと版の履歴 | 保存先が同期されたか | 事業者の公式手順でリモート側の版を削除 |
| ごみ箱 | 通常の削除を使ったか | 対象を確認してごみ箱から削除する。ただし媒体の完全消去とは考えない |
| エディター、表計算ソフト、プレビュー | 最近使ったファイル、自動保存、一時コピー | 書き出し前に閉じ、確認できた一時ファイルを消す |
| バックアップと時点保存の複製（スナップショット） | バックアップ対象だった時間帯にファイルが存在したか | 保存期間の規則に従う。削除を確認できなければ、そのファイルに入っていたパスワードを変更 |
実際のCSVがメール、チャット、AIサービス、公開リポジトリ、信頼できない変換サイトへ渡った可能性があるなら、パスワードは漏れたものとして扱う。証拠を残し、影響の大きい認証情報から変更し、必要に応じてセッションを無効にして、棚卸しの順に対処する。すでに複製された秘密情報は、移行先の保管庫へ入れても非公開には戻らない。AIアシスタントのプライバシー監査で説明したとおり、チャット入力欄は記録を残す場所であり、安全な受け渡し経路ではない。
結論——どの移行経路を選ぶべきか#
サービス事業者のアカウントへの依存を受け入れても、管理型同期と日々の手間の少なさを重く見るならBitwardenを選べ。バックアップと同期を自分で運用しても、ローカル管理を優先するならKeePassXCを選べ。どちらでも、内容と復旧経路を確認せよ。
| 優先したいこと | 最初の候補 | 必須の備え |
|---|---|---|
| 複数端末で自動同期 | Bitwarden | マスターパスワードの保管・復旧計画、別に保管した2FA復旧コード、確認済みのアクセス経路 |
| ローカルの暗号化データベース | KeePassXC | 端末外のKDBXバックアップと確認済みの復元手順 |
| 移行中の露出を最小化 | 資料に明記された直接読み込みまたはCXP | 移行元、移行先、インストール経路、OS、認証情報の種類ごとに対応範囲を確認 |
| ブラウザだけで簡単に使う | ブラウザのマネージャーを使い続ける | 端末とアカウントを強く守り、復旧を確認。移行は必須ではない |
| 高リスクまたは複雑な保管庫 | 段階的な移行 | 少量ずつ移し、重要項目を手作業で確認し、読み取り専用の移行元を長めに残す |
「書き出して、うまくいくよう願う」で終わらせるな。認証情報を種類ごとに把握し、ファイルで表現できないものを知り、一度だけ読み込み、秘密を漏らさず内容を比較し、復旧を試してから古い経路を止めよ。製品選びも重要だが、切り替え方はそれ以上に重要である。
よくある質問#
移行で誤りやすいのは、製品選び、件数による確認、パスキーの扱い、平文ファイルの片づけ、SSDや同期ストレージからCSVを削除する限界の5点である。
BitwardenはChromeのパスワードマネージャーより安全ですか？#
一概には言えません。Bitwardenへ移すと、保管庫をブラウザの仕組みから分けられ、複数のクライアントや共有機能を使えるため、信頼先と復旧方法が変わります。Google中心の使い方なら、Chromeのほうが単純な場合もあります。製品名だけで安全性を決めず、ロック解除済み端末での危険、アカウント復旧、同期への依存、移行失敗の影響を比べてください。
KeePassXCはオフラインだからBitwardenより安全ですか？#
必ずしもそうではありません。KeePassXCには必須のクラウド同期アカウントがありませんが、KDBXファイル、バックアップ、同期、競合、復旧を自分で管理する必要があります。ローカルに1つしかないファイルは、自主管理ではなく単一障害点です。Bitwardenの管理型同期には異なるリスクがあるだけで、必ずしも大きいわけではありません。
読み込み件数が一致したら、CSVを削除してよいですか？#
いいえ。同じ件数でも、1件の欠落と1件の重複が隠れていることがあります。認証情報の中身を比較し、影響の大きいアカウントを確認し、パスキーとTOTPを別に数え、通常ログインと復旧を試してから、受け渡しファイルと移行元の保管庫を削除してください。
ChromeのパスワードCSVにパスキーも入りますか？#
パスワード行の件数を、パスキーが移った証拠にしないでください。Googleが示すCSVの最低限の列はURL、ユーザー名、パスワードです。パスキーは、保管元の事業者ごとに持ち出しの条件が異なります。パスキーを別に棚卸しし、移行元と移行先が実際に使うOS上で明示的に対応している場合だけ、CXPを使ってください。
SSD上のパスワードCSVは、安全に上書き消去すべきですか？#
1回の上書きや削除で、SSD、同期先、バックアップ、プレビューにあるすべての複製が消えるとは約束できません。自動同期されない暗号化ローカルストレージを使って複製を防ぎ、ファイルが存在する時間を短くしてください。確認できた複製を削除し、同期履歴を調べ、漏れを否定できない場合は認証情報を変更してください。
出典#
次の公式資料と一次資料12件は、2026年8月3日時点の移行に関する主張を支える。11件には、対象ページと日時が一致するアーカイブがある。Edgeの現行資料だけは同日時点で完全に一致する保存版がなく、その欠落をワイルドカードのURLで隠していない。
