自動化を組んで一番こわかったのは、エラーが出る失敗ではありませんでした。エラーが出ないまま、静かに何も起きていない状態です。画面には「準備完了」と出ている。ログにも赤い文字はない。それなのに、実際には一度も動いていない。私はこれを何度もやりました。
結論から書きます。自動化は「動いたかどうか」ではなく「出たかどうか」を見張らないと、止まったことに気づけません。スクリプトが正常終了したことと、投稿が世に出たことは、まったく別の事実です。私はこの二つを同じものだと思っていた期間があって、その間ずっと何も出ていませんでした。
この記事は、2026年6月から自動投稿の仕組みを組んできて、実際に無言で止まった事例と、そのあとに入れた見張りの設計をまとめたものです。私はエンジニアではありません。飲食の現場に10年いて、そこからSNS運用代行のフリーランスになった人間です。だから対策も、専門的なものではなく「自分が寝ていても異変が目に入る」ことだけを狙っています。
「準備完了」と表示されていたのに、一度も動いていなかった
2026年8月4日、Xの自動投稿を組みました。Windowsのタスクスケジューラーに1日5本ぶんのタスクを登録して、一覧を開くと全部「準備完了」と表示されている。ここで私は完成したと思いました。
実際には、一度も動いていませんでした。原因は、タスクを登録するための自分のスクリプトの中で、変数名にPowerShellの予約語を使っていたことです。その結果、タスクに渡すはずだった引数が丸ごと空になっていました。
ここが厄介なところで、タスク自体は「登録に成功した状態」なんです。空の引数を持ったタスクとして、正しく存在している。だから一覧の表示は正常だし、登録時にもエラーは出ない。実行しようとしても中身が無いので、ログに残るような失敗すら発生しない。
気づくのに時間がかかりました。「動いていないな」と思ってから、原因が引数の消失だと分かるまで、あちこち触っています。エラーメッセージが一行でもあれば、そこから逆算できたはずでした。何も無い状態から探すのが、いちばん時間を食います。
それ以来、タスクを登録したあとは「準備完了」の表示だけで安心しないことにしました。登録直後に、そのタスクへ実際に渡っている引数を開いて、空になっていないか毎回確かめます。目視です。かっこ悪いですが、これをやってから同じ失敗はしていません。
表示が正常であることは、動作の証明にならない
この一件で私の中の前提が変わりました。それまでは、管理画面が正常を示していれば正常だと思っていた。今は、管理画面は「設定が保存されたこと」しか教えてくれない、と考えています。設定が保存されていることと、その設定が意味のある値であることは別です。
だから今は、新しく何かを登録したときの確認手順を二段に分けています。一段目は登録が通ったかどうか。二段目は、登録された中身が空でないかどうか。二段目を飛ばした日に、だいたい何か起きています。
実際に無言で止まった事例を並べてみる
2026年6月に自動化を組み始めて、まだ2ヶ月ほどです。その短い期間でも、無言で止まった事例はいくつも出ました。順番に書きます。共通しているのは、どれも「壊れた」という自覚が持てない止まり方をしている点です。
PCがスリープしていて、生成が走っていなかった
2026年7月3日から5日まで、Threadsの投稿が1本も出ていませんでした。原因は早朝にPCがスリープしていて、6時の生成スクリプトが走れなかったことです。
私の仕組みは、毎朝6時台にAIが投稿文をまとめて生成して、Googleドライブにテキストで保存します。投稿スクリプトはそれを読んで投げるだけ。つまり生成が走らないと、投稿する材料そのものが存在しません。投稿スクリプト側から見ると、読むファイルが更新されていないだけなので、これも派手な失敗にはなりません。
3日間です。自分の投稿を毎日見に行く習慣があれば初日に気づけたはずですが、自動化した安心感で見に行かなくなっていました。自動化した対象ほど見なくなる、というのが正直な実感です。
PCが落ちていて、投稿だけが失敗した
7月14日には、投稿が3件失敗しました。原因はPCが落ちていたことです。これは前の事例と違って、失敗として記録が残りました。ログにも残り、Discordにも通知が飛んでいます。
同じ「PCが動いていない」でも、記録が残るケースと残らないケースがあります。スクリプトが起動して失敗すれば残る。スクリプトが起動そのものをしなければ残らない。この差は大きくて、後者を捕まえる仕組みは別に用意しないといけない、と思うようになりました。
書き込む場所と読む場所がずれていた
note告知が一度も投稿されていない時期がありました。原因は、告知文をスプレッドシートにだけ書き込んで、投稿スクリプトが読むドライブ側のファイルを更新していなかったことです。
これも無言です。書き込み処理は成功している。読み込み処理も成功している。ただ、その二つが別の場所を見ていた。片方だけを確認していると、どちらも正常に見えてしまいます。
note告知はRSSで新着を拾って、月水金に自動で出す仕組みにしています。Xでは本文にURLを置かず、投稿にぶら下げる返信に貼る形です。工程が増えるほど、こういう「つながっていない」失敗の余地は増えます。
ファイルの中身が見た目どおりではなかった
認証トークンのファイルにBOMが混ざっていて、投稿が丸ごと止まったことがあります。見た目は何も変わりません。開いても、そこには正しいトークンが書いてあるように見える。原因特定に時間がかかりました。
似た話で、トークンのファイルを全行つなげて読んでしまい、認証エラーになったこともあります。実際に必要だったのは1行目だけでした。これは認証エラーという形で表に出たぶん、まだ親切な失敗です。
使える書き方と使えない書き方の差で、機能が消えた
日付を整える処理で、パソコンによって使える書き方と使えない書き方があるのを知らずに書いたことがあります。結果、その機能がまるごと無言でスキップされていました。落ちるわけでも、警告が出るわけでもない。ただ何もしないで通り過ぎる。
エラーが表に出ない失敗がいちばんこわい、というのはこの一件で決定的になりました。落ちてくれる失敗は、直せばいい。落ちない失敗は、そもそも存在に気づけません。
期限切れは、失敗ではなく静かな停止として来る
ここまでは組み方のミスですが、時間の経過だけで止まるものもあります。Threadsの認証トークンは60日で切れます。切れたら投稿は全部止まります。
私はこれに、あと10日というところで気づきました。何かの拍子に有効期限を確認して、真っ青になったという感じです。もし気づかなければ、ある日を境に全部止まって、しかも当日の朝は普通に「投稿処理を実行しました」に近い顔をして終わっていたと思います。
気づいたその日に延長して、ついでに毎月1日に自動で延長する仕組みを入れました。60日で切れるものを月に1回延ばしておけば、多少サボっても切れる前に次が来ます。余裕の幅を持たせる、という考え方です。
この手の「期限で止まるもの」は、組んだ日には存在しない問題です。動いているときに未来の停止を想像するのは難しい。だから私は、新しく認証まわりを触ったときは有効期限をその場で調べて、延長処理まで作ってから完成にする、という順番に変えました。
キーの取り直しにも順番がある
関連して、XのAPIキーを取りに行ったときの話です。画面には下6桁しか表示されず、完全な値を見る方法がありませんでした。結局いったん作り直すしかない。
さらに、キーを作り直す順番を間違えると、後から作ったほうが無効になります。親のキーを先に作り直してから、その下のキーを作り直す必要がありました。これも、無効になったこと自体は誰も教えてくれません。認証が通らなくなって初めて分かります。
認証まわりは、無言で止まる要素の密度がとくに高い場所だと思っています。値が見えない、期限がある、順番がある。この三つが揃っているので、ここだけは面倒でも手順を残しておく価値がありました。
いま入れている見張りの設計
ここからは対策です。私が今やっているのは、大きく分けて三つです。失敗したときに手元に届く仕組み、定期的に数を数える仕組み、そして人間側の確認手順です。
失敗を、通知とログの両方に残す
投稿が失敗したらログに残り、Discordに通知が飛び、次にPCを開いたときにも報告が上がるようにしています。通知先をDiscordにした理由は別の記事で書いたので省きますが、要は自分が確実に見る場所に出すことです。
ただしこれは「起動して失敗した」ケースしか捕まえられません。先ほどの、起動そのものがしなかったケースは通知に出てきません。だから通知が来ないことを「順調」と読むのは危険です。通知が来ないのは、順調か、死んでいるか、そのどちらかです。
週次・月次で、投稿数そのものを数える
ここを埋めるのが集計です。週次・月次で自分の投稿を自動集計して、Discordにレポートが飛ぶようにしています。ここで見ているのは反応の数字だけではありません。本数です。
たとえば2026年8月4日までの7日間で、Threadsに24本投稿しています。1日5本のはずですから、7日なら35本のペースではない。この差を眺めると、どこかで出ていない枠があると分かります。数字が「良いか悪いか」ではなく「あるべき本数と合っているか」を見る使い方です。
月単位でも同じです。2026年7月のThreadsは82本投稿して、合計ビュー582・いいね8・平均ビュー7.1でした。6月25日から7月27日までで見ると87本を自動投稿しています。こうやって本数が並ぶと、丸ごと出ていない期間があればへこみとして見えます。7月3日から5日の停止も、後から数字を並べたときに輪郭がはっきりしました。
反応の数字のほうも一応書いておくと、7月27日時点で数えたときの7月のビューは527・いいね7・返信0・リポスト0でした。返信は一度も来ていません。フォロワーは、87本投稿した期間を通して0人のままでした。noteのほうは2026年7月27日時点で記事27本・フォロワー2人・合計いいね45です。この記事の主題ではないので深追いしませんが、見張りの数字と成果の数字は別物として持っておくと混乱しません。
「0か1のまま」を数えて、出ているかどうかの判定に使う
もう一つ使っているのが、ビューが0か1のままだった投稿の本数です。7月27日時点では68本のうち13本がビュー0か1でした。2026年7月全体では18本、8月4日までの週では8本ありました。
これは本来アルゴリズムの話ですが、私は「投稿が本当に出たのか」の傍証としても見ています。ある枠だけ0が固まっていたら、その時間帯の投稿が実は出ていない可能性を疑う。スロット別の平均ビューも同じ用途で、7月27日時点では朝15.7・昼5.7・夜1.8、8月4日までの週は朝6.0・昼6.6・夜2.4でした。夜が低いのは傾向として理解していますが、極端にゼロへ寄ったときは仕組み側を先に疑います。
人間側の確認は、手順にして固定する
最後は自分の手です。自動化を組んでいるのに手を動かすのは矛盾しているようですが、無言の失敗は仕組みでは拾いきれない部分が残ります。私が固定している確認は次のとおりです。
- タスクを登録した直後に、渡している引数が空になっていないか開いて見る
- 認証まわりを触ったら、有効期限をその場で調べて、延長処理まで作ってから完成にする
- 書き込む場所と読む場所が同じかどうかを、両側から確認する
- 週次レポートで、反応より先に本数を見る
- 新しく作った機能は、翌日に一度だけ実物が出ているか目で見る
どれも高度なことはしていません。過去に自分がやらかしたことを、そのままチェック項目にしただけです。やらかしの数だけ項目が増えるので、今後も増えると思います。
AIに書かせている部分の「無言の失敗」
もう一つ、動作ではなく内容が無言で壊れるパターンがあります。投稿文をAIに書かせていたとき、実際とは違う数字を書いてきたことがありました。本当は68本なのに62本と書いていたんです。
これがこわいのは、文章としては自然だから、読んでも気づけないところです。スクリプトは正常に動いている。投稿も出ている。ログもきれいです。壊れているのは中身だけ。
対策として、実際に起きたことと実測値だけを書いた台帳を作り、そこに載っている数字しか使わせないようにしました。ところが台帳を足しただけでは直りませんでした。前から書いてあった「毎回、具体的な出来事を必ず入れる」という指示と噛み合わず、台帳のネタが尽きるとやっぱり作り話をしたんです。「無ければ書かなくていい」と言い直して、やっと止まりました。
この一件は運用の話として別記事にしてあるので詳細は譲りますが、監視という観点でだけ言うと、監視対象は「動いたか」だけでなく「出たものが正しいか」まで含むということです。私は今のところ、これを人間の目でしか確認できていません。ここは弱点として残っています。
止まっても被害が小さくなるように組む
見張りを増やしても、気づくのは事後です。だから並行して、止まったときの被害を小さくする方向も考えるようになりました。
一つは、工程を分けておくことです。私の仕組みは、朝6時台にAIが投稿文をまとめて生成してGoogleドライブに保存し、投稿スクリプトはそれを読んで投げるだけ、という形にしています。分かれていると、止まった箇所が特定しやすい。ファイルが更新されていなければ生成側、更新されているのに出ていなければ投稿側です。
一体で組んでいたら、7月3日から5日の停止も「何かが止まった」までしか分からなかったと思います。切れ目があると、切れ目が診断の材料になります。
もう一つは、費用の面での安心です。自動化にかかっている費用は、XのAPI利用料が1日5本の投稿で月350円ほど。ThreadsのAPIは無料で、タスクスケジューラーはWindows標準機能なので0円です。金額が小さいので、止まっていた期間に無駄な支出が積み上がる心配はほとんどありません。これは精神的にわりと大きくて、金額が大きい仕組みだったら、無言の停止に気づいたときのダメージも別物だったはずです。
ついでに、常時動いているPCが前提の仕組みは、PCの状態そのものが単一障害点になります。私の場合、7月3日から5日はスリープ、7月14日はPCが落ちていたことが原因でした。2ヶ月のうち2回、PCの状態が原因で止まっています。これは仕組みの問題ではなく置き場所の問題なので、いずれ考えないといけない部分だと思っています。
2ヶ月やって、監視について考えが変わったこと
自動化を組み始めたのは2026年6月です。まだ2ヶ月ほどしかやっていませんが、監視の考え方は最初とだいぶ変わりました。
最初は「エラーを見張ればいい」と思っていました。失敗したら通知が来る、来なければ大丈夫、という設計です。今は逆で、エラーは見張れる範囲の一部でしかないと思っています。エラーを出す資格があるのは、少なくとも起動したスクリプトだけです。起動しなかったもの、値が空だったもの、別の場所を見ていたもの、期限が切れたもの、内容が違っていたもの。これらは全部、エラーを出しません。
だから今は「異常を検知する」より「正常の証拠を定期的に取りに行く」に近い発想でやっています。投稿が出ているという証拠を、週次の本数として自分に送る。それが期待値と合っているかを見る。合っていなければ、そこから原因を探しに行く。
もちろん、これで全部拾えているとは思っていません。今も、自動化を作っているのに結局そのつど自分の手を動かしてしまっている部分があります。完全に手放せている実感はありません。ただ、無言で3日間止まっていたことに後から気づく、という状態からは抜けられました。
それから、これは監視とは少しずれますが、書いておきます。私は反応が無い期間をすぐ失敗と思わないようにしています。引き継いだクライアントの案件をコンセプトから作り直して、伸びるまで手応えは一切ありませんでした。効いているのかどうか分からないまま続けて、最近になって急に伸びた。自分でも驚きましたし、クライアントも驚いていました。
ただし、これは「仕組みがちゃんと動いている」ことが前提の話です。動いていないものを我慢して続けても、何も積み上がりません。週ごとの平均ビューが18.2 → 15.9 → 8.4 → 7.9 → 5.0と右肩下がりでも、それは少なくとも「出ている」という前提の上で判断できる数字です。出ていないのか、出ているけど届いていないのか。この二つを取り違えないために監視がある、というのが今の理解です。
まとめ
- エラーが出る失敗より、エラーが出ない失敗のほうがこわい。落ちてくれるものは直せるが、落ちないものは存在に気づけない。
- タスクが「準備完了」と表示されていても、渡している引数が空なら一度も動かない。登録の成功と、中身が正しいことは別の確認。
- 起動して失敗すれば通知が飛ぶが、起動そのものをしなければ何も残らない。通知が来ないことを順調と読まない。
- 2026年7月3日から5日はスリープで生成が走らず、投稿が3日間ゼロだった。自動化した対象ほど見に行かなくなる。
- 書き込む場所と読む場所がずれていた、ファイルにBOMが混ざっていた、環境差で機能が丸ごとスキップされていた。どれも無言だった。
- 認証トークンは60日で切れる。あと10日で気づいたので、毎月1日に自動延長する仕組みを入れた。期限で止まるものは、組んだ日には存在しない問題。
- 週次・月次の集計では、反応の数字より先に本数を見る。あるべき本数と合っているかが、出ているかどうかの判定になる。
- ビュー0か1の本数やスロット別平均は、届き方の指標であると同時に「本当に出たのか」の傍証にもなる。
- AIに書かせた文章の数字が違っていたことがある。動作は正常でも内容が壊れる無言の失敗もある。
- 工程を生成と投稿に分けておくと、止まった箇所が切り分けやすい。切れ目が診断の材料になる。
- 2ヶ月で2回、PCの状態が原因で止まっている。常時動くPC前提の仕組みは、PCそのものが単一障害点。
- 今の考え方は「異常を検知する」ではなく「正常の証拠を定期的に取りに行く」。
コメント