※本記事は自宅で運用している自動化の実行ログをもとにしています。
「写真は移動していないため再実行で回復できます」。この一文を、自動化のエラーログで何十回見てきたか分からない。自宅で5つのブログとインスタ投稿をAIに任せていると、毎日どこかで小さいエラーが出る。ほとんどは再実行すれば直る。だからログの❌を見ても「はいはい、いつものやつ」で流していた。
ところが2026年9月、その「いつものやつ」で片づけていた前提が崩れた回があった。同じ操作を4回繰り返しても直らない失敗と、失敗が2日続いていたことに翌朝まで気づけなかった放置があったのだ。
自動化の失敗ログが「再実行で回復」と言い続けていた理由
インスタの自動投稿（カルーセル投稿とリール投稿）は、失敗しても実行ログに理由を書いて次の実行に賭ける設計にしていた。実際、9月10日・12日・13日に出たHTTPエラーは、いずれも翌日か翌々日の実行で回復していた。写真データ自体は消えていないので、次に投稿処理が走れば同じ写真をもう一度アップロードするだけで済む。
ここだけ見ると「放っておけば直る仕組み」に見える。だが9月14日の朝、在庫チェックが🚨マークをつけて報告してきた。9月12日・13日と2日連続で同じ原因（画像URLの取得エラー・コード9004）が出ていたのだ。
| 発生日 | 症状 | 対応 |
| 9月10〜16日 | カルーセル投稿の画像URL取得エラー（9004）と、リール投稿の連続エラーが並行して発生 | 再実行のみで様子見・9月14日に🚨で顕在化 |
| 9月17日 03:36 | リール側の原因を特定＝動画の書き出し形式が非推奨（yuvj444p） | リールは書き出し形式を修正／画像取得の側には最大4回の自動再試行を追加 |
| 9月21日 | リール投稿が単発でエラー | 翌実行で回復・継続障害ではないと判断 |
| 9月22日 18:04 | 同じ画像URLで4回再試行しても投稿エラーが解消せず | 「再試行は万能ではない」と判断し設計変更へ |
| 9月23日 17:40 | – | 送信前に画像URLの中身を確認し、失敗していれば別URLへ上げ直す方式に変更 |
| 9月23〜29日 | 7日連続で全工程が成功 | – |
ここが今回の本題。9月17日の修正（再試行の回数を増やす）は一度効いたのに、9月22日にはまったく同じ再試行の仕組みが効かなかった。回数を増やすだけの再試行には、効く場合と効かない場合があるらしい、と気づいた瞬間だった。
再試行が効く自動化の失敗と効かない失敗の境目
RPA（業務自動化）のエラーを扱う解説では、原因を大きく「例外」と「変更」に分けて整理している。日立ソリューションズのコラムによると、「例外」はパソコン環境に変化があったことで起こるもので、ハードウェア原因とソフトウェア原因に分かれる。「変更」は業務手順の変更と成果物の変更に分かれ、データ取得元のシステムが変わった場合などがこれにあたる。
この整理を借りて、今回の2つの障害を自分の言葉で分け直してみた。分かれ目は「もう一度試したときに条件が変わるか」だった。
| 自分の整理 | 今回の例 | 再試行の効き方 |
| もう一度で条件が変わる失敗 | Instagram側の画像取得が一度だけ失敗した | 同じURLでも次の試行で通ることがある |
| もう一度でも条件が変わらない失敗 | アップロード先のURLがそもそも画像を返さなくなった | 同じURLを何回試しても結果は変わらない |
9月17日の対策は、上の表の1行目を前提にしたものだった。だから9月10〜16日の失敗には効いた。ところが9月22日の失敗は2行目、つまりURL自体が画像を返さなくなった側だった。同じ条件を繰り返す再試行は、条件が変わらない限り同じ結果しか返さない。ここを混同すると、対策を打ったのに直っていないように見えて振り回される。
ここ、地味に見落としやすいところだと思う。ログに「再試行で回復できます」と書いてあると、それが常に正しいと思い込んでしまう。
自動化の失敗に気づけないまま2日が過ぎていた
今回もう一つ引っかかったのは、失敗そのものより「失敗に気づくまでの時間」だった。9月12日・13日の❌は、9月14日朝の在庫チェックまで誰も見ていなかった。仕組みとしては毎回ログに記録していたのに、だ。日数にすれば2日。短いようでいて、毎日動く仕組みでは2日分の投稿が飛んでいる。
システム監視の分野では、通知されるアラートの数が膨大になると対処する管理者への負荷が増大する、と指摘されている。同じ解説には、異常を検知できていても、それが一時的なものか恒常的なものかは判断がつきにくい、とも書かれていた。うちで起きたのは後者だ。アラートが多すぎたわけではない。「単発の❌はだいたい翌日直る」という経験則に慣れすぎて、連続しているかどうかを毎回数えていなかった。
止まったこと自体は仕組みが検知していた。気づけなかったのは人間の側。ここは自動化のログを持っている人ほど陥りやすい落とし穴だと思う。
自動化の失敗を実際に直した2段階の対処
最終的に打った対策は2段階だった。落ち着いて振り返ると、どちらも「疑う対象を変えた」だけの話だ。
1段階目（9月17日）は、動画の書き出し形式をInstagram側が推奨する形式に修正した。あわせて、画像取得が失敗したときに30秒・60秒・90秒の間隔で最大4回まで自動的に再試行する処理を足した。これで9月10〜16日型の失敗はいったん止まった。
2段階目（9月23日）は、送信前に画像URLが本当に画像を返すかを確認する処理を入れた。返さなければ画像を保管先へ再アップロードし、新しいURLで送り直す。同じURLへの再試行では直らない失敗があると分かったので、「同じことをもう一度」ではなく「前提を作り直す」方向へ対策を変えたことになる。以降9月23日から29日までの7日間、投稿・リール作成・キュー投稿のいずれも失敗が出ていない。
正直、1段階目で満足して様子を見なければ、2段階目の原因には気づけなかった。同じ現象に見えても、直った理由を丁寧に見ないと次の失敗を見逃す。
個人の自動化に持ち帰れる教訓
個人事業主が自分の業務にAIや自動化を組み込むときにも、そのまま使える教訓が3つあると思う。
1つ目。「再実行で直ります」という前提のログは、直っている間は便利だが、直らなくなった瞬間に気づきにくい。エラーメッセージを鵜呑みにせず、同じ原因が2回続いたら一度立ち止まって見る癖をつけておくと安心だ。
2つ目。再試行の回数を増やす対策は「一時的な例外」にしか効かない。原因が状態そのものの変化なら、回数を増やしても意味がない。効かなかったときに「回数を足す」以外の選択肢を持っておきたい。
3つ目。失敗より怖いのは、失敗に気づけない期間があることだ。うちの場合は在庫チェックという別工程が週1で気づかせてくれたが、それが無ければもっと長く放置していたかもしれない。自動化を組むときは、実行そのものとは別に「連続して失敗していないか」を見る役目を用意しておくとよさそうだ。
よくある質問
自動化のエラーで「再試行すれば大丈夫」と書いてあるのに直らないのはなぜですか。
一時的な通信エラーのように、もう一度試せば条件が変わる失敗には再試行が効きます。一方、アップロード先のURLが画像を返さなくなったなど、何回試しても条件が変わらない失敗では結果も変わりません。原因がどちらなのかを見分けることが先になります。
自動化の失敗に早く気づくにはどうすればよいですか。
実行のたびにログを残すだけでは足りません。同じ原因が連続していないかを定期的に数える別の確認作業（在庫チェックや週次点検など）を用意しておきましょう。単発の失敗と、放置すべきでない連続失敗を区別しやすくなります。
自動化は「動けば安心」ではなく、止まったときにどう気づき、どう直すかまで含めて設計しないと、便利さの裏で気づかない放置が生まれる。今回の一件は、そのことを実行ログが教えてくれた例だった。
関連して、自動化の監視が嘘をついた話｜見落としの正体と対策では今回とは別の見落としパターンを扱っている。動画生成が4日止まった件はAI自動化のトラブル対処｜4日止まった原因はffmpeg未検出にまとめた。導入初期のつまずきはAI導入の失敗3つ｜実際に起きた原因と対策にある。3本あわせて読むと、自動化の失敗パターンの幅が見えてくる。
参考：日立ソリューションズ「RPAに起こりがちなエラーは「例外」と「変更」。その原因と対策をRPAのプロが解説」／NTTドコモビジネス「大量の監視アラートが生みだす運用上の課題とは」（いずれも2026年9月30日に本文確認）／Microsoft Learn「一時的な障害の処理に関するベスト プラクティス」（Azure Architecture Center・2026年2月26日更新。障害が一時的か長期的かを判断してから再試行すること、4xx系のクライアントエラーは再試行では解決しないこと、再試行回数の増加そのものを監視対象にすることを記載）／障害の発生日時・原因・対策は自宅で運用しているInstagram自動投稿の実行ログ（2026年9月10日〜29日）による
