ディスク使用率100%は何を止めれば直る？── SysMain・Windows Search・Defenderの見分け方

ディスク100%という表示だけでサービスを止めず、遅い操作と読み書きの関係を調べます。必要な機能を保ちながら、一つの変更を試し、元の状態に戻して比較するための解説と手順です。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全13件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

問題・質問

タスク マネージャーでディスクが100%になり、アプリの起動や文字入力が遅い。調べると「SysMainを無効化」「Windows Searchを停止」「Defenderをオフ」という対策が出てくる。このとき、どの表示を読み、何を変更すればよいのでしょうか。

中心となる問いは、「何が読み書きしているか」と「なぜ必要な操作が待たされるか」を、設定を戻せる形でどう切り分けるかです。上位に出たプロセス名だけで原因を決めず、転送量が少ないのに100%になる場合や、検索・スキャン以外の要因も扱います。

対象環境

主な対象はWindows 11のPCを使う一般ユーザーです。タスク マネージャー、リソース モニター、Windows Search、SysMain、Microsoft Defender Antivirusを扱います。画面名と利用できる機能はWindowsのビルドや管理ポリシーで異なります。会社の管理PCは、設定変更の前に管理者へ相談してください。

サービスの停止・再開とDefenderの記録は、管理者として開いたWindows PowerShell 5.1を使う手順です。一般ユーザーの観察と、管理者による変更を区別します。必要な情報を表示できない場合は、権限を迂回せず管理者へ調査を依頼します。

Defenderパフォーマンスアナライザーの公式対応条件はWindows 10以降、Defenderプラットフォーム4.18.2108.X以降で、記録には管理者権限が必要です。別のセキュリティ製品が動作する環境や組織の制限がある環境では、この手順を無理に適用しません。[S9]

本記事はMicrosoftの一次資料を基にした解説と調査手順です。この改稿でWindows実機の性能測定やサービス停止試験を実施したという意味ではありません。Windows IoT EnterpriseやWindows Server向け資料の対象範囲と、一般のWindows 11 PCで実測した結果とは区別します。

回答・解決方法

SysMain・Windows Search・Defenderをまとめて止める万能手順はありません。まず遅い操作、時間帯、対象ディスク、プロセスとファイル、応答時間を確認します。SysMainは根拠がある場合だけ一時停止と再開を比較し、Searchは必要な検索範囲を見直し、Defenderは保護を維持してスキャンを分析します。

本記事が提案する順序は、観察 → 対象を絞る → 一つだけ変更 → 元に戻して比較です。重要なファイルは先に保存してください。読み書きエラー、ストレージの重大な警告、突然の切断がある場合は、以下の比較より重要なデータのバックアップと管理者・メーカーへの相談を優先します。[S15]

flowchart TB
    accTitle: ディスク100%を調べる基本順序
    accDescr: ディスク100%を見たら、遅い操作と対象を観察し、一つの変更だけを比較して元に戻す順序を示します。
    A["ディスク100%と操作の遅さ"] --> B["時間帯と対象を記録"]
    B --> C["一つの仮説を試す"]
    C --> D["元に戻して再確認"]
    D --> E["必要な対策だけ残す"]

図1: 設定をまとめて変える前に、比較できる状態を作ります。

定義

ここでいう「ディスク100%」は、ディスクのアクティブな時間の表示を指します。容量が満杯であることでも、理論上の最高転送速度が出ていることでもありません。タスク マネージャーの「パフォーマンス」で、アクティブな時間、読み取り・書き込み速度、平均応答時間を分けて確認します。空き容量は別に確認します。

忙しかった時間の割合と、1秒に運べたデータ量は別の指標です。一件ごとの処理に待ち時間がかかれば、連続して仕事をしていても進むデータ量は少なくなります。「大きな箱をまとめて運ぶ」場合と、「小さな箱を一つずつ受け渡す」場合の違いに似ています。細かい読み書きやストレージ側の遅延があると、少ないMB/sでも100%付近になり得ます。転送量だけでなくI/Oの応答時間も確認する理由です。[S1]

flowchart TB
    accTitle: ディスクを見る三つの指標
    accDescr: アクティブな時間、転送速度、応答時間は別の指標であり、同じ時間帯で合わせて見ることを示します。
    A["同じ時間帯を観察"] --> B["忙しさ：アクティブ時間"]
    A --> C["処理量：読み書き速度"]
    A --> D["待ち：応答時間"]
    B --> E["操作の遅さと突き合わせる"]
    C --> E
    D --> E

図2: パーセントだけでは、処理量が多いのか、待ち時間が長いのかを区別できません。

「100%だからSSDの速度を使い切っている」「数MB/sだからディスクは原因ではない」のどちらも早計です。また、平均応答時間は個々の操作の最悪値そのものではありません。単発の高い数字だけで故障と決めず、操作が止まった時刻やエラーと照合します。

役割

3つの機能は別々の目的を持ち、停止したときに失われる機能も違います。調査では「数字を下げること」より、必要な仕事と機能を維持したまま待ち時間を減らせるかを見ます。

役割の根拠はMicrosoftのサービス設定資料、検索インデックスの説明、Windows Securityの説明です。[S3] [S4] [S7]

SysMainはそのサービス設定資料で「無効化しない」分類に入っています。ただし資料の対象はWindows IoT Enterpriseです。一般のWindows 11 PCの全構成で必ず速くなるという実測保証ではなく、100%の表示だけで恒久的に無効化する根拠にもなりません。

構成

調査は、遅い操作と、その裏で動く読み書きを対応付けるための記録から成ります。見る道具と、それぞれが答えられる問いを分けます。

リソース モニターでプロセスとファイルを関連付ける方法と、Defender分析器の対象範囲は一次資料に基づきます。[S2] [S8]

ディスク番号とドライブ文字は合わせて見ます。C:とD:が同じ物理ディスクにある場合、D:への作業がC:側の操作と競合する可能性もあります。別のドライブ文字だから別のディスクだとは限りません。

flowchart TB
    accTitle: 調査に残す観察記録
    accDescr: 遅くなった時刻と操作を起点に、ディスク、プロセス、ファイル、回復した条件を記録します。
    A["遅い操作と時刻"] --> B["該当ディスクを確認"]
    B --> C["プロセスとファイルを見る"]
    C --> D["終わった後も観察"]
    D --> E["回復した条件を記録"]

図3: 「重かった」だけでなく、再現に使える記録を残します。

仕組み

名前が見えたことと、根本原因であることは違います。ファイルを大量に作るアプリが動けば、そのアプリの書き込みに加えて、検索対象なら索引の更新、保護対象ならセキュリティ検査が重なる場合があります。Searchはファイルの情報を検索用に索引化し、Defenderはファイルや処理に対する検査を行います。[S4] [S8]

flowchart TB
    accTitle: 一つの作業から複数の読み書きが生じる例
    accDescr: 大量のファイル生成に、検索対象なら索引更新、保護対象なら検査が重なる可能性を示します。
    A["大量のファイル生成"] --> B["アプリ自身の書き込み"]
    A -.-> C["検索対象なら索引更新"]
    A -.-> D["保護対象なら検査"]
    B --> E["同じ保存先で競合し得る"]
    C --> E
    D --> E

図4: 点線の処理が必ず毎回発生するという意味ではなく、調査する候補の関係です。

逆に、正規のWindows機能だから無関係だと決めることもできません。必要な機能でも、実際の環境では競合要因になり得ます。調べるのは、どの処理の量や頻度を変えると、必要な作業が改善するかです。

サービスを止めた直後に数字が下がっても、仕事を一つ減らしたことしか分からない場合があります。時間の経過で更新やコピーが終わった可能性もあります。単なる同時発生と、変更によって元の操作が改善した結果を区別します。

具体例

以下は原因を考えるための例であり、実測結果ではありません。「ディスク100%」という同じ表示でも、次に調べる対象は異なります。

ZIPを展開している間だけ遅く、完了すると落ち着く場合は、展開ソフトの書き込みに索引更新や検査が重なっていないかを見ます。Defenderの負荷が増えても、Defenderだけの故障とは限りません。ファイルを作る頻度、対象フォルダー、ストレージの応答も調査対象です。

開発用PCで大量のnode_modulesやビルド出力を何度も作り直している場合は、その場所をWindowsの検索で探す必要があるかを考えます。不要なら検索対象の見直し候補になりますが、フォルダー名だけで一律に除外する推奨ではありません。Defenderの保護対象から除外する話とも別です。

アプリを多数開いたときだけ操作が遅い場合は、メモリ使用量とハードフォールト、ディスクの待ちを合わせて観察します。反対に、同じ小さな操作でも繰り返し長く止まり、読み書きエラーもある場合は、サービスの調整よりデータの保全とストレージの診断を優先します。

手順

まず変更しない観察を行い、その記録に合う手順だけを選びます。以下をすべて順番に実施する必要はありません。重要なファイルを保存し、管理PCでは管理者と合意した範囲で実施してください。ストレージの警告やエラーがある場合は、負荷をかける比較よりバックアップを先にします。

変更せずに時間帯・ディスク・ファイルを記録する

困っている操作と、その保存先を一つ決めます。Systemやsvchost.exeは、上位に出たという理由だけで強制終了しないでください。Systemにはカーネルやドライバーの処理も関係します。[S1]

1. Ctrl + Shift + Escでタスク マネージャーを開き、「プロセス」のディスク列を並べ替えます。

   同じ時間帯に「パフォーマンス」で該当ディスクを開き、ディスク番号、ドライブ文字、アクティブな時間、読み書き速度、平均応答時間を記録します。

2. Win + Rからresmon.exeを起動し、「ディスク」でプロセスと対象ファイルを確認します。

   読み取り・書き込み・応答時間も記録します。必要な情報を表示できなければ管理者へ調査を依頼します。[S2]

3. 遅くなる前、遅い間、操作やバックグラウンド作業が終わった後を比較します。

   「起動後3分」「ZIPの展開中」「同期が終わるまで」のように作業と結び付け、回復した条件も残します。瞬間的な表示一つで原因を決めません。

遅い操作と時刻、対象ディスク、関係するプロセス・ファイル、回復条件がそろえば、次の比較対象を選べます。時間的な重なりが見えない場合は、サービスの停止へ進まず、再現条件を見直します。

SysMainとの関連が疑われる場合だけ一時停止と復帰を比較する

タスク マネージャーでサービス ホストのグループを展開し、SysMainとの関連を疑う材料が得られた場合に限る手順です。管理者として短時間の比較を行います。先にservices.mscでSysMainの状態とスタートアップの種類を記録し、普段の操作の時間も控えてください。

一時的な停止と、スタートアップの種類を「無効」にする操作は別です。この例では実行中のSysMainだけを対象とし、スタートアップの種類、レジストリ、依存サービスを変更しません。[S10] [S11]

強制終了や電源断まで自動復帰を保証するコードではありません。finallyは通常の終了や例外時に再開を試みます。PowerShellのウィンドウを強制的に閉じないでください。中断した場合はservices.mscで状態を確認し、この手順で止めたSysMainが停止したままなら開始します。再開できなければ管理者に相談し、停止したまま放置しません。[S12]

flowchart TB
    accTitle: SysMainの一時比較と恒久的な無効化の違い
    accDescr: 今回の調査では実行中のサービスを一時停止して戻し、起動設定の恒久変更とは分けて扱います。
    A["SysMainとの関連を確認"] --> B["元の状態を記録"]
    B --> C["実行中なら一時停止"]
    C --> D["同じ操作を比較"]
    D --> E["再開して確認"]
    B -.-> F["起動設定は変更しない"]

図5: 「止めて差を見る」と「ずっと無効にする」を混同しないようにします。

以下は管理者として開いたWindows PowerShell 5.1で使う比較用のコードです。ブロック全体を実行すると、停止後の90秒間に別のウィンドウで同じ作業を試せます。90秒はこの例の観察区間であり、原因を確定できる長さや性能の合否基準ではありません。

# 管理者の Windows PowerShell 5.1 で、ブロック全体を実行する。
$service = Get-Service -Name SysMain -ErrorAction Stop
if ($service.Status -ne 'Running') {
    throw 'SysMain は実行中ではありません。現在の設定を変えずに終了します。'
}

try {
    Stop-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Stopped', [TimeSpan]::FromSeconds(30))
    Write-Host '90秒間、別のウィンドウで同じ操作を比較してください。'
    Start-Sleep -Seconds 90
}
finally {
    Start-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Running', [TimeSpan]::FromSeconds(30))
    Get-Service -Name SysMain | Select-Object Name, Status
}

1. 元の状態の記録と復帰方法を確認し、管理者のWindows PowerShell 5.1で上のブロック全体を実行します。

   90秒の停止区間に別ウィンドウで同じ操作を試し、待ち時間とディスクの状態を記録します。

2. 出力とサービス画面でSysMainがRunningに戻ったこと、スタートアップの種類が変更前と同じことを確認します。

   エラーや中断があれば、実行前に確認した復帰方法を使います。復帰を確認できるまでは比較完了と扱いません。

3. 元の状態で同じ操作をもう一度行い、停止中の結果と比較します。

   ディスクの数字だけでなく、アプリ起動や普段の作業の待ち時間を比べます。停止直後の低下だけで恒久的な無効化を決めません。

元の状態、停止中、復帰後の結果と、復帰したサービス状態を記録します。一度の比較で因果関係が証明できたとは扱いません。

flowchart TB
    accTitle: 一時停止の試験を終了するときの確認
    accDescr: 通常はfinallyで再開を試み、強制終了や再開失敗の後はサービス画面で状態を確認します。
    A["比較を終了"] --> B{"再開を確認できたか"}
    B -->|"はい"| C["元の状態で再比較"]
    B -->|"いいえ"| D["サービス画面で確認"]
    D --> E["開始または管理者へ相談"]

図6: 自動で戻すコードがあっても、最後の状態確認を省略しないでください。

Windows Searchを止めず、検索が必要な範囲を見直す

検索インデックスに依存する検索を使うか、対象から外しても困らない場所かを先に確認します。変更前の範囲を記録しておき、検索に支障が出たら戻せるようにします。会社の管理PCでは管理者の方針に従います。

検索対象からの除外と、Defenderの保護対象からの除外は別の設定です。両方をまとめて変更しないでください。検索から外した場所は、索引を使う内容検索や結果の更新が以前と同じにならない場合があります。[S6] [S7]

索引の作成・更新は検索を速くするための準備でもあります。忙しいからと機能全体を止める前に、準備する情報の量を見直します。[S4]

flowchart TB
    accTitle: 検索の範囲を絞る判断
    accDescr: 索引対象のフォルダーを確認し、その場所をWindowsの検索で使う必要があるかに応じて対象を見直します。
    A["索引対象の場所を確認"] --> B{"検索で必要な場所か"}
    B -->|"必要"| C["対象を維持"]
    B -->|"不要"| D["記録して検索対象を見直す"]
    D --> E["負荷と検索結果を確認"]

図7: 検索機能全体を止める前に、準備する情報の量を減らせないか考えます。

1. 「設定」→「プライバシーとセキュリティ」→「Windowsの検索」（ビルドによっては「検索」）で、インデックスの進行状況と検索範囲を確認します。

   表示名が異なる場合は、設定内で「インデックス」を検索します。作成中、完了、一時停止、エラーを区別し、表示された状態を記録します。[S5] [S4]

2. 検索しない大量のファイルが含まれている場合だけ、記録した範囲のうち一つを見直します。

   「除外されたフォルダー」や「インデックスのオプション」の「変更」で範囲を調整します。必要な検索場所は維持し、索引の進行状況と元の操作を再度確認します。[S5]

3. 検索結果の問題や変更の反映など、必要性がある場合だけインデックスを再構築します。

   再構築は「とりあえず押す修復ボタン」ではありません。索引を作り直す仕事が発生し、途中の検索結果は不完全になり得ます。Microsoftは最大24時間程度を見込む案内をしていますが、すべてのPCの完了時間を保証する値ではありません。電源につないで完了できる時間を確保し、繰り返し再構築を開始しないでください。[S5]

作成中の一時的な負荷と完了後の定常状態を分け、残した対象のファイルを検索できることと元の操作を確認します。必要な結果が得られなくなったら、記録した検索範囲へ戻して再確認します。進行しない場合は表示された状態やエラーに応じて調査します。

flowchart TB
    accTitle: インデックス再構築中と完了後を分ける
    accDescr: 再構築では作り直しの負荷と一時的な検索結果の不足があり、効果は完了後に判断します。
    A["必要性を確認して再構築"] --> B["索引を作り直す期間"]
    B --> C["完了を待つ"]
    C --> D["検索結果と負荷を確認"]

図8: 再構築を始めた直後の忙しさだけで、対策の成否を判断しません。

Defenderの保護を維持してスキャン負荷を記録する

管理者として開いたWindows PowerShell 5.1と、対象環境に示したDefenderの対応条件が必要です。コマンドが利用できない場合や組織管理の制限がある場合は、保護設定を変更して迂回せず管理者または製品窓口へ確認します。[S9]

リアルタイム保護は切りません。Antimalware Service ExecutableやMsMpEng.exeが目立つことだけを理由に無効化しないでください。無効化中は開いたファイルやダウンロードしたファイルを通常どおり検査できなくなり、数字が下がっても同じ保護条件で速くなったとはいえません。[S7]

記録にはファイルパスやプロセス情報が含まれます。保存先と機密情報の扱いを確認し、短い再現区間に絞ります。外部共有の前には内容と共有権限を確認してください。上位項目は除外してよい一覧ではなく、分析器も除外設定の提案ツールではありません。[S9]

パフォーマンスアナライザーはスキャンを記録し、検査に時間がかかったファイルや関連プロセスをレポートにします。PC全体のディスク遅延をすべて測る道具ではありません。リソース モニターで見た遅い時間帯と合わせて、検査が関係するかを調べます。[S8]

flowchart TB
    accTitle: Defenderの負荷を保護したまま調べる
    accDescr: リアルタイム保護を維持しながら遅い操作を記録し、スキャンのレポートと操作時間を突き合わせます。
    A["リアルタイム保護を維持"] --> B["遅い操作を記録"]
    B --> C["検査時間のレポート"]
    C --> D["実際の待ち時間と照合"]
    D --> E["ファイル生成なども調べる"]

図9: セキュリティ機能を消して数字を下げるのではなく、負荷の内容を見ます。

以下のコードで記録を開始したら、別のウィンドウで遅い操作を再現します。記録側の案内に従ってEnterで終了し、その後にレポートを読みます。一意な名前でTEMPに記録し、既存ファイルを上書きしません。長時間記録し続ける手順にはしません。[S8]

# 管理者の Windows PowerShell 5.1 で実行する。
Get-Command New-MpPerformanceRecording, Get-MpPerformanceReport -ErrorAction Stop |
    Select-Object Name, Source

# 既存の記録を上書きしないよう、一意な名前を使う。
$trace = Join-Path $env:TEMP ('Defender-' + [guid]::NewGuid().ToString('N') + '.etl')
Write-Host "記録先: $trace"
New-MpPerformanceRecording -RecordTo $trace -ErrorAction Stop

# 記録を終了してからレポートを読む。
Get-MpPerformanceReport -Path $trace -TopFiles 10 -TopProcesses 10 -ErrorAction Stop

1. 管理者のWindows PowerShell 5.1で上のコードを実行し、記録区間に遅い操作を再現してからEnterで記録を終了します。

   出力された記録先とレポートを確認します。コマンドが失敗した場合は、そのエラーと対応条件を管理者と確認してください。

2. レポートの上位項目と、遅い操作の時刻・対象ファイルを突き合わせます。

   上位に出るのは、記録区間のスキャンへの影響が大きかった項目です。まず何がそのファイルを何度も作り直しているか、同じ作業が重複していないか、アプリ側で量や頻度を調整できないかを調べます。「上位10件を除外すれば安全に速くなる」とは解釈しません。[S9]

保護を維持した状態の記録と、次に調べる生成元・頻度が得られれば、この記録手順は完了です。記録できたことと性能問題が解消したことは別です。除外が本当に必要な場合は、保護低下と影響範囲を理解した管理者が個別に判断します。C:全体やユーザープロファイル全体を、記事の手順だけで除外しないでください。

flowchart TB
    accTitle: 分析レポートから調べる順序
    accDescr: スキャン負荷の上位項目は調査の入口であり、生成元や頻度を確認してから対策を考えます。
    A["レポート上位の項目"] --> B["生成元と頻度を確認"]
    B --> C["アプリ側の改善を検討"]
    C --> D["必要なら管理者と個別判断"]
    A -.-> E["そのまま除外リストにしない"]

図10: レポートは原因調査の材料であり、保護を外してよいファイルの一覧ではありません。

3つの機能以外に、メモリとストレージの状態を確認する

アプリを閉じる前に作業を保存します。読み書きエラー、重大な警告、突然の切断がある場合は、比較試験よりバックアップを優先します。ページファイルの無効化や、機種・適用条件が不明なレジストリの一括変更は行いません。

メモリにないページをストレージから読み戻す処理を、ハードページフォールトと呼びます。ディスクの物理故障という意味ではありません。読み戻す元はページファイルだけでなく、実行ファイルやメモリマップトファイルなどの場合もあります。値が出ただけでメモリ不足とも断定できません。[S13]

flowchart TB
    accTitle: ハードフォールトの読み方
    accDescr: ハードフォールトはメモリにないページをディスクから読む処理で、物理故障やメモリ不足そのものを断定する指標ではありません。
    A["必要なページがメモリにない"] --> B["ファイルから読み戻す"]
    B --> C["ディスクI/Oが発生"]
    C --> D["メモリ使用量と操作を比較"]
    B -.-> E["物理故障という意味ではない"]

図11: 「ハードフォールト」という名前だけで、故障やページファイルの問題に決めつけません。

1. エラーや警告がある場合は、重要データのバックアップと管理者・メーカーへの相談を先に行います。

   Microsoftもストレージの重大な警告に対してバックアップを先に案内しています。警告が表示されないことだけで、すべてのディスクの正常性が保証されるわけではありません。[S15]

2. 警告やエラーがなく、アプリを多数開くと遅くなる場合は、メモリ使用量とディスクの待ちを同じ時間帯に確認します。

   不要なアプリを閉じると元の操作も改善するかを比較します。ページファイルを無効にして読み書きを減らす方法は勧めません。コミットできるメモリの上限を下げ、別の失敗や不安定さを招く可能性があります。[S14]

3. ストレージ側を調べる必要がある場合は、データの保全後に対象機種の診断・ドライバー・ファームウェア情報を確認します。

   PC・ストレージのメーカーが案内する適用条件に従います。資料の更新日が新しくても、自分のOSや機種に適用できるとは限りません。SysMainの古い既知問題にはWindows 7の特定条件を対象とするものがあります。[S16]

メモリと操作の関係、またはストレージの警告と保全・診断の状況を記録します。3つのサービスに関係が見えないことだけで調査を打ち切らず、判明した条件を管理者やメーカーへ引き継ぎます。

flowchart TB
    accTitle: ストレージの警告があるときの優先順位
    accDescr: 重大な警告や読み書きエラーがある場合は、設定の最適化ではなくバックアップと機種に合った診断を優先します。
    A["警告や読み書きエラー"] --> B["重要データをバックアップ"]
    B --> C["メーカーの診断を確認"]
    C --> D["適用条件を見て修理や対策"]

図12: 故障の兆候があるときは、パーセントを下げることよりデータを守ることが先です。

確認

「直った」は、ディスクのパーセントではなく元の仕事で判断します。アプリ起動、コピーの完了、文字入力など、もともと困っていた操作を変更前と比較します。検索結果が更新されない、保護やSysMainが止まったまま、といった状態では完了にしません。

比較では同じ操作、同じ保存先、なるべく同じバックグラウンド状態をそろえます。SysMainなら元の状態→停止中→元の状態の順で確かめると、時間がたっただけで仕事が終わった可能性に気付きやすくなります。ただし、2回目にキャッシュが効くなどの差を完全には排除できません。

flowchart TB
    accTitle: 対策完了の判断
    accDescr: 元の操作が改善したことに加え、検索、保護、サービスの状態を確認して対策を完了します。
    A["元の操作を再実行"] --> B["待ち時間が改善したか"]
    B --> C["検索と保護は維持できたか"]
    C --> D["一時変更を戻せたか"]
    D --> E["条件と結果を記録して完了"]

図13: ディスクの数字ではなく、必要な仕事と機能がそろって回復したかで判定します。

制約

本記事の観察→一つの変更→復帰後の再比較は、原因を絞るための提案です。SysMainの一時停止や検索範囲の調整で必ず改善するという保証はありません。一回の比較で因果関係を証明したとも扱いません。DefenderのレポートだけでPC全体の遅延を説明することもできません。

Windows Serverの性能調査資料にある応答時間の数値は、すべてのWindows 11 PCやSSDの一律の合否基準として使っていません。Windows IoT Enterpriseのサービス設定の推奨や、Windows 7の既知問題も、現在のPCへそのまま転用しません。画面名、対応機能、権限、管理方針を実環境で確かめます。[S1] [S3] [S16]

コードが正常に終了したこと、サービスが元の状態へ復帰したこと、必要な操作が速くなったことは、別々に確認します。強制終了時の復帰や機器の正常性をコードだけに任せず、復帰後の状態と元の作業を確かめてください。

業務用Windowsアプリで特定の操作だけ遅い、現場のPCだけ固まる状態が続く場合は、小村ソフトの技術相談でも相談できます。発生時刻、再現操作、対象ファイルの種類、変更前後の記録があると調査の入口を具体的にできます。ログや記録を共有する際は、機密情報を含まないかを確認してください。

参考資料

本文の[S1]〜[S16]は次の一次資料に対応します。資料の適用範囲と、本記事が提案する比較手順・説明用の例は区別しています。

• [S1] Microsoft Learn, Troubleshoot performance problems in Windows。I/Oの応答時間やSystemプロセスを調べる考え方。Windows Server向け資料の数値を、全クライアントPCの合否基準には使いません。
• [S2] Microsoft Virtualization Team, Hyper-V Replica debugging: Why are very large log files generated?。リソース モニターでプロセスとディスク上のファイルを関連付ける調査例。
• [S3] Microsoft Learn, Guidance on configuring system services。SysMainの役割とサービス無効化の注意。適用対象はWindows IoT Enterpriseです。
• [S4] Microsoft Support, Search indexing in Windows。検索インデックスの目的と動作。
• [S5] Microsoft Learn, Troubleshoot Windows Search performance。検索対象の調整、再構築、進行状況の見方。
• [S6] Microsoft Support, Windows Search and privacy。Windows Searchの設定と検索対象。
• [S7] Microsoft Support, Stay protected with the Windows Security app。リアルタイム保護を無効にした場合の影響。
• [S8] Microsoft Learn, Performance analyzer for Microsoft Defender Antivirus。スキャンの記録と分析の手順。
• [S9] Microsoft Learn, Microsoft Defender Antivirus Performance Analyzer reference。対応条件、記録に必要な管理者権限、記録・レポート用コマンドと除外設定への注意。
• [S10] Microsoft Learn, Stop-Service。サービスを停止するコマンド。
• [S11] Microsoft Learn, Start-Service。サービスを開始するコマンド。
• [S12] Microsoft Learn, about_Try_Catch_Finally。終了処理をfinallyに置く構文。
• [S13] Microsoft Learn, How to determine the appropriate page file size for 64-bit versions of Windows。ハードページフォールトと読み戻し先の説明。
• [S14] Microsoft Learn, Introduction to the page file。ページファイルとコミット上限の関係。
• [S15] Microsoft Support, What to do about a critical warning for a storage device。重大な警告が出たときのバックアップの案内。
• [S16] Microsoft Learn, Superfetch Sysmain service causes CPU usage spikes。Windows 7の特定条件を対象とする既知問題であり、Windows 11全般の対策としては扱いません。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

ディスク使用率100%なのに数MB/sしか出ないのはなぜですか？

ディスクのアクティブな時間と、1秒間に転送できたバイト数は別の指標だからです。細かい読み書きやI/Oの待ち時間によって、転送量が少なくても忙しい状態になります。対象ディスクの応答時間と、遅い操作が同時に発生しているかを確認します。

SysMainを無効にすると必ず速くなりますか？

必ず速くなるとはいえません。まず通常の設定を維持し、SysMainとの関連が疑われる場合に限って、元の状態を記録したうえで一時停止と再開を比較します。恒久的な無効化は、その比較だけで決めないようにします。

Windows Searchは停止してもよいですか？

検索インデックスに依存する検索の速度や結果の更新に影響するため、最初の対策にはしません。インデックスの進行状況を確認し、必要のないフォルダーが検索対象に入っている場合は、その範囲を見直す方法を先に検討します。

Defenderをオフにしてディスク使用率を下げてもよいですか？

日常の高速化策としてリアルタイム保護を切ることは勧めません。Microsoft Defender Antivirusのパフォーマンスアナライザーでスキャンの負荷を記録し、どのファイルや処理が関係するかを調べます。レポート上位の項目も、そのまま除外設定に追加してはいけません。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。