Assigned AccessはWindows Proでも使えますか？

使えます。Assigned Access(シングルアプリキオスクとマルチアプリの制限付きユーザー体験)はPro / Enterprise / Education / IoT Enterprise(それぞれのLTSC含む)でサポートされます。一方、Explorer.exe自体を業務アプリに置き換えるShell LauncherはEnterprise / Education / IoT Enterprise系のみで、Proでは使えません。また、キオスク体験にはUACが有効であることと、コンソールからのサインインが必要で、リモートデスクトップ接続越しのキオスク体験はサポートされません。

Win32(デスクトップ)アプリをキオスクにするにはShell Launcherが必須ですか？

Windows 11では必須ではなくなりました。Windows 11(21H2以降のスキーマ)のAssigned Accessは、KioskModeApp要素のv4:ClassicAppPath属性でデスクトップアプリの実行ファイルパスを指定でき、Pro端末でもWin32アプリのシングルアプリキオスクを構成できます。Windows 10のAssigned AccessキオスクはUWPアプリとMicrosoft Edgeに限られるため、Win32アプリを1本だけ動かすならShell Launcher(Enterprise系限定)か、マルチアプリ構成でAutoLaunchを使う方法が現実解になります。エディションと方式の対応を先に確認してから設計してください。

キオスクアプリが異常終了したら自動で復帰しますか？

方式により挙動が異なります。Assigned Accessのシングルアプリキオスクは、アプリが閉じられると自動的に再起動される仕様です。Shell Launcherでは、シェルにしたアプリの終了時の動作をDefaultActionとReturnCodeActionsで宣言的に構成でき、RestartShell(シェル再起動)・RestartDevice(端末再起動)・ShutdownDevice・DoNothingから選べます。終了コードに対応するアクションが未定義でDefaultActionもない場合は何も起きず黒画面のまま止まるため、DefaultActionは必ず定義してください。アプリ側にも未処理例外時に自らを終わらせて復帰動作へつなぐ設計が必要です。

保守員はどうやって管理者としてログインすればよいですか？

Assigned Accessのキオスク体験は、既定ではCtrl+Alt+Delでサインイン画面へ抜けられ、Windows 11ではBreakoutSequence要素でこのキー組み合わせを変更できます。Keyboard FilterでCtrl+Alt+Delごと塞ぐ構成では、Keyboard Filter側のブレイクアウトキー(既定は左Windowsキーを5回連打)でようこそ画面に戻る経路を残せます。キオスク体験自体はコンソール専用ですが、管理者アカウントでのリモートデスクトップ保守は別セッションとして併用できます。脱出経路を全部塞いでしまい現地作業でしか復旧できない端末にしないことが重要です。

自動ログオンのパスワードをレジストリに書くのは安全ですか？

推奨しません。WinlogonのAutoAdminLogon方式はDefaultPasswordがレジストリに平文で残ります。Assigned AccessとShell Launcherの構成XMLにはAutoLogonAccount要素があり、これを使うとWindowsが専用のローカル標準ユーザーを自身で作成・管理して自動サインインするため、パスワードを自分で保管する必要がありません。キオスク用アカウントは最小権限のローカル標準ユーザーとし、ドメインアカウントの流用は避けるのが原則です。なお、Exchange ActiveSyncのパスワード制限ポリシーが効いている端末では自動ログオンが動作しない点にも注意してください。

キオスクモードで業務端末を固める ── Assigned Access・Shell Launcherの選び方と運用設計

2026年07月24日 00:40 · 更新日: 2026年09月12日 · 小村豪 · キオスクモード, Assigned Access, Shell Launcher, Windows 11, 業務端末, 装置連携, 情シス, 運用設計

更新履歴(4件・最終更新 2026年08月02日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

2026年08月02日: 記事の冒頭に「この記事の知識マップ」節を追加しました。本文で扱っている概念とその関係を、要約・図・詳細ページへのリンクにまとめたものです。本文の主張は変えていません。
2026年08月01日: 外部レビュー(1283件)への対応として本文を更新しました。個々の変更内容は、この下の履歴を参照してください。
2026年07月31日: WMIブリッジで構成を実際に適用する手順を、SYSTEM権限での起動から適用・解除まで通しで書き起こしました。あわせて適用できたかを確かめる方法(イベントログの場所、レジストリ、構成の読み戻し)、設定アプリでの手順、AUMIDの確認方法を追加しています。
2026年07月31日: 構成XMLのGUIDを「申請したGUID」と書いていたため、どこかへ申請して取得するものと読めていたのを「自分で採番したGUID」に改め、New-Guid で生成する手順を補いました。
2026年07月24日: 初版公開

この記事を引用する(DOI（登録済みアーカイブ）: 10.5281/zenodo.21547429)

以下のDOIは過去に登録されたアーカイブを指しており、現在の本文とは一致しない場合があります。現在の本文を参照するときは、このページのURLを使用してください。

小村豪(2026)「キオスクモードで業務端末を固める ── Assigned Access・Shell Launcherの選び方と運用設計」合同会社小村ソフト. https://comcomponent.com/blog/windows-kiosk-mode-assigned-access-guide/

DOI（登録済みアーカイブ）: 10.5281/zenodo.21547429
DOI（前回登録した版）: 10.5281/zenodo.21733139

「受付端末なのに、来客がタスクバーから別のアプリを開いていた」「装置の操作画面を閉じると、普通のデスクトップが出てしまう」。業務アプリを自動起動するだけでは、そのPCを専用端末にはできません。

必要なのは、使わせるアプリを決めること、許可しない操作を止めること、故障や保守のときに戻れることを、まとめて設計することです。WindowsにはAssigned AccessとShell Launcherがありますが、守れる範囲も、使えるエディションも違います。

この記事では、受付・展示・工場の操作端末・検査装置の操作画面を作る開発者と情シス担当者向けに、方式の選定、設定、適用確認、無人運用の順に整理します。PowerShellとXMLの例を使いながら、OS側の制限と業務アプリ側の設計を分けて説明します。

1. まず結論：自動起動とキオスク化は別の仕事

「自動ログオン＋スタートアップ起動」だけでは、キオスクにはなりません。Explorerがそのまま動いているため、Alt+TabやWindowsキーから別の画面へ移れます。サインインや起動を自動化することと、利用者の操作を制限することは別です。

方式は、まず次の用途で選びます。使えるエディションとWindowsのバージョンは、2章で確認してください。¹²³

作りたい端末	第一候補	選ぶ理由
来客や不特定の人が、1つのアプリだけを使う受付・展示端末	Assigned Accessのシングルアプリキオスク	対象アプリだけを全画面で使わせ、閉じられたら自動再起動する
決まった数個のアプリを使う共有端末	マルチアプリキオスク（制限付きユーザー体験）	許可アプリの一覧と専用スタートメニューを用意する
Explorer自体をなくし、業務アプリを装置の操作画面にする端末	Shell Launcher	シェルを置き換え、アプリの終了コードに応じた復帰動作を決める

ただし、Shell Launcherはシェルを置き換える機能であり、他のアプリの起動を禁止する機能ではありません。必要ならAppLockerやKeyboard Filterを併用します。また、同じ端末にシングルアプリのKioskModeAppとShell Launcherを同時には設定できません。³²

設定の入口は共通化されています。シングルアプリ・マルチアプリ・Shell Launcherは、AssignedAccess CSPをMDMから構成するか、ローカルのWMIブリッジから構成します。WMIブリッジのデバイス設定は、管理者ではなくSYSTEMで実行するのが重要な前提です。⁴⁵

いま知りたいこと	読むところ
Proの端末で何ができるか、方式を決めたい	2章：方式と利用条件
Edge・UWPを1台で試したい	3章：Assigned Accessの設定経路
Windows 11のWin32アプリをXMLで設定したい	4章：XMLとWMIブリッジ
エラーはないのに動かない、設定を解除したい	5章：適用確認と解除
業務アプリをExplorerの代わりに動かしたい	6章：Shell Launcher
再起動・更新・保守まで含めて運用したい	7章：運用設計 → 8章：アプリ側の設計

どの方式でも、保守員のサインイン経路を残してください。OSの制限だけでなく、全画面UI、異常終了からの復帰、昇格不要といったアプリ側の設計も必要です。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 方式と利用条件を先に確認する

2.1 4つの方式を「何を止めるか」で比較する

見た目が全画面でも、守れる範囲は同じではありません。Explorerが残るか、許可外アプリの起動を誰が止めるかを比較します。

方式	動くアプリ	シェルの状態	守れる範囲	エディション
自動ログオン+スタートアップ起動	何でも	Explorerそのまま	ほぼ何も守れない(Alt+Tab、Winキー、タスクマネージャーすべて素通し)	全エディション
Assigned Access シングルアプリキオスク	UWP / Edge(Windows 11はWin32も可²)	ロック画面の上で対象アプリのみ全画面。閉じても自動再起動¹	デスクトップ・スタートメニューに触れない。既定の脱出はCtrl+Alt+Delのみ	Pro以上¹
マルチアプリキオスク(制限付きユーザー体験)	許可リストのアプリ(UWP/Win32混在可)	専用スタートメニュー+AppLockerで許可外の起動をブロック²	許可外アプリの起動を阻止。ただしAlt+F4やCtrl+Alt+Delは既定で生きている⁶	Pro以上¹
Shell Launcher	任意のWin32 / UWPアプリをシェルに	Explorer.exe自体が存在しない(CustomShellHost.exeが業務アプリを起動・監視)³	タスクバーもスタートも無い。ただし他アプリの起動自体は防がないので、必要ならAppLocker等を併用³	Enterprise / Education / IoT Enterprise系のみ³

マルチアプリキオスクはAssigned Accessの制限付きユーザー体験です。UWPとWin32を混在させた許可リストを作り、専用スタートメニューと自動生成されるAppLockerルールで、許可外アプリの起動を止めます。一方、Alt+F4・Alt+Tab・Ctrl+Alt+Delは既定でブロックされないため、必要なキー抑止と保守経路は7.4節で設計します。²⁶

装置向けにShell Launcherを選ぶ利点は、タスクバーやスタートメニューなど、Explorer由来のUIが存在しないことです。終了コード別の復帰動作も構成できます。ただし、アプリ内部から別のプログラムを起動する経路まで消えるわけではありません。³⁷

2.2 エディションとWindowsのバージョンを分けて見る

先にエディションを確認し、そのあとで対象アプリを動かせるWindowsのバージョンかを確認します。「ProでShell Launcherを使おうとしていた」という手戻りを、ここで防ぎます。

機能	利用できるエディション
Assigned Access（シングルアプリ／マルチアプリ）	Pro、Enterprise／Enterprise LTSC、Education、IoT Enterprise／IoT Enterprise LTSC
Shell Launcher	Enterprise／Enterprise LTSC、Education、IoT Enterprise／IoT Enterprise LTSC。Proは対象外
Keyboard Filter	Enterprise、Education、IoT Enterprise系。Proは対象外

この対応は、各機能の公式なエディション要件に基づきます。¹³⁸

「ProでWin32アプリを1本だけ動かしたい」という要望は、Windowsのバージョンで分かれます。²

Windows 11では、21H2以降のスキーマで追加されたv4:ClassicAppPathにEXEのパスを指定し、Assigned Accessのシングルアプリキオスクにします。
Windows 10 Proでは、シングルアプリキオスクの対象はUWP／Edgeです。Win32アプリなら、UWP化、マルチアプリ構成＋rs5:AutoLaunchによる自動起動、またはエディション変更を検討します。

産業用PCを新規調達できるなら、Shell LauncherとKeyboard Filterを使え、機能更新を前提にしないIoT Enterprise LTSCが本命です。選定の考え方は「産業用PCのWindows選び ── IoT Enterprise LTSC実践ガイド」にまとめています。

2.3 キオスクの動作確認はコンソールで行う

Assigned Accessのキオスク体験には、UACが有効であることと、コンソールからのサインインが必要です。RDP接続越しのキオスク体験はサポートされません。「RDPで試して動かない」を設定失敗と取り違えないでください。¹

管理者が別セッションでRDP保守を行うこととは別の話です。セッションの違いは「Windowsのセッション分離をどう理解するか」を参照してください。キオスク利用者は最小権限のローカル標準ユーザーを原則とし、ドメインアカウントの流用は避けます。⁶

3. Assigned Access：設定方法を選ぶ

まず設定経路を選びます。Win32アプリ、自動ログオン、脱出キーの変更まで含めて構成する場合は、4章のXML方式へ進んでください。

設定経路	向いている用途	注意点
設定アプリ	1台だけ、Edgeまたは単純なUWPアプリ	ウィザードでアカウントとアプリを選ぶ
`Set-AssignedAccess`	ローカル標準ユーザーをUWPアプリ専用にする	UWP限定。管理者・ドメインアカウントは指定できない
構成XML＋AssignedAccess CSP	Win32、脱出キー、自動ログオンを含む構成	MDMから配布するか、SYSTEMのWMIブリッジで適用する

設定アプリとCSPの手順はクイックスタート、コマンドレットの制約はSet-AssignedAccessの資料で確認できます。⁴⁹

3.1 設定アプリでEdge・UWPを構成する

設定アプリは、キオスク用ローカルアカウントの作成と対象アプリの選択をまとめて行える、最短の経路です。⁴

設定 > アカウント > 他のユーザーを開きます。
「キオスクモードのセットアップ」の「開始する」を押します。
「アカウントの作成」で名前を入力し、「次へ」を押します。既存のローカル標準ユーザーを選ぶこともできます。
サインイン時に実行するアプリを選びます。Edgeの場合は、全画面のデジタルサイネージか一部の操作を残すパブリックブラウザーか、起動URL、パブリックブラウザーの無操作時の再起動間隔を設定します。
「閉じる」を押し、端末を再起動します。

再起動後は、作成したローカルアカウントが自動サインインし、指定アプリが起動します。1台だけでEdgeか単純なUWPアプリを使うなら、この方法で十分です。⁴

3.2 PowerShellでUWPアプリを指定する

Set-AssignedAccessは、ローカル標準ユーザーを1つのUWPアプリ専用にするコマンドレットです。Windows 11でWin32を構成できることと、このコマンドレットがUWP限定であることを混同しないでください。⁹²

# ローカル標準ユーザー KioskUser を UWPアプリ専用にする
Set-AssignedAccess -UserName 'KioskUser' -AppUserModelId 'Contoso.KenkiPanel_abc123!App'

# 解除
Clear-AssignedAccess

AUMID（AppUserModelID）はGet-StartAppsで調べます。戻り値のNameとAppIDのうち、AppID列が構成に渡す値です。¹⁰

# 一覧から目視で探す
Get-StartApps

# 名前の一部で絞る(ワイルドカード可)。AppID列の値がそのままAUMID
Get-StartApps -Name '*KenkiPanel*' | Format-Table Name, AppID -AutoSize

出力例です。実際の値は環境ごとに異なります。

Name              AppID
----              -----
KenkiPanel        Contoso.KenkiPanel_abc123!App

Get-StartAppsが調べるのは、実行中のユーザーのアプリです。キオスクアカウント向けにプロビジョニングしたアプリを調べるなら、そのアカウントでサインインして実行します。管理者で一覧に出ないことだけで、アプリがないとは判断しません。¹⁰

UWPアプリの更新でAUMIDが変わる場合は、キオスク構成も更新する必要があります。⁶

4. XMLとWMIブリッジで構成を適用する

4.1 XMLで、アプリ・ユーザー・脱出キーを結び付ける

XML方式では、アプリを定義するProfileと、それを使うアカウントのConfigを対応付けます。MDMでは./Vendor/MSFT/AssignedAccess/ConfigurationへXMLを設定します。MDMがない端末では、4.2節のWMIブリッジから同じ構成を適用します。⁴

次は、Windows 11でWin32アプリを指定する例です。v4:ClassicAppPathがEXEのパス、v4:ClassicAppArgumentsが引数、BreakoutSequenceが脱出キーです。AutoLogonAccountはWindowsが専用のローカル標準ユーザーを作成・管理する指定です。²

<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
    xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <!-- Windows 11: Win32アプリをキオスクにする(引数も渡せる) -->
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe"
                    v4:ClassicAppArguments="--line 3" />
      <!-- 脱出キーを既定のCtrl+Alt+Delから変更する -->
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <!-- Windowsが専用のローカル標準ユーザーを作成・管理して自動サインイン -->
      <AutoLogonAccount rs5:DisplayName="受付端末" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>

UWPの場合はKioskModeAppのAppUserModelIdにAUMIDを指定します。シングルアプリのキオスクプロファイルはユーザーにだけ割り当てられ、グループには割り当てられません。²

Profile IdとDefaultProfile Idは同じGUIDにします。GUIDは申請するものではなく自分で採番する識別子で、生成方法は6.2節に示します。アプリのパス・引数・AUMIDは対象端末に合わせて置き換え、更新後も一致しているか確認してください。⁷⁶

4.2 SYSTEMで起動し、XMLをHTMLエンコードして渡す

以下はMDMがない端末での手順です。デバイス設定を扱うMDMブリッジWMIプロバイダーは、SYSTEM（LocalSystem）での実行が必要で、管理者として開いただけのPowerShellでは足りません。⁴

手順1：SYSTEMのPowerShellを起動する。公式に案内されているSysinternalsのPsExecを使います。管理者として開いたコマンドプロンプトから実行してください。

:: 管理者としてコマンドプロンプトを開き、SYSTEM権限の対話的PowerShellを起動する
psexec.exe -i -s powershell.exe

手順2：実行アカウントを確認する。起動したPowerShellで、SYSTEMになっていることを確かめます。

# NT AUTHORITY\SYSTEM と表示されればOK
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

手順3：同じSYSTEMセッションでXMLを適用する。MDM_AssignedAccessのConfigurationに、XMLをそのままではなくHTMLエンコードした文字列として渡します。⁴

$assignedAccessConfiguration = @"
<?xml version="1.0" encoding="utf-8"?>
<AssignedAccessConfiguration xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config" xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config" xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe" v4:ClassicAppArguments="--line 3" />
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount rs5:DisplayName="受付端末" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>
"@

$namespaceName = "root\cimv2\mdm\dmmap"
$className     = "MDM_AssignedAccess"

$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
# XMLはそのままではなく、HTMLエンコードして渡す
$obj.Configuration = [System.Net.WebUtility]::HtmlEncode($assignedAccessConfiguration)
Set-CimInstance -CimInstance $obj

手順4：端末を再起動する。再起動後のコンソールサインインで、AutoLogonAccountが作成したアカウントの自動サインインと、指定アプリの起動を確認します。構成を書き込むだけで完了とはせず、次章の確認まで行ってください。⁴

5. 適用結果を確認し、必要なら解除する

5.1 「値が入ったか」と「意図どおり動くか」を分ける

エラーが出なかったことだけでは、構成が正しく動くとは限りません。CSPの読み戻し、イベントログ、レジストリを使って、どこで止まっているかを切り分けます。

まず、適用時と同じSYSTEMのPowerShellでCSPから読み戻します。エンコードされたままの値は、デコードして確認できます。

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration

# エンコードされたまま返って読みにくい場合はデコードして目視する
[System.Net.WebUtility]::HtmlDecode($obj.Configuration)

値が空なら構成の書き込みを、値が入っているのに動かないならアプリのパス、ProfileとConfigのGUID、エディションやバージョンの条件を確認します。適用時にエラーが出た場合は、最初に4.2節のSYSTEM確認へ戻ってください。

5.2 ログとレジストリで構成を追う

構成XMLの検証エラーや実行時の失敗の確認先は、次のイベントログです。既定で無効の場合は「ログの有効化」を選び、有効にしてから問題を再現させます。⁶

イベント ビューアー
  > アプリケーションとサービス ログ
    > Microsoft
      > Windows
        > AssignedAccess
          > Operational

レジストリでは、次のキーに構成が記録されます。端末全体とユーザー単位のどちらを見ているかにも注意してください。⁶

キー	内容
`HKLM\Software\Microsoft\Windows\AssignedAccessConfiguration`	端末に適用されている構成
`HKLM\Software\Microsoft\Windows\AssignedAccessCsp`	CSP経由で設定された構成
`HKCU\SOFTWARE\Microsoft\Windows\AssignedAccessConfiguration`	そのユーザーに適用されている構成

ここでの読み戻しとログ確認に加えて、コンソールで指定アプリが起動すること、脱出キーから保守員がサインインできることまで確認します。RDPでの管理者保守と、キオスク体験の確認は別です。¹²

5.3 XMLで設定したAssigned Accessを解除する

WMIブリッジで設定した構成は、同じSYSTEM権限のPowerShellからConfigurationを$nullにし、端末を再起動して解除します。⁴

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration = $null
Set-CimInstance -CimInstance $obj

3.2節のSet-AssignedAccessによる最小構成を解除するコマンドは、その節のClear-AssignedAccessです。ここで扱っているのはAssigned AccessのConfigurationであり、Shell Launcherの構成先は次章のShellLauncherプロパティです。⁹⁵

6. Shell Launcher：Explorerを業務アプリに置き換える

6.1 シェルの置換と、アプリの起動制限を分ける

Enterprise系エディションを使える装置端末では、Shell Launcherが有力です。v2（Windows 10 1809以降）は、Explorer.exeに代わってCustomShellHost.exeが業務アプリを起動・監視し、Win32とUWPをシェルにできます。³

ただし、採用前に次の制約を確認します。³

指定したプロセスの終了を監視します。別プロセスを起動して自分は終了するランチャー型EXEはシェルにできません。公式資料の例はwrite.exeです。
シェルはサインインユーザーの権限で動きます。管理者を割り当てれば、その権限を渡すことになります。昇格を必要とするシェルはUACの無効化を要求するため、そうしなくて済むようアプリを昇格不要に設計します。
他アプリの起動は、それだけでは止まりません。業務アプリのファイルダイアログなどからEXEを起動できる経路が残り得ます。信頼できない利用者が触る端末では、AppLockerやKeyboard Filterを併用します。

6.2 GUIDを対応付け、終了時の動作をXMLで定義する

Shell Launcherでは、終了コードに応じた復帰動作をXMLで宣言できます。次の例は、未割り当てユーザーには通常のExplorerを残し、専用アカウントに業務アプリを割り当てる構成です。{自分で採番したGUID}は、実際のGUIDへ置き換えてから使ってください。⁷

<ShellLauncherConfiguration
    xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration"
    xmlns:V2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
  <Profiles>
    <DefaultProfile>
      <!-- 保守員など、プロファイル未割り当てのユーザーは通常のExplorer -->
      <Shell Shell="%SystemRoot%\explorer.exe" />
    </DefaultProfile>
    <Profile Id="{自分で採番したGUID}">
      <Shell Shell="%ProgramFiles%\Contoso\KensaPanel.exe" V2:AppType="Desktop"
             V2:AllAppsFullScreen="true">
        <ReturnCodeActions>
          <ReturnCodeAction ReturnCode="0"  Action="RestartShell"/>   <!-- 正常終了→再起動 -->
          <ReturnCodeAction ReturnCode="10" Action="RestartDevice"/>  <!-- 要再起動を要求 -->
        </ReturnCodeActions>
        <DefaultAction Action="RestartShell"/>
      </Shell>
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount/>  <!-- ローカル標準ユーザー「Kiosk」を自動作成・自動サインイン -->
      <Profile Id="{自分で採番したGUID}"/>
    </Config>
  </Configs>
</ShellLauncherConfiguration>

GUIDはXML内で一意になるよう自分で採番します。どこかへ申請する必要はなく、PowerShellのNew-Guidで生成できます。⁷

# 波かっこ付きの形で1つ生成する。この文字列をXMLに貼り付ける
"{$((New-Guid).Guid.ToUpper())}"

生成した値は、Profiles側とConfigs側の両方に同じ形で、波かっこ込みで書きます。4章のAssigned AccessのProfile IdとDefaultProfile Idも同じ考え方です。

選べる終了時アクションは、次の4つです。⁷

アクション	動作
`RestartShell`	シェルに指定したアプリを再起動する
`RestartDevice`	端末を再起動する
`ShutdownDevice`	端末をシャットダウンする
`DoNothing`	何もしない

終了コードがReturnCodeActionsにないうえにDefaultActionも未定義だと、何も起こらず黒画面のまま止まります。DefaultActionは必ず定義してください。例では通常の終了と未定義の終了コードをシェル再起動、終了コード10を端末再起動にしています。⁷

DoNothingはExplorerを自動起動する指定ではありません。保守のために使う場合も、未割り当ての管理者でサインインして通常のExplorerを使うなど、7.4節の保守経路と組み合わせます。⁷

6.3 Assigned Accessと同じCSPの、別の構成先へ適用する

MDMでは./Vendor/MSFT/AssignedAccess/ShellLauncherへXMLを設定します。ローカルではWMIブリッジのMDM_AssignedAccessクラスのShellLauncherプロパティを使います。4章と共通なのはSYSTEMでの実行とXMLのHTMLエンコードであり、書き込むプロパティはConfigurationではありません。⁵

構成経路や環境によっては、「Windowsの機能の有効化」のデバイスのロックダウン配下で、Shell Launcher（Client-EmbeddedShellLauncher）を事前に有効化しておく必要があります。適用方法の詳細は、Shell Launcherのクイックスタートを参照してください。⁵

7. 無人運用：起動・復帰・更新・保守をつなぐ

7.1 自動ログオンは専用の標準ユーザーで行う

自動ログオンの第一候補は、構成XMLのAutoLogonAccountです。Windowsが専用のローカル標準ユーザーを作成・管理するため、自分でパスワードを保管する必要がありません。²⁷

WinlogonのAutoAdminLogon／DefaultUserName／DefaultPasswordを使う従来の方法では、パスワードがレジストリに平文で残ります。また、EAS（Exchange ActiveSync）のパスワード制限ポリシーがある端末では自動ログオンが動作しないため、MDMのポリシーと衝突していないかも確認します。⁶

7.2 アプリの終了後はOSの復帰機構につなぐ

Assigned Accessのシングルアプリキオスクは、アプリが閉じられると自動再起動します。Shell LauncherはDefaultActionとReturnCodeActionsで復帰動作を決めます。一次復帰は、まずOS側の機構に任せます。¹⁷

そのうえで、再起動しても同じ例外で落ち続ける状況への備えとして、夜間の定期再起動を組み込みます。タスクの設計は「タスクスケジューラの安全な運用設計」を参照してください。

ただし、操作不能のままプロセスが残る場合は、「終了」を契機にした復帰へつながりません。ログを残して終了するアプリ側の設計と、多重起動対策は8章で扱います。

7.3 Windows Updateは止めず、時間と再起動後の復帰を設計する

Windows Updateは、停止するのではなく時間を制御します。公式の推奨は、営業時間に合わせたアクティブ時間、自動ダウンロードと夜間のスケジュールインストール、再起動警告を含む通知の抑止です。更新後の再起動から、自動ログオン、キオスク復帰までつながることを実機で確認します。⁶

電源設定も運用の一部です。専用端末ではスリープとディスプレイオフのタイムアウトを0（無効）とし、電源ボタンを無効化する構成が推奨されています。⁶ ノートPC流用端末やModern Standby機は、「スリープ・休止・Modern Standbyと長時間稼働アプリ」もあわせて確認してください。

7.4 キーを塞ぐ前に、保守員が戻る経路を決める

マルチアプリの制限付きユーザー体験では、Alt+F4・Alt+Tab・Ctrl+Alt+Delは既定でブロックされません。物理キーボードとスクリーンキーボードの両方でキーの組み合わせを抑止するのが、Enterprise系限定のKeyboard Filterです。機能の有効化にはDism /online /Enable-Feature /FeatureName:Client-KeyboardFilterを使います。⁶⁸

タブレット型端末では、画面端からのスワイプでシステムUIを出さないよう、LockDown/AllowEdgeSwipeポリシーを0（無効）に設定します。

制限と対にして残すのが、保守経路です。Assigned Accessのシングルアプリキオスクは、既定でCtrl+Alt+Delから抜け、管理者アカウントでサインインします。Windows 11ではBreakoutSequenceでキーを変更できます。²

Keyboard FilterでCtrl+Alt+Delまで塞ぐ場合は、Keyboard Filter側のブレイクアウトキーを残します。既定は左Windowsキーの5回連打で、ようこそ画面へ戻れます。Assigned AccessのBreakoutSequenceと、Keyboard Filterのブレイクアウトキーは、別の設定です。Keyboard Filterは管理者アカウントを適用除外にでき、セーフモードでは無効です。⁸

キオスク体験はコンソール専用ですが、管理者のRDP保守は別セッションとして併用できます。脱出キーとリモート保守経路を文書化し、「誰も入れない端末」にしないことが重要です。構成のトラブルは5章のAssignedAccess > Operationalから調べます。¹⁶

8. 業務アプリ側で満たす5つの条件

OSを固めても、業務アプリが普通のデスクトップアプリのままでは、抜け道や復帰できない状態が残ります。

全画面・枠なしを維持する。Shell LauncherにはV2:AllAppsFullScreenがありますが、基本はアプリ自身でも最大化・最前面・タイトルバーなしを維持し、フォーカスを失った場合は自分を前面へ戻す設計にします。⁷

一般利用者向けの終了ボタンを置かない。代わりに、四隅の順番タップとパスワードなど、保守員だけが使う操作で保守メニューを開きます。保守終了時はDoNothingと管理者への切り替えを組み合わせ、更新後の終了時はRestartDeviceへつなぐなど、アプリとShell Launcherの終了コードを合わせて設計します。DoNothingだけでExplorerへ戻るわけではありません。⁷

未処理例外は、ログを残して復帰につなぐ。例外を握りつぶして、操作不能の画面だけを残すのが最悪です。ログを書いて速やかに自プロセスを終了し、Assigned Accessの自動再起動やShell LauncherのRestartShellに拾わせます。

多重起動を防ぐ。OSの自動再起動と自前の再起動が重なる場合に備え、Mutexによる多重起動防止を入れます。実装は「Windowsアプリの多重起動防止」を参照してください。

管理者昇格を要求しない。キオスクは標準ユーザーで動かすのが原則です。Shell Launcherで昇格が必要なシェルを使い、UACの無効化が必要になる設計を避けます。³ 管理者権限が必要な処理は、「Windowsアプリで「管理者権限が必要な処理だけ」を分離する具体的な書き方」のように分離してください。

9. 設計の判断表と受け入れ確認

ここまでの選定・設定・運用を、最後に確認します。

論点	選択肢	判断の目安
方式選定	自動ログオンのみ / Assigned Access / マルチアプリ / Shell Launcher	不特定者が触る1アプリ端末はシングルアプリキオスク。数アプリの共有端末はマルチアプリ。Explorer自体を消したい装置端末はShell Launcher(Enterprise系限定)。自動ログオン単体は不可¹³
Win32アプリのキオスク化	Shell Launcher / Windows 11のClassicAppPath / UWP化	Windows 11ならPro+Assigned Accessで足りる。Windows 10 ProはUWP化かマルチアプリ+AutoLaunch、それが無理ならエディション変更²
自動ログオン	レジストリ直書き / XMLのAutoLogonAccount	XML方式はアカウント作成・管理をWindowsに任せられ、平文パスワードが残らない²⁷
落ちたときの復帰	自前の監視プロセス / OSの再起動機構+定期再起動	キオスクは自動再起動が組み込み。Shell LauncherはDefaultAction必須。連続クラッシュ対策に夜間再起動を併用¹⁷
ショートカット抑止	何もしない / Keyboard Filter	マルチアプリではAlt+F4等が素通し。Enterprise系ならKeyboard Filterで塞ぎ、ブレイクアウトキーを保守経路として残す⁶⁸
保守経路	塞ぎ切る / 脱出キー+管理者RDPを設計	BreakoutSequenceとブレイクアウトキーを文書化し、リモート保守経路も確保。「誰も入れない端末」は事故²⁸

受け入れでは、設定値が保存されたことに加え、コンソールでのアプリ起動、アプリ終了後の復帰、更新・再起動後の自動復帰、保守員のサインインを、実際のキオスクアカウントと端末で確認します。構成の読み戻しだけで、これらまで確認したことにはしません。

10. まとめ

キオスク化は、業務アプリを自動起動することではありません。利用者が触れる範囲を制限し、アプリが落ちても戻り、必要なときには保守できることまでが設計の対象です。

1つのアプリだけを使わせるならAssigned Access、数個の許可アプリを使わせるならマルチアプリ構成、Explorer自体を置き換える装置用途ならShell Launcherを選びます。Proで使える範囲と、Windows 10／11のアプリ指定の違いを、設定前に確認してください。¹²³

XMLの適用はAssignedAccess CSPにまとめられており、MDMがなくてもSYSTEMのWMIブリッジから設定できます。設定する、読み戻す、コンソールで確かめる、解除できるようにしておくを一連の手順にします。⁴⁵

運用は、AutoLogonAccount、OSの復帰機構と定期再起動、Windows Updateの時間制御、脱出キーとRDP保守を組み合わせます。最後に、全画面維持・終了操作の制限・例外からの復帰・多重起動防止・昇格不要をアプリ側でも満たして、専用端末を完成させます。

参考リンク

Microsoft Learn, Assigned Access overview. Assigned AccessがPro / Enterprise(LTSC含む) / Education / IoT Enterprise(LTSC含む)でサポートされること、キオスク体験ではUWPアプリまたはMicrosoft Edgeがロック画面の上で全画面実行され、閉じられると自動再起動すること、キオスク体験にはUAC有効とコンソールサインインが必要でリモートデスクトップ接続がサポートされないこと、制限付きユーザー体験(マルチアプリ)の位置づけについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Create an Assigned Access configuration file. KioskModeAppのAppUserModelIdとv4:ClassicAppPath / v4:ClassicAppArguments(Windows 11 21H2スキーマ)、脱出キーが既定でCtrl+Alt+DelでBreakoutSequence要素で変更できること、AllAppsList構成でAppLockerルールが生成されること、rs5:AutoLaunch、AutoLogonAccountがローカル標準ユーザーを作成・管理すること、KioskModeAppとShellLauncherを同一デバイスに同時設定できないこと、キオスクプロファイルをグループに割り当てられないことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶
Microsoft Learn, Shell Launcher overview. Shell LauncherがExplorer.exeをWin32/UWPアプリに置き換える機能であること、対応エディションがEnterprise / Enterprise LTSC / Education / IoT Enterprise / IoT Enterprise LTSCであること、v2がCustomShellHost.exeでWin32/UWP両対応であること、他アプリへのアクセス自体は防がずAppLocker等の併用が必要なこと、別プロセスを起動して終了するアプリをシェルにできないこと、シェルがサインインユーザーの権限で動き昇格が必要な場合はUAC無効化が必要なことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Quickstart: Configure a single-app kiosk with Assigned Access. 設定アプリ(アカウント > 他のユーザー > キオスクのセットアップ > 開始する > アカウントの作成 > アプリの選択 > 閉じる)での構成手順、AssignedAccess CSP(./Vendor/MSFT/AssignedAccess/Configuration)への適用、WMIブリッジ(名前空間root\cimv2\mdm\dmmap、MDM_AssignedAccessクラスのConfigurationプロパティ)をSYSTEM権限のPowerShellから使う手順、デバイス設定のWMIブリッジがSYSTEM(LocalSystem)アカウントでの実行を要すること、テストにpsexec.exe -i -s powershell.exeを使えること、XMLをHtmlEncodeしてSet-CimInstanceで設定すること、設定後に端末を再起動すると自動サインインしてキオスクアプリが起動すること、Configurationに$nullを設定して再起動する解除方法について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰
Microsoft Learn, Quickstart: Configure a single-app kiosk with Shell Launcher. Shell LauncherのXMLをAssignedAccess CSPのノード(./Vendor/MSFT/AssignedAccess/ShellLauncher)またはWMIブリッジ(MDM_AssignedAccessクラスのShellLauncherプロパティ)で適用する手順と解除方法について。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Assigned Access recommendations. キオスクアカウントを最小権限のローカル標準ユーザーにする推奨、Winlogonレジストリによる自動ログオン設定とEASパスワード制限時に自動ログオンが動作しないこと、Windows Update(アクティブ時間・スケジュールインストール・通知オフ)と電源設定の推奨構成、制限付きユーザー体験でAlt+F4・Alt+Tab・Ctrl+Alt+Delがブロックされないこと、UWPアプリ更新でAUMIDが変わりうること、トラブルシューティング用のログが「アプリケーションとサービスログ > Microsoft > Windows > AssignedAccess > Operational」で有効化できること、構成の記録先レジストリキー(HKLM\Software\Microsoft\Windows\AssignedAccessConfiguration、HKLM\Software\Microsoft\Windows\AssignedAccessCsp、HKCU\SOFTWARE\Microsoft\Windows\AssignedAccessConfiguration)について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³
Microsoft Learn, Create a Shell Launcher configuration file. ShellLauncherConfiguration XMLの構造(Profiles/Shell/Configs)、Profile IdのGUIDがXML内で一意であればよくPowerShellのNew-Guidで生成できること、V2:AppTypeとV2:AllAppsFullScreen、終了時アクションがRestartShell / RestartDevice / ShutdownDevice / DoNothingの4種であること、終了コードがマッピングになくDefaultActionも未定義なら何も起きないためDefaultActionを定義すべきこと、AutoLogonAccountがローカル標準ユーザー「Kiosk」を作成・管理することについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³
Microsoft Learn, Keyboard Filter. Keyboard FilterがCtrl+Alt+Delを含むキー組み合わせを物理・オンスクリーン両キーボードで抑止できること、対応エディションがEnterprise / Education / IoT Enterprise系であること、DISM(Client-KeyboardFilter)による有効化、ブレイクアウトキー(既定は左Windowsキー5回連打)でようこそ画面に戻れること、管理者アカウントへの適用除外、セーフモードでは機能しないこと、リモートデスクトップセッションでは非サポートであることについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Set-AssignedAccess. Set-AssignedAccessコマンドレットが指定ユーザーを単一のストアアプリ(UWP)専用に構成すること、対象がローカル標準ユーザーに限られ管理者・ドメインアカウントを指定できないこと、Clear-AssignedAccessによる解除について。 ↩ ↩² ↩³
Microsoft Learn, Get-StartApps. Get-StartAppsが現在のユーザーのインストール済みアプリの名前とAppID(AppUserModelID)を取得すること、-Nameでワイルドカードを含む名前指定による絞り込みができること、出力がNameとAppIDを持つオブジェクトであることについて。 ↩ ↩²

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Assigned AccessはWindows Proでも使えますか？: 使えます。Assigned Access(シングルアプリキオスクとマルチアプリの制限付きユーザー体験)はPro / Enterprise / Education / IoT Enterprise(それぞれのLTSC含む)でサポートされます。一方、Explorer.exe自体を業務アプリに置き換えるShell LauncherはEnterprise / Education / IoT Enterprise系のみで、Proでは使えません。また、キオスク体験にはUACが有効であることと、コンソールからのサインインが必要で、リモートデスクトップ接続越しのキオスク体験はサポートされません。
Win32(デスクトップ)アプリをキオスクにするにはShell Launcherが必須ですか？: Windows 11では必須ではなくなりました。Windows 11(21H2以降のスキーマ)のAssigned Accessは、KioskModeApp要素のv4:ClassicAppPath属性でデスクトップアプリの実行ファイルパスを指定でき、Pro端末でもWin32アプリのシングルアプリキオスクを構成できます。Windows 10のAssigned AccessキオスクはUWPアプリとMicrosoft Edgeに限られるため、Win32アプリを1本だけ動かすならShell Launcher(Enterprise系限定)か、マルチアプリ構成でAutoLaunchを使う方法が現実解になります。エディションと方式の対応を先に確認してから設計してください。
キオスクアプリが異常終了したら自動で復帰しますか？: 方式により挙動が異なります。Assigned Accessのシングルアプリキオスクは、アプリが閉じられると自動的に再起動される仕様です。Shell Launcherでは、シェルにしたアプリの終了時の動作をDefaultActionとReturnCodeActionsで宣言的に構成でき、RestartShell(シェル再起動)・RestartDevice(端末再起動)・ShutdownDevice・DoNothingから選べます。終了コードに対応するアクションが未定義でDefaultActionもない場合は何も起きず黒画面のまま止まるため、DefaultActionは必ず定義してください。アプリ側にも未処理例外時に自らを終わらせて復帰動作へつなぐ設計が必要です。
保守員はどうやって管理者としてログインすればよいですか？: Assigned Accessのキオスク体験は、既定ではCtrl+Alt+Delでサインイン画面へ抜けられ、Windows 11ではBreakoutSequence要素でこのキー組み合わせを変更できます。Keyboard FilterでCtrl+Alt+Delごと塞ぐ構成では、Keyboard Filter側のブレイクアウトキー(既定は左Windowsキーを5回連打)でようこそ画面に戻る経路を残せます。キオスク体験自体はコンソール専用ですが、管理者アカウントでのリモートデスクトップ保守は別セッションとして併用できます。脱出経路を全部塞いでしまい現地作業でしか復旧できない端末にしないことが重要です。
自動ログオンのパスワードをレジストリに書くのは安全ですか？: 推奨しません。WinlogonのAutoAdminLogon方式はDefaultPasswordがレジストリに平文で残ります。Assigned AccessとShell Launcherの構成XMLにはAutoLogonAccount要素があり、これを使うとWindowsが専用のローカル標準ユーザーを自身で作成・管理して自動サインインするため、パスワードを自分で保管する必要がありません。キオスク用アカウントは最小権限のローカル標準ユーザーとし、ドメインアカウントの流用は避けるのが原則です。なお、Exchange ActiveSyncのパスワード制限ポリシーが効いている端末では自動ログオンが動作しない点にも注意してください。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ブログ一覧に戻る