自律的なAIエージェントがSREチームの手動インシデント調査を置き換える方法。
オンコールのエンジニアが午前3時に呼び出される。
彼らはノートパソコンを開く。PagerDutyを確認する。CloudWatchを開く。kubectlに切り替える。Grafanaを開く。GitHubのデプロイ履歴を確認する。
この出来事が前回起きたときの状況をSlackで検索する。
45分後、彼らは根本原因を突き止めた：最新のデプロイで環境変数が誤って設定されており、データベース接続文字列を壊していた。
調査自体がボトルネックだった。修正そのものではない。
これはほとんどのSREチームの現実だ。そしてそれはエージェント主導のインシデント管理が解決するために作られた問題である。
それでは、エージェント主導のインシデント管理とは正確には何なのか？
エージェント主導のインシデント管理は、自治的なAIエージェントが人間の逐次指示なしでインシデントを調査・診断・解決を支援するアプローチです。
事前に定義されたスクリプトに従う従来のランブック自動化とは異なり、エージェント主導のシステムは大規模言語モデル（LLMs）を用いて、どのツールを使い、どのデータを集め、どのように所見を統合して実用的な根本原因分析へと導くかを動的に決定します。
キーワードは自律です。AIは指示を待たず、調査します。
現在使われているものとの違い
現在のほとんどのインシデント管理ツール — Rootly、FireHydrant、incident.io — はワークフロー自動化に焦点を当てています。彼らが優れている点は以下のとおりです：
- インシデント発生時にSlackチャンネルを作成する
- 適切なオンコールエンジニアへページ通知を送る
- 事前定義されたランブックを実行する
- ステータスページの更新を生成する
しかし、それらはインシデントを調査しません。人間がそれを行う必要があるのです。
エージェント主導のインシデント管理は、調査自体を自動化します：
従来のアプローチ：
- 対応: 人間がアラートを受け取り、手動で調査を開始する
- ツールの使用: エンジニアが各システムを手動で照会する
- 知識: オンコール担当者に依存する
- 速度: 初期診断には30〜60分
- 文書化: 解決後に作成される（しばしば数日後）
エージェント主導のアプローチ：
- 対応: ウェブフックによって自動的にトリガーされるAIエージェント
- ツールの使用: エージェントが30以上のツールを動的に選択・連携
- 知識: RAGを介して組織全体のナレッジベースを検索
- 速度: 包括的な分析には数分
- 文書化: 調査時に自動生成されるポストモーテム
実際の仕組み
モニタリングツールがアラートを発したときのワークフローは次のとおりです：
アラート取り込み → PagerDuty、Datadog、Grafana からのウェブフックがAIエージェントをトリガーします。
動的ツール選択 → エージェントはアラートの文脈を評価し、30以上のツールから自律的に選択します — Kubernetesクラスターを照会し、クラウドCLIコマンドを実行し、ログを検索し、最近のデプロイを確認します。
多段階調査 → エージェントは多段階の推論を行います。Kubernetesのポッド状態を確認し、誤設定されたデプロイメントへと問題をたどり、Terraformの状態を調べて検証します。
ナレッジベース検索 → 組織のランブック、過去のポストモーテム、ドキュメントをベクトル検索（RAG）し、関連する過去の文脈を提示します。
根本原因の統合 → 所見を時系列、影響評価、是正提案を含む構造化された根本原因分析へと統合します。
ポストモーテム生成 → 詳細なポストモーテムが自動生成され、Confluenceへエクスポートできます。
これらのステップを人間が開始する必要はありません。
なぜ今、これが重要なのか
手動のインシデント調査を持続可能にしない3つの傾向があります：
アラート疲労は現実です。 SREチームは日々数百のアラートを処理します。
ほとんどはノイズですが、それぞれトリアージが必要です。エージェント主導のシステムはこれを自動的に処理し、人間の判断が必要な場合のみエスカレーションします。
マルチクラウドが標準です。 組織は平均3つ以上のクラウドプロバイダーを利用しています。
AWS、Azure、GCP間のインシデントを手動で関連付けるには、異なるCLI、異なるコンソール、異なる認証を扱う必要があり、スケールしません。
知識は逃げていく。 最も経験豊富なSREが休暇に出ると、その調査知識も連れて行かれます。知識ベースRAGを備えたエージェント主導システムは、常にチームの集合的な専門知識へアクセスできます。
Gartnerによれば、2026年までに企業の30%がITサービスマネジメントにAI支援を取り入れる見込みです。これは2023年の5%未満からの上昇です。
制限点は？
エージェント主導のインシデント管理は強力ですが、万能薬ではありません：
- 複雑な体系的問題 は依然として人間の判断を必要とします — AIエージェントはデータ収集と相関には優れていますが、組織的またはプロセスレベルの根本原因を見逃す可能性があります
- 初期設定 にはクラウドコネクタの設定、ナレッジベースの取り込み、権限の付与が必要
- LLMコスト は調査の深さに応じて増大しますが、ローカルモデルを利用すればこれを緩和できます
- 未成熟なエコシステム — ベストプラクティスはまだ発展途上です
目的はオンコールのエンジニアを置き換えることではなく、彼らに先手を打つことです。人間が午前3時にノートパソコンを開くとき、AIはすでに文脈を収集し、データを相関付け、根本原因を絞り込んでいます。
私たちはオープンソース版を作りました
私たちはAuroraを作りました。インシデント調査ツールは透明で、セルフホスト可能で、無料であるべきだと信じているからです。
AuroraはLangGraphでオーケストレーションされたLLMエージェントを使い、AWS、Azure、GCP、OVH、Scaleway、Kubernetesにまたがるインシデントを調査するオープンソース（Apache 2.0）エージェント主導のインシデント管理プラットフォームです。
他と異なる点：
- オープンソース — AIがあなたのインフラで実行するコードの全行を監査可能
- セルフホスト — あなたのインシデントデータは決して環境を離れません
- 任意のLLM — OpenAI、Anthropic、Google、またはOllama経由のローカルモデル
- 22以上の統合 — PagerDuty、Datadog、Grafana、Slack、GitHub、Confluence
- 無料 — 座席あたりやインシデントあたりの料金はありません
3つのコマンドで始めましょう：
git clone https://github.com/Arvo-AI/aurora.git
cd aurora
make init && make prod-prebuilt
元々公開されたのはhttps://www.arvoai.ca/blog/what-is-agentic-incident-managementです。
