ーー 本日はお時間をいただきありがとうございます。まずは簡単な自己紹介と、現在のお役割を教えてください。

Tyler Hannanと申します。ClickHouseでSenior Director of Developer Advocacyを務めています。約30年間データベースの世界に携わっており、Elasticではエンジニアリングからマーケティングまで幅広く経験し、Elasticsearchの上場にも関わりました。その中でも最もワクワクしているのがClickHouseです。日本のエンジニアの皆さんと直接お話しできる機会をいただけて光栄です。

なぜ今、ClickHouseなのか

ーー では、ClickHouseとはどのようなデータベースなのか、一言で教えてください。

ClickHouseは、OLAP（オンライン分析処理）のために設計されたオープンソースの分散型カラムナーデータベースです。GitHub上のコミット数は20万を超え、約2,000人のコントリビューターが参加している非常に活発なプロジェクトでもあります。

私たちのタグラインは「数十億行をミリ秒で」でした。今では「リアルタイム分析のための最速データベース」「オブザーバビリティのための最速データベース」など、ユースケースに応じた表現をしていますが、根底にある「billions of rows in milliseconds」という原則は変わっていません。

ーー なぜ今、世界中で「高速な分析データベース」がこれほど求められているのでしょうか。

クラウドデータウェアハウスという概念は、Snowflakeによって最も広く知られるようになりました。多くの企業がデータをウェアハウスに集約するようになると、そのデータの上に単なるレポートではなく、アプリケーションを構築したいというニーズが自然に生まれてきます。

内部向けのレポートであれば、クエリに数分かかっても許容できます。しかしユーザー向けのアプリケーションを構築する場合、ミリ秒単位のレスポンスが求められます。これが、ClickHouseが一貫して「速度」を重視してきた理由です。

"ミリ秒"を実現する4つの設計思想

ーー ClickHouseの速度は「カラムナーストレージだから」という説明をよく聞きますが、それだけではないですよね。エンジニアリングの観点から、もう少し詳しく教えてください。

おっしゃる通りです。カラムナーストレージは重要な要素ですが、ClickHouseの速度を支える仕組みは他にもいくつかあります。

1つ目は、列ごとのデータ保存です。ClickHouseは列を個別のファイルとして保存し、クエリに必要な列だけを読み込みます。分析クエリでは全列を使うことはまれですから、これだけでI/Oを大幅に削減できます。

2つ目は、ベクトル化実行です。値を1つずつ処理するのではなく、配列単位で演算を行います。CPUのSIMD命令を活用して、複数の値を同時に処理できます。実際、ClickHouseは30種類以上のハッシュテーブル実装を持っていて、クエリとデータの特性に応じて最適なものを自動選択します。

3つ目は、MergeTreeエンジンの設計です。データは「パーツ」と呼ばれる不変でソートされた単位で保存され、バックグラウンドでマージされます。これにより、インサートが軽量になり、高い並行性を実現できます。

4つ目は、疎なプライマリインデックスです。一般的なB-treeとは異なり、デフォルトでは8,192行ごとにインデックスエントリを持ちます。これにより、行数が非常に多いテーブルでもインデックスがメモリに収まりやすくなっています。

ーー 速度以外に、ClickHouseが重視している要素はありますか。

もう1つのコアとなる要素は圧縮です。ClickHouseは一般的に、元のデータサイズを10倍から30倍に圧縮できます。

クラウドデータベースでは、ストレージとコンピュートの2つにお金を払います。圧縮によってストレージコストが下がるのはもちろんですが、読み込むデータ量も減るので、クエリも速くなります。圧縮とクエリ時間は、どちらもコストに直結するわけです。

そしてもう1つ、私が強調したいのは使いやすさです。ClickHouseは標準的なSQLで操作でき、ノートPC上でも、サーバー上でも、クラウド上でも同じように動作します。Dockerイメージをいくつも起動する必要はなく、コマンドライン一発でセットアップが完了するのも大きな特徴です。

なぜ使いやすさを強調するかというと、エンジニアが新しい技術を検討するタイミングは、既存のシステムで何か問題が起きたときが多いからです。そういうときに、速度や圧縮率がいくら優れていても、導入や学習に時間がかかるようでは意味がありません。

ーー データ量が増大する中で、ストレージコストは切実な問題です。ClickHouseの高い圧縮率は、現実的にどの程度のコスト削減効果を生むのでしょうか。

公式ベンチマークの数字をお伝えすると、Snowflakeと比較して38%良い圧縮率、BigQueryと比較して60%良い圧縮率という結果が出ています。これは特定のベンチマークでの数字ですので、ワークロードによって変わります。

圧縮の仕組みとしては、ClickHouseはLZ4やZSTDなどの汎用コーデックに加えて、DeltaやGCDなど数値向けの専用エンコーディングを組み合わせられます。さらに、ORDER BYで指定したソートキーに従ってデータが並ぶため、同じ値が連続しやすくなり、圧縮効率が上がります。

実務的な効果としては、Redshiftからの移行事例でストレージサイズが半分になったケースがあります。

Snowflake・BigQueryとどう共存するか

ーー 多くの企業がすでにSnowflakeやBigQueryなどのクラウドDWHを利用しています。これらとClickHouseは競合するのでしょうか、それとも共存するのでしょうか。

私たちはClickHouseの速度とコスト効率に自信を持っており、オープンソースのベンチマーク「ClickBench」で透明性を保っています。

ただ、私がお伝えしたいのは「どれか1つを選ぶ」という話ではありません。多くのお客様は、既存のSnowflakeやBigQueryを置き換えるのではなく、その上にClickHouseを「スピードレイヤー」として追加しています。

バッチ処理やBIのワークロードはSnowflakeで継続しながら、ユーザー向けのリアルタイムダッシュボードや高並行性が求められる部分だけをClickHouseで処理する。こういった共存パターンが増えています。

ーー 具体的に、どのような「症状」が出たらClickHouseの導入を検討すべきでしょうか。

いくつかの兆候があります。

1つ目は、クエリレイテンシです。BigQueryやSnowflakeでは、キャッシュが効かない場合やクエリの複雑さによって、秒単位のレイテンシが発生するケースがあります。サブ秒のレスポンスが必要なユーザー向けアプリケーションでは、これが問題になります。

2つ目は、同時接続数です。Snowflakeはデフォルト設定で1ウェアハウスあたり8クエリを目安としており、マルチクラスター構成でスケールできますが追加コストがかかります。BigQueryも予約スロットに依存します。一方、ClickHouseはワークロード次第ですが、1ノードあたり1,000以上の同時クエリを処理できるよう設計されています。

3つ目は、コストの予測可能性です。BigQueryのスキャンデータ量に応じた課金やSnowflakeのウェアハウスサイズ管理で、コストが予測しにくいという声を多く聞きます。ClickHouse Cloudはコンピュート（時間とサイズ）＋ストレージ＋データ転送という構成で、クエリごとのスキャン課金ではないため、コスト予測がしやすい設計になっています。

ーー Redshiftを長く使っている企業も多いですが、移行や併用を検討すべきタイミングはありますか。

Redshiftは優れたデータウェアハウスですが、リアルタイム分析には2つの課題があります。

1つは、クエリのコンパイルオーバーヘッドです。Redshiftは各クエリの実行プランをコンパイルするため、特にアドホッククエリでは秒単位のオーバーヘッドが発生するケースがあります。クエリパターンが予測可能でキャッシュが効く場合は問題になりませんが、インタラクティブなアプリケーションでは体感レイテンシに影響する場面があります。

もう1つは、同時実行の制限です。RedshiftのWorkload Management（WLM）では、全キューで同時実行スロットの上限が設定されています。BIには十分ですが、高並行性のアプリケーションではキューイングやスロット待ちが発生しやすい構造です。

公式ベンチマークでは、同程度のリソースでClickHouseは平均2.5倍高速という結果が出ています。また、ストレージ効率も2倍程度優れているケースが多いです。

RDBで分析が限界に達したとき

ーー WebサービスではPostgreSQLやMySQLで分析まで行おうとして限界を迎えるケースがあります。「どういう症状が出たらRDB単体での運用に見切りをつけるべき」という明確なサインはありますか。

PostgreSQLは素晴らしいデータベースですが、分析には向いていません。OLTPとOLAPは根本的に異なるワークロードです。

具体的なサインとしては、まずクエリの実行時間が許容できなくなったときです。数百万行を超えるテーブルで集計クエリを実行すると、秒単位の時間がかかり始めます。

次に、分析クエリが本番のトランザクション処理に影響を与え始めたときです。重いレポートクエリがユーザー向けの処理を遅くするのは、よくある問題です。

ClickHouseでは、PostgreSQLやMySQLからCDC（Change Data Capture）でデータを流し込む仕組みを用意しています。ClickPipesという機能で、OLTPデータベースの変更をリアルタイムにClickHouseに反映できます。

推奨パターンは、PostgreSQLを「記録の正」として維持しながら、分析はClickHouseで行うという構成です。それぞれのデータベースを、得意な用途に使うということです。

ClickHouseが向かないケース

ーー 万能なツールは存在しません。「こういうユースケースにはClickHouseは向いていない」というアンチパターンを教えてください。

ClickHouseはOLAPデータベースです。OLTP、つまりトランザクション処理には向いていません。

具体的には、頻繁な行単位の更新が必要な場合です。ユーザー管理や金融トランザクションのような、1件ずつデータを更新するワークロードには、PostgreSQLのようなデータベースの方が適しています。

また、強いトランザクション整合性が求められる場合も同様です。ClickHouseは結果整合性を前提に設計されています。

ただし、ClickHouseには更新パターンに対応するための仕組みも用意されています。ReplacingMergeTreeやCollapsingMergeTreeといったテーブルエンジンを使えば、マージ時に古い行を削除したり、差分を集約したりできます。完全な置き換えではなく、設計パターンとして理解していただければと思います。

どんなツールにも得手不得手があります。だからこそ、自分のユースケースに合うかどうかを実際に試して確認することが大切です。ClickHouseは簡単に始められるので、まず手を動かしてみてください。

Cloud版とOSS版、どちらを選ぶか

ーー ClickHouseにはOSS版とCloud版がありますが、アーキテクチャ上の決定的な違いは何でしょうか。

オープンソース版は毎月リリースしていて、多くのベンダーとは異なり、オープンソースがCloudをリードする形になっています。そのため、Cloudは常に最も安定したバージョンを提供できます。

アーキテクチャの違いとしては、Cloud版ではコンピュートとストレージが分離されています。オブジェクトストレージ上のデータを、複数のコンピュートノードから独立してスケールできます。

また、Cloud固有の機能としては、ClickPipes（マネージドなデータ取り込みパイプライン）、SQL Console（UI）、自動スケーリングなどがあります。これらはマネージド環境を前提とした機能です。

ただし、これはOSS版の機能を制限しているわけではありません。セキュリティ機能を含むコア機能はすべてオープンソースに含まれています。Cloud版を契約しているかどうかに関係なく、すべての人が同じClickHouseユーザーだと考えています。

ーー エンジニアが「OSS版を自前運用するか」「Cloud版を契約するか」で迷ったとき、判断の基準は何でしょうか。

結局のところ、自分でデータベースを運用したいかどうかです。

ClickHouseオープンソースはクラスタ製品です。私たちはZooKeeperをC++で書き直してClickHouse Keeperを作りました。パフォーマンスを向上させるためです。データベースの運用に慣れている企業であれば、自前運用も選択肢になります。

一方、クラウドに移行中だったり、アプリケーション開発に集中したい企業には、私たちがデータベースを運用します。

エンジニアにとって嬉しいのは、ノートPC上のClickHouseも、Cloud上のClickHouseも、サーバー上のClickHouseも、操作方法は同じだということです。同じSQLが使え、同じインテグレーションが動き、同じツールが動作します。運用方法が違うだけで、開発体験は変わりません。

dbt・Grafana・Kafkaとの連携

ーー データ基盤の構築において、dbtのような変換ツールや、Grafana、Metabaseなどの可視化ツールとの連携は不可欠です。ClickHouseの高速性を損なわずに連携できる「推奨の技術スタック」はありますか。

ClickHouseは70種類以上のファイルフォーマットをサポートしていて、外部システムとの連携を重視しています。公式のIntegrationsページに、対応しているツールのカタログがあります。

データ変換については、dbtとの連携が公式にサポートされており、dbt-clickhouseアダプターを使えばdbtのモデル定義をそのままClickHouseに適用できます。実際、SnowflakeやBigQueryで書いたdbtプロジェクトを移行するケースも増えてきました。

可視化ツールとしては、Grafana、Metabase、Supersetなどが公式にサポートされており、特にGrafanaはオブザーバビリティのユースケースで多く使われています。専用のClickHouseプラグインも用意されているので、導入もスムーズです。

ストリーミングについては、Kafkaとの連携が強力で、Kafkaテーブルエンジンを使えばKafkaトピックを直接テーブルとしてクエリできます。Cloud版であればClickPipesを使うことで、マネージドな形でのデータ取り込みも可能です。

外部データソースへの直接クエリも特徴的です。PostgreSQL、MySQL、MongoDB、S3など、様々なデータソースに対してClickHouseから直接クエリを投げることができます。すべてのデータをClickHouseに取り込む必要はなく、必要に応じてフェデレーションできます。主要なインテグレーションはClickHouse社が公式にメンテナンスしており、詳細はIntegrationsページで確認できます。

AIエージェント時代のデータベース

ーー ClickHouseはベクトル検索もサポートしていますが、単なる数値分析の基盤から、AIアプリケーションのバックエンドへと進化しようとしているのでしょうか。

2025年に、ClickHouseは2つの企業を買収しました。

1つはHyperDXで、OpenTelemetryのデータ、ログ、メトリクス、トレースを扱うためのオブザーバビリティUIを提供しています。私たちはこれをClickStackと呼んでおり、オープンソースとCloud版の両方を展開しています。

もう1つはLibreChatです。LLMアプリケーションのためのユーザーインターフェースです。オープンソースのMCPサーバーと、お好みのLLMプロバイダーを組み合わせれば、エージェンティックなデータスタックが構築できます。

llm.clickhouse.comではパブリックデモを公開しており、GitHubのイベントデータに対して英語でも日本語でも質問できます。エージェントがデータベースとやり取りすることで、SQLを書けない人でもデータにアクセスできるようになるのです。

Anthropicが発表したMCP（Model Context Protocol）仕様に対して、私たちはすぐにClickHouse用のMCPサーバーをオープンソースで構築しました。2025年12月9日に、AnthropicがこのスペックをLinux Foundationに寄贈しました。AIとデータベースの統合が、今後さらに進むと考えています。

ある意味、AIエージェントは新しいデータベースユーザーになります。ただ、クエリを非常に速く書くユーザーです。だから速度が重要なのです。以前は「数十億行を数千人のユーザーへ」と言っていましたが、今は「数十億行を数百万のエージェントへ」かもしれません。これはデータベースにとって根本的な変化です。

日本市場への本格展開

ーー なぜ日本市場を重要視されているのでしょうか。また、日本のエンジニアや企業に向けて、今後どのようなローカライズや機能強化を予定していますか。

Japan Cloudとのパートナーシップにより、日本市場への本格的な展開を進めています。ClickHouse CloudはAWSとGoogle Cloudの東京リージョンで利用可能です。Azureの東京リージョンもEnterpriseプラン向けに提供されています。ウェブサイトとドキュメントの大部分は日本語にローカライズされており、日本のエンジニアコミュニティからの貢献も歓迎しています。

まず試してみてほしい

ーー 最後に、データ基盤の刷新や技術選定に悩んでいる日本のエンジニアに向けて、メッセージをお願いします。

エンジニアとして最も大切なのは、まず試してみることです。ClickHouseはノートPC上でも、クラウド上でも、同じように動きます。無料のクレジットで、自分のデータを入れて、自分のクエリを実行してみてください。

技術選定で重要なのは、どのデータベースが最速か、最安か、という比較ではありません。自分たちの課題を解決できるかどうかです。

私がこの仕事を30年近くやってきて確信しているのは、すべてに対応できる単一のツールはないということです。複数のツールを組み合わせて問題を解決する。それが今のエンジニアリングです。

ClickHouseが皆さんの課題解決に役立つかどうか、ぜひ試してみてください。そして、もし良いと思ったら、コミュニティに参加していただけたら嬉しいです。