結論: 通知が来ない日は、正常か停止かのどちらかです
自動化した仕事が止まっても、その日は何も起きません。警告の画面が出るわけでも、誰かが困った顔をするわけでもない。止まった自動化は、静かに何もしないだけです。
私たち株式会社隼は、通知の設計で「何もなければ何も送らない」という原則を敷いています。0件のときに黙る仕組みは、鳴ったときに必ず読まれるからです。この原則自体は今も変えていません。ただ、この原則には副作用がありました。沈黙が「異常なし」と「動いていない」の2つの意味を持ってしまう。この2つは、通知だけを見ている限り一生区別できません。
私たちが区別に使うことにしたのが「最終実行の鮮度」です。その仕組みが最後に正常終了した時刻を1箇所に残し、通知ではなく記録のほうで生存を確かめる。以下は、そこに行き着くまでに実際に起きたことを、失敗のまま書いています。
何が起きたのか？
答えを先に言うと、外部サービスへのログイン状態が期限切れになり、そこにぶら下がっていた自動処理が同じ日に一斉に失敗しました。
私たちは経理・請求・入金確認まわりで十数本の自動処理を毎日動かしています。数字を集める、突き合わせる、異常だけ知らせる。この一群が共通で使っていたのが、社外のデータ保管サービスへの接続でした。その接続の認証が切れました。設定ファイルは残っているのに、中身の有効期限だけが切れている状態です。
各タスクは「書き込めませんでした」と知らせる設計だったので、失敗そのものは表に出ました。問題は、原因のほうを誰も見ていなかったことです。個々の失敗は通知していたのに、全部の土台である認証が生きているかを見る仕組みがなかった。 復旧の手順もブラウザでログインし直す作業で、これは人が画面の前でやるしかありません。翌朝の定時運行で自然に戻る設計のものは自力で回復し、戻らないものは手で動かしました。
なぜ点検表は全部○だったのか？
理由はシンプルで、点検が週に1回だったからです。
私たちは自動化の「黙り込み」を検知する点検を回しています。各タスクが最後に動いた記録の鮮度を読み、古いものを要確認として挙げる仕組みです。ところがその週の点検は、認証が切れる前に走っていました。点検表は全部○のまま、実際には止まっていたことになります。
ここで学んだのは、点検の精度ではなく間隔の問題でした。週に1回の点検は、週の途中で起きた停止に対しては無力です。 停止から発覚までの最大の空白が、そのまま点検の間隔になる。私たちの場合、財務の自動処理は毎朝まとめて動くので、空白を1週間から1日に縮めるだけで実害はほぼ消えます。
見張りを立てたら、見張りが黙りました
対策として、毎朝の見張りを1本立てました。財務の自動処理が動き出す前に、実際に1件だけ書き込みを試す。通れば沈黙、通らなければ人がやる手順を添えて知らせる。設定の壊れ方のうち機械で直せるもの（権限の崩れ・余計な改行の混入・設定の消失）は、その場で直してもう一度試すところまで持たせました。
その見張りが、立てた3日後に空振りしました。
原因は指示書の書き出しです。冒頭が「〜を検知する仕組みです」という説明文で始まっていたため、AIがそれを読んで挨拶を返しただけで、肝心のスクリプトを動かさずに終わっていました。しかも記録には「成功」と残っていました。見張りが動いていないのに、動いた記録だけが残っていた。 私たちが恐れていた黙り込みが、黙り込みを見つけるための仕組みそのもので起きたことになります。
直したのは1点だけです。指示書の冒頭を説明文ではなく命令形に変えました。あわせて、見張りの成否は自己申告ではなく、書き込みが通ったかどうかの結果で判定するようにしています。AIへの指示が実行されず言葉だけ返ってくる問題は、AIへの指示の置き場所を決めた記事にも通じます。
沈黙は4種類に分かれます
正直に書くと、私たちにはもう1つ失敗があります。別系統の自動更新が3日連続で同じ理由で失敗し、毎日その報告も届いていたのに、直りませんでした。原因は分かっていて、対処が後回しになっただけです。通知は届いていた。それでも止まったままでした。
この2つの失敗を並べると、確認すべきものが通知だけではないと分かります。私たちは今、①通知が来たか②最終実行の記録が新しいか、の2つで状態を仕分けています。通知が来ておらず記録も新しいなら正常、これは沈黙してよい。通知が来ていないのに記録が古いなら黙り込みで、これが最も危険です。通知が来て記録も新しいなら、検知できている異常として想定内。そして通知が来ているのに記録が古いままなら、それは異常ではなく放置です。
4つ目の「放置」は仕組みの問題ではなく、私たちの判断の問題でした。毎日届く同じ失敗通知は、3日目には風景になります。同じ通知が2回続いたら内容を読む前に対処の予定を決める、というのが今の運用です。通知を増やすほど読める量を超えていく話は、自動化の上限を読み手の定員から数えた記事に書いています。
明日からできること
まず、いま動かしている自動化を1つ選び、最後に正常終了した時刻がどこかに残っているかを確かめてみてください。残っていなければ、記録を1行足すところから始まります。日時とタスク名だけで十分です。
そのうえで、次の3つを決めます。1つ目は、その時刻を見る間隔を「週に1回」ではなく「その仕組みが次に動く直前」にすること。2つ目は、見張りに実際の書き込みを1件やらせて、その結果で成否を判定すること——動いたかどうかを本人の自己申告で決めない。3つ目は、同じ失敗通知が2回続いたら、内容を読む前に対処の予定を先に決めることです。
沈黙を信じるかどうかは、通知の設計では決まりません。最後に動いた時刻が新しいかどうか、それだけで決まります。私たちが通知の宛先や書式を整理したときの原則は通知の宛先を役割で分けた記事にまとめていますが、その原則を安全に使い続けるための土台が、この鮮度の記録でした。