2026年6月12日

進化的データベース開発の実現：Lakebaseによるデータベースブランチング（完結編）

パート3：大規模におけるジェンのチーム

によって Pramod Sadalage 、 Kevin Hartman による投稿

『Evolutionary Database Design』で説明され、『Refactoring Databases: Evolutionary Database Design』で実践された手法は、20年にわたり明確に示されてきました。7つのプラクティス、70以上の名前付きリファクタリングのカタログ、移行のメカニズム。そのすべてが文書化され、査読され、教えられてきました。

この手法は、2010年に『Continuous Delivery』（第12章：データの管理）によってCI/CDに導入されました。マイグレーションはデプロイパイプラインにおける第一級の成果物（ファーストクラスのアーティファクト）となりました。「コードとしてのデータベース変更」という規律は、より広範なCI/CDの動きへと広がりました。CDが解決できなかったのは、パイプラインごとの分離です。パイプラインはマイグレーションを実行できましたが、依然としてターゲットとなるデータベースが必要であり、そのターゲットは共有されていました。プラクティス4「全員が独自のデータベースインスタンスを持つ」は、開発者ごとに本番環境と同等のデータベースを用意するには時間、コスト、そしてDBAのサイクルが必要になるため、ほとんどのチームにとって憧れのままでした。このギャップを回避するために登場した補完レイヤー（モックオブジェクト、共有ステージング環境、インメモリデータベースの代替、DBAのチケットキューなど）は、意図した設計ではなく、デフォルトで基礎的な手法となってしまいました。

2026年、コピーオンライトのデータベースブランチ機能がDatabricks Lakebaseに登場します。テラバイト規模の本番データベースから、作成時にはストレージを消費せず、わずか1秒でブランチを作成することが、O(1)の操作で可能になります。プラクティス4を憧れのままにしていた制約が、ついに解消されたのです。

本シリーズでは、この制約が解消されたときに何が変わるのかを説明します。手法そのものが変わるわけではありません（それは維持されます）。新しく生まれるプラクティス、自動化されるチーム規模のガバナンス、DBAの役割の進化、そしてエージェントが人間の開発者と共有する新しい基盤について解説します。

ジェンの紹介

ジェンは、『Evolutionary Database Design』に登場する開発者のキャラクターです。そのエッセイの中で、彼女は日常的なユーザーストーリーとしてデータベースのリファクタリング（inventory_code フィールドを location_code、batch_number、serial_number に分割する作業）を実装し、DBAと開発者が連携できること、スキーマを少しずつ進化させられること、そしてマイグレーションによって変更を安全に進められることを示しました。

本シリーズは、20年後のジェンのストーリーから始まります。彼女が従う手法は、2003年当時と同じものです。新しくなったのは、彼女のワークフローを支える基盤です。コピーオンライトのデータベースブランチ機能により、彼女が読んできたプラクティスが本番規模で実用可能になりました。この3部構成のシリーズ全体を通して、彼女は3つの異なるスコープ（彼女の1日（パート1）、新しいプレイブック（パート2）、そして彼女のチーム（パート3））における「同じジェン」として登場します。

パート3：大規模組織におけるジェンのチーム

パート1では、ジェンが1つの機能を開発する流れを追いました。パート2では、2026年に彼女の業務が準拠する11のプラクティスからなるプレイブックを紹介しました。パート3では、この同じプレイブックを50人の開発者からなるチームに適用します。ここでは、人間と並んでエージェントもブランチを作成します。そして、「この規模において、何が構造的な要素となるのか？」を問いかけます。

3つの要素が重要になります。

1つ目は、プロモーションパス（昇格パス）における各環境を表す長期運用ブランチである「ティアトポロジー」です。開発者が1人のときは、フィーチャーブランチと本番環境だけで済みました。50人になると、安定したレーンと、その上に重ねられた一時的な（エフェメラルな）レーンを持つ、構造化された階層が必要になります。

2つ目は、どのブランチに対して誰が何を行えるかを定義するフレームワークである「権限モデル」です。開発者が1人のときは、慣習を信頼するだけで十分でした。50人になり、さらにエージェントも加わるようになると、このフレームワークを一度設計し、自動的に適用する必要があります。

3つ目は、「DBAの役割」です。開発者が1人のとき、DBAはPR（プルリクエスト）におけるジェンの設計パートナーでした。50人になると、DBAはジェンやそのチームメイトが作業するフレームワークを設計するプラットフォームエンジニアになります。

本記事ではこれら各要素について説明し、その後にエージェントについて取り上げます。同じ機能におけるエージェントの活用がプラクティス11です。エージェントはジュニア開発者のようなものです。彼らは、動作するコードを生成し、テストをパスさせ、マイグレーションを適用しますが、適切なガイダンスがなければ、メンテナンス不可能なシステムを作り出してしまいます。テストは、チームが彼らの品質を担保するための手段です。次に紹介するTDD（テスト駆動開発）のプレイブックは、チームがテストを最優先にするための方法を示しています。

個別のインスタンスではなく、長期運用ブランチとしてのティア

ブランチ機能が登場する前の世界では、環境とはインスタンスのことでした。ステージング用の専用Postgresデプロイメント、UAT（ユーザー受け入れテスト）用のデプロイメント、パフォーマンス用のデプロイメントがそれぞれ個別にプロビジョニング、パッチ適用、マスキング、同期されていました。パート2で言及した補完レイヤーも、ここに存在していました。環境間のズレ（ドリフト）は構造的な問題でした。

チーム規模になると、ティアモデルは同じLakebaseの親から分岐する長期運用ブランチへと集約されます。

ブランチは、ティア（長期的に存在し、プロモーション階層における親となるもの）またはフィーチャー（一時的であり、ティアから派生して最終的にクリーンアップされるもの）のいずれかです。ティアには親が存在します。この「親である」というチェーンがプロモーション階層を構成します。

図1では、メインが本番環境であり、必要に応じてフィーチャーブランチが作成されるシンプルな階層を示しています。この構成は、初期のプロトタイピングや、非常に小規模なチームでの初期段階の作業に一般的に役立ちます。より多くの開発者が所属し、多くの環境を必要とする成熟したチームでは、以下に示すような構成が必要になります。

図2：最新のスキーマと参照データで構成されるメインラインと、そのさまざまなブランチのレイアウト

一部の企業では、リリース候補（RC）を用意する必要があり、このリリース候補は一定期間開発が行われ、テストに合格した後に本番環境にプロモート（昇格）されます。図3は、リリース候補を開発し、その後に本番環境へプロモートできるようにするレイアウトを示しています。その後、リリース候補ブランチはクリーンアップされます。

ブランチの名前は任意ですが、重要なのは「親である」という関係のルールがどのように設定されているかです。親チェーンの階層に矛盾する遷移を許可しないポリシーを実装することで、直接的なフィーチャーマージを防ぐことができます。

ポリシー定義により、パイプライン管理において多くのメリットが得られます。

ブランチを認識する単一のパイプライン定義。 パート2で導入されたpr.yml はすべてのPRに対して実行され、merge.ymlはすべてのプロモーションに対して実行されます。同じワークフローで、フィーチャー、ティア、およびそれらの間の遷移をカバーできます。
プロモーションは再デプロイではなくマージ。 ステージングから本番環境へのリリースはgitマージであり、その下流効果としてLakebaseのブランチプロモーションが行われます。マイグレーションは各ティアで1回だけ適用され、初期段階でコードが検証されるのと同様に、まず前のティアで検証されます。
「テスト環境」と本番環境の間のズレ（ドリフト）を排除。 すべてのティアは同じ親から派生しています。任意の2つのティア間のスキーマの差分（diff）は、実際に計算可能なものです。スキーマは分岐マーカーを持つ1つのページチェーンであり、データベースソフトウェアを2つインストールしたものではありません。これにより、チームはパッチ適用やアップグレードが必要な多数のデータベースサーバーを管理する手間から解放されます。
リポイントによるロールバック。不適切なプロモーションが発生した場合は、アプリケーションの参照先をその階層のプロモーション前のスナップショットに切り替えることで復旧します。スナップショット自体が別のブランチであるため、開発チームはデプロイの失敗から迅速に復旧できます。
project_id、branch_id、endpoint_idによるコスト配分。Unity Catalogはメタデータを自動的にキャプチャします。監査テーブルと課金テーブルに対してSQLクエリを実行するだけで、誰がどのブランチをいつ作成したのか、またそのブランチの実行維持にどれだけのコストがかかっているのかを特定できます。

また、データベースインスタンスの数も劇的に減少します。6つの環境インスタンス（prod、staging、UAT、QA、perf、demo）で構成されていた世界が、親にリンクされた長期実行ブランチの階層を持つ1つのLakebase親インスタンスへと集約されます。プロビジョニング、監視、パッチ適用に使用されていたインスタンスは、本番環境と同じデータ構造を持ち、本番環境と同じポリシーで管理され、必要に応じてわずか1秒で本番環境の状態にリセットできる論理ブランチになります。

さまざまなルール（コンベンション）を適用することで、親として多様なタイプのブランチを作成できます。一般的な方法としては、データベーススキーマと参照データを含むブランチを維持することです。これにより、誰でもそこからブランチを作成してテストデータを投入したり、実際のデータを作成する自動テストを実行したりできるようになり、stagingや他のブランチとの競合を避けることができます。

今すぐ取り組むべきこと：権限モデル

プラクティス10：パート2のプレイブックでは、「一度設計したガバナンスをブランチごとに継承する」アプローチについて説明しました。これがどのように実装されるかを見てみましょう。

設計作業は実行時の障壁（ゲート）にはなりません。これは、共通のタスクによって強制できる構造的な設計です。

チームの規模が拡大したり、エージェントが追加されたりする前に、今決定すべき事項は以下の通りです。

各階層からのブランチ作成。本番環境（production）からのフォークは、stagingやフィーチャー（feature）からのフォークとは異なる権限が必要です。デフォルト設定は「フィーチャーはエントリー（最下位）階層からフォークし、本番環境からは決してフォークしない」とすべきです。本番環境のフォークは、ホットフィックスや復旧フロー専用に制限します。
階層間のプロモーション。「フィーチャーからstaging」へのプロモーションは、コードレビューの対象です。「stagingから本番環境」へのプロモーションは、リリース調整の対象です。これら2つは、それぞれ異なるレビュー担当者が存在する個別のゲートであり、ビジネスチームと開発チームの独立性を確保します。
読み取りと書き込み。ブランチ上の本番環境と同等のデータに対する読み取りアクセス権は、そのブランチへの書き込みアクセス権とは異なります。多くのエンジニアリング職種は読み取り権限を必要としますが、書き込み権限が必要なのはごく一部です。
Unity Catalogポリシー。 Unity Catalogポリシー（マスキング、行フィルター、列レベルの権限など）は、本番環境に適用されます。これらのポリシーは、デフォルトで配下のすべてのブランチに継承されます。階層固有の例外（例：負荷テスト用に合成されたPIIを使用するQA階層など）は、一度宣言するだけで適用されます。
監査証跡のキャプチャ。すべてのブランチ作成、プロモーション、マイグレーションの適用、アクセスパターンが、クエリ可能な1つの場所に集約されます。

これをチーム規模で機能させるための原則は、 「ロールが宣言し、ポリシーが強制する」ことです。プラットフォームエンジニアは、階層構造、権限モデル、プロモーションパス、およびUnity Catalogのポリシー体制を宣言します。ポリシーは、宣言された内容と矛盾する移行を拒否します。人間やエージェントが、別の方法で操作を再試行することによって、宣言された境界をオーバーライドできる余地はありません。

これは、チームが50人の開発者規模になり、エージェントが人間によるレビューが追いつかないほどの速さでブランチを作成し始める前に、今行うべき作業です。フレームワークは、共通のルールやガードレールによってチームを結束させるものです。それ以外のすべての要素は、その内部で動作します。

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

20年前、2003年のエッセイ『Evolutionary Database Design』の結びには、次のような言葉が記されていました。

「ここで説明した手法を使用することは、多くの作業が必要なように思えるかもしれませんが、実際には膨大な人員は必要ありません。多くのプロジェクトにおいて、30人ほどの開発者がおり、チーム規模（QA、アナリスト、マネジメントを含む）は100人近くに達していました。日常的に、メンバーのワークステーション上にはさまざまなスキーマのコピーが100個ほど存在していました。それでも、これらすべての活動に必要なのは、1人の専任DBAと、プロセスとワークフローの仕組みを理解している数人の開発者だけでした。」

この議論は、5つの補強材料を伴って2026年にも引き継がれます。

1. 比率は維持され、DBA1人あたりの余力が増加します。約100人に対して1人の専任DBAという比率で、同様に100以上のブランチが同時に並行稼働していても、ブランチ作成がわずか1秒のメタデータ操作になったため、ブランチあたりのコストは低くなります。重要なのは比率そのものではありません。DBAがその時間を何に費やしているかです。

2. 業務がより上位のレイヤーへとシフトします。2003年にはインフラやスキーマのプロビジョニング、アクセス制御、そして時折発生する手動介入に費やされていた時間が、現在ではブランチポリシーの設計、マスキングポリシー、プロモーションワークフロー、および監査証跡のオブザーバビリティへと移行しています。具体的な成果物としては、すべてのPRに投稿するスキーマ差分ボット、開発ブランチを毎晩リセットするスケジュールジョブ、ブランチのライフサイクルとTTL準拠を追跡するオブザーバビリティダッシュボード、スキーマ検証に基づいてマージを制限するCI定義などが挙げられます。これはプラットフォームの設計業務であり、以前よりもはるかに高次の仕事です。

3. エージェントの登場。2003年のエッセイが考慮する必要のなかった要素が、コードを記述する「エージェント」です。Neonの報告によると、1日に約50万個のブランチが作成されており、その80%以上がエージェントによるものです。1人のDBAがチケット管理でこれほどの量を処理することは不可能です。役割をプラットフォームアーキテクトへと進化させることこそが、エージェント規模の運用に対応できる唯一の方法です。

4. 数値が具体的になります。従来のモデルでは、6人の開発者チームは通常、スプリントあたり30件以上の運用チケット（プロビジョニング、スキーマレビュー、データ更新、アクセス権付与など）を生成します。ブランチネイティブモデルでは、スプリントあたり5件未満の価値の高いポリシーレビューに抑えられます。DBAの定型業務（toil）は週20時間以上から5時間未満に減少し、MTTR（平均復旧時間）は4時間以上から30分未満に短縮されます。この定型業務の削減により、DBAは開発者とペアを組んで、開発中の機能に最適なソリューションを見つけることに注力できるようになります。

5. 監査証跡が戦略的なダッシュボードになります。かつては3つのサービスと3つのクエリ言語を相互参照する必要があった作業が、今ではプラットフォームのシステムテーブルに対する1つのSQLクエリで完結します。すべてのブランチ、すべてのアクション、すべてのコスト、すべてのガバナンスイベントが1つの場所に集約されます。DBAが手動でこのビューを構築する必要はありません。プラットフォームがそれを自動で行います。

『Refactoring Databases』（2006年）のまえがきで、Martin Fowlerは、本書がIDEがコードのリファクタリングを自動化するのと同じように、データベースのリファクタリングを自動化するツールへの「ほんの第一歩」となることを望んでいました。ブランチ作成こそが、その次のステップです。Fowlerが2006年に望んでいた、コードと同じスピードで行われる規律あるデータベース変更を、現在のプラットフォームが提供しています。DBAが規律を設計し、プラットフォームがそれを適用します。

新しい役職名はさまざまです（プラットフォームエンジニア、データベースプラットフォームオーナー、あるいは依然としてDBAと呼ばれることもあります）。しかし、その本質は同じです。他のすべてのメンバーがその中で活動するためのフレームワークを設計する人物です。

同等の能力を持つエージェント

プラクティス11：パート2では、同様のブランチ作成機能を備えた、実務担当者としてのコーディングエージェントについて説明しました。これについて詳しく見ていきましょう。

エージェントがアクセスできるのはブランチであり、本番環境ではありません。Jenに適用されるのと同じワークフローのルールが、エージェントにも適用されます。テストは、エージェントが変更または削除できるモックに対してではなく、ブランチ上の実際のデータベースに対して実行されます。誰がマイグレーションを作成したかに関わらず、すべてのPRにスキーマの差分が反映されます。Jenを保護するポリシーは、エージェントも保護します。

しかし、ポリシーだけでは十分ではありません。指示を与えられないエージェントは、ジュニア開発者のようなものです。

ジュニアデベロッパーは、機能のチケットを渡され、それ以上の指導がない場合でも、コンパイル可能なコード、パスするテスト、そしてクリーンに適用できるマイグレーションスクリプトを作成することができます。しかし、そのコードはコードベースの他の場所にあるロジックを重複させ、二重定義を持ち込んでしまう可能性があります。マイグレーションでは、正しい名前で間違った型のカラムが追加されてしまうかもしれません。テストは、正常系（ハッピーパス）しか実行しないためにパスしているだけかもしれません。これらの失敗は、CIがグリーン（成功）で実行されている間は表面化せず、6週間後に他の誰かがその作業を拡張しなければならなくなったときに初めて明らかになります。

エージェントも同様のことを行いますが、はるかに高速で、かつ大量に行います。

明確なガイダンスがない場合、エージェントは以下のようなことを行います。

コードベースにすでに存在するパターンを再発明する。
一見正しそうに見えるものの、定義されたリファクタリングの移行メカニズムをスキップするようなスキーマ変更を作成する（例：最初にデータを移動せずにカラムを削除する、既存の行を更新せずに NOT NULL カラムを追加するなど）。
本番環境に存在するデータの形状ではなく、自分が想定したデータの形状に対してパスするテストを作成する。
適用はできるものの、ロールバック時に不整合な状態を引き起こすマイグレーションを作成する。
わずかな変更に対応するために、抽象化の上にさらに抽象化を重ねる。

サブストレート（基盤）は、グリーンバーを信頼できるものにします（モックはなく、ブランチ上の本物のデータベースを使用します）。しかし、コードをメンテナンス可能にするわけではありません。

チームは、4つの強化策を通じてコードのメンテナンス性を確保します。

ガードレール：権限モデル。 エージェントは本番環境からブランチを作成することはできず、ティア間でプロモートすることもできず、自分が所有していないティアにマイグレーションを適用することもできません。サブストレートがこれを拒否します。
パターン：定義されたリファクタリング。 databaserefactoring.com にある2006年のカタログでは、明確な移行メカニズムを伴う70以上のリファクタリングが定義されています。「Split Column（カラムの分割）リファクタリングを適用する」よう指示されたエージェントは、「このカラムを分割する」よう指示されたエージェントとは異なるマイグレーションを生成します。
ワークフロー：ソース管理（SCM）ステートマシン。 エージェントは、ブロッキングゲートで区切られた一連のステート（状態）に従います。サブストレートは、宣言されたコントラクトを満たさない遷移を拒否します。
レビュー：PRループにおける人間。 すべての PR でスキーマの差分（diff）が表示され、DBA がレビュー経路に含まれます。パート2で再構成されたプラクティス#1により、これが非同期化されました。チーム規模でエージェントが関与する場合、この非同期レビューこそが、テストでは検出できなかったズレを捉えるものになります。

SCM ワークフローは、最も重要な役割を担うものです。Lakebase App Dev Kit において、*ソース管理（SCM）*は単なるコードブランチ以上のものをカバーします。それは、ペアブランチング（パート1で紹介した、単一のユニットとして管理されるコードブランチと Lakebase ブランチ）をカバーします。Lakebase App Dev Kit の共通サブストレートの機能として提供されるこのペアブランチングは、階層に矛盾するマージ、ブランチに伴うマイグレーション、CI ゲート、親ティアにマイグレーションを適用するマージなど、共通のガードレールを強制します。この開発キットは、このSCM ワークフローを実行可能なステートマシンとして提供します。

上記の図4は、開発中の5つのステート（scaffold-complete, feature-claimed, pr-ready, ci-green, merged）を示しています。異なるステート間の各遷移は、CLI コマンド（lakebase-scm-claim-feature-branch, lakebase-scm-prepare-pr, lakebase-scm-wait-ci, lakebase-scm-merge）によって実行されます。各 CLI コマンドは、処理を実行する前に前提条件を検証し、遷移を実行して、新しいステートを .lakebase/workflow-state.json （スキーマ検証済みのゲートサーフェス）に書き込みます。ゲートの検証に失敗した場合、マシンは前のステートで復旧可能な状態に保たれます。これらのゲートは、単なる推奨事項ではなく、ブロッキング（処理をブロックするもの）です。

エージェントはこれらの CLI を呼び出すため、並行したパスを独自に作り出すことはできません。サブストレートは、前提条件の検証に失敗した場合、ステートマシンの進行を拒否します。間違ったティアを親とするフィーチャーブランチは拒否され、CI がグリーンになる前のマージの試みは拒否され、不整合なステートファイルは次のゲートをブロックします。ハンドオフの契約はスクラムマスターの役割が所有し、サブストレートがそれを強制します。構造的な決定（ティアの階層、フィーチャーのソースティア、プロモーションパス）はアーキテクトまたはスクラムマスターに帰属し、記録され、サブストレートによって尊重されます。サブストレートがティアや親を勝手に作り出すことはありません。宣言された内容を尊重し、それに矛盾する遷移を拒否します。

これこそが、これまでのチームによるエージェントの使い方を打破するフレームワークです。単純な統合では、エージェントをチャットウィンドウのシニアエンジニアのように扱います。コンテキストを投入し、出力を求め、それを繰り返します。これは開発者1人の規模では機能しますが、チーム規模では破綻します。なぜなら、エージェントの「コンテキスト」をレビュー、ガバナンス、または再現することができないからです。代わりに、エージェントをジュニアデベロッパーとして扱ってください。実行可能なステートマシン内で、文書化された限定的なタスクを与え、その出力をスキーマに対して検証し、ゲートを進め、それを繰り返します。サブストレートがこれを強制し、ワークフローのステートファイルが API となります。

チーム規模のプラクティスに関するプレイブックのエントリー

パート2では、「2026年に向けた新たなプラクティス」におけるプラクティス#10と#11を紹介しました。

プラクティス#10：一度設計されたガバナンスを、ブランチごとに継承する

ルール。 権限モデル、アクセス制御を管理する Unity Catalog ポリシー、および監査ログのキャプチャは、トランク上で一度設計され、すべての下位ブランチに自動的に継承されます。

なぜこれが現在、永続的な習慣となっているのか？ チーム規模において、ガバナンスはデベロッパーが意識すべき規律ではなく、DBA またはプラットフォームエンジニアの職能であるべきだからです。ブランチは数秒で作成・破棄されます。ブランチごとに手動でガバナンスを設定していては、ブランチ作成によって得られる時間短縮の効果が相殺されてしまいます。

メカニズム：

ティア階層の宣言：どの長期運用ブランチが存在するか、それらの親リンクは何か、各ティアがどのようなガバナンス体制を持つか。
権限境界の宣言：誰が各ティアからブランチを作成できるか、誰がティア間でプロモートできるか、誰が読み取りと書き込みを行えるか。
Unity Catalog ポリシー継承の宣言：マスキング、行フィルター、およびどのカラムレベルの権限がデフォルトで親から継承されるか。ティア固有の例外は一度だけ宣言されます。すべての Unity Catalog ポリシータイプにわたる自動伝播の展開が完了しつつあります。最終的な状態を目指してフレームワークを設計してください。
監査ログキャプチャの宣言：すべてのブランチ作成、プロモーション、マイグレーションの適用、アクセスパターンが、クエリ可能なシステムテーブルに自動的に記録されます。
DBA またはプラットフォームエンジニアがポリシーを通じて強制します。宣言されたモデルに矛盾する遷移は拒否されます。

アンチパターン。 実行時にブランチごとにガバナンスを設定すること。一度だけ宣言することの意義は、人間がレビューするよりも速いスピードでブランチが作成される場合でも、フレームワークが維持される点にあります。ブランチごとに手動で設定を行うと、ブランチ作成によって解消されたはずのボトルネックが再発してしまいます。

Jenのチームによる拡張。 Jenのプラットフォームエンジニアまたはdbaは、プロジェクト作成時に階層構造を宣言しました。Jenや彼女のチームメイト、またはチームのエージェントが作成するすべてのブランチは、宣言されたマスキング、権限、および監査設定を継承します。チームが新しい階層を追加すると、フレームワークは新しい親リンクを記録します。進行中の機能は元の親を維持し（遡及的な親の再設定は行われません）、新しい機能は新しいエントリ階層からフォークします。

実践#11：同じブランチ作成機能を備えた、実務者としてのエージェント

ルール。 エージェントは、SCMワークフローの実行可能な状態マシン（5つの状態、状態間のブロッキングゲート、スキーマ検証済みの状態ファイル）の内部で動作します。Jenとエージェントには同じワークフロールールが適用され、誰が操作しているかに関わらず、共通の基盤がそれらを強制します。

なぜこれが今、持続可能な習慣となっているのでしょうか？ ブランチの作成はメタデータ操作であるため、エージェントによる大量の処理が可能です。エージェントが活用するために開発された基盤は、宣言された階層構造や記録されたゲート状態と矛盾する遷移を拒否できます。頼りにできるチャットウィンドウのコンテキストはありません。ディスク上のアーティファクト（workflow-state.json）のみが、ゲート遷移間の境界を越えます。

仕組み：

SCM状態マシンには5つの状態（scaffold-complete, feature-claimed, pr-ready, ci-green, merged）があります。各遷移はCLIによって駆動され、各CLIは処理を実行する前に前提条件を検証します。
ゲートのインターフェースは .lakebase/workflow-state.jsonであり、scm-workflow-state.schema.jsonに対して検証されます。すべての遷移において、新しい状態と、次のゲートが必要とする不変条件が書き込まれます。
構造的な決定（階層構造、機能ごとのソース階層、プロモーションパス、ハンドオフ契約）は役割（アーキテクトまたはスクラムマスター）に帰属し、記録された後、基盤によって強制されます。
エージェントはCLIを呼び出します。基盤がルールを強制するため、エージェントがそれを回避することはできません。ゲートの検証に失敗した場合、状態マシンは前の状態で回復可能なままとなり、エージェントが「異なる方法で再試行する」ことはありません。
pr-readyからci-greenの内部で実行されるCIゲートは、ブランチ上で実際のPostgresを実行し、スキーマの差分がPRに投稿されます。エージェントの成果は、実際のデータベースの状態に照らし合わせて評価されます。

アンチパターン。 チャットウィンドウでエージェントをシニアエンジニアのように扱い、「コンテキストをダンプして出力を求める」という手法は、単一の開発者規模では機能しますが、チーム規模では破綻します。なぜなら、その「コンテキスト」をレビュー、管理、または再現することができないからです。代わりに、artifact-as-APIモデルを使用してください。エージェントはworkflow-state.jsonと、そのフェーズ用に文書化された入力を読み取り（READ）、文書化された出力を書き込み（WRITE）します。検証ツールがチェックを行い、契約が満たされた場合にのみ、次のゲートが起動します。

Jenのチームによる拡張。 Jenのチームのすべてのエージェントは、Jenや彼女のチームメイトと同じ5状態マシン内で動作します。スクラムマスターの役割がハンドオフ契約を所有し、基盤はそれらを満たさない遷移を拒否します。エージェントは、誤った階層からフォークされた機能をリリースすることはできません。CIがグリーンになる前にマージすることはできません。スキーマ差分アーティファクトをバイパスすることはできません。誰が、または何がアクションを開始したかに関わらず、フレームワークは維持されます。

その上に織り込まれたオプトインレイヤーとしてのTDD

実践#11は、SCMワークフローをベースラインとして確立します。エージェントも人間も同様に、すべてのキット利用者がこれに従います。TDDは、テスト駆動の規律を望むチーム向けに、そのベースラインの上に重ねられる個別の検討事項です。これはオプトインですが、SCMゲートはどの経路をたどるかに関わらず必須です。

TDD以前に、なぜテストが重要なのか：エージェントがコードを作成する場合、スケールする唯一の強制力はテストです。Kent Beckは、2026年のPragmatic Engineerのインタビューで、この失敗モードを公に指摘しました。彼は、AIエージェントがテストをパスさせるためにテスト自体を削除してしまうのを防ぐのに苦労しています。ループ内の何もエージェントにシステムの実際の形状に向き合わせない場合、グリーンバーを満たすのは容易です。モックを使えばこれが極めて容易になり、インメモリの代替手段でも同様です。

ブランチ作成により、データレイヤーにおけるグリーンバーの信頼性が担保されます。エージェントがテストを実行するのは、実際のブランチ上にある実際のデータベースです。スキーマ制約は一致しない行の挿入を拒否し、外部キーは孤立したデータを拒否し、実際のデータの形状はモックが黙って吸収してしまっていたであろう仮定を浮き彫りにし、エージェントはテーブルをドロップできません。これらのガードレールにより、適合を偽装するためのコストが高くなります。

しかし、基盤は必要条件であって十分条件ではありません。テストはどこからか調達する必要があります。エージェントがテストを書くのであれば、エージェントはそれを削除することもできます。これこそが、TDDが埋めるギャップです。

TDDワークフローは、SCMワークフローの上に重ねられます。これはSCM状態のfeature-claimedとpr-readyの間で実行されます。ブランチ操作のためにSCMを呼び出しますが（サイクル実験ブランチは内部でSCMプリミティブを使用します）、SCMから呼び出されることはありません。依存関係は一方向です。TDDレイヤーを望まないチームは、機能ブランチ上で直接編集を行うことで機能をリリースでき、それでもすべてのSCMゲートを満たすことができます。

Lakebase App Dev Kit は、役割ごとの独自のエージェントとゲート検証ツールを備えた、2つ目の状態マシンとしてTDDワークフローを提供します：

Spec-author は、依頼者のナラティブを、スキーマ検証済みの構造化された機能アーティファクトに変換します。
Architect-reviewer は、機能の非機能要件とアーキテクチャ原則をアーキテクチャ上の決定にマッピングし、architecture.jsonと説明文として出力します。
Test-strategist は、テストリストと受入基準ごとのシナリオを作成し、test-list.jsonとレンダリングされたMarkdownとして出力します。すべてのNFRには少なくとも1つの受入基準（AC）があり、すべてのACにはシナリオがあります。
Scrum-master は、ビルドサイクルをオーケストレートします。各サイクルは実験ブランチをフォークし（内部でSCM基盤を使用）、ドライバーエージェントを実行して次のACを実装し、ナビゲーターエージェントを実行して結果をレビューおよび検証します。
Driverとnavigator は、インナーループのテスト作成者とコード作成者であり、ペアを組んでRED-GREEN-REFACTORを行います。

各役割には、スキーマに対して検証される、文書化された入力と出力があります。各エージェントは文書化された入力のみを受け取り、次の役割が実行される前に出力が検証されます。アーティファクトは役割間のAPIであり、スキーマは型チェックです。アーティファクトの欠落は、ゲートの検証失敗と同様に扱われます。不正な形式のアーティファクトは、欠落しているものとして扱われます。TDDレイヤーは、実践#11がSCM向けに確立したのと同じartifact-as-APIモデルを借用しています。

TDDレイヤーは、『Companion: Lakebase App Dev Kit』（オープンソース、人間の実務者向けのコンパニオン電子書籍付き）に含まれています。SCMおよびTDDの状態マシン、役割ごとのエージェント契約、アーティファクト適合性チェック、およびゲート検証ツールはすべて、任意のオーケストレーター（キット、IDE拡張機能、CIジョブ、人間のシェルセッション）が呼び出せるCLIとして提供されます。

要約すると、SCMがベースラインであり（実践#11）、TDDはその上のレイヤーです。ブランチ作成によってテストの信頼性が担保され、TDDによってテストが最優先され、キットによって両方のワークフローが実行可能になります。

Jenのチームが示していること

パート1 では、Jenが1つの機能を開発する手順を説明しました。彼女はコードブランチとLakebaseブランチをペアにし、本番環境と同等のデータに対して実際のマイグレーションを数秒で実行し、モックなしでテストし、レビュー用にスキーマ差分をインラインで投稿したPRを開き、マイグレーションを適用して一時的なブランチをクリーンアップした状態でマージしました。データベースの変更は、通常の開発の一部となりました。

パート2では、プレイブックを定義しました。それは、2003年からの7つのプラクティス、そのうち5つを2026年まで理想にとどまらせていた制限事項、ブランチ機能の登場によって再構成された同じ7つのプラクティス、そしてこのテクノロジーが個々の開発者に対して可能にする2つの新しいプラクティスです。日常業務における9つのプラクティスと、チーム規模で新たに生まれる2つのプラクティスがあります。

パート3では、このプレイブックをチームに適用しました。階層トポロジーを定義し、長期実行されるブランチが1つのLakebase親の内部にどのように配置されるか、権限モデルがどのようにプラットフォームエンジニアの設計成果物となり、一度宣言されればサブストレート（基盤）によって強制されるか（プラクティス10）を説明しました。また、2003年の人員配置に関する議論を5つの観点から補強し、DBAの役割がプラットフォームアーキテクトへとどのように進化を遂げるかを示しました。エージェントは、SCMワークフローの実行可能な状態マシンの内部で、同じ機能に基づいてワークフローに参加します。誰が、あるいは何が操作しているかに関わらず、サブストレートがゲートを強制します（プラクティス11）。TDDは、その上に織り込まれたオプトインのレイヤーです。これを希望するチーム向けに、専用の役割、ゲート、成果物契約を備えたテストファーストの規律を提供します。

『Companion: Plugin Walkthrough』では、VS CodeおよびCursor向けのLakebase SCM Extensionをエンドツーエンドで解説しています。

『Companion: Lakebase App Dev Kit』は、人間の実務者向けの副読本e-bookを付属しており、上記のTDDワークフロー（SCMおよびTDDの状態マシン、役割ごとのエージェント、ゲートバリデータ、そしてエージェントをチームに安全に導入するための成果物契約）をカバーしています。

この手法は20年もの間、明確でした。技術的な機能は2026年に登場しました。人間とエージェントの実務者の双方に向けたプレイブックが、現在運用可能になっています。ジェンのチームは50人の開発者と多数のエージェントで構成されていますが、ワークフローは同じです。

結論：データベースをブランチする機能により、開発チームはデータベースのプロビジョニング、実際のスキーマに対するテストの構築、PR作成ごとの個別データベースに対するCIの実行、そしてエージェントによる同様の作業の実行を、すべてUnity Catalogのガバナンスフレームワークによるポリシー適用のもとで行うことができるようになり、非常に高い柔軟性が得られます。

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