Windows 10 のマルチアプリ キオスク環境で Disk Cleanup や Microsoft Teams を起動しようとしたとき、「この操作はこのコンピューターの制限により取り消されました」と表示されてしまうことがあります。本記事では、Assigned Access と AppLocker の仕組みを整理しながら、具体的な原因と再発防止を含めた対処方法を詳しく解説します。
マルチアプリ キオスクで発生する「制限」エラーの全体像
Windows 10 の Assigned Access（マルチアプリ キオスク）は、特定のアプリだけを実行させるロックダウン用途でよく利用されます。しかし、運用設計や XML の書き方を少し間違えると、次のようなエラーに悩まされることがあります。
- Disk Cleanup（
cleanmgr.exe）を起動すると「この操作はこのコンピューターの制限により取り消されました」と表示される - イベントログに AppLocker 8004（ブロック） が記録される
- AllowedApps に許可したはずの Microsoft Teams が起動しない
- ログオン直後に「制限」ダイアログが何度も出て、キオスクとして不格好になる
これらはバラバラな症状に見えますが、裏側では共通して「Assigned Access の AllowedApps と AppLocker/GPO の制御が噛み合っていない」ことが原因になっていることがほとんどです。
症状と主な原因の整理
典型的な症状
- Disk Cleanup を起動するとすぐに制限ダイアログが表示される
- ユーザー操作をしていないのに、数分おきに制限ダイアログがポップアップする
- Teams をタイルやショートカットから起動しても、すぐ閉じる／制限ダイアログが出る
- イベント ビューアーの 「Microsoft-Windows-AppLocker/EXE and DLL」 に ID 8004 のログが大量に溜まる
主な原因を一覧で把握する
| カテゴリ | 具体的な原因 | ポイント |
|---|---|---|
| AllowedApps | %SYSTEM32% など存在しない環境変数を使っている | 正しくは %SystemRoot%\System32 か KnownFolder AUMID を使用 |
| AppLocker | AllowedApps では許可しているが、AppLocker の拒否規則が優先されている | AppLocker は「拒否が一つでも当たればブロック」 |
| 32/64bit | System32 と SysWOW64 のどちらかしか許可していない | Disk Cleanup は 32bit/64bit 両方の実体があり、両方許可が無難 |
| GPO / レジストリ | RestrictRun や「指定された Windows アプリケーションのみ実行する」が中途半端 | 許可リストに cleanmgr.exe や Teams.exe が含まれていない |
| スケジュールタスク | SilentCleanup などがユーザー対話で動き、AppLocker でブロック | 結果として「制限」ダイアログだけがユーザー画面に残る |
Disk Cleanup（cleanmgr.exe）が制限エラーになる原因と対処
AllowedApps における環境変数の誤用
マルチアプリ キオスクの構成 XML（AllowedApps）で、次のように書いている環境は要注意です。
<App DesktopAppPath="%SYSTEM32%\cleanmgr.exe" />
%SYSTEM32% は標準の環境変数ではありません。そのため、Assigned Access がアプリ パスを正しく解決できず、AppLocker 側の評価結果と食い違いが発生します。
正しい記述方法は次のいずれかです。
- KnownFolder AUMID（推奨）
<App AppUserModelId="{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\cleanmgr.exe" />
- 絶対パスで指定（System32 / SysWOW64 両方）
<App DesktopAppPath="C:\Windows\System32\cleanmgr.exe" />
<App DesktopAppPath="C:\Windows\SysWOW64\cleanmgr.exe" />
GUID {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7} は、System32 を表す KnownFolder を指しています。これに \cleanmgr.exe を組み合わせることで、パスに依存しない形で Disk Cleanup を許可できます。
実際の修正手順（例）
- 現在のキオスク構成 XML をエクスポートする（WICD／Intune／ローカルポリシーなど、運用に応じて）
%SYSTEM32%など未定義の環境変数を使っている <App> 要素を探す- 該当部分を AUMID か絶対パスのいずれかに置き換える
- XML を再度インポート／再配布して端末を再起動
- キオスクユーザーでサインインし、Disk Cleanup がエラーなく起動するか確認
すでに、この修正だけで「制限」ダイアログが出なくなった事例が多数報告されています。
AppLocker の許可規則を明示的に追加する
Assigned Access の AllowedApps を正しても、AppLocker でブロックされていては実行できません。特に「すべて禁止＋一部だけ許可」ポリシーの場合、Disk Cleanup の EXE に対する明示的な許可が必要です。
AppLocker イベントの見方
| イベント ID | 意味 | チェックポイント |
|---|---|---|
| 8002 | 実行が許可された EXE/DLL | どのルールで許可されたかを確認 |
| 8004 | 実行がブロックされた EXE/DLL | どのルールで拒否されたか、パスやユーザーを確認 |
同じアプリで 8002 と 8004 が両方出ている場合は、
- 32bit / 64bit で別々に評価されている
- 通常実行とスケジュールタスク実行など、別コンテキストで 2 回評価されている
といった可能性があります。
Disk Cleanup を AppLocker で確実に許可する
以下のような規則を追加するのが基本です。
- パス規則
%SystemRoot%\System32\cleanmgr.exe
%SystemRoot%\SysWOW64\cleanmgr.exe
- Publisher（署名者）規則
Disk Cleanup は Microsoft 署名のシステムバイナリなので、「発行元 = Microsoft Corporation」で範囲指定する方法もあります。ただし影響範囲が広がるため、検証環境で十分にテストしてから本番に適用してください。
いずれの場合も、拒否規則より上位に許可規則を配置することが重要です。AppLocker では、最終的に拒否と判断された時点でブロックされ、AllowedApps の設定よりも優先されます。
System32 と SysWOW64 の両方を許可する理由
Windows 10（64bit）では、同じ機能の EXE が 32bit / 64bit で別々の場所に存在します。
| アーキテクチャ | 実体パス | 補足 |
|---|---|---|
| 64bit | C:\Windows\System32\cleanmgr.exe | 64bit プロセスから見た標準の System ディレクトリ |
| 32bit | C:\Windows\SysWOW64\cleanmgr.exe | 32bit アプリから見ると、ここが「System32」として扱われる |
AppLocker や RestrictRun では どちらか片方しか許可していないと、別経路で起動した際にブロックされることがあります。特に、スケジュールタスクやシェルからの起動パスが異なる場合、キオスク画面上で突然制限ダイアログが出る原因になります。
RestrictRun と GPO の影響を整理する
RestrictRun が有効な場合の注意点
ユーザー毎のレジストリで次の設定が有効な場合、実行可能な EXE は「許可リスト」に含まれているものだけになります。
| キー | 値 | 意味 |
|---|---|---|
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\RestrictRun | 1 | RestrictRun 機能が有効 |
この状態で Disk Cleanup や Teams を動かしたい場合は、同じキー配下に次のような値を追加します。
cleanmgr.exeTeams.exeUpdate.exe（旧デスクトップ版 Teams のアップデータ）
GPO「指定された Windows アプリケーションのみ実行する」
同様に、ローカル／ドメイン GPO で次のポリシーが有効な場合も、許可リストが不足していると制限ダイアログの原因になります。
- ユーザーの構成 > 管理用テンプレート > システム > 指定された Windows アプリケーションのみ実行する
このポリシーは、「書いたものだけ動く」ホワイトリスト方式です。キオスク用ユーザーに適用されている場合は、次のような項目を漏れなく追加します。
cleanmgr.exeexplorer.exe（必要に応じて）Teams.exe/Update.exe/ その他依存 EXE
gpresult /h や PowerShell の Get-GPResultantSetOfPolicy を使って、実際にどの GPO が有効かを確認しておくと、思わぬポリシーの重なりによるトラブルを防げます。
Get-GPResultantSetOfPolicy -Computer <PC名> -User <ユーザー> -ReportType Html -Path C:\GPresult\result.html
SilentCleanup などスケジュールタスクが「制限」ダイアログを出している場合
キオスク環境では、ユーザーが何も操作していないのに定期的に制限ダイアログが現れることがあります。代表例が、Disk Cleanup 関連のスケジュールタスクです。
タスク スケジューラの次の場所を確認します。
- タスク スケジューラ > タスク スケジューラ ライブラリ > Microsoft > Windows > DiskCleanup
ここには、例えば SilentCleanup といったタスクが存在します。これが「ユーザーがログオンしているときのみ」かつ「ユーザーの権限」で実行されるようになっていると、
- タスク起動 → AppLocker でブロック → エラーとして制限ダイアログが表示
という流れで、キオスク画面にダイアログだけが残ってしまいます。
対策案
- タスクの実行アカウントを SYSTEM に変更し、「ユーザーがログオンしているかどうかにかかわらず実行する」に設定する
- Disk Cleanup に依存する運用を見直し、Storage Sense や他のクリーンアップ方法に移行する
- どうしても不要なタスクであれば、スケジュールタスク自体を無効化する
なお、AppLocker を「監査のみ」にするとダイアログは出なくなりますが、実行がすべて許可されるため、キオスク用途では安全ではありません。あくまで検証時の一時設定と考えるべきです。
Microsoft Teams がキオスクで起動しない場合の対処
Teams の種類と AUMID を整理する
Teams はバージョンやインストール形態によって AUMID が異なります。AllowedApps に別の AUMID を書いてしまうと、キオスクでは起動できません。
| 種類 | インストール形態 | 代表的な AUMID | 補足 |
|---|---|---|---|
| 旧デスクトップ版 Teams | ユーザー配下（Squirrel / Electron） | com.squirrel.Teams.Teams | 従来の Teams クライアント |
| 新 Teams（MSIX） | パッケージアプリ（MSIX） | MSTeams_8wekyb3d8bbwe!MSTeams | 「新しい Teams」クライアント |
実機で AUMID を確認する方法
確実なのは、実際に Teams がインストールされている端末上で AUMID を取得することです。
- shell:Appsfolder から確認
- [Win] + [R] で「ファイル名を指定して実行」を開く
shell:Appsfolderと入力し、OK をクリック- Teams のショートカットを右クリック > プロパティから AUMID を確認
- PowerShell で確認
Get-StartApps | Where-Object Name -like "*Teams*"
ここで表示された AUMID を、そのまま AllowedApps の XML に記述します。
Teams の依存プロセスも許可する
Teams は単体の EXE だけで動いているわけではありません。特に旧デスクトップ版では、Squirrel Updater やバックグラウンドプロセスなど、複数の EXE が連携しています。
| プロセス名 | パス例 | 役割 |
|---|---|---|
Teams.exe | %LocalAppData%\Microsoft\Teams\current\Teams.exe | メインのクライアント |
Update.exe | %LocalAppData%\Microsoft\Teams\Update.exe | Squirrel ベースのアップデータ |
CrossDeviceResume.exe | 環境によりパスは異なる | ログオン直後に動作し、制限ダイアログの原因になることがある |
AppLocker や RestrictRun で Teams 本体だけを許可していると、Update.exe や CrossDeviceResume.exe がブロックされてダイアログが表示されるケースがよくあります。次のような方針で許可範囲を見直してください。
- Teams 関連の実行ファイルを イベントログから洗い出す（AppLocker 8004）
- 必要なものだけを RestrictRun の許可リストに追加する
- AppLocker では、
%LocalAppData%\Microsoft\Teams\*をパス規則で許可するなど、影響範囲とセキュリティのバランスを取る
AppLocker と Assigned Access の両方で Teams を許可する
Teams がキオスクで起動しない場合、次の二つの層で許可されているかを必ず両方確認します。
- Assigned Access（AllowedApps）
Teams の AUMID（例：com.squirrel.Teams.TeamsまたはMSTeams_8wekyb3d8bbwe!MSTeams）が正しく記載されているか。 - AppLocker
EXE 規則／パッケージアプリ規則で Teams とその依存プロセスが確実に許可されているか。
特に新 Teams（MSIX）は「パッケージ化されたアプリ」として扱われるため、AppLocker の「パッケージ アプリ」規則で MSTeams パッケージを許可する必要があります。
運用補足と再発防止チェックリスト
重要ポイントの整理表
| チェック項目 | 確認する内容 | ポイント |
|---|---|---|
| AllowedApps の記述方法 | AUMID または絶対パスで記述されているか | 未定義の環境変数を使わない（例：%SYSTEM32% は NG） |
| 32/64bit の両対応 | System32 と SysWOW64 の両方を許可しているか | Disk Cleanup などは両方の実体が存在するため、両方許可が基本 |
| AppLocker のルール | 拒否規則が優先されていないか、順序と適用範囲を確認 | 必要な EXE は明示的な許可規則を作る |
| RestrictRun / DisallowRun | 許可リストに不足がないか、不要な拒否が紛れていないか | cleanmgr.exe、Teams.exe、Update.exe などを忘れずに |
| スケジュールタスク | SilentCleanup など UI を伴うタスクがユーザー対話で動いていないか | SYSTEM アカウントで非対話実行、または無効化・代替機能へ移行 |
| ツールと OS のバージョン | WICD/ADK のバージョンと OS ビルドが揃っているか | 21H1 など OS ビルドに合わせたツールを使うと誤挙動が減る |
| 管理方式 | 可能であれば Intune で一元管理できているか | Intune のキオスク構成＋アプリ許可ポリシーに移行すると安定しやすい |
実務向けトラブルシュート手順例
現場で調査するときの手順の一例です。
- キオスクユーザーでサインインし、問題のアプリ（Disk Cleanup / Teams）を起動して症状を再現
- イベント ビューアーで AppLocker の 8002 / 8004 イベントを確認し、どのパス・ユーザー・ルールでブロックされているか特定
- イベントに記載された EXE パスをもとに、AppLocker の許可・拒否規則を見直す
- 必要に応じて、
Get-AppLockerPolicy -Local -Xmlで現在のポリシーを XML として確認 - AllowedApps XML の記述（AUMID／パス）と、実際のアプリの場所が一致しているかを検証
- RestrictRun／「指定された Windows アプリケーションのみ実行する」GPO が有効なら、許可リストの漏れがないか確認
- スケジュールタスク（DiskCleanup / Teams 関連）がユーザー対話で動いていないかをチェック
- 修正後は、テスト用端末でキオスクユーザーを新規プロファイルから作り直し、クリーンな状態で挙動を確認
- 問題が解消したら、変更内容と根本原因を運用ドキュメントに反映し、再発防止策としてチームに共有
よくある勘違いと注意点
「%SYSTEM32% は Windows 標準の変数だと思っていた」
実際には %SYSTEM32% という環境変数は存在しません。たまたま別の設定で動いている端末を見て、そのまま真似してしまうと、別環境では動かなくなる原因になります。必ず、
%SystemRoot%\System32（正しい組み合わせ）- KnownFolder AUMID（
{1AC14E77-...}\cleanmgr.exeなど）
のいずれかを使うようにしましょう。
「AllowedApps に書けば AppLocker は無視される」
Assigned Access（AllowedApps）はあくまで「キオスクで選べるアプリのリスト」に過ぎません。実際の実行可否は、
- AppLocker のルール
- GPO / RestrictRun / DisallowRun
などのポリシーの影響を強く受けます。AppLocker の拒否規則が一つでも当たると、AllowedApps で許可していても起動できません。
「ダイアログだけ消せないか？」
ユーザーにダイアログを見せたくないというニーズはよくありますが、
- AppLocker を「監査のみ」にする → 実行も許可されてしまう
- エラーダイアログを抑制するレジストリや GPOは基本的に用意されていない
という事情から、根本原因（許可漏れ）を修正することが唯一の正攻法です。ダイアログを無理に隠すのではなく、「本来ブロックされるべきでないものを正しく許可する」方針で設計することが重要です。
まとめ：キオスク環境では「許可の設計」がすべて
- Disk Cleanup（cleanmgr.exe）の制限エラーは、AUMID か正しいパス指定に修正し、AppLocker で確実に許可することで解消した事例が多数あります。
%SYSTEM32%のような未定義の環境変数を AllowedApps で使わないこと、System32とSysWOW64の両方を許可することがポイントです。- Teams は AUMID の取り違えと依存プロセス（Teams.exe / Update.exe / CrossDeviceResume.exe など）の未許可が典型的な詰まり所です。
- AppLocker / RestrictRun / GPO の複数レイヤーでホワイトリストが重なっているため、どこか一か所でも漏れがあると「この操作は…制限により取り消されました」が発生します。
- ダイアログそのものを隠す設定は基本的に存在しないため、正しい許可設計と運用ドキュメントの整備こそが再発防止の近道です。
- 可能であれば Intune などのモダン管理に移行し、キオスク構成と AppLocker を一元管理することで、設定のばらつきを減らすことができます。
キオスク環境では、「何を禁止するか」よりも「何を確実に許可するか」を丁寧に設計することが重要です。本記事の内容をベースに、自社環境に合わせたチェックリストやテンプレートを作成しておくと、今後のトラブルシュートが格段に楽になります。
コメント