Windows 11モダンスタンバイ復帰後にWi‑Fiが遅い原因と解決策：Realtek 8821CEで起きるCCMPリプレイ対策（Dell Inspiron 15-3520）

スリープ復帰後だけ無線LANのダウンロードが極端に遅くなる——そんな不可解な不具合に悩まされるWindows 11ノートは少なくありません。本記事では、Dell Inspiron 15‑3520（Realtek 8821CE）で再現した事例を軸に、原因の芯をわかりやすく解きほぐし、現場で即使える恒久に近いワークアラウンド（推奨設定）と検証手順、運用展開のポイントまでを一気通貫で解説します。一般論に終わらない“実戦向け”の内容として、コマンドの丸写しで対処できるよう具体的に記載します。

現象の要約と検証環境

対象と症状

• 機種：Dell Inspiron 15‑3520 ×2台（Windows 11）
• 無線：Realtek 8821CE Wireless LAN 802.11ac PCI‑E NIC
• ネットワーク環境：複数ISP（光／ケーブル）・複数ルーターで同症状
• 現象：スリープ（モダンスタンバイ）から復帰すると無線ダウンロード速度が75〜80％低下
• 一時対処：Wi‑Fiを「切断→再接続」すると即時に元の速度へ回復
• 無効だった対策：ドライバー／チップセット／BIOSの更新・再インストール、ルーター初期化

再現手順の目安

1. 復帰前のベンチマーク（例：大容量ファイルのHTTP/SMBダウンロードや社内配布サーバーからの取得）で基準値を記録。
2. スリープへ移行（ふつうに画面を閉じる・電源ボタン・OSのスリープ操作のいずれでも可）。
3. 数分〜数十分後に復帰し、同じダウンロードを実行。
4. 速度が顕著に低下（おおむね基準の2割〜3割程度に頭打ち）。
5. Wi‑Fiを「切断→再接続」または機内モードON→OFFで即回復。

テストマトリクス（例）

条件	ベース速度	スリープ復帰直後	切断→再接続後	備考
ISP A × ルーターA（5 GHz/80 MHz）	250 Mbps	45〜55 Mbps	240〜255 Mbps	顕著に低下→再接続で回復
ISP B × ルーターB（5 GHz/80 MHz）	300 Mbps	50〜60 Mbps	295〜305 Mbps	環境差を越えて再現
ISP A × ルーターC（2.4 GHz/20 MHz）	60 Mbps	10〜15 Mbps	60 Mbps前後	帯域によらず同傾向

原因の芯：S0低電力アイドル（Modern Standby）とAES‑CCMPの「リプレイ保護」

当該機はModern Standby（S0 Low Power Idle）で動作します。S3（従来のスリープ）と異なり、S0ではシステムは「ほぼスリープ」に見えながらも、ネットワーク接続を維持したまま低電力で待機できるモードが既定で有効化されています（項目名：ネットワーク接続を維持するスリープ／Network Connectivity in Standby）。

このとき無線NIC（Realtek 8821CE）は物理的切断を伴わずにアイドル遷移するため、復帰後もしばしば暗号化セッションが前提としたフレーム時系列とズレます。WPA2/WPA3のデータ暗号に使われるAES‑CCMPにはリプレイ保護があり、時系列が巻き戻った／重複したと判断されたフレームは安全側で破棄されます。今回の個体では復帰直後にCCMPリプレイ（CCMPReplays）カウンターが急増し、上位レイヤーからは「受信ロスが増えて速度が伸びない」形で観測されました。再接続をかけると暗号セッションが貼り直され、リプレイ判定が解消して速度が元に戻る、という理屈です。

なお、同型番でも製造ロットやドライバーとの組み合わせにより症状が出ない個体もあります。将来的なドライバー更新で根治される可能性はありますが、いま困っている現場では「復帰時に自動でリンクを貼り直させる」運用が即効性の高い解決策になります。

最短で直す：推奨ワークアラウンド（スリープ中のネットワーク維持を無効化）

Modern Standbyの「ネットワーク接続を維持」を無効化し、スリープ突入時にWi‑Fiが自動切断→復帰時に自動再接続されるようにします。復帰直後の「中途半端に残ったセッション状態」を避けられるため、速度低下が解消されます。

PowerShell（管理者）で一括設定

powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 0
powercfg /SETDCVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 0
powercfg /SETACTIVE     SCHEME_CURRENT

• 0 = Disabled（スリープ中はネットワークを切断）
• AC/DCともに0へ設定後、プランを再アクティブ化して反映

GUIでの設定手順（Windows 11）

1. 設定 → システム → 電源とバッテリー → 追加の電源設定
2. 使用中プランのプラン設定の変更 → 詳細な電源設定の変更
3. スリープ → ネットワーク接続を維持するスリープ を 無効（バッテリー／電源接続の双方）に変更

設定値の早見表

サブ設定	値	意味	推奨
CONNECTIVITYINSTANDBY（AC）	0	スリープ中はネットワーク切断	◯
CONNECTIVITYINSTANDBY（DC）	0	スリープ中はネットワーク切断	◯
1	ネットワーク接続を維持（Connected）	×（本件では非推奨）

副作用と対処

• スリープ中はPush通知や着信（VoIP等）、バックグラウンド同期が停止します。復帰直後にまとめて処理されます。
• 一方で待機電力はむしろ下がる傾向にあり、バッテリー駆動時間には好影響を与えることが多いです。

「効いているか」を確かめる：診断と検証の実務

Modern Standbyの有無を確認

powercfg /a

「スタンバイ（S0 低電力アイドル）— ネットワーク接続」といった表記があればModern Standby対応機です。

現在の設定値を確認

powercfg /QUERY SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY

AC/DCともに0（Disabled）になっていれば本記事のワークアラウンドが適用済みです。

速度の実測とログ採取

• netshでリンク速度の目安を見る：netsh wlan show interfaces
• wlanreportで時系列を確認：netsh wlan show wlanreport%ProgramData%\Microsoft\Windows\WlanReport\ 内にHTMLレポートが作成されます。
• pktmonでドロップ傾向を掴む（管理者）：pktmon start --capture --comp ndis --pkt-size 0 timeout /t 60 pktmon stop pktmon format PktMon.etl -o PktMon.txt
• Windows Performance Recorder（WPR）で無線スタックを含むトレースを採取し、Windows Performance Analyzerで復帰直後の再送・損失を可視化。

CCMPリプレイが疑われるときの観点

• 復帰直後に再送・受信エラーが一時的に膨らむ（数十秒〜数分）。
• アクセスポイント側の統計にも「重複フレーム／リプレイ検知」が増える。
• Wi‑Fiを切断→即再接続するとエラーがゼロ近傍へ戻る。

運用で広げる：スクリプト／一括配布テンプレート

ローカル適用（.cmd）

@echo off
REM --- Network Connectivity in Standby を無効化 ---
powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 0
powercfg /SETDCVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 0
powercfg /SETACTIVE     SCHEME_CURRENT
echo Done.

PowerShell（検出＋修正のワンライナー）

$q = (powercfg /QUERY SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY) -join "`n"
if ($q -notmatch "AC.*0" -or $q -notmatch "DC.*0") {
  powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 0
  powercfg /SETDCVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 0
  powercfg /SETACTIVE     SCHEME_CURRENT
}

グループポリシー／構成管理での配布ヒント

• スタートアップスクリプトとして上記cmd/ps1を配布すれば、起動時に自動修正可能。
• グループポリシーの「電源オプション」（Power Options）やGPP（環境設定）で該当サブ設定（SUB_SLEEP→CONNECTIVITYINSTANDBY）をAC/DCとも0へ。
• モバイルPCのみをWMIフィルター（Win32_Batteryの存在など）で対象にするのも有効。
• 構成プロファイル（例：スクリプト配布、プロアクティブ修復）で定期評価→ドリフト自動修正。

ロールバック（既定状態に戻す）

powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 1
powercfg /SETDCVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 1
powercfg /SETACTIVE     SCHEME_CURRENT

本質理解：なぜ「切断して寝かせる」と速さが戻るのか

Modern Standbyのネットワーク維持は、スリープ中もAPとの関連付けや暗号コンテキストを温存します。便利な反面、復帰タイミングのズレやAP側の省電力連携（U‑APSD、TIM/DTIM）と噛み合わないとフレームの番号（パケットカウンタ）が想定外の順序で到着し、AES‑CCMPのリプレイ保護が働きます。これはセキュリティ上正しい挙動ですが、結果として実効スループットを著しく損ねます。スリープ突入時に物理的に切断してしまえば、復帰時は毎回クリーンな再接続となり、暗号セッションとシーケンスが整った状態から通信が再開されるため、速度低下の再現条件を根本から外せます。

補足：別解・追加のチューニング（必要な場合のみ）

上記ワークアラウンドで直らない／副作用が大きいケース向けの選択肢です。併用は構いませんが、変更多数は切り分けを難しくするため一つずつ検証しましょう。

• ドライバーの更新／ロールバック：同じ「8821CE」でもビルド差で挙動が変わる場合があります。最新版と1〜2世代前双方を試験。
• 帯域の固定：AP側でクライアントを5 GHz優先（2.4 GHzを無効またはステアリング）に。混雑環境では安定することが多い。
• セキュリティ方式の固定：WPA2‑PSK（AES‑CCMP）単独／WPA2‑WPA3混在の切り替えで改善することあり（テスト目的で一時的に）。
• APの省電力機能の見直し：DTIM間隔・スマート省電力・スケジュール機能などをデフォルトに戻す／緩める。
• ネットワークのリセット：Windows設定 → ネットワークの詳細設定 → ネットワークのリセット。
• NICの詳細プロパティ：「優先バンド」「ローミングの積極性」「スループットブースト」等がある個体では、既定（Auto/中）に戻す。
• WoWLAN（Wake on WLAN）：不要であれば無効化しておくと、復帰シーケンスの簡素化に寄与する場合があります。

注意：本件のコアは復帰直後の暗号セッション不整合に起因するデータドロップであり、APや回線の性能そのものではありません。ルーターやISPを変えても再現したのは、この前提と整合します。

現場の意思決定に役立つポイント（Q&A）

Q. スリープ中のネットワーク切断で困ることは？

A. スリープ中のメール・チャット・VoIP着信・クラウド同期は止まります。ただし復帰後に即時追いつき、業務では「復帰後が遅い」という主訴を優先して解決できます。会議端末など常時着信が必要な役割は例外設計としてください。

Q. バッテリーには悪影響？

A. 一般に待機電力は下がるため好影響です。夜間の放電が気になる端末にも有効です。

Q. 企業配布時のベストプラクティスは？

• 検出→修正のスクリプトを起動時に走らせる。
• WMIフィルターでModern Standby対応機に限定。
• 例外ポリシー（チーム端末・通話端末など）は別OU／別プロファイルで管理。
• 変更の監査ログを残す（イベントログ／スクリプトの出力ログ）。

Q. 将来のドライバー更新で解決する？

A. 可能性はあります。とはいえ現象が発生している端末に対しては、本記事のワークアラウンドを適用し、更新適用後にA/B比較で撤回を検討するのが現実的です。

検証レポートの書式テンプレート（コピペ可）

【対象】Dell Inspiron 15-3520 / Realtek 8821CE / Windows 11 22H2/23H2/24H2
【症状】スリープ復帰後にWi‑Fiダウンロードがベース比 -75〜-80%
【前提】異なるISP/ルーターで再現。切断→再接続で即回復
【原因仮説】Modern Standby復帰直後のAES‑CCMPリプレイ判定増加による実効スループット低下
【対処】CONNECTIVITYINSTANDBY=0（AC/DC）へ設定
  powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 0
  powercfg /SETDCVALUEINDEX SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY 0
  powercfg /SETACTIVE     SCHEME_CURRENT
【結果】復帰後のダウンロード速度がベース値へ回復（N回連続試験で安定）
【副作用】スリープ中のPush/同期は停止（復帰後に追いつく）。待機電力は低下傾向

付録：よく使うコマンド早見表

目的	コマンド	メモ
Modern Standby確認	powercfg /a	S0低電力アイドルの有無
設定値の参照	powercfg /QUERY SCHEME_CURRENT SUB_SLEEP CONNECTIVITYINSTANDBY	AC/DCの現在値を確認
無効化（推奨）	powercfg /SETACVALUEINDEX ... 0 powercfg /SETDCVALUEINDEX ... 0	最後に/SETACTIVEで反映
有効化（元に戻す）	powercfg /SETACVALUEINDEX ... 1 powercfg /SETDCVALUEINDEX ... 1	必要に応じて再検証
インターフェース情報	netsh wlan show interfaces	リンク速度/電波強度を目安に
WLANレポート	netsh wlan show wlanreport	HTMLレポートが作成される
パケットモニタ	pktmon start ... → pktmon stop	復帰直後60秒のログが有効

まとめ：Modern Standby時代の「復帰後だけ遅い」を確実に潰す

本稿のポイントは三つです。第一に、問題の正体はModern Standby復帰直後の暗号セッション不整合であり、回線やルーター性能の問題ではないこと。第二に、スリープ中のネットワーク維持を無効化すれば復帰時に自動で“クリーンな再接続”が走り、速度低下を実務的に解決できること。第三に、企業環境ではスクリプトやGPOで一括・再現性高く配布できることです。

モダンスタンバイ対応PC全般で、「復帰後にだけ遅い」→「切断→再接続で直る」という一致があるなら、まずはCONNECTIVITYINSTANDBY=0を試してみてください。症状の根に触れる対処で、原因追跡の時間を短縮し、ユーザー体験を即日で改善できます。

ケーススタディ：Dell Inspiron 15‑3520／Realtek 8821CEの観察メモ

• 複数ISP・複数ルーターを跨いで同傾向。装置依存よりもクライアント側状態依存が濃厚。
• 同型番でも無症状の個体あり。製造ロット差／ドライバービルド差の可能性。
• デバイスマネージャーの電源管理タブが出ない個体があり、一般的な「電力節約のために…」チェック外しは使えない。
• 復帰後にCCMP関連エラーと見られるドロップが一時的に増加。再接続で解消。
• ワークアラウンド適用後は再現が止み、速度は安定化。待機電力は僅かに改善。

トラブルシューティングの道標

症状	優先度	アクション	期待効果
復帰後だけ遅い／切断→再接続で直る	高	CONNECTIVITYINSTANDBY=0（AC/DC）	ほぼ即解消、再現しにくくなる
復帰後に切断→自動再接続まで時間がかかる	中	APのバンドステアリング／DTIM設定を標準へ	再接続時間の短縮
まれにAPから弾かれる	中	WPA2単独／WPA3単独で一時検証	相互運用の問題を切り出し
スリープ中の着信が必要	ケースバイケース	対象端末のみCONNECTIVITYINSTANDBY=1を維持	要件優先の例外運用

おわりに

Windows 11のモダンスタンバイは便利ですが、特定の無線NIC・ドライバー・APの組み合わせでは、今回のような「復帰後だけ遅い」という体感劣化を招くことがあります。幸い、スリープ中にリンクを切るだけで回避できるケースが多く、導入も撤回も容易です。現場での再現・非再現を短時間で見極め、ユーザー体験を最短距離で回復するための手引きとして、ぜひ本記事の手順とスクリプトを活用してください。