DBX - GUI・CLI・MCPで接続設定を再利用するデータベースクライアント

データベースクライアントでスキーマを調べ、SQLを編集し、その内容を別のAI画面へ渡す。端末から同じ接続先を操作するときには、さらに接続情報を用意する。DBXが対象にしているのは、こうした操作面の分散だと読み取れる。READMEはAIツールとのコピー＆ペーストを減らす編集体験と、DBeaver／Navicatからの接続インポートを示している。

この位置付けでは、SQLエディターの機能だけを比べても設計の狙いを捉えにくい。GUIで管理する接続を、CLIのクエリ実行やMCP経由のテーブル参照へどう引き継ぐかが焦点になる。ただし、接続設定を再利用できるからといって、すべての入口で権限制御や実行処理が同じとは限らない。取得資料から確認できるのは各操作経路の説明であり、共通内部モジュールの構造ではない。

作者はDBXを「100以上のデータベース」に対応するクライアントと説明する。その範囲にはネイティブドライバーに加え、エージェント経由の接続も含まれる。多種類の接続先を一つの画面で探索する用途は考えられるが、接続できることから編集機能の同等性までは導けない。

READMEのスキーマブラウザーはテーブル、列、索引、外部キーなどを扱う一方、構造編集やオブジェクト編集には対応エンジンの条件がある。採用時には、必要な接続先ごとに読取、更新、構造変更、トランザクションなどを確認する必要がある。取得資料には、それらを横断して比較できる統一した機能対応表はない。

認証情報を保存したファイルがあっても、別の操作経路で使えるとは限らない。READMEによれば、DBXは認証情報をdbx.dbへ保存する前に暗号化する。デスクトップではOSの資格情報ストア、Web／Dockerでは既定でデータディレクトリ内のsecret.keyを使う。

したがって、CLIやMCPへ接続を引き継ぐ条件には、保存データの場所だけでなく、復号鍵へアクセスできることも含まれる。接続管理を共有する設計を理解するには、プロファイルと鍵を別の要素として捉える必要がある。

READMEが示すデスクトップ構成は、Tauri 2のアプリにVue 3＋TypeScriptの画面とRustバックエンドを組み合わせたものだ。SQL編集にはCodeMirror 6を使い、メタデータに基づく補完と診断を提供するとされる。問い合わせ結果は、仮想スクロールに対応するデータグリッドで表示する。

記載された要素をつなぐと、エディターでSQLを編集し、Rustバックエンドの対応ドライバーを通じて問い合わせ、その結果をグリッドへ返す概念的な流れになる。バックエンドの利用ライブラリにはsqlx、tiberius、redis-rs、MongoDBのRustドライバーが挙がる。ただし、画面とバックエンドのIPC、接続プール、結果の転送単位は未確認だ。仮想スクロールの記載から、データベース側の読込方式や大規模結果の処理性能まで推定することはできない。

接続先の拡張には、ネイティブドライバー、エージェントベースのプロファイル、ドライバーストア、任意のJDBCプラグインが用意されると説明されている。つまり、対応先が増えても、すべてを同じ依存関係で扱う構成とは限らない。接続先の選択は、どの実行経路と追加要素を使うかの選択にもなる。

プラグインについては、インストール前の署名検証、UIのサンドボックス化、各プラグイン専用のsidecarプロセスが記載される。ただし、この説明だけではデータベース操作を含む権限境界の全体は分からない。署名検証やUIの隔離という要素と、MCPから許可される操作の範囲は、それぞれ確認すべき設計事項である。

MCP利用では、まずDBXで接続を登録し、Settings → MCPで接続許可リストとアクセスモードを管理する。モードの機械可読値はread_only、safe_write、high_risk_write。取得された製品リリースはv0.6.29で、リリースノートはアクセス方針を明示的に適用した場合だけ永続化する修正を報告している。画面で設定した内容と、保存された方針を区別して扱う必要がある。

次に、エージェントのMCP設定から独立サーバーを起動する。READMEによれば、サーバー本体はRust製で、npm配布では小さなNode.jsランチャーがそのバイナリを起動する。ネイティブバイナリはNode.jsなしで実行できる。デスクトップへの自動導入ではないため、利用するエージェント側の起動設定も必要になる。

サーバーが提供するとされる操作は、接続一覧、テーブル参照、SQL実行、DBXのUIでテーブルを開く操作だ。既存接続を再利用するため、エージェントの入口からDBXの接続管理へ戻る構図になる。一方、許可リストとモードをどの順序で評価し、SQLをどう分類・拒否するかは未確認である。モード名から、特定のSQLが確実に許可または拒否されると推定してはいけない。

旧設定のDBX_MCP_ALLOW_WRITES=0にも注意が要る。READMEでは、中央ポリシーを初めて保存するまでの制限であり、保存済みポリシーを上書きしないと説明する。環境変数の値だけを見て、現在のアクセス方針を判断することはできない。

ローカルのCLIとstandalone MCPは、既存のDBXデータと、OS資格情報ストアまたは明示設定した鍵を利用する。起動時に鍵を作成したり、旧平文データを自動移行したりはしない。移行が必要ならDesktop／Webのウィザードを使う。Windows portable版では、dbx.dbを含むdataディレクトリをDBX_DATA_DIRで指定する必要がある。

Web／Docker構成では、MCPはWebバックエンドのHTTP APIへ接続する。接続先をDBX_WEB_URLで指定し、Webログインがパスワードを要求する場合には、同じパスワードをDBX_WEB_PASSWORDへ設定する。ローカルの保存データを利用する経路と、Webバックエンドへ要求を渡す経路では、接続の境界が異なる。ただし、取得資料にはWeb API仕様や認証方式の全体像がなく、この設定だけで認証・認可の全体を説明することはできない。

専用CLIは、接続一覧やクエリ結果のJSON出力を示している。たとえば「dbx connections list --json」と「dbx query local "select 1" --json」がREADMEの例で、localは例示された接続識別子だ。既存データと復号鍵を利用できる端末なら、この出力をスクリプトやシェル対応エージェントへ渡す用途を考えられる。

DBX内のAI SQL補助は、MCPで外部エージェントへ操作を提供する経路とは別に捉えたい。READMEはClaude、OpenAI、Ollamaなどのローカルモデル、OpenAI互換APIへの対応と、生成SQLの実行前安全チェックを説明する。v0.6.29では選択テキストを文脈として送信する機能も報告される。ただし、スキーマやクエリ結果を含む送信データ全体、保持方針、安全チェックの判定規則は未確認だ。確認できるのは文脈をSQL生成へ渡す入口と、実行前チェックの存在についての作者の説明までである。

適合しやすいのは、複数DBのスキーマ探索、SQL編集、結果確認をGUIへまとめ、その接続を端末やMCP互換エージェントでも利用したい開発作業だ。人が確認する画面を保ちながら、接続許可リストとアクセスモードを設定してエージェントへ提供する用途が考えられる。CLIはJSONを扱う既存のスクリプトと組み合わせる入口になる。

一方、すべての接続先で同じ編集・比較機能が使えることを前提とする運用には、資料が不足している。v0.6.29のデータ比較も、テーブルごとの読込上限と打ち切り表示を持つと報告される。大きなテーブルの比較結果を全件一致の証明として扱うには、読込範囲を追加確認する必要がある。

DBeaverとNavicatは同じデータベースクライアント領域の比較候補で、DBXは両者からの接続インポートを記載する。既存の接続設定を移す入口はあるが、それだけで日常の操作や運用機能まで全面的に置き換えられるとは判断できない。必要なエンジンと操作を揃えて比較したい。

READMEはDBeaverのJava依存とDBXのChromium非同梱・Rust構成を対比し、作者はアプリサイズを約25 MBと説明する。ただし、対象OS、配布形式、計測方法、外部依存を含むかは不明で、起動速度やメモリ使用量の独立比較もない。小さい配布物という説明を、そのまま高速性や運用コストの低さへ結び付ける根拠はない。

「追加ランタイム不要」という説明も構成ごとに読む必要がある。npm版MCPはNode.jsランチャーを使い、外部エージェントやJDBCの経路もある。ソースビルドにはNode.js、pnpm、RustとLinuxのシステム依存が必要だ。比較する単位は製品名だけでなく、実際に選ぶ配布・接続構成になる。

Docker経由のブラウザー利用は、保存データと鍵の永続化・バックアップを管理できるチームで検討できる。ただし、既定のsecret.keyはdbx.dbと同じ永続データ領域に置かれる。領域全体がコピーまたは公開された場合、保存時暗号化だけでは保護できない。バックアップ対象に鍵も含まれる構成として扱う必要がある。

明示設定した鍵は、暗号化データを利用している間に変更してはいけない。また、デスクトップのOS側の鍵はdbx.dbとともに移動しないため、ファイルの直接コピーはデバイス間同期にならない。別デバイスへの移行には暗号化エクスポート／インポートを使う。接続設定を共有する便利さの裏には、保存データと復号手段を維持する作業がある。

取得READMEはMCPの許可リストとアクセスモードを説明するが、SQL判定の実装、認証方式の全体像、監査ログ、安全性テスト結果までは示していない。AI補助にも送信範囲と判定規則の未確認事項がある。本番アクセス前にこれらの実装や試験証跡を要求する環境では、現状の資料だけでは判断材料が足りない。

ライセンスはApache-2.0で、READMEはmacOS・Windows・Linuxのデスクトップに加え、Web／Docker、CLI、独立MCPサーバーを記載する。しかし、配布経路の存在から各環境での同等な動作やAPIの安定性までは確認できない。評価時には、利用する入口、接続先、保存鍵、適用済み方針を組み合わせて確認することになる。