自動化でいちばん怖いのは、動かなくなることではありません。動かなくなったときに、動いていたころの状態がもう手元に無いことです。私はこれを、2026年6月から自動投稿の仕組みを組み始めて2ヶ月ほどの間に何度か味わいました。結論から書くと、上書きする前に控えを取るという癖ひとつで、復旧にかかる時間はまったく変わります。
私は元調理師で、飲食の現場に10年いました。そこからSNS運用代行のフリーランスとして独立して、いまはThreadsとXで1日5本ずつの自動投稿を回しています。Windowsのタスクスケジューラーと、PythonでAPIを直接叩く作りです。プログラミングを仕事にしてきた人間ではないので、この記事に書くのは高度な冗長構成の話ではありません。素人が壊しても戻せるようにするには、何を残しておけばよかったかという、失敗から逆算した話です。
バックアップは「消えたとき」より「変えたとき」のために要る
自動化を始めたころ、私はバックアップという言葉をディスク障害と結びつけて考えていました。ファイルが消えたときに戻すもの、という理解です。実際に困ったのは、そこではありませんでした。自分で変更して、自分で壊して、変更前がどうだったか思い出せないという場面のほうが、圧倒的に多かったのです。
自動化の設定というのは、少しずつ触るものです。投稿の時間をずらす、生成の指示文を書き換える、失敗したときの通知先を変える。ひとつひとつは小さな変更で、そのときは「これで良くなるはず」と思って触っています。ところが数日経ってから不調に気づいたとき、原因が今日の変更なのか、三日前の変更なのか、そもそも変更とは無関係なのかが分からなくなります。
自動化は基本的に、動いているあいだ何も言ってきません。ここが手作業と決定的に違うところです。手作業なら、おかしければその場で目に入ります。自動化は、静かに間違ったまま走り続けます。だから「いつの状態に戻せばいいのか」を後から特定できることが、バックアップの本体だと考えるようになりました。
私が実際に「戻せなくて」困った場面
2026年7月3日から5日まで、Threadsの投稿が1本も出ていませんでした。原因は早朝にPCがスリープしていて、6時の生成スクリプトが走れなかったことです。これは設定を触ったせいではなかったのですが、気づいた瞬間に私が最初に疑ったのは「直前に自分が何かいじったのでは」でした。そして、いじったかどうかを確かめる手段が、そのときの私には無かったのです。
結局その日は、スクリプトを頭から読み直して、たぶんここは触っていない、たぶんここも触っていない、と確認していきました。ものすごく非効率でした。前の状態のコピーが1つ残っているだけで、差分を見れば5秒で済んだ話です。
控えを取るタイミングは「上書きする直前」に固定する
いろいろ試した結果、私が落ち着いたのは定期的に取るのではなく、上書きする直前に取るというやり方でした。週に一度まとめて、といった運用は、私の場合まず続きませんでした。忘れるからです。それに、週次で取っていても「今週の火曜に何をどう変えたか」は残りません。
上書きの直前という条件は、忘れにくいという利点があります。ファイルを開いて書き換えようとしている、まさにその瞬間だからです。私はスクリプトや設定ファイルを編集するとき、編集前のファイルを日付つきの別名でコピーしてから触るようにしました。凝った仕組みではなく、ただのコピーです。
この癖が効いてくるのは、変更が複数にまたがったときです。たとえば投稿の生成処理を書き換えると、生成側だけでなく、それを読む投稿側の期待する形も変わることがあります。片方だけ戻しても直りません。両方の編集前を同じ日付で残しておけば、セットで戻せます。
どこまで控えるかの線引き
最初は「全部残しておけば安心」と思って、動くファイルを片っ端からコピーしていました。これは失敗でした。控えが増えすぎて、どれが直前のものか分からなくなったからです。バックアップが多すぎるのは、無いのと大差ないというのが実感です。
いまは、対象を絞っています。私が残しているのは、投稿を実行するスクリプト、AIに渡す指示文、認証トークンやキーの類、そしてタスクスケジューラーへの登録内容です。逆に、AIが毎朝生成する投稿文そのものは控えていません。あれは失っても翌朝また作られるものだからです。
作り直せるものは控えなくていい。作り直せないもの、作り直すのに手間がかかるものだけ控える。
この線引きで考えると、意外と対象は少なくなります。私の場合、本当に守らなければいけないのは10ファイルもありません。数が少ないと、上書き前のコピーという習慣も維持しやすくなります。
実際に控えがあって助かった場面
2026年8月4日に、Xの自動投稿を組んだときの話です。タスクスケジューラーの画面では全部のタスクが「準備完了」と表示されていたのに、実際には一度も動いていませんでした。原因は、タスクを登録するスクリプトの中で変数名にPowerShellの予約語を使ってしまっていて、タスクに渡す引数が丸ごと空になっていたことでした。
この不具合のいちばん厄介なところは、エラーもログも残らないことです。タスクは「起動しました、終了しました」という顔をしています。投稿されていないという結果だけがあって、途中経過が何も無い。原因にたどり着くまでに時間がかかりました。
このとき助かったのが、登録スクリプトを何度か書き換える過程で残していた編集前のコピーでした。動かない状態と、その前の状態を並べて見ることで、変数名の扱いが変わっている箇所に目が行きました。控えが無ければ、動かない現物をずっと睨み続けていたはずです。
比較できるものがあると、思い込みが崩れる
自分で書いたものを自分で読み直すと、書いたときの意図がそのまま頭に残っているので、書いてある内容ではなく意図のほうを読んでしまいます。「ここはこうしたつもりだから、こうなっているはず」と思い込む。これが原因特定を遅らせます。
前のバージョンと並べると、この思い込みが崩れます。意図ではなく差分を見ることになるからです。私にとってバックアップの価値は、復元よりもむしろ比較対象が手に入ることのほうが大きいと感じています。
鍵とトークンは、控えの取り方が別扱いになる
認証情報まわりは、他のファイルと同じ感覚で扱うと痛い目を見ます。私は実際に見ました。
XのAPIキーを取りに行ったとき、画面には下6桁しか表示されず、完全な値を確認する方法がありませんでした。控えを取っていなかったので、いったん作り直すしかありませんでした。しかもこのとき、作り直す順番を間違えると、後から作ったほうが無効になるという構造がありました。親のキーを先に作り直して、その下のキーを後から作り直す必要があったのです。
ここから学んだのは、キーは発行された瞬間が唯一の控えを取れるタイミングだということです。後からもう一度見られる前提で進めると、詰みます。一般に、この手のシークレット値は再表示できない設計になっていることが多いと言われています。私が触った範囲でも、実際そうでした。
控える場所と、控え方
キーやトークンをどこに置くかは、正直まだ答えが出ていません。私はいまGoogleドライブとローカルの両方に持っていますが、これがベストだとは思っていません。ただ、置き場所の話とは別に、ファイルの形で何度も失敗しているので、そこは書いておきます。
認証トークンのファイルにBOMが混ざっていて、投稿が丸ごと止まったことがあります。見た目は何も変わりません。エディタで開いても、トークンの文字列がそのまま見えるだけです。それなのに読み込み側が弾く。原因の特定に時間がかかりました。
別のときには、トークンのファイルを全行つなげて読んでしまって認証エラーになりました。実際に必要だったのは1行目だけでした。これも、ファイルの中身自体は正しいのに動かないパターンです。
この2つを踏まえて、いまは認証情報のファイルをコピーするときに、テキストエディタで開いて手で貼り直すようなことをしないようにしています。ファイルはファイルのままコピーする。中身を見て貼り直した瞬間に、見えない何かが混ざる余地が生まれるからです。
期限切れは、バックアップでは救えない
控えを取る話をしていると、なんでも控えで解決できる気がしてきますが、そうではない領域があります。期限です。
Threadsの認証トークンは60日で切れます。私は、あと10日で切れるところで気づきました。切れたら投稿は全部止まります。ここで控えがあっても意味はありません。古いトークンをいくら大事に保管していても、切れたものは切れているからです。
気づいたその日に延長して、ついでに毎月1日に自動で延長する仕組みを入れました。バックアップと自動更新は、目的が違います。バックアップは過去に戻すためのもので、自動更新は未来で止まらないためのものです。両方要ります。
「無言で止まるもの」を一覧にしておく
期限切れのように、事前に予定が分かっている停止要因は、リストにしておくと安心できます。私はThreadsのトークンの件があってから、期限があるもの、外部サービスの都合で失効しうるものを意識するようになりました。
日付を整える処理でも似た失敗をしています。パソコンによって使える書き方と使えない書き方があるのを知らずに書いて、機能がまるごと無言でスキップされていました。エラーが表に出ない失敗が、いちばんこわいです。動いているように見えて動いていないものは、バックアップの対象を決めるとき視界に入ってきません。
戻せるようにするより、壊れたことに気づけるようにする
ここまでバックアップの話を書いてきましたが、実際に運用してみて分かったのは、控えの取り方より壊れたことに気づくまでの時間のほうが、被害の大きさを決めるということでした。
3日止まっていた投稿は、控えがあれば3日ぶんが戻るわけではありません。止まった時間は戻りません。7月3日から5日の停止も、控えの問題ではなく、気づくのが遅れた問題でした。
そこで、投稿が失敗したらログに残して、Discordに通知が飛ぶようにしました。さらに次にPCを開いたときにも報告が上がるようにしています。7月14日には投稿が3件失敗しましたが、これはPCが落ちていたことが原因で、通知があったのでその日のうちに把握できました。
通知が来ないことと、正常であることは違う
ただし、この通知にも穴があります。Xのタスクが一度も動いていなかった件では、そもそも起動していないので失敗通知も飛びません。通知が来ていない状態は、正常なのか、通知の仕組みごと死んでいるのか区別がつかないのです。
いまは週次と月次で自分の投稿を自動集計して、Discordにレポートを飛ばしています。本数がレポートに出てくるので、動いていなければ数字が減ります。「悪いことが起きたら知らせる」だけでなく「何本出たか毎回報告する」を足したのは、この穴のためです。
それと、タスクを登録したあとは「準備完了」の表示だけで安心しないようにしました。渡している引数が空になっていないか、毎回確かめます。表示上の正常は、動作の正常を意味しません。
ファイルの二重管理が生む、静かな不整合
復旧の話でもうひとつ書いておきたいのが、同じ内容を2箇所に持ったときの事故です。
noteの新着告知が一度も投稿されていない時期がありました。原因は、告知文をGoogleスプレッドシートにだけ書き込んでいて、投稿スクリプトが実際に読むGoogleドライブ側のファイルを更新していなかったことです。スプレッドシートを見ると告知文はちゃんと入っているので、一見すると何も問題が無いように見えました。
これはバックアップの失敗というより、どちらが本物か決めていなかったことによる失敗です。控えのつもりで置いたものと、実際に読まれるものが混ざると、こういうことが起きます。
いまは、投稿スクリプトが読むファイルを本物と決めています。毎朝6時台にAIが投稿文をまとめて生成してGoogleドライブにテキストで保存し、投稿スクリプトはそれを読んで投げるだけ、という一方通行の形です。スプレッドシートは集計や記録のために使いますが、投稿の実行系はそこを見ません。
控えは控えだと分かる名前にする
本物と控えを取り違えないようにするために、控えのファイル名には日付を入れています。控えかどうかを中身で判断しないといけない状態は危険です。私は一度、控えのつもりのファイルを本番の場所に置いたまま忘れかけたことがあります。名前を見た瞬間に区別がつくようにしておくと、こういう事故が減ります。
AIに直させるときこそ、控えが要る
スクリプトの修正をAIに手伝ってもらうことは多いです。私が実際に使っているのはChatGPT、Claude、Geminiです。便利なのですが、丸ごと書き換えられたときに元が無いと、比較する相手がいなくなります。
AIが返してくるコードは、たいてい自然に読めます。読めるからこそ、変わっている箇所に気づきにくい。これは文章でも同じ経験をしていて、投稿文をAIに書かせていたら、本当は68本なのに62本と書いてきたことがありました。文章としては自然なので、読んでも気づけません。
対策として、実際に起きたことと実測値だけを書いた台帳を作り、そこに載っている数字しか使わせないようにしました。ただ、台帳を足しただけでは直りませんでした。前から書いてあった「毎回、具体的な出来事を必ず入れる」という指示と噛み合わず、台帳のネタが尽きると、やはり作り話をしたのです。「無ければ書かなくていい」と言い直して、ようやく止まりました。
この経験があるので、コードでも文章でも、AIに渡す前の状態は残すようにしています。出てきたものを受け入れるかどうかを、差分で判断できるようにするためです。
控えを取る癖が身についたあとで見えたこと
2026年6月から自動化を組み始めて、まだ2ヶ月ほどです。その間に、上に書いたような失敗を一通りやりました。控えを取る癖がついてから変わったのは、触るのが怖くなくなったことです。
戻せないと思っていると、設定を触るときに手が止まります。動いているものを壊したくないからです。でも自動化は、触らないと良くなりません。私の場合、投稿の時間帯を変えたり、生成の指示文を書き直したりを繰り返しています。戻せる状態を作っておくことは、慎重になるためではなく、大胆に触れるようにするためだと考えています。
とはいえ、仕組みが安定したことと、結果が出ることは別の話です。私は6月25日から7月27日までにThreadsへ87本を自動投稿しましたが、その間フォロワーは0人のままでした。7月27日時点で数えると、7月のビューは527、いいね7、返信0、リポスト0です。7月全体では82本投稿して合計ビュー582、いいね8、平均ビュー7.1でした。
自動投稿は「続ける力」はくれましたが、「届く力」は別物でした。壊れても戻せる仕組みを作ったところで、そもそも誰にも見られていないという問題は残ります。それでも、壊れたまま気づかない状態よりは、はるかにマシだと思っています。少なくとも、次に何を試すかを考える土台にはなります。
まとめ
- 自動化のバックアップは、消えたときより自分で変更して壊したときのために要る。
- 控えを取るタイミングは、定期ではなく上書きする直前に固定すると忘れにくい。
- 対象は絞る。作り直せるものは控えない。作り直せないもの、手間がかかるものだけ残す。
- APIキーやトークンは、発行された瞬間が唯一の控えを取れるタイミング。後から見られる前提で進めると詰む。
- 認証情報はファイルのままコピーする。中身を貼り直すとBOMなどの見えない違いが混ざる。
- 期限切れはバックアップでは救えない。Threadsのトークンは60日で切れるので、自動延長を別に用意した。
- 控えの価値は復元だけでなく、比較対象が手に入ることにもある。差分で見ると思い込みが崩れる。
- 通知が来ないことと正常であることは違う。週次・月次の本数レポートを足して、無言の停止を検知するようにした。
- 同じ内容を2箇所に置くなら、どちらが本物かを決める。決めないと静かな不整合が起きる。
- AIに書き換えさせるときこそ、渡す前の状態を残す。出力は自然に読めるぶん、変化に気づきにくい。
- 戻せる状態を作る目的は、慎重になるためではなく、大胆に触れるようにするため。
コメント