Windows Server 2025でAppLockerを使ってMicrosoft Edgeの起動を完全にブロックする手順

Windows Server 2025 で AppLocker を使って Microsoft Edge（Chromium 版）の起動だけを禁止したいのに、うまくブロックできないケースは少なくありません。本記事では、最小限の設定手順から、実運用でハマりやすいポイント、ロールバック方法までを体系的に解説し、安全に検証・展開できる具体的なノウハウを整理します。

Windows Server 2025 で Edge を AppLocker でブロックする全体像

Windows Server 2025 でも、AppLocker は引き続き利用可能であり、アプリケーション制御の中心的な機能として位置付けられています。

AppLocker は、実行可能ファイル（EXE）、スクリプト、Windows Installer、DLL、パッケージ化アプリなどに対して「どのファイルを実行してよいか」を制御できる機能です。 Microsoft Edge（Chromium 版）は通常の msedge.exe として動作するため、[実行可能ファイルの規則] で制御するのが基本になります。

この記事で目指すゴールは、次の 3 点です。

• Chromium 版 Microsoft Edge の起動を AppLocker で安定してブロックできるようにする
• 既存アプリ（特に WebView2 を利用するアプリ）への影響を最小限に抑える
• トラブル時に「どこを見ればよいか」が分かる状態にする

結論を先にまとめると、次のような構成が最もトラブルが少ないパターンです。

• Application Identity（AppIDSvc）サービスを「自動起動＋実行中」にする
• AppLocker の各コレクションで「既定の規則」を必ず作成する
• [実行可能ファイルの規則] に Microsoft Edge の Publisher（発行元）ベースの「拒否」規則 を作る
• 最初は「監査のみ」でログを確認し、問題なければ「実施」に切り替える

AppLocker と Edge ブロックの基本設計

AppLocker は、主に次の 3 種類の条件でルールを作成できます。

• Publisher（発行元）：署名情報（発行元、製品名、ファイル名、バージョン）を基準に制御
• パス：ファイルの格納パス（例：C:\Program Files\...）を基準に制御
• ハッシュ：ファイルのハッシュ値（更新のたびに変わる）を基準に制御

Microsoft Edge のようにバージョン更新頻度が高いアプリをブロックする場合、Publisher 条件で「製品名: Microsoft Edge」レベルにルールを設定するのが最も現実的です。

パスやハッシュだけに頼る構成だと、次のような問題が起きがちです。

• Edge の更新でバージョンごとにフォルダー名が変わり、パスルールが追従できない
• ハッシュルールはバージョン更新のたびに作り直しが必要で、運用コストが高い

そのため、この記事では次のようなルール設計を前提とします。

• ルール条件：Publisher（発行元）
• レベル：製品名 = Microsoft Edge
• 操作：拒否
• 対象：Everyone（または制御したいユーザー／グループ）

事前チェック：AppLocker 前提条件と環境確認

AppLocker で Edge をブロックできないトラブルの多くは、「ルールそのもの」よりも 前提条件の不足 が原因です。まずは次のチェックリストを一通り確認しておきましょう。

項目	確認内容	推奨状態
Edition / ライセンス	AppLocker 対応エディションか（Windows Server Standard/Datacenter 等）	対応エディションであること
Application Identity サービス	サービス名 AppIDSvc が有効・実行状態か	スタートアップ「自動」、状態「実行中」
既定の規則	各コレクション（EXE/DLL/パッケージアプリなど）に既定ルールを作成済みか	OS・Program Files など基本部分は「許可」されている
適用モード	「監査のみ」か「実施」か	検証時は「監査のみ」、本番は「実施」
ログ出力	イベントビューアーで AppLocker のログが出ているか	EXE and DLL ログに記録があること

Application Identity（AppIDSvc）サービスを有効化する

AppLocker は、Application Identity サービス（AppIDSvc）が起動していないとポリシーを評価できません。 Windows Server 2025 では、このサービスが既定で「無効」または「手動（トリガー）」になっていることが多く、そのままではルールがまったく効きません。

ローカルで設定する例：

1. 管理者権限でコマンドプロンプトまたは PowerShell を開く。
2. 次のコマンドを実行して、自動起動＋サービス開始を設定します。 sc.exe config appidsvc start= auto net start appidsvc

なお、Application Identity サービスは Windows 10 以降、保護プロセスとして扱われるため、サービス管理ツール（services.msc）からはスタートアップ種類を「自動」に変更できない場合があります。その場合も、上記のように sc.exe や GPO の「システムサービス」設定から変更する必要があります。

GPO で一括設定する場合：

1. ドメイン コントローラーで gpmc.msc を開く。
2. 対象 OU にリンクする GPO を新規作成／編集。
3. [コンピューターの構成] > [Windows の設定] > [セキュリティの設定] > [システム サービス] を開く。
4. Application Identity をダブルクリックし、スタートアップの種類を 自動 に設定。

既定の規則（Default Rules）を必ず作成する

AppLocker では、既定の規則を作らないまま「実施」モードに切り替えると、OS や管理ツールまでブロックされてしまう危険があります。公式ドキュメントでも、「Windows システムファイルを実行できるようにするために、標準の AppLocker 既定ルールを作成する」ことが推奨されています。

ローカルセキュリティポリシー secpol.msc から次の操作を行います。

1. [アプリケーション制御ポリシー] > [AppLocker] を開く。
2. [実行可能ファイルの規則]／[パッケージ化されたアプリの規則] など、各コレクションを選択。
3. 右側の操作メニューから [既定の規則の作成] を実行。

これにより、%WINDIR% や Program Files など OS の基本部分は許可され、そのうえで Edge だけを「拒否」とする構成が取りやすくなります。

適用モード：「監査のみ」と「実施」の違い

AppLocker の各コレクション（EXE/DLL/パッケージアプリなど）は、監査のみ（Audit only） と 実施（Enforced） の 2 モードを切り替えられます。

• 監査のみ：実際のブロックは行わず、「もしルールが実施されていたらどうなっていたか」をイベントログに記録する。
• 実施：ルールどおりに実際のブロック／許可を行う。

Edge のブロックを本番適用する前に、必ず一度 監査モードで 1～2 週間ほどログを取り、「想定外にブロックされる実行ファイルはないか」を確認してから、「実施」に切り替えるのがおすすめです。

ローカルセキュリティポリシーで Edge をブロックする手順

単体サーバーや検証環境で試す場合は、ローカルセキュリティポリシーを使うのが手軽です。以下は Windows Server 2025 での具体的な手順です。

ローカルセキュリティポリシーを開く

1. Win + R キーで「ファイル名を指定して実行」を開きます。
2. secpol.msc と入力して [OK] をクリック。
3. 左ペインで [アプリケーション制御ポリシー] > [AppLocker] > [実行可能ファイルの規則] を選択。

Microsoft Edge を対象にした Publisher ベースの拒否規則を作成する

次に、Edge 用の「拒否」規則を作成します。作業手順は、公式ドキュメントの Publisher ルール作成手順とほぼ同じ流れです。

1. [実行可能ファイルの規則] を右クリックし、[新しい規則の作成] をクリック。
2. 「開始する前に」画面は [次へ]。
3. [アクセス許可] 画面で次を選択：
   • 操作：「拒否」
   • ユーザーまたはグループ：「Everyone」（または必要なグループ）
4. [条件] 画面で [発行元] を選択し、[次へ]。
5. [参照] ボタンで、実際の msedge.exe を指定する。
   • 例：C:\Program Files\Microsoft\Edge\Application\msedge.exe
   • 環境によっては C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe や、ユーザー単位インストール (%LOCALAPPDATA%\Microsoft\Edge\Application\msedge.exe) の場合もあります。
6. 発行元情報が読み込まれたら、スライダー（レベル）を 製品名（Product） に設定し、製品名が 「Microsoft Edge」 になっていることを確認。
7. 必要に応じてバージョン範囲を指定（原則として「すべてのバージョン」を拒否する構成が分かりやすい）。
8. ルール名（例：Block Microsoft Edge (Publisher)）と説明を入力して [作成]。

Publisher ルールのレベル違いを簡単に整理すると、次のようになります。

レベル	例	特徴	Edge ブロック用の適性
発行元（Publisher）	O=Microsoft Corporation	同じ署名のすべてのファイルが対象になりやすく、範囲が広い。	広すぎるため、Edge 以外も巻き込む可能性が高い。
製品名（Product）	Microsoft Edge	同じ「製品」に属する実行ファイル全般を対象にできる。バージョン更新にも強い。	推奨。Edge の更新にも追従しやすい。
ファイル名（File name）	msedge.exe	製品内の特定のファイル名だけに限定できるが、バージョンごとにパスが変わる場合は別途考慮が必要。	製品レベルと併用すると、よりピンポイントな制御が可能。

規則の優先順位と評価順

AppLocker では、拒否ルールが許可ルールより優先します。 そのため、基本的には Edge 用の拒否規則を作成するだけで、既定の許可規則よりも優先して評価されます。

ただし、以下のような場合は、意図しない許可／ブロックにつながることがあります。

• 同じファイルに対して、ユーザーごとに異なる許可・拒否ルールを作っている
• OU や GPO が複数重なり、結果として複数の AppLocker ポリシーがマージされている

そのような場合は、PowerShell の Get-AppLockerPolicy -Effective コマンドで「最終的に適用されているルール」を確認するのが確実です。

Get-AppLockerPolicy -Effective -Xml > C:\Temp\Applocker-Effective.xml

出力された XML をエディターで開き、Edge 関連のルールがどのようにマージされているか確認してみましょう。

適用モードを「監査のみ」に設定してテストする

ルールを作り終えたら、すぐに「実施」に切り替えたくなりますが、ここで一度踏みとどまるのが安全です。まずは [プロパティ] から [実行可能ファイル] の動作を「監査のみ」に設定し、Edge や他アプリケーションの起動ログを数日分収集することをおすすめします。

1. [AppLocker] を右クリックし、[プロパティ] を開く。
2. [実行可能ファイル] タブで動作を 監査のみ に設定。
3. gpupdate /force を実行してポリシーを即反映。

旧 Edge（UWP/Legacy）が残っている環境への対応

Windows Server 2025 自体では基本的に Chromium 版 Edge が中心ですが、クライアント OS とポリシーを共用している場合など、旧 UWP 版 Edge（Microsoft.MicrosoftEdge...）が混在していることがあります。その場合は、次のように分けて考えると整理しやすくなります。

• Chromium 版 Edge：[実行可能ファイルの規則]（EXE ルール）で制御
• 旧 Edge（UWP）：[パッケージ化されたアプリの規則] で制御

旧 Edge をブロックしたい場合は、[パッケージ化されたアプリの規則] でも Publisher 条件を使って「Microsoft.MicrosoftEdge」を拒否するルールを追加します。 ただし、Windows 10/11 クライアント側のスタートメニューや設定アプリが Edge に依存しているケースもあるため、検証用マシンでのテストは必須です。

GPO で複数台のサーバーに展開する手順

検証が終わったら、グループポリシー（GPO）で複数サーバーに展開します。基本的な編集手順は公式ドキュメントと同様です。

1. ドメイン コントローラーで gpmc.msc を開く。
2. Edge ブロック用の専用 GPO（例：GPO_AppLocker_Block_Edge）を作成。
3. 対象のサーバーが属する OU に GPO をリンク。
4. GPO を右クリックして [編集]、次のパスを開く：
   • [コンピューターの構成] > [Windows の設定] > [セキュリティの設定] > [アプリケーション制御ポリシー] > [AppLocker]
5. ローカルで作成したのと同じ要領で、[実行可能ファイルの規則] に Edge 拒否ルールを作成。
6. 同じ GPO の [システムサービス] で Application Identity を「自動」に設定。
7. 最初は [AppLocker のプロパティ] で 監査のみ にしてリンクし、ログを確認。

展開フェーズのイメージを簡単に表にすると次のようになります。

フェーズ	対象	モード	目的
フェーズ 1	単体テストサーバー	監査のみ	ルールの基本動作とログ内容の確認
フェーズ 2	パイロット OU（少数の本番サーバー）	監査のみ → 実施	実運用に近い環境で副作用を確認
フェーズ 3	全社的な対象 OU	実施	本番展開後の安定運用

監査モードでのログ確認方法

「監査のみ」モードでは、AppLocker が「許可／拒否すべきと判断した」イベントがすべてログに記録されます。 Edge のブロックが想定どおりに動くか確認するために、次のポイントをチェックしましょう。

イベントビューアーで AppLocker ログを確認する

1. イベントビューアーを開く。
2. 左ペインで次のパスをたどる：
   • [アプリケーションとサービス ログ] > [Microsoft] > [Windows] > [AppLocker] > [EXE and DLL]
3. Edge を起動し、その直後のイベントを確認する。

監査モードでも、「Edge を拒否するルールがある場合」、Edge 起動に対して 「拒否相当」イベント が記録されます。ここで次の点を確認しておくと安心です。

• 対象となっているファイルパスが msedge.exe であること
• 適用されたルール名が、作成した Edge 拒否規則であること
• 意図しないアプリ（業務アプリなど）が同じルールに巻き込まれていないこと

おおまかなテストシナリオ例

• 標準ユーザーアカウントで Edge を起動し、ログに拒否相当イベントが記録されることを確認
• 管理者アカウントでは Edge を許可したい場合、別途「許可」ルールを追加し、期待どおりに動作するか確認
• 業務アプリ（特に WebView2 ベース）の起動時にも AppLocker イベントが記録されていないか確認

実施モードに切り替えてブロックを確認する

監査ログを確認して問題がなければ、いよいよ「実施」モードに切り替えます。

1. [AppLocker] を右クリックし、[プロパティ] を開く。
2. [実行可能ファイル] の動作を 実施 に変更。
3. gpupdate /force を実行してポリシーを即反映。
4. 対象ユーザーでサインインし、Edge を起動してみる。

成功すれば、「このアプリはシステム管理者によってブロックされています」といったメッセージが表示されるか、あるいは何も起こらずに Edge が起動しない状態になります。同時に、AppLocker の [EXE and DLL] ログには実際の拒否イベントが記録されます。

よくあるつまずきポイントと対処例

ここからは、Windows Server 2025 で Edge をブロックしようとした際に、実際に起こりやすいトラブルと対処法を一覧にまとめます。

症状	主な原因	確認ポイント	対処法
Edge がまったくブロックされない	Application Identity サービスが停止／無効	services.msc や sc query appidsvc で状態を確認	スタートアップを「自動」、状態を「実行中」にし、GPO でも同設定を配布
Edge 以外のアプリまで動かなくなった	既定の規則未作成／過度に厳しい拒否ルール	既定の規則が存在するか、Get-AppLockerPolicy -Effective で確認	既定の規則を作成し、必要なら Edge 拒否ルールの対象ユーザーを限定
ログに何も記録されない	AppLocker コレクションが無効／監査モードも無効	[AppLocker プロパティ] で「監査のみ」または「実施」になっているか	少なくとも「監査のみ」に設定し、gpupdate /force 後に再テスト
業務アプリ（WebView2 ベース）が起動しなくなった	WebView2 の実行ファイルが Edge 拒否ルールに巻き込まれている	イベントログで msedgewebview2.exe がブロックされていないか確認	WebView2 用の「許可」ルールを追加し、Edge 本体のみを拒否する構成に調整
ある OU だけ Edge がブロックされない	別の GPO の AppLocker 設定が上書き／マージされている	gpresult /r や Get-AppLockerPolicy -Effective で有効ポリシーを確認	GPO のリンク順や適用範囲を見直し、Edge 拒否ルールを含む GPO を優先
スタートメニューや設定アプリまで動作がおかしくなった	旧 Edge や Web コンポーネントまで過度にブロック	どの実行ファイルがブロックされているかイベントログで特定	必要なコンポーネントには「許可」ルールを追加し、ピンポイントで Edge を拒否

Edge と WebView2 を区別して制御するポイント

最近のアプリケーションは、Microsoft Edge WebView2（msedgewebview2.exe）を内部ブラウザとして利用するケースが増えています。 AppLocker で Edge 本体をブロックしても、WebView2 ランタイムまで完全に止めてしまうと、次のような副作用が起きやすくなります。

• 新しい Teams クライアントなど、WebView2 ベースのアプリが起動しない
• 業務アプリの一部画面が真っ白になり、ログに WebView2 関連のエラーが出る

そのため、次のような方針が現実的です。

• Edge 本体（msedge.exe）は Publisher ベースの拒否ルールでブロック
• WebView2 ランタイム（msedgewebview2.exe）は、基本的には許可したままにする
• 必要に応じて、WebView2 のパスに対して許可ルールを追加しておく
  • 例：C:\Program Files (x86)\Microsoft\EdgeWebView\Application\*\msedgewebview2.exe など

もし「ブラウザとしての Edge 利用だけを禁止したい」のであれば、WebView2 までは極力止めず、ユーザーのデフォルトブラウザを別のものに切り替える、URL ハンドラを制御するといった別レイヤーの対策も併用すると、業務影響を減らしやすくなります。

ロールバック（解除）と一時的な緩和策

万が一、Edge ブロックのポリシーが思わぬ影響を与えてしまった場合、次のように段階的なロールバックが可能です。

ルール単位での解除

1. 問題の GPO またはローカルポリシーの AppLocker コンソールを開く。
2. Edge 用に作成した「拒否」ルールを右クリックし、[無効] または [削除] を実行。
3. gpupdate /force または再起動でポリシーを再適用。

「無効」にすると、ルール自体は残るため、原因調査後に再度有効化することも簡単です。

コレクション単位で「監査のみ」に戻す

影響範囲が読めない場合は、AppLocker の [プロパティ] で該当コレクション（多くの場合 [実行可能ファイル]）を 一時的に「監査のみ」 に戻します。これにより、実際のブロックは解除され、ログだけが記録される状態になります。

最終手段としての AppIDSvc 停止

どうしても切り分けが難しい場合は、最終手段として Application Identity サービス（AppIDSvc）を停止することで、AppLocker ポリシー自体の評価を止めることも可能です。

sc.exe stop appidsvc

ただし、これは AppLocker による保護をすべて無効化する行為であるため、本番環境ではあくまで緊急時のみ、事前に影響範囲と復旧手順を明確にしたうえで実行してください。

より厳格な制御が必要な場合の WDAC 検討

AppLocker は、Windows Server 環境における代表的なアプリケーション制御機能ですが、近年の Microsoft のセキュリティ戦略では、より厳格な Windows Defender Application Control（WDAC） が推奨されつつあります。

WDAC は、AppLocker よりも低レベルで実行ファイルを制御でき、「許可したもの以外は一切実行させない」ホワイトリスト運用に強みがあります。その反面、設計・検証・運用の負荷は AppLocker より高く、いきなり本番で適用するのは避けるべきです。

現実的なステップとしては、次のような流れが考えられます。

• まずは AppLocker で Edge を含む主要アプリの制御ルールを固める
• AppLocker のログを活用し、「実際に利用されている実行ファイルの一覧」を洗い出す
• その情報を基に、WDAC の許可ポリシー（ホワイトリスト）を設計していく

「Edge だけどうしても止めたい」程度であれば、まずは AppLocker だけで十分対応可能なケースが多いでしょう。組織としてより強固なアプリ制御を進めたい場合に、段階的に WDAC を検討するのがおすすめです。

運用のベストプラクティスとチェックリスト

最後に、Windows Server 2025 環境で「AppLocker で Microsoft Edge をブロックする」運用を継続するうえでのベストプラクティスをまとめます。

設計・導入フェーズのポイント

• 必ず テスト環境 → パイロット → 本番 の 3 段階で展開する
• Edge ブロック専用の GPO を用意し、他のセキュリティポリシーと分離しておく
• AppLocker ポリシーの XML を定期的にバックアップし、変更履歴を残す

日常運用でのチェック項目

• Windows 更新や Edge のメジャーアップデート後に、AppLocker ログに想定外の拒否イベントが増えていないか確認
• 新しい業務アプリを導入する際は、事前にテスト環境で AppLocker との相性を確認
• WebView2 を利用するアプリを追加した場合、必要であれば WebView2 のパスに対する許可ルールを追加

まとめ：Edge ブロックのポイント整理

• Application Identity（AppIDSvc）を「自動＋実行中」にすることは必須
• AppLocker の各コレクションで「既定の規則」を必ず作成してからルール追加
• [実行可能ファイルの規則] に Publisher ベース（製品名: Microsoft Edge）の拒否ルール を作る
• 最初は必ず「監査のみ」で動作確認し、ログで副作用がないことを確認してから「実施」へ
• WebView2（msedgewebview2.exe）は基本的には許可し、Edge 本体だけをピンポイントで拒否する
• 問題が発生した場合は、「ルール無効化 → 監査のみ → 最終手段として AppIDSvc 停止」の順で段階的にロールバックする

これらのポイントを押さえておけば、Windows Server 2025 環境でも Microsoft Edge の利用を確実に制限しつつ、業務アプリへの影響を最小限に抑えた AppLocker 運用が実現しやすくなります。