Skip to main content
13.4k
クラウド
セルフホスト
クラウド
セルフホスト

データベース変更管理 (DCM) とは？

Tianzhou · 2026年4月15日

関連記事:

  1. データベース変更管理とは？ (この記事)
  2. データベース変更を守る: 踏み台から統合プラットフォームへ
  3. ステートベース vs. チェンジベース データベースバージョン管理
  4. データベースバージョン管理のベストプラクティス
  5. データベース自動化の 6 段階

定義

データベース変更管理 (Database Change Management、DCM) とは、データベースに対するあらゆる変更 — 構造とデータの両方 — を、コードの変更がバージョン管理と CI/CD を通って流れていくのと同じ方法で、提案し、レビューし、デプロイし、監査する規律のことです。

リレーショナルデータベースでは SQL がその媒体になります。変更は次の 3 カテゴリーに分かれます。

  • DDL (Data Definition Language) — スキーマ: CREATE、ALTER、DROP
  • DML (Data Manipulation Language) — データ: INSERT、UPDATE、DELETE
  • DCL (Data Control Language) — 権限: GRANT、REVOKE

ほとんどの DCM ツールは DDL に重点を置きます。成熟した DCM は 3 つすべてをカバーします — 障害リスク、データリスク、コンプライアンスリスクはそれぞれ別のカテゴリーに宿るからであり、どれか 1 つを管理するためには他のものにも触れざるを得ないからです。

実際のところ、これらの変更は 1 か所から来るわけではありません。アプリケーションサーバー、cron ジョブ、アドホックなスクリプト、CLI を叩く人間 — すべてが同じデータベースに集まります。

change sourceschange sources

これが DCM のさばかなければならない相手です。

なぜ難しいのか

マイグレーションを書くこと自体は簡単です。難しいのはそれをチーム横断・環境横断・時間を超えて安全に出荷することです。繰り返し起こる失敗モード:

1. 調整されない変更

2 人の開発者が異なるブランチで同じカラムをリネームする。DBA が本番に直接インデックスを追加する。あるサービスが読み取り中にアプリケーションがマイグレーションをデプロイする。

uncoordinated changesuncoordinated changes

あらゆる変更を提案し直列化する場所が 1 つに定まっていないと、スキーマの衝突、失われる変更、障害が発生します。

2. 環境ドリフト

dev、staging、prod が乖離していく。dev にはあるカラムが prod にはない。staging では制約が有効だが「遅かった」という理由で prod では無効になっている。次のマイグレーションは 1 つの環境にしか存在しない形を前提とし、他の 2 つへのデプロイが壊れます。

3. 本番での取り返しのつかないミス

DROP TABLE が間違ったデータベースに対して実行された。WHERE 句のない DELETE が、誰も気付かない間に投入された。マイグレーションがピーク時間帯に 5000 万行のテーブルを 20 分間ロックした。それぞれが固有の失敗であり、固有の予防策があります — ただし、変更が本番に到達する前にレビューを通る場合に限ります。

4. コンプライアンスと監査のギャップ

SOC 2 監査人がこう尋ねます。「3 月 14 日に PII テーブルに触れたスキーマ変更は誰が承認し、その SQL は何でしたか？」答えが Slack のスクリーンショットや Jira チケットや DBA の記憶の中にあるなら、あなたには問題があります。監査証跡は自動的・改ざん検知可能・クエリ可能でなければなりません。

5. ロールバックの複雑さ

ほとんどの DDL はきれいに可逆ではありません — DROP COLUMN はデータを失い、ALTER TABLE には組み込みの取り消しがありません。ロールバック計画なしに急いで行われた変更は、復旧プロジェクトになります。DML 変更はさらに厄介で、スキーマだけでなく状態を再構築する必要があります。

6. アクセスの野放図な拡散

root のクレデンシャルが 5 つの設定ファイルに散らばっている。7 人の開発者が「緊急用」で本番に直接アクセスできる。最後に手打ちで実行された UPDATE が誰のものか誰も知らない。アクセス制御とクエリ制御は DCM の一部であるべきで、別のトラックではありません。

理想のワークフロー

現代の DCM はデータベース変更をコード変更と同じように扱います。

ideal workflowideal workflow

  1. 提案 — 開発者が SQL を書く (またはスキーマ定義から生成する) 変更リクエストとして提出する — データベース版のプルリクエストです。

  2. 自動レビュー — システムがルールセットに照らして SQL をリンティングします: 命名規則、バックアップなしの破壊的操作、欠けているインデックス、WHERE のない UPDATE など。現代の SQL レビューエンジンは 200 以上のルールを持ち、人がレビューする前に一般的なミスを捕捉します。

  3. 人によるレビュー — DBA やプラットフォームエンジニアが意図、ビジネスへの影響、リンターでは捕捉できないもの (例:「このマイグレーションは経理チームが依存している不変条件を保つか？」) をレビューします。

  4. 承認 — リスクに応じて、変更はカスタム承認フローを流れます — 例えば本番の DDL は DBA + マネージャーの承認、PII に触れる DML はセキュリティレビューが必要、といった具合です。

  5. 段階的ロールアウト — 変更は dev → staging → prod の順に環境を流れます。各ステージがチェックポイントになります。複数 DB・マルチテナントでのロールアウトは、カナリア対応つきの単一バッチとして実行されます。

  6. 監査 — あらゆるアクション — 誰が提案し、誰が承認し、どの SQL がいつどのデータベースに対して走ったか — が不変に記録されます。監査ログがコンプライアンス上の問いすべての答えになります。

  7. ロールバック計画 — ささいなもの以外の変更には、ロールバック SQL がフォワードマイグレーションと並んで書かれ、保管されます。

ステートベース vs. チェンジベース

変更をどう表現するかの 2 つの考え方:

チェンジベース (命令的) — マイグレーション SQL を自分で書きます: ALTER TABLE orders ADD COLUMN status VARCHAR(20);。各変更は番号付き・順序付きのファイルです。Flyway、Liquibase、そして Bytebase のデフォルトワークフローはこのモデルを採用します。

ステートベース (宣言的) — スキーマの「あるべき姿」を定義すると、ツールが差分を計算してマイグレーションを自動生成します。Atlas、Schemachange、そして Bytebase の PostgreSQL 向けステートベースワークフローはこのモデルを採用します。

チェンジベースステートベース
真実の源順序付きマイグレーションファイルあるべきスキーマ (HCL、SQL、ORM)
データマイグレーション自然な適合 — SQL を自分で書く不自然 — 宣言モデルは形を記述するもので、データ移動ではない
レビュー差分マイグレーションファイルそのものツール生成 SQL (適用前にレビュー必須)
ドリフト検知困難 — 適用済みマイグレーションと実スキーマの突合が必要標準装備 — あるべき状態との差分
ロールバック明示的な DOWN マイグレーション (書いていれば)以前の状態を再適用

ほとんどの現場のチームはハイブリッドを採用します — グリーンフィールドのスキーマ作業はステートベース、データマイグレーション、条件付きバックフィル、状態に依存するものはチェンジベース、という使い分けです。

DCM ツールの評価方法

市場には多くのツールがあります — マイグレーション機能付きのデスクトップクライアント、CLI のマイグレーションエンジン、フルプラットフォーム。選定時に見るべきポイント:

  1. SQL レビューの深さ — ルール数、環境ごとの設定可能性、エンジン固有のカバレッジ。「外部キーにインデックスが欠けている」を捕捉できるツールは、構文だけを見るツールよりも多くのインシデントを防ぎます。

  2. 承認フローの柔軟性 — 「本番の DDL は DBA 承認、PII に触れる DML はセキュリティ承認」のようなルールを定義できますか？それとも「承認者 1 人が yes をクリックするだけ」ですか？

  3. マルチ環境・マルチテナントのロールアウト — 1 つの変更がゲート付きで dev → staging → prod にデプロイできますか？500 のテナント DB にカナリア付きでデプロイできますか？

  4. GitOps 連携 — Git に SQL をコミットすると、自動でレビュー可能な変更が作られますか？SQL レビュー結果は PR に表示されますか？

  5. アクセス制御とデータマスキング — DCL を無視した DCM は仕事の半分しかしていません。ロールベースアクセス、動的データマスキング、ジャストインタイムのデータアクセスを強制できますか？

  6. 監査ログ — あらゆるアクションが、ユーザー、時刻、SQL、対象とともに記録されていますか？クエリ可能・エクスポート可能ですか？

  7. ロールバックサポート — ツールはロールバック SQL を保存し実行できますか？ツールの外側で行われたスキーマ変更を検知・フラグ付けできますか？

  8. エンジンカバレッジ — 単に「接続できるか」ではなく「エンジン固有の構文とベストプラクティスを理解しているか」(例: MySQL のオンライン DDL、PostgreSQL の CONCURRENTLY、Oracle の invisible index)。

  9. デプロイモデル — エアギャップ環境向けのセルフホスト？オンボーディングの速いクラウド？両方？

  10. 開発者体験 — DBA 向けの GUI、自動化のための CLI/API、開発者向けの IDE 連携。摩擦が少ないほどツールは使われます。

より広範な比較は データベース変更を守る: 踏み台から統合プラットフォームへをご覧ください。

DCM と DevOps

古典的な DevOps はアプリケーションのデプロイを、チケット駆動の運用からコード駆動のパイプラインへと移しました。DCM は同じことをデータベースで行います。データベース自動化の 6 段階は成熟度のはしごです。

  • レベル 0 — 本番に SSH して手で SQL を実行
  • レベル 1 — SQL ファイルは Git にあるが手動で適用
  • レベル 2 — デプロイ時にマイグレーションツールが走るが、レビューはない
  • レベル 3 — 変更はデプロイ前にレビュー + 承認を通る
  • レベル 4 — フルプラットフォーム: レビュー、承認、GitOps、マルチ環境ロールアウト、監査、アクセス制御、マスキング
  • レベル 5 — ポリシー・アズ・コード、ドリフト検知、自動是正による自律運転

ほとんどのチームはレベル 2 にいます。DCM が真価を発揮するのはレベル 2 からレベル 4 へのギャップ — 金曜日に障害が起きなくなり、監査人が居心地の悪い質問をしなくなる場所です。

Bytebase の DCM へのアプローチ

Bytebase は、このワークフローを軸に作られたデータベース DevSecOps プラットフォームです。

bytebase projectbytebase project

  • 変更を issue として扱う — あらゆる DDL/DML 変更は issue (データベース版の PR) として提案される
  • SQL レビュー — エンジン固有の 200 以上のルール、環境ごとに設定可能
  • カスタム承認フロー — 環境、変更種別、データ機微度に基づくルールで変更をルーティング
  • マルチ環境ロールアウト — 1 つの issue で dev → staging → prod に段階デプロイ
  • GitOps — GitHub、GitLab、Bitbucket、Azure DevOps — Git の SQL ファイルがレビュー可能な変更 issue になる
  • アクセス制御 + データマスキング — ワークスペース/プロジェクトロール、カラム単位の動的マスキング、ジャストインタイムアクセス
  • 監査ログ — あらゆるアクション、あらゆるユーザー、あらゆる対象がクエリ可能・エクスポート可能
  • 23 エンジン — RDBMS 9、NoSQL 6、データウェアハウス 7、加えて Elasticsearch

CNCF に認知された唯一のデータベース変更管理ソリューションであり、既存ツールを上回るペースで採用が広がっています。

star historystar history

FAQ

DCM はスキーマ移行と同じものですか？

いいえ。スキーマ移行は DCM の一部 — 特に DDL の部分 — にすぎません。DCM は DML (データ変更)、DCL (権限)、レビューワークフロー、監査、アクセス制御もカバーします。Flyway や Liquibase のようなマイグレーションツールが扱うのはスキーマ移行です。DCM プラットフォームが扱うのはライフサイクル全体です。

チームが小さくても DCM は必要ですか？

すべてのデータベース変更を 1 人が書いてデプロイしていて、コンプライアンス監査人が質問してこないなら、おそらく不要です。本番を変更できる 2 人目が現れた瞬間 — あるいは監査証跡が必要になった瞬間 — DCM が必要になります。早く始めるほど、後付けより安く済みます。

DCM は単なる「データベース DevOps」ですか？

重なりますが同一ではありません。データベース DevOps はデータベースをコードのように扱うという、より広い文化的・ツール的なシフトです。DCM はそのシフトの中で、変更の提案・レビュー・デプロイ・監査に焦点を当てた特定の規律です。DCM はデータベース DevOps のうち「変更レビュー + 承認 + ロールアウト + 監査」のスライスです。

Git と CI だけで DCM はできますか？

ある程度は — SQL ファイルを Git に置き、PR でレビューし、デプロイ時にマイグレーションツールを走らせることができます。これで自動化のはしごのレベル 2 から 3 までは到達できます。Git + CI で得られないもの: エンジン固有の SQL レビュー、ランタイムのアクセス制御、クエリ結果へのデータマスキング、動的なデータアクセス申請、直接データベース接続もカバーする監査証跡 (CI 駆動の変更だけではなく)。

ステートベースとチェンジベースの違いは？

チェンジベース: マイグレーション SQL を自分で書く (順序付きファイル)。ステートベース: あるべきスキーマを宣言し、ツールがマイグレーションを生成する。ステートベースはスキーマ作業ではきれいに動き、チェンジベースはデータ移行に不可欠です。多くのチームは両方を使います。ステートベース vs. チェンジベースを参照してください。

DCM はデータ変更もカバーしますか？それともスキーマだけですか？

両方です。成熟した DCM プラットフォームは DML 変更を DDL と同じレビューの厳しさで扱います — 本番に対して走る DELETE FROM orders WHERE ... は DROP COLUMN と同じくらい重大です。レビュー、承認、監査、ロールバックも同じように適用されます。

さらに読む:

ブログに戻る

関連記事

データベース開発のスタンダードを体験する

セルフホスト
クラウド