Windows 11 Proを別の端末から操作するには、接続先PCでリモートデスクトップを有効にし、接続を許可するユーザーとネットワーク経路を確認します。設定スイッチをオンにするだけではなく、エディション、Windowsファイアウォール、Network Level Authentication（NLA）、アカウントのパスワードまでそろって初めて安全に接続できます。本記事では、家庭内または社内の信頼できるネットワークを前提に、設定、確認、トラブルの切り分け、元に戻す方法まで順に説明します。TCP 3389をインターネットへ直接公開する方法は扱いません。
接続先にできるWindows 11のエディションを確認する
最初に確認するのは、操作される側、つまり接続先PCのエディションです。Microsoftの現行資料では、受信するRDPホストになれるのはWindows Professional、Enterprise、EducationおよびWindows Serverです。Windows 11 Homeは、ほかのPCへ接続するクライアントとしては使えますが、標準機能のRDPで接続される側にはできません。Homeで設定画面が見つからない場合、故障ではなく製品仕様です。
「設定」から「システム」→「バージョン情報」を開き、「Windowsの仕様」にあるエディションを確認します。本記事の手順はWindows 11 Proを主対象にします。会社のPCではEnterpriseやEducationでも同様の画面がありますが、組織のポリシーで設定変更が禁止されていることがあります。その場合は回避せず、管理者へ依頼してください。
- 接続先PC：Windows 11 Pro、Enterprise、Educationのいずれか
- 接続元端末：Windows Homeを含む各エディションを利用可能
- 接続先PC：電源が入り、ネットワークへ接続されていること
- 利用者：接続を許可されたアカウントと有効なパスワードを持つこと
有効化する前にネットワークとアカウントを整える
RDPを有効にすると、接続先PCはネットワーク上のほかの機器から接続要求を受けられる状態になります。まず自宅のプライベートネットワーク、または管理された社内ドメインネットワークであることを確認します。ホテル、空港、共有Wi-Fiなど、不特定多数が参加するネットワークで受信を有効にするべきではありません。Microsoftも、信頼できるネットワークに限定して有効化するよう案内しています。
接続に使うアカウントには、推測されにくい固有のパスワードを設定します。PINは端末でのサインイン手段であり、従来のRDP資格情報としてそのまま使えるとは限りません。Microsoftアカウント、ローカルアカウント、ドメインアカウントのどれを使うかを先に決め、ユーザー名の形式も控えます。共有アカウントを増やすのではなく、実際に利用する本人だけを許可するのが安全です。
設定変更前には、現在の「リモートデスクトップ」がオフかオンか、許可ユーザーの一覧、ネットワークプロファイルをメモしておきます。元の状態を記録しておけば、接続できなかったときに無関係な設定まで変更せずに戻せます。
Windows 11 Proでリモートデスクトップを有効にする
- 接続先PCで「スタート」→「設定」を開きます。
- 「システム」→「リモート デスクトップ」を選択します。
- 「リモート デスクトップ」をオンにします。
- 確認ダイアログの内容を読み、「確認」を選択します。
- 画面に表示されるPC名を控えます。同じネットワーク内では、接続元の「リモート デスクトップ接続」にこの名前を入力できます。
この操作には管理者権限が必要です。有効化すると、Administratorsグループのメンバーと、明示的に追加したユーザーが接続対象になります。同時にWindowsはリモートデスクトップ用のファイアウォール規則を扱います。接続できないからといってWindowsファイアウォール全体を停止する必要はありません。
同じ画面の詳細設定で、NLAを要求する設定を確認します。NLAはリモートセッションを作る前に利用者を認証し、未認証の接続による負荷や攻撃面を減らします。古いクライアントとの互換性問題を調べる場面を除き、通常は有効のままにします。問題調査のため一時的に変更する場合も、変更前の状態と時刻を記録し、検証後に必ず戻します。
標準ユーザーへ必要最小限の接続権限を付ける
管理者ではないユーザーに接続を許可する場合は、「リモート デスクトップ ユーザー」または「このPCにリモートでアクセスできるユーザーを選択する」を開き、「追加」から対象ユーザーを指定します。日常利用者をAdministratorsへ昇格させる必要はありません。Remote Desktop Users相当の権限に限定すれば、RDPへのサインインを許可しつつ、端末全体の管理権限を不用意に渡さずに済みます。
入力するユーザー名は環境で異なります。ローカルアカウントなら「PC名\ユーザー名」、ドメインなら「ドメイン名\ユーザー名」または組織指定の形式を使います。名前が解決できない場合は、ユーザーが実在するか、無効化されていないか、パスワードが設定されているかを先に確認します。大きなグループを丸ごと追加するより、業務上必要な小さなグループまたは個人を選ぶ方が監査しやすくなります。
追加後は一覧を閉じて開き直し、対象ユーザーが残っていることを確認します。許可を追加した事実だけで接続成功と判断せず、次のネットワーク確認と実接続テストまで行います。
ファイアウォールと到達性を安全に確認する
Windowsファイアウォールは受信通信を既定でブロックし、必要な通信だけを許可規則で通します。RDP有効化後もファイアウォール自体はオンのままにします。管理されたPCでは、ローカル規則と組織のポリシーが統合されない構成もあるため、画面上で有効にしたのに通信できない場合があります。規則を新規作成する前に、管理ポリシー、適用中のネットワークプロファイル、既存の「リモート デスクトップ」受信規則を確認してください。
同じ信頼済みLANにある接続元PCでは、PowerShellから次の読み取り専用テストを実行できます。「PC名」は接続先の実名に置き換えます。
Test-NetConnection -ComputerName PC名 -CommonTCPPort RDPTcpTestSucceededがTrueなら、接続元から標準RDPポートまでのTCP到達性は確認できています。ただし、ユーザー権限や資格情報まで正しいことを保証する結果ではありません。Falseなら、PC名の名前解決、接続先の電源、同一ネットワークまたはVPNへの参加、ファイアウォール規則、ルーターによる端末間分離の順に確認します。テストのためにファイアウォール全体を無効化しないでください。
ファイアウォール規則を絞る必要がある環境では、受信元をローカルサブネットや管理用サブネットに限定する方針が適しています。Microsoftも、受信規則は用途に必要な範囲へ具体的に制限し、既定のブロック動作を維持することを推奨しています。会社のPCでは管理者の設計を優先します。
別のPCから接続して設定を検証する
- 接続元PCでスタートメニューを開き、「リモート デスクトップ接続」を起動します。
- 接続先のPC名を入力し、「接続」を選択します。
- 許可したアカウントの資格情報を入力します。
- 証明書名の警告が出た場合は、表示された接続先名が意図したPCと一致するか確認します。確認できない警告を無条件に保存しないでください。
- サインイン後、ユーザー名、接続先PC名、必要なアプリだけを確認します。
- 作業を保存し、サインアウトするか、継続中の作業を残す必要がある場合だけ切断します。
接続テストでは、最初から管理者アカウントだけを使うのではなく、実際に利用する標準ユーザーでも確認します。「到達できるがサインインできない」なら権限または資格情報、「PC名で到達しないがIPアドレスでは到達する」なら名前解決、「どちらでも到達しない」なら電源、経路、ファイアウォールを疑うと切り分けやすくなります。
外部ネットワークからはVPNまたはRD Gatewayを使う
自宅や会社の外から接続するために、ルーターでTCP 3389をインターネットへ直接転送する構成は推奨しません。公開範囲が広がり、総当たりや脆弱性探索の対象になります。まず組織が提供するVPNへ接続し、内部ネットワーク上のPCとしてRDPする構成を選びます。Windows Serverを含む組織環境では、RD Gatewayも選択肢です。
RD Gatewayは、外部端末とゲートウェイの間に暗号化されたトンネルを作り、利用者認証と接続先リソースの認可を一か所で制御します。運用には正しく信頼された証明書、アクセス許可ポリシー、更新、監視が必要です。個人PCで場当たり的に構築するのではなく、ネットワーク管理者が設計します。NLA、強い資格情報、最小権限は、VPNやゲートウェイを使う場合も省略しません。
接続できないときの確認順序
- 接続先がHomeではなく、RDPホスト対応エディションか。
- 接続先の電源が入り、スリープしておらず、ネットワークへ参加しているか。
- 「リモート デスクトップ」がオンのままか。
- 接続ユーザーがAdministratorsまたは許可ユーザー一覧に含まれるか。
- ユーザー名の形式とパスワードが正しいか。
- NLAに対応したクライアントを使っているか。
- 接続元から名前解決とRDPのTCP到達性があるか。
- Windowsファイアウォールや組織ポリシーが対象ネットワークで許可しているか。
この順序なら、接続不能のたびに受信規則を追加したり、セキュリティ機能を止めたりせずに原因を狭められます。イベントログや組織ポリシーの確認が必要な段階では、時刻、接続元、接続先、表示されたエラーを記録して管理者へ渡してください。
不要になった設定を安全に元へ戻す
検証用に追加したユーザーは許可一覧から削除し、RDP自体が不要なら「設定」→「システム」→「リモート デスクトップ」をオフにします。接続中の利用者がいないことと、未保存データがないことを確認してから行います。既定のファイアウォール規則を手作業で削除するより、機能のスイッチを元の状態へ戻す方が再現性があります。
一時的にNLAやファイアウォール規則を変更した場合は、記録した元の値へ戻し、再起動後も意図した状態か確認します。会社のポリシーで配布された規則は削除しません。最後に別端末から接続できなくなったことを確認すれば、受信を閉じた検証まで完了です。
コメント