毎日決まった時刻に、パソコンに何かを自動でやらせたい。私の場合はSNSの投稿を1日5本、朝7時・昼12時・17時・21時・23時に出したかった。結論から書くと、これはWindowsに最初から入っている「タスクスケジューラー」だけで組めます。追加ソフトはゼロ、料金もゼロです。
ただ、実際にやってみて分かったのは、登録すること自体はそこまで難しくない、難しいのは「本当に動いたか」を確かめることでした。私は登録画面に「準備完了」と表示されているのを見て安心し、実際には一度も動いていなかった、ということを2026年8月にやっています。だからこの記事は、登録手順で終わらせず、確認の手順まで含めて書きます。
この手順でできること／必要なもの
この手順で作れるのは「決まった時刻になったら、決めておいた処理を勝手に走らせる」仕組みです。私が実際に動かしているのは、朝6時台にAIが投稿文をまとめて生成してGoogleドライブに保存する処理と、7時・12時・17時・21時・23時に、そのテキストを読んで投稿する処理です。ThreadsとX、それぞれ1日5本ずつ動いています。
必要なものは多くありません。Windowsのパソコンと、走らせたい処理そのものだけです。私はPythonで書いたスクリプトを走らせていますが、タスクスケジューラー自体は「決まった時刻に何かを起動する」だけの機能なので、起動できるファイルであれば中身は問いません。
費用の話も先に書いておきます。タスクスケジューラーはWindows標準機能なので0円です。私の場合、かかっているのはXのAPI利用料が1日5本の投稿で月350円ほど、ThreadsのAPIは無料です。つまり「決まった時刻に走らせる」という部分そのものには、一円もかかっていません。
私は元調理師で、飲食の現場に10年いてから独立しました。自動化を組み始めたのは2026年6月なので、この記事を書いている時点でまだ2ヶ月ほどです。専門的な知識があって始めたわけではないので、同じくらいの位置から始める人に向けて書きます。
STEP 1：走らせたい処理を、単体で動く状態にする
いきなりタスクスケジューラーを開きたくなりますが、先にやることがあります。走らせたい処理を、まず自分の手で動かして、最後まで正常に終わるのを確認しておくことです。ここを飛ばすと、あとで動かなかったときに「スケジュールの設定が悪いのか、処理そのものが悪いのか」が切り分けられなくなります。
私はここを一度サボって痛い目に遭っています。処理側の問題とスケジュール側の問題が混ざると、原因を探す範囲が一気に広がる。実際、認証トークンのファイルにBOMという見えない文字が混ざっていて投稿が丸ごと止まったことがあるのですが、見た目には何も変わらないので原因の特定にかなり時間がかかりました。あれがもし「スケジュール登録と同時」に起きていたら、もっと迷っていたと思います。
つまずきやすい点
手で動かすときは、できるだけタスクスケジューラーが動かすのと同じ形で起動するのがコツです。エディタの実行ボタンから動かして満足してしまうと、コマンドから叩いたときにパスが通っていない、といった差が残ります。私はコマンドプロンプトやPowerShellから、実際にタスクへ登録する予定のコマンドをそのまま打って確認しています。
もうひとつ、処理が読みに行くファイルの「置き場所」も先に固めておきます。私はここで一度失敗していて、note告知が一度も投稿されていない時期がありました。原因は、告知文をスプレッドシートにだけ書き込んでいて、投稿スクリプトが読みに行くGoogleドライブ側のファイルを更新していなかったこと。処理は正常に動いていたのに、読む先が空だったわけです。
できたかの確認方法
コマンドから叩いて、期待した結果が実際に起きていればOKです。投稿なら投稿が出ている、ファイル生成ならファイルができている。「エラーが出なかった」だけでは不十分で、結果物を目で見て確認するところまでやります。エラーが出ずに何もしていない、という状態が本当にあるからです。
STEP 2：タスクスケジューラーにタスクを登録する
処理が単体で動くのを確認したら、次はタスクの登録です。Windowsの検索窓から「タスクスケジューラー」と打てば開きます。左側のツリーからタスクを作る場所を選び、タスクの作成を選ぶと、いくつかのタブが並んだ画面が出てきます。
設定する中身はシンプルで、大きく分けて三つです。いつ動かすか（トリガー）、何を動かすか（操作）、どういう条件のときに動かすか（条件と設定）。この三つが埋まれば動きます。
いつ動かすかを決める
トリガーは「毎日」を選んで、開始時刻を入れます。私はThreadsとXそれぞれで、7時・12時・17時・21時・23時の5枠を登録しています。加えて、朝6時台に投稿文をまとめて生成する処理を別枠で走らせています。この「生成」と「投稿」を分けているのには理由があって、投稿の時刻に生成まで走らせると、生成でつまずいたときに投稿ごと巻き込まれるからです。
先に生成してテキストとして保存しておけば、投稿スクリプトはそれを読んで投げるだけになります。役割を小さく分けておくと、失敗したときにどちらが悪いのか一目で分かります。
何を動かすかを決める
操作のタブでは、起動するプログラムと、それに渡す引数を指定します。ここが一番事故が起きやすい場所でした。詳しくはSTEP 3に書きますが、引数の欄は「入っているつもり」で空になることがあります。手で打ち込む場合でも、パスに空白が含まれていると意図しない切れ方をすることがあるので、引用符の付け方は確認しておいたほうがいいです。
つまずきやすい点
「開始（オプション）」の欄、つまり作業フォルダの指定を空のままにすると、処理が相対パスでファイルを探しているときに見つけられないことがあります。私はスクリプトの置いてあるフォルダを明示的に入れるようにしました。手で動かしたときは動いたのにタスクからだと動かない、というときは、まずここを疑うようにしています。
できたかの確認方法
登録が終わると、一覧にタスクが並んで状態が「準備完了」と表示されます。ただし、この表示は「登録されている」以上のことを何も保証しません。ここで安心しないでください。確認は次のSTEPでやります。
STEP 3：登録した内容が空になっていないか確かめる
ここが、この記事でいちばん書きたかったSTEPです。2026年8月4日、私はXの自動投稿を組んで、タスクは全部「準備完了」と表示されていたのに、実際は一度も動いていませんでした。
原因は、タスクを登録するスクリプトの側にありました。変数名にPowerShellの予約語を使ってしまっていて、その結果タスクに渡す引数が丸ごと空になっていたのです。タスク自体は登録されているので一覧には正常に見える。時刻が来れば起動もする。でも引数が空なので、処理は何もせずに終わる。エラーもログも残りません。
気づくのに時間がかかりました。エラーが出ていれば探しにいけるのですが、何も出ないので「動いているはず」という前提が崩れないんです。エラーが表に出ない失敗が、いちばんこわいと思っています。
何をするか
登録が終わったら、一覧でタスクを選んで、プロパティを開きます。操作のタブを見て、プログラムのパスと引数の欄に、意図した文字列がそのまま入っているかを目で確認します。これだけです。作業としては数十秒で終わります。
スクリプトからまとめて登録した場合は特に必須です。手で1個ずつ作ったときは打ち込んだ内容がそのまま入りますが、スクリプト経由だと変数の展開に失敗しても静かに通ってしまいます。私はそれ以来、タスクを登録したあとは「準備完了」の表示だけで安心せず、渡している引数が空になっていないかを毎回確かめるようにしています。
つまずきやすい点
複数タスクを一括で登録したときは、全部を確認します。私は5枠×2アカウントで10個あるので、面倒でも全部開きます。1個だけ引数が空、というパターンは表からはまったく見えません。
それと、この確認は「引数が入っているか」であって「引数が正しいか」ではありません。パスの綴り間違いなどは、この段階では気づけません。それを見つけるのが次のSTEPです。
できたかの確認方法
プロパティの操作タブに、自分が書いたつもりの文字列が過不足なく表示されていればOKです。空欄、途中で切れている、引用符が変な位置にある、のどれかであれば登録し直します。
STEP 4：時刻を待たずに、手動実行で本当に動くか試す
引数の確認ができたら、次は実際に走らせます。設定した時刻を待つ必要はありません。タスクの一覧でタスクを右クリックすると実行という項目があるので、それを押せばその場で走ります。
ここが登録と確認をつなぐ一番大事な工程です。時刻を待つと、動かなかったときに「時刻の設定が悪いのか、処理が悪いのか」がまた分からなくなる。手動実行で走らせれば、少なくとも「タスクから起動したときに処理が最後まで通るか」だけを切り分けて確認できます。
何を見るか
実行したあと、見るべきものは二つあります。ひとつは結果物。投稿なら投稿が出ているか、ファイル生成ならファイルができているか。もうひとつは、タスクスケジューラーの一覧に表示される「前回の実行結果」です。ここに実行結果のコードが出ます。
ただし、ここでも油断はできません。タスク側の実行結果が正常でも、処理の中身が何もしていない場合があります。私が8月に踏んだのはまさにこれで、タスクとしては起動して正常終了しているけれど、引数が空だったので中身が空回りしていた。だから結果物の確認とセットで見る必要があります。
つまずきやすい点
「手で動かしたときは動いたのに、タスクからだと動かない」というときは、実行するユーザーの違いと作業フォルダの指定を疑います。私はここでつまずいたときに、STEP 2で書いた作業フォルダの指定を入れて解決しました。
もうひとつ、処理が読み込むファイルの形式が原因のこともあります。私は認証トークンのファイルを全行つなげて読んでしまって認証エラーになったことがあります。実際に必要だったのは1行目だけでした。こういうものは手で動かしたときも同じように失敗するはずなので、STEP 1をきちんとやっていれば手前で潰せます。
できたかの確認方法
手動実行で、期待した結果物ができていればこのSTEPはクリアです。ここまで来て初めて「設定した時刻に走るはず」という状態になります。逆に言えば、ここを通していない状態は、まだ何も確認できていないということです。
STEP 5：失敗したときに気づける仕組みを入れる
手動実行が通ったら、次は「失敗に気づける状態」を作ります。ここまでのSTEPは一度やれば終わりますが、毎日走る仕組みはこれから先も失敗し続けるものだと思っておいたほうがいいです。実際、私のところでは何度も止まっています。
2026年7月3日から5日まで、Threadsの投稿が1本も出ていませんでした。原因は早朝にPCがスリープしていて、6時の生成スクリプトが走れなかったこと。7月14日にも投稿が3件失敗していて、こちらもPCが落ちていたことが原因でした。処理そのものではなく、パソコンが起きていなかったという話です。
この手の失敗は、通知が来なければ何日も気づきません。私は投稿が失敗したらログに残るようにして、Discordに通知が飛ぶようにして、さらに次にPCを開いたときにも報告が上がるようにしました。三重にしているのは、ログだけだと見に行かないからです。
つまずきやすい点
通知を仕込むときに一番やりがちなのが、「処理がエラーで落ちたとき」しか通知しない作りにすることです。それだと、そもそも処理が起動しなかったケースを取りこぼします。スリープで走らなかったときも、引数が空で何もせず正常終了したときも、エラーは発生していません。
私は週次と月次で、自分の投稿を自動集計してDiscordにレポートが飛ぶようにしました。本数が集計されるので、想定より少なければ「どこかで走っていない」と分かります。エラー通知が「起きた失敗」を教えるのに対して、集計は「起きなかったこと」を教えてくれます。無言の失敗に対しては、こちらのほうが効きました。
できたかの確認方法
わざと失敗させてみて、通知が届くかを確認します。私は処理が読みに行くファイルの名前を一時的に変えて、通知が飛ぶことを確かめました。通知の仕組みを入れただけで確認していないと、それ自体が無言で壊れます。
STEP 6：期限のあるものを、あとから慌てないように仕込む
最後のSTEPは、少し先を見る話です。決まった時刻に走らせる仕組みを作ると、しばらくは順調に動きます。でも「期限のあるもの」が中に含まれていると、ある日突然全部止まります。
私の場合はThreadsの認証トークンでした。有効期限が60日で、気づいたときにはあと10日で切れるところだった。切れたら投稿が全部止まります。気づいたその日に延長して、ついでに毎月1日に自動で延長する仕組みを入れました。これもタスクスケジューラーの、月1回のトリガーで動かしています。
もうひとつ、これに関連して踏んだのがAPIキーの再発行です。XのAPIキーを取りに行ったら、画面には下6桁しか表示されなくて、完全な値を見る方法がありませんでした。結局いったん作り直すしかなかった。しかもキーを作り直す順番を間違えると、後から作ったほうが無効になります。親のキーを先に作り直してから、その下のキーを作り直す必要がありました。
つまずきやすい点
期限のあるものは、切れる直前まで何の症状も出ません。だから普段の確認では見つかりません。私は「期限があるものは、期限が来る前に自動で更新する処理を、別のタスクとして登録する」という形にしました。人間の記憶に頼ると、必ず忘れます。
なお、期限の管理をカレンダーやリマインダーでやる方法もあると思いますが、ここは私は試していません。私はタスクスケジューラーで月次の更新処理を回す形にしただけです。
できたかの確認方法
更新処理を仕込んだら、これも手動実行で走らせて、実際に期限が延びているかを確認します。STEP 4と同じで、登録しただけでは確認になりません。
組んでみて分かったこと
ここまでが手順です。最後に、2ヶ月ほど回してみて分かったことを、良かった点と期待外れだった点の両方で書いておきます。
まず良かった点。決まった時刻に走る仕組みは、「続ける力」を確実にくれます。2026年6月25日から7月27日までに、Threadsへ87本を自動投稿しました。7月だけで82本です。これを毎日手で投稿していたら、間違いなくどこかで止まっていたと思います。私は営業もテキストのやり取りも苦手で、決まった時間に何かを出し続けるのは相当きついので、そこを機械に渡せたのは大きかった。
そして期待外れだった点。「続ける力」と「届く力」は完全に別物でした。87本投稿した期間、フォロワーは0人のままでした。7月27日時点で数えたとき、7月のビューは527・いいね7・返信0・リポスト0。返信は一度も来ていません。68本のうち13本はビューが0か1のまま。週ごとの平均ビューは18.2→15.9→8.4→7.9→5.0と右肩下がりでした。
直近も似た状況です。2026年8月4日までの7日間で24本投稿して、合計ビュー120・いいね1・返信0。うち8本はビューが0か1のままでした。noteのほうは7月27日時点で記事27本、フォロワー2人、全記事の合計いいねが45です。
数字を並べて何が言いたいかというと、仕組みを作ることと、結果が出ることは、まったく別の話だということです。定時実行の手順自体は、この記事に書いたとおりやれば組めます。でも組んだからといって見られるようになるわけではない。私はここを勘違いしていて、まず自動化を整えれば何とかなると思っていました。実際には、投稿の質を上げる前に、そもそも誰にも見られていないことのほうが問題でした。
ひとつだけ、傾向として見えたものはあります。7月27日時点のスロット別平均ビューは朝15.7・昼5.7・夜1.8で、朝がいちばん見られていました。7月全体で見ても平均ビューが最も高かったのは朝の枠です。ただし8月4日までの週は朝6.0・昼6.6・夜2.4で、昼のほうが上でした。数字が小さいので、これを法則として扱うのは難しいと思っています。
もうひとつ、書いた内容の傾向としては、抽象的な問いかけだけの投稿より、具体的なしくじりを書いた投稿のほうが見られていました。これは実感としてそう感じている、というレベルの話です。
それでもこの仕組みを止めていないのは、手応えが無い時期のあとに来るものがあると知っているからです。引き継いだクライアントの案件をコンセプトから作り直したことがあって、それが最近になって伸びました。伸びるまで手応えは一切なく、やっている最中は効いているのかどうか分からないままでした。クライアントも驚いていたし、正直、自分でも驚きました。だから今も、反応が無い期間をすぐ失敗とは思わないようにしています。
まとめ
- 決まった時刻に処理を走らせるのは、Windows標準のタスクスケジューラーだけでできる。追加ソフトは不要で、この部分の費用は0円。
- まず走らせたい処理を単体で最後まで動かす。ここを飛ばすと、動かないときに原因の切り分けができなくなる。
- 登録したら、一覧の「準備完了」表示で安心しない。プロパティを開いて、プログラムのパスと引数が空になっていないかを目で確認する。
- 時刻を待たず、右クリックの手動実行で走らせる。実行結果のコードだけでなく、結果物ができているかまで見る。
- 失敗に気づける仕組みを入れる。エラー通知だけでは「そもそも起動しなかった」を取りこぼすので、本数の集計もあわせて出す。
- 認証トークンのような期限があるものは、更新処理そのものを別タスクとして登録する。人間の記憶には残らない。
- 私の実測では、6月25日〜7月27日に87本を自動投稿してフォロワーは0人のまま、7月のビューは527・いいね7・返信0だった。仕組みが動くことと、届くことは別だった。
コメント