自動運転のエラーに11日間だれも気づいていなかった ― 失敗記録を見直して、毎日の「見回り役」を置いた話
J-WORKSでは、SNS投稿やデータの取り込みなどを自動で動かしている。直近21日分の失敗記録をAIに見直させたところ、サイトのクリック数を取り込む処理が約11日間、毎日失敗し続けていたのに、だれも気づいていなかった。失敗の中身を分類し、失敗が続いているものを定期的に見回る仕組みを作った記録。
検証条件
J-WORKSの社内システムは、SNS投稿、記事の生成、外部のデータの取り込みなどを、決まった時刻に自動で実行している。それぞれの実行結果は記録として残るが、記録を毎日だれかが見ているわけではなかった。2026年9月29日、AIに直近21日分の自動運転の失敗記録をまとめて見直させた。今回の記録は、その見直しで分かったことと、その後に作った仕組みである。
実行内容
21日分の失敗記録を、処理ごとに並べ、失敗が1回きりで終わっているのか、何日も続いているのかに分けた。あわせて、記録の上では止まった理由が残っていないのに動いていない処理が無いかも確認した。
結果
見直しで、次のことが分かった。Webサイトのクリック数を取り込む処理は、9月18日に一度手作業で直していたが、その後に結果をだれも確認しないまま、約11日間、毎日失敗し続けていた。また、別の仕組みも、止めたという記録が無いまま5日間止まっていた。一方で、SNS投稿の失敗(Threadsで4回、Xで1回など)は、次の回で自然に回復していた。つまり、失敗には「一時的で、放っておいても次で直るもの」と「続いていて、だれかが対応しないと直らないもの」の2種類があり、問題は後者が埋もれていたことだった。次の回で回復する失敗は、毎回だれかが対応する必要は無いが、回復しない失敗と同じ一覧に並んでいると、本当に対応が必要なものが見えにくくなる。後者の2件に共通していたのは、「一度手をつけたが、最後まで見届けずに離れた」ことである。クリック数の取り込みについては、翌9月30日に原因を調べ直した。外部のサーバーへ接続するためのプログラムが、社内システムから起動されたときに必要な設定値(環境変数)の一部を受け取っておらず、何も出力しないまま即座に終了していたことが分かり、その設定値を補うよう直した。あわせて、失敗したときに原因の手がかりが記録に残るようにした。
失敗原因
11日間気づけなかった原因は、自動運転の失敗を「だれかが見るはず」の記録に残すだけで、続いている失敗を拾い上げる役が決まっていなかったことにある。さらに、一度直した時点で「直したつもり」になり、翌日以降の結果を確かめていなかった。自動化された仕組みは、一度動き始めると「動いているはず」と思い込みやすく、失敗が静かに続いていても、だれも気づかない状態が生まれやすい。手作業で直した後に、翌日の実行結果を確かめる、という一手間が抜けていたことが、11日という長さにつながった。
改善
毎朝の健康診断のように自動運転の状態を見て回る「見回り役」を置くことにし、9月30日に社内システムへ組み込んだ。見回りは30分ごとに、前回の実行が失敗している定期処理と、エラーのまま止まっているAIスタッフを確認する。一時的な失敗であれば1回だけやり直す。ただし、SNS投稿など外部へ公開する処理は、決められた時間帯の外では動かさず、記録だけにとどめる。また、公開系の処理の実行中や、30分以内にその予定がある間は、やり直しを次の見回りへ延ばす。やり直しても失敗するものや、明らかに一時的ではないエラーは、修正のための開発作業として1件登録し、同じ問題を重ねて登録しないようにした。お金や認証(決済やログイン情報など)に関わるエラーは、自動ではやり直さず、運営者の確認待ちとして社内の画面に表示する。見回りで実際に何かをした回だけ記録を残し、社内の画面に表示する。見回りの結果を知らせる方法も、メールのような新しい通知の仕組みは作らず、運営者が普段見ている社内の画面に出す形にした。
現在の結論
2026年9月29日の見直しで確認できたのは、クリック数の取り込みが約11日間、別の仕組みが5日間、だれにも気づかれずに止まっていた一方、SNS投稿の失敗は次の回で回復していたことである。この結果を受けて、翌日に見回りの仕組みを作り、クリック数の取り込みの原因も直した。AIや自動化の仕組みに運用を任せる場合は、「直したつもり」「動いているはず」で終わらせず、毎日決まった時間に、失敗が続いているもの・データが増えていないものを機械的に見回る役を置くことをおすすめする。その際、一時的な失敗と続いている失敗を分けて扱うと、本当に対応が必要なものが埋もれにくくなる。見回りを作るときに決めておくとよいのは、(1)何を「失敗」とみなすか(前回の実行が失敗した、データが増えていない等)、(2)一時的な失敗をどう扱うか(1回だけやり直す等)、(3)やり直しても直らない失敗を誰に渡すか、(4)自動でやり直してはいけない処理(外部への公開、お金や認証が関わるもの等)はどれか、(5)見回りの結果をどこに表示するか、の5点である。特に(4)を決めておかないと、見回り自体が新しい事故の原因になりうる。また、何かを直した後は、少なくとも次の実行結果を確かめてから、作業を終えたことにするとよい。
根拠
2026-09-29(JST)に実施した直近21日分の自動運転の失敗記録の見直し結果(J-WORKS社内のノウハウ記録)と、2026-09-30(JST)に実装した見回りの仕組み・クリック数取り込みの修正の記録(変更内容とコミットメッセージ)による。