AIワークロードには、ユースケースを問わず、共通して次の要件があります。
- 高いクエリ同時実行性
- サブ秒の応答時間
- 大規模でも完全な精度を保ったデータ
このドキュメントでは、ClickHouse がリアルタイム分析、データウェアハウジング、オブザーバビリティの各領域でこれらの要件にどのように対応するか、またそれらのユースケースがエージェント型アプリケーション向けの統合データプラットフォームへとどのように収束しつつあるかを説明します。
エージェント型ワークロード向け ClickHouse
生成インサイト、異常検知、レコメンデーション、プロダクトデータ向けの自然言語インターフェイスといった AI 活用アプリケーション機能では、トランザクション書き込みと分析読み取りの間で密接なフィードバックループが必要になります。 このための標準的なアーキテクチャが、Postgres + ClickHouse です。
- Postgres がトランザクションとアプリケーションの状態を処理し、ClickHouse が分析を担います。
- ClickHouse は、高速なインジェスト、数十億行に対するサブ秒のクエリ、そして顧客向けアプリケーションに求められる同時実行性を提供します。
アプリケーションのエージェント化が進むほど、この組み合わせの重要性はさらに高まります。 エージェントはライブなプロダクトデータを継続的にクエリする必要があるため、クエリ頻度と同時実行性の両方が増加します。 ClickHouse は、自動データレプリケーションと統一された開発者体験を提供するネイティブな Postgres + ClickHouse 連携によってこれに対応し、個別の CDC パイプラインを管理する必要をなくします。
自然言語分析インターフェイス (AI Analyst と呼ばれることもあります) は、実験段階から本番環境へ移行しつつあります。 ユーザーは平易な英語で質問し、数秒で答えが返ってくることを期待します。
インフラストラクチャの観点では、1 つの自然言語クエリが 1 つの SQL クエリを生成するわけではありません。通常は、エージェントが利用可能なデータセットを探索し、複数の推論経路を評価する中で、短時間に数十個のクエリを生成します。 その結果、社内アナリスト向けのワークロードは、同時実行性とレイテンシの特性において、外部の顧客向けワークロードに近づいていきます。
従来のデータウェアハウスは、低頻度でバッチ指向のクエリ向けに設計されていました。重視しているのは、多数のクエリ全体でのスループットであって、高い同時実行性におけるサブ秒の応答時間ではありません。このアーキテクチャで AI Analyst のワークロードを実行すると、許容できないレイテンシが発生するか、得られる価値を上回るペースでコストが増大します。
ClickHouse は、高い同時実行性のインタラクティブなクエリのために構築されています。ペタバイト規模のデータ、数千の同時ユーザー、数十億行に対するサブ秒の応答時間に対応します。
従来のオブザーバビリティスタックは、メトリクス、ログ、トレースという 3 つの独立した柱の上に構築されており、ストレージコストを抑えるためにデータは事前に集計され、サンプリングされています。このトレードオフは人手中心のワークフローでは許容できますが、AI SRE では成り立ちません。 自動インシデントトリアージ、根本原因分析、異常相関には、きめ細かく、高カーディナリティで、長期間保持されるデータが必要です。3 日前のデプロイメントイベントとエラーパターンを相関させる AI Agent は、サンプリングされたログやダウンサンプリングされたメトリクスでは機能しません。
AI SRE を支えるアーキテクチャは、列指向ストレージに保存された幅広い構造化イベントに基づく単一の信頼できる情報源です。完全な忠実度のイベントを一度だけ保存し、メトリクス、トレース、SLO はインジェスト時に事前集計するのではなく、クエリ時にそこから導出します。 ClickHouse はこのモデルに非常に適しています。
- ログおよびイベントデータに対する高い圧縮率
- 高カーディナリティな wide events に対するサブ秒のクエリ
- 本番インフラストラクチャ規模のデータ量でも効率的なインジェスト
- GB 単位のインジェスト料金ではなく、コンピュートとストレージに基づくコストモデル
ClickStack は、このモデルに基づいて構築された ClickHouse のオブザーバビリティスタックであり、データ収集レイヤーとして OpenTelemetry を使用します。 オープンソース版とマネージドサービスの両方で利用できます。
データウェアハウジングとオブザーバビリティの収束
データウェアハウジングとオブザーバビリティは、これまでそれぞれ異なるベンダー、購買部門、技術スタックを持つ別個の領域として扱われてきました。しかし、この分離は技術的な必然というより、ますます慣習にすぎなくなっています。 現在では、両者ともオブジェクトストレージに書き込みます。どちらも、高い同時実行性の下で対話的かつ低レイテンシのクエリを必要とします。さらにデータレベルでは、同じイベントがオブザーバビリティプラットフォームとデータウェアハウスの両方に保存され、その間を脆弱な同期レイヤーでつないでいることも少なくありません。 こうしたデータをすべてオープンなフォーマットで一度だけ保存し、AI Analyst と AI SRE の両方のツールからクエリできるようにすれば、この重複をなくし、両方のワークフローで必要な文脈を共有できるようになります。
プラットフォーム層: エージェント対応インターフェイスとLLMオブザーバビリティ
完全なエージェント型アナリティクスプラットフォームを構成するには、データベースに加えてさらに2つの要素が必要です。
エージェント対応インターフェイス
AIエージェントがデータへの主要なインターフェイスとなる場合、データプラットフォームは、エージェントが利用できる形でその機能を提供する必要があります。具体的には、MCP互換API、自然言語インターフェイス、そしてユースケースごとに個別実装しなくても統合できるエージェントフレームワークです。Agentic Data Stackは、ClickHouseとLibreChatを組み合わせることで、データに対する分析エージェントをすぐに導入できるターンキーな方法を提供します。
LLMオブザーバビリティ
エージェントの利用が広がるにつれて、その実行のトレーシング、モデル性能の監視、コストの追跡、複数段階のワークフロー全体にまたがる障害のデバッグは、中核となるエンジニアリング要件になります。LangfuseはClickHouse Cloud上で稼働し、大規模なリアルタイムLLMオブザーバビリティを提供します。