LakebaseとエージェンティックSDLC：コーディングエージェント向けデータベースブランチング

AIはソフトウェアの構築方法を変えました。コーディングエージェントが開発作業の中で大きな役割を担うようになるにつれ、開発者はエージェントのオーケストレーション（調整・制御）へとシフトしています。複数のエージェントを並列で実行することが当たり前となり、スキルやフックからMCP、サブエージェントに至るまで、エージェントをより安全かつ効果的にするためのツールも進化しています。

しかし、開発ワークフローにおけるミッションクリティカルな要素である「データベース」が見落とされがちです。

並行して動作する各エージェントは、コードを書き、スキーマ変更を適用し、データベースに対してテストを実行する必要があります。従来のデータベース設定で典型的な単一の開発環境やステージング環境など、共有環境を使用していると、大きな問題が生じます。エージェント間でスキーマ変更が競合したり、互いに干渉したり、実際のデータを反映していないモックに頼らざるを得なくなったりします。これらは開発者にとってもすでに課題でしたが、コーディングエージェントによってさらに深刻化しています。エージェントはより迅速に動き、並列で動作するため、本番データへのリスクを避け、機密データの漏洩を防ぐための安全な環境が必要です。

Lakebase Postgresのアーキテクチャは、データベースのブランチ機能（データベースブランチング）によってこの問題を解決します。Gitでコードをブランチ操作するのと同様に、Lakebaseではデータベースのサイズに関係なく、1秒未満でデータベース全体をブランチできます。コピーオンライト（Copy-On-Write）を使用するため、ブランチは親ブランチのデータを共有し、差分が生じた分だけ追加ストレージを消費します。さらに、スケールツーゼロ（Scale-to-Zero）をサポートしているため、アイドル状態のブランチには計算コスト（コンピュートコスト）がかかりません。これは、複数のエージェントを同時に実行する際に重要です。各ブランチは完全に分離されており、エージェントはマイグレーションの適用やテストの実行を行い、完了後にブランチを廃棄することができます。

この記事では、コーディングエージェントを中心に構築されたLakebase開発ループのエンドツーエンドのワークフローを通じて、これが実践でどのように機能するかを紹介します。以降のセクションで説明する内容を実現するためのGitHub Actionsワークフローの例を掲載したサンプルリポジトリもご用意しています。

実際の動きをご覧になりたい場合は、以下の解説動画をご視聴ください。

本題に入る前に、Databricksの環境構成についての注意点です。Lakebase Postgresを使用する際の一般的な構成は、開発（dev）、ステージング（staging）、本番（prod）など、環境ごとに1つのDatabricksワークスペースを使用することです。単一のワークスペースを使用することも可能ですが、多くのチームはセキュリティやコンプライアンスなどの理由からワークスペースを活用することを望みます。同様に、個人可識別情報（PII）などの機密データの露出を避けるため、本番データベースではなく、初期データが投入されたデータベースからブランチを作成することも一般的です。この記事では簡略化のために単一のワークスペースを使用しますが、同じコア概念はマルチワークスペース構成にも適用され、同様に簡単に実装できます。

並列コーディングエージェントのための安全で分離されたデータベース

従来のデータベースに対する大きな破壊的変化は、複数のコーディングエージェントが同時に作業することから生じます。新機能の開発や問題修正の際、各エージェントはデータベースのスキーマ読み込み、変更の適用、シードデータの設定、テストの実行を頻繁に行う必要があります。分離環境がない場合、これらのエージェントは互いに干渉したり、共有データベースを破損させたりする可能性があります。データベースブランチング機能を使用することで、各エージェントに分離された環境が提供され、同時に実行されている他のエージェントに影響を与えることなく独立して作業できるようになります。

ローカルでコードの競合を回避する実用的な方法は、Gitワークツリー（worktree）を活用することです。ワークツリーは各エージェントに独自のブランチがチェックアウトされた専用ディレクトリを提供するため、エージェント間でファイルレベルの競合が発生しません。Gitワークツリーは並列エージェントのコード分離を解決します。そして、Lakebaseのブランチ機能はもう片方の課題であるデータベース分離を解決します。リポジトリにpost-checkoutフックを追加することで、新しい各ワークツリーは独自のデータベースブランチを自動的に取得します。開発が完了すると、エージェントはPRを作成します。エージェントの動作は、AGENTS.mdやCLAUDE.mdなどのリポジトリ指示ファイルを通じてガイドできます。

安全なAI開発のための、Claude Code、ワークツリーおよびLakebaseのブランチ機能を使用したワークフロー例を以下に示します。

• エージェントが claude -worktree feature-123 を実行します
• Gitがfeature-123ブランチのワークツリーを作成します
• post-checkout フックが自動的に起動し、データベースブランチを作成します
• エージェントは完全に分離された独自のコードディレクトリとデータベースを所有するようになります

作業が完了すると、エージェントはPRを作成します。この動作はリポジトリ指示ファイルで規定されています。PRが作成されると、ワークツリーとデータベースブランチの両方を破棄できます。Gitとの重要な違いの1つは、Lakebaseのブランチはメインブランチにマージバック（統合）されないことです。親と子がそれぞれ独立して変更される可能性があるため、データの擦り合わせを行うことは非実用的になるからです。代わりに、スキーマの変更はアプリケーションロジックとともにコード内で追跡され、Drizzle、Flyway、Liquibase、Alembicなどのツールを使ったマイグレーションを通じて親ブランチへと昇格（プロモート）されます。

この例では、Drizzleを使用します。スキーマの変更が必要な場合、エージェントは対応するマイグレーションをコードベースに追加します。その後、デプロイ自動化プロセスにより、プレビューアプリケーションのデプロイ時、および変更がメインブランチにマージされた時に、そのマイグレーションが適用されます。

すべてのプルリクエストのための短命（エフェメラル）なデータベース

プルリクエスト（PR）が開かれると、本番環境に反映される前に、実際のデータベースに対してコードを自動検証・テストしたいと考えます。

継続的インテグレーション（CI）ツール（ここではGitHub Actions）を使用して、本番ブランチの子として各PR用に短命（エフェメラル）なLakebaseブランチが作成されます。そのブランチがPR専用のデータベース環境となります。これに対して自動テストを実行し、プレビューアプリケーションをデプロイして、レビュアーが実際のデータベースに対して変更を検証できます。

ブランチは本番環境から作成されるため、変更が本番環境に到達する前に、スキーママイグレーションを適用してテストすることも可能です。

PRが承認されてマージされると、機能コードとマイグレーション指示が昇格（プロモート）され、一時的なLakebaseブランチは削除されます。

一般的なGitHub Actionsワークフローは以下のようになります。

• mainブランチに対してPRが開かれます
• CIがLakebase CLIを呼び出し、pr-123のようなブランチを作成します
• マイグレーションツール（Drizzle、Alembicなど）が、新しく専用に作られたデータベースブランチに対して実行されます
• プレビューアプリがデプロイされ、該当ブランチの接続文字列に向けられます
• スキーマの差分（diff）が生成され、どのテーブル、列、インデックスが変更されたかを正確に示すPRコメントとして投稿されます
• レビュアーがコードとデータベースの両方の変更を検証します
• PRがクローズまたはマージされると、CIがブランチを削除します

リポジトリの例ではDatabricks Appsを使用してアプリケーションをデプロイしていますが、このコンセプトはVercel、Netlify、Cloudflareなどの他のホスティングプラットフォームにも適用できます。

データベースブランチを使用したバグ再現、マイグレーション、およびテスト

開発タスク以外にも、データベースブランチングは他のいくつかの役立つワークフローをサポートできます。これらはサンプルリポジトリには実装されていませんが、Lakebase開発ワークフローにおける価値ある追加機能となります。例えば、データベースブランチングを使用すると、通常はバグが発生する直前の特定の時点における本番環境から分離されたブランチを作成し、実際のデータに対して問題を調査し、バグを安全に再現して、修正が検証されたらブランチを削除できます。

また、ブランチ作成によってスキーママイグレーションもより安全になります。変更を本番環境にデプロイする前に、データベースブランチを自動的に作成し、マイグレーションを適用してテストを実行し、アプリケーションが期待通りに動作し続けていることを確認できます。マイグレーションが検証されたら、同じ変更を本番環境に反映（プロモート）できます。

これらのワークフローは強力です。なぜなら、例えば Unity Catalog マスキングなどを使用して、稼働中のデータベースを危険にさらすことなく、本番環境と同等または本番環境由来のデータを使って開発者が作業できるからです。各ブランチは独立しており一時的であるため、デバッグ、テスト、検証を行うための安全な環境となります。

まとめ

これらのパターンを組み合わせることで、Lakebase開発ループが形成されます。エージェントごとのブランチ、PRごとのブランチ、そして本番検証用の独立したブランチです。

Agentic SDLC（エージェント型SDLC）において、データベースブランチングはコーディングエージェントを活用する開発チームに安全で柔軟な基盤を提供します。ぜひご自身でブランチ作成をお試しください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事