テレメトリ駆動開発：gcxとGrafana MCPを活用し、AIコーディングエージェントの挙動への「確信」を持つ方法

PR（プルリクエスト）の「マージ」ボタンを押す直前、以前よりも少し不安を感じることはありませんか？それはなぜでしょうか。

現代の標準からすれば、あなたはすべてを正しく行いました。 ClaudeにGitHubのIssueやSlackのスレッドを読み込ませて計画を立てさせ、何度かやり取りをして「状況はすべて把握しました」とClaudeは返信しました。 準備は万端に思えたので、Claude Codeにその計画を実装させました。さらに、レビュー用のエージェントに差分（diff）をチェックさせ、いくつかの指摘事項も修正しました。 いざ自分で差分を読み始めますが、コードは長大です。システム全体の中でこの変更がどう機能するのか、頭の中でモデルを組み立てようと試みます。 Claudeとさらに何度か質疑応答を繰り返し、なんとなく「大丈夫そうだ」と思えるレベルに達したため、PRを作成します。 AIのレビューもオールクリアで、チームメンバーからも「LGTM（Looks Good To Me）、リリースしよう」とコメントがつきました。

なのに、なぜまだ不安が残るのでしょうか？ それはおそらく、自分で一からタイピングして書いたコードのようには、その差分を「深く理解」できていないからです。

AIが登場する前、私たちはコードを書く過程でシステム変更のメンタルモデルを構築し、デプロイするコードが想定通りに動くという確信をそのモデルに委ねていました。しかし、AIがコードを変更するようになると、そのプロセスが抜け落ちてしまいます。 コーディングエージェントのおかげでデプロイのスピードは上がりましたが、私たちの「理解のスピード」はそれに追いついていません。 コードの変更に対する自信を保つための、より良い方法が必要なのです。

ありがたいことに、このような状況では「より多くのデータ」が適切な判断を助けてくれます。 エージェントにコードを生成させたことで失われた「知識や確信」は、システムが期待通りに動いているデータを実際に目で見ることで補うことができます。 優れたオブザーバビリティは、ビルド段階を含め、ソフトウェアのライフサイクル全体を通じてそれを可能にします。

本記事では、当社のAIツールを活用して、コードとエージェントに対する確信を高める方法をご紹介します。

コーディングエージェントに自社のテレメトリへのアクセス権を与える

まず、この新たな環境に適応するために私たちが提供しているツールについてご紹介します。

Grafana CloudのCLIである「gcx」と「Grafana MCPサーバー」は、どちらもAIエージェントをGrafanaインスタンスに接続し、テレメトリデータを直接操作できるようにするツールです。

• Grafana MCPサーバー: 自身でホストすることも、Grafana CloudスタックのホステッドMCPサーバーを利用することもでき、一般的なユースケースに特化した機能を提供します。
• gcx: より柔軟で自由度の高いツールです。 エージェントが探索的に利用でき、ユーザー独自のワークフローを構築することが可能です。

Grafana Cloudだけでなく、セルフホストのOSS版やEnterprise版のインスタンスでも使用できます。

どちらのツールも、既に一般提供が開始されています。

Claude Codeを使用している場合は、プラグインとしてGrafana MCPサーバーを簡単にインストールできます。また、Grafana Assistantの操作をガイドするGrafana Assistantプラグインも提供しています。 一方、gcxには独自の「スキル」がバンドルされており、gcx agent skills install.コマンドでインストール可能です。 これらのスキルにより、一般的なワークフローにおいてエージェントがgcxを効果的かつ効率的に使えるようになります。

エージェントにシステムの「実際の挙動」を理解させる

私たちがこれらのツールを開発したのは、エージェントとの協業から生じる課題を解決するためです。

なぜなら、エージェントは「システムが実際にどう稼働しているか」例えば現実的なリクエストの頻度やサイズ、どのコードパスが頻繁に使われ、どこが使われていないかを理解することで、初めてより実用的な結果を出せるからです。

このデータがあれば、エージェントが滅多に使われないコードを過剰に最適化するのを防いだり、負荷テスト用により現実的なダミーデータを生成したりできるようになります。

テレメトリへのアクセスに加えて、エージェントはSLOの定義や合成モニタリングのチェック結果なども読み取り、システムの運用状況に関するコンテキストを補完できます。

これにより、チームの運用スタイルに最適な変更計画を立てることが可能になります。

SLOの定義からはシステムの最重要メトリクスを把握し、外形監視のチェックからは外部からの呼び出し元が期待する「望ましい挙動」を理解します。

例えば、決済サービスに新しいプロバイダーを追加するとしましょう。 すでに決済サービスのREDメトリクス（リクエスト数、エラー率、レイテンシ）を示すダッシュボードがあり、既存のプロバイダーSwipeのp95レイテンシが2秒であることが分かっているとします。 あなたはエージェントに対し、「トラフィックの30%を新しいプロバイダーに振り分けること」「レイテンシは既存と同じ水準を保つこと」を指示します。

するとエージェントは、本番環境から実際のテレメトリデータを取得し、これらの要件を現実のデータと照らし合わせます。 エージェントは対処すべき要件や制約を正確に把握できるため、提案される実装内容も実態に即したものに変わってきます。 例えば、システムへの現在の決済リクエスト率を調べ、これから構築する新しいリクエストハンドラーのトラフィック量を予測します。 また、ユニットテストや統合テスト用に決済プロバイダーのモックを作成する際も、現実に即したレイテンシを組み込むべきだと理解します。

その結果、エージェントが学習データに基づく「単なる推測」ではなく、実際のデータに導かれるため、本番環境に近い状況下で想定通りに動作するロジックが完成します。

Grafana Assistantでの会話をコマンドライン（CLI）に引き継げる機能があることをご存じでしょうか。 会話のコンテキストをコーディングエージェントに渡したい時に非常に便利です。AssistantのサイドバーやWorkspaceで三点リーダーをクリックし、「会話を引き継ぐ（Hand off Conversation）」を選択すると、会話のトランスクリプトを引き出すためのgcxコマンドが表示されます。

テレメトリ駆動開発

まったくの新規システムでない限り、すでに何らかのテレメトリが出力され、システムの健全性を監視するためのダッシュボードやSLOが設定されているはずです。 これらの既存データは、ドキュメント化された仕様書やテスト条件を補完する「エージェントへの仕様書」の一部として活用できます。

もしオブザーバビリティの導入が初めてであったり、システムにどんなメトリクスを追加すべきか迷っていたり、あるいは計装作業のハードルが高すぎると感じている場合は、gcxにバンドルされているgcx-observabilityスキルを試してみてください。 このスキルは、あなたとエージェントに対してコードベースの計装（インスツルメンテーション）をガイドし、活用できるオブザーバビリティ機能を紹介してくれます。 gcx agent skills get gcx-observabilityコマンドで内容を確認できます。

この流れを、先ほどの決済プロバイダーの例でさらに見てみましょう。 新しいプロバイダーの障害を検知できるようにするため、あなたはエージェントに「メトリクスをプロバイダー別に集計してダッシュボードを更新して」と指示します。 gcxやGrafana MCPサーバーを使えば、エージェントはダッシュボードを読み取り、自ら更新することができます。 更新したダッシュボードの定義をソース管理にコミットしたり、Grafanaに直接プッシュしたりすることも可能です。 さらに、ダッシュボードで使われているクエリを解析し、コードベース内のどの部分のテレメトリを修正すべきかを特定することまでやってのけます。

開発中にテレメトリを最大限に活用するには、エージェントが「期待する挙動が確認できるまで」変更を反復（イテレーション）できる環境が必要です。 そのデータをメトリクスとして確認するには、ローカル環境のビルドからテレメトリをエクスポートする必要があります。 こうした環境構築も、AIを使えばはるかに簡単です。 エージェントは多数のOSSオブザーバビリティツールについて学習済みであるため、OpenTelemetry Collectorを起動し、データをGrafanaスタックに送信する方法を熟知しています。（当社のCTOであるTom Wilkieの記事『なぜオープンソースはAIのチートコード（裏技）なのか』をご参照ください）

もし完全なローカル環境を構築したい場合は、エージェントにgrafana/otel-lgtmのDockerイメージを使うよう指示すれば、すぐにLGTMスタックが立ち上がります。 gcxを設定して、このローカルのGrafanaインスタンスとやり取りさせることも可能です。 今回の例であれば、gcx resources pullコマンドで本番環境から決済ダッシュボードを取得し、ローカルのGrafanaにプッシュできます。 エージェントは（途中でgcxのドキュメントを読みながら）、検証用のダッシュボードやメトリクスが正しく表示されるようにデータソースの設定を微調整することも手伝ってくれます。

結果として、テレメトリからの「完全自動化されたフィードバックループ」が完成します。 コーディングエージェントはこのループを使って、あなたの望む状態に到達するまでコードの変更と検証を反復できるのです。

トラフィックの生成

次に、その挙動を確認するために、決済トラフィックのシミュレーションが必要になるでしょう。 これも以前なら非常に時間と手間のかかる作業でした。 AIがなければ、トラフィックの傾向を人間が分析し、想定されるシナリオを網羅するサンプルリクエストを手書きするか、ファザー（fuzzer）を使ってトラフィックにバリエーションを持たせる必要がありました。 さらにk6のテストスクリプト構文を学び、ローカルでの動かし方を調べる必要もあり、少なくとも丸1日はかかる作業です。

しかし今なら、AIエージェントに頼むだけで、サンプルトラフィックの生成、テストスクリプトの作成、さらにはk6のDockerコンテナの立ち上げまで行ってくれます。 本番環境のテレメトリにアクセスできるため、テストに最も適したリクエストの形状やレートも把握しています。 これにより、あなたはある程度の負荷がかかった状態でシステムがどう振る舞うかを観察でき、「現実の環境でもシステムが機能する」という確信に一歩近づくことができます。

k6にも独自のエージェントスキルが用意されており、k6 x agent init <ターゲット>（例えばk6 x agent init claude-codeなど）でインストール可能です。 このワークフロー全体と同様に、これらのスキルもテレメトリを活用します。 現実のトラフィックに基づく新しいテストの作成方法をエージェントに教え、テストが失敗した際に「テストコードが悪いのか、テスト対象のシステムが悪いのか」を分析し、本番環境で問題になる前に修正案を提示したり、しきい値を調整したりすることが可能になります。

ローカルビルドが動き、現実的な負荷の元で想定通りのパフォーマンスと挙動を示しているのを自分の目で見ることができれば、コードに対する確信を高められます。 コントロールを失うことなく、より速く開発を進められるのです。

改善のループ

エージェントはシステムの改善案を提示することもできます。 「システムのメモリ使用量を10%削減して」と指示すれば、エージェントはプロファイリングデータを照会し、コード内のホットスポット（負荷の高い部分）を特定し、変更内容を解説したPRの下書きを作成してくれます。 あとは、k6スクリプトとテレメトリ環境を使って、その変更が実際に効果があったか証明するだけです。

Grafana LabsのTempoチームは、すでにこのパターンを活用しています。 彼らは、数テラバイトのデータを持つ負荷の高い開発環境に対して、反復的にパフォーマンス分析を行う独自のエージェント・ハーネス（テスト環境）を構築しています。 分析のたびに、ベースラインを取得するためのクエリを実行し、デプロイメントのプロファイルから改善の候補を探します。 候補が見つかれば、変更を実装してデプロイし、同じクエリを再実行してベースラインと比較します。 そのデータをもとに、チームは変更をコミットするかどうかを判断しています。

残念ながら、UIに関してはテレメトリだけでは全体像を把握できません。

しかし、現在実験的機能として提供している「Agentic Testing」を使えば、自然言語で指示や検証手順を記述し、公開されているWebアプリケーションに対してエージェントにテストを実行させることができます。

これらのテストはUIのデグレ検知に役立ち、従来のブラウザテストよりも定義が簡単で、UIの変更にも柔軟に対応できます。

コントロールを取り戻す

内容を半分しか理解していないPRや、エージェントが自動生成した味気ない説明文で終わらせる必要はもうありません。 「現実的な負荷の元で、ローカルビルドが想定通りに動いていること」を証明するダッシュボードへのリンクが添えられたPRを作成できるようになるのです。先ほどの決済サービスの例であれば、メトリクスやログのどこに新しいプロバイダーのラベルを追加したかを示し、ローカルビルドのテレメトリをGrafanaにエクスポートした上で、「負荷テスト実行時の新プロバイダーのメトリクス」を示す新しいダッシュボードのリンクをPRに貼り付けることができます。 これにより、新しい決済ハンドラーが30%のトラフィックを問題なく処理できたことを、レビュアーに明確に示すことができます。

この変更が想定通りに動くことを、自分自身、そしてPRのレビュアーに確信させるための「証拠」がはるかに多く揃うことになります。 この追加の証拠は、レビュアーの認知的負荷を減らすことにも繋がります。

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