何が起きているか
Enter-PSSession、Invoke-Command、またはWinRMベースのツールを実行すると、次のエラーが発生します：
WSManFault Message: The client cannot connect to the destination specified in the request.
Verify that the service on the destination is running and is accepting requests.
WS-Managementスタックはこれをキャッチオール（汎用エラー）としてスローします。クライアントはリクエストを送信しましたが、応答が返ってきませんでした。原因は4つ考えられます：リモートのWinRMサービスが起動していない、ファイアウォールがポート5985でパケットをドロップしている、クライアントがリモートホストを信頼していない、または認証に失敗している。それぞれ対処法が異なるため、まずどの層が問題かを特定してください。
クイック診断チェックリスト
何かを変更する前に、以下の3つのチェックを実行してください。どの層で問題が発生しているかを正確に把握できます。
# 1. リモートマシンに到達できるか？
Test-Connection -ComputerName REMOTE_HOST -Count 2
# 2. ポート5985（WinRM HTTP）は開いているか？
Test-NetConnection -ComputerName REMOTE_HOST -Port 5985
# 3. WinRMはローカルで何と言っているか？
winrm id -r:REMOTE_HOST
Test-NetConnectionがTcpTestSucceeded: Falseを返す場合、ファイアウォールまたはWinRMリスナーが原因です。TrueなのにWinRMが失敗する場合は、TrustedHostsまたは認証の問題です。ネットワークは正常で、WinRM層に問題があります。
修正1 — リモートマシンでWinRMを有効化して起動する
WinRMはほとんどのWindowsワークステーションで無効になっています。これがこのエラーの最も一般的な原因です。リモートマシンへのコンソール、RDP、またはGPOアクセスがある場合は、ここから始めてください。
# リモートマシンで実行（管理者権限のPowerShell）
Enable-PSRemoting -Force
# サービスが起動しているか確認
Get-Service WinRM
# リスナーがアクティブか確認
winrm enumerate winrm/config/listener
Enable-PSRemotingは3つのことを同時に行います：WinRMサービスの起動、ポート5985でのHTTPリスナーの作成、そして受信ファイアウォールルールの追加です。ネットワークプロファイルが「パブリック」に設定されているマシンでは実行を拒否される場合があります。その場合は-SkipNetworkProfileCheckを追加して強制実行してください：
Enable-PSRemoting -Force -SkipNetworkProfileCheck
修正2 — リモートマシンのファイアウォールを開く
サービスが起動していてリスナーがアクティブでも、まだブロックされる場合があります。明示的な許可ルールがない限り、Windowsファイアウォールはポート5985への受信トラフィックをドロップします。手動でルールを追加してください：
# リモートマシンで実行
# WinRM HTTP（5985）を許可
New-NetFirewallRule -DisplayName "WinRM HTTP" `
-Direction Inbound -Protocol TCP -LocalPort 5985 `
-Action Allow
# HTTPS（5986）を使用する場合
New-NetFirewallRule -DisplayName "WinRM HTTPS" `
-Direction Inbound -Protocol TCP -LocalPort 5986 `
-Action Allow
GPO管理のファイアウォールはより複雑です。gpresult /h gpo.htmlで適用されているポリシーを確認し、HTMLレポートを開いて「Windows Remote Management」を検索してください。GPOがポート5985をブロックしている場合は、ポリシーレベルで修正してください。ローカルルールはGPOを上書きできません。
修正3 — クライアントのTrustedHostsにリモートホストを追加する
ドメイン外（ワークグループ、クロスドメイン、またはIPアドレスでの接続）では、リモートマシンがTrustedHostsに登録されていない限り、WinRMは認証を試みません。資格情報が送信される前に、ハンドシェイクが静かに失敗します。
# クライアントマシンで実行（管理者権限のPowerShell）
# 特定のホストを追加
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "REMOTE_HOST" -Force
# 複数のホストを追加（カンマ区切り）
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "host1,host2,192.168.1.50" -Force
# すべてを信頼する（ラボ環境のみ — 本番環境では絶対に使用しない）
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
# 確認
Get-Item WSMan:\localhost\Client\TrustedHosts
TrustedHostsを変更した後は、クライアントのWinRMサービスを再起動してください。サービスが再読み込みされるまで設定が有効になりません：
Restart-Service WinRM
修正4 — 資格情報を明示的に指定する
Kerberosはドメイン内でのみ機能します。クロスドメインおよびワークグループ接続では明示的な資格情報が必要です。Get-Credentialで渡してください：
$cred = Get-Credential # ユーザー名/パスワードの入力を求めます
# 明示的な資格情報でテスト
Enter-PSSession -ComputerName REMOTE_HOST -Credential $cred
# Invoke-Commandの場合
Invoke-Command -ComputerName REMOTE_HOST -Credential $cred -ScriptBlock {
hostname
whoami
}
ワークグループマシンでは、ユーザー名の前にマシン名を付けてください：MACHINENAME\Administrator。Administratorだけを使用すると失敗することが多いです。ワークグループには存在しないドメイン検索がデフォルトで実行されるためです。
修正5 — WinRMリスナーを確認して再作成する
リスナーの破損や設定ミスはまれですが、特にWindowsアップデート後やwinrm quickconfigの失敗後に発生することがあります。既存のリスナーを削除してゼロから再作成してください：
# リモートマシンで実行
# 現在のリスナーを一覧表示
winrm enumerate winrm/config/listener
# すべてのリスナーを削除
winrm delete winrm/config/listener?Address=*+Transport=HTTP
# デフォルトのHTTPリスナーを再作成
winrm create winrm/config/listener?Address=*+Transport=HTTP
# またはクイック設定ショートカットを使用
winrm quickconfig -q
修正6 — WinRM MaxEnvelopeSizekbを増加させる（大きなペイロードの場合）
hostnameなどの単純なコマンドは動作するのに、大きなオブジェクトを返すと失敗する場合があります？デフォルトのエンベロープサイズは500KBで、複雑な処理には小さすぎます。8MBに引き上げてください：
# リモートマシンで実行
Set-Item WSMan:\localhost\MaxEnvelopeSizekb -Value 8192
修正を確認する
# クライアントマシンから実行
# 1. 接続をテスト
Test-NetConnection -ComputerName REMOTE_HOST -Port 5985
# 2. WinRMを直接テスト
Test-WSMan -ComputerName REMOTE_HOST
# 3. インタラクティブセッションを開く
Enter-PSSession -ComputerName REMOTE_HOST
# 4. リモートコマンドを実行
Invoke-Command -ComputerName REMOTE_HOST -ScriptBlock { hostname; $PSVersionTable.PSVersion }
成功したTest-WSManの出力は次のようになります：
wsmid : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor : Microsoft Corporation
ProductVersion : OS: 0.0.0 SP: 0.0 Stack: 3.0
Enter-PSSessionで[REMOTE_HOST]: PS C:\Users\...>のプロンプトが表示されれば、接続成功です。exitを実行してセッションを正常に終了してください。
エラーの詳細別トラブルシューティング
- 「WinRM cannot complete the operation」— ポート5985/5986を確認：ファイアウォールがブロックしています。修正2へ進んでください。
- 「The WinRM client cannot process the request」— TrustedHostsに言及：修正3へ進んでください。
- 「Access is denied」：資格情報が間違っているか、権限が不足しています。修正4へ進んでください。
- 「The server certificate on the destination computer has the following errors」：HTTPSリスナーの証明書が無効または自己署名です。証明書を修正するか、内部ネットワークではHTTPに切り替えてください。
- 「Connecting to remote server failed」— GPOプッシュ後：まずリモートマシンで
gpupdate /forceを実行してから、再試行してください。
ドメイン環境 — ほとんどの手順をスキップ可能
両方のマシンが同じドメインにある場合、リモートでEnable-PSRemotingを実行した後、WinRMは通常そのまま動作します。TrustedHostsは完全にスキップできます。Kerberosがホストの信頼を自動的に処理するためです。それでも問題が発生するとすれば、リモート側のファイアウォールルールが不足している場合です。その場合は修正2で対処してください。
覚えておくべきこと
1つの曖昧なエラーに対して、4つの異なる根本原因があります：サービス停止、ファイアウォールブロック、信頼されていないホスト、資格情報の誤り。推測せず、まずTest-NetConnection -ComputerName REMOTE_HOST -Port 5985を実行してください。TcpTestSucceeded: Trueはネットワークが正常であることを意味します。WinRMの設定に移ってください。Falseの場合はファイアウォールの修正に集中してください。このチェック1つでトラブルシューティングの時間が半分になります。