「このレポート、10億行あるんだけど集計が30秒かかる」——そんな相談を受けたとき、ClickHouseは有力な選択肢になる。
ClickHouse は、大量データのリアルタイム分析に特化したオープンソースのカラムナ型OLAPデータベースだ。GitHub Stars 47,000超（2026年4月時点）、Apache 2.0ライセンスで公開されており、Cloudflare・Uber・Spotifyといった大企業からrybbitのようなOSSプロジェクトまで幅広く採用されている。
この記事ではClickHouseのアーキテクチャと実用的な使い方を解説します。データパイプラインや自動化ツール全般は AI自動化ツール完全ガイド2026｜ノーコードからコードまで徹底比較 をご覧ください。
ClickHouseとは——OLTP全盛の時代に誕生したOLAP専用DB
ClickHouseは2009年、ロシアの検索大手 Yandex がウェブアナリティクスプラットフォーム「Yandex.Metrica」のために開発を始めたデータベースだ。2016年にオープンソース化され、現在は ClickHouse Inc. が中心となって開発を続けている。
「OLAP」（Online Analytical Processing）とは、大量のデータをリアルタイムに集計・分析する処理のことを指す。ECサイトの売上集計、サーバーログの傾向分析、ウェブ訪問数の推移追跡——これらはすべてOLAPの範疇だ。一方、注文の作成・更新・削除といった個別レコードの書き込みを高頻度で行う処理を「OLTP」（Online Transaction Processing）と呼ぶ。
PostgreSQL・MySQLはOLTPとOLAPの両方を扱えるよう設計されているが、ClickHouseは最初からOLAPのみに特化した。この「特化」が、集計クエリ速度の圧倒的な差につながっている。
「Click」はYandex.Metricaの前身サービス「Click Stream Analysis」から、「House」はデータハウス（データウェアハウス）に由来するとされる。公式ロゴはクリックハウス（カッコウが巣を奪う行動）の家をモチーフにしている。
主要な数値として記録すると：
- ⭐ 47,000+ GitHub Stars（2026年4月時点）
- 🍴 8,600+ forks
- 💬 最新安定版：v26.3（2026年4月）
- 📜 ライセンス：Apache 2.0
- 🏢 使用企業：Cloudflare、Uber、Spotify、Bloomberg、eBay など1,000社以上
なぜClickHouseは速いのか——3つの技術的理由
1. カラムナ（列指向）ストレージ
従来のRDBMS（PostgreSQL、MySQLなど）は行指向（Row-oriented）でデータを保存する。usersテーブルに100カラムがあれば、1行分のデータ（100カラム）を物理的に連続して格納する。
ClickHouseは逆に列指向（Columnar）でデータを保存する。「金額」カラムのデータは金額同士で、「日付」カラムのデータは日付同士で格納される。
-- 行指向（PostgreSQL など）の物理的なデータ配置
[行1: user_id=1, date=2026-01-01, amount=500, ...]
[行2: user_id=2, date=2026-01-01, amount=1200, ...]
...
-- 列指向（ClickHouse）の物理的なデータ配置
[amount列: 500, 1200, 800, 300, ...]
[date列: 2026-01-01, 2026-01-01, 2026-01-02, ...]
[user_id列: 1, 2, 3, 4, ...]
SELECT SUM(amount) FROM orders WHERE date = '2026-01-01' というクエリを実行するとき、行指向では全カラムをスキャンしてamountとdateだけ取り出す必要がある。列指向ではamountとdateの2カラム分だけを読めばよい。1億行・100カラムのテーブルなら、読み込むデータ量が理論上98%削減できる。
2. ベクトル化実行エンジン
ClickHouseは、現代CPUのSIMD（Single Instruction, Multiple Data）命令を活用したベクトル化実行エンジンを持つ。
通常のクエリ実行では1行ずつ処理するが、ClickHouseはCPUキャッシュに収まるサイズ（典型的に8,192行）のデータブロック単位で処理する。1つのCPU命令で複数の数値を同時に計算できるため、1億行の集計でも実質的に数千万命令で処理が完結する。
SELECT SUM(amount)"] --> B["パーサー
SQL解析"] B --> C["プランナー
実行計画生成"] C --> D["カラムストレージ
amount列のみ読込"] D --> E["ベクトル化エンジン
8192行ブロック単位
SIMD演算"] E --> F["並列集計
マルチスレッド"] F --> G["結果返却
sub-second"]
3. データ圧縮
列指向の副産物として、データ圧縮率が劇的に向上する。同じ型・同じ種類のデータが連続して並ぶため、LZ4やZSTDといった汎用圧縮アルゴリズムの効率が最大限に発揮される。
実測では：
- PostgreSQLで100GBのデータが、ClickHouseでは9〜20GBになる（5〜10倍の圧縮）
- 圧縮によってディスクI/Oも削減され、クエリ速度もさらに向上する
日時カラムやIPアドレスカラムでは専用のDelta符号化も適用可能で、さらに高い圧縮率を達成できる。
PostgreSQL・MySQL・BigQueryとの比較
ClickHouseの「使いどころ」を理解するには、競合との比較が最も効果的だ。
| 項目 | ClickHouse | PostgreSQL | MySQL | BigQuery |
|---|---|---|---|---|
| 主な用途 | OLAP（分析） | OLTP + OLAP | OLTP + OLAP | OLAP（サーバーレス） |
| ストレージ | カラムナ | 行指向 | 行指向 | カラムナ |
| 集計クエリ速度 | ◎ 最速 | △ 遅い（大規模時） | △ 遅い（大規模時） | ○ 速い（レイテンシ高め） |
| OLTP（行のUPDATE/DELETE） | △ 非推奨 | ◎ 最適 | ◎ 最適 | △ 非対応 |
| セルフホスト | ✅ Docker | ✅ | ✅ | ❌（GCP専用） |
| コスト（大規模） | 安い（ハードウェア固定費） | 高い（ディスク大） | 高い（ディスク大） | 従量課金（高コスト） |
| SQLサポート | MySQL互換SQL + 拡張 | 標準SQL | 標準SQL | 標準SQL |
| JOINの得意さ | △ 小〜中テーブル | ◎ | ◎ | ◎ |
| レプリケーション | ○ ZooKeeper/ClickHouse Keeper | ○ | ○ | ◎ マネージド |
| 管理の容易さ | △ チューニング必要 | ○ | ○ | ◎ マネージド |
高頻度な行レベルのUPDATE/DELETEは設計上避けるべきだ。たとえばユーザーのプロフィール更新・注文ステータスの変更・セッション管理など、個別レコードを逐次書き換えるワークロードは PostgreSQL/MySQL に任せる設計が一般的。ClickHouseとPostgreSQLを組み合わせた「ハイブリッドアーキテクチャ」が実用的な選択になる。
BigQueryとのコスト比較が重要なポイントだ。BigQueryはクエリ課金（1TBスキャンあたり$5〜$6）のため、月に数百TBをスキャンする運用では請求が予測不能になる。ClickHouseはセルフホストであればVPS固定費のみで、コスト上限が明確だ。
主なユースケース
ログ・イベント分析
サーバーログ、アプリケーションエラーログ、アクセスログの分析はClickHouseが最も得意とする領域だ。Cloudflareは1日10兆件のDNSリクエストログをClickHouseで処理している。
時系列データとの相性も抜群で、MergeTreeテーブルエンジンが日付・時刻カラムでの効率的なソートと範囲絞り込みを最適化する。
リアルタイムBI・ダッシュボード
数十億行のデータをリアルタイムに集計してダッシュボードに表示するユースケースでは、ClickHouseの sub-second クエリが直接UX改善につながる。GrafanaやMetabaseとの統合も充実している。
ウェブ・プロダクト解析
rybbit（Cookie不要のOSSウェブ解析）、PostHog（プロダクトアナリティクス）、HyperDX（2025年3月にClickHouseが買収したオブザーバビリティプラットフォーム）など、解析系OSSプロダクトがClickHouseをバックエンドに選ぶケースが増えている。これらのプロダクトがClickHouseを選ぶ理由は後述する。
セキュリティ・不正検知
大量のネットワークパケット・認証ログ・APIアクセスログを横断集計して異常を検知するSIEM（Security Information and Event Management）用途でも使われる。カラムナストレージは「特定のIPアドレスからのリクエスト数推移」「エラーコード別の時系列集計」といった典型的なセキュリティクエリと相性がよい。
Dockerで始めるClickHouse
基本的な起動
docker run -d \
-p 8123:8123 \
-p 9000:9000 \
--name clickhouse \
clickhouse/clickhouse-server:latest
起動後、HTTP API（ポート8123）でクエリを実行できる：
# バージョン確認
curl 'http://localhost:8123/?query=SELECT+version()'
# テーブル作成
curl 'http://localhost:8123/' \
--data-binary "CREATE TABLE events (
event_time DateTime,
user_id UInt32,
page String,
duration UInt16
) ENGINE = MergeTree()
ORDER BY (event_time, user_id)"
# データ挿入
curl 'http://localhost:8123/' \
--data-binary "INSERT INTO events VALUES
(now(), 1, '/top', 320),
(now(), 2, '/product/123', 1450),
(now(), 1, '/cart', 220)"
データ永続化付きDocker Compose
本番に近い環境ではデータの永続化が必要だ：
# docker-compose.yml
version: "3.8"
services:
clickhouse:
image: clickhouse/clickhouse-server:26.3
ports:
- "8123:8123" # HTTP API
- "9000:9000" # ネイティブクライアント
volumes:
- clickhouse_data:/var/lib/clickhouse
- ./clickhouse-config.xml:/etc/clickhouse-server/config.d/custom.xml
ulimits:
nofile:
soft: 262144
hard: 262144
volumes:
clickhouse_data:
起動後、clickhouse-client（CLIクライアント）でインタラクティブに操作できる：
docker exec -it clickhouse clickhouse-client
なぜOSSプロダクトがClickHouseを選ぶのか
rybbit は TypeScript で構築されたウェブ解析プラットフォームだ。アーキテクチャの中核として ClickHouseと PostgreSQL を役割分担させている。
（script.js）"] --> B["バックエンドAPI
Node.js + TypeScript"] B --> C["ClickHouse
ページビュー・イベント
高速集計DB"] B --> D["PostgreSQL
ユーザー・サイト設定
OLTP DB"] C --> E["ダッシュボード
リアルタイム表示"] D --> E
rybbitがClickHouseを採用した理由は明確だ：
- 月次数百万PVの集計が sub-second で返る — ClickHouseのMergeTreeエンジンが時系列データを最適化するため、「先週のPV推移」「ファネル別コンバージョン率」といった典型クエリが100ms以下で完了する
- スケールフリー — 月1万PVでも月10億PVでも、ClickHouseの応答速度はほぼ線形に保たれる
- Docker同梱で運用シンプル — rybbitのDocker Composeには
clickhouse/clickhouse-server:25.4.2イメージが含まれており、セルフホスト時も追加インフラ不要
PostHog も同じ設計思想でClickHouseを採用しており、「PostgreSQLからClickHouseに移行したことでクエリ速度が100倍になった」と公式ブログで述べている。
MergeTreeエンジンと主要エンジン一覧
ClickHouseのテーブルエンジンは用途によって使い分ける。
| エンジン | 特徴 | 典型的な用途 |
|---|---|---|
| MergeTree | 基本エンジン。主キーによるソートと高速範囲検索 | ログ、イベントテーブル |
| ReplacingMergeTree | 同一主キーの最新行のみ残す（重複排除） | ユーザーステータス管理 |
| SummingMergeTree | 数値カラムの集計を自動的にマージ | カウンター、累積集計 |
| AggregatingMergeTree | 集計状態を事前計算して保持 | マテリアライズドビュー |
| ReplicatedMergeTree | ZooKeeperでレプリケーション管理 | 高可用性クラスター |
| Distributed | 複数ノードへのシャーディング | 水平スケールアウト |
MergeTreeの ORDER BY 句が実質的な主インデックスになる。ClickHouseはスパース（疎）インデックスを採用しており、デフォルトで8192行ごとに1つのインデックスエントリを保持する。これにより、インデックス自体のメモリ消費を抑えつつ高速な範囲検索を実現している。
ClickHouseの制限と注意点
ClickHouseを採用する前に理解しておくべき制約がある。
トランザクション処理には使わない
公式ドキュメントも明言しているが、ClickHouseはACID トランザクション（特にコミット・ロールバックの繰り返し）を想定していない。決済処理・在庫管理・予約システムなどはPostgreSQL/MySQLが適切だ。
行レベルのUPDATE/DELETEは高コスト
ClickHouseのUPDATEとDELETEは「Mutation」と呼ばれる非同期バッチ処理として実装されており、即時反映されない。「購入済みフラグを1行だけUPDATEする」用途には適さない。GDPRの「忘れられる権利」への対応など、定期的な削除が必要な場合は設計上の考慮が必要だ。
JOINは小さいテーブルとの組み合わせが前提
ClickHouseのJOINは「大テーブル × 小テーブル」の構造で最適化されている。大テーブル同士のJOINはメモリを大量消費し、パフォーマンスが劣化する。ClickHouseの設計思想は「JOINより非正規化（denormalization）」で、ログテーブルに必要なカラムをあらかじめ埋め込む方が高速になることが多い。
クラスター構成は複雑
分散クラスター（シャーディング・レプリケーション）のセットアップには ZooKeeper または ClickHouse Keeper の管理が必要になる。シングルノードであれば管理は容易だが、HA構成では運用コストが上がる。マネージドサービスとして ClickHouse Cloud を使えば、この複雑さを回避できる。
ClickHouseとBIツールの統合
ClickHouseは主要なBIツール・可視化ツールとの統合が充実している。
Grafana連携
Grafanaには公式のClickHouseデータソースプラグイン（grafana-clickhouse-datasource）が提供されている。インストール後、ホスト・ポート・認証情報を設定するだけでGrafanaダッシュボードからClickHouseにクエリを投げられる。
# Grafana Docker Compose 例
grafana:
image: grafana/grafana:latest
environment:
- GF_INSTALL_PLUGINS=grafana-clickhouse-datasource
ports:
- "3000:3000"
時系列グラフでのアクセスログ可視化、ヒートマップでのエラー分布表示、ゲージでのリアルタイムKPI監視など、Grafanaの豊富なパネルがそのままClickHouseのデータに使える。
Metabase連携
Metabaseも公式のClickHouseドライバーを提供している。ノーコードでグラフを作れるため、SQLに不慣れなビジネスユーザーがClickHouseのデータを直接確認するユースケースに適している。
Apache Superset連携
PyPIパッケージ clickhouse-connect を使って Apache Superset からClickHouseに接続できる。SQLAlchemyベースのため、Supersetの各種ビジュアライゼーションがそのまま使える。
パフォーマンスチューニングの基本
ClickHouseを最大限に活かすための基本的なチューニングポイントを整理する。
ORDER BY の設計
MergeTreeエンジンの ORDER BY（ソートキー）がクエリ速度を大きく左右する。最も頻繁にWHERE句で使うカラムを先頭に置く設計が重要だ。
-- 悪い例：ランダムなuser_idを先頭に
CREATE TABLE events (
user_id UInt32,
event_time DateTime,
page String
) ENGINE = MergeTree()
ORDER BY user_id;
-- 良い例：時系列での絞り込みが多いなら日時を先頭に
CREATE TABLE events (
event_time DateTime,
user_id UInt32,
page String
) ENGINE = MergeTree()
ORDER BY (event_time, user_id);
マテリアライズドビュー
集計処理をリアルタイムに事前計算する「マテリアライズドビュー」はClickHouseの強力な機能だ。書き込み時に自動的に集計値を更新するため、ダッシュボードのクエリコストをほぼゼロにできる。
-- 毎分のPV数を事前集計するマテリアライズドビュー
CREATE MATERIALIZED VIEW pv_per_minute
ENGINE = SummingMergeTree()
ORDER BY (minute, page)
AS
SELECT
toStartOfMinute(event_time) AS minute,
page,
count() AS pv
FROM events
GROUP BY minute, page;
挿入のたびに pv_per_minute が更新されるため、「過去1時間の1分ごとのPV推移」というクエリが SELECT * FROM pv_per_minute WHERE minute >= now() - INTERVAL 1 HOUR で瞬時に返る。
データ型の選択
ClickHouseは整数型のビット幅を細かく選べる（UInt8、UInt16、UInt32、UInt64）。HTTPステータスコード（200〜599）なら UInt16、ページビューカウンターなら UInt32 のように適切な型を選ぶことでストレージと処理速度を最適化できる。
| 型 | 範囲 | 適した用途 |
|---|---|---|
| UInt8 | 0〜255 | フラグ、ステータスコード |
| UInt16 | 0〜65535 | ポート番号、HTTPステータス |
| UInt32 | 0〜42億 | ユーザーID、カウンター |
| UInt64 | 0〜1.8×10¹⁹ | 大規模カウンター |
| DateTime | Unix時刻 | イベント時刻 |
| LowCardinality(String) | 低カーディナリティ文字列 | OS名、国名、ブラウザ名 |
LowCardinality(String) は国名・OS名・ブラウザ名のように取りうる値が数百種類以下のカラムに使う。内部的に辞書エンコーディングが適用され、ストレージが20〜50%削減される。rybbitでも LowCardinality はブラウザ・OS・国カラムに採用されている。
ClickHouseの選択フロー
どのような状況でClickHouseを選ぶべきか、判断フローを整理する。
または DuckDB で十分"] C -->|No| E["セルフホストが必要か？"] E -->|No| F["BigQuery / Snowflake
マネージドを選択"] E -->|Yes| G["クラスター構成が必要か？"] G -->|No| H["ClickHouse シングルノード
Docker で始める"] G -->|Yes| I["ClickHouse Cluster
または ClickHouse Cloud"]
「月間データ量が少ない」「チームにDB管理の工数がない」「GCPエコシステムを使っている」場合はBigQueryやDuckDBが現実的な選択肢になる。ClickHouseの真価は数十億行以上のデータをセルフホストで低コストかつリアルタイムに扱う場面で発揮される。
ClickHouse Cloudとマネージドオプション
セルフホストの複雑さを避けたい場合、ClickHouse Cloud という公式マネージドサービスがある。
| プラン | 用途 | 特徴 |
|---|---|---|
| Development | 開発・検証 | $0から開始、自動サスペンド |
| Production | 本番環境 | 自動スケール、SLA 99.9% |
| Dedicated | 大規模本番 | 専用インフラ、カスタムSLA |
AWS・GCP・Azureの3クラウドに対応しており、東京リージョン（ap-northeast-1）でも利用できる。
2025年3月にはオブザーバビリティプラットフォームの HyperDX を買収し、「ClickStack」としてClickHouseネイティブなログ・メトリクス・トレース統合ソリューションを提供し始めた。OSSのHyperDX上にClickHouseをバックエンドとして組み合わせた形で、Elasticsearchスタックの代替として注目されている。
よくある質問（FAQ）
Q. ClickHouseは日本語コンテンツに対応していますか？
日本語のフルテキスト検索は限定的です。LIKE '%検索語%' は使えますが、形態素解析ベースの日本語全文検索（PostgreSQLのpg_bigm相当）はネイティブサポートがありません。日本語テキストの全文検索が主要ユースケースであればElasticsearch/OpenSearchを検討してください。
Q. データのインポート方法は？
CSVのバルクインポートが最もシンプルです。INSERT INTO table FORMAT CSV または clickhouse-client --query "INSERT INTO table FORMAT CSV" < data.csv。KafkaからのストリームインジェストはKafkaTableエンジンで対応できます。
Q. PostgreSQLと同時に使うには？
rybbitのようにDocker Compose上でClickHouseとPostgreSQLを並列起動し、アプリケーション側でクエリを振り分けるのが標準的です。PostgreSQL FDW（外部データラッパー）でClickHouseに接続することも可能ですが、ClickHouse側からPostgreSQLのデータを参照する PostgreSQL テーブルエンジンも提供されています。詳しくはrybbitのアーキテクチャ解説を参考に、rybbit：OSSウェブ解析プラットフォームのClickHouse活用をご覧ください。
Q. Elasticsearch/OpenSearchと比べてどうですか？
ClickHouseはログの分析集計が約2〜6倍高速で、ストレージ効率も優れます。ただし全文検索（LIKE以外のテキスト検索）はElasticsearchが得意です。ClickHouseは「ログの傾向分析・可視化」に、Elasticsearchは「ログの全文検索・絞り込み」に使い分けるのが現実的です。
Q. バックアップはどうすればよいですか？
clickhouse-backup OSSツールが広く使われています。スナップショットベースのバックアップをS3/GCS/Azure Blobに転送できます。ClickHouse CloudはマネージドバックアップをGUIから管理できます。
