macOS 27 で夜間にバッテリーが減る？スリープ中に Mac を起こす原因の調べ方

macOSTahoe ·
macOS 27 で夜間にバッテリーが減る？スリープ中に Mac を起こす原因の調べ方

macOS 27 でスリープ中にバッテリーが減る場合は、pmset の起床理由とアサーションを読み、replicatord と agentstored に対処し、Apple に送るべき情報を把握しましょう。

蓋を閉じたときは 100 パーセントだったのに、朝になると Mac は温かく、バッテリーは 40 パーセント、20 パーセント、あるいは完全に空になっている。macOS 27 Golden Gate が 9 月 14 日に公開されて以降、Apple のサポートコミュニティではこうした報告が繰り返し投稿されています。スリープ中、あるいは机の上で放置している間に MacBook が驚くほど充電を失い、しかも熱を持つというものです。よくある助言である「Spotlight の完了を待つ」「アプリをいくつか閉じる」は、アップデートから 3 週間が経っても一晩でバッテリーの 3 分の 1 を失っている人の助けにはなりません。このガイドでは別のアプローチを取ります。一般的なコツを並べるのではなく、macOS に組み込まれたログツールで Mac が夜間に実際に何をしていたかを計測し、出力の読み方と、パターンごとの対処法を紹介します。あわせて、報告されている 2 つの暴走プロセス replicatord と agentstored について、分かっていること・分かっていないこと、そして報告が実際に役立つように Apple へ何を送るべきかも取り上げます。

重要ポイント

  • 報告は実在しますが、Apple は認めていません。 Apple サポートコミュニティの主要スレッドでは、10 月 14 日時点で「私も」が 73 件、返信が 16 件あります。Apple の社員からのコメントはなく、Apple は 27.0.1 を単に不具合修正としか説明していません。
  • すべての Mac が影響を受けるわけではありません。 長年の常連投稿者は、16 インチ M4 Pro MacBook Pro で約 10 時間使用してもバッテリーが 50 パーセント残っていると報告しています。ご自身の Mac で計測してください。
  • 何かを変更する前に計測しましょう。 pmset -g log はすべてのスリープ、起床、DarkWake を理由付きで記録し、pmset -g assertions は今この瞬間に Mac を起こしている原因を表示します。
  • 起床理由は手がかりであって、結論ではありません。 メンテナンスによる起床は通常の動作です。調べる価値があるのは、15 分ごとの DarkWake や、数分間続く DarkWake というパターンです。
  • プロセスの事例は 2 つあります。 あるユーザーは、100 パーセントに張り付いた replicatord をデータベースファイルの名前変更で解消しました。agentstored には既知の解決策がありません。
  • クリーナー、SIP の変更、繰り返しのリセットは避けましょう。 慎重に計測しても改善しない場合は、sysdiagnose を添えて報告してください。

実際にどんな報告が出ているか

最も詳細な報告は、9 月 22 日に立てられた Apple サポートコミュニティのスレッド 「Severe Battery Drain and overheating on MacBook Pro M5 after upgrading to macOS 27 Golden Gate」 です。10 月 14 日に確認した時点で、「私も」が 73 件、2 ページにわたる返信が 16 件ありました。投稿者は MacBook Pro (M5 Pro、2026 年 5 月購入) を使っており、アップグレード前は一晩でほとんど充電が減らなかったと述べています。アップグレード後は、充電器を外して使っていなくても「by the next morning the battery can be completely drained」(翌朝にはバッテリーが完全に空になっていることがある) 状態で、アイドル中も本体が熱く感じられたとのことです。あるテストでは、スリープしているはずの約 16 時間で、おおよそ 100 パーセントから 1 パーセントまで減りました。

スレッド内のその他の報告です。いずれもユーザーの発言であり、当方では検証できません。

  • MacBook Air M5 の所有者は、バッテリー駆動時間が 10 時間超から 4～5 時間に落ちたと述べています。
  • 16 インチ M4 Pro の所有者は、2 日持っていたものが 6 時間になったと述べていますが、ボランティアが、添付のスクリーンショットではディスプレイが点灯しており、Mac はスリープしていなかったと指摘しています。
  • 27.0.1 を使う M3 MacBook Air の所有者は、使っていないのに「completely drained itself while not even using it」(使ってもいないのに完全に自己放電した) ことが 2 回あったと述べています。
  • 27.2 ビルドを使う MacBook Air M5 の所有者は、アップデートのたびに「got worse」(悪化した) と述べています。
  • MacBook Pro M5 の所有者は 10 月 8 日に、Wi-Fi と Bluetooth をオフにしても約 15 分ごとに Mac が DarkWake で起き、ログでは wifibt と SMC.OutboxNotEmpty が原因として示されると投稿しました。

2 つの注意点があります。まず、投稿者は 9 月 27 日に、「deprecated for this macOS version」(この macOS バージョンでは非推奨) のアプリをアンインストールしたら Mac が正常に戻ったと書いていますが、アプリ名は挙げていません。これは一事例であり、一般的な解決策ではありません。次に、Apple は macOS 27 のバッテリー問題を認めていません。スレッド内のボランティアは、Apple はこのフォーラムに参加していないと述べています。当方が見つけた唯一の公式な記述は、Apple のセキュリティリリースのページ にある 27.0.1 (ビルド 26A434、9 月 28 日) の説明ですが、バッテリー駆動時間には触れていません。

大型アップグレード後の通常の挙動 (とその期間)

メジャーアップグレードのたびにバックグラウンド処理が走ります。Spotlight がインデックスを再構築し、写真がライブラリを再解析し、iCloud が再同期し、Apple Intelligence 対応の Mac ではオンデバイスモデルのダウンロードが行われることもあります。初日に温かい Mac も、4 日目にはたいてい問題なくなります。

Apple は所要期間を公表していません。 Apple のサポートページを検索しましたが、見つかりませんでした。サードパーティのガイドには 72 時間といった数字がありますが、Apple を出典としているものはありません。所要時間は、ライブラリの大きさと、Mac が電源につながれたままアイドルしている時間の長さによって変わります。

兆候通常のインデックス作成の可能性が高い実際の問題の可能性が高い
アップグレードからの経過時間1～3 日主要スレッドのように 1 週間以上
熱の出どころMac を開いて電源につなぎ、席を離れたMac を閉じている、またはバッグの中、バッテリー駆動
プロセスmds_stores、photoanalysisd、cloudd が忙しいが、やがて落ち着く1 つのプロセスが何時間も CPU コア 1 つ分の 100 パーセントに張り付く
数日間の推移夜ごとに少しずつ改善横ばい、または悪化

個別の原因については、macOS 27 後の Spotlight 再インデックス、アップグレード後に 30 GB はどこへ消えたのか (主要スレッドのボランティアが、空き容量が 8 GB しかない Mac で急速な消耗が起きた例を挙げています)、Apple Intelligence が「準備中」で止まる問題 をご覧ください。また、あるコミュニティ投稿者は macOS 27 では Apple Intelligence をオフにできないと述べていますが、当方では確認できなかったため、これに基づく助言はしません。

ステップ 0：スリープの問題かどうかを確認する

  1. 管理されたテストを行います。 100 パーセントまで充電し、電源を外して蓋を閉じ、時刻を記録して、8 時間など決めた時間だけ放置します。開いたときの残量を書き留め、2 晩目にも繰り返します。
  2. 普段の環境のままにします。 Bluetooth マウスやドックはいつもどおりにして、実際の夜間の状態を再現します。
  3. Mac が本当にスリープしたか確認します。 スレッド内のボランティアは、スリープアサーションを持つものがあれば Mac は起きたままになるため、蓋を閉じても「may not put the laptop to sleep」(ノートパソコンをスリープさせないことがある) と指摘しています。バッグの中で起きたままの Mac は、急速にバッテリーを消耗し、熱くなります。

結果は「一晩中起きていた」「断続的に起きていた」「スリープしていたのに消耗した」のいずれかに分類できます。次のステップで、どれに当たるかが分かります。

計測ツールキット：4 つのコマンドと 1 つのアプリ

以下のコマンドはすべて macOS 自身のマニュアルページに記載されており、man pmset、man top などで読めます。ここでの構文は macOS 27.0.1 のマニュアルページに一致します。Apple が文書化していないログ形式を説明する部分については、その旨を明記します。pmset -g log の出力について、マニュアルは「a history of sleeps, wakes, and other power management events. This log is for admin & debugging purposes.」(スリープ、起床、その他の電源管理イベントの履歴。このログは管理とデバッグ用) としか説明していません。以下の個々の行の解釈は、情報に基づく読み解きであり、Apple の文書ではありません。

先に zsh の落とし穴を 1 つ。macOS の標準シェルでは log がシェル組み込みコマンドなので、log show は「too many arguments」で失敗します。例のとおり、必ず /usr/bin/log とフルパスで書いてください。

コマンド 1：pmset -g stats、1 行の概要

pmset -g stats

マニュアルは -g stats を「the counts for number sleeps and wakes system has gone thru since boot」(起動以降にシステムが経たスリープと起床の回数) を表示するものと説明しています。出力は 3 行で、Sleep Count、Dark Wake Count、User Wake Count です。これが最初の健全性チェックになります。1 日前に再起動したのに Dark Wake Count が数百になっていれば、Mac は頻繁に自分で起きています。主要スレッドの投稿者は「225 Sleep/Wakes since boot, and one sleep cycle showed 7 Dark Wakes」(起動以降 225 回のスリープ/起床、あるスリープサイクルでは 7 回の Dark Wake) と報告しています。

回数が多いからといって、自動的に悪いとは限りません。DarkWake はディスプレイをオフにしたまま Mac が数秒間バックグラウンド処理を行う部分的な起床で、Mac はメンテナンスのために日常的にこれを行います。スレッド内のボランティアは、ほとんどの DarkWake はバッテリーをほとんど使わず 1 分未満で終わること、自分の Mac で 15 分続いた DarkWake は異例だったことを述べています。これは一個人の観察ですが、肝心な点とは一致します。回数は調べるべきかどうかを教え、継続時間と理由は何を見ているのかを教えてくれます。

コマンド 2：pmset -g log、スリープと起床の履歴

pmset -g log | awk '$4=="Sleep"||$4=="Wake"||$4=="DarkWake"' | tail -60

ログは数万行に及ぶことがあり、その大半は電源アサーションです。上のフィルターは Sleep、Wake、DarkWake のエントリだけを残します。フォーラムのボランティアは、スペースを 2 つ入れた短い grep である grep -E 'Sleep |Wake ' を投稿しています。種類の列が空白で埋められているため動作しますが、アサーションの要約行もいくつか拾ってしまうので、awk 版のほうがすっきりします。残った各行は、日付、時刻、タイムゾーンで始まり、続いてイベントの種類、詳細が並びます。

macOS 27 で正常な夜間のシーケンスは次のようになります。内容は分かりやすいよう軽く編集しています。

09:00:41 Sleep      Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using Batt (Charge:100%) 31 secs
09:01:12 DarkWake   DarkWake from Deep Idle [CDNP] : due to smc.sysState.Wake(0x70070000) USB-C_plug SMC.OutboxNotEmpty Using BATT (Charge:100%) 0 secs
09:01:13 Sleep      Entering DarkWake state due to 'Notification Wake Back to Sleep':TCPKeepAlive=active Using AC (Charge:100%) 108 secs
09:03:01 Wake       DarkWake to FullWake from Deep Idle [CDNVA] : due to UserActivity Assertion Using AC (Charge:100%)

各行を左から右へ読みます。

  • イベントの種類。 Sleep は Mac がスリープに入る、または DarkWake に戻ることです。DarkWake はディスプレイを伴わない起床、Wake は完全な起床です。Entering ... state due to 'Reason' は、なぜスリープに入ったかを示します。
  • 引用符内の理由。 Maintenance Sleep、Sleep Service Back to Sleep、Notification Wake Back to Sleep は、Mac がバックグラウンドのセッションを終えたことを表します。Clamshell Sleep は蓋が閉じられたことです。Idle Sleep と Software Sleep はタイマーまたはアプリの要求によるものです。
  • TCPKeepAlive=active。 Mac がスリープ中も TCP 接続を維持していたことを意味し、tcpkeepalive の設定が 1 の場合の標準的な動作です。
  • 「due to」の後の起床理由。 最も重要な文字列です。例は、この記事の後半の表で扱います。
  • Using BATT または Using AC と、括弧内の充電量。 その時点の電源と、バッテリー残量のパーセンテージです。夜間を通して Charge の値を比べれば、サードパーティ製ツールなしで消耗カーブが得られます。
  • 末尾の秒数。 Apple は文書化していませんが、直前までいた状態にどれだけ留まったかを表しているようです。Sleep ... 31 secs で終わる DarkWake は約 30 秒起きていたことになり、数百秒で終わるものは数分間起きていたことになります。

ログを消耗カーブにするには、時刻、イベントの種類、充電量だけを出力します。

pmset -g log | awk '$4=="Sleep"||$4=="Wake"||$4=="DarkWake" {match($0,/Charge:[0-9]+%/); print $1,$2,$4,substr($0,RSTART,RLENGTH)}' | tail -80

1 時間あたりの DarkWake の回数を数えると、15 分周期のリズムがはっきり分かります。

pmset -g log | awk '$4=="DarkWake"{print $1, substr($2,1,2)":00"}' | sort | uniq -c | tail -24

きちんとスリープする Mac では、1 時間に数回の DarkWake が見られる程度です。主要スレッドの 10 月 8 日の報告、つまり MacBook Pro M5 が夜間も日中も約 15 分ごとに起きていた件は、1 時間あたり 4 回の一定の頻度として現れ、個々の起床には 20 秒以上続くものもあるはずです。これだけでは決め手になりませんが、説明をつけるべきリズムです。

コマンド 3：Wake Requests、次の起床を要求したのは誰か

同じログには、予定された起床要求、つまり Mac が自分で計画した将来の起床も記録されています。短縮するとこのように見えます。

pmset -g log | grep "Wake Requests" | tail -3
Wake Requests  [process=mDNSResponder request=Maintenance deltaSecs=7198 wakeAt=... info="upkeep wake"]
               [process=dasd request=SleepService deltaSecs=1016 wakeAt=... info="com.apple.dasd:501:..."]
               [process=powerd request=TCPKATurnOff deltaSecs=316236 wakeAt=...]

各かっこが 1 つの要求です。要求した process、request の種類、現在から何秒後か (deltaSecs)、自由記述の info 文字列が含まれます。これは、システムが提供する容疑者リストに最も近いものです。dasd のエントリは Duet Activity Scheduler で、バックグラウンドタスクをスケジュールし、それを実行するために Mac を起こすことがあります。長い info 文字列はタスク名を示します。主要スレッドでは、ある投稿者が自分のログに現れたタスクとして、com.apple.intelligenceflow.toolbox.update.fastpass、スクリーンタイムの履歴クリーンアップ、PowerUIAgent のメンテナンスを挙げています。これらは一人の Mac のタスク名であり、不具合の証拠ではありません。同じ見慣れないタスク名が夜通しすべての起床要求に現れるなら、それが手がかりです。スケジューラーの仕組みについては、一晩中動く dasd と appstoreagent の記事をご覧ください。

コマンド 4：pmset -g assertions、今 Mac を起こしているのは誰か

pmset -g assertions

マニュアルでは、これは「displays a summary of power assertions. Assertions may prevent system sleep or display sleep.」(電源アサーションの要約を表示する。アサーションはシステムスリープやディスプレイスリープを妨げることがある) とあります。アサーションとは、プロセスからの「これをしている間はスリープしないで」という要求です。出力の先頭は件数の要約表で、その下の「Listed by owning process」に各保持者の名前が出ます。次の項目に注目してください。

アサーション意味0 以外の値が示唆すること
PreventUserIdleSystemSleep何かがアイドルスリープを妨げているプロセス (動画、ダウンロード、caffeinate、リモートアクセスツール) が Mac を起こしておきたがっている
PreventSystemSleepより強力：スリープを完全に妨げる良いことはまれ。一部のハードウェアやオーディオ作業で一般的
PreventUserIdleDisplaySleep / InternalPreventDisplaySleepディスプレイが点灯したままか、タイムアウト待ちMac を使っているなら正常
BackgroundTaskバックグラウンドタスクが実行中通常は一時的。値が持続するなら、タスクが固まっていることを示す
NetworkClientActiveネットワークの動作が Mac を起こしている転送または同期が進行中
UserIsActiveMac があなたが使用中だと判断しているBluetooth マウスやキーボードのイベントであることが多い

2 回実行してください。 まず蓋を開けたままアイドル状態の Mac で実行し、次に朝 Mac を起こした直後にもう一度実行します。主要スレッドの投稿者がこれを実行したところ、恒常的な妨害要因は見つかりませんでした。PreventSystemSleep、BackgroundTask、NetworkClientActive はすべて 0 で、coreaudiod によるものや、ネットワーククライアントに紐づくカーネルのアサーションなど、一時的なエントリがいくつかあっただけです。ボランティアは、macOS は一時的なアサーションを大量に作るため、原因の特定に役立つことはまれだと返信しています。これは当方の経験とも一致します。アサーションは「一晩中起きていた」ケースで最も役立ち、「何度も起きる」ケースではほとんど役立ちません。

アサーションが作られ解放される様子のログには、pmset -g assertionslog がリアルタイムで流してくれるほか、履歴も検索できます。

pmset -g log | grep -E "Assertions" | grep -i "created" | tail -30

ログのアサーション行には、保持しているプロセスと理由の文字列が出ます。たとえばブラウザーの「Video Wake Lock」や、「caffeinate command-line tool」のエントリなどです。あるアプリが夜通しアサーションの作成と解放を繰り返しているなら、そのアプリが容疑者です。

コマンド 5：pmset -g とその仲間、有効な設定

pmset -g
pmset -g custom
pmset -g cap
pmset -g sched

-g は使用中の設定を表示し、-g custom はバッテリーと電源アダプタを分けて表示し、-g cap はこの Mac がサポートする機能を一覧にし、-g sched は予定された起床を一覧にします。主要スレッドの投稿者は powernap = 1、tcpkeepalive = 1、womp = 0、standby = 1、hibernatemode = 3 でしたが、いずれもノート型 Mac の通常値です。マニュアルによれば、powernap は Power Nap の切り替え、womp はシステム設定の「ネットワークアクセスによるスリープ解除」と同じもの、hibernatemode 3 (ポータブル機の既定値) はメモリへの給電を保ったままディスクにもコピーを持つモードです。tcpkeepalive はマニュアルの設定一覧には記載されていませんが、出力とログ (TCPKeepAlive=active) には現れます。

ガイドの中には、すぐに tcpkeepalive 0 や powernap 0 に設定するよう勧めるものがあります。それらの変更が macOS 27 でマニュアルの記述以上に何をするかは確認していません。そのため、計測結果がそこを指した場合にのみ、設定を 1 つずつ変更し、元に戻せるよう以前の値を控えてください。

アプリ：アクティビティモニタの「エネルギー」タブと top

アクティビティモニタを開き、エネルギーをクリックして、過去 12 時間の電力で並べ替えます (列見出しを右クリックして列を追加します)。スリープを妨げているか (Preventing Sleep) の列は、どのプロセスがスリープアサーションを保持しているかを示し、このタブと pmset -g assertions を結びつけます。「12 hr Power」が高いのに CPU が低いプロセスは、計算しているというより Mac を頻繁に起こしている可能性が高く、まさに起床ログが示すものと同じです。

ターミナルでは次のようにします。

top -l 2 -n 8 -o cpu -stats pid,command,cpu,idlew,power

-l 2 は 2 回サンプリングし (2 回目に実際の差分が出ます)、-n 8 は 8 個のプロセスを表示し、-stats は列を選びます。idlew はアイドル時の起床回数、power はエネルギースコアで、どちらも macOS 27.0.1 の top で使えますが、マニュアルには説明がありません。CPU の割合が小さく見えても、大きな値は容疑者の目印になります。

自宅の机で深夜、閉じたシルバーのノートパソコンの横で印刷した紙を見直している男性。脇には時刻とパーセンテージを書いた小さなノートがある

ログを読む：何が見え、何を意味し、何をすべきか

以下は判断表です。ここに挙げる起床理由は、macOS 27 の pmset -g log に実際に現れる文字列です。その意味は当方による文字列の読み解きで、Apple は文書化していないため、3 列目は証明ではなく進め方として扱ってください。

ログに見えるものおそらく意味することすべきこと
Clamshell Sleep の後に DarkWake が少ない長い空白蓋が閉じられ、Mac が正常にスリープしている何もしない。これが健全な形
おおよそ 2 時間ごとの rtc/Maintenance または request=Maintenance定期メンテナンスの起床。上のサンプルでは mDNSResponder が所有正常
タスクを名指しする dasd 要求を伴う rtc/SleepServiceDAS がスケジュールしたバックグラウンドタスクWake Requests でタスク名を確認する。同じ名前での起床が多ければ手がかり
smc.sysState.Wake(0x70070000) wifibt SMC.OutboxNotEmptyWi-Fi/Bluetooth チップが SMC に起床を要求した一晩に数回は正常。15 分間隔で数十回なら 10 月 8 日のパターン。デバイスを外してテストする (下記参照)
USB-C_plug、acdetach電源または USB のイベント物理的な要因：ドック、ハブ、充電器、ケーブル。外して再テストする
UserActivity Assertion何かがあなたが操作中だと宣言したBluetooth マウスやキーボード、トラックパッドへの接触、または user-active API を呼ぶアプリ。pmset -g assertions で「Bluetooth LE HID Activity」を確認する
数分間続く DarkWake何かが実際に作業をしているその時間帯の unified log を取得し (下記参照)、次回アクティビティモニタを確認する
同じプロセスを名指しする Wake Requests が連続するそのプロセスが自分を再スケジュールし続けている名前を控える。dasd なら info 文字列を検索する
powerd による、com.apple.powermanagement.darkwakelinger という名前でタイムアウトする InternalPreventSleep電源管理が DarkWake の後に Mac を短時間だけ起こしたままにしている短いタイムアウトならおそらく通常動作。投稿者が挙げたもので、Apple は文書化していない。名前ではなく継続時間を見る
夜間に Sleep エントリがまったくなく、Charge が着実に減るMac が一度もスリープしなかった「一晩中起きていた」ケース。pmset -g assertions を実行し、蓋、外部デバイス、caffeinate、リモートセッションを確認する
スリープのログは正常だが、Charge が以前よりずっと速く減るスリープしているのに消耗しているハードウェアまたはファームウェアの問題を疑う。バッテリーの状態の節を参照

1 回の起床を掘り下げるには、ログのタイムスタンプを使います。主要スレッドでボランティアが次のテンプレートを投稿しており、2 つの時刻の間の unified log を読むための文書化された方法です。

/usr/bin/log show --start "2026-10-14 03:14:00" --end "2026-10-14 03:16:00" --style compact > ~/Desktop/wake-window.txt

調べたい DarkWake について、ご自身の pmset -g log のエントリにある正確な時刻を使い、出力は大きいのでファイルに保存してください。このボランティアは、このログには一見無害なエラーや警告が大量に含まれていて、単一の原因を見つけるのは難しいことがあるとも警告しており、当方も同意見です。プロセス名がすでに分かっている場合 (アクティビティモニタや Wake Requests から) は、検索を絞り込みます。

/usr/bin/log show --last 30m --style compact --predicate 'process == "powerd"'

--last 30m は範囲を絞り、--style compact は各行を短くし、--predicate はプロセスやサブシステムで絞り込みます。powerd は調べたいプロセスに置き換えてください。ログは限られた期間しかさかのぼれないため、イベントの直後に実行してください。通常のユーザーとして実行し、システムレベルのエントリが必要なら sudo を付けます。

Apple シリコンで異なる点

  • 独立した SMC リセットはありません。 再起動が従来のリセットと同じ役割を果たします。NVRAM、PRAM、SMC のガイド をご覧ください。ログには、電源コントローラ由来のテキストなので smc.sysState の文字列が引き続き現れます。
  • 利用できる pmset のキーは Mac によって異なります。 pmset -g cap で、お使いの Mac が対応する項目を確認できます。
  • ポータブル機ではハイバネーションが既定で有効です (hibernatemode 3)。そのため、長いスリープではスタンバイが働くまで少し充電が減ることがあります。
  • 起床理由の文字列は Intel と異なります。 古い記事は EC.LidOpen を挙げていますが、Apple シリコンでは smc.sysState.Wake、NUB.SPMI、rtc/Maintenance、そして wifibt のようなハードウェア名が現れます。Eclectic Light の 2017 年の解説 は起床の構造を説明していますが、文字列は Intel 時代のものです。

事例 1：CPU 100 パーセントの replicatord

Apple サポートのスレッド 「replicatord running at 100% CPU on macOS 27」 は、macOS 27.0 を使う M1 Pro MacBook Pro の所有者が 9 月 17 日に投稿しました。プロセスを終了しても、再起動しても改善しませんでした。確認した時点では、返信が 2 件あり、「私も」の数は表示されていませんでした。

Apple による replicatord の説明は見つかりませんでした。推測はしません。スレッドには、手法と、あるユーザーに効いた解決策が書かれています。

  1. ボランティアは、LaunchAgent を有効のままにし、セーフモードでテストし、アクティビティモニタの 表示 > プロセスをサンプル (View > Sample Process) を使うよう助言しました。
  2. 投稿者のサンプルでは CPU 時間が「nearly completely spent in SQLite database access」(ほぼ完全に SQLite データベースへのアクセスに費やされている) ことが分かり、データベースの破損を疑いました。
  3. lsof を使って、~/Library/Group Containers/group.com.apple.replicatord/replicatord/ にあることを突き止めました。
  4. replicatord.sql、replicatord.sql-shm、replicatord.sql-wal の名前を変更してプロセスを終了すると、「came back and created a fresh db. CPU consumption now is back to normal.」(戻ってきて新しい DB を作成した。CPU の消費は通常に戻った) とのことです。

これは 1 台の Mac での、ユーザーによる報告の解決策であり、Apple は確認していません。元に戻せる形で試すには次のようにします。

cd ~/Library/"Group Containers"/group.com.apple.replicatord/replicatord/
ls -la
mkdir -p ~/Desktop/replicatord-backup
cp -p replicatord.sql* ~/Desktop/replicatord-backup/
mv replicatord.sql replicatord.sql.old
mv replicatord.sql-shm replicatord.sql-shm.old
mv replicatord.sql-wal replicatord.sql-wal.old
killall replicatord

ターミナルに「Operation not permitted」と表示された場合は、macOS のプライバシー保護がアクセスを妨げている可能性があります。ターミナルにフルディスクアクセスを許可するのも一つの方法ですが、範囲が広いので、作業後に必ず外してください。元に戻すには： killall replicatord を実行し、新しくできた replicatord.sql* ファイルを削除し、.old ファイルの名前を元に戻して、プロセスが再起動するのを待ちます。このデータベースに何が入っているかは分かりません。そのため、手順では削除ではなく名前変更とバックアップにしています。CPU が再び 100 パーセントに戻った場合は、元に戻して報告してください。これは、replicatord が実際に CPU の使用率一覧に現れている場合にのみ有効です。

事例 2：agentstored と、まだ解決策がない理由

MacRumors のスレッド 「AgentStored process constantly running on Golden Gate」 は、10 月 14 日に確認した時点で投稿から 1～2 日で、返信はありませんでした。投稿者によると、/System/Library/PrivateFrameworks/AgentSessionKitRuntime.framework 配下の agentstored は「is sitting at 100% on one core nonstop, even right after a reboot」(再起動直後でも、1 コアで 100 パーセントのまま止まらない) とのことで、「34+ hours of CPU time and written ~39 GB to disk」(34 時間以上の CPU 時間、約 39 GB のディスク書き込み) に達しています。「自動ビジュアル調査」(Automatic Visual Look Up) をオフにしたことも、AgentSessionKit のデータベースを ~/Library/Daemon Containers から移動したことも、効果がありませんでした。

  • agentstored に関する Apple の文書は見つかりませんでした。そのため、何をするものかは述べません。
  • 既知の解決策はありません。また、独立した裏付けのない 1 件の報告にすぎません。

それでも計測はできます。アクティビティモニタで、CPU タブの CPU 時間とディスクタブの書き込んだバイト数を確認し、「表示 > プロセスをサンプル」を実行して、そのサンプルをフィードバックアシスタントの報告用に保存しておきましょう。実験として ~/Library/Daemon Containers からファイルを削除しないでください。投稿者はすでにデータベースを 1 つ移動しましたが、効果はありませんでした。持続的な大量書き込みは、待つよりも早めに報告する理由になります。

スリープ中の消耗を正当に減らす設定

これらは Mac の起床頻度を変えるものであり、不具合の修正ではありません。パスは、macOS 27 を最初に選べるバージョンとして掲載している Apple の Mac ユーザガイドのページで確認しました。

設定場所備考
ネットワークアクセスによるスリープ解除システム設定 > バッテリー > オプション (ノート型)、エネルギー (デスクトップ型)Apple のページには、バッテリーを節約するには、電源アダプタ接続時のみ、または使用しないなど、頻度の低い選択肢を選ぶよう書かれている。確認済み
低電力モード / エネルギーモードシステム設定 > バッテリーバッテリー駆動時と電源アダプタ接続時で別々に設定する。確認済み
バッテリー充電の最適化 / 充電制限システム設定 > バッテリー、充電セクション、情報ボタンバッテリー寿命を守るもので、スリープ中の消耗は減らさない。確認済み
Power Nappmset の powernap キー、古い macOS：バッテリー > オプションマニュアルに記載あり。macOS 27 のシステム設定でのラベルは確認できなかった
Mac を起こす Bluetooth デバイス以前は Bluetooth > 詳細2022 年のコミュニティのスレッドによれば Monterey で削除された。macOS 27 での状況は確認できなかった。スリープ前にデバイスの電源を切ってテストする
「探す」(Find My)Apple アカウントとプライバシーの設定macOS 27 での正確なパスは未確認。テストとして無効にすることは勧めない

フォーラムの返信では、通知の要約をオフにすることと、システム設定 > 一般 > ログイン項目と機能拡張を見直すことも提案されていました。後者は、メジャーアップグレードの後に習慣にしておくとよいことです。Wi-Fi や Bluetooth をテストするには、それぞれを 1 晩オフにしますが、wifibt による起床が見られた投稿者は、両方をオフにしても起床が続いたと述べています。

ノートパソコンのトラックパッドの横で、印刷したチェックリストを脇に置き、切り替えスイッチを動かしている人の手元のアップ。ノートパソコンの画面はぼやけて読めない

ソフトウェアの切り分け

主要スレッドのボランティアは、的確な切り分け方を勧めています。

  1. セーフモード。 Apple シリコンでは、シャットダウンし、起動オプションが表示されるまで電源ボタンを押し続け、ボリュームを選び、Shift キーを押しながら「セーフモードで続ける」を選びます。そこでログがきれいなら、サードパーティ製の機能拡張かログイン項目が関係しています。
  2. 新しいユーザアカウント。 その夜間のパターンがきれいなら、原因はお使いのユーザの設定やデータにあります。確認後は削除してください。
  3. クリーナー、最適化ツールなどのソフトウェアを削除またはアップデートし、ログイン項目と機能拡張を一覧にして、見慣れない項目を 1 グループずつ無効にしながら、夜ごとの 1 時間あたりの DarkWake を比較します。

充電制限ツールやメニューバー管理アプリは macOS 27 向けのアップデートが必要でした。macOS 27 の充電制限アプリ をご覧ください。

バッテリーやハードウェアを疑うとき

ログには途切れない長いスリープが記録されているのに、充電が以前よりずっと速く減る場合は、バッテリーを疑ってください。

  1. システム設定 > バッテリーを開き、バッテリーの状態の横にある情報ボタンをクリックします。Apple の macOS 27 のページには、バッテリーの状態と最大容量が記載されています。
  2. Apple のバッテリーサービスのページは、「正常」を「the battery is functioning normally」(バッテリーが正常に機能している)、「サービス推奨」を、バッテリーの充電を保持する能力が新品時より低下している、または正常に機能していない状態と定義しています。
  3. system_profiler SPPowerDataType | grep -E "Cycle Count|Condition|Maximum Capacity" を実行します。Health Information セクションにはこの 3 つの値が含まれます。
  4. 急な変動を調べるには、バッテリー駆動で pmset -g pslog を動かしたままにします。マニュアルによれば、30 パーセントから 0 のような不連続は「indicative of an aging battery」(バッテリーの劣化を示す) とのことです。

発熱については、MacBook Pro M5 の過熱ガイド で扱っています。バッテリーが健全なのにログが落ち着かないなら、原因はソフトウェアです。

Apple に送るもの

エンジニアにつながる経路はフィードバックアシスタントです。Apple のバグ報告のページ には、「automatically attaches a sysdiagnose for each issue」(各問題に sysdiagnose を自動的に添付する)、また sysdiagnose は「should be included with all reports, even if you think one is not needed」(不要だと思っても、すべての報告に含めるべき) と書かれています。デベロッパアカウントがない場合は、Apple の macOS フィードバックフォーム がより簡単なウェブの選択肢です。

  1. ひどかった夜の直後に sysdiagnose を取得します。 sysdiagnose のマニュアルでは、トリガーとして Control-Option-Command-Shift-ピリオドが挙げられています。ターミナルで sudo sysdiagnose を実行すると、既定で /var/tmp に書き出され、数分かかります。個人情報が含まれることがあります。
  2. 事実を含めます。 macOS 27.0.1 (26A434)、Mac のモデル、アップグレードかクリーンインストールか、そしてテスト結果 (開始と終了のパーセンテージ、継続時間、蓋の状態) です。
  3. pmset -g log の抜粋と pmset -g stats を添付します。
  4. 容疑者の名前を挙げ、CPU 時間と書き込みバイト数、そして除外したこと (セーフモード、新しいユーザ、空き容量) を記します。

やってはいけないこと

  • 「クリーナー」や「最適化ツール」をインストールしないでください。 スレッド内のボランティアによれば、これらはアップグレード後の互換性問題の原因になり、起床理由を直せるものはありません。
  • デーモンを止めるために System Integrity Protection を無効にしないでください。 名前変更による修正に、そのような変更は不要です。
  • LaunchAgents や LaunchDaemons を手当たり次第に削除しないでください。 ボランティアは、調査中は Apple のエージェントを有効のままにするよう助言しています。
  • SMC や NVRAM を繰り返しリセットしないでください。 Apple シリコンでは再起動がリセットです。リセットガイド をご覧ください。
  • 複数の設定を一度に変更したり、1 晩だけで判断したりしないでください。
  • 慌てて消去してダウングレードしないでください。 まずアップデート判断ガイドとダウングレードガイドを読んでください。原因は 1 つのアプリかもしれません。

よくある問題のトラブルシューティング

ログに夜間のスリープがまったく記録されていない

症状：pmset -g log の深夜から朝の間に Sleep エントリがなく、Charge が着実に減っている。

原因：何かが Mac を起こしたままにしていました。候補は、アプリ (動画、ダウンロード、リモートアクセス、caffeinate) によるアサーション、ターミナルセッション (ttyskeepawake の設定)、接続されたデバイス、完全には閉じていなかった蓋です。

解決策：

  1. pmset -g assertions を実行し、「Listed by owning process」で PreventUserIdleSystemSleep または PreventSystemSleep を探します。
  2. アクティビティモニタの「エネルギー」タブで、スリープを妨げているか (Preventing Sleep) の列を確認します。
  3. そのアプリを通常どおり終了して、再テストします。
pmset -g assertions | grep -E "PreventUserIdleSystemSleep|PreventSystemSleep|caffeinate"

それでも解決しない場合：外部デバイスをすべて外し、ターミナルとリモートセッションを終了して、管理されたテストをもう一度行います。それでも Mac が一度もスリープしない場合は、アサーションの出力を報告に含めてください。

Mac が約 15 分ごとに起き、理由に wifibt が含まれる

症状：一定間隔で DarkWake のエントリがあり、いずれも wifibt SMC.OutboxNotEmpty を挙げている。

原因：ワイヤレスチップが繰り返しシステムに起床を求めています。これは主要スレッドの 10 月 8 日の報告と一致しており、そこでは Wi-Fi と Bluetooth をオフにしても起床が続きました。原因は分かっておらず、Apple もコメントしていません。

解決策：

  1. 上の awk コマンドで 1 時間あたりの起床回数を数え、継続時間を控えます。
  2. Bluetooth アクセサリを外し、近くにある Handoff 関連のデバイスの電源を切ってから、再テストします。
  3. システム設定 > バッテリー > オプションでネットワークアクセスによるスリープ解除を「しない」に設定し、1 晩再テストします。
  4. 低電力モードをオンにした場合と比較します。

それでも解決しない場合：フィードバックアシスタントで報告する候補です。DarkWake の回数と、翌朝に取得した sysdiagnose を添付してください。

pmset -g log が役に立つ出力をしない、または grep が何も返さない

症状：フィルター後の出力が空、または log がエラーを返す。

原因：grep -E 'Sleep |Wake ' のパターンは、空白の数が正確であることに依存します。zsh では log がシェル組み込みコマンドで、「too many arguments」で失敗します。

解決策：イベントの列を基準にする awk フィルターを使い、unified log には /usr/bin/log show を使ってください。再起動後に pmset -g log が空の場合は、Mac に何度かスリープのサイクルを経験させてください。

よくある質問

macOS 27 でスリープ中にバッテリーが減るのは、確認された不具合ですか？

Apple は認めていません。M3、M4、M5 の MacBook を使うユーザーが、Apple のコミュニティフォーラムで夜間の大きな消耗を報告している一方、問題がないという所有者もいます。Apple による認知も既知の問題としての掲載も見つからず、27.0.1 も不具合修正としか説明されていません。広く報告されているものの未確認のパターンとして扱い、アップデートのせいにする前に、ご自身の Mac で計測してください。

アップグレード後、Spotlight と写真の処理にはどのくらいかかりますか？

Apple は所要期間を公表しておらず、公式な数字は見つかりませんでした。サードパーティのガイドでは数日とされています。ライブラリの大きさと、Mac が電源につながれてアイドルしている頻度のどちらも影響します。主要スレッドのように、蓋を閉じた状態で 1 週間後にも Mac が熱く消耗しているなら、インデックス作成だけでは説明がつかない可能性が高いです。

DarkWake とは何ですか？悪いことですか？

DarkWake は、ディスプレイがオフのまま Mac がメンテナンス、メールのチェック、ネットワークの維持といった短いバックグラウンド作業を行う部分的な起床です。一晩に何回もあるのは普通です。フォーラムのボランティアは、ほとんどが 1 分未満だと述べています。重要なのは、頻度、継続時間、そして同じ理由が繰り返されるかどうかです。数分間続く DarkWake は調べる価値があります。

replicatord を終了したり、そのデータベースの名前を変更したりしても安全ですか？

根拠は、Group Container フォルダ内の 3 つのデータベースファイルの名前を変更してプロセスを再起動したところ CPU 使用率が通常に戻った、という 1 人のユーザーの報告だけです。Apple はこのプロセスを文書化していません。試す場合は、先にファイルをバックアップし、削除ではなく名前変更にし、元のファイルを復元する方法を把握しておいてください。デーモンを無効にしないでください。

Power Nap やネットワークアクセスによるスリープ解除はオフにすべきですか？

妥当なテストではありますが、特効薬ではありません。Apple のページには、ネットワークによる起床の頻度を下げる選択肢を選ぶとバッテリーを節約できると書かれており、powernap キーは pmset のマニュアルに記載があります。設定は 1 つずつ変更し、管理された夜間テストを行って DarkWake の回数を比較してください。Power Nap のスイッチが macOS 27 のシステム設定のどこにあるかは確認できませんでした。

Tahoe にダウングレードすれば直りますか？

直る可能性はありますが、全員に必要という証拠はなく、消去と再インストールが必要です。まず計測しましょう。特定のアプリやプロセスが原因なら、それを削除するほうがはるかに手軽です。ログで Mac 自体が繰り返し起きていて我慢できない場合は、ダウングレードガイドでそのコストを説明しています。

フィードバックアシスタントの報告には何を添付すべきですか？

ひどかった夜の直後に取得した sysdiagnose、macOS のビルド (例：27.0.1、26A434)、Mac のモデル、pmset -g log のログ抜粋、そして開始と終了のパーセンテージを含む管理されたテストの結果を添付してください。Apple 自身のページに、sysdiagnose はすべての報告に添えるべきとあるので、重複に思えても含めてください。

まとめ

macOS 27 では一部の MacBook 所有者が夜間の大きな消耗を報告していますが、Apple は何も述べておらず、報告も単一の原因を指してはいません。できることは計測です。管理された夜間テストを行い、pmset -g stats と pmset -g log を読んで Mac がスリープしたのか、繰り返し起きたのか、一度もスリープしなかったのかを確認し、アサーションとアクティビティモニタを調べて、判断表を使ってください。replicatord にはバックアップを取って試せるユーザー報告の回避策があり、agentstored には提出すべき明確な報告があるだけです。ログが健全なのにバッテリーが速く減る場合は、ソフトウェアのせいにする前にバッテリーの状態を確認してください。もし今の Mac が使い物にならないと判断したなら、アップデートすべきかとダウングレードをご覧ください。

関連記事：macOS 27 で夜間に dasd と appstoreagent の CPU 使用率が高い問題、Mac のスリープ問題 完全ガイド、macOS 27 後の Spotlight 再インデックス