コーディングエージェントが専用の Git ブランチで作業していても、一つの共有開発データベースを通じて他のすべてのタスクと衝突する可能性があります。移行でスキーマが変わり、テスト用データが上書きされると、テスト失敗の原因が分からなくなります。実用的な境界はリポジトリのチェックアウトだけでなく、コードと、そのコードが変更できる状態の組み合わせです。
図は出典を明記した Databricks のワークフロー画像です。背景を説明するもので、すべてのデータベース製品が同じブランチ動作を持つという主張ではありません。
Databricks は一つの解決策として、コーディングタスクに使い捨てのデータベースブランチを結び付ける Lakebase の方式を示しています。Neon などの Postgres ワークフローにも似た仕組みがあり、PlanetScale は別の規律である、レビューを経たスキーマの本番反映を示しています。教訓はベンダーに依存しません。状態を隔離して実験を再現可能にし、レビュー済みの移行で本番に進める内容を決めます。
タスクの識別情報から始める
追跡できる環境だけを作成します。エージェントの実行、リポジトリのコミット、プルリクエストまたはチケット、親データベースの状態、作成日時、担当者、許可ツール、有効期限を記録します。一時ブランチは匿名のコピーではなく証拠になります。二つのエージェントを比較できるのは、それぞれの開始状態が分かる場合だけです。
ブランチは目的を満たす最小限のデータセットから始めます。スキーマのみ、合成データ、マスキング済みデータは、通常、本番由来のコピーより安全です。不具合調査で実際の記録が必要なら、作成権限とは別にアクセスを制限します。環境を申請する権限が、その全行を読む権限を自動的に与えてはいけません。
タスクごとに最小権限を与える
データベースブランチは書き込みを閉じ込めますが、すべての副作用を隔離するわけではありません。接続されたアプリはメールを送り、決済事業者を呼び、Webhook を実行し、オブジェクトストレージへ書き込み、広範な認証情報を使うことができます。短命で固有の接続 ID を与え、本番の接続先を拒否し、副作用を伴う連携をテスト用の受け口へ向けます。ネットワーク制御とシークレットの範囲は作業環境の一部であり、追加の選択肢ではありません。
ブランチの作成時に期限を設定します。コピーオンライトによる作成が安価でも、変更後のストレージ、計算資源、ログ、索引が無料になるわけではありません。自動削除には、インシデント、監査、法的保存義務に対する例外を文書化します。タスクより長生きするブランチは費用とデータガバナンスの両方の問題です。
評価環境として使う
定義された状態に対して移行、テスト、調査を実施します。テスト結果、コマンド、生成された移行成果物をタスク記録とともに保存します。複数のエージェントが代替案を調べるなら、同じ親スナップショットを与えて比較可能にします。失敗した環境のリセットや削除は安全でなければなりません。承認済みの本番操作がその環境に依存しないためです。
ここに、データベースのブランチがエージェント開発に役立つ理由があります。一つの実験が別の実験の条件をひそかに変えるのを防ぎます。ただし、選んだ実装が正しいことは証明しません。公開 API や文書はライフサイクル制御を説明しますが、チームは自分たちのブランチ深度、変更データ量、並列計算を測定し、製品デモから実際の負荷を予測できると考えないことが重要です。
実験状態ではなく指示を本番へ進める
データはソースコードと同じようにはマージできません。妥当そうな二つの移行でも、順序、互換性、展開要件が衝突します。本番候補は、テスト、ロールバックの検討、展開計画を備えたレビュー済み移行ファイルであるべきです。ブランチのレコードを本番へマージする要求ではありません。PlanetScale の展開レビューは、隔離と本番反映が異なる問題を解くことを思い出させます。
承認前に、稼働中アプリとの後方互換性、破壊的操作、必要な索引、データのバックフィル、展開順序を確認します。権限変更と不可逆なスキーマ操作には人のレビューを残します。ブランチでのテスト成功は強い証拠ですが、運用判断の代わりにはなりません。
ブランチ数ではなく境界を測る
導入は範囲を限定した一つの流れから始めます。プルリクエストごとに一つのブランチ、マスキング済みデータ、短い期限、本番への外向きアクセス禁止です。共有環境の競合、テスト再現性、削除成功率、レビュー時間、本番へ漏れた移行不具合を測定します。エージェントが作成したデータベース数を成功指標にしてはいけません。
Databricks の Lakebase 発表が明らかにしたのは、エージェントにはコードと同じくらい状態の境界が必要だという問題です。持続可能な方法は単純です。タスクを特定し、データと権限を最小化し、環境を期限切れにし、証拠を残し、レビュー済みの指示だけを本番へ進めます。一時データベースの状態を無管理の本番入口にせず、迅速な実験を容易にできます。