Mac pmset効かない原因とLaunchAgentへの移行手順

じたばたIT実践録
Mac pmset効かない原因とLaunchAgentへの移行手順を3行で要約
  • wakepoweronはスリープ解除に対応していないため、wakeへの変更が必要だった
  • macOS Sequoia以降ではpmset repeatの設定がWakeスケジュールに内部登録されないバグが確認されている
  • cronを廃止してLaunchAgentへ移行することで、スリープ中に時刻を過ぎても起動後に自動実行される仕組みを実現した
macOS Sequoia以降で、pmset repeatコマンドによるWakeスケジュール設定が内部システムに正しく登録されず、指定時間にMacが起動しないという重大なバグを示す4コマ漫画。
①朝8時になり、なぜMacが起動しないのか疑問に思う。②コマンドで設定済みだが、内部登録エラーが発生している。③pmset repeatコマンドとmacOS Sequoiaの不整合を強力なパンチで表現する。④Sequoia以降のバグであり、設定が登録されないことを説明する。

前回の記事で構築した「pmset + caffeinate + cron」の自動実行環境、初日は完璧に動いていました。ところが2日目の朝、ログファイルは空のまま。Pythonスクリプトは一切実行されていませんでした。

調査を進めると、原因は2段階に分かれていました。まずwakepoweronというオプションの誤用、そしてmacOS Sequoia以降で発生するpmsetのバグです。この記事では、実際のログを使って原因を特定した過程と、LaunchAgentへ完全移行して4日連続成功した手順をすべて記録しています。

[ユーザー名] や [プロジェクトフォルダ] の部分は、ご自身の環境に合わせて読み替えてください。

初日だけ成功して2日目から失敗した原因

原因はスリープ解除が6:00AMに行われず、cronの実行タイミングをそのまま過ぎてしまったことです。実際のpmsetログを確認すると、以下の状態が記録されていました。

2026-02-23 00:37:39 +0800  Sleep  Entering Sleep state due to 'Idle Sleep'
2026-02-23 07:03:21 +0800  Wake   Wake from Deep Idle : due to caffeinate

設定していたcronの実行時刻は6:01AMと6:07AMです。しかしMacは7:03AMまで眠り続けており、cronが発火するタイミングをすでに1時間以上過ぎていました。cronはスリープ中に設定時刻を過ぎると、その回の実行を完全にスキップします。

Wake Requestsにスケジュールが登録されていなかった

次に、スリープ直前のWake Requestsを確認しました。Wake Requestsとは、Macが次に起きるべき時刻の予約リストのことです。

pmset -g log | grep "Wake Requests" | tail -5

出力を見ると、どの行にも6:00AMのエントリが存在しませんでした。pmset -g schedでは設定済みと表示されているにもかかわらず、内部のスケジューラには一切登録されていない状態です。

# pmset -g schedの表示(設定済みに見える)
Repeating power events:
  wake at 6:00AM every day

# しかしWake Requestsには6:00AMのエントリがない
[process=powerd request=AdaptiveWake wakeAt=2026-02-23 08:28:23]
[process=powerd request=UserWake wakeAt=2026-02-23 02:52:15 ...]
pmset -g schedの表示が正常でも、実際のWakeスケジュールへの登録有無はpmset -g log | grep "Wake Requests"で別途確認が必要です。表示上は正常に見えても内部では無効になっているケースがあります。

原因①:wakepoweronはスリープ解除に使えない

前回の記事で使用したwakeorpoweron(またはwakepoweron)は、電源OFF状態からの起動を対象としたオプションです。スリープ状態からの復帰にはwakeを指定する必要があります。

まずは既存の設定をリセットし、正しいオプションで再登録します。

sudo pmset repeat cancel
sudo pmset repeat wake MTWRFSU 06:00:00
pmset -g sched

確認コマンドの出力が以下のようになれば、オプションの修正は完了です。

Repeating power events:
  wake at 6:00AM every day
デプロイ太郎
デプロイ太郎

wakepoweron と wake は似て非なるもの。電源ボタンで起こすか、目覚まし時計で起こすかくらい役割が違う。スリープ解除には必ず wake を使おう。

原因②:macOS Sequoia以降でpmsetのWakeが内部登録されないバグ

オプションをwakeに変更しても、Wake Requestsへの登録が確認できませんでした。これはmacOS Sequoia以降で報告されている既知の問題です。

pmset repeat wakeコマンドは設定ファイルへの書き込みには成功しますが、スリープ時に次回起動スケジュールをWake Requestsへ登録する処理が行われないケースがあります。cronをどれだけ正確に設定しても、Macが起きてこなければ意味がありません。

この問題はIntel MacのmacOS Sequoia環境で確認されました。Apple Silicon(M1/M2/M3)や他のバージョンでは挙動が異なる場合があります。

根本解決:cronをやめてLaunchAgentへ移行する

LaunchAgentはmacOS標準のタスクスケジューラで、cronと比較して決定的な違いがあります。スリープ中に設定時刻を過ぎても、Mac起動後に自動で実行をキャッチアップしてくれます。

比較項目 cron LaunchAgent
スリープ中に時刻を過ぎた場合 スキップされる 起動後に実行される
設定の複雑さ シンプル plistファイルが必要
macOSとの親和性 外部ツール macOS標準機能
スリープ解除機能 なし なし(pmsetと併用)

Step 1:実行スクリプトを作成する

複数のPythonスクリプトをまとめて実行するシェルスクリプトを作成します。caffeinate をスクリプト内で起動することで、実行中のスリープ戻りも防止します。

cat << 'EOF' > ~/wakeup_and_run.sh
#!/bin/bash
caffeinate -i -t 3600 &
cd /Users/[ユーザー名]/Documents/[プロジェクトフォルダA] && /Library/Frameworks/Python.framework/Versions/3.13/bin/python3 [スクリプト名A].py >> /tmp/[ログファイル名A].log 2>&1
cd /Users/[ユーザー名]/Documents/[プロジェクトフォルダB] && /Library/Frameworks/Python.framework/Versions/3.13/bin/python3 [スクリプト名B].py >> /tmp/[ログファイル名B].log 2>&1
EOF
chmod +x ~/wakeup_and_run.sh

Step 2:LaunchAgentのplistファイルを作成する

LaunchAgentの設定は、plistと呼ばれるXML形式のファイルで行います。以下のコマンドをターミナルに貼り付けて実行してください。

cat << 'EOF' > ~/Library/LaunchAgents/com.user.dailytask.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.dailytask</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/[ユーザー名]/wakeup_and_run.sh</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>6</integer>
        <key>Minute</key>
        <integer>1</integer>
    </dict>
    <key>StandardOutPath</key>
    <string>/tmp/launchagent.log</string>
    <key>StandardErrorPath</key>
    <string>/tmp/launchagent.log</string>
</dict>
</plist>
EOF

Step 3:LaunchAgentを登録・確認する

ファイルを作成したら、以下のコマンドでシステムに登録します。

launchctl load ~/Library/LaunchAgents/com.user.dailytask.plist
launchctl list | grep com.user.dailytask

出力に com.user.dailytask が表示されれば登録完了です。PIDの列に数字が入っている場合は、現在実行中であることを示しています。

Step 4:古いcron設定を削除する

LaunchAgentへ移行したら、cronの設定は削除しておきます。二重登録のままにすると意図しない重複実行が起きる可能性があります。

crontab -e

エディタが開いたら、設定されている全行を削除して:wqで保存します。

移行後の最終構成と動作確認

移行後の自動実行の流れは以下の通りです。

時刻・タイミング 動作 担当ツール
6:00AM(できる場合) スリープ自動解除 pmset
6:01AM または起動後 スクリプト自動実行 LaunchAgent
実行中 60分間スリープ防止 caffeinate(スクリプト内)

実行後は以下のコマンドでログを確認できます。

cat /tmp/launchagent.log
デプロイ太郎
デプロイ太郎

LaunchAgentに移行してから4日連続でスクリプトが動いた。pmsetのWakeが多少ズレても、LaunchAgentがキャッチアップしてくれるのが心強い。

設定変更後は最低3〜5日はログを見届けてから「解決した」と判断しよう。1日で安心するのが今回の失敗の本質だった。

まとめ

  • wakepoweronはスリープ解除に使えない。スリープ復帰には必ずwakeオプションを指定する
  • macOS Sequoia以降ではpmset repeatがWakeスケジュールに内部登録されないバグがあり、pmset -g log | grep "Wake Requests"での実態確認が必要
  • cronをやめてLaunchAgentへ移行すると、スリープ中に時刻を過ぎても起動後にキャッチアップ実行される

まずはpmset -g log | grep "Wake Requests"を実行して、自分の環境でWakeスケジュールが正しく登録されているかどうかを確認してみてください。登録されていなければ、今回紹介したLaunchAgent移行が有効な選択肢になります。

よくある質問

Q
LaunchAgentはスリープを自動解除できますか?
A

LaunchAgent単体ではスリープ解除はできません。スリープ解除はpmsetが担当し、LaunchAgentはMacが起きている状態でスクリプトを実行する役割です。pmsetのWakeが効かない環境でも、Macが起動している状態であれば設定時刻の実行を保証してくれます。

Q
cronとLaunchAgentを両方設定したままにしても問題ありませんか?
A

両方を設定したままにすると、同じスクリプトが二重実行される可能性があります。LaunchAgentへ移行したあとは、crontab -eで既存のcron設定を削除しておくことを強く推奨します。

Q
LaunchAgentの設定を変更したい場合はどうすればいいですか?
A

一度アンロードしてからplistファイルを編集し、再度ロードします。編集中にロードしたままにすると変更が反映されません。

launchctl unload ~/Library/LaunchAgents/com.user.dailytask.plist
# plistファイルを編集する
launchctl load ~/Library/LaunchAgents/com.user.dailytask.plist
Q
設定が正しいか1日ではなく何日確認すればよいですか?
A

最低でも3〜5日間の連続動作確認を推奨します。今回の失敗の教訓として、初日だけ成功しても翌日以降に崩れるケースがあります。毎朝cat /tmp/launchagent.logでログを確認する習慣をつけると、問題の早期発見につながります。

Q
Apple Silicon(M1/M2/M3)のMacでも同じ問題が起きますか?
A

今回確認した問題はIntel MacのmacOS Sequoia環境で発生したものです。Apple Siliconでもpmsetの挙動に差異があるため、pmset -g log | grep "Wake Requests"で実際のスケジュール登録状況を確認することをおすすめします。

出典・参考リンク

コメント

タイトルとURLをコピーしました