AIに会社を任せていたら、4回の仕事が黙って止まっていた

動いていると思っていました。
13時間後に調べると、4回止まっていました。
エラーの通知は、一件も来ていませんでした。

僕の会社では、営業の準備、発信の分析、サービスの監視などをAIに任せています。
決められた時間になると自分で起動して、仕事を進め、終わったら報告する仕組みです。

一人会社なので、僕が寝ている間にも仕事が進む状態を作りたかった。
実際、それで助けられている仕事はかなりあります。

ただ、ひとつ大きな見落としがありました。

報告が来ないのは、仕事がないからだと思っていた

異変が見つかったのは、2026年7月22日です。

AIの定期作業が失敗したときに通知を出す仕組みを追加したところ、その日の昼に初めて通知が来ました。
エラーは「Connection closed mid-response」。処理の途中で接続が切れ、そのまま終了していました。

気になって、それ以前の実行記録も調べました。

すると、直近13時間で同じ止まり方をした定期作業が4回ありました。
夜の社内記録、営業準備、サービスの定期確認。種類の違う仕事が、どれも何も出力しないまま終わっていました。

ここは正確に書いておきます。
4回止まったからといって、4回分の仕事がすべて失われたとは限りません。
後から別の経路で成果物が作られていた仕事もあり、実際の損失額や失われた作業量までは確定できませんでした。

ただ、4回停止していたことと、僕たちが気づいていなかったことは事実です。

なぜ気づけなかったのか。
理由は単純でした。

成功したときだけ報告する仕組みにしていたからです。

報告が来なければ、「今日は報告することがなかった」「まだ実行時間ではない」「処理の途中で止まった」の区別がつきません。
正常でも異常でも、画面上では同じ沈黙になります。

僕はその沈黙を、勝手に「順調」と読んでいました。

記録をもう少し見ると、止まり方にも偏りがありました。
短時間で終わる軽い定期作業は、同じ時間帯でも動いていました。
止まっていたのは、比較的長く走る仕事です。

ある処理では、最後の応答から接続が切れるまで約15分の空白がありました。
AIが考え続けていたのか、通信が途中で止まっていたのか。その時点では原因を断定できませんでした。

ここも、人間の仕事とは感覚が違います。

人が長い作業で困っていれば、返事が遅くなる、手が止まる、相談が来るといった気配があります。
同じ部屋にいれば、なんとなく分かることもあります。

AIの定期作業には、その気配がありません。
元気に働いているようにも、完全に止まっているようにも見えない。
画面に何も出ない限り、こちらから確認するまで同じです。

「AIは文句を言わずに働く」という言い方があります。
実際は、文句だけではなく、困っていることも言わずに消える場合がありました。

失敗通知を作って、直った気になった

最初にやったのは、AIの処理がエラーで終了した瞬間に通知する仕組みを作ることでした。

通知先も一か所ではなく、監視用の場所と僕への直接通知の二つにしました。
最初の通知は監視用の場所に届いていたのに、3時間半、誰の目にも触れなかったからです。

「通知は送った」と「誰かが気づいた」は別でした。

これで、止まったことは分かるようになりました。
当時は、かなり前進したと思っていました。

でも、まだ半分でした。

その後4.5日間の記録を確認すると、失敗通知は24回発生していました。
24回とも通知の送信自体には成功していました。

それなのに、失敗した仕事は自動では戻りません。
人間が通知を見て、内容を確認して、もう一度実行しなければ、その回の仕事は止まったままです。

実際、毎晩更新する社内記録には3日間の空白ができました。
ある定期作業は5時間39分動いたあとに停止し、成果物をひとつも残しませんでした。

通知は届いていました。
でも、誰も再実行しませんでした。

僕たちは「失敗を見えるようにした」ことで安心して、その失敗を誰が直すのかまで決めていなかった。

火災報知器は付けた。
でも、鳴ったあとに消火する人がいませんでした。

通知の出口を、人間の受信箱から機械へ移した

次に、失敗した定期作業を自動で再実行する仕組みを追加しました。

エラーを検知すると、止まった仕事を特定して、再実行の待ち行列へ入れます。
30分ごとに動く別の仕組みがそれを拾い、条件を確認してから再実行します。

ただし、何でも自動でやり直せばいいわけではありません。

同じ仕事を二重に実行すると、営業メールを重ねて送ったり、同じ投稿を二回出したりする危険があります。
そこで、再実行は一つの障害につき一回。同じ仕事は一日二回まで。次の定期実行が60分以内なら見送る。障害から6時間以上たっていたら実行しない、といった条件を付けました。

投稿など、二重実行の影響が大きい仕事は自動復旧の対象外です。
止まったことだけ通知して、最後は人間が確認します。

実運転では、発信データを分析する定期作業を使って一周を確認しました。

失敗を検知する。
再実行の待ち行列へ入る。
別の仕組みが拾う。
分析結果が作られる。
完了として記録される。

ここまでつながって、ようやく「失敗を通知できる」から「失敗しても仕事を戻せる」に変わりました。

それでも、まだ見つけられない停止がある

これで全部解決したわけではありません。

いまの仕組みは、AIの処理が始まり、途中でエラーになった場合には動きます。
そもそも予定時刻に起動しなかった場合は、エラーを出す処理自体が存在しません。

また沈黙です。

これを見つけるには、「エラーが出たか」ではなく、「本来あるはずの成果物が、決めた時刻までに存在するか」を別の仕組みで確認する必要があります。

たとえば、毎朝作られるはずの報告書がなければ異常。
毎晩更新されるはずの記録の日付が古ければ異常。

AI本人の自己申告だけではなく、仕事の結果を外から見る仕組みが必要です。
ここは、まだ作り切れていません。

この考え方は、AIだけに限りません。

メール送信の仕組みなら、「送信処理が成功した」ではなく、送信記録が残っているかを見る。
サイト監視なら、「監視プログラムが動いた」ではなく、対象ページが実際に開き、必要な文字が表示されているかを見る。

仕事をした本人に「終わりましたか」と聞くだけではなく、出来上がるはずのものを見る。
人間の組織では当たり前にやっていた確認を、AIの仕組みにも一つずつ作り直す必要がありました。

AI社員が増えてから、静かな朝の見え方が変わった

AIに仕事を任せる前は、うまく指示を書くことが大事だと思っていました。
どんな役割を与えるか。何を読ませるか。どう判断させるか。

もちろん、それも必要です。

でも、実際の会社の仕事で動かしてみると、それだけでは足りませんでした。

止まったことをどう見つけるか。
誰が直すのか。
どこまで自動で戻してよいのか。
本当に成果物ができたことを、誰が確認するのか。

成功する手順より、失敗したあとの設計の方が難しい。

いま僕は、AIから報告が来ない朝ほど疑うようになりました。
以前なら「今日は何もなかったんだろう」と思っていたのに、まず止まっていないかを確認します。

AI社員が増えれば、僕の手作業は減ります。
ただ、僕が見なくていい場所が増えるわけではありません。
見るべきものの形が、人の働きぶりから、仕組みの沈黙へ変わっただけでした。

まだ全然、任せ切れる状態ではありません。