AIの定期実行が止まったことに、誰が気づくのか｜Slackだけで作る死活監視

AIエージェントの死活監視とは、無人で定期実行しているAIの処理が「動いたか・止まったか」を人間が気づける形にしておく仕組みです。エラーを拾う仕組みではありません。エラーすら出さずに何も起きなかったことを拾う仕組みです。

わたしたちは社内の定型業務を、AIエージェントによる定期実行に順次移しています。その監視を、監視ツールを新しく買わずにSlackだけで組みました。実際にこの仕組みで業務端末の停止を検知し、原因を特定するところまでいけたので、設計判断をそのまま公開します。

目次

• 1. 課題：AIの失敗より、AIの沈黙のほうが怖い
• 2. 打ち手の全体像：記録する場所・報告する場所・監視する場所を分ける
• 3. 設計の勘所：検知漏れ・誤検知・アラート疲れをどう抑えるか
• 4. 運用サイクル：アラートは人が閉じる
• 5. 実際に効いた場面：業務端末がネットワークから切れた朝
• 6. うまくいかなかったこと
• 7. まとめ

1. 課題：AIの失敗より、AIの沈黙のほうが怖い

AIエージェントに定型業務を任せると、最初のうちは毎日のように実行結果を見に行きます。ところが安定してくると、だんだん見なくなります。当然です。毎日きちんと結果が返ってくるものを、毎日確認する動機は続きません。

こうして「たぶん動いているはず」で回り始めた時点から、次の状態が起こり得ます。

• 端末が再起動して、そのまま起動しなかった
• ログインセッションが切れていて、業務の入口にすら入れなかった
• ネットワークが落ちていて、そもそも何も起動しなかった
• 起動はしたが、途中で条件が揃わず、AIの判断で処理を見送った

ここで「エラー通知を仕込めばいい」と考えると、打ち手を外します。本当の問題は、AIが失敗することではなく、AIが何もしなかったときに何も起きないことでした。

処理が途中で失敗すれば、エラーという形で何かが残ります。しかしそもそも起動しなかった場合、エラーも記録も残りません。残るのは沈黙だけです。そして沈黙は、正常に静かな日と見分けがつきません。実行結果を通知させる設計では、この状態を絶対に検知できません。通知が来ないことが、正常なのか異常なのか判断できないからです。

したがって必要なのは、失敗を拾う仕組みではありません。「動くはずだったのに、動いた形跡がない」を拾う仕組みです。順序としては、まず「いつ何が動くはずか」を正本として書き出し、そのうえで実行の形跡と突き合わせる必要があります。

2. 打ち手の全体像：記録する場所・報告する場所・監視する場所を分ける

構成は単純です。監視のための道具を新しく増やさないことを最優先にしました。使っているのは、すでに社内で使っているSlackと、AIエージェントの定期実行機能だけです。監視用のサーバーもデータベースも、監視SaaSの契約もありません。

要点は、Slackのチャネルを役割ごとに3つに分けたことです。

• 記録専用チャネル：機械が読む場所。各処理が「処理開始」「処理終了」「処理中断」を定型1行で書くだけ
• 人向けの報告チャネル：人が読む場所。実行結果の詳細や承認依頼はこちら
• トラブル集約チャネル：異常だけが集まる場所。ここが静かなら、今日は見るものがない

そして監視エージェントだけを、業務用端末の外に置きました。1時間おきに起動し、スケジュールの正本と記録専用チャネルを突き合わせて、動くはずのものが動いた形跡があるかを判定します。

3. 設計の勘所：検知漏れ・誤検知・アラート疲れをどう抑えるか

勘所1：監視を、監視対象と同じ端末で動かさない

判断：監視エージェントだけをクラウド側の定期実行に置き、業務用端末では動かさないことにしました。

理由：同じ端末で動かすと、端末ごと止まったときに監視も一緒に沈黙します。それは監視として成立していません。監視で最も検知したい事象が、監視が最も検知できない事象になるという構造です。後述する実例は、まさにこのケースでした。

やらなかったこと：業務用端末にもう1つ監視用の常駐処理を置く案は採りませんでした。設定は簡単ですが、上の理由で肝心なときに役に立ちません。

勘所2：ハートビートではなく、予定表と突き合わせる

判断：「生きています」という定期信号を送らせるのではなく、いつ何が動くはずかを書いた正本の表を持ち、実行の記録と突き合わせる方式にしました。

理由：定期信号は「端末が生きているか」しか分かりません。端末が生きていても、特定の処理だけ起動していない状態は日常的に起こります。予定表との突合なら、処理単位で「動くはずだったのに動いていない」を判定できます。

やらなかったこと：端末への死活pingは入れていません。粒度が粗すぎて、異常のほとんどを取りこぼします。

勘所3：機械が読む記録と、人が読む報告を分ける

判断：実行の記録（開始・終了・中断）は専用チャネルへ、実行結果の詳細報告は業務チャネルへ、と投稿先を分けました。

理由：業務チャネルには長文の報告や人間同士の議論が混ざります。そこから監視に必要な行だけを拾わせると、判定が曖昧になります。記録専用チャネルに定型1行だけを流す形にすれば、監視は1つのチャネルの短い行を読むだけで済み、判定がぶれません。

やらなかったこと：業務チャネルをそのまま読ませて、AIに文脈から判断させる案は採りませんでした。一見スマートですが、判定根拠が毎回変わるので、誤検知が起きたときに原因を追えません。

勘所4：状態を「終了」と「中断」に分ける

判断：処理の終わり方を成功・失敗の2種類ではなく、「処理終了」と「処理中断」の2種類に分けました。判断基準は「規定の手順を最後まで規定どおり実行したか」です。

理由：AIエージェントは、条件が揃わないときに自分の判断で一部の手順を見送ることがあります。たとえば承認の根拠が確認できず、外部への送信を中止する、といった動きです。これは事故ではなく望ましい振る舞いですが、規定どおりには実行されていません。ここを「終了」にしてしまうと、記録の上では正常に見え、人間が気づけません。結果が無害でも、規定どおりでなければ中断として記録し、人間の判断を仰ぐ設計にしました。

やらなかったこと：成功・失敗の2値は採りませんでした。実際にこの取りこぼしを経験したためです（後述）。

勘所5：異常がなければ、何も投稿しない

判断：監視の実行結果を毎回投稿するのをやめ、異常を検知したときだけ投稿することにしました。あわせて、投稿の先頭に重要度を3段階（緊急／要対応／参考）で付け、緊急と要対応にだけ通知メンションを付けます。

理由：1時間おきに「正常です」が流れるチャネルは、1週間で誰も見なくなります。そうなると、本当のアラートも一緒に読み飛ばされます。静かであること自体を情報にするほうが、結果的に見てもらえます。

やらなかったこと：正常時のサマリー投稿はしていません。「動いていることを確認したい」欲求は分かりますが、それはアラートの信頼性と引き換えになります。

勘所6：監視には、直す権限を与えない

判断：監視エージェントの権限は読み取りと通知だけに絞りました。業務の再実行も、端末の操作も、正本の書き換えもさせません。Slack側に与えた権限も、履歴の読み取り2つ・投稿1つ・担当者へのダイレクトメッセージ1つの計4つだけです。

理由：自動復旧を持たせると、異常時に何が起きたのかが分からなくなります。原因調査と復旧は人間の仕事に残し、監視は「気づかせる」ことに専念させました。権限を絞ってあること自体が、監視エージェントを安全に常時稼働させられる前提にもなっています。

やらなかったこと：異常を検知したら自動で再実行する、という機能は入れていません。外部への送信を含む処理では、二重送信の事故に直結します。

4. 運用サイクル：アラートは人が閉じる

監視で最も設計が要るのは、実は検知ではなくアラートの閉じ方でした。

監視エージェントは、毎回まっさらな状態で起動します。人間が裏で対応して直したことは、監視からは見えません。そのため人が直した事象を、監視は延々と検知し続けます。

そこで、対応が終わったらアラートのスレッドに「解決済（日時）／対応：誰が何をしたか」と返信する運用にしました。監視は、スレッドに「解決済」があればその事象を再掲しません。逆に、クローズされないまま日をまたいだ事象は、放置防止のために改めて通知します。

ここで意識的に決めたことが2つあります。

• 絵文字リアクションでのクローズは採用しない。実装は楽ですが、監視Botにリアクションを読む権限を追加することになります。権限を絞ってあることを前提に常時稼働を許容しているので、そこは崩したくありませんでした
• 「うるさいから閉じる」を許さない。クローズは「業務として片が付いた」記録なので、対応内容を必ず書きます。後から経緯を追えなくなると、クローズ運用そのものが形骸化します

この運用を続けていて予想外だったのは、監視が「予定表そのものの間違い」を見つけてくれることです。実際に、隔日で動く処理の実行日が表の記載と実態でずれていたこと、通知先の記載が古いままだったことが、突合の過程で見つかっています。これらはアラートとは別に「参考」として通知させ、正本を人間が直す運用にしています。

5. 実際に効いた場面：業務端末がネットワークから切れた朝

2026年8月25日の未明、業務用端末がネットワークから切れました。

症状としては、端末のIPv4アドレスが割り当てられていない状態でした。厄介だったのは、IPv6は生きていたことです。そのためAIエージェント自体は起動しており、端末の画面上は動いているように見えます。しかし、IPv4でしか到達できない外部サービス群には一切つながっていませんでした。Slackもその中に含まれます。

つまりこの朝、業務用端末は「異常を報告する手段そのものを失っていた」ことになります。エラー通知を端末から送る設計だったら、この事故は誰にも届きませんでした。

実際の流れは次のとおりです。

• 深夜3時に動くはずだった処理の記録が、記録専用チャネルに現れなかった
• 端末の外で動いている監視エージェントが、予定時刻から1時間が過ぎても記録がないことを検知した
• 04:43、トラブル集約チャネルへ緊急として通知した（予定時刻から1時間43分後）
• 担当者が朝に通知を確認し、端末のIPアドレスの状態を調べて原因を特定した
• 09:12頃、IPv4アドレスを手動で設定して復旧させた。到達性を確認したうえで、止まっていた処理を再実行した

復旧後、通知内容には「今回の暫定復旧は確認できたが、再発防止の設定確認が必要」という残課題も含めて記録しました。無人実行中にネットワーク設定を変更させない方針にしているため、復旧作業自体は人間がやる前提になっています。

6. うまくいかなかったこと

失敗1：規定外の判断を「正常終了」として記録していた

当初は、処理の終わりを1種類しか記録していませんでした。ある月次処理で、AIが承認の根拠を確認できず、規定にある送付を自分の判断で見送ったことがあります。判断としては正しいのですが、記録の上では通常の処理終了と区別がつかず、監視からは正常に終わったようにしか見えませんでした。ここから「処理中断」を独立した状態として追加しました。監視の設計より先に、記録の語彙を設計すべきだったと反省しています。

失敗2：アラートが鳴り続けた

クローズの仕組みを持たないまま運用を始めたため、人が対応して直した後も同じ事象を検知し続けました。ひどいときは、1つの事象について7日連続で通知が出ています。これはアラート疲れの典型で、放置すると本当の異常まで無視されるようになります。「解決済」の宣言でクローズする運用は、この失敗を受けて後から足したものです。

失敗3：プラットフォームの自動表示を「不審な指示文」と誤検知した

監視エージェントには、Slackの本文をデータとして扱い、本文に紛れ込んだAI宛ての指示に従わないよう指示しています。その一環で不審な文言を検知したら報告させていたのですが、Slackがアプリ経由の投稿に自動で付ける表示を、不審な付加テキストとして2日連続で緊急通知しました。

対策として「一度アラートを上げ、人が調べて正常な仕様だと確かめたもの」だけを良性パターンとして除外リストに登録する運用にしました。ここで大事なのは、憶測で先回りして除外しないことです。先回りすると、本当の異常まで一緒に握りつぶすことになります。

失敗4：ルール変更の移行期に、動いているものを「未開始」と誤検知した

記録の投稿先を業務チャネルから記録専用チャネルへ移す途中、端末側のひな型がまだ古いままの処理がありました。実際には正常に完了していたのに、新しい場所に記録がないため「未開始」と判定されました。監視のルールを変えるときは、記録する側の更新が全部行き渡ってから切り替える必要があります。移行期は、旧い場所も読む互換処理を一時的に入れて逃げました。

7. まとめ

• 無人で動くAIの監視で拾うべきは、失敗ではなく沈黙。エラー通知では「起動しなかった」を検知できない
• 「いつ何が動くはずか」の予定表を正本として持ち、実行の記録と突き合わせる。死活pingでは粒度が粗すぎる
• 監視は、監視対象と同じ端末で動かさない。端末ごと止まったとき、監視も一緒に沈黙する
• 機械が読む記録と、人が読む報告は投稿先を分ける。異常がないときは何も投稿しない
• 検知より難しいのはアラートの閉じ方。人が「解決済」と宣言する運用がないと、通知は読み飛ばされるようになる

この仕組みで新しく調達したものはありません。すでに全員が見ているチャットツールを記録の置き場にすれば、監視は今日から始められます。