macOS 26「Tahoe」へのアップデート後、多くのユーザーがシステム全体に及ぶ深刻なパフォーマンス低下に直面した。原因は、VS CodeやSlackなど著名なアプリで広く採用されるフレームワーク「Electron」にあったのだ。

AD

macOS 26 Tahoeで広がる「謎の遅延」の正体

2025年9月にリリースされたmacOS 26「Tahoe」は、新たなデザイン言語「Liquid Glass」を導入するなど、意欲的なアップデートとして注目を集めた。しかし、その直後から、一部のユーザーコミュニティで奇妙な現象が報告され始めた。

「M1 Max搭載のMacBook Proなのに、ウィンドウを動かすだけでカクつく」
「Discordを開いていると、Chromeでのスクロールまで重くなる」

特定のアプリケーション、特にVisual Studio Code (VS Code)、Slack、Discord、Microsoft Edgeといった、日常的に多くのユーザーが利用するアプリを実行していると、システム全体の動作が著しく遅くなるというのだ。 奇妙なことに、これらのアプリが最前面になくても、ただ起動しているだけで（最小化されていなければ）問題は発生した。

当初、多くのユーザーはOS自体のバグや、自身のハードウェアとの相性問題を疑った。アクティビティモニタを確認しても、CPUやGPUの負荷率は一見すると低いままで、原因の特定は困難を極めた。 しかし、開発者コミュニティによる粘り強い調査の結果、問題の根源が共通の技術基盤、すなわち「Electron」フレームワークにあることが突き止められた。

問題の核心：Electronが踏み入れた「禁断のAPI」

このパフォーマンス問題の直接的な原因は、macOSのウィンドウ描画を司る中核プロセス「WindowServer」の異常な動作にあった。そして、その引き金を引いたのが、Electronフレームワーク内部に長年存在していた、ある「ハック」だったのである。

WindowServerとプライベートAPI _cornerMask

macOSにおいて、画面上に表示されるすべてのウィンドウ、影、アニメーションは「WindowServer」というプロセスが一手に管理している。いわば、macOSのグラフィック表示における心臓部だ。

一方、Appleは開発者に対し、OSの機能を利用するための公式な手順、すなわち「公開API (Public API)」を提供している。しかし、その裏にはAppleが内部的に使用し、将来的な変更の可能性があるため外部開発者の利用を想定していない「プライベートAPI (Private API)」が存在する。メソッド名の先頭にアンダースコアが付くのがその慣例であり、今回の主犯格である_cornerMaskもその一つだ。

GitHub上の開発者の分析によれば、Electronは過去のmacOSでウィンドウの角丸や影（Vibrancy効果を持つビュー）を滑らかに表示させる目的で、このプライベートAPIである_cornerMaskを意図的にオーバーライド（上書き）していた。 これは当時、公開APIだけでは実現が難しかった表現のための、いわば「裏技」的な実装だった。

macOS Tahoeで裏目に出た「古いハック」

長年問題を起こさなかったこの実装が、macOS Tahoeで突如として牙を剥いた。開発者の推測によれば、AppleはTahoeのWindowServerで、ウィンドウの影の描画処理を効率化するための最適化（一種のキャッシュ技術であるメモ化）を導入した。

WindowServerはこの最適化を行う際、アプリが標準の描画処理を使っているかどうかを、メソッドの実装がAppKitの標準実装と同一か否かで判断している。 しかし、Electronは_cornerMaskをオーバーライドしていたため、たとえ中身が親クラスのメソッドを呼び出すだけの単純なものであっても、WindowServerは「カスタムされた描画処理だ」と判断。 結果として最適化のキャッシュが効かなくなり、ウィンドウの影を繰り返し再計算・再描画し続けるという非効率な状態に陥った。

これが、CPU負荷は低いにもかかわらずGPU（特にWindowServerプロセス）に異常な負荷がかかり、システム全体の描画が遅延する現象の正体である。

AD

迅速な解決：Electronチームによる修正とその意味

問題が明らかになると、Electronコミュニティの対応は迅速だった。

_cornerMaskオーバーライドの削除

原因を特定した開発者avarayrは、問題の_cornerMaskのオーバーライドを単純に削除するという修正案を提示した。 幸いなことに、この「ハック」が導入された当時とは異なり、現代のmacOSでは標準のAppKitでもウィンドウの角丸は十分に滑らかに描画されるため、このコードを削除しても視覚的なデメリットはほぼ存在しなかった。

この修正は直ちにElectronのメンテナーに承認され、メインブランチにマージされた。 さらに、現在サポートされている旧バージョンにもバックポート（遡及適用）された。修正が適用された主なバージョンは以下の通りだ。

  • v39.0.0-alpha.7
  • v38.2.0
  • v37.6.0
  • v36.9.2

これにより、Electronフレームワーク自体における問題は解決された。

ユーザーが恩恵を受けるにはアプリの更新が必須

重要なのは、Electronフレームワークが修正されても、ユーザーが使っているVS CodeやSlackなどのアプリケーションが自動的に治るわけではない、という点だ。

アプリケーションの開発者は、修正版のElectronフレームワークを使って自社のアプリを再ビルドし、アップデートとしてユーザーに配布する必要がある。 ユーザーとしては、利用しているElectronベースのアプリのアップデートを注意深く確認し、速やかに適用することが唯一の根本的な解決策となる。

有志によって、インストール済みのアプリが使用しているElectronのバージョンを一覧表示するスクリプトも公開されており、自身が影響を受けるかどうかの確認に役立つだろう。

プライベートAPIを巡る議論：Appleの責任か、開発者の問題か

この一件は、プラットフォームにおけるプライベートAPIの利用について、改めて大きな議論を巻き起こした。

  • Appleの品質保証（QA）への疑問: 多くの開発者は、VS CodeやSlackなど、Macプラットフォームで絶大なシェアを持つアプリケーションに影響する重大な問題を、なぜAppleのQAチームが見過ごしたのかと疑問を呈している。
  • 開発者の事情: 一方で、Electron開発者がプライベートAPIを使ったこと自体を非難するのは早計だという意見もある。Appleが公開APIで必要な機能を提供しない場合、開発者はユーザー体験を向上させるために、リスクを承知でプライベートAPIに頼らざるを得ないことがあるからだ。
  • プラットフォームの互換性ポリシー: Microsoftが過去のWindowsで、特定のアプリケーションとの互換性を維持するためにOS側に特別なコードを追加してきた歴史と比較し、Appleの互換性に対する姿勢を問う声もある。 Appleは伝統的に「プライベートAPIの利用は自己責任」というスタンスだが、その線引きがプラットフォームの健全性にどう影響するかは、今後も議論が続くだろう。

筆者としては、どちらか一方に全ての責任を押し付けるのは適切ではないと考える。Appleは主要なサードパーティアプリでのテストを拡充すべきであり、同時に開発者コミュニティも、プライベートAPIへの依存がもたらす長期的なリスクを常に評価し続ける必要があるのではないだろうか。

Sources