WindowServer高CPU：ディスプレイ・キャプチャ・拡大縮小

パフォーマンス公開日 更新日 約9分で読めます

WindowServer は macOS のディスプレイ合成プロセスです。CPU 使用率は、各アプリの画面をディスプレイ上に合成する作業量を反映しますが、プロセス名だけでは、どのアプリが繰り返し再描画しているかは分かりません。アニメーション、画面共有、ディスプレイ変更中の一時的な上昇は正常です。役に立つシグナルは、アイドル時に負荷が続き、しかも反応の鈍さ、発熱、バッテリー消耗として現れていることです。

WindowServer の実態

WindowServer は、アプリが描いた内容を各ディスプレイの最終画像にまとめます。ウインドウ、メニュー、Dock、透明度、アニメーション、外付けディスプレイ出力はすべてここを通ります。そのため、アプリのグラフィック負荷の一部はアプリ自身ではなく WindowServer の下に現れます。高い数値だけでは原因を特定できません。だから WindowServer を強制終了するのは最初の一手として誤りです。macOS がすぐ再起動し、すべてが再描画され、どのサーフェスがフレームを送り続けていたかは依然として分かりません。

何が負荷を押し上げるか

次のような要因で WindowServer は忙しくなります。

  • 多数のウインドウとスペース。 何十もの開いたウインドウと仮想デスクトップは、すべて追跡と合成が必要です。ディスプレイごとに個別の操作スペース がオンだと、Mission Control のスペースがサーフェス数をさらに増やします。
  • 外付け・高解像度ディスプレイ。 押し出すピクセルが増え、とくに 4K や 5K、複数モニタ同時接続では基準負荷が着実に上がります。クラムシェル（ふたを閉じた）運用でも、接続された各パネルは合成されます。
  • スケーリング解像度。 非ネイティブの「見た目」解像度では、より大きな描画面を作ってから縮小することがあります。コストは Mac、ディスプレイ、スケールモード、作業内容次第で、Retina スケーリング自体は正常です。
  • 透明度とモーション。 メニュー、Dock、コントロールセンターのぼかしと半透明は、WindowServer が継続的に計算するライブ効果です。最近の macOS ではシステム UI 効果が重くなり、同じ場面でも以前よりコストが上がることがあります。
  • ブラウザやその他の Electron アプリ。 アニメーション、動画、WebGL、動きの多いダッシュボードがあるタブやウインドウは、見ていなくてもフレームを送り続けます。Chrome、Edge、Brave、Arc、Slack、Discord、VS Code などは、GPU 合成の仕事が結局 WindowServer に乗るため、ユーザー報告に頻出します。
  • ウインドウが多く常に再描画するアプリ。高速出力するターミナル、毎秒更新するステータスバー、背景でアニメーションするページなどです。
  • キャプチャとリモート表示ソフト。 画面収録、ビデオ通話、AirPlay、Sidecar、連係カメラ、リモートデスクトップ、仮想ディスプレイツールは、キャプチャや合成の仕事を増やします。
  • 高リフレッシュレートと動くデスクトップ。 フレームが増えたり、ピクセルが絶えず変わったり（ダイナミック壁紙、ステージマネージャの頻繁な切替、ライブウィジェット）すると、ウインドウに触れていなくても負荷が上がります。
  • 常時表示のリソースモニタ。 開きっぱなしのアクティビティモニタ、メニューバーの CPU グラフ、UI を頻繁に更新させるツール自体が合成器を忙しくします。sysmond も高いときは、いったんモニタを閉じてから WindowServer を再確認してください。

古い独立 GPU ドライバは Windows ではよくある話です。Apple silicon Mac では GPU スタックは macOS に含まれ、「GPU ドライバを更新する」はほとんど道ではありません。macOS と疑わしいアプリを最新に保つ方が先です。

高い WindowServer CPU が正常なとき

次の場面では短いスパイクが予想されます。

  • 多数のウインドウを開く・リサイズする、スペースを切り替える、ディスプレイを接続する
  • フルスクリーン動画、ゲーム、タイムラインのスクラブ
  • 画面共有や画面収録
  • 前面で UI の多いページをアニメーションさせる

場面が落ち着いたら、これらのバーストは下がるはずです。静かなデスクトップでも高く続く、入力中にカーソルが引っかかる、ファンやバッテリー消耗が合成器に連動するのに明らかな再描画源がない、といったときは問題として扱います。

アクティビティモニタで診断する

設定を変える前に基準値を取ります。

  1. アクティビティモニタ（アプリケーション › ユーティリティ）を開き、CPU タブで WindowServer を検索します。
  2. 静かなデスクトップで 1〜2 分のパーセンテージを記録します。見えるウインドウは少なく、画面共有なし、動画なし、ブラウザタブはアイドルか破棄済み。
  3. 遅さをもう一度再現し（重いブラウザウインドウ、キャプチャ開始、外付けディスプレイ復帰）、その変化に合わせて WindowServer が上がるかを見ます。
  4. CPU で並べ替え、ブラウザヘルパー、会議アプリ、画面収録ツール、仮想ディスプレイらしい名前をざっと見ます。先頭のアプリが容疑者で、WindowServer はその描画の請求書であることが多いです。
  5. 任意：ターミナルで top -o cpu を 30 秒。同じ順位が取れ、アクティビティモニタ自身のウインドウを開きっぱなしにしなくて済みます。

WindowServer は症状で判断します。入力が滑らかになる、熱が下がる、バッテリーが持ちやすくなる、です。数値が下がっても見た目や熱が改善しないなら、有用な修正ではありません。

落ち着かせる手順（軽いものから強いものへ）

まず安い勝ちを先に。変数は一つだけ変え、待ち、指標と体感の両方が良くなったときだけ残します。

  1. 使っていないウインドウ、タブ、スペースを閉じる。 ブラウザウインドウをまとめ、アイドルタブを破棄し（Chrome/Edge の メモリセーバー またはブラウザのタスクマネージャ）、使わないスペースを減らします。ブラウザを開いているときは、通常これが最大の削減です。
  2. 透明度を下げる： システム設定 › アクセシビリティ › ディスプレイ を開き、透明度を下げる をオンにします。Apple のディスプレイ設定ガイドが見た目の変化を説明しています。macOS を最新に保ってください。途中のビルドではこのトグルがほぼ効かず、後のパッチで効くことがありました。同じ場面で比較してから、性能対策として残します。
  3. 動作を減らす： いまは アクセシビリティ › モーション に専用パネルがあります。Apple のモーションガイドによると、アプリを開く、デスクトップを切り替えるなどのアニメーションが変わります。
  4. キャプチャとリモート表示を止める。 画面収録を止め、会議のカメラ／共有をオフにし、Sidecar や AirPlay を外し、仮想ディスプレイツールを一つずつ終了します。
  5. デスクトップを簡素化する。 アニメーションやダイナミック壁紙を静止画にし、メニューバーを再描画し続けるライブウィジェットや常時 HUD オーバーレイを隠すか終了します。
  6. ディスプレイのスケールとリフレッシュレートを試す。 既定の「見た目」サイズ、または外付けの低いリフレッシュレートを試し、同じ負荷で比較します。スケーリングはすべて悪い、という前提だけで読みやすい文字を犠牲にしないでください。
  7. 診断のためにディスプレイを 1 台外す。 基準が下がったら、そのディスプレイのスケール、リフレッシュレート、ケーブル、アダプタを個別に試します。マルチモニタでは、デスクトップと Dock › Mission Control の ディスプレイごとに個別の操作スペース をオフにし、独立した合成コンテキストを減らしてみます。
  8. macOS と重いアプリを更新し、同じアイドル場面を再テストします。合成器やブラウザ GPU の不具合は、普通のポイントリリースに入ることが多いです。
  9. ログアウトして再ログインは証拠を集めたあとに。ユーザーの表示セッションが再起動します。フル再起動は漏れた再描画状態を消しますが、再び引き起こすアプリを隠すこともあるので、パターンが分かってから使い、隔離の代わりにはしません。

役に立たないこと

  • WindowServer を強制終了しない。 画面上のすべてが一度に再描画され、CPU が再び跳ね、所有者については何も分かりません。
  • 汎用の「クリーナー」や「ブースト」アプリで合成負荷が直ると思わない。 ウインドウを閉じる、効果を減らす、キャプチャを止めるのが本当のレバーです。
  • 普通の Retina スケーリングを故障扱いしない。 同じ Mac と同じケーブルで、実際に使っているスケールモードと既定を測り比べます。

内部：合成器と、スケーリングがコストになる理由

WindowServer は合成器です。各アプリは自分のオフスクリーンバッファ（backing store）に描き、WindowServer がそれらを各ディスプレイの最終画像にまとめ、変換と効果を適用します。場面が変わると合成が走るので、絶え間ない再描画やキャプチャは CPU や GPU を継続的に使います。一部のスケールモードは大きな中間面を作ってから縮小しますが、それは要因の一つにすぎません。ピクセル数、リフレッシュレート、ディスプレイ数、再描画頻度は独立に試す必要があります。

複数のアプリ backing store が合成器に入り、1 枚の表示画像を出力する。スケーリング解像度は大きく描いてからパネルのネイティブ画素へ縮小する様子。
WindowServer は各ディスプレイ向けにアプリのサーフェスを合成します。スケーリング、リフレッシュレート、キャプチャ、繰り返しの再描画は、いずれもこの合成パイプラインの仕事を増やし得ます。

モニタが役立つところ

アクティビティモニタや Mole の「ステータス」表示は、WindowServer、CPU、GPU の推移を見せますが、合成コストを自動で 1 つのアプリに割り当てることはできません。確実な方法は制御された隔離です。再描画源を 1 つ止めるか、表示変数を 1 つ変え、アイドルと負荷の基準を比較します。

繰り返しできる診断

アイドル時と問題発生時に WindowServer を測り、アニメーション内容、ブラウザ、キャプチャツール、ディスプレイ、スケール、リフレッシュレートを一つずつ隔離します。指標とユーザーに見える症状の両方が改善したときだけ変更を残します。WindowServer を強制終了せず、普通の Retina スケールを故障扱いしないでください。

よくある質問

WindowServer の高 CPU は危険ですか？

発熱、ファン音、バッテリー消耗を上げ、UI を引っかかりやすくしますが、マルウェアではなく、それ自体で Mac を壊しません。再描画の原因を直してください。プロセスを削除したり無効にしたりしないでください。

Chrome は問題なさそうなのに WindowServer が高いのはなぜ？

ブラウザの仕事は、合成用サーフェスを提出するため、しばしば WindowServer に乗ります。アニメーションや動画のあるバックグラウンドタブは、Chrome 自身のヘルパー使用率が控えめでもフレームを送り続けます。それらのタブを中断または閉じてから再確認してください。

Apple silicon でも透明度を下げるべきですか？

制御された試験として試してください。多くの M シリーズ Mac は、透明度とモーションを下げると、とくに複数ディスプレイや複数ブラウザウインドウで、まだ合成作業が減ります。同じアイドル場面が良くなったときだけ設定を残します。

再起動で WindowServer は永久に直りますか？

再起動は一時的な再描画状態を消し、しばらく効くことが多いです。同じブラウザウインドウ、キャプチャツール、ディスプレイ構成で負荷が戻るなら、構成が原因です。そちらを直し、セッションがすでに悪い状態のときだけ再起動してください。