Windows App の更新で、情シスが最初に注目すべきなのは、UI の見た目よりも URI/URL 連携 と auto logoff です。社内ポータルや案内メールから Azure Virtual Desktop に直接入れるようになり、共有PCでは使い終わった後の Windows App のサインイン状態やローカルデータを自動で片付けやすくなりました。結論から言うと、導線短縮には URI/URL 連携、共有端末の後始末には auto logoff が効きます。ただし、auto logoff が片付けるのはあくまで Windows App のローカル状態 であり、リモートセッションそのものを強制ログオフする機能ではありません。ここを取り違えないことが、運用設計で失敗しない一番のポイントです。 (TECHCOMMUNITY.MICROSOFT.COM)
Microsoft の 2026年3月公開の Windows App 更新ブログでも、Windows 上の ms-avd ベースのリンクからメールや社内サイト経由でリモートセッションに戻れること、そして shared devices 向けに Windows App on Windows の auto logoff が入ったことが明示されています。さらに商用クラウドでは旧 Remote Desktop client for Windows (MSI) と web-based Remote Desktop client が 2026年3月27日から未サポートになっており、今後は Windows App 前提で社内導線を組み直す重要度が上がっています。 (TECHCOMMUNITY.MICROSOFT.COM)
Windows App の URI 連携は「Windows ネイティブ」と「ブラウザ直リンク」で分けて考える
Windows App の「直接起動」は、実務では次の 2 つに分けて考えると整理しやすいです。Windows 版の Windows App は Azure Virtual Desktop 向けに ms-avd を扱えます。一方、ブラウザ版 Windows App は direct launch URL で Azure Virtual Desktop や Windows 365 の特定リソースへそのまま接続できます。Windows App for Windows の ms-avd 対応は 2.0.804.0 以降で、同じ端末に旧 Remote Desktop client と Windows App が両方入っている場合は ms-avd プロトコルが Windows App を起動します。ブラウザ版では 2025年4月に direct launch URL が追加され、2025年11月には RemoteApp の direct launch support も追加されました。 (Microsoft Learn)
| 起動方式 | 主な対象 | 向いている場面 | 実務上の注意点 |
|---|---|---|---|
ms-avd:connect | Windows 上の Windows App + Azure Virtual Desktop | 社内ポータル、社内メール、運用ツールからネイティブ起動したい | 既存の Remote Desktop client 向け URI をそのまま流用せず、Windows App 前提で再検証する |
| direct launch URL | ブラウザ版 Windows App + Azure Virtual Desktop / Windows 365 | BYOD、外部ユーザー、ブラウザ中心運用、ソフト導入を減らしたい | URL 生成に必要な ID 取得が必要。RemoteApp のタブ挙動にも注意 |
この切り分けをしておくと、設計判断がかなり早くなります。管理対象の Windows 共有端末なら Windows App ネイティブ + auto logoff、インストールを避けたい端末や外部ユーザーならブラウザ直リンク、という考え方が基本です。 (Microsoft Learn)
URI/URL 連携で、どこまで自動化できるのか
できることは、単なる「起動ショートカット」より一段実務寄りです。たとえば次のような導線に落とし込めます。
- 社内ポータルの「経理デスクトップを開く」「RemoteApp を開く」ボタン
- ヘルプデスクの案内メールに入れる接続リンク
- 受付・教室・シフト端末のトップページからのワンクリック起動
- 外部委託先向けの専用接続ページ
特にブラウザ版の direct launch URL は、Windows App の UI を経由せず、特定のリソースへ直接接続できる のが利点です。Azure Virtual Desktop では desktop と RemoteApp の両方を URL で指定でき、Windows 365 では対象 Cloud PC に直接入れます。加えて、外部 ID 利用時は tenant、アカウント選択の手間を減らしたい場合は loginHint を付けられます。なお、リンクを作っても権限が自動付与されるわけではなく、そのデスクトップや RemoteApp がユーザーに割り当て済みであることが前提 です。 (Microsoft Learn)
ブラウザ版で使う direct launch URL の基本形
Azure Virtual Desktop 向けの基本形は次のとおりです。
https://windows.cloud.microsoft/webclient/avd/<workspaceID>/<resourceID>外部 ID を使う場合は tenant を付けます。
https://windows.cloud.microsoft/webclient/avd/<workspaceID>/<resourceID>?tenant=<tenantID>ログイン済みユーザーをそのまま通したい場合は loginHint を末尾に付けます。
https://windows.cloud.microsoft/webclient/avd/<workspaceID>/<resourceID>?tenant=<tenantID>#loginHint=<UPN>Windows 365 は次の形です。
https://windows.cloud.microsoft/webclient/ent/<workspaceID>loginHint は URL の末尾でないと機能しません。外部ユーザーの導線を簡素化したい場面では、この仕様を知っているかどうかで完成度がかなり変わります。 (Microsoft Learn)
AVD の ID は Azure Portal だけで完結しない前提で進める
direct launch URL を実装するときに詰まりやすいのが、workspaceID と resourceID の取得です。Microsoft Learn でも、必要な値は Azure Portal だけでは見つけにくく、Azure PowerShell を使う前提で案内されています。実務では「ポータルを開いて探す」より、最初から PowerShell で取る方が速いです。 (Microsoft Learn)
# Workspace の Object ID
Get-AzWvdWorkspace -ResourceGroupName "<ResourceGroupName>" -Name "<WorkspaceName>" |
Format-Table Name, FriendlyName, ObjectId
# Desktop の Object ID
Get-AzWvdDesktop -ResourceGroupName "<ResourceGroupName>" -ApplicationGroupName "<ApplicationGroupName>" |
Format-Table Name, ObjectId
# RemoteApp の Object ID
Get-AzWvdApplication -ResourceGroupName "<ResourceGroupName>" -ApplicationGroupName "<ApplicationGroupName>" |
Format-Table Name, ObjectIdWindows 365 の direct URL では Cloud PC の workspace ID を使います。こちらは Microsoft Graph PowerShell SDK の Microsoft.Graph.DeviceManagement.Administration モジュールを使って取得します。Enterprise と Frontline dedicated mode の Cloud PC が対象です。 (Microsoft Learn)
Import-Module Microsoft.Graph.DeviceManagement.Administration
Connect-MgGraph -Scopes "CloudPC.Read.All"
Get-MgDeviceManagementVirtualEndpointCloudPc | Format-Table DisplayName, IdWindows ネイティブ起動は ms-avd:connect を中心に考える
Windows 共有端末や社内管理端末で Windows App をネイティブ起動したいなら、軸になるのは ms-avd:connect です。ここで注意したいのは、Windows App for Windows が対応しているのは ms-avd であって、ms-rd ではない という点です。さらに Microsoft Learn 上でも、Remote Desktop client と Windows App で URI パラメーターのサポート差分があることが示されています。つまり、過去の Remote Desktop client 用リンクを、そのまま Windows App へ持ち込まない方が安全 です。まずは 1 本の社内リンクでパイロットし、想定したアカウント・リソース・画面遷移になるかを確認してから横展開するのが堅実です。 (Microsoft Learn)
auto logoff は共有端末の「後始末」機能と考える
auto logoff は、共有PC運用でかなり便利です。ただし役割を正しく理解しておく必要があります。Microsoft Learn では、Windows App auto logoff は Windows App の connection center から使うシナリオ向け とされており、Windows 365 Boot、Windows 365 Switch、タスクバーにピン留めした接続 ではサポートされません。動作すると、Windows App のローカルキャッシュ上にある資格情報、RDP ファイル、その他の識別可能なデータが削除され、次回起動時はサインイン画面に戻ります。必要なら SkipFRE で初回体験画面をスキップできます。 (Microsoft Learn)
ここで大事なのは、auto logoff はセキュリティ機能そのものではない という点です。Microsoft も、これは運用上の利便性とデータ衛生を目的としたもので、未承認アクセス防止やポリシー強制の代替ではないと明記しています。さらに、auto logoff が動くと ローカルログも消える ため、トラブル調査中は逆に不便になることがあります。加えて、毎回リソース一覧を取り直す都合で、起動が少し長くなる可能性もあります。 (Microsoft Learn)
共有PCで使うなら、この 3 パターンから始める
Microsoft が公開している auto logoff のシナリオを、そのまま実務向けに並べ替えると次の 3 パターンが使いやすいです。 (Microsoft Learn)
| パターン | 主な設定 | 向いている場面 | 判断ポイント |
|---|---|---|---|
| アプリを閉じたら片付ける | AutoLogoffEnable=1 + SkipFRE=1 | 使い終わったら必ず Windows App を閉じる運用 | 一番わかりやすい。まず試すならこれ |
| 接続成功後に片付ける | AutoLogoffOnSuccessfulConnect=1 + SkipFRE=1 | 共用PCで「接続さえ始まればローカル側のサインイン状態は残したくない」 | 接続後は Windows App 側だけ裏で片付く |
| 放置対策も入れる | AutoLogoffTimeInterval=<分> + SkipFRE=1 （必要に応じて AutoLogoffEnable=1） | 教室PC、受付端末、シフト端末など、放置が起きやすい | きっちり分単位ではなく、実際の発火は遅れることがある |
特に共有端末で相性がいいのは、接続成功後に片付ける か、放置対策込み のどちらかです。前者は「ローカル側に前ユーザーの痕跡を残したくない」端末に向いています。後者は「閉じ忘れや離席がある」運用に向いています。逆に、1台を一人が主に使う端末では、毎回リセットするメリットは小さめです。
すぐ試すなら「10分放置 + 閉じたらリセット」が現実的
共有PCで最初に導入するなら、次のような構成がわかりやすいです。これは Microsoft が案内しているレジストリ値を元にした、実務向けの例です。設定配布は Intune、Configuration Manager、Group Policy、PowerShell が使えます。 (Microsoft Learn)
$wa = "HKLM:\SOFTWARE\Microsoft\WindowsApp"
if (!(Test-Path $wa)) { New-Item -Path $wa -Force | Out-Null }
New-ItemProperty -Path $wa -Name AutoLogoffEnable -PropertyType DWORD -Value 1 -Force | Out-Null
New-ItemProperty -Path $wa -Name AutoLogoffTimeInterval -PropertyType DWORD -Value 10 -Force | Out-Null
$w365 = "HKLM:\SOFTWARE\Microsoft\Windows365"
if (!(Test-Path $w365)) { New-Item -Path $w365 -Force | Out-Null }
New-ItemProperty -Path $w365 -Name SkipFRE -PropertyType DWORD -Value 1 -Force | Out-Nullこの設定にしておくと、ユーザーが離席して OS 側で十分なアイドル状態と判断されたとき、または Windows App を閉じたときに、Windows App のローカル状態を片付けやすくなります。共有PCの「前の人のアカウントが残っていた」を減らすには、かなり実用的です。 (Microsoft Learn)
ここを誤解すると運用でハマる
auto logoff しても、リモートセッション自体は終わらない
一番多い誤解はここです。Microsoft Learn でも、アイドルで auto logoff が動いても アクティブな Azure Virtual Desktop セッションや Windows 365 セッション自体は影響を受けない とされています。つまり、共有端末で「使い終わったら必ずセッションごと終了したい」なら、Windows App auto logoff だけでは足りません。Azure Virtual Desktop 側の Session Time Limits も併せて決める必要があります。たとえば Microsoft の autoscale FAQ でも、切断セッションを時間制限でサインアウトする設定として Remote Desktop Session Host > Session Time Limits > Set time limit for disconnected sessions を案内しています。 (Microsoft Learn)
5分設定が、きっちり5分で発火するとは限らない
AutoLogoffTimeInterval は「何分後に必ず発火する」タイマーではありません。Windows OS の inactivity signal を一定間隔で見に行く仕組みなので、公式ドキュメントでも、たとえば 5 分設定でも実際の発火は 最大でほぼ 2 倍近く遅れることがある と説明されています。会議室端末や受付端末で「5分きっかりで片付けたい」と考えると期待とズレやすいので、実際には 10 分前後で設計した方がトラブルになりにくいです。 (Microsoft Learn)
調査中に auto logoff を有効化すると、ログが消えて困る
auto logoff はローカルログを消します。つまり、接続失敗やアカウント切り替え問題を調べている最中に有効化すると、必要な痕跡まで消えます。パイロット導入では、まずログ取得と接続検証を優先し、その後に auto logoff を有効化する 順番の方が安全です。運用に入ってからも、障害調査時だけ一時的に auto logoff を外す運用を決めておくと、現場が困りません。 (Microsoft Learn)
同じ host pool の Desktop と RemoteApp を URI で両取りしない
Azure Virtual Desktop の設計面でも注意点があります。Microsoft は、同じ host pool に対して ms-avd:connect で desktop と RemoteApp の両方へ接続することは推奨していません。ユーザーが同じ host pool に対して 2 つの別セッションを持つ形になると、セッションホスト過負荷、サインイン詰まり、接続失敗、黒画面、アプリクラッシュの原因になり得ると案内しています。URI 連携を広げるほど、この手の設計ミスは見えにくくなるので、desktop 用 host pool と RemoteApp 用 host pool を分ける くらいの意識でいた方が安全です。 (Microsoft Learn)
ブラウザ版 RemoteApp は「複数タブの挙動」まで見ておく
ブラウザ版の direct launch URL は便利ですが、RemoteApp を同じ host pool から別タブで開く運用には癖があります。Microsoft Learn では、同じ host pool の 2 つ目のアプリを新しいタブで起動すると、元のタブが切断され、両方のアプリが新しいタブに見える とされています。社内ポータルに複数の「業務アプリ起動」ボタンを並べる場合、この挙動を知らずに設計すると「リンクは間違っていないのに挙動が変」と見えやすいので、事前に利用部門へ説明しておくべきです。 (Microsoft Learn)
導入は「1本のリンク」と「1台の共有PC」から始める
大きく始めるより、次の順番で進めると失敗しにくいです。
- まず 1 つの代表導線を決める
社内ポータルか、案内メールか、共有PCのトップページかを決めます。管理端末中心なら Windows ネイティブ、BYOD や外部向けならブラウザ直リンクが基本です。 (Microsoft Learn) - 1 リソースだけ direct launch か
ms-avdで動かす
いきなり全業務アプリをリンク化せず、まずは 1 つの desktop か 1 つの RemoteApp で検証します。特に Windows App では、旧 Remote Desktop client からの流用より再設計の方が事故が少ないです。 (Microsoft Learn) - 共有PCでは auto logoff を入れるが、役割を絞る
「ローカルの後始末」なのか、「離席端末の片付け」なのかを決めてからキーを選びます。全部盛りにするより、まずはAutoLogoffEnableかAutoLogoffOnSuccessfulConnectのどちらかで始めると運用が安定しやすいです。 (Microsoft Learn) - セッション自体を切りたいなら host 側ポリシーもセットで入れる
shared devices 運用では、Windows App の auto logoff と AVD 側の Session Time Limits を役割分担させるのが王道です。前者はローカルの痕跡消し、後者はサーバー側セッションの終了です。 (Microsoft Learn)
まとめ
Windows App の URI 連携と auto logoff は、どちらも派手な機能ではありません。ただ、情シスの実務ではかなり効きます。URI/URL 連携は「社内導線を短くする機能」、auto logoff は「共有端末の後始末を自動化する機能」 と捉えると、導入判断がぶれません。特に shared devices では、Windows App のサインイン状態やキャッシュを残さないだけでも、問い合わせやヒヤリハットを減らせます。反対に、セッション強制終了やセキュリティ統制まで auto logoff に期待すると失敗します。 (TECHCOMMUNITY.MICROSOFT.COM)
次にやるべきことはシンプルです。まず 1 本の社内リンクを作る、次に 1 台の共有PCで auto logoff を試す、そして 必要なら AVD 側の Session Time Limits を追加する。この 3 ステップで始めれば、Windows App への移行を単なるクライアント置き換えで終わらせず、運用設計の改善まで持っていけます。商用クラウドでは旧クライアントがすでに未サポートになっているため、今のタイミングで導線と共有端末設計を見直す価値は十分あります。 (TECHCOMMUNITY.MICROSOFT.COM)
コメント