リモートデスクトップの「お待ちください」と遅延の原因と対処の手順

はじめに

Windows のリモートデスクトップ接続（RDP）は、離れた場所にある PC やサーバーを遠隔操作できる機能です。実務で遭遇するトラブルは、大きく「画面が重く操作が遅延する」系統と、「接続時に『お待ちください』のまま進まない」系統の 2 つに分かれます。両者は原因も対処も異なるため、切り分けが重要になります。

「お待ちください」のまま進まない場合は、単純なネットワーク遅延とは異なり、ローカルセッションマネージャーの処理待ちや認証処理のスタックが原因になることが多く、リモート側からのリフレッシュが必要になります。一方で動作が遅い場合は、画面設定による通信量の削減と、回線品質（ラウンドトリップ時間）やトランスポートの見直しが中心的な対処になります。本記事では、まず前提として利用しているクライアントの違いを整理したうえで、原因別の対処を解説します。

使っているクライアントを確認する（mstsc と Windows App の違い）

対処に入る前に、自分がどのクライアントで接続しているかを確認しておくと、設定画面の差異で迷わずに済みます。

Windows のリモートデスクトップ系クライアントは、現在 2 種類が併存しています。1 つは OS に組み込まれている「リモートデスクトップ接続」（mstsc.exe）、もう 1 つは Microsoft が 2024 年 9 月に提供を開始した新しい「Windows App」です。Microsoft Store 版の旧「Remote Desktop アプリ」は Windows App へ置き換えられ、Store 版は 2025 年 5 月 27 日にサポートが終了しました。MSI 版のスタンドアロンクライアント（MSRDC）も、商用クラウド向けは 2026 年 3 月 27 日にサポート終了が案内されています。

ただし、組み込みの mstsc.exe（リモートデスクトップ接続）は廃止の対象ではなく、社内 LAN の PC やサーバーへ RDP 接続する標準的な手段として引き続き利用できます。本記事で扱う「エクスペリエンス」タブや「画面」タブの設定は、この mstsc.exe を前提としています。Windows App では設定項目の名称や配置が異なる点に注意してください。

参考: Windows App to replace Remote Desktop app for Windows（Microsoft Windows IT Pro Blog）
“the Remote Desktop app for Windows will no longer be supported”
（Windows 版の Remote Desktop アプリは今後サポートされなくなる）
https://techcommunity.microsoft.com/blog/windows-itpro-blog/windows-app-to-replace-remote-desktop-app-for-windows/4390893

「お待ちください」で止まる・フリーズする場合の対処

接続時に「お待ちください」の表示のまま進まず、デスクトップ画面へ遷移しない現象は、単純なネットワーク遅延とは性質が異なります。長時間待っても自然に解消しないことが多く、原因の多くはリモート側の処理がスタックしている点にあります。ここでは原因別に切り分けながら対処します。

ローカルセッションマネージャーの処理待ち（ユーザー切り替え）

「ローカルセッションマネージャーの処理が完了するのをお待ちください」と表示される場合、接続先で既存のサインインユーザーの切り替え処理が応答待ちになっていることがあります。接続先の物理画面側にログオフ確認のダイアログが出て、その応答を待っている状態です。

切り分けとしては、別の管理者アカウントで接続できるかを試すと、特定プロファイル固有の問題か、システム全体の問題かを判別しやすくなります。1 時間以上待っても解消しない場合は処理がスタックしている可能性が高く、リモート側のリフレッシュ（再起動またはサインアウト）が必要になります。

参考: ローカル セッション マネージャー サービスの待機中には VM が応答しない（Microsoft Learn）
「プロセスが終了するのを待つだけで問題が解消する場合もあります」
https://learn.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/windows/vm-unresponsive-wait-local-session-manager

資格情報・認証の遅延（NLA / ドメインコントローラー到達性）

ドメイン環境では、ログオン時にリモートデスクトップサービス（RDS）がユーザー構成をドメインコントローラー（DC）へ問い合わせます。DC への回線が遅延・輻輳していると、この往復処理に時間がかかり、ログオンが遅く（ハングしたように）見えることがあります。Microsoft の KB 4021856 では、RDS・lsass（Kerberos）・リダイレクターの間で発生するデッドロックとして、この現象が説明されています。

また、NLA（ネットワークレベル認証）は接続を確立する前に認証を行う仕組みのため、DC に到達できないと「NLA を実行できない」旨で接続が止まることがあります。NLA は証明書失効リスト（CRL）の確認で外部へ問い合わせを行うため、その通信経路が遮断されていると「リモート接続を保護しています」の表示のまま数十秒から 1 分ほど停止することがあります。

対処の方向性としては、まず DNS と DC の到達性・名前解決を点検し、CRL の確認に必要な通信経路を確保したうえで、DC 側や回線側の負荷を確認します。NLA を無効化すれば事象を回避できる場合もありますが、ブルートフォースや中間者攻撃の対象になりやすく、セキュリティ上は推奨されません。原因（DNS / DC / CRL）の解消を優先するのがおすすめです。なお、サーバー側ではログオン時の DC 問い合わせを抑制する fQueryUserConfigFromLocalMachine レジストリ設定が KB 4021856 で案内されていますが、適用は影響を理解したうえで検討してください。

参考: Server freezes or user logon is slow when connecting to Windows Server by using RDP（Microsoft Learn / KB 4021856）
“the round trips for these induce significant delays”
（これらの往復処理が大きな遅延を引き起こす）
https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/sbsl-issue-create-rdp-connection-to-computer

Ctrl+Alt+End での緊急回避と、効かない場合の対処

画面がフリーズしてマウス操作を受け付けない状態でも、リモートデスクトップ専用のショートカットでセキュリティオプション画面を呼び出せます。通常の「Ctrl + Alt + Delete」は手元のローカル PC が反応してしまうため、リモート側に対しては以下の操作を行います。

1. キーボードの「Ctrl」+「Alt」+「End」を同時に押します。
2. リモート側の画面が切り替わり、ロックやサインアウトを選べる画面が表示されます。
3. 右下の電源アイコンから「再起動」または「サインアウト」を選び、状態を一旦リセットします。

タスクマネージャーを起動できる場合は、「プロセス」タブから「エクスプローラー（explorer.exe）」を再起動すると、PC 本体を再起動せずにデスクトップが復帰することがあります。

ただし、Ctrl+Alt+End はあくまで RDP セッションが確立している前提です。セッション確立前のブルー背景の「お待ちください」で固着している場合は、Ctrl+Alt+End も効かないことがあります。その場合、管理者であれば同一 LAN 内の別端末や別の管理者セッションから、停止しているセッションを確認・切断する方法があります。

:: セッションの一覧と ID を確認する
qwinsta /server:<サーバー名>

:: 対象セッションをリセット（切断）する
rwinsta <セッションID> /server:<サーバー名>

セッションのリセットは対象セッションの未保存データが失われるため、影響を確認したうえで実行してください。インターネット越しなどでこれらの手段が使えない場合は、ホスト側の物理的な再起動に頼ることになります。

参考: qwinsta（Microsoft Learn）
“This command is the same as the query session command”
（このコマンドは query session コマンドと同じである）
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/qwinsta

動作が「遅い・重い」場合の対処

リモートデスクトップの動作が遅延する主な要因は、ネットワーク帯域の不足と、リモート側 PC のリソース（CPU・メモリ）の圧迫です。ここでは、システムを危険にさらさずに見直せる項目から順に解説します。

画面設定（エクスペリエンス / 画面タブ）での通信量削減

リモートデスクトップは、画面の描画情報をネットワーク経由で常に転送しています。通信環境が不安定な場合は、クライアント側の設定で転送データ量を削減する方法が、比較的すぐに効果の出やすい対処です。

1. リモートデスクトップ接続（mstsc.exe）を起動し、左下の「オプションの表示」をクリックします。
2. 「エクスペリエンス」タブを開き、接続速度のプルダウンで低速側のプロファイル（「モデム」など）を選ぶか、下部のチェックボックスを手動で外します。
3. 特に「デスクトップの背景」と「ウィンドウのドラッグ中に内容を表示する」を無効化すると、描画の遅延が軽減されやすくなります。文字の見やすさを保ちたい場合は「フォントスムージング」のみ残す設定が実用的です。
4. 「画面」タブで画面の色数を下げる（例: 32 ビットから 16 ビットへ）と、通信量をさらに節約できます。

これらは描画品質と引き換えに転送量を減らす設定のため、回線が細い環境ほど体感差が出やすくなります。

ラウンドトリップ時間（RTT）警告と回線・トランスポートの見直し

接続バー（画面上部のバー）の接続情報アイコンをクリックすると、現在の接続品質とラウンドトリップ時間（RTT）を確認できます。RTT は通信の往復遅延を表し、この値が大きいほど操作の反応が遅くなります。回線品質が低下すると「接続のラウンドトリップ時間が長くなっています」という警告が表示されることもあります。

まず見直すのは物理的な回線です。無線接続であれば有線へ切り替える、手元側・リモート側それぞれの回線品質を確認する、VPN 経由の場合は MTU やフラグメントの設定を点検する、といった順序が基本になります。

次にトランスポートの見直しです。RDP 8 以降は既定で UDP を優先します。UDP は高遅延の回線でも応答性を高めることが多い一方、パケットロスや VPN 経由でのフラグメントが起きる環境では、かえって描画のカクつきや切断の原因になることがあります。UDP が原因で不安定になっている場合に限り、クライアント側で UDP を無効化して TCP のみに固定すると安定することがあります。

• グループポリシーで設定する場合: コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > リモート デスクトップ サービス > リモート デスクトップ接続のクライアント >「クライアントで UDP を無効にする」を「有効」にします。
• レジストリで設定する場合（上記ポリシーと同等）: 管理者権限のコマンドプロンプトで以下を実行します。

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /d 1 /t REG_DWORD

• サーバー側で制御する場合: リモート デスクトップ セッション ホスト > 接続 >「RDP トランスポート プロトコルを選択する」で「TCP のみを使用する」を選びます。

UDP は再送を減らして応答性を高める仕組みのため、無効化はあくまで「UDP に起因する不安定さが確認できる場合」に限定して検討するのがおすすめです。

参考: MS-RDPEUDP（Microsoft Learn）
“MS-RDPEUDP is a new protocol in RDP8”
（MS-RDPEUDP は RDP 8 で導入されたプロトコルである）
https://learn.microsoft.com/en-us/archive/blogs/openspecification/ms-rdpeudp-glance-at-tlsdtls-handshake-packets

Windows Update（アクティブ時間）による帯域圧迫の抑制

リモート先の PC で Windows Update がバックグラウンドで実行されると、大量のデータダウンロードによってネットワーク帯域が一時的に占有され、操作が重くなることがあります。これを避けるため、業務時間中に更新や再起動が走らないよう「アクティブ時間」を設定します。

Windows 11 での手順は次のとおりです。

1. 「設定」を開き、左側メニューの「Windows Update」を選択します。
2. 「詳細オプション」をクリックし、「アクティブ時間」を展開します。
3. 既定では「自動的に調整する」が選択されています。「アクティブ時間を調整する」のプルダウンを「手動」に切り替えると、開始時刻と終了時刻を指定できます（最大 18 時間）。
4. 普段リモート接続で作業する時間帯（例: 8:00 から 18:00 など）を指定して保存します。

これにより、指定した時間帯は自動的な再起動が抑制され、リモート作業中の予期せぬ帯域圧迫や中断を防ぐことにつながります。

参照: アクティブ時間を使用して PC を最新の状態に保つ（Microsoft サポート） https://support.microsoft.com/ja-jp/windows/de79813c-7919-5fed-080f-0871c7bd9bde

企業環境で複数人が接続する場合の注意点

Windows 10 や 11 などのクライアント OS へのリモート接続は原則 1 対 1 ですが、Windows Server 環境では複数人のユーザーが同時に 1 台のサーバーへ接続して業務を行うケースがあります。この場合、単一 PC への接続とは異なる原因で遅延や接続トラブルが発生します。

複数のユーザーが同時に重いアプリケーションを実行したり、ブラウザのタブを大量に開いたりすると、サーバー側の CPU やメモリが枯渇し、接続している全員の画面操作が遅延します。動作が重い場合は、管理者権限でタスクマネージャーの「ユーザー」タブを確認し、過剰にリソースを消費しているセッションを特定・整理する方法があります。

また、Windows Server の標準機能で同時にリモート接続できるのは、管理目的の管理者 2 セッションまでです。3 名以上が同時に接続して業務を行う場合や、接続上限によるエラーやフリーズを避けたい場合は、「リモートデスクトップサービス（RDS）」の構築と、接続するユーザー数またはデバイス数に応じたアクセスライセンス（RDS CAL）が必要になります。

ライセンスの仕組みや、自社に必要な RDS CAL の選び方については、関連記事『Windows Server のリモートデスクトップ同時接続数を増やす手順と RDS CAL の違い』で詳しく解説しています。

まとめ

本記事では、リモートデスクトップの「お待ちください」での停止と、動作の遅延・重さについて、原因の切り分けと対処を解説しました。前者はリモート側の処理スタック、後者は回線品質とリソースが主因であり、対処の入口が異なります。クライアントの違いを確認したうえで、原因に応じた対処を選ぶことが解決の近道になります。

• クライアントは mstsc と Windows App の 2 種類を確認
• 「お待ちください」は単純な遅延と異なり処理スタックが主因
• ローカルセッションマネージャーの待機はユーザー切り替えの応答待ちが多い。
• 認証遅延は DNS・DC 到達性・CRL 経路の点検を優先
• 動作が遅い場合は画面設定とトランスポートの見直しが基本
• ラウンドトリップ時間が大きいときは回線と UDP / TCP を点検
• 複数人の同時接続には RDS の構築と RDS CAL が必要

以上、最後までお読みいただきありがとうございました。