Managed Postgres 向け ClickHouse Agents の提供を開始

TL;DR: #

ClickHouse による Managed Postgres で ClickHouse Agents が利用可能になりました。自然言語で Postgres データを探索し、Postgres と ClickHouse を横断してクエリを実行できるほか、データベースの監視、チューニング、移行支援まで行うエージェントを構築できます。デフォルトですべて読み取り専用となっており、設計段階からセキュリティが確保されています。

2026年6月の OpenHouse でベータ版として発表された ClickHouse Agents は、Claude を搭載した ClickHouse Cloud のフルマネージド型エージェントサービスです。ライブデータに基づいたエージェントをノーコードで構築でき、SQL を書いたりツールを連携したりすることなく、自然言語で質問できます。セルフサービスでのデータ探索からクエリパフォーマンスの分析まで幅広く活用されており、質問からわずか数秒で回答を得られます。

内部では、エージェントビルダーとチャットインターフェースを、サンドボックス化されたコードインタープリターと組み合わせています。オープンなスタック上に構築されており、MCP 互換システムならどれでも接続できるほか、ClickHouse Cloud をデータ基盤としながら、ベンダーロックインなしで独自のエージェント、モデル、ツールを持ち込めます。ベースとなっているのは、戦略的買収によって ClickHouse に加わり、Coinbase や Shopify といった企業で大規模に信頼されているオープンソース AI チャットプラットフォームの LibreChat です。

今回のリリースにより、このエージェント体験が ClickHouse Cloud 内のすべての Managed Postgres サービスへと拡張されます。開発者はエージェント型インターフェースを介して Postgres と ClickHouse をまとめてクエリできるようになり、OLTP と OLAP の統合データスタックを提供するという私たちのビジョンがさらに前進します。

デモ #

このデモでは、ClickHouse Agents が Managed Postgres インスタンスに直接連携する様子を示しています。エージェントは run_postgres_select_query ツールを活用してスキーマを解析し、利用可能なデータベースとテーブルを特定します。サービスの健全性を評価するために、私たちは get_postgres_metrics と list_postgres_slow_query_patterns を利用して、リアルタイムのパフォーマンスデータを表面化させ、ボトルネックを自動的に特定します。

ユースケース #

自然言語で Postgres をクエリする #

エージェントの接続先を Managed Postgres サービスに設定すれば、自然な言葉で運用データを探索できます。「プラン別のアクティブなサブスクリプション数と、過去 30 日間に解約されたサブスクリプションを教えて」と尋ねると、エージェントがスキーマを確認し、クエリを実行して、使用した SQL とともに回答を返します。デフォルトで読み取り専用アクセスとなっているため、チーム内の誰もがデータを変更するリスクなく安全に探索できます。

ClickHouse Agents ではすでに ClickHouse Cloud 内のデータを基盤としたカスタムエージェントを構築できますが、今回 Postgres にも対応しました。必要なコンテキスト (スキーマ、社内ルール、チームから頻繁に出る質問など) をエージェントに与えることで、運用データに特化した専任担当者になります。Postgres のサポートにより、トランザクションデータを構築したカスタムエージェントへ直接取り込めるようになりました。

Postgres (OLTP) と ClickHouse (OLAP) を横断してクエリする #

エージェントを Postgres サービスと ClickHouse サービスの両方に接続すると、両者を横断して推論できるようになります。OLTP と OLAP というそれぞれのエンジンに個別にクエリを実行し、その結果をマージするため、最新の運用データをアナリティクスに取り込めます。

「Postgres から直近 1 週間のサインアップを取得し、ClickHouse のイベント数と照合して、どのプランのアクティベーションが最も早かったかを表示して。」

この 1 つのリクエストの裏側で、エージェントは Postgres に対してサインアップを取得するクエリを実行し、ClickHouse に対してユーザーごとのイベント数を取得するクエリを実行し、ユーザー単位で 2 つの結果を突き合わせ、プランをランク付けして提示します。

アナリティクス用途で Postgres から ClickHouse へ移行する #

私たちがよく目にするパターンとして、Postgres のデータ量が増加するにつれて分析クエリが遅くなり、そのワークロードを ClickHouse へ移管したいと考えるチームの存在があります。移行エージェントを利用すれば、手順を整理し、実際にデータがどのようにクエリされているかに基づいて ClickHouse に適したデータモデルを提案しながら、移行プロセスを案内してくれます。

私たちはこれを、エージェントが一連のワークフローを実行できるスキルとしてまとめました。これには、検出、アクセスパターンの分析、ClickHouse スキーマ設計 (エンジン、ORDER BY、パーティショニング、マテリアライズドビュー)、Postgres から ClickHouse への型マッピング、ClickPipes / PeerDB による CDC 取り込み、そして検証が含まれます。詳細は Postgres to ClickHouse migration skill の全文をご覧ください。

これは、ClickHouse のデータモデリングガイドである「Postgres to ClickHouse data modeling tips (v2)」およびオリジナルの Tips に基づいています。

データベースの監視 #

Query Insights(ローンチブログ)とネイティブのサービスメトリクスをもとにエージェントを構築し、データベースを監視できます。この 1 週間の傾向や、現在最も負荷の高いクエリを尋ねるだけで、ダッシュボードを作成することなく明確な要約が得られます。

エージェントは全体像を把握した上で動作します。指定した任意の期間におけるバケット化された時系列データとして利用可能なネイティブメトリクスには、以下が含まれます。

• CPU 使用率とメモリ使用率
• ディスク使用量とディスク I/O(IOPS)
• ネットワークトラフィック
• 接続数
• キャッシュヒット率
• 操作のスループット(fetch、insert、update、delete)
• デッドロック
• データベースサイズ
• コミットされたトランザクションとロールバックされたトランザクションの比較

また、Query Insights からは、遅いクエリパターン(データベース、ユーザー、操作、アプリケーションごとにグループ化)ごとに以下の情報が得られます。

• 呼び出し回数とエラー数
• 合計、平均、最大、および p50 / p95 / p99 の所要時間
• 返された行数
• 共有バッファキャッシュのヒット数と読み取り数
• CPU 時間
• WAL バイト数

遅いクエリの特定と解決 #

サービスが遅い理由をエージェントに質問できます。Query Insights が最も負荷の高いクエリを浮き彫りにし、EXPLAIN が最も問題のあるクエリのプランを明らかにします。サービスメトリクスはサーバーに負荷がかかっているかどうかを示します。たとえば、大きなテーブルに対するシーケンシャルスキャンはインデックスの不足を示唆しています。インデックスを追加することで、クエリを大幅に高速化できます。

私たちは、エージェントがこの一連のループを自律的に実行できるようにスキルを開発しました。Postgres performance-tuning スキル)は、遅いパターンを特定し、EXPLAIN を実行し、メトリクスを確認して、優先順位付けされた改善策を提示します。

次のステップ #

私たちの取り組みはまだ始まったばかりです。ClickHouse Agents を拡張していく今後の方向性をいくつかご紹介します。

• 適切なスキルに基づいて構築された、公式のパフォーマンス推奨エンジン。 現在エージェントをガイドしている厳選されたスキルは、ファーストクラスの推奨エンジンへと発展します。また、質問されたときだけに実行されるわけではありません。指定した間隔で自律的に実行されるようにスケジュール設定できるため、最適なしきい値に基づいてユーザー自ら調べにいかなくても、遅いクエリ、スキーマ、キャパシティに関するインサイトが自動的に届きます。データベースのパフォーマンスが低下し始めた際には、アプリケーションに影響が及ぶ前に通知することを目指しています。
• 自己修復型のパフォーマンスチューニングエージェント。 次の飛躍は、アドバイスからアクションへの移行です。推奨エンジンと安全な自動修復を組み合わせることで、エージェントは自律的に修正を適用し、autovacuum 設定やその他の Postgres 構成などをチューニングして、問題がユーザーの手元に届く前に検知して解決できるようになります。