5月6日のCode w/ ClaudeでAnthropicがManaged Agentsに追加したWebhooks機能は、Outcomesとの組み合わせで「夜間バッチに置いて朝に結果通知だけ受け取る」という運用パターンを現実的にした。これまでPCの前でAgentの完了を待つ時間が地味に効いていた開発者にとって、見た目以上に効く改善だ。本稿ではイベント種別の整理と、Slack通知エンドポイントを組むまでの実装時間を実機ベースで記録する。
Webhookイベント種別の細かさが運用設計を変える
Webhook側で発火するイベント種別は公式ドキュメントに細かく載っており、Managed Agentsの状態遷移をかなり粒度高く拾えるようになっている。
session.status_run_started
session.status_idled
session.status_rescheduled
session.status_terminated
session.thread_created
session.thread_idled
session.thread_terminated
session.outcome_evaluation_ended今回の運用で主役になるのは最後の session.outcome_evaluation_ended だ。Outcomes評価が完了したタイミングで発火するので、SlackやDiscordへの完了通知フックをこのイベントに掛けるだけで、夜間ジョブの結果を朝イチで確認できる体制が組める。
筆者の使い方は単純で、Outcomesでrubricを書く→夜間にAgentを走らせる→翌朝、評価結果と一緒にSlackへ通知、という構成だ。睡眠時間が増えたというほど大げさではないが、PCの前でAgentの完了を待つ時間は確実に減った。
Slack通知エンドポイントを組むまでの所要時間
最初の組み立てにかかった時間を計測しておいた。後発でセットアップする人の見積もり材料として残しておく。
| ステップ | 所要時間(初回) |
|---|---|
| Outcomesのrubricを書く | 17分 |
| Webhook受信側エンドポイント実装 | 21分 |
| Slack Block Kit化と整形 | 14分 |
| 接続検証(ステージング) | 9分 |
合計で1時間ちょい。初回の組み立てとしてはかなり軽い部類だ。2回目以降はエンドポイントの使い回しでrubricを足すだけになるので、1タスクあたり10分程度で増設できるようになる。
Webhook payloadには評価のスコアと、不合格時の指摘事項がそのまま乗ってくる。これをSlackのBlock Kitに整形して流すと、レビュアーが朝イチでスマホからでも状況把握できる形になる。深夜にメンションが飛ばないよう、Slackの通知設定側で時間帯フィルタを掛けておくと、運用がさらに静かになる。
「Agentの完了を待つ」運用からの脱却
これまでManaged Agentsを長時間タスクで使う際、もっとも厄介だったのは「終わったかどうか分からないから、結局たまにブラウザを開いて状況確認する」という見えないコストだった。マルチタスクの集中が削られるという意味で、実時間以上に効いていた。
Webhooksでこのコストがほぼゼロになる。Agentが終わるとSlackに通知が来る、ということが運用上保証されるので、それまでは別のタスクに集中していられる。コンテキストスイッチが減ることのほうが、実は時間短縮そのものより効果が大きい。
ベータ機能ではあるものの、エンドポイント側の実装は標準的なHTTP Webhookと変わらない。既存のSlack通知基盤を持っているチームであれば、流用で組み込めるはずだ。
推奨する次の一手
実装観点で次に試す価値があると感じているのは、以下の3点だ。
- ステージング環境にWebhook受信エンドポイントを置き、
session.outcome_evaluation_endedを購読 - Slack Block Kitでrubricの不合格項目を整形表示するテンプレートを1つ作る
- 夜間バッチで回したいタスクのrubricを1本書いて、翌朝の通知到達まで通しで検証
ここまで通せば、以降は新規タスクのrubricを足すだけで運用が拡張できる構造になる。Outcomes・Webhooksともにベータの間に運用パターンを固めておくと、GA化のタイミングで本番ジョブをそのまま移せる。Managed Agentsを「PoCで触ったきり」になっているチームほど、Webhooks起点で運用設計を組み直す価値があると感じている。
