社内データベースをAIエージェント（自律的にタスクを遂行するAIプログラム）に接続する案件が増えています。営業データや人事データを持つテーブル群に対して、自然言語で質問すると回答が返ってくる仕組みです。
ただし導入時には必ず「このユーザーはこのテーブルを読んでよいか」という権限制御の壁にぶつかります。エージェントに繋いだ途端、本来閲覧禁止のはずの給与テーブルの中身が回答に混ざってしまうケースが典型例です。この記事では、スキーマ（データベースの表構造の定義情報）とアクセス権限をAIエージェントにどう渡すかを検討している開発者・PM向けに、選定の判断軸を整理します。
どんな場面でこの判断が必要になるか
LLM（大規模言語モデル）にSQLを書かせる仕組みを作ると、まず全テーブルのDDL（データ定義言語、テーブル構造を記述したSQL文）をプロンプトに丸ごと渡す実装になりがちです。
テーブル数が数十を超えるエンタープライズDBでは、これがそのままコストとリスクに直結します。42テーブルのスキーマ全体をプロンプトに含めると平均2,583トークンかかるのに対し、質問内容に応じて必要なテーブルだけ選ぶ方式（スキーマゲーティングと呼ばれる手法）なら631トークン程度に収まったという計測例があります。約75%の削減です。
さらに深刻なのは、人事や経理など「呼び出し元のロールによっては見せてはいけないテーブル」が紛れ込むリスクです。この2つの課題、つまりトークンコストの圧縮と行・テーブル単位のアクセス制御を、どの実装方式で解決するかが検討ポイントになります。
判断軸1: 導入コストをどこまで許容できるか
一つ目の軸は、既存システムへの組み込みにどれだけ工数を割けるかです。
PythonライブラリとしてインポートしてCatalogオブジェクトを組み立てる方式は、柔軟性は高い反面、既存のエージェント基盤への統合作業が発生します。ロールの定義、DBへの接続設定、選択結果をプロンプトに差し込む処理まで、すべて自前で書く必要があります。
一方でCLI（コマンドラインインターフェース）から使う方式なら、pip install schemagateのあとschemagate demoのようなコマンドを叩くだけで、質問に対して必要なテーブルだけが選ばれた結果を確認できます。すでにエージェントを運用中のチームであれば、まずCLIで挙動を試してから統合方式を決める、という段階的な検証がしやすくなります。
判断軸2: 誰が権限設定を確認・検証するか
二つ目の軸は、権限設定の正しさを誰がどうレビューするかです。
ログに出力されたSQLやトークン数だけを見ていても、「なぜこのテーブルが除外されたか」は分かりません。ロール設定を変更した際に、意図通り絞り込まれているかを目で確認できる画面があるかどうかは、運用フェーズで効いてきます。
ローカルで起動するダッシュボード型の確認画面（スキーマゲーティングでは「Studio」と呼ばれる機能）では、質問を入力しながらロールを切り替え、除外されたオブジェクトの一覧とDDLへの反映結果を並べて見られます。権限設計をエンジニア以外のセキュリティ担当者やPMがレビューする場面では、こうした可視化の有無が採用の分かれ目になります。
判断軸3: 接続先クライアントがMCPに対応しているか
三つ目の軸は、既存のAIクライアントやIDE連携がMCP（Model Context Protocol、AIモデルと外部ツール・データソースを接続するための標準規格）に対応しているかどうかです。
MCP対応クライアントであれば、サーバー側にツールを立てておくだけで、クライアント側からはselect_schemaやlist_objectsのようなツール呼び出しとして扱えます。呼び出し時にprincipal（呼び出し元の識別子）やrolesを渡さなければ匿名扱いとなり、制限のかからないオブジェクトしか見えない設計です。
注意したいのは、存在しないオブジェクトへのアクセスと、権限がなく閲覧できないオブジェクトへのアクセスが、同じエラーとして返る点です。これはエラーメッセージからテーブルの存在自体を推測されないようにするための設計であり、セキュリティ要件が厳しい業務システムでは評価ポイントになります。既存の開発基盤がMCP非対応なら、この軸は今回は保留にして、CLIやライブラリ方式から着手する判断も妥当です。
判断軸4: DB障害時にエージェントを止めてよいか
四つ目の軸は可用性です。基幹DBが一時的に落ちたとき、AIエージェントの応答も一緒に止まってよいかどうかを事前に決めておく必要があります。
スキーマの索引をメモリ上に保持し、起動後にDBへの接続が切れても最後に取得できた構造情報から回答を続ける実装であれば、DB障害とエージェント障害を切り離せます。逆にリクエストのたびにDBへスキーマ問い合わせをかける実装だと、DB側の障害がそのままエージェントの障害に直結します。SREやインフラ担当がいるチームであれば、この耐障害設計の有無を事前に確認しておくべきです。
選択肢の比較
| 方式 | 導入コスト | 権限の可視化 | 向いている場面 |
|---|---|---|---|
| ライブラリ組み込み | 高い（コード改修必須） | 自前実装次第 | 既存エージェント基盤に深く統合したい場合 |
| CLI | 低い（コマンド実行のみ） | 標準出力で確認可能 | まず挙動を検証したい・PoC段階 |
| ダッシュボード確認画面 | 低い（ローカル起動） | 画面で可視化される | 権限設計をレビューしたい場合 |
| MCPサーバー | 中（クライアント対応が前提） | ツール呼び出し単位で制御 | MCP対応クライアントを使っている場合 |
ケース別の推奨
- 既にAIエージェントが稼働していて「見せてはいけないテーブルが見えている」不具合報告が来ている場合は、まずCLIで自分たちのDDLを流し込み、対象テーブルが絞られるかを確認するのが早道です
- ロール設計をセキュリティ担当や監査部門にレビューしてもらう必要がある場合は、ダッシュボード確認画面を使い、ロールごとの除外リストをスクリーンショットで残せる運用にするとレビューが進めやすくなります
- Claude Desktopや対応IDEなどMCPクライアントを既に使っている場合は、MCPサーバー方式を検討する価値があります。ただし
principalとrolesの受け渡し設計は事前にドキュメントで仕様を確認してください
- 基幹DBの可用性要件が厳しく、DB障害時にもエージェントの応答を止めたくない場合は、索引をメモリ保持する実装かどうかを公式ドキュメントやソースコードで確認してから採用を決めるべきです
あえて見送るべき条件
対象のテーブル数が数個程度で、そもそも全スキーマをプロンプトに渡してもトークンコストが問題にならない規模なら、この種の仕組みを導入する優先度は低いといえます。
また、権限管理の要件がすでにDB側のRLS（行レベルセキュリティ）やビュー分離で十分にカバーされている場合、AIエージェント側で二重に権限制御を実装するとかえって管理対象が増えます。既存のDBアクセス制御と役割が重複していないか、導入前に整理しておくとよいでしょう。
エージェント自体をまだ本番投入していない、PoC段階以前のプロジェクトであれば、権限設計の検討は後回しにして、まずエージェントの回答精度そのものを検証するほうが優先度は高いはずです。
まとめ
AIエージェントにDBスキーマとアクセス権限を渡す際は、導入コスト・権限の可視化・クライアントの対応状況・DB障害時の耐性という4つの軸で自分たちのプロジェクトを当てはめて考えるとよさそうです。
まず試せる一歩としては、CLIツールを手元のスキーマに向けて実行し、想定通りにテーブルが絞り込まれるか、権限のないテーブルが本当に除外されるかを目視で確認することです。そこで問題が見えなければ、ダッシュボードやMCP統合へ段階的に広げていく進め方が現実的です。