自動で動かしていた動画生成が、4日連続で止まりました。最終的な原因は「ffmpegが見つからない」——ソフトは入っているのに、自動実行から起動すると置き場所の設定が引き継がれず、無いものとして扱われていたためです。しかも原因は1つではなく、手前にフォント探索のつまずきも隠れていました。やっかいなのは、投稿側の処理は成功し続けていたのでログがパッと見は正常に見えたこと。この記事では、気づいた経緯・原因の切り分け・復旧手順・再発防止の3つの習慣を実行ログどおりに書きます。
何が起きたか：動画生成だけが4日連続で失敗
止まったのは、写真を短い縦動画（リール）に変換する処理です。毎晩18時に自動で走る仕組みで、実行ログを見ると失敗は2026年7月8日から11日まで4日連続。そのたびに「終了コード1」で落ちていました。
このシステムでは、同じ時間帯に3つの処理が順番に動きます。写真をまとめて投稿する処理、写真を動画に変換する処理、作りためた動画を投稿する処理の3つです。当時のログを表にすると、こうなっていました。
| 日付 | 写真の投稿 | 動画の生成 | 動画の投稿（在庫から） |
|---|---|---|---|
| 7月8日 | 成功 | 失敗（終了コード1） | 成功（在庫 残り14本） |
| 7月9日 | 成功 | 失敗（終了コード1） | 成功（残り13本） |
| 7月10日 | 成功 | 失敗（ffmpeg未検出） | 成功（残り12本） |
| 7月11日 | 成功 | 失敗（ffmpeg未検出） | 成功（残り11本） |
| 7月12日 | 成功 | 成功（修正後） | 成功（残り11本） |
出典：自宅の自動投稿システム実行ログ（2026-07-08〜07-12の実測）
ご覧のとおり、失敗していたのは真ん中の「動画の生成」だけです。投稿側は毎日成功の行が出ていたので、ログはパッと見は正常に見えました。その裏で、作り置きの在庫だけが14本から11本へ静かに減っていたわけです。ここ、見逃しやすいところです。実行ログの作り方はこちらにまとめています。
原因は1つではなかった：フォント探索とffmpeg未検出
最初のログには「終了コード1」としか残っておらず、原因が絞れませんでした。7月9日の夜に調べたところ、1つ目の原因が見つかります。動画のテロップ用フォントを探すコマンドがこのパソコンに入っておらず、処理が起動直後に終了していたのです。しかも記録をさかのぼると、7月7日の改修以降、この環境では一度も成功していませんでした。
そこでテロップを使わないときはフォント探索を飛ばすように直し、あわせて「失敗したときは詳しいエラー文をログに残す」変更も入れました。これで直ったと思ったのですが、翌7月10日もまた失敗します。
ただし今度は、エラー文がはっきり変わっていました。「No such file or directory: ‘ffmpeg’」。動画変換に使うffmpeg（エフエムペグ＝動画をつなぐ無料ソフト）が見つからない、という内容です。詳しいエラーを残す変更が、ここで効きました。
ffmpeg自体はパソコンに入っていました。ところが、自動実行の仕組み（時間になると裏で動かす仕掛け）から起動すると、ソフトの置き場所を示す設定（PATH＝パス）が引き継がれず、「そんなソフトは無い」と判断してしまう。手で動かすと成功し、自動だと失敗する。この差が犯人でした。
復旧：置き場所を絶対の住所で指定した
7月12日に直しました。やったことは大きく2つです。1つ目は、ffmpegの置き場所を絶対パス（省略しない完全な住所）で指定し、設定に頼らず必ず見つかるようにしたこと。2つ目は、手で確認できる導入チェック用のファイルを1つ足したことです。修正の前後を比べると、次のようになります。
| 項目 | 修正前 | 修正後 |
|---|---|---|
| ffmpegの探し方 | 環境の設定（PATH）頼み | 絶対パスで指定＋設定も補強 |
| フォント探索 | テロップを使わなくても実行 | 使わないときは飛ばす |
| 失敗時の記録 | 「終了コード1」のみ | 詳しいエラー文もログに残す |
| 導入の確認 | 手段なし | チェック用ファイルで手動確認できる |
修正した当日の夜に動作を確認し、翌13日は定時18時の自動実行でも成功。連続失敗は止まりました。直したあとに「本当に自動で通るか」を実際の自動実行で見届けるまでが復旧です。手元で1回動いただけで安心しないようにしています。なお、同じ動画生成の仕組みは、その後こう改善しました。
同じトラブルを防ぐ3つの習慣
今回の一件から、自動化のトラブル対処で効いた習慣を3つに整理しました。難しいことはありません。
| 習慣 | やること |
|---|---|
| 失敗も1行残す | 成功だけでなく失敗もログに記録し、あとから時系列で追えるようにする |
| 手動と自動で差が出ないか疑う | 「手では動くのに自動だと落ちる」ときは設定の引き継ぎを疑う |
| 直したら自動実行で確認 | 手元で1回動いた=復旧、と決めつけない。本番の自動実行で見届ける |
加えて今回学んだのは、「減っていく数字」を見ることです。成功・失敗の行だけでなく、在庫本数のように減り続けると困る数字をログに載せておくと、どこかが静かに止まったときに気づけます。ここだけ押さえておけば大丈夫です。自動化は「動いて当たり前」ではなく、静かに止まる前提で見張る仕組みをセットにしておくと安心できます。別のトラブル事例（構造化データの検証手順）はこちら。
よくある質問
Q. 手動では動くのに、自動実行だと失敗するのはなぜですか？
A. 自動実行の仕組みから起動すると、ソフトの置き場所を示す設定（PATH）が手動時と同じに引き継がれないことがあるためです。外部ソフトを呼ぶときは絶対パスで指定しておくと確実です。
Q. 一部だけ止まる「静かな停止」に早く気づくには？
A. 処理ごとに成功・失敗を1行ずつログへ残し、在庫本数のような「減ると困る数字」も一緒に記録しておくことです。今回も投稿は成功し続けていたため、在庫の減りが唯一のサインでした。
Q. エラーの詳細が出ないときはどうすればいいですか？
A. 終了コードだけでは原因を絞れません。失敗したときに詳しいエラー文をログへ記録する処理を先に足すのがおすすめです。今回もその変更のおかげで、2つ目の原因がすぐ読み取れました。
まとめ
今回のトラブルは、フォント探索のつまずきとffmpeg未検出という2つの原因が重なり、投稿成功の行に隠れて4日間見過ごされたものでした。失敗をログに残し、手動と自動の差を疑い、直したら自動実行で確認する。この3つで、次の「静かな停止」に早く気づけます。あわてず、記録から順にたどれば原因はたいてい見つかります。
あわせて読みたい：AI導入の失敗3つ｜実際に起きた原因と対策／AI監視を自動化する仕組み｜失敗を見逃さない3層構成
参考：自宅の自動投稿システム実行ログ（2026-07-08〜07-13）
