自動処理の監視は「最後に成功した時刻」を見る｜安全に止まる仕組みは通知とワンセット

ホームページの自動更新、売上の自動集計、SNSの自動投稿。店舗の運営には、いまや何かしらの「自動で動く処理」が組み込まれています。

この自動処理には、手作業にはない怖さがあります。止まっても、誰も何も言ってこないことです。担当者が休めば誰かが気づきますが、自動処理は静かに止まり、静かに止まり続けます。気づくきっかけが「お客様からの指摘」になってしまうと、その時点で数週間分の情報が届いていなかった、ということが実際に起こります。

この記事では、自動処理を安心して任せるための監視の考え方を、結論から示します。

結論：「失敗の検知」ではなく「成功の鮮度」を監視する

先に正解を書きます。自動処理の監視で見るべきものは、次の2つです。

1. 「最後に成功した時刻」を監視する。 エラーの発生を待つのではなく、「最後にうまくいったのはいつか」を見ます。たとえば30分ごとに動く処理なら、「最後の成功から3時間経っていたら異常」と判断できます。失敗が何回起きたかは数えなくてよく、成功が新しいかどうかだけを見ます。

2. 処理を「安全に止める」仕組みを入れるなら、「止まったと知らせる」通知をワンセットで付ける。 想定外のデータが来たときに処理を止めるのは正しい設計です。壊れた状態のまま公開するより、止まる方が安全だからです。ただし、止める判断だけを実装して通知を付けないと、その安全装置は「静かなサービス停止」に変わります。止める設計と知らせる設計は、必ず同時に入れます。

なぜ「失敗の検知」ではだめなのか。それは、自動処理の失敗の多くが、失敗として観測できない形で起きるからです。

失敗が「見えない」3つの型

自動処理が止まるとき、エラー通知が飛んでくるとは限りません。保守の現場で実際に確認された、気づけない失敗には3つの型があります。

型	何が起きるか	なぜ気づけないか
エラーが捨てられる	処理は失敗し続けているが、エラー出力が破棄される設定になっている	ログに何も残らない
成功と報告される	処理自体は「正常終了」するが、中身が空振りしている	ログ上はすべて成功
そもそも実行されない	定期実行の登録はあるが、発火していない	エラーログが空＝一見正常

1つめの型は、定期実行の設定で出力を捨てる書き方（ログを残さない設定)になっているケースです。サーバーの定期実行ではよくある書き方ですが、失敗の情報も一緒に飲み込まれます。

2つめの型は、以前の記事（自動処理が「成功」と出ているのに反映されないとき）で扱った型です。実例では、毎日動く集計処理が52日間「正常終了」し続けながら、中身は認証切れで空振りしていました。

3つめの型は、Macやサーバーの定期実行によくあります。実例では、登録も設定ファイルも正常でエラーログも空のまま、28日間一度も実行されていなかったケースがあります。原因として多いのは、実行予定の時刻にマシンがスリープしていた、というものです。実行されていないのだからエラーも出ない。「エラーログが空」はむしろ正常に見えてしまいます。「登録されている」ことは「動いている」ことの証拠にならない、と覚えておいてください。あわせて、定期実行の時刻はマシンが確実に起きている時間帯に置くのが予防策になります。

3つの型は原因がバラバラですが、共通点が1つあります。どの型でも「成果物の最終更新時刻」は止まることです。だから監視は、ログでもエラーでもなく「最後に成功した時刻」を見るのが確実なのです。

なぜ「失敗回数」を数える監視ではだめなのか

「失敗が3回続いたら通知する」という監視も、考え方としてはあります。しかし店舗の実務ではおすすめしません。理由は2つです。

第一に、失敗を数える監視は「失敗が記録される」ことを前提にしているからです。先ほどの3つの型は、いずれも失敗が記録に残りません。記録されないものは数えられず、監視は一度も発動しないまま止まり続けます。

第二に、通知が鳴りすぎる問題です。自動処理には、サーバーの一時的な混雑などで単発の失敗が起きて、次の回では勝手に復旧しているものが少なくありません。失敗のたびに通知を飛ばすと、「また鳴っているが放っておけば直るやつだ」という扱いが定着し、本物の停止が来たときに無視されます。通知は、鳴ったら必ず対応するものだけに絞るのが運用の鉄則です。

「最後に成功した時刻」の監視は、この両方を解決します。単発の失敗で成功時刻が古びることはなく、本当に止まったときだけ確実に古くなる。数えるより、日付を見る方が強いのです。

実例：安全装置が「正しく」働き続けて、更新が3週間止まる

もう1つ、見落とされやすいのが「安全装置による停止」です。ある医療機関の公式サイトで実際に起きた例を挙げます。

このサイトは、管理画面で記事を公開すると、30分ごとの自動処理がサイトを組み立て直して反映する仕組みでした。この自動処理には安全装置が入っていました。URLの対応表に登録されていない新しい記事が来たら、処理を止めるというものです。誤ったURLでページを公開しないための、それ自体は正しい設計です。

ある日、対応表に未登録の新規記事が1本公開されました。安全装置は設計どおりに働き、処理を止めました。ここまでは正常です。問題はその後です。止まったことを知らせる通知が、どこにもなかったのです。

30分ごとの処理は、その後も律儀に動き続けました。そして毎回、同じ安全装置で止まり続けました。3週間で約1,000回です。その間に公開された別の重要なお知らせも、処理が止まっているため巻き添えでサイトに反映されません。発覚のきっかけは、サイトを見た関係者からの「新しいお知らせが表示されていない」という指摘でした。

この事態は、安全装置が壊れていたから起きたのではありません。安全装置が正しく働き続けたのに、それを知る手段がなかったから起きました。「止める」だけ実装して「知らせる」を付けないと、安全のための仕組みがそのまま障害になります。冒頭の結論2は、この構造を防ぐためのものです。

なお、この件で原因特定の決め手になったのも「最後に成功した時刻」でした。処理の成果物の更新時刻が3週間前で止まっていたことが、どの時点から止まっていたかを一発で示したのです。

自動処理の点検手順：明日からできる4ステップ

自分の店舗・会社の自動処理を点検する手順です。専門知識がなくても、1と2は今日できます。

ステップ1：動いているはずの自動処理を書き出す。 サイトの自動更新、予約の自動返信、売上の自動集計、SNSの自動投稿、バックアップ。「何が自動で動いているか」の一覧が、そもそも存在しないことが多いです。制作会社や保守会社に任せている場合は、一覧をもらってください。

ステップ2：それぞれ「最後に成功したのはいつか」をどこで確認できるか決める。 難しい話ではありません。自動投稿なら「最新の投稿日時」、自動集計なら「データの最終日付」、サイトの自動更新なら「最後に記事が反映された日時」。ログではなく、成果物を見るのがコツです。ログは嘘をつく（成功と書いてある・そもそも書かれない）ことがありますが、成果物の日付は嘘をつきません。

ステップ3：「何時間止まったら異常か」の線を決める。 処理の間隔から逆算します。30分ごとの処理なら数時間、毎日の処理なら2日。この線を超えたら知らせる通知を、メールやLINEなど普段見る場所に飛ばします。ここは保守側の実装が必要なので、依頼する場合は「最後に成功した時刻がN時間より古くなったら通知してほしい」とそのまま伝えれば通じます。

ステップ4：「止める」仕組みには「知らせる」を必ずセットで求める。 新しく自動化を発注するとき、確認することは2つです。「想定外のときは止まりますか」と「止まったことは、誰に、どうやって伝わりますか」。前者だけ確認して安心しないでください。後者の答えが「ログに残ります」なら、それは誰にも伝わらないのと同じです。

「表示されない」と言われたら：中身側と反映側を最初に切り分ける

監視とあわせて、トラブル時の初動も決めておくと復旧が早くなります。「サイトに新しい記事が表示されない」という連絡を受けたとき、原因は大きく2か所に分かれます。

• 中身側：そもそも記事が公開されていない（下書きのまま・公開日が未来になっている）
• 反映側：記事は正しく公開されているが、それをサイトに反映する処理が止まっている

先ほどの医療機関の例では、管理画面側を先に確認して「記事は正しく存在する」ことを確定させたため、調査が反映側に一直線に進みました。この切り分けを最初にやらないと、正常な側を延々と調べることになります。連絡を受ける側（保守会社）にとっても、依頼する側にとっても、「管理画面では公開になっていますか」が最初の一問です。

まとめ

• 自動処理の監視は、失敗の検知ではなく「最後に成功した時刻」＝成功の鮮度を見る
• 失敗は「エラーが捨てられる」「成功と報告される」「実行されていない」の3つの型で見えなくなるが、成果物の最終更新時刻はどの型でも止まる
• 安全のために処理を止める設計は正しい。ただし「止める」と「知らせる」は必ずワンセット。通知のない安全装置は、静かなサービス停止になる
• 点検は「自動処理の一覧を作る→成功の確認場所を決める→異常の線を決めて通知する→止める仕組みに知らせるを求める」の4ステップ
• 「表示されない」の初動は、中身側（公開されているか）と反映側（反映する処理が動いているか)の切り分けから

自動化は、任せきれるから価値があります。そして任せきるために必要なのは、高度な監視ツールではなく、「最後にうまくいったのはいつか」を見るというシンプルな習慣です。自動処理を入れている方は、まずステップ1の一覧づくりから始めてみてください。