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

速度測定では数百Mbps出るのに、リモートデスクトップでは文字が少し遅れて現れる。写真の多いページをスクロールすると、さらに画面が引っかかる。

この違和感を解く鍵は、「たくさんのデータを運べること」と「操作への返事が早いこと」は別だという点です。さらに、返事として届く画面は、接続先のPCで作り、手元のPCで表示しています。回線だけで完結する仕事ではありません。¹

同じリモート画面で「文字を打つ」「スクロールする」「業務アプリで検索する」の順に、何が変わるかを追ってみましょう。1〜4章が仕組みの説明、5章以降が実際に調べるための調査編です。

1. 回線を速くしても、「返事待ち」が短くなるとは限らない

リモートのメモ帳に、一文字入力するとします。見えているのは目の前の画面ですが、メモ帳が動いているのは接続先のPCです。手元の操作を向こうへ送り、向こうで変わった画面の情報をこちらへ戻して、文字が現れます。

では、速度測定で出る「500Mbps」は、この往復の何を表しているのでしょうか。

これは、1秒間にどれだけのデータを運べるかという数字です。ダウンロードするファイルが大きいときには、この能力が効きます。一方、一文字打ったときに気になるのは、押してから結果が戻るまでの時間です。道路の車線を増やすことと、目的地までの距離を短くすることの違いに似ています。¹

説明用に、操作が接続先へ届くまで50ミリ秒、結果の画面の情報が戻るまで50ミリ秒かかると仮定します。この場合、通信に使う時間だけで合計100ミリ秒、つまり0.1秒です。ここでは両端のPCで処理する時間をいったん除いています。

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

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

このネットワークを行って戻る時間を往復時間（RTT）と呼びます。回線を変えて運べる量が増えても、往復時間が同じままなら、図1の返事待ちは残ります。¹

だから、ダウンロードは速いのに、文字入力はワンテンポ遅れることがあります。 次は、同じ接続で文字入力には困らないのに、スクロールすると重くなる場合を考えます。

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

2. スクロールすると、画面を送る仕事が増える

メモ帳に一文字を足したとき、見た目が変わるのは画面の小さな部分です。ところが、写真の並んだページをスクロールすると、広い範囲の表示が次々に変わります。

RDPは、毎回画面全体を無圧縮で送るのではなく、変更した部分を送り、内容に合った圧縮やキャッシュを使って通信量を抑えています。一文字を足す場面と、写真が動き続ける場面では、更新して送る仕事の量が違うのです。²

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

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

そのため、静止した文書を読んでいるときは軽くても、スクロールを始めると画面転送に余裕がなくなることがあります。リモート側の解像度を高くしたり、モニターを増やしたりすると、画面を作って送る対象も大きくなります。²

ここでようやく、解像度を下げて比較する意味が分かります。これは「RDPを速くするおまじない」ではなく、画面を作って送る仕事を減らすと、動きが戻るかを見る実験です。詳しい試し方は5章にまとめます。

文字入力は平気でもスクロールだけ重いのは、同じ回線で、より多くの画面更新を扱っているからかもしれません。 では、回線にはまだ余裕があるのに、画面が追いつかない場合はどうでしょうか。

3. 回線が空いていても、画面を作るPCが待たせることがある

画面は、送る前と受け取った後にも処理がある

写真のページをスクロールしたとき、接続先のPCは表示を更新し、画面の情報を送信しやすい形へ変換・圧縮します。これがエンコードです。手元のPCは、届いた情報を表示できる形に戻します。こちらをデコードと呼びます。¹

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

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

たとえば、接続先の画面の圧縮に時間がかかっているとします。回線が空いていても、送る情報の準備が終わるまで待ちます。逆に、情報は届いていても、手元のPCがデコードや表示に追いつかなければ、画面の更新は遅れます。³

「会社のPCは高性能だから、手元は何でもよい」と考えがちですが、手元のPCにも受け取った画面を表示する仕事が残っています。回線に余裕があることと、その両端の処理に余裕があることは別なのです。

一つのアプリだけ止まるなら、そのアプリの返事を待っていることもある

今度は、同じリモート画面で業務アプリの「検索」を押したら、数秒止まる場面を考えてみます。その間も、隣で開いたメモ帳には普通に文字を入力できるとします。

この場合には、業務アプリが何を待っているかを見たくなります。接続先のアプリが別のデータベースへ検索を依頼していて、その返事に時間がかかっているのかもしれません。共有フォルダーからファイルを読む処理でも、同じように待ちが生じます。⁴

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

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

また、アプリの画面や入力を担当する処理が長い仕事を抱えると、次の入力や画面更新まで手が回らなくなります。たとえばWPFのUIスレッドが長時間占有されると、このような応答の遅れが起こります。CPU全体の使用率だけを見ていても、画面を担当する処理の待ちは見落とせます。⁵

RDPの画面上で待っているからといって、待たせているのがRDPとは限りません。 「メモ帳は動くが検索だけ止まる」という違いは、通信設定を変える前にも見つけられる手がかりです。

4. ここまでのまとめ：回線速度は、反応の速さの一部分

最初の「回線は速いのに、なぜ重いのか」へ戻りましょう。

文字を打つ場面では、操作を送って結果を受け取るまでの返事待ちがありました。スクロールする場面では、更新して送る画面の量が増えました。そして、その画面を作るアプリや、両端のPCの画面処理にも時間がかかります。

速度測定の大きな数字だけでは、この三つが順調かどうかまでは分かりません。しかも、速度測定の相手と、VPNやゲートウェイの先にあるRDPの接続先では、通る経路も違います。画面を送り出す接続先側の上りや、途中の混雑も関わります。¹⁴

RDPの快適さは、「どれだけ運べるか」だけでなく、「操作の結果が、どれだけ早く見えるか」で決まります。 仕組みの説明はここまでです。実際に遅さを調べるときは、以下の調査編で、自分の症状に合う比較を選んでください。

5. 調査編：まず、同じ操作を一条件ずつ比べる

調査例はWindowsの「リモート デスクトップ接続」と、Windows 11・Windows Serverの接続先を想定しています。コマンド例はWindows PowerShell 5.1向けです。会社の端末では管理者の許可された範囲で比較し、作業を保存してから設定変更・再接続を行ってください。

先ほどの三つの場面を入口に、比較を選びます。表は原因の断定ではなく、調査の出発点です。

「ログイン画面が出るまで長い」「認証だけで止まる」場合は、まず接続確立や認証の記録を調べます。ここで説明してきた、接続後の入力やスクロールとは調査の入口が異なります。

別のアプリでも、同じように遅れるか

問題のアプリとメモ帳で、同じ程度の文字を入力します。まず同じリモートセッション内で比べると、接続先や回線を変えずに、アプリによる違いを見られます。接続先では対象アプリのCPU・メモリ・ディスクを、手元ではRDPクライアントの負荷をタスク マネージャーで確認します。⁴

別端末や別の許可された経路で比べるときも、同じ操作を繰り返し、戻した結果まで記録します。複数ユーザーが使うホストでは、自分のセッション・プロセスを確認してください。

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

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

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

スクロールが重いときは、リモート側の解像度を下げる

まずモニター数か解像度のどちらか一方を変え、同じページをスクロールします。Windowsのmstscでは、接続前の「画面」設定や幅・高さの指定で比較できます。手元のウィンドウを縮めるだけでなく、接続先のデスクトップの大きさが実際に変わったかを確認してください。大きな画面を縮小表示しているだけのこともあります。⁶⁷

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

不要な機器のリダイレクトも一つずつ比較できます。業務に必要な音声・入力機器を一括で止めたり、会社のバックアップやセキュリティ処理を勝手に停止したりする手順ではありません。

6. 調査編：待っている場所を数字で確かめる

5章の比較を計測で確かめます。文字入力なら通信と入力待ち、スクロールなら画面処理の数字を見ます。

手元から：通信の往復やTCP接続を調べる

次は手元のWindows端末での例です。社内LANや許可されたVPN経由でRDPホストへ直接接続し、接続先が標準のTCP 3389を使う構成を想定しています。RD GatewayやAzure Virtual Desktop経由では確認先や経路が異なります。ポートの公開やファイアウォールの変更は行いません。

$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

pingはICMPへの応答時間を調べます。遅い時間帯に値が大きく揺れるなら記録します。ただし、ICMPが遮断されて応答しない場合もあります。反対に、小さい値が並んでも、RDPの画面転送やアプリ処理まで調べたことにはなりません。⁸

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

20回のpingは短い観察です。断続的な不調は、症状の時刻と接続情報を照合します。Azure Virtual Desktopでは接続ごとのRTTや帯域の推定値も利用できますが、平均値だけで短い停止を否定しないようにします。¹

接続先で：アプリが入力を取り出すまでの待ちを調べる

接続先のリモートセッション内でperfmon.exeを開き、利用できる環境ではUser Input Delay per ProcessまたはUser Input Delay per Sessionを追加します。対象セッション・プロセスを選ぶと、入力がキューに入り、アプリが取り出すまでの待ちを観察できます。¹⁰

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

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

値は測定区間内の最大の待ち時間です。Windows 10 バージョン1809以降・Windows Server 2019以降に対応し、これらの対象では有効化のレジストリ追加は不要です。最初は既定の1秒間隔で観察します。表示名・利用可能なカウンター・必要な権限は環境に合わせて確認してください。¹⁰

プロセス別の標準のインスタンス名はSessionID:ProcessID <Process Image>です。同じセッションのPowerShellで、時刻とセッションIDを控えます。¹⁰¹¹

Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
(Get-Process -Id $PID).SessionId
query.exe session

他の利用者のセッションを表示するには追加の権限が必要な場合があります。必要に応じて管理者の記録と照合し、共有するログから業務上不要なユーザー名や接続先情報を除きます。¹¹

この値が低くても、アプリが入力を取り出した後の処理や、結果の画面が戻るまでの遅れは残ります。1章の往復時間とも、キーを押して文字が現れるまでの体感時間とも、測る区間が違います。

接続先で：画面更新を送り切れているか調べる

スクロール時のカクつきには、利用可能なRemoteFX Graphicsカウンターを使います。query sessionやqwinstaで対象セッション名を確認し、対応するインスタンスを選びます。カウンターの計測場所や利用可否は、OS・ホスト構成・権限によって確認が必要です。³

画面更新がある操作中に、Input Frames/SecondとOutput Frames/Secondを比べます。出力が入力より少なければ、途中で画面が間引かれています。Frames Skipped/Secondの接続先・ネットワーク・クライアントのリソース不足別の値を見ると、調査先を絞る手がかりになります。³

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

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

入力側からフレーム数が少ない場合は、アプリがそもそも頻繁に画面を更新していないこともあります。静止画面の低いフレーム数は異常ではありません。更新があるのに遅い場合はAverage Encoding Timeも見て、接続先の圧縮に時間がかかっていないか確かめます。³

計測資料を読むときの補足。 1章の図は通常の画面転送を理解するための概念図で、キーごとに独立した一往復のパケットを送るという意味ではありません。動画・音声を別の仕組みで転送する構成もあります。Azure Virtual Desktopの接続品質ログや、古い構成を含むGraphicsカウンターの資料は、機能の適用先を確認して使います。資料の数値を「すべてのRDPが最大30fps」などの共通仕様には読み替えません。²¹³

7. 調査編：UDP・GPUの設定は、分かったことに合わせて選ぶ

通信が疑わしいなら、まず実際の経路と方式を確認する

RDPは構成と通信条件に応じてTCPやUDPを使います。「Select RDP transport protocols」のポリシーでは、UDPまたはTCPを使う設定と、TCPだけを使う設定を選べます。UDP接続が成立しなければTCPを使う動作もあるため、接続できたことだけでは方式は分かりません。クライアントの接続情報、製品の診断ログ、管理者の通信記録で確認します。¹²

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

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

Azure Virtual DesktopのRDP Shortpathは、そのサービスのUDP経路を確立する仕組みです。直接経路や中継の使われ方も含め、社内PCへ直接mstscで接続する場合と同じ設定表にはできません。Shortpathを確立できない場合はTCPベースの接続へ戻ります。¹³

「UDPを切れば速くなる」と一律に変更せず、利用中の方式・ポリシー・VPNやゲートウェイの条件をそろえて比較します。ファイアウォールや認証を無効にしたり、RDPポートをインターネットへ直接公開したりする対処は行いません。

画面の処理が疑わしいなら、GPUがその処理に使われているかを見る

GPUがあっても、接続先アプリの描画、RDPのエンコード、手元のデコードがすべてGPUを使うとは限りません。MicrosoftのGPU構成資料でも、リモートセッションの描画とフレームのハードウェアエンコードは別に設定・確認します。対応OS、ドライバー、ポリシー、クライアントの条件を調べます。¹⁴

6章で圧縮時間が長いと分かったなら、その段階でエンコードへのGPU利用を確認します。入力キューで待っているアプリへエンコード設定を変えても、狙う場所が違います。文字を読みやすくしたい仕事と動画を滑らかに見たい仕事では、画質・通信量・処理負荷の選び方も変わります。¹⁴²

業務アプリの開発者は、入力イベントを受けた時刻、DB・ファイル処理の開始と終了、UIへの反映を分けて記録すると、アプリ内の待ちを追えます。重い処理をUIスレッドに居座らせない設計も重要です。なお、接続先の処理完了ログは、手元の画面の表示完了を記録したものではありません。⁵

8. 調査を引き継ぐときに残したいメモ

「メモ帳は普通に打てるが、写真をスクロールすると止まる」のように、遅い操作を伝えます。試した条件と結果も残しましょう。

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

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

関連記事

• Windowsのセッション分離をどう理解するか
• Windowsのディスク100%を安全に切り分ける
• 「残り1秒」が終わらないのはなぜ？

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

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

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

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

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

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

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

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

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

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

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

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

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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