【AI社員実践記 第15話】「見張り番」を誰が見張る？ 4つの自動処理に“点呼”を追加してみた

こんにちは、オフィスピコッツの小笹です。

第9話から、月900円弱のVPSへ少しずつ仕事を増やしてきました。

最初は26サイトを見回るサイト監視係。

その後、

• ドメイン期限チェック
• 月次稼働率レポート
• リンク切れ巡回
• 補助金の締切ウォッチ

と仕事が増え、今では1台のVPSの中で5つの仕事が動いています。

ここまで来ると、

「人間が毎回確認しなくても、機械が勝手に働いてくれる」

状態にかなり近づいてきました。

ところが、5人目の係を追加したところで、一つ大きな穴に気づきました。

今回のテーマは、

「見張り番は、誰が見張るのか」

です。

作業時間は約30分。

追加の固定費は0円でした。

「メールが来ない＝正常」と思っていた

これまで作った自動化には、一つ共通した考え方があります。

平常時は、できるだけ黙っている。

たとえばドメイン期限チェック係。

期限が十分残っていれば、メールは送りません。

リンク切れ巡回係も同じです。

リンク切れがなければ、何も言ってきません。

サイト監視も、正常に動いている間は通知しません。

毎日、

「今日も大丈夫でした」

というメールを何通も送られても、結局読まなくなるからです。

問題があるときだけ知らせる。

これは今でも気に入っている設計です。

ただし、AI社員との会話の中で、その設計には一つ弱点があると分かりました。

「黙っている」には2種類ある

AI社員が整理したのは、こんな話でした。

「異常がないから黙っている場合と、係そのものが動いていないから黙っている場合は、外から見ると同じです」

確かにその通りです。

たとえば毎週月曜日に動くドメイン期限チェック。

正常なら何もメールを送りません。

では、何らかの原因でcronの設定が消えていたらどうなるか。

月曜日になっても動きません。

でもメールは来ません。

人間側から見れば、

「今週も問題なしだったんだな」

と見えます。

実際には、チェックそのものが一度も行われていないのにです。

もっと怖いのは、Pythonプログラムの途中でエラーが出るケースです。

動き始めた。

途中で止まった。

メールは送られなかった。

これも人間から見ると「無音」です。

つまり、

「メールが来なかった」という事実だけでは、正常と停止を区別できない。

自動化する仕事が増えたことで、新しい確認作業が生まれていたわけです。

自動化したのに「ちゃんと動いた？」を人間が確認するのはおかしい

ここで一番避けたいのは、

「毎週、cronが動いているかサーバーへログインして確認する」

という運用です。

それでは、自動化した意味がかなり薄くなります。

毎週月曜にドメイン期限チェック。

毎週水曜にリンク切れチェック。

毎週金曜に締切ウォッチ。

毎月1日に月次レポート。

これらについて、

「今週もちゃんと動いたかな」

と人間が一つずつ見回り始めたら、また新しい定例作業が増えます。

そこで今回、

自動処理が正常に終わったこと自体を、別の仕組みに監視させる

ことにしました。

Uptime Kumaにあった「Push監視」を使う

使ったのは、第9話からサイト監視に使っているUptime Kumaです。

Uptime Kumaには通常のURL監視だけでなく、

Push

という監視方式があります。

普通のサイト監視は、

Uptime Kuma側から、

「サイトは生きていますか？」

と確認しに行きます。

Push監視は逆です。

監視される側から、

「今、正常に仕事が終わりました」

という合図を送ります。

そして、決められた時間内に次の合図が来なければ、

「この処理、止まっているかもしれない」

とUptime Kumaが異常にします。

要するに、

係が仕事を終えるたびに点呼を返す仕組み

です。

5つの仕事のうち、4つの定期処理に点呼を付ける

現在のVPSには5つの仕事があります。

ただし、今回Push監視を付けるのは4つです。

サイト監視係はUptime Kumaそのものなので、今回点呼を返す対象にはしません。

対象にしたのは、

• 第2係：ドメイン期限チェック
• 第3係：月次稼働率レポート
• 第4係：リンク切れチェック
• 第5係：締切ウォッチ

の4つです。

まずUptime Kumaの管理画面でPush監視を追加します。

監視タイプを「Push」にし、

分かりやすい名前を付けます。

Push監視を作ると、それぞれ専用のURLが発行されます。

このURLへアクセスすると、

「この係は今、正常に終わりました」

という点呼になります。

なお、このURLは外部に公開する必要のない固有情報なので、記事画像ではモザイクしています。

週次の係は「約7日以内に点呼が来るか」を見る

ドメイン期限チェックは毎週月曜日。

リンク切れチェックは毎週水曜日。

締切ウォッチは毎週金曜日。

これらについては、

約1週間に1回、必ず成功報告が来る

はずです。

そこでPush監視側にも、それに合わせた監視間隔を設定しました。

画面では630,000秒。

約7.3日です。

毎週ちょうど同じ時刻に実行されるので、少しだけ余裕を持たせています。

7日間ぴったりにしてしまうと、

サーバーの負荷や実行開始のわずかなズレだけで警告になる可能性があります。

「来るべき頃を少し過ぎても来なければ異常」

くらいにしておく方が実運用では使いやすそうです。

点呼URLをプログラムの中には書かなかった

今回の実装で気に入っているところがあります。

4つのPythonプログラムそのものは、ほとんど触っていません。

点呼の処理をプログラム内部へ追加する方法もあります。

でもAI社員が選んだのは、

cronの実行行の最後へ点呼処理を追加する

方法でした。

考え方は、

仕事を実行 && 成功したら点呼

です。

この&&がポイントです。

Linuxでは、

左側の処理が正常終了した場合だけ、右側を実行する

という意味になります。

つまり、

Pythonプログラムが最後まで正常に終わる。

そのときだけUptime Kumaへ点呼を送る。

途中でエラーになった場合は、

点呼を送らない。

結果として、

• cron自体が動かなかった
• Pythonが途中でエラー終了した

どちらの場合でも、

次の点呼が来ない

という同じ形で気づけます。

定時実行の予約表に「点呼」を追加

実際のcron設定にも、各処理の後ろへPush通知を追加しました。

記事画像では、内部パスとPush監視用URLはすべて隠しています。

見えているのは実行時刻だけです。

第2係。

第3係。

第4係。

第5係。

それぞれが自分の仕事を終えたあと、

「終わりました」

とUptime Kumaへ返す形です。

プログラム本体を大きく変更せず、定時実行の出口へ点呼を付ける。

すでに動いている仕組みに後から追加する方法として、かなりシンプルでした。

第14話で扉を閉めたこととも両立した

実は、この作業の直前に第14話のセキュリティ改善を行っています。

Uptime Kumaの3001番ポートをインターネットへ直接公開するのをやめ、

サーバー内部からしかアクセスできない状態へ変更しました。

管理画面を見るときだけSSHの暗号化経路を通します。

では今回のPush監視はどうなるのか。

答えは、

まったく問題ありません。

点呼を送る4つの係と、Uptime Kumaは同じVPSの中にいます。

外のインターネットを通ってUptime Kumaへ接続する必要がありません。

サーバー内部から、

localhost

で連絡できます。

むしろ、

外側の扉を閉じたまま、内側だけで点呼を取れる

状態です。

第14話の戸締まりと、今回の内部監視がきれいにつながりました。

月次レポートだけは、そのまま設定できなかった

ここまでかなり順調でした。

ところが第3係の月次稼働率レポートで、一度止まりました。

この係は毎月1日にしか実行しません。

月によって間隔は28日、30日、31日です。

そこで、

32日くらい点呼が来なければ異常

という設定にしようとしました。

32日は秒にすると、

2,764,800秒です。

ところがUptime Kumaへ入力すると、エラーになりました。

表示されたのは、

「値は2073600以下にする必要があります。」

というメッセージです。

2,073,600秒。

約24日です。

つまりPush監視の間隔として、約1か月をそのまま指定できません。

道具の限界に合わせて、役割を2つに分けた

ここで、

「では月次レポートだけ監視できない」

で終わらず、AI社員が設計を変えました。

月次レポートについては、

「月次レポートが成功したか」

と、

「少なくとも仕組み自体が生きているか」

を分けることにしました。

月次レポートそのものは、毎月1日にメールが届きます。

そのメールが届くこと自体が、本番処理の成功確認になります。

一方、Uptime KumaのPush監視へは、

毎週月曜日に「生きています」という点呼だけ送る

別のcron行を追加しました。

これなら、24日という上限を超えません。

つまり第3係だけは、

• 毎週：生存確認
• 毎月1日：本来の月次レポート

という二段構えです。

一つの監視機能へ無理やり要件を合わせるのではなく、

道具ができる範囲に仕事を分解する。

第13話でもCloudflareとVPSを使い分けましたが、今回も似た考え方になりました。

最初に4人へ手動で点呼を送ってみた

設定が終わったところで、4つのPush監視へ手動で点呼を送ってみます。

第2係。

第3係。

第4係。

第5係。

結果は、

4つともOK。

本番の実行日を待たなくても、

「Uptime Kumaまで点呼が届く」

ところまでは先に確認できます。

あとは、それぞれのcronが予定どおり動けば、その後は自動です。

ダッシュボードの「正常」が26から30へ増えた

Uptime Kumaのダッシュボードへ戻ります。

すると、上部の統計表示が変わっていました。

これまでは、

正常26。

監視中の26サイトです。

今回4つのPush監視を追加したことで、

正常30。

になりました。

一覧の上には、

• 第5係 締切ウォッチ
• 第4係 リンク切れチェック
• 第3係 月次稼働率レポート
• 第2係 ドメイン期限チェック

が並んでいます。

その下に、これまで監視してきたサイト群。

つまりUptime Kumaは今、

外の26サイトと、サーバー内部で働く4つの定期処理の両方を見張っている

状態です。

「正常30」は少し意味が違う数字になった

同じ緑色の「正常」でも、今回追加した4つはサイトではありません。

Webサイトが表示できる。

それを確認する監視と、

定期処理が予定どおり成功報告を返している

ことを確認する監視。

2種類が同じ画面に並びました。

これは結構便利です。

Uptime Kumaを見れば、

「Webサイトは大丈夫か」

だけでなく、

「裏で動かしている自動化も生きているか」

まで一度に分かります。

自動化する仕事が増えるほど、こういう一覧性は効いてきそうです。

では、Uptime Kuma自身が死んだら誰が気づく？

ここまでやると、当然次の疑問が出ます。

「Uptime Kuma自身やVPSそのものが止まったら？」

同じVPSの中にある仕組みなので、Uptime Kumaが完全に止まれば、4人からの点呼を受け取る側も止まります。

サーバーごと落ちれば、締切ウォッチも動きません。

ここは同じサーバーの中だけでは完結できません。

ただ、現在第5係の締切ウォッチは、

毎週金曜の朝、該当が0件でも必ずメールを送る

設計です。

金曜日に毎週届くはずのメールが来なければ、

人間側から、

「VPS側で何か起きていないか？」

と気づくきっかけになります。

完全自動の外部監視ではありません。

一番外側には、まだ人がいます。

今の構成を整理すると、

• サイトが落ちる → Uptime Kumaが気づく
• cronや自動処理が止まる → Push点呼が途絶えてUptime Kumaが気づく
• VPSやUptime Kumaごと止まる → 毎週届くはずのメールが来ないことを人が見る

という三段階です。

最後の一段だけは人間。

それくらいが今の規模にはちょうどいいと思っています。

「異常時だけ通知」の弱点を、一段上の監視で補った

これまで、

正常なら黙る

という設計を何度も使ってきました。

この考え方自体は変えません。

毎日「正常でした」という通知が来れば、結局読まなくなるからです。

ただし今回分かったのは、

無音設計には、生存確認を別に持たせる必要がある

ということです。

人間へは正常通知を送らない。

その代わり、機械同士では、

「今日も動いた」

を確認し合う。

そして、その確認が途絶えたときだけ人間へ知らせる。

これなら受信箱を増やさず、監視の穴だけを埋められます。

自動化すると「確認作業が増える」という逆説

AI社員と自動化を進めていると、不思議なことがあります。

人間の作業を減らすために仕組みを作る。

仕組みが増える。

すると、

その仕組みが正常に動いているか確認する仕事

が増えます。

サイト監視係を作った。

ドメイン期限チェック係を作った。

リンク切れ係を作った。

締切ウォッチを作った。

そのたびに、

「これ、今週ちゃんと動いた？」

という問いが増えていく。

これを人間が確認し始めると、自動化の恩恵が少しずつ減ってしまいます。

そこで今回、

仕組みの確認も仕組みに任せる

ところまで進めました。

自動化の次に来るのは、

自動化の監視

なのかもしれません。

プログラムを直さず「外側」から監視できたのも良かった

今回もう一つ気に入っているのが、

4つのPythonプログラムへ大きな修正を入れなかったことです。

自動化が増えるたびに、

「監視機能を追加するために各プログラムを書き換える」

となると、影響範囲が広がります。

既に正常に動いているコードは、できればあまり触りたくありません。

今回はcron側で、

正常終了したら点呼

を追加しただけです。

監視する仕組みを、

仕事本体の外側へ後付けできた

ことになります。

今後別の定期処理を追加するときも、同じ型が使えます。

新しい係を作る。

cronへ登録する。

最後にPush点呼を付ける。

この形が、VPSでの標準手順になりそうです。

今回の追加費用は0円

今回も、新しいサービス契約はありません。

Push監視は、すでに使っているUptime Kumaの機能です。

VPSも既存。

メール通知も既存。

そのため、

追加固定費は0円。

作業時間は約30分でした。

5人の仕事を自動化したあと、

そのうち定期実行する4つへ点呼を付ける。

それだけで、

「動いているはず」から「動いたことを確認できる」

状態へ変わりました。

今回の結論

今回のテーマは、

「見張り番は、誰が見張るのか」

でした。

答えは、

見張り番同士に、点呼を返させる。

です。

自動化した4つの定期処理は、

仕事が正常に終わるたびにUptime Kumaへ報告。

報告が途絶えたら異常。

人間へは、その異常だけが届きます。

第9話ではサイトを見張り始めました。

第10話以降、VPSへ仕事を増やしました。

第14話では、育ったサーバーの戸締まりを見直しました。

そして第15話では、

中で働いている仕組みそのものを見張る仕組み

まで追加しました。

サーバーを一台借りたところから始まった実験ですが、少しずつ「会社の小さな業務基盤」らしくなってきています。

あなたの会社の自動化、本当に動いていますか

自動処理は、

一度作るとつい、

「あとは勝手に動いているだろう」

と思ってしまいます。

でも、

• バックアップ
• 定期メール
• データ取得
• サイト監視
• バッチ処理
• レポート作成

など、定期実行している仕組みほど、

止まっても人が気づきにくい

ものがあります。

「異常メールが来ていないから大丈夫」ではなく、

正常に動いたことをどう確認するか

まで考えておく。

今回の点呼は、そのための小さな仕組みです。

オフィスピコッツでは、ホームページやサーバーの運営について、

「今どんな仕組みが動いているのか分からない」

「自動化したものが本当に動いているか不安」

という段階からの整理も行っています。

• 運営サポート：https://pikoz.net/unei-support/
• AIレスキュー：https://pikoz.net/ai-rescue/
• ネット顧問：https://pikoz.net/komon/
• AI社員実践記：https://pikoz.net/category/ai-jissen/

AI社員実践記は、まだ続きます。