5 ポイント 投稿者 GN⁺ 2025-08-01 | 2件のコメント | WhatsAppで共有
  • MacBook Pro Silicon M1 Max夜通しバッテリー消費の現象を体験
  • 電源管理ログを直接分析しようと試みたが、問題の原因特定には限界があった
  • 専用アプリのSleep Aidを使って、ウェイクイベントを視覚的に確認できた
  • Sleep Aidの設定で「Wake for maintenance(メンテナンス目的で起動)」が無効になっていることが原因であると判明
  • 該当オプションを再び有効化した結果、夜通しのバッテリー消費現象が解消された

MacBook Proでの夜通しバッテリー消費問題

  • 数年間 MacBook Pro Silicon M1 Maxを使い続けてきた
  • 最近、予期せずノートPCを電源に接続せずに置くと、夜通しでバッテリー消費が増える症状が現れ始めた
  • 症状が次第に悪化し、原因分析を自ら開始した

電源管理ログ分析を試す

  • MacOSのターミナルコマンド pmset -g log を通じて電源管理関連のログを確認できる
  • しかしこのログの出力は膨大で解釈が難しかったため、ログ解析用に直接開発したシンプルなツール pmset-analyzer を使用した
  • ただし、このツールだけでは実質的な解決には大きな助けにならなかった

詳細設定の調整と追加調査

  • 公式ドキュメントやコミュニティで案内されている tcpkeepalive などの電源管理設定を一つずつ調整してみた
  • 設定変更だけでは問題解決に大きな効果がなかった

Sleep Aidアプリによる問題解決

  • 追加調査の過程で Sleep Aid というアプリを知った
    • このアプリは**ウェイクイベント(wake event)**を視覚的に表示し、各種電源管理設定を直感的に変更できるインターフェースを提供する
  • Sleep Aidで確認したところ、"Wake for maintenance(メンテナンス目的で起こす)" オプションが無効化されていた
  • アプリの説明どおり、この設定が無効のままだと頻繁なウェイクイベントが発生する場合がある
  • 該当オプションを再び有効化して以降、夜通しのバッテリー消費現象は発生しなくなった

2件のコメント

 
ahwjdekf 2025-08-02

MacBook Pro のスリープ問題

MacBookをスリープモードにして寝ていたのに、突然夜中に画面が点いて部屋中が明るくなります。寝ていて目が覚めて、そのまま完全にシャットダウンしたことが何度もあります。これ、いつからか論争の種になっていたのに、まだこんな状態なんですね……

 
GN⁺ 2025-08-01
Hacker Newsのコメント
  • また一つ便利なヒント。Activity MonitorでEnergyタブを開き、"Preventing sleep"列で並べ替えると、どのアプリがmacOSのスリープを妨げているか確認できる。自分の場合はDevonthinkアプリが原因だと分かった。まだバグレポートは出していない。Appleの電源管理機能がこうした問題をユーザーに知らせないのは不思議だ。Macがバッグの中で熱くなってバッテリーを使い切る状況は重要な問題ではないのだろうか。その一方で、Chromeがネットワークデバイスの検出を許可するかどうかを繰り返し尋ねてくる方が、よほど重要度は低いように思える
    • Appleの電源管理がこれについて警告しないのも驚きだが、ふたを閉じてもアプリがシステムのスリープを妨げられることの方がさらに驚きだ。動画プレーヤーのように、タイムアウトベースのスリープ防止が時には必要なのは理解できる。だが、ふたを閉じたりスリープボタンを押したりしたときに、システムを眠らせないかどうかをアプリが決められる実用的な例はほとんどない。たいていは、結果としてリュックの中で過熱したノートPCを持ち歩く可能性を高めるだけだ。しかも、Webページ一つだけでもシステムのスリープ移行を妨げられるとなると、70個あるタブのどれが原因かを見つけるのは難しい。タイムアウトベースのスリープ防止権限と、"ふたを閉じたら必ずスリープ"のようなコア動作を変更する権限は分けた方がいいと思う。タイムアウトの利用は許可しても、ふたを閉じる動作のようなものは必ずユーザーに通知し、許可を得るべきだ
    • 任意のアプリがシステム全体のスリープを妨げられるとは知らなかった。こうした権限はユーザーの管理下にあるべきだ。開発者がこの種のAPIを呼び出すには、少なくともentitlementが必要であるべきではないかと思う
    • shellで pmset -g assertions コマンドを使うと、どのプロセスがシステムのスリープを妨げているか分かり、保留中のpower assertionの詳細も確認できる。pmset には公式ドキュメントにないコマンドもあり、Appleが公開しているソースコードを見ると分かる。特定のassertionを無視させるコマンドもある。ただし、"UserIsActive" assertionを無効にすると、システムを復帰させるのに苦労するかもしれない
    • こんな機能があるとは知らなかった。ありがとう。最近、使っていなかったMacBookのバッテリーがなぜ減り続けるのか不思議だったが、調べてみるとFirefoxがスリープを妨げていた。自動再生動画が原因らしい。完璧ではないが、直せる類いの問題だ
    • Safariは一方で、Netflixを視聴中に電力消費が多いので閉じるよう通知を出してくる
  • 自分のMacBook Proでも似た現象があった。Apple Siliconモデルではなく、その前のモデルだ。当時、ルーターでDHCPリース時間をデフォルトよりかなり短い15分に変更していた。自分の考えでは、MacBookが15分ごとにIP更新のために目を覚まし、少し眠ってはまた起きることを繰り返していたのだと思う。ルーターのリース時間を元のデフォルトに戻したところ、バッテリー消耗の問題は完全に解消した。その原因を予測するのは難しかったが、ちょうど新しいMacBook Proを買った直後で、いろいろな問題に敏感になっていたおかげで早く見つけられた
    • きちんと動作するDHCPクライアントは、リース時間の50%が経過した時点で更新要求を送る。つまり、思っているよりもっと頻繁に起きていた可能性が高い
    • DHCPリース時間を15分に変えた理由が気になる。何か目的があったのだろうか
    • 自分も今知ったのだが、使っているmikrotikルーターはデフォルトで10分のリース期間を使っている
    • この現象は本当に興味深い。一度IP更新のために起きるたびに、どれくらいのmAhを消費するのか気になる。数ミリアンペア・ミリ秒程度な気もするが、結局のところノートPCはWiFiを少しの間有効にして、数個のパケットをやり取りする程度だろう。もちろん、Apple Silicon以前のモデルなので、実際には起きている間にほかのこともしていた可能性はある
    • これはmacOSのバグだと思う。スリープ中ならIPは不要なのだから、DHCPリース更新のために起きるのはおかしい。ソースが公開されていないOSはこういう点で問題だ
  • “Wake for maintenance” オプションがオフだと、Sleep Aidではそのために頻繁に起きる可能性があると設定画面で案内している。著者は誤って「オプションがオフだった」と書いたのではないかと思う
    • 自分もそう思った。推測だが、この設定がオフだと、起床イベントが時間ごとにまとめて一括処理されず、夜の間にばらばらのタイミングで何度も発生するのかもしれない。まさにその現象を説明しているように見える
    • 混乱する。明示的にコンピュータを起こすオプションを有効にすると、むしろ起きる回数が減るのだろうか
    • 自分も混乱している。著者のスクリーンショットではEnable状態だ。それが「正常」に見えるのに、Disabledの方がなぜWakeを増やすのか直感的にはよく分からない
    • こういう常識に反する説明には補足が必要だし、少なくともそうした例外であることを明確に示してほしい。記事を書いたあとで修正する際、こういう問題は見落としやすい
  • これまで使ってきたすべてのMacラップトップで、ふたを閉じたときは常にhibernateに設定して問題を回避してきた。再び使うためにふたを開けたとき、復帰に20〜30秒ほどかかるが、スリープやバッテリー消費を気にする必要が大幅に減るなら小さな代償だと思う。ターミナルではこのコマンドで設定できる: sudo pmset -a hibernatemode 25。元に戻すには sudo pmset -a hibernatemode 3 を入力すればよい
    • hibernateモードがFDE(フルディスク暗号化)とうまく動くのか気になる。Linuxでは、メモリ内容をディスクに書き出す過程で暗号化に関する注意点がいろいろある
    • これは、多くの人が期待する動作をもっとも手軽に設定する方法だと思う
  • MacBookのスリープ問題を本当に長い間掘り下げてきたが、原因はWindowServerで、結局はOSの完全再インストールが必要になりそうだ。1〜2か月に一度、バッグの中で熱くなって電池切れになったノートPCを取り出すことと同じくらい腹立たしいのが、「自分はそんなことになったことがないが、何か使い方を間違えているのでは?」という反応だ
  • MacOSはこの10年、ほとんどメンテナンスモードのままのように感じる。ARM/Mac Siliconへの移植作業は膨大だったのだろうと思う。AIアップデートも期待外れだったし、最近は実質的な改善があまりなかった印象だ。以前、電源ボタンがBackspaceの隣にあるIntel Macbook Airを使っていたことがあり、電源ボタンを一回押しただけではすぐにシャットダウンしないよう、長押し必須にするスクリプトをMacフォーラムで見つけて使っていた。ところが、そのスクリプトにはトロイの木馬が仕込まれていて、Macの工場出荷時リセットとiCloudの全面削除が必要になったという。そのスクリプトには内部変数らしきGUIDもあり、どこだか分からない場所からリソースをダウンロードできたらしい。自分はただの内部変数だと思っていた
  • Apple公式サポート文書 を見ると、この機能(電源オプション)は標準で提供されている
    • macOS 26 DBが入ったM4 MacBook Airには、その場所にpower napがない。代わりに "Wake for network access" があり、デフォルトは "Only on Power Adapter" になっている
    • power napと "wake for network access" を同じものだと勘違いしていた。macOS 26では、もうそのオプション自体がないようだ。自分の設定は "Only on Power Adapter" になっていて、妥当に思える。M4 MacBook Airでの話だ
  • 自分もほぼ同じ内容のブログ記事を先週書いた。残念ながら自分の場合、その解決策は効かず、power nap以外の別のプロセスが起こし続けている。関連投稿: annoying.technologyの投稿
  • Activity MonitorのEnergyタブはこのような状況で役立つ。どのアプリがシステム全体のsleepを完全に妨げているか分かるし、各プロセスの過去12時間の電力消費も見られる。夜のうちにすぐ原因を追跡できる
  • 自分もMacBook Pro(Apple Silicon)で似た問題を抱えている。SSDを接続したままスリープさせると、システムが定期的に起きてドライブをアクティブ化しているようだ。その結果、ノートPCもSSDも熱を持ち、バッテリーもすぐ減る。唯一の対処法は、スリープ前にすべての外付けドライブを外し、充電器につないでおくことだけだ。かなり厄介なバグだ。品質管理とテストが不足していたのだと思う