📉 3日間・新規投稿ゼロ——消していたのは送信ツールじゃなく、後片付けスクリプトだった

郵便受けの扉を毎朝開けているのに、3日間、中身が空のまま——。そういう感覚でした。

あなたは今、こうなっていませんか？

• 自動投稿のツールは「動いている」のに、SNSプロフィールに新着が来ていない
• エラーも警告もないのに、数字が3日間ぴたりと止まっている
• ログには「成功」と出るのに、実際の投稿がひとつも増えていない
• ツールが悪いのかコンテンツが悪いのか、どこを疑えばいいかわからなくなっている

先に結論を言います。

投稿を送り出す処理は完全に正常で、犯人は投稿直後に走る「後片付けスクリプト」でした。

この記事では、ログは「成功」なのに投稿が3日間届かなかった原因をどう突き止めたかと、その後に変えた確認の習慣を書きます。

3日間、新規投稿がゼロだった

最初に違和感を覚えたのは、特別な理由もなくTikTokのプロフィールを開いたときのことです。

再生数が747のまま止まっていた

先頭に表示されている動画の再生数が、747のまま変わっていませんでした。

「更新していないだけかな」と思ってリロードしました。

数字は同じままで、新しい動画が入っていないことに気づきました。

「あれ、ちょっと待って」と思いながらカウントしてみたら、新規投稿が0本でした。

72時間で1本も追加されていなかった、ということになります。

届いている前提で中身ばかり悩んでいた

正直に言うと、最初の2日間は「なんかフォロワーの伸びが遅いな」と思っていました。

投稿は届いているものとして、コンテンツの質を上げることを考えていたんです。

「もっと面白い動画にすれば反応が増えるかな」とか、「投稿時間を変えてみようか」とか。

でも実際には、投稿が1本も届いていなかった。

根本が壊れているのに、表面をいじり続けていた形です。これが今回の教訓のひとつになりました、笑。

投稿が「届いている前提」で悩んでいたので、その前提を疑うことができなかったんです。

「なぜ反応が少ないんだろう」という問いは、「届いている」という前提の上に立っています。

前提が崩れているとき、その前提の上で考えを深めても、答えは出てきません。

📕 AIエージェントと自動化の全工程をまとめた総集編


手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

ログには「成功」が並んでいた

「でも、エラーは出ていなかったはずでは？」と思って、すぐにログを確認しに行きました。

ログというのは、システムが何をしたかを記録しておくメモのようなものです。

そのログには「投稿成功」の文字がきれいに並んでいました。

3日分、毎日きっちり「投稿しました」という記録が残っていたんです。

成功記録があるのに投稿がない

「成功しているのに、なぜプロフィールに出ていないの？」

ここで、頭の中がかなり混乱しました。

成功記録がある。でも、投稿がない。

この矛盾をどう解釈すればいいか、最初はまったくわかりませんでした。

読み飛ばした「ダイアログ操作：完了」

ログをもう少し細かく読み込むと、「投稿処理：完了」という記録の直後に、もうひとつ記録がありました。

「ダイアログ操作：完了」という行です。

最初に見たとき、この行を読み飛ばしてしまいました。

「後片付けの記録か、どうせ問題ないだろう」と流してしまったんです。

でも、これが答えでした。

その行には「何をしたか」が書いておらず、「終わった」という事実だけが書かれていたんです。

ログは「処理が終わったか」を教えてくれます。

でも「処理が正しかったか」は、また別の話です。

これは後から気づいたことですが、ログを読むときに「何をしたか」を見落とすと、こういうことになります。

処理の流れを最初から追い直した

少し時間をおいて、一から「処理の流れ」を追い直すことにしました。

「投稿する」という動作が、どういう順番でどの処理を経ているかを、最初から確認したんです。

投稿の後に出る確認ダイアログ

TikTokに動画を投稿するとき、実は処理がひとつだけで終わらないことがあります。

動画データを送った後に、アプリ内でダイアログという確認の画面が出るんです。

「この動画を公開しますか」みたいな画面をイメージしてもらえると、わかりやすいです。

そこに「OK」と「Cancel」の2つのボタンがある。

手動で投稿するなら、当然「OK」を押します。

でも自動化しているときは、そのボタンを押す役割も、別の処理が担います。

それが「後片付けスクリプト」と呼んでいたものでした。

「投稿を送った後、確認画面を閉じる係」として動く、脇役の処理です。

脇役と呼ぶのは、処理の表に出てこない存在だからです。

動画を送る処理は「主役」で、誰もが気にします。

でも確認画面を閉じる処理は、ほとんど意識されません。

「当然うまくいっているはず」と思われがちな、地味な担当です。

後片付け役がCancelを押し続けていた

そのスクリプトが何をしていたか確認したとき、思わず声が出ました。

「Cancel」ボタンをずっと押し続けていたんです！

「OK」ではなく、取り消し側のボタンを。

つまり、投稿するたびに、その直後に自分でキャンセルしていたわけです。

「主役が投稿した瞬間、脇役が消していた」——そういう状態です。

3日間、毎日これが繰り返されていた。

ボタンの配置が知らぬ間に逆転していた

なぜこうなったかというと、ダイアログのボタン配置がいつの間にか変わっていたからです。

以前は「Cancel」が右側にあって、スクリプトも右側のボタンを「OK」だと思って押していました。

いつのまにかUI、つまり画面の見た目が変わって、ボタンの位置が左右逆転していた。

脇役のスクリプトは、その変化に気づかないまま、ずっと間違ったほうを押し続けていたんです。

アプリのUIは告知なしに変わる

アプリのUIは、運営側が頻繁に変えることがあります。

「ボタンをここに置いたほうがユーザーが使いやすい」という判断で、画面の見た目が更新されるんです。

こうしたUIの更新は、ユーザーへの事前告知なしに行われることがほとんどです。

バージョンアップのお知らせが来ることもありますが、ボタンの位置まで細かく書いてある通知はほとんど来ません。

人間が手動で使うなら、画面を見てボタンを押すので問題ありません。

でも自動化は「この位置にあるボタンを押す」と決めているので、位置が変わると誤作動します。

これは自動化ツールの根本的な弱点のひとつです。

位置を頼りにする自動化の弱点

もう少し具体的に言うと、こういうことです。

自動化ツールが画面を操作するとき、「ここにあるはずのボタン」という情報を使います。

座標や、ボタンの見た目の特徴を頼りに、「これが押すべきボタンだ」と判断するんです。

その特徴が変わると、判断が狂います。

「見た目が変わる可能性がある場所を頼りにしている処理は、定期的に確認する」——このルールが、ここから生まれました。

「ちょっとした画面の変化が、静かに全体を止める」——これは自動化のあるあるだと後から知りました。

自分で体験するまで、こんなに気づきにくいものだとは思っていませんでした。

壊れているのに動いて見える怖さ

特に怖いのは、壊れているのに「動いている」ように見えることです。

ツールは正常に起動します。処理は正常に走ります。ログは「成功」を記録します。

でも、結果は出ていない。

この「見かけ上の正常」に気づくには、最終的な成果物を直接確認するしかありません。

「プロセスが動いた」ではなく、「成果物が存在するか」を見る目が要るんです。

なぜ3日も気づかなかったのか

冷静になってから「なぜ3日も気づかなかったのか」を振り返りました。

答えはシンプルで、「ツールが動いている」という事実だけを見ていたからです。

「エラーが出ていない＝正しく動いている」——そう信じていました。これが、今回いちばんの盲点でした。

ツールが動くことと届くことは別

ツールが動くことと、投稿が届くことは、別の話です。

郵便屋さんが出発したことと、荷物が届いたことは同じじゃない。

わたしは「郵便屋さんが出発した」記録を見て、「届いた」と判断していました。

でも実際は、出発後に毎回間違った住所に向かっていた状態に近かった。

正常に動くまま間違ったことをする

自動化のシステムは、複数の処理がつながっています。

「投稿する」→「後片付けする」→「確認する」と、チェーンのようにつながっている。

そのどこかが静かに壊れたとき、エラーが出ないことがあります。

なぜなら、個々の処理は「正常に終了している」からです。

後片付けスクリプトの立場では、「ボタンを押す」という処理は正常に動いていました。

「押してはいけないボタンを押している」という判断を、システムは自分ではしてくれないんです。

この件から学んだことのひとつは、「正常に動くシステムが間違ったことをしている」という状態が存在する、ということです。

エンジニアでなくてもAIツールや自動化を使うすべての人に、関係する話だと思います。

しかも、こういう故障は「派手なエラー」として現れません。

「処理できませんでした」「接続に失敗しました」のような赤いメッセージは出ないんです。

システムは静かに、正確に、間違ったことをし続けます。

これが、今回もっとも印象に残ったことです。

数字が動かない原因は2種類ある

SNS運用で「数字が動かない」という状態には、大きく2種類あります。

「届いているけど刺さらない」と、「そもそも届いていない」です。

前者なら、コンテンツの内容を変えることで改善できます。

後者なら、コンテンツをどれだけ磨いても意味がありません。

3日間のわたしは、後者なのに前者だと思っていました。

「動画の中身をもっと工夫しないといけないのかな」と、的外れな方向を考えていたんです。

コンテンツの改善を考える前に、まず「届いているか」を確かめる必要がありました。

これが、今回いちばんの反省点です。

コンテンツを先に疑ってしまう落とし穴

自動化ツールを使う場合、もうひとつ落とし穴があります。

問題が起きたとき、「コンテンツが悪い」と思いやすいんです。

ツールへの不信感より、コンテンツへの不信感のほうが、心理的に浮かびやすいからです。

「自分の作るものが面白くないからだ」という方向に、思考が向きやすい。

でも実際は、ツールの問題やシステムの問題が原因のことも、よくあります。

コンテンツを疑う前に、まず「ちゃんと届いているか」を確認する順番が大切です。

実際の投稿画面でしか見えないこと

似たようなことは、自動化を使ったコンテンツ運用で、案外よく起きます。

たとえば、画像が正しく添付されているか。

テキストに変な文字が混じっていないか。

投稿の本数が想定通りに積み上がっているか。

これらはすべて、ツールのログではなく、実際の投稿画面を開いて確認するしか見えないことです。

ログの「成功」が意味する範囲

「ログが成功なら問題ない」という考え方は、一度疑ってみる価値があります。

ログが記録するのは「処理が終わったか」であって、「処理が意図通りだったか」ではないからです。

ここに、自動化を始めた頃に多くの人がはまる誤解があります。

「ログに成功と書いてある」という情報は、「プログラムがクラッシュしなかった」という意味に近いんです。

それ以上でも、それ以下でもない。

意図通りの結果が出たかは、ログではなく、実際の成果物を確認するしかわかりません。

確認の順序とログの粒度を変えた

この件から、確認の順序を変えました。

今は「プロフィールの実際の投稿数」から確認するようにしています。

以前は「ツールのログ」から入っていました。「エラーが出ていないか」を最初に確認していたんです。

でも今は、一番最初に「実際に届いているか」を直接確認します。

TikTokならプロフィールのグリッド、Instagramなら投稿一覧を先に開く。

「ツールが動いていること」と「投稿が届いていること」を、別で確認するようにしました。

当たり前のように聞こえますが、自動化して間もない頃は見落としやすい部分です。

なぜ見落とすかというと、「自動化した」という安心感があるからです。

「もう見なくていい」「任せているから大丈夫」という気持ちが、確認の動機を薄くするんですね。

でも任せているからこそ、外から結果を見る目が要る、というのが今の考え方です。

週1回、2分で投稿本数を数える

具体的にやっていることは単純です。

週に1回、実際のSNSアカウントを開いて投稿本数を数えます。

ツールの管理画面ではなく、外から見える状態を直接確認します。

「先週は何本増えたか」を数えるだけでいいんです。

たとえばTikTokなら、プロフィール画面を開いてグリッド状に並んだ動画を確認します。

一番新しい動画の日時を確認して、今日の日付と比べる。

Instagramなら、プロフィールから投稿一覧を開いて、最新の日付を確認します。

ツールの管理画面と、実際の投稿一覧の本数が一致しているかを照合するだけです。

この照合を、週に1回やります。

ツールのログと実際の本数がズレていたら、どこかで問題が起きている証拠です。

「ログが成功でも、投稿数が増えていなければ何かがおかしい」——これが今の判断基準です。

これだけで、今回のような3日間ゼロには早く気づけます。

確認にかかる時間は、2分以内です。

「そんな単純なことでいいの？」と思うかもしれません。

でも、わたしが3日間気づかなかった理由は、この2分を省いていたからです。

ツールを信頼することと、結果を確認することは、別の行為です。

信頼したうえで、確認する——この両立が必要なんだと、今回で理解しました。

「何をしたか」までログに残す

もうひとつ、実際の運用で変えたことがあります。

スクリプトが「何をしたか」を詳しく記録させるようにしたことです。

以前のログは「処理：完了」という記録しかありませんでした。

今は「どのボタンを押したか」「どの処理を選択したか」まで記録するようにしています。

たとえば「ダイアログ操作：Cancelボタンをクリック」と書かれていたら、すぐに気づけます。

ログの粒度を上げることで、「何が起きたか」が読めるようになりました。

「操作した結果」だけでなく、「操作した内容」も残す——この違いが、調査の時間を大きく変えます。

今回の件で、最初に「ダイアログ操作」のログを読んだとき、「Cancelを押しました」と書いてあれば、調査は数分で終わっていました。

でも「完了」とだけ書いてあったので、処理の流れを全部追い直すことになったんです。

ログは後から調べるためのものですが、「調べやすいログ」と「調べにくいログ」があります。

記録する粒度が、調査コストを決める——これを、この体験で初めて実感しました。

自動化するほど外から見る目が要る

解雇からおよそ半年、広告費0円でコンテンツを動かし続けてきました。

自動化への依存度が上がるほど、こういう静かな故障は起きやすいと感じています。

なぜかというと、手動でやっていた頃は「投稿したらプロフィールを確認する」という動作が自然にあったからです。

自動化すると、「見なくていい」という安心感が生まれてしまう。

この安心感が、盲点を作ります。「ツールに任せている＝確認しなくていい」ではないんです。

むしろ、任せている分だけ、「本当に届いたか」の確認が必要になります。

任せているからこそ、外から見る目が大事になる。

これはSNS以外でも同じだと思います。

メールの自動返信でも、ECの在庫管理でも、ブログの予約投稿でも、同じことが起きます。

自動化は故障の起き方を変えるだけ

「自動化した」という事実は、「問題が起きない」という保証ではありません。

問題の起き方が、「派手なエラー」から「静かな誤動作」に変わるだけです。

派手なエラーは気づきやすい。

赤いメッセージが出るし、処理が止まるし、通知が来る。

でも静かな誤動作は、気づかないまま時間が過ぎていきます。

まずは週1回の実物確認から

自動化の成熟度が上がると、静かな誤動作に気づく仕組みも一緒に育てる必要があります。

そのための最初のステップが、「週に1回、実物を直接確認する」という習慣です。

複雑なモニタリングシステムや、アラート通知の仕組みを作る前に、まずここから始めるのが現実的です。

自動化とは「確認を省く」ことではなく、「確認の仕方を変える」ことです。

手動でやっていた頃と同じ場所を、定期的に外から見る目が必要です。

仕組みそのものの作り方については、別のnoteにまとめています。

フォローしていただくとタイムラインから読めますので、興味があれば覗いてみてください。

疑われにくい脇役の処理が止めていた

今回わたしが手を焼いたのは、「送信処理」ではなく「後片付け処理」でした。

誰も最初に疑わない、地味な脇役の部分です。

配信ツールが正常に動いているのに投稿が届かない——これはSNS運用で最も気づきにくい穴のひとつだと思います。

「ツールは動いている」という安心感が、直接確認する動機を奪うからです。

プロフィールを見る習慣は、たった2分でできます。

でも、その2分を省いていたから、3日間気づかなかった。

届いた証拠を確かめる目を残す

郵便受けを毎日開けることと、「届いているか」を確認することは、別の動作です。

受け取る仕組みを自動化しても、「届いた証拠を確認する目」は残しておく必要があります。

「ツールが動いている」と「投稿が届いている」は、別の話です。

この2つを分けて確認する習慣が、今回の件でようやく身につきました。

3日間・新規投稿ゼロ——この状態は、どんなに精巧なシステムでも、静かに起きます。

定期的に外から見る目だけが、それを防いでくれます。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順