Grafana Cloudのフルスタックオブザーバビリティ：つながりとコンテキストを広げ、人とAIエージェントの調査を速くする

多くのチームは、スタック全体からテレメトリーを集めています。しかし、それらのシグナルを結び付けて、何が起きているのか、ユーザーにどう影響するのかを理解するのは、簡単ではありません。サービスの依存関係、オーナーシップ、過去のインシデントといった重要なコンテキストは、さまざまなツールやランブック、チームメンバー同士の会話に散らばっていることが少なくありません。

本日、ObservabilityCON 2026で、Grafana Cloud全体でフルスタックのオブザーバビリティ（可観測性）を前進させる新機能を発表します。この体験を支えるのが、Knowledge Graphです。Knowledge Graphは、Grafana Cloudにおける実行時のコンテキストレイヤーで、システムの構成要素、それらの関係、健全性に関するインサイトを、1つの連結したビューにまとめます。

Grafana Labsは、Knowledge Graphの対象を、より多くのインフラ、アプリケーション、ユーザー向けのシグナルに広げています。あわせて、サービスカタログ、オンコール担当のチーム、過去のインシデントで得られた教訓など、より幅広い運用上のコンテキストも取り込みます。

これらのつながりにより、人とAIエージェントは、システムがどのように組み合わさっているかについて、オープンスタンダードに基づいた同じ共通のコンテキストを持てます。その結果、トラブルシューティングや根本原因の特定を、より速く進められます。

「調査で最も難しい課題が、データの不足そのものであることはまれです。課題は、複雑なエコシステム全体で、サービスの担当者や担当チーム、依存関係、運用知識、顧客への影響を結びつけることです。」と、LexisNexis Risk Solutionsのソフトウェアエンジニアリング担当シニアディレクターであるNeil Wilson氏は述べています。「［Knowledge Graph上の］エンティティグラフの関係は、それらのつながりを可視化し、エンジニアとAIシステムの両方がデータから理解へ、そしてアクションへと移行するために必要なコンテキストを提供します。」

Grafana Cloudを、SREのスペシャリストだと考えてみてください。Grafana Assistantを使う場合も、gcxで独自のエージェントを持ち込む場合も、必要なときに、その専門知識をすぐに使いたいはずです。調査の前半を、すべてがどう組み合わさっているのかを組み立て直すことに費やしたくはないでしょう。Grafana Labsがフルスタックのオブザーバビリティで目指しているのは、Knowledge Graphを基盤とした、より速く、より信頼でき、よりコスト効率の高い回答です。

システムをつながった形で見る：フルスタックをさらに広く

Knowledge Graphは、すべてのスタックで利用できるプラットフォーム機能へと進化しています。Grafana Cloud全体のコンテキストを、ここで整理できます。

これまでKnowledge Graphは、Grafana Cloud Application Observability、Kubernetes Monitoring、Database Observability、Cloud Provider Observabilityに対応してきました。これらのソリューションは、サービス、Pod、ノードなどのそれぞれのエンティティを自動で検出し、エンティティとその関係をKnowledge Graphにマッピングします。さらに、エンティティの健全性を監視し、そのインサイトをグラフに追加します。動的なベースラインからの逸脱から設定の変更まで、さまざまな変化を浮かび上がらせます。

そして今、そのフルスタックの全体像をさらに広げ、環境のより多くの要素をKnowledge Graphに取り込んでいます。

• フロントエンドアプリ（一般提供）：Frontend Observabilityが、フロントエンドアプリとユーザー向けのシグナルを、その背後にあるサービスやインフラにマッピングします。
• シンセティックチェック（パブリックプレビュー）：Synthetic Monitoringのチェックからのアラートが、サービスの健全性と並んで表示されるようになりました。問題をすばやく見つけ、調査を速められます。
• Google Cloud、AWS、Azureのクラウドリソースの追加（一般提供）：Cloud Provider Observabilityが、Google Cloud、AWS、Azureのより多くのリソースをマッピングし、クラウドインフラのより完全な全体像を提供します。
• AIエージェント（パブリックプレビュー）：Agent Observabilityが、AIエージェントを、その依存先とあわせてマッピングします。エージェントがシステムの他の部分とどうつながっているかを確認できます。
• Microsoft SQL Serverデータベース（プライベートプレビュー）：Database Observabilityが、SQL Serverデータベースを検出し、自動でマッピングするようになりました。

これらのアップデートにより、ユーザー向けのアプリから、その背後にあるサービス、データベース、インフラまで、スタックのより広い範囲にわたって問題を調査できます。

テレメトリーだけではわからないコンテキストを、Knowledge Graphに

システムがどう組み合わさっているかを知ることは重要ですが、問題を効果的に調べるには、組織に固有のコンテキストも必要です。どのチームがどのサービスを担当しているのか、それらのサービスが製品やビジネスプロセスをどう支えているのか、過去のインシデントから何を学んだのか、といった情報です。

こうしたコンテキストをKnowledge Graphにさらに取り込み、エンジニアリングチームと、日々いっしょに働くAIエージェントの両方が利用できるようにします。

サービスのコンテキスト：Grafana Cloud Service Centerで、サービスをオーナーと結び付ける

テレメトリーが実際に動いているものを表すのに対し、サービスカタログは、自分たちの組織が理解している言葉でシステムを表します。この2つを結び付けると、調査の際に、デプロイされたコンポーネントから、それが属するサービス、担当チーム、そのチームが管理しているガイドへとたどれるようになります。

Knowledge GraphとGrafana Cloud Service Centerの新しい連携（現在プライベートプレビュー）により、これらのつながりがグラフ上に加わります。サービスのオーナーシップ、オンコールのスケジュール、ランブックを、それぞれが支えるコンポーネントと並べて確認できます。

たとえば、Everyday Checkingという架空の銀行アプリを考えてみましょう。このアプリは、口座管理とカード決済のサービスで動いています。口座開設が遅くなった場合、どのデプロイメントが影響を受けているのか、どのチームが担当しているのか、誰がオンコールなのか、口座開設のランブックがどこにあるのかを知る必要があります。これらの情報がすべてKnowledge Graphでつながっていれば、エンジニアやエージェントにとって、はるかに役立つ出発点になります。

チームのコンテキスト：Grafana Assistantで、カスタムエンティティを追加する

チームには、自動検出では推測できない知識があります。口座管理とカード決済は、Everyday Checkingアプリに属しているかもしれません。いくつかのサービスが、特定のオンライン製品やビジネスプロセスを支えているかもしれません。こうした関係を、Knowledge Graphを通じて、組織の全員が利用できるようにするべきです。

そのために作ったのが、現在一般提供されているカスタムエンティティとリレーションシップです。テレメトリーに基づいてルールを定義し、必要なエンティティを作成して、Knowledge Graphのほかの部分と結び付け、健全性のインサイトを付けられます。たとえば、複数のサービスがproduct_line="everyday-checking"というラベルを共有している場合、そのラベルを使って、それらを新しいEveryday Checkingという製品エンティティにまとめられます。

また、現在一般提供されているGrafana AssistantのKnowledge Graphモードを使って、これらのカスタムエンティティとリレーションシップの定義を進められます。製品のモデル化の方法を尋ねたり、カスタムルールを書いたり、足りないつながりを調べたりすると、Assistantが手順を案内します。

運用上のコンテキスト：前回の調査を、次の調査に生かす

最も役立つ運用上の知識の一部は、何かがうまくいかなかったときに生まれます。たとえば、誰かが仮説を検証して否定したり、再起動で改善したように見えてもエラーが再発したり、ある設定変更でようやくサービスが復旧したりします。調査が終わるころには、チームは最終的な根本原因よりもはるかに多くのことを学んでいます。

Grafana Cloud IRMとの連携により、そうした教訓を運用上のコンテキストとしてKnowledge Graphに取り込みます（現在プライベートプレビュー）。これは、サービスにインシデントの要約を添付するだけのものではありません。調査中に記録された証拠から、仮説、対応、その結果を抽出し、システムの関連する部分に結び付けます。

Everyday Checkingの例に戻りましょう。チームが再起動を試したものの、エラーが再発し、その後、データベースのコネクションプールの設定を元に戻すことで口座開設を復旧させたとします。次の調査では、その履歴を使って、同じ条件が当てはまるかどうか、もう一度再起動を試す価値があるかどうかを確認できます。以前のインシデントが、現在のテレメトリーと照らし合わせて検証すべき手がかりになるのです。

実行時のコンテキスト：AIエージェントも人も、同じ理解から調査を始める

Knowledge Graphに表れるつながりの1つ1つが、チームにより有用な問いを立てられるようにします。この製品を支えているのはどのサービスか。影響を受けているのはどのデプロイメントか。誰が担当しているのか。前回同じことが起きたとき、何を試したのか。

人は、Grafana Cloudでこうしたつながりを確認できます。そして今、AIエージェント向けの実行時コンテキストとしてのKnowledge Graph（一般提供）により、Grafana Assistantや、gcxで接続した独自のエージェントも、システムについての同じ共通の理解をもとに作業できます。

「レイテンシのアラートが発火し、続いて下流のHPCCシステムで2つ目のアラートが発火しました。本当の問題は、外部ベンダーへの呼び出しが、データベース層のコネクションプールを使い果たしていたことでした」と、LexisNexis Risk SolutionsのWilson氏は話します。「AssistantがKnowledge Graphをたどって、その根本原因にずっと早くたどり着けました。チームがすでに進み始めていた別の調査の道筋からも、引き戻してくれました」

新しいCypherクエリツールでは、エージェントが、システムのつながりについてKnowledge Graphに直接質問することもできます。Cypherは、標準的なグラフクエリ言語です。たとえば「このデータベースを呼び出しているすべてのサービスと、それらが動いているPod」のようなパターンを記述すると、一致したものが、その関係と現在の健全性とともに返ってきます。これにより、エージェントは、毎回生のテレメトリーから組み立て直すのではなく、すでに利用できるコンテキストを土台にできます。

今すぐ始める

システムと運用上の知識が、Knowledge Graphを通じてより多くつながることで、人もAIエージェントも、すべてがどう組み合わさっているかを、よりはっきりと把握できます。コンテキストをつなぎ合わせる時間が減り、根本原因をより速く見つけられます。

さっそく試してみましょう。Grafana Assistantに「Knowledge Graphをもっと活用するには？」と尋ねれば、スタックに合わせた具体的な推奨が得られます。注：変更によっては、管理者権限が必要な場合があります。

この記事で紹介したプライベートプレビュー（Microsoft SQL ServerデータベースのKnowledge Graphへのマッピングなど）を利用するには、こちらのフォームに記入してください。詳しくは、Knowledge Graphのドキュメントを参照してください。

ObservabilityCON 2026が開幕しました！ 主要な発表をまとめたブログ記事もチェックしてください。

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