Windows 11でVPNが繋がらない？エラーコード別の解決法とAlways On VPN導入ガイド

はじめに：VPN接続トラブルはヘルプデスクの定番チケット

リモートワークが当たり前になった2026年の企業環境で、「VPNがつながらない」というヘルプデスクチケット、相変わらず多いですよね。Gartnerの2025年レポートによると、リモートアクセス関連のチケットは全体の約18%を占めていて、平均解決時間は35分とのこと。しかも、そのうち約60%はクライアント側の設定や環境に起因する問題で、正しい手順さえ知っていればL1サポートで十分対応可能なものなんです。

正直なところ、筆者もヘルプデスク時代にVPN関連のチケットには何度泣かされたかわかりません。

特にWindows 11環境では、セキュリティ強化に伴うネットワークスタックの変更、累積更新プログラムによる予期しない動作変更、そしてMicrosoftが推進するAlways On VPNへの移行なんかが重なって、トラブルの原因がどんどん複雑化しています。

この記事では、ITヘルプデスク担当者が現場で即座に使える診断手法とPowerShellスクリプトを中心に、VPN接続トラブルの体系的な解決方法を紹介していきます。L2TP/IPsec、IKEv2、SSTPのプロトコル別対処法から、企業環境でのAlways On VPN展開まで、実践的な内容をカバーしています。では、さっそく見ていきましょう。

VPNプロトコル別の特徴と選定基準

トラブルシューティングに入る前に、Windows 11で利用可能なVPNプロトコルの特徴を整理しておきます。ここを理解しておくと、問題の切り分けが格段に速くなりますよ。

L2TP/IPsec：レガシーだが依然として多い構成

L2TP/IPsecは長年にわたって企業VPNの標準として使われてきました。事前共有キー（PSK）による認証が手軽なので、中小企業を中心に今でもかなり広く利用されています。ただし、NATトラバーサルの問題が頻発するため、Windows 11環境ではトラブルの温床になりがちです（これが本当に厄介）。

• メリット：設定が比較的シンプル、ほとんどのVPNサーバーが対応
• デメリット：NAT環境でのトラブルが多い、UDPポート500/4500/1701の開放が必要、PSK認証はセキュリティ的に弱い
• 使用ポート：UDP 500（IKE）、UDP 4500（NAT-T）、UDP 1701（L2TP）、ESP（プロトコル50）

IKEv2：Microsoftが推奨するモダンプロトコル

IKEv2はMicrosoftが現在最も推奨しているVPNプロトコルです。モバイル環境での再接続性能が優れていて、Wi-Fiとモバイルネットワーク間の切り替え時にも接続を維持できるMOBIKEプロトコルをサポートしています。個人的には、新規構築なら迷わずIKEv2をおすすめします。

• メリット：高速な再接続、モバイル対応、証明書ベースの強力な認証
• デメリット：証明書インフラ（PKI）の構築が必要、PSK認証はWindows標準GUIで非対応
• 使用ポート：UDP 500（IKE）、UDP 4500（NAT-T）

SSTP：ファイアウォール突破に強いプロトコル

SSTPはHTTPS（TCP 443）を使用するため、ほとんどのファイアウォール環境で接続可能です。厳しいネットワーク制限がある環境での「最後の手段」として重宝します。

• メリット：ファイアウォールに強い、TCP 443のみで動作
• デメリット：Windows専用、TCPベースのためパフォーマンスが劣る場合がある
• 使用ポート：TCP 443（HTTPS）

プロトコル選定の早見表

判断基準	推奨プロトコル	理由
新規導入・企業環境	IKEv2	セキュリティと再接続性能のバランスが最良
既存L2TP環境の維持	L2TP/IPsec	移行コストとの兼ね合い
厳しいFW環境	SSTP	TCP 443のみで接続可能
モバイルワーク中心	IKEv2	MOBIKE対応で接続安定
Always On VPN	IKEv2	デバイストンネル対応はIKEv2のみ

VPNエラーコード別トラブルシューティング

VPN接続エラーには明確なエラーコードが表示されることが多くて、これを正しく読み解くのが解決への最短ルートです。ここでは、ヘルプデスクで特に遭遇しやすいエラーコードを取り上げます。

エラー789：セキュリティ層の処理エラー（L2TP/IPsec）

「リモートコンピューターとの初期ネゴシエーション中に、セキュリティ層で処理エラーが発生したため、L2TP接続の試行が失敗しました」というメッセージが表示されます。最も多い原因はIPsec関連サービスの停止です。意外とシンプルな原因なのですが、メッセージが仰々しいので焦りますよね。

診断手順

# IPsec関連サービスの状態を確認
Get-Service -Name "IKEEXT","PolicyAgent" | Select-Object Name, Status, StartType | Format-Table -AutoSize

# サービスが停止している場合は起動
Start-Service -Name "IKEEXT" -ErrorAction SilentlyContinue
Start-Service -Name "PolicyAgent" -ErrorAction SilentlyContinue

# サービスのスタートアップの種類を「自動」に設定
Set-Service -Name "IKEEXT" -StartupType Automatic
Set-Service -Name "PolicyAgent" -StartupType Automatic

# 設定を確認
Get-Service -Name "IKEEXT","PolicyAgent" | Select-Object Name, Status, StartType | Format-Table -AutoSize

ローカルセキュリティポリシーの確認

サービスが正常に動作しているのにエラー789が消えない場合は、ローカルセキュリティポリシーの認証レベル設定を確認してみてください。

1. secpol.mscを実行してローカルセキュリティポリシーを開く
2. 「ローカルポリシー」→「セキュリティオプション」へ移動
3. 「ネットワークセキュリティ: LAN Manager認証レベル」を「LMとNTLMを送信する（ネゴシエーションの場合、NTLMv2セッションセキュリティを使う）」に変更
4. 「ネットワークセキュリティ: NTLM SSPベースのクライアント向け最小セッションセキュリティ」の「128ビット暗号化が必要」のチェックを外す

エラー809：NATファイアウォールによるブロック

「リモートサーバーが応答していないため、コンピューターとVPNサーバーの間のネットワーク接続を確立できませんでした」というエラーです。自宅のWi-Fiルーターなど、NAT環境からL2TP/IPsec接続する際に頻発します。在宅勤務が増えた今、このエラーは本当によく見かけます。

原因

Windows 11のデフォルト設定では、クライアントとVPNサーバーの両方がNATデバイスの背後にある場合、L2TP/IPsec接続がセキュリティ上の理由でブロックされます。要するに、UDPカプセル化（NAT-T）が明示的に許可されていないためです。

解決策：レジストリによるNAT-Tの有効化

# NAT-Traversalを有効にするレジストリ設定（管理者権限で実行）
# 値の説明：
#   0 = NATの背後にあるサーバーへの接続を許可しない（デフォルト）
#   1 = サーバーがNATの背後にある場合に接続を許可
#   2 = サーバーとクライアントの両方がNATの背後にある場合も接続を許可

$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent"
New-ItemProperty -Path $regPath -Name "AssumeUDPEncapsulationContextOnSendRule" -Value 2 -PropertyType DWord -Force

# 設定の確認
Get-ItemProperty -Path $regPath -Name "AssumeUDPEncapsulationContextOnSendRule"

# ※設定反映にはPC再起動が必要です
Write-Host "レジストリを設定しました。PCを再起動してください。" -ForegroundColor Yellow

ファイアウォールのポート確認

# VPN関連ポートの疎通確認
$vpnServer = "vpn.example.com"  # VPNサーバーのアドレスに置き換え

# UDP 500（IKE）の確認
Test-NetConnection -ComputerName $vpnServer -Port 500 -InformationLevel Detailed

# UDP 4500（NAT-T）の確認
Test-NetConnection -ComputerName $vpnServer -Port 4500 -InformationLevel Detailed

# TCP 443（SSTP用）の確認
Test-NetConnection -ComputerName $vpnServer -Port 443 -InformationLevel Detailed

# Windows Defenderファイアウォールのルール確認
Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*VPN*" -or $_.DisplayName -like "*IPsec*" -or $_.DisplayName -like "*IKE*"} |
    Select-Object DisplayName, Enabled, Direction, Action | Format-Table -AutoSize

エラー800：VPNサーバーへの到達不可

VPNトンネルの確立自体に失敗している状態です。ネットワーク的にVPNサーバーに到達できないか、IPsecパラメーターの不一致が原因になっています。まずは基本的なネットワーク疎通から確認していきましょう。

切り分け手順

# Step 1: 基本的なネットワーク疎通を確認
$vpnServer = "vpn.example.com"
Test-Connection -ComputerName $vpnServer -Count 4

# Step 2: DNS解決の確認
Resolve-DnsName -Name $vpnServer -Type A

# Step 3: 経路の確認（どこで止まっているか）
Test-NetConnection -ComputerName $vpnServer -TraceRoute

# Step 4: WAN Miniportアダプターの状態確認
Get-PnpDevice | Where-Object {$_.FriendlyName -like "*WAN Miniport*"} |
    Select-Object Status, FriendlyName, InstanceId | Format-Table -AutoSize

WAN Miniportの再インストール

Windows Update後にエラー800が突然発生した場合、WAN Miniportアダプターが破損している可能性があります。これは意外と盲点で、見落としがちなポイントです。以下の手順で再インストールしてみてください。

# WAN Miniportデバイスを一覧表示
$wanDevices = Get-PnpDevice | Where-Object {$_.FriendlyName -like "*WAN Miniport*"}
$wanDevices | Format-Table Status, FriendlyName, InstanceId

# 各WAN Miniportデバイスを無効化→有効化して再認識させる
foreach ($device in $wanDevices) {
    Write-Host "再認識中: $($device.FriendlyName)" -ForegroundColor Cyan
    Disable-PnpDevice -InstanceId $device.InstanceId -Confirm:$false -ErrorAction SilentlyContinue
    Start-Sleep -Seconds 2
    Enable-PnpDevice -InstanceId $device.InstanceId -Confirm:$false -ErrorAction SilentlyContinue
}
Write-Host "WAN Miniportの再認識が完了しました。" -ForegroundColor Green

エラーコード早見表

よく遭遇するエラーコードをまとめておきます。チケット対応時にさっと確認できるように、ブックマークしておくと便利です。

エラーコード	主な原因	最初に確認すべきこと
691	認証失敗（ユーザー名/パスワード誤り）	資格情報の再入力、アカウントロック状態の確認
720	PPP接続のネゴシエーション失敗	WAN Miniportの再インストール
789	IPsecセキュリティ層のエラー	IKEEXTサービスとPolicyAgentサービスの状態
800	VPNサーバー到達不可	pingとDNS解決、ネットワーク疎通確認
809	NAT/FWによるブロック	NAT-Tレジストリ設定とポート開放
812	RADIUSポリシーの不一致	NPS/RADIUSサーバーの認証ポリシー設定
853	EAPネゴシエーション失敗	証明書の有効期限と信頼チェーン

Windows Update後のVPN障害への対応

Windows 11環境でVPNトラブルが急増する最大のトリガー、それは月例のWindows Updateです。これは本当に困りもので、過去にも複数の更新プログラムがVPN接続を破壊する事態を引き起こしています。毎月の第2火曜日（いわゆる「パッチチューズデー」）の翌日は、ヘルプデスクの繁忙日になりがちです。

過去に問題を引き起こした主な更新プログラム

• KB5009566（2022年1月）：L2TP/IPsec接続が完全に機能しなくなる深刻な不具合。KB5010795で修正済み
• KB5026372（2023年5月）：L2TP/IPsec接続時のファイルサーバーアクセスが極端に遅くなる問題
• KB5074109（2026年1月）：特定のVPN構成でIKEv2の再接続が失敗する問題が報告

Windows Update後の緊急診断スクリプト

VPN障害が発生したとき、まず以下の診断スクリプトを実行して状況を把握しましょう。これ一本で主要な確認項目をカバーできます。

# Windows Update後のVPN診断を一括実行するスクリプト

Write-Host "=== VPN診断レポート ===" -ForegroundColor Green
Write-Host "実行日時: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')" -ForegroundColor Gray
Write-Host ""

# 1. 最近のWindows Updateを確認
Write-Host "[1] 直近にインストールされた更新プログラム:" -ForegroundColor Cyan
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 |
    Format-Table HotFixID, Description, InstalledOn -AutoSize

# 2. VPN関連サービスの状態
Write-Host "[2] VPN関連サービスの状態:" -ForegroundColor Cyan
$vpnServices = @("RasMan", "IKEEXT", "PolicyAgent", "SstpSvc", "RasAuto")
Get-Service -Name $vpnServices -ErrorAction SilentlyContinue |
    Select-Object Name, DisplayName, Status, StartType | Format-Table -AutoSize

# 3. VPN接続の一覧と状態
Write-Host "[3] 構成済みVPN接続:" -ForegroundColor Cyan
Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, ConnectionStatus,
    AuthenticationMethod | Format-Table -AutoSize

# 4. NAT-Tレジストリ設定の確認
Write-Host "[4] NAT-Tレジストリ設定:" -ForegroundColor Cyan
$natT = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -ErrorAction SilentlyContinue
if ($natT) {
    Write-Host "  AssumeUDPEncapsulationContextOnSendRule = $($natT.AssumeUDPEncapsulationContextOnSendRule)" -ForegroundColor White
} else {
    Write-Host "  未設定（デフォルト: 0 = NAT-T無効）" -ForegroundColor Yellow
}

# 5. WAN Miniportデバイスの状態
Write-Host "`n[5] WAN Miniportデバイス:" -ForegroundColor Cyan
Get-PnpDevice | Where-Object {$_.FriendlyName -like "*WAN Miniport*"} |
    Select-Object Status, FriendlyName | Format-Table -AutoSize

# 6. 直近のVPN関連イベントログ
Write-Host "[6] 直近24時間のVPN関連エラーログ:" -ForegroundColor Cyan
Get-WinEvent -LogName "Application" -MaxEvents 500 -ErrorAction SilentlyContinue |
    Where-Object {$_.Message -like "*VPN*" -or $_.Message -like "*RasClient*" -or $_.Message -like "*IPsec*"} |
    Select-Object -First 10 TimeCreated, Id, Message | Format-Table -Wrap

Write-Host "=== 診断完了 ===" -ForegroundColor Green

問題のある更新プログラムへの対処

特定のWindows Update適用後にVPN障害が発生した場合、一時的な回避策として更新プログラムのアンインストールが有効です。ただし、これはセキュリティリスクとのトレードオフになるので、あくまで応急処置として考えてください。恒久的にはMicrosoftからの修正パッチを待つか、代替プロトコルへの移行を検討するのがベターです。

# 特定のKBをアンインストール（例：KB5074109）
# 管理者権限のPowerShellで実行
wusa /uninstall /kb:5074109 /norestart

# アンインストール後に自動更新を一時停止（35日間）
# グループポリシーまたはWindows Updateの設定から停止可能
$regPath = "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings"
$pauseDate = (Get-Date).AddDays(35).ToString("yyyy-MM-ddTHH:mm:ssZ")
Set-ItemProperty -Path $regPath -Name "PauseUpdatesExpiryTime" -Value $pauseDate

L2TP/IPsec接続のステップバイステップ修復手順

L2TP/IPsecはWindows 11で最もトラブルが多いVPNプロトコルです。ここでは、ヘルプデスクで使える体系的な修復フローを紹介します。上から順に試していけば、大半のケースは解決できるはずです。

Step 1：VPN接続設定の再作成

最も確実で副作用の少ない方法は、VPN接続設定の削除と再作成です。「え、それだけ？」と思うかもしれませんが、これで直るケースが意外と多いんです。PowerShellを使えば正確に設定を再現できます。

# 既存のVPN接続を削除
Remove-VpnConnection -Name "社内VPN" -Force -ErrorAction SilentlyContinue

# L2TP/IPsec接続を新規作成（事前共有キー認証）
Add-VpnConnection -Name "社内VPN" `
    -ServerAddress "vpn.example.com" `
    -TunnelType L2tp `
    -L2tpPsk "事前共有キーをここに入力" `
    -AuthenticationMethod MSChapv2 `
    -EncryptionLevel Required `
    -RememberCredential `
    -SplitTunneling

# 作成した接続を確認
Get-VpnConnection -Name "社内VPN" | Format-List *

Step 2：必須サービスの確認と起動

# L2TP/IPsecに必要なサービスを一括確認・起動
$requiredServices = @(
    @{Name="RasMan"; Display="Remote Access Connection Manager"},
    @{Name="IKEEXT"; Display="IKE and AuthIP IPsec Keying Modules"},
    @{Name="PolicyAgent"; Display="IPsec Policy Agent"},
    @{Name="RasAuto"; Display="Remote Access Auto Connection Manager"}
)

foreach ($svc in $requiredServices) {
    $service = Get-Service -Name $svc.Name -ErrorAction SilentlyContinue
    if ($service.Status -ne "Running") {
        Write-Host "$($svc.Display) が停止しています。起動します..." -ForegroundColor Yellow
        Start-Service -Name $svc.Name
        Set-Service -Name $svc.Name -StartupType Automatic
    } else {
        Write-Host "$($svc.Display) は正常に動作中です。" -ForegroundColor Green
    }
}

Step 3：NAT-Tレジストリ設定の適用

# NAT環境でのL2TP/IPsec接続を許可するレジストリ設定
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent"

# 現在の設定を確認
$current = Get-ItemProperty -Path $regPath -Name "AssumeUDPEncapsulationContextOnSendRule" -ErrorAction SilentlyContinue
if ($current) {
    Write-Host "現在の設定値: $($current.AssumeUDPEncapsulationContextOnSendRule)" -ForegroundColor Cyan
} else {
    Write-Host "NAT-T設定が未構成です（デフォルト: 接続ブロック）" -ForegroundColor Yellow
}

# 値を2に設定（サーバー・クライアント双方がNAT配下でも許可）
New-ItemProperty -Path $regPath -Name "AssumeUDPEncapsulationContextOnSendRule" -Value 2 -PropertyType DWord -Force | Out-Null
Write-Host "NAT-T設定を適用しました。PCの再起動が必要です。" -ForegroundColor Green

Step 4：ネットワークスタックのリセット（最終手段）

ここまでの手順で解決しない場合の最終手段です。全ネットワーク設定がリセットされるので、Wi-Fi接続情報なども消えてしまう点には注意してください。

# ネットワークスタックの完全リセット（管理者権限必須）
# 注意：全ネットワーク設定がリセットされます

# Winsockカタログのリセット
netsh winsock reset

# TCP/IPスタックのリセット
netsh int ip reset

# DNSキャッシュのクリア
ipconfig /flushdns

# IPアドレスの解放と再取得
ipconfig /release
ipconfig /renew

Write-Host "ネットワークスタックをリセットしました。PCを再起動してください。" -ForegroundColor Yellow

IKEv2接続のトラブルシューティング

IKEv2はL2TP/IPsecよりも安定していますが、証明書関連のトラブルが発生しやすいプロトコルです。特に企業環境では、証明書の有効期限切れやチェーンの検証エラーが主な原因になります。「繋がらない」と言われたら、まず証明書を疑うのが鉄則です。

証明書の確認

# コンピューター証明書ストアのVPN関連証明書を確認
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {
    $_.EnhancedKeyUsageList.FriendlyName -contains "IP security IKE intermediate" -or
    $_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication"
} | Select-Object Subject, Issuer, NotAfter, Thumbprint | Format-Table -AutoSize

# 有効期限が30日以内に切れる証明書を警告
$warningDate = (Get-Date).AddDays(30)
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.NotAfter -lt $warningDate -and $_.NotAfter -gt (Get-Date)} |
    ForEach-Object {
        Write-Host "警告: 証明書 '$($_.Subject)' が $($_.NotAfter.ToString('yyyy-MM-dd')) に期限切れします" -ForegroundColor Yellow
    }

# ルート証明書の信頼チェーンを確認
Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object {$_.Subject -like "*VPN*" -or $_.Subject -like "*企業名*"} |
    Select-Object Subject, NotAfter, Thumbprint | Format-Table -AutoSize

IKEv2接続の作成（証明書認証）

# IKEv2接続を証明書認証で作成
Add-VpnConnection -Name "社内VPN-IKEv2" `
    -ServerAddress "vpn.example.com" `
    -TunnelType Ikev2 `
    -AuthenticationMethod MachineCertificate `
    -EncryptionLevel Maximum `
    -SplitTunneling

# IKEv2のセキュリティパラメーターを設定
Set-VpnConnectionIPsecConfiguration -ConnectionName "社内VPN-IKEv2" `
    -AuthenticationTransformConstants GCMAES128 `
    -CipherTransformConstants GCMAES128 `
    -EncryptionMethod AES128 `
    -IntegrityCheckMethod SHA256 `
    -DHGroup Group14 `
    -PfsGroup PFS2048 `
    -Force

# 設定確認
Get-VpnConnection -Name "社内VPN-IKEv2" | Format-List *

Always On VPN：企業向け次世代リモートアクセス

Always On VPN（AOVPN）は、従来のDirectAccessに代わるMicrosoftの推奨リモートアクセスソリューションです。ユーザーが手動でVPN接続を開始する必要がなくなるので、「VPN接続するの忘れてました」というあのストレスフルなチケットから解放されます。デバイスがインターネットに接続すると、自動的にVPNトンネルが確立される仕組みです。

Always On VPNのアーキテクチャ

Always On VPNは2つのトンネルで構成されています。

• デバイストンネル：ユーザーのログオン前にデバイスレベルで確立。IKEv2のみ対応。マシン証明書で認証します。ログオン前のグループポリシー適用やリモートデスクトップ接続に利用
• ユーザートンネル：ユーザーのログオン後に確立。IKEv2、SSTP、L2TP/IPsecに対応。ユーザー証明書またはEAP認証を使用。社内リソースへのアクセスに利用

Intuneによる展開の前提条件

Microsoft Intuneを使用してAlways On VPNプロファイルを展開するには、以下の前提条件が必要です。結構ハードルが高いように見えますが、既にEntra ID環境を構築済みの企業なら、追加投資はそこまで大きくありません。

• Windows Server 2019以降のRRAS（ルーティングとリモートアクセス）サーバー
• 社内PKI（証明書インフラ）の構築済み環境
• Microsoft Entra IDに参加済みのWindows 11デバイス
• Microsoft Intune（またはConfiguration Manager）のライセンス
• NPS（ネットワークポリシーサーバー）またはサードパーティRADIUSサーバー

Intune VPNプロファイルの作成手順

1. Microsoft Intune管理センター（intune.microsoft.com）にサインイン
2. 「デバイス」→「構成」→「作成」→「新しいポリシー」を選択
3. プラットフォーム：「Windows 10以降」、プロファイルの種類：「テンプレート」→「VPN」を選択
4. 基本設定で接続名、サーバーアドレス、トンネルの種類（IKEv2）を指定
5. 認証方式で「マシン証明書」を選択し、展開済みのSCEP/PKCS証明書プロファイルを指定
6. Always On VPNを「有効」に設定
7. 必要に応じてスプリットトンネリング、トラフィックフィルター、DNSルールを構成
8. 割り当て先のMicrosoft Entra IDグループを選択して展開

Windows 11固有の注意事項

Windows 11デバイスでは、Intune VPNプロファイルに関していくつか知っておくべき制限事項があります。

• 複数プロファイルの同時変更：1つ以上のVPNプロファイルを持つデバイスで複数の変更を同時処理すると、VPN接続が一時的に失われることがあります。ただし、2回目のIntuneチェックインで自動復旧するので慌てなくて大丈夫です
• デバイストンネルの制限：デバイストンネルはIKEv2のみ対応で、デバイスごとに1つのプロファイルしか割り当てできません
• アップグレード後の問題：Windows 10からWindows 11へのアップグレード後にVPNプロファイルが正常に機能しないケースがあります。その場合はプロファイルの再展開が必要です

ヘルプデスク向け：VPN問い合わせ対応フローチャート

ヘルプデスクのL1サポート担当者が、VPN関連の問い合わせを効率的にさばくための標準フローです。このフローに沿って対応すれば、多くの問題を15分以内に解決できます。

初期ヒアリング項目

まずはユーザーからしっかり情報を集めましょう。ここで手を抜くと、後の切り分けに余計な時間がかかります。

1. エラーメッセージまたはエラーコード：正確なメッセージをスクリーンショットで取得
2. 発生タイミング：いつから発生？ Windows Update直後か？ 何か設定変更した？
3. ネットワーク環境：自宅Wi-Fi？ モバイル回線？ ホテル・カフェ？
4. VPNプロトコル：L2TP/IPsec？ IKEv2？ SSTP？ サードパーティVPNアプリ？
5. 他のユーザーでも発生しているか：個別の問題か、全社的な障害か

対応フロー

ステップ	確認内容	アクション
1	インターネット接続自体は正常か	ブラウザでWebサイトにアクセスできるか確認
2	VPNサーバーに到達可能か	pingまたはTest-NetConnectionで確認
3	VPN関連サービスは動作中か	RasMan、IKEEXT、PolicyAgentの状態確認
4	エラーコードを確認	上記エラーコード早見表に従い対処
5	NAT-Tレジストリ設定は適用済みか	L2TP/IPsecの場合、レジストリ値を確認
6	Windows Updateが原因か	直近のKBを確認、必要に応じてアンインストール
7	VPN接続の再作成	設定を削除して再作成
8	ネットワークリセット	最終手段としてネットワークスタックをリセット

リモートでの診断実行

ユーザーがVPN接続できない場合、リモートデスクトップは当然使えないことが多いので、Microsoft TeamsやQuick Assistを使ってリモート支援を行います。ユーザーにPowerShellコマンドをチャットで送って、実行結果のスクリーンショットを共有してもらう方法も実は有効です。

以下は、ユーザーにコピペで実行してもらえるワンライナー診断コマンドです。結果がクリップボードにコピーされるので、そのままチャットに貼り付けてもらえます。

# ユーザーに送るワンライナー診断コマンド（コピペで実行可能）
# クリップボードにVPN診断結果をコピーする
$result = @()
$result += "=== VPN診断 $(Get-Date -Format 'yyyy-MM-dd HH:mm') ==="
$result += "`nVPN接続一覧:"
$result += (Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, ConnectionStatus | Out-String)
$result += "VPNサービス状態:"
$result += (Get-Service RasMan, IKEEXT, PolicyAgent -ErrorAction SilentlyContinue | Select-Object Name, Status | Out-String)
$result += "NAT-T設定:"
$natVal = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name AssumeUDPEncapsulationContextOnSendRule -ErrorAction SilentlyContinue).AssumeUDPEncapsulationContextOnSendRule
$result += if ($natVal) { "  値: $natVal" } else { "  未設定" }
$result -join "`n" | Set-Clipboard
Write-Host "診断結果をクリップボードにコピーしました。チャットに貼り付けてください。" -ForegroundColor Green

サードパーティVPNクライアントの注意点

企業環境ではWindows標準のVPN機能だけでなく、Cisco AnyConnect、Palo Alto GlobalProtect、FortiClient、Zscaler Private Accessなどのサードパーティ製VPNクライアントも多く使われています。これらには、Windows標準VPNとは違った固有のトラブルがあるので、知っておいて損はありません。

共通する問題と対処法

• Windows Update後の動作不良：VPNクライアントのアンインストール→最新版の再インストールが最も確実。面倒ですが、これが一番早い
• 仮想ネットワークアダプター（TAP/TUN）の破損：デバイスマネージャーからアダプターを削除し、VPNクライアントを再インストール
• DNS解決の競合：VPN接続中にスプリットDNSが正しく動作しない場合、VPNクライアントのDNS設定を確認
• PC固有のソフトウェア干渉：Dell Killer Control CenterのAdvanced Stream Detect機能、HP Sure Click、Lenovo Vantageなどがネットワーク通信に干渉する場合があります。一時的に無効化して切り分けてみてください

# サードパーティVPNの仮想アダプター状態確認
Get-NetAdapter | Where-Object {
    $_.InterfaceDescription -like "*TAP*" -or
    $_.InterfaceDescription -like "*TUN*" -or
    $_.InterfaceDescription -like "*WireGuard*" -or
    $_.InterfaceDescription -like "*Cisco*" -or
    $_.InterfaceDescription -like "*Palo Alto*" -or
    $_.InterfaceDescription -like "*Fortinet*"
} | Select-Object Name, InterfaceDescription, Status, LinkSpeed | Format-Table -AutoSize

# VPN関連プロセスの確認
Get-Process | Where-Object {
    $_.ProcessName -match "vpn|cisco|anyconnect|globalprotect|forticlient|zscaler"
} | Select-Object ProcessName, Id, CPU, WorkingSet | Format-Table -AutoSize

よくある質問（FAQ）

Q1：Windows 11にアップデートしたらVPNが繋がらなくなりました。すぐにできる対処法は？

まずVPN関連サービス（RasMan、IKEEXT、PolicyAgent）が起動しているか確認してください。次に、L2TP/IPsecを使用している場合はNAT-Tレジストリ設定（AssumeUDPEncapsulationContextOnSendRule = 2）を適用して、PCを再起動します。それでもダメなら、VPN接続設定を削除して再作成してみてください。この3ステップで大半のケースは解決できるはずです。

Q2：L2TP/IPsecとIKEv2のどちらを使うべきですか？

新規導入や移行を検討しているなら、IKEv2を強くおすすめします。IKEv2はNAT環境でのトラブルが少なく、モバイル環境での再接続性能も優秀です。さらにAlways On VPNのデバイストンネルはIKEv2のみ対応なので、将来的な拡張性も高いです。ただし、証明書インフラ（PKI）の構築が前提になるため、初期投資は必要になります。

Q3：会社のVPNに自宅のWi-Fiから接続できないのですが、モバイルテザリングでは接続できます。なぜですか？

自宅のWi-Fiルーターが原因である可能性が高いです。多くの家庭用ルーターではIPsecパススルー機能がデフォルトで無効になっています。ルーターの管理画面にアクセスして、「IPsecパススルー」または「VPNパススルー」を有効にしてみてください。合わせて、NAT-Tレジストリ設定（AssumeUDPEncapsulationContextOnSendRule = 2）がWindows側に適用されているかも要確認です。

Q4：VPN接続は確立できるのに社内のファイルサーバーやWebシステムにアクセスできません。なぜですか？

スプリットトンネリングの設定が原因のことが多いです。スプリットトンネリングが有効な場合、VPN経由で転送するトラフィックのルーティング設定が正しくないと、社内リソースへの通信がVPNトンネルを通らずにインターネットに直接出てしまいます。Get-VpnConnectionコマンドでSplitTunneling設定を確認し、必要に応じてAdd-VpnConnectionRouteで社内ネットワークのルートを追加してください。

Q5：Always On VPNを導入するメリットは何ですか？従来のVPNと何が違いますか？

Always On VPNの最大のメリットは、ユーザーが手動でVPN接続する必要がなくなることです。デバイスがインターネットに接続すると自動的にVPNトンネルが確立されるため、「VPN繋ぐの忘れてました」問題が解消されます。また、デバイストンネル機能のおかげでユーザーのログオン前からデバイスレベルでVPN接続が確立されるので、グループポリシーの適用やリモートデスクトップ接続も可能になります。導入コストはそれなりにかかりますが、運用の手間とセキュリティリスクの低減を考えると、十分に投資する価値はあると思います。