Cognition の Devin が、Auto-Triage というインシデント自動監視・対応機能を発表した。バグやアラート、インシデントを常時監視し、問題が起きたら即座に調査を始め、関連レポートをつなぎ合わせ、場合によっては PR まで開いてくれる。
公式ドキュメント を読むと、Auto-Triage は Devin Automations の一種で、Slack チャネルを24時間監視する永続 Devin として設計されている。バグ・リグレッション・インシデントの報告が入るたびに、人が手動で担当者を割り当てる代わりに Devin が初動を取る、というイメージだ。
どう動くか
仕組みは親子構成になっている。
- 親 Devin が Slack チャネルを常時監視し、新着メッセージをすべて見る
- ノイズを除外し、重複報告を検出する
- 対応が必要なバグと判断したものについて、子 sub-Devin を起動する
- 子 Devin が関連コードを読み、根本原因を追い、Slack スレッドに診断結果を投稿し、適切なコードオーナーにタグ付けする
ランディングページでは Slack、Linear、GitHub、スケジュール、webhook、観測ツール、チケット、アラート、コードベースへの接続が示されているが、ドキュメント上の中心は Slack チャネルへの常時接続 だ。MCP 連携で Datadog や Sentry、Linear などの外部ツールにも触れられる。
セットアップ
ドキュメント上の手順はシンプルだ。
- 監視したい Slack チャネル（
#bugsや#incidentsなど）に Devin を招待する - Automations で Triage bug reports on Slack テンプレートから新規 automation を作成する
- チャネルを選んで保存する
これだけで監視が始まる。Slack 連携は Settings > Integrations > Slack で個人アカウントを接続しておく必要がある。
カスタマイズ
Setup prompt で triage Devin の振る舞いを調整できる。例としてドキュメントには次のような指示が挙げられている。
- 「payments サービスのリグレッションを優先。フロントエンドのバグは UI チームにタグ付けする」
- 「エラーログやスタックトレースが含まれる issue だけ調査する。報告が曖昧なら詳細を求める」
- 「根本原因が分かったら、必ず関連ソースファイルへのリンクを含める」
MCP 連携も推奨されている。Datadog MCP でメトリクス・ログ・トレースを引き、Sentry MCP でエラー詳細や影響ユーザー数を確認、Linear MCP で関連チケットの確認や新規作成、といった使い方が想定されている。Settings > MCP Marketplace で有効化してから automation を設定する流れになる。
scratchpad — 長期記憶の仕組み
Auto-Triage の核心は scratchpad だ。親 monitor とすべての子 sub-Devin が共有する永続メモリで、次の用途がある。
- 最近 triage した項目の追跡（チャネル ID、メッセージタイムスタンプ、報告者）
- コード領域とオーナーの routing table の維持
- 重複項目の記録（将来の報告を既存スレッドにリンクする）
- セッション再起動後も残るコンテキストの保存
親 Devin が主に scratchpad を更新するが、子 Devin も読み書きできる。スレッドで「それは自分の担当じゃない」と返信があった場合、routing table を更新して次回から正しく振り分ける、という学習ループになる。
ランディングページで言われている「インシデントごとに賢くなる」は、この scratchpad を通じた 長期記憶 の話だと読める。
- 過去の調査を記憶する
- 関連レポートを重複排除する
- Slack スレッドやチケットをリンクする
- チームの所有領域をマッピングする
- 繰り返し発生する問題を追跡する
すでに使っているチームもいる
Modal のようなチームは、推論チームのインシデント対応に Devin Auto-Triage をすでに使っている。
Devin Automations は、これまで試した他の auto-triage ツールからの一歩前進のように感じます。それは私たちのチャネルを監視し、私たちのコードベースと観測可能性スタックと連携し、私たちがプロンプトを与えなくても役立つ調査結果を持って戻ってきます。
— Hari Subbaraj, Member of Technical Staff @ Modal
「プロンプトを与えなくても調査結果が返ってくる」という点が、他の auto-triage ツールとの差として強調されている。チャネル監視・コードベース・observability の三点が揃っているからこそ、初動の質が上がる、という評価に読める。
セキュリティと制限
Slack 経由の入力はサポートチケットなど 信頼できないユーザー入力 を含みうるため、ドキュメントでは network policy で outbound アクセスを制限することを検討するよう書かれている。ランディングページでも、Devin と sub-Devin はネットワークサンドボックス化された環境で動き、プロンプトインジェクションやデータ流出への保護がある、と説明されている。
リソース面では、他の automation と同様に ACU 制限 と invocation 制限 がある。親 Devin が起動する子 sub-Devin 1 件ごとにセッションとして ACU 予算が消費される点は、運用前に把握しておきたい。
ドキュメントが推す運用のコツ
- チャネルは絞る — バグ報告専用チャネルから始める。汎用エンジニアリングチャネルだとノイズが増える
- Setup prompt で期待値を明示する — 優先すべき issue と無視してよいものを書いておく
- MCP 連携を入れる — Datadog や Sentry などの runtime データがあると triage 品質が大きく上がる
- routing の誤りをスレッドで訂正する — 間違った人にタグ付けされたら返信で直すと、親 Devin が routing table を更新する
自分の整理
コーディングエージェントの話は「実装を速くする」文脈が多いが、Auto-Triage は 運用・インシデント対応 に寄せた使い方だ。Devin Automations という「長時間動き続ける Devin」に Slack 監視を渡し、見張り・記憶・調査・振り分け を任せる、という位置づけになる。
個人的には、次のあたりが実務で効きそうだと感じた。
- 初動調査の自動化 — 報告が来た瞬間にコードと observability データを横断して状況を整理してくれる
- ノイズ削減 — scratchpad による重複排除で、同じ障害の繰り返し報告を1本のスレッドにまとめられる
- オーナーへの自動ルーティング — 診断結果と合わせて適切な担当者にタグ付けされる
- PR までつながる — ランディングページでは調査後に PR を開くことも示されている
一方で、routing table がどこまでチーム固有の運用に馴染むか、子 sub-Devin の ACU 消費がどの程度になるかは、導入後に見ないとわからない。Modal の事例が示すように、observability スタックとの MCP 連携が前提になるチームほど相性は良さそうだ。
インシデント対応は「起きたあとに誰かが動く」作業が多い。Auto-Triage は、その最初の15分を Devin に任せる発想に近い。詳細は 製品ページ、公式ドキュメント、Cognition の発表 を参照。