
Grafana Assistantがパブリックプレビューになったので触ってみた
はじめに
Grafana Cloudにアクセスするとこんなポップアップが出ていました!
先日、Grafana Assistantがパブリックプレビューになっていたようなので早速触ってみました。
Grafana Assistantは、Grafana専用のエージェント型LLM統合ツールです。
Grafanaのインターフェイス上でAIアシスタントを呼び出すことができます。
ちなみにドキュメントには以下の記載がありましたので、本番環境での使用は控えた方が良さそです。
Grafana Assistantは現在パブリックプレビュー段階です。この機能は予告なく変更される可能性があります。
何ができる?
Grafana Assistantでは以下のようなことができるようです。
- 学習とサポート- Grafana Labsのエコシステムの多くはオープンソースであるため、LLMはすでにGrafanaに関する幅広い知識を持っています。
- オンボーディング- Grafanaの概念や用語を理解し、強力なユーザーインターフェースの可能性を最大限に引き出す方法を学びます。
- クエリ- アシスタントがあなたに代わってクエリを作成します
- 探索とナビゲーション- 観測データについて質問し、発見する
- 調査- 連続したツール呼び出しを組み合わせて洞察を探したり、特定の問題を掘り下げたりします
- ダッシュボード- ダッシュボードの作成と編集(一括更新を含む)
今回はダッシュボード作成や編集、クエリ作成、探索あたりを試してみました。
プラグインの有効化
早速ポップアップのTry it nowをクリックしてみましょう!
画面が遷移して
「専用に設計されたエージェントLLMアシスタントGrafana の学習、調査、変更などに役立ちます」
と表示されています。
専用に設計されたエージェントということで期待が膨らみます。
Go to plugin configurationをクリックすると利用規約が表示されます。
利用規約でいくつか気になった部分を抜粋します。
- データはモデルのトレーニングに使用されない
- 検索エンジンAPIとしてTavilyを利用
- Grafana AssistantはAnthropicのAPIを利用
当然ですが、ダッシュボードに利用しているデータはトレーニングには利用されません。
検索エンジンのAPIにはAIエージェントに最適化された検索プラットフォームのTavilyを利用しているようです。
また、APIはAnthropicのAPIを利用しているようです。
AntropicのケーススタディにもGrafana AssistantでClaudeが使われていることが書かれていました。
モデルはClaude Haiku 3とClaude Sonnet 3.7を使っているようで、簡単な要約タスクはHaikuを使っていると書かれていました。
また、近日中にClaude Sonnet は3.7から4にアップデートされるようです。
少し話がそれましたが、利用規約に同意するとプラグインが有効になりました。
ではAssistantを起動してみましょう!
画面の右上に出ているキラキラマークをクリックします。
すると、画面の右側にチャット欄が出てきます。
あとはここに指示を書くだけでAssistantが利用できます。
やってみる
それでは早速Grafana Assistantを使ってみましょう。
ダッシュボード構築
まずは、ダッシュボード構築にどれくらい使えるのか試してみました。
今回はAWSのCURを使ってAWSの利用費を分析するダッシュボードを作ってみます。
現時点ではインプットとして画像を渡すことはできないようなので、テキストで構築したいダッシュボードを指示していきます。
以前Claude Codeと一緒にダッシュボードを作ってみた。という内容の記事を書きましたので、そのダッシュボードと同じようなダッシュボードを作れるのか試してみます。
プロンプト
@AWS Cost Table
月初から今日までのコストの合計を表示するパネルを作成してください。
パネルにはドルベースの数値のみ表示してください。
背景を$30以内で緑、$30以上で黄色、$50以上で赤に設定してください
最初の@AWS Cost TableはAWS Cost Tableというデータソースを指定しています。
@~とすることでデータソースやダッシュボードをコンテキストとして含めることができます。
出力結果は以下のようにNo dataとなっていました。
自動的にパネルが生成されSQLを書いてくれているようですが、なぜかパネルのクエリ部分が空になっています
このあと何度かクエリ部分の修正を依頼してみましたが、何度やってもなぜかクエリが入力されませんでした。
チャット欄を確認するとクエリが書かれているので、それをコピぺしてみましたが構文エラーなど、うまくいかないことが続きました。
このままではうまくいきそうになかったので、別の方法を試します。
まずは自分で1つパネルを作成して、それを参考にAssistantに他のパネルを作成してもらいます。
まずは適当にEC2の利用費を出力するクエリでパネルを作成します。
プロンプト
SELECT
line_item_product_code,
line_item_line_item_description,
SUM(line_item_unblended_cost) AS sum_line_item_unblended_cost
FROM
cur_database.cur_cost_export
WHERE
year = '2025' AND month = '8'
AND line_item_product_code = 'AmazonEC2'
AND line_item_line_item_type NOT IN ('Tax','Refund','Credit')
GROUP BY
line_item_product_code,
line_item_line_item_description
ORDER BY
sum_line_item_unblended_cost DESC;
作成されるパネルはこんな感じです。
では、次にこのクエリを参考に先ほど依頼した月初から今日までの利用費のパネルを作成してもらいましょう。
プロンプト
EC2 Costのパネルを参考に
月初から今日までのコストの合計を表示するパネルを作成してください。
パネルにはドルベースの数値のみ表示してください。
背景を$30以内で緑、$30以上で黄色、$50以上で赤に設定してください
Assistantの回答
...(省略)
既存のパネルでAWS Athenaデータソースを使用してAWS Cost and Usage Reportから月別のコストデータを取得しているのがわかります。現在のパネルと同様の構造で、月初から今日までのコスト合計を表示するパネルを作成しましょう。
...(省略)
想定通り自分で作成したパネルのデータソース情報やクエリ方法を理解してくれているようです。
先ほどとは違い、パネルにクエリが記載されています。
しかし何かエラーが出ているようなので確認したところ、どうやらクエリでTYPE_MISMATCHが発生しているようです。
Assistantは依頼内容から動的に月初から今日の日付までの合計値を出そうとしているようです。
しかし、今回の場合は9月の値を全て合計すれば良いだけなので、SELECTのSUM(line_item_unblended_cost)のみで達成しています。
なので少しクエリを調整してもらいましょう。
プロンプト
クエリで構文エラーが出ているようです。
動的に月初から今日までの日付を取得する必要はありません。
9月分のコストを合計するだけで良いです。
これで想定通りのパネルが作成されました。
インプットの内容はかなり細く指示が必要な印象でした。
次に、年月は動的に変わるので変数で定義したいところです。
ということで変数も作ってもらいましょう。
プロンプト
2025年や9月といった変動する部分については変数で定義して欲しいです。
変数が作成されて、パネルのクエリも変数が適用されていました。
こういった実装が自然言語でサクッと実装できると感動しますね。
一旦ダッシュボード作成や編集のイメージはできたのでこの辺にしておきます。
気になったこと
気になったこととして、Assistantで編集を行う際、特に何の確認もなくクエリやパネルオプションの設定が変更されました。
パネルを変更する際は変更箇所を提示した上で、変更の可否などは聞いてほしいなと思いました。
調査
次に既存のダッシュボードをもとにAssistantを使って調査できるのか確認します。
今回使うのはAWSサービスごとに詳細なコスト使用状況が確認できるダッシュボードです。
ではこちらのダッシュボードからコスト分析やコスト削減の調査が可能か試してみます。
プロンプト
@AWS サービス詳細分析
2025年9月のAmazon Elastic Compute Cloudの使用タイプ・オペレーション別コストから、特にどの部分に費用が発生していて、どのような対応をすればコスト削減につながりますか?
Assistantの回答
現在のダッシュボードからAWS EC2のコスト分析に関するパネルが確認できました。現在のダッシュボードには以下の情報が表示されています:
- 今月の利用費 - 2025年9月の合計コスト
- 月末予想コスト - 線形予測による月末コスト
- 使用タイプ・オペレーション別コスト - 棒グラフでの詳細分析
- トップ50リソース別コスト - リソースごとの詳細コスト表
現在のダッシュボードが既に2025年9月のAmazon Elastic Compute Cloudのデータを表示していますので、これらのパネルから詳細な分析と推奨事項を提供いたします。
2025年9月のAWS EC2コスト分析とコスト削減提案
現在のダッシュボードでは、Amazon Elastic Compute Cloudの使用タイプ・オペレーション別コスト、月末予想コスト、およびリソース別の詳細なコスト分析が表示されています。
主要なコスト要因の特定
使用タイプ・オペレーション別コスト分析のパネルから、以下の要素を確認することで主要なコスト要因を特定できます:- EC2-Instance - オンデマンドインスタンスの実行コスト
- EBS-Volume - ストレージボリュームコスト
...(省略)
上記の最適化施策を段階的に実装
現在のダッシュボードデータから具体的なコスト削減額を算出するには、実際の数値を確認する必要があります。リソース別コスト表から最も高額なリソースを特定し、それらに対して優先的に最適化施策を適用することをお勧めします。
どうやら、現在表示されているダッシュボードにどういったパネルが存在するかは認識できるが、実際にクエリ結果を確認することはできないようです。
Assistant自身に何ができるのか聞いてみましょう。
プロンプト
あなたは現在のダッシュボードに表示されているクエリ結果の情報を取得することはできないのですか?
あなたは何ができますか?
Assistantの回答
おっしゃる通りです。申し訳ございません。私は現在のダッシュボードパネルに表示されている実際のクエリ結果データを直接取得することはできません。
私ができることは以下の通りです:
現在可能な操作
- ダッシュボードパネルの設定情報を読み取る
- SQLクエリの内容
- パネルの設定
- 変数の定義
- データソースへの直接クエリ実行(対応データソースのみ)
- Prometheus、Loki、SQL系データソースなど
- ダッシュボードパネルの作成・変更
現在の制限
- 表示されている実際の結果データは取得できません
- Athenaデータソースは現在サポート対象外のため、直接クエリ実行もできません
予想通りダッシュボードパネルの設定情報は読み取れるようです。
Assitantが実行するクエリに関しては一部のデータソースしか対応していないようです。
また、対応しているデータソースに調査を依頼した場合でも、パネルのクエリ結果ではなくAssistantが直接データソースに対してクエリを実行した結果から回答するようです。
今回使っていたデータソースは全てAthenaデータソースだったので直接クエリにも対応していなかったようです。
PrometheusやLokiなど一部のデータソースでは直接クエリに対応しているようです。
と、いうことでPrometheusやLokiでやってみました。
PrometheusとLokiで試してみた
PrometheusとLokiのデモデータを使ってAssistantで調査ができるかやってみます。
まずはPrometheusとLokiのデモデータを使って適当なダッシュボードを作成します。
内容はKubernetesのデモデータで、上半分がPromethus、下半分がLokiのデータです。
それではPrometheusのデータを調査してもらいましょう。
name_sapaceがquickpizzaで最もCPU使用率の高いコンテナを教えてください。
以下、画像の方が分かりやすいと思うのでAssistantの回答を添付します。
回答内容とダッシュボードを比較すると、Assistantは正しい情報を取得していることが分かりました。
Lokiのログも試してみましょう。
少し曖昧な内容の指示を出してみましょう。
プロンプト
2025/09/27で確認しておくべきログはありますか?
少し長くなってしまいましたが以下の回答が得られました。
回答内容は、ダッシュボードに表示されている通り本日のログに1つWARNが出力され、そのログから影響範囲や対応可否について回答してくれています。
PrometheusやLokiなどAssistantが直接クエリを実行することをサポートしているデータソースの場合、質問に対してクエリ生成から調査までをやってくれます。
今回は少し曖昧な指示を出しましたが、欲しかった回答が得られました。
現時点ではPrometheusやGrafana LGTMスタックであるLokiやTempo, MimirといったGrafanaと親和性の高いデータソースはAssistantからクエリできるのだと思われます。
所感
とりあえず使ってみた所感としてはGrafanaと親和性の高いデータソースなら結構使えるな〜という印象を受けました。
調査だけでなく作成や編集といった部分に関してもPrometheusやLokiではエラーややり取りが少なく求めるアウトプットが得られました。
おそらくユーザーがダッシュボードのAIに求めるのはこういった機能だと思います。
今後は他のデータソースに対しても同じようにAssistantから直接クエリできることを期待したいですね。
一方で気になった部分として、ダッシュボードの編集を依頼した際に変更前に何の確認もなく編集が実行されるのが気になりました。
Grafanaにはバージョン管理機能があるとはいえ、まずはどんな変更が行われるのか確認してほしいところです。
プレビュー版ということで気になった部分はどんどんフィードバックしていこうと思います。
他にも試せていない機能があるので、面白い機能があればまたブログを書きたいと思います。