SRP（ソフトウェア制限ポリシー）やAppLockerで「%UserProfile%配下の実行を禁止」すると、Edge更新の中核であるMicrosoftEdgeUpdateCore.exeが引っかかりがちです。本記事では、ブロックの影響と理由、移設の可否、そして“禁止を維持したまま更新を生かす”具体策を実務目線で解説します。
結論：MicrosoftEdgeUpdateCore.exe を止めると「更新できない端末」を量産しやすい
最初に結論から言うと、%LocalAppData% 配下で動く MicrosoftEdgeUpdateCore.exe（Microsoft Edge Update の実行ファイル） を SRP / AppLocker で一律ブロックすると、Edge の自動更新が止まりやすくなります。更新が止まると、脆弱性修正が届かない状態でブラウザを使い続けることになり、セキュリティ強化どころかリスクが増えるケースが典型です。
| ブロックで起きやすいこと | 現場での症状例 | 放置した場合のリスク |
|---|---|---|
| Edge の更新チェック／適用が失敗する | 「更新できません」「最新ではありません」表示、更新通知が消えない | 既知脆弱性が残り続ける |
| 更新エンジン自体の自己更新が不安定になる | 短時間でプロセス起動→終了を繰り返す、失敗ログが増える | 端末ごとに挙動差が出て運用が破綻しやすい |
| WebView2 Runtime の更新が滞る可能性 | WebView2 を使うアプリで互換性問題・脆弱性懸念（アプリ側は正常でも埋め込みブラウザが古い） | ブラウザ以外の業務アプリにも波及 |
つまり「ユーザープロファイル配下は原則禁止」という要件を貫くなら、Edge 更新だけは例外設計か、そもそもユーザー単位インストールを無くす設計が必要になります。
なぜログに何度も出るのか：Microsoft Edge Update の“定期実行”が原因
テスト運用で %LocalAppData%\Microsoft\EdgeUpdate\1.3.x.x\MicrosoftEdgeUpdateCore.exe の実行が繰り返し見えるのは、異常というより更新の仕組み上、定期的に起動する設計であることが多いです。Edge 更新は、タスクスケジューラ（例：MachineCore / MachineUA など）やサービス（edgeupdate / edgeupdatem）で「更新があるか確認→あれば適用」という動きをします。
| よくあるトリガー | 実行される目的 | 確認ポイント |
|---|---|---|
| 定期タスク（UA / Core） | バックグラウンドで更新確認・ダウンロード・適用準備 | タスクスケジューラで EdgeUpdate 系タスク名を検索 |
| サービス（edgeupdate / edgeupdatem） | 更新チェック・更新処理の起点。短時間で開始→停止することもある | サービス一覧で状態と起動種類を確認 |
| ユーザーのサインイン／アプリ起動 | ユーザー単位インストールの場合、ユーザー文脈で更新処理を回す | 実行元パスが AppData\Local か Program Files か |
フォルダ名に入っている 1.3.195.61 のような数字は、更新エンジン（Edge Update）のバージョン番号として“世代管理”されることがあり、更新時に新しいバージョンのフォルダへ差し替わります。SRP / AppLocker をハッシュ固定で許可していると、更新のたびにブロックされやすいので注意が必要です。
まずは“更新が失敗しているのか”を確認する：ログの場所と見方
「実行されている＝問題」とは限りません。更新処理は“確認した結果、何もせず終了”することもあるため、成功・失敗の判断はログで行うのが確実です。環境によって差はありますが、Microsoft Q&A でも Edge Update のログ出力先として C:\ProgramData\Microsoft\EdgeUpdate\Log が挙げられています。
| 見る場所 | 何が分かるか | 運用上の使いどころ |
|---|---|---|
| EdgeUpdate のログ（例：ProgramData 配下） | 更新確認・ダウンロード・適用の成否、更新エンジン自身の更新 | 「なぜ繰り返し起動するのか」を短時間で切り分け |
| AppLocker イベントログ（監査/ブロック） | どのルールで拒否されたか、どのファイルが対象か | 監査モードで“必要な例外だけ”を精密に追加 |
| EDR / Defender の検知ログ | 不審な挙動（異常な子プロセス、疑わしい通信、権限昇格など） | 実行制御で取り切れない攻撃の補完 |
“ユーザー単位インストールかどうか”を見分ける簡単チェック
同じ Edge でも、端末全体（マシン単位）で入っているのか、ユーザー単位で入っているのかで、更新エンジンの置き場所が変わりやすく、SRP / AppLocker との衝突ポイントも変わります。まずは端末の状態を機械的に確認しておくと、ルール設計がブレません。
| チェック項目 | マシン単位の可能性が高いサイン | ユーザー単位の可能性が高いサイン |
|---|---|---|
| EdgeUpdate の配置 | Program Files（または Program Files (x86)）配下にも EdgeUpdate 関連フォルダがある | %LocalAppData%\Microsoft\EdgeUpdate 配下が中心で、ユーザーごとに存在する |
| msedge.exe の配置 | Program Files 系配下の Application フォルダに msedge.exe がある | %LocalAppData%\Microsoft\Edge\Application 配下に msedge.exe がある |
| 更新の実行主体 | サービス（edgeupdate / edgeupdatem）や MachineUA/Core タスクが主に動く | ユーザーのログオンに紐づく実行や User 系タスクが目立つ |
確認用コマンド例
:: Edge が PATH に入っている環境なら実行元が分かる
where msedge
:: EdgeUpdate の痕跡をざっくり探す（管理者権限推奨）
dir "%ProgramFiles%\Microsoft\EdgeUpdate" /ad
dir "%ProgramFiles(x86)%\Microsoft\EdgeUpdate" /ad
dir "%LocalAppData%\Microsoft\EdgeUpdate" /adなぜユーザープロファイル（AppData\Local）で実行されるのか：ユーザー単位インストールと権限モデル
「そもそもなぜ %ProgramFiles% ではなくユーザー領域から動くのか？」の答えは、Edge（および更新エンジン）がユーザー単位インストールも想定しているからです。ユーザー単位でインストールされたアプリは、そのユーザーの書き込み可能領域（AppData など）に更新のための部品を置くのが自然です。管理者権限を毎回要求せずに更新できるメリットもあります。
| インストール形態 | 主な配置場所 | 更新の動き | 運用面の特徴 |
|---|---|---|---|
| 端末全体（マシン単位） | %ProgramFiles% / %ProgramFiles(x86)% 配下が中心 | サービス／タスクがシステム側で更新を回しやすい | 企業管理（Intune / MECM 等）と相性が良い |
| ユーザー単位 | %LocalAppData% 配下（ユーザープロファイル内） | ユーザー文脈で更新エンジンが動きやすい | 管理者権限なしで導入・更新しやすいが、実行制御と衝突しやすい |
また、WebView2 Runtime（Evergreen）は自動更新され、Edge の更新と同じ系統の更新を受け取る旨が公式ドキュメントで説明されています。つまり、Edge 更新エンジンを止める判断は、ブラウザだけでなく埋め込みブラウザ（WebView2）を使うアプリ群にも影響し得ます。
%SystemRoot% や %ProgramFiles% に移して実行させられるか：基本的に非推奨で現実的ではない
MicrosoftEdgeUpdateCore.exe を手作業で別フォルダへ移して運用するのはおすすめできません。更新エンジンは自分自身も更新し、タスクやレジストリ、関連ファイルの配置も前提が決まっているため、単純移設は破綻しやすいからです。更新のたびに元の場所へ再展開されることもあり、「移したら終わり」になりません。
実務的には、次のどちらかの方向で設計します。
- 例外許可で両立する：ユーザープロファイル配下は原則禁止にしつつ、Edge Update など必要最小限の“署名ベース”例外だけ通す
- 配置を寄せて両立する：Edge をマシン単位で配布し、更新も可能な限りシステム領域（Program Files）側で完結させる
両立の基本戦略：パスではなく「署名（Publisher）」で許可し、更新で壊れないルールにする
ユーザープロファイル配下の実行を禁止する狙いは、ダウンロードした不審な exe / スクリプトをユーザーが実行してしまう事故を減らすことです。この狙いを損なわずに Edge 更新を通すには、パス許可ではなく署名許可が鉄則です。
AppLocker の Publisher ルールは、デジタル署名（発行元）と、製品名／ファイル名／バージョンといった属性を使って許可でき、パスルールより安全で、ハッシュルールより更新に強いことが整理されています。Edge Update のように頻繁に更新されるコンポーネントは、Publisher ルールが最も運用に乗りやすい部類です。
| 方式 | 更新への強さ | 安全性 | 向いているケース |
|---|---|---|---|
| パスルール | 弱い（置き換え・横取りに弱い） | 低〜中（ユーザーが書ける場所は特に危険） | システム領域など“書き込みが管理された場所”のみ |
| ハッシュルール | 最弱（更新で必ず変わる） | 中 | 更新頻度が低い社内ツールなど |
| Publisher（署名）ルール | 強い（更新しても同じ署名・属性なら通る） | 高（署名が前提） | Edge Update、Microsoft 製品、頻繁に更新されるアプリ |
AppLocker での現実的なルール例：ユーザープロファイルは“基本デフォルト拒否”、Edge Update だけ限定許可
AppLocker を「許可リスト型（Allowlist）」として運用すると、ユーザープロファイル配下はルールを作らない限り実行できない状態にできます。そこへ Edge Update だけ Publisher ルールで足すのが、要件と運用のバランスが良いパターンです。
作業の流れ（いきなり強制せず、監査モードから始める）
- 監査（Audit only）で適用し、ブロック候補をイベントログで収集する
- EdgeUpdate の実行イベント（許可/拒否）を確認し、必要なファイルだけ許可ルール化する
- パイロット端末で強制（Enforced）に切り替え、業務影響がないことを確認して展開する
作り方の要点（GPO / ローカルポリシー）
- GPO：コンピューターの構成 → Windows の設定 → セキュリティの設定 → アプリケーション制御ポリシー → AppLocker
- 対象コレクション：まずは 実行可能ファイル（Executable Rules） から
- 既定ルール：Windows / Program Files を許可する既定ルールを作成し、業務停止リスクを下げる
Publisher ルールの設定例（最小権限の考え方）
| 項目 | 推奨例 | 意図 |
|---|---|---|
| 対象 | EXE（必要なら DLL / Script も） | まずは実行ファイルから段階的に |
| アクション | 許可（Allow） | “必要なものだけ通す” |
| ユーザー／グループ | 全ユーザー（または対象OU/グループ） | 端末設計に合わせる |
| 発行元（Publisher） | Microsoft Corporation | 署名検証で偽装を防ぐ |
| 製品名（Product） | Microsoft Edge Update（もしくは EdgeUpdate 系） | “Microsoft 全部許可”にしない |
| ファイル名（File name） | MicrosoftEdgeUpdateCore.exe（必要に応じて MicrosoftEdgeUpdate.exe 等も追加） | 許可範囲を狭める |
| バージョン | 任意（Any） | 更新で壊れないようにする |
ここでありがちな失敗は「Users\*\AppData\Local\Microsoft\EdgeUpdate\* をパス許可」してしまうことです。ユーザーが書き込める場所をパス許可すると、悪意ある exe を同じ場所に置かれた場合に通ってしまいます。署名（Publisher）で“正規の更新コンポーネントだけ”を通すことが重要です。
運用で必ず押さえるポイント（AppLocker の前提）
- AppLocker は防御の一部（defense-in-depth）であり、より堅牢なアプリ制御が必要なら App Control for Business（WDAC 系）も検討対象
- ルールを強制するには Application Identity（AppIDSvc） が必要
- 既定では“ユーザー文脈で起動したコード”に適用される。SYSTEM 等まで広げる場合は拡張設定を理解して適用する
SRP（ソフトウェア制限ポリシー）でやるなら：証明書ルールは“広くなりやすい”点に注意
SRP でも「ユーザープロファイル配下は禁止」は実現できますが、更新に耐える形で例外を作るのが AppLocker より難しい場面があります。SRP の “証明書ルール” は署名ベースで許可できる一方、AppLocker の Publisher ルールのように「製品名／ファイル名」で細かく絞れない運用になりがちです。
そのため SRP で例外を作る場合は、例外の数を増やさない／EDR とログ監視で補うといった運用設計が重要になります。
根本対策：ユーザー単位インストールを減らし、Edge をマシン単位で統制する
「ユーザープロファイル配下の実行を極力ゼロにしたい」要件が強い組織では、例外を増やすよりもインストール形態を揃える方が結果的に安全で運用も楽です。
- Edge を企業配布（マシン単位）に統一し、ユーザーが勝手に別チャネルや別場所へ入れる余地を減らす
- Edge Update のポリシー（msedgeupdate.admx）で、インストール可否や更新動作を組織標準に寄せる
Microsoft Learn の Edge Update ポリシーでは、例えば「インストール可否（Allow installation / Allow installation default）」や「更新ポリシー（Update policy override / Update policy override default）」など、更新・導入を制御するためのポリシーが一覧化されています。これらを使うと、ユーザーが勝手にインストールするチャネルを抑止しつつ、正式に許可したチャネルは自動更新させる、といった運用が組みやすくなります。
| やりたいこと | ポリシー設計の方向性（例） | 期待できる効果 |
|---|---|---|
| 勝手な導入（別チャネル）を抑止 | インストール許可をチャネル単位で制御（不要チャネルはブロック） | ユーザー領域に“新しい更新エンジン”が増えにくい |
| 更新タイミングを制御したい | 更新ポリシーを「自動/手動」などに整理（推奨は自動を維持） | 業務影響の見通しが立てやすい |
| 特定バージョンへ合わせたい | Target version override で段階展開（恒久固定は避ける） | 互換性問題の緊急回避に使える |
注意点として、更新を完全停止（Updates disabled）に振り切るのは、ブラウザを業務利用する前提では原則おすすめできません。緊急避難として一時的に止める場合でも、解除手順と期限を決め、恒久化しない運用が現実的です。
トラブルシュート：ブロックしてしまった時の切り分けポイント
もしテスト中に MicrosoftEdgeUpdateCore.exe がブロックされてしまった場合、まずは「どの制御で、何がマッチしたか」を切り分けます。AppLocker なら監査ログが強力なので、監査モードで必ずログを取り、ルールを改善してから強制に移行するのが安全です。
確認に使えるコマンド例（PowerShell）
# Edge Update 系のサービスを確認
Get-Service -Name edgeupdate, edgeupdatem -ErrorAction SilentlyContinue | Format-Table -Auto
# Edge Update 系のタスクを確認（環境により名前が異なる場合があります）
Get-ScheduledTask | Where-Object { $_.TaskName -like "*EdgeUpdate*" } | Select-Object TaskName, State
# 実行ファイルの署名確認（例：ユーザー領域にある EdgeUpdateCore）
$path = "$env:LOCALAPPDATA\Microsoft\EdgeUpdate"
Get-ChildItem -Path $path -Filter "MicrosoftEdgeUpdateCore.exe" -Recurse -ErrorAction SilentlyContinue |
Select-Object -First 1 -ExpandProperty FullName |
ForEach-Object { Get-AuthenticodeSignature $_ } | Format-List| 症状 | 疑うポイント | 対処の方向性 |
|---|---|---|
| Edge が更新できない／更新通知が消えない | 更新エンジン（Core / Updater）がブロック | Publisher ルールで必要ファイルを許可し、ハッシュ許可は避ける |
| EdgeUpdate プロセスが高頻度で起動する | 失敗→再試行が発生している可能性 | ブロックログを確認し、該当ルールを見直す |
| WebView2 を使うアプリの表示が崩れる／動かない | WebView2 Runtime の更新停滞・依存バージョン差 | WebView2 の更新経路（Edge 更新）を確保する |
例外を増やさずに安全に回す“運用チェックリスト”
「ユーザープロファイル配下を禁止したい」組織ほど、例外追加が雪だるま式になりがちです。最後に、現場で破綻しにくいチェック観点をまとめます。
| チェック観点 | 確認方法 | OKライン |
|---|---|---|
| 例外はパス許可になっていないか | AppLocker / SRP ルールを棚卸し | ユーザー書き込み可能領域は署名許可が基本 |
| 更新で壊れるルールになっていないか | ハッシュルールの有無、バージョン固定の有無 | 頻繁に更新されるコンポーネントは Publisher で「Any version」 |
| 監査ログが取れているか | 監査モード、イベント収集（SIEM 等） | パイロット期間中に“ブロック候補”を見つけられる |
| EDR/Defender で挙動監視できているか | 不審な子プロセス、通信、永続化の検知ルール | 実行制御で漏れる攻撃（スクリプト・LOLBin 等）も検知できる |
| Edge の更新ポリシーが組織標準か | GPO / Intune で msedgeupdate のポリシー確認 | 更新を止めず、必要なら段階展開や一時停止でコントロール |
まとめ：禁止を貫くなら「署名で最小許可」か「マシン単位へ寄せる」の二択
MicrosoftEdgeUpdateCore.exe は Edge 更新の中核であり、ユーザープロファイルからの実行が見える環境では、ブロックすると更新停止につながりやすいことを前提に考える必要があります。対策としては、AppLocker の Publisher ルールで必要最小限を許可しつつ、監査ログとEDRで運用を固めるのが最短ルートです。より強く“ユーザー領域ゼロ”を目指すなら、Edge の導入形態と更新ポリシーを組織標準に寄せ、ユーザー単位インストールを減らす設計が有効です。
コメント