Databricksのビュー置換が権限を保持へ：12月2日の変更前にCI/CDと管理タグを検証する

結論：ビューの置換と権限の変更を別の完了条件で管理する

編集上の提案：ビューを再定義するジョブには、SQLの実行成功だけでなく、置換後に誰がどの列・行へアクセスできるかの試験を加えます。既存権限の消失を利用して公開範囲を初期化していた場合は、権限を明示的に管理する処理と定義の更新処理を分けてください。

編集上の反論：メタデータの保持は、再デプロイ時の権限欠落を減らす方向の変更です。ただし、以前の権限が現在のデータ公開要件にも適切とは限りません。新しい列や新しい参照元を追加したときに、保持された権限で意図しない情報が見える可能性を、業務上の公開範囲と照合します。

背景と技術的要因：定義を戻しても認可状態は戻るとは限らない

確認済み事実：公式予告では、CREATE OR REPLACE VIEWは削除・再作成に代えてその場で更新する動作となり、権限・タグ・コメントが既定で保持されます。列に管理タグが付いている場合、その列の削除前にタグを解除しなければCANNOT_DROP_TAGGED_COLUMNで失敗すると説明しています。

編集上の分析：問題になるのは、定義ファイルだけを正本として扱い、認可や分類ラベルの状態をデプロイ対象から外していた構成です。タグに依存するアクセス制御と、ビューを変更する操作を別々にレビューしないと、ジョブを通すためのタグ解除がデータ保護を弱める変更になり得ます。

適用日・対象・Runtime差：予告と構文の適用範囲を照合する

日付の区別：公表資料のLast published＝2026-10-13。日本語の今後の変更ページの最終更新＝2026-10-28。SQL構文ページの最終更新＝2026-10-12。適用開始予定＝2026-12-02。確認日＝2026-10-30。最初の公表日＝null。全環境への適用完了日＝null。非推奨化期日＝nullです。Last publishedを初回公表日と断定しません。

確認済み事実：Databricks公式KBは、Runtime 19以降のクラシック汎用・ジョブコンピュート、SQLウェアハウス、ノートブック・ジョブのサーバーレス、Spark Declarative Pipelinesを変更対象として挙げています。SQL構文資料では、メタデータ保持を制御する句はUnity Catalog管理ビュー向けで、Runtime 18.3以降およびDatabricks SQLが対象とされています。

確認済み事実：同じSQL構文資料は、保持指定を省略した場合、Runtime 18.3では保持せず、19以降では保持すると説明しています。編集上の提案：日付による変更予告とRuntimeによる既定値を一つにまとめず、ワークロードごとの実行場所・版・ビュー種別で確認してください。全Runtimeやhive_metastore、一時ビューへ一律に一般化しません。API・SDKの新しい必須バージョンは確認できずnullです。

アーキテクチャ・実装・IaC：定義、権限、タグを同じ変更単位で照合する

編集上の提案：SQLファイル、ノートブック、dbt等の生成SQL、ジョブ、Terraformから実行するSQLを検索し、対象ビュー、実行ID、コンピュート、依存するBI・アプリを一覧にします。生成されたSQLまで確認し、テンプレートだけを見て置換動作を判断しないでください。

編集上の提案：置換前後に、ビューへの直接付与、カタログ・スキーマからの継承、所有者、コメント、通常タグ、管理タグを採取して比較します。Terraformが管理する権限とSQL側で残る権限の責任を整理し、次のapplyで意図しない権限の復元・削除が起きないか、使用中のプロバイダーで検証してください。

確認済み事実：公式資料はメタデータを保持するCOPY句と保持しないNOCOPY句を案内しています。管理タグは通常のメタデータ破棄の例外です。完全な構文は公式SQL参照で確認してください。編集上の提案：保持しない設定を機械的に全ビューへ付けず、継続すべき権限と明示的に取り消す権限を先に決めます。

編集上の提案：管理タグ付き列を削除する場合、タグ管理者の承認、影響するポリシー、削除後の列構成を確認します。タグ解除から置換完了までの途中状態も試験し、エラー回避だけを目的とする一括タグ解除をデプロイの自動修復へ組み込まないでください。

運用・監視・フェイルオーバー：拒否の試験と認可状態の復元を含める

編集上の提案：監視にはSQLジョブの終了状態とタグ付き列の変更エラーを含めます。成功時にも公開範囲を照合し、デプロイID、SQLの版、実行ID、Runtime、変更前後の権限・タグ、試験結果を関連付けて保管します。成功したデプロイが認可の回帰を検知できる設計にします。

編集上の提案：利用を許可するIDに加え、拒否されるべきIDでも代表クエリを実行します。直接付与、グループ経由、上位オブジェクトからの継承を含む試験行列を作り、行フィルターやマスキングがある場合は期待する結果も照合します。

編集上の提案：切戻しではSQL本文を以前へ戻すだけで完了としません。変更前の権限・タグ・所有者との差分を確認し、現行ポリシーに照らして必要な状態を復元します。DR先や別ウェアハウスへの切替でも同じ認可試験を行い、実行環境の違いで既定動作が変わらないか確認してください。

編集上の分担案：データ基盤担当はSQLと実行環境、データ所有部門は公開範囲、セキュリティ担当は管理タグとポリシー、運用担当は検知と切戻しを担います。外部委託先がDDLだけを担当する場合も、権限の受入判定を誰が行うか契約上の業務範囲と合わせます。

実装・移行手順：同じSQLを権限とタグの状態別に試験する

編集上の試験案：検証用Unity Catalogビューを作り、直接付与権限、コメント、通常タグ、管理タグ付き列を用意します。列構成を維持した置換、管理タグ付き列を削除する置換、保持方針を明示した置換を別々に試験します。対象のSQLウェアハウス・Runtimeで、成功・拒否・保持・削除の期待値を記録してください。

編集上の手順案：棚卸し、事前状態の採取、検証、SQLと権限管理の修正、限定展開、利用者視点の確認、切戻し試験の順で進めます。将来予定の動作が検証環境へ未適用なら、その点を未検証として残し、適用後の再確認をリリース条件にします。

適用上の前提：個別環境の設計保証や法的助言を行うものではありません。実装適用にあたっては、検証環境での事前テストと業務範囲の確認が必要です。機能の提供状況・Runtimeの仕様は最新の公式資料で再確認してください。