【AI社員実践記 第20話】自動化は作って終わりじゃない　時差・誤検知・沈黙の3つを整えた

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

第9話から、1台のVPSを使って自社の監視・定期処理の仕組みを少しずつ育ててきました。

サイトの生存を確認する係。

ドメイン期限を見張る係。

月次稼働率をまとめる係。

リンク切れを探す係。

補助金の締切を確認する係。

保守状況をWebサイトへ表示する係。

いまでは複数の自動処理が、毎日・毎週それぞれのタイミングで動いています。

人間が毎回確認しなくても機械が仕事をしてくれる。

かなり便利になりました。

ところが今週、その監視・自動化する側の仕組みで、小さな事故が2つ見つかりました。

今回は新しいものを作る話ではありません。

すでに動いている自動化の「ズレ」を直した話です。

結果として、

• 実行時刻のズレ
• リンク切れの誤検知
• 自動処理が黙って止まる問題

の3つを見直しました。

人間が実際に手を動かした時間は、約15分でした。

火曜日の夕方に「水曜3時」のメールが届いた

最初に違和感を持ったのは、リンク切れチェック係から届いたメールでした。

この係は、毎週サイト内を巡回して、

• 404になっているリンク
• 画像切れ
• 存在しないURL

などを探します。

実行予定は、

毎週水曜日の朝3時。

訪問者がほとんどいない深夜に動かし、朝になれば結果が届いている。

そういう設計にしていました。

ところが今回、メールが届いたのは、

火曜日の18時ごろ。

まだ水曜日になっていません。

手動で実行した覚えもありません。

「なんで今？」

というところから調査が始まりました。

原因は、UTCと日本時間を取り違えたcron設定

AI社員と一緒にcronの設定を確認しました。

cronは、

何曜日の何時何分に、このプログラムを動かす

という予約表です。

ここで気をつけなければならないのが、サーバーのタイムゾーンです。

日本時間とUTCには9時間の差があります。

今回のサーバーは、日本時間で動く設定でした。

ところがcronには、

「水曜3時をUTCへ直すと火曜18時」

と考えて、

火曜18時

を登録していました。

サーバー側は日本時間です。

当然、書かれた通りに、

火曜18時に実行。

何も故障していません。

cronはむしろ正確に仕事をしています。

間違っていたのは、人間側の時刻指定でした。

時差のミスは、逆方向でも起きる

少し前には、別の定期処理でも逆方向の時差ミスを経験しました。

日本時間のつもりで設定した時刻がUTCとして扱われ、9時間ズレる。

今回は逆に、

UTCへ換算した時刻を、日本時間のサーバーへ書いてしまった。

時差の事故は、どちら向きにも起きます。

ここでAI社員と一つルールを決めました。

cronを新しく設定したら、設定画面だけを見て「完成」としない。

必ず、

初回に実際何時に動いたかを見る。

設定値を何度読んでも、思い込みが同じなら間違いには気づきません。

実際の動作時刻だけが答えを教えてくれます。

もう一つ。「リンク切れ4件」のメールも届いていた

時刻がずれて届いたメールには、もう一つ気になる内容がありました。

リンク切れ 4件。

4件もある。

これは直さないといけません。

第11話では、本当に404になっているリンクを5件見つけ、その日のうちに修正しました。

今回も同じような問題だと思い、1件ずつ確認します。

ところが、ブラウザで開いてみると、

4件とも正常に表示されました。

本当のリンク切れは、

0件。

今度はリンクチェック係の方に問題がありました。

3件は「人には見せるが、ロボットには404を返す」リンク

4件のうち3件は、決済サービスの短縮URLでした。

人間がChromeなどのブラウザから開くと、

正常に決済ページへ移動します。

ところが、リンクチェッカーのような機械的アクセスでは、

404 Not Found

を返します。

ロボット対策などのため、アクセス方法によってレスポンスを変えているようです。

リンクチェッカーから見れば、

「404なのでリンク切れ」

です。

判定自体は間違っていません。

でも、人間が実際に利用すると正常に開きます。

つまり今回必要だったのは、

チェック機能を直すことではなく、「この相手は検査しなくていい」と教えること

でした。

残り1件は、記事の中に書いた「サンプルURL」

もう1件は、さらに単純でした。

記事本文の中で説明用に使っていた、

架空のサンプルURL

です。

「たとえばこのURLの場合……」

という説明のために書いているだけなので、実在しません。

当然アクセスすれば404になります。

リンクチェッカーは、

それが説明用の文字列なのか、本物のリンクなのかまでは判断できません。

こちらも、

本当のリンク切れではありません。

今回4件検出されたのに、修正が必要なリンクは0件でした。

誤検知は「失敗」ではなく、除外リストを育てる材料

そこで今回、リンクチェッカーに除外リストを追加しました。

今後チェックしなくていい、

• 特定サービスのドメイン
• サンプル用途など、意図的に確認対象から外すURL

を登録できます。

ここでAI社員と決めたのは、

最初から完璧な除外リストを作ろうとしない

ことです。

世の中のどのサービスが、機械アクセスに404を返すか。

事前に全部知ることはできません。

なので、

1. リンクチェッカーが検出する
2. 人間がブラウザで1分確認する
3. 本当に切れていれば修正
4. 正常なら除外リストへ追加

という運用にしました。

誤検知が1件出るたびに、

チェック係が少し賢くなる。

そのくらいに考える方がよさそうです。

今回はまず、確認できた2つのドメインを除外対象へ追加しました。

完璧な自動化より「育てられる自動化」

これは、AIを使った仕組みづくり全般にも言えそうです。

最初から、

誤検知ゼロ。例外ゼロ。完全自動。

を目指すと、設計がどんどん複雑になります。

しかも、本番へ出して初めて分かる例外は必ずあります。

今回の決済サービスのように、

人間には普通に見えるけれど、機械には違う答えを返す。

こういうものを事前に全部想定するのは難しい。

それなら、

一度動かす。
結果を見る。
例外を1つずつ覚えさせる。

という方が、実務では早いことがあります。

第17話でも、「東京都」に「京都」が含まれているため地域判定を誤る問題を、テストで見つけました。

今回も同じです。

実際に動かすことで、机上では見えなかった例外が出てきました。

ここまで直したら、もう一つ怖くなった

時刻を修正。

誤検知も整理。

これでリンク切れチェック係はかなり安定しました。

ただ、ここまでやると別の疑問が出ます。

「この係そのものが、ある日黙って止まったら？」

今回は、変な時間にメールが来たから異常に気づきました。

では、

cronが消えた。

Pythonが途中でエラーになった。

サーバー内の何かが変わった。

そしてメールが来なくなった。

その場合、人間側から見るとどうなるでしょう。

「今週はリンク切れがなかった」

と、

「リンクチェック自体が動かなかった」

は、どちらもメールが来ません。

見た目は同じです。

「異常なし」と「働いていない」は、どちらも沈黙

これは第15話で一度考えた問題です。

正常時に毎回、

「今日も正常でした」

というメールを送ると、通知が増えすぎます。

だから基本設計は、

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

ただし、そうすると、

無音＝正常

とは限りません。

無音＝停止

かもしれない。

そこで導入しているのが、

点呼

です。

各自動処理は、仕事が正常に終わるとUptime Kumaへ、

「今日も終わりました」

という合図を返します。

決められた時間までにその合図が来なければ、

Uptime Kuma側が異常として扱います。

人間の受信箱へ正常メールを増やさず、

機械同士だけで生存確認をする仕組みです。

第19話で作った「Web暖簾」にも点呼を追加

今回は、もう一つ動いている処理にも点呼を追加しました。

第19話で作った、

Web暖簾の最終点検日を更新する処理

です。

この処理は毎朝7時50分に動きます。

Uptime Kumaでサイトが正常なことを確認し、

Cloudflareへ最終点検日を送る仕組みです。

これまで処理自体の点呼はありませんでした。

そこでUptime Kumaへ、

「badge-push点呼」

を追加しました。

24時間以内に点呼が来る設定です。

毎朝の処理が正常に終われば、点呼を返します。

もし処理が止まり、翌日になっても点呼がなければ、

「この係、返事がありません」

と分かります。

監視の仕組みを、

さらに別の監視で確認する。

少し大げさに聞こえますが、追加した処理はごく小さいものです。

cronもまとめて見直した

今回の修正をきっかけに、VPS内のcron設定もまとめて確認しました。

ドメイン期限チェック。

月次稼働率。

リンク切れ。

締切ウォッチ。

各種点呼。

スナップショット。

差分チェック。

Web暖簾の日付更新。

定期処理が増えてくると、

「この時刻、本当にこれで合っている？」

を人間の記憶だけで管理するのは難しくなってきます。

リンク切れチェックについては、

0 3 * * 3

へ修正。

毎週水曜日の朝3時です。

Web暖簾の処理は、

毎朝7時50分。

その末尾には点呼も追加しました。

ここまでで、今回の設定変更は終了です。

ただし、その場では「完了」と言わない

今回、少し意識を変えたところがあります。

設定を書き換えた。

cron一覧にも正しい時刻が表示されている。

点呼も追加した。

以前なら、

「修正完了」

としていたかもしれません。

でも、時差の事故を経験した直後です。

今回は、

設定完了と、動作確認完了を分ける

ことにしました。

Web暖簾の点呼は、

翌朝7時50分に本当に返ってくるか。

リンク切れチェックは、

来週水曜3時に本当に動くか。

そこまで確認して、初めて完全に終了です。

設定表が正しいことより、

実際にその時刻に動いたこと

を最終確認にする。

今回の時差ミスから決めた、新しい運用ルールです。

人間が手を動かした時間は約15分

今回やったことを整理すると、大きく3つです。

1. 時刻の修正
   リンク切れチェックを毎週水曜3時へ修正
2. 誤検知の除外
   人間には正常に開くリンクやサンプルURLを除外できる仕組みを追加
3. 点呼の追加
   Web暖簾の日次処理にも生存確認を追加

AI社員には事前に、

「この行の、この部分を、こう変える」

という作業手順を一本にまとめてもらいました。

私はVPSへ接続。

指示に沿って修正。

設定画面を見せる。

AI社員に確認してもらう。

人間が実際に操作していた時間は、合計15分ほどです。

大きな作り直しはありません。

今ある仕組みを、運用しながら少しずつ直しています。

自動化には3つの罠がある

今回の出来事を整理すると、自動化には少なくとも3つの罠があると感じました。

1. 時刻の罠

UTCと日本時間。

どちらで設定しているのかを間違えると、処理自体は正常でも実行時刻がズレます。

対策は、初回の実動作時刻を見ること。

2. 誤検知の罠

機械はルール通りに判定します。

でも、404だからといって人間にとって本当に壊れているとは限りません。

対策は、人間が一度確認し、例外を除外リストへ覚えさせること。

3. 沈黙の罠

異常がなければメールしない。

でも処理自体が止まってもメールしません。

対策は、正常終了したことを機械同士で点呼すること。

どれも大規模なシステム変更は必要ありませんでした。

数分の確認。

設定1行。

小さな除外リスト。

それだけです。

自動化は「作った瞬間」が完成ではない

AI社員と作業を始めたころは、

プログラムが動いた。

メールが届いた。

画面に表示された。

そこまで行けば、

「完成」

だと思っていました。

最近は少し違います。

一週間使う。

本番データが来る。

例外が出る。

時刻のズレに気づく。

誤検知を経験する。

それを直す。

また動かす。

運用されて初めて、仕組みが仕事に合わせて育っていく。

AIが短時間でコードを書けるようになったからこそ、

「最初に完璧なものを作る」

より、

早く小さく動かし、実際の結果から直す

方が合っている場面も増えている気がします。

「壊れない自動化」ではなく「ズレに気づける自動化」

今回、自動化そのものが完全に壊れたわけではありません。

リンクチェック係は動いていました。

メールも送っていました。

リンクも確認していました。

でも、

時間がズレていた。

ノイズが4件混ざった。

別の処理には点呼が付いていなかった。

つまり、

大きく壊れる前の小さなズレ

です。

こういうズレを放置すると、

「通知は来るけど信用できない」

「いつ動いているのか分からない」

「本当に毎回実行されているのか不安」

という状態になります。

自動化の価値が少しずつ下がります。

だから目指すのは、

絶対に壊れない自動化

ではなく、

ズレたときに気づける自動化

なのかもしれません。

今回の追加費用は0円

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

VPSは既存。

Uptime Kumaも既存。

リンクチェッカーも既存。

点呼も既存の仕組みです。

そのため、

追加固定費は0円。

必要だったのは、

運用中に出てきた違和感を拾い、

少しだけ設定を育てることでした。

今回の結論

これまでのAI社員実践記では、

「こんな自動化を作った」

という話を何度も書いてきました。

第20話では初めて、

自動化の側で起きた小さな事故と、その立て直し

が中心になりました。

AIを使えば、仕組みはかなり短時間で作れます。

でも、

作った仕組みは、放っておけば静かにズレることがあります。

時刻がズレる。

誤検知が混ざる。

黙って止まる。

だから、

作る力と同じくらい、「ズレに気づく仕組み」を持つことが大切。

今回の15分は、新しい機能を増やした時間ではありません。

今まで作ってきた自動化を、

もう少し安心して放っておける状態にする時間

でした。

AI社員実践記も20話。

最初は「AIに何ができるか」を試していた連載でしたが、

だんだん、

AIと作った仕組みをどう運用し、どう育てるか

の話になってきました。

それもまた、実際に使い続けているからこそ出てきた変化なのだと思います。

自動化した仕事、本当に今も動いていますか

バックアップ。

定期メール。

データ取得。

監視。

レポート作成。

AIで作ったバッチ処理。

一度設定すると、

「勝手に動いているはず」

になりやすいものです。

でも、

動いているはずと、動いたことを確認できる状態は別です。

オフィスピコッツでは、AIを使った自動化だけでなく、

今ある仕組みの確認・整理・見守りについてもご相談いただけます。

• 無料セルフ診断 ai-check https://pikoz.net/ai-check/
• AI見守りプラン・AIレスキュー https://pikoz.net/ai-rescue/
• ネット顧問 https://pikoz.net/komon/
• AI社員実践記 https://pikoz.net/category/ai-jissen/

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