元調理師で、いまはSNS運用代行のフリーランスをしている、さとりです。2026年6月から、Windowsのタスクスケジューラーを使ってSNS投稿の自動化を組んでいます。まだ2ヶ月ほどですが、ThreadsとXに1日5本ずつ、毎日決まった時間に投稿が出続ける状態になりました。
先に結論を書きます。タスクスケジューラーはWindows標準の機能なので、費用は0円です。定時実行の土台としては十分に使えます。ただし、勘所を知らないまま組むと、私と同じ落とし穴を踏むことになります。
具体的には、設定画面の「準備完了」という表示は当てにならないこと。PCが起きていなければ何も動かないこと。そして、失敗してもエラーが表に出ないことがあること。この3つです。この記事では、実際に私が組んでいる構成と、2ヶ月で踏んだ失敗を、起きたことそのままに書きます。
タスクスケジューラーで動かしているものの全体像
まず、私がタスクスケジューラーで何を動かしているかを書きます。中身はPythonのスクリプトで、タスクスケジューラーの役割は「決まった時間にそれを起動する係」です。スケジューラー自体は何も賢いことをしません。時間が来たら起動する、それだけです。
2026年8月4日時点で動いているのは、次のタスクです。
- 毎朝6時台に、AIがその日の投稿文をまとめて生成し、Googleドライブにテキストで保存する
- Threadsに1日5本、7時・12時・17時・21時・23時に、保存された投稿文を読んで自動投稿する
- Xにも同じ時間に1日5本、同じ作りで自動投稿する。こちらは2026年8月4日に動かし始めた
- noteの新着をRSSで拾って、月水金に自動で告知する
- 週次・月次で自分の投稿を自動集計して、Discordにレポートを飛ばす
- Threadsの認証トークンを、毎月1日に自動で延長する
設計として意識したのは、生成と投稿を分けることです。朝にAIが投稿文をまとめて作ってドライブに置き、日中の投稿スクリプトはそれを読んで投げるだけ。投稿の瞬間にAIを呼ばないので、投稿タスク自体は軽くなりますし、失敗したときに「生成が悪いのか、投稿が悪いのか」を切り分けやすくなります。
そして、投稿が失敗したらログに残り、Discordに通知が飛び、次にPCを開いたときにも報告が上がるようにしています。この通知まわりは後付けで足したものですが、いま振り返ると、最初から入れておくべきだったと思っています。理由は後半で書きます。
勘所その1 「準備完了」の表示を信用しない
いちばん伝えたいのがこれです。2026年8月4日、Xの自動投稿を組み終えて、タスクスケジューラーの画面では全タスクが「準備完了」と表示されていました。ところが、実際には一度も動いていませんでした。
原因は、タスクを登録するスクリプトの側にありました。変数名にPowerShellの予約語を使ってしまっていて、タスクに渡す引数が丸ごと空になっていたんです。タスク自体は正常に登録されているので画面には「準備完了」と出ます。エラーも出ません。ログにも何も残りません。動いていないことに気づくまで、時間がかかりました。
この失敗のいやらしいところは、見た目上は何も間違っていないことです。タスクの一覧を眺めても、全部そろっていて、全部「準備完了」。それでも中身の引数が空なら、起動しても何もせずに終わります。「登録できた」と「意図した中身で登録できた」は、まったくの別物でした。
それ以来、タスクを登録したあとは表示だけで安心しないと決めて、確認の手順を固定しました。
登録後に毎回確認していること
- タスクのプロパティを開いて、渡している引数が空になっていないかを見る
- スケジュールを待たずに一度手動で実行して、実際に最後まで動くかを見る
- ログファイルに実行の痕跡が残っているかを見る
この中では、手動で一度実行してみるのがいちばん確実でした。スケジュール通りに動くかどうかの前に、そもそも起動して最後まで走るのか。ここを飛ばして「準備完了」の文字だけ見て寝ると、翌朝、何も起きていません。私はそれを経験しました。
勘所その2 PCが起きていなければ何も動かない

当たり前のことのようで、実際にいちばん多く踏んだのがこれです。タスクスケジューラーはクラウドのサービスではなく、自分のPCの上で動きます。つまり、PCがスリープしていたり電源が落ちていたりすれば、どれだけ丁寧に組んだタスクも走りません。
2026年7月3日から5日まで、Threadsの投稿が1本も出ていない期間がありました。原因は、早朝にPCがスリープしていて、6時の生成スクリプトが走れなかったことです。私の構成では、投稿スクリプトは生成済みのファイルを読む作りなので、朝の生成が走らなければ、その日の投稿は全部止まります。生成と投稿を分けた設計の、弱点が出た形でした。
7月14日にも、投稿が3件失敗しました。このときの原因は、PCそのものが落ちていたことです。仕組みがどれだけちゃんとしていても、土台のPCが起きていなければ何も起きない。この単純な事実を、私は2回、実際に止まってから学びました。
一般に、タスクの条件設定にはスリープを解除して実行するための項目があると言われていますが、電源まわりの設定との組み合わせで挙動が変わるところなので、私は設定で完璧に防ぐことよりも、「動くはずの時間に動いた形跡があるか」を後から確認できるようにすることを重視しています。
そのために入れたのが、先ほど書いた失敗時の通知です。投稿が失敗したらログに残り、Discordに通知が飛び、次にPCを開いたときにも報告が上がる。これを入れてから、止まっていたことに何日も気づかない、という事態は減りました。逆に言えば、通知が無かった時期は、3日間止まっていても気づけなかったわけです。定時実行の仕組みは、実行する仕組みと同じくらい、止まったことを知る仕組みが大事だと思っています。
勘所その3 エラーが表に出ない失敗がいちばんこわい
2ヶ月やってみて、時間を持っていかれた失敗は、どれも「エラーが出ない失敗」でした。赤いエラーが出てくれれば、それを読んで直せます。何も言わずに黙って止まる、あるいは黙って一部だけスキップされる。これがいちばんこわい。
たとえば、日付を整える処理で、パソコンによって使える書き方と使えない書き方があるのを知らずに書いてしまったことがあります。結果、その機能がまるごと無言でスキップされていました。エラーは出ません。ただ、その処理だけが静かに存在しないことになっていた。動作確認した環境と実行する環境が違うだけで、こういうことが起きます。
認証トークンのファイルに、BOMと呼ばれる見えないデータが混ざっていて、投稿が丸ごと止まったこともあります。ファイルを開いても、見た目は何も変わりません。中身は合っているのに認証だけ通らない。原因の特定にかなり時間がかかりました。似た話で、トークンのファイルを全行つなげて読んでしまって、認証エラーになったこともあります。実際に必要だったのは1行目だけでした。ファイルの読み方ひとつで止まるのだと知りました。
note告知が一度も投稿されていない時期もありました。このときの原因は、告知文をスプレッドシートにだけ書き込んでいて、投稿スクリプトが読むドライブ側のファイルを更新していなかったことです。仕組み自体は正常に動いていて、渡すデータの置き場所を私が間違えていただけ。当然、エラーは出ません。仕組みから見れば「読んだファイルに告知が無かった」だけですから。
こうした失敗への対策として効いているのは、結局のところ「実行のたびに痕跡を残す」ことでした。走ったらログに書く。失敗したらDiscordに飛ばす。週次と月次で集計レポートを自動で送る。痕跡が定期的に届いている状態を作っておけば、届かなくなった時点で異変に気づけます。何も届かない静けさを、正常と区別できるようにしておく、と言い換えてもいいかもしれません。
自動生成の側でも、似た構造の問題がありました。投稿文をAIに書かせていたら、実際とは違う数字を書いてきたことがあります。本当は68本なのに62本と書いていて、しかも文章としては自然なので、読んでも気づけない。対策として、実際に起きたことと実測値だけを書いた台帳を作り、そこに載っている数字しか使わせないようにしました。ところが台帳を足しただけでは直らず、前から書いてあった「毎回、具体的な出来事を必ず入れる」という指示と噛み合わなくて、台帳のネタが尽きるとやっぱり作り話をしました。「無ければ書かなくていい」と言い直して、やっと止まりました。これもエラーの出ない失敗の一種だと思っています。
認証トークンとAPIキーの管理はセットでついてくる

タスクスケジューラーそのものの話からは少し外れますが、定時実行でSNSに投稿する以上、認証情報の管理は必ずセットでついてきます。ここでもつまずいたので書いておきます。
Threadsの認証トークンは60日で切れます。あるとき確認したら、あと10日で切れるところでした。切れたら投稿が全部止まります。気づいたその日に延長して、ついでに毎月1日に自動で延長するタスクをタスクスケジューラーに足しました。期限があるものは、覚えておこうとせず、気づいたその日に自動化してしまうのがいいと思っています。少なくとも私は、自分の記憶を信用していません。
Xの方では、APIキーの確認で困りました。キーを取りに行ったら、画面には下6桁しか表示されなくて、完全な値をあとから見る方法が無かったんです。結局、いったん作り直すしかありませんでした。しかも、作り直す順番を間違えると、後から作ったほうが無効になります。親のキーを先に作り直してから、その下のキーを作り直す必要がありました。
キーやトークンの類いは、取得した瞬間に、失くす前提で保管しておくくらいでちょうどいい。これが2ヶ月での実感です。あとから見られると思っていたものが見られない、というのは、実際に起きます。
費用と、2ヶ月動かした正直な結果
費用の話をします。タスクスケジューラーはWindows標準機能なので0円です。ThreadsのAPIも無料。かかっているのはXのAPI利用料だけで、1日5本の投稿で月350円ほどです。つまり、1日10本の自動投稿と、生成・集計・告知・トークン延長まで含めた仕組み全体が、月350円ほどで回っています。
ここまで書いておいて何ですが、結果も正直に書きます。Threadsでは2026年6月25日から7月27日までに87本を自動投稿しましたが、その間、フォロワーは0人のままでした。7月は82本投稿して、合計ビュー582・いいね8・平均ビュー7.1。数字だけ見れば、届いてはいません。仕組みは毎日動いているのに、です。
2ヶ月回して分かったのは、自動投稿は「続ける力」はくれるけれど、「届く力」は別物だ、ということでした。手で毎日5本を投稿し続けるのは、私には無理だったので、続ける部分を仕組みに任せられたこと自体には意味があったと思っています。ただ、投稿の質を上げる前に、そもそも誰にも見られていないことのほうが問題でした。届く方は、いままさに試行錯誤しています。
それでも、この記事で書いた内容自体は、成果とは切り離して役に立つはずです。「毎日決まった時間に、確実に何かを実行する」という土台だけなら、追加費用ゼロで組めます。飲食の現場に10年いて、独立してから自動化を独学で始めた私でも組めたので、特別な環境や才能が要るものではないと思います。ただし、成果が出るかどうかは別の話です。そこは保証できませんし、私自身がまだ出せていません。
まとめ

- Windowsのタスクスケジューラーは標準機能なので0円で定時実行を組める。私の構成では費用はXのAPI利用料の月350円ほどだけ
- 「準備完了」の表示は信用しない。登録スクリプトの変数名が原因で引数が空になり、一度も動いていなかったことがある
- 登録後は、引数が空でないかの確認と、手動での実行テストを毎回やる
- PCが起きていなければ何も動かない。スリープで3日間、電源断で3件、実際に投稿が止まった
- エラーが表に出ない失敗がいちばんこわい。BOM、ファイルの読み方、環境差での無言スキップ、データの置き場所違いで止まった
- 実行のたびに痕跡を残し、失敗したらDiscordに通知を飛ばす。止まったことを知る仕組みは、実行する仕組みと同じくらい大事
- 認証トークンやAPIキーの管理は必ずセットでついてくる。期限ものは気づいたその日に自動化する


コメント