Windowsの割り当てアクセスが勝手に終了するときは、機能そのものが壊れているというより、「どの終了なのか」を取り違えているケースが多いです。実際には、アプリが閉じて自動再起動している、サインイン画面に戻されている、Microsoft Edge がアイドル時間でセッションをリセットしている、または割り当てアクセスに向かないアプリが別アプリやダイアログを開こうとして失敗している、のどれかで説明できることが大半です。(Microsoft Learn)
最短で直すなら、アプリ種別の適合性、Edgeのアイドル設定、自動サインインと更新、アプリのインストール状態/AUMID、ログの順に確認してください。特に「Edgeをパブリックブラウジングで使っていて数分後に戻る」「更新後からだけ不安定」「独自EXEやChromeを単一アプリの割り当てアクセスで使おうとしている」は、現場で非常に多い詰まり方です。(Microsoft Learn)
最初に見るべき4つのチェックポイント
- 5分前後でEdgeだけ閉じる、または最初のURLに戻るなら、まずアイドルタイムアウトを疑います。Edgeのキオスクモードは、パブリックブラウジングでは既定で5分、全画面サイネージでは既定で0分です。
--kiosk-idle-timeout-minutesや Intune の「Refresh browser after idle time」を確認してください。(Microsoft Learn) - 再起動・停電・更新後に戻ってこないなら、自動サインインと Authentication UI のログを見ます。キオスク端末では自動サインインが推奨され、更新による再起動を業務時間外に寄せる設定も重要です。(Microsoft Learn)
- 更新後から起動直後に落ちるなら、アプリが割り当てアクセス用アカウントにインストールされているか、UWPアプリの AUMID が変わっていないかを確認します。UWPアプリの更新で AUMID が変わることがあり、その場合は設定側の見直しが必要です。(Microsoft Learn)
- 独自EXE、Chrome、補助ツール連携が前提なら、単一アプリの割り当てアクセスではなく、Shell Launcher やマルチアプリキオスクの方が設計に合っている可能性が高いです。(Microsoft Learn)
まず押さえたい前提
単一アプリの割り当てアクセスは「UWPかMicrosoft Edge」が基本
Windowsの単一アプリキオスクで Assigned Access が前提としているのは、UWPアプリまたは Microsoft Edge です。デスクトップアプリを1本だけ全画面で固定したいなら、近い役割を持つのは Assigned Access ではなく Shell Launcher です。さらに Shell Launcher は Enterprise / Education / IoT Enterprise 向けで、Assigned Access と同じ端末に併用できません。つまり、独自EXEやChromeを“単一アプリの割り当てアクセス”で安定運用しようとすると、設定以前に方式が合っていないことがあります。(Microsoft Learn)
UACがオフ、RDPでの検証、管理者アカウント運用は遠回り
Assigned Access のキオスク利用には UAC が有効であることが必要で、RDP セッションではサポートされません。公開端末ではローカルの標準ユーザーが推奨です。ドメインや Microsoft Entra アカウントをそのままキオスクに使うと、不要な権限や自動サインインの相性問題を持ち込みやすくなります。切り分け段階では、ローカル標準ユーザーでコンソールサインインに揃えるのが最短です。(Microsoft Learn)
「終了した」の正体がサインアウトなら、ブレークアウトを疑う
Assigned Access は既定で Ctrl + Alt + Del でキオスクを抜けます。抜けたあとの再開待ち時間は既定30秒で、HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI の IdleTimeOut で変更できます。ただし、この値は Microsoft Edge のキオスクモードには適用されません。XML で Breakout Sequence を既定以外に変えている環境では、そのキーがアプリのショートカットと重なると、利用者には「勝手に終了した」ように見えることがあります。これは公式仕様から導ける実務上の注意点です。(Microsoft Learn)
症状別の原因と対処
Edgeが数分で閉じる、初期URLに戻る
これは故障よりも、Edgeキオスクモード側のアイドルリセットであることが多いです。特に「パブリックブラウジング」で構成すると既定のアイドル時間が5分なので、受付端末やサイネージ用途で放置される環境では、何もしていなくても“勝手に戻る”ように見えます。固定サイトを見せるだけなら、まず全画面の Digital/Interactive signage を検討してください。(Microsoft Learn)
確認と対処は次の順で十分です。
- Edge のキオスク種別が Public browsing になっていないか確認する。固定URLを出し続ける用途なら Digital/Interactive signage の方が合います。(Microsoft Learn)
--kiosk-idle-timeout-minutesを見直す。無効化したいなら0を使います。(Microsoft Learn)- Intune 管理なら Refresh browser after idle time の値も確認する。ここでリセット時間が入っていると、Windows側の割り当てアクセスが正常でも Edge だけ先に閉じます。(Microsoft Learn)
再起動、停電、更新後にキオスクへ戻らない
この症状は、アプリではなく自動サインインと更新設計を見るべきです。Microsoft もキオスクでは自動サインインを推奨しており、更新や停電後に自動で復帰できるようにしておく前提です。逆にここが崩れていると、割り当てアクセス自体は正しくてもサインイン画面で止まります。(Microsoft Learn)
実務では次を確認してください。
- キオスクアカウントで 自動サインイン できるか。ローカル標準ユーザーなら扱いやすく、ポリシーによっては自動サインインを妨げる設定もあります。(Microsoft Learn)
- Windows Update の再起動時間 を業務時間外に寄せているか。Active Hours、ScheduledInstallTime、通知抑制の設計が甘いと、端末側では「勝手に落ちた」に見えます。(Microsoft Learn)
- スリープや画面オフ が短すぎないか。専用端末では、必要に応じてスリープと画面オフを実質無効にする設定が推奨されています。(Microsoft Learn)
- まず見るログは
Applications and Services Logs > Microsoft > Windows > Authentication User Interface > Operationalです。自動サインインやサインイン周りの失敗が追えます。(Microsoft Learn)
起動直後に落ちる、更新後からだけ不安定
このパターンはアプリの配布状態か識別子のズレを疑います。割り当てアクセスで使うアプリは、対象のキオスクアカウントに対してインストールまたはプロビジョニングされていなければなりません。また、UWPアプリは更新で AUMID が変わることがあり、その場合は割り当てアクセスの設定も更新が必要です。(Microsoft Learn)
ハマりやすいのは次のケースです。
- 管理者アカウントでだけアプリを入れて、キオスクアカウントでは一度もサインインしていない。この場合、選べているように見えても実行側で失敗しやすくなります。(Microsoft Learn)
- そのアプリが lock screen 上で動けない種類 である。割り当てアクセスのキオスクアプリにはこの条件があります。(Microsoft Learn)
- アプリ更新後にだけ壊れた。こういうときは AUMID の再取得 と設定更新を先にやる方が早いです。(Microsoft Learn)
ダウンロード、印刷、ファイル選択、外部アプリ呼び出しで崩れる
割り当てアクセスは、別アプリを呼び出す前提の操作に弱いです。Microsoft も、他のアプリを起動することを前提にした Windows アプリはキオスクに向かないと案内しています。さらに Edge キオスクでは、共通の開く/保存ダイアログが自動ではロックダウンされません。ここで別画面に飛んだり、制限メッセージが出たりすると、利用者には「終了した」と見えます。(Microsoft Learn)
たとえば、次のような挙動は要注意です。
- Webアプリの ファイルアップロード でシステムのファイル選択が必要になる。(Microsoft Learn)
- PDFを既定ビューアで開く、別ブラウザを起動する、外部の印刷補助ツールを呼ぶ など、子プロセス起動が前提になっている。Assigned Access はこうした動きと相性が悪いです。(Microsoft Learn)
- Edge で保存系ショートカットが生きていて、共通ダイアログ に入ってしまう。必要なら
ConfigureKeyboardShortcutsで関連ショートカットを止めます。(Microsoft Learn)
キー操作やアクセシビリティ機能で抜ける
マルチアプリや制限付きユーザー エクスペリエンスでは、Alt + F4、Alt + Tab、Alt + Shift + Tab、Ctrl + Alt + Delete などが標準では塞がっていないことがあります。追加で抑止したいなら、公式機能は Keyboard Filter です。Keyboard Filter は Enterprise / Education / IoT Enterprise 系で利用でき、反映には再起動が必要です。(Microsoft Learn)
アクセシビリティ系の抜け道も見落としがちです。WIN + U などで設定画面へ入るパターンがあるので、必要なら Keyboard Filter で一緒に塞ぎます。Edge 側のショートカットだけを抑えたい場合は、Keyboard Filter ではなく ConfigureKeyboardShortcuts を使い分ける方が安全です。(Microsoft Learn)
ログはこの順で見ると早い
ログは闇雲に広げるより、順番を決めた方が早く終わります。Microsoft は、キオスク問題の一部は一度しか記録されないことがあるため、再現前にログを有効化しておくことを勧めています。(Microsoft Learn)
1. AssignedAccess の実行ログ
本命は Applications and Services Logs > Microsoft > Windows > AssignedAccess > Operational です。構成ミスと実行時エラーの両方を追いやすく、まずここを見れば「そもそも割り当てアクセス設定が正しく動いているか」が分かります。(Microsoft Learn)
2. Authentication User Interface のログ
再起動後に戻ってこない、自動サインインしない、サインイン画面で止まるときは、Applications and Services Logs > Microsoft > Windows > Authentication User Interface > Operational を先に見ます。(Microsoft Learn)
3. アプリ起動系のログ
アプリのアクティベーション失敗なら、Windows Logs > Application と Applications and Services Logs > Microsoft > Windows > Apps > Microsoft-Windows-TWinUI/Operational が有効です。起動したように見えてすぐ落ちるケースで役立ちます。(Microsoft Learn)
4. Intune / MDM で配布しているなら MDM ログも見る
Intune や MDM で割り当てアクセスを配布しているなら、Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin も確認対象です。ローカル設定は正しそうなのに、実は MDM 側でポリシー適用に失敗していることがあります。(Microsoft Learn)
5. 取得できるなら AssignedAccess の状態コードを確認する
CSP の Status が取れる環境では、Running、AppNotFound、ActivationFailed、AppNoResponse を見ると切り分けが一気に進みます。たとえば AppNotFound はアプリ未配布、ActivationFailed はサインイン失敗、AppNoResponse は起動後のハング寄りです。(Microsoft Learn)
必要なら構成の読み取り先として、HKLM\Software\Microsoft\Windows\AssignedAccessConfiguration と HKLM\Software\Microsoft\Windows\AssignedAccessCsp、ユーザー単位では HKCU\SOFTWARE\Microsoft\Windows\AssignedAccessConfiguration も確認できます。編集ではなく、何が入っているかの確認用途として使うのが無難です。(Microsoft Learn)
すぐ戻したいときの復旧手順
- 終了の仕方を分類する
「Edgeだけ数分で戻る」「再起動後に戻らない」「起動直後に落ちる」「特定操作で崩れる」のどれかに当てはめます。ここを曖昧にすると、原因が混ざって遠回りします。(Microsoft Learn) - アプリ種別が方式に合っているか確認する
単一アプリの Assigned Access で無理がないのは UWP か Edge です。独自EXEやデスクトップアプリなら、Shell Launcher かマルチアプリ構成へ寄せた方が早いです。(Microsoft Learn) - キオスクアカウントで一度サインインし、アプリ配布状態を確認する
アプリがそのアカウントに入っているか、更新後に AUMID が変わっていないかを見ます。(Microsoft Learn) - Edgeなら idle とダイアログを見直す
Public browsing のまま放置していないか、--kiosk-idle-timeout-minutesや Intune の idle 設定が意図どおりか、保存系ショートカットを残していないかを確認します。(Microsoft Learn) - 自動サインイン、更新、電源を整える
ローカル標準ユーザー、自動サインイン、業務時間外の更新、必要ならスリープ無効化まで含めて見直します。(Microsoft Learn) - ログを有効化してから再現させる
AssignedAccess、Authentication UI、必要なら TWinUI と MDM ログを取り、再現前後のイベントを比較します。(Microsoft Learn) - 設定が怪しいなら、いったん削除して作り直す
ローカル設定ならSettings > Accounts > Other Users > Kiosk > Remove kiosk、PowerShell ならClear-AssignedAccessで外せます。なお、割り当てアクセスの反映は次回サインイン時なので、設定変更後は必ずサインアウト/サインインで確認してください。(Microsoft Learn) - MDM配布で古い手順を使っていないか見直す
KioskModeAppノードは非推奨で、Configurationノードが入っていると実質的に効かない構成があります。古いJSON手順と新しいXML構成を混在させているなら、./Vendor/MSFT/AssignedAccess/Configurationに寄せた方が切り分けしやすいです。(Microsoft Learn)
設計を見直したほうが早いケース
次のように考えると、無駄な試行錯誤が減ります。
- 固定URLを全画面で見せたい
Microsoft Edge の単一アプリキオスクが第一候補です。(Microsoft Learn) - UWPアプリを1本だけ動かしたい
Assigned Access の単一アプリ構成が合います。(Microsoft Learn) - 独自EXEやデスクトップアプリを1本だけ固定したい
Shell Launcher の方が方式として自然です。(Microsoft Learn) - スキャナ、印刷補助、ファイル選択、外部ビューアなど複数の補助要素が必要
単一アプリの割り当てアクセスより、マルチアプリキオスクや別設計の方が安定しやすいです。これは、Assigned Access が別アプリ起動前提の操作と相性が悪いことから見ても妥当な判断です。(Microsoft Learn)
遠回りしないコツは、「Edgeのアイドル設定の話なのか」「自動サインインの話なのか」「そもそもアプリ選定が方式に合っていないのか」を最初に分けることです。5分前後で戻るなら Edge、再起動後に戻らないならサインイン/更新、更新後や起動直後に落ちるならアプリ配布や AUMID、独自EXEなら Shell Launcher を優先して見てください。そこまで確認しても直らないときは、ログを取ったうえでプロファイルを削除して作り直すのが最短です。(Microsoft Learn)
コメント