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

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

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

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

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

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

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

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

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

2026年09月05日 04:00 · 小村豪 · Windows 11, パフォーマンス, 障害調査, SysMain, Windows Search, Microsoft Defender, PowerShell

タスクマネージャーを開いたら、ディスクが100%。アプリを開くのも、文字を入力するのも遅い。そこで「SysMainを無効化」「Windows Searchを停止」「Defenderをオフ」という対策を見つけると、とにかく全部止めたくなります。

しかし、ここで分けたいのは、「何が読み書きしているか」と「なぜ操作が待たされるか」です。タスクマネージャーの上位に出た名前だけでは、その区別がつきません。

この記事では、Windows 11のPCを使う一般ユーザーを主な対象に、表示の読み方、3つの機能の役割、設定を戻せる調査手順を説明します。画面名や利用できる機能はWindowsのビルド・管理ポリシーで異なります。管理者向けの操作は明示します。出典は2026年9月5日に確認したMicrosoftの一次資料です。特定の実機で改善率を測定した記事ではありません。

1. 先に結論：3つを同じように止めない

この記事で勧める順序は、観察 → 対象を絞る → 一つだけ変更 → 元に戻して比較です。重要なファイルを保存し、会社の管理PCなら設定変更の前に管理者へ相談してください。

機能	まず何を見るか	最初に検討すること
SysMain	問題の時間帯に、そのサービスとの関連があるか	通常は維持。根拠がある場合だけ一時停止と再開を比較
Windows Search	インデックスの進行状況と検索対象	検索しないフォルダーが含まれていないか見直す
Microsoft Defender Antivirus	スキャンと遅い操作が重なるか	保護を維持したまま記録・分析する

この表は、単に停止の危険度を並べたものではありません。SysMainはシステム性能の維持・改善、Searchは検索のための索引作成、Defenderはマルウェア対策という別々の役割を持ちます。失われる機能も、それぞれ違います。¹²³

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

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

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

2. 100%は「容量が満杯」でも「最高速度」でもない

タスクマネージャーの「パフォーマンス」で対象ディスクを開くと、アクティブな時間、読み取り・書き込み速度、平均応答時間を確認できます。忙しかった時間の割合と、運べたデータ量は別物です。空き容量が足りないかどうかも、別に確認する必要があります。

たとえば、処理の一件一件に待ち時間がかかれば、連続して仕事をしていても進むデータ量は少なくなります。これは「大きな箱をまとめて運ぶ」のと「小さな箱を一つずつ受け渡す」の違いに似ています。細かい読み書きやストレージ側の遅延があると、少ないMB/sでも100%付近になり得ます。Microsoftの性能調査資料でも、転送量だけでなくI/Oの応答時間を確認します。⁴

したがって、「100%だからSSDの速度を使い切っている」「数MB/sだからディスクは原因ではない」のどちらも早計です。まず、問題が起きているディスク番号とドライブ文字を合わせて見ます。C:とD:が同じ物理ディスクにある場合、D:への作業がC:側の操作と競合する可能性もあります。

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

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

3. 最初の観察：いつ、どのファイルで遅くなるか

最初からサービスを止めず、Ctrl + Shift + Escでタスクマネージャーを開きます。「プロセス」のディスク列を並べ替え、同時に「パフォーマンス」で該当ディスクを確認します。さらにWin + Rからresmon.exeを起動し、リソースモニターの「ディスク」でプロセス名・ファイル・読み取り・書き込み・応答時間を見ます。表示できる情報が足りない場合は、管理者に調査を依頼してください。⁵

記録は「起動後3分」「ZIPを展開している間」「同期が終わるまで」のように、作業と結び付けます。画面の一瞬だけではなく、遅くなる前・遅い間・戻った後を比べるのがこの記事の勧めです。更新やコピーが進んでいて完了後に落ち着く状態と、同じ小さな操作で毎回長く止まる状態では、次に調べることが違います。

なお、応答時間の平均は、個々の操作の最悪値そのものではありません。単発の高い数字だけで故障と決めず、再現する停止やエラーと照合します。Systemやsvchost.exeが上位でも、名前だけで強制終了しないでください。Systemにはカーネルやドライバーの処理も関係します。⁴

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

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

4. 名前が見えたことと、根本原因であることは違う

ファイルを大量に作るアプリが動けば、そのアプリの書き込みだけでなく、検索索引の更新やセキュリティ検査が重なる場合があります。Searchはファイルの情報を検索用に索引化し、Defenderはファイルや処理に対する検査を行います。²⁶

ここから先は、原因を考えるための例です。展開ソフトで大量のファイルを作っている最中にDefenderの負荷が増えていても、「Defenderだけが壊れている」とは限りません。ファイル生成の頻度、対象フォルダー、ストレージの応答が一緒に効いている可能性があります。

逆に、正規のWindows機能だから無関係だと決めるのも誤りです。必要な機能でも、実際の環境では競合要因になり得ます。知りたいのは善悪ではなく、どの処理をどれだけ減らすと、必要な作業が改善するかです。

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

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

5. SysMain：まず維持し、疑いがあるときだけ一時比較

SysMainは、Microsoftのサービス一覧ではシステム性能の維持・改善を目的とするサービスです。その資料では無効化しない分類に入っています。ただし資料の対象はWindows IoT Enterpriseであり、「一般のWindows 11 PCすべてで必ず速くなる」という実測保証ではありません。¹

この記事では、ディスク100%という表示だけを根拠に、スタートアップの種類を「無効」にすることは勧めません。停止直後に数字が下がっても、単にバックグラウンドの仕事が減っただけかもしれません。アプリを開く時間や、普段の作業が改善したかまで見ます。

タスクマネージャーでサービスホストのグループを展開して関連を確認し、SysMainを疑う材料が得られた場合に限って、管理者として短時間の比較をします。停止の前にservices.mscでSysMainの状態とスタートアップの種類を記録してください。サービスの一時停止と、次回以降も起動しない設定は別の操作です。⁷⁸

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

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

管理者向け：90秒の比較と復帰を一つの処理にする

次は管理者として開いたWindows PowerShell 5.1で、ブロック全体を実行する例です。もともと実行中のSysMainだけを対象にし、停止後の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
}

finallyは通常の終了や例外時に復帰を試みるためのものです。PowerShellのウィンドウを強制的に閉じる、プロセスを終了する、電源が落ちる場合まで復帰を保証するものではありません。途中で中断した場合はservices.mscで状態を確認し、この手順で止めたSysMainが停止したままなら開始してください。復帰に失敗した場合も、そのまま放置せず管理者へ相談します。⁹

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

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

6. Windows Search：止める前に「何を検索したいか」を見直す

Windows Searchの索引は、ファイル名や内容などをすばやく探すための仕組みです。索引の作成中・更新中は仕事が発生しますが、これは検索を速くするための準備でもあります。²

Windows 11では「設定」→「プライバシーとセキュリティ」→「Windowsの検索」を開き、インデックスの進行状況と検索範囲を確認します。表示名が異なる場合は、設定内で「インデックス」を検索してください。使わない大量のファイルが対象なら「除外されたフォルダー」や「インデックスのオプション」の「変更」で範囲を絞れます。¹⁰

たとえば開発用PCのnode_modulesやビルド出力は、Windowsの検索で探す必要がなければ見直し候補です。ただし、これはフォルダー名だけで一律に外す推奨ではありません。検索から外した場所の内容が、以前と同じように検索できなくても困らないかを先に考えます。変更前の範囲を記録しておけば、検索に支障が出たときに戻せます。

ここでいう「検索対象からの除外」は、後述する「Defenderの保護対象からの除外」とは別です。両方の設定をまとめて変更しないでください。¹¹³

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

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

再構築を「とりあえず押す修復ボタン」にしない

インデックスの再構築は索引を作り直す操作です。既に作成中なら、その仕事をもう一度始めることになります。Microsoftは再構築に最大24時間程度を見込む案内をしており、作成中は検索結果が不完全になり得ます。¹⁰

したがって、ディスクが忙しいという理由だけで、何度も再構築することは勧めません。まず進行状況とエラーを確認し、対象範囲の調整後や検索結果の問題など、再構築が必要な場合に実行します。実行したなら、電源につないで作業が完了できる時間を確保し、再構築中の負荷を定常状態の負荷と区別します。

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

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

7. Defender：保護を切らずに「何を検査しているか」を調べる

Antimalware Service ExecutableやMsMpEng.exeが目立っていても、日常の高速化策としてリアルタイム保護を切ることは勧めません。保護を無効にしている間は、開いたファイルやダウンロードしたファイルを通常どおり検査できなくなります。ディスクの数字が下がっても、必要な機能を失っているなら、同じ条件で速くなったとはいえません。³

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

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

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

管理者向け：記録を取って上位の項目を見る

公式の前提はWindows 10以降、Defenderプラットフォーム4.18.2108.X以降です。管理者権限が必要です。別のセキュリティ製品を使っている場合や、組織管理で機能を制限している場合は、この手順を無理に適用せず管理者や製品の窓口へ確認します。¹²

次は管理者として開いたWindows PowerShell 5.1で実行します。記録を開始したら別のウィンドウで問題の操作を再現し、記録側の案内に従ってEnterで終了します。日常的な問題なら短い再現区間に絞り、長時間記録し続けないようにします。⁶

# 管理者の 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

ここで上位に出るのは、記録した区間のスキャンへの影響が大きかった項目です。「上位10件を除外すれば安全に速くなる」という意味ではありません。Microsoftも、この分析器を除外設定の提案ツールとは位置付けていません。¹²

まず、そのファイルを何が何度も作り直しているか、同じ作業が重複していないか、アプリ側で調整できないかを調べます。除外が本当に必要なら、影響範囲と保護の低下を理解した管理者が個別に判断します。C:全体やユーザープロファイル全体を、記事の手順だけで除外しないでください。記録にはファイルパスやプロセスの情報が入るため、外部へ渡す前には機密情報の扱いも確認します。

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

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

8. 3つ以外も見る：メモリとストレージの状態

アプリを多数開いたときに遅くなるなら、タスクマネージャーのメモリも確認します。メモリにないページをストレージから読み戻す「ハードフォールト」が増える場合がありますが、これはディスクの物理故障という意味ではありません。読み戻す元はページファイルだけでなく、実行ファイルやメモリマップトファイルなどの場合もあります。値が出ただけでメモリ不足とも断定できません。¹³

「不要なアプリを閉じると、ディスクの待ちと操作が一緒に改善するか」は比較する価値があります。一方、ページファイルを無効にして読み書きを消す方法は勧めません。コミットできるメモリの上限を下げ、別の失敗や不安定さを招く可能性があります。¹⁴

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

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

また、読み書きエラーやストレージの重大な警告、突然の切断があるなら、サービスの調整より重要なデータのバックアップを優先します。Windowsのストレージ警告についても、Microsoftはバックアップを先に案内しています。警告が見えないことだけで、すべてのディスクが正常だと保証されるわけではありません。¹⁵

バックアップ後に、PC・ストレージのメーカーが提供する診断や、対象機種に合ったドライバー・ファームウェア情報を確認します。古い記事にあるレジストリの一括変更を、機種や適用条件を確かめずに試す順序にはしません。たとえばMicrosoftのSysMain関連の既知問題にも、対象がWindows 7の特定条件に限定されたものがあります。資料の更新日だけでは、現在のWindows 11へ適用できるとは判断できません。¹⁶

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

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

9. 「直った」はパーセントではなく、元の仕事で判定する

対策の成否は、もともと困っていた操作で確認します。「アプリ起動が待たされない」「コピーが正常に完了する」「文字入力が引っかからない」という結果を、変更前と比べます。ディスク100%が短くなっても、検索結果が更新されない、保護が止まったまま、という状態では完了にしません。

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

これはこの記事で提案する調査の考え方です。数字を下げる設定を集めるより、どの変更が、必要な機能を保ったまま、元の操作を改善したかを記録するほうが、再発時にも役立ちます。

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

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

まとめ

ディスク100%に対して、SysMain・Windows Search・Defenderをまとめて止める万能手順はありません。まず時間帯、対象ディスク、ファイル、応答時間を確認します。そのうえでSysMainは必要な場合だけ一時比較、Searchは検索範囲を見直し、Defenderは保護を維持して分析する、という分け方が出発点になります。

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

参考リンク

Microsoft Learn, Guidance on configuring system services。SysMainの役割とサービス無効化の注意。適用対象はWindows IoT Enterpriseです。 ↩ ↩²
Microsoft Support, Search indexing in Windows。検索インデックスの目的と動作。 ↩ ↩² ↩³
Microsoft Support, Stay protected with the Windows Security app。リアルタイム保護を無効にした場合の影響。 ↩ ↩² ↩³
Microsoft Learn, Troubleshoot performance problems in Windows。I/Oの応答時間やSystemプロセスを調べる考え方。Windows Server向けの資料にある数値基準を、すべてのクライアントPCの合否基準としては使っていません。 ↩ ↩²
Microsoft Virtualization Team, Hyper-V Replica debugging: Why are very large log files generated?。リソースモニターでプロセスとディスク上のファイルを関連付ける調査例。 ↩
Microsoft Learn, Performance analyzer for Microsoft Defender Antivirus。スキャンの記録と分析の手順。 ↩ ↩² ↩³
Microsoft Learn, Stop-Service。サービスを停止するコマンド。 ↩
Microsoft Learn, Start-Service。サービスを開始するコマンド。 ↩
Microsoft Learn, about_Try_Catch_Finally。終了処理をfinallyに置く構文。 ↩
Microsoft Learn, Troubleshoot Windows Search performance。検索対象の調整、再構築、進行状況の見方。 ↩ ↩²
Microsoft Support, Windows Search and privacy。Windows Searchの設定と検索対象。 ↩
Microsoft Learn, Microsoft Defender Antivirus Performance Analyzer reference。対応条件、管理者権限、記録・レポート用コマンドの仕様と除外設定への注意。 ↩ ↩²
Microsoft Learn, How to determine the appropriate page file size for 64-bit versions of Windows。ハードページフォールトと読み戻し先の説明。 ↩
Microsoft Learn, Introduction to the page file。ページファイルとコミット上限の関係。 ↩
Microsoft Support, What to do about a critical warning for a storage device。重大な警告が出たときのバックアップの案内。 ↩
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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ブログ一覧に戻る

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

1. 先に結論：3つを同じように止めない

2. 100%は「容量が満杯」でも「最高速度」でもない

3. 最初の観察：いつ、どのファイルで遅くなるか

4. 名前が見えたことと、根本原因であることは違う

5. SysMain：まず維持し、疑いがあるときだけ一時比較

管理者向け：90秒の比較と復帰を一つの処理にする

6. Windows Search：止める前に「何を検索したいか」を見直す

再構築を「とりあえず押す修復ボタン」にしない

7. Defender：保護を切らずに「何を検査しているか」を調べる

管理者向け：記録を取って上位の項目を見る

8. 3つ以外も見る：メモリとストレージの状態

9. 「直った」はパーセントではなく、元の仕事で判定する

まとめ

参考リンク

Windowsの名前解決の順序 ── hosts・DNSキャッシュ・LLMNR/mDNS・DoH

メモリ整合性(HVCI)をオフにすると速くなるのか ── 意味と手順と判断

WPR/WPA実践 ── 「PC全体が重い」をシステム全体から調べる性能調査入門

Get-WinEventでイベントログを実務的に調べる ── 絞り込みの速さが調査時間を決める

Windows効率モードとは - 緑の葉アイコンとオフにする方法

関連トピック

Windows技術トピック

よくある質問

著者プロフィール

小村豪

1. 先に結論：3つを同じように止めない

2. 100%は「容量が満杯」でも「最高速度」でもない

3. 最初の観察：いつ、どのファイルで遅くなるか

4. 名前が見えたことと、根本原因であることは違う

5. SysMain：まず維持し、疑いがあるときだけ一時比較

管理者向け：90秒の比較と復帰を一つの処理にする

6. Windows Search：止める前に「何を検索したいか」を見直す

再構築を「とりあえず押す修復ボタン」にしない

7. Defender：保護を切らずに「何を検査しているか」を調べる

管理者向け：記録を取って上位の項目を見る

8. 3つ以外も見る：メモリとストレージの状態

9. 「直った」はパーセントではなく、元の仕事で判定する

まとめ

参考リンク

関連する記事

Windowsの名前解決の順序 ── hosts・DNSキャッシュ・LLMNR/mDNS・DoH

メモリ整合性(HVCI)をオフにすると速くなるのか ── 意味と手順と判断

WPR/WPA実践 ── 「PC全体が重い」をシステム全体から調べる性能調査入門

Get-WinEventでイベントログを実務的に調べる ── 絞り込みの速さが調査時間を決める

Windows効率モードとは - 緑の葉アイコンとオフにする方法

関連トピック

Windows技術トピック

よくある質問

著者プロフィール

小村 豪

小村豪