エージェントの評価は困難です。そして、オブザーバビリティのタスクを検証することはさらに困難です。

確かに、AIエージェントのコーディング能力やツール利用能力は劇的に、かつ数値化できるほど向上しました。しかし、オブザーバビリティは異なる種類の課題を突きつけます。実際のインシデントにおいて真に困難なのは、単にクエリを書くことではありません。膨大なシグナルから重要なものを選別し、一時のスパイクが単なるノイズか異常の兆候かを見極め、メトリクス・ログ・トレースを紐付けて原因を特定することです。さらに、他のエンジニアが使っているダッシュボードを壊さないよう配慮しながらGrafanaの設定を調整するといった、慎重な判断も求められます。

GrafanaコミュニティがAI活用型オブザーバビリティという新しい世界を探索しやすくするため、私たちはオブザーバビリティワークフローにおいてAIエージェントを評価するためのベンチマークgrafana/o11y-benchをオープンソースとして公開しました。これは、実際のGrafanaスタックに対してエージェントを実行し、Grafana MCPサーバーへのアクセス権を与えた上で、その環境内での一連のタスク実行能力を採点するものです。

o11y-benchは、Terminal Benchの作成者らによってリリースされたオープンソースフレームワークHarborをベースに構築されています。Harborは、特定のタスク群に対してエージェントを評価するための環境を標準化します。私たちが開発したベンチマークは、メトリクス・ログ・トレースのクエリ、インシデント調査、的を絞ったダッシュボードの変更など、実務で実際に重要となるワークフローに焦点を当てています。

なぜオブザーバビリティに独自のベンチマークが必要なのか

オブザーバビリティは、単なる「エージェントによるツールの呼び出し」という単純な問題ではありません。根本原因の調査やダッシュボード作成といったタスクは、膨大な量のメトリクス、ログ、トレース、時間範囲、および保存されたアプリケーション状態の相互作用に依存します。こうした変数の多さが、エージェントが実際に正しく作業を完了したかどうかの判断を難しくさせます。例えば、クエリが構文的に正しくても誤った系列を選択している可能性があり、ダッシュボードが表示されていても保存方法が間違っている可能性があるのです。

現在のAIシステムを適切に評価するには、ベンチマークタスクとシミュレーション環境が現実を反映していなければなりません。o11y-benchは実際のGrafanaスタック上でエージェントを実行し、現代の複雑なオブザーバビリティスタックを模した厳格な基準で評価します。

こうした標準化された測定指標は、Grafanaユーザーにとって大きな意味を持ちます。デモで見栄えが良いだけのエージェントと、実際の現場で本当に信頼できるエージェントを明確に見分けられるようになるからです。オブザーバビリティの世界では、わずかな見落としや些細な間違いが、致命的な判断ミスに繋がることが少なくありません。

タスク、環境、採点ロジック、および結果をオープンソース化することで、私たちはこれが検証可能で再現性があり、議論に対してもオープンであることを望んでいます。また、これらのタスクが次世代モデルのオブザーバビリティ関連スキルの向上に役立つことも期待しています。

オープンソース、オープンなテスト

Harborをベースにしたo11y-benchでは、合成されたメトリクス、ログ、トレースが含まれるGrafana Dockerコンテナと共に、サンドボックス環境でモデルやエージェントを実行できます。以下のタスクを実行するだけで簡単に開始できます。

このコマンドは一つのタスク（query-cpu-metrics）に対してベンチマークを開始し、結果を/jobsフォルダに出力します。そこでエージェントの思考プロセスを確認したり、「評価用のLLM（LLM-as-a-judge）」やヒューリスティックによるスコアリングを見たりすることで、エージェントやモデルのパフォーマンスを把握できます。

o11y-benchの目標は、コミュニティと共に何が可能かを探ることです。まずは主要な基盤モデルを用いたリーダーボードを開始しましたが、エージェントの仕組みやモデル構成の新しい組み合わせ、そしてオブザーバビリティにおけるエージェントの可能性を押し広げるための実験を歓迎します。

o11y-benchがテストするタスク

o11y-benchの最初のパブリックリリースには、さまざまなワークフローにわたる63のタスクが含まれています。

• PrometheusおよびPromQLタスク
• LokiおよびLogQLタスク
• TempoおよびTraceQLタスク
• 多段階のインデント調査
• ダッシュボードの編集および修復タスク

私たちが厳選したタスクは、評価のブレが起きない正確な採点基準を持ちつつ、現場で起こりがちな失敗パターンを再現できるだけの「深み」を備えています。例えば、Prometheusクエリのカテゴリにあるpromql-retry-backlog-triageという課題を例に挙げてみましょう。

「決済インシデントの裏でリトライが蓄積している可能性があります。過去約6時間において、どのサービスが最も高いリトライ/バックログの深さを示しましたか？その値は最大でどれくらいでしたか？また、次に数値が悪かったサービスは、単なる小規模な波及効果に見えますか、それとも同等レベルの主要な問題に見えますか？」

システムに詳しい人間であれば、この問題は比較的単純に見えます。しかし、高度な思考（High-thinking）を行うエージェントやトークン消費の激しいエージェントは、システムに関する情報を集めすぎて停滞し、トークンを浪費した挙げ句タイムアウトしてしまうことが分かりました。一方で、よりフォーカスされたエージェントは、適切なクエリを絞り込み、迅速かつ正確にシステムを診断できました。

高度な思考を行うエージェントも最終的には正解に辿り着くかもしれませんが、o11y-benchに含まれる指標を使えば、単なる「0か1か」の正解だけでなく、コスト、トークン使用量、全体的なパフォーマンスも検証できます。これにより、特定のシナリオにおいてどのエージェントやモデルを採用すべきかという実用的な判断材料が得られます。

オブザーバビリティ作業の検証が難しい理由

エージェントを十分にテストできるタスクを考案することは、評価プロセスの一部の側面に過ぎません。それらのタスクが正確に完了したかを「検証」できる必要があります。

ユーザーがエージェントにレイテンシの調査やエラー率の比較、ダッシュボードの更新を依頼した場合、単に見栄えの良い最終回答が得られるだけでは不十分です。多くのクエリタスクでは、エージェントが見たものと同じスタックに対してリファレンス用のPrometheusやLokiクエリを実行し、その値とモデルが実際に引用した値を比較します。ダッシュボードタスクでは、保存されたGrafanaの状態を検査し、必要に応じてパネルクエリを実行してリファレンスクエリと比較します。

私たちは「結果」から評価を始めます。説明文そのものについてもスコアリングを行いますが、流暢な文章を証拠として扱うのではなく、環境から得られる「検証可能な事実」と組み合わせます。

二つの簡単な例を挙げます：

• モデルが「p95レイテンシは約2.3秒でした」と述べた場合、検証プログラムは同じデータに対してリファレンスクエリを実行し、その数字が実際に裏付けられているかを確認します。
• モデルがダッシュボードを修正したと述べた場合、検証プログラムは保存されたパネルJSONを検査し、期待される変数をバインドしてクエリを実行し、リファレンスクエリの結果と比較します。

私たちの全体的な採点思想は、エージェントが「言ったこと」ではなく、実際に「行ったこと」という真実（Ground truth）を常にチェックすることです。実務において、これは「履歴上では説得力があるように見えるエージェント」と「実際の調査で信頼できるエージェント」の決定的な違いとなります。

信頼性（Pass^3）vs 3回中の成功（Pass@3）の測定

このベンチマークでは、モデルの性能を評価するために二つの主要なスコアを使用しています。

• Pass^3： 一貫性の尺度。3回の実行におけるベンチマークスコアの平均として算出。
• Pass@3： 3回中の成功率。3回の試行のうち、少なくとも1回タスクを解決できたかどうかを示す。

注：各指標にはそれぞれの価値がありますが、どちらが有用かはユースケースによります。本プロジェクトでは「一貫性」を重視しているため、ランキングではPass^3を優先しています。評価手法の詳細については、Anthropicのブログも参照してください。

成功の定義（指標）を変えると、異なるリーダーが登場する点は非常に興味深い事実です。

評価結果

初期リリースでは、29のモデルバリアント、63のタスク（各3回の試行）で、計5,481回のトライアルを実施しました。

Pass^3を主要指標とした結果：

• 思考機能をオフにしたOpus 4.7が首位を獲得。
• 思考機能を「高」に設定したOpus 4.7が2位。興味深いことに、Pass^3（一貫性）は低下したものの、Pass@3（最高スコア）は向上しました。

オープンソースモデルではQwen 3.6 Plusが最高の成績を収め、一部のSonnetやGPTモデルすら上回りました。

主な結論として、トップモデルを分ける真の要因は「信頼性」にあります。多くのモデルが「3回に1回」は正解できますが、一貫して正解できるモデルは極めて稀です。このギャップこそが、私たちが信頼性をメインの評価指標とする理由です。

「一度正解した」ことと「一貫して正解できる」ことは別物です。特に、些細なミスがエンジニアを誤った調査方向へ導いてしまうオブザーバビリティの世界ではなおさらです。平均スコアはタスクや採点プログラムのデバッグには有用ですが、エージェントへの信頼度を測るための主要指標としては適切ではありません。

カテゴリ別の視点で見ると、さらに状況が明確になります。Grafana APIタスクはほぼ飽和状態（高スコア）であり、Prometheusも比較的強力です。TempoとLokiは中位に位置しています。ダッシュボード作成は依然として最も困難な領域です。これは、状態管理、クエリの正確性、変数の配線、保存された挙動などが組み合わさっており、「惜しい」間違いが起きやすいためです。

ここで、Pass@3は「3回のうち少なくとも1回正解した」ことを意味し、完璧なPass^3は「3回とも正解した」ことを意味します。この二つの乖離を明らかにすることが、このベンチマークの大きな目的の一つです。

自分で試してみる

最も手っ取り早い開始方法は、grafana/o11y-benchリポジトリをローカルにクローンし、READMEに従うことです。

そこから、HarborやLiteLLMを通じて利用可能なあらゆるモデルやエージェント構成に対して、個別のタスク、フルスイートの実行、比較レポートの作成が可能です。

o11y-benchを試された際は、より多くのモデルや構成での結果、あるいは再現実験の結果などをぜひ共有してください。今後のベンチマーク改訂への提案も歓迎します。HuggingFaceリーダーボードへの寄稿や、リポジトリでのIssue作成をお待ちしています。

GrafanaCON 2026のその他の刺激的なアップデートについての詳細は、発表まとめブログをご確認ください。また、Assistantやその他のAI機能に関するFAQを含むGrafana Cloud AIの詳細については、AIオブザーバビリティのページをご覧ください。

Grafana Cloudは、メトリクス、ログ、トレース、ダッシュボードなどを始める最も簡単な方法です。私たちは、充実した永久無料枠と、あらゆるユースケース向けのプランを用意しています。今すぐ無料でアカウントを作成しましょう！