Datadogの代替となるか？Observability Databaseという新カテゴリ——ClickHouse×OpenTelemetryで構築するセルフホスト監視基盤

はじめに——監視費がインフラコストの重荷になりやすい理由

監視SaaSの請求書を見て息を呑んだ経験はありませんか。本記事では、監視コストがなぜ膨らみやすいのかを整理したうえで、テレメトリを列指向データベースに蓄えてSQLで分析する「Observability Database」という選択肢を、ClickHouse×OpenTelemetryの実装であるClickStackを通じて解説します。

ClickHouse社のTCOガイド（2025年11月更新）も「監視の請求額は、多くのエンジニアリング組織で最大級のインフラ費用のひとつになった」と指摘しています。テレメトリ量が増え続けるいま、監視費は他人事ではなくなってきています。

構造的な原因は課金モデルにあります。SaaS監視プラットフォームは、取り込みGB単位・ホスト単位・高カーディナリティメトリクス単位の従量課金が基本で、「見えるほど払う」構造です。さらにデータの保持期間は別SKUとして高額に設定されており、保存期間を延ばすだけで請求が跳ね上がります。つまり「全データを送って全部見る」という理想の監視が、経済的に難しくなりがちなのです。

これは自宅サーバや小規模インフラでも話は同じです。ログ・メトリクス・トレースを丁寧に収集すればするほど、監視費がインフラコストの中で大きな割合を占めることも珍しくありません。

本記事では、この問題への解として、Observability Databaseとは何か（そしてどのアーキテクチャ世代に位置するのか）、ClickStackの構成、主要スタックとの比較、セルフホスト構築のステップ、そして「セルフホストは無料ではない」という正直なコスト評価までを順に扱います。

Observability Databaseとは何か——なぜ今「データベース」なのか

前節で見た監視費の問題は、実はアーキテクチャの選択に根があります。ここでは監視システムの変遷を3つの世代で整理し、「Observability Database」と呼ばれるカテゴリがなぜ今登場したのかを説明します。

ClickHouse社が自社ガイドで整理するところによると、監視アーキテクチャは3つの世代を経てきました（注：この3世代分類と「Search-Fortress型」などの用語は、同社の資料におけるフレーミングであり、業界標準の用語ではありません）。

1. Search-Fortress型（ELK/OpenSearch）: Apache Luceneの転置インデックス中心。テキスト検索やSIEM用途には強いものの、監視分析ではストレージ肥大と高カーディナリティ集計で破綻しやすいと同社は指摘します。Parseableの試算では、100TB/日のワークロードでElasticsearchのコストは月10万ドルを超えうるとされ（ClickHouse社のガイドもこの数値を引用）、同社ガイドではクラスタ障害時の復旧の重さも併記されています
2. Best-of-Breed連邦型（LGTMスタック）: Loki（ログ）+Mimir（メトリクス）+Tempo（トレース）+Grafanaのように目的別ツールを組み合わせる。ただしデータサイロが発生し、インシデント時に複数UIを行き来する「回転椅子分析（swivel-chair analysis）」でMTTRが延びやすいとされます
3. 統一データベース型（Observability Database）: すべてのテレメトリを1つの列指向DBに格納し、ログ・トレース・メトリクス・セッションをDBレベルで相互照会する

従来の「メトリクス・ログ・トレースの3本の柱」モデルは、シグナルごとに最適化する一方で、相関分析が人間の画面切り替えと記憶に依存する構造的な弱点を抱えていました。インシデント時に「メトリクスの異常→該当ログ検索→トレース取得」と複数ツールを行き来するコストが、そのまま復旧時間に乗ってしまうのです。

flowchart TB
    subgraph G1["第1世代: Search-Fortress型（ELK / OpenSearch）"]
        A1[アプリ / サーバ] --> B1[Logstash / Agent]
        B1 --> C1["Elasticsearch（Lucene転置インデックス）"]
        C1 --> D1[Kibana]
    end
    subgraph G2["第2世代: Best-of-Breed連邦型（LGTMスタック）"]
        A2[アプリ / サーバ] --> B2[各種Agent]
        B2 --> C2a[Loki ログ]
        B2 --> C2b[Mimir メトリクス]
        B2 --> C2c[Tempo トレース]
        C2a --> D2[Grafana]
        C2b --> D2
        C2c --> D2
    end
    subgraph G3["第3世代: 統一データベース型（Observability Database）"]
        A3[アプリ / サーバ] --> B3[OTel Collector]
        B3 --> C3["ClickHouse（列指向DB・全テレメトリ統合）"]
        C3 --> D3[HyperDX / SQL]
    end
    G1 -->|ストレージ肥大・高カーディナリティで破綻しやすい| G2
    G2 -->|データサイロ・回転椅子分析でMTTR悪化| G3

では、なぜ列指向DBは監視に向くのでしょうか。テレメトリデータは「大量に追記し、一部カラムだけを集計して読む」という典型的なOLAPパターンだからです。ClickHouse社は列指向圧縮で15〜50倍と主張しており（同社TCOガイド）、ログでは最大170倍とする同社側の報告もあります。後述する国内企業の公開事例でも高い圧縮率が報告されています。また、user_idのような高カーディナリティ次元の組み合わせ爆発はPrometheus等でメモリ膨張を招きますが、列指向DBはこの集計が得意分野とされます。

もう一つの前提変化がOpenTelemetryの標準化です。ClickHouse社のガイドでは、2026年時点でOTelはCNCFで2番目に活発なプロジェクトと紹介されており、ベンダーニュートラルな計装・転送の業界標準になっています。OTel Collectorはreceiver→processor→exporterのパイプラインを構成し、バックエンドは設定ファイルの変更だけで差し替え可能です。計装が標準化された結果、ボトルネックは「バックエンドのスケール性能とコスト」に移りました。つまり、バックエンドを自分で選べる時代になったのです。

ClickStackの全容——OTel Collector + ClickHouse + HyperDX

Observability Databaseの構想を具体的なプロダクトとして実装したものが、ClickHouse社が提供するオープンソースの「ClickStack」です。このセクションでは、公式ドキュメントに基づいてその構成要素と役割分担を解説します（以下は2026年8月時点の公式ドキュメントに基づく構成です）。

ClickStackは3つのコアコンポーネントで構成されます。

1. OpenTelemetry Collector（ClickStack配布版）: 事前設定済みでClickHouseへの取り込みに最適化されており、バッチ挿入で効率化されています
2. ClickHouse: 列指向分析DB。高カーディナリティ耐性、並列実行エンジン、ネイティブJSON対応を備えます
3. ClickStack UI（HyperDX）: 監視用途に特化したフロントエンド

UIを担うHyperDXは、GitHubで「ClickHouseのためのKibana」と説明されるOSSです。もともと独立したOSSプロジェクトとして開発され、ClickStackのUIとして統合されました。Lucene風の検索構文（例: level:err）とSQLの両方でクエリでき、ライブログテール、イベント差分、ログパターン認識、アラートといった監視に必要な機能を備えています。「SQLで全部書くのは大変、でも複雑なときはSQLの全文検索に頼りたい」という両方のニーズに応える設計です。

運用形態は複数用意されています。完全セルフホスト（OSS）の場合、ダッシュボードやユーザーアカウントなどアプリ状態の保存用に、追加でMongoDBインスタンスが必要です（HyperDX公式リポジトリ/ドキュメント参照）。一方のManaged ClickStackでは、ClickHouse CloudがDBとUIをホストし、ユーザーはCollectorだけを運用します。公式のデプロイ手段としては、このほかにDocker Compose、Kubernetes向けの公式Helmチャート、全コンポーネント同梱のAll-in-Oneコンテナ（本番非推奨）などが用意されています。スキーマは任意のClickHouseスキーマ上で動作し（schema agnostic）、完全なオープンソースとしてどこでもデプロイ可能です。

flowchart LR
    App[アプリケーション / サーバ] -->|OTLP| OTel["OpenTelemetry Collector<br/>（ClickStack配布版）"]
    OTel -->|バッチ挿入| CH[("ClickHouse<br/>（列指向分析DB）")]
    UI["HyperDX（ClickStack UI）<br/>Lucene風検索 / SQL / ライブテール"] -->|クエリ| CH
    Mongo[("MongoDB<br/>ダッシュボード・アカウント状態")] --- UI
    User[エンジニア] --> UI

自宅サーバ派にとって嬉しいのは、この全体がdocker-composeやKubernetes（公式Helmチャート）で自分のマシンに載せられる点です。次節以降で、他スタックとの比較と実際の構築手順を見ていきましょう。

主要スタック比較——ELK・LGTM・ClickStack・SaaS

監視基盤の候補は、アーキテクチャの3世代（Search-Fortress型のELK、連邦型のLGTM、統一DB型のClickStack）とSaaS型監視サービスの4系統に整理できます。ここでは、選定時に実際に破綻しやすい5つの軸——コスト構造、データサイロ、高カーディナリティ耐性、運用負荷、相関分析——で比較表にまとめました。

※表中の定量値は各社の公表資料・公開事例に基づくもので、測定条件はそれぞれ異なります。「Search-Fortress型」等の用語を含む分類はClickHouse社のフレーミングに基づき、定性的評価は公式資料と公開事例をもとにした本記事編集時点（2026年8月）の整理です。

各スタックの破綻ポイント——リトマス試験

• ELK / OpenSearch：破綻はまずストレージから始まります。Lucene転置インデックスはテキスト検索やSIEM用途には強いものの、集計系ワークロードではストレージオーバーヘッドが大きく、user_idのような高カーディナリティフィールドの集計で性能が落ちやすい構造です（ClickHouse社の分析による指摘）。
• LGTMスタック：各コンポーネント自体は安定している一方、「3本の柱」がそのままデータサイロになります。インシデント時に複数UIを行き来する回転椅子分析でMTTRが延びるのは、運用した人ほど実感する弱点です。
• SaaS（Datadog等）：運用の省力化は最も優れていますが、「見えるほど払う」従量課金と保持期間の別課金が、テレメトリ量の増加とともに請求書を膨らませます。
• ClickStack：コスト構造と相関分析に強みがある代わりに、運用責任はすべて自分に帰ってきます。

正直なトレードオフを言えば、OSSへの移行は「従量課金を人件費と計算機費に変換する取引」です。テレメトリ量が少なく運用工数を割けない小規模チームにはSaaSが依然として合理的であり、逆にデータ量が多くデータ主権・マルチクラウドの要件があるチームにはセルフホストが効きます。どちらが得になるかは、後述の「コストの正直な話」のセクションで具体化します。

実践ガイド——セルフホスト構築のステップと実例

比較で全体像が見えたところで、次は実際に構築するステップです。国内にも公開事例があります。コンタクトセンターAI「X-Ghost」をBYOC環境で提供する株式会社GENAXが2026年にZennで公開した記事によると、①テレメトリを顧客環境の外に出せない（データ主権）②マルチクラウドでプロバイダ依存を避けたい、③取り込み量課金がつらい——という理由でClickHouse + HyperDX（ClickStack）を採用し、ある環境ではログテーブルで約20分の1、メトリクス系テーブルで40分の1以上の圧縮率をsystem.partsで確認できたと報告しています。圧縮率はsystem.partsで確認できるため、自分のデータでも検証可能です。

構築ステップ（一つの運用設計例）

以下のステップは、GENAXの公開事例に基づく「一つの運用設計例」です。公式に必須とされる手順ではなく、環境や要件に応じた調整が必要です。

1. 計装をOTelに寄せる — Collectorのreceiver→processor→exporterパイプラインで、バックエンド差し替えを設定変更レベルにしておく
2. Collectorを配備 — ClickStack配布版の事前設定済みCollectorを使いつつ、create_schema: false としてスキーマ自動作成はオフにする
3. スキーマをマイグレーション管理 — golang-migrate + Helm hookでSQLとして管理。テーブルはReplicatedMergeTree + ClickHouse Keeperでレプリケーションし、TTLはホット7日→コールド経由→90日削除で設計
4. HyperDX UIを配備 — ダッシュボードは公式のdashboard provisioner（JSON）でGit管理。アラート・保存検索のYAML宣言的なCI/CD適用は同社の内製CLIによるもの
5. アラート・SQLをCIでテスト — 登録SQLをchDBでオフラインテストし、誤検知や重クエリをデプロイ前に防止

ハマりどころ

GENAXの知見で特筆すべきは「スキーマ自動作成に頼らない」姿勢です。取り込み時の自動スキーマは便利ですが、本番運用ではTTLやレプリケーション込みのスキーマをコード管理する方が事故りにくいという判断です。また、HyperDX MCP / ClickHouse MCPを用意してAIエージェントからの読み取り口を人間と分離（user/role分離）している点も、AIエージェントが運用に入り込む時代の実践的なパターンとして参考になります。

コストの正直な話——「セルフホストは無料」ではない

ここまでの数字は魅力的ですが、最も厳しい警告はClickHouse社自身が発しています。同社のTCOガイド（2025年11月更新）は、セルフホストにはエンジニアの保守・オンコールによる「People TCO」として月1,600〜4,800ドルが加算されうると明記し（算定前提の詳細は原文参照。あくまで同社試算の一例です）、バースト性の高いワークロードではマネージドの方が安い場合もあると自ら注意喚起しています。

圧縮率も慎重に扱いましょう。ClickHouse社の主張は15〜50倍（同社TCOガイド。ログで最大170倍とする同社側の報告もあります）、GENAXの公開事例ではある環境でログ約20倍・メトリクス40倍以上が報告されています。圧縮率はデータ特性に大きく依存するため、10〜50倍程度のレンジで考え、自分のデータでsystem.partsを実測するのが誠実な姿勢です。

どちらが安くなるかは、①テレメトリ量（SaaS従量課金が支配的か）、②バースト性（瞬間増幅に備えた計算機の常備は割高）、③チーム規模（運用工数を割けるか）、④データ主権要件——の4点でほぼ決まります。判断フローチャートにまとめました。

flowchart TD
    A[監視基盤の選択] --> B{SaaS課金が支配的?}
    B -->|いいえ| C{運用工数を割ける?}
    C -->|いいえ| D[SaaSのまま計装だけOTel化]
    C -->|はい| E[ClickStackセルフホスト]
    B -->|はい| F{バースト性が高い?}
    F -->|はい| G{データ主権要件あり?}
    G -->|いいえ| H[Managed ClickStack等の検討]
    G -->|はい| E
    F -->|いいえ| E

フローチャートが示す通り、答えは一意ではありません。重要なのは、計装をOTelに寄せておけばバックエンドの差し替えコストを大幅に下げられることです。つまり今すぐ全面移行しなくても、「いつでも逃げられる状態」を作れることこそが、監視コスト交渉における最も強力なカードになります。

よくある質問（FAQ）

ClickStackやObservability Databaseへの移行を検討する際に、よく寄せられる疑問をFAQ形式でまとめました。判断材料としてお役立てください。

Datadogからの移行は現実的？

計装をOpenTelemetryに寄せていれば、バックエンドの差し替えはOTel Collectorの設定変更レベルで済みます。ただし、ダッシュボードやアラートの再構築、そして運用保守の人的コストは別途必要です。「データの送り先変更は軽いが、見せ方の作り直しと運用引き受けが本番」と捉えると、移行の見通しが立ちます。

セルフホストのPeople TCOは？

ClickHouse社の自社試算（TCOガイド、2025年11月更新）では、セルフホストにはエンジニアの保守・オンコールによる「People TCO」として月1,600〜4,800ドルが加算されうるとされています（算定前提は原文参照）。同社自身、小規模チームやバースト性の高いワークロードではマネージドやSaaSの方が安い場合があると注意喚起しています。「セルフホスト＝無料」ではない点を押さえましょう。

ClickStackの構成要素は？

公式ドキュメントによると、3つのコアコンポーネントで構成されます。①ClickHouseへの取り込みに最適化された事前設定済みのOpenTelemetry Collector、②列指向分析DBのClickHouse本体、③監視特化UIのClickStack UI（HyperDX）です。OSS版ではさらに、ダッシュボードやユーザーアカウントなどのアプリ状態を保存するためにMongoDBが別途必要です。

圧縮率はどのくらい？

ClickHouse社は列指向圧縮で15〜50倍と主張しています（同社TCOガイド。ログで最大170倍とする同社側の報告もあります）。国内の公開事例（GENAX）でも、ある環境でログテーブル約20分の1、メトリクス系テーブル40分の1以上の圧縮率がsystem.partsで確認されたと報告されています。ただし圧縮率はデータ特性に大きく依存するため、10〜50倍程度のレンジで見積もるのが安全です。

高カーディナリティ問題とは？

user_idやリクエストIDのように一意な値の組み合わせが爆発的に増えることで、Prometheusなどのメモリが膨張する問題です。テレメトリのタグやディメンションが増えるほど深刻化します。列指向DBはこうした高カーディナリティの集計が得意分野とされており、Observability Databaseが注目される理由のひとつです。

まとめ——次に取るべき3つのアクション

Observability Databaseは万能薬ではありません。しかし「見えるほど払う」SaaS課金に疲れているなら、検討する価値は十分にあります。大規模移行を決める前に、次の3つの小さな一歩から始めてください。

アクション1: 既存計装のOTel対応率を確認する

バックエンドの差し替えが設定変更レベルで済むかどうかは、計装のOpenTelemetry対応率でほぼ決まります。アプリケーションとミドルウェアの計装を棚卸しし、OTel化の進捗を把握しましょう。

アクション2: system.partsで圧縮率を自分のデータで測る

圧縮率はデータ特性に依存します。既にClickHouseを運用しているなら、system.partsで実際の圧縮率を測定し、コスト試算の土台にしましょう。

アクション3: 小さな環境でClickStackを試す

完全OSSでどこでもデプロイ可能なClickStackを、自宅サーバやステージング環境の一部ログから試してみてください。実データでの手触りが、本番移行の判断材料になります。

監視コストとの付き合い方は、日々の小さな検証から変わります。まずは計装の棚卸しと圧縮率の実測——この2つから始めてみてください。

参考文献

本記事の主張は、以下の公開資料に基づきます（いずれも2026年8月15〜16日時点で確認）。

• ClickHouse「A practical guide to observability TCO and cost reduction」（2025年11月26日更新）: https://clickhouse.com/resources/engineering/observability-tco-cost-reduction
  • 3世代分類の背景、Lucene系ストレージの課題、圧縮15〜50倍、People TCO月1,600〜4,800ドル、バースト性ワークロードでの注意喚起の出典
• ClickHouse「Best Open Source Observability Solutions (2026 Guide)」（2025年11月10日更新）: https://clickhouse.com/resources/engineering/best-open-source-observability-solutions
  • 3世代分類（Search-Fortress／Best-of-Breed／Unified Database）、回転椅子分析、OTelのCNCF活動順位紹介、Elasticsearch月10万ドル超の引用の出典
• Parseable「The Economics and Physics of 100 TB daily telemetry data」: https://www.parseable.com/blog/the-economics-and-physics-of-100-tb-telemetry-data-per-day
  • 100TB/日ワークロードの経済性試算（Elasticsearch/OpenSearchのコスト試算）の出典
• ClickStack公式ドキュメント（Overview）: https://clickhouse.com/docs/clickstack/overview
  • 3コンポーネント構成、schema agnostic、Lucene風検索+SQL、機能一覧の出典
• ClickStack公式ドキュメント（Deployment options）: https://clickhouse.com/docs/clickstack/deployment/overview
  • Managed／Docker Compose／Helm／All-in-One等のデプロイ形態の出典
• HyperDX GitHub: https://github.com/hyperdxio/hyperdx
  • 「ClickHouseのためのKibana」の説明、OSS版のMongoDB要件の参照先
• ClickStack GitHub: https://github.com/ClickHouse/clickstack
• 株式会社GENAX「ClickHouse + HyperDX で作るセルフホストなオブザーバビリティ基盤」（Zenn, 2026年）: https://zenn.dev/genax_corp/articles/a88f9fa2026107
  • 導入理由、圧縮率実測（ログ約20分の1・メトリクス40分の1以上）、スキーママイグレーション/TTL/ユーザー分離等の運用設計の出典
• Qiita「OpenTelemetryとClickHouseで構築するObservability」（二次資料・日本語参考）: https://qiita.com/0h-n0/items/6f687a0e826944334156

関連記事

• OpenForgeRLで切り拓く、自宅サーバーで育てるAIエージェント