Cross-Device Resume を無効にする方法
目次
Cross-Device Resume は Windows の MDM ポリシーで無効にできます。 私たちの
実験では、それを適用し、再起動してサインインした後、
CrossDeviceResume.exe は 153 秒間の観察中に起動しませんでした。
機能を再び許可して再起動すると、プロセスは再び現れました。
設定は BoosterX → 最適化 → tweak → Cross-Device Resume から適用するのが簡単です: 無効化を選択し、**「適用」**を押して PC を再起動します。 この研究は BoosterX の実装ではなく、Windows の公開された仕組みを検証したものです: プログラムが設定をどのように適用するかはこのシリーズでは検証されておらず、 記事でも主張していません。適用と元に戻す方法の詳細は 設定ページにあります。
何を検証したか
Section titled “何を検証したか”私たちが関心を持ったのは、Resume 通知が消えることだけでなく、Windows へのサインイン時に その個別プロセスの通常の起動を防ぐことでした。 これらは別の結果です: プログラムは起動してすぐ終了する場合もあれば、 通知なしで動作し続ける場合もあれば、起動要求をまったく受け取らない場合もあります。
Microsoft は DisableCrossDeviceResume を、電話からの作業の続きに関する通知を無効にする
ユーザーポリシーとして説明し、再起動が必要であると示しています。文書化されているもの: ポリシーの目的と適用のタイミング。
私たちの実験で観察されたもの: 個別プロセスの起動がないこと。
Microsoft の説明。
| 条件 | 検証した環境 |
|---|---|
| システム | Windows 11 Pro 25H2、ビルド 26200.9445 |
| コンポーネント | CrossDeviceResume 2607.27000.0.0 |
| 検証環境 | 1 台の VMware 仮想マシン |
| シナリオ | 同じユーザーによる再起動と対話型サインイン |
| 観察 | プロセス一覧とその作成の監査、イベント 4688 |
| 実験日 | 2026-09-17 |
これは機能実験であり、FPS やメモリ消費のテストではありません。物理 CPU のモデル、 仮想リソースの構成、ドライバーのバージョンは公開された サンプルに含まれていません。結果を物理 PC、他のビルド、 または他の起動方法に検証なしで当てはめることはできません。
どのように検証したか
Section titled “どのように検証したか”まず、動作中のプロセスとポリシーの初期状態を記録しました。次に、 Windows のローカル管理の仕組みを通じて禁止ポリシーを適用し、 操作の成功を確認し、状態を読み戻しました。再起動後、 対話型サインインとシェルの起動開始を待ち、プロセス とその作成ログを確認しました。
逆方向の対照として Resume を許可し、サインインを伴う再起動を繰り返しました。 別途、機能を再び禁止し、すでに動作中のプロセスを明示的に終了し、 再起動の可能性を観察しました。プロセスの終了は独立した 操作であり、それをポリシーに帰属させることはできません。
なぜレジストリへの書き込みだけでは無効化を証明できないのか
Section titled “なぜレジストリへの書き込みだけでは無効化を証明できないのか”レジストリに目的の値が存在することは、Windows がそれを 有効な MDM ポリシーとして受け入れたことを確認するものではありません。したがって、「値は書き込まれているのに CrossDeviceResume がそれでも起動する」という状況は、この研究の結果と矛盾しません。
公開されているドキュメントには、このポリシーに対応する通常の Registry 設定の既成の対応はありません。私たちのシリーズには、直接書き込みのすべての variant を個別に制御して比較したものはありません。直接書き込みはポリシーの適用の代替として確認されていませんが、レジストリのあらゆる変更が常に無意味であると主張する根拠もありません。 動作する結果はポリシー管理の仕組みを通じて得られ、状態とサインイン後の実際の起動を確認しています。
システム DLL とラボでの回避の役割
Section titled “システム DLL とラボでの回避の役割”実験では組み込みの mdmlocalmanagement.dll を使用しました。これは
ローカル管理のインターフェースを提供します: RegisterDeviceWithLocalManagement と
ApplyLocalManagementSyncML。それらの宣言は
公開されている Windows SDK ヘッダーで利用できます。
システムライブラリはポリシー適用の要求を受け入れました; サードパーティの
DLL をダウンロードしたり、Windows のファイルを置き換えたり、実行コードにパッチを当てたりする必要はありませんでした。
Intune とクラウド管理はこの実験では使用していません。
検証した Windows Pro での通常のローカル登録は「サポートされていません」を返しました。 ラボでは Embedded Mode を一時的に有効にすることでこの制限を通過し、 その後ポリシーを適用してモードの元のパラメーターを復元しました。 Microsoft は Embedded Mode を特殊なデバイス Windows IoTの文脈で説明しています。 Pro でのこのような使用は、Microsoft がサポートする確認済みのシナリオではありません。
一時モードの復元は、ローカルの管理登録 と割り当てられたポリシーを削除しませんでした。検証したシナリオの範囲外での一時的なモード有効化の 副作用は調査していません。ここでは実験の原理を説明しています; コマンド、要求の内容、回避の再現手順は公開していません。
| 検証 | 結果と結論の境界 |
|---|---|
| 禁止ポリシーの適用 | 操作は成功し、読み戻しで状態を確認 |
| すでに動作中のプロセス | 自動的には終了しなかった |
| 禁止状態での再起動とサインイン | プロセスは存在しなかった; シェル起動後 153 秒間にその起動は記録されなかった |
| 許可、再起動、サインイン | プロセスが現れ、作成はログで確認された |
| 再度の禁止とプロセスの個別終了 | 10 秒後、プロセスは存在しなかった; 120 秒間の観察中に再起動は検出されなかった |
| 検証環境の完全なロールバック | 初期状態は VM スナップショットで復元され、確認された |
サンプルには 1 台の VM と 1 つの検証手順があります。120 秒間の interval 内での反復観察は独立した実験ではありません。 2 台目のコンピューターでの独立した再現はありません。
確認されたこと
Section titled “確認されたこと”- 検証したシナリオでは、ポリシーが再起動とサインイン後の個別プロセスの通常の起動を防いだ。
- 機能の再許可は同じ検証環境で起動を戻した。
- ポリシーの適用自体は、すでに動作中のプロセスを終了させない。
- 得られた結果のために、システム DLL の置き換えや EXE へのパッチは必要なかった。
防止された起動は、観察されたシナリオでこのプロセスの動作を排除します。 これは、FPS を測定しなくても、不要なバックグラウンド機能を無効にする具体的な効果です。
確認されていないこと
Section titled “確認されていないこと”FPS の向上、frametime の変化、CPU 全体の負荷、RAM の節約は測定していません。
EXE の手動起動、すべての代替のアクティブ化方法、ShellHost 内への
Resume の配置、別のアカウントまたは SYSTEM からの動作は検証していません。
このシリーズには、BoosterX の既製のインターフェースを通じた適用の個別のペア
test はありませんでした: 表は Windows のラボでの仕組みを説明しています。
検証日時点で、Microsoft はこのポリシーを Windows Insider Preview に適用可能と mark しています。指定された Windows 11 Pro 25H2 での観察は、公式のサポート matrix の 代わりにはなりません。別に予定していた VM での検証は実施されなかったため、それに関する結果はありません。 153 秒間にイベントがなかったことは、あらゆる起動が永久に禁止されることを意味しません: 確認された効果は再起動とサインイン後の通常の起動に関するものであり、 他の方法でのプロセス起動はこの研究では調査していません。
記事は、BoosterX がどの方法でその設定を適用するかを確定していません。 BoosterX のカードとここで検証した MDM ポリシーの間の関連は 実験計画に含まれていませんでした; プログラムが同じ仕組みを使用しているかどうかの判断は、 アプリケーションの実際の動作に基づく別の検証を必要とします。
無効化は Resume に関するものです。それを「電話とのリンク」全体 または Windows のデバイス間インフラストラクチャ全体の無効化として説明することはできません。
実用的な結論
Section titled “実用的な結論”電話からの作業の続きを使用しないなら、Resume の無効化は正当化されます。 検証した環境では、MDM ポリシーによってその通常の起動を回避できました。 ユーザーにとっては、ポリシーストアを手動で実験するよりも、BoosterX の既存の設定を選択して PC を再起動する方が簡単です。 自分の Windows のバージョンで結果を確認してください。
実験では、機能の許可と再起動によってプロセスの起動が戻りました。 その後、VM を初期スナップショットから完全に復元しました: 検証中に 割り当てられたポリシーがないこと、モードの初期状態、一時的な自動サインインの 取り消し、プロセスの復帰を確認しました。
BoosterX では、同じカードで有効化すると適用と 再起動後に Resume が許可されます。これはスナップショットのロールバックの完全な同等物ではありません: ラボでのポリシー適用によって 作成されたローカルの管理登録は、他のツールで以前に適用された 制限と同様に保持されます。元に戻す方法の詳細は 設定ページにあります。
公開された一次情報源
Section titled “公開された一次情報源”- Microsoft: Connectivity / DisableCrossDeviceResume: ポリシーの目的、ユーザー範囲、再起動; 私たちの VM の結果の証明ではありません。
- Microsoft Windows SDK: mdmlocalmanagement.h: ローカル管理インターフェースの宣言; 任意のエディションでの利用可能性を約束するものではありません。
- Microsoft: Embedded Mode: Windows IoT の文脈; Pro でのサポートされた適用に関する手順ではありません。
研究と使用されたツールは BoosterX の開発者に帰属するため、 開発者は結果に対して直接の利害関係を持ちます。方法論と適用範囲の境界は 上記で説明されており、結論は公開データ と列挙された公開情報源によって確認できます。Microsoft は 研究の著者ではなく、その結論を確認していません。
検証日と変更履歴
Section titled “検証日と変更履歴”2026-09-17: 初版; 公開情報源を確認し、1 台の VM の結果、 結論の境界、起動の逆方向の検証を公開。
2026-09-19: 独立した照合の後、結論の枠組みを修正: BoosterX の具体的な仕組みに関する 主張を削除。研究は Windows の公開された MDM ポリシーとその適用のラボでの経路を検証するものであり、プログラム内の設定の実装ではありません; 実験の結果、結論の境界、情報源は保持され、 確認された効果の限界に関する注記が明確化されました。
2026-09-20: 利益相反に関する免責事項を強化: 研究とツールを所有する開発者の直接の 利害関係を明示的に認め、 description を短縮。