「SQLをAIが書く」時代、ClickHouseが語る“なぜデータベースの高速性が求められる”のか：“最速”を掲げる分析DBはどう応える？

クエリ処理が極めて高速なデータベースとして開発され、リアルタイム分析やオブザーバビリティーなどで活用が進んでいるClickHouse。LLMによるクエリ生成が今後増えると予測される中でどのような変化があり、同データベースの特性はどう生きてくるのか。

[遠藤文康，＠IT]

　従来エンジニアが担ってきた業務の一部がLLM（大規模言語モデル）やAI（人工知能）エージェントによって置き換え可能になっていく中で、“AI以前の常識”とされてきた前提が見直されつつある。データベースの分野も例外ではない。AIが大量のクエリを生成したり、AI自らの挙動を記録・分析する必要性が生じたりすることを受け、データベースに求められる役割や性能要件にも変化が生じる。

　オブザーバビリティー（可観測性）のログやメトリクス（数値化された性能指標）を扱うデータ基盤や、リアルタイム分析、データウェアハウス（DWH）などに使われるデータベース管理システムに「ClickHouse」がある。2009年に「世界最速のOLAP（オンライン分析処理）データベース」を目指して開発が始まった、カラム型（列指向）のデータベース管理システムだ。2016年に「Apache 2」ライセンスの下でオープンソースプロジェクトがリリース。2022年にはマネージドサービスである「ClickHouse Cloud」が提供開始になっている。

　その活用例は生成AI分野でも広がっている。生成AIツール「Claude」の開発元であるAnthropicや、「ChatGPT」の開発元であるOpenAIが、オブザーバビリティーの基盤にClickHouseを採用していることが公表されている。Anthropicは採用の背景として、「Claude 3.5」のリリースとともに利用が急増し、監視やトラブルシューティング、チューニングのために処理すべきデータ量が膨大になると同時に、データアクセスを厳格に制限する必要性が高まってきたと説明している。

ClickHouseのタイラー・ハナン氏

　「ClickHouseのあらゆるユースケースにおいて、『AIをどう使うか』『AIをどう取り込むか』という観点が重要になり始めている」。ClickHouseで開発者支援を統括するタイラー・ハナン氏（Senior Director of Developer Advocacy）は、この1年ほどの変化をそう振り返る。ClickHouseは開発以来「クエリ処理の高速化」を重視してきた。その特性は、LLMやAIエージェントを活用したアプリケーションの本格普及を前に、新たな意味を帯び始めているという。

　AIエージェントが外部のツールやデータソースと連携するための仕組みとして、Anthropicは2024年11月に「MCP」（Model Context Protocol）というプロトコルを公開した。「AIツールとデータベースが相互にやりとりする方法において、“根本的な変化”をもたらすもの」だったとハナン氏は語る。ClickHouseはこのプロトコルの可能性を認識し、LLMが接続しやすくするためのMCPサーバをいち早く開発した。

　さらにAnthropicは2025年12月、MCPをLinux Foundationに寄贈することを発表した。特定企業の管理下にある仕様ではなく“真に業界標準”の位置付けとなることで、「MCPによる変化はさらに強いものになる」とハナン氏は強調する。

「AIエージェントは新たなユーザー」　なぜ“データベースの高速性”が必要？

　MCPのようなLLMやAIエージェントが外部データと連携するための仕組みが整備されてくることで、人間以外のユーザーによるアクセスや処理の増加がこれから加速すると考えられる。

　「AIエージェントはデータベースの新しいユーザーだ」とハナン氏は語る。従来は、人間が大量のデータを分析することを前提にデータベースが設計されてきた。しかし今後は、大量のデータに対して、多数のAIエージェントが自律的にクエリを発行し、その結果を基に次の処理や判断を連鎖的に行う──そうした利用形態が広がっていく可能性がある。

　こうした中で一段と求められるようになるのが、“極めて高速なデータベース”だという。「人間が数時間から数日をかけて実施していたレポート作成の作業が、AIエージェントがほとんど瞬間的に生成する数々のクエリに置き換わっていくとすれば、データベースはそのクエリの増大を支えられるようにスケールできなければならない」（ハナン氏）

自然言語で使えるユーザーインタフェース

　もう一つ重要な変化が、ユーザーインタフェース（UI）の在り方だ。ClickHouseは2025年11月に、オープンソースのAIチャットツール「LibreChat」の買収を発表しているが、これは「データベース言語『SQL』のスキルがない“より多くの人”が、分析データベースを利用可能になる」ことを意味する。こうしてLLMのアプリケーションに対して分析データベースを提供するためのUIやMCPサーバ、ClickHouseを、まとまった1つのオープンソースのソフトウェアスタック（同社は「Agentic Data Stack」と呼んでいる）として提供する。

　ClickHouseの社内では「Dwayne Data Warehouse AI Natural Language」（DWAINE）というプロジェクトとして、社内向けAIアシスタント（社内LLM）を運用している。従業員がデータに基づく質問をし、回答を得るのに役立っており、社内アナリティクスの約70％を処理しているという。

図1　ClickHouse社内のプロジェクト（DWAINE）でAIアシスタント（社内LLM）を運用（提供：ClickHouse）

がん研究機関における活用

　がん研究機関のMemorial Sloan Kettering Cancer Center（MSK）は、オープンソースのがんデータ解析プラットフォーム「cBioPortal」の性能改善のためにClickHouseを採用した。リレーショナルデータベース管理システム（RDBMS）「MySQL」を前提とした従来アーキテクチャでは、数十万規模の患者データや膨大なゲノムデータのフィルタリング・分析に時間がかかり、研究スピードの阻害要因となっていた。複雑なフィルタリング処理をSQLに書き換えるとともに、計算処理をアプリケーション層ではなくClickHouse内に集約するなどして、クエリ性能を10倍向上させた（図2）。がん研究者が大量データを高速に探索し、仮説検証を迅速に行える環境も整いつつあるという。

図2　クエリ性能を10倍向上させた（提供：ClickHouse）

ClickHouseはなぜ高速なのか

　「ClickHouseは開発当初からスピードの優位性を持っており、それを長年にわたって維持してきた」とハナン氏は語る。『“数十億行をミリ秒でクエリする”というスローガンがClickHouseの原点であり、それを忘れることはない」。ClickHouseや他のデータベース管理システムの動作を比較できるベンチマーク（性能比較）は、こちらのサイトで公開されており、「ClickHouseは常に上位にある」（同氏）という。

図3　ClickBenchでの性能比較（提供：ClickHouse）

　なぜClickHouseは高速なのか。その理由として、ハナン氏は幾つかのポイントを挙げる。まずはデータの圧縮。おおよそ10倍から30倍の圧縮が見込める。「同じ処理を実行するとしても、読み込むデータが圧縮されていればそれだけ速くなる」

　カラム型（列指向）である点では、データは列として保存され、列として取得されるため、クエリに必要なデータだけを処理することになるのでこれも速さにつながる特徴になる。CPUアーキテクチャに最適化し、データを大きなバッチ単位で処理するベクトル化クエリ実行（Vectorized Query Execution）という手法も使っている。

求められるオブザーバビリティー

　より低レイテンシやリアルタイム性が求められる用途で、ClickHouseが採用されるケースが広がっているという。「『Snowflake』と併用しつつ、よりスピードが求められる場合に“もう一つのレイヤー”としてClickHouseを使うパターンはよく見られる」（同氏）。ただし「Snowflakeから移行しなければならないとか、『PostgreSQL』から移行しなければならないということではない」とハナン氏は強調する。「スピードやレイテンシ、あるいはストレージにおけるデータ圧縮が重要な場面で、ClickHouseが優れた選択肢になる」

　ClickHouseのようなデータベースへのニーズが高まってきた背景にある一つの要因が、オブザーバビリティーの必要性だ。オブザーバビリティーとは、ログやメトリクス、トレース（処理経路の追跡情報）を通じてシステム内部の状態を可視化、分析する取り組みを指す。

　同社が2025年にHyperDXを買収したことも、オブザーバビリティー分野の強化に関わるものだった。HyperDXは、ClickHouseの上でログ、メトリクス、トレースを全て1カ所に集約するための“オブザーバビリティーのUI”となる。

AIをツールとして使うための運用基盤

　「AIエージェントはSRE（サイト信頼性エンジニアリング：運用にソフトウェアエンジニアリング手法を取り入れてシステムの信頼性を高める手法）ができるのか」「AIはSREエンジニアになれるのか」は“この1年で出てきた問い”の一つで、これに対しては「場合によってはYes、場合によってはNo」だとハナン氏は言う。例えばコンテナオーケストレーションツール「Kubernetes」で大規模にシステムが展開されている場合、AIは関連するログ行を返してくれる点では非常に有用だが、システムの複雑さを理解するのは依然として得意ではない。AIは現段階ではオブザーバビリティーの基盤そのものを運用する存在というよりも、エンジニアを支援するツールという位置付けが現実的だということだ。

　ハナン氏は「AIツールを運用するのであれば、ユーザーがどのようにそれを使っているのかを把握する必要がある」とも指摘する。AIに一定の役割を担わせるようになるほど、それをツールとして安定的に使っていくための運用基盤には何が必要なのかを考えなければならない。