データベース MCPサーバー——エージェントにDBを触らせる口——を、既存のGUIツールが抱え込む例が出てきた。Gridex はその一つで、PostgreSQL・MySQL・SQLite・Redis・MongoDB・SQL Server・ClickHouse の7種をひとつの画面から扱うネイティブの DB IDE に、MCPサーバーとAIチャットを内蔵している。Apache-2.0、⭐1,619、タグ26本。

データベース MCPサーバーを内蔵するという構えで効いてくるのは、機能の多さではなく「何を止められるか」だ。本番の接続をエージェントに渡す以上、権限の切り方がそのまま事故の確率になる。そこでREADMEの公称値ではなく、実装ファイルからツールと防御層を数え直した。

1つのアプリの中身は3つの別実装でmacOSとLinuxとWindows。macOSはSwiftで201ファイル52524行、LinuxとWindowsはC++で185ファイル57264行、MCPサーバーを内蔵し実装は13ツールだがREADMEは15と記載。プラットフォーム別ファイル数はlinuxが267、windowsが252、macosが214。7DB対応を実装で確認、セキュリティ層は6本、AIは3プロバイダとOllama、ビルドは未実施
2026-10-04 時点。行数・ファイル数・ツール名はすべてリポジトリから数えた実測値
この記事のポイント
・READMEの「15 tools」に対し、**実装から数えたツール名は13個**（残り2階層は "(future)" と明記されている）
・逆に**セキュリティ層はREADMEの記載より厚く**、実装では6本あった
・「Swiftで作られた」のは macOS 版だけで、**Swift 52,524行と C++ 57,264行が併存**している
30秒でわかるGridex（2026-10-04時点）
  • ・7種のDBを1画面で扱うネイティブIDE。**Apache-2.0**・⭐1,619・タグ26本
  • ・**MCPサーバー内蔵**。保存済み接続をClaude DesktopやCursorから触らせられる
  • ・MCPツールは実装で **13個**（Schema 6・Read 3・Write 4）
  • ・接続ごとに **locked / read_only / read_write** を設定。書き込みは承認制
  • ・AIチャットは **Anthropic / OpenAI / Ollama** の3プロバイダ
  • ・**macOSはSwift、Linux・WindowsはC++** の3実装が並立

MCPそのものの作り方はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてある。本記事はその応用例として、既存のGUIツールがMCPサーバーを抱え込むという形を実装から読む。

データベース MCPサーバーの中身：ツールは13個だった

READMEの該当節は明快だ。

15 tools across 5 permission tiers:

5階層の権限で15ツール、と書かれている。ところが同じ節の表を数えると、並んでいるのは13個しかない。

階層 ツール 実行条件
Schema list_connections list_schemas list_tables describe_table list_relationships get_sample_rows 有効な接続なら常時許可
Read query explain_query search_across_tables read_only 以上。SQLサニタイザが書き込み文を拒否
Write insert_rows update_rows delete_rows execute_write_query read_write のみ。承認が必要
DDL （将来のスキーマ移行ツール） —
Advanced （将来の管理ツール） —

6 + 3 + 4 = 13。残り2階層は README 自身が「(future schema migration tools)」「(future admin tools)」と書いている。実装側でも数えてみた。

grep -rhoE '"[a-z_]+"' macos/Services/MCP/ | tr -d '"' \
  | grep -E '^(list_|describe_|get_sample|query$|explain_|search_|insert_|update_|delete_|execute_)' \
  | sort -u | wc -l
# 13

実装でも13個だった。見出しの「15 tools」だけが実態から2つ多い。将来の2階層を数に含めたか、単に古い数字が残っているかのどちらかだろう。使えるツールは13個、と読み替えておけばよい。

MCPツールは5階層の権限で仕切られている。Schemaは6ツールでlist_tablesやdescribe_tableなど常時許可、Readは3ツールでqueryとexplain_queryとsearch_across_tables、Writeは4ツールでinsertとupdateとdeleteとexecute_write_query、DDLとAdvancedは0ツールでREADMEにfutureと明記。実装で数えたツール名は13個でREADMEの見出しは15 tools
階層ごとのツール名は README の表、総数は実装ファイルから数えた

ツール構成自体は素直だ。スキーマを読む6つが常時許可なのは理にかなっていて、エージェントがテーブル構造を把握するのに書き込み権限は要らない。list_relationships が独立しているのも効く——外部キーの関係が分からないとJOINの書きようがない。

権限の切り方も見ておきたい。接続ごとに3つのモードがある。

モード できること
locked MCPから一切触れない
read_only Schema 6ツール + Read 3ツール。SQLサニタイザが書き込み文を拒否
read_write 全13ツール。ただし書き込み系は利用者の承認が必要

この「モードによって見えるツールが変わる」構えは、Supabase MCPとは｜ホスト版とローカル版の違いと、read-onlyで消える10ツールを実測で測ったものと同じ考え方だ。あちらは read-only で10ツールが消えた。Gridex は13ツール中、Write の4つが read_write 専用になる。

接続単位で切れるのが実務的だ。本番は locked か read_only、ステージングだけ read_write、という分け方が素直にできる。エージェント側に渡すのは同じMCPサーバーなので、設定ミスの余地がツール側ではなく接続側に集約される。

search_across_tables が Read 階層にあるのは面白い。全文検索をツール1つで提供すると、エージェントは「どのテーブルに顧客名があるか」を試行錯誤せずに済む。ただし裏を返せば、1回の呼び出しで複数テーブルを横断して読めるということでもあるので、権限設計上は重い部類に入る。

防御層はREADMEより厚かった

エージェントにDBを渡す以上、こちらが本題になる。READMEが挙げているのは2つだけだ。

  • MCPPermissionEngine — per-connection mode (locked, read_only, read_write)
  • MCPSQLSanitizer — rejects DDL/DML that escape the declared tier

実際のディレクトリを見ると6本あった。

macos/Services/MCP/Security/
  MCPApprovalGate.swift
  MCPIdentifierValidator.swift
  MCPPermissionEngine.swift
  MCPRateLimiter.swift
  MCPRowCountEstimator.swift
  MCPSQLSanitizer.swift

READMEに出てこない4本がこれだ。

・MCPApprovalGate — 利用者の承認を取る関門
・MCPRowCountEstimator — 変更が及ぶ行数を見積もり、大量変更を検知する
・MCPIdentifierValidator — テーブル名・カラム名の妥当性を検証する
・MCPRateLimiter — 呼び出し頻度を制限する

エージェントのSQLは6つの層を通る。PermissionEngineがlockedとread_onlyとread_writeを判定し、SQLSanitizerが階層外のDDLとDMLを拒否し、RowCountEstimatorが大量変更を検知し、ApprovalGateが利用者の承認を要求する。ほかにIdentifierValidatorとRateLimiterがあり、READMEが挙げるのは2つだけで実装のほうが厚い
ファイル名から読み取った構成。各層の実際の挙動は当記事では未検証

MCPRowCountEstimator の存在が特に意味を持つ。UPDATE users SET ... に WHERE を付け忘れたとき、「何行が変わるか」を事前に見積もれれば止められる。エージェントがSQLを書くときの典型的な事故なので、ここを独立した層にしているのは実務を分かっている設計だ。

また MCPRateLimiter があるのは、エージェントが暴走したときの被害を時間で区切るという発想だろう。承認制だけだと、承認を連打させられる形の事故が残る。

ただしこれらはファイル名と README から読み取った構成であり、当記事では動作を確認していない。ビルドしていないので、read_only が本当に書き込みを止めるかも、承認が本当に要求されるかも検証していない。「層が用意されている」ことと「期待どおり効く」ことは別なので、本番接続を渡す前に自分で試す必要がある。

flowchart TD A["エージェントがツールを呼ぶ"] --> B["PermissionEngine
接続のモードを判定"] B -- "locked" --> X["拒否"] B -- "read_only / read_write" --> C["IdentifierValidator
テーブル名・カラム名"] C --> D["SQLSanitizer
階層外のDDL・DMLを拒否"] D --> E{"書き込み系か？"} E -- "いいえ" --> G["実行"] E -- "はい" --> F["RowCountEstimator
影響行数を見積もる"] F --> H["ApprovalGate
利用者の承認"] H --> G G --> I["監査ログに記録"]

「1つのアプリ」の中身は3つの別実装

ここは採用判断に効くので分けて書く。GitHubのリポジトリ画面から読み取れる情報と、実際の中身が食い違っている。

リポジトリの説明文はこうなっている。

A native macOS / windows / Linux database IDE built with Swift and AppKit. Connect to PostgreSQL, MySQL, SQLite, and Redis from a single app

一方、GitHubの言語表示は C++ だ。AppKit は macOS 専用のフレームワークなので、「Windows と Linux を AppKit で」というのは成り立たない。実際に数えた。

言語 ファイル数 行数
Swift 201 52,524
C++ 185 57,264
C/C++ ヘッダ（.h/.hpp） 236 17,422

そしてディレクトリが分かれている。

ディレクトリ ファイル数 中身
linux/ 267 C++ 実装
windows/ 252 C++ 実装
macos/ 214 Swift 実装

共通コードを3プラットフォームでビルドする構成ではなく、3つの独立したツリーが並んでいる。DBアダプタも別々に実装されていて、macOS は macos/Data/Adapters/ に7つ（ClickHouse・MSSQL・MongoDB・MySQL・PostgreSQL・Redis・SQLite）、Windows は windows/Gridex/ 配下に PostgreSQLAdapter.cpp などが直接置かれている。

リポジトリ画面から読むと言語はC++とだけ出て説明文はSwiftとAppKitで構築とあり対応DBは4種と書かれている。ファイルを数えるとSwift 52524行とC++ 57264行が併存しAppKitはmacOS実装だけの話でREADMEどおり7DB分のアダプタが存在する
GitHubの説明文は4DB、READMEは7DB。実装を数えるとREADMEのほうが正しかった

MCP関連も同様に分かれている（macOS 35ファイル・Linux 53・Windows 70）。つまり同じ機能を3回書いている。ネイティブの操作感を優先した設計判断だと読めるが、採用側から見れば次の意味を持つ。

・プラットフォームによって完成度が違いうる。機能が片方にしか入っていない時期が生まれる
・READMEのMCP節も「macOS (stdio)、Windows (stdio + HTTP)、Linux (stdio)」と対応トランスポートが揃っていないことを明記している
・バグ修正も3回必要になるので、修正の反映速度に差が出る

なお対応DBは GitHub の説明文が「PostgreSQL, MySQL, SQLite, and Redis」の4種と書いているのに対し、README は7種を挙げている。アダプタを数えると7つあり、READMEのほうが正しい。説明文が更新されずに残っているパターンだ。

ls macos/Data/Adapters/
# ClickHouse  MSSQL  MongoDB  MySQL  PostgreSQL  Redis  SQLite

ここまでで、リポジトリ画面から読み取れる3つの情報——言語（C++）・説明文（Swift and AppKit / 4DB）・ライセンス（Apache-2.0）——のうち、正確だったのはライセンスだけだった。GitHubの表層は、更新されないメタデータと自動判定の組み合わせでできているので、採用判断の材料としては弱い。前回当サイトで7本のOSSのライセンス実体を読んだときと同じ構図が、今度は言語と説明文の側で起きている。

ドライバは全部Swiftネイティブで書かれている

MCPから離れて、SQLクライアントとしての足回りも見ておく。READMEの ## Driver Highlights に接続方式が並んでいて、ここが素直に珍しい。

DB ドライバ 方式
PostgreSQL PostgresNIO Swift（vapor系）
MySQL MySQLNIO Swift（vapor系）
Redis RediStack Swift（swift-server系）
MongoDB MongoKitten Swift
SQL Server CosmoSQLClient Swift・TDS 7.4 を直接実装（FreeTDS不要）
ClickHouse 自前 Pure Swift（URLSession で HTTP/HTTPS）
SQLite システムの libsqlite3 C ライブラリ

SQLite を除けばすべてSwift実装のドライバで、libpq も FreeTDS も使っていない。SQL Server で FreeTDS を避けているのは特に効く——あれは導入でつまずきやすい依存の代表格だ。ClickHouse に至っては HTTP インターフェースを自分で叩いていて、system.* のイントロスペクションと「CH 20.8+ のバージョン差を吸収する fallback」まで書かれている。

ネイティブ依存が少ないぶん配布が軽く、環境差でのトラブルが減る。一方で、Swiftドライバの成熟度にそのまま乗ることにもなる。奇妙な型や新しいサーバ機能で詰まったとき、逃げ道が少ない構成ではある。

接続まわりでは2つ押さえておきたい。

・SSHトンネル：swift-nio-ssh によるローカルポートフォワード。パスワード・秘密鍵・パスフレーズ付き鍵に対応し、SSHTunnelService という actor が接続ごとに1本張って切断時に畳む
・mTLS（Teleport-style）：sslKeyPath + sslCertPath + sslCACertPath の3点セットで相互TLS。PostgreSQL・MySQL・Redis・ClickHouse で end-to-end に効くとあり、ClickHouse は PKCS#12 のクライアントバンドルも受ける

Teleport が発行した証明書をそのまま置けば繋がる、という書き方をしている。踏み台とmTLSが前提の環境でDBクライアントを選ぶとき、ここが対応していないと話が始まらないので、明示されているのは助かる。

バックアップも7DBそれぞれに実装がある。PostgreSQL は pg_dump/pg_restore、MySQL は mysqldump を呼ぶ一方、MongoDB（NDJSON）・Redis（SCANによるJSONスナップショット）・ClickHouse（SHOW CREATE TABLE + FORMAT Values）は Pure Swiftで自前実装されている。外部CLIに依存する形式だけ、選択的なテーブル指定・圧縮・進捗表示が付く。

移行まわりでは、TablePlus・Navicat・DataGrip・DBeaver からの接続インポートに対応している。Navicat については「NCX with Blowfish decrypt」と書かれていて、暗号化された接続ファイルを復号して取り込む実装が入っている。既存のSQLクライアントから乗り換えるときの摩擦を、かなり意識している作りだ。

MCP以外の機能も一通り揃っている

READMEの見出しを数えると、機能節は MCP Server・ER Diagram・AI Chat・Editor & Grid・SSH Tunnel・mTLS・Backup & Restore・Import の8つある。MCPが目玉として置かれているが、土台のDBクライアントとしても一通り埋まっている構成だ。

ER図の自動生成（assets/diagram.png がリポジトリにある）は、エージェントに渡す前段として地味に効く。list_relationships というMCPツールが独立している話と同じで、テーブル間の関係を把握する手段を人にもエージェントにも用意している、という一貫性がある。

ツール数13という規模感も押さえておきたい。Notion MCPとは｜ホスト版とローカル版の違いを24ツール・21,831トークン実測で解説で測ったNotionのホスト版が24ツールだったので、Gridexはその半分強にあたる。MCPのツール定義はエージェントの文脈に常駐するので、少ないほど他のツールと併用しやすい。なお当該記事の21,831トークンは cl100k_base 近似での実測値で、本記事ではGridexのツール定義のトークン数は測っていない（MCPサーバーに接続していないため）。

逆に言えば、MCPだけが欲しいなら重いかもしれない。DBごとのMCPサーバーは単体のOSSとしても存在するので、GUIを使わないならそちらのほうが軽い。GridexのMCPが効くのは「普段このアプリでDBを触っていて、同じ接続設定をそのままエージェントにも使わせたい」という場合だろう。接続情報を二重管理しなくて済むのが実利になる。

開発にコーディングエージェントが入っている

細かい観察だが、このリポジトリ自体がエージェント前提で回っている形跡がある。

.claude/settings.local.json
CLAUDE.md          （75行）

直近のマージコミットのブランチ名も gridex/codex/verify-pr89-conflict-resolution だった。Claude Code と Codex の両方の痕跡がある。

MCPサーバーを内蔵するツールが、自分自身の開発にもエージェントを使っている——という循環は、今の開発現場を素直に反映している。採用判断に直結する話ではないが、この種のツールがどういう前提で作られているかを示す材料にはなる。

ただし .claude/settings.local.json は本来ローカル設定でコミット対象外にすることが多いファイルなので、意図的に共有しているのか、単に .gitignore の漏れなのかは分からない。中身は確認していない。

AIチャットは3プロバイダ、Ollamaがある

MCPサーバーとは別に、アプリ内にAIチャットがある。プロバイダの実装はここだ。

macos/Services/AI/Providers/
  AnthropicProvider.swift
  OpenAIProvider.swift
  OllamaProvider.swift

プロバイダの切り替えは ProviderFactory.swift と ProviderRegistry.swift が担っていて、registry に登録する形になっている。実装が3つに閉じているわけではなく、追加しやすい構造になっているということだ。

Ollama があるのが実務的に大きい。DBツールのAIチャットには、テーブル構造やサンプル行が文脈として渡る。スキーマ名やカラム名は、それ自体が事業の設計情報だ。ローカルモデルで完結させられる選択肢があるかどうかは、社内で使えるかの分かれ目になる。

認証まわりにはもう一段ある。

macos/Services/AI/Auth/
  ChatGPTOAuthService.swift
  ChatGPTOAuthLoopbackServer.swift
  ChatGPTOAuthConstants.swift
  PKCE.swift
  JWTDecoder.swift

APIキーを貼る代わりに、ChatGPT のサブスクリプションでログインする経路が実装されている。PKCE とループバックサーバを使う、CLIツールでよく見る形だ。APIキーの発行・管理を利用者にさせずに済むので、GUI アプリとしては正しい選択に見える。

データベース MCPサーバーとして入れるかの判断材料

向いている場面

・複数種類のDBを日常的に行き来する人。7種を1つのアプリで扱える
・エージェントにDBを触らせたいが、権限を細かく切りたい場合。接続ごとに locked / read_only / read_write を設定できる
・スキーマを外部APIに出したくない場合。AIチャットは Ollama で完結させられる
・ネイティブアプリの操作感を重視する場合（Electron 系との最大の違い）

慎重に見るべき点

・3実装が並立しているため、プラットフォーム間で機能差が出うる。MCPのトランスポートも揃っていない
・最終コミットが 2026-09-07 で、約1か月更新がない
・GitHubの説明文が古い（4DB表記、AppKitでクロスプラットフォーム）ので、READMEと実装を見る必要がある
・MCPの防御層は用意されているが、効き方は自分で検証すべき

当記事で測っていないこと

・ビルドも実行もしていない。Swift/C++ のネイティブGUIアプリで、当環境にはビルド環境もディスプレイもない
・したがって MCPサーバーに接続していない。13ツールは実装から数えたツール名であり、tools/list を取った数ではない
・6つのセキュリティ層が期待どおり動くかは未検証。read_only で書き込みが止まるか、承認が要求されるかを確かめていない
・AIチャットも未起動。3プロバイダはファイルの存在で確認しただけ
・7種のDBへの実接続も行っていない
・.claude/settings.local.json の中身は確認していない
・Linux / Windows 実装のMCPツールが macOS と同じ13個かは数えていない（macOS の実装のみ計数）

つまり本記事が確かめたのは「何が実装されているか」であって「それが正しく動くか」ではない。前者だけでも、公称値との差（ツール数は2つ少なく、防御層は4つ多い）は拾えた。

検証するならどこからも書いておく。実際に導入するなら、順番はこうなるはずだ。

  1. ダミーのDBに read_only で接続を作り、MCPクライアントから tools/list を取って13ツールであることを確認する
  2. その接続に対して execute_write_query を呼び、MCPSQLSanitizer が実際に拒否するかを見る
  3. read_write に切り替え、WHERE なしの UPDATE で MCPRowCountEstimator と MCPApprovalGate が止めるかを見る
  4. 監査ログに全部残っているかを確認する

ここまで通ってから本番の接続を登録する、という順序が安全だろう。防御層があること自体は実装で確認できたので、確かめるべき問いが「あるかどうか」から「効くかどうか」に移っているのが、現時点で言えることになる。

参照ソース

・gridex/gridex（⭐1,619・Apache-2.0・タグ26本、2026-10-04時点）
・Gridex LICENSE（実体ファイルで Apache License 2.0 を確認）
・Gridex 公式サイト

本記事の計測レコードは data/measurements/runs/2026-10-04-gridex-db-ide.json に登録した。