---
title: "AIがデータベース市場を再定義する"
date: "2026-07-14T12:57:29.374Z"
author: "Tanya Bragin"
category: "Product"
excerpt: "AIは、リアルタイム分析、データウェアハウス、オブザーバビリティといった領域でデータベース市場の要件を再構築しており、ClickHouseはそれらの要件を満たすうえで他に類を見ない立ち位置にあります。"
---
# AIがデータベース市場を再定義する
## Summary
* AIの導入とは、単にユーザー体験を再考することにとどまらず、データ戦略を正しく構築することでもあります。これを誤れば、AIの取り組みは失敗に終わります。
* AIワークロードは、高い同時実行性、リアルタイムなクエリ処理、そしてスケールしたフルフィデリティ(完全な粒度)のデータを要求します。従来のバッチ指向アーキテクチャは、これらを想定して設計されてはいません。
* これまでサイロ化していたユースケース、例えばデータウェアハウスとオブザーバビリティが、データレイヤーにおいて収束しつつあります。
* ClickHouseは、AIアプリ、AIアナリスト、AI SREといった体験にわたるAIワークロードを支える統一プラットフォームへと進化しています。詳細は本文をご覧ください。
AIは、データプラットフォーム上にもう一つ加わっただけのワークロードではありません。既存のあらゆるユースケースにおいて、ワークロードに対する期待値そのものを根本的に変えてしまいます。
今まさに起こっている3つの大きな変化は、1) アプリケーションがエージェンティックになりつつあること、2) 分析インターフェースが会話型になりつつあること、3) オブザーバビリティが静的なダッシュボードからAI駆動の調査へと移行していること、です。いずれのケースでも、根底にあるデータ要件は、高い同時実行性、リアルタイムのクエリ性能、スケールしたフルフィデリティのデータ、という同じ点に収束していきます。
これらは、既存のデータプラットフォームが想定して設計された要件ではありません。今後数年間に下されるデータプラットフォームの選択が、何が可能になるか、つまりチームがどれだけ速く動けるか、どのようなプロダクトを作れるか、ビジネスにとってどのようなインサイトに到達できるか、を形作ります。今問うべきは、今のプラットフォームが今日のワークロードを処理できるかどうかだけでなく、AI駆動のアプリケーションが実際に求めるものに対して正しい土台となっているかどうか、です。
[以前の投稿](https://clickhouse.com/blog/the-unbundling-of-the-cloud-data-warehouse)で、私はクラウドデータウェアハウスのアンバンドリングについて書きました。インタラクティブで顧客向けのアプリケーションへのシフトが、バッチ指向のウェアハウスとリアルタイムワークロードとのアーキテクチャ上のミスマッチを露呈させてきたという話です。本稿で説明したいのは、その次の波となる破壊的変化で、それは「リアルタイム分析」「データウェアハウス」「オブザーバビリティ」の3つの市場をまたいで起こっています。
リアルタイム分析: 「ベストオブブリード」データベースの夜明け
**ステークホルダー: 次世代のユーザー向けおよびAI駆動アプリケーションを構築する開発者**
Postgresは、行指向のトランザクションデータを扱う卓越した能力により、現代的なユーザー向けアプリケーションを構築するデフォルトのデータベースになりました。これは、アプリケーションが本格的にデータインテンシブになるまでは問題なく機能していました。リアルタイムダッシュボード、利用状況分析、顧客向けメトリクス、毎秒数百万行のイベントストリームなどがそれを牽引しています。こうしたますます分析的になるワークロードに対しては、Postgres単独ではスケールしなくなりました。クエリは遅すぎ、インデックスはコストが高すぎ、同時実行性は低すぎたのです。
業界が辿り着いた解は、Postgres + ClickHouseでした。トランザクションとアプリケーションの状態はPostgresが担い、分析はClickHouseが担うという組み合わせです。このペアリングは、本格的な分析要件を持つ顧客向けアプリケーションにとって、事実上のモダンデータスタックとなりました。ClickHouseは分析ワークロードにおける明白な選択肢へと進化しました。高速な取り込み、数十億行に対するサブ秒クエリ、顧客向けアプリケーションが要求する同時実行レベルでも効率的な動作。データは[CDCパイプライン](https://clickhouse.com/blog/clickhouse-welcomes-peerdb-adding-the-fastest-postgres-cdc-to-the-fastest-olap-database)経由でPostgresからClickHouseに移動し、ClickHouseが組み込み型のプロダクト分析から顧客向けダッシュボードまで、あらゆるものを動かすようになったのです。
そして今、AIが、現代的なAIアプリケーションやそれを動かすエージェントを構築するためのトランザクショナルおよび分析的基盤の必要性を加速しています。AIによって生成されるインサイト、異常検知、レコメンデーション、プロダクトデータへの自然言語インターフェースなど、LLMベースの機能は、トランザクション書き込みと分析読み取りの間でより緊密なフィードバックループを必要とします。これが、私たちが[ネイティブなPostgres + ClickHouse](https://clickhouse.com/blog/postgres-managed-by-clickhouse)データスタックの構築に本腰を入れている理由です。Postgresがトランザクションワークロードを処理し、ClickHouseが分析を処理する、エンジンレベルでネイティブな拡張機能を介して緊密に統合された単一の統一体験です。自動的なデータレプリケーションと管理、そして統一された開発者体験を実現します。
顧客向け体験を構築するプラットフォームの意思決定者にとって、方向性は明確です。データストアレイヤーにおいて、トランザクションと分析の両方の機能が必要とされています。そして、「ベストオブブリード」のメリットを失わずに、トランザクションと分析の機能を緊密に統合できることは、開発者のワークフローを高速化し、AIを活用した新機能をより早く出荷可能にする、追加のアドバンテージとなります。
---
## 今日から始めましょう
ClickHouseがあなたのデータでどのように動作するか興味がありますか? わずか数分でClickHouse Cloudを始めることができ、$300の無料クレジットを受け取れます。
[Sign up](https://console.clickhouse.cloud/signUp?loc=blog-cta-1294-sign-up&utm_blogctaid=1294)
---
データウェアハウス: AIアナリストのワークロードがバッチ指向DWHアーキテクチャを破壊する
**ステークホルダー: データウェアハウスとビジネス分析を近代化するデータエンジニアリングチーム**
[アンバンドリングの投稿](https://clickhouse.com/blog/the-unbundling-of-the-cloud-data-warehouse)で、私はSnowflakeのようなクラウドデータウェアハウスがバッチ取り込み、ヘビーなETL、定期的なレポート用に設計されていたこと、そしてそれがインタラクティブな顧客向けアプリケーションには不向きであった理由を述べました。
そして今、伝統的なデータウェアハウスの役割が、その「主戦場」とも言えるユースケースにおいて問い直されています。「AIアナリスト」の登場により、自然言語のプロンプトから始まり、アドホックなレポートやダッシュボードを含む下流の成果物を導出するというビジネス分析の在り方です。
text-to-SQLツールや自然言語分析インターフェースに支えられた[エージェント向け分析](https://clickhouse.com/blog/agent-facing-analytics)は、実験段階から本番運用へと移りつつあります。UXへの影響は明白です。ユーザーは平易な英語で質問し、数秒以内の回答を期待します。インフラへの影響はそれほど明白ではありませんが、より重大です。各自然言語クエリは1本のSQLクエリを生成するだけにとどまらず、利用可能なデータセットを探索し、多くの並列な可能性について推論する過程で、立て続けに数十本のクエリを発行することがあります。一見ユーザーからの単一の質問に見えるものが、データベースに対する同時並行クエリのバーストとなります。その結果、内部のアナリストが生成するワークロードが、外部の顧客向けワークロード、すなわち高同時実行性、低レイテンシ、インタラクティブな応答に似てきます。同じパターンは、問題を解決する過程で意思決定の根拠となる正しいデータポイントを見つけるために、自律的にデータプラットフォームへクエリを投げるエージェントにも当てはまります。
これは、レガシーデータウェアハウスアーキテクチャが前提としてきたものをひっくり返します。SnowflakeやDatabricksのようなプラットフォームは、アドホックでバッチ指向の分析向けに設計されてきました。それらの計算モデルは、クエリが頻繁ではなく、本質的に非インタラクティブであることを前提としています。多数のクエリを通じた全体スループットの高さを最適化しており、各クエリの高同時実行性や低レイテンシを最適化しているわけではありません。AIアナリストの体験はクエリを高速かつ非常に頻繁なものにし、そのワークロードをレガシーDWHアーキテクチャ上で動かすということは、許容できないレイテンシ(AIアシスタントが遅く感じられる)か、提供価値以上に急速に膨らむコストか、いずれかを意味します。
ClickHouseは、こうした要件、つまりペタバイト規模のデータ、高いクエリ同時実行性、サブ秒の応答時間、で卓越するためにゼロから構築されました。バッチレポートを稀に実行するアナリストではなく、数十億行に対してインタラクティブなクエリを実行する数千の同時ユーザーにサービスを提供するように設計されています。結局のところ、これらはまさにエージェンティック時代が要求する特性なのです。
長期的なプラットフォームに賭けようとしているチームにとって、計算式はシンプルです。AI駆動のビジネス分析は将来の可能性ではなく、すでに現実です。これまでのバッチレポート時代に適していたプラットフォームは、その技術的要件を満たしません。レガシーなデータウェアハウスシステムからの移行コストは実在しますが、有限です。一方、競合がインタラクティブなAI分析を実行している間に、誤ったプラットフォーム上で同時実行性に対する税を支払いながら今後5年間を過ごすコストの方が、はるかに大きいのです。
オブザーバビリティ: AI SREはスケールしたきめ細かいデータを要求する
**ステークホルダー: オブザーバビリティ戦略を担うプラットフォーム/インフラチーム**
伝統的なオブザーバビリティスタックは、メトリクス、ログ、トレースという3つの独立した柱を中心に構築されており、それぞれが専用のシステムに格納されてきました。このアーキテクチャは、ストレージとコンピュートが高価だった時代には理にかなっていました。メトリクスは事前集計し、ログはサンプリングし、トレースの保持期間を短くしてコストを抑えていたのです。そのトレードオフは管理可能なものでした。
AI SREのワークフローは、2つの新たな圧力をもたらすことでこのモデルを破壊します。それは、自然言語クエリの大量同時発行と、自動化されたインシデントトリアージ、根本原因分析、異常相関を駆動するための、きめ細かく、ハイカーディナリティで、長期保持のデータを常に必要とすることです。サンプリングされたログやダウンサンプリングされたメトリクスは、3日前のデプロイイベントとエラーパターンを相関させようとするAIエージェントにとっては役に立ちません。AIツールに高い能力を求めれば求めるほど、保持すべきデータは増え、既存プラットフォームのコスト構造はそれに反する形で効いてきます。
これは、Charity Majorsが[Observability 2.0](https://charity.wtf/tag/observability-2-0/)と呼んできた核心的なシフトです。すなわち、3本柱モデルを、列指向ストレージエンジンに保存された幅広い構造化イベントに基づく単一の真実の情報源へと置き換えることです。事前に問う質問を決めて事前集計するのではなく、フルフィデリティなイベントを保存し、クエリ時にメトリクス、トレース、SLOを導出します。現代のオブザーバビリティ企業は今やこのモデルの上に作られており、その多くがメインのストレージエンジンとしてClickHouseを使用しています。
Datadogのような伝統的なオブザーバビリティのプレイヤーは、ここで真の「イノベーターのジレンマ」に直面しています。彼らはデータ量に基づいて課金しており、プラットフォームには大幅なレート制限が設定されているため、顧客はコストを抑えるために、より「少ない」データを取り込むよう訓練されてきました。ログをサンプリングし、メトリクスをダウンサンプリングし、トレース保持を制限する、といった具合にです。AI SREのワークフローを実現するためにGBあたりの単価を下げることは、ビジネスの基盤となっている収益モデルを共食いすることを意味します。幅広いイベントと列指向ストレージを中心に再構築するということは、彼らが何十年にもわたってスケールさせてきた特殊なデータ構造や価格メカニズムを捨てるということでもあります。
一方、ClickHouseは単純な理由でこの領域に独自に適しています。ログやイベントデータに対する高い圧縮率、ハイカーディナリティの幅広いイベントに対するサブ秒クエリ、本番インフラが生成する取り込み量での効率的な動作、そしてGBあたりのデータ取り込み料金ではなくコンピュートとストレージに基づくコストモデル、です。
これが、私たちがOpenTelemetryとClickHouseに基づくオブザーバビリティ、確立されたUIとAI SREの機能を備えた、ターンキーなオブザーバビリティスタック[ClickStack](https://clickhouse.com/clickstack)に投資している理由でもあります。これは[オープンソース](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started/oss)と[マネージドサービス](https://clickhouse.com/blog/introducing-managed-clickstack-beta)の双方で利用可能です。
オブザーバビリティとDWHは収束する: 2つの市場、1つのアーキテクチャ
データウェアハウスとオブザーバビリティは、過去10年間、別々のドメインとして扱われてきました。バイヤーも、ベンダーも、スタックも別々でした。そして歴史的には、ストレージバックエンド、ユーザーインターフェース、利用パターンといった観点で、その分離には技術的な意味がいくらかありました。データセットさえも異なっていたのです。なぜなら、当初はオンラインプレゼンスを原動力とするビジネスはほとんどなかったからです。
今日、この分離は技術的な必要性というよりも、時代遅れの慣習です。ストレージ側では、ビジネス分析であれオブザーバビリティであれ、事実上すべての現代的なデータプラットフォームがオブジェクトストアに書き込みます。そしてコンピュートエンジンには、AIアナリストやAI SRE機能のサポートと併せて、高同時実行性かつインタラクティブで低レイテンシなクエリが要求されます。
最後に、過去にはほとんどのチームがオブザーバビリティのデータを純粋にオペレーショナルなものとして扱っていました。しかし実際には、APIコールは購買であり、エラーは失敗したトランザクションです。同じ真実の情報源を見るのではなく、しばしば同じイベントが2つのプラットフォームに2チームによって二重に保存され、その間に脆弱な同期レイヤーが挟まる、という形になっています。
これらすべてをビジネスデータとして捉え直し、オープンフォーマットで一度だけ保存し、AIアナリストとAI SREの両方のツーリングからクエリ可能にするチームは、その重複を取り除き、どちらのサイロ単独では持ち得なかった文脈を解き放ちます。
2026年の完全なデータプラットフォームは、単なるデータベース以上のものです。データベースに加えて、それをAIエージェントからアクセス可能にするツール群、そしてエージェントの振る舞いを理解するための計装が含まれます。
2つのことが同時に起きています。第一に、AIエージェントがデータへの主要なインターフェースになりつつあります。ユーザーはますますSQLを書かなくなり、代わりに自然言語で質問し、エージェントがその質問をクエリに分解し、実行し、結果を統合します。これはつまり、データプラットフォームが自身の能力をエージェントに対してネイティブに公開する必要があるということです。既製のUI、MCP互換のAPI、すべてのユースケースで個別のインテグレーション作業を必要とせずにデータへ手を伸ばせるエージェントフレームワークが求められます。これが、私たちが主要なオープンソースAIチャットプラットフォームである[LibreChat](https://clickhouse.com/blog/librechat-open-source-agentic-data-stack)を買収し、それをエージェンティックデータスタックと呼ぶものの中核コンポーネントとした理由です。LibreChatとClickHouseを組み合わせることで、チームは自分たちのデータの上に分析エージェントを、エージェント層をゼロから構築することなく、ターンキー方式でデプロイできるようになります。
第二に、AIエージェントが普及するにつれて、それらの振る舞いを理解し、ガバナンスを効かせることが第一級のエンジニアリング上の課題になります。LLMオブザーバビリティ、すなわちエージェントの実行のトレース、モデル性能のモニタリング、コストの追跡、複数ステップにわたるエージェンティックワークフローの失敗のデバッグ、はオプショナルなインフラではありません。それは、AIを自信を持って本番運用するか、POC/実験フェーズで止まってしまうか、の分かれ目です。エージェンティックなシステムにおけるオブザーバビリティの問題は、伝統的なソフトウェアよりも難しいのです。実行グラフは動的で、入出力は高次元で、失敗はしばしば二値ではなく微妙な形をしています。ClickHouse Cloud上で稼働し、スケールしたリアルタイムLLMオブザーバビリティを実現する[Langfuse](https://clickhouse.com/blog/langfuse-llm-analytics)が、この問題を解いています。
プラットフォームの意思決定者にとって、結論は明らかです。データベースは必要ですが、十分ではありません。完全なピクチャーには、エージェント対応のインターフェースとLLMオブザーバビリティのツールが、データプラットフォーム体験にネイティブに統合された形で含まれます。
ClickHouseは、私たちが**インタラクティブなAI駆動アプリケーションのための統一データプラットフォーム**と捉えるものへと進化しています。トランザクションと分析のワークロード、モダンなリアルタイムデータウェアハウスと会話型BI、そして進化するAI SRE駆動のオブザーバビリティワークフローを、AIネイティブなアプリケーションが要求する性能とコストのプロファイルで、すべて単一のプラットフォーム上で扱えるようにするものです。
市場は急速に動いており、次の時代を勝ち抜くプラットフォームはすでに見えています。長期的なインフラの意思決定を行うすべてのチームにとって問うべき問いは、移行コストがまだ管理可能な今、正しい賭けをしているか、それとも後でより困難でより高コストな意思決定をすることになるか、です。
---
## 今日から始めましょう
ClickHouseがあなたのデータでどのように動作するか興味がありますか? わずか数分でClickHouse Cloudを始めることができ、$300の無料クレジットを受け取れます。
[Sign up](https://console.clickhouse.cloud/signUp?loc=blog-cta-1295-sign-up&utm_blogctaid=1295)
---