AI エージェントとデータベースについて書かれたもののほとんどは、読み取りに関するものです。エージェントは許可されたデータだけを見ているか。正しいクエリを書くのに十分なコンテキストを持っているか。どちらの問いも、エージェントを読み手として前提しています。そしてしばらくの間、その前提は通用していました。
その前提は失効しました。いまやエージェントは、マイグレーションを書き、カラムを変更し、テーブルをバックフィルする側になりました。読み取りの失敗はデータを漏らします。書き込みの失敗はデータを破壊します。同じデータベースでも、まったく別種のリスクであり、そして多くのチームは後者にまだ備えていません。
エージェントはすでに書いている
これは予測ではありません。先日開催された Background Agents Summit では、チームが次々と同じことを語っていました。変更を書き、レビューの時まで人間を介在させずにプルリクエストを開く、バックグラウンドエージェントです。
Stripe は 3,000 万行のコードベース上で「Minions」を動かしています。エージェントがマシンを確保し、変更を加え、チェックを実行し、PR を開きます。Uber の「Minion」プラットフォームは、いまやマージされる全 PR の 11% を生成しており、別のシステムである Shepard は大規模なマイグレーションそのものを狙っています。
かつてあなたのデータベースに問い合わせていたエージェントが、いまやそれを変更しています。その変更と本番環境の間に、何が立ちはだかっているのでしょうか。
コードにはマージゲートがある。あなたのデータベースにはない。
誰もが見過ごしている部分があります。エージェントがコードを書くとき、あなたは安全ゲートを無料で手に入れます。出力はブランチに着地します。人間がプルリクエストをマージするまで、何一つ本番環境には届きません。Stripe はこれを明示しました。エージェントが書いたすべての PR について、人間によるレビューは必須のままだと。Uber は、それらのレビューを適切な担当者に振り分けるためだけに Code Inbox を作りました。Git がゲートであり、それは 15 年間そこにあり続けてきました。
データベースには同等のものがありません。エージェントに接続文字列とマイグレーションを渡せば、送られた瞬間に ALTER TABLE が実行されます。ブランチもなければ、保留状態もなく、マージもありません。変更は、エージェントが準備完了だと判断した瞬間にライブになります。そして、午前 2 時に本番環境に対して DROP TABLE と打ち込むときにあなたが感じるあの重みを、どんなエージェントも感じません。
私たちは、誤って間違ったデータベースを指さないように、そして本番を DROP しないように、何年もかけて人間に教え込んできました。エージェントはその傷跡を一切持たずに始まり、誰にも見ていられない速さで動きます。コードが git から得ているマージゲートを、データベースには意図的にインストールしなければなりません。
プロンプトで安全にはたどり着けない
魅力的な解決策は、ルールをエージェントに書き込むことです。「WHERE 句なしにテーブルを変更してはならない」「本番に触れる前に必ず確認すること」。システムプロンプトに入れて済ませる、というわけです。
それは持ちこたえません。そしてこれはサミットで繰り返し出てきたテーマでした。自律的なエージェントは、プロンプトに書いたどんなルールも理屈で回避します。あるコマンドを実行するなと伝えれば、コマンドの名前を変え、ツールを差し替え、あるいは作業をステップに分割して、どの単一アクションもポリシーに引っかからないようにします。エージェントが読めるガードレールは、エージェントが反論できるガードレールです。エンフォースメントは、エージェントが見ることも編集することもできない場所に存在しなければなりません。
OS レベルの一派は、正しい直感を持っていますが、高度を間違えています。nono のようなツールは、カーネルでエージェントをサンドボックス化します。ファイルシステムの許可リスト、ネットワークの許可リスト、デフォルト拒否。有用です。しかしカーネルが見るのは、ポート 5432 への TCP 接続です。SELECT 1 と DROP SCHEMA public CASCADE を見分けることはできません。users.ssn が制限されていることも、payments テーブルを誰かが変更する前に DBA の承認が必要なことも知りません。データベースガバナンスはセマンティックです。SQL をパースしないサンドボックスは、ここで本当に重要なすべての区別に対して目が見えていません。
つまりガードレールは、そのどちらにも属しません。エージェントが理屈で乗り越えられるプロンプトでもなく、変更を理解するには鈍すぎるカーネルでもありません。それはデータベース変更レイヤー、すなわちエージェントの推論の下、生の接続の上に属します。
エージェントではなく、変更をガバナンスする
コツは、エージェントを信頼できるものにしようとするのをやめ、代わりに変更をゲートに通すことです。人間が書いたものでもエージェントが書いたものでも、同じゲートを。
Bytebase では、エージェントは接続文字列を受け取りません。サービスアカウントを受け取り、そのアカウントは完全なガバナンススタックを携えています。エージェントが提案するすべての変更は、あなたの人間がすでに通っているのと同じパイプラインを走る issue になります。
- SQL レビュー。 200 以上の Lint ルールが、何かが実行される前に危険な形を捕えます。
WHEREのないUPDATE、ホットなテーブルへのブロッキングなALTER、バックフィルのないカラム削除。自動レビュアーは決して疲れず、決して素通りさせません。 - 承認フロー。 エージェントが単独で適用してよいものと、人間を必要とするものを、あなたが決めます。開発ブランチのマイグレーションはセルフサービスで済みます。本番の財務テーブルへの変更は DBA へルーティングされます。サミットでは一つの問いがずっと回り続けていました。端末に人間がいないとき、リクエストはどこへ行くのか。その答えは、プロンプトと祈りではなく、定義された承認フローです。
- 段階的なロールアウトとロールバック。 変更は環境を順番に進み、ロールバック計画が付随します。だから過ちは致命的ではなく、回復可能なものになります。
- 監査。 すべての変更が記録され、エージェントと、その代行をした人間に帰属されます。何かが壊れたとき（そして必ず壊れます）、何が起きたのかを再構築できる唯一の手がかりが、その証跡です。
これらは新しい機構ではありません。チームが何年も走らせてきた変更プロセスです。新しいのは書き手です。ゲートはいまや、より重要になっています。なぜなら、エージェントはこれまでのどんな人間よりも速く書き、そして少なく悩むからです。
本当に重要な問い
最初に来たのはアクセスでした。エージェントは見るべきものだけを見ているか。次にコンテキスト。正しく動くために必要なものを持っているか。どちらも読むエージェントについての問いです。より新しい問いは、あなたが本番データを守れるかどうかを決める問いです。エージェントが変更を書いたとき、それが出荷される前に、誰が承認するのか。
業界は、エージェントを書くことにより上達させる競争を繰り広げています。誰も全力疾走していない競争は、地味な方です。変更が通過しなければならないゲートを作ること。コードは git からそのゲートを無料で手に入れました。あなたのデータベースは、あなたがそれをインストールするのをまだ待っています。
シリーズの他の記事
- データベース MCP サーバーとは？ - 基礎編：データベース MCP サーバーとは何か、そして生のサーバーがローカルでは問題なくても本番環境で牙をむく理由。
- ガバナンスされた MCP と生の MCP - エージェントのデータベースアクセスがガバナンスされるか野放しになるか、それが決まる唯一の場所が MCP サーバー。
- AI エージェントの DB アクセスをどうガバナンスするか - 読み取りパス：データを問い合わせるエージェントのための ID、認可、マスキング、監査。
- Schema as Code から Schema as Context へ - エージェントが正しく振る舞うために必要な分類・オーナーシップ・ポリシーを与える。