【ITニュース解説】My First 10/10 Was a Lie: How I Tested an SRE Agent Properly

システムエンジニアを目指す皆さんにとって、日々の業務でシステムトラブル（インシデント）が発生した際に、どのように原因を特定し、解決するかは非常に重要な課題だ。近年、こうしたインシデント対応をサポートするAIエージェントが登場しているが、その性能を正しく評価することは簡単ではない。この記事では、あるAIエージェントのテストを通じて、どのようにすればより信頼性の高い評価ができるのかを具体的な例を交えながら解説する。

まず、AIエージェントの最初のテストで、研究者は完璧な10点満点という結果を出した。このエージェントは、過去のインシデントの事後報告書（トラブルの振り返り記録）を記憶しており、その中から関連情報を探し出す仕組みだ。テストでは、10件のインシデントを選び、それらに関する質問を作成して、エージェントが「正しい根本原因を見つけ出すか」「今後同様の問題が起きないための警告を発するか」「関連する過去のインシデントを引用するか」を評価した。結果は全ての項目で満点だった。

しかし、この満点は「うそ」だったと記事は指摘している。なぜなら、テストに使われた10件のインシデントは、まさにエージェントが記憶している事後報告書の中から選ばれたものだったからだ。これは例えるなら、カンニングペーパーに書いてある答えをそのままテストで使うようなものだ。エージェントは、質問された内容とそっくりな過去の記録を記憶の中から「検索」したに過ぎない。つまり、このテストではエージェントが「未知のトラブル」に対して、どれだけ効果的に対応できるかは全く分からなかったのである。単に過去の情報を探し出す能力は確認できたが、本当に役立つかどうかは不明だったのだ。

この反省から、より正確なテスト方法が考案された。その方法は次の通りだ。 一つ目は「データを分ける」ことだ。全てのインシデント記録（合計114件）のうち、104件をエージェントの記憶（知識ベース）として学習させた。そして、残りの10件はエージェントには一切教えず、「未知のインシデント」として確保した。これが本当のテスト対象となる。 二つ目は「症状のみの質問を作成する」ことだ。確保した10件の未知のインシデントについて、そのトラブルの「症状」だけを記述した質問文を作成した。例えば、「ウェブサイトが時々エラーになる」といった具合だ。この質問文には、インシデントの根本原因や事後報告書に書かれているような専門用語は一切含めないように注意した。これは、エージェントが単にキーワードを検索して答えるのを防ぐためだ。 三つ目は「二つの条件で比較する」ことだ。同じ質問文を使って、エージェントに二通りの状況で回答させた。一つは、これまで学習させた104件のインシデントの記憶を「使った」場合。もう一つは、その記憶を「使わない」場合（これを「ベースライン」と呼ぶ）だ。記憶を使わない場合は、エージェントが持っている一般的な知識だけで回答することになる。これにより、記憶があることでどれだけ回答の質が変わるのかを明確に比較できる。 四つ目は「正確な評価基準で採点する」ことだ。エージェントが出した回答を、あらかじめ分かっているインシデントの「真のカテゴリ」（例えば、「データベースの問題」「ネットワークの障害」など）と比較して、正解かどうかを採点した。 五つ目は「全ての出力を保存する」ことだ。テストで得られたエージェントの全ての回答や関連データをファイルに保存し、結果の透明性と再現性を確保した。これにより、後から誰が見ても、なぜそのような評価になったのかが分かるようにした。

この新しい方法でテストした結果は、非常に明確な差を示した。 エージェントが過去のインシデントの記憶を「使った」場合、10件中9件で根本原因を正しく診断できた。さらに、高い確信度で回答し、関連する過去の事例を引用したり、問題が再発しないための警告も発したりした。 一方、記憶を「使わなかった」ベースラインの場合、10件全てにおいて根本原因を完全に正しく診断することはできなかった。そのうち4件は部分的に正しい診断だったが、残りの6件は全くの見当違いな、架空の情報をでっち上げて回答してしまった（これをAIの分野では「ハルシネーション」と呼ぶ）。例えば、実際には実行されていないコマンドの結果を引用したり、存在しないエラーを指摘したりした。記憶がない状態だと、エージェントはコードレベルの具体的な問題（接続漏れ、キャッシュ設定ミスなど）を推測しがちだが、そのほとんどは真実とは異なっていたのだ。

この結果から分かるのは、「ベースライン比較」がいかに重要かということだ。エージェントが9割正解したと聞くと一見素晴らしい結果に思えるが、もしベースラインがなければ、それがエージェントの真の能力によるものなのか、それともたまたま質問が簡単だっただけなのか判断できない。記憶がない状態で全く答えられなかったというベースラインの結果があるからこそ、記憶機能がどれだけエージェントの性能を向上させるのか、その真の価値を理解できるのだ。

ただし、今回の評価にもいくつかの限界があることを忘れてはならない。 まず、テストしたインシデントの数が10件と少なかった。この程度の数では、一つの間違いが全体の結果に大きな影響を与えてしまうため、統計的に厳密な結論を出すのは難しい。 また、インシデントの採点は一人で行われたため、採点者の主観が入り込む可能性もある。 さらに、「正しい根本原因」とは、具体的な出来事の連鎖ではなく、大まかなカテゴリ（例えば「依存関係の飽和」か「設定変更」か）レベルでの一致を指している。 「部分的に正しい」という判断も、どこまでを「部分」とするかは主観的な判断が含まれる。 テストのために確保した「未知のインシデント」であっても、学習データと全く無関係というわけではなく、共通のシステムやベンダーに関連するものであったため、学習データと似たような問題だった可能性もある。 そして、それぞれの質問は一度しか実行されなかったため、エージェントの回答の安定性については確認できていない。 また、今回のテストでは、レート制限により一つの質問に対する回答が得られなかったが、これも失敗としてカウントされた。

これらの限界を踏まえると、より厳密なテストを行うには、もっと多くのインシデントを対象とし、複数回実行して安定性を確認し、複数の評価者による採点を行い、学習データと明確に異なる種類のインシデントを「未知のインシデント」として用意するなどの工夫が必要になるだろう。

今回の経験から得られた重要な教訓は以下の通りだ。 一つ目は、もしテストデータがエージェントの記憶の中にすでに含まれている場合、それは単に情報を「検索する」能力を測っているに過ぎないということだ。本当の評価のためには、エージェントに学習させる前に、テスト用のデータを必ず分けておく必要がある。 二つ目は、常に「ベースライン」を設定して比較を行うことだ。比較対象がないスコアは、その真の意味を理解するのが難しい。エージェントの機能を無効にした状態での結果と比較することで、その機能がどれだけ価値があるかを判断できる。 三つ目は、質問文はインシデントの「症状」だけを記述し、根本原因に関する言葉を使わないようにすることだ。これにより、エージェントが単なるキーワードマッチングではなく、真に推論する能力を評価できる。 四つ目は、テスト中に発生した「失敗」は、どんな理由であれ必ず失敗として数えることだ。例えば、システム的な問題で回答が得られなかった場合でも、それを「データ欠損」として扱わず、「回答できなかった」という失敗としてカウントすることが重要だ。 五つ目は、テストの全ての生データを保存することだ。これにより、自分の評価結果が客観的で信頼できるものであることを証明し、後から検証できるようにしておくべきだ。

これらの教訓は、AIエージェントだけでなく、あらゆるシステムの性能を評価する上で役立つ基本的な考え方だ。システムエンジニアとして、単に「動く」だけでなく、「期待通りに、かつ信頼性高く機能する」ことをどのように確認するか、という視点を持つことは非常に大切である。