text-to-SQL は AI とデータベースを巡る議論の主役でした。自然言語から AI エージェントに正しい SQL を生成させるのは難しい問題です。しかし、それは話の半分でしかありません。
その問題が解決されたとしましょう: AI エージェントは丁寧にキュレートされたセマンティック層を持ち、一貫して正確な SQL を作るとします。それでも、そのエージェントは見るべきデータだけを見ているか？
カスタマーサポートのエージェントが「ユーザー #123 の請求詳細を見せて」と尋ねられたとします。users、billing、payments を結合する正しい SQL を生成しますが、結果には users テーブルのマスクされていない SSN が含まれます。SQL は正確でした。それでもデータ漏洩は起きました。
正しい SQL を生成することと、データアクセスをガバナンスすることは別の問題です。
| 問題 1: 正確さ | 問題 2: ガバナンス | |
|---|---|---|
| 問い | SQL は正しいか？ | エージェントはこのデータを見てよいか？ |
| 領域 | AI / Text-to-SQL | セキュリティ / アクセス制御 |
| 失敗の形 | 誤ったクエリ結果 | 正しい結果と一緒にデータ漏洩 |
| 例 | SELECT * FROM uesrs (タイポ) | users テーブルの SSN がアンマスクで返る |
ガバナンス無しでは、正しい SQL は責任の温床になります。
人のアクセスと同じガバナンスの基礎
エージェントは、DB を照会する人ユーザーと同じ統制を必要とします。
-
アクセス制御。 最小権限 — エージェントが必要とする DB、スキーマ、テーブルだけにスコープする。営業分析のエージェントが
hr.payrollに触る用事はない。 -
データマスキング。 機微カラム — SSN、クレジットカード、医療記録 — はエージェントに結果が届く前に動的にマスクされるべき。人のアナリストが
***-**-1234を見るなら、エージェントも同じ。 -
監査ログ。 すべてのクエリを記録する — 何を、いつ、どのエージェントが、どのユーザーの代行で。問題が起きたとき、監査証跡が追跡の手段になる。
エージェントでは賭け金が高いです — 構成を誤ったエージェントは数秒で、人が数時間で持ち出せるよりも多くのデータを持ち出せます。
エージェントで何が違うか
原則は同じ、運用モデルが違います。
エージェントは短命
エージェントは立ち上がり、タスクを実行し、消えます — しばしば数秒で。DB アカウントを払い出して数ヶ月有効なままにするのは不適合です。エージェントには 1 タスクにスコープされ、終わったら即座に取り消される資格情報が必要です。
各エージェントは独自の ID が必要
複数のエージェントが 1 つの DB ユーザーアカウントを共有すると、「誰が何をしたか」の可視性をすべて失います。各エージェントタイプは独自のアクセスポリシーを持つ別個の ID を持つべきです — そうしてアクセス制御と監査ログが意味を持ち続けます。
Just-in-Time アクセスがデフォルトになる
人ユーザーにとって Just-in-Time (JIT) の DB アクセスはベストプラクティスです。エージェントには、立ち上がる → クエリ → 結果を返す → 終わり、という自然なモデルです。タスクの前後に DB アクセスを保持する理由はありません。JIT はセキュリティのアップグレードというより、デフォルトのアーキテクチャになります。
Bytebase でエージェントアクセスをガバナンスする
Bytebase は PostgreSQL、MySQL、SQL Server、Oracle、Snowflake、BigQuery などを横断する AI エージェント向けの統一ガバナンス層を提供します。
組み込みのガバナンス基盤:
- DB、スキーマ、テーブル単位の細粒度アクセス制御
- カラム単位の動的データマスキング
- タスクごとに権限を付与・取り消しする Just-in-Time アクセス
- エージェントとユーザーの完全な帰属つき監査ログ
エージェント ID は一級概念です。Bytebase はサービスアカウントとワークロード ID をサポートし、各エージェントが独自のアクセスポリシーで動けます。Bytebase MCP サーバー経由で接続するか、API を呼び出してガバナンスを織り込んだ独自のエージェントワークフローを構築できます。