Better Stack、ClickHouseとSQLで観測可能性を10倍安く組み直す

Juraj MasarとVeronika Kolejakは、以前の仕事でエンジニアが複数の古い運用ツールをつなぐ苦労を見ていた。

Better Stackの創業時の考えは、Juraj Masarの言葉で「We are simply engineers making the tools we always wanted to use」だった。出典

複雑なobservabilityへの違和感

2021年に始まったBetter Stackは、monitoring、logging、incident management、status pageを一つのプロダクトへ束ねた。

公式発表は、既存ツールが高価で、統合に手間がかかり、理解にも時間がかかることを問題として挙げている。出典

SQLを共通言語にする転換

Veronika Kolejakは、エンジニアの多くが各社固有のquery言語には不慣れでもSQLは知っていると説明した。

ClickHouseを使い、長くhot storageに置ける速度とコストを売りにした。出典

70,000人からAI SREへ

2022年時点で70,000人超の開発者と1,400社超が利用し、Series Aを含む調達は$18.6Mに達した。出典

現在はAI SRE、MCP server、eBPF、OpenTelemetryなどへ機能を広げている。出典

統合の次に残る問い

Better Stackの物語は、ツールを減らすことから、運用データをAIが扱える形にすることへ進んでいる。

読者にとっての示唆は、統合を目的にせず、query・価格・操作体験という具体的な摩擦を同時に解けるかを見ることだ。

開発チームはmonitoring、logs、incident response、status pageを別々に組み合わせる負担を抱える。

Better Stackはそれらを一つのUIにまとめ、SQLとClickHouseで既存observabilityの複雑さとコストを下げる。

公式発表では2022年時点で7万人超の開発者と1,400社超が利用していた。出典

ClickHouseを土台にしたコスト・速度の組み合わせと、monitoringからincident managementまでの統合データモデルが障壁になる。

ただし基盤技術そのものは模倣可能で、UXと蓄積データが重要だ。出典

ネットワーク効果は弱い。

顧客が増えても同じ製品の価値は直接増えず、導入事例と運用知識の蓄積による信頼効果が中心になる。出典

インフラ専任者を大きく置けないスタートアップから、複数サービスを運用する開発チームまで。

SQLに慣れたチームほど移行の学習コストが低い。出典

単なる機能追加ではなく、SQLをobservabilityの共通言語にした点が大きい。

ClickHouseによる高速・低コストなデータ処理と、Figma-likeなUIを同時に訴求している。出典

observability市場はDatadogやNew Relicが強く、既存のqueryや運用を移行するコストが残る。

AI SREは新しい機能領域で、誤検知や説明責任を含む検証が必要だ。出典

開発者向けのfree tier、docs、GitHub、コンテンツで導入障壁を下げ、monitoringからlogs・incident managementへ拡張する。

AI SREとMCPは既存データを新しい操作面へ変える追加導線だ。出典

主要チャネル: content, community, github, product-led

カテゴリの既存大手を正面から機能数で追うのではなく、価格、速度、UI、query言語のような複数の不満を一つの選択理由に束ねる。

統合は「何でも屋」ではなく、共通データモデルがあって初めて効く。

日本ではSaaS導入後の運用担当が限られる企業が多い。

日本語のincident templates、国内リージョン、SIer向けの導入支援を組み合わせれば、価格だけでなく運用標準化として提案できる。