【ITニュース解説】OpsMind: Building an AI Incident Response Agent That Learns From Every Production Incident

システム運用において、予期せぬトラブル、つまり「インシデント」が発生することは避けられない。しかし、同じようなインシデントが二度目に発生した時、初回と同じようにゼロから調査をやり直すのは、時間の無駄であり、システム設計上の失敗とも言える。今回解説する「OpsMind」は、この課題を解決するために開発されたAIインシデント対応エージェントだ。

OpsMindの基本的な考え方はこうだ。インシデント対応システムは、目の前の障害を分析するだけでなく、組織がその障害から何を学んだかを記憶し、次に同様のトラブルが発生した際にその経験を活用すべきである。

これまでの多くのインシデント対応ツールは、現在システムで何が起こっているかを詳細に教えてくれる点では非常に優れていた。例えば、システム応答の遅延、エラー発生率、CPUやメモリの使用状況、データベース接続数、過去のデプロイ履歴、システムログ、処理の追跡情報、そして各種アラートなど、多くの情報を確認できる。しかし、「以前にも同じような状況があったか？その時私たちは何を学び、どう解決したのか？」という問いに答えるのは非常に難しかった。この重要な知識は、インシデント後に作成される報告書（ポストモーテム）、社内のチケットシステム、標準的な手順書（ランブック）、チャットツールでのやり取り、監視ダッシュボード、そして何よりも実際にその場に居合わせたエンジニアの頭の中に分散してしまっていたからだ。

OpsMindは、このような過去の経験をインシデントの一部として捉え、積極的に活用するワークフローを構築している。インシデントが発生すると、まず現在のシステムの状態を示すデータや、最近のデプロイ（システムへの新しい変更の導入）の状況を収集する。次に、「Hindsight Recall」という機能を使って、過去の経験を検索し、現在の状況と類似点がないかを確認する。その結果に基づいて、システムは問題解決のための調査ステップを推奨する。エンジニアはその推奨内容を確認し、問題解決のための具体的なアクションを承認・実行する。インシデントが解決し、その結果が検証されたら、OpsMindは「Hindsight Retain」という機能を使って、その解決プロセスとそこから得られた教訓を組織の知識として記憶する。この「解決策が再利用可能な知識として保存され、次のインシデントに活かされる」という最後の2つのステップが、単なるインシデントアシスタントとOpsMindを区別する重要な点だ。

OpsMindのシステムは、ユーザーインターフェース（フロントエンド）と、インシデント対応のワークフローを管理する部分（バックエンド）に分かれている。フロントエンドは、インシデントの一覧表示、システムの状態を示すデータの可視化、調査結果、過去の記憶の探索、学んだことのイベント、手順書、ポストモーテムなどを担当する。一方、バックエンドはインシデントの一連のワークフロー全体を制御する。

特に重要な設計判断の一つに、「Hindsight」と呼ばれる記憶システムを、アプリケーションの他の部分から独立したサービスとして切り離している点がある。これにより、インシデントのオーケストレーション（全体の調整）を担う部分は、記憶システムが具体的にどのように過去の情報を検索・取得するのかを知る必要がない。この分離は、インシデントの記憶システムが、通常のアプリケーションの状態管理とは異なる要件を持つため重要だ。例えば、記憶システムの構成や検索方法、エラー時の再試行ポリシーなどを変更したい場合でも、インシデントワークフロー全体のコードを書き直す必要がない。

OpsMindが記憶する内容は、単なるインシデント発生時のチャット履歴のアーカイブではない。インシデント中のチャットには、何百ものメッセージが含まれることがあり、その多くは推測や一時的な会話だ。これらの会話全体を保存しても、将来のインシデント対応者にとって本当に役立つ経験になるとは限らない。

そこでOpsMindは、別のエンジニアが本当に知っておくべきこと、つまり「何が起こったか」「どのサービスが影響を受けたか」「具体的な症状」「関連するデプロイバージョン」「疑われた根本原因」「試行されたアクション」「失敗したアクション」「成功したアクション」「そして最終的な教訓」といった、検証済みの成果や教訓を構造化された情報として記憶する。これは、エンジニアがデバッグ中に37回メッセージをやり取りしたことよりも、3つのことが試され、2つが失敗し、1つが成功し、最終的に根本原因が特定された、という事実こそが、組織の有用な知識単位だと考えるからだ。

OpsMindの真価は「二度目のインシデント」で発揮される。例えば、ある決済APIで初めてインシデント（INC-104）が発生したとする。システム応答の遅延が4.8秒、HTTP 5xxエラー率が18%、データベース接続プール使用率が96%と高まり、デプロイバージョンv4.2.1が関与していることがわかる。調査の結果、デプロイに起因するデータベース接続リークが原因だと判明し、インスタンスの再起動やレプリカの増強は効果がなく、デプロイのロールバックで解決した。OpsMindはこの解決とそこから得られた教訓を、検証済みの結果として記憶する。

6週間後、再び決済APIで似たようなパターンを示すインシデント（INC-137）が発生した。P99遅延が5.1秒、HTTP 5xxエラー率が16%、データベース接続が94%という状況だ。ただし、今回のデプロイバージョンはv4.2.3であり、前回のv4.2.1とは異なる。この時、OpsMindは単純に前回の修正を繰り返すことはしない。代わりに、組織の記憶を検索し、「決済サービスに関わる、遅延、5xxエラー、データベース接続の枯渇、デプロイ関連の不具合を伴う過去のインシデントを探す」といったクエリを実行する。

この検索結果により、AIエージェントは過去の参照点を得る。すると、問いは「何が原因だろうか？」から、「過去の障害パターンとこのインシデントで一致する部分とそうでない部分は何か？」へと変わる。この区別は非常に重要だ。過去のインシデントは、データベース接続の枯渇とデプロイの変更が調査に値すること、そして過去にはレプリカのスケールアップが効果がなかったことを教えてくれる。しかし、現在のリリースはv4.2.3であり、v4.2.1ではないため、OpsMindの推奨は「過去のロールバックを直ちに適用する前に、現在のデプロイにおける接続ライフサイクルの変更を調査する」といった、より状況に合わせたものになる。これが、過去の経験を再利用しつつも、盲目的に模倣しない、OpsMindが目指す振る舞いだ。

Hindsightの記憶機能がサービス境界の背後に置かれているのは、いくつか理由がある。一つは、外部の専門サービス（VectorizeのHindsight）を利用しているため、その設定情報（APIキーやURLなど）をアプリケーションのコア部分から分離できる点だ。また、検索（Recall）、記録（Retain）、推論（Reflect）という記憶に関する主要な操作を一箇所に集約できる。さらに、Hindsightの接続状態が監視可能になるという運用上の利点もある。OpsMindは、記憶システムが正常に接続されているか、最後にいつ過去の検索や記録が行われたかといったステータスを表示できるため、エンジニアは推奨事項が実際に最新の組織の記憶に基づいているのか、あるいは機能が劣化している状態から来ているのかを明確に判断できる。

OpsMindは、AIエージェントに本番環境への変更を自動的に行わせることはしない。エージェントは、現在のシステム信号の分析、過去のインシデントの検索、類似点と相違点の特定、調査ステップの提案、そしてその推奨の根拠説明を行うまでだ。最終的に本番環境で何を実行するかは、エンジニアが決定する。この役割分担は、システムが提示する調査結果のデータモデルにも反映されており、単なる「このコマンドを実行せよ」という指示ではなく、推奨されるアクション、その根拠、自信度、過去の一致、そして推論の過程が明確に示される。インシデント対応において、なぜその推奨がなされたのかを説明できることは、単なる見た目の機能ではなく、信頼性に関わる重要な要素である。

OpsMindのユーザーインターフェースは、チャットウィンドウが中心ではなく、インシデント調査のための専用のワークスペースが主軸となる。エンジニアは、現在のインシデントの状況や重要度、リアルタイムのシステムデータ、デプロイのタイミング、調査結果、過去の記憶との一致、過去に失敗したアクション、推奨される次のステップ、その根拠、最終的な解決策、そして解決後に記憶される学習内容などを一元的に確認できる。また、「Memory Explorer」という専用の機能もあり、システムが何を記憶しているかをエンジニア自身が確認できるようになっている。記憶システムが単なる見えないブラックボックスになってしまわないように、透明性が確保されているのだ。インシデントが解決され、そこから学んだことが記憶されると、それは「組織の記憶イベント」として登録され、次の調査時に検索可能になる。これにより「インシデント発生 → 調査 → 解決 → 学習」という循環が、過去の経験の検索（Hindsight Recall）を介して可視化される。

このシステムを構築する中で、いくつかの重要な教訓が得られた。まず、有用な記憶の単位はインシデント全体よりも、「何が起こり、何を試み、何が失敗し、何が成功し、どのような条件下だったか」という、検証された教訓のようなより小さな単位であるということだ。次に、過去のインシデントとの類似性が高いことは、そのインシデントを詳細に調査する理由にはなるが、必ずしも過去の解決策をそのまま繰り返す許可ではない、という点。だからこそ、二度目のインシデントでは、デプロイバージョンや現在のシステムデータを過去の記憶と綿密に比較する。記憶は、調査の範囲を絞り込むものであって、エンジニアの判断を不要にするものではないのだ。さらに、成功した修正だけでなく、失敗に終わった試みも同等に重要な知識であることもわかった。もし、あるエンジニアがデータベース接続リークの問題に対してポッドの再起動が効果がないと学んだのなら、次のエンジニアが深夜2時に同じことを再発見する必要はないはずだ。最後に、記憶は監視可能なライフサイクルを持つべきだ。いつ記憶が検索され、何が取得され、いつ新しい知識が保存されたのかを知りたい。信頼できない記憶は、活用が難しい。

そして、このシステムの最大のテストは「二度目のインシデント」だった。最初のインシデントでは、エージェントがシステムデータを分析できることを示せるかもしれない。しかし、関連する二度目のインシデントで、システムが本当に過去から学んだかどうかを試すことができる。「組織が既に解決済みの種類の問題に対して、次の調査の振る舞いは変化するか？」この問いに「No」と答えるなら、永続的な記憶機能は単なる飾りになってしまうだろう。

OpsMindの今後の展望としては、現在のアーキテクチャを基盤に、実際の監視システムや運用システムをインシデントワークフローに直接接続していくことが考えられる。単に「もっと多くの記憶」を追加するのではなく、システムの状態を示す詳細なデータ（メトリクスやトレース）、デプロイシステム、インシデント管理プラットフォーム、手順書、ポストモーテムのリポジトリ、サービス所有者の情報、変更履歴など、多岐にわたる情報源との連携を深めることだ。そして、記憶のライフサイクルをさらに厳密にし、検証された成果は出所、条件、自信度とともに記憶し、矛盾する記憶や古くなった記憶は沈黙させずに浮上させるようにする。

OpsMindが目指す最終目標は、全てを記憶するエージェントを作ることではない。重要な運用経験を記憶し、必要なときにそれを正確に検索し、組織が既にコストを払って学んだ間違いをエンジニアが繰り返すことを避ける手助けをするエージェントを作ることだ。まさに、その能力を「二度目のインシデント」で証明したかったのである。