オブザーバビリティとエージェント型AI - データ探索から答えへ -

本スライドは、Open Source Summit Japan 2025のセッションで使用したスライドです。

長年、オブザーバビリティは、データを集め、クエリを書き、点在する情報をつないで理解する作業でした。ログを grep し、ダッシュボードを作り、手動で状況を追う——こうした流れは、OpenTelemetry のような標準や SPL / PromQL といった言語があっても、本質的には「エンジニアが何を調べるべきかを知っている」ことが前提でした。

このトークでは、「データを問い合わせる」から「答えを得る」への転換を取り上げます。
ログ検索から構造化テレメトリーへと進化してきた観測の歴史をたどり、今後に必要な要素——ワイドイベント、サンプリングしない高カーディナリティデータ、そして高速かつスケーラブルなクエリエンジン——を示します。

さらに、エージェント型AIがどのように調査を支援し、異常を解釈し、実際のテレメトリーに基づいて自然言語でトラブルシュートできるかを、標準化したモデル／プロンプトのベンチマークとサンプルデータセットを使って紹介します。

同時に、AIが観測のあり方そのものをどう変えつつあるのか、そして現時点での限界やエージェント依存の課題についても考察します。

Transcript

1. 2025.12 オブザーバビリティとエージェント型 AI - データ探索から答えへ - Miki Matsumoto Senior Support Engineer
2. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 2 About me • ClickHouseの日本人社員第１号 • 現在はSAやTechnical Supportをメインに担当 • 最近の10年+、主に大規模で分散システムの SREやプロフェッショナルサービスを中心に活動
3. ClickHouse の紹介
4. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 4 ClickHouse とは? ClickHouseは、 オープンソース の 列指向 OLAP データベース です。 膨大なデータを 超高速 で 分析するために設計されています。 簡単にスケール可能 データを超高速で処理できる 高効率なストレージ SQLを流暢に扱える
5. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 5 ClickHouse 世界で最も人気のある分析データベース 2009 プロトタイプ 2016 オープン ソース 2021 ClickHouse Inc. 2022 ClickHouse Cloud DBEngines における 分析OSSデータベースランキング #1 GitHubスター数 44,500 　　　　　　　以上 Cloudを利用している企業数 2,000 　　　　　　　　　　　以上 2024 AWS Tokyo Regionオープン 2025 GCP Tokyo Regionオープン
6. 6 ClickHouse の勢い ClickHouse オープンソース ➔ 44.5万以上のスター ➔ 1,600以上の コントリビュータ ➔ 7,000以上のフォーク 世界で最も人気のある分析データベース 8年経ったけれど、 まだ始まったばかり ➔ 1万人以上のSlackメンバー ➔ 25万人以上のコミュニティメンバー ➔ 約500名のアクティブな コントリビュータ
7. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 7 ClickHouse Cloud の利用状況の推移 わずか３年で2,000超の企業が利用 Tesla
8. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 8 ClickHouse 社が開発しているメジャーな OSSは？ スター数 製品概要 ClickHouse 44.5K リアルタイムDB/DWH LibreChat 32.2K LLMのチャットプラットフォーム HyperDX 9.1K オブザーバビリティプラットフォームのUI + 分析基盤 PeerDB 2.8K DB間の リアルタイム CDC パイプライン chDB 2.5K インプロセス用の ClickHouse
9. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 9 Observability にClickHouse を利用している企業 & many more OpenAI Tesla
10. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 10
11. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 11 • どんなスキーマでも、 ClickHouse 上に数秒でデプロイ • フロントエンドからインフラまで、 オブザーバビリティ向けに設計 • ClickHouse の性能を最大限引き出す最適化 • OpenTelemetry ネイティブ、完全オープンソース ClickStack 高性能なオープンソースの observability stack
12. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 12 ClickStack のアーキテクチャ User Kubernetes Cluster Node ClickHouse App container Container logs & Kubernetes metrics OTel Daemonset OTel SDK OTel collector deployment Kubernetes API HyperDX
13. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 13 DEMO
14. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 14 データ探索から答えへ
15. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 15 AIエージェントは、 優秀なSREになれるのか？
16. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 16 AIエージェントの基盤に ClickHouse を採用する利用 • ドキュメントはすべて公開され、 ベースモデルにすでに学習済み ◦ 追加分のトークンコストはゼロ • 基本的な説明や前提知識をコンテキストに含める必要が減る ◦ トークンが減り、精度向上・コスト削減につながる • モデルは、独自方言ではなく 標準 SQL の生成が非常に得意 ˮContext Rot: How Increasing Input Tokens Impacts LLM Performanceˮ research.trychroma.com/context-rot SQL の理解 公式ドキュメント Github Issues ClickHouseブログ LLM Model ClickHouse コンテキスト
17. 17 100 PB ストレージサイズ 社内のオブザーバビリティ基盤で検証 API LibreChat MCP SREs Observability store 500 兆 レコード 6ヶ月 データ保持期間 LogHouse AI エージェントのアーキテクチャ https://clickhouse.com/blog/scaling-observability- beyond-100pb-wide-events-replacing-otel
18. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 18 いくつかの課題 同じ質問を繰り返しても 少しずつ異なるク エリを生成する。 探索型の分析を続ける中で、その小さな 違いが積み重なり、エージェントが全く別 の方向へ探索を進めてしまう。 基盤モデルはシステムプロンプトで包むと “おしゃべりˮになりやすく、広い検索範囲か ら無理に問題を探そうとします。 その結果、存在しない問題を作り出したり、 軽微な事象を過大評価したりしてしまいま す。 クエリのジッター（揺らぎ） エージェントの過剰探索 LogHouse での経験をもとに
19. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 19 クエリのジッター（揺らぎ） • モデルの知性が高くても、生成されるクエ リに “ジッター（揺らぎ） ˮ が発生 • Temperature(温度)を 低く設定しても、同じプロンプトに 対してわずかに異なるクエリ が 返ってくる 同じプロンプトでも結果が変わる
20. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 20 クエリのジッター 「plum-qa-31 の最近のエラーを確認して」のクエリジッター SELECT toStartOfMinute(event_time) as minute, errorCodeToName(code) as error_name, count() as occurrences FROM loghouse.merge_error_log WHERE spoken_name = 'plum-qa-31' AND event_time >= now() - INTERVAL 2 HOUR GROUP BY minute, error_name ORDER BY minute DESC, occurrences DESC SELECT toStartOfHour(event_time) as hour, level, count() as log_count FROM otel.server_text_log_0 WHERE Namespace = 'ns-plum-qa-31' AND EventDate >= today() AND event_time >= now() - INTERVAL 6 HOUR AND SeverityText IN ('ERROR', 'FATAL') GROUP BY hour, level ORDER BY hour DESC
21. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 21 クエリのジッターの解決方法 MCP 用に専用関数を提供する • クエリをモデルにそのまま作らせる方法は、 遅い・不安定・誤った内容を出しやすい • 専用の機能（ツール）を用意して使わせる方が はるかに安定する • MCP 経由で公開 • 一般的な運用手順（Playbook）に沿って設計 • 必要に応じて 自由な SQL を使った詳細分析も可 能 getExceptionsHistogram(), getK8sReadinessEvents(), getQueryLatencies(), getCPUWaitTimeseries(), getMergesRunning(), getSelectedBytesTimeseries(), getInsertedRowsTimeseries(), getPageCacheHitRateTimeseries(), getAutoscalerEvents(), getServerVersionDistribution() …
22. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 22 エージェントが “余計な問題 ˮを探してしまう課題 基盤モデルをシステムプロンプトで包むと、どうしても “おしゃべりˮ になりがちで、 広い検索空間の中から必ず何か問題を見つけようとしてしまう。そのため、実際に は存在しない問題を 捏造したり、たいしたことのない事象を 過大評価 したりする ことがある。 エージェントの探索範囲が広すぎるため、本質的ではないシグナルを延々と追い 続けてしまう ことも起きる。 • より小さく、焦点を絞ったコンテキストウィンドウ を使う • 汎用エージェントではなく、特定の問題に特化したサブエージェント （例：メモリ問題専門）を用意 • サブエージェントには、関連するプレイブック を提供 （コンテキストに含める、または RAG で補強する形） • エージェントに 重大度（Severity）判定 をさせ、軽微なものは破棄 する 問題 解決策 - 検索範囲を絞る AI AGENT Agentic SRE ORCHESTRATOR AI AGENT Agentic SRE AI AGENT Agentic SRE
23. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 23 DEMO
24. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 24 今後の展開 エージェントをオブザーバビリティワークフローへ拡張 • ClickStack におけるエージェント主導のインシデント調査 ◦ 監視 UI に組み込まれたエージェントが、ログ・メトリクス・トレースを横断して関連シグナルを発見し、調 査を開始 する。 • アラート起点のインシデント調査 ◦ エージェントがアラートを受けて調査を開始し、必要に応じてプレイブックを活用しながら、 あらかじめ定義された探索パスに沿って問題を深掘りする。 • Human-in-the-loop ワークフロー ◦ エンジニアがエージェントの分析内容を ガイドし、検証 することで、精度を保ちながら、検知から解決まで の時間を大幅に短縮。
25. ©2025 CLICKHOUSE INC., CONFIDENTIAL & PROPRIETARY 25 Thanks