これまでのオブザーバビリティ UI は過去のものに。次に来るものは何か？

私たちが目にする中で最も満足度の高いオブザーバビリティユーザーは、ほぼ例外なく独自のUIを構築した人たちです。ClickStackを開発し、どの機能の優先度を高めるべきか検討する中で、これは繰り返し現れるテーマでした。

核となるワークフローは一部のニーズを十分にカバーしています。しかし、特定のビジネス、チーム、あるいは調査方法に適合した使い勝手を求める要望のロングテールが常に存在します。他のすべてのユーザーに対して製品を複雑にすることなくそうしたニーズに応えることは、プロダクトマネージャー(PM)にとってはおなじみの、プロダクト設計における葛藤です。

しかし、AIを用いてオブザーバビリティアプリケーションを生成することは、このジレンマからの脱出策になるかもしれません。既存の画面に合わせて質問を作り直すのではなく、自分たちの質問に合わせて体験を形作ることができるようになるのです。

私たちは、オブザーバビリティUIをゼロから構築するリソースがなくても、すべてのユーザーが独自の体験を得られるように「ClickHouse Observability Apps」を開発しました。これは、ライブデータ上で動作するインタラクティブなアプリケーションであり、相互に連携した画面、カスタムの可視化、そしてダッシュボードにとどまらないワークフローを備えています。既存の調査用APIやコアコンポーネントを再利用し、確立されたクエリロジックと一貫した動作を、チームが作成する体験へと取り込みます。

誰もが独自のUIを求めていた #

ここ数年、Anthropic、DoorDash、Tesla、Netflixなどの企業が、ClickHouse上に独自のオブザーバビリティ体験を構築する様子を見てきました。それらの企業は自社のシステム、チーム、そして答えるべき質問を中心に体験を形作っています。ワークフローが足りなければ、自分たちで作るだけです。こうしたチームに対してベンダー提供のUIを使うよう説得するのは、Vimユーザーに対して「こちらのほうがメニューがきれいだから」とエディタの乗り換えを勧めるようなものです。

すべての企業に自前のオブザーバビリティUIを構築するリソースがあるわけではありませんが、自社のシステム、ビジネスプロセス、そして重要な顧客体験の流れ(カスタマージャーニー)を反映した体験は各社に必要です。社内においても、その体験はそれを利用する人々に適合していなければなりません。決済エンジニアは決済プロセッサの成功率から調査を始めるかもしれませんし、サポート担当者は顧客の未完了の注文から、インフラチームはチェックアウトの背後にあるサービス群から始めるかもしれません。基盤にある同じデータに対して、それぞれ異なるアプローチが必要です。ベンダーがすべての組み合わせを予測して作り込んでおくことを期待するのは、現実的ではありません。

また、ユーザーからは常に相反する意見が寄せられていました。機能のごく一部しか使っていないにもかかわらず、既存のツールが複雑すぎると感じるユーザーがいる一方で、私たちが提供していない可視化やワークフローを求めるユーザーもいました。後者のグループが求めるものをすべて作ろうとすれば、前者のグループが逃れたがっている複雑さをまさに生み出してしまうリスクがありました。

そこで、別のアプローチを試すことにしました。チームが必要な体験を自ら生成できるように、ClickHouse Observability Appsを構築したのです。自然言語でアプリケーションを説明すると、エージェントがClickHouse Observability内にアプリケーションを構築し、ライブデータに対する独自のビューとナビゲーションを提供します。対話を通じて調整し、質問が変わるにつれて適応させ、チーム内で共有できます。

具体例としていくつかご紹介します。これらは多少作り込んだ例ですが、私たちがユーザーから受ける要望の傾向を概ね反映しています。

支えているカスタマージャーニーを通じてインフラを把握する #

「チェックアウトやサインインといった重要なユーザージャーニーを中心に、インフラマップを一覧化して可視化するアプリを作ってください。ジャーニーを選択してその依存関係を確認し、それが支えているジャーニーや機能に基づいて各コンポーネントの重要度を把握できるようにします。コンポーネントに障害が発生した場合は、どのジャーニーが影響を受け、ユーザーにとって何がリスクにさらされるかを表示してください。日常的なインフラの把握にも、インシデント時の影響評価にも役立つものにしてください。」

コンポーネントの重要性は、顧客がそれを何のために使っているかによって決まります。製品自体にそうした機能が備わっていなくても、カスタムの可視化によってその関係性を浮き彫りにできます。すべての顧客のアーキテクチャ、共有サービス、ビジネス上の優先順位、あるいは必要とされる正確な可視化の形を予測できるベンダーは存在しません。ベンダーに対して「他の十分な数の顧客も同じものを求めている」と納得させる労力をかける代わりに、自社のチームでそうした詳細を反映したビューを構築できるようにするべきです。

フィーチャーフラグのロールアウト後に何が変わったかを調査する #

「アプリケーションやインフラのKPIと並行して、フィーチャーフラグの値を追跡するアプリを作ってください。変更を選択し、影響を受けたテナントを比較し、パフォーマンス低下の背後にあるリクエストを調査できるようにします。」

エンジニアはロールアウト後のレイテンシを調査するかもしれませんし、サポートは影響を受けた顧客を特定する必要があります。それぞれが自らの担当業務に合わせてアプリケーションを適応させ、新たな疑問が生じた際にはビューを追加したり調査内容を変更したりできます。1回のロールアウトのためだけにこのアプリを作成し、疑問が解消したら破棄するだけでも十分価値があるでしょう。あるいは、同僚と共有し、ブランチを切り、日常的に使うツールへと改良していくこともできます。

失敗した決済の最終的な結果までを追跡する #

「各決済プロセッサの通常率と比較した、クレジットカード種別ごとの決済成功率のビューを作ってください。失敗から影響を受けた注文やそのトレースへとドリルダウンできるようにします。影響度合いや、それらの注文が最終的に成功したかどうかを分析してください。過去36時間のログ、トレース、メトリクスを対象とします。」

チームは画面の構成、画面同士の連携方法、そして調査の各ステップで何が起きるかを自在に制御できます。プロセッサの比較から影響を受けた注文へ、さらに注文の履歴へ、そして見慣れたトレースビューアーへと、関連するフィルターや時間範囲を全体で引き継ぎながら遷移します。これは単なるダッシュボードの生成にとどまりません。チームが必要とする作業方法に合わせて、ライブデータと再利用可能な調査ツールをアプリケーションが結合してくれるのです。

SQLが可能にする分析 #

これらのアプリケーションには、データに対して自由に問いを投げかけられる柔軟性が必要です。固定的なクエリエンドポイントに制限されたアプリでは、そのエンドポイントがすでに提供している回答を再パッケージすることくらいしかできません。基盤となる分析が問いに答えられなければ、別の可視化を用意しても意味がないのです。

ClickHouseのSQLサポートを活用することで、私たちははるかに先へ進む余地を得ることができました。決済アプリケーションでは、各プロセッサのベースラインを計算し、決済の試行と注文を紐付け、最終的に回復した失敗がどれかを判断する必要があります。それらの結果を注文データと組み合わせることで、まだ完了していない購入の金額規模を明らかにできるかもしれません。そうしたビジネスロジックは、どこかで表現されなければなりません。

また、個々の顧客、注文、テナント、リクエストを横断した探索も求められます。次の質問では、特定のデプロイや、誰も予想していなかった属性の組み合わせが関わってくるかもしれません。データとクエリエンジンは、調査を支えるのに十分な詳細度と応答性を備え、高カーディナリティの探索をサポートできる必要があります。

一部のユーザーはすでに自分たちでこれを行っています。私たち自身のオブザーバビリティチームも、既存のツールでは提供されていない可視化を作成するために、Pythonノートブック上でSQLを記述しています。一例として、Plotlyのタイムラインでログ収集の正確な開始と終了を表示し、重複を明らかにするケースがあります。問題の調査を始める前に、チームはそのビューを構築しなければなりませんでした。

ここでは、Plotlyチャートでスクレイプ時間を実時間(ウォールタイム)に対してマッピングし、各長方形がスクレイプの正確な開始時刻と終了時刻にまたがっています。注釈部分はスクレイプの重複期間をハイライトしており、その範囲でデータが重複していることを裏付けています。問題を調査する前に、まずこの可視化を構築する必要がありました。詳細についてはこちらをご覧ください。

エージェントの活用によって、この能力をより多くの人々が利用できるようになる可能性があります。関連するスキーマとコンテキストが与えられれば、エージェントがクエリを書いてテストし、同僚が探索できるアプリケーションを構築できます。質問が変われば、クエリとインターフェースを一緒に進化させることができ、そのSQLも確認可能です。

課題は、その分析がユーザーの意図した質問に確実に答えているか確認することです。支払いができなかった顧客の数を把握したかったのに、クエリ自体は正常に実行されつつも失敗した試行回数をカウントしてしまっている、ということもあり得ます。以下で述べるように、これは私たちが依然として正しく解決しなければならない主要な課題の1つです。

実現のために他に何が必要か #

生成されたアプリケーションは、私たちの調査ツールやMCPサーバーと同じAPIレイヤーを使用します。ログの検索、トレースの追跡、イベントの比較など、確立された操作を再利用できます。私たちが正確性とパフォーマンスのために注ぎ込んできた成果はこれらのアプリケーションにも引き継がれ、その上に構築される体験全体で共通の操作の一貫性が保たれます。

その基盤にあるのが、ログ、トレース、メトリクスが単一のデータストアに共存する共通データレイヤーとしてのClickHouseであり、クエリエンジン内での相関分析を可能にします。既存のツールの枠を超える分析が調査に必要な場合、エージェントはSQLを使用してシグナルを結合し、ビジネス固有のロジックを適用し、他のデータセットを探索できます。その際、実行されるクエリはいつでも確認可能です。

OpenTelemetryもまた、データが何を意味するのかについての文書化されたモデルを提供してくれます。そのセマンティック規約は、リソース、ログ、トレース、メトリクスにわたる属性名、型、意味、期待される値を定義しています。それらの規約に従っているテレメトリに対しては、エージェントがスキーマを解釈してクエリを作成する際の仕様として機能します。チームが利用可能なデータソースに関するコンテキストと組み合わせることで、エージェントが推測しなければならない範囲を減らすことができます。

同じ原則がインターフェースにも当てはまります。エージェントは再利用可能なUIコンポーネントをインポートし、既存の調査ツールに接続できます。私たちがすでに構築した動作やスタイリングを再利用しながら、課題に合わせてチャート、コントロール、詳細ビューを組み立てることができます。これにより、生成してチェックすべきコード量が減り、より一貫性のあるアプリケーションが実現します。

境界の中で生成アプリに自由を与える #

エージェントは、チームのデータソース、スキーマ、およびClickStackでのOpenTelemetryデータのクエリ方法に関するコンテキストから作業を開始します。また、Apps SDKを使用してアプリケーションを構築するための指示も受け取ります。クエリをアプリケーションに組み込む前にClickHouseに対してテストを行い、リンターチェックによって一般的なSDKやスタイリングの誤りを検出します。

生成されたアプリは、ブラウザ内のサンドボックス化されたiframe内で動作します。ネットワークリクエストの実行、他へのページ遷移、未承認のスクリプトの読み込み、ClickStackセッションの直接読み取りなどは行えません。代わりに、クエリの実行、トレースやログのドロワーの表示、タイムピッカーの変更といった特定のアクションを要求するメッセージを送信します。ClickStackはそれらのメッセージを検証し、許可されたアクションを実行して結果を返します。

クエリは読み取り専用であり、閲覧しているユーザーのデータベース権限で実行されます。アプリを共有しても、作成者のアクセス権限まで共有されるわけではありません。こうした境界の内部で、ライブデータとなじみのある調査ツールを利用できます。

そこから、エージェントに対してアプリケーションの変更、修正、あるいは別のアプローチの探索を依頼できます。もしエージェントによる改善が裏目に出た場合でも、即座に以前のバージョンへロールバックできます。

私たちが依然として正しく解決すべき課題 #

クエリが正常に実行されても、間違った質問に答えてしまっていることがあります。支払いに失敗した試行回数をカウントすることは、支払いができなかった顧客の数をカウントすることと同じではありません。クエリのテストやコードのチェックによって一部のミスは捕捉できますが、それによってアプリケーションがユーザーの意図を反映していることまでは証明できません。

私たちは、その適合性を測定するための評価手法の改善を続けており、その結果をエージェントのコンテキスト、指示、ツールの改善に活用しています。また、ブラウザベースのインタラクションテスト、より強力なリントおよび型チェック、敵対的レビューの実現に向けても取り組んでいます。目的は、ユーザーが気づく前にエージェント自身が自分のミスを発見できる優れた手段を提供することです。 RBACとサンドボックスによって強制的な境界が提供されますが、ベータ版に向けてプロンプトインジェクションに対する堅牢性を引き続き向上させていく予定です。現在、クエリ結果、既存のアプリコード、過去のユーザーのプロンプト、エラーメッセージを明示的に信頼できない入力として扱っています。ログエントリに指示が含まれている可能性はありますが、それがシステムに命令を下せるわけではありません。これによりリスクは低減しますが、この機能がプライベートプレビューにとどまっている間は、完全に解決された問題とは位置づけていません。

また、エージェントがすべてのチャートやフィルターをゼロから考案しなくても済むよう、確立されたクエリロジックと動作を備えた再利用可能なコンポーネントを拡充しています。さらにその先では、各チームがMCP経由の独自のエージェントやConfiguration as Code(コードとしての構成管理)を通じてアプリを構築・管理できるようにしたいと考えています。

既存のオブザーバビリティUIでは答えられない質問をお持ちください #

現在プライベートプレビュー中のObservability Appsは、SQLの力をチームの手にもたらします。質問を説明し、エージェントに分析を構築させ、同僚が自分たちでクエリを書くことなく探索できるインタラクティブなアプリケーションへと変換しましょう。

既存の画面には収まらない、一風変わった問い、ビジネス固有のロジック、そして特殊な調査の数々が寄せられることを楽しみにしています。

SQLは問いを投げかける自由を与えてくれます。インターフェースは、探索する自由を提供するべきです。