Open House のオブザーバビリティ発表：MCP サーバー、AI Notebooks、ClickStack Cloud

Open House イベントでは、ClickHouse コミュニティが 3 日間にわたってワークショップ、技術ディープダイブ、プロダクト発表、デモ、リアルタイムデータの未来についての議論を行いました。イベントでは多くのユーザー、顧客、オブザーバビリティコミュニティのメンバーにお会いできて嬉しく思います。現地に参加できなかった方のために、Open House で共有されたオブザーバビリティに関する発表をまとめます。

ClickStack とオブザーバビリティに関して、3 つの主要なアップデートを発表しました：ClickStack Cloud、AI Notebooks（ベータ版）、そして新しい ClickStack MCP サーバーです。

ClickStack Cloud 最大の発表は、ClickStack Cloud のプライベートプレビュー開始です。ClickStack Cloud は ClickHouse 上に構築されたフルマネージド、サーバーレスのオブザーバビリティプラットフォームです。ユーザーはコレクター、インフラストラクチャのサイジング、スケーリングポリシー、スキーマチューニングを管理する必要がなく、OpenTelemetry データをマネージドエンドポイントに送信するだけで、ClickStack UI を通じてログ、メトリクス、トレースの探索を即座に開始できます。ClickStack Cloud は運用作業を削減しつつ、ClickHouse の高いパフォーマンス特性を維持することを目指しています。詳細は専用のブログ記事をご覧ください。

Managed ClickStack の一般提供開始 ClickStack Cloud のプライベートプレビューに加えて、既存の Managed ClickStack が一般提供開始となりました。Managed ClickStack は、インジェスチョンパイプライン、コンピュートサイジング、ワークロード分離、スキーマ設計、データストアチューニングなど、オブザーバビリティスタックを直接制御したいチーム向けに設計されています。ユーザーは自身の OpenTelemetry コレクターとインジェスチョンアーキテクチャを管理し、ClickHouse Cloud を基盤のオブザーバビリティデータストアとして使用します。大規模なデプロイメントでは、この制御はパフォーマンス最適化と市場をリードするコスト効率の達成に不可欠です。Managed ClickStack と ClickStack Cloud は異なる運用モデル向けです。前者は完全マネージドサーバーレスエクスペリエンスを提供し、後者は深い制御を必要とする組織向けです。

AI Notebooks（ベータ版） また、Managed ClickStack 向けに AI Notebooks のベータ版を発表しました。過去 1 年間で、ほぼすべてのオブザーバビリティプラットフォームが何らかの AI チャット体験を追加してきましたが、チャットだけでは実際のインシデント調査の進め方に合わないと感じるようになりました。プロダクションデバッグは乱雑であり、エンジニアはログ、トレース、ダッシュボード、デプロイメント、仮説の間を行き来します。彼らは後戻りし、並行調査に分岐し、新しいシグナルが現れると以前の前提を再検討します。インシデントがシングルスレッドの会話であることは稀であり、インターフェースもそれを強制すべきではありません。

AI Notebooks は、一時的なチャットセッションではなく、永続的な調査ワークスペースとして設計されています。各調査は、プロンプト、クエリ、チャート、推論ステップ、発見事項の構造化されたシーケンスとなり、プロセス全体で可視かつ編集可能です。エンジニアはノートブックの任意のポイントから分岐して、以前の作業やコンテキストを失うことなく代替理論を探索できます。実際のワークフローは、共同デバッグ体験のように感じられます。

構築にあたり、透明性についても明確な考えを持っていました。プロダクションインシデントでは、特に AI が調査ループに関与している場合、エンジニアはシステムが実際に何をしているのかを理解する必要があります。すべてのクエリ、チャート、推論ステップ、中間結果はノートブック内で可視化されます。クエリを手動で編集したり、独自の検索を挿入したり、提案されたパスを完全に無視して調査を別の場所に持っていくこともできます。AI はバックグラウンドでブラックボックス的な結論を生成するシステムではなく、エンジニアの隣に座る協力者のように振る舞ってほしいと考えました。

内部では、Notebooks は ClickStack のオブザーバビリティプリミティブと最適化された ClickHouse ワークフローの上に直接構築されています。システムは SQL コンソールに LLM をアタッチしているだけではありません。モデルは ClickStack 自体を駆動する構造化調査ツールに対して動作し、最適化された検索、集計、可視化を実行しつつ、生成されたクエリを検査および改良のために公開します。Notebooks はチーム間で共有でき、調査を永続的なコラボレーション成果物に変え、インシデント終了後に消えてしまう使い捨てのチャット履歴ではなくなります。Managed ClickStack をすでに実行しているユーザーは、ClickStack UI の左側のナビゲーションパネルから AI Notebooks にアクセスできます。

最後に、Notebooks の経験は自然と 3 つ目の発表につながりました。ClickStack 内部で構造化調査ワークフローを構築する一環として、新しい ClickStack MCP サーバーを導入しました。これにより、外部の AI システムやエージェントが、Notebooks を内部的に駆動するのと同じオブザーバビリティプリミティブと直接統合できるようになります。

ClickStack MCP サーバー Notebooks に加えて、Open House では AI とオブザーバビリティツールにおけるより広範なシフトについて議論しました。ClickStack 内部の AI 支援調査は重要ですが、チームは ClickStack 内で公開されているのと同じ強力なツールを自身のエージェントで活用したいと考えるでしょう。ユーザーはますます、オブザーバビリティデータを中心に独自のエージェント、プロンプト、ワークフロー、自動化を構築しています。Cursor や Claude Code 内で行う人もいれば、SDK を接続してローカルで内部システムに対してエージェントを実行する人もいます。多くの場合、これらのワークフローを構築するチームはすでにデバッグ方法に強い運用知識を組み込んでおり、ツールがそれを反映することを望んでいます。

私たちの見解では、オブザーバビリティプラットフォームはユーザーがすでに作業している場所に合わせるべきであり、単一の AI 体験に押し込むべきではありません。「Bring your own agents」の哲学に基づいて構築したいと考えています。最初のステップは、ClickStack Notebooks を内部的に駆動するのと同じ調査用ビルディングブロックを公開し、外部のエージェントやワークフローが利用できるようにすることです。そのために、オープンソースの ClickStack で ClickStack MCP サーバーを発表できることを嬉しく思います。

なぜ専用の ClickStack MCP なのか？ 現在、汎用の ClickHouse MCP サーバーが利用可能であり、広範な分析タスクや SQL 駆動の探索に適しています。しかし、AI Notebooks を構築する過程で、オブザーバビリティワークフローは一般的な BI ワークロードとは異なる動作をすることが何度もわかりました。モデルは、毎回生の SQL クエリを生成するよりも、構造化された調査ツールに対して動作する方がはるかに良いパフォーマンスを発揮します。生の SQL は強力ですが、多くのオブザーバビリティ調査は 1 回限りのクエリとして表現するのが厄介です。繰り返し現れるログパターンのマイニング、時間枠間の動作比較、トレース外れ値の根本原因特定、ログ、メトリクス、トレースを横断した調査などには、多段階の分析とドメイン固有のロジックが必要です。これらすべてをモデルに任せると、毎回必要なクエリパターンと分析ロジックをゼロから再構築しなければならず、問題自体ではなくクエリメカニクスにコンテキストを費やすことになります。

ClickStack MCP サーバーは、エージェントにオブザーバビリティ作業のためのより高レベルなセマンティックツールを提供します。生の SQL インターフェースのみを公開するのではなく、ログパターンのトレンド発見、外れ値との属性相関、遅いトレースの検査、反復可能なワークフローでの調査進行など、安定したツールを提供します。内部では、これらのツールは最適化された ClickHouse クエリを実行しますが、エージェントは毎回複雑な分析を手作業で組み立てるのではなく、意図レベルの操作と対話します。これは AI Notebooks 内部で使用されているのと同じアプローチです。モデルは調査の各ステップで大きな SQL 文を手動で結合するのではなく、基盤となるオブザーバビリティワークフローと ClickStack の最適化をすでに理解している専門ツールに対して動作します。内部ベンチマークでは、標準の ClickHouse MCP と比較して、ツール呼び出しが 25% 減少し、一貫性が 2.5 倍向上し、評価スコアがほぼ 20% 改善されました。その大部分は、モデルに生の SQL だけからすべてのワークフローを生成させるのではなく、高レバレッジのセマンティック調査ツールを提供したことに起因しています。

柔軟性の維持 同時に、構造化調査ツールが直接的な SQL アクセスを完全に置き換えるべきとは考えていません。ClickHouse がエージェントワークロードやオブザーバビリティに適している理由の 1 つは、SQL が依然として非常に強力な探索言語であることです。時には、インシデントがより高レベルの抽象化が役に立たなくなるポイントに達し、基盤データへの直接アクセスが必要になることがあります。構造化ツールは多くの反復的で一般的な調査パスを効率的に処理しますが、SQL はエンジニアやエージェントがより深く掘り下げたり、異常な仮説をテストしたり、システムが明示的に設計されていない質問に答えたりするための脱出口として残ります。実際には、これらのワークフローは自然に補完し合います。調査の大部分には最適化された調査プリミティブを使用し、状況に応じてネイティブクエリにドロップダウンします。

オーケストレーション、調査だけではない 一部のエンジニアは端末や Claude Code のようなエージェントフレームワークで直接作業することを好みますが、調査は最終的に他の人と共有する必要があります。SRE はコラボレーション、コンテキストの保存、結論に達した後の証拠の提示が必要です。そのため、オブザーバビリティ MCP サーバーは調査プリミティブのみを公開するべきではないと考えます。実際の運用ワークフローには、ダッシュボードの作成、検索の永続化、アラートの管理、チーム間での発見事項の共有などのオーケストレーションプリミティブも必要です。これはローカルエージェントワークフローで特に重要です。エージェントがローカルでインシデントを調査した場合、その証拠はチーム全体で共有・レビューできるようにどこかに永続化する必要があります。生のチャット出力をドキュメントにコピーしたり、静的レポートを生成したりすると、実際のインシデントではすぐに破綻し、不整合が生じます。

そのため、ClickStack MCP サーバーは ClickStack 内部で双方向の管理ツールを公開します。エージェントはインシデントを調査するだけでなく、ダッシュボードを作成し、検索を永続化し、結果として得られる成果物が必要な証拠と可視化を含んでいることを検証できます。実際には、調査は自然に使い捨てチャット履歴ではなく、永続的な運用成果物へと進化します。

MCP の使用 ClickStack MCP サーバーの使用開始は簡単です。フルスタックをローカルで試す最も簡単な方法は、ClickStack オールインワンコンテナを使用することです。