リモートワーク環境でAmazon WorkSpacesを使っていると、「昨日まで普通に使えていたのに今日は接続できない」「リモート先でマウスカーソルが見えない」「ログインはできるのにデスクトップが正常に立ち上がらない」といった、業務を止めるタイプのトラブルに遭遇することがある。
この記事では、実際に遭遇して解決に至った3つの代表的な症状について、原因の切り分け方と対処法を整理する。症状の表層だけを見て闇雲に再起動を繰り返すのではなく、どのレイヤーで問題が起きているのかを見極めることで、クライアント側で直せるものと管理者に依頼すべきものを判断できるようになる。
Amazon WorkSpacesの接続フロー
トラブルシューティングの前提として、WorkSpacesへの接続がどのレイヤーで成立しているかを把握しておくと切り分けが速くなる。クライアントアプリは大きく分けて「ネットワーク到達性の確認」「認証」「ストリーミングセッションの確立」「Windowsプロファイルのロード」という4段階を踏んでセッションを成立させている。
下図は接続フローと、本記事で扱う3つの症状がどの段階で発生するかを示したものだ。
「WorkSpaceは数秒で準備完了になります…」から変わらない

クライアントアプリに「WorkSpaceは数秒で準備完了になります…」というメッセージが表示されたまま、いつまで経っても画面が切り替わらない症状。これはストリーミングセッションの確立ができていないケースが大半を占める。
切り分けの手順
経験上、疑うべきは回線側であることが多い。実際に直面した事例では、朝スマートフォンのテザリングでは接続できなかったが、夜に自宅Wi-Fiで試したら問題なく繋がった、というパターンだった。
つまりWorkSpaces側ではなく、特定のネットワーク経路にだけ問題が出ていた形だ。
| 試行順 | 確認内容 | 判定できること |
|---|---|---|
| 1 | 別の回線で接続する | 別回線でOKなら元回線の問題 |
| 2 | 別端末のテザリングで接続 | 同一回線でもNGなら端末側の可能性 |
| 3 | 問題のある端末を再起動 | キャリア側セッションのリセットで解決することがある |
テザリング元のスマートフォン自体を再起動したら繋がるようになった、というケースも実際にあった。
これはキャリア網でのセッション状態やスマホ内のネットワークスタックがリセットされることで通信経路が正常化するためと考えられる。AWS側の障害を疑う前に、手元の環境を切り替えて再現性を確認するのが先だ。
「Amazon WorkSpaces」のウィンドウ内でカーソルが消える
WorkSpaces経由で接続したWindows上のChromeで、マウスカーソルが描画されなくなる症状。操作自体は効いているのだが見えないので、クリック位置が分からず作業にならない。
これはWorkSpaces固有の不具合というより、Chromeのハードウェアアクセラレーションとリモートデスクトップ系プロトコルの相性問題として広く知られている現象だ。対処法としては以下が有効なことが多い。
- Chromeの設定から「ハードウェア アクセラレーションが使用可能な場合は使用する」をオフにする
- Chromeを一度終了して再起動する
- それでも解決しない場合はWorkSpacesセッションを切断して再接続する
根本原因はGPU描画のリダイレクションにあるため、アクセラレーションを無効化すれば症状はほぼ収まる。常用するなら設定変更をプロファイルに固定しておくと再発を防げる。
WorkSpace でプロファイルが消えてログインできない
AWS WorkSpace でログインしてもプロファイルが読み込めない現象が発生しました。
ログインはできますが、次の警告が表示されます。

認証は通るものの「アカウントにサインインできません」という警告が出てデスクトップが正常に立ち上がらない症状。次のような文言が表示される。
この問題は、アカウントからサインアウトし、もう一度サインインすると解決できることがあります。今すぐサインアウトしない場合、作成するファイルや変更の内容はすべて失われます。
これはクライアント側では解決できないのが厄介な点だ。原因はWorkSpace側のユーザープロファイル本体が破損しているか、Active Directory上のプロファイルパスが参照できない状態になっていることが多く、インフラ管理者によるプロファイルの修復または再作成が必要になる。
管理者対応待ちの間の業務継続策
プロファイル修復には時間がかかるため、その間に業務を止めないための迂回策として、WorkSpacesから社内PCへリモートデスクトップ接続する方法がある。WorkSpaces自体は起動できる別アカウントで入り、そこからmstscで自席PCに繋ぐという二段構えだ。
Windowsアイコン右クリック
→ 「ファイル名を指定して実行」
→ "mstsc" を実行
→ コンピューター: 接続先PC名 (例: CSJxxxx)
→ ユーザー名: CSJ\PCログイン名
→ パスワード: PCログイン時のパスワード
mstscで起動するリモートデスクトップ接続ウィンドウでは、左下の「オプションの表示」から設定ファイル(.rdp)として名前を付けて保存できる。次回以降はそのファイルをダブルクリックするだけで接続情報が読み込まれるので、毎回入力する手間が省ける。マルチモニター環境で作業したい場合は、「画面」タブの「リモートセッションですべてのモニターを使用する」にチェックを入れておくと、接続先PCの画面を複数ディスプレイに展開できる。
切り分けの順序を身体に入れておく
3つの症状を並べてみると、トラブル対応は「クライアントで直せる層」「アプリ設定で直せる層」「管理者依頼が必要な層」の3階層で考えるとスムーズに進む。
| 症状 | 責任分界 | 対応時間の目安 |
|---|---|---|
| 接続画面で停止 | クライアント/ネットワーク | 数分〜数十分 |
| カーソル消失 | リモート側アプリ設定 | 1〜2分 |
| プロファイル破損 | 管理者(AD/WorkSpaces) | 半日〜1日 |
焦って管理者にエスカレーションする前に、まず自分の手元で回線と端末を切り替えて再現性を確認し、アプリケーション層の設定を見直す。この二段階を踏むだけで管理者のリソースを無駄に消費せずに済み、自力で解決できる範囲が広がる。トラブルが起きたときにエラー文言のスクリーンショットと発生時刻を残しておくと、エスカレーション時の初動も速くなるので、日常的な癖として身につけておきたい。