Microsoft Edgeの「Microsoft Edge: Improvements to site permissions user interfaces」は、サイト権限の許可・拒否・確認画面を分かりやすくするUI改善です。結論から言うと、権限そのものの種類やWeb APIの仕様変更ではなく、Webサイト上で権限を求められたときの表示、アドレスバー周辺、ページ情報ダイアログ、設定画面からの権限確認・変更のしやすさが変わります。管理者は、既存のサイト権限ポリシーが意図どおり効いているか、ヘルプデスクの案内文や社内手順が古い画面前提になっていないかを確認するのが重要です。(Microsoft)
公式情報では、対象サービスはMicrosoft Edge、ロードマップIDは552598、状態はIn development、一般提供は2026年6月、対象クラウドはWorldwide、プラットフォームはWebとされています。公式API上の更新日時は2026年6月2日23:00:40 UTCで、日本時間では2026年6月3日朝に相当します。なお、Microsoft 365ロードマップの予定や説明は変更される可能性があるため、展開前には最新のロードマップ情報を確認してください。(Microsoft) (Microsoft)
Microsoft Edgeのサイト権限UIで変わること
今回の変更点は、Microsoft Edgeの「サイト権限」をユーザーがより自然に理解し、必要な場面で確認・変更しやすくするためのUI改善です。公式説明では、権限を要求しているWebサイト上の文脈と、設定画面から権限へ移動した場合の両方で、見た目と動作をユーザーの期待に合わせるとされています。具体的には、権限を要求するWebサイトでのOmnibox、つまりアドレスバー周辺の表示、Page Infoダイアログ、設定画面での権限表示・変更が改善対象です。(Microsoft)
ここでいうサイト権限とは、Webサイトごとに許可・ブロック・確認を制御する設定です。代表例として、位置情報、通知、カメラ、マイク、ポップアップ、Cookie、JavaScript、クリップボード、WebUSB、WebHID、ローカルネットワークアクセスなどがあります。Microsoft Edgeのポリシー一覧では、これらの多くが「Content settings」や関連カテゴリとして管理対象になっています。(Microsoft Learn) (Microsoft Learn)
| 変更される領域 | 何が変わるか | 管理者・開発者が見るべきポイント |
|---|---|---|
| 権限要求時の表示 | Webサイトが位置情報・通知・デバイスなどの権限を求めたときの見え方や操作導線が変わる | ユーザーが「許可」「ブロック」「後で確認」を誤って選ばないよう、社内案内やFAQを更新する |
| Omnibox | アドレスバー周辺に表示される権限状態や関連アイコンの扱いが変わる | 従来の「鍵アイコンをクリック」前提の手順書が通用するか確認する |
| Page Infoダイアログ | サイト情報画面内の権限確認・変更の導線が変わる | ヘルプデスクが画面共有で案内する手順を再検証する |
| Settings内の権限管理 | 設定画面からサイト権限を確認・変更しやすくなる | 管理ポリシーでロックしている項目と、ユーザーが変更できる項目を切り分けて説明する |
重要なのは、今回のロードマップ項目だけを見る限り、権限ポリシーの名前やWeb標準APIの挙動そのものが変わるとは説明されていない点です。影響の中心は「ユーザーがどこで、どのように権限を確認・変更するか」です。そのため、セキュリティ設定の棚卸しよりも先に、ユーザー導線とサポート手順の更新が必要になります。
影響を受けやすい利用シーン
特に影響を受けやすいのは、ブラウザ上でカメラ、マイク、通知、位置情報、ローカルデバイス連携を使う業務です。UIが変わることで、ユーザーが「権限が拒否されているのか」「OS側でブロックされているのか」「管理者ポリシーで制御されているのか」を見分けにくくなる可能性があります。
Web会議・音声入力・録画ツール
Teams on the web、Web会議サービス、音声入力、ブラウザ録画ツールでは、マイクやカメラ権限の確認が頻繁に発生します。Microsoftのサポート情報でも、Edgeでマイクを使う場合は、ブラウザ設定のマイク権限画面で対象ドメインが許可されているか確認する手順や、アドレスバーのロックアイコンから権限を変更する手順が案内されています。UI変更後は、この「ロックアイコン」「権限表示」の見た目が変わる可能性があるため、社内マニュアルのスクリーンショット更新が必要です。(マイクロソフトサポート)
通知を使う業務アプリ
SaaS型のワークフロー、チャット、監視ツール、CRMなどでは、ブラウザ通知を使うことがあります。Edgeには通知の既定動作を制御するDefaultNotificationsSettingがあり、許可、ブロック、都度確認の選択肢をポリシーとして設定できます。未構成の場合はユーザーの設定に依存しますが、組織で通知を統制したい場合は、既定値とサイト別の許可・ブロックリストを確認しておくべきです。(Microsoft Learn)
位置情報を使う業務
配送、店舗検索、勤怠、現場報告など、位置情報を使うWebアプリも確認対象です。EdgeのDefaultGeolocationSettingでは、Webサイトによる物理的位置情報の追跡を既定で許可、ブロック、または都度確認にできます。未構成の場合はAskGeolocationが使われ、ユーザーが変更できるとされています。(Microsoft Learn)
社内ポータルや古い業務システム
ポップアップ、ファイル選択、クリップボード、Cookie、JavaScript、ローカルネットワークアクセスなどに依存する業務システムでは、ユーザーが権限を見直す機会が増える可能性があります。UIが分かりやすくなること自体は歓迎すべきですが、ユーザーが自己判断で必要な権限をブロックすると、帳票出力、ファイルアップロード、デバイス連携、通知受信が突然動かなくなることがあります。
管理者が最初に確認すべきこと
管理者が最初に行うべきことは、Edgeのサイト権限を「ユーザー任せにしている項目」と「組織ポリシーで制御している項目」に分けることです。UIが変わると、ユーザーは設定を見つけやすくなります。その一方で、管理ポリシーで制御されている項目をユーザーが変更できると誤解するケースも増えます。
| 確認項目 | 判断基準 | 実務上の対応 |
|---|---|---|
| 通知 | 業務アプリで通知が必須か、不要な通知を抑制したいか | 必須アプリは許可リスト、不要サイトはブロックリストを検討する |
| 位置情報 | 業務上必要なサイトが限定されているか | 必要サイトだけ許可し、それ以外は都度確認またはブロックを検討する |
| カメラ・マイク | Web会議や録画で利用頻度が高いか | OS側のプライバシー設定とEdge側のサイト権限をセットで案内する |
| ポップアップ | 社内システムが別ウィンドウ表示に依存しているか | 対象ドメインを洗い出し、業務影響があるサイトだけ許可する |
| クリップボード・USB・HID | 外部デバイスやコピー操作に依存する業務があるか | 利用部署・対象サイト・利用目的を明文化してから許可する |
| ユーザー向け手順書 | 古いEdge画面のスクリーンショットが残っていないか | UI変更後の画面で撮り直し、問い合わせの一次回答を更新する |
Microsoft Edgeのポリシーリファレンスでは、Edgeを組織内で構成するためのブラウザ関連グループポリシーが一覧化されており、Content settingsには通知、位置情報、Cookie、JavaScript、ポップアップ、WebUSB、WebHID、Window Managementなど多数のサイト権限関連ポリシーが含まれます。(Microsoft Learn)
サイト別の許可・ブロック設定を見直す
全社一律で「すべて許可」または「すべてブロック」にすると、運用でつまずきやすくなります。実務では、既定では慎重にし、業務で必要なサイトだけ例外許可する形が管理しやすいです。
たとえば通知の場合、Edgeには特定サイトの通知を許可するNotificationsAllowedForUrlsと、特定サイトの通知をブロックするNotificationsBlockedForUrlsがあります。これらはURLパターンのリストとして指定でき、未設定の場合はグローバルな既定値、またはユーザー個人の構成が使われます。(Microsoft Learn) (Microsoft Learn)
| 方針 | 向いているケース | 注意点 |
|---|---|---|
| 既定は都度確認 | 業務サイトが多様で、利用部門ごとに必要権限が異なる | ユーザーが誤ってブロックした場合の復旧手順が必要 |
| 既定はブロック、必要サイトだけ許可 | セキュリティ統制を重視する組織 | 新しいSaaS導入時に権限不足の問い合わせが増えやすい |
| 既定は許可、危険・不要サイトだけブロック | 利便性を優先する小規模環境 | 通知スパムや不要な位置情報共有を防ぎにくい |
| 部門別に許可リストを分ける | コールセンター、現場、開発部門など利用形態が異なる | Intuneやグループポリシーの対象設計が複雑になる |
判断に迷う場合は、「その権限が止まると業務が止まるか」「その権限を許可すると情報漏えい・端末連携・通知乱発のリスクがあるか」で優先度を決めます。カメラ・マイクは業務継続性、位置情報・通知・ローカルネットワークアクセスはプライバシーとセキュリティ、ポップアップはレガシーシステム互換性の観点で整理すると判断しやすくなります。
ユーザー向け案内で変えるべきポイント
今回のUI改善では、ユーザーがサイト権限を見つけやすくなる一方、ヘルプデスクの案内が古いままだと混乱が起きます。特に「アドレスバー左の鍵アイコンを押してください」「サイトの設定を開いてください」といった案内は、UI変更後の表示と一致するか確認が必要です。
Microsoftのサポート情報では、EdgeでWebサイトのカメラまたはマイク利用を止める手順として、Edgeの設定から「Privacy, search, and services」へ進み、「Site Permissions > All sites」で対象サイトを選び、CameraまたはMicrophoneをBlockにする方法が案内されています。UI変更後も考え方は同じですが、画面上の項目名や配置が変わる可能性があります。(マイクロソフトサポート)
ユーザー向けには、次のような説明にすると伝わりやすくなります。
Webサイトでカメラ、マイク、通知、位置情報が使えない場合は、Edgeのアドレスバー付近にあるサイト情報から権限を確認してください。見つからない場合は、Edgeの設定で「サイトのアクセス許可」または「サイト権限」を開き、対象サイトの許可状態を確認します。組織で管理されている項目は、ユーザー側で変更できないことがあります。
この案内では、特定のアイコン形状に依存しないのがポイントです。UI変更直後は、ユーザー環境やEdgeの更新状態によって表示差が出ることがあるため、「鍵アイコン」と断定するよりも「アドレスバー付近のサイト情報」と表現した方が安全です。
開発者が確認すべきテスト項目
Web開発者にとって今回の変更は、権限APIの破壊的変更というより、ユーザーが権限要求をどう認識するかに関わる変更です。つまり、動作確認だけでなく、権限要求のタイミングや説明文の見直しが重要になります。
| テスト項目 | 確認すること | 失敗しやすいポイント |
|---|---|---|
| 初回アクセス時の権限要求 | ユーザーが何のための権限か理解できるか | ページ表示直後に通知・位置情報・マイクを一度に求める |
| 拒否後の再案内 | 権限を拒否したユーザーに復旧手順を出せるか | 「ブラウザ設定を確認してください」だけで具体性がない |
| 管理ポリシー適用時 | ユーザーが変更できない状態を想定しているか | アプリ側で何度も許可を促し、問い合わせが増える |
| OS権限との切り分け | Windows側でカメラ・マイクが無効な場合を説明できるか | Edge側だけ許可してもデバイスが使えない |
| 複数ドメイン構成 | 認証、API、CDN、サブドメインごとの権限が想定どおりか | app.example.comでは許可済みだが、別サブドメインで再要求される |
| PWA・業務アプリ | インストール済みアプリ風の利用時も権限導線が分かるか | 通常ブラウザ画面とPWA画面で案内が一致しない |
特に避けたいのは、ユーザーがページの価値を理解する前に権限を求める設計です。たとえば、勤怠アプリで位置情報を使うなら、ログイン直後にいきなり許可を求めるのではなく、「打刻場所の確認に位置情報を使用します」と説明してから要求した方が誤拒否を減らせます。通知も同様に、「重要なお知らせを受け取るため」など、利用目的が明確なタイミングで要求するべきです。
展開前に管理者がやるべき実務チェックリスト
UI変更は小さく見えても、問い合わせの増加につながることがあります。展開前には、Edgeの設定、管理ポリシー、社内手順、業務アプリの4点をまとめて確認しましょう。
Edgeの管理ポリシーを確認する
まず、Intune、グループポリシー、レジストリ、Edge management serviceなど、どの経路でEdgeポリシーを配布しているかを確認します。Edgeのポリシーは、WindowsではSOFTWARE\Policies\Microsoft\Edge配下に設定されるものが多く、個別ポリシーのドキュメントにはADMXパス、レジストリパス、値の型が記載されています。たとえばDefaultGeolocationSettingやDefaultNotificationsSettingはいずれもContent settings配下のポリシーとして説明されています。(Microsoft Learn) (Microsoft Learn)
確認すべきポイントは次の通りです。
- 位置情報、通知、カメラ、マイク、ポップアップなど、業務影響が大きい権限を一覧化する
- 既定値が「許可」「ブロック」「確認」のどれになっているか確認する
- 例外許可・例外ブロックの対象ドメインを棚卸しする
- 廃止済み、旧式、重複したポリシーが残っていないか確認する
- ユーザーが変更できる項目と、管理者が固定している項目を分ける
検証環境で画面を撮り直す
UI改善の影響を受けるのは、管理コンソールだけではありません。むしろ問い合わせ対応では、ユーザーの画面とマニュアル画像が違うことが混乱の原因になります。Edgeの安定版に反映された段階で、以下の画面を撮り直すとよいでしょう。
| 画面 | 撮り直す理由 |
|---|---|
| 権限要求のポップアップ | ユーザーが許可・ブロックを選ぶ最初の画面だから |
| アドレスバー付近のサイト情報 | サポート時に最も案内しやすい入口だから |
| Page Infoダイアログ | サイト単位の権限確認で使う可能性が高いから |
| Edge設定内のサイト権限画面 | ユーザー自身で復旧する手順に必要だから |
| 管理ポリシーで変更不可の表示 | 「自分で変更できない」理由を説明するために必要だから |
スクリーンショットは、個人用プロファイル、職場または学校アカウントのプロファイル、管理ポリシー適用済み端末で分けて取得するのが理想です。同じEdgeでも、プロファイルやポリシー状態によって見え方が変わる場合があるためです。
ヘルプデスク向けの切り分け手順を作る
問い合わせ対応では、原因を「Webアプリ」「Edgeのサイト権限」「OSのプライバシー設定」「管理ポリシー」「外部デバイス」のどれかに切り分ける必要があります。
おすすめの順序は次の通りです。
| 順序 | 確認内容 | 例 |
|---|---|---|
| 1 | どのサイトで起きているか | Teams、社内ポータル、CRMなど |
| 2 | どの権限が必要か | マイク、カメラ、通知、位置情報 |
| 3 | Edgeのサイト権限が許可されているか | 対象サイトの権限画面を確認 |
| 4 | OS側でデバイス利用が許可されているか | Windowsのカメラ・マイク設定 |
| 5 | 管理ポリシーで固定されていないか | ユーザーが変更不可になっていないか |
| 6 | 別プロファイル・別端末でも再現するか | 個人プロファイルと業務プロファイルの差分確認 |
Windows側のカメラやマイク権限が無効だと、Edgeでサイト権限を許可していてもデバイスを利用できない場合があります。Microsoftのサポート情報でも、Windows 11では「Privacy & security」からCameraやMicrophoneのアプリ権限を確認する手順が案内されています。(マイクロソフトサポート) (マイクロソフトサポート)
移行・展開時に注意したいポイント
今回の変更は、ユーザー体験の改善が中心です。そのため、展開計画では「機能が使えるか」だけでなく、「ユーザーが迷わず正しい権限を選べるか」を確認する必要があります。
いきなり全社展開だけで判断しない
Edgeは更新が継続的に行われるため、全ユーザーで同時に同じ画面になるとは限りません。まずはIT部門、ヘルプデスク、業務アプリの主要利用部門で先行確認し、問い合わせが起きやすい権限を把握してから全社案内を出すと安全です。
「UI変更＝設定リセット」と誤解させない
今回の公式説明では、サイト権限UIの見た目や動作の改善が示されていますが、既存のユーザー権限設定や管理ポリシーがリセットされるとは説明されていません。ユーザー向けには、「画面の見え方が変わるが、組織で管理している設定は引き続き管理者ポリシーに従う」と説明すると混乱を避けられます。
管理ポリシーで固定した項目を説明する
管理ポリシーでブロックしている権限は、ユーザーがUI上で見つけやすくなっても変更できない場合があります。これは不具合ではなく、組織のセキュリティ設定です。問い合わせを減らすには、「この項目は会社のポリシーにより変更できません。利用が必要な場合は、対象サイトと利用目的を添えて申請してください」という案内を用意しておくと効果的です。
業務アプリの権限要求タイミングを見直す
開発者やSaaS管理者は、権限要求のタイミングを見直してください。サイトを開いた瞬間に複数の権限を求める設計は、UIが改善されてもユーザーに拒否されやすいままです。必要な場面で、必要な権限だけを、理由と一緒に求める設計に変えると、権限拒否によるトラブルを減らせます。
よくある勘違いと正しい理解
サイト権限の種類が増える変更ではない
今回のロードマップ説明は、サイト権限のUI改善に関するものです。新しい権限カテゴリの追加や、既存Web APIの仕様変更が明示されているわけではありません。新しい権限が増えるかどうかは、別のEdgeリリースノートやWeb標準の変更として確認する必要があります。
管理者ポリシーが不要になるわけではない
設定画面で権限を確認・変更しやすくなっても、企業環境では管理ポリシーが引き続き重要です。むしろ、ユーザーが権限画面を見つけやすくなることで、「なぜ変更できないのか」「どのサイトなら許可されるのか」という問い合わせが増える可能性があります。
ユーザーの操作ミスが完全になくなるわけではない
UIが分かりやすくなっても、ユーザーが誤ってブロックを選ぶことはあります。特に通知や位置情報は、利用目的が分からないと拒否されやすい権限です。アプリ側の説明、社内FAQ、ヘルプデスク手順を組み合わせて、拒否後の復旧ルートを用意しておく必要があります。
管理者・開発者別の対応まとめ
| 対象者 | まずやること | 次にやること |
|---|---|---|
| Microsoft Edge管理者 | サイト権限関連ポリシーを棚卸しする | 許可・ブロック・都度確認の方針を業務別に整理する |
| Intune・GPO担当者 | Edgeポリシーの配布経路と対象グループを確認する | 部門別の例外許可リストを必要最小限にする |
| ヘルプデスク | 旧UI前提のFAQとスクリーンショットを確認する | UI変更後の復旧手順を作り直す |
| Web開発者 | 権限要求のタイミングと説明文を見直す | 拒否後・管理ポリシー適用時の表示をテストする |
| 情シス責任者 | 業務停止リスクが高い権限を特定する | 全社展開前にパイロットユーザーで検証する |
いま取るべき次のアクション
Microsoft Edgeの「Improvements to site permissions user interfaces」は、セキュリティ機能の大幅変更というより、サイト権限をユーザーが理解しやすくするUI改善です。ただし、企業環境では小さなUI変更でも、Web会議が使えない、通知が届かない、位置情報が取得できない、社内システムのポップアップが開かないといった問い合わせにつながります。
まずは、通知、位置情報、カメラ、マイク、ポップアップの5つを優先して、現在のEdgeポリシーと例外設定を確認してください。次に、ヘルプデスクの手順書とユーザー向けFAQを、特定のアイコン名に依存しすぎない説明へ更新します。開発者は、権限を求める前に利用目的を明確に伝え、拒否された場合の復旧導線をアプリ内に用意しましょう。
この3点を先に済ませておけば、UI変更後もユーザーの混乱を抑えながら、Microsoft Edgeのサイト権限を安全かつ実用的に運用できます。
コメント