MCPのセキュリティ：ClaudeやCursorにデータベースへの直接アクセスを渡すべきか？

2026年に一般的になりつつあるシナリオから始めます。あなたはClaudeやCursorでアプリを書いてきました。誰か（おそらく私が、以前の記事で）MCP経由でAIをデータベースに接続し、実際のデータについて質問に答えさせたり、ビューを設定させたり、スキーマを管理させたりすることを提案します。本当に便利です——私は毎日使っています。しかしAIアシスタントを本番データベースに配線する前に、デフォルトではなく意図的に答えるべき質問があります。

あなたは実際に何を、誰に許可しているのか？

正直な答えは、「MCPデータベースアクセス」はひとつのものではないということです。「開発用データベースへの無害な読み取り専用探索」から「サードパーティのインフラを流れる本番データベースの認証情報」までのスペクトラムです。あなたの構成のセキュリティ態勢は3つの変数に依存し、何かを接続する前にその3つすべてを言えるべきです。

変数1：AIの接続は実際にどこに住んでいるか？

これは最大の決定であり、オプションが外から見ると同じに見えるため、多くの人が間違えるところでもあります。

直接接続（認証情報はMCP設定の中）。 最も一般的な構成です。設定ファイル——claude_desktop_config.jsonや.cursor/mcp.json——に保存した接続文字列でデータベースに直接接続するMCPサーバープロセスを実行します。AIがツールを呼ぶと、サーバーがクエリを実行します。接続はローカルですが、データベースの認証情報は平文の設定ファイルに置かれ、MCPサーバープロセス自体は動いている間、データベースへの開かれた特権接続を保持します。そのプロセスが侵害されたり——あるいはAIが破壊的なツール呼び出しに誘導されたり——すれば、AIとデータの間に何もありません。

クラウドリレー（認証情報は彼らのサーバー上）。 「データベースをChatGPT/Claudeに接続」するサービスの中には、まったくローカルで実行しないものがあります。Webダッシュボードで接続情報を渡し、彼らが自社インフラからデータベースに接続し、AIクライアントは彼らのクラウドサービスと話します。これで認証情報もデータ*も他人のサーバー上にあります。両方の世界の最悪の部分であり、最も正当化が難しいものです。

ローカルアプリ＋管理されたMCPサーバー（認証情報はマシンから出ない）。 私がBasevoltを構築する際の軸にした構成です。デスクトップアプリがデータベース接続を保持し、localhost上にMCPサーバーを公開して、AIクライアントが接続します。AIは認証情報を見ません——ローカルのアプリと話し、アプリがデータベースと話します。認証情報ファイルの問題は消え、アクセスを実際に制御できるレイヤーが得られます。

経験則はこうです。AIがデータベースの認証情報を保持すべきではなく、認証情報がマシンから出るべきでもありません。 どちらかが自分の構成で真なら、あなたはスペクトラムの危険な側にいます。

変数2：AIは実際に何ができるか？

「MCPデータベースアクセス」は「SELECTクエリを実行する」から「テーブルを削除する」まで何でも意味し得ます。AIができることの範囲は、気づいているかどうかにかかわらず、あなたが下しているセキュリティ上の決定です。問うべき質問はこれです。この構成が最悪で何をできるか、そしてそれを止める制御があるか？

重要度の高い順に、制御手段は次の通りです。

読み取り専用モード。 MCPサーバーが対応していれば、これが単一で最も価値の高い制御です。AIはクエリとスキーマの説明はできますが、書き込み、変更、削除はできません。本番データベースにとって、これは「AIをアナリストとして使う」と「AIに装填済みの銃を持たせる」の違いです。実際のデータがあるものにアシスタントを接続するなら、読み取り専用から始めましょう。

特定のデータソースやテーブルへの限定。 おそらく複数のデータベースを接続しています——本番とスクラッチ、あるいは複数のプロジェクト。AIが触れるものを選べるということは、ある場所でのミスがすべてに波及しないということです。

直接SQL実行なし。 一部のMCP構成は、生のSQLではなく構造化された操作を公開します——「ビューを作成」「フィールド型を設定」「テーブルを一覧」——「この任意のクエリ文字列を実行」ではなく。これは意味のある安全性の改善です。AIは思いつくものを何でも実行できなくても、役に立つことはできます。

アクセス失効。 AIのアクセスを即座に遮断する能力——アプリを閉じる、ベースを切断する、サーバーをオフにする——は思う以上に重要です。ローカルアプリならボタンひとつ。クラウドリレーなら、彼らの管理パネルと彼らのタイミングに頼ることになります。

変数3：AIがデータを読むとき、データはどこへ行くか？

ここが人々が忘れる部分です。完全にローカルな構成でも、AIがあなたのデータについての質問に答えるとき、クエリの結果はAIプロバイダーに送られます——それによってAIはデータを読んで応答できるのです。これはこれらのツールの仕組みの基本であり、モデルはデータを見なければそれについて話せません。

だから本当の質問は「データはマシンから出るのか？」ではありません——どのAIアシスタントでも、あなたが質問したデータはモデルに行きます。質問はこうです。あなたは何のデータを質問していて、それをそこに送る権利があるのか？ 合成データを使ったローカル開発データベースを探索しているなら、問題はありません。顧客PIIがある本番データベースにアシスタントを接続しているなら、そのデータを第三者のモデルインフラに送っていることになります——それは自社のポリシーでは問題ないかもしれませんし、GDPRや契約上のコンプライアンス問題かもしれません。接続する前にどちらにいるのかを知りましょう。後ではなく。

実際にお勧めする構成

原則だけでなく、具体的な姿勢を示します。これは私が自分のプロジェクトで実行している構成です。

ローカルアプリ（またはローカルMCPサーバー）が接続を保持——クラウドリレーは決して使わず、認証情報をAIクライアントの設定ファイルに置くことも決してしない。
本番データベースは読み取り専用から始める。 AIに書き込ませたいなら、まずステージングかスクラッチのコピーに向ける。「間違ったテーブルの列名を変更してしまう親切なエージェント」の話は仮説ではありません。
AIを必要なベースに限定する。 MCPサーバーが公開するデータソースを選べるなら、最小限を公開する。
質問したものはすべてモデルに行くと仮定する。 だから、第三者に送るべきでないデータについてアシスタントに質問しない。これが人を捕まえるルールです。アーキテクチャは問題なく、データが問題なのです。

最後の点は強調に値します。なぜなら、ほとんどの「MCPセキュリティ」の議論はここで静かに終わるからです。プロトコルはローカルで、認証情報は安全で、それでも正しい質問をするだけで顧客データを漏らし得ます。MCPデータベースアクセスの安全性は、アーキテクチャ3割、判断1割——そしてその判断はあなたのものです。

接続前に問うべき質問

MCPデータベースアクセスを配線しようとしているなら、これを確認してください。

認証情報はどこにある？ 答えが「AIクライアントの設定ファイル」や「リレーのサーバー」なら、まずそこを直す。
AIが実行し得る最悪のクエリは？ 答えが「すべて削除」なら、進む前に読み取り専用モードか限定データベースが必要。
何のデータを質問するつもりか？ その一部が顧客データなら、モデルプロバイダーに送ることについて自社ポリシーが何と言っているか確認する。
どうやってアクセスを失効させる？ 即時かつローカルでなければ、それはギャップです。

これらは珍しい質問ではありません——データベースに触れ得るあらゆる統合について問うのと同じ質問です。MCPとの違いは表面が大きいことです。AIアシスタントはcronジョブより能力が高く、創造的で、予測が難しい。だからこそ、意図的に考える価値があるのです。

結局どこに落ち着くか

MCPデータベースアクセスは、AIツールの波から生まれた最も有用なものの一つです。私は毎日使っており、ローカルでの設定やアーキテクチャオプションの比較についても書いてきました。しかし「有用」と「安全」は同じではなく、その間のギャップはあなたの責任です。

良い知らせは、安全なバージョンは危険なバージョンより難しくないということです。自分のアプリが認証情報を保持するローカルMCPサーバー、重要なものはすべて読み取り専用、必要なデータベースに限定、そして毎回の会話の前に「このデータをモデルに送ってもいいか？」と問う習慣——この構成で、価値の大部分をリスクほぼゼロで得られます。危険なバージョンとは、ファイアウォールの設定を間違えたものではなく、能力の高いAIを本番データベースに接続し、これらの質問を一度もしなかったものです。