dbxのMCPサーバーでClaude CodeからDBを直接操作する：AIエージェント時代のDBAワークフロー実践ガイド

「スキーマをコピペしてAIに貼る」作業、まだ続けますか？

Claude CodeやCursorでDB関連のコードを書かせるとき、こんな作業をしていませんか？

1. SHOW CREATE TABLE users を実行してターミナルに表示
2. その結果をコピーしてチャットに貼り付け
3. AIが生成したSQLをコピーして、DBクライアントに戻して実行
4. エラーがあればまた貼り直し……

この往復が消えます。それが本記事の結論です。

本記事を読み終えると、以下ができるようになります。

• dbxのMCPサーバーをClaude Codeに接続し、AIが直接DBを参照・操作できる環境を構築できる
• AI生成SQLを3段階の権限モデルで事前審査し、意図しないデータ破損を防ぐ設計を理解できる
• SSH経由で本番DBに安全につなぎ、本番調査をエージェントに任せる運用を組める

扱う範囲はMCPサーバーの導入から、10ツールの使い分け、セーフティチェック設計、本番DBへのSSH接続までです。順番に手を動かしながら読み進めてみてください。

dbxとは — Rust製・単一バイナリのクロスプラットフォームDB管理ツール

基本スペックと立ち位置

dbx（GitHub: t8y2/dbx、ライセンス: Apache-2.0）は、Rust製の軽量クロスプラットフォームDB管理ツールです。Javaランタイム不要の単一バイナリとして動作し、macOS・Windows・Linux、さらにDockerによるセルフホストにも対応しています。

対応データベースは90種類以上。MySQL・PostgreSQL・SQLite・Redis・MongoDB・DuckDB・SQL Server・Oracle・ClickHouseはもちろん、マイナーなDBまで広くカバーしています。

一般的なGUIクライアントとの決定的な違いは、**「GUIクライアント＋MCPサーバーが同梱されている」**という設計にあります。この一点が、後述するセーフティチェックの仕組みを可能にしています。

なぜRustなのか — MCPサーバーという用途に効く3つの理由

「Rustだから速い」では終わらない話をします。MCPサーバーという常駐プロセスの文脈でRustが効いてくる理由は以下の3点です。

• パフォーマンス：仮想スクロール対応グリッドや、Parquet・CSV・JSONのドラッグ＆ドロッププレビューをネイティブ速度で処理できます
• メモリ安全性：MCPサーバーはエージェントから継続的にリクエストを受け続けます。Rustのメモリ安全性はクラッシュ耐性に直結し、長時間稼働の信頼性を担保します
• 低リソース：デスクトップアプリにMCPサーバーを同梱しながら軽量に収まるため、常時起動が現実的な選択肢になります

GUIとMCPを共有する設計思想

dbxの核心はここにあります。従来のDBクライアントは「人間が操作する前提のGUI」として設計されていました。dbxは異なります。

• 人間 → GUIでDB操作
• AIエージェント → MCPサーバー経由でDB操作

この2つが同じ接続プールを共有しています。この設計が何を意味するか。AIエージェントに認証情報を直接渡す必要がない、ということです。この点は後ほど詳しく説明します。

そもそもMCPとは — 2026年時点の立ち位置を30秒で

Model Context Protocolの基礎

MCP（Model Context Protocol）は、Anthropicが2024年11月に発表したオープンプロトコルです。「AIアプリと外部データソースをつなぐUSB-C端子」と表現されることが多く、ツール・リソース・プロンプトの3プリミティブでAIに外部機能を提供します。本記事で使うのは主にToolsです。

2025→2026、業界標準への昇格

MCPはすでに「一社の独自仕様」ではありません。

• 2025年12月にLinux Foundationへ寄贈され、ベンダー中立の標準規格に昇格
• OpenAI・Google DeepMind・Microsoftも採用を表明
• 2026年初頭時点で1,000以上のコミュニティMCPサーバーが公開

この標準化の進展が、「MCPに乗ることへのリスク」を実質的に消しています。今が導入を検討するタイミングと言えるでしょう。

MCP対応クライアントなら実装は使い回せる

Claude Code・Cursor・Windsurf・Clineなど、主要なAIコーディングエージェントはすでにMCPに対応しています。設定ファイルの置き場所こそ異なりますが、記述するJSONの内容はほぼ同一です。次章で実際に確認します。

【実践1】dbx MCPサーバーをClaude Codeに接続する

前提条件チェックリスト

作業を始める前に以下を確認してください。

• dbxデスクトップアプリをインストール済み
• Node.js（npx が実行できる状態）がインストール済み
• dbx側に最低1つのDB接続が登録済み ← これが重要な前提です

最後の点が特に重要です。dbxのMCPサーバーはdbxアプリで登録済みの接続情報を参照します。エージェントに認証情報を渡す必要がない理由はここにあります。

設定ファイルに数行追加するだけ

Claude CodeでdbxのMCPサーバーを有効化するには、以下のJSONを設定ファイルに追加します。

{
  "mcpServers": {
    "dbx": {
      "command": "npx",
      "args": ["-y", "@dbx-app/mcp-server"]
    }
  }
}

配置先のファイルは目的に応じて選択してください。

-y フラグは npx の確認プロンプトをスキップします。初回実行時はパッケージの取得のため数秒かかりますが、2回目以降はキャッシュが効きます。

Cursor / Windsurf での設定差分

他のクライアントを使っている方のために、設定ファイルのパスをまとめます。JSON本体の内容は同一です。

接続確認 — 最初に打つべき一言

設定後、Claude Codeで /mcp コマンドを実行してサーバーが connected 状態になっているか確認してください。

動作確認に使えるプロンプト例です。

dbxに登録されている接続を一覧して

うまくいかない場合の初動確認ポイントは3つです。

1. dbxデスクトップアプリが起動中か
2. Node.jsのパスが通っているか（which npx で確認）
3. Claude Codeを再起動したか

【実践2】AIエージェントが使える10のMCPツール

ツール一覧と役割

dbxのMCPサーバーが提供するツールは以下の10種類です。

4カテゴリで理解する

機能別に整理すると、使い分けの判断が明確になります。

• 探索系（list_connections / list_tables / describe_table / get_schema_context）：AIがDBの構造を把握するための読み取り系ツール群
• 実行系（execute_query / execute_redis_command）：実際にクエリを発行するツール
• GUI連携系（open_table / execute_and_show）：結果をdbxデスクトップに表示するdbxならではの機能
• 管理系（add_connection / remove_connection）：接続情報の追加・削除

dbx_get_schema_context が効く理由

生の DESCRIBE や SHOW CREATE TABLE の出力をそのままAIに渡すと、2つの問題が生じます。トークンの浪費と、整形されていない情報による精度の低下です。

dbx_get_schema_context はこの問題をツール側で解決します。AI向けに整形されたスキーマコンテキストを返すため、プロンプト設計の手間が省けます。導入部で約束した「スキーマのコピペが不要になる」は、技術的にはここで実現されています。

dbx_execute_query の100行上限は制約ではなく設計

クエリ結果が最大100行に制限されていることを、最初は「不便」と感じるかもしれません。しかしこれはAI-DB統合における意図的な設計です。

実際の開発現場では、この制限が2つの事故を防ぎます。

1. コンテキストウィンドウの枯渇：数万行の結果がAIのコンテキストを埋め尽くし、後続のタスクが実行不能になる
2. 誤った全件SELECT の被害抑制：意図せず SELECT * FROM logs を実行しても、影響が100行に収まる

大量データが必要な場合は、集約クエリを書かせる方向に自然と誘導されます。これは実際の開発現場でのベストプラクティスと一致しています。

【本記事の核心】セーフティチェック — AI生成SQLを実行前に審査する

前提：AI生成SQLのゼロショット精度は約78%

2026年の業界調査では、AIが生成したSQLのゼロショット実行精度は**約78%**とされています。5クエリに1つは何らかの誤りを含む計算です。

より深刻なのは、エラーを返さずに静かにデータを壊すSQLの存在です。代表的なパターンを挙げます。

• WHERE 句が脱落した UPDATE / DELETE
• JOIN 条件の取り違えによる意図しないデータ結合
• 確認なしで実行される TRUNCATE

「AIを信用するかどうか」という問いの立て方は実は正確ではありません。正確に言えば、「信用の範囲を機械的にどう区切るか」という設計の問題です。dbxはこれをツール側で解決しています。

dbxの3段階権限モデル

dbxの「設定 → MCP」画面から、接続ごとに以下の3段階の権限を設定できます。

注目すべきは 「Data read/write」が「WHERE付き」を条件にしている点です。WHERE句の脱落という最も頻発する事故パターンを、構文レベルで遮断しています。

また「接続ごと」に設定できることも重要です。本番DBはRead only、開発DBはFull accessという粒度でコントロールできます。

環境別の推奨設定

実際の開発現場では、以下の設定を起点にするとよいでしょう。

最小権限の原則をAIエージェントに適用する

2026年のAI-DB統合ベストプラクティスとして確立しているのは、最小権限の原則（Least Privilege）・監査ログ・結果サイズ制限の3点セットです。

dbxはこのうち「権限制御」と「結果サイズ制限」の2つをツール側で提供しています。残る運用責任は、どの接続にどのレベルを割り当てるかの判断です。この判断は機械には委ねられません。人間が意図を持って設定する必要があります。

それでも防げないこと（正直に書きます）

権限モデルがあれば安全、と言い切るつもりはありません。以下は現時点での限界として認識してください。

• 本番負荷：Read only設定でも、重い集約クエリは本番DBに負荷をかけます
• 設定ミス：権限設定そのものを誤った場合、権限モデルでは救えません
• データのコンテキスト流出：AIのコンテキストに機密データが載る点は別途考慮が必要です

これらは免責事項ではなく、「権限設定後に何を監視すべきか」の観点として捉えてください。

【実践3】SSH経由で本番DBに安全につなぐ

SSHトンネル設定

dbxはSSHトンネル経由の接続をサポートしています。鍵認証・パスワード認証の両方に対応しており、踏み台サーバー経由の典型的なアーキテクチャで使用できます。

AIエージェント
  ↓ MCP
dbxデスクトップ
  ↓ SSHトンネル（鍵認証）
踏み台サーバー
  ↓ VPC内通信
本番DB（インターネット非公開）

「Read only権限 × SSHトンネル」の組み合わせが、本番DBへの安全なエージェントアクセスにおける二重ロックとして機能します。

設定の暗号化エクスポート／インポート

dbxには接続設定を暗号化してエクスポート・インポートする機能があります。チーム開発での活用場面が主です。

• 新メンバーのオンボーディングが「暗号化ファイルを渡す」だけで完了する
• 接続情報が平文でSlackやメールに流れるリスクを排除できる

注意点として、エクスポートファイルはGit管理しないこと、受け渡しルールをチームで合意することを強くお勧めします。

ユースケース — 実際のワークフローはこう変わる

ケース1：スキーマを把握しながらAPIを書かせる

usersテーブルとordersテーブルの構造を見て、
注文履歴を返すREST APIエンドポイントを実装して

エージェントの内部動作：describe_table でスキーマ取得 → get_schema_context でAI向けに整形 → 実装コード生成

従来との差分はスキーマの手動転記がゼロになること、型の取り違えがなくなることです。

ケース2：本番データの調査（Read only）

先週の解約ユーザーの行動パターンを調べて。
7日間のアクティビティを集計してほしい

execute_query で集約クエリを発行し、結果をそのまま分析コメントに変換します。100行制限があるため、自然と集約クエリを書く方向に誘導される点も実際の現場では使いやすいポイントです。

ケース3：Redis / MongoDB など非RDBの操作

セッションキャッシュの現在の件数と、
TTLが切れそうなキーを教えて

execute_redis_command によるキャッシュ状態の確認が、自然言語から実行できます。「RDBだけのMCPサーバー」との差別化ポイントです。

ケース4：GUIとエージェントのハイブリッド

dbx_open_table や dbx_execute_and_show を使うと、エージェントが実行したクエリの結果をdbxデスクトップに表示できます。

「AIに任せる」と「自分の目で確かめる」の切り替えコストがほぼゼロです。エージェントが生成したSQLを確認してから実行、という判断を人間が挟みやすい構造になっています。

よくある疑問（FAQ）

dbxに登録済みの接続設定はそのまま使える？

はい。dbx側で設定済みの接続をMCPで公開する方式のため、AIエージェントにDB認証情報を直接渡す必要がありません。認証情報はdbxアプリ内に留まります。

本番DBにつないで安全ですか？

Read only権限 + SSHトンネルの組み合わせで制御可能です。ただし、どの接続にどのレベルを割り当てるかの判断は運用者の責任になります。設定後は対象接続の権限を定期的に見直す習慣をつけてください。

対応しているデータベースは何種類ですか？

90種類以上です。MySQL・PostgreSQL・SQLite・Redis・MongoDB・DuckDB・SQL Server・Oracle・ClickHouseなどが含まれます。最新の対応状況は公式GitHubリポジトリでご確認ください。

Claude Code以外のエージェントでも使えますか？

MCP対応クライアントであればどれでも利用可能です。Cursor（.cursor/mcp.json）やWindsurf（mcp_config.json）での設定は、JSON本体の内容は同一でファイルパスのみ異なります。

他のDB系MCPサーバーとの違いは何ですか？

3点あります。①GUIクライアントと接続プールを共有し認証情報をエージェントに渡さない点、②接続単位の3段階権限モデル、③Redis・MongoDBなど非RDBを同一インターフェースで扱える点。特に②はAI生成SQLのリスク管理として実用的な差別化になっています。

まとめ — エージェント時代のDBAワークフローへ

本記事で紹介した内容を3点に整理します。

1. 設定はJSON数行、dbxに登録済みの接続を流用するため、AIエージェントへの認証情報の受け渡しは不要
2. 10のMCPツールで探索・実行・GUI連携・管理をカバー。dbx_get_schema_context がスキーマコピペの作業を消し去る
3. 3段階権限モデルが、AI生成SQL約78%精度問題への現実的な回答。WHERE付きUPDATE/DELECTのみ許可するData read/writeレベルが特に有効

まず試してみるなら、ローカル開発DBをRead onlyで登録し、dbx_get_schema_context の出力を確認するだけで十分です。スキーマ情報がどのようにAI向けに整形されるかを見るだけで、このツールの設計思想が伝わるはずです。

MCPがLinux Foundation標準になった今、問われているのは「AIをDBにつなぐかどうか」ではありません。どこまでの権限でつなぐか——この問いへの答えを、dbxは具体的な選択肢として提供しています。

参考リンク

• dbx GitHub リポジトリ
• dbx MCP Server README
• MCP Complete 2026 Guide (WorkOS)
• Best MCP Servers for Claude Code (MintMCP)
• How to Validate AI-Generated SQL Before Deployment (Liquibase)
• SQL Agent Safety Architecture (Tim Dietrich)