Grafanaのo11y-benchで実践する、AIエージェント評価の自動化設計

• 事実と背景：Grafana LabsがAIエージェント評価基盤の設計思想とオープンソースの「o11y-bench」を公開。
• 技術的変革：最終応答の成否だけでなく、実行プロセスを決定的なチェックとLLMによるルーブリック評価の2軸で検証。
• 現場への影響：開発者はプロンプト変更によるデグレを検知可能になり、AI予算の浪費やシャドーAIの暴走を防ぐ盾となる。

深夜2時、本番環境でアラートが鳴り響く。オンコールのエンジニアがAIエージェントに「エラー率急増の原因を調べてダッシュボードを作ってくれ」と指示を投げる。数秒後、AIは「ダッシュボードを作成しました。キャッシュ更新の遅延が原因です」と、もっともらしいグラフを添えて完璧な日本語で回答を返してきた。しかし、そのグラフの裏側にあるPromQLクエリを覗き見て、背筋が凍る。AIが叩いていたのは、全く関係のないテスト環境のメトリクスだったのだ。

これが、Grafana LabsのYasir Ekinci氏が指摘する「最も難しい失敗は、表面上もっともらしく見えるものである」という事態の生々しい現実だ。AIエージェントは、間違ったクエリに基づいているにもかかわらず、さも正しいかのような美しいパネルを描画してしまう。この「もっともらしい嘘」は、従来のソフトウェアテストにおける単純なアサーション（期待値の一致）では絶対に検知できない。なぜなら、出力されるHTMLやマークアップ、自然言語のテキストは「完璧に見える」からだ。さらに、LLMの非決定的な性質により、同じプロンプトを投げても毎回異なるアプローチを取るため、テストコードは容易に「無限ループ」や「偽陽性」の罠に陥る。

DatadogのCPOが指摘するように、多くの企業で「数カ月で消えるAI予算」や「シャドーAIの脅威」が深刻な問題となっている。その本質は、AIエージェントが裏で何を実行しているか不透明であり、かつその品質を客観的に評価する術を持たないため、実戦投入した瞬間に信頼を失い、プロジェクトが頓挫することにある。我々エンジニアが直面しているのは、この「ブラックボックス化したAIの振る舞い」をいかにしてオブザーバビリティ（可観測性）の網に捉えるかという、極めて泥臭い闘いなのだ。

プロンプトを1行書き換えただけで、昨日まで動いていたAIの機能がデッドロックを起こしたように沈黙する。そんなスパゲッティコードのようなプロンプト管理に終止符を打つため、Grafana Assistant開発チームが提示したのが「シナリオ（仕様）」と「エージェント（実装）」、そして「グレーダー（評価器）」の完全な分離である。この思想を具現化したオープンソースのベンチマークツールが「o11y-bench」だ。o11y-benchでは、プロンプトの中に評価基準を埋め込むのをやめ、YAML形式の独立した「シナリオ」として定義する。

例えば、キャッシュ遅延のピークを調べるタスク（promql-cache-refresh-lag-peak）では、ユーザーの依頼（statement）と、評価基準（rubric）、そして正解を導き出すためのクエリ（fact）が明確に分離されている。ここで重要なのは、評価方法の「二面性」だ。o11y-benchは、評価対象の性質に応じて、決定的なチェックと、LLM-as-a-judge（ルーブリック評価）を厳密に使い分けている。

決定的なチェックは、APIから取得したダッシュボードのJSONスキーマや、実行されたクエリの構文木を直接検証する。これは100%再現可能で、実行コストもかからない。一方で、「原因となったサービスを正しく特定できているか」といった高次の意味的判断には、LLMに明確な「ルーブリック（評価基準）」を与えて判定させる。「この回答は良いか？」とLLMに1回で尋ねるような曖昧な評価は、ノイズを増やすだけで百害あって一利もない。基準を「原因の特定」「具体的な数値の提示」「事実への立脚」といった項目に分解し、それぞれに合否を判定させることで、初めてプロンプトやモデルの変更に対する「デグレ（退行）」を定量的に検知できるようになる。

Grafanaチームが実施した、175のシナリオを各3回実行したプロンプト改修の評価結果は、我々エンジニアに冷酷なトレードオフを突きつける。彼らはプロンプトのサイズを削減し、構造を整理することで、トークン消費量とコストを大幅に下げることに成功した。一見、大勝利のアップデートに見える。しかし、能力の区分（Capability）ごとに合格率を可視化したところ、恐るべき事実が判明した。

「discover（データ探索）」は92.3%から94.9%へ、「safety（安全な操作）」は88.9%から93.1%へと向上した。しかし、肝心の「dashboard（ダッシュボード作成）」の合格率は100%から83.3%へと急落し、「observe（状態監視）」も93.6%から79.5%へと大幅にデグレしていたのだ。もし、全タスクを合算した「平均合格率」だけを見ていたら、あるいはコスト削減の数値だけを見ていたら、この致命的なデグレに気づかないまま本番環境にデプロイし、ユーザーからのクレームの嵐に直面していただろう。

国内でも、株式会社ラクスが「伝票作成AIエージェント」の構築において、品質を支える評価設計に並々ならぬリソースを割いている。彼らもまた、AIエージェントの出力が業務要件を満たしているかを多角的に評価する独自の仕組みを構築している。AWSが「Amazon CloudWatch Omni」を発表し、監視の世界にもAIが深く統合されつつある今、我々が構築すべきは「AIを監視するためのAI評価ループ」である。AIが改善案を提案し、ベンチマークがそれを検証し、最終的な採用は人間が決定する。この「Evaluate（評価）」「Learn（学習）」「Change（変更）」のループを回し続けることだけが、AI予算をドブに捨てず、本番環境でAIを実用化するための唯一の道なのだ。

しかし、この評価ループを構築したからといって、我々は永遠の安息を得られるわけではない。むしろ、新たな「終わりのない運用保守」の始まりである。ソフトウェア開発における「脆いテスト（Flaky Test）」の悪夢を思い出してほしい。テスト対象のコードは何も変わっていないのに、ネットワークの揺らぎや環境の差分でCIが赤くなる。AIエージェントの評価環境では、この問題がさらに増幅されて牙をむく。

時間の経過とともに、評価対象の環境（GrafanaやPrometheusのデータ）は変化し、シナリオは古び、グレーダーの判定基準はずれていく。モデルのAPI仕様変更によって、昨日まで動いていたLLM-as-a-judgeが突然狂い始めることもある。「シナリオとグレーダーは、YAMLを眺めているだけでは保守できない」とEkinci氏が警告するように、我々はグレーダーの劣化を防ぐために、実際の実行ログ（トランスクリプト）やトレースを泥臭く分析し続けなければならない。

ここで我々は、業界への痛烈な問いに直面する。「AIによって開発や運用の効率化を目指した結果、我々はそれ以上のリソースを『AIの評価と監視システムの保守』に奪われるのではないか？」

この問いに対する実践的な処方箋は、最初から巨大なベンチマークを作ろうとしないことだ。o11y-benchが示すように、まずは現実のワークフローを模した「小さく、具体的で、1件から得られる情報量が多い」5つ程度のシナリオから始めるべきだ。そして、評価コードをプロダクトコードと同等の「ファーストクラスオブジェクト」として扱い、CI/CDパイプラインに組み込むこと。AIエージェントの品質を担保する責任をAI自身に丸投げせず、我々エンジニアがその「評価の番人」としてコードを書き続ける覚悟を持つこと。それこそが、AI時代を生き抜くシニアエンジニアに求められる真のスキルセットなのだ。