Managed ClickStack MCP Serverのご紹介

ClickStack MCP サーバーをクラウドへ #

先月の Open House では、ClickStack MCP サーバーを発表し、ClickStack を支えるのと同じオブザーバビリティ調査機能を、外部エージェントや AI ワークフローから利用できるようにしました。当初はオープンソース版 ClickStack の一部としてリリースされ、Claude、Cursor、Codex といったツールを、ログ・メトリクス・トレース向けに設計された専用の調査プリミティブを通じて、オブザーバビリティデータに直接接続できる手段を提供していました。

本日、これらの機能を ClickHouse Cloud 上の Managed ClickStack でも利用可能にします。

Managed ClickStack ユーザーにとって、これはエージェントが同じ専用オブザーバビリティツールにアクセスできるようになることを意味します。その基盤には ClickStack のアーキテクチャがあり、より多くのテレメトリをより長期間保持し、サンプリングしていないログ・メトリクス・トレースを低コストで保存し、オブザーバビリティ費用を抑えるために他で使われがちなロールアップを避けられるという利点をそのまま享受できます。

これらの機能により、エージェントは大幅に多くのコンテキストにアクセスできます。より長い履歴期間にわたって推論し、時間の経過とともに現れる傾向を特定し、サンプリングされたり集約されたりしたビューではなく、完全なテレメトリを使って調査することができます。

MCP サーバーは、より広範な ClickStack Cloud アーキテクチャの恩恵も受けます。エージェントのワークロードは、取り込みやユーザー向けワークロードとは独立した専用のコンピュートリソース上で実行可能であり、compute-compute 分離、ノートブック、ダッシュボード、共同調査ワークフローといった機能もそのまま利用できます。その結果、運用すべきシステムを新たに増やすことなく、AI エージェントを本番のオブザーバビリティに導入する分かりやすい方法が手に入ります。

ClickStack MCP サーバーの利用に興味がある方は、セットアップと設定の完全ガイドをご覧ください。

なぜ専用のオブザーバビリティ MCP なのか? #

汎用の ClickHouse MCP サーバーはすでに存在しており、幅広い分析タスクや SQL ベースの探索にはうまく機能します。しかし AI Notebooks を構築する中で、オブザーバビリティのワークフローは一般的な BI ワークロードとは挙動が異なることに何度も気づきました。モデルは、生の SQL クエリを繰り返し生成するよりも、構造化された調査ツールに対して動作する方がはるかに良いパフォーマンスを発揮します。

生の SQL は強力ですが、オブザーバビリティの調査の多くは、一回限りのクエリとして表現するには扱いにくいものです。繰り返し現れるログパターンの抽出、時間ウィンドウ間での挙動比較、トレース外れ値の根本原因分析、ログ・メトリクス・トレースを横断する調査の追跡といったタスクには、多段階の分析とドメイン固有のロジックが必要です。これらをすべてモデルに任せると、必要なクエリパターンと分析ロジックを毎回ゼロから再構築せざるを得ず、問題そのものではなくクエリの組み立てにコンテキストを消費してしまいます。

ClickStack MCP サーバーは、オブザーバビリティ作業のための、より高水準なセマンティックツールをエージェントに提供します。生の SQL インターフェースだけを公開するのではなく、ログパターンの傾向の発見、属性と外れ値の相関分析、遅いトレースの調査、再現可能なワークフローによる調査の進行といった安定したツールを提供します。内部的にはこれらのツールも最適化された ClickHouse クエリを実行しますが、エージェントは複雑な分析を毎回手で組み立てるのではなく、意図レベルの操作とやり取りすることになります。

これらのツールの効果として、社内ベンチマークでは標準の ClickHouse MCP と比較して、調査がツール呼び出し回数 25% 減で完了し、一貫性は 2.5 倍向上、評価スコアもほぼ 20% 向上することが示されています。その大きな要因は、ワークフローを毎回生 SQL から生成させるのではなく、レバレッジの高いセマンティックな調査ツールをモデルに与えたことにあります。

ツールの例 - イベントパターン #

例として、イベントパターンツールを取り上げます。

ClickStack のイベントパターンは、類似するイベントをクラスタリングすることで、大量のログやトレースを理解しやすくするために使用されます。

何百万行ものログを個別にスクロールする代わりに、ユーザーはどのエラーが繰り返し発生しているか、どれが新しいものか、イベント量の変化を引き起こしているのはどれかを示す、意味のある小さなグループのセットを得られます。

これを生の SQL で効率的に表現するのは困難です。通常、モデルは正規表現を使ってイベント本文を正規化し、結果として得られるパターンでグループ化し、時系列で出現回数をカウントするクエリを生成する必要があります。大規模なデータセットでは、これはスキャンされるデータ量に応じてスケールし、高カーディナリティの出力、長いクエリ時間、不要なサーバー負荷にすぐにつながります。クォータやクエリ複雑度の制限で最悪のケースは抑えられますが、結局ユーザーが時間範囲を絞り込んだり、質問に答える前に基礎となるデータモデルをチューニングしたりすることがよくあります。

ClickStack MCP サーバーは別のアプローチを取ります。イベントパターンについては、マッチするイベントのランダムサンプルと結果セット全体のカウントを含む、軽量なクエリを少数実行できます。サンプルはその後、MCP レイヤーで Drain3 アルゴリズムを使って処理されパターンを特定し、最終的なカウントは外挿・ランク付けされてエージェントに返されます。

これにより、モデルははるかに優れたプリミティブを扱えるようになります。クエリのオーバーヘッドはデータセット全体に比例して増加するのではなく固定されており、生の出力のカーディナリティは大幅に低く、基礎となるイベント本文の変動が大きい場合でもツールはうまく動作し続けます。

ツールの再利用 #

これらと同じツールが ClickStack AI Notebooks の内部でも使用されています。モデルは、調査の各ステップで大規模な SQL 文を手動で組み立てているわけではありません。代わりに、観測性ワークフローや ClickStack の最適化をすでに理解している専用のツールに対して動作します。

柔軟性の維持 #

同時に、構造化された調査ツールが SQL への直接アクセスを完全に置き換えるべきだとは考えていません。

ClickHouse がエージェント型ワークロードやオブザーバビリティに非常に適している理由の 1 つは、SQL が依然として極めて強力な探索言語であることです。インシデント対応では、より高レベルの抽象化では対応しきれない地点に到達し、根底にあるデータへ直接アクセスする必要が出てくる場合があります。構造化されたツールは、繰り返し発生する一般的な調査経路を効率的に処理しますが、エンジニアやエージェントがさらに深く掘り下げたり、変わった仮説を検証したり、システム設計時に明示的に想定されていなかった問いに答えたりする必要があるとき、SQL は最後の逃げ道として機能します。

実際のところ、これらのワークフローは自然に補完し合うことになります。調査の大部分は最適化された調査用プリミティブを使い、状況が要求する場面ではネイティブクエリへ落とし込むのです。

単なる調査ではなく、オーケストレーションも #

ターミナルや Claude Code のようなエージェントハーネス内で直接作業するのを好むエンジニアもいますが、調査結果は最終的に他のメンバーと共有される必要があります。SRE はコラボレーションし、コンテキストを保持し、結論に至った際にはその根拠を提示しなければなりません。

そのため、オブザーバビリティ MCP サーバーは調査用プリミティブのみを公開すべきではないと考えます。実運用のワークフローでは、ダッシュボードの作成、検索の保存、アラートの管理、チーム横断での発見事項の共有といったオーケストレーション用プリミティブも必要です。

これはローカルなエージェントワークフローにおいて特に重要になります。エージェントがローカルでインシデントを調査した場合、その結果として得られた証跡はチーム全体での共有とレビューのためにどこかへ永続化される必要があります。生のチャット出力をドキュメントにコピーしたり、静的レポートを生成したりするやり方は、実際のインシデント対応ではすぐに破綻し、不整合の原因となります。

そうした理由から、ClickStack MCP サーバーは ClickStack 内部に双方向の管理ツールを直接公開しています。エージェントはインシデントを調査するだけでなく、ダッシュボードを作成し、検索を永続化し、生成された成果物が必要な証跡と可視化を含んでいることを検証することもできます。

実際には、調査は使い捨てのチャット履歴ではなく、永続的な運用上の成果物へと自然に発展していきます。

完全なコンテキストと専用コンピュートを備えた MCP サーバー #

オブザーバビリティがエージェント主導へと進むにつれ、クエリ数も分析対象データ量も大幅に増加すると見ています。従来のダッシュボードと異なり、エージェントは本質的に探索的で、システムを反復的に調査し、仮説を検証し、ログ・メトリクス・トレースを横断的に辿ります。

同時に、これらの調査の質はコンテキストに大きく依存します。エージェントは、履歴分析やトレンド発見のためにより長い保持期間にアクセスできること、そして全体像を理解できる非サンプリングのテレメトリにアクセスできることから恩恵を受けます。そのコンテキストがなければ、有望そうな道筋を辿った末に、関連データがサンプリングで失われていた、集約されていた、あるいはもはや保持されていなかったといった事態に容易に陥ります。

これらの傾向を総合すると、基盤となるオブザーバビリティプラットフォームには新たな要求が生まれます。完全な忠実度のテレメトリを長期間にわたってコスト効率よく保持しつつ、エージェントが継続的に探索・調査・仮説検証を行うために大幅に増えるクエリ量を支える必要があるのです。

Managed ClickStack はまさにこうしたワークロードのために設計されています。ClickHouse Cloud 上に構築されており、大量のログ・メトリクス・トレースをコスト効率よく保持でき、オブザーバビリティコストを抑えるために用いられがちなサンプリングやロールアップを避けられます。

同様に重要なのは、エージェントのワークロードを専用のコンピュートリソースを使って取り込みワークロードおよびユーザー向けワークロードの双方から分離できることです。これによりチームは、本番のダッシュボード、アラート、取り込みパイプラインへの影響を抑えつつ、エージェント主導の調査を独立してスケールさせることができます。

Managed ClickStack で MCP サーバーに接続する #

Managed ClickStack MCP サーバーの利用開始は簡単です。ClickHouse Cloud 上の ClickStack は https://mcp.clickhouse.cloud/clickstack でマネージドな MCP エンドポイントを公開しており、認証には OAuth 2.0 を使用します。

接続前に、ClickStack が有効化された ClickHouse Cloud サービスを用意してください。MCP アクセスは Cloud コンソールから Connect → Connect with MCP を選択し、MCP サポートをオンに切り替えることで有効化できます。

有効化したら、該当サービスの ClickStack に移動し、Team Settings → API & Agents を選択します。ここで ClickStack は、Claude Code、Cursor、Codex CLI など主要な MCP クライアント向けに、設定済みの接続文字列を提供します。

設定後は、認証を完了する必要があります。例として、Claude 用の MCP 接続文字列をコピーしたとしましょう。

1claude mcp add clickstack --transport http https://mcp.clickhouse.cloud/clickstack --header "x-service-id: 11e1031f-9a13-4cac-9bc7-d4ec9286ec17"

この場合、Claude Code を起動して /mcp を実行し、clickstack-cloud を選択して OAuth フローを完了します。

重要な点として、生成される接続文字列には ClickHouse Cloud のサービス ID が含まれます。これにより、どの ClickHouse サービスが実際のクエリを実行するかが決定されます。エージェントワークロードを他のワークロードから分離して専用のコンピュート上で実行したい場合は、子サービスを作成し、そのサービスから ClickStack を起動できます。生成される MCP 構成は自動的に該当サービスを対象とするため、エージェント主導の調査を取り込みやユーザー向けワークロードから独立してスケールさせることができます。

接続が完了すると、エージェントは ClickStack のオブザーバビリティ用プリミティブと直接やり取りできるようになります。例えば、次のような質問が可能です。

「過去 24 時間でエラー率が最も高いサービスを見せて」

内部的には、MCP サーバーはこれらの要求を、その場限りの SQL 生成だけに頼るのではなく、AI Notebooks と同じ最適化された調査ツール群を通じてルーティングします。

例えば、決済サービスのレイテンシ上昇を調査し、Claude を通じて最終的にキャッシュ追い出しの問題が根本原因だと判明したとしましょう。

この時点で、調査内容を永続化して共有する手段が必要になります。Claude の生出力をドキュメントへコピーしたり、モデルに静的な HTML レポートを生成させたりすることもできますが、いずれのワークフローもあまり自然に感じられません。

以下では、MCP サーバーを使って調査内容をまとめるダッシュボードを生成し、結果を ClickStack に直接永続化します。さらに、ダッシュボードが必要な証跡を提示していることを確認する検証ステップも含まれます。

得られたダッシュボードは、インシデントを要約し、RCA ドキュメント向けの証跡を提示する永続的な成果物となります。

ClickStack MCP サーバーの利用に興味がある場合は、セットアップと構成の完全ガイドを参照してください。

まとめ #

オブザーバビリティは今後ますますエージェント主導になっていくと考えていますが、エージェントが効果的に機能するには、生データへのアクセス以上のものが必要です。専用の調査ツール、長期にわたるコンテキスト、完全な忠実度のテレメトリ、そしてスケールして動作する能力が必要です。Managed ClickStack によって