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 エージェントを本番 DB に向けるとき、典型的なセットアップではスキーマダンプ — テーブル名、カラム型、たまにコメント — を渡してクエリを生成させます。
これはデモには通用しますが、本番では崩れます。
エージェントは hr.employees.salary が機密でマスクされるべきだと知らず、customer.ssn にコンプライアンス必須のマスキングアルゴリズムが必要だと知らず、payments のクエリには 1 時間で失効する Just-in-Time の承認が要ると知りません。
本当のリスクは、エージェントが悪いクエリを書くことではなく、エージェントが正しいクエリを書いてしまうことです — 本来実行されるべきでなかったクエリを。
Schema as Context: スキーマを取り巻くもの
スキーマ — テーブル、カラム、索引、制約 — は構造の骨格です。文脈はそれに意味と安全性を与えるすべてです。
-
データ分類。 すべてのカラムに機微度 (public、internal、confidential、restricted) を構造化された機械可読メタデータとしてタグ付けし、下流のポリシーを駆動する。
-
動的データマスキング。 完全マスク、部分マスク、カスタムアルゴリズムを、クエリ時に「誰が」 — または「何が」 — 問うているかに基づいて当てる。LLM のコンテキストウィンドウに機微データが漏れないようにする強制境界。
-
アクセス制御。 DB ネイティブの GRANT を超える細粒度・ロールベースのアクセス。プロジェクト単位のスコープ、環境単位の制限、自動失効する Just-in-Time アクセス。
-
SQL レビューポリシー。 200+ の Lint ルール — アンチパターン検出、命名規約、性能のガードレール — が、エージェントが SQL を生成・提案するときの自動レビュワーになる。
-
変更ワークフロー。 プロセス自体をコード化する: どの変更が DBA 承認を要し、どの環境が段階的ロールアウトを要し、ロールバック計画は何か。自律システムが不可逆な間違いを犯さないようにするワークフロー。
監査証跡 — すべてのクエリ、変更、アクセス申請 — はコード化するものではありません。上記のポリシーを強制した副産物としてランタイムに生成され、エージェントが実際に何をしたかについての説明責任をあなたに与えます。
文脈をコード化する: Terraform、API、独自フォーマット
LLM にセキュリティポリシーの PDF を渡して遵守を期待することはできません。機械可読でバージョン管理されたポリシー定義を、プログラム的に強制する必要があります。
Bytebase は上記すべての文脈層を管理し、Terraform プロバイダー と API で公開します — DB をプロビジョニングする同じ CI/CD パイプラインで、誰がアクセスできるか、どのマスキングルールが当たるか、どのレビュープロセスが変更を律するかも一緒にプロビジョニングできます。さらに踏み込みたいチーム向けに、API で独自の文脈層を、エージェントが最も消費しやすいフォーマットで組めます — 分類タクソノミーを JSON で取り出す、マスキングポリシーを構造化データでエクスポートする、全部 YAML、TOML、Markdown でシリアライズする、など。
すべてがコード化されると、ポリシーはプラットフォーム層で強制される (クエリ時マスキング、クエリ実行前のアクセス拒否) か、エージェントが行動前に推論するための構造化メタデータとして利用可能になります。
Schema as Code はバージョン管理を与え、Schema as Context は AI 対応性を与えます。
参考文献
- Evolutionary Database Design — DB 変更を進化的なバージョン管理マイグレーションとして扱う、Martin Fowler と Pramod Sadalage の基礎記事。
- Spider 2.0 — 実世界の DB におけるエンタープライズ級 text-to-SQL タスクで LLM を評価するベンチマーク。