コンテンツにスキップ

プラセボテスト:細かなレジストリ設定はバックグラウンド活動を抑制するのか

目次

いいえ。最適化ガイドでバックグラウンド活動の抑制として説明されている17個の「細かい」レジストリパラメータは、合計のバックグラウンド活動を低下させませんでした。レジストリとファイルの操作は、クリーンな時間帯の自然なばらつきの範囲内にとどまりました。点的な効果が証明されたのは2つのメカニズムのみです。LLMNRの無効化は対応するネットワーク要求をゼロにし、テレメトリグループはDiagTrackの定期的な構成ポーリングを停止させました(−98–99.8%)。さらに3つのパラメータは読み取られましたが、観測可能な効果は得られませんでした。

ステータス: Windows 11 26H2の仮想マシンにおける、4つの対照時間帯を伴う単一のA/B実行で測定されました。「効果なし」の判定は、観測されたアイドル時のバックグラウンド活動に関するものです。動作周期の長いパラメータについては、測定ウィンドウが不足していました。

一般的な主張は1つです。既知の17個のレジストリパラメータのセットを適用すると、アイドル状態のWindowsのバックグラウンド活動が目に見えて低下する。加えて17個の個別の主張があります。各パラメータは観測可能な挙動を変化させるかどうか。

  • Windows 11 Pro、build 26300.9457(26H2)、仮想マシン、定常状態のシステム;
  • 頻繁に推奨される17個のレジストリパラメータ: テレメトリ、診断、ネットワーク、互換性、検索;
  • パラメータ適用ウィンドウ: 3分間の安定化後の9.2分; 同じ長さのクリーンな対照ウィンドウに加え、同じ実行の4つの追加対照時間帯;
  • メトリクス: カーネルトレースによるプロセスとスレッドの起動、レジストリ、ファイル、ネットワークの操作;
  • すべてのパラメータは同時に適用され、測定直後に復元されました。

検証されなかったもの: シナリオ負荷(インストール、更新、アプリケーションの動作)、ウィンドウより長い動作周期を持つパラメータ、物理ハードウェア、その他のビルド。

単一の起動サイクルにおける厳密なA/B: パラメータを適用したウィンドウと、同じ長さのクリーンなウィンドウとの比較、加えて自然なばらつきを評価するための4つの対照クリーン時間帯。カーネルトレースのイベントはプロセスごとにグループ化され、付随する監視ノイズは除外されました。レートは1分あたりに正規化され、スパイクに対する堅牢性のために、最初の1分を除いた毎分合計の中央値が比較されました。

合計バックグラウンド活動: 同等

Section titled “合計バックグラウンド活動: 同等”
メトリクス パラメータ適用時 クリーンウィンドウ クリーン時間帯(ばらつき) 判定
プロセス起動/分 2549 2601 2601 同等
レジストリ操作/分 14235 14780 14394–18951 ばらつきの範囲内
ファイル操作/分 3098 4472 3251–4472 ばらつきの範囲内

バックグラウンド時間帯の自然な変動(レジストリで最大28%)は、セットによるどの効果よりも大きいです。生の差分「レジストリ −13%」と「ファイル −53%」は、パラメータではなく観測最初の1分のスパイクによって説明されます。

メカニズム 結果 証拠
LLMNRの無効化(マルチキャスト名前解決) LLMNR要求: すべてのクリーン時間帯で10分あたり17.8–20.7 → 0 偶然の確率は1e-7未満; 対になるmDNS要求は引き続き到着していた
テレメトリグループ(AllowTelemetry ×2 + DiagTrackのアップロード禁止) テレメトリホストの活動: 131–1950 レジストリ操作/分 → 3 テレメトリ構成の定期的なポーリングが即座に停止された

テレメトリグループは3つのパラメータを同時に適用したため、この実験でそれぞれの寄与を分離することは不可能です。

パラメータ 期待されたこと 実際
mDNSの無効化 mDNS要求の停止 頻度は変化しなかった: 10分あたり35.9 対 クリーン時間帯の29.6–35.6; 値はサービスによって読み取られる
NetBIOS over TCP/IPの無効化 NetBT要求の停止 ケイデンスは同一: 10分あたり16.8 対 16.1–16.7
自動DoHの無効化 DNS要求の減少 変化なし; このシステムでは自動DoHはそもそも有効ではなかった

このウィンドウで検証されなかったもの

Section titled “このウィンドウで検証されなかったもの”

10個のパラメータは判定なしのままでした。4つのWDI診断はウィンドウ内で読み取られず、その動作間隔は9分より長いか、シナリオ負荷時のみに現れます。検索トレースのスロットルは、キャプチャに含まれていなかった検索自身のチャネルに影響します。互換性とUSBのパラメータは、検証するためのアイドル時の活動がありませんでした。

重要な副次的事実: ポリシーブランチのパラメータを適用すること自体が、グループポリシーの更新とアプリケーションサービスを呼び覚ましました。これは短いウィンドウでは活動の増加として見える、一度きりの「適用コスト」です。

  • 測定済み: バックグラウンド操作の合計の低下はない; パラメータ適用時のレートはクリーン時間帯のばらつきの内側にある。
  • 測定済み: LLMNRの無効化はmDNSとNetBIOSに触れることなく、LLMNR要求を完全に停止する。
  • 測定済み: テレメトリグループはDiagTrackの定期的な構成ポーリングを停止させる(ホスト活動 −98–99.8%)。
  • 観測済み: mDNSとNetBIOSのパラメータはサービスによって読み取られるが、観測可能な効果は得られない。
  • WDI、互換性、USB、検索スロットルのパラメータの効果: ウィンドウまたは観測チャネルが適していなかった。
  • 各テレメトリパラメータの個別の寄与。
  • 他のビルドや物理ハードウェアでの挙動。
  • 負荷時のあらゆる効果: 測定されたのはアイドル時のみ。

順序のランダム化なしの、1つの状態に対する1つのウィンドウ。Windowsのバックグラウンド変動は大きいため、同等性の結論は1組のウィンドウではなく4つの対照時間帯に依拠しています。一部のスケジューラジャーナルは、パラメータ適用ウィンドウ中にイベントの書き込みを停止しました。その間に発火したスケジュールタスクはプロセスからは見えますが、ジャーナルからは見えません。点的な判定(LLMNR、テレメトリ)は堅牢です。効果はすべての対照時間帯に存在し、パラメータ適用ウィンドウでゼロになります。

「パラメータが読み取られる」と「パラメータが挙動を制御する」の区別が最も重要です。検証された17個の設定のうち、実際に観測可能な挙動を変えるのは2つのグループのみで、どちらにも専用の管理ポイントがあります。LLMNRはBoosterXでは「ローカル名の解決」設定でカバーされ、テレメトリは「データ収集ポリシーのテレメトリ」と「バックグラウンドETW自動ロガー」でカバーされます。アイドル状態のWindowsの残りのバックグラウンド活動は、Defender、WMI、ライセンスチェック、Storeが生み出しており、このセットの「細かい」レジストリパラメータはそれらを抑制しません。

関連資料: 調査「静かなアイドル」は実際にバックグラウンド活動を低下させるものを示しています; 「デスクトップ対サインイン画面」は残存ノイズが何で構成されているかを説明しています。

17個の値すべては測定停止直後に復元されました。正常な復元はスナップショットで記録されました。システムは復元まで再起動されませんでした。

測定はBoosterX Researchによって、記載された仮想マシン上で実施されました。この調査はBoosterXの開発者に帰属するため、開発者は結果に直接の利害関係を持ちます。手法と境界は上記に記載されており、結論は公開された手法によって検証できます。

最終検証: 2026-09-22。