🔥 5回連続で投稿0本——生成コストだけが先に出ていくSNS自動化の「空焼き」を止めた話

印刷ジョブを送るたびに、パソコンの画面には「完了」と表示されていました。

でも、プリンターの用紙トレイは空で、1ページも出てきていませんでした。

完了の記録だけが毎日積み上がり、費用だけが着実に溜まっていきます。

「機械が反応していること」と「結果が届いていること」は、まったく別の話だとわかります。

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

先に結論を言います。

自動投稿は「失敗しても次も動く」設計のため、生成コストだけが先に積み上がります。

この記事では、Instagramの自動化が5日間連続で失敗し続けた実体験と、失敗を検知して自動で止める回路をどう設計したかを書きます。

「届いているか確かめずに使い続けることのコスト構造」と、回路の設計の考え方について話します。

5日間、投稿0本だったと気づいた日のこと

「動いている気がする」は、確かめていない

自動化を組んだ直後は、毎日ログを確認していました。

処理が終わるたびに開いて、「今日も動いた」を確かめていました。

でも2週間、3週間と経つにつれて、確認の間隔が少しずつ開いていきます。「昨日も動いた。

今日もきっと動いている」という感覚が積み重なって、確認しなくなります。

その積み重ねの先に、今回の事態がありました。

Instagramのアカウントを久しぶりに開いたとき、投稿の本数が明らかに少ないことに気づきます。

「あれ、おかしい……」と思って、処理のログを開きました。

そこには、5日分の「失敗」記録が並んでいました。

投稿本数はゼロ。でも、AIへのリクエスト記録はしっかりと残っていました。

5日間、毎日文章が生成されていたことになります。

でも、1本もInstagramには届いていませんでした。最初はログの見方を間違えたのかと思いました。

何度確認しても、同じ結果でした（笑）。

ログを読んで初めてわかったこと

ログには、処理ごとに status という項目があります。

値は success か failed の2種類で、失敗した行には error の欄に内容が入ります。

5日分のログを並べると、failed が連続で並んでいました。

それぞれの error 欄には「ブラウザの起動に失敗しました」という内容が記録されていました。

ブラウザが立ち上がらなければ、Instagramにアクセスできません。

アクセスできなければ、当然投稿は届きません。

でも、AI文章の生成ステップはブラウザの起動状態を確認しないため、毎日動き続けていました。

ログをステップごとに分けて記録していれば、差異はもっと早く見えていたはずです。

5日間でやっと気づいた原因は、最初のログ1行目から読み取れる内容でした。

「ログが残っている」と「ログを読んでいる」は、別物だと思い知りました。

「生成できた」と「投稿できた」の間にある壁

自動化の流れをかんたんに整理します。

「AIが文章を作る」→「Instagramに投稿する」という2段階で動きます。

この2段階は、見た目はつながって見えますが、処理としては独立しています。

前の段階が成功しても、後の段階が動ける状態にないと、投稿には至りません。

今回、投稿に必要なブラウザが5日間起動していませんでした。

でも文章を生成する部分は、ブラウザの起動状態を確認せずに動き続けます。

結果として「生成は毎日成功・投稿は5日連続で0本」という状態が積み上がりました。

問題の本質は、「ブラウザが起動しているかどうかを先に確認する」設計が最初から抜けていたことです。

その1つの確認が入っていれば、5日分のコストは発生しなかった。

設計の穴は、気づかないと静かに損失を積み上げ続けます。

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

「空焼き」という状態を整理します

コンロの火だけつけっぱなしのイメージ

「空焼き」という言葉で、今回の状態を整理してみます。

料理で言えば、コンロに鍋を置かずに火だけつけている状態です。

ガスは燃え続けるのに、何も温まらない。燃料だけが消えていって、料理は完成しません。

SNS自動化の空焼きは、この状態にそっくりです。

AIへのリクエストという「燃料」は毎日使われ続けるのに、投稿という「料理」は1本も出てきません。

コンロなら炎や熱気でそれとわかります。

でも自動化のログは、誰かが能動的に見に行かない限り、誰にも気づかれません。

静かに、音もなく、コストだけが積み上がっていく——それが空焼きの一番厄介なところです。

気づいたときには、すでにかなりの分量が溜まっています。

「ガスの節約」より「火を止める」が先

空焼きが起きているとき、最初に思いつくのは「生成のコストを下げよう」という発想です。

使うモデルを小さくしたり、1日の処理回数を減らしたりという方向です。

でも、コストを下げても空焼きの構造は変わりません。

少し安くなるだけで、投稿0本のままコストが積み上がり続けます。

空焼きへの有効な対策は、コスト削減よりも先に「止まる回路」を作ることです。

根本の問題は「ガスの量」ではなく「火を自動で止める仕組みがない」ことだからです。

5日後に気づくのか、翌朝に気づくのかでは、積み上がるコストが5倍変わります。

止める速度を上げることが、もっとも確実なコスト管理です。

「早く気づくか」がコストの量を決める

今回の5日間を振り返ると、日によって状況が少し違いました。

ブラウザが起動していないことを即座に検知できた日は、文章の生成が0件で止まりました。

でも検知が遅れた日は、生成だけが実行されてコストが発生しました。

「何を確認するか」だけでなく「いつ確認するか」でも、無駄になるコストの量が変わります。

失敗すること自体は、完全に防ぐのが難しい部分もあります。

でも「失敗に気づくのを早くする」ことは、設計でコントロールできます。

空焼きを「ゼロにする」より「できるだけ短くする」を目標にした方が、ずっと現実的です。

失敗の回数より、失敗が続く「長さ」を短くするイメージです。

なぜ失敗しても誰も止めなかったのか

「次もやる」がデフォルトになっている

ほとんどの自動化ツールは、失敗しても翌日も同じように動き続けます。

これは仕様として「間違い」ではありません。

ネットワークの一時的な不調や、PCを再起動した直後のタイミングなど、翌日には自然に解消する失敗もあります。

「1回の失敗で永久停止する」設計では、かえって使いにくくなります。

でも「何回失敗しても止まらない」と「5回失敗したら一度止まる」では、結果が大きく変わります。

前者は問題が続く限りコストが積み上がり続け、後者はある時点で「確認してください」という信号を出します。

自動化に「次もやる」だけがデフォルトになっているとき、止める判断は人間に委ねられます。

でも人間は確認しに行かない限り気づかないので、止める機会がないまま時間が過ぎていきます。

「誰も止めなかった」のは、止めようとしなかったからではありません。

「止まる仕組み」がそもそも設計されていなかったからです。

ログは「記録する」だけでは機能しない

自動化のログが残っていても、それは「書き込まれているだけ」の状態です。

書き込まれたログを、誰かが能動的に読みに行かない限り、情報は止まったままです。

多くのツールには、ログの出力先を指定する設定項目があります。

log_level や log_path といった名前の設定で、どこに何を残すかを決められます。

でも「残す」と「届ける」は、まったく別の設定です。

残すだけでは、能動的に読みに行く人間がいなければ機能しません。

ログは「残す」設定と「届ける」設定を、別々に用意する必要があります。

今回の5日間は、ログは残っていたけれど届ける設定がなかったために、誰にも知らされませんでした。

「通知がない」という静寂の罠

もう一つ、落とし穴がありました。「通知が来ていないから大丈夫」という思い込みです。

失敗のたびにエラーのログは記録されていました。

でも、そのログを誰かに「届ける」仕組みがありませんでした。ログは「残す」だけでは意味がありません。

能動的に見に行かない限り、誰も知らないまま時間が過ぎます。

「エラーがない」のではなく「エラーが届いていなかっただけ」という状態でした。

通知のない静寂を「問題なし」と読んでしまったのが、5日分の空焼きにつながりました。

「何かあれば通知が来る」設計と「何もなければ静かなまま」設計では、見える世界がまったく違います。

静寂の意味を変えるのが、通知設計の本質です。

広告との、見過ごしていた非対称

広告は「成果ゼロで止める」が当たり前

Lilyはかつて、大規模な広告を扱う仕事に携わっていたことがあります。

その現場では、「成果が出なければ止める」は絶対の鉄則でした。

クリック率が一定を下回ったら、その日のうちに配信を停止します。

「様子を見よう」と1日待つことはほぼなく、数時間単位で止める判断が下りていました。

それは精神論や意識の高さの話ではなく、純粋なコスト管理の話です。

成果ゼロで広告を回し続けることを、その現場では誰も「一時的な不調かもしれない」とは言いませんでした。

止める判断の速さがコストを守る——その感覚が、広告の現場には染み込んでいました。

「出力がないなら、入力も止める」がデフォルトでした。

自動投稿には、そのブレーキがなかった

では、SNS自動投稿はどうでしょう。

5日連続で投稿0本が続いても、仕組みは誰も止めませんでした。

広告には「一定の閾値を下回ったら自動停止」という仕組みが標準で入っています。

自動投稿には、それが最初から入っていませんでした。

成果ゼロで広告は止まる。でも、失敗が続いても投稿の仕組みは止まらない。

この非対称を意識したのは、今回の空焼きがあってからのことです。

「注意して定期的に確認しましょう」という運用ルールで対応しようとすると、どこかで必ず抜けます。

人間の注意力に頼る設計には、必ず穴が開く瞬間があります。

仕組みとして「止まる条件」を作ること——それが唯一の解でした。

「確認する習慣」より「止まる設計」を先に作る

「毎朝確認する習慣をつけよう」という解決策を試したことがあります。最初の1週間は続きます。

でも2週間目には間隔が空き始め、1ヶ月後には「たまに見る」に変わっていました。

習慣は、それが途切れたとき、代わりに何もしてくれません。

設計は、習慣が途切れても動き続けます。

「確認を忘れた」を起点に損失が発生するよりも、「止まる条件」が発動する方がずっと安全です。

広告のKPI管理で学んだ感覚と、ここでやっとつながりました。

止まる設計を先に作ってから、確認の習慣を補助的に使う順番が正しい、と今は考えています。

成果ゼロで動かし続けるコストを最小化するには、人の意識ではなく仕組みの設計で対応するしかありません。

回路の設計：失敗5回で自動停止・6時間後に再試行

なぜ「5回」という閾値にしたか

失敗が続いたとき、何回目で止めるか——この数字を決めるのが、思った以上に難しかったです。

1回で止めると、接続の一時的なエラーや再起動のタイミングでも毎回停止してしまいます。

使えない自動化は、ない方がマシです。

かといって10回にすると、最悪10日分のコストを積み上げることになります。それも困る。

5回という数字は、「一時的な問題で説明できる範囲」と「構造が壊れている」の境目として設定しました。

5日連続で失敗するなら、もう環境や設定に根本的な問題があると判断できます。

実際に使ってみて、「これくらいが適切だった」と感じています。

もし自分で設計するなら、まず3〜5回の範囲から試してみることをおすすめします。

失敗カウンターの仕組みと、リセット条件

回路の中心になるのは「失敗カウンター」という状態管理です。

処理が1回失敗するたびに、カウンターを1増やします。

処理が1回成功したとき、カウンターを0にリセットします。

カウンターが5に達した時点で、その日の処理を停止します。

注意が必要なのは「リセット条件」です。

カウンターをリセットするのは「成功したとき」だけで、翌日になっても自動でリセットしません。

翌日も同じ問題が続いていれば、2日目の1回目の失敗でカウンターは6になります。

止まったままにしておく設計か、翌日にリセットするかは、自分の運用に合わせて決める必要があります。

どちらが良いかは、「失敗の原因がいつ自然解消するか」によって変わります。 詳細な実装と設定例は、有料記事にまとめています。

停止後は6時間後に1回だけ再試行する

止めた後の設計も、あわせて考える必要があります。「止まったまま永遠に動かない」では困るからです。

今の設計では、失敗が5回に達して停止した後、6時間後に1回だけ再試行します。

再試行で成功すれば、そのまま通常の運用に戻ります。再試行でも失敗なら、その日はそれ以上動きません。

翌日の定時スタートまで待って、改めて再開します。

「何度でも試みる」ではなく「1回だけ試してから待つ」にしたのは、コストをかけすぎないためです。

修復を試みながらコストだけが積み上がる、という二次的な空焼きを避けたかった。

この6時間という間隔は、「半日待てば一時的な問題が解消していることが多い」という感覚から設定しました。

自分の環境によって、2時間でも12時間でも変えていいと思っています。

再試行の記録も、通常の失敗と区別してログに残しておくことをおすすめします。

「再試行して成功した回数」は、環境の安定度を測る指標になります。

この数字が増えてきたら、「6時間の間隔を短くしてもいい環境」だというサインです。

通知の設計：1日1回に絞った理由

通知が多すぎると、かえって見なくなる

最初は、失敗のたびにリアルタイムで通知を出していました。処理が失敗するたびに届く設計です。

でも1日の中で5回通知が届くと、2日目くらいから確認しなくなります。

「また来た」という感覚になって、開かないまま流してしまいます。

通知は「気づくためのもの」のはずです。でも多すぎると「無視するためのノイズ」に変わってしまいます。

広告の管理画面でも、似た経験がありました。アラートが多すぎると、本当に大事な警告を流してしまう。

「来る頻度が高すぎると読まなくなる」という人間の性質は、意識の問題ではありません。

設計で補うしかない部分です。

サマリー通知に入れる情報を絞った

毎朝8時に届く通知には、3つの情報だけを入れています。1つ目は「昨日何回失敗したか」という回数。

2つ目は「最後に失敗した処理のエラー内容（短文）」。

3つ目は「現在のカウンターが閾値に対してどのくらいの位置にあるか」。

「昨日3回失敗・閾値まで残り2回」という内容がひと目で読める形です。

この3つだけにしたのは、「読めばすぐ判断できる量」にとどめたかったからです。

詳細なログへのリンクは添えていますが、サマリーだけで今日何をすべきかわかる設計にしています。

通知の目的は「読んで判断する」ことなので、読む時間のかかる情報は入れない方が機能します。

情報を絞るほど、届いたときの1通の重みが増します。

朝8時に「昨日の失敗サマリー」が届く

今の設計では、通知は1日1回だけです。失敗が0件であれば、通知は来ません。

1件以上あった日だけ届くので、来たときには必ず中身を確認します。

「また来た」という感覚がなくなりました。

通知が来ない朝を、「昨日は問題なかった」という安心として読めるようになりました。

設計を変えることで、静寂の意味が「確認していない」から「確認済み」に変わります。

届いた通知の中身を確認してから動く——この小さな習慣が戻ってきた感覚があります。

「来なければ正常」を信頼できる設計にする

「失敗がなければ通知が来ない」設計には、1つ落とし穴があります。

通知システム自体が壊れたとき、失敗が起きても通知が来なくなる、という問題です。

これを防ぐために「ウォッチドッグ」と呼ばれる確認の仕組みを入れています。

毎朝の通知を「失敗があった日だけ」ではなく「毎日必ず1回送る」に変えるのが、最もシンプルな対策です。

失敗がなければ「昨日0件」という内容の通知が届きます。

これが来なければ「通知システム自体が壊れている」とわかります。

「来ない＝正常」ではなく「何かしら来る＝正常」に変えることで、静寂の罠から抜け出せます。

どちらの設計を選ぶかは、通知の頻度と運用の好みで決めていいと思います。

重要なのは「静寂を無条件に正常と読まない」という視点を持つことです。

まとめ：切り替えてからの2週間と、今日できること

空焼きの期間が「5日」から「1日以内」に縮まった

回路を切り替えてからの2週間、失敗が発生した日が4日ありました。

でも、最長でも翌朝8時の通知で気づいて止められました。

以前なら5日分積み上がっていたコストが、多くても1日分以内で止まるようになりました。

「失敗をゼロにする」ではなく「失敗に早く気づいて止める」方が、現実的だと実感しました。

失敗を完全になくすことは難しいです。でも、失敗に早く気づいて止める仕組みは、設計で作れます。

根拠のない安心から、根拠のある安心に変わったのが、この2週間でいちばん大きな変化でした。

「確認していないけど大丈夫なはず」と「通知が来ていないから大丈夫」は、気持ちの軽さがまったく違います。

自動化の仕組みをもっと細かく設計したい方には、別の有料記事にまとめています。フッターのリンクから覗いてみてください。

設計を変えたことで変わった日常の感覚

回路を入れる前は、「ちゃんと動いているかな」という不安が、毎日どこかにありました。

確認しに行けば安心できるのに、確認する手間を理由に先送りにしていました。

先送りが積み重なって、5日分の空焼きが完成していたわけです。

回路を入れた後は、「通知が来ていない＝昨日は問題なかった」という状態になりました。

朝起きてスマートフォンを確認するとき、通知がなければその瞬間に安心できます。

自動化の設計は、コードやツールの話だと思っていました。

でも実際には、「確認する時間をどこに集中させるか」という自分の行動設計でもありました。

止まる仕組みがあることで、確認しない日に罪悪感が生まれなくなりました。それが一番の変化かもしれません。

今日から始められる1つのこと

難しいことをしなくても、今日確認できることがあります。

「直近5日間の投稿が、実際にSNSに届いていたか」を確認することです。

SNSの投稿画面を開いて、日付の並びに抜けがないかを見るだけです。届いていれば問題なし。

届いていなかった日があれば、何が止まっていたかを追いかける起点になります。

ログがあるなら、その日の status 欄が failed になっていないかを確認します。

error 欄に何が書いてあるかを読むだけで、止まった原因の8割はわかります。

「動いている気がする」という状態から「確かめた」という状態に変えるだけで、空焼きに気づける確率が大きく上がります。

まず5日分を振り返ることから、始めてみてください。

📕 この記事の内容を、実装まで全部まとめた有料記事があります
手順・コード・テンプレをそのまま渡しています
AIで「寝てても回る仕組み」を30日で組む全手順｜コード不要・特典40ファイル・毎月更新