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 の発表 を参照してください。