安心していたのは、つかの間でした。
Threadsの予約投稿を完全自動化した話を、以前この場で書きました。
queue_add.pyで投稿したい内容と時刻をキューに追加しておくと、run_queue.pyがlaunchdによって15分おきに起動され、予約時刻を過ぎた投稿を勝手に処理してくれる仕組みです。
「これでもう見てなくても投稿される」と、すっかり安心しきっていました。
やっと手放れした。
毎日の運用がひとつ楽になった、と満足していたのを覚えています。
ところが後日、Claude Codeにログを確認してもらったところ発覚した、ちょっと血の気が引く事実。
成功していたのは、最初の1回だけ
launchdの実行ログを見ると、動いていたのは仕組みを組んだ直後の1回(RunAtLoad、起動時の即時実行分)だけでした。
それ以降は、ずっとです。
その後の定期実行は、15分おきに律儀に起動してはいるものの、毎回「Operation not permitted」というエラーで静かに失敗し続けていたんです。
エラー通知も、画面表示も、なし。
気づかなければ、ずっとこのままだったと思います。
launchdの仕組みを組んだ直後は問題なく動いていたので、余計に「これでもう大丈夫」と思い込む材料になっていました。
「動いていない」ことに、誰も気づけない設計だった
一番まずかったのは、失敗が完全に無音だったことです。
エラーログという、自分から見に行かない限り絶対に表に出てこない場所にだけ、証拠が残っていました。
launchd自体は正常に起動を繰り返していたので、表面的には「仕組みは生きている」ように見えました。
でも中身は、起動しては即座に弾かれる、を15分ごとに繰り返していただけでした。
これでは、予約したはずの投稿が実際に公開されているか、こちらから毎回確認しない限り気づきようがありません。
毎回確認するくらいなら、自動化の意味がない。
原因はmacOSのTCC保護だった
原因は、置き場所でした。
Claude Codeに調べてもらって、そう分かりました。
当時スクリプトを置いていたのは~/Desktop/cats-hand/threads/、つまりDesktopフォルダの中です。
普段の作業ファイルと同じ場所にまとめて置いていただけで、特に深い理由があったわけではありません。
macOSにはTCC(Transparency, Consent, and Control)という仕組みがあり、Desktop・Documents・Downloads・iCloud Driveといった保護フォルダは、対話的な操作を伴わないバックグラウンド処理からの読み書きに、個別の許可が必要になります。
launchdによる定期実行はまさにこの「対話的でないバックグラウンド処理」に該当していて、そこが引っかかっていた、という構図でした。
普段Finderで開いたりターミナルで触ったりする分には何の制限も感じないので、まさかバックグラウンド実行だけこんな形で足止めされるとは思っていませんでした。
対処はシンプル、でも気づくまでが長かった
解決策自体は単純で、スクリプト一式を保護対象外の~/cats-hand-automation/(ホームディレクトリ直下)に移設するだけでした。
移設してからは、以降ずっと安定して動いています。
呆気なかったです。
対処そのものは数分で終わったのに、そこにたどり着くまでの「実は全部失敗していた」という事実に気づくまでの方が、よほど時間がかかりました。
原因さえ分かってしまえば拍子抜けするくらい単純な話でしたが、原因に気づく手がかりがログの中にしかなかった、というのが今回の厄介なところでした。
「自動化した」と「動いている」は別の話
今回の教訓は、これに尽きます。
仕組みを組んだ時点でのテストがうまくいっても、それは、あくまで「今この瞬間はちゃんと動いた」ということの証明でしかなく、その先ずっと動き続ける保証には一切ならない、というのが今回身をもって分かったことでした。
定期実行が本当に機能し続けているかは、後から改めて確認しないと分からないんだと痛感しました。
特にlaunchdのような「バックグラウンドで黙々と動くタイプ」の仕組みは、失敗してもエラー画面が出るわけではないぶん、正常に動いているという錯覚がずっと続いてしまいます。
自動化とは本来「人がやらなくていいことを増やす」ための工夫のはずなのに、その工夫自体がちゃんと機能しているかを結局は人が確かめないといけない、という妙な逆説が今回はっきり見えました。
今後どうするか
今回の件を踏まえて、新しく自動実行の仕組みを作るときは、最初から保護フォルダを避けて配置することをルール化しました。
それに加えて、仕組みを組んだ直後だけでなく、しばらく経ってからもう一度ログを確認する習慣も付けようと思っています。
「設定した瞬間」の確認だけでは足りない。
それが今回の一番の学びです。
動画の固定コメント投稿など、他にもlaunchdで動かしている仕組みがいくつかあるので、次に見直すタイミングでは同じ観点(定期実行が本当に成功し続けているか)でログを確認しておくつもりです。
まとめ
「見てなくても投稿されるようにした」つもりが、実は見ていない間ずっと失敗し続けていた、という話でした。
バックグラウンドで動く仕組みほど、動いているかどうかを定期的に確認する必要があるんだなと実感しています。
「自動化した」の一歩先に「自動化できているか確認する仕組み」まで用意して、ようやく本当の意味で手放れしたと言えるのかもしれません。
同じようにlaunchdやcronで何かを自動化している方は、一度ログを覗いてみると、思わぬ発見があるかもしれません。
この記事が参考になったら、応援クリックをお願いします
