Microsoft Edgeの「カスタム プライマリ パスワード」を使って保存済みパスワードを保護していた組織は、Edge 149への更新を機に対応が必要です。2026年6月4日公開のMicrosoft Edge Stable 149.0.4022.52では、ユーザーが新しいカスタム プライマリ パスワードを作成できなくなり、既存ユーザーもデバイス認証へ自動移行されます。あわせて、管理ポリシー PrimaryPasswordSetting の WithCustomPrimaryPassword オプションも使い続ける前提では運用できなくなります。(Microsoft Learn)
特に確認すべきなのは、「Edgeのパスワードマネージャーを使っているか」「PrimaryPasswordSetting をGPO、Intune、MDM、macOS構成プロファイルで配布していないか」「ユーザーにWindows HelloやmacOS Touch IDなどのデバイス認証が使える状態になっているか」の3点です。この記事では、Microsoft EdgeのPrimary Password廃止について、変更点、影響範囲、管理者・開発者が確認すべき移行チェックリストを実務向けに整理します。
Microsoft EdgeのPrimary Password廃止で何が変わるのか
今回の変更は、Microsoft Edgeのパスワードマネージャーにある「Custom Primary Password」、つまりユーザーがEdge専用に作成していたカスタム保護パスワードの廃止です。
Microsoftの案内では、2026年3月5日から新規ユーザーにはCustom Primary Passwordが利用できなくなり、2026年6月4日以降は既存の利用者もデバイスベース認証へ自動的に移行されます。移行後は、Windows Hello、Windowsのサインイン情報、macOS Touch ID、OSレベルの認証などで保存済みパスワードの表示・自動入力を保護する形になります。(マイクロソフトサポート)
変更前と変更後の違い
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 保存済みパスワードの保護 | Edge専用のカスタム プライマリ パスワードを設定可能 | デバイス認証へ移行 |
| 新規作成 | edge://settings/autofill/passwords/settings から作成可能 | 新規作成不可 |
| 既存ユーザー | Custom Primary Passwordで認証 | デバイス認証へ自動移行 |
| 管理ポリシー | PrimaryPasswordSetting で WithCustomPrimaryPassword を指定可能 | WithCustomPrimaryPassword はサポート対象として扱えない |
| ユーザー体験 | Edge専用パスワードを入力 | Windows Hello、PIN、指紋、顔認証、OSパスワードなどで認証 |
ここで重要なのは、保存済みパスワード機能そのものが廃止されるわけではない点です。廃止されるのは、Edge独自の「カスタム プライマリ パスワード」です。パスワードの保存、自動入力、デバイス認証による保護は引き続き利用できます。
影響を受ける環境
影響が大きいのは、社内標準ブラウザとしてMicrosoft Edgeを配布し、パスワードマネージャーの挙動をポリシーで制御している企業・学校・自治体などの管理環境です。
特に次の環境では確認が必要です。
| 対象 | 確認すべき理由 |
|---|---|
| Edgeの保存済みパスワードを業務利用している端末 | 自動入力時の認証方法が変わる可能性がある |
| GPOでEdgeポリシーを管理しているWindows端末 | PrimaryPasswordSetting の値が古いまま残る可能性がある |
| IntuneやMDMでEdge設定を配布している端末 | 構成プロファイル内に廃止対象の値が残る可能性がある |
| macOSでEdgeを管理している環境 | Touch IDやOS認証を前提にした運用確認が必要 |
| ヘルプデスク・情シス部門 | ユーザーから「Edgeのパスワード入力画面が変わった」と問い合わせが来る可能性がある |
| Webアプリ開発・検証チーム | 認証フォームや自動入力の検証条件が変わる可能性がある |
一方で、Edgeのパスワード保存機能を無効化している組織や、社内で専用のパスワードマネージャーを標準化している組織では、ユーザー影響は比較的小さいと考えられます。ただし、ポリシーの棚卸しは必要です。古い設定が残っていると、将来のトラブル調査で原因の切り分けが難しくなります。
管理者がまず確認すべきPrimaryPasswordSettingポリシー
Microsoft Edgeでは、保存済みパスワードの自動入力前に認証を求める設定を PrimaryPasswordSetting ポリシーで制御できます。このポリシーはWindowsとmacOSでサポートされ、Windowsではグループポリシーの「Administrative Templates/Microsoft Edge/Password manager and protection」配下、レジストリでは SOFTWARE\Policies\Microsoft\Edge の PrimaryPasswordSetting として扱われます。(Microsoft Learn)
PrimaryPasswordSettingの主な値
| 値 | 設定名 | 今後の扱い |
| -: | ————————— | ———————— |
| 0 | Automatically | 自動入力時に追加の認証フローを使わない設定 |
| 1 | WithDevicePassword | デバイス認証を使う設定。移行先の有力候補 |
| 2 | WithCustomPrimaryPassword | 廃止対象。今後この値に依存した運用は避ける |
| 3 | AutofillOff | 保存済みパスワードの自動入力候補を表示しない設定 |
これまで WithCustomPrimaryPassword を使っていた組織は、基本的に WithDevicePassword へ移行するか、パスワード自動入力を使わせない方針であれば AutofillOff を検討します。どちらを選ぶべきかは、セキュリティポリシーとユーザーの業務実態で判断します。
移行先は「デバイス認証」が基本
Microsoftは、Custom Primary Passwordの代替としてデバイスベース認証を案内しています。具体的には、Windows Hello、PIN、顔認証、指紋認証、macOS Touch ID、OSのサインインパスワードなどです。Edgeのポリシー説明でも、WithDevicePassword を設定すると、保存済みパスワードの自動入力前にデバイス認証を求める挙動になるとされています。(Microsoft Learn)
実務上は、単にポリシー値を変更するだけでは不十分です。デバイス認証が使えない端末、共有PC、VDI、リモートデスクトップ環境、キオスク端末では、ユーザー体験や認証フローが想定どおりにならない場合があります。
判断基準
| 組織の方針・環境 | 推奨される対応 |
|---|---|
| Edgeのパスワードマネージャーを許可している | WithDevicePassword へ移行し、デバイス認証を標準化する |
| パスワード管理ツールを別途導入している | Edgeの保存・自動入力を無効化する方針も検討する |
| 共有端末が多い | 個人プロファイルの分離、OSログイン管理、自動入力制限を確認する |
| BYODや非管理端末がある | ユーザー案内と条件付きアクセス、MAM方針との整合を確認する |
| ヘルプデスク負荷を抑えたい | Edge更新前にFAQと画面付き手順を配布する |
おすすめは、「Edgeのパスワード保存を許可する端末」と「許可しない端末」を分けて考えることです。全社一律で変更すると、現場の業務フローと合わない可能性があります。
管理者向け移行チェックリスト
Edge 149以降の展開前後で、管理者は次の順に確認すると抜け漏れを減らせます。
| 手順 | 確認項目 | 具体的な作業 |
| -: | ———- | ———————————————————- |
| 1 | 現在のポリシー確認 | GPO、Intune、MDM、macOS構成プロファイルで PrimaryPasswordSetting を検索 |
| 2 | 廃止対象値の洗い出し | WithCustomPrimaryPassword または値 2 が残っていないか確認 |
| 3 | 移行方針の決定 | WithDevicePassword にするか、AutofillOff にするかを決める |
| 4 | デバイス認証の確認 | Windows Hello、PIN、Touch ID、OSパスワードの利用状況を確認 |
| 5 | テスト展開 | IT部門や一部部署でEdge更新後の自動入力・認証を検証 |
| 6 | ユーザー周知 | 「Edge専用パスワードではなく端末認証に変わる」と説明 |
| 7 | 本番展開 | Edge Stable 149以降の更新スケジュールに合わせて展開 |
| 8 | 問い合わせ対応 | 認証画面の変化、自動入力できないケース、Windows Hello未設定端末を切り分ける |
特に見落としやすいのは、複数の管理経路に同じポリシーが残っているケースです。たとえば、GPOでは修正済みでも、Intuneの構成プロファイルに古い値が残っていると、端末側では意図しない設定が適用されることがあります。
展開前に確認したい実務上の注意点
Edgeの更新タイミングにばらつきが出る
Microsoft EdgeのStable Channel更新は、すべての端末に同時に反映されるとは限らず、段階的にロールアウトされます。Microsoftのリリースノートでも、Stable Channelの更新は1日以上かけて段階的に展開されることがあると説明されています。(Microsoft Learn)
そのため、同じ社内でも「ある端末ではCustom Primary Passwordが消えたが、別の端末ではまだ表示される」という状態が一時的に発生する可能性があります。ヘルプデスク向けには、Edgeのバージョン確認手順を用意しておくと切り分けが早くなります。
確認場所の例：
edge://settings/helpここでMicrosoft Edgeのバージョンを確認し、Edge 149以降かどうかを見ます。
ユーザーには「セキュリティが弱くなる」と誤解されやすい
Custom Primary Passwordがなくなると聞くと、「追加のパスワードが消えるので安全性が下がる」と受け止めるユーザーがいます。しかし、移行先は端末の認証機能です。Windows HelloやTouch IDを適切に設定している環境では、OSの認証基盤を使って保存済みパスワードを保護する形になります。
周知文では、次のように説明すると混乱を抑えられます。
Microsoft Edgeの保存済みパスワードを使う際の確認方法が変わります。
これまでEdge専用のパスワードを使っていた方は、今後Windows Hello、PIN、指紋認証、顔認証、端末のサインイン情報などで確認する方式に切り替わります。
保存済みパスワード機能自体が廃止されるわけではありません。共有PCではプロファイル運用を見直す
共有PCでEdgeのパスワード保存を許可している場合は、今回の変更を機に運用を見直すべきです。デバイス認証が使われるようになっても、OSアカウントを共有している環境では、認証の意味が弱くなる場合があります。
共有端末では、少なくとも次の点を確認してください。
- ユーザーごとにWindowsアカウントを分けているか
- Edgeプロファイルを個人ごとに分けているか
- 退職者・異動者の端末サインイン情報が残っていないか
- 保存済みパスワードの同期を許可する範囲が明確か
- 業務システムのパスワードをブラウザに保存してよいか
共有アカウントで業務システムにアクセスしている場合、Edgeの設定だけで安全性を担保するのは困難です。アカウント管理、端末管理、認証ポリシーを合わせて見直す必要があります。
開発者・Web担当者が確認すべきこと
今回の変更は主にブラウザ側のパスワード保護機能に関するものですが、Webアプリの開発・検証にも影響する可能性があります。
特に、ログインフォーム、自動入力、パスワード変更画面、社内SSO連携を持つWebアプリでは、Edge 149以降で実際のユーザー操作を確認しておくと安心です。
検証すべきポイント
| 検証項目 | 確認内容 |
|---|---|
| ログインフォーム | Edgeの保存済みパスワード候補が想定どおり表示されるか |
| 自動入力前の認証 | デバイス認証後にID・パスワードが入力されるか |
| パスワード変更画面 | 新しいパスワード保存・更新の案内が正常に出るか |
| SSO環境 | Microsoft 365や社内IdPとの認証フローに支障がないか |
| E2Eテスト | テスト自動化がブラウザの認証プロンプトで止まらないか |
| ユーザーサポート | 画面変更により手順書のスクリーンショットが古くなっていないか |
開発者が注意すべきなのは、「自動入力が動かない」と報告されたときに、Webアプリ側の不具合と決めつけないことです。Edgeのポリシー、ユーザーのプロファイル状態、OS側の認証設定、保存済み資格情報の有無によって挙動が変わります。
移行時に起きやすいトラブルと対処法
「Edge専用のパスワード入力画面が出なくなった」
これは今回の変更による想定内の挙動です。Custom Primary Passwordは廃止され、デバイス認証へ移行されます。ユーザーには、Windows Hello、PIN、指紋認証、顔認証、端末パスワードなどで認証するよう案内します。
「保存済みパスワードが自動入力されない」
まず、Edgeのパスワード自動入力が有効か確認します。次に、管理ポリシーで AutofillOff が適用されていないか、または別のパスワード管理方針が適用されていないか確認します。
ユーザー側の確認場所の例：
edge://settings/passwordsまたは、Microsoftの案内に沿って、Edgeの「設定」から「Passwords and autofill」関連の設定を確認します。Microsoft Supportでは、保存済みパスワードの保護方法として、Edgeの設定画面からデバイスサインインオプションを使う設定に切り替える手順を案内しています。(マイクロソフトサポート)
「ポリシーを変更したのに端末に反映されない」
Windows環境では、GPO、Intune、ローカルレジストリ、Edge管理テンプレートのバージョン差を確認します。macOSでは、構成プロファイルに古いキーや値が残っていないかを確認します。
Edgeポリシーの反映状況は、次の内部ページで確認できます。
edge://policyPrimaryPasswordSetting が表示される場合は、値と適用元を確認します。古い値が残っている場合、管理コンソール側だけでなく、端末側のポリシー更新状態も確認してください。
「Windows Helloを設定していないユーザーが混乱している」
デバイス認証への移行では、ユーザーが普段使っている端末サインイン方法が重要になります。Windows Helloを必須にしている組織であれば、未設定ユーザーを事前に洗い出すと移行がスムーズです。
最低限、次の案内を用意しておくと問い合わせを減らせます。
- Windows HelloまたはPINの設定手順
- 指紋・顔認証が使えない端末での代替手順
- パスワード自動入力時に表示される認証画面の例
- 認証に失敗した場合の問い合わせ先
セキュリティ方針として見直したいポイント
今回のPrimary Password廃止は、単なる機能削除ではなく、ブラウザ内の独自パスワードからOSレベルの認証へ寄せる流れと考えると理解しやすくなります。
管理者は、次の観点でEdgeのパスワード管理方針を見直すとよいでしょう。
Edgeのパスワード保存を許可するか
業務システムのパスワードをブラウザに保存してよいかは、組織のセキュリティ方針によって異なります。許可する場合は、デバイス認証、端末暗号化、OSアカウント管理、退職者対応まで含めて設計します。
許可しない場合は、AutofillOff や PasswordManagerEnabled など関連ポリシーも含めて、保存・自動入力・同期の扱いを整理します。Edge 148のリリースノートでは、パスワード関連機能の制御に PasswordManagerEnabled と PrimaryPasswordSetting を組み合わせる必要がある場面にも触れられています。(Microsoft Learn)
OS認証の強度を確保する
デバイス認証へ移行するなら、OSサインインが弱いままでは意味が薄れます。短すぎるPIN、共有アカウント、ロックされない端末、退職者アカウントの放置などがあると、Edge側の認証方式を変えてもリスクは残ります。
確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| 端末ロック | 一定時間で自動ロックされるか |
| Windows Hello | 利用対象者・必須化範囲が明確か |
| PINポリシー | 桁数や複雑さが組織方針に合っているか |
| 共有アカウント | 業務上必要な例外か、廃止できるか |
| 退職・異動対応 | OSアカウントとEdgeプロファイルが適切に削除されるか |
ユーザー教育を軽視しない
管理者側でポリシーを正しく設定しても、ユーザーが「何が変わったのか」を理解していないと問い合わせが増えます。特に、認証画面の見た目が変わる変更は、セキュリティインシデントと誤解されることがあります。
社内告知では、次の3点に絞ると伝わりやすくなります。
- Edgeの保存済みパスワード機能は継続される
- Edge専用のカスタム パスワードは廃止される
- 今後は端末のサインイン方法で本人確認する
期限前後の推奨対応スケジュール
すでに2026年6月4日の移行期限に到達しているため、今から対応する場合は「事前準備」ではなく「現状確認」と「残存設定の解消」が中心になります。
| タイミング | 対応内容 |
|---|---|
| すぐ | PrimaryPasswordSetting の配布状況を確認 |
| すぐ | WithCustomPrimaryPassword または値 2 の残存を洗い出す |
| 1週間以内 | Edge 149以降の端末で自動入力とデバイス認証を検証 |
| 1週間以内 | ヘルプデスク向けFAQを作成 |
| 展開後 | edge://policy とユーザー問い合わせ内容をもとに設定漏れを修正 |
| 継続対応 | Edgeリリースノートと管理テンプレート更新を定期確認 |
特に大規模環境では、すべての端末が同時にEdge 149へ更新されるとは限りません。段階的な展開状況を前提に、バージョン別の問い合わせ対応を用意しておくと混乱を避けられます。
まとめ：Primary Password廃止はポリシー棚卸しの好機
Microsoft EdgeのPrimary Password廃止では、Custom Primary Passwordが使えなくなり、保存済みパスワードの保護はWindows HelloやmacOS Touch IDなどのデバイス認証へ移行します。Edge 149では新規作成ができず、既存ユーザーも自動的にデバイス認証へ移行されます。管理者は、PrimaryPasswordSetting の WithCustomPrimaryPassword に依存した設定が残っていないかを早急に確認すべきです。
次に取るべき行動は明確です。まず edge://policy、GPO、Intune、MDM、macOS構成プロファイルで PrimaryPasswordSetting を確認します。次に、移行先を WithDevicePassword にするのか、パスワード自動入力を制限するのかを決めます。最後に、ユーザー向けに「Edge専用パスワードから端末認証へ変わる」という案内を出し、ヘルプデスクが問い合わせに対応できる状態を整えましょう。
コメント