AI導入2026-05-31

【第7部】定期実行で動くAIエージェントを運用する

株式会社Atsumell|7分で読めます

# 【第7部】定期実行で動くAIエージェントを運用する

> 連載「Slack AIエージェント基盤を作る」全8部の第7部。

第6部までで、AIエージェントは文脈を持って仕事を続けられるようになる。すると、人間が毎回呼ばなくても動いてほしくなる。第7部では、未返信の確認、失敗ジョブの再確認、週次調査のような定期実行を扱う。呼ばれたら答えるBotから、状況を見に行く運用者へ変える回だ。

前後で読む

前回: 第6部記憶を設計する
次回: 第8部安全性と観測性を固める

Slack AIエージェントは、人間がメンションしたときだけ動くものだと思われがちだ。だが、実務で効いてくるのは「人が忘れたころに動く」場面だ。未返信の確認、期限が近いタスクの拾い上げ、定例前の資料準備、週次の再調査、失敗ジョブの再確認。

こうした仕事は、人間が毎回思い出して頼むより、定期実行でAIエージェントが見に行くほうが向いている。

この基盤では、Slackからの依頼だけでなく、ハートビート的な定期実行を前提にしている。決まった間隔で状態を見に行き、必要なときだけSlackへ通知する。AIエージェントを「呼ばれたら答えるBot」から「状況を見に行く運用者」へ近づける設計だ。

定期実行で動くAIエージェントが担う仕事

定期実行に向く仕事には共通点がある。頻度は高いが、毎回の判断はそこまで重くない。放置すると抜け漏れになる。人間がやると単調で忘れやすい。

たとえば次のようなものだ。

Slackスレッドの未完了依頼を確認する
実行中ジョブが止まっていないか見る
期限が近いフォローアップを通知する
定例前に関連情報をまとめる
週次で公開情報を再調査する
失敗したジョブを再試行候補へ入れる
長期記憶の更新候補を整理する

ここで大切なのは、定期実行で何でも自動実行しないことだ。AIエージェントが判断して通知するものと、人間の承認を挟むものを分ける。破壊的な操作、外部送信、費用が大きい処理は、定期実行から直接走らせないほうがよい。

ハートビートは単なるcronではない

定期実行と聞くとcronを思い浮かべるかもしれない。もちろんスケジューラーは必要だが、AIエージェントの運用ではそれだけでは足りない。

ハートビートには、次の役割がある。

今見るべき対象を選ぶ
前回の実行結果を参照する
通知すべき変化だけを抽出する
同じ通知を繰り返さない
失敗時に再実行するか判断する
Slackへ出す文面を短く整える

単純に毎時すべてを確認すると、Slackが通知だらけになる。逆に通知を絞りすぎると、重要な変化に気づけない。ハートビートは、頻度、対象、通知条件、抑制条件をセットで設計する必要がある。

Slack通知は「行動できる短さ」にする

定期実行の通知でよくある失敗は、ログをそのままSlackへ流すことだ。長文の通知は読まれない。

Slackへ出すべきなのは、次の行動が分かる短い情報だ。

何が起きたか
どの対象か
どれくらい急ぐか
何を押せばよいか
詳細はどこにあるか

Slack Bolt for JavaScriptを使えば、メッセージやボタン付きUIを組み立てられる。ただし、UIを増やしすぎると運用が重くなる。最初は短い通知と詳細リンク、必要な確認ボタンだけで十分だ。

記憶と定期実行をつなぐ

定期実行は、AIエージェントの記憶と相性がよい。

たとえば「毎週この競合情報を見ておく」「この顧客への返信は翌営業日に確認する」「このプロジェクトでは金曜に未完了タスクをまとめる」といったルールは、長期ナレッジやユーザー設定として持てる。

ただし、記憶に入れたルールをそのまま実行するのは危ない。保存時にスコープを付ける。誰の依頼か、どのチャンネルで有効か、いつまで有効か、外部送信を含むか。これを持たせることで、定期実行が勝手に広がるのを防げる。

OpenAIのコード生成ガイドでも、AIに任せる作業では制約と評価が欠かせない。定期実行では、制約がさらに強く要る。人間がその場で見ていないタイミングで動くからだ。

失敗を前提にした運用

定期実行のAIエージェントは、必ず失敗する。対象のページが変わる、権限が切れる、Slack APIの制限に当たる、モデルの出力が期待と違う。だから、失敗時の設計を先に作る。

失敗理由を分類する
再試行してよい失敗と止める失敗を分ける
同じ失敗を何度も通知しない
人間が引き取る条件を決める
次回実行時に前回失敗を参照する

失敗を隠すと、AIエージェントは信用されなくなる。失敗を短く、具体的に、次の手と一緒に返すと、運用の一部として受け入れられる。

定期実行は通知量ではなく判断品質を見る

Heartbeatを入れると、AIが勝手に働いているように見える。だが、実際の運用品質は通知の数では測れない。むしろ通知が多いほど読まれなくなる。見るべきなのは、必要な変化だけを拾えているか、同じ失敗を繰り返していないか、人間の判断が必要なところで止まれているかだ。

この基盤では、scheduled task、idle queue、outcome event、watchdog、self-checkを分けて扱う。scheduled taskは決まった観察。idle queueは低優先度処理。outcome eventは判断の振り返り。watchdogは停止検知。self-checkは依存部品の確認。役割を分けることで、自律運用をログの洪水にしない。

定期実行を入れるなら、最初に通知抑制キー、承認境界、失敗時の再試行回数を決める。スケジュール時刻はその後でよい。

Heartbeatは「毎時実行するcron」ではない

定期実行をcronで始めるのは簡単だ。だが、AIエージェントの運用では、ただ時間で起動するだけでは足りない。Heartbeatは、前回状態、未完了タスク、Slack活動、記憶更新候補、KPI変化を見て、今やるべきことだけを選ぶ小さな運用ループとして作る。

この流れにすると、AIエージェントは「決まった時刻に全部見る」のではなく、「見るべきものだけを見る」ようになる。通知疲れを防ぐには、この選別が必要だ。

idle queueで低優先度タスクを処理する

Slackからの依頼はリアルタイム性が高い。一方で、競合調査の再確認、未完了タスクの棚卸し、古い記憶のrollup、成果物リンク切れ確認のような仕事は、すぐに返す必要がない。こうした処理はidle queueへ回す。

idle queueには、優先度、実行期限、再試行回数、通知抑制キーを持たせる。

{
  "taskId": "idle_...",
  "kind": "followup_check",
  "priority": "low",
  "notBefore": "2026-05-31T12:00:00.000Z",
  "dedupeKey": "masked-thread:followup",
  "maxRetries": 2,
  "notifyPolicy": "only-on-change"
}

通知抑制キーがないと、同じ未完了タスクを毎回Slackへ出してしまう。AIエージェントの定期実行で嫌われるのは、失敗よりもノイズだ。変化があるときだけ知らせる、同じ失敗はまとめる、人間が取れる行動を添える。この3つが運用の品質を決める。

Heartbeatにも安全境界を置く

人間が呼んでいないタイミングで動くからこそ、Heartbeatは権限を絞る必要がある。読み取り、要約、候補作成、内部通知までは自動化してよい。一方、外部送信、削除、契約、請求、公開反映、PR mergeのような操作は承認待ちにする。

この境界を設けると、AIエージェントは「勝手に動く怖いもの」ではなく「必要なタイミングで気づかせる運用補助」になる。エンタープライズで定期実行を入れるなら、スケジューラーより先に承認境界を設計するべきだ。

OODAとoutcomeをログで学習する

Heartbeatは、定期実行のたびに「実行した」というログだけを残すのでは弱い。何を予測し、何を実行し、結果が当たったのか外れたのかを残すと、次回の判断に使える。

{
  "type": "outcome.recorded",
  "agent": "corporate",
  "taskId": "scheduled_...",
  "prediction": "返信漏れが発生している可能性",
  "action": "Slack threadを確認して短く通知",
  "hitMiss": "hit",
  "reason": "ユーザーが通知後に対応した"
}

この粒度のeventをJSONLで残しておくと、あとからjqや簡単な集計で、通知が役に立っているか、silentが多すぎないか、同じタスクを反復していないかを見られる。

watchdogとself-checkを分ける

自律運用では、AIが動いていることをAI自身にだけ確認させない。watchdogはheartbeatの鮮度を見る。self-checkはLLM、memory、Slack、GitHub、worker poolなどの可用性を見る。役割が違う。

watchdogは「最近heartbeatが成功しているか」を見る。self-checkは「依存部品がまだ使えるか」を見る。どちらもSlackへ毎回投稿する必要はないが、停止検知や致命的な依存不全は通知する。

これがあると、定期実行は単なる便利機能ではなく、運用対象になる。AIエージェントを本番に置くなら、AIの判断力だけでなく、AIを監視する仕組みも必要になる。

連載「Slack AIエージェント基盤を作る」

あわせて読みたい既存記事

#AIエージェント#定期実行#自律運用#Slack連携#フォローアップ

AIエージェントの定期実行を業務に組み込みませんか？

Atsumellは監視、通知、低優先度キュー、停止検知まで含めて、自律運用の設計を支援できます。

相談する