Grafana Agent Observabilityでエージェントのトラストプラットフォームを構築する方法

Grafana Agent Observabilityでエージェントのトラストプラットフォームを構築する方法

2026-07-301 min
Twitter
Facebook
LinkedIn

エージェントワークロードを観測することは容易ではありません。特に、独自の監視スタックをゼロから構築しようとしている場合や、LLMが登場する以前の時代に作られたツールだけに頼ろうとしている場合はなおさらです。

Grafana Labsでも、この課題はよく理解しています。

Grafana Assistantは、社内のハッカソンプロジェクトとして始まり、わずか6か月強で一般提供(GA)に至りました。ユーザーが積極的に採用してくれたことは嬉しいことでしたが、その一方で、バックエンドでのスケーリングや複雑さの管理という成長痛も伴いました。複数のチームからの変更が積み重なる中で、プロンプト・ツールセット・エージェントハーネスへの貢献をレビューすることが悪夢のようになっていました。独自のダッシュボードではとても対処しきれなかったのです。(私たちの経験については、新しいエンジニアリングブログ「Unprompted」でさらに詳しく読むことができます。)

もしあなたもエージェントを構築しているなら、同様の悩みを経験したことがあるかもしれません。朗報があります。私たちが通ってきたのと同じ成長痛を、あなたは盲目的に繰り返す必要はありません。私たちはこれらの課題に対処するための社内ツールとして Agent Observability を構築しました。そして本日、Grafana Cloudユーザーへの一般提供を開始します。このツールを使えば、エージェントの監視、動作テスト、問題発生時の介入をスムーズに行えるようになります。

しかし、適切なツールを持つことは最初のステップにすぎません。この記事では、Grafana Assistantを構築する過程で私たちが経験したフェーズをもとに、独自のエージェントを監視するための堅牢な信頼性・モニタリング環境を構築するためのガイダンスとベストプラクティスを紹介します。

Phase 0:初期プロトタイプと初期デプロイ

新しいアイデアから始め、エージェントフレームワークを選び、新しいエージェントに最初の「Hello, world!」を送るのはとてもワクワクする瞬間です。実際、システムプロンプトにツールとシングルショットの例を追加して、簡単なQ&Aテストをするだけで、驚くほど多くのことができるようになります。エージェントが概ね安定して有用な状態になったら、エージェントが対処すべきユースケースの基本セットを使って、初期ベンチマークやテストスイートを実行できます。しかし、初めて本番環境にデプロイされて最初の問題が現れると、亀裂が見え始めます。顧客から「おかしな会話があった」と連絡が来るかもしれませんし、社内ユーザーが「こんな変な返答があった」というスクリーンショットをSlackに貼ることもあるでしょう。そのとき、どうやってトラブルシューティングを始めますか?

開発の次のステップは、こうした会話を効率的に見つけてトリアージできる仕組みを整えることです。従来のソフトウェア監視と同様に、これはエージェントのコードへの計装によって実現します。

Phase 1:実トラフィックの監視

エージェントを観察する際に重要な側面が2つあります。

1つ目は、レイテンシ・コスト・トークン数・エラーといった従来のエンジニアリングメトリクスです。これらのメトリクスにより、開発者はエージェントの全体的なメンテナビリティを把握し、コストの異常を特定し、プロンプトキャッシングの導入によるトークン削減など、最初の改善を実施できます。財務部門から「エージェントの運用コストはいくらか?」と聞かれたとき、このステップがその答えを提供します。

2つ目の側面は、会話そのものです。深い分析なしに会話をスポットチェックしてエージェントの動作を確認するだけでも、驚くほど多くのフィードバックが得られます。数十の会話を読み込むだけで、エージェントがどのように機能しているかについての全体像が見えてきます。会話を計装することで、顧客からのリクエストをトリアージし、問題のある会話を特定して解決することも容易になります。

エージェントの会話への計装と可視性を設定するには、Grafana Agent Observability SDK を通じて、エージェントフレームワークに合わせた設定を記述するだけです。SDKには計装を支援するコーディングエージェントスキルが付属しています。また、Grafanaの新しいCLIツール「gcx」にも、これらのフェーズのセットアップを支援するスキルが付属しています(詳細は agento11y-instrument を参照してください)。

これで、本番環境でエージェントに関して発生した問題に対応するための手段が整いました。しかし、スポットチェックと従来のエンジニアリングメトリクスだけでは限界があります。次のステップは、異常を自動的に検出することです。そのためのより強力な方法が用意されています。

Token and cost usage dashboard in Grafana Agent Observability

(画像:Grafana Agent Observabilityのトークンおよびコスト使用量ダッシュボード)

2つ目の側面は、会話そのものです。深い分析なしに会話をスポットチェックしてエージェントの動作を確認するだけでも、驚くほど多くのフィードバックが得られます。数十の会話を読み込むだけで、エージェントがどのように機能しているかについての全体像が見えてきます。会話を計装することで、顧客からのリクエストをトリアージし、問題のある会話を特定して解決することも容易になります。

Conversation list view in Grafana Agent Observability

(画像:Grafana Agent Observabilityにおける会話リストビュー)

エージェントの会話への計装と可視性を設定するには、Grafana Agent Observability SDK を通じて、エージェントフレームワークに合わせた設定を記述するだけです。SDKには計装を支援するコーディングエージェントスキルが付属しています。また、Grafanaの新しいCLIツール「gcx」にも、これらのフェーズのセットアップを支援するスキルが付属しています(詳細は agento11y-instrument を参照してください)。

これで、本番環境でエージェントに関して発生した問題に対応するための手段が整いました。しかし、スポットチェックと従来のエンジニアリングメトリクスだけでは限界があります。次のステップは、異常を自動的に検出することです。そのためのより強力な方法が用意されています。

Phase 2:ベースラインパフォーマンスの評価

エージェントは本質的に非決定論的であり、幅広いユースケースに合わせて大きくカスタマイズされています。この特性のために、従来のメトリクスを使用してエージェントの品質を把握することが難しくなります。本番環境で正しく機能していることを、どのように信頼すればよいでしょうか?

これに対処するために、決定論的チェック(regexやJSONバリデーションなど)とLLMジャッジ評価器の組み合わせが、時間の経過とともにエージェントの品質を監視するうえで推奨されます。

LLMジャッジ評価器は、別のLLMにトランスクリプトや個々のツール呼び出しなどを確認させ、出力スケール(通常はboolean(合格/不合格)またはLikert(1〜5))でスコアリングする仕組みです。

Grafanaがすぐに使えるEvaluatorテンプレートには、PII識別やToxicityなどがあり、手軽にスタートできます。Helpfulness は、純粋なエンジニアリング指標よりもエージェントのパフォーマンスについて多くの情報を得られる一方で、信頼性に欠ける場合があります。そこでカスタムEvaluatorが、特定のエージェントの動作をより正確に診断するためのメトリクス調整に役立ちます。評価器を作成する際には、ジャッジモデルに渡すプロンプトと、会話から抽出するコンテキストを設定することで、特定のユースケースに対するジャッジの精度を向上させます。Evaluatorルールによって、ライブトラフィックに対してこれらの評価をいつ・どのように実行するかについて完全な柔軟性が得られます。たとえば、会話トランスクリプト全体に対して実行したり、会話内の個々のエージェントメッセージだけに対して実行したりといった設定が可能です。プロンプトインジェクション検出・カスタムフルフィルメントスコアなど、ユースケースに合わせた幅広い評価に対応しています。

さらに、LLMによる評価を補完するために、正規表現のような決定論的な評価手法を組み合わせることで、特定のキーワードが含まれる会話をピンポイントで検知できます。たとえば、AIエージェントが誤って競合製品を推奨してしまっている会話や、APIキーの漏洩につながるような不適切なやり取りをチェックし、フラグを立てる(アラートをあげる)といった使い方が可能です。

Conversation-level evaluators in a conversation

(画像:会話内のEvaluatorによる判定例)

Agent Observability内のEvaluatorは、評価スコアを「Grafana Cloud Metrics」に自動でパブリッシュするため、既存の集計ダッシュボードに加えて、独自のカスタムダッシュボードを簡単に構築できます。メトリクス化されることで、Grafana Alertingとのシームレスな連携も可能になります。これにより、もしエージェントのプロンプト変更を本番デプロイした結果、ユーザーの目の前でパフォーマンスや品質が大幅に低下した場合、オンコールのエンジニアに即座にアラートを送り、即座にロールバックを実行するといった運用が実現します。

Evaluator scores over time for a chat application

(画像:チャットアプリにおけるEvaluatorのスコア推移)

Evaluatorによって本番トラフィックの監視が始まれば、開発者は実際の環境で稼働するエージェントをより信頼できるようになり、不具合をプロアクティブに検知できるという確信を持てるようになります。

そして、次のステップは、品質劣化を一切引き起こすことなく、エージェントを安心して改善できる仕組みを整えることです。


フェーズ 3:より強固なテストスイートの構築

フェーズ0で触れたように、最初のデプロイメントの時点では、いくつかの主要なユースケースを用意してテストやベンチマークを行い、「これなら大丈夫だろう」という確信を得ていたはずです。しかし、そこで満足してはいけません。

テストスイートとは、本質的に「テストケースの集合体」です。シンプルなテストケースは、「初期の入力プロンプト」と「期待される出力結果(評価基準)」で構成されます。これらは、エージェントをテストし、改善や品質劣化を評価するための「シードプロンプト」として機能します。

ここで最も価値があるのが、本番環境でEvaluatorから「低スコア」をつけられたり、失敗したりした実際の会話データです。こうした失敗からは、エージェントが対応できていないエッジケースや、より広い範囲で改善が必要な領域が明らかになり、開発者がどこに注力すべきかを把握できます。Evaluator には アクション を割り当てることができ、こうしたパターンに当てはまる会話を特定して、コレクション に振り分けられます。該当する会話のコレクションができたら、人またはエージェントがアノテーションを付け、それを テストスイート に追加できます。

Flow for collecting low-scoring conversations

(画像:低スコアの会話をテストスイートへ収集するフロー)

このようにして、「主要ユースケース」「本番環境で発生した実際の失敗事例」「今後改善したいアイデア」を網羅した強力なテストスイートの土台ができあがれば、いよいよオフライン環境での評価と実験を開始できます。

フェーズ 4:実験のトラッキングとCI/CDへの統合

「オフライン評価」とは、本番環境の実トラフィックを監視する「オンライン評価」とは異なり、用意された固定のテストスイートに対してエージェントを実行し、そのパフォーマンスレポートを生成する手法です。これは、初期開発、ベンチマーク、変更内容の検証、そしてCI/CDパイプラインにおいて重要な役割を果たします。

Experiments list view in Grafana Agent Observability

(画像:Grafana Agent Observabilityの実験リスト画面)

ベンチマークは、エージェントや単体のLLMが、特定の既知のタスクに対してどの程度優れたパフォーマンスを発揮するかを測定します。たとえば、Grafanaが提供する「o11y-bench」は、Grafanaエコシステム内のオブザーバビリティタスクに関連する約70の課題に対して、エージェントの対応力を測定します。新しい最先端モデルがリリースされるたびに、自社のビジネスドメインにおいてどのモデルが最も適しているかを判断する大きな判断材料になります。

エージェントの改善に日々取り組む開発者にとって、最も重要なのは「プロンプト変更などの修正が安全かどうかを検証すること」です。開発者やプロダクトマネージャーが、手軽に変更を加え、それがテストスイート全体にどう影響したかを一目で確認できるプラットフォームは、迅速なイテレーションに欠かせません。最もよくあるユースケースは、プロンプトを変更する前後でテストスイートに対するエージェントのパフォーマンスを比較し、その変更を本番環境にデプロイしても問題ないかを判断することです。

agento11y SDKを使用すると、テストスイートをローカルにプルし、エージェントを実行してスコアを記録し、詳細なレポート(Experiment)を生成することができます。各テストケースには固有のIDが割り振られているため、プロンプト変更前後の複数回のテスト結果を横並びで比較することが可能です。「o11y-bench」を例に、Haikuモデルをベースラインとし、Sonnetモデルでの実行結果と比較すると、品質が劇的に向上する一方で、コスト(Token数)が増加している様子などが一目瞭然になります。

Experiments comparison view over two o11y-bench runs

(画像:2回のo11y-bench実行結果の比較画面)

(ご自身のo11y-benchの実行結果をGrafanaにパブリッシュして、ぜひ実際に試してみてください。) 

 手動でトリガーすることもできますが、プルリクエスト(PR)のCI/CDゲートとして組み込むことで、チームに圧倒的な安心感をもたらします。たとえば、「PRを作成する際の必須要件として、自動的にGrafanaで実験を実行させ、リグレッションがないことを証明するレポートのリンクをPRの概要欄に自動で貼り付ける」といったルールを運用するのです。

A failing CI/CD Github Action built on Experiments

(画像:実験が失敗し、CI/CDがブロックされたGitHub Actionsの画面)

検証結果に満足したら、変更を安全にマージして本番環境へデプロイします。デプロイ後は、エージェントのバージョン管理タブでバージョンごとの差分(diff)を追跡し、万が一の事態にはすぐにロールバックできる体制で監視を継続します。

Agent versioning view in Grafana Agent Observability

(画像:Grafana Agent Observabilityのエージェントバージョン管理画面)

あとは、このサイクルを繰り返すだけ

最後のステップは、「ひたすらこのループを回すこと」です! 本番データを収集し、テストスイートを磨き上げ、実際のデータに基づいた確実な検証を行いながらプロンプトやロジックの改善案を試す―この一連のイテレーションを高速で回し続けます。AIの世界は日々進化しています。新しいモデルが登場し、新しい実行技術が開発され、プロンプトやツール構成の最適解は無限に存在します。

今すぐAgent Observabilityを始めましょう

従来のオブザーバビリティは、ソフトウェアの「正常な動作を維持し、改善すること」が目的でした。Agent Observabilityは、不確実で複雑な「AIエージェント」の開発において、現実のデータに基づくフィードバックを開発者に提供し、確信を持ったイテレーションを可能にするという、一歩進んだ価値をもたらします。

Grafana Cloudで既に利用開始できるようになっているGrafana Agent Observabilityを活用すれば、エージェントのワークロードを安全に監視・改善し、開発チームに圧倒的な「心の平穏」をもたらすことができます。ぜひ、公式ドキュメントをチェックして、あなたのエージェントに信頼の基盤を築いてください。

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

Tags