text-to-SQL は、AI とデータベースを巡る議論をまるごと飲み込んでしまいました。それも当然で、エージェントに自然言語から正しい SQL を生成させるのは本当に難しい問題です。しかし、それは話の半分にすぎません。そして正直に言えば、誰もが安心して語れるのはその半分の方です。
その問題が解決されたとしましょう。あなたのエージェントは丁寧にキュレートされたセマンティック層を持ち、一貫して正確な SQL を書くとします。ここで誰も問わない問いがあります。そのエージェントは、見るべきデータだけを見ているのか？
カスタマーサポートのエージェントが「ユーザー #123 の請求詳細を見せて」と尋ねられたとします。users、billing、payments を結合する正しい SQL を生成しますが、結果には users テーブルのマスクされていない SSN が含まれて返ってきます。クエリは完璧でした。それでもデータ漏洩は起きてしまったのです。
正しい SQL を生成することと、データアクセスをガバナンスすることは別々の問題です。なのに、人はこの 2 つを混同し続けています。
| 問題 1: 正確さ | 問題 2: ガバナンス | |
|---|---|---|
| 問い | SQL は正しいか？ | エージェントはこのデータを見てよいか？ |
| 領域 | AI / Text-to-SQL | セキュリティ / アクセス制御 |
| 失敗の形 | 誤ったクエリ結果 | 正しい結果と一緒にデータ漏洩 |
| 例 | SELECT * FROM uesrs (タイポ) | エージェントが users テーブルのアンマスクの SSN を返す |
端的に言えば、ガバナンス無しでは、正しい SQL はそのまま責任の温床になります。text-to-SQL が上手くなるほど、あなたはより危険にさらされるのです。
基礎は変わらない
最初の主張で、これは簡単な方です。エージェントは、あなたのデータベースを叩くもう 1 つの主体にすぎません。クエリを実行するどんな人間とも同じ統制を必要とします。
AI エージェントのアクセス制御
最小権限。エージェントが実際に必要とする DB、スキーマ、テーブルだけにスコープする。営業分析のエージェントが hr.payroll に触る用事はありません。
データマスキング
機微なカラム（SSN、クレジットカード、医療記録）は、結果がエージェントに届く前にマスクされるべきです。人のアナリストが ***-**-1234 を見るなら、エージェントも同じものを見るべきです。相手がロボットだからといって例外はありません。
監査ログ
すべてのクエリを記録する。何が、いつ、どのエージェントによって、どのユーザーの代行で実行されたか。何かがおかしくなったとき（そして必ずおかしくなります）、追跡を可能にするのは監査証跡だけです。監査人に手渡すのも、これです。
AI エージェントによるデータベースアクセスを監査したいなら、ログはデータベースセッションが持つ以上のものを運ばなければなりません。5 つの項目がなければ監査とは呼べません。エージェントの ID、代行された人間、クエリを引き起こしたツール呼び出し、実行された文、そして時刻です。データベース側のログが与えてくれるのは最後の 2 つだけです。最初の 3 つは、エージェントが接続する層にしか存在しません。
つまり原則そのものは古い話です。新しいのは被害範囲（ブラストレディウス）です。構成を誤ったエージェントは数秒で、人が午後いっぱいかけても出せないほどのデータを持ち出せます。しかも疲れることも、罪悪感を覚えることもありません。
エージェントで本当に違うこと
原則は同じ、運用モデルが違う。面白いのはここからです。
エージェントは短命
エージェントは立ち上がり、1 つのタスクを実行し、消えます。多くの場合は数秒のうちに。長命な DB アカウントを払い出して、それを何ヶ月も放置しておくのは、まったく形が合っていません。エージェントが欲しいのは、単一のタスクにスコープされ、そのタスクが終わった瞬間に取り消される資格情報です。
各エージェントには独自の ID が必要
複数のエージェントに 1 つの DB ユーザーを共有させた瞬間、あなたは可視性を捨てたことになります。あのクエリを実行したのは誰か？ あるエージェントです。どれか？ 分かりません。各エージェントタイプは、独自のアクセスポリシーを持つ別個の ID を担うべきです。さもなければ、アクセス制御も監査ログもただの見せかけです。
Just-in-Time は機能であることをやめ、デフォルトになる
人のユーザーにとって、Just-in-Time (JIT) の DB アクセスは、人を説得してようやく採用してもらうベストプラクティスです。エージェントにとっては、それが単に仕事の自然な形です。立ち上がり、クエリし、結果を返し、終わり。タスクの前にも後にもアクセスを保持する理由がありません。エージェントでは、JIT は売り込むべきセキュリティのアップグレードから、誰も意識する必要のないデフォルトのアーキテクチャへと変わります。
Bytebase はどう扱うか
Bytebase では、エージェントを特別扱いの後付けではなく、一級の主体として扱います。1 つの統一ガバナンス層が、PostgreSQL、MySQL、SQL Server、Oracle、Snowflake、BigQuery、その他の前面に座ります。何台動かしていようと、すべてのインスタンスに対する単一のエンドポイントであり、データがそこに留まらなければならないなら、あなたのネットワークの内側でセルフホストで動きます。
これが AI エージェントのガバナンスされたデータアクセスの実際の姿であり、あなたの人間がすでに通っているのと同じ仕組みです。
- DB、スキーマ、テーブル単位の細粒度アクセス制御
- カラム単位で適用される動的データマスキング
- タスクごとに権限を付与・取り消しする Just-in-Time アクセス
- エージェントとユーザーの完全な帰属つき監査ログ
そしてエージェント ID は、その場しのぎではなく組み込みです。Bytebase はサービスアカウントとワークロード ID をサポートし、各エージェントが独自のアクセスポリシーの下で動きます。Bytebase MCP サーバー経由で接続するか、API を直接叩いて、ガバナンスを最初から織り込んだ独自のエージェンティックなワークフローを構築できます。
text-to-SQL を出荷する競争は、たいてい最もきれいなクエリを生成した者が勝ちます。しかし本当に重要な競争は、まだ誰も走っていない競争です。あなたのエージェントがあの完璧なクエリを生成したとき、それが何を見てよいのかを、あなたは正確に把握していますか？
シリーズの他の記事
- データベース MCP サーバーとは？ - 基礎編：データベース MCP サーバーとは何か、そして生のサーバーがローカルでは問題なくても本番環境で牙をむく理由。
- ガバナンスされた MCP と生の MCP - エージェントのデータベースアクセスがガバナンスされるか野放しになるか、それが決まる唯一の場所が MCP サーバー。
- Schema as Code から Schema as Context へ - エージェントが正しく振る舞うために必要な分類・オーナーシップ・ポリシーを与える。
- エージェントがマイグレーションを書いたとき、誰が承認するのか？ - 書き込みパス：エージェントが作成するスキーマおよびデータの変更をガバナンスする。