Databricks、並列コーディングエージェント向けLakebaseブランチングの詳細

Databricksは2026年10月8日に、ブログ記事を公開し、すべての並列コーディングエージェントとすべてのプルリクエストが、Lakebaseデータベースサービスに組み込まれたコピーオンライトブランチングで作成された、独立した一時的なPostgresデータベース上で実行される開発ワークフローの詳細を示しました。

この記事では、Databricksはデータベースを、コーディングエージェントが開発作業の比重を増し、複数エージェントを並行して実行することが標準となりつつある時期において、開発ワークフローのしばしば見過ごされがちな部分として説明しています。従来の共有環境、たとえば単一の開発データベースやステージングデータベースでは、同時に動作するエージェントがスキーマ変更で衝突したり、互いに干渉したり、実際のデータを反映しないモックに依存したりすることがあります。これらはすでに開発者にとっての課題であると記事は述べていますが、エージェントはより高速に動き、並行して動作し、プロダクションデータを危険にさらしたり機密データを露出させたりしない安全な環境を必要とするため、これらの問題をさらに悪化させます。

ブランチングの仕組み

Databricksによると、Lakebaseブランチングを使用すると、サイズに関係なく、ユーザーは1秒未満でデータベース全体をブランチできるとのことです。ブランチはコピーオンライトストレージを利用し、新しいブランチは親のスキーマとデータを継承しつつ基盤ストレージを共有し、分岐した分だけ追加ストレージを消費します。DatabricksのLakebaseブランチングドキュメントによれば、各プロジェクトはデフォルトで「production」という名前のブランチが作成され、ルートブランチを除くすべてのブランチは親を持ちます。子ブランチでの変更は親に影響せず、またこの分離はPostgresロールの状態にも及びます。ロールやデータベースの作成、GRANTやREVOKEの適用、ロール属性の変更は、あるブランチで行っても他のブランチには影響しません。

ドキュメントによれば、各ブランチは独自のコンピュートリソースを持ち、アイドル時にはゼロにスケールダウンし、アクティブなコンピュート時間に対してのみ課金されます。ストレージの課金はブランチの有効期限に依存します。期限が設定されたブランチは変更されたデータ分のみ課金され、期限がない永続的なブランチは独立したデータベースと同様に全データサイズ分課金されます。ブランチリセットは子ブランチを親からリフレッシュする機能で、親から子への一方向のみで動作します。時点復元は、復元ウィンドウ内の履歴データから新しいルートブランチを作成し、元のブランチは変更せずに稼働し続けます。

Databricksは製品ページで、LakebaseをオープンソースPostgresエンジンをフォークせずに実行するフルマネージドかつサーバーレスのPostgresサービスとして説明しています。

エージェントごとのブランチ

記事のワークフローでは、Git worktree と Lakebase ブランチを組み合わせています。worktree は各エージェントに独自のディレクトリとチェックアウトされたブランチを提供し、エージェント間のファイルレベルの競合を排除します。その後、ポストチェックアウトフックが新しい worktree ごとにデータベースブランチを自動的に作成します。例では、Claude Code を使用して構築され、エージェントは claude -worktree feature-123Git が worktree を作成し、フックが発動すると、エージェントは自分専用のコードディレクトリと完全に分離されたデータベースを持つことになります。AGENTS.md や CLAUDE.md といったリポジトリの指示ファイルがエージェントの動作を導き、エージェントが完了するとプルリクエストを作成し、その後 worktree とデータベースブランチの両方を廃止できます。

記事では、Git との違いとして、Lakebase ブランチはメインブランチにマージされないと指摘しています。親と子がそれぞれ独立して変更でき、データの整合がすぐに実用的でなくなるためです。その代わり、スキーマ変更はアプリケーションロジックと共にコードで管理され、Drizzle、Flyway、Liquibase、Alembic などのツールを用いたマイグレーションを通じて親ブランチへ昇格させます。例では Drizzle を使用しており、スキーマ変更が必要になるとエージェントは対応するマイグレーションをコードベースに追加し、プレビューアプリケーションのデプロイ時と変更がメインにマージされる際にデプロイ自動化がそれを適用します。

プルリクエストごとのブランチ

継続的インテグレーションのために、記事は GitHub Actions のワークフローを示しています。main に対してプルリクエストを開くと、Lakebase CLI がプルリクエスト名を付けた一時的なブランチを production ブランチの子として作成し、そのブランチがプルリクエストのデータベース環境となります。マイグレーションツールは新しいブランチ上で実行され、プレビューアプリケーションがデプロイされブランチの接続文字列に向けられ、スキーマ差分が生成されてプルリクエストのコメントとして投稿され、どのテーブル・カラム・インデックスが変更されたかが正確に示されます。プルリクエストがクローズまたはマージされると、自動化によりブランチが削除されます。ブランチが production から開始されるため、変更が本番に到達する前にスキーママイグレーションを適用・テストできます。例では Databricks Apps 上でプレビューをデプロイしていますが、記事はこの概念が Vercel、Netlify、Cloudflare など他のホスティングプラットフォームにも適用できると述べています。

環境について、記事は一般的な Lakebase の構成では開発、ステージング、本番など環境ごとに Databricks ワークスペースを一つずつ使用し、チームは本番データベースではなくシード済みデータベースからブランチを作成して PII などの機密データの露出を防ぐことが多いと指摘しています。今回の手順ではシンプルさのために単一のワークスペースを使用していますが、同様の概念はマルチワークスペース構成にも適用できることを付記しています。

バグ再現とマイグレーションテスト

エージェント単位やプルリクエスト単位のループを超えて、この記事では例示リポジトリでは実装されていないブランチングワークフローについて説明しています。開発者は、バグが発生する直前など特定の時点の本番環境から分離されたブランチを作成し、実データを用いて問題を再現・調査し、修正が検証されたらそのブランチを削除できます。チームは本番環境へデプロイする前にブランチを作成し、スキーママイグレーションを適用してテストを実行し、変更を本番に昇格させる前にアプリケーションが期待通りに動作することを確認することも可能です。これらのワークフローにより、開発者は Unity Catalog のマスキング機能などを利用して、本番に近いデータや本番由来のデータで作業でき、ライブデータベースを危険にさらすことなく作業できます。

この記事は、GitHub 上の databricks/tmm リポジトリの Lakebase-Agentic-CI ディレクトリにある例示リポジトリへのリンクを提供し、パターンを実装した GitHub Actions ワークフローのサンプルが含まれています。これらのパターンが組み合わさって、記事では「Lakebase 開発ループ」と呼ばれる、エージェントごとのブランチ、プルリクエストごとのブランチ、そして本番検証用の分離ブランチという構成になると結論付けています。