Microsoft IntuneでMicrosoft Edge version 77以降を展開・更新する場合、今回押さえるべき結論は「Intune単体の新機能追加」ではなく、Configuration ManagerでEdgeの展開・更新を管理する際の前提条件と設定確認が重要という点です。特に、PowerShell実行ポリシー、Microsoft Edgeの自動更新方針、ソフトウェア更新ポイントの同期設定、グループポリシーとの競合、管理ダッシュボード用のインベントリ設定は、展開失敗や更新漏れにつながりやすい確認ポイントです。公式ドキュメントでは、Microsoft Edge version 77以降をConfiguration Managerから展開でき、選択したEdgeビルドのインストールにはPowerShellスクリプトが使われると説明されています。(Microsoft Learn)
Microsoft Intuneの「Deploy and update Microsoft Edge, version 77 and later – Configuration Manager」は何が変わるのか
今回の公式情報で確認すべきポイントは、Microsoft Intune管理下のWindows端末に対して「Edgeをどう配布するか」だけではありません。Configuration Managerを使っている組織では、Edgeの初回展開、更新管理、監視、既存ポリシーとの整合性まで含めて見直す必要があります。
GitHub上のMicrosoftDocsリポジトリでは、該当ドキュメントに対して2026年5月18日に「Add SFI ms.custom values」というコミットがあり、該当ファイルにも1行追加が含まれています。差分の性質としては、手順そのものを大きく変える機能変更というより、ドキュメントのメタデータ・分類に関する更新と見るのが妥当です。(GitHub)
ただし、管理者にとって重要なのは「本文が大きく変わったか」だけではありません。Edgeの更新はセキュリティ対応と直結するため、Configuration Manager管理に寄せるのか、Edge自身の自動更新に任せるのかを明確にしないと、更新タイミングが部署や端末ごとにばらつきます。
対象になる管理者と環境
この情報の主な対象は、Configuration Manager Current Branchを使ってMicrosoft Edge version 77以降を展開・更新している管理者です。Microsoft Learnの該当ページも、適用対象をConfiguration Manager Current Branchとしています。(Microsoft Learn)
特に影響を受けやすいのは、次のような環境です。
| 対象環境 | 確認すべき理由 |
|---|---|
| Configuration ManagerでEdgeをアプリとして展開している環境 | PowerShell実行ポリシー、コンテンツ配置、配布ポイント、ログ確認が必要 |
| Edge更新をConfiguration Managerのソフトウェア更新として管理している環境 | Updates分類とMicrosoft Edge製品の同期設定が必要 |
| IntuneとConfiguration Managerを併用している環境 | Intune配布、ConfigMgr配布、グループポリシーの役割分担が曖昧になりやすい |
| グループポリシーでEdge Updateを制御している環境 | Configuration Managerで指定した更新設定をGPOが上書きする可能性がある |
| Edgeの展開状況をダッシュボードで可視化したい環境 | WebView2拡張機能やハードウェアインベントリ設定が必要 |
Microsoft IntuneだけでEdgeを展開する場合は、Intune管理センターから「Microsoft Edge version 77 and later」のアプリ種類を選択してWindows端末へ割り当てできます。一方、Configuration Managerのドキュメントは、オンプレミス管理基盤を使ってEdgeを展開・更新するケースを扱っています。IntuneとConfiguration Managerのどちらを主に使うかで、確認すべき場所が変わります。(Microsoft Learn)
まず整理すべきポイントは「展開」と「更新」の分離
Microsoft Edgeの管理では、初回インストールと更新管理を分けて考える必要があります。
初回展開では、管理者がBeta、Dev、Stableなどのチャネルと、展開するMicrosoft Edgeクライアントのバージョンを選択します。Configuration Managerでは、組み込みの「Microsoft Edge Management」ノードからEdgeアプリケーションを作成し、クライアント端末のSoftware Centerでユーザーがインストールできる形にできます。(Microsoft Learn)
一方、更新管理では「All Microsoft Edge Updates」ノードを使い、ほかのソフトウェア更新と同様に手動展開、段階的展開、自動展開ルールへの追加などを行います。更新を取得するには、ソフトウェア更新ポイントで「Updates」分類と「Microsoft Edge」製品が同期対象になっている必要があります。(Microsoft Learn)
Edgeの更新方針は2択で考える
Configuration Manager version 2002以降では、Microsoft Edgeアプリケーション作成時に、Edgeの自動更新を許可する選択肢があります。つまり、更新管理の設計は大きく次の2パターンに分かれます。(Microsoft Learn)
| 更新方針 | 向いている環境 | 注意点 |
|---|---|---|
| Configuration Managerで更新を管理する | 更新タイミングを厳密に制御したい企業、検証リングを分けたい環境 | 同期設定、ADR、配布ポイント、適用状況の監視が必要 |
| Microsoft Edgeの自動更新を許可する | 端末数が少ない、迅速なセキュリティ更新を優先したい環境 | バージョン差異が出やすく、業務アプリ検証との調整が必要 |
実務では、全社一律でどちらかに決めるよりも、重要システムを使う部門はConfiguration Manager管理、一般部門はEdge自動更新を許可する、といった分け方もあります。ただし、同じ端末に対して複数の管理経路から異なる更新ポリシーを適用すると、原因調査が難しくなります。
展開前に確認すべき前提条件
Configuration ManagerでMicrosoft Edgeを展開する場合、最初に確認すべきなのはPowerShellと証明書です。公式ドキュメントでは、Edge展開対象のクライアントについて、PowerShell実行ポリシーをRestrictedに設定できないとしています。インストールにPowerShellが使われるためです。(Microsoft Learn)
また、PowerShell実行ポリシーをAllSignedにしている環境では、Microsoft Code Signing PCA 2011証明書を信頼している必要があります。公式情報では、Configuration Managerコンソールをインストールした端末のCMPivot.exeからコード署名証明書をエクスポートし、管理対象端末のTrusted Publishersストアへインポートする流れが説明されています。(Microsoft Learn)
ネットワーク到達性も展開失敗の原因になる
Configuration Managerコンソールを実行する端末は、Edgeのリリース情報やコンテンツ取得のために、指定されたエンドポイントへアクセスできる必要があります。公式ドキュメントでは、Edgeリリース情報用のhttps://aka.ms/cmedgeapi、https://edgeupdates.microsoft.com/api/products?view=enterprise、Edgeリリースコンテンツ用のhttp://dl.delivery.mp.microsoft.comが示されています。 (Microsoft Learn)
ファイアウォールやプロキシで外部通信を制限している企業では、ここがよく詰まります。特に「コンソール上では作成できたが、コンテンツのダウンロードで失敗する」という場合は、PatchDownloader.logとネットワーク許可設定を合わせて確認してください。
Configuration ManagerでEdgeアプリを作成する流れ
Edge展開は、Configuration Managerコンソールの「Software Library」から進めます。公式手順では、「Microsoft Edge Management」ノードから「Create Microsoft Edge Application」を選択し、アプリケーション名、説明、コンテンツの場所、チャネル、バージョン、自動更新の可否などを指定します。(Microsoft Learn)
実務での流れは、次のように整理できます。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| アプリ作成 | Microsoft Edge ManagementからEdgeアプリを作成 | コンテンツ保存先フォルダーが空でない |
| チャネル選択 | Stable、Beta、Devなどを選ぶ | 検証用チャネルを本番展開してしまう |
| バージョン選択 | 展開するEdgeクライアントのバージョンを選ぶ | 古い業務アプリとの互換性検証を省略する |
| 自動更新設定 | Edge自身の自動更新を許可するか決める | ConfigMgr管理と自動更新が混在する |
| 展開設定 | コレクション、期限、ユーザー通知を設定 | 全社展開前のパイロット展開を省略する |
| 監視 | ログと展開状態を確認 | Software Centerだけ見て完了判断する |
本番展開では、最初から全端末へ必須展開するのではなく、情報システム部門、業務アプリ利用部門、一般ユーザーの順でリング展開するのが安全です。Edgeはブラウザーであるため、社内ポータル、SaaS、認証基盤、プロキシ、拡張機能、IEモード設定など、多くの業務に影響します。
グループポリシーがConfiguration Manager設定を上書きする点に注意
最も見落としやすいのが、グループポリシーとの優先関係です。公式ドキュメントでは、以前にグループポリシーでEdgeの更新動作を変更していた場合、Configuration ManagerがEdgeインストール時に行った設定をグループポリシーが上書きすると説明されています。(Microsoft Learn)
つまり、Configuration Manager側で「Edgeの自動更新を許可した」と思っていても、GPO側でEdge Updateを無効化していれば、端末上では期待どおりに更新されない可能性があります。
確認すべきポリシーの例
Edge更新トラブルを防ぐには、少なくとも次の観点でポリシーを棚卸ししてください。
| 確認項目 | 見るべきポイント |
|---|---|
| Edge Update関連ポリシー | 自動更新を無効化していないか、チャネルごとに制御していないか |
| Intune設定カタログ | Edge用のADMX-backedポリシーが重複していないか |
| オンプレミスGPO | 旧来のEdge管理テンプレートが残っていないか |
| Configuration Manager設定 | Edgeアプリ作成時の自動更新オプションと矛盾していないか |
| 端末側の実際の状態 | edge://policyで適用ポリシーを確認しているか |
Microsoft Intuneの設定カタログでは、Microsoft Edge version 77以降向けのポリシーをWindowsとmacOSに展開できます。設定はオンプレミスGPOに近いADMX-backedポリシーとして扱われるため、IntuneとGPOを併用している環境では、どちらを正とするかを明確にしておく必要があります。(Microsoft Learn)
IntuneでEdgeを直接配布する場合との違い
Microsoft Intuneでも、Microsoft Edge version 77以降をアプリ種類として追加し、Windows端末へ割り当てることができます。Intuneの公式ドキュメントでは、Windows向けのこのアプリ種類はStable、Beta、Devチャネルを提供し、Microsoft EdgeはWin32アプリとしてシステムコンテキストにインストールされると説明されています。既存のユーザーコンテキスト版Edgeがある場合、システムインストールで上書きされます。(Microsoft Learn)
ここで重要なのは、Intune配布ではMicrosoft Edgeの自動更新が既定でオンになっている点です。Configuration Manager管理で更新タイミングを制御したい環境とは設計思想が異なります。(Microsoft Learn)
| 比較項目 | Configuration Managerで展開 | Intuneで直接展開 |
|---|---|---|
| 主な用途 | 既存のConfigMgr基盤でEdgeを展開・更新 | クラウド管理端末へEdgeを配布 |
| 更新管理 | ConfigMgr管理またはEdge自動更新を選択 | Edge自動更新が既定でオン |
| 展開先 | Configuration Managerクライアント | Intune管理端末 |
| 監視 | ConfigMgrの展開状態、ログ、Edge Managementダッシュボード | Intuneのアプリインストール状態 |
| 注意点 | GPO、PowerShell、同期、証明書、配布ポイント | Intune Management Extension、Entra参加状態、CDN到達性 |
Intuneの組み込みEdge配布は、workplace joinコンピューターでは利用できません。公式ドキュメントでは、組み込みアプリ展開にはIntune Management Extensionが必要で、これはMicrosoft Entra joinedデバイスに存在すると説明されています。workplace join端末では、MSIをアップロードして配布する方法を検討する必要があります。(Microsoft Learn)
Edgeのチャネル選択は「本番・検証・先行確認」で分ける
Microsoft Edgeのリリースはチャネルごとに役割が異なります。IntuneのWindows向けEdge配布ドキュメントでは、Stableチャネルは企業での広範な展開に推奨され、Betaは組織内パイロット向け、Devはフィードバック向けと説明されています。(Microsoft Learn)
公式のリリーススケジュールでは、Stableチャネルはバージョン94以降、4週間のメジャーリリースサイクルに移行しており、管理された環境向けには8週間サイクルのExtended Stableオプションもあります。(Microsoft Learn)
実務では、次のように使い分けると運用しやすくなります。
| チャネル | 推奨用途 | 配布対象の例 |
|---|---|---|
| Stable | 本番利用 | 一般社員、標準端末、共有端末 |
| Beta | 検証・先行確認 | 情報システム部門、業務アプリ検証担当 |
| Dev | 早期検証・技術評価 | 開発部門、Edge機能検証チーム |
| Extended Stable | 更新検証に時間が必要な管理環境 | 大規模企業、厳格な変更管理がある環境 |
業務アプリがブラウザー依存の場合、Stableだけを見ていても不十分です。Betaチャネルに少数端末を割り当て、次期Stableで問題が起きそうな拡張機能、認証、社内Webアプリを早めに確認する運用が効果的です。
Edge更新をConfiguration Managerで管理する手順
Edge更新をConfiguration Managerで管理するには、ソフトウェア更新の同期設定が前提になります。公式ドキュメントでは、Microsoft Edge更新を取得するために「Updates」分類と「Microsoft Edge」製品を同期対象として選択する必要があるとされています。(Microsoft Learn)
基本の確認手順は次のとおりです。
| 手順 | 確認内容 |
|---|---|
| ソフトウェア更新ポイントを確認 | Updates分類が有効になっているか |
| 製品選択を確認 | Microsoft Edgeが同期対象になっているか |
| 同期を実行 | 必要に応じてSynchronize Software Updatesを実行 |
| All Microsoft Edge Updatesを確認 | 更新プログラムが表示されるか |
| 展開方法を決定 | 手動展開、段階的展開、ADRのどれを使うか |
| 適用状況を監視 | 準拠率、失敗端末、再起動要求を確認 |
自動展開ルールを使う場合は、Edgeの更新サイクルに合わせて評価タイミングを設計してください。Edgeはセキュリティ更新が頻繁に出るため、月例更新だけを前提にしたルールでは適用が遅れる場合があります。
監視ではログとダッシュボードを分けて使う
Edge展開のトラブルシューティングでは、見るべきログが役割ごとに異なります。公式ドキュメントでは、アプリや展開の作成失敗はSMSProv.log、コンテンツダウンロード失敗はPatchDownloader.log、クライアント側のインストール情報はAppEnforce.logで確認すると整理されています。(Microsoft Learn)
| 症状 | 優先して見るログ | 判断ポイント |
|---|---|---|
| Edgeアプリを作成できない | SMSProv.log | コンソール操作、権限、プロバイダーエラー |
| コンテンツ取得に失敗する | PatchDownloader.log | CDN、プロキシ、許可エンドポイント |
| 端末にインストールされない | AppEnforce.log | 検出ルール、実行結果、インストールコマンド |
| 更新が表示されない | 同期関連ログ、SUP設定 | Updates分類とMicrosoft Edge製品の選択 |
| 展開後のバージョンが揃わない | ダッシュボード、インベントリ | 自動更新とConfigMgr管理の混在 |
Configuration Manager 2002以降では、Microsoft Edge ManagementダッシュボードでEdgeのインストール台数、バージョン別のクライアント数、インストール済みブラウザーなどを確認できます。Configuration Manager 2203以降ではWebView2コンソール拡張機能が必要です。(Microsoft Learn)
ダッシュボード利用時のインベントリ設定に注意
Edge Managementダッシュボードを使うには、ハードウェアインベントリの設定も確認が必要です。公式ドキュメントでは、Installed Software – Asset Intelligence、Default Browser、Browser Usageの各クラスで、必要なプロパティを有効にするよう示されています。(Microsoft Learn)
特に注意したいのが、Browser Usageの収集です。公式ドキュメントには既知の問題として、ハードウェアインベントリ処理が失敗する可能性があり、Dataldr.logに主キー制約違反のようなエラーが出る場合があると記載されています。回避策として、Browser Usageのハードウェアインベントリクラス収集を無効にする方法が示されています。(Microsoft Learn)
ダッシュボードの可視化を優先してBrowser Usageを有効にした結果、インベントリ処理に問題が出ると、資産管理全体に影響する可能性があります。まず小規模コレクションで有効化し、Dataldr.logとインベントリ処理状況を確認してから対象を広げるのが安全です。
管理者が今すぐ確認すべきチェックリスト
Microsoft IntuneとConfiguration Managerを併用している環境では、次の順で確認すると抜け漏れを減らせます。
| 確認項目 | 合格ライン |
|---|---|
| 管理方針 | Edgeの初回展開と更新管理の担当が明確になっている |
| 展開経路 | Intune配布、ConfigMgr配布、MSI配布のどれを使うか決まっている |
| 更新方針 | ConfigMgr管理かEdge自動更新かを端末グループごとに決めている |
| GPO/Intuneポリシー | Edge Update関連ポリシーが矛盾していない |
| PowerShell | 実行ポリシーがRestrictedではない |
| 証明書 | AllSigned環境でMicrosoft Code Signing PCA 2011を信頼している |
| ネットワーク | Edgeリリース情報とコンテンツ取得先へアクセスできる |
| 同期設定 | Updates分類とMicrosoft Edge製品が選択されている |
| ログ確認 | SMSProv.log、PatchDownloader.log、AppEnforce.logの確認手順がある |
| 段階展開 | パイロット、本番、例外端末のリングがある |
このチェックリストで特に優先度が高いのは、更新方針とポリシー競合です。展開自体が成功しても、更新が止まっているとセキュリティリスクが残ります。逆に、自動更新を許可しすぎると、業務アプリ検証前にEdgeのメジャーバージョンが進む可能性があります。
開発者・業務アプリ担当が確認すべき影響
Microsoft Edgeの展開・更新は、インフラ管理者だけの作業ではありません。社内Webアプリ、SaaS連携、認証、拡張機能、プロキシ、IEモードを使うシステムに影響するため、開発者や業務アプリ担当も検証に参加する必要があります。
確認すべき観点は次のとおりです。
| 観点 | 確認例 |
|---|---|
| 認証 | Microsoft Entra ID、SAML、OIDC、フォーム認証が正常に動くか |
| 社内Webアプリ | ログイン、検索、帳票出力、ファイルアップロードが動くか |
| 拡張機能 | 必須拡張機能がブロックされていないか |
| ダウンロード制御 | 業務ファイルのダウンロードがポリシーで止まらないか |
| IEモード | レガシーアプリが必要なモードで開くか |
| プロキシ | PAC、認証プロキシ、SSL inspection環境で通信できるか |
| キオスク端末 | 自動起動、ホームページ、セッション終了時の挙動が想定どおりか |
Intuneの設定カタログでは、Edgeのホームページ、拡張機能、ダウンロード制限、お気に入りバーなどの設定を構成できます。これらは業務利用に直結するため、単に「Edgeを入れる」だけでなく、「業務に必要なブラウザー状態を再現できるか」を検証してください。(Microsoft Learn)
移行・展開で失敗しやすいパターン
Microsoft Edgeの管理でよくある失敗は、技術的な手順ミスよりも、管理経路の整理不足です。
IntuneとConfiguration Managerの両方で同じ端末を管理している
共同管理や移行中の環境では、IntuneでEdgeを配布しつつ、Configuration ManagerでもEdge更新を管理しようとするケースがあります。この場合、端末ごとにどちらのポリシーが効いているかを確認しないと、更新される端末と更新されない端末が混在します。
対策は、端末グループごとに「Edgeアプリ配布はIntune」「更新管理はConfigMgr」などの責任範囲を明文化することです。例外端末は別コレクションや別グループに分け、ポリシーの重複を避けます。
GPOの古いEdge Update設定が残っている
旧運用でEdge Updateを止めていたGPOが残っていると、Configuration Managerで自動更新を許可しても端末側では更新されないことがあります。端末のedge://policyで実際に適用されているポリシーを確認し、GPO、Intune、ローカルポリシーのどこから来ているかを切り分けてください。
更新をADRに入れたが、同期対象にMicrosoft Edgeがない
自動展開ルールを作っても、そもそもソフトウェア更新ポイントでMicrosoft Edge製品を同期していなければ、対象更新は取得されません。Edge更新が一覧に出ない場合は、ADRより先に分類と製品の同期設定を確認してください。
ダッシュボードを見ているがインベントリが足りない
Edge Managementダッシュボードは便利ですが、必要なハードウェアインベントリクラスが有効になっていないと正しい情報が表示されません。可視化できない場合は、ダッシュボードの不具合と決めつけず、インベントリクラス、収集サイクル、Dataldr.logを確認しましょう。
実務でおすすめの展開設計
大規模環境では、次のような段階設計が現実的です。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | 情シス、開発者、業務アプリ担当 | インストール、更新、主要業務アプリの動作確認 |
| パイロット | 一部部署、ITリテラシーが高い利用者 | 実運用での不具合、プロキシ、拡張機能の確認 |
| 初期展開 | 一般端末の一部 | 更新負荷、Software Center通知、問い合わせ傾向の確認 |
| 全社展開 | 標準端末 | 安定展開と準拠率の監視 |
| 例外管理 | 専用端末、キオスク、レガシー業務端末 | 更新タイミングやポリシーを個別制御 |
この設計では、Edgeのチャネルも合わせて分けると効果的です。Betaチャネルを少数の検証端末に配布しておけば、Stableチャネルへ反映される前に互換性問題を見つけやすくなります。
まとめ：次にやるべきこと
今回の「Deploy and update Microsoft Edge, version 77 and later – Configuration Manager」で管理者が取るべき行動は、単に公式ページを読むことではありません。自社環境でEdgeの展開と更新をどの管理基盤が担っているかを確認し、Configuration Manager、Microsoft Intune、グループポリシーの設定が矛盾していないかを点検することです。
まず、Edgeの更新をConfiguration Managerで管理するのか、Edgeの自動更新に任せるのかを決めてください。次に、PowerShell実行ポリシー、署名証明書、ネットワーク到達性、Updates分類とMicrosoft Edge製品の同期設定を確認します。最後に、少数端末でパイロット展開し、SMSProv.log、PatchDownloader.log、AppEnforce.log、Edge Managementダッシュボードで状態を確認してから本番展開へ進めるのが安全です。
特にIntuneとの併用環境では、「Edgeを配布できるか」よりも「誰が更新を制御しているか」を明確にすることが重要です。ここを整理しておけば、展開後の更新漏れ、バージョン差異、ポリシー競合を大きく減らせます。
コメント