速度測定では数百Mbps出るのに、RDPの入力が遅いのはなぜですか？

大きなデータを運ぶ速さと、操作に反応が返るまでの時間は別です。入力の送信、接続先アプリの処理、画面の圧縮、転送、手元での表示が関係します。また、速度測定の相手とRDPの接続先では通信経路も異なります。

文字は普通に打てるのに、スクロールだけカクつくのは回線の問題ですか？

回線だけには絞れません。画面更新が増えたときに、接続先の描画・圧縮、通信、手元のデコード・表示のどこかが追いつかない可能性があります。リモート側の解像度やモニター数を一つずつ変えて比較し、必要なら描画関連のカウンターを調べます。

pingが速ければ、RDPの通信は正常ですか？

それだけでは判断できません。pingはICMPへの応答を測り、RDPの画面転送やアプリの処理は測りません。RD Gatewayなどを使う構成では経路も一致しないことがあります。応答がない場合も、ICMPの遮断とRDP自体の不通を区別してください。

User Input Delayは、キーを押して文字が出るまでの時間ですか？

違います。接続先で入力がキューに入り、プロセスが取り出すまでの待ち時間を測るカウンターです。通信の往復、取り出した後のアプリ処理、画面の圧縮・デコード・表示までを含む体感遅延ではありません。

RDPが重いときはUDPを無効にすべきですか？

一律には勧めません。まず実際の接続方式と経路、適用ポリシーを確認します。UDPが使えずTCPにフォールバックしている場合もあり、TCP限定への変更で常に速くなるわけではありません。管理者の許可の下で条件をそろえて比較し、不要な変更は戻します。

回線は速いのにRDPが重いのはなぜ？ ── 入力・描画・通信を分けて調べる

2026年09月11日 02:00 · 更新日: 2026年10月18日 · 小村豪 · Windows, RDP, リモートデスクトップ, パフォーマンス, トラブルシューティング

更新履歴(初版のみ・2026年09月11日公開)

2026年09月11日: 初版公開

RDPの操作応答は、回線の転送速度だけでは決まりません。遅い操作を特定し、入力待ち、画面処理、通信を一条件ずつ比較して、次に調べる場所を絞ります。

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

問題・質問

速度測定では数百Mbps出るのに、リモートデスクトップでは文字が少し遅れて現れる。写真の多いページをスクロールすると画面が引っかかる。業務アプリの検索を押したときだけ数秒止まる。このような「回線は速いのにRDPが重い」状態を、どこから調べればよいのでしょうか。

この記事では、接続後の入力・スクロール・アプリの応答を切り分けます。症状が似ていても原因は一つとは限りません。「ログイン画面が出るまで長い」「認証だけで止まる」場合は、接続確立や認証の記録から調べる別の問題として扱います。

対象環境

主な対象は、Windowsの「リモートデスクトップ接続」（mstsc）からWindows 11またはWindows Serverへ接続する利用者・管理者です。コマンド例はWindows PowerShell 5.1向けです。接続済みのセッションで同じ操作を再現できることを前提にします。

直接接続、VPN、RD Gateway、Azure Virtual Desktopでは経路・利用できる診断情報・設定の適用先が異なります。TCP 3389の確認例は、標準ポートを使うRDPホストへの許可された直接接続に限ります。Azure Virtual Desktop向け資料の診断機能やGPU設定を、一般の社内PCへそのまま適用しません。

会社の端末では管理者が許可した範囲で調査します。共有ホストでは自分のセッションと対象プロセスを識別し、他の利用者の記録が必要なら管理者へ依頼してください。性能カウンターの利用可否・表示名・必要な権限は環境ごとに確認します。

以下は公式資料に基づく確認方法です。特定の端末で障害を再現して解消したという実測報告ではありません。数値例は説明用の仮定と区別して示します。

回答・解決方法

まず「何の操作が遅いか」を分け、同じ操作を一条件ずつ比較してください。速度測定が速くても、通信の往復、接続先アプリの入力待ち、画面のエンコード、手元のデコード・表示のどこかで待つ可能性があります。比較と計測で調査先を絞り、UDPやGPUの設定はその結果に合わせて選びます。参照: 接続品質の測定区間、セッションホストの性能要因。

この段階では根本原因は未確定です。解像度を下げて改善しても、通信だけでなく両端の画面処理も変わるため、「回線が原因だった」とは断定しません。測った区間と測っていない区間を分けて、結果を記録します。

定義

RDP

RDP（Remote Desktop Protocol）は、手元の端末と接続先の間で入力や画面情報などをやり取りするプロトコルです。画面と入力だけでなく、機器リダイレクトや印刷などの情報も扱います。参照: RDPが転送する情報。

回線の転送速度

回線の転送速度は、1秒間にどれだけのデータを運べるかを表します。速度測定の「500Mbps」はこの量に関する数字です。操作してから返事が届くまでの時間を示す数字ではありません。参照: RDPの帯域要件。

往復時間（RTT）

往復時間（RTT）は、通信が相手へ届いて戻るまでの時間です。転送速度を上げることと往復時間を短くすることは、道路の車線を増やすことと、目的地までの距離を短くすることの違いに似ています。大量のファイルを運ぶ能力が増えても、往復時間が同じなら操作の返事待ちは残ります。参照: RTTと画面表示の遅延。

操作応答の遅れ

ここでいう操作応答の遅れは、手元で操作してから結果が見えるまでの待ちです。RTTだけでなく、アプリの処理と画面を作って届ける処理も関係します。画面の転送区間だけの遅延とも区別します。参照: 画面取得から表示までの測定区間。

エンコード

この記事でいうエンコードは、接続先で画面を送信しやすい形へ変換・圧縮する処理です。回線による転送とは別に、接続先で処理時間がかかります。参照: 接続先のエンコード時間。

デコード

この記事でいうデコードは、届いた画面情報を手元で表示できる形へ戻す処理です。暗号の解除という意味の復号とは区別します。参照: 手元のデコードと表示時間。

User Input Delay

User Input Delayは、接続先で入力がキューに入ってからプロセスが取り出すまでの待ちを測ります。キーを押して文字が見えるまでの総時間ではありません。参照: User Input Delayの定義。

役割

調査範囲の絞り込み

切り分けの目的は、設定を一括変更して偶然速くすることではなく、遅さを調べる場所を限定することです。「メモ帳は動くが検索だけ止まる」「文字入力は普通だがスクロールだけ重い」という違いを使えば、通信設定を変える前にも調査の入口を選べます。

利用者・管理者・開発者の分担

利用者は再現する操作と比較結果を残し、管理者は接続経路・共有ホスト・セッションの記録を照合します。アプリの開発者は、入力受付、DBやファイルへの要求、UIへの反映を分けて記録します。RDP上で待っているという事実だけでは、待たせている処理までRDPとは限りません。参照: ホストとバックエンドの分担、WPFのUIスレッド。

構成

入力から画面表示まで

入力は手元から接続先へ届きます。接続先アプリが入力を処理して画面を更新し、エンコードした画面情報を回線で運び、手元でデコード・表示します。通信の前後にも、別々のPCが担当する仕事があります。参照: 画面取得から表示までの処理。

flowchart TB
    accTitle: 回線の前後にも画面の処理がある
    accDescr: 接続先の圧縮、ネットワークの転送、手元のデコードと表示は別の処理で、どこかが追いつかないと画面の更新が遅れます。
    A["接続先：画面を作って圧縮"] --> B["回線：画面の情報を運ぶ"]
    B --> C["手元：表示できる形へ戻す"]
    C --> D["手元の画面に表示"]

図1: 接続先で圧縮し、回線で運び、手元で表示に戻す。それぞれ別の場所で行う仕事です。

接続先の圧縮に時間がかかれば、回線が空いていても送信の準備を待ちます。情報が届いていても、手元のデコードや表示が追いつかなければ更新は遅れます。「会社のPCは高性能だから手元は何でもよい」とは限りません。回線の余裕と、その両端の処理の余裕は別です。参照: 画面処理の性能カウンター。

仕組み

画面更新と処理負荷

メモ帳に一文字を足すと、変わるのは画面の小さな部分です。写真の多いページをスクロールすると、広い範囲の表示が次々に変わります。RDPは毎回画面全体を無圧縮で送るのではなく、変更部分の転送や、内容に合った圧縮・キャッシュで通信量を抑えます。画面の内容と更新の頻度によって仕事量が変わります。参照: 画面内容と帯域の関係。

flowchart TB
    accTitle: 文字入力とスクロールで変わる画面の仕事量
    accDescr: 小さな文字の変化と、広い範囲の連続した更新では、画面を作って送る仕事の性質が異なります。
    A["メモ帳に一文字を追加"] --> B["小さな範囲が変化"]
    C["写真の多い画面をスクロール"] --> D["広い範囲が連続して変化"]
    B --> E["変化に応じて圧縮・転送"]
    D --> E

図2: 同じ接続でも、一文字を追加する場面と、広い範囲が動き続ける場面では仕事量が変わります。

静止した文書は軽くても、スクロール中には画面転送に余裕がなくなる場合があります。リモート側の解像度やモニター数を増やすと、処理対象の画面も大きくなります。解像度を下げる比較は、画面を作って送る仕事を減らすと動きが戻るかを見る実験です。画素数だけから通信量を決める計算ではありません。参照: 解像度・画面更新・圧縮の影響。

アプリ処理と入力待ち

業務アプリの検索だけ数秒止まり、同じセッションのメモ帳には普通に入力できるなら、そのアプリが何を待つかを確認します。接続先アプリがさらに別のDBへ検索を依頼したり、共有フォルダーからファイルを読んだりして、その返事を待つ場合があります。手元と接続先を結ぶRDP通信とは別の経路です。参照: 接続先からバックエンドへの通信。

flowchart TB
    accTitle: RDPの先にも通信相手がある
    accDescr: 手元の端末と接続先を結ぶ通信とは別に、接続先アプリが業務サーバーの返事を待つ場合を示します。
    A["手元の端末"] -->|"RDP"| B["接続先の業務アプリ"]
    B -->|"検索やファイルの要求"| C["DB・共有フォルダー"]
    C -->|"アプリが待っている返事"| B

図3: RDPの先にいる業務アプリが、さらに別のサーバーの返事を待つことがあります。

画面や入力を担当する処理が長い仕事を抱えると、次の入力や画面更新が遅れます。たとえばWPFでは、UIスレッドが長時間占有されると応答性が損なわれます。CPU全体の使用率が低いことだけでは、特定のUIスレッドの待ちを否定できません。参照: DispatcherとUIスレッド。

具体例

次の表は原因の判定表ではなく、調査の出発点です。同じセッションで操作を比べてから、必要な端末・経路・表示条件を変えます。

見えている症状	最初に比べること	その後に見る場所
複数アプリで一文字ずつ遅れて出る	同じ接続先への別端末・別の許可された経路	往復時間、入力待ち、接続先全体の負荷
入力は普通だがスクロールがカクつく	リモート側の解像度またはモニター数	接続先の圧縮、画面転送、手元のデコード
一つのアプリだけ固まる	同じセッションのメモ帳などは応答するか	そのアプリの処理、ディスク、接続先から先の通信
利用者が増える時間だけ皆が遅い	同じ時間帯の他のセッションも同様か	共有ホストのCPU・メモリ・ストレージ、共有回線
コピーや印刷を始めると遅くなる	自分の転送を一時停止すると戻るか	転送や機器リダイレクトと画面通信の競合

複数アプリで文字が遅れる

同じセッションの複数アプリで一文字ずつ遅れる場合は、別端末や別の許可された経路でも同じ操作を比較します。往復時間、接続先の入力待ち、接続先全体の負荷を照合し、一つの数値だけで原因を決めません。

リモートのメモ帳へ一文字入力する場面を考えます。メモ帳が動くのは接続先です。説明用に、操作が届くまで50ミリ秒、結果の画面情報が戻るまで50ミリ秒と仮定すると、通信に使う時間は合計100ミリ秒、つまり0.1秒です。両端の処理時間はこの例から除いています。

flowchart TB
    accTitle: 一文字の結果が戻るまでの通信時間の例
    accDescr: 説明用に行きと帰りをそれぞれ50ミリ秒と仮定した例です。両端の処理時間は含めず、キーごとのパケット数を表すものでもありません。
    A["手元で一文字を入力"] -->|"行き：50ミリ秒"| B["接続先で入力を受け取る"]
    B --> C["入力を反映した画面を送る"]
    C -->|"帰り：50ミリ秒"| D["手元に結果が届く"]

図4: 仮に行き50ミリ秒・帰り50ミリ秒なら、通信だけで0.1秒かかります。実測値ではありません。

運べる量が増えても往復時間が変わらなければ、この返事待ちは残ります。図は処理の理解のための概念図であり、キーごとに独立した一往復のパケットを送るという意味ではありません。速度測定の相手とRDP接続先では経路も異なり、VPN・ゲートウェイ・接続先側の上り・途中の混雑を含めて考えます。参照: RTTの考え方、ネットワークとホストの性能。

スクロールだけカクつく

文字入力は普通でも、写真の多いページをスクロールすると広い範囲の画面更新が続きます。リモート側の解像度またはモニター数を一つずつ変え、同じページで比較します。改善したら、接続先の圧縮、画面転送、手元のデコードを次の調査対象にします。解像度だけでは、この三つのどれが原因かまでは分かりません。参照: 画面内容と解像度による負荷。

一つのアプリだけ固まる

検索を押した業務アプリだけが止まるなら、同じセッションのメモ帳などが応答するかを比べます。別アプリが動いている場合は、対象アプリの処理、ディスク、DBや共有フォルダーへの要求を先に調べます。RDPで操作していることと、RDP通信が待ちの原因であることは別です。参照: アプリとバックエンドの性能要因。

利用者が増える時間だけ皆が遅い

同じ時間帯に複数の利用者で遅くなる場合は、管理者に他のセッションの状況を確認します。共有ホストのCPU・メモリ・ストレージと共有回線の負荷を、症状の時刻に合わせて照合します。他の利用者の記録や処理へ無断でアクセスしたり、ジョブを停止したりしません。参照: 共有ホストの資源と利用者数。

コピーや印刷中に遅くなる

自分のコピーや印刷を始めた時刻と不調が重なる場合は、停止を許可された転送だけを一時停止して比較します。停止後に戻るか、再開すると遅くなるかを記録し、画面以外の転送や機器リダイレクトとの競合を調べます。業務に必要な機器を一括で無効にする比較は避けます。参照: 機器リダイレクトの影響。

手順

すべての設定を順に変更する必要はありません。まず比較の基準を作り、症状に合う確認だけを選びます。設定変更・再接続の前に作業を保存し、元の値と戻し方を記録してください。必要な権限や機能がなければ、無理に有効化せず管理者へ引き継ぎます。

同じ操作を比較する

同じユーザー・データ・操作を用意します。共有ホストでは自分のセッションを確認し、他の利用者のアプリや処理は停止しません。別端末や別経路の利用も管理者が許可した範囲に限ります。

元の設定で遅い操作を再現し、時刻と症状を記録します。

問題のアプリと同じリモートセッションのメモ帳で、同じ程度の文字を入力します。一つのアプリだけか、セッション全体かを区別します。
接続先と手元の負荷を同じ時間帯に確認します。

タスクマネージャーで、接続先では対象アプリのCPU・メモリ・ディスクを、手元ではRDPクライアントの負荷を見ます。CPU全体の値だけでなく対象プロセスを確認します。参照: 負荷を調べる対象。
別端末、別の許可された経路、表示条件のうち一条件だけを変え、同じ操作を繰り返します。

接続先やアプリの状態まで同時に変わる比較では、その違いも記録します。複数の条件が変わった結果を、一条件だけの効果とみなしません。
元の条件へ戻し、同じ操作を再確認します。

元に戻しても速いままなら、一時的な負荷の変化なども考えられます。変更が効いたと決めつけず、症状が再現する条件を記録します。

元の状態・変更後・元に戻した状態の結果が揃い、どの条件と症状が対応するかを比較できます。改善した条件は調査の手がかりであり、単独では根本原因の証明ではありません。

flowchart TB
    accTitle: 一度に変える条件を限定する
    accDescr: 元の状態で再現する操作を決め、一条件だけを変えて比較し、戻した結果も確認する流れです。
    A["元の設定で同じ操作"] --> B["一条件だけ変える"]
    B --> C["同じ操作を繰り返す"]
    C --> D["元に戻して再確認"]
    D --> E["改善した条件を記録"]

図5: 元の状態、変更後、元に戻した状態で同じ操作を繰り返し、変化した条件を記録します。

リモート側の解像度を比較する

スクロールなど、画面更新が重い場合に比較します。変更前の解像度・モニター数を記録し、作業を保存してから再接続します。業務に必要な画面や文字の読みやすさを損なう設定を、そのまま常用しません。

モニター数か解像度のどちらか一方だけを変えます。

mstscでは接続前の「画面」設定や幅・高さの指定で比較できます。参照: mstscの画面指定。
接続先デスクトップの実際の大きさが変わったことを確認し、同じページをスクロールします。

手元のウィンドウを縮めただけでは、大きなデスクトップを縮小表示している場合があります。動的解像度とsmart sizingを区別し、利用クライアントの対応条件を確認します。参照: デスクトップ解像度と表示倍率。
元の設定へ戻して同じ操作を繰り返し、両端の負荷と画面の動きを比較します。

低解像度かつモニター一枚へまとめて変えた場合は、大まかな比較にとどまります。改善したら一方ずつ戻し、影響を分けてください。

改善した場合は、画面処理・画面転送の範囲に手がかりがあります。3840×2160は1920×1080の4倍の画素数ですが、通信量が常に4倍になるわけではありません。変更部分や圧縮によって変わり、解像度の変更は両端の処理にも影響します。参照: 画素数と通信量の関係、画面処理の確認。

flowchart TB
    accTitle: 解像度を下げた比較で分かる範囲
    accDescr: リモート側の解像度を下げると、画面処理と転送の双方の負担が変わり得るため、改善だけでは回線に原因を限定できません。
    A["リモート側の解像度を下げる"] --> B["接続先の画面処理が変わる"]
    A --> C["送る情報量が変わる"]
    A --> D["手元の表示処理が変わる"]

図6: 解像度の変更は、回線だけでなく、接続先と手元の画面処理にも影響する比較です。

コピー・印刷と症状を照合する

一時停止するのは、自分が開始した転送など、停止を許可された処理だけです。会社のバックアップ・セキュリティ処理や他の利用者のジョブは停止しません。業務に必要な音声・入力機器のリダイレクトを一括で無効にしません。

コピー・クラウド同期・印刷の開始前と実行中に、同じ操作と負荷を記録します。

RDPには画面以外に、ドライブやプリンターなどの情報も流れます。手元の機器を接続先で使うリダイレクトは、利用中の通信・処理負担を増やす場合があります。参照: 機器リダイレクトの影響。
対象の転送を許可された範囲で一時停止し、同じ操作を再確認します。

再開して比較できる場合は、再開後の症状も記録します。不要な機器リダイレクトを試す場合も、一つずつ変更し、元の設定へ戻せるようにします。

転送開始と不調、一時停止と回復が対応するかを判断できます。対応が見えたら、画面以外の転送と共有資源の負荷を管理者の記録と照合します。

flowchart TB
    accTitle: 不調の前後を同じ時間軸で見る
    accDescr: 転送前、転送中、停止後に同じ操作と負荷を記録し、不調と作業の関係を比較します。
    A["転送前の操作と負荷"] --> B["転送中の操作と負荷"]
    B --> C["停止後の操作と負荷"]
    C --> D["不調と回復が対応するか"]

図7: 転送前・転送中・停止後で、同じ操作の遅さと負荷がどう変わるかを見ます。

ICMPとTCP接続を確認する

実行場所は手元のWindows端末です。社内LANまたは許可されたVPNで、標準のTCP 3389を使うRDPホストへ直接接続する構成だけを対象にします。RD Gateway・Azure Virtual Desktop経由や独自ポートの構成では、確認先を管理者と決めてください。ポートの公開やファイアウォールの変更は行いません。

許可された接続先を入力し、ICMP応答とTCP接続の結果を記録します。

$target = Read-Host '調査を許可されたRDPホストの名前またはIPアドレス'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw '接続先を指定してください。'
}
    
# ICMPの応答時間を複数回見る。失敗だけではRDPの不通と判断しない。
ping.exe -n 20 $target
    
# 標準のTCP 3389へ直接接続する構成に限った確認。
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
    

遅い時間帯と通常時の結果を、症状の時刻・実際の接続経路と照合します。

20回のpingは短い観察です。値の揺れや応答なしを記録しますが、ICMPが遮断される場合もあります。断続的な停止は平均値だけで否定せず、接続情報や管理者の通信記録を使います。参照: pingの測定対象。

TcpTestSucceeded: Trueは指定ポートへのTCP接続に成功したという意味です。帯域、UDP、認証後の操作、画面の滑らかさは測っていません。Test-NetConnectionにUDPを調べる-UDPスイッチはありません。参照: Test-NetConnectionの構文と結果。

入力キューの待ちを測る

接続先のリモートセッション内で調べます。Microsoftの対応条件はWindows 10 バージョン1809以降・Windows Server 2019以降です。この対象では有効化のレジストリ追加は不要です。表示名・権限・カウンターの有無を確認し、利用できなければその事実を記録して管理者へ相談します。参照: 対応条件と設定。

同じセッションのPowerShellで、時刻とセッションIDを控えます。
```
Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
(Get-Process -Id $PID).SessionId
query.exe session
    
```
他の利用者のセッションを照会するには追加の権限が必要な場合があります。対象プロセスの標準のインスタンス名はSessionID:ProcessID <Process Image>です。セッションIDだけで別の利用者や同名プロセスの値を混ぜないようにします。参照: query sessionの権限、インスタンスの識別。
perfmon.exeで、利用可能なUser Input Delay per ProcessまたはUser Input Delay per Sessionを追加します。

対象のプロセス・セッションを選び、最初は既定の1秒間隔で観察します。複数セッションをまとめる集約インスタンスと、個別セッションの値を区別してください。
入力が遅い操作を再現し、キューの待ちと症状の時刻を比較します。

個別の測定対象では、測定区間内の最大の待ち時間を見ています。値が低くても、アプリが入力を取り出した後の処理や、結果が手元へ戻るまでの遅れは残ります。

接続先の入力キューで待っているかを調べられます。通信の往復や手元での表示を含む体感時間とは別の指標です。参照: 最大値と測定区間の意味。

flowchart TB
    accTitle: User Input Delayが測る区間
    accDescr: 接続先の入力キューからアプリが取り出すまでが測定区間であり、前後の通信や画面表示は含まれません。
    A["手元から入力が届く"] --> B["接続先の入力キューに入る"]
    B -->|"ここを測る"| C["アプリが入力を取り出す"]
    C --> D["アプリ処理と画面の転送"]
    D --> E["手元に表示される"]

図8: 測るのは接続先の入力キューでの待ちです。手元に結果が見えるまでの総時間とは違います。

画面更新と間引き理由を調べる

スクロールなど画面更新が続く操作を用意します。RemoteFX Graphicsカウンターの利用可否・計測場所はOS、ホスト構成、権限によって確認が必要です。ここでは利用可能なカウンターを読むのであり、古いRemoteFX機能を導入・有効化する手順ではありません。参照: Graphicsカウンターの適用条件。

query sessionまたはqwinstaで対象セッション名を確認し、対応するカウンターのインスタンスを選びます。
画面更新のある操作中に、Input Frames/SecondとOutput Frames/Secondを比較します。

出力が入力より少なければ、画面が途中で間引かれています。Frames Skipped/Secondの接続先・ネットワーク・クライアントのリソース不足別の値を確認します。
間引き理由と両端・通信の負荷を照合し、Average Encoding Timeも確認します。

エンコード時間が長いなら、接続先の圧縮処理を調べます。入力側からフレーム数が少ない場合は、アプリが頻繁に画面を更新していない可能性もあります。静止画面でフレーム数が低いこと自体は異常ではありません。

画面更新中の入出力、間引き理由、エンコード時間から調査先を絞れます。カウンターの分類は手がかりであり、実際の負荷や接続構成と合わせて判断します。参照: フレーム数とエンコード時間の読み方。

flowchart TB
    accTitle: 画面の間引きから調査先を絞る
    accDescr: 画面更新がある操作中に入出力フレーム数を比較し、間引き理由のカウンターを手がかりに、処理・通信・表示の負荷と照合します。
    A["スクロール中の入出力を比較"] --> B["出力が少ないなら間引きを確認"]
    B --> C["理由別カウンターを見る"]
    C --> D["接続先・通信・手元の負荷と照合"]

図9: スクロール中の入出力を比較し、間引き理由と、接続先・回線・手元の負荷を照合します。

TCP・UDPと接続経路を確認する

比較・計測で通信が疑わしい場合に確認します。管理者と利用中のクライアント・経路・適用ポリシーを確認します。設定変更が必要な場合も承認された範囲に限り、変更前の値と復旧方法を記録します。ファイアウォールや認証を無効にしたり、RDPポートをインターネットへ直接公開したりしません。

接続情報、製品の診断ログ、管理者の通信記録で、実際のTCP・UDPと経路を確認します。

RDPは構成と通信条件に応じてTCPやUDPを使います。「Select RDP transport protocols」ではUDPまたはTCPを利用する設定とTCPのみの設定を選べます。UDP接続が成立しなければTCPを使う動作もあるため、接続成功だけでは方式は分かりません。参照: RDP transportの選択とフォールバック。
症状の時刻と経路・方式を照合し、必要な設定だけを一つずつ比較します。

「UDPを切れば速くなる」と一律に変更しません。VPNやゲートウェイの条件、操作、表示条件を揃えて比較し、不要な変更は元に戻します。

方式と経路を把握したうえで、変更と症状の関係を記録できます。TCP限定への変更が常に高速化になるわけではありません。

flowchart TB
    accTitle: 接続方式を確認してから通信設定を比較する
    accDescr: 通常の直接接続とゲートウェイ・サービス経由の接続を区別し、実際の経路と方式を確認してから許可された比較を行います。
    A["使用クライアントと接続構成"] --> B["実際の経路・TCPやUDPを確認"]
    B --> C["症状の時刻と照合"]
    C --> D["必要な設定だけ一つずつ比較"]

図10: 利用中の接続方式と経路を確かめ、症状と照合してから、必要な設定だけを比較します。

画面処理のGPU利用を確認する

比較・計測で画面処理が疑わしい場合に確認します。画面処理の計測結果と、対応OS・ドライバー・ポリシー・クライアントを確認します。GPUが搭載されているだけで設定を変更しません。管理者の承認と元へ戻す準備を先に行います。

接続先アプリの描画、RDPのエンコード、手元のデコードを分け、疑わしい段階を選びます。

GPUがあっても、すべての段階がGPUを使うとは限りません。MicrosoftのAzure Virtual Desktop向け構成資料でも、リモートセッションの描画とフレームのハードウェアエンコードは別に設定・確認します。参照: 描画とエンコードのGPU構成・検証。
対象製品の手順に沿って実際の利用状況を確認し、必要な変更の前後で同じ操作を測ります。

圧縮時間が長いならエンコードへのGPU利用を調べます。入力キューで待つアプリにエンコード設定を変えても、狙う場所が違います。文字の読みやすさと動画の滑らかさでは、画質・通信量・処理負荷の選び方も異なります。参照: ワークロードによる違い。

GPUの有無ではなく、問題の段階にGPUが利用され、同じ操作の負荷と応答がどう変わったかを記録できます。改善がない変更は、管理者と確認して元に戻します。

確認

測定結果の適用範囲

数値が低いことと、操作が快適であることを同一視しません。各指標の範囲は、手順中に示したMicrosoftの資料で確認できます。

観測した結果	分かること	まだ分からないこと
pingの応答が小さい	その相手へのICMP応答時間	実際のRDP経路全体、アプリ処理、画面表示の正常性
TcpTestSucceededがTrue	指定先・指定ポートへのTCP接続成功	UDP、帯域、認証後の応答
User Input Delayが大きい	対象の接続先入力キューでの待ち	入力を取り出した後の処理と、手元までの総遅延
更新中に出力フレームが少ない	画面の間引きと、その理由を調べる手がかり	単一の根本原因。両端・通信の記録との照合が必要
解像度を下げると改善する	表示条件と症状が対応する可能性	回線、エンコード、デコードのどれが原因か

変更後と元の条件での再検証

改善は、変更後に同じ操作が支障なく行えることに加え、必要な画質・機器・業務機能が保たれることで確認します。元の条件へ戻した結果も照合してください。瞬間的な回復だけなら原因を確定せず、混雑時間帯や同時処理を含めて記録します。

未解決時の引き継ぎ

改善しない、再現しない、カウンターが利用できない場合も有用な結果です。実施できた比較とできなかった確認を分け、次のメモで管理者・開発者へ引き継ぎます。共有ログから、調査に不要なユーザー名や接続先などの業務情報を除いてください。

症状が出た時刻とタイムゾーン：
接続先OS・利用クライアントとバージョン：
直接接続／VPN／RD Gateway／Azure Virtual Desktopなど：
遅い操作とアプリ、同じセッションの別アプリの反応：
リモート側の解像度・モニター数：
同時に動いていたコピー・印刷など：
一つだけ変えた条件と、元に戻した結果：
接続先・手元で観測した負荷やカウンター：

実際のTCP・UDPが確認できたか、権限不足などで確認できなかった項目、業務上許容できる設定も補足します。「回線が遅い」ではなく「メモ帳は普通に打てるが写真をスクロールすると止まる」と伝えると、次の担当者が同じ条件で調べられます。

アプリの開発者は、入力イベントの受付、DB・ファイル処理の開始と終了、UIへの反映を分けて記録します。重い仕事をUIスレッドに居座らせない設計も検討します。ただし、接続先の処理完了ログは手元の表示完了を記録したものではありません。参照: UIの応答性を保つ処理の分離。

制約

運べる量、返事を待つ時間、画面を作って表示する時間は別です。この区別を保てば、「RDPが重い」を一つの原因で片付けず、いま遅い操作から調べられます。

ローカル操作との条件差

ローカル操作とRDP操作は同じ条件とは限りません。接続先の実画面で速いことは参考になりますが、セッションや描画条件が変わる場合があります。ユーザー・データ・アプリの状態を揃え、「実画面では速い」だけで回線に原因を限定しないでください。

接続経路と診断機能の適用範囲

経路とサービスの違いを残して判断します。RD Gatewayなどでは、ホストへのICMPや直接TCP接続の経路と実際のRDP経路が一致しないことがあります。Azure Virtual Desktopでは接続ごとのRTTや帯域推定値を利用できますが、その診断機能は同サービス向けです。平均値だけで短い停止を否定しません。参照: Azure Virtual Desktopの接続品質ログ。

RDP Shortpathの適用範囲

RDP ShortpathはAzure Virtual Desktopの仕組みです。同サービスのUDP経路を確立し、構成によって直接経路や中継を使います。確立できなければTCPベースの接続へ戻ります。社内PCへ直接mstscで接続する場合と同じ設定表にはできません。参照: RDP Shortpathの経路とフォールバック。

画面転送方式と数値の適用範囲

画面転送の概念図や古い資料を全構成へ一般化しません。動画・音声を別の仕組みで転送する構成もあります。Graphicsカウンターの資料には古い構成の説明もあるため、記載の数値を「すべてのRDPが最大30fps」という共通仕様へ読み替えません。機能・数値の適用先を確認して使います。参照: 画面転送とワークロード、Graphicsカウンター資料。

参考資料

Microsoft Learnの一次資料です。2026年9月17日に参照内容を確認しました。製品ごとの適用条件と、この記事で実施済みの実測ではないことを区別して読んでください。

Microsoft Learn, Analyze connection quality in Azure Virtual Desktop。RTTと、接続先での画面取得から手元での表示までの遅延の区別。診断機能自体はAzure Virtual Desktop向けです。
Microsoft Learn, Remote Desktop Protocol bandwidth requirements。画面内容、解像度、フレーム更新、圧縮、キャッシュと通信量の関係。
Microsoft Learn, Diagnose graphics performance issues in Remote Desktop。画面の入出力、間引き理由、エンコード時間の確認方法。古い構成の説明を含むため、数値上限をすべてのRDPへ一般化しません。
Microsoft Learn, Performance Tuning Remote Desktop Session Hosts。共有ホストの負荷、接続先からバックエンドへの通信、機器リダイレクトの影響。
Microsoft Learn, Threading model。WPFのUIスレッドとDispatcher、応答性を保つための処理の分離。
Microsoft Learn, mstsc。リモートデスクトップの幅・高さや複数モニターの指定。
Microsoft Learn, Supported RDP properties。デスクトップの解像度・動的解像度・smart sizingの区別。対応するクライアントと製品ごとの適用条件を確認します。
Microsoft Learn, ping。ICMP Echoによる応答の確認とオプション。
Microsoft Learn, Test-NetConnection。TCP接続確認と出力の意味。
Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts。User Input Delayの測定区間、対象OS、インスタンス、最大値の意味。
Microsoft Learn, query session。セッション情報と、他のセッションの照会に必要な権限。
Microsoft Learn, ADMX_TerminalServer Policy CSP。RDPが利用するTCP・UDPの選択とフォールバック。
Microsoft Learn, RDP Shortpath。Azure Virtual Desktop向けのUDP経路と、確立できない場合の動作。
Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop。描画とフレームエンコードを分けたGPU構成・検証。

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

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。

サービスを見るお問い合わせ

よくある質問

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

速度測定では数百Mbps出るのに、RDPの入力が遅いのはなぜですか？: 大きなデータを運ぶ速さと、操作に反応が返るまでの時間は別です。入力の送信、接続先アプリの処理、画面の圧縮、転送、手元での表示が関係します。また、速度測定の相手とRDPの接続先では通信経路も異なります。
文字は普通に打てるのに、スクロールだけカクつくのは回線の問題ですか？: 回線だけには絞れません。画面更新が増えたときに、接続先の描画・圧縮、通信、手元のデコード・表示のどこかが追いつかない可能性があります。リモート側の解像度やモニター数を一つずつ変えて比較し、必要なら描画関連のカウンターを調べます。
pingが速ければ、RDPの通信は正常ですか？: それだけでは判断できません。pingはICMPへの応答を測り、RDPの画面転送やアプリの処理は測りません。RD Gatewayなどを使う構成では経路も一致しないことがあります。応答がない場合も、ICMPの遮断とRDP自体の不通を区別してください。
User Input Delayは、キーを押して文字が出るまでの時間ですか？: 違います。接続先で入力がキューに入り、プロセスが取り出すまでの待ち時間を測るカウンターです。通信の往復、取り出した後のアプリ処理、画面の圧縮・デコード・表示までを含む体感遅延ではありません。
RDPが重いときはUDPを無効にすべきですか？: 一律には勧めません。まず実際の接続方式と経路、適用ポリシーを確認します。UDPが使えずTCPにフォールバックしている場合もあり、TCP限定への変更で常に速くなるわけではありません。管理者の許可の下で条件をそろえて比較し、不要な変更は戻します。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

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

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ブログ一覧に戻る