共有された記録がなければ、AIによるインシデント管理は破綻する
AIエージェントがインシデント対応の領域に参入しています。
LangChain、PagerDuty、New Relicといった企業は、SREエージェントを構築しています。これらのツールはトレースを読み取り、ログを抽出し、アップデートのドラフトを作成できます。それらは迅速に動作し、優れたコンテキストを提供します。
しかし、落とし穴があります。
多くのチームは、AIのコンテキストを自分たちだけの「メモ帳」のように扱っています。根本原因の特定といった緩和作業にはAIを利用しますが、調整作業（コーディネーション）を忘れてしまうのです。
インシデント管理は、単に原因を見つけることではありません。それは「調整」です。人々が以下の事項について合意形成を図ることなのです：
- 何が起きたのか。
- 何が変わったのか。
- 何を除外したのか。
- 次のステップの担当者は誰か。
- ビジネス側が何を把握すべきか。
もしこれらの情報がプライベートなチャットやエージェントのメモの中に留まってしまうなら、プロセスは失敗します。
有用なAIインシデント記録は、単なるチャットログではありません。それは構造化された「運用オブジェクト」であるべきです。以下の内容を含める必要があります：
- トリガー（アラート、サービス、重要度）。
- エビデンス（トレース、ログ、メトリクス、最近のデプロイ）。
- 仮説（何が起きていると考えているか、およびその理由）。
- 棄却された理論（原因ではないと証明されたこと）。
- 決定と承認（なぜロールバックを選択したのか、あるいは待機することにしたのか）。
この構造は、AIにありがちな失敗を防ぎます。エージェントは「重力の井戸（gravity well）」のようになることがあります。もっともらしい原因を見つけると、そこに固執してしまいます。そして、その一つの理論を裏付けるために、すべての新しいデータを解釈しようとしてしまうのです。
共有された構造化された記録は、チームに「反証となるエビデンス」に目を向けさせます。これにより、エージェントのバイアスを抑制できます。
対応者に必要なのは、さらなるノイズではありません。「共有された状態（shared state）」です。新しいメンバーがインシデントに加わったとき、Slackを5分間も遡って探し回るようなことがあってはなりません。現在の仮説、エビデンス、そして保留中のアクションを即座に把握できるべきです。
目指すべきは、派手なデモを見せる自律型レスポンダーではありません。組織知（institutional knowledge）を残せるツールです。
最も賢いモデルを探すのはやめましょう。構造化された記録の構築を始めましょう。
- インシデントのための明確なフィールドを定義する。
- エージェントがこの記録を安全に読み書きできるようにする。
- データだけでなく、決定事項を記録するようにする。
- インシデントの混乱を、再利用可能な知識へと変えるために記録を活用する。
最良のAIツールとは、人間のチームを「一つの組織」として動かせるツールのことです。
Optional learning community: https://t.me/GyaanSetuAi