進化的データベース開発の実現：Lakebaseによるデータベース分岐（結論編）

本稿は、DatabricksによるLakebaseを使用したデータベース分岐に関するシリーズの第3部であり、結論編です。このシリーズは、基盤となるインフラストラクチャが根本的に変化した際に、進化的データベース開発の方法論が実際にどのように実装されるかを探求します。架空の開発者Jenの視点から、彼女の個人的なワークフロー（第1部）から始まり、11のプラクティスからなるプレイブック（第2部）を経て、最終的に50人のチームとAIエージェントの参加（第3部）に至ります。

階層トポロジー：個別インスタンスではなく長期間存続するブランチ

データベース分岐が登場する前は、各環境は独立したデータベースインスタンスでした。ステージング、UAT、パフォーマンステスト用に専用のPostgresデプロイメントがあり、それぞれ個別にプロビジョニング、パッチ適用、マスキング、同期が必要でした。この補償層は環境間の構造的なドリフトを引き起こしていました。

チーム規模では、階層モデルは単一のLakebase親ブランチから派生した長期間存続するブランチに集約されます。ブランチは2種類あります：階層（長期間存続し、昇格階層の親となる）と機能ブランチ（一時的で、階層から派生し、クリーンアップされる）です。昇格パスは親ブランチの連鎖によって定義されます。

この構造には多くの利点があります：

• 統一されたパイプライン定義：同じワークフローがすべてのブランチと遷移を処理します。
• 昇格はマージ：ステージングから本番へのデプロイは実質的にgitマージであり、その下流効果はLakebaseブランチの昇格です。マイグレーションは各階層で一度だけ適用され、前の階層で検証済みです。
• 環境間のドリフトなし：すべての階層は同じ親ブランチから派生し、スキーマの差分は計算可能です。
• リポイントによるロールバック：問題のある昇格は、アプリケーションを昇格前のブランチスナップショットにポイントすることで回復できます。
• コスト帰属：Unity Catalogが自動的にメタデータをキャプチャし、SQLクエリで誰がいつどのブランチを作成し、コストがいくらかを把握できます。

データベースインスタンスの数は大幅に減少します。6つの環境（本番、ステージング、UAT、QA、パフォーマンス、デモ）は、1つのLakebase親ブランチとその長期存続ブランチの階層に集約されます。

権限モデル：今すぐ設計すべきもの

チームがスケールする前、またはエージェントが追加される前に、権限モデルの設計を事前に行う必要があります。主要な決定事項は以下の通りです：

• 各階層からのブランチ作成権限：本番からのフォークはホットフィックスとリカバリフローに限定し、一般的な機能ブランチはエントリー（最下層）の階層から派生させるべきです。
• 階層間の昇格権限：「機能からステージング」への昇格はコードレビューの問題、「ステージングから本番」への昇格はリリース調整の問題であり、別々のゲートとレビューアが必要です。
• 読み取りと書き込みの分離：本番データのブランチへの読み取りアクセスと書き込みアクセスは区別すべきです。
• Unity Catalogポリシー：本番ポリシーはデフォルトですべての子孫ブランチに継承され、階層固有の例外（例：ロードテスト用に合成PIIを含むQA階層）は一度宣言します。
• 監査証跡：すべての操作を単一のクエリ可能な場所に記録します。

基本原則：ロールが宣言し、ポリシーが強制します。プラットフォームエンジニアが階層階層、権限モデル、昇格パスを宣言し、ポリシーはそれに反する遷移を拒否します。人間やエージェントが宣言された境界を再試行によって上書きすることはできません。

DBAの新たな役割：管理者からプラットフォームエンジニアへ

20年前、進化的データベース設計の論文は、約100人の開発者と関連チームに対して1人のフルタイムDBAで十分だと述べていました。この比率は2026年でも有効ですが、DBAの業務内容は変化しています。

かつてDBAはインフラストラクチャのプロビジョニング、スキーマの準備、アクセス制御、時折の手動介入に時間を費やしていましたが、現在はブランチポリシーの設計、マスキングポリシー、昇格ワークフロー、監査証跡の可観測性に移行しています。具体的な成果物としては、すべてのPRにコメントするスキーマ差分ボット、開発ブランチを毎晩リセットするスケジュールジョブ、ブランチのライフサイクルとTTLコンプライアンスを追跡するダッシュボード、スキーマ検証に基づくマージゲートのCI定義などがあります。これははるかに高度なプラットフォーム設計作業です。

さらに、AIエージェントの出現が新たな課題をもたらします。エージェントはジュニア開発者のようなものです。実行可能なコードとテストを生成できますが、ガイダンスなしでは保守不可能なシステムを作り出します。テストはエージェントの誠実さを保つ手段であり、TDD（テスト駆動開発）プレイブックによってチームはテストを優先することを確実にします。

結論

本稿は、データベース分岐インフラが成熟した後に、チームのスケール拡大とエージェント参加が引き起こす3つの耐荷重構造をまとめました：階層トポロジー、権限モデル、DBAの役割の進化です。これらの構造はランタイムのゲートではなく、スケール前に設計すべきフレームワークです。フレームワークこそがチームに共有の慣習とガードレールを提供し、すべての操作はその内部で実行されます。