【ITニュース解説】Your Next Incident Shouldn’t Start From Zero: Building Recall

システムを運用していると、ウェブサイトの停止やアプリケーションの不具合といった予期せぬ問題、つまりインシデントが発生する。私たちはこれらの問題の原因を速やかに特定し、解決に努める。しかし、一度解決した問題と似た現象が後日再び発生した際、以前どう解決したかを思い出すのは難しいことが多い。過去の記録を探し回ったり、経験者に尋ねたりしても、情報がすぐに見つからず、結局またゼロから調査を始める羽目になることも少なくない。これは、貴重な経験がチーム内に蓄積されていても、それが十分に活用されていない状況だと言える。

この課題を解決するために開発されたのが「Recall」というシステムである。Recallの目標は、過去のインシデント対応で得られた知識や経験を「記憶」として保存し、次に問題が起きたときに、その記憶を素早く引き出して活用できるようにすることだ。具体的には、現在の問題の内容を記述し、それに関連する過去のインシデントを検索して参照できるようにする。過去の文脈と現在の新しい証拠を組み合わせて問題解決を進め、実際にどのような対応を行い、どう解決したのか、あるいは何がうまくいかなかったのかといった教訓も記録として残す。

インシデント調査は、まず現在起きている問題に関する情報から始まる。影響を受けるサービス、環境、深刻度、具体的な症状、関連するログ情報などだ。Recallはこれらの情報を元に、裏側で動くAIプログラム（モデル）に分析を依頼する。AIの診断はあくまで「仮説」として提示される。たとえば、過去のインシデントで「データベースの接続プールが原因だった」とあったとしても、今回の問題も必ずしも同じ原因とは限らない。そのため、AIが提示した原因候補や調査ステップは、エンジニア自身が検証し、本当に正しいのかどうかを確かめる必要がある。Recallは自動でシステムに変更を加えるようなコマンドは実行せず、エンジニアが次に何をすべきかを判断する手助けをする役割を担う。

Recallが過去の記憶を保持するために、二種類のデータ保存システムを使い分けている点も特徴だ。一つは「SQLite」と呼ばれる、個々のインシデント調査の構造化された状態を管理するためのシステムである。インシデントのステータス、更新内容、保存された分析結果、最終的な解決策といった具体的な記録を保持する。アプリケーションが画面に表示したり更新したりする際に利用される。もう一つは「Hindsight」と呼ばれる、過去のインシデント情報を集約し、後から検索できるようにする記憶データベースだ。エンジニアがインシデント調査の中で得られた証拠や最終的な結果を記録すると、Recallはその内容を読みやすい形式の文書としてHindsightに送る。この文書には、症状、実行されたアクション、結果、そこから学んだ教訓などが含まれる。Hindsightに保存される情報には、人間が報告した証拠と、AIが解釈した内容が明確に区別して記録されるため、情報の信頼性が保たれる。例えば、「システムを再起動してみたが効果がなかった」という事実が記録されていれば、次に同様の問題が発生した際に、同じ無駄な試みをせずに済むかもしれない。最終的な解決策だけでなく、うまくいかなかった試みも貴重な情報として保存されるのだ。

Recallには、「記憶あり」と「記憶なし」の分析結果を比較できるユニークな機能がある。これは、現在の証拠だけに基づいてAIが分析した結果と、現在の証拠に加えて過去のインシデントの記憶も参照してAIが分析した結果を、画面上で並べて表示するものだ。これにより、過去の記憶が今回の調査にどのような影響を与えたのかを視覚的に確認できる。記憶があったことで、より具体的なチェック項目が示されたのか、過去に失敗したアプローチが提示されたのか、それとも疑われる原因そのものが変わったのか、あるいは単に役立つ過去の文脈が提供されたのか、といった点を検証できる。常に過去の記憶がより良い答えを導き出すとは限らない。関連する過去の事例がない場合もあるし、AIの応答は完璧ではないため、異なる答えが必ずしも正しいとは言えない。この比較ビューは、AIが提示する情報を盲信するのではなく、その有用性をエンジニアが自ら検証するためのツールである。

AIの応答は常に完璧ではないため、Recallはこの不完全なAIの応答に対処するための工夫も凝らしている。AIモデルから返された診断結果は、まずPydanticというツールを使って、定められた形式に沿っているか、必要な情報がすべて含まれているかといった検証が行われる。また、AIが引用した過去の情報源が、実際に提供された過去のインシデント記録の中に存在するかどうかも確認される。もし検証に失敗したり、参照元が不明な情報が提示されたりした場合は、RecallはAIに修正を要求する。それでも修正ができない場合は、無理に診断結果をでっち上げるのではなく、「診断できませんでした」と正直にその失敗を報告する。AIが提示する内容は「証拠」として扱われ、そのまま「指示」として実行されるわけではない。さらに、システムに変更を加えるような危険なアクションがAIによって提案された場合は、その内容がフラグ付けされ、エンジニアによる詳細なレビューが促される。これらの厳重なチェックは、誤った出力や根拠のない主張を防ぐためのものだが、AIの診断が絶対に正しいことを保証するものではない。最終的な真偽の確認と検証は、インシデント対応を行うエンジニアの責任として残されている。

Recallの開発には、ユーザーインターフェースを構築するReact、スタイリングを行うTailwind CSS、バックエンドを担うFastAPI、AIモデルの推論エンジンであるGroq、先に述べたSQLiteとHindsight、データ検証のPydanticといった技術が使われている。これらはDockerでコンテナ化され、Renderというサービスでデプロイされている。

このプロジェクトを通じて得られた最も重要な教訓は、単に過去のテキスト情報を保存するだけでは「記憶」とは言えない、ということだ。記憶は文脈とともに保存されなければならない。具体的には、どの環境でインシデントが起きたのか、何が実際に観測されたのか、何はあくまで推測に過ぎなかったのか、どのような試みが行われたのか、そして復旧が本当に確認されたのか、といった詳細な情報が不可欠である。また、AIの応答やシステムの動きにおける失敗を隠さずに正直に扱うことも重要だとわかった。AIが提示する「仮説」と、エンジニアが検証し確定した「診断」は明確に異なるものとして区別されるべきだ。そして、システムはエンジニアがAIの提案に疑問を抱いたり、矛盾する証拠を追加したり、必要に応じて調査の方向性を変えたりする余地を常に残しておく必要がある。

Recallはまだプロトタイプの段階だが、今後は繰り返し発生するインシデントシナリオを使ってその有効性を評価したり、過去の履歴がより有用な調査ステップにつながるかを検証したりする予定だ。また、証拠から最終的な解決に至るまでのプロセスをより追跡しやすくしたり、一度クローズしたインシデントが再発した際のワークフローを改善したり、初期の仮説が間違っていた場合にどう対処するかといった点の改善も進められる。

このプロジェクトの根底にある問いはシンプルだ。次にシステムに問題が起きた時、チームがこれまでに積み重ねてきた経験は、どれだけ利用可能で、どれだけ役に立つだろうか。Recallは、その貴重な経験を次の問題解決へと確実に引き継ぎ、チーム全体で成長していくための試みなのである。