クラウドの定期実行を使えば、ローカルで動かしている処理もそのまま自動化できると考えていました。しかし、今回試した環境では、Macに保存している認証情報をクラウド側から利用できず、想定どおりには動きませんでした。
この記事では、SNS投稿の時刻指定でつまずいた原因と、ローカルで動かす方法へ切り替えた経緯を紹介します。あわせて、予約タスクは「登録できたか」だけでなく、「指定時刻に実際に動いたか」まで確認する必要がある、という失敗から得た教訓もまとめます。
決まった時刻に自動実行したかった
SNS投稿を毎日決まった時刻に自動で行うため、Claude Codeが提供するクラウド版の定期実行機能を試すことにしました。ローカルで動かしているスクリプトを、そのままクラウドのスケジュール機能に移せば楽になると考えていました。
実際に試してわかったこと
想定していたこと
クラウド側で定期実行を設定すれば、ローカルと同じ条件でスクリプトが動き、決まった時刻に投稿されるだろうと考えていました。
実際に起きたこと
ところが、今回試した環境では、実行のたびに新しい環境が用意される仕組みになっていました。そのため、ローカルの作業ディレクトリにしか置いていない認証情報（`.env`ファイルや、ブラウザ自動化用のログインCookieなど）は、そのままでは利用できませんでした。
仕組みの前提が、「毎回同じ認証情報を使い回して投稿する」というやりたかったこととズレていた、という結論に行き着きました。
今回とった対応策
クラウド側の定期実行はいったん見送り、代わりに「今、手元で開いているローカルのセッションを維持したまま、その場で時刻指定の一回限りタスクを仕込む」という方法に切り替えました。ローカル環境であれば、すでに認証済みの状態がそのまま使えます。現在は「登録できたか」だけでなく、指定時刻に実際に動いたかまで確認しながら運用しています。
クラウドとローカル、使い分けの判断軸
この経験から実感したのは、クラウドの定期実行とローカル完結の自動化には、それぞれ向いている場面が違うということです。
- クラウド向き：毎回まっさらな環境で完結できる処理（外部APIの呼び出しだけで完結する作業など）
- ローカル向き：ローカルにしかない認証情報やログイン状態を使い回す必要がある処理
「クラウドでなんでも自動化できる」と決めつけず、処理の中身によって向き不向きがあることを踏まえて選ぶのが良さそうだと感じています。
よくある質問（FAQ）
Q. クラウドの定期実行機能自体が使えないということですか？
A. いいえ、機能自体は正常に動作します。今回のケースでは、ローカルにしかない認証情報を使い回す必要がある処理だったため、要件に合わなかったという話です。
Q. ローカル完結の自動化に切り替えるデメリットはありますか？
A. ローカル側の端末やセッションを維持しておく必要がある点はデメリットです。常時起動しているクラウド環境と違い、ローカル側の状態に依存します。
まとめ
SNS投稿の時刻指定自動化を、クラウドの定期実行機能で試みてつまずいた実例を紹介しました。今回試した環境では、実行のたびに新しい環境が用意される仕組みのため、ローカルにしかない認証情報を使う処理には向きませんでした。ローカルのセッションを維持したまま時刻指定タスクを仕込む方法に切り替え、登録できたかだけでなく実際に動いたかまで確認しながら運用しています。クラウドとローカル、それぞれの得意分野を見極めて使い分けることが大切だと感じています。
