---
publishDate: 2026-07-06T08:31:00Z
lang: 'ja'
translationKey: 'rustdesk-connected-waiting-for-image'
draft: false
title: 'RustDeskの「Connected, waiting for image」を完全解決するガイド'
excerpt: '「Connected, waiting for image」は、リモート画面のキャプチャができていない状態を意味します。ヘッドレス構成、スリープ、コーデック、ドライバーなど、考えられるあらゆる原因とその対処法を解説します。'
image: '~/assets/images/blog/rustdesk-connected-waiting-for-image-og.webp'
category: 'トラブルシューティング'
tags: ['RustDesk', 'トラブルシューティング']
author: 'RustDesk Team'
slug: 'rustdesk-connected-waiting-for-image-ja'
faq:
  - question: 'なぜRustDeskは「Connected, waiting for image」と表示するのですか?'
    answer: 'セッション自体は正常に確立されていますが、リモートマシン側が送信する画面イメージを生成できていない状態です。最も多い原因は、キャプチャ対象となるアクティブなディスプレイが存在しないことです。モニターが接続されていないヘッドレスサーバー、スリープやロック状態になった画面、あるいはOSがRustDeskによる記録を許可していないディスプレイなどが該当します。キャプチャ元を修正すれば、画像は表示されるようになります。'
  - question: 'ヘッドレスコンピューターでRustDeskが「waiting for image」のままになる場合、どう解決すればよいですか?'
    answer: 'モニターが接続されていないマシンには、キャプチャすべきフレームバッファが存在しないため、RustDeskは何も送信できません。実際のモニターを接続する、GPUにディスプレイが接続されていると認識させる安価なHDMIダミープラグを挿す、あるいはLinuxではドキュメント化されたヘッドレス構成(github.com/rustdesk/rustdesk/wiki/Headless-Linux-Support)を利用してください。ディスプレイをスリープから復帰させる、またはスリープさせないようにするだけで、ほとんどのケースは解決します。'
  - question: '映像コーデックを変更すると黒画面は解決しますか?'
    answer: '多くの場合、解決します。リモートセッションのツールバーや設定画面から、VP8、VP9、AV1、またはハードウェアが対応していればH.264/H.265といったコーデックに切り替えられます。リモート側のハードウェアがエンコードできないコーデックを使用していると、画面が真っ黒になったりフリーズしたりします。VP9のようなソフトウェアコーデックにフォールバックすることで、たいていは画面が正常に表示されるようになります。'
  - question: 'あるPCでは画像が表示されるのに、別のPCでは表示されません。なぜですか?'
    answer: 'これは、うまくいかない側のマシンに固有の要因があることを示しています。ディスプレイがスリープしている、あるいは存在しない、macOSで画面収録の権限が付与されていない、GPUドライバーが古い、ハードウェアアクセラレーションの競合、ハードウェアが対応していないコーデックを使用している、などが考えられます。正常に動作しているマシンではなく、失敗しているマシンに対して、このガイドの原因別の対処法を順に試してください。'
  - question: '自己ホスティングしているサーバーが「waiting for image」の原因になることはありますか?'
    answer: '通常、このメッセージが表示される時点でセッションはすでに接続されているため、サーバー自体は正しく機能しています。ただし、パブリックリレーの過負荷やリレーポートのブロックによって、映像ストリームが停止することがあります。標準的なサーバー構成では、TCP 21115-21117とUDP 21116を許可してください。WebSocketクライアントを使用する場合のみ、TCP 21118-21119も許可します。より安定したスループットを求めるなら、リレーの自己ホスティングを検討してください。'

metadata:
  description: '「RustDesk connected, waiting for image」と表示される?黒画面の原因と対処法を解説:ヘッドレスディスプレイ、スリープ/ロック、映像コーデック、GPUドライバー、Wayland、ファイアウォールのポート設定まで。'
  keywords: 'RustDesk connected waiting for image, RustDesk 黒画面, RustDesk waiting for image 解決方法, RustDesk 画像が表示されない, RustDesk HDMIダミープラグ, RustDesk 映像コーデック, RustDesk ハードウェアアクセラレーション'
---

RustDeskで**「Connected, waiting for image」**と表示され、その後に黒い画面が出る場合、朗報なのは、難しい部分はすでにクリアできているということです。つまり、両端末が互いを見つけ出し、セッションはすでに確立されています。足りていないのは*画像*だけです。リモートマシン側の何かが、送信すべき画面イメージを生成できていないのです。このガイドでは、最もよくある原因からエッジケースまで、判明しているすべての原因と、それぞれの具体的な対処法を順に解説します。

## 結論から言うと

セッションは接続されていますが、キャプチャすべきフレームバッファが存在しません。リモートマシンに**モニターが接続されていない、ディスプレイがスリープ・ロック状態になっている、またはOSがRustDeskによる記録を許可していないディスプレイである**場合、映像ストリームにはエンコードする対象がありません。モニター、HDMIダミープラグ、適切な権限、対応コーデックなど、RustDeskが実際にキャプチャできる稼働中のディスプレイを用意すれば、画像は表示されるようになります。

## まず確認すべきこと:そもそもキャプチャする対象はあるか?

圧倒的に多く報告されている原因は**ヘッドレスマシン**です。モニターが接続されていない、またはディスプレイがスリープ状態のまま稼働しているサーバー、ミニPC、ワークステーションなどが該当します。アクティブなディスプレイが存在しない場合、GPUはフレームバッファを生成しないため、RustDeskは接続はできても送信するデータがありません。このパターンはRustDeskのIssueトラッカーで繰り返し報告されており、[対象機のモニターがオフのときに限って黒画面になるという報告](https://github.com/rustdesk/rustdesk/issues/9884)や、長期にわたる[「Connected, waiting for image」スレッド](https://github.com/rustdesk/rustdesk/issues/222)などが挙げられます。

キャプチャする対象を用意する方法は3つあります。

- **モニターを接続する** — 電源が入っており、スリープしていない状態を確認してください。
- **HDMI(またはDisplayPort)ダミープラグを使用する** — この安価なアダプターは、GPUにディスプレイが接続されていると認識させるため、RustDeskが取得できるフレームバッファを描画し続けます。ヘッドレスデスクトップやホームサーバーにおける標準的な対処法です。
- **Linuxではドキュメント化されたヘッドレス構成を利用する** — RustDeskはヘッドレスなLinux構成をサポートしていますが、通常のデスクトップセッションとは設定が異なります。詳しくは[Headless Linux Support wiki](https://github.com/rustdesk/rustdesk/wiki/Headless-Linux-Support)を参照してください。

モニターが*すでに*接続されている場合、次に疑うべきはスリープ状態に入っていることです。

## 原因別の対処法

| 原因                                 | 兆候                                           | 対処法                                                                                                                                                                   |
| ------------------------------------ | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| ヘッドレス / ディスプレイなし        | サーバーやミニPCで黒画面になる                 | モニターを接続する、HDMIダミープラグを追加する、またはLinuxのヘッドレス構成を利用する                                                                                    |
| 画面のスリープ / ロック              | 以前は動作していたが、アイドル後に黒画面になる | 画面をスリープから復帰させる。スリープ/スクリーンセーバーを無効化する。macOSでは設定でディスプレイのスリープを停止する                                                   |
| 権限不足(macOS)                      | 接続はするが、常に黒画面のまま                 | 「プライバシーとセキュリティ」で画面収録を許可する。ログイン画面用にヘルパーをインストールする                                                                           |
| コーデックの不一致                   | 画面が空白/フリーズする                        | コーデックを切り替える(VP8 / VP9 / AV1 / H.264 / H.265)。ソフトウェアコーデックにフォールバックする                                                                      |
| ハードウェアアクセラレーションの競合 | 特定のGPUで黒画面になる                        | セッションツールバーまたは設定でハードウェアコーデックをオフにする、あるいはコーデックを切り替える                                                                       |
| GPUドライバーが古い                  | ドライバー/OSの更新後に黒画面になる            | GPUドライバーを更新する(特にNVIDIA)                                                                                                                                      |
| Waylandセッション(Linux)             | 同意プロンプトが出ず、画面が空白               | PipeWire/ポータルのプロンプトを承認し、デスクトップポータルがインストールされていることを確認する。ディストリビューションがX11セッションを提供している場合はそちらも有効 |
| ネットワーク / リレーの停滞          | 「waiting for image」のまま止まる              | TCP 21115-21117とUDP 21116を許可する。WebSocketクライアントを使用する場合はTCP 21118-21119も追加する                                                                     |

### 画面のスリープ、ロック、スクリーンセーバー

以前は動作していたのに、マシンがアイドル状態になった後で黒画面になった場合、ディスプレイがスリープに入っています。

- **Windows:** リモートアクセスが必要な時間帯はディスプレイとマシンがスリープしないよう電源プランを設定し、スクリーンセーバーを無効化してください(またはセッション中にパスワードを要求しないよう設定します)。
- **macOS:** リモートアクセスが必要な時間帯はディスプレイがスリープしないようにします。**システム設定 → ディスプレイ**(またはロック画面/エネルギーの設定)で設定し、バッテリー駆動時はスリープの挙動が異なるため、Macは電源アダプターに接続したままにしてください。
- **Android:** 画面がオンになっていないと共有できないため、接続前にディスプレイをタップして起動させてください。画面がオフでスリープ中のAndroid端末にiOSから接続するケースは、[「waiting for image」の既知の事例](https://github.com/rustdesk/rustdesk/issues/11479)として報告されています。まず対象端末を起動させてください。

### macOSの権限設定

macOSは、明示的な同意がない限り、どのアプリにも画面収録を許可しません。Mac上でRustDeskが接続はするものの黒画面のままになる場合は、**システム設定 → プライバシーとセキュリティ → 画面収録**を開いてRustDeskを有効にし、アプリを再起動してください。特に*ログイン画面で*黒画面になる場合は、ユーザーがログインする前に実行されるRustDeskのサービス/ヘルパーがインストールされていないことを意味します。ログイン前のキャプチャに対応させるため、これをインストールしてください。

### 映像コーデックの不一致

RustDeskは複数の方式でストリームをエンコードできますが、デフォルトの設定が必ずしもリモート側のハードウェアに適しているとは限りません。セッションツールバー(または設定)でコーデックを切り替えてみてください——**VP8、VP9、AV1、またはハードウェアが対応していればH.264/H.265**——そして画像が表示されるか確認します。特定のGPUでハードウェアコーデックが空白の画像しか出力しない場合は、VP9のようなソフトウェアコーデックに戻すのが確実な対処法です。

### ハードウェアアクセラレーションとGPUドライバー

一部のGPU(最も報告が多いのはNVIDIA構成)は、RustDeskのハードウェアアクセラレーションによるキャプチャ/レンダリング処理と競合します。有効な対処法は2つあります。

- **ハードウェアコーデックをオフにする。** セッションツールバー(または設定)で**ハードウェアコーデックを使用**を無効にし、エンコード処理をソフトウェア方式にフォールバックさせます。これにより、多くの問題のあるGPUで黒画面が解消します。
- **GPUドライバーを更新する。** ドライバーやOSの更新後に発生し始めた黒画面は、最新のドライバーに更新することで解決するケースが多く、特にNVIDIA製ハードウェアで顕著です。

### LinuxとWayland

Linuxでは、**Waylandの画面キャプチャはPipeWireと`xdg-desktop-portal`を経由します**。初回はディスプレイを選択するための同意プロンプトが表示されますが——多くの場合その選択は記憶されるため、以降は再表示されません——アクティブなログインセッション内であれば動作します。これはWaylandのセキュリティ設計によるものであり、それ単体ではグリーター画面や完全にヘッドレスなマシンには対応しません(ただし、無人でのWaylandキャプチャは現在活発に開発が進められています。[PR #15420](https://github.com/rustdesk/rustdesk/pull/15420))。Waylandで画面が空白になる場合、通常はポータルの画面共有プロンプトを承認し、`xdg-desktop-portal`とPipeWireがインストールされて実行されていることを確認すれば解決します。ヘッドレスなマシンでは、ドキュメント化された[ヘッドレス構成](https://github.com/rustdesk/rustdesk/wiki/Headless-Linux-Support)を利用してください。ディストリビューションがまだX11/Xorgセッションを提供している場合は、それにログインすることでもポータル経由の処理を回避できます——ただし、多くのディストリビューションがWayland専用へと移行しつつある中では、ポータル/PipeWire側の問題を解決しておくほうが、より将来性のあるアプローチと言えます。

### ネットワークとリレー

このメッセージには「connected」という単語が含まれているため、セッション自体はすでに確立されていることがほとんどです。ただし、リレーが過負荷状態にあったり、リレーポートがブロックされていたりすると、*映像*だけが停止することがあります。標準的なサーバー構成では、**TCP 21115-21117とUDP 21116**が両端末間で疎通していることを確認してください。**WebSocketクライアントを使用する場合のみ、TCP 21118-21119**を開放します。パブリックのデモサーバーは共有リソースであり、スループットは保証されていません。RustDeskを日常的に利用しているのであれば、自分自身のリレーをセルフホスティングすることで、はるかに安定した動作が得られます。セッション自体が切断される、またはそもそも確立されない場合は別の問題です。[RustDesk Server Pro のよくある質問](https://rustdesk.com/docs/ja/self-host/rustdesk-server-pro/faq/)を参照してください。

## 常に最新の状態を保つ

古いビルドには、古いキャプチャ関連のバグがそのまま残っています。操作する側とされる側の**両方**のクライアントを最新リリースに更新し、セルフホストしている場合はサーバーも更新してください。両端末を更新するだけで解消する黒画面の報告も少なくありません。

## オープンソースならではの強み

このチェックリストを試しても黒画面が解決しない場合でも、RustDeskにはクローズドソース製品にはない強みがあります。それは、AGPLライセンスの下で公開されている実際のキャプチャコードです。あなた自身(または委託先のエンジニア)が、お使いのプラットフォームでキャプチャがどのように動作しているかを直接コードで確認し、問題を再現したうえで、ベンダーのサポート対応を待つことなく、公開リポジトリに対して正確な報告を提出できます。

## サーバーを自分で管理すれば、変数はもっと少なくなる

[自分自身のリレーとIDサーバーを運用](/ja/blog/why-self-host-remote-desktop-software-ja)すれば、共有のパブリックインフラという要素そのものがなくなります。キャプチャの問題を追いかけているときに不確定要素が一つ減るだけでなく、調整可能な部分をすべて自分でコントロールできるようになります。これは、データを自社で保持できることに加えた、地味ながら確かなメリットです。
