ClickHouse はオブザーバビリティ戦争に勝っているのか?

2026年7月、Mat Duggan 氏と Charity Majors 氏がそれぞれ、「ClickHouse はオブザーバビリティ戦争に勝っている」と論じる記事を公開しました。どちらも私たちが働きかけたものではありません。読んで光栄に思うと同時に、この見方がこれほど広く伝わったことに少し驚きました。

もちろん称賛はありがたく受け取ります。ただ、経験豊かなオブザーバビリティの実践者であり業界のリーダーでもある2人が、本番環境で見てきたことを根拠に、公の場でこう主張せずにいられなかったのはなぜか。少し立ち止まって考えてみたくなりました。

ClickHouse はオブザーバビリティスタックのどの部分で勝っているのでしょうか。なぜそこで選ばれることがこれほど多くなったのでしょうか。ClickHouse が正しい答えではないのはどんなときでしょうか。そして、今後も魅力的な選択肢であり続けるために、私たちはどこに力を注ぐべきでしょうか。

コストを下げながらオブザーバビリティの能力を高めるために ClickHouse を役立てるチームが増えていることを、私たちはうれしく思っています。ただ、筆者は熱心な F1 ファンなので Lewis Hamilton の言葉を借りると、「まだやり残した仕事がある(we still have unfinished business)」のです。

「勝つ」とは何を意味するのか #

Mat も Charity も、最終的にはストレージとクエリの層に焦点を当てています。これは「勝つ」の定義を狭めるものです。この層はオブザーバビリティという問題の一側面にすぎません。収集、スキーマ設計、相関付け、可視化、アラート、調査のワークフロー、そしてそれらを包む体験は、依然として作り上げる必要があります。優れたエンジンは土台を作りますが、プロダクトとしての判断や、テレメトリをどう扱いどう捉えるかを決めてくれるわけではありません。

Charity の言葉を借りれば、

「より良いストレージエンジンでも、悪いアーキテクチャには勝てない(A better storage engine can't beat bad architecture)」

ストレージ層においては、ClickHouse は自前のオブザーバビリティシステムを構築する多くのエンジニアリングチームにとって既定の選択肢になりました。Netflix、Anthropic、OpenAI のチームは、大規模なテレメトリ、特にログとトレースの保存とクエリに ClickHouse を使っています。

同様に、多くのオブザーバビリティ SaaS 企業が ClickHouse の上にプロダクトを構築しています。インターフェース、ワークフロー、プロダクトとしての判断は自社で担い、ClickHouse はエンジンとして使うという形です。

これらのプロダクトはそれぞれ異なるユーザーに向けたもので、思想も同じではありません。リッチなワイドイベントを中心に設計されたものもあれば、ログ、メトリクス、トレースを軸にした馴染みのある体験を維持しているものもあります。共通しているのは ClickHouse の列指向アーキテクチャで、これがテレメトリの形とアクセスパターンに合っているという点です。

オブザーバビリティデータは、個別のシグナルとして持つより、リッチなワイドイベントとして持つほうが有用な場合が多いという Charity の意見に、私たちも同意します。コンテキストをまとめて保持すれば関係性が保たれ、形式ごとに情報を重複させることを避けられ、問いが生じたときにビューを導き出せます。しかし、多くのチームにはすでに、ログ、トレース、メトリクスを軸に組み上げた計装、スキーマ、ワークフローがあります。ClickHouse の恩恵を受けるために、テレメトリを作り直さなければならないというのは筋が違います。

ClickHouse は従来型のログやトレースともうまく機能します。本番のログは多くの場合、構造化されていて、幅が広く、カーディナリティが高いものです。そもそもワイドイベントとは、メトリクスを伴う構造化ログ以上の何かなのでしょうか。自由形式のメッセージであっても、繰り返し現れるトークンやテンプレートを含んでおり、並べて格納すればよく圧縮されます。トレースのスパンはすでにワイドイベントに似ています。タイムスタンプ、所要時間、識別子、属性、ステータスを含む構造化レコードだからです。

ClickStack も同じ実践的なアプローチを取っています。ClickHouse、OpenTelemetry Collector、ClickStack UI を組み合わせ、ワイドイベントを受け入れつつ、チームがすでに収集しているログ、トレース、メトリクスもそのまま受け付けます。ユーザーは馴染みのあるワークフローを維持しながら、それらのシグナルをデータとして相関付けクエリする能力を手放さずにすみます。

プロダクトはシグナル、スキーマ、ワークフローについて異なる判断をしながらも、ストレージについては同じ結論に到達できます。ClickHouse は、どちらのモデルにおいてもストレージとクエリのエンジンとしての実力を証明してきました。

したがって、このモデルでオブザーバビリティシステムを構築するチームにとって事実上のストレージとクエリの層になることを「勝つ」と呼ぶなら、答えはおそらくイエスです。

なぜ ClickHouse はストレージ層にこれほど適しているのか #

ClickHouse がオブザーバビリティに根本的に適しているのは、列指向データベースだからです。ワイドイベント、ログレコード、トレースのスパンは、思想やシグナルの種類こそ異なりますが、分析データとしての性質を共有しています。レコードあたりのフィールドが多く、量が大きく、クエリは通常そのうち一部のフィールドだけを参照または集計するという性質です。

行指向データベースでは、1つのレコードに属する値がまとめて格納されます。列指向データベースはその代わりに、フィールドごとに値をまとめて格納します。タイムスタンプは他のタイムスタンプと、サービス名は他のサービス名と、所要時間は他の所要時間と並びます。この配置は、数百万から数十億のイベントにわたって少数のフィールドだけを走査することが多いオブザーバビリティのクエリに合っています。

この結論は ClickHouse 固有のものではありません。Honeycomb は早い段階でこの結論に到達し、リッチなワイドイベントを中心に自前の分散カラムストア Retriever を構築しました。Datadog も、ログやその他のイベントデータのために2022年に導入した列指向イベントストア Husky で、似たアーキテクチャ上の結論に至っています。両社のプロダクトモデルは異なります。Honeycomb はワイドイベントにコンテキストをまとめて保持することを主張し、Datadog はメトリクス、ログ、トレースを軸にした馴染みのある体験を提供し続けています。しかしストレージ層では、どちらも列にたどり着きました。

では、なぜ列指向アーキテクチャはオブザーバビリティデータにこれほど適しているのでしょうか。

利点はディスク上から始まります。各データパートの中で、行はテーブルのソートキーで並べられ、各列は個別に格納されます。ソートキーが主なアクセスパターンを反映していれば、似た値が近くに置かれます。すると、Dictionary、Delta、ランレングスといったエンコーディングで汎用圧縮の前にデータを削減でき、汎用圧縮そのものも連続した値の並びから恩恵を受けます。

ClickHouse をオブザーバビリティに使うユーザーが最初に挙げるのは、多くの場合この圧縮の利点です。

「ClickHouse で達成できた圧縮率には本当に感銘を受けました。10倍の列もあれば20倍の列もあり、場合によっては50倍に達しました。」

Character.AI

「わずか20 CPU コアで毎秒最大300万行を取り込み、チューニングなしで1:8の圧縮率を達成しています。」

Shopee

ディスク上のデータ配置は、エンジニアが実際に実行するクエリにも合っています。オブザーバビリティのチャートの多くは集計クエリです。たとえば時間バケットごとにリクエスト数を数えたりレイテンシを平均したりし、その結果をサービス、リージョン、あるいは別のディメンションでグループ化します。こうしたクエリは数百万から数十億のイベントを走査することもありますが、実際に触れるのはタイムスタンプと集計対象の値、それに幅広いレコードのうちのわずかなフィールドだけです。

ClickHouse はそれらの列だけを読み、残りを読む I/O コストを払わずにすみます。スパースな主キーインデックスはフィルタに一致しないグラニュールを除外でき、さらに別のアクセスパターンを支えるデータスキッピングインデックスも利用できます。

「ユーザーのクエリの大半(約80%)は直近2日間のデータにしか触れないので、そのデータはディスクに置いて高速にアクセスできるようにしています。」

OpenAI

「ClickHouse は時間に基づいてデータをスキップできるので、必要なデータへ効率よく絞り込め、テーブルのサイズはほとんど関係なくなります。」

BENOCS

同じ配置は、列が CPU に届いた後も引き続き効きます。ClickHouse は行を1つずつ解釈するのではなく、列の値のブロック単位でデータを処理します。集計クエリでは、連続した値のバッチに同じ操作をまとめて適用できます。これによりキャッシュの局所性が高まり、行あたりのオーバーヘッドが減り、適した操作ではプロセッサが備える SIMD 命令を使えます。複数のブロックを CPU コアをまたいで並列に処理することもできます。

その並列性はクラスターにも広がります。分散クエリはデータを保持するシャードへ送られ、各ノードが自身の担当分を同時に走査して集計します。部分結果は起点となったノードへ返され、最終結果へマージされます。したがってノードを追加すれば、ストレージだけでなくクエリ用の計算資源も増えます。

「Parallel Replica 機能はクエリを複数ノードへ分散して並列処理し……クエリ速度を最大2.5倍に高めます」

Poizon

「SIMD 命令を多用し、データ構造を CPU キャッシュに効率的なものにし、目的に特化したアルゴリズムを使うことで……膨大な規模のデータを処理しています。」

RunReveal

Mat の記事は、列指向ストレージとは別の性質を取り上げています。ClickHouse のスケーリングモデルです。彼の指摘は次のとおりです。

「1日10 TB の ClickHouse は、1日1 TB の ClickHouse にシャードを足した姿に見える(ClickHouse at 10 TB a day looks like ClickHouse at 1 TB a day with more shards.)」

デプロイメントはまず大きなマシンで垂直にスケールでき、ワークロードが求めるまでシャーディングを先送りできます。そこから、同じクエリエンジンとデータモデルを保ったままシャードを追加して水平にスケールできます。シャードの追加には依然としてキャパシティプランニングが必要で、セルフマネージドのデプロイメントでは慎重なリバランスも要ります。それでも、システムは大きくなっても見慣れた姿のままです。

ClickHouse を大規模に運用する他のチームも、同じ予測可能性を挙げています。

「ClickHouse はクラウドネイティブで、水平にスケールするように設計されています。つまり、取り込みとクエリの両方について、比較的少ない運用負荷でスケールできます。」

OpenAI

集計はオブザーバビリティで一般的なクエリパターンの一つです。調査の最中には、エンジニアはエラーメッセージを検索し、属性でフィルタし、テレメトリを収集した時点では予測できなかった手がかりを追いかけもします。アラート、ダッシュボード、あらかじめ定義されたワークフローで、あらゆる問いを先回りすることはできません。この検索中心のワークフローは、Elasticsearch がログのバックエンドとして広く使われるようになった理由の一つです。

ClickHouse は以前から、高度に並列化された文字列走査によるテキスト検索を実行でき、Bloom フィルタのスキップインデックスで、その語を含みえないグラニュールを除外できました。Bloom フィルタは役に立ちますが、確率的であり、グラニュール単位で動きます。偽陽性を生じ、慎重なチューニングが必要で、ほとんどのグラニュールにその語が現れる場合にはほとんど絞り込めません。

2026年3月、全文検索が ClickHouse で一般提供(GA)になりました。このテキストインデックスは、各トークンからそれを含む行番号を引ける転置インデックスを使います。ClickHouse はすべての文字列値を走査せずに候補行を特定し、同じクエリの中でその結果をフィルタして集計できます。これらのインデックスは Bloom フィルタに比べてストレージを多く使い、書き込みのオーバーヘッドも増えますが、行単位で正確に語を検索でき、複数トークンやフレーズの検索にも対応します。

私たちは ClickStack でこのテキストインデックスを活用し、ログ本文の検索と Map 属性に対する完全一致フィルタを高速化しています。インデックス自体が検索可能なので、ClickStack は前方一致の検索で属性値を見つけ出し、元のテレメトリ列を走査せずにオートコンプリートやフィルタ候補を提示することもできます。転置インデックスが候補行を絞り込み、その後の分析は ClickHouse の列指向エンジンが担います。

ユーザーからは、オブザーバビリティの検索ワークロードの性能を高めるうえで、このテキストインデックスが非常に強力だという声が届いています。

「ClickHouse の全文検索は、ログデータの検索方法を根本から変えました。私たちは多様なソースから数百万のイベントを取り込み、生のペイロードを String 列に保存しています。以前は複数語の検索に線形走査で30〜45秒かかることがありました。新しい転置インデックスでは、同じクエリが約400ミリ秒で完了します。」

Icite

高カーディナリティは、列指向モデルでは異なる振る舞いをします。Prometheus のようなストアでは、ラベルの一意な組み合わせごとに別々の時系列が作られ、それぞれにメタデータ、チャンク、インデックスのオーバーヘッドが伴います。ClickHouse では、代わりにイベント行が1行増えるだけです。TraceId、user_id、container_id のようなフィールドは数百万の異なる値を含むかもしれませんが、ストレージと圧縮のコストが及ぶのはその列だけ、シャード化された Map に保持している場合は該当するバケットだけです。ServiceName のような列ほど効率よくは圧縮できないかもしれませんが、イベントの他のすべてのフィールドの圧縮率を下げることはありません。

フィルタリングも同様に、データセット全体の異なる値の総数ではなく、読み取る列とグラニュールによって決まります。高カーディナリティのフィールドに対する選択性の高いフィルタは、特にソートキーやセカンダリインデックスがそのアクセスパターンを支えている場合、走査するデータ量を減らせます。それでもカーディナリティにコストはあります。数百万の異なる値でグループ化すると、ClickHouse は数百万の集計状態を構築する必要があり、クエリ時間とメモリ使用量が増えます。ただし、設定すればこれらの状態はディスクへ退避できます。それに、数百万の系列でグループ化して表示したいというユーザーは、そもそも稀です。ClickHouse と Prometheus のカーディナリティに関するより詳しい比較では、それぞれのモデルでこうしたコストがどこに現れるかを追っています。結果として、ClickHouse のユーザーは高カーディナリティを恐れなくなります。

「もうカーディナリティを恐れていません……基本的にすべてのデータを一か所に置き、あらゆる問いに答えるのに使えます。」

Sierra

列だけの話ではない #

列指向アーキテクチャは、先に述べた狭い意味において ClickHouse がオブザーバビリティのストレージとクエリの層で「勝っている」理由の一つであることは明らかです。しかし、これほど多くのエンジニアリングチームやオブザーバビリティベンダーが ClickHouse を選んだ理由は、列だけでは説明できません。

性能へのこだわり #

オブザーバビリティデータに対する ClickHouse の性能の多くは、そのアーキテクチャで説明できます。圧縮は保存し読み取るデータ量を減らし、列単位の I/O、ベクトル化実行、(ノード内とノード間の)並列性はクエリに答えるために必要な仕事量を減らします。加えて、このプロジェクトは性能とリソース効率に対する徹底したこだわりの文化を育んできました。Andy Pavlo は、クエリ実行に関する CMU の講義でその姿勢をこう捉えています。

この性能へのこだわりの源である ClickHouse の作者、Alexey Milovidov は、同じエンジニアリング哲学をプロジェクトの内側から説明しています。

この積み重ねはオブザーバビリティで大きく効いてきます。量が十分に大きければ、不必要に読んだバイトや無駄にした CPU サイクルがそのまま運用コストになるからです。この効率は保持の経済性も変えます。ClickHouse はオブジェクトストレージと、ストレージとコンピュートの分離を第一級の機能として備えており、大きなデータセットを低コストで保持できます。圧縮と選択的な読み取りと合わせれば、サンプリングせず欠けのないテレメトリを、すべてローカルディスクに置かなくても長く保持できます。

すると、サンプリングやロールアップは、ストレージコストが強いる必須要件ではなく、最適化の手段になります。チームは生のイベントを残しておき、どの問いが重要かわかってから何を集計するかを決められます。

ユーザーはこのリソース効率を実際に評価しています。

「ユーザーは今、事前集計した形式に頼るのではなく、長い期間にわたるデータをクエリし、生データをリアルタイムに分析できます。」

Tekion

「私たちのユースケースにおいて、ClickHouse は市場のあらゆる製品の中で最高の1ドルあたりの性能を提供します。」

Last9

すべてのシグナルを1つのデータストアに #

多くのチームは、テレメトリのシグナルごとに別のバックエンドを持ちたいとは思っていません。ClickHouse はログ、トレース、そして一部のメトリクスワークロード(後述)に対応できます。そのぶん、スケーリングモデルも障害モードもクエリ言語も運用要件も違うシステムを、チームがいくつも学んで維持する必要がなくなります。この機会はオブザーバビリティの外にも広がります。ClickHouse はリアルタイム分析やデータウェアハウスにも使われているため、テレメトリ、運用データ、ビジネスデータを後からアプリケーション層で結合するのではなく、同じエンジンでクエリし相関付けられます。これらのワークロードが重なるなら、統合によってインフラは単純になり、総保守コストも下がります。

Sierra はこれをうまく言い表しています。オブザーバビリティと分析を、1つのデータの問題として捉えているのです。

「オブザーバビリティと分析を別々の島として考えるのをやめて、ClickHouse のような本当に優れた計算エンジンを土台にした1つのデータの問題として捉えられたら、すごくいいと思います。」

データの共通言語としての SQL #

ClickHouse がオブザーバビリティで広く使われるようになったもう一つの理由は、そのクエリインターフェースにあると私たちは考えています。SQL はオープンで広く理解された標準であり、成熟したツールのエコシステムを持つため、エンジニアにとって扱いやすく、アプリケーションを構築するのも簡単です。AI エージェントの学習データやツールにも豊富に登場します。ClickHouse は SQL を、分析、統計、時系列、文字列の関数群で大きく拡張し、複雑なフィルタリング、ディメンションによるグループ化、結合、ウィンドウ関数、多段の集計に対応します。こうしたより豊かな分析ワークフローは、メトリクスやログといった単一のシグナルに最適化されたデータストア向けに設計されたクエリ言語では、表現しづらいことがあります。

「データについて興味深い問いを投げられるようになりたいのであって、単純なドメイン固有言語に縛られたくはありません。」

Tesla

もちろん、すべてのユーザーがこのレベルの制御を必要とするわけではないことも承知しています。だからこそ ClickStack は馴染みのあるビルダーを提供し、Lucene 形式の検索を背後の ClickHouse のスキーマとインデックスに最適化されたクエリへ変換し、複雑さを隠すクエリビルダーも備えています。それらの抽象化では足りなくなったときは、ネイティブ SQL のチャートとアラートでエンジンを直接扱えます。同じプラットフォームが、手早いログ検索も、作り手の判断が組み込まれたダッシュボードも支えつつ、オブザーバビリティデータをより深く調査し分析したいユーザーには SQL を残しています。

オープンなエコシステム #

ClickHouse のオープンなエコシステムも、チームが安心してオブザーバビリティに採用できる理由の一つです。私たちのアプローチは、1つの完結したワークフローの採用を求めるのではなく、ユーザーの今の環境に合わせることでした。ClickStack は統合された体験を求めるチーム向けのオープンソースのスタックであり、Grafana プラグインへの継続的な投資はすでに Grafana を使っているチームを支えます。増え続けるパートナー統合により、チームは基盤となるストアを変えることなく、収集、可視化、調査の選択肢を広げられます。

同じアプローチは、私たちの OpenTelemetry への投資も形作っています。Collector Contrib ディストリビューションにおける clickhouse exporter と Datadog receiver の取り組みはその一つで、既存のテレメトリパイプラインを OpenTelemetry 互換のバックエンドへつなぐ助けになります。また、転送とシリアライズのオーバーヘッドを減らすため、取り込み形式として Arrow に対応する Apache Arrow collector プロジェクトにも貢献しています。ClickStack の OpenTelemetry 互換の SDK ディストリビューションは、標準の SDK が直接提供していないセッションリプレイやブラウザからの収集といった機能を加えます。しかし最も重要なのは、ClickHouse を採用するために、すでに持っているツールと計装を捨てる必要があってはならないという点です。

寛容なライセンス #

ClickHouse の Apache 2.0 ライセンスがその採用にどれほど寄与してきたかにも触れておかなければなりません。この寛容なライセンスのおかげで、チームは ClickHouse をローカルや自社インフラの中で動かし、自分たちの要件に合わせて改変し、その上に商用プロダクトや SaaS サービスを構築できます。自分たちの条件で始め、データベースをどこでどう動かすかの制御を手元に残せます。

「オープンソース版には明確な利点がありました。『すぐに始められ、実績があり、優れた性能が得られる』のです。」

Anthropic

「チームは ClickHouse がオープンソースに根ざしている点を評価しました。『私たちの技術スタックはすべてオープンソースです』[ただし]最終的には ClickHouse Cloud で運用することを選びました。」

Laminar

後にデータベースの運用が本業の妨げになったら、そうしたチームは ClickHouse Cloud に移り、マネージドサービスならではの利点を得られます。ストレージとコンピュートの分離は、オブザーバビリティで見られる規模では特に魅力的です。データは共有オブジェクトストレージに一度書かれ、レプリカごとに別のコピーを持つことを避けられます。コンピュートサービスはそのデータを読み、「書き込み税(write tax)」なしに独立してスケールできます。たとえば取り込みと対話的なクエリを分離し、取り込みのスパイクが調査に必要な計算資源を食いつぶさないようにできます。オープンソースならユーザーが始め方を自分で決められ、ClickHouse Cloud は必要になったとき、別のデータベースに乗り換えなくてもすむもう一つの運用モデルになります。

しかし、メトリクスはどうか #

ここまで読み進めた方は、同じストレージとクエリの議論がメトリクスにも当てはまるのか気になっているかもしれません。正直な答えは、イエスでもありノーでもあります。

高カーディナリティのイベントのフィールドとして運ばれるメトリクスについては、答えはイエスです。これは Charity が述べているモデルで、測定値をそれを生み出したコンテキストと一緒に保持し、クエリ時に集計します。こうしたレコードは、測定値が付いた構造化ログと考えられます。サービス、顧客、リクエスト、デプロイメントなど、従来のメトリクスストアなら系列の爆発を招くディメンションを保持しています。ClickHouse はそれらのディメンションを列として扱うため、1つのフィールドにカーディナリティを足しても、データベースが維持しなければならないオブジェクトの数が掛け算で増えることはありません。

Prometheus 形式のメトリクスは別の問題です。Prometheus と OpenTelemetry は異なるメトリクスモデルとプロトコルを定義しており(なぜオブザーバビリティが必要なのかを含め、いずれも別の記事で扱うべき問いです)、チームには何年分ものダッシュボード、アラート、運用習慣がそれらを軸に積み上がっています。ユーザーの今の環境に合わせるとは、全員に PromQL を SQL へ翻訳させたり、すべてのメトリクスをワイドイベントとして作り直させたりするのではなく、そうしたワークフローを支えることです。

その対応は今日すでに存在しますが、完成したとは言えません。ClickHouse 24.8 は、Prometheus の remote write と remote read に対応した実験的な TimeSeries テーブルエンジンを導入しました。ClickHouse 25.8 は初期の PromQL 対応を追加し、2026年6月には ClickStack が同じエンジンを土台とする実験的な PromQL データソースとチャートエディタを公開しました。対応範囲は広がり続けていますが、ストレージモデルと API はまだ変わる可能性があります。ダッシュボードやアラートの全体が成熟した PromQL のセマンティクスに依存しているチームは、確立された Prometheus 互換システムを ClickHouse でそのまま置き換えられると考えるべき段階にはまだありません。

Prometheus とのドロップイン互換と TimeSeries エンジンの成熟は、今や ClickHouse と ClickStack の主要な投資領域です。ClickHouse がオブザーバビリティ全体にとって既定のストレージとクエリの層になるうえで、これはおそらく残された最大のギャップです。ログ、トレース、イベント型メトリクスについての証拠はすでに十分にあります。Prometheus 形式のメトリクスは、私たちにまだ仕事が残っている領域です。

データベースがあればオブザーバビリティプロダクトができるわけではない #

ClickHouse が正しいストレージエンジンであっても、その上に作られたオブザーバビリティプロダクトは貧弱になりえます。収集、スキーマ設計、シグナルの相関付け、可視化、アラート、調査の流れ、運用のオーナーシップのすべてが、エンジニアがそのシステムでインシデントの原因をつかめるかどうかを左右します。ソートキーの選択を誤れば、データの刈り込みが効かなくなります。クエリがスキーマとインデックスを有効に使えないこともあります。インターフェースが有用なコンテキストを隠したり、日常的な調査を不必要に難しくしたりすることもあります。データベースは能力を提供しますが、それらを一貫した形に組み上げるのはプロダクトの仕事です。

その認識が、私たちが ClickStack を作った理由の一つです。ClickStack 自身もオープンソースとして力強く採用が進んでいます。

ClickStack は、私たちが学んだことをスキーマ、生成されるクエリ、最適化された調査ワークフローの既定値へ落とし込む場を与えてくれます。既定の ClickStack のクエリを速くする取り組みがこの点をよく示しています。改善は、データベースの設定を1つ変えただけでは得られません。主キー、テキストインデックス、マテリアライズドビュー、UI が生成するクエリをまとめて変更し、代表的なオブザーバビリティワークロードで検証する必要があります。その性能を可能にしたのは ClickHouse ですが、それを引き出すには正しい判断を積み重ねなければならないのです。

エージェントがゲームを変える #

オブザーバビリティの主要なインターフェースは、ダッシュボードや検索ボックスを越えて動き始めています。エージェントがエンジニアの代わりに調査し、仮説を立て、テレメトリをクエリするようになっているからです。今では、私たちの社内 LogHouse クラスターに届くクエリの60%以上をエージェントが発行しています。

これでワークロードの姿が変わります。エージェントは1つの問いに対して数十のクエリを発行することがあります。スキーマを探り、結果を検証し、再試行し、SRE のような間を置かずに掘り下げていくからです。

クエリのレイテンシはそのループの中に直接組み込まれ、同時に動く複数のエージェントはクエリのバーストを生みます。ClickHouse はウェブ分析にルーツを持つため、低レイテンシと高い同時実行性の両方への備えがありました。SQL も役立ちます。基盤モデルは SQL に大量に触れているため、エージェントはテレメトリをフィルタし、結合し、集計し、検証するための表現力の高い言語を手にします。

エージェントは、データを欠けなく残すことと長く保持することの価値も高めます。人間は欠けたイベントを経験で補えるかもしれませんが、エージェントは取得したコンテキストの上でしか推論できません。サンプリングで落とされ、ロールアップされ、期限切れで消えたレコードは、どんなプロンプトでも取り戻せません。サンプリングしていないテレメトリはより多くの調査経路を提供し、長い保持期間は異常を通常の振る舞いから見分けるのに必要な履歴を与えます。ClickHouse は、そのコンテキストを保持することを現実的にします。

高速な SQL エンジンは、それでも答えの一部にすぎません。モデルは無効なクエリや非効率なクエリを発行しては再試行し、決定論的なツールなら除外できたはずの経路を探って、トークンとデータベースの資源を浪費することがあります。これが ClickStack MCP サーバーを作った動機です。私たちの社内評価では、汎用の ClickHouse MCP サーバーと比べて、オブザーバビリティに特化したそのツール群は呼び出し回数が27%少なく、結果の一貫性が2.7倍高く、評価スコアが約20%向上しました。

ログパターン分析は良い例です。数百万のメッセージを正規表現で正規化して結果をグループ化するようモデルに求めると、大きな走査と高カーディナリティの結果を生みかねません。ClickStack は代わりに、少数の範囲を限定したクエリで一致するイベントをサンプリングし、MCP 層で Drain3 を使ってクラスタリングし、順位付けしたパターンをエージェントへ返します。エージェントはより良い調査の基本操作を手にし、ループは速く回り、ClickHouse は不必要な仕事を避けられます。あらかじめ定義されたツールが想定していなかった問いに調査が行き着いたときには、SQL が引き続き使えます。

エージェントはオブザーバビリティの仕事の一部を、ダッシュボードから会話や自動化された調査へ移すかもしれませんが、データストアの重要性を薄めることはありません。エージェントが求める低レイテンシ、高い同時実行性、表現力の高いクエリ、欠けのないデータ、過去のコンテキストは、チームを ClickHouse へ導いた性質をむしろ強く裏付けています。だからこそユーザーは、この変わりつつあるインターフェースも ClickHouse が支えられると確信できるはずです。

ClickHouse が適さないかもしれないとき #

ClickHouse の強みが最も意味を持つのは、量、保持期間、カーディナリティ、クエリの柔軟性、あるいはコストが大きな問題になるときです。テレメトリが控えめで、すぐ使える体験を好む小さなチームには、データベースを運用することが最善とは限りません。

以前であれば、私たちはこうしたチームをターンキーのプロダクトへ案内していたでしょう。誰もスキーマを設計したり、SQL を書いたり、周辺インフラを保守したりしたくない場合は特にそうです。オープンソースの ClickStack は今、そのギャップの多くを埋めています。

ClickStack は OpenTelemetry による収集と馴染みのあるオブザーバビリティワークフローを提供するので、ユーザーは体験を自分で作り上げたり、日常的な調査のために SQL を書いたりする必要がありません。

それでも、ユーザーはスタックをデプロイし運用しなければなりません。Managed ClickStack はその負担をさらに取り除きつつ、コレクター、スキーマ、コンピュートのサイジング、チューニング、ワークロードの分離の制御はユーザーの手に残します。この制御は大規模では魅力的な経済性を生みますが、一部のチームが望む以上のものです。

もう一つ、妥当な例外があります。オブザーバビリティプロダクトを構築する企業は、自前のストレージエンジンを正当化できるほど特化したワークロードを持っているかもしれませんし、データストアを持つこと自体が商業的な知的財産の一部だと判断するかもしれません。ロードマップ、振る舞い、トレードオフに対する制御は重要でありえます。代替案が、競合相手でもある企業への依存を意味する場合には特にそうです。データベースを構築し運用するのは高くつく選択ですが、そうした状況では合理的な選択にもなりえます。

ほとんどのユーザーは、オブザーバビリティデータベースを作っているわけでも、オブザーバビリティ市場で競合しているわけでもありません。大量のログとトレース、そして近ごろではメトリクスも保持しクエリする必要があるチームにとって、ClickHouse は依然として有力な既定の選択肢です。

それで、ClickHouse は勝っているのか #

私たちは勝利を宣言するつもりはありません。慢心のリスクだけを考えても、それは賢明ではないからです。しかし証拠は、より狭い結論を支持しています。ClickHouse は、オブザーバビリティシステムを構築する多くのチームにとって事実上のストレージとクエリのエンジンになりました。新しいオブザーバビリティプロダクトで最初に評価すべきバックエンドであり、ほとんどのチームのログとトレース、そして近ごろではメトリクスのワークロードにも応えられると私たちは考えています。

この地位は、元々の列指向アーキテクチャだけに支えられているわけではありません。全文検索インデックスは検索における重要なギャップを埋め、PromQL 対応は従来型メトリクスへの対応を始めており、ClickStack はデータベースの能力をより完全なオブザーバビリティ体験へ変えつつあります。これらの層すべてで成果を出し続けることのほうが、どんな勝利宣言よりも重要です。

Severin Neumann はオブザーバビリティを戦争ではなく無限のゲーム(infinite game)だと表現しました。ゴールラインはありません。量は増え続け、保持への期待は長くなり、人間もエージェントもより難しい問いを投げます。今日先頭にいるものは、明日もその地位をあらためて勝ち取らなければなりません。

ストレージとクエリの層については、ClickHouse が勝てる選択肢であることを私たちも認めてよいでしょう。オブザーバビリティ全体は、1つのデータベースが勝てる戦争だったことなど一度もありません。私たちにとって、仕事はまだ始まったばかりです。