Chat2DB Community を採用する前に確認すべきこと

Chat2DB が埋めるのは「接続先が増えすぎた開発者」の作業台

MySQL、PostgreSQL、ClickHouse、MongoDB、Redis と、現場で扱うデータストアの種類は増える一方だ。Chat2DB はこれを 1 つのクライアントに集約する。README が挙げる対応先は 40 以上で、MySQL、PostgreSQL、Oracle、SQL Server、ClickHouse、MongoDB、Redis、SQLite、MariaDB、TiDB、Hive、DB2、Snowflake、BigQuery、Elasticsearch、Trino、TimescaleDB、Greenplum、YugabyteDB、CrateDB、QuestDB、Apache IoTDB、Firebird、HSQLDB、Apache Derby が名指しされている。

対象として README が明示するのは開発者、DBA、アナリスト、データチーム。GUI でメタデータを眺め、DDL と DML を実行し、データをその場で編集し、CSV などを入出力する。そこに自然言語から SQL を生成する層が乗る。SQL エディタ単体でも成立する作りで、AI は後付けの付加機能という位置づけに見える。

見落としやすいのは拡張の入口だ。新しい JDBC データベースはコード変更なしで、設定だけで追加できると README は説明している。社内固有の JDBC ドライバを使う現場にとっては、この一点が採用理由になり得る。

AI は同梱されない。自分のモデルを接続する設計

Chat2DB の AI 支援は、モデルを同梱して提供するタイプではない。README の表現は「bring your own AI model」で、生成、説明、最適化を自然言語で行うために自分のモデルを接続する。つまり推論コストとデータの送信先は利用者側の設定に依存する。

API キーは暗号化して保存される。README によれば、データソースのパスワードと AI モデルの API キーは AES-256-GCM で、インストールごとの鍵を使って暗号化される。同じ鍵を使いつつ、用途ごとに別の AAD 値で認証しているため、片方の暗号文をもう片方として復号することはできないと説明されている。

ここで実務上の論点が出る。スキーマ情報やクエリをどのモデルに送るかは、ツール側ではなく接続設定側の判断になる。オンプレミスのモデルを指定すれば送信先は閉じるが、外部 API を使えばスキーマが外に出る。Chat2DB はその境界を決めてくれない。

暗号鍵が単一障害点になる

Web 版とヘッドレス起動では、暗号鍵がなければ起動に失敗する。README は「Web/headless startup fails when no valid key is provided」と明記し、鍵を自動生成するのは Desktop モードだけだとしている。

鍵はリポジトリのチェックアウトから一度だけ生成する。

./script/security/init-community-encryption-key.sh

出力先は ~/.config/chat2db-community/encryption.key。README はこれを別途バックアップし、アップグレードやコンテナ再構築をまたいで保持するよう求めている。置き換えたり失ったりすれば、保存済みのデータソースパスワードと AI モデルの API キーは読めなくなる。

鍵の形式は Base64 で、デコードしてちょうど 32 バイトでなければならない。初期化スクリプトが生成するのは 44 文字で末尾が = のパディング形式。人間が覚えるパスワードではなく、そのまま保管する鍵素材だ。カスタムパスを使う場合はスクリプトの引数と起動時の -Dchat2db.community.encryption-key-file の両方に同じパスを渡す必要がある。

Desktop と Docker でデータの置き場所が違う

配布形態は Desktop、Web、Docker、CLI の 4 つ。Desktop は GitHub Releases からインストーラを落として入れるだけで、追加設定は不要と README は書く。Docker は要件が明示されていて、Docker 19.03.0 以上、Compose V2 を使う場合は Docker Compose 2.0.0 以上、CPU 2 コア以上、メモリ 4 GiB 以上。

Docker の起動手順は鍵生成が先だ。

git clone https://github.com/OtterMind/Chat2DB.git && cd Chat2DB ./script/security/init-community-encryption-key.sh

docker run --detach \ --name chat2db-community \ --restart unless-stopped \ --publish 127.0.0.1:10825:10825 \ --volume "$HOME/.chat2db-community-docker:/root/.chat2db-community" \ --env CHAT2DB_COMMUNITY_ENCRYPTION_KEY_FILE=/run/secrets/chat2db-community-encryption.key \ --volume "$HOME/.config/chat2db-community/encryption.key:/run/secrets/chat2db-community-encryption.key:ro" \ chat2db/chat2db:latest

起動後は http://localhost:10825 を開く。Compose を使うなら docker compose --file docker/docker-compose.yml up --detach でよい。

注意点が 2 つある。1 つ目はデータの保存先。docker run の例は $HOME/.chat2db-community-docker を使い、Compose 定義は chat2db-community-data という名前付きボリュームを使う。README はこの 2 か所はデータを共有しないと明記している。2 つ目はバージョン間の移行。Chat2DB Community 5.3.0 は独立した /root/.chat2db-community を使い、それ以前のイメージが使っていた /root/.chat2db からの自動移行は行わない。

127.0.0.1 に縛る前提を崩すと壊れる

README のセキュリティ節はかなり率直だ。Chat2DB Community は単一ユーザー向けのローカルファーストアプリケーションであり、ユーザーアカウントもユーザー間の認可境界も持たない。HTTP サービスは 127.0.0.1 か ::1 に束縛したままにし、他のユーザーや信頼できないネットワークに公開してはならない、と書かれている。

これは「設定を忘れると危ない」という話ではなく、境界が存在しないという設計の話だ。社内の誰でも URL を叩ける場所に置けば、接続済みの全データソースに誰でも到達できる。docker run の例が --publish 127.0.0.1:10825:10825 とループバックに固定しているのはこのためだ。

もう 1 つの信頼境界は JDBC ドライバで、README はこれを実行可能な Java コードだと説明し、信頼できる入手元のものだけを入れよとしている。加えて、インポートした設定ファイル、アーカイブ、SQL ファイル、データベースの中身、AI の応答はいずれも信頼できないデータとして扱う、としている。AI が生成した SQL をそのまま実行する運用を取るなら、この但し書きは自分の環境の話になる。

DBeaver との差は「AI を同梱するか、自分で繋ぐか」

比較対象として素直なのは DBeaver だ。同じく Java ベースで JDBC ドライバを差し替えて多数のデータベースに接続する。GUI の作りも、メタデータ閲覧、SQL 実行、データ編集、ER 図、データ入出力という機能の並びも近い。

違いは AI の扱いに出る。DBeaver は AI 支援をコアの前提に置かず、拡張や別製品の側に寄せる。Chat2DB は自然言語からの SQL 生成、説明、最適化を最初から画面に組み込み、そのバックエンドを利用者のモデルに委ねる。モデルを自分で用意する手間を許容できるなら、Chat2DB のほうが設定は短い。逆に、AI を一切使わず純粋な SQL クライアントとして使いたいなら、Chat2DB を選ぶ理由は薄い。

もう 1 つの差は配布の形だ。Chat2DB は Desktop だけでなく Web と Docker と CLI を用意し、CLI は MCP に対応すると README は説明している。ヘッドレス環境やエージェントからデータベースを触りたい場合、この経路があるかどうかが分岐点になる。

ライセンス表記が確定していない点をどう扱うか

リポジトリのライセンス識別子は NOASSERTION で、これは SPDX の標準的な識別子に自動判定できなかったことを意味する。README は Community 版を free と表現しているが、この表記だけでは再配布や商用利用の条件は決まらない。

ここは推測で埋めてはいけない部分だ。導入を検討する組織は、リポジトリ内のライセンスファイルと配布条件を自分で確認し、必要なら法務に回すべきである。本記事は法的助言を与えるものではない。

運用コストの側面はもう少し具体的に言える。リリースは v5.3.3、v5.3.4、v5.3.5 と約 2 週間間隔で出ており、更新のたびにイメージを取得し直し、コンテナを削除して起動コマンドを再実行する。このとき鍵ファイルを消さないこと。Desktop 版はインストーラの更新で完結するが、Docker 版はデータボリュームと鍵の 2 つを意識して保持し続ける必要がある。

編集部の結論

単一ユーザーが手元のマシンで複数種のデータベースを横断して触り、SQL 生成や説明を自分のモデルに任せたいなら、Desktop 版から試す価値はある。逆に、チームで共有する Web サービスとして公開したい場合や、複数人で同一インスタンスに接続する運用は想定されていない。最初に確認するのは 3 点。Desktop 版で鍵ファイルがどこに生成されるか、既存の接続情報を移行する場合に 5.3.0 の /root/.chat2db-community へ手動で移す必要があるか、そして AI に渡すスキーマ情報の範囲をどこまで許容するか。鍵ファイルを失えば保存済みパスワードと API キーは復号できないので、導入初日に ~/.config/chat2db-community/encryption.key のバックアップ先を決めておくこと。

公式情報源

1. Issues
2. OtterMind/Chat2DB on GitHub
3. Project website
4. README
5. Releases