AIエージェントが書いたコードを「本番の観測データ」で検証する — GrafanaのMCPサーバーとCLIツールが正式リリース

8月17日、Claudio Masoloが「Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development」と題した記事を公開した。この記事では、GrafanaのCLIツール「gcx」とMCPサーバーが正式GA（一般提供）に達し、AIコーディングエージェントがライブの可観測性データを参照しながら開発できるようになったことについて詳しく紹介されている。

なぜ今、観測データをエージェントのループに引き込むのか

AIコーディングエージェントの普及で、コードを書く速度は上がった。しかし、エンジニアがそのコードを十分に理解しないままPRをマージしてしまうリスクも高まっている。従来、エンジニアは自分でコードを打ちながら変更の全体像を把握していた。エージェントがdiffを生成する場合、そのモデル構築のステップが失われる。

Grafana Labsは、この問題への答えとして「可観測性データをループに引き込む」アプローチを取った。コードレビューだけに頼るのではなく、実際の観測データをエビデンスとしてエージェントの出力を検証する仕組みだ。

gcxとGrafana MCPサーバー：2つのツールの役割分担

今回GAになったのは以下の2ツールだ。

Grafana MCPサーバー：MCP（Model Context Protocol）に準拠し、よく使うユースケース向けに固定のツールセットを提供する。Grafana Cloudのホスト型エンドポイントとセルフホスト型の両方で利用可能。
gcx CLI：より柔軟な設計で、エージェントがカスタムワークフローを構築するために使うCLI。Grafana CloudのほかOSSおよびEnterpriseのセルフホスト環境にも対応する。

Redditで、Grafana Lab社員のdafydd-tは次のように説明している：

Grafana MCPサーバーは、Grafanaを操作するための一般的なタスク向けに、より意見（opinionated）が強いツールを提供する。gcxは、自分のワークフローを構築するために使える、より広く意見の少ないツールセットを提供する。

端的に言えば、すぐに使える定番フローにはGrafana MCPサーバーが向いており、チーム固有のワークフローや複雑な自動化を組み立てたい場合はgcxを選ぶ、という使い分けになる。

gcxにはgcx agent skills installでインストールできるスキルバンドルが同梱されており、Claude Code向けのプラグインもMCPサーバー用とGrafana Assistantガイダンスレイヤー用にそれぞれ提供されている。

具体的なワークフロー：推測ではなく実データで実装判断する

Grafana Labsが示す実例は、新しい決済プロバイダーを追加するシナリオだ。エージェントは負荷を推測するのではなく、まず現在のREDメトリクス（Rate・Errors・Duration）を確認する。既存プロバイダーのp95レイテンシが2秒であることが判明すれば、その値をユニットテストや統合テストのモックレイテンシとして設定し、新しいハンドラーのリクエストレート推定にも使う。

エージェントはさらに、既存ダッシュボードを読み込み・変更し、ダッシュボードのクエリをテレメトリを生成しているコードまで追跡し、更新したダッシュボード定義をGrafanaやソースコントロールに書き戻すことができる。

ローカル環境での反復作業には、OpenTelemetry Collectorのセットアップやgrafana/otel-lgtm DockerイメージによるフルローカルLGTMスタックが使える。gcxのresources pullで本番のダッシュボード定義をローカルに取り込む構成だ。

負荷テストの生成も自動化できる。本番テレメトリを使ってリアルなk6ロードテストスクリプトを作成し、k6をコンテナで起動する一連の作業は、従来は約1日かかっていた手作業に相当するとGrafana Labsは述べている。k6もk6 x agent initでインストールできる独自のエージェントスキルバンドルを提供しており、観測されたトラフィックからテストを生成し、「テスト自体の失敗」と「テスト対象システムの失敗」を区別する補助もできる。

社内事例とフロントエンドへの対応

Grafana Labs社内では、Tempoチームがカスタムのエージェントハーネスを構築している。このハーネスは、数テラバイトのデータを持つ開発環境をプロファイリングし、最適化の候補を特定する。変更を実装したあと、同じベースラインクエリを実行して差分を測定し、最終的にマージの可否は人間が判断する。

バックエンドテレメトリではカバーできないフロントエンドの回帰問題に対しては、自然言語の指示でライブWebアプリのUIフローを検証するAgentic Testing（実験的機能）も提供されている。

PRの姿が変わる

これらのツールが普及すると、PRの見た目も変わる。エージェント生成のdiffと説明文だけでなく、現実的な負荷のもとでローカルビルドを可視化するダッシュボードへのリンクや、テスト実行時に新たに追加されたメトリクス・ログラベルの一覧がPRに含まれるようになる。たとえば「このPRで追加したエンドポイントのp95レイテンシはX msで、既存プロバイダーの基準値以内に収まっている」といったエビデンスを、ダッシュボードのスナップショットリンクとともにPR本文に添付できるようになる。

焦点は「エージェントはチケットを理解したか？」から「動作中のシステムは期待通りか？」へと移行する。レビューエージェントが熟読なしに変更を承認するケースが増えている現状で、この観点の転換は実質的な意味を持つ。

詳細はGrafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Developmentを参照していただきたい。