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

「受付端末のはずのPCで、来客がタスクバーからExcelを開いていた」「装置の操作画面の裏でYouTubeが再生されていて、タッチパネルの反応が悪いという苦情の原因がそれだった」「展示会のデモ機が、朝行ったらデスクトップ丸見えでスクリーンセーバーの設定画面になっていた」── 特定アプリ専用のはずのWindows端末は、放っておくと必ず「ただのPC」として使われます。

ありがちな対策が「自動ログオンにして、スタートアップに業務アプリを登録する」ですが、これは何も守っていません。Explorerシェルは丸ごと生きているので、Alt+TabでもWinキーでも一瞬でデスクトップに出られます。かといって、WindowsにはキオスクのためにAssigned Access・Shell Launcher・マルチアプリキオスクと複数の仕組みがあり、どれが使えるかがエディションとWindowsバージョンで変わるため、「Proの端末で組もうとしたらShell Launcherが無かった」という手戻りもよく起きます。

この記事では、受付端末・工場の操作端末・検査装置の操作画面・展示端末など「1つのアプリしか動かさないPC」を構成したい開発者・情シス担当者を対象に、方式の全体像とエディション要件、PowerShell/XMLでの設定例、そして自動ログオン・異常終了からの復帰・Windows Update・保守経路といった運用設計までを、公式ドキュメントの裏付けつきで整理します。

1. まず結論

• 「自動ログオン+スタートアップ起動」はキオスクではありません。Explorerシェルが生きている限り、ユーザーは何でもできます。守りたいなら専用の仕組みを使います。
• Assigned Accessのシングルアプリキオスクは、UWPアプリまたはMicrosoft Edgeをロック画面の上で全画面実行し、アプリが閉じられると自動で再起動します。Pro以上のエディションで使えます。¹
• Windows 11では、Assigned AccessでWin32(デスクトップ)アプリもキオスクにできます。Windows 11(21H2)以降のスキーマで追加された v4:ClassicAppPath にEXEのパスを指定します。Windows 10のキオスクはUWP/Edge限定です。²
• Shell LauncherはExplorer.exe自体を業務アプリ(Win32/UWP)に置き換える仕組みで、Enterprise / Education / IoT Enterprise系エディション限定です。Proでは使えません。シェルの終了時動作(再起動・端末再起動など)を宣言的に構成できます。³⁴
• マルチアプリキオスク(制限付きユーザー体験)は、許可アプリの一覧と専用スタートメニューで「数個のアプリだけ使える共有端末」を作る方式です。AppLockerルールが自動生成され、許可外のアプリは起動できません。²
• 構成方法は統合が進んでいます。シングルアプリ・マルチアプリ・Shell Launcherのいずれも、現在はAssignedAccess CSP(Intune等のMDM)、または同じCSPをローカルで叩くWMIブリッジ+PowerShellで構成するのが標準の手順です。⁵⁶
• キオスク体験の脱出は既定でCtrl+Alt+Delです。Windows 11では BreakoutSequence で変更できます。保守員がサインインする経路を必ず設計に残してください。²
• 端末を固めても、業務アプリ側の設計(全画面UI・終了ボタンを出さない・例外時の自己回復)ができていなければ穴になります。OSの仕組みとアプリの設計はセットです。

この記事の知識マップ

受付端末や装置の操作画面のように1つのアプリしか動かさないPCを作るには、Explorerシェルがそのまま生きる自動ログオン+スタートアップ起動では何も守れず、Assigned AccessかShell Launcherという専用の仕組みが必要になる。Assigned Accessのシングルアプリキオスクはロック画面の上で対象アプリだけを全画面実行し閉じられると自動再起動する仕組みでPro以上のエディションから使え、Windows 11ではWin32アプリもv4:ClassicAppPathで指定できる。数個のアプリを使わせる共有端末にはマルチアプリキオスクが向き、Explorerの存在自体を消したい装置端末にはShell Launcherが最有力だが、Enterprise/Education/IoT Enterprise系エディション限定である。どちらもAutoLogonAccountとWMIブリッジという共通の運用手段を持つ。

flowchart LR
    accTitle: Windowsキオスク構成(Assigned Access/Shell Launcher)の知識マップ
    accDescr: 自動ログオンだけの構成では何も守れないのに対し、Assigned Accessのシングルアプリキオスクはロック画面上での全画面実行と自動再起動で装置PCを固め、Shell LauncherはExplorer自体を業務アプリへ置き換え、両者がエディション要件やAutoLogonAccount・WMIブリッジといった共通の構成手段でどうつながるかを示す図
    assigned_access["Assigned Access"]
    shell_launcher["Shell Launcher"]
    unattended_pc["無人運転の装置PC"]
    autologon_startup_only["自動ログオン+スタートアップ起動"]
    multi_app_kiosk["マルチアプリキオスク(制限付きユーザー体験)"]
    pro_edition["Windows Pro/Enterprise系エディション"]
    enterprise_edu_iot_edition["Enterprise/Education/IoT Enterprise系エディション"]
    keyboard_filter["Keyboard Filter"]
    classic_app_path["v4:ClassicAppPath"]
    applocker["AppLocker"]
    autologon_account["AutoLogonAccount要素"]
    winlogon_autologon["Winlogonレジストリ自動ログオン"]
    wmi_bridge["MDMブリッジWMIプロバイダー"]
    kiosk_escape_shortcut["キー操作によるキオスクからの脱出"]
    breakout_sequence["BreakoutSequence(脱出キーの変更)"]
    console_signin_requirement["コンソールサインイン要件"]
    admin_rights["管理者権限"]
    autologon_startup_only -->|"用いるのは非推奨"| unattended_pc
    assigned_access -.->|"推奨される対応"| unattended_pc
    shell_launcher -->|"推奨される対応"| unattended_pc
    multi_app_kiosk -->|"推奨される対応"| unattended_pc
    assigned_access -->|"前提とする"| pro_edition
    shell_launcher -->|"前提とする"| enterprise_edu_iot_edition
    keyboard_filter -->|"前提とする"| enterprise_edu_iot_edition
    assigned_access -.->|"両立しない"| shell_launcher
    assigned_access -.->|"利用する"| classic_app_path
    multi_app_kiosk -->|"自動化する"| applocker
    shell_launcher -.->|"前提とする"| applocker
    assigned_access -->|"で構成できる"| autologon_account
    shell_launcher -->|"で構成できる"| autologon_account
    winlogon_autologon -->|"用いるのは非推奨"| unattended_pc
    autologon_account -->|"の後継"| winlogon_autologon
    assigned_access -->|"で構成できる"| wmi_bridge
    shell_launcher -->|"で構成できる"| wmi_bridge
    multi_app_kiosk -->|"原因になり得る"| kiosk_escape_shortcut
    keyboard_filter -->|"軽減する"| kiosk_escape_shortcut
    assigned_access -.->|"で構成できる"| breakout_sequence
    assigned_access -->|"前提とする"| console_signin_requirement
    breakout_sequence -.->|"前提とする"| admin_rights

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

2. 選択肢の全体像 ── 4つの方式は「何を守れるか」が違う

まず方式を横に並べます。重要なのは見た目ではなく、Explorerシェルがどうなっているかと、許可外の操作を誰が止めるかです。

使い分けの感覚はこうです。

• 来客や不特定の人が触る端末(受付・展示・公共ブラウジング)は、シングルアプリキオスク。触れる面が最小になります。
• 決まった数個のアプリを使う共有端末(現場のライン端末、教育用)は、マルチアプリキオスク。
• Win32の業務アプリ1本を装置の操作画面として動かす産業用途は、Shell Launcher。Explorer由来のUI(通知、タスクバー、エッジスワイプで出るUI)がそもそも存在しないのが強みで、終了コードに応じた復帰動作を構成できるのも装置向きです。⁴
• 自動ログオン+スタートアップは、上記いずれかの部品(サインインの自動化)としては使いますが、それ単体はキオスクではありません。

なお、同じ端末にKioskModeApp(シングルアプリキオスク)とShell Launcherを同時に設定することはできません。² どちらか一方を選びます。

3. エディション要件 ── Proでできること、Enterpriseが要ること

方式選定の前に、手元の端末のエディションを確認してください。ここを後回しにすると設計ごとやり直しになります。

• Assigned Access(シングルアプリ/マルチアプリ): Pro / Enterprise / Education / 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 11ならAssigned Accessの v4:ClassicAppPath でそのまま実現できます。²
• Windows 10 Proなら選択肢がなく、UWP化するか、マルチアプリキオスク+自動起動(rs5:AutoLaunch)で近づけるか、エディションを上げるかになります。²

装置組み込みや産業用PCで新規に端末を選定できるなら、Shell Launcher・Keyboard Filterまで揃い、機能更新の押し付けもないIoT Enterprise LTSCが本命です。エディション選定の考え方は同日公開の「産業用PCのWindows選び ── IoT Enterprise LTSC実践ガイド」で詳しく扱っています。

もう1つの前提として、キオスク体験はUACが有効であることと、コンソールからのサインインが必要です。リモートデスクトップ接続でキオスク体験は動きません。¹ 「RDPで入って動作確認しよう」として動かず悩む、が定番の初見トラップです。コンソールセッションとRDPセッションの関係は「Windowsのセッション分離をどう理解するか」を参照してください。

4. Assigned Accessでシングルアプリキオスクを作る

設定経路は3つあります。簡単な順に4.1〜4.3で見て、そのうち本命の構成XMLについては、実際に端末へ適用する手順(4.4)と適用できたかの確認方法(4.5)まで続けます。

4.1 設定アプリで作る(1台だけ・Edge/UWPなら最短)

キオスク用のローカルアカウント作成と対象アプリの選択を、ウィザードで行えます。手順は次のとおりです。⁵

1. 設定 > アカウント > 他のユーザー を開く
2. 「キオスクモードのセットアップ」(Set up a kiosk)の 「開始する」(Get Started)を押す
3. 「アカウントの作成」ダイアログでアカウント名を入力し、「次へ」を押す(既にローカル標準ユーザーがある場合は「既存のアカウントを選ぶ」も選べます)
4. キオスクアカウントのサインイン時に実行するアプリを選ぶ。Microsoft Edgeを選んだ場合は、続けて次を設定します
   • 全画面表示(デジタルサイネージ)にするか、一部のブラウザー操作を残す(パブリックブラウザー)か
   • サインイン時に開くURL
   • パブリックブラウザーを選んだ場合、無操作が続いたときにEdgeを再起動するまでの時間
5. 「閉じる」を押す

設定後に端末を再起動すると、作成されたローカルアカウントが自動的にサインインし、指定アプリが起動します。⁵ 1台だけ・Edgeか単純なUWPアプリなら、これで十分です。

4.2 PowerShellコマンドレットで作る(UWP限定)

Set-AssignedAccess は「このローカル標準ユーザーはこのUWPアプリだけ」という最小構成を1行で作れます(UWP限定・ローカル標準ユーザー限定・管理者アカウント不可)。⁹

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

# 解除
Clear-AssignedAccess

引数に渡すAUMID(AppUserModelID)は Get-StartApps で調べます。インストール済みアプリの名前とAppIDを一覧するコマンドレットで、Name と AppID の2列が返ります。¹⁰

# 一覧から目視で探す
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.3 構成XML+AssignedAccess CSP(本命)

Win32アプリの指定、自動ログオン、脱出キーの変更まで含めた本命の方法です。Intune等のMDMからは ./Vendor/MSFT/AssignedAccess/Configuration に、スタンドアロン端末ではWMIブリッジ経由でSYSTEM権限のPowerShellから同じXMLを流し込みます。⁵ XMLの要点はこうです。

<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)を指定します。注意点として、UWPアプリの更新でAUMIDが変わることがあり、その場合は構成の更新が必要です。⁷ また、キオスクプロファイルはユーザーにのみ割り当てられ、グループには割り当てられません。²

4.4 WMIブリッジで実際に適用する

MDMがない端末では、MDMブリッジWMIプロバイダー経由で同じCSPを叩きます。ここが手順として最も詰まるところなので、順に書きます。⁵

手順1: SYSTEMとしてPowerShellを起動する。デバイス設定のWMIブリッジは、SYSTEM(LocalSystem)アカウントで実行されている必要があります。管理者権限の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: XMLをHTMLエンコードして流し込む。そのSYSTEM権限のPowerShellセッションで実行します。

$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 で作られたローカルアカウントが自動サインインし、指定アプリが起動します。⁵

解除する場合は、同じくSYSTEM権限のPowerShellから Configuration に $null を設定して、再起動します。⁵

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

4.5 適用できたかをどう確かめるか

「エラーは出ないのに効いていない」を切り分けるために、確認の手立てを3つ用意しておきます。

(a) イベントログを有効にして見る。公式に案内されている確認先はこのチャネルです。⁷ 構成XMLの検証エラーや実行時の失敗はここに出ます。

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

既定では無効の場合があるので、チャネルを選んで右ペインの「ログの有効化」を押してから再現させてください。

(b) 書き込まれた構成をレジストリで確認する。Assigned Accessの構成は次のキーに記録されます。⁷

(c) CSPから読み戻す。流し込んだ直後に、同じSYSTEM権限のPowerShellで読み返せば、値が入ったかどうかはその場で分かります。

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

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

これで空なら適用そのものが失敗、入っているのに動かないならXMLの内容(アプリのパス、プロファイルとConfigのGUID不一致、エディション要件)を疑う、と切り分けられます。手順3でエラーが出た場合は、まず手順2のSYSTEM確認に戻ってください。

5. Shell LauncherでWin32アプリをシェルにする

Enterprise系エディションが使えるなら、装置の操作画面のような「Explorerの存在自体が邪魔」な端末にはShell Launcherが最有力です。Shell Launcher v2(Windows 10 1809以降)はExplorer.exeの代わりにCustomShellHost.exeが業務アプリを起動・監視し、Win32でもUWPでもシェルにできます。³

構成は専用XMLで、アプリが終了したときの復帰動作を終了コード別に宣言できるのが最大の特徴です。⁴

<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>

Profile Id のGUIDは、どこかに申請して発行してもらうものではありません。XML内で一意になるように自分で採番する値で、PowerShellの New-Guid で生成できます。⁴

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

生成した値を Profiles 側と Configs 側の両方に同じ形(波かっこ込み)で書いてください。上のサンプルをそのままコピーしても動かないのは、この置き換えが必要なためです。4章のAssigned Access構成XMLに出てくる Profile Id / DefaultProfile Id も同じ性質の値です。

アクションは RestartShell / RestartDevice / ShutdownDevice / DoNothing の4種類です。終了コードがマッピングになく、DefaultActionも未定義だと「何も起きない」、つまり黒い画面のまま止まります。DefaultActionは必ず定義してください。⁴ 適用は、MDMなら ./Vendor/MSFT/AssignedAccess/ShellLauncher に、ローカルならAssigned Accessと同じWMIブリッジで MDM_AssignedAccess の ShellLauncher プロパティにXMLを設定します。⁶ 環境によっては事前に「Windowsの機能の有効化」でデバイスのロックダウン配下のShell Launcher機能(Client-EmbeddedShellLauncher)を有効化しておく必要があります。

Shell Launcher固有の落とし穴を3つ挙げます。³

• 別プロセスを起動して自分は終了するタイプのアプリはシェルにできません。Shell Launcherは指定したプロセスの終了を監視するため、ランチャー型のEXE(公式ドキュメントの例ではwrite.exe)を指定すると、即座に「終了した」と判定されます。
• シェルはサインインしたユーザーの権限で動きます。管理者アカウントにシェルを割り当てればその権限で何でもできてしまいますし、シェルアプリ自体が管理者昇格を要求する場合はUACを無効にしなければ起動できません。そうなる前にアプリを昇格不要に設計すべきです。
• Shell Launcherは他のアプリの起動を防ぎません。シェルを置き換えるだけなので、業務アプリ内のファイルダイアログ経由でEXEを起動する、といった経路は残ります。触る人を信頼できない端末では、AppLockerやKeyboard Filterを併用します。

6. 運用設計 ── 自動ログオン・復帰・Update・保守経路

方式を選んで設定して終わり、ではありません。無人で回り続けるための設計がキオスクの本体です。

自動ログオンは、構成XMLの AutoLogonAccount を第一候補にします。Windowsが専用のローカル標準ユーザーを作成・管理するため、パスワードの保管が不要です。²⁴ 従来のWinlogonレジストリ方式(AutoAdminLogon/DefaultUserName/DefaultPassword)も使えますが、パスワードが平文で残ります。また、EASパスワード制限が適用された端末では自動ログオンが動作しない仕様なので、MDMのポリシーと衝突していないか確認してください。⁷

アプリが落ちたときの一次復帰はOS側に任せます。Assigned Accessキオスクはアプリが閉じると自動再起動します。¹ Shell LauncherはDefaultAction/ReturnCodeActionsで復帰動作を構成します。⁴ その上で、「再起動しても同じ例外で落ち続ける」ケースに備えて、夜間の定期再起動タスクを仕込んでおくと復帰性が上がります(タスクの組み方は「タスクスケジューラの安全な運用設計」参照)。

Windows Updateは止めるのではなく、時間を制御します。アクティブ時間を営業時間に合わせ、自動ダウンロード+夜間のスケジュールインストールにし、再起動警告を含む通知をオフにするのが公式の推奨構成です。⁷ 再起動後は「自動ログオン→キオスク復帰」まで自動でつながることを実機で確認しておきます。電源設定も同様に、スリープやディスプレイオフのタイムアウトを0(無効)にし、電源ボタンを無効化します。⁷ ノートPC流用端末やModern Standby機は特に挙動に癖があるので、「スリープ・休止・Modern Standbyと長時間稼働アプリ」もあわせて確認してください。

キーボードとタッチの穴は方式ごとに違います。マルチアプリキオスク(制限付きユーザー体験)では、Alt+F4・Alt+Tab・Ctrl+Alt+Delは既定でブロックされません。⁷ これらを塞ぐのがKeyboard Filterで、物理・スクリーンキーボード双方のキー組み合わせを抑止できます(Dism /online /Enable-Feature /FeatureName:Client-KeyboardFilter で有効化、Enterprise系限定)。⁸ タブレット型の端末では、画面端からのスワイプでシステムUIが出ないようにLockDown/AllowEdgeSwipeポリシーを無効(0)に設定します。

保守経路の確保は、塞ぐ話と同じくらい重要です。Assigned Accessキオスクの脱出は既定でCtrl+Alt+Del(Windows 11では BreakoutSequence で変更可)、そこから管理者アカウントでサインインします。² Keyboard FilterでCtrl+Alt+Delを塞ぐ場合は、Keyboard Filter側のブレイクアウトキー(既定は左Windowsキー5回連打)がようこそ画面への最後の経路になります。⁸ なお、Keyboard Filterはセーフモードでは無効で、管理者アカウントには適用除外にできます。⁸ キオスク体験はコンソール専用ですが、管理者のRDP保守は併用できるので、リモート経路も残しておくと現地出動が減ります。トラブル時は、イベントログの「AssignedAccess > Operational」チャネルが構成ミスの一次情報になります。⁷

7. 業務アプリ側の設計と実務の定石(判断表)

OS側をどれだけ固めても、アプリが「普通のデスクトップアプリ」のままでは穴が残ります。キオスクに載せるアプリの設計要件を挙げます。

• 全画面・枠なしを自分で維持する。Shell Launcherの V2:AllAppsFullScreen はありますが、基本はアプリ自身が最大化・最前面・タイトルバーなしを維持し、フォーカス喪失時に自分を前面へ戻す設計にします。
• 終了ボタンを出さない。閉じる手段を画面に置かない代わりに、保守員だけが知る隠し操作(例: 画面の四隅を順にタップ+パスワード)で保守メニューを出します。終了コードを分けておけば、Shell Launcherの ReturnCodeActions で「保守メニューからの終了→Explorer復帰用に何もしない」「更新後の終了→端末再起動」のような連携ができます。⁴
• 例外時に自己回復する。未処理例外を握りつぶして操作不能のまま画面が残るのが最悪です。ログを書いて速やかに自プロセスを終了し、OS側の再起動機構(キオスクの自動再起動・Shell LauncherのRestartShell)に拾わせます。
• 多重起動を防止する。自動再起動系の仕組みと自前の再起動処理が重なると二重起動が起きがちです。Mutexによる多重起動防止を入れておきます(「Windowsアプリの多重起動防止」)。
• 昇格を要求しない。キオスクアカウントは標準ユーザーが原則で、Shell Launcherでは昇格が必要なシェルはUAC無効化を強いられます。³ 管理者権限が要る処理は分離しておきます(「Windowsアプリで「管理者権限が必要な処理だけ」を分離する具体的な書き方」)。

最後に判断表です。

8. まとめ

• 「自動ログオン+スタートアップ起動」はキオスクではありません。Explorerが生きている限り何も守れないため、Assigned AccessかShell Launcherを使います。
• Assigned AccessはPro以上で使え、シングルアプリキオスク(UWP/Edge、Windows 11はWin32も)とマルチアプリの制限付きユーザー体験を構成できます。
• Shell LauncherはExplorer.exeを業務アプリに置き換えるEnterprise / Education / IoT Enterprise系限定の仕組みで、終了コード別の復帰動作(RestartShell等)を宣言できます。
• 構成はAssignedAccess CSPに統合されており、MDMがなくてもWMIブリッジ+PowerShell(SYSTEM権限)で同じXMLを適用できます。
• 運用設計の骨子は、AutoLogonAccountによる自動サインイン、OS再起動機構+定期再起動による復帰、Windows Updateの時間制御、そしてBreakoutSequence・ブレイクアウトキー・リモート保守という脱出経路の確保です。
• 最後の砦は業務アプリの設計です。全画面維持・終了ボタンなし・例外時の自己回復・多重起動防止・昇格不要を満たして初めて「1つのアプリしか動かさないPC」が完成します。

関連記事

• 産業用PCのWindows選び ── IoT Enterprise LTSC実践ガイド
• Windowsアプリの多重起動防止
• Windowsのセッション分離をどう理解するか
• スリープ・休止・Modern Standbyと長時間稼働アプリ
• タスクスケジューラの安全な運用設計
• Windowsアプリで「管理者権限が必要な処理だけ」を分離する具体的な書き方

関連する相談領域

合同会社小村ソフトでは、受付端末・工場の操作端末・検査装置の操作画面といったキオスク端末の方式選定と構成、キオスクに耐える業務アプリ(全画面UI・自己回復・権限分離)の設計・開発、既存端末の「固め直し」を扱っています。

• Windows業務アプリ開発
• 装置連携・ソフトリアルタイム制御アプリ開発
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

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

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

よくある質問

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

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