⏱ 読了目安: 約4分
- Claude CodeとMCPを連携させ、業務DBを安全に参照するアーキテクチャを構築する手法を解説。
- SQLiteのURIモードによる物理的な読み取り制限と、業務操作単位でのツール公開により権限を最小化。
- AIに自由なSQLを許さず、必要なデータのみを抽出する設計で、セキュリティリスクを根本から排除する。
AIに「全権」を渡すリスクと設計思想
深夜の障害対応で、焦りながらSQLを叩いた経験があるエンジニアなら、誰しも一度は「誤ってDELETE文を実行してしまったらどうしよう」という冷や汗をかいたことがあるはずだ。AIに業務DBへのアクセス権を与える際、我々が直面するのはまさにこの恐怖である。多くの開発者が陥りがちな罠は、AIの利便性を優先するあまり、execute_sqlのような万能ツールを安易に公開してしまうことだ。しかし、これは「AIにデータベースの鍵をすべて渡す」に等しい行為であり、プロのエンジニアとしては到底許容できない設計である。
今回紹介するアプローチは、Model Context Protocol（MCP）を単なる接続手段としてではなく、セキュリティの境界線として定義し直すことだ。具体的には、SQLiteの接続文字列に?mode=roを指定することで、OSレベルで書き込みを物理的に遮断する。これは「AIが書き込まないようにプロンプトで指示する」という脆弱な対策とは次元が異なる。仕組みとして書き込めない環境を構築することで、万が一AIがハルシネーションを起こして破壊的なSQLを生成したとしても、システムは堅牢に守られる。
さらに重要なのは、DBのテーブル構造をそのままAIに露出させないという判断だ。get_tableのような汎用的なツールは、テーブルのスキーマ変更が即座にAIの挙動に影響を与えるという疎結合の原則に反する。我々が実装すべきは、get_customerやlist_open_tasksといった、業務上の「意図」を反映したインターフェースである。これにより、DBの物理構造とAIの対話層を分離し、将来的な保守性を劇的に向上させることができる。これは単なるセキュリティ対策ではなく、長期的なシステム運用を見据えたアーキテクチャの最適化なのだ。
MCPサーバー実装と安全な境界設計
実装において最も注意すべきは、AIとの対話における「情報の粒度」である。今回構築するMCPサーバーでは、Pythonのmcpライブラリ（バージョン2.2.0）を使用し、stdio経由でClaude Codeと通信を行う。ここで重要なのは、SQLのプレースホルダー活用によるインジェクション対策だけではない。取得件数に上限（limit）を設け、意図しない大量データ取得によるメモリ枯渇や情報漏洩を防ぐという、防御的プログラミングの基本を徹底することだ。
以下に、本稿で推奨する安全なMCPサーバーの構成要素を整理する。
| 項目 | 対策内容 |
|---|---|
| DB接続 | SQLite URIモード（mode=ro）による物理的読み取り専用化 |
| ツール公開 | 汎用SQL実行ではなく、業務単位の関数（get_customer等）のみ公開 |
| データ制御 | 取得件数の上限設定（limit）と不要なカラムの除外 |
| インターフェース | テーブル構造を隠蔽し、業務ロジックをAPIとして定義 |
この設計において、プロンプトはあくまで「行動方針」であり、権限管理の代わりにはなり得ない。多くのエンジニアが「AIに指示すれば大丈夫」と錯覚しがちだが、それはデッドロックを「気合で回避する」と言っているのに等しい。システム側で制約を課すことこそが、真のエンジニアリングである。また、本番環境への展開を考慮する場合、SQLiteのローカル接続からPostgreSQL等のリモートDBへ移行する際は、MCP専用のDBユーザーを作成し、必要なビューのみを参照させるという「最小権限の原則」を徹底しなければならない。これは、AIが社内システムに深く浸透するこれからの時代において、我々が避けては通れない必須の作法である。
AI時代のエンジニアが問われる境界線
最後に、我々エンジニアが自問すべきは「AIにどこまでを任せ、どこからを人間が制御すべきか」という境界線の引き方である。AIは確かに強力なツールだが、それはあくまで「下ごしらえ」を行う存在に過ぎない。最終的な意思決定や、データの整合性に対する責任は、依然として我々エンジニアにある。MCPというプロトコルは、AIと業務データを接続する単なるパイプラインではない。それは、AIという「予測不能なエージェント」に対して、我々が定義した「安全な砂場」を提示するための強力なフレームワークなのだ。
明日からあなたが取るべきアクションは明確だ。まずは手元の業務DB接続を見直し、読み取り専用のユーザーや接続設定が適切に機能しているかを確認すること。そして、AIに公開しているツールが「汎用的なSQL実行」になっていないか、業務単位の小さなAPIに分解できないかを検討してほしい。もし、あなたが「AIが便利だから」という理由だけで、無防備なDB接続を放置しているなら、それは技術的負債を積み上げているのと同じである。AIの進化速度に翻弄されるのではなく、AIを制御するための「境界」をコードで定義する。それこそが、これからの時代に求められるシニアエンジニアの矜持ではないだろうか。あなたは、AIに渡す「鍵」を、本当に適切に管理できているだろうか？
コメント