【図解】CPU使用率とロードアベレージの違い｜「低いくせに重い」真因と目安を解説

インフラエンジニアとしてキャリアを積むと、必ず直面する「数字の矛盾」があります。

「CPU使用率は低いのに、アプリケーションの応答が極端に遅い」
「ロードアベレージは異常に高いが、サーバー自体は負荷が低そうに見える」

これらの現象を「OSの機嫌が悪い」で片付けてはいけません。そこには必ず、OSのスケジューラ、スレッド管理、そしてハードウェア特性に裏打ちされた「論理（ロジック）」が存在します。

本記事では、インフラエンジニアが単なる「数字を眺める人」から「システム内部を透視できるプロ」へステップアップするために、CPU使用率とロードアベレージの決定的な違い、危険水準の目安、そしてトラブルシューティングの手順を図解付きで分かりやすく解説します。

【Linux/Windows】CPU使用率とロードアベレージの決定的な違いとは？

一言で言えば、CPU使用率は「計算機が働いていた時間の割合（%）」、ロードアベレージは「処理を待っている行列の長さ（個数）」です。

さらにLinuxでは「ディスクI/O待ち」もロードアベレージに含まれるため、「CPU使用率は低いのにシステムが重い」という現象が発生します。

CPU使用率（Utilization）：店員の「稼働時間」

CPU使用率は、一言で言えば「CPUがどれだけ休まず働いていたかの割合（%）」です。

• 定義：一定時間内に、CPUがアイドル状態（暇な時間）ではなかった時間の割合。
• 例え：レジの店員が1分間のうち、何秒間手を動かして会計作業をしていたか。

ロードアベレージ（Saturation）：行列の「長さ」

対して、Linux等で重視されるロードアベレージは「割合（%）」ではなく「プロセス数（個数）」で表されます。

• 定義：CPUで処理中、または処理順番を待っているプロセスの平均数。
• 例え：レジで会計中の人と、後ろに並んで待っている人の「合計人数」。

【ここが重要】Linuxには「見えない待ち（ディスクI/O）」が含まれる

WindowsとLinuxでは「負荷」の定義に決定的な違いがあります。

OS	主な指標	含まれるもの	特徴
Linux	ロードアベレージ	CPU実行中 ＋ CPU待ち ＋ ディスクI/O待ち	ストレージが遅いだけでも数値が跳ね上がる
Windows	CPU使用率	CPU実行中のみ	ディスク遅延は「ディスク使用率」として別管理

つまり、Linuxにおいて「CPU使用率は10%なのに、ロードアベレージが10を超えている」という現象が起きたら、それはCPUの計算能力不足ではなく、「HDD/SSDの読み書き待ちで、処理が大渋滞している（D状態プロセス）」ことを意味します。

文字通り「絵」で理解する！インフラの基本とOSリソースの仕組み

CPUやメモリ、OSの基本構造をまずは難解な数式抜きでイメージから掴みたい方には『絵で見てわかるOS/ストレージ/ネットワーク 新装版』がおすすめです。

アーキテクチャの基礎が図解で丁寧に整理されているため、若手エンジニアが基礎体力をつける最初の一冊としてこれ以上ないほど親しみやすい良書です。

【判定表】ロードアベレージの目安と危険水準（CPUコア数との関係）

「ロードアベレージが『5』を超えたら危険ですか？」という質問をよく受けますが、答えは「CPUのコア数による」です。

1コアのサーバーにおける「ロードアベレージ 5」は大渋滞ですが、16コアのサーバーにおける「5」はスカスカの健全な状態です。ロードアベレージは必ず「論理CPUコア数との比較」で判断してください。

ロードアベレージの適正値・目安一覧（1コアあたりの換算）

状態レベル	1コアあたりの数値	システムの状況	現場エンジニアが取るべきアクション
🟢 健全（正常）	0.7 未満	処理に十分な余裕がある状態。	静観でOK。定期モニタリングを継続。
🟡 注意（混雑開始）	1.0 前後	CPUリソースをちょうど使い切っている状態。	処理の遅延が始まっていないか確認。
🔴 危険（ボトルネック）	2.0 以上	待ち行列が発生し、明確な遅延が発生。	緊急調査が必要。I/O待ちかCPU枯渇かを特定。

💡 1分・5分・15分値の見方

uptime や top コマンドで表示される「1分前 / 5分前 / 15分前」の3つの数値の「変化の傾向」を見ます。

• 2.0, 1.5, 0.5（数値が上昇傾向）：現在進行形で負荷が急速に高まっている（緊急対応要）
• 0.5, 1.5, 2.0（数値が低下傾向）：スパイク的な負荷が過ぎ去り、沈静化に向かっている

なぜ「CPU使用率が低いのに重い」現象が起きるのか？3つの真因

現場で最も混乱しやすい「CPU使用率は低いのにレスポンスが極端に遅い」というトラブル。18年の経験上、原因は以下の3パターンに集約されます。

真因①：ディスクI/O待ち（D状態プロセスの発生）

先述の通り、Linuxのロードアベレージには「ストレージの読み書き待ち（Uninterruptible Sleep / D状態）」が含まれます。

データベースのフルスキャンや大量のログ書き込みが発生すると、CPUは「データの到着待ち」で手が止まるためCPU使用率は低くなりますが、待たされているプロセスで行列ができるためロードアベレージは激増します。

なお、ディスクI/O待ちが激増する最大の原因のひとつが「メモリ不足によるSWAP（スワップ）」です。メモリ枯渇がなぜストレージ遅延を引き起こすのか、そのメカニズムと正しい監視手法は以下の記事で詳しく解説しています。

真因②：シングルスレッドの限界（1コアだけ100%に張り付き）

• 事象：8コアのサーバーで、全体のCPU使用率は「25%」と表示されているのに、処理が遅い。
• からくり：全体平均で見ると25%ですが、コア別（top 実行中に 1 キー押下）で見ると「1つのコア（CPU0）だけが100%」に張り付き、残り7コアは暇を囲っている状態です。
• 原因：プログラムがマルチスレッドに対応しておらず、単一の処理（シングルスレッド）で動いているためです。この場合、いくらサーバーのコア数を増やすスケールアップを行ってもパフォーマンスは改善しません。

シングルスレッド限界に直面した場合、単純なコア追加では解決しません。トラブルを未然に防ぐ「適切なCPU数やスペックの割り出し方」や、経営層を納得させるサイジング計算式については以下の記事で解説しています。

真因③：コンテキストスイッチのオーバーヘッド（交通整理の限界）

多数のWebリクエストや小規模プロセスが一斉に立ち上がると、OSはミリ秒単位で処理するプロセスを切り替えます（コンテキストスイッチ）。

切り替え処理自体にCPUパワーが食われ、本来行うべきアプリの処理が進まなくなる「交通整理パニック」状態です。vmstat コマンドで cs（Context Switch）の数値が異常に高い場合はこれを疑います。

ロードアベレージの「中身」がわかる！OSの挙動を実験で学ぶ大人気書

「CPU使用率やロードアベレージの数値の裏で、Linuxがどう動いているのか」を視覚的に理解するなら、『［試して理解する］Linuxのしくみ』が一番の近道です。

プロセスがどうCPUを奪い合い、なぜ待ち行列（ロードアベレージ）が発生するのかが豊富な図解と実験で分かります。コマンドの結果を脳内でビジュアル化できるようになりたい若手エンジニア必読の1冊です。

クラウド・コンテナ時代の新常識：Steal TimeとCFSスロットリングの罠

オンプレミス環境と異なり、AWSやDocker等のモダン環境では「OSのメトリクスが正常に見えても裏で制限されている」ケースがあります。

クラウドの「盗まれた時間（Steal Time）」

AWS EC2などの仮想環境で top を実行した際、%st（Steal Time）の数値を確認してください。

• Steal Timeとは：物理ホストが他の同居仮想マシン（隣人）にCPUを割り当てたため、自インスタンスが処理権限を奪われた時間。
• 注意点：自サーバー内で何も重い処理をしていなくても、クラウド事業者のバースト制限や他VMの影響で突然パフォーマンスが低下します。

コンテナの「CFSスロットリング」

DockerやKubernetes環境では、CPU使用率が50%程度でもレスポンスがミリ秒単位で遅延することがあります。

• 原因：CFS（Completely Fair Scheduler）クォータ機能により、コンテナに設定されたCPUリミットを短時間に使い果たすと、OSが強制的にプロセスを一時停止させるためです。
• 対策：秒単位の「平均CPU使用率」には現れにくいため、コンテナ専用のメトリクス（スロットリング発生回数）を監視する必要があります。

USEメソッドによる体系的ボトルネック診断手順

パフォーマンス分析の世界的権威であるブレンダン・グレッグ（Brendan Gregg）氏が提唱する「USEメソッド」をCPU監視に適用することで、勘に頼らない論理的な調査が可能になります。

トラブル発生時のプロの調査手順（3ステップ）

1. uptime でロードアベレージを確認（【状況確認】）➔ コア数を超えているか？（超えていなければ正常稼働中。超えていれば混雑が発生中）
2. top で内訳を確認（【追加調査】）
   • %wa（iowait）が高い ➔ ディスクI/O待ち（ストレージの追加調査が必要）
   • %st（steal）が高い ➔ 外部要因による処理待ち（クラウド・物理ホスト側の調査が必要）
   • %usr / %sys が高い ➔ アプリ・OSの計算負荷が高い（ステップ3へ）
3. top 実行中に 1 キーを押し、コアごとの偏りを確認（【詳細調査】）
   • 1コアだけ100% ➔ シングルスレッドの限界（アプリ側のスケールアウト等が必要）
   • 全コア高負荷 ➔ 純粋なCPU能力不足（CPUのスケールアップが必要）

USEメソッドの提唱者が描く、システムパフォーマンス分析の最高峰バイブル

今回紹介した「USEメソッド」の提唱者であるブレンダン・グレッグ氏の世界的名著が、この『詳解 システム・パフォーマンス 第2版』です。

CPUやロードアベレージの数値の裏で、OSやハードウェアがどう動いているのかが徹底的に網羅されています。このメソッドの本質を学び、システム全体のボトルネックを迷わず特定できる一生物のスキルを身につけたいなら、間違いなく究極の一冊です。

まとめ：数字の裏側にある「OSスケジューラの論理」を読もう

CPUのパフォーマンス分析とは、単に top コマンドの一番上に出る「CPU使用率」の数字を報告することではありません。

18年のインフラ運用経験から断言できるのは、「標準ツールの出力を正しく組み合わせて見れば、原因を特定できないパフォーマンス問題はほとんど存在しない」ということです。

• 「%」を見る時は、計算機としての限界（CPU使用率）を知る
• 「個数」を見る時は、システム全体の混雑度（ロードアベレージ）を知る
• ロードアベレージが高い時は、まず「ディスクI/O待ち（%wa）」を疑う

ぜひ今日から、表面的な「平均値」という言葉を疑い、数字の裏にあるOSの論理を解明してみてください。