Grafana Labsの新規プロダクト担当VPにインタビュー。生成AI関連について訊いてみた

Grafana Labsが開催したミニイベントObservabilityCON ON THE Road Tokyoで来日したMarc Chipouras氏にインタビューを行った。Chipouras氏は新規プロダクト担当のVice Presidentで、Grafana Labsが提供するオブザーバビリティのクラウドサービスGrafana CloudにおけるAI関連の新機能をカンファレンスでは紹介していた。生成AIを使ってオブザーバビリティデータから根本原因を突き止める発想は、多くのオブザーバビリティベンダーがチャレンジしている機能だが、Grafana Labsも例に漏れずGrafana Assistantという名称で生成AIを活用したAIアシスタント機能を提供している。今回は特にGrafana LabsにおけるAIに特化したインタビューという内容になった。

インタビューに答えたMarc Chipouras氏

今回は特にAIに関する内容をお訊きしたいと思います。2026年の1月にシンガポールでAAAI-26という国際会議が開催され、機械学習や自然言語関連などの領域で多くの論文が発表されていました。私が興味を持って見ていたセッションは「機械学習で学んだモデルが間違った時にどうやってそれを修正するのか？」というトピックでした。ここでは多くの新しい理論や方法が研究され発表されていました。多くのオブザーバビリティベンダーが生成AIを使って根本原因分析を試行していますが、どのデモを見ても必ず正解に辿り着くという成功例しか見せないんですね。でもAIが間違った判断をした時にどうやってそれを直すのか？ というアプローチを見せてくれたベンダーはまだいません。Grafana LabsのInvestigationという機能も生成AIを使った新機能ですが、もしも生成AIが間違った時にどうやってそれを修正するのか？ についてGrafana Labsのやり方を教えてください。

Chipouras：生成AIについてはさまざまな方法でその性能を改善しようとしています。でも興味深いポイントは複数のエージェントを使って回答を生成するよりも、一つのモデルと一つのエージェントの組み合わせのほうが、正答率が高いという事実も明らかになっています。またオブザーバビリティの領域ではより多くのデータをフィードすることで性能が良くなることもわかっています。

それは機械学習で言うところのReinforcement Learning Human Feedback、人間のフィードバックによる強化学習とは異なるものですか？

Chipouras：違いますね。どちらかといえばデータを使って正しいコンテキストを与えることで生成AIの性能を上げるという発想です。この部分にはGrafana Labsはナレッジグラフを使ってデータの関係性を理解するというアプローチをとっています。単にオブザーバビリティデータをフィードするのではなく、その関係をコンテキストとして与えるというやり方ですね。これは強化学習とは違う方法です。

システムについて質問します。生成AIのモデルは何を使っているんですか？ ナレッジグラフのグラフデータベースは何で実装されているんですか？

Chipouras：大規模言語モデルとして現在はAnthropicのモデルだけを使っています。OpusやSonnetをさまざまな部分に使っています。ナレッジグラフについてはRedis Graphをグラフデータベースとして使っています。現時点での実装なのでこれがずっとこのままであることを確約するものではありませんが、現在の生成AIの進歩の速さを考えると今の時点で多くのモデルをサポートするという発想よりも、一つのモデルに特化して機能を改善していくという発想でソフトウェア開発を行うほうが有利だと考えています。ユーザーにとっての選択の自由は犠牲になりますが。

将来的にはさまざまなモデルやローカルで実行されるモデルなどもサポートしたいと思っていますが、現時点ではこういう構成になっているということです。

大規模言語モデルを持っていないという状況は他のベンダーと同じで、とあるベンダーのブリーフィングでは彼らはLLMもアイデンティティ関連のソフトウェアも持っていないために、LLMに送るプロンプトをひたすら改善するという発想になっています。アイデンティティ情報を持っていないためにデータに対するアクセスのコントロールも限定的で後付けでやらないといけないという状況です。彼らとしては「コンテキストエンジニアリング」と命名してLLMそのものよりも何をプロンプトとして送るのか？ を改善することで正解に辿り着こうという発想なんですが、それはGrafana Labsも同じですか？

Chipouras：Grafana CloudではRBAC（Role Based Access Control）が実装されていますので、デベロッパーが見てはいけない顧客データにアクセスするということはできないようになっています。コンテキストという部分では、グラフデータを使うことで単に大量のデータを送りつけるというやり方ではないですね。

今回、Chipourasさんのデモでとても感心したことがあります。それはインシデント管理を一人の担当者がやるのではなく、グループで取り組む仕事であるという発想です。これまでの生成AIによるコーディングアシスタントは一人のデベロッパーに対してソースコードやコメントを生成するだけでチームワークでなかったんですね。でもInvestigationsのデモでは生成AIの他にコマンダーやインベスティゲーターという役割が存在し、複数の人間が取り組むということが見せられていました。

Chipouras：はい、我々はインシデント管理をチームで取り組む仕事であると認識しています。我々のデベロッパーはオンコールとしてGrafana Cloudのサポートの仕事を定期的に担当しますが、その際に使っている機能を顧客向けに提供したのがInvestigationsなのです。実際のオンコールのインシデント対応では、必ず複数のエンジニアが組んで仕事をします。一人がメインの担当であればもう一人は影の担当者として働きます。そういう発想なので、デモで複数のエンジニアがアサインされるチームワークとして機能が実装されたのは当然ですね。

もう一つ、あのデモで気付いたことがあります。インシデントの原因を探る中で「ソースコードのここが原因である、これをこうやって修正するべき」という提案を生成AIが行いますが、それは日本のIT部門においては難しいのではないかという疑問です。そもそもオブザーバビリティはオペレーションつまり運用部門の仕事で、ソースコードを修正するのは開発部門、つまり運用ではない部門です。日本では開発と運用が分離されているケースが多いので、運用の人に「このソースコードを修正しろ」と提案されてもそれには対応できないんじゃないかと思いますが、それについては？ もちろん、社内に開発部門を抱えてソースコードの修正から即座に本番環境に適用できる組織になっているケースもありますが、まだ少数だと思います。

Investigationsのデモを行うChipouras氏

Chipouras：それは興味深い認識ですね。確かに運用チームと開発チームが分かれていて運用のエンジニアがソースコードを修正できないという状況は発生するとは思いますが、調査の結果をコンテキストとしてまとめて提示することで運用のエンジニアが開発のエンジニアに修正するための十分な情報を渡すことが可能になるということでもあります。それは必ずしも運用担当者がソースコードを修正できないのが悪いという意味ではありません。

インシデント管理で別の質問があります。インシデントを解決しただけではなくそれを振り返るポストモーテムの機能はあるんですか？ つまり担当のエンジニアではなくその上司が対応を評価したりチームの仕事を数値でみるためにまとめたりするという機能ですが。

Chipouras：それはGrafana Cloudの機能としては存在しませんが、機能追加として実装することは可能だと思います。そこについてはGrafana Labsがやるのではなくサードパーティがアドオンのような形で実装するのがベストだと思いますね。Grafana Cloudはドキュメント管理のソフトウェアではないので、実際にドキュメントを保存するための機能はありません。でもサードパーティがそれらの機能を付加価値として提供するのは良い方向だと思います。すべてのインシデント管理に関するデータはGrafana Cloudに存在しますので、それを使ってGitHubやNotionなどと連携してドキュメントを作るということは可能です。

最後の質問です。自動運転システムのコンテキストでは、すべての環境のデータをリアルなデータだけで自動運転のシミュレーションはできないため、いかにリアルなデータから合成データを作って自動運転のテストをするのか？ というのがAAAIでもSIGGRAPHでも話題になっていました。つまりリアルな運転データだけでは雨や霧、強風などの天候の状態、朝なのか夜なのか、そして混雑した都市部なのか郊外なのか、歩行者や自転車、バイクで混雑しているというような状態をテストすることができないために、リアルなデータから合成してテストに使う必要があるという点です。これをデータセンターの運用に置き換えてみると、さまざまな障害のオブザーバビリティデータを使って複合的に障害をシミュレートして運用部門での対応や原因分析に使うという発想になるかと思います。実際にはカオスエンジニアリングに近いテストケースだと思いますが、そういうシミュレーションをクラウドの中で行うという発想はないんでしょうか？

Chipouras：それは面白い発想ですね。テストのシミュレーションという意味ではK6というオープンソースのソフトウェアがあります。K6はさまざまな状況に応じてクラスターのロードテストを実施したり、デベロッパーがローカルでアプリケーションをテストしたりすることが可能です。その延長線として実際に想定されたテストをシステムに実行してみるということは可能だと思います。

やや面倒くさい質問にも丁寧に答えてくれたMarc Chipouras氏は翌日のMeetupにも参加し、Grafanaコミュニティとも活発に交流を行っていた。オープンソース発祥ではあるもののクラウドサービスに先端的な開発を集中させ、顧客のニーズに応えようとする姿勢は好感の持てるものだった。オープンソースとクラウドサービスの両面を持つGrafana Labsであるが、何よりも企業としての持続を優先するならばクラウドサービスを優先する戦略は正しいだろう。社内にはOpen Telemetryのコミュニティに力を注ぐTed Young氏のようなコミュニティリーダーも存在し、バランスを取りながらコミュニティ活動と営利活動の双方を推進するGrafana Labsの活動に注目していきたい。