Macが眠ると自動化も止まる

1. リード

自動化があると、人は安心しやすい。時刻を決め、仕組みを置き、あとは毎朝結果を見るだけだと思いたくなる。だが Mac の上で動く自動化には、もう一つ前提がある。その時刻に、Mac が最後まで起きていることだ。ここを見落とすと、正しい仕組みを置いても、朝の前提は静かに崩れる。

RC 検証週で見えてきたのは、Connector の成否だけではなかった。launchd を入れれば終わりでもなかった。自動実行が始まっても、DarkWake のまま 06:30 を迎えると、途中で Maintenance Sleep に戻りうる。毎日動く仕組みは、動き出すことだけでなく、最後まで朝の文脈に残ることまで含めて設計しなければいけなかった。

2. 背景

Vol.12 では、手で動くことと毎日動くことが別の品質だと書いた。その続きが今回の話だ。Step49.1 で Daily Connector Automation を切り出し、日次Connectorが「朝にもう並んでいる」状態を目指した。だが 2026-07-24 の Current Context では、その次の論点として DarkWake 問題がはっきり記録されている。

ここで重要なのは、まだ正式 v1.0.0 ではないことだ。RC 検証週の役割は、「動いた」という成功談を書くことではなく、「どこまで確認できて、どこが未完了か」を分けることだった。だからこの記事でも、解決済みとは書かない。書けるのは、DarkWake 中の launchd 起動が新しい運用論点として見え、その対策として --wait-for-user-active が追加された、という事実までだ。

3. 今回のテーマ

テーマは、Mac が眠ると自動化も止まる、という運用上の現実だ。

launchd を入れた時点で「これで毎朝回る」と感じやすい。だが RC 検証週では、その感覚が少しずつ削られていった。始まることと、終わることは別だ。終わることと、運用者が安心して結果を見られることも別だ。DarkWake 問題は、その間にある見えにくい前提を表に出した。

4. 実際の出来事

Current Context にあるとおり、2026-07-24 の HEAD では、DarkWake 中に 06:30 実行が始まると途中で Maintenance Sleep に戻りうることが記録されていた。これは Connector の取得ロジックの話ではない。スケジューラが起動したあと、OS 側の状態変化が運用を中断させうる、という時間軸の話だ。

ここで見落としやすいのは、「開始した」という事実が、そのまま「朝の役に立つ」という意味にはならないことだった。06:30 に launchd が反応したとしても、運営者が朝に画面を開くころまで処理が残っていなければ、前提は成立しない。これは失敗ログの有無より厄介だった。失敗なら気づけるが、静かに途中で切れると、最初は「今日はたまたま更新が薄いのかもしれない」と解釈してしまいやすいからだ。

しかもこの問題は、Connector 単体を何度テストしても十分には見えない。GA4、GSC、Clarity、Metricool の取得ロジックがそれぞれ正しくても、OS がその時間帯にどの状態でいるかは別の層にある。Vol.12 で書いた「動くConnectorと、毎日動く仕組みは別だった」という話が、ここではさらに細かくなり、「毎日始まることと、毎日最後まで残ることも別だった」と言い直された形だった。

ここで大事だったのは、launchd を入れたことを「完成」と扱わなかったことだと思う。もし完成扱いしていたら、次に起きた摩擦は例外処理の不足として片づけられたかもしれない。だが実際には、毎朝の無人実行を成立させる条件そのものがまだ詰め切れていなかった。だから対策は、Connector 側の追加実装ではなく、launchd 実行だけ通常起動待ちへ変える最小修正として整理された。

--wait-for-user-active の追加は、派手な改善には見えない。だがこの種の修正は、運営 OS にとってかなり重要だ。朝の 10 分を守る道具は、派手な新機能より、こうした目立たない前提条件の積み重ねで安定するからだ。

一方で、この修正が入った時点でも、Current Context は「無人実機確認は未完了」と明記している。ここは絶対に飛ばせない。修正を入れたことと、その修正で毎朝の前提が十分に守られると確認できたことは別物だ。確認が終わっていない以上、記事でも完成形としては書かない。

5. 考えたこと

非エンジニアの立場から見ると、ここで学んだのは「自動化の敵は故障だけではない」ということだった。故障していれば、比較的分かりやすい。エラーが出る。ログが赤くなる。だが睡眠や起動条件のような OS のふるまいは、もっと静かに前提を壊す。静かに壊れるものは、気づくまでに時間がかかる。

だからこそ RC 検証週の価値がある。毎朝同じ条件で見ていなければ、この種の違和感は「たまたま今日は遅かった」で流れてしまう。流してしまうと、正式版へ上げたあとで、運営者が毎朝不安を背負うことになる。朝の不安を減らすはずの道具が、別の不安を増やしては意味がない。

もう一つ印象に残ったのは、最小修正の意味だ。問題が見えると、つい大きく直したくなる。だが検証週の途中で大きく変えると、何が効いたのかが分からなくなる。--wait-for-user-active のような最小修正に留めたことは、技術的な慎重さでもあり、記録としての誠実さでもあった。

この種の誠実さは、非エンジニアにとってかなり重要だった。コードの細部をすべて評価できなくても、「どの層の問題なのか」「何を直したのか」「何がまだ未確認なのか」が言葉で分かれていれば、公開や Version 判断に参加できる。逆にそこが混ざると、最終判断は雰囲気に引っ張られやすい。DarkWake 問題が教えてくれたのは、技術課題そのものだけではなく、判断に必要な粒度まで言語化することの重さだったと思う。

Human Approval の思想とも少し重なっている。本番の書き込み操作では、実行できることと、実行してよいことを分けていた。同じように無人実行でも、「起動したこと」と「朝の前提として信用してよいこと」は分けて考えなければいけなかった。AI と一緒の開発では、動いた瞬間に前進感が強く出る。だからこそ、その前進感をそのまま完成扱いしないための言葉と境界が必要だった。

6. 学び

launchd を入れたことと、毎朝最後まで実行できることは別の確認項目である
DarkWake や Maintenance Sleep のような OS のふるまいも運用品質に含まれる
自動化の失敗は、故障より前に「前提条件の抜け」として現れることがある
検証週では、大きな改修より最小修正の方が学びを切り分けやすい
無人実機確認が終わるまでは、修正後でも完成形として書かない

7. 次回メモ

この続きで書くなら、DarkWake 問題への最小修正を入れたあとも、なぜ Go を急がなかったのかという話につながる。ただし正式 v1.0.0 は未リリースのため、最終的な成功談にはしない。