合同会社小村ソフト
相談する
メニュー

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

· 更新日: · · キオスクモード, Assigned Access, Shell Launcher, Windows 11, 業務端末, 装置連携, 情シス, 運用設計

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

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

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

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

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

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

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

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

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

  • Assigned Access(シングルアプリ/マルチアプリ): Pro / Enterprise / Education / IoT Enterprise(各LTSC含む)。1
  • Shell Launcher: Enterprise / Enterprise LTSC / Education / IoT Enterprise / IoT Enterprise LTSC。Pro不可。3
  • Keyboard Filter(キー抑止): Enterprise / Education / IoT Enterprise系のみ。Pro不可。8

つまり「Proの端末でWin32アプリを1本だけ動かしたい」という定番の要望は、

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

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

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

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

設定経路は3つあります。簡単な順に見ます。

(1) 設定アプリ。「設定 > アカウント > 他のユーザー」の「キオスクモードのセットアップ」から、キオスク用のローカルアカウント作成と対象アプリの選択をウィザードで行えます。Edgeを選ぶと全画面(デジタルサイネージ)か制限付きブラウザーか、起動URL、無操作時の再起動時間まで設定できます。1台だけ・Edgeか単純なUWPアプリなら、これで十分です。5

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

# ローカル標準ユーザー KioskUser を UWPアプリ専用にする(AUMIDはGet-StartAppsなどで確認)
Set-AssignedAccess -UserName 'KioskUser' -AppUserModelId 'Contoso.KenkiPanel_abc123!App'

# 解除
Clear-AssignedAccess

(3) 構成XML+AssignedAccess CSP。Win32アプリの指定、自動ログオン、脱出キーの変更まで含めた本命の方法です。Intune等のMDMからは ./Vendor/MSFT/AssignedAccess/Configuration に、スタンドアロン端末ではWMIブリッジ経由でSYSTEM権限のPowerShellから同じXMLを流し込みます。5 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が変わることがあり、その場合は構成の更新が必要です。7 また、キオスクプロファイルはユーザーにのみ割り当てられ、グループには割り当てられません。2

WMIブリッジで適用する場合は、psexecなどでSYSTEMとして起動したPowerShellから MDM_AssignedAccess クラスの Configuration プロパティにHTMLエンコードしたXMLを設定します($obj.Configuration = [System.Net.WebUtility]::HtmlEncode($xml) の形)。解除は同プロパティに $null を設定して再起動です。5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後に判断表です。

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

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」が完成します。

関連記事

関連する相談領域

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

参考リンク

  1. Microsoft Learn, Assigned Access overview. Assigned AccessがPro / Enterprise(LTSC含む) / Education / IoT Enterprise(LTSC含む)でサポートされること、キオスク体験ではUWPアプリまたはMicrosoft Edgeがロック画面の上で全画面実行され、閉じられると自動再起動すること、キオスク体験にはUAC有効とコンソールサインインが必要でリモートデスクトップ接続がサポートされないこと、制限付きユーザー体験(マルチアプリ)の位置づけについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  2. 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を同一デバイスに同時設定できないこと、キオスクプロファイルをグループに割り当てられないことについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  3. 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無効化が必要なことについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  4. Microsoft Learn, Create a Shell Launcher configuration file. ShellLauncherConfiguration XMLの構造(Profiles/Shell/Configs)、V2:AppTypeとV2:AllAppsFullScreen、終了時アクションがRestartShell / RestartDevice / ShutdownDevice / DoNothingの4種であること、終了コードがマッピングになくDefaultActionも未定義なら何も起きないためDefaultActionを定義すべきこと、AutoLogonAccountがローカル標準ユーザー「Kiosk」を作成・管理することについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  5. Microsoft Learn, Quickstart: Configure a single-app kiosk with Assigned Access. 設定アプリ(アカウント > 他のユーザー > キオスクのセットアップ)での構成手順、AssignedAccess CSP(./Vendor/MSFT/AssignedAccess/Configuration)への適用、WMIブリッジ(MDM_AssignedAccessクラスのConfigurationプロパティ)をSYSTEM権限のPowerShellから使う手順と解除方法について。 ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, Quickstart: Configure a single-app kiosk with Shell Launcher. Shell LauncherのXMLをAssignedAccess CSPのノード(./Vendor/MSFT/AssignedAccess/ShellLauncher)またはWMIブリッジ(MDM_AssignedAccessクラスのShellLauncherプロパティ)で適用する手順と解除方法について。 ↩ ↩2

  7. Microsoft Learn, Assigned Access recommendations. キオスクアカウントを最小権限のローカル標準ユーザーにする推奨、Winlogonレジストリによる自動ログオン設定とEASパスワード制限時に自動ログオンが動作しないこと、Windows Update(アクティブ時間・スケジュールインストール・通知オフ)と電源設定の推奨構成、制限付きユーザー体験でAlt+F4・Alt+Tab・Ctrl+Alt+Delがブロックされないこと、UWPアプリ更新でAUMIDが変わりうること、AssignedAccessイベントログについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  8. Microsoft Learn, Keyboard Filter. Keyboard FilterがCtrl+Alt+Delを含むキー組み合わせを物理・オンスクリーン両キーボードで抑止できること、対応エディションがEnterprise / Education / IoT Enterprise系であること、DISM(Client-KeyboardFilter)による有効化、ブレイクアウトキー(既定は左Windowsキー5回連打)でようこそ画面に戻れること、管理者アカウントへの適用除外、セーフモードでは機能しないこと、リモートデスクトップセッションでは非サポートであることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  9. Microsoft Learn, Set-AssignedAccess. Set-AssignedAccessコマンドレットが指定ユーザーを単一のストアアプリ(UWP)専用に構成すること、対象がローカル標準ユーザーに限られ管理者・ドメインアカウントを指定できないこと、Clear-AssignedAccessによる解除について。 ↩

関連する記事

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

関連トピック

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

よくある質問

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

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

お問い合わせ
ブログ一覧に戻る