DB変更、手作業のメモで回してませんか？
「適用し忘れた」「順番を間違えた」「開発は動くのに本番だけ違う」…これ、地味に怖いですよね。しかも一度事故ると、原因探しで夜が溶けます。
そこで登場するのが、DB変更を“決まった道順の地図”にしてくれるツールです。
この記事を読むと、
- Flyway/Liquibaseを選べる
- 基本の書き方がわかる
- 既存DBへ途中導入（baseline）できる
- チーム運用とCI/CDルールまで作れる
ができるようになります。
迷ったらその日に決められる小さなPoCのやり方も用意します。
まずは早見表で仮の答えを出して、あとで理由を確認していきましょう。
先に結論だけ言うと、SQL中心でサクッと行くならFlyway寄り。差分管理やYAMLなど多形式で統一したいならLiquibase寄りです。
まず結論：あなた向きがわかる早見表
いきなり全部を理解しようとすると、だいたい迷子になります。なので先に「仮の答え」を出しちゃいましょう。あとで本文を読むと、「なるほど、だからこっちか〜」って腹落ちしますよ。
早見表：チームの状況→おすすめ
| チームの状況 | おすすめ | 理由（超ざっくり） |
|---|---|---|
| SQLで管理する文化がある／まず最短で始めたい | Flyway寄り | SQLファイルを順番に流す発想でわかりやすいです |
| DBが複数種類ある／書き方を統一ルールにしたい | Liquibase寄り | YAML/XML/JSONで「やりたい変更」をまとめて書けます |
| 監査・承認・権限が強めの会社／説明責任が重い | Liquibase寄り（＋有料も検討） | 変更の証跡や運用ルールを固めやすいです |
| チームが小さめで、まずは事故を減らしたい | Flyway寄り | シンプルに始められて運用ルールも作りやすいです |
| 「どっちも良さそう…」で決めきれない | まずPoC | 触った体感が一番早いです（30〜60分で判断可能） |
※ここで言う「おすすめ」は“向いてる方向”です。どっちを選んでも運用次第でちゃんと戦えます。
30秒で決める：おすすめパターン3つ
- 最短で導入して、まず事故を止めたい → Flyway
SQLをそのまま積み木みたいに積んでいく感じで、初心者でも入りやすいです。 - チーム全体で変更ルールを揃えたい／DBが増えがち → Liquibase
「何を変えるか」を変更セットで書けるので、ルールが作りやすいです（YAMLなども選べます）。 - 監査・承認が必須で、運用がガチ → Liquibase（有料含めて検討）
“誰が何をいつ承認したか”みたいな話が出るなら、最初からその方向で考えたほうが後で楽です。
迷ったらここを見る：5つの比較軸
このあと本文では、次の5つで「違い＝選ぶポイント」を整理します。
- 書き方：SQL中心か／変更セット（YAML等）中心か
- 学びやすさ：覚える量と最初のつまずき
- 戻しやすさ：ロールバックの考え方（安全第一で）
- チーム向き：衝突しにくさ・レビューしやすさ
- 会社向き：監査・権限・有料機能が効く場面
迷ったら「まずPoC」で当日判断がいちばん強いです
正直、最後は“触った感”が勝ちます。おすすめはこれだけです。
これで「うちのチームはこっちが気持ちいいな」がほぼ決まります。次は、そもそもDB変更管理ツールが何をしてくれるのか、超やさしくいきますね。
そもそもDB変更管理ツールって何？（超やさしく）
DB変更管理ツールを一言でいうと、DBの変更を「積み木」みたいに順番どおり積んで、履歴も残して、ミスも見つけてくれる仕組みです。手作業で「このSQL、誰がいつどこに当てたっけ？」をやるのをやめるための道具ですね。
「手作業のDB変更」が起こす事故あるある
手でやると、だいたい次の事故が起きます。
これ、どれも原因はシンプルで、変更の“道順”が人の記憶とメモに依存してるからです。
ツールがやってくれる3つのこと（順番・記録・チェック）
じゃあツールは何をしてくれるの？っていうと、基本はこの3つです。
「積み木」のたとえでイメージすると超ラクです
こんな感じです。これだけで、さっきの事故あるあるが一気に減ります。
最小構成で始めるなら、無料版＋ローカルDB（DockerでもOK）で十分です。
次の章では、いよいよFlywayとLiquibaseで「どこに違いが出るのか」を5つの軸でやさしく比べます。
Flyway vs Liquibase：違いが出る5つの比較軸
ここは「違い＝選ぶポイント」を、むずかしい言葉なしで整理するパートです。先に言っちゃうと、Flywayは“SQLを順番に流すのが得意”、Liquibaseは“変更ルールを形にしてチームで揃えるのが得意”…この差が基本です。
書き方：SQL中心か／変更セット中心か
学びやすさ：覚える量と最初のつまずき
戻しやすさ：ロールバックの考え方（安全第一）
チーム向き：衝突しにくさ・レビューしやすさ
会社向き：監査・権限・有料機能が効く場面
- 結論：説明責任が重い会社ほどLiquibase（＋有料検討）が刺さりやすいです。
- 理由：「誰が何をいつ変えた？」を後から追える形にしやすいのが強みです。承認フローや権限まわりが必要になると、無料だけではしんどいこともあります。
- 向いてる人：監査・統制が強い現場はLiquibase寄り、軽めなら無料で十分なことが多いです。
同じ変更を見比べよう（並べて理解する）
ここでは、同じ要件を Flyway と Liquibase で書いて、手触りの違いをつかみます。題材はシンプルに「usersテーブルにカラムを1本追加」です。
例題：usersテーブルにカラム追加
やりたいこと：users に email（文字列、NULL OK）を追加する
Flyway（SQL）例：ファイル名と中身のイメージ
Flywayは「SQLファイルを順番に流す」が基本です。
-- 例：V20251224_01__add_email_to_users.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255);
ポイントは「ファイル名で順番が決まる」ことと、「中身はいつものSQL」ってところです。SQLレビューが強いチームだとめちゃ楽です。
Liquibase（YAML）例：変更セットのイメージ
Liquibaseは「変更を“変更セット”として書く」イメージです。
databaseChangeLog:
- changeSet:
id: 20251224-01-add-email
author: yourname
changes:
- addColumn:
tableName: users
columns:
- column:
name: email
type: varchar(255)
「何をしたいか」が先に並ぶので、SQLに慣れてない人でも意図が追いやすいことがあります（逆に、SQL派には回りくどく見えることもあります）。
「読みやすい」はチーム文化で変わる
結局ここ、正解は1つじゃないです。見るべきはこのへんです。
この“読みやすさ”の相性が、後々の事故率に直結します。次は「既存DBに途中から入れる方法（baseline）」で、いちばん不安が出やすいところを潰していきます。
途中から導入する方法（既存DBでも大丈夫）
「もうDB動いてるんだけど、今さら入れて意味ある？」ってなりますよね。大丈夫です。コツは “いまの状態を初期版として固定して、次の変更からルール運用に乗せる” ことです。
基本の型：いまの状態を「初期版」として固定（baseline）
やることはこの3ステップだけです。
- 現状を固定：いまのDB構造を「これが初期版です」と決める
- baseline登録：ツール側に「ここまでは適用済み扱い」と印を付ける（履歴テーブルも作られます）
- 次の差分から運用：以降の変更を1個ずつファイル（変更セット）で追加していく
フォルダ構成も最小でOKです（例：migrations/ 配下に変更を追加していくイメージ）。
ありがちな落とし穴：過去のSQLを全部入れない
途中導入で一番やりがちなのが、過去のSQLを全部ツールに突っ込んで再現しようとすることです。これ、だいたい事故ります。
理由はシンプルで「すでに当たってる変更」をもう一回当てにいって、コケるからです。なので基本は 過去は追わない／“いま”を起点にする が正解です。
導入チェック：最小PoC（30〜60分）で確認する
小さく試すなら、これだけやれば判断できます。
ここまで通れば、「既存DBでもちゃんと回る」が確定します。
次は、チーム運用とCI/CDで“人の注意”を減らす型にいきます。
チーム運用とCI/CDの型（ミスを減らす）
DB変更は「気をつけます」で守ると、だいたい破れます。なので仕組みでミスを潰す型を置いちゃいましょう（FlywayでもLiquibaseでも考え方は同じです）。
ルール例：1変更＝1ファイル、適用済みは触らない
衝突対策：命名ルールと「同時変更」のさばき方
CIで必ずやる：テストDBに適用→アプリ起動チェック
CI（GitHub Actions / GitLab CI / Jenkinsなど）で
- 空のテストDB作成
- migration適用
- アプリ起動＆テスト
これだけで「本番だけ違う」が激減します。ログは保存先（CIログやログ基盤）を決めて残します。
本番運用：適用タイミング（起動時／デプロイ前）を決める
Spring Bootなら「起動時にやるか、パイプラインで先にやるか」をチームで固定すると迷わなくて済みます。
無料版と有料版の考え方（将来困らない判断）
結論、最初は無料でOKなことが多いです。ただ「事故ったときのダメージ」が大きい会社は、有料も早めに視野に入れると安心です。
無料で足りるのは、
- チーム小さめ
- 監査がゆるめ
- DB種類が少ない
- 承認フローが要らない、
あたり。まずはFlyway/Liquibaseの無料版＋ローカルDBで回して、命名やレビュー手順を固めるのが現実解です。
有料が効くのは、①監査で「誰が承認したか」を残したい ②権限や統制が必要 ③複数チームで衝突コストが高い ④困ったときのサポートが欲しい、みたいな場面です。
稟議向けの言い方はこれで十分です：
「事故コスト（人数×時間×頻度＋停止損）＞ライセンス費なら投資価値あり」。なので基本は“まず無料→困りごとが出たら有料で拡張”でOK。
価格帯は、無料（OSS）／有料（チーム・企業向け、見積もり・契約で変動）と整理して説明すると通りやすいです。
最後にYES/NOで決めるチェックリスト（まとめ）
ここまで読んだら、あとはYES/NOでサクッと決めましょう。**YESが多い方が“今のあなたの現場に合う寄り”**です。どっちも同じくらいなら、迷わず「まずPoC」ルートでOKです。
判断チェックリスト（10問）
- 変更は基本 SQLでレビューしたい → YESなら Flyway寄り
- まずは 最短で導入して回したい → YESなら Flyway寄り
- DBは今後 複数種類になりそう → YESなら Liquibase寄り
- 書き方を YAMLなどで統一ルールにしたい → YESなら Liquibase寄り
- 同時に変更が走って 衝突が多い → YESなら Liquibase寄り
- 監査で「誰が何をしたか」を ちゃんと説明する必要がある → YESなら Liquibase寄り
- 承認フローや権限など、運用が ガチ → YESなら Liquibase（有料検討）寄り
- 「戻せるから安心」より 事故らない運用（CI・手順）を作りたい → YESなら どっちでもOK（運用勝負）
- 途中導入（既存DB）を スムーズに始めたい → YESなら どっちでもOK（baselineの型でOK）
- チーム内で「これ読みやすい！」が 一致しそう → YESなら その好みに合わせるのが正解
ざっくり集計の目安：
おすすめ結論の再掲＋次にやること（1週間の行動）
結論の再掲
次にやること：1週間プラン
これで「なんとなく不安」から「運用として回せる」に変わります。お疲れさまでした！
よくある質問
- QFlywayとLiquibase、結局どっちが人気なんですか？
- A
人気＝正解ではないので、チームの相性で選ぶのが安全です。
ざっくり言うと、SQLでサクッと回したいならFlyway、ルールを揃えて管理したいならLiquibaseがハマりやすいです。
- Q「ロールバックできるなら安心」って思っていいですか？
- A
そこは注意です。DBはデータが絡むので、きれいに戻せない変更も多いです。
基本は「戻す」より、次の変更で直す＋バックアップ（スナップショット）が安全です。
- Q途中から導入したいんですが、過去のSQL全部入れないとダメですか？
- A
だいたい入れないほうが正解です。
「いまのDB状態」を初期版（baseline）として固定して、次の変更からツール管理に乗せるのが王道です。
- Q既に適用したmigrationファイルを、こっそり直したらダメですか？
- A
基本ダメです。あとで必ず事故ります。
直したいなら、新しいファイル（新しい変更）として追加してください。「適用済みは触らない」が鉄則です。
- Qチームで同じテーブルを同時に触ったら、衝突しませんか？
- A
します。なので対策が必要です。
おすすめは、1変更＝1ファイル＋命名ルールで順番固定。衝突したら無理にねじ込まず、後から入った側を“次の変更”として作り直すのが安全です。
- QCI/CDって、最低限なにをやればいいですか？
- A
最低限はこれだけでOKです。
テスト用DBを作る → migration適用 → アプリ起動 → 自動テスト。
これで「本番だけ違う」がかなり減ります。
- QSpring Bootでは、DB変更を起動時に自動適用していいですか？
- A
場合によります。
- 小さめ構成で単純なら起動時適用でも回ります
- 止まると困る本番なら「デプロイ前に適用」をパイプライン化するほうが安全寄りです
どっちにするかをチームルールで固定すると迷いません。
- QLiquibaseはSQLも書けますか？逆にFlywayでYAMLみたいなのは書けますか？
- A
LiquibaseはSQLも使えます（混ぜて運用するチームもあります）。
Flywayは基本がSQL中心です（「SQL資産をそのまま管理したい」方向け、という理解でOKです）。
- Q無料版のままだと将来困りますか？
- A
小さめチームなら、無料でずっと回ることも多いです。
ただし、監査・承認・権限・レポート・サポートみたいな「会社の要求」が強くなると、有料の価値が出やすいです。
迷ったら「困りごとが出たら検討」でOKです。
- Q本番でmigrationが失敗したら、どうするのが正解ですか？
- A
正解は「事前に決めておく」です。おすすめの型は、
- ログで原因を特定
- 安全な復旧手段（バックアップ/スナップショット）を使う
- 修正は“次の変更”で入れる
「その場でファイルを書き換える」は事故りやすいので避けてください。