Platform Engineeringチームの松尾です。
先日開催されたGrafana Observability CON 2026 Tokyo に参加しました。
Grafana Observability CONはオブザーバビリティ構築OSSの代表格であるGrafanaを開発するGrafana Labが、自社展開するSaaSのGrafana Cloudについての広報・ユーザーのネットワーキングを促進するイベントです。
今回のイベントで特に印象的だったのは、Grafana Cloud が単なるダッシュボード基盤ではなく、インシデント対応や根本原因分析、さらには AI を活用した運用支援まで含めたプラットフォームとして進化していることでした。
私たちのCavor環境*1では OSS の LGTM スタック*2を運用していることもあり、Grafana Cloud が提示していた方向性を「すでに持っている構成をどう発展させるか」という視点で聞く場面が多くありました。
本記事では、発表内容を網羅的に紹介するのではなく、特に印象に残ったトピックを振り返りながら、実運用にどう活かせそうかという観点で整理します。
あわせて、以前公開した「オプティムにおけるPlatform Engineeringの現在地」でも書いた通り、Cavor では Monitoring を含む共通基盤の整備や、テナントの品質可視化、改善アシスト、使いやすさや性能の向上を継続して進めています。今回のイベントで見えた方向性は、そうした取り組みの延長線上で今後を考えるうえでも示唆が多いものでした。
イベント全体から見えた変化
全体を通して感じたのは、オブザーバビリティの重心が「とにかくデータを集めて可視化する」から、「必要なデータを適切に扱い、すばやく判断につなげる」方向へ移っていることでした。
キーワードとして特に目立っていたのは、以下の領域です。
Knowledge Graphによるシステム構成とシグナルの接続RCA Workbenchを使った根本原因分析の高速化Grafana Assistantやエージェント型 AI による運用支援Adaptive Telemetry/Adaptive Traceによるコスト最適化Instrumentation Hubを通じた OpenTelemetry 導入支援- フロントエンド観点を含めた E2E の可観測性
これまでの「監視ツール」という位置づけよりも、「運用判断を支援する基盤」としての Grafana を強く打ち出していたように感じます。
印象に残ったトピック
Knowledge Graph と RCA Workbench
今回の発表の中で、特に気になったのは Knowledge Graph でした。
これは単にメトリクスやログを並べるのではなく、システム内の各コンポーネントがどうつながっているかを Grafana 側で把握し、その構造と観測データを結びつける考え方です。これにより、インシデント発生時に「どこで何が起きているのか」を構成情報込みで辿りやすくなります。
デモでは、incident から RCA Workbench に入り、関連するリソースの KPI を一覧し、その先でデータベースの遅延や slow query に辿り着くまでの流れが非常にスムーズでした。問題の兆候を見つけるだけでなく、根本原因に到達するまでの導線そのものが設計されている点が印象的でした。
運用の現場では、ダッシュボードやアラートは整備されていても、そこから先の調査は人に依存しやすいものです。Knowledge Graph の価値は、その属人的な調査導線を短縮できるところにあると感じました。
Grafana Assistant とエージェント型 AI
AI 関連では Grafana Assistant や investigation の仕組みが紹介されていました。
Slack から調査観点を投稿し、エージェントに調査を進めさせるような世界観は、単なるチャットボットというより、運用導線に AI を組み込む試みとして興味深いものでした。画面横断で情報を参照できること、過去事例や関連情報にアクセスできることが前提になるため、単発の質問応答ではなく、運用ナレッジの活用基盤として効いてきそうです。
一方で、こうした仕組みを活かすには、Grafana 側に十分な情報が集約されていることが前提になります。AI が賢いかどうか以前に、構成情報やテレメトリ、アラート、インシデント情報がきちんと整備されているかが重要だと改めて感じました。
Adaptive Telemetry / Adaptive Trace
コスト最適化の文脈では、Adaptive Telemetry や Adaptive Trace がとても実践的でした。
オブザーバビリティでは「取れるものは全部取る」に寄りがちですが、実際には価値の低いテレメトリまで大量に保持してしまい、コストと運用負荷の両方を押し上げることがあります。発表では、収集したテレメトリを機械学習で選別し、有用なものに絞り込むことでコストを下げる考え方が紹介されていました。
特に印象的だったのは、単にコストを下げるための間引きではなく、「必要なデータを維持しながら、保持期間や運用性も改善する」という文脈で語られていた点です。ラベル数やカーディナリティが増えがちな環境では、こうした仕組みの価値は大きいはずです。
監視コストの最適化を考えるとき、保存量だけでなく、取り込み量や処理量まで含めて見直す必要があります。その意味でも、Adaptive 系の機能は今後かなり重要な論点になりそうでした。
Instrumentation Hub と OpenTelemetry 導入支援
OpenTelemetry まわりでは、導入と運用の難しさが改めて強調されていました。
OpenTelemetry は柔軟である一方、構成要素が多く、広いカバレッジを取ろうとすると継続的なメンテナンス負荷が高くなりがちです。実運用では、Collector やエージェントの設計、収集対象の選定、各種権限や配布方法まで含めて考える必要があり、「入れれば終わり」になりません。
その点で、Instrumentation Hub から Alloy をクラスターに導入していく流れは、運用負荷を下げる方向性として現実的に見えました。OpenTelemetry を正しく運用するためのハードルを、プロダクト側で少しずつ吸収しようとしているのだと思います。
フロントエンド観点の可観測性と k6
もう一つ印象に残ったのが、ユーザー体験の観測でした。
バックエンドやインフラのメトリクスは見えていても、実際のユーザーがどの程度快適に使えているかは別問題です。発表では、100ms, 1s, 10s といった体感の閾値にも触れながら、フロントエンド観点の監視や k6 を使ったパフォーマンステストの重要性が語られていました。
E2E でサービスを捉えるのであれば、アプリケーション、データベース、インフラだけでなく、ユーザーが実際に体験している品質も監視対象に含めるべきです。オブザーバビリティを「システムの状態監視」ではなく「サービス品質の把握」として考えるなら、ここは今後ますます重要になると感じました。
実運用に引きつけて考えたこと
今回の発表内容はどれも魅力的でしたが、そのまま導入できるものと、前提条件の整備が必要なものは分けて考える必要がありそうです。
まず、Knowledge Graph や AI を活用した調査支援は非常に魅力的です。ただし、それを機能させるには、各種リソースの関連付け、メトリクス・ログ・トレースの整備、インシデント情報の集約といった基盤側の準備が欠かせません。Cavor で OSS の LGTM スタックを運用している立場から見ても、観測データが散在している状態（データがあるがその相関メタデータがない）では AI の恩恵は限定的になりそうですし、まずはデータのつながりをどう作るかが重要だと感じました（Grafana上で作成された相関データをAgentのコンテキストサイズにトリミングして処理するデータパイプラインの構築が必要そうなので、一朝一夕でこの基盤を用意するのは難しいとも思いました。）。
一方で、比較的現実的に取り組みやすそうだと感じたのは、テレメトリ最適化の考え方です。すでにラベル数や収集量、保持期間のバランスに悩んでいる環境では、Adaptive Telemetry の方向性そのものが参考になります。特定の機能をそのまま採用するかどうかに関係なく、「何を残すべきで、何を減らせるか」を見直すきっかけになります。これは OSS の LGTM スタックを運用している場合でも同じで、クラウド機能をそのまま使えないとしても、設計思想自体は十分に取り入れられそうです。
また、E2E 観点のオブザーバビリティも重要です。アプリケーションのレスポンスやエラーレートだけでなく、データベースやフロントエンドも網羅的に含めて見られるようになると、障害調査の精度は大きく向上します。Profile や DB 監視まで含めた導線は、今後の改善候補として意識しておきたいところです。
このあたりは、前述の記事で触れている「テナントの品質の可視化」「品質の改善アシスト」「ガードレールの強化」ともつながる話です。監視項目を増やすこと自体が目的ではなく、共通基盤としてどう見える化し、どう改善につなげるかという観点で考えると、今回紹介されていた Knowledge Graph や AI 支援、テレメトリ最適化のアプローチはかなり参考になりました。
すぐに試したいことと、まだ難しそうなこと
今回のイベントを踏まえて、比較的早く検討できそうだと思ったのは次のような点です。
- テレメトリの収集方針を見直し、価値の低いデータをどこまで削減できるか整理する
- DB 監視や Profile 活用の余地を確認し、調査導線を改善する
- フロントエンド観点の監視や
k6による性能検証を、オブザーバビリティの一部として扱う
一方で、すぐに取り込むのは難しそうだと感じた点もありました。
- 現行構成のままで
Grafana Assistantのような AI 活用を深く進めること
特に AI 活用については、機能そのものよりも、その前提となる観測基盤の整備状況が効いてきます。まずはデータの質と関連付けを改善しないと、AI を導入しても十分な効果は出しにくそうです。
まとめ
Grafana Observability CON 2026 Tokyo を通して見えてきたのは、オブザーバビリティが「監視」から「運用支援」へ進んでいることでした。
Knowledge Graph や RCA Workbench は、障害調査の導線を大きく変える可能性がありますし、Adaptive Telemetry はコストと運用負荷の両方に効く、非常に実践的なテーマでした。AI 活用も魅力的ですが、それを支える構成情報やテレメトリ設計の重要性を改めて認識する機会にもなりました。
まずはテレメトリの最適化と、E2E での観測対象の拡張から着手するのが現実的だと感じています。そのうえで、将来的に Knowledge Graph や AI 支援を活かせる状態をどう作るかを考えていきたいと思います。
お知らせ
私たちのチームでは、Cavor をはじめとしたプラットフォームやオブザーバビリティ基盤の改善に一緒に取り組む仲間を募集しています。
OSS の LGTM スタック運用や、監視基盤の設計、OpenTelemetry、運用改善、開発者体験の向上といったテーマに関心がある方は、ぜひ採用情報もご覧ください。
