本シリーズの第1部では、Backstageの基盤データベースをDatabricks Lakebaseに移行することで、リスクの高いスキーママイグレーションを1秒のブランチ作成とテスト操作に変換できることを紹介しました。しかし、セキュリティおよびガバナンスチームが依然として運用データベースをブラックボックスとして扱っている限り、開発サイクルの高速化だけでは十分ではありません。
従来のアーキテクチャでは、アプリケーションデータベースとデータレイクは完全に異なるセキュリティパラダイムに属していました。Backstageのインフラストラクチャ所有権グラフは、独立したRDSインスタンスに保存され、複雑なIAMロールとPostgresネイティブ権限によって管理されています。一方、ウェアハウスのデータはデータチームがUnity Catalogを使用してガバナンスを適用しています。Unity CatalogはDatabricksが作成したオープンソースのフレームワークで、データ、AI、そして現在は運用データベースに対しても統一されたガバナンスレイヤーを提供します。アクセス制御、監査証跡、系列、コンプライアンスをプラットフォーム全体で一元的に管理できます。
RDS上の単一テーブルの削除を監査するには、CloudTrail（IAMプリンシパル）、pg_stat_activityまたはpgauditログ（SQLステートメント）、CloudWatch（タイムスタンプ）の3つのサービス、3つのクエリ言語、3つのアクセスポリシーを相互参照する必要がありました。運用データベースはコンプライアンス上のサイドチャネルとなっていました。
BackstageをLakebaseにポイントしたとき、データの保存場所が変わっただけでなく、アクセスポリシーの場所も変わりました。LakebaseはDatabricks内にネイティブに組み込まれているため、Unity Catalogは運用Postgresデータベースに直接拡張されます。このPOCでは、Lakehouse Federationを使用してBackstageカタログをUnity Catalogの外部カタログ（lakebase_bs）として公開しました。これにより、標準のUC権限で誰が何を見られるかを制御でき、Postgresレベルのロール管理は不要になります。このPOCではBackstage用のエンドツーエンドの行レベルセキュリティポリシーは構築しませんでしたが、アーキテクチャ的には、機密性の高い課金テーブルを保護するのと同じRLSルールをこれらの運用テーブルに直接適用できます。「運用」と「分析」の壁は物理的な境界ではなくなり、単なるアクセスパターンになります。
第1部の1秒のコピーオンライトブランチを覚えていますか？従来の設定では、開発者がデータベースを1時間だけブランチして破棄したことをセキュリティエンジニアに証明するのは手動の作業でした。Lakebaseでは、運用データベースに対するすべてのコントロールプレーン操作が自動的にsystem.access.auditに記録されます。第1部の災害復旧実験から正確なブランチ操作を監査ログに問い合わせて検証しました。すべてのブランチ作成と削除が記録され、各イベントは特定のOAuthユーザーIDと送信元IPに関連付けられ、自動的にキャプチャされ、Unity Catalog内の他の監査テーブルとまったく同じ行レベルセキュリティ制御の対象となります。CloudTrailの相互参照は不要、RDSログの解析も不要、1つのSQLクエリで完了します。
ガバナンスチームは誰がブランチを作成したかだけでなく、そのコストも知りたいと考えます。従来のAWS環境では、一時的なRDSインスタンスのコストを追跡するにはカスタムCloudWatchタグ戦略が必要で、短期間のワークロードを見逃すことがよくありました。LakebaseはUnity Catalogのシステム課金テーブルとネイティブに統合されているため、コンピュートコストは自動的にproject_id、branch_id、endpoint_idごとに分類されます。このPOCでは、本番ブランチは31.6130 DBU、削除されたテストブランチは0.0107 DBUと個別に帰属されました。監査証跡とコスト証跡はまったく同じ場所で管理されます。
毎日ブランチを作成するチームにとって、このガバナンスはコンプライアンスの質問に答えます：誰がいつ何をしたか、そしてそのコストはいくらかを証明できるか？答えはイエスです。1つのSQLクエリで3つのサービスを代替できます。しかし、第1部のブランチングワークフローを採用する開発チームにとってもう1つの重要なガバナンス質問があります：チームがスプリントごとに数十のブランチを作成する場合、ガバナンスはどうなるのか？第1部では、すべての機能ブランチとプルリクエストに独自の分離されたデータベースコピーを提供するワークフローを説明しました。6人の開発者からなるチームが2週間のスプリントを実行する場合、30〜40のブランチを作成および破棄する可能性があります。これは30〜40の本番データのコピーであり、それぞれに機密フィールド（顧客のPII、財務記録、医療データ）が含まれている可能性があります。
ここで、Unity Catalogのブランチレベルのガバナンスが単なる便利さではなく、耐荷重性を持つものになります。Lakebaseブランチが作成されると、Unity Catalogの属性レベルのマスキングポリシーが自動的に新しいブランチに伝播します。開発者は機能ブランチでマスクされていない本番データを見ることはありません。それは誰かが設定を覚えているからではなく、ガバナンスレイヤーが作成時に強制するからです。PRテストを実行するCIブランチは本番と同一に管理されます。破壊的なシナリオを実行するQAブランチも本番と同一に管理されます。ポリシーの適用を忘れたために機密データが漏洩する「非本番例外」は存在しません。
Perforceの2025年データコンプライアンスレポートによると、組織の60％が機密データが適切に匿名化されていない非本番環境で侵害や盗難を経験しています。環境が数秒で作成および破棄される場合、開発/テスト環境をプロビジョニングする際の手動データマスキングはスケールしません。ガバナンスは自動でなければならず、そうでなければ実現しません。
監査証跡とコスト帰属データは、DBAの役割が受動的なチケット処理から戦略的なプラットフォームアーキテクチャへと静かにシフトしていることを示しています。現在、DBAの時間の多くは、環境プロビジョニング、スキーマレビュー、データリフレッシュ、アクセス権付与などの運用リクエストに費やされています。6人の開発者チームはスプリントごとに30以上のチケットを生成する可能性があり、DBAのカレンダーはキューになります。DBAを価値あるものにする専門知識（データ整合性、パフォーマンス、ガバナンスの深い理解）は、反復的なプロビジョニング作業に埋もれてしまいます。
ブランチングがセルフサービスになり、ガバナンスが自動化されると、その反復作業はなくなります。開発者は1秒で独自の環境をプロビジョニングします。スキーマ変更はプルリクエストで非同期にレビューされます。DBAはCIによって投稿されたフォーマットされたスキーマ差分を確認し、自分のスケジュールでレビューし、通常のPRワークフローを通じて承認または変更を要求します。時間ができたことで、レビューはより深くなります。DBAはチームメンバーが本番の既存データと構造を理解するのを支援し、より良いソリューションに到達するために協力し、データ整合性とガバナンス基準を維持する徹底的なレビューを実施します。データマスキングはポリシーによって強制され、手動介入は不要です。コスト帰属は自動化され、毎月の調整作業は不要です。
解放されるのは、実際にDBAの専門知識を活用する作業です。ブランチングポリシーの定義、ガバナンスルールの設計、プロモーションワークフローのアーキテクチャ、パフォーマンスのチューニング、セルフサービスを安全にするためのガードレールの確立。DBAは作業を行うことから、作業の行われ方を設計することへとシフトします。スプリントあたり30以上の運用チケットから5未満の高価値ポリシーレビューへ。上で実証された監査証跡は単なるコンプライアンスの成果物ではなく、DBAの新しい戦略的ダッシュボードであり、プラットフォームがどのように使用されているか、次にどこに投資すべきかをリアルタイムで把握できるツールです。
2つのオープンソースツール（どちらもDatabricks Appsとしてデプロイされ、同じUnity Catalog権限と監査証跡によって管理される）がこのループを閉じます。
LakebaseOpsはプラットフォームが自律的に実行するものです。3つのエージェント（プロビジョニング、パフォーマンス、ヘルス）が、かつてDBAがチケット化していた51のタスクを置き換えます。そのうち7つはスケジュールされたDatabricksジョブとして実行され、DBAが手動で維持していたpg_cron crontabを置き換えます。監視UIは、ライブpg_statメトリクス、スロークエリの回帰、ブランチTTLの強制、9つのKPI採用ダッシュボードを表示します。移行ウィザードは、10のソースエンジン（Aurora、RDS、Cloud SQL、AlloyDB、Cosmos DBなど）をLakebaseと比較し、AWSおよびAzure APIからのライブ価格を提供します。
Lakebase MCPは、DBAがプラットフォーム上で行う作業です。Model Context Protocolサーバーは、MCP対応の任意のAIエージェント（Claude、Copilot、GPT）に46のツールを公開します。DBAはpgAdminを開くのをやめ、意図を説明し始めます。
2つの設計上の選択により、安全性が確保されます。第一に、二重層ガバナンス：SQLステートメントガードとツールごとのアクセスガード。4つの事前構築済みプロファイル（read_only、analyst、developer、admin）は、上記のUCアクセスパターンにマッピングされます。コーディングアシスタントはread_onlyとして実行され、物理的にテーブルを削除できません。
第二に、すべてのクエリは帰属可能です。サーバーは各ステートメントを発生元ツールでタグ付けします。
ブランチレベルのコスト帰属と組み合わせることで、「午前4時のCPUスパイクを引き起こしたのは、どのブランチのどのエージェントか？」という質問に1つのSQLクエリで答えることができます。
LakebaseOpsはチームのために実行され、Lakebase MCPはチームと共に実行されます。どちらも上記のガバナンス姿勢を継承します。
本シリーズの第3部では、最終的な成果を見ていきます。Backstage内のインフラストラクチャ所有権データをクラウドの課金データと単一のSQLクエリで直接結合します。