自動化を始めようと思ったとき、いちばん時間を溶かしたのは「作る作業」ではなく「何を自動化するか決める作業」でした。私は2026年6月から自動化を組み始めて、まだ2ヶ月ほどしか経っていません。その2ヶ月で分かったのは、最初に手をつけるべきなのは「毎日やっていて、途中で判断が一切要らない作業」だけということです。
逆に言うと、それ以外から手をつけると失敗します。私は実際に順番を間違えて、動いていないものを「動いている」と思い込んだまま数日過ごしました。この記事では、自動化する対象をどう選んだか、どういう順番で間違えたか、いま何を残して何をやめたかを、実際に手元にある数字と一緒に書きます。
私は元調理師で、飲食の現場に10年いました。そこからSNS運用代行のフリーランスとして独立した人間です。プログラマー出身ではないので、ここに書くのは「詳しい人の正解」ではなく「素人が2ヶ月かけて手探りで決めた基準」です。
結論：毎日やる作業から。判断が要る作業は後回し
自動化する対象を選ぶとき、私が最後に落ち着いた基準は2つだけです。ひとつは「毎日、または決まった曜日に必ず発生するか」。もうひとつは「その作業の途中で、自分が何かを決めているか」です。
前者がYesで後者がNoの作業だけを、最初に自動化しました。毎日やる作業は、自動化した効果がそのまま毎日返ってきます。判断が要らない作業は、書くべきルールが単純で、動かなかったときの原因も追いやすいです。
逆に、判断が入る作業を先に自動化しようとすると、そのつど例外が出てきます。例外を潰すために条件を足して、条件が増えて、結局どこで間違えたのか分からなくなる。私はこれを一度やって、途中で捨てました。
具体的に何を最初に選んだか
私が最初に自動化したのは、SNSへの定時投稿です。Threadsに1日5本、7時・12時・17時・21時・23時に自動で投稿しています。Windowsのタスクスケジューラーと、Pythonと、APIを直接叩く構成で組みました。
この作業を選んだ理由は単純で、毎日必ず発生して、しかも「投稿する時刻を決める」という判断が事前に済んでいるからです。7時になったら投げる。それだけです。中身を書くという判断は別の工程に切り出しました。
同じ作りで、Xにも1日5本、同じ時間に自動投稿しています。こちらは2026年8月4日に動かし始めました。Threadsで動いた仕組みをほぼそのまま持っていけたので、2本目は1本目よりずっと早く組めています。
「判断が要らない」を見分ける方法
判断が要るか要らないかは、頭で考えると意外と分かりません。自分では「決めていない」と思っている作業に、実は毎回小さな判断が挟まっていることがあるからです。
私が使ったのは、その作業を言葉で書き出してみる方法です。手順を上から順に文章にして、途中に「〜なら」「〜の場合は」「様子を見て」といった言葉が出てきたら、そこに判断が入っています。出てこなければ、自動化の候補として上に置きます。
たとえば「7時に投稿する」は、書き出しても分岐が出ません。一方で「反応が良さそうな投稿を選んで再投稿する」は、「良さそう」の時点で判断が入ります。前者は最初に、後者は後回しにしました。
判断を「前工程」に追い出せないか考える
ただ、判断が入るからといって全部を諦めたわけではありません。判断そのものを別の時間帯にまとめて追い出せば、実行部分は判断ゼロにできます。
投稿文の生成がまさにそれです。毎朝6時台にAIが1日分の投稿文をまとめて生成して、Googleドライブにテキストとして保存します。7時以降の投稿スクリプトは、そのファイルを読んで投げるだけです。書く工程と投げる工程を分けたことで、投げる側は完全に判断が要らなくなりました。
この分け方は、あとから効いてきました。投稿が出ない不具合が起きたとき、「文が作られていないのか」「文はあるのに投げられていないのか」を切り分けるだけで、原因の半分は絞れます。工程を分けるのは、作るときの手間より、壊れたときの調査のために意味があると感じています。
順番を間違えた実例：動いていないのに気づけなかった
いちばん痛かったのは、Xの自動投稿を組んだときです。タスクスケジューラーの画面には全部のタスクが「準備完了」と表示されていて、私はそれを見て動いていると思い込んでいました。実際には一度も動いていませんでした。
原因は、タスクを登録するスクリプトの中で、変数名にPowerShellの予約語を使っていたことです。そのせいでタスクに渡す引数が丸ごと空になっていました。引数が空なので中身が実行されず、しかも実行されていないのでエラーも出ず、ログにも何も残りません。
この手の失敗は、画面上は何も問題がないように見えます。エラーが赤字で出てくれれば気づけますが、無言で何もしないものは気づけません。それ以来、タスクを登録したあとは「準備完了」の表示だけで安心せず、渡している引数が空になっていないかを毎回確かめるようにしています。
似た失敗をもう一つ
日付を整える処理を書いたときも、同じことをやりました。パソコンによって使える書き方と使えない書き方があるのを知らずに書いて、その機能がまるごと無言でスキップされていました。これもエラーは出ません。
2026年7月3日から5日までは、Threadsの投稿が1本も出ていませんでした。原因は早朝にPCがスリープしていて、6時の生成スクリプトが走れなかったことです。7月14日にも投稿が3件失敗していて、こちらもPCが落ちていたことが原因でした。
自動化する作業を選ぶ話をしているのに失敗談ばかり書いているのは、「自動化できるか」より先に「壊れたときに気づけるか」を選定基準に入れるべきだと分かったからです。気づけない自動化は、無いのと同じどころか、動いていると勘違いする分だけ悪いです。
「気づける状態」をセットで作る
そこで、投稿の自動化と同時に、失敗を検知する側も作りました。投稿が失敗したらログに残り、Discordに通知が飛び、次にPCを開いたときにも報告が上がるようにしています。
通知先をDiscordにしたのは、私の場合メールだと埋もれるからです。ここは好みが分かれるところだと思いますが、少なくとも「見に行かないと分からない場所」に置くと確実に見なくなります。
加えて、週次と月次で自分の投稿を自動集計して、Discordにレポートが飛ぶようにしました。これは失敗検知とは別の目的で、そもそも自分がどれだけ投稿していて、どれだけ見られているのかを、思い込みではなく数字で持つためです。
期限があるものは自動化の優先度が高い
もうひとつ、選定基準に後から足したのが「放っておくと期限が来て止まるもの」です。Threadsの認証トークンは60日で切れます。切れたら投稿が全部止まります。
これに気づいたのは、あと10日で切れるというタイミングでした。気づいたその日に延長して、ついでに毎月1日に自動で延長する仕組みを入れました。もし気づかなければ、ある日突然、全部の投稿が無言で止まっていたはずです。
毎日やる作業ほど目立たないけれど、期限で止まるものは被害が大きいです。作業時間の削減にはならなくても、こういうものは早めに自動化しておく価値があると感じています。
実際に自動化して、どうだったか（数字）
自動化した結果を、都合の良いところだけ書いても意味がないので、手元の実測値をそのまま出します。
Threadsは2026年6月25日から7月27日までに87本を自動投稿しました。その間、フォロワーは0人のままでした。7月27日時点で数えたとき、7月のビューは527、いいね7、返信0、リポスト0でした。返信は一度も来ていません。
スロット別の平均ビューは、7月27日時点で朝15.7、昼5.7、夜1.8でした。朝がいちばん見られています。週ごとの平均ビューは18.2、15.9、8.4、7.9、5.0と右肩下がりでした。7月27日時点では、68本のうち13本がビュー0か1です。
月単位でも集計しています。2026年7月のThreadsは82本投稿して、合計ビュー582、いいね8、平均ビュー7.1でした。平均ビューが最も高かったのは朝の枠です。ビューが0か1のままだった投稿は18本ありました。
直近では、2026年8月4日までの7日間でThreadsに24本投稿して、合計ビュー120、いいね1、返信0でした。この週のスロット別平均ビューは朝6.0、昼6.6、夜2.4。ビューが0か1のままだった投稿は8本でした。
noteのほうは、2026年7月27日時点で記事27本、フォロワー2人、全記事の合計いいねが45です。
この数字から何を選び直したか
この結果を見て思ったのは、自動投稿は「続ける力」はくれるけれど「届く力」は別物だということです。87本を人力で投稿し続けるのは私には無理でしたが、自動化しても見られる本数が増えるわけではありませんでした。
そして、投稿の質を上げる前に、そもそも誰にも見られていないことのほうが問題だと分かりました。質を上げるための自動化を先に作っていたら、見られていない文章の質を上げ続けることになっていたはずです。
ひとつだけ手応えがあったのは、抽象的な問いかけだけの投稿より、具体的なしくじりを書いた投稿のほうが見られていたことです。これは中身の話であって、自動化の話ではありません。だからこそ、自動化する対象と、自分で考える対象を分ける必要があると感じました。
自動化しない、と決めた作業
選ぶ話の裏側として、自動化しないと決めたものも書いておきます。ここを決めないと、全部を自動化しようとして手が止まります。
まず、投稿の中身を最終的に判断する部分は自動化していません。理由は、AIに書かせていたら実際とは違う数字を書いてきたことがあるからです。本当は68本なのに62本と書いていて、しかも文章としては自然なので、読んでも気づけませんでした。
対策として、実際に起きたことと実測値だけを書いた台帳を作り、そこに載っている数字しか使わせないようにしました。ただ、台帳を足しただけでは直りませんでした。前から書いてあった「毎回、具体的な出来事を必ず入れる」という指示と噛み合わず、台帳のネタが尽きるとやっぱり作り話をしたからです。「無ければ書かなくていい」と言い直して、ようやく止まりました。
この経験から、間違っていても自分では気づけない種類の作業は、自動化の対象から外すか、必ず人が確認する工程を残すようにしています。投稿が出ないのは気づけますが、内容が違うのは気づけません。
自動化したのに手を動かしてしまっている部分
正直に書くと、自動化を作っているのに、結局そのつど自分の手を動かしてしまっている作業もあります。ここは今の私の課題です。
原因のひとつは、自動化した工程の前後に、自動化していない手作業が残っていることだと思っています。前工程が手動だと、そこを通るたびに人が介在するので、真ん中だけ自動でも全体としては手が離れません。
note告知でこれに近い失敗をしました。告知が一度も投稿されていない時期があって、原因は告知文をスプレッドシートにだけ書き込んで、投稿スクリプトが読むドライブ側のファイルを更新していなかったことです。工程はつながっているつもりでも、データの置き場所がつながっていないと動きません。
いまはnoteの新着をRSSで拾って、月水金に自動で告知しています。Xでは本文にURLを置かず、投稿にぶら下げる返信に貼る形にしました。
作る前に確認しておくと楽なこと
ここまでの失敗を踏まえて、対象を決めたあと、作り始める前に確認しておくと楽だったことを書きます。
ひとつは、その作業に必要な認証情報を、あとから見返せるかどうかです。私はXのAPIキーを取りに行ったとき、画面に下6桁しか表示されず、完全な値を見る方法がありませんでした。結局いったん作り直すしかありませんでした。
しかもキーを作り直す順番を間違えると、後から作ったほうが無効になります。親のキーを先に作り直してから、その下のキーを作り直す必要がありました。ここは知らないと確実に一度ハマります。
もうひとつは、設定ファイルの中身です。認証トークンのファイルにBOMが混ざっていて、投稿が丸ごと止まったことがあります。見た目は何も変わらないので、原因の特定に時間がかかりました。同じくトークンのファイルを全行つなげて読んでしまい、認証エラーになったこともあります。実際に必要だったのは1行目だけでした。
費用の話
費用も先に確認しておいたほうがいい項目です。私の場合、いま自動化にかかっているのは、XのAPI利用料が1日5本の投稿で月350円ほど。ThreadsのAPIは無料です。タスクスケジューラーはWindowsの標準機能なので0円です。
対象を選ぶ段階で「これを自動化したらいくらかかるか」を見ておくと、途中で止める判断がしやすくなります。無料で組めるものから始めれば、失敗しても捨てやすいです。
私が使ったツールと、その範囲
ここまでに出てきた構成をまとめておきます。実行のスケジュールはWindowsのタスクスケジューラー、通知はDiscord、生成文の置き場はGoogleドライブ、集計の一部はGoogleスプレッドシートです。文章の生成にはChatGPTとClaudeとGeminiを使っています。画像はGeminiとhiggsfieldを触りました。
私が実際に使ったことがあるのはこれだけです。世の中には他にも自動化のツールがありますが、私は未検証なので、ここでおすすめとして挙げることはしません。
タスクスケジューラーを選んだのは、Windowsに最初から入っていて追加費用がかからないからです。一方で、PCが落ちていたりスリープしていたりすると走らないという弱点があります。7月に投稿が止まった原因は、まさにここでした。この弱点を知ったうえで使うか、別の方法を選ぶかは、作業内容によると思います。
いまの状況と、次にやること
正直なところ、自社の収益はまだ立っていません。業務委託は仕事量が多くて大変なわりに利益は低く、AIを使った仕事に可能性は感じているものの、収益が立っていないので方向性が合っているのか不安になります。自分の発信の集客もうまくいっていません。誰にも見られていない状況が続くのは、単純にきついです。
それでも自動化を続けているのは、一度うまくいった経験があるからです。引き継いだクライアントの案件を、コンセプトから作り直したものが最近になって伸びました。ただ、伸びるまで手応えは一切ありませんでした。やっている最中は、効いているのかどうか分からないままでした。
手応えが無い時期がしばらく続いたあとで、急に来た。だから今も、反応が無い期間をすぐ失敗とは思わないようにしています。Threadsの数字が右肩下がりでも、まだ2ヶ月です。
直近では、2026年8月6日に自社サイト（7ページ）とLPの公開準備を終えました。問い合わせフォームをGoogleフォームにつなぎ、送信テストまで成功しています。あとはサーバーに置くだけです。数字が動くかどうかは分かりませんが、動いたかどうかを測れる状態にはしておきます。
まとめ
- 最初に自動化するのは「毎日やる」かつ「途中で判断が要らない」作業。この2つを満たすものだけを選ぶ。
- 判断が入るかどうかは、手順を文章に書き出して「〜なら」「様子を見て」が出てくるかで見分ける。
- 判断が入る場合は、判断を前工程にまとめて追い出せば、実行部分は判断ゼロにできる。投稿文は朝まとめて生成し、投稿はそれを読んで投げるだけにした。
- 「自動化できるか」より「壊れたときに気づけるか」を先に確認する。エラーも出ずに無言でスキップされる失敗がいちばん厄介だった。
- タスクを登録したら「準備完了」の表示を信じず、渡している引数が空でないか毎回確かめる。
- 放っておくと期限で止まるもの（認証トークンなど）は、作業時間の削減にならなくても優先度を上げる。
- 間違っていても自分では気づけない作業（数字を含む文章の生成など）は、対象から外すか人の確認工程を残す。
- 自動投稿は続ける力はくれたが、届く力は別だった。87本投稿してフォロワー0人、7月のビューは527、返信0という実測値がそれを示している。
- 費用は先に確認する。私の構成はXのAPIが月350円ほど、Threads APIとタスクスケジューラーは0円。
コメント