メインコンテンツへスキップ
clickhousectl は、ローカル環境と Cloud の両方で ClickHouse を扱うための CLI です。 clickhousectl では、次のことができます。
  • ローカルの ClickHouse バージョンをインストールして管理する
  • ローカルの ClickHouse server を起動して管理する
  • ローカルの Postgres インスタンスを起動して管理する
  • ClickHouse server に対してクエリを実行する
  • ClickHouse Cloud をセットアップし、Cloud 管理の ClickHouse クラスターを作成する
  • ClickHouse Cloud の Postgres サービスを作成して管理する
  • ClickHouse Cloud のリソースを管理する
  • データ インジェスト用の ClickPipes を作成して管理する (S3、Kafka、Kinesis、Postgres、MySQL、MongoDB、BigQuery)
  • 対応しているコーディングエージェントに、公式の ClickHouse agent スキルをインストールする
  • ローカルの ClickHouse 開発環境を Cloud にプッシュする
clickhousectl は、人間と AI エージェントの両方による ClickHouse を使った開発を支援します。

インストール

クイックインストール

インストールスクリプトは、お使いのOSに対応した適切なバージョンをダウンロードし、~/.local/bin/clickhousectl にインストールします。利便性のため、chctl のaliasも自動的に自動的に作成されます。

要件

  • macOS (aarch64, x86_64) または Linux (aarch64, x86_64)
  • Cloud コマンドの実行には、ClickHouse Cloud APIキー が必要です

ローカル

ClickHouse バージョンのインストールと管理

clickhousectlbuilds.clickhouse.com から ClickHouse のバイナリをダウンロードし、そこにビルドがない場合は packages.clickhouse.com (Linux) または GitHub releases (macOS) から取得します。
local use は、選択したバージョンのバイナリを指す ~/.local/bin/clickhouse のシンボリックリンクも作成するため、通常の clickhouse コマンド (例: clickhouse localclickhouse client) を PATH 経由で使えるようになります。スキップするには --no-global を指定します。そのパスに通常のファイルがすでに存在する場合は、警告を表示してそのまま残します。アクティブなデフォルトバージョンに対して local remove を実行すると、このシンボリックリンクも削除されます。

ClickHouseバイナリの保存先

ClickHouseのバイナリはグローバルなリポジトリに保存されるため、ストレージを重複させることなく複数のプロジェクトで共有できます。バイナリは ~/.clickhouse/ に保存されます。

プロジェクトを初期化する

init は、現在の作業ディレクトリに ClickHouse および Postgres のプロジェクトファイル用の標準的なフォルダー構成を作成します。これは必須ではなく、必要に応じて独自のフォルダー構成を使用できます。 次の構成が作成されます。

クエリを実行する

ClickHouse サーバーの作成と管理

ClickHouse サーバーのインスタンスを起動・管理します。各サーバーには、それぞれ独立したデータディレクトリが .clickhouse/servers/<name>/data/ に割り当てられます。
サーバー名: --name を指定しない場合、最初のサーバーの名前は “default” になります。“default” がすでに実行中であれば、ランダムな名前 (例: “bold-crane”) が生成されます。繰り返し起動/停止する際に同じ識別子を使いたい場合は、--name を使用してください。 ポート: デフォルトでは HTTP 8123 と TCP 9000 を使用します。これらがすでに使用中の場合は、空いているポートが自動的に割り当てられ、出力に表示されます。ポートを明示的に指定するには、--http-port--tcp-port を使用してください。 グローバルなサーバー管理: liststopstop-all では --global を使用することで、システム全体の全プロジェクトを対象に操作できます。server list --global は、実行中のすべての ClickHouse サーバーを表示し、各サーバーがどのディレクトリに属しているかを示す Project カラムも表示します。

ローカルサーバー向けのカスタム設定ファイル

ローカルサーバーは適切なデフォルト設定で起動しますが、設定を切り替える必要がある場合もあります。設定ファイルを ~/.clickhouse/configs/ に配置し、サーバーの起動時に名前を指定して適用します。
指定したファイルは、ClickHouse の組み込みのデフォルト設定に重ねて適用される (config.d 経由) ため、変更したい設定だけを含めればよく、完全な config を再現する必要はありません。ファイルは .xml.yaml.yml のいずれでもよく、拡張子の有無にかかわらず名前で参照できます。

プロジェクトローカルのデータディレクトリ

すべてのサーバーのデータは、プロジェクトディレクトリ内の .clickhouse/ に保存されます。
名前付きサーバーごとに専用のデータディレクトリがあるため、サーバー同士は完全に分離されています。再起動してもデータは保持されます。中断したところから再開するには、名前を指定してサーバーを停止し、再度起動してください。サーバーのデータを完全に削除するには、clickhousectl local server remove <name> を使用します。

ローカルのPostgresを実行する

ClickHouseに加えて、clickhousectl ではローカルのPostgresインスタンスを実行・管理することもできます。ローカルのPostgresはDocker上で動作するため、Dockerがインストールされ、起動している必要があります。各インスタンスは名前とメジャーバージョンで識別されるため、複数のPostgresバージョンをそれぞれ別のデータディレクトリで並行して実行できます。

認証

APIキー (推奨) またはOAuth (ブラウザベース) を使用して、ClickHouse Cloud に認証します。 まだClickHouse Cloudのアカウントをお持ちでない場合は、clickhousectl cloud auth signup を実行すると、ブラウザでサインアップページが開きます。

API キー/シークレット (推奨)

API キーは、認証方法として推奨されています。特に、AI Agent から CLI を操作する場合に適しています。スコープ付き API キーを作成すると、選択した権限 (read-only または read/write) のみを付与でき、各キーは 1 つの組織に紐付けられます。そのため、CLI にアクセスを許可するための、安全で最小権限の方法となります。
認証情報は .clickhouse/credentials.json (プロジェクトローカル) に保存されます。 環境変数を使用することもできます。セッションで export する場合は次のとおりです:
または、現在の作業ディレクトリの .env ファイルに配置します:
または、どのコマンドでもフラグを使って認証情報を直接渡せます:

OAuthログイン

これにより、OAuth デバイスフローによる認証のためにブラウザが開きます。トークンは .clickhouse/tokens.json に保存されます (プロジェクトローカル) 。
OAuth アクセスは現在 読み取り専用 で、あなたが所属するすべての組織 にアクセスできます。書き込みアクセスが必要な場合、または CLI の対象を 1 つの組織に限定する場合は、代わりに スコープ付き API キーを作成 してください。

認証ステータスとログアウト

認証情報の解決順: CLI フラグ > .clickhouse/credentials.json > export 済みの環境変数 > .env ファイル > OAuth トークン。

使用された認証情報の取得元をデバッグする

任意のcloudコマンドに--debugを指定すると、コマンドの実行前に、解決された認証情報の取得元 (および API URL) が stderr に出力されます。

Cloud

API を使用して ClickHouse Cloud サービスを管理します。

組織

サービス

サービス作成オプション

Query API の認証モード

cloud service query は、clickhouse バイナリやサービスのパスワードを使わずに、HTTP 経由で Cloud サービスに対して SQL を実行するための標準的な方法です。どちらの認証モードにも対応しています。
  • API キー認証 (SQL の読み取り + 書き込み) : 保存済みの API キーがないサービスに対して cloud service query を初めて実行すると、そのサービス用の Query API エンドポイントがプロビジョニングされ、それに紐づく専用の API キーが作成されます。この key (keyIdkeySecretendpointId) は、.clickhouse/credentials.jsonservice_query_keys.<service-id> に保存されます。この key のスコープは 1 つのサービスに限定されるため、そのサービスに対する読み取りと書き込み (SELECT、INSERT、DDL) はできますが、組織内の他のサービスにはアクセスできません。プロビジョニングせずに失敗させるには、--no-auto-enable を指定します。
  • OAuth (cloud auth login) : クエリは、Web の SQL コンソールと同様に、ユーザー自身の identity として実行されます。OAuth 使用時のサービス上の SQL permissions は read-only です。Query API キーがプロビジョニングまたは保存されることはありません。このモードでは --no-auto-enable は効果がありません。
idled 状態のサービスにクエリすると、どちらの認証モードでも自動的に復帰します (最初のクエリには 1 分ほどかかる場合があります) 。stopped 状態のサービスが自動的に起動されることはなく、クエリは cloud service start を実行するよう案内するヒント付きで失敗します。生成された Query API ホストを上書きするには、CLICKHOUSE_CLOUD_QUERY_HOST を設定します。

クエリエンドポイントの管理

プライベート エンドポイントの管理

バックアップ設定

Postgres サービス

clickhousectl では、上記の ClickHouse サービス用コマンドと同様に、ClickHouse Cloud Postgres サービスの作成や管理も行えます。

Postgres サービスの作成オプション

バックアップ

ClickPipes

外部ソースからClickHouse Cloudにデータを取り込むためのClickPipesを管理します。

ClickPipes の作成

各ソースタイプには、clickpipe create の配下にそれぞれ固有のサブコマンドがあります。
ソースタイプごとの全オプションは、clickhousectl cloud clickpipe create <source> --helpで確認してください。

メンバー

招待

キー

アクティビティ

JSON 出力

JSON 形式のレスポンスを出力するには、--json フラグを使用します。
clickhousectl は、コーディングエージェントのコンテキスト (Claude Code、Cursor、Codex、Gemini CLI、Goose、Devin、および標準の AGENT 環境変数を設定する任意のツール) を自動検出し、--json を指定しなくても JSON を stdout に自動的に出力します。

終了コード

終了コードは gh CLI の慣例に従います。

スキル

公式の ClickHouse Agent スキル は、ClickHouse/agent-skills からインストールしてください。

非対話型フラグ

セルフアップデート

clickhousectl は自身を最新リリースに更新できます。
CLI はバックグラウンドで更新の有無も確認し (24 時間に 1 回まで) 、新しいバージョンが利用可能な場合は通知を表示します。
最終更新日 2026年6月25日