20 年以上にわたり、業界はチームに対してデータベーススキーマをアプリケーションコードのように扱えと言い続けてきました。バージョン管理し、レビューし、パイプラインを通じて出荷する。このアドバイス自体は今も有効です。しかし新しい消費者がテーブルに現れました。そしてこの消費者は、あなたの DBA のようにはプルリクエストを読みません。
LLM と AI エージェントが、SQL の生成、マイグレーションの提案、データ変更の実行を担う場面がますます増えています。こうした行為者にとって、バージョン管理されたマイグレーションファイルだけでは到底足りません。彼らに必要なのは文脈です。
Schema as Code は必要な第一歩だった
Database-as-Code の流れ (Migration ベース vs State ベースの議論はいったん置いておきます) は、スキーマ管理に本物の規律を持ち込みました。Liquibase や Flyway のようなツールは、Infrastructure as Code と同じように、CI/CD パイプラインを通じて適用されるバージョン管理されたマイグレーションと、単一の真実の源をチームに与えました。Bytebase はこれにレビューワークフロー、アクセス制御、ガバナンスを加えて拡張しました。
ここに落とし穴があります。CREATE TABLE 文はデータの形を伝えてくれます。しかしそれは、誰がそのデータを閲覧・変更してよいのか、どのカラムが PII や財務記録や医療記録を保持しているのか、異なるロールがクエリしたときにどのマスキングルールが当たるのか、変更が本番に到達する前にどの承認を通過しなければならないのか、については何も語りません。
人の開発者にとって、その知識は部族の記憶や古い Slack のスレッドに住んでいます。AI エージェントにとっては、コード化されていなければ存在しないも同然です。
エージェントは DDL 以上を必要とする
text-to-SQL エージェントを本番データベースに向けると、典型的なセットアップではスキーマダンプ (テーブル名、カラム型、たまにいくつかのコメント) を渡してクエリを生成させます。
これはデモでは通用しますが、本番では崩れます。
エージェントは hr.employees.salary が機密 (Confidential) でマスクされるべきだと知りません。customer.ssn にコンプライアンス上必須のマスキングアルゴリズムが必要だと知りません。payments のクエリには 1 時間で失効する Just-in-Time のアクセス承認が要ることなど、まったく分かっていません。
本当のリスクは、エージェントが悪いクエリを書くことではありません。エージェントが、そもそも実行されるべきでなかった正しいクエリを書いてしまうことです。
文脈とは、スキーマを取り巻くすべて
スキーマ (テーブル、カラム、索引、制約) は構造の骨格です。文脈とは、そこに意味を与え、安全に保つすべてのものです。
-
データ分類。 すべてのカラムにその機微度 (public、internal、confidential、restricted) を、下流のポリシーを駆動する構造化された機械可読メタデータとしてタグ付けする。
-
動的データマスキング。 完全マスク、部分マスク、あるいはカスタムアルゴリズムを、誰が (あるいは何が) 問い合わせているかに基づいてクエリ時に適用する。これは、機微なデータが LLM のコンテキストウィンドウに漏れ出すのを止める強制境界です。
-
アクセス制御。 データベースネイティブの GRANT を超える、細粒度でロールベースのアクセス。プロジェクト単位のスコープ、環境単位の制限、そして自動失効を伴う Just-in-Time アクセス。
-
SQL レビューポリシー。 アンチパターン検出、命名規約、性能のガードレールをカバーする 200 以上の Lint ルールが、エージェントが SQL を生成・提案したときの自動レビュワーとして機能する。
-
変更ワークフロー。 プロセスそのものをコード化する。どの変更が DBA の承認を要するか、どの環境が段階的なロールアウトを要するか、ロールバック計画は何か。これらのワークフローこそが、自律システムが不可逆な間違いを犯すのを防ぎます。
監査証跡 (すべてのクエリ、すべての変更、すべてのアクセス申請) は、コード化するものではありません。それらは上記のポリシーを強制した副産物として、ランタイムに自然と生み出され、エージェントが実際に何をしたかについての説明責任をあなたに与えます。
文脈をコード化する: Terraform、API、そして独自フォーマット
LLM にセキュリティポリシーの PDF を手渡して遵守を期待することはできません。必要なのは、機械可読でバージョン管理されたポリシー定義を、プログラム的に強制することです。
Bytebase は上記すべての文脈層を管理し、それらを Terraform プロバイダー と API を通じて公開します。そのため、データベースをプロビジョニングする同じ CI/CD パイプラインで、誰がアクセスできるか、どのマスキングルールが当たるか、どのレビュープロセスが変更を律するかも一緒にプロビジョニングできます。さらに踏み込みたいチーム向けに、API を使えば、エージェントが最も消費しやすいフォーマットで独自の文脈層を構築できます。分類タクソノミーを JSON として取り出す、マスキングポリシーを構造化データとしてエクスポートする、あるいは全体を YAML、TOML、Markdown としてシリアライズする、といった具合にです。
すべてがコード化されると、ポリシーはプラットフォーム層で強制されるか (クエリ時のマスキング、クエリ実行前のアクセス拒否)、あるいはエージェントが行動する前に推論できる構造化メタデータとして利用可能になります。
Schema as Code はバージョン管理をもたらしました。Schema as Context は AI 対応性をもたらします。スキーマダンプは、あなたのデータがどう見えるかをモデルに伝えました。今問われているのは、あなたのデータが何をしてよいのかまでモデルに伝えるかどうかです。
参考文献
- Evolutionary Database Design - データベース変更を進化的でバージョン管理されたマイグレーションとして扱う、Martin Fowler と Pramod Sadalage の基礎記事。
- Spider 2.0 - 実世界のデータベースにわたるエンタープライズ級の text-to-SQL タスクで LLM を評価するベンチマーク。
シリーズの他の記事
- データベース MCP サーバーとは？ - 基礎編：データベース MCP サーバーとは何か、そして生のサーバーがローカルでは問題なくても本番環境で牙をむく理由。
- ガバナンスされた MCP と生の MCP - エージェントのデータベースアクセスがガバナンスされるか野放しになるか、それが決まる唯一の場所が MCP サーバー。
- AI エージェントの DB アクセスをどうガバナンスするか - 読み取りパス：データを問い合わせるエージェントのための ID、認可、マスキング、監査。
- エージェントがマイグレーションを書いたとき、誰が承認するのか？ - 書き込みパス：エージェントが作成するスキーマおよびデータの変更をガバナンスする。