筆者はブログ5サイトをAIで自動運営しています。AIをそのまま導入すると、思わぬ失敗も起きます。今回は実際に起きた3つの失敗を、実行ログをもとにそのまま書きます。
結論から言うと、失敗の原因は毎回別々でした。外部APIの一時的なエラー、環境設定の見落とし、データ不足の3パターンです。対策も一つではなく「再試行で直る失敗」「原因を消し切らないと直らない失敗」「無理に動かさず止めるべき失敗」に分かれました。ここだけ押さえておけば、自分の環境でも同じ切り分けが使えます。
AI導入で実際に起きた3つの失敗（一覧）
| 失敗 | 原因 | 発生期間 | 対策 |
|---|---|---|---|
| Instagram投稿がエラーで止まった | Meta側の一時的な400エラー | 2026年7月6日・1回 | 写真を動かさない設計だったため再試行のみで回復 |
| リール動画が作れない | フォント探索の不具合、さらにffmpegのパス不備 | 2026年7月8〜11日・4日連続 | 1回目の修理では一部しか直せず、原因を洗い直して7月12日に再修理 |
| note転用記事が作れない | 元データ（検索データ・記事）がほぼ空 | 2026年7月8日以降・保留中 | 無理に作らず、データが貯まるまで処理を止める設計のまま様子見 |
失敗1：Instagram投稿が400エラーで止まった話
2026年7月6日18時00分41秒、Instagramへの自動投稿（カルーセル投稿）が失敗しました。実行ログに残っていたエラーは次のとおりです。
HTTPError: 400 Client Error: Bad Request for url: https://graph.facebook.com/v25.0/17841404294980856/media
原因はMeta側APIの一時的なエラーです。ここで助かったのは、失敗しても投稿予定の写真データを移動・削除しない設計にしていたことです。同日18時56分14秒、同じ処理をもう一度動かしただけで、写真5枚の投稿に成功しました（投稿ID：18130213522627807）。所要時間にして約56分、対応らしい対応は「もう一度動かす」だけでした。
外部のAPIを使う以上、こういう一時的なエラーはゼロにはできません。壊れやすいのはAPI呼び出しの部分だと割り切り、「失敗してもデータが消えない・二重投稿にならない」設計にしておけば、被害は再試行の手間だけで済みます。
失敗2：リール動画が4日連続で失敗した話
もう一つは、もっと厄介でした。7月8日から7月11日まで、リール動画の自動作成（create_reel）が4日連続で失敗しました。実行ログに残っていたエラーは日によって表示が違い、それが原因の見誤りにつながりました。
| 日付 | 状態 | ログに残ったエラーの要約 |
|---|---|---|
| 7月8日 | ❌ 失敗 | RuntimeError: make_video.py が失敗しました（終了コード1） |
| 7月9日 夜 | 🔧 修理（一部のみ） | 原因を「Macに無いfc-matchでのフォント探索」と特定し対処。次回実行での回復を想定 |
| 7月10日 | ❌ 失敗（再発） | FileNotFoundError: [Errno 2] No such file or directory: ‘ffmpeg’ |
| 7月11日 | ❌ 失敗（継続） | FileNotFoundError: [Errno 2] No such file or directory: ‘ffmpeg’（前日と同一） |
| 7月12日 | ✅ 復旧 | PATH補強＋絶対パス解決でffmpeg・fc-match双方を解消。以降は連続成功 |
7月9日の夜に一度「修理完了」と判断したのですが、これが甘かったのです。実際に直っていたのはフォント探索まわりの不具合だけでした。動画変換ソフト（ffmpeg）本体をうまく呼び出せていない、という別の原因が残っていたのです。結果、翌日以降もFileNotFoundError: ffmpegという、フォント探索とは別種のエラーで失敗が続きました。
意外に思うかもしれませんが、「直った」と判断するタイミングが早すぎたのが本当の敗因でした。7月12日になってようやく、実行環境のPATH設定を見直し、ffmpegとfc-matchの両方を絶対パスで解決する形に改修して原因を消しきりました。1つ目の原因を潰しても、2つ目の原因が残っていれば同じ「失敗」という結果だけが繰り返されます。エラーメッセージの文言が変わっていないか（今回なら「フォント探索」から「ffmpeg未検出」へ変わっていた）まで見比べる。修理したあと、次の自動実行の結果まで見届ける。当たり前のことを、あらためて思い知らされました。
失敗3：データが無いから、あえて止めた話
3つ目は失敗というより「止めた」話です。7月8日、ブログの人気記事をnote向けに転用する自動処理を動かそうとしたところ、判断に使う2つのデータ源がどちらも空でした。1つは検索データ（gsc_data.json、対象期間は集計開始直後でまだ蓄積なし）、もう1つはフォールバック用の投稿記事データです。
ここで無理にそれらしい記事を作ることもできたはずです。ですが、根拠のない転用記事を出すほうが後々のリスクが大きいと判断し、処理そのものを中止しました。あわてなくて大丈夫です、と自分に言い聞かせるような判断でした。データが貯まるのを待つ、というのも立派な対策のひとつだと思います。この処理はその後、検索データが蓄積された段階で自動的に再開しています。
3つの失敗から見えた共通点
3件を並べてみると、対応の分かれ目は「症状が同じでも原因は違うことがある」という一点に尽きます。失敗1は再試行だけで直る一過性のエラー、失敗2は原因が2つ重なっていて1つ直しただけでは症状が消えない厄介なケース、失敗3はそもそも直すのではなく止める判断が正解でした。この3パターンを覚えておくと、次に似た失敗が起きたときの初動が早くなります。
よくある質問
Q. AI導入の失敗は、どこまで自動で直せますか。
A. 外部APIの一時的なエラーのような「再試行すれば直る失敗」は、自動でも対応できます。ただし環境設定の見落としのような原因は、人が切り分けて直すまで残ります。
Q. 修理したつもりが直っていない、を防ぐには。
A. 修理後に「次の自動実行の結果」まで確認することです。今回も、修理直後の一時的な成功だけで判断していたら見落としていました。エラーメッセージの文言が変わっていないかも合わせて見ます。
Q. データが足りないときはどうすればいいですか。
A. 無理に処理を進めず、いったん止めるという選択肢を持っておくと安全です。今回もその判断で余計なリスクを避けられました。
Q. こうした失敗は事前に防げなかったのですか。
A. 一部は防げたはずですが、実際に動かしてみないと気づけない原因もありました。失敗を記録して次に活かす仕組みのほうが現実的だと感じています。
あわせて読みたい
失敗を早く見つける仕組みについてはAI監視を自動化する仕組み｜失敗を見逃さない3層構成で詳しく書いています。今回の実測値のもとになった実行ログの作り方はAIの業務ログ管理術｜自動化で最初に作る実行ログとはを見てください。
画像：Pixabay
