データベースマイグレーションとは スキーマ変更と移行の2つの意味・手順と注意点

「マイグレーションを実行してください」と言われて調べたら、スキーマ変更の話とデータベース移行の話が混ざって出てきた。そんな経験のある方は少なくないはずです。

データベースマイグレーションという言葉には、2つの異なる意味があります。1つは開発の中でスキーマの変更を管理すること、もう1つはデータベースを別の環境や製品へ移すことです。

どちらも「移行」という意味は共通していますが、作業の内容、関わる担当者、リスクの性質がまったく異なります。この区別をしないまま情報を集めると、必要な答えにたどり着けません。

この記事では、2つの意味を切り分けたうえで、それぞれの進め方、方式の選び方、そして実務でつまずきやすい点までを順に扱います。

確認したいポイント	結論	詳細
2つの意味とは？	スキーマ変更管理と環境の移行	開発の文脈ではスキーマ変更の管理、インフラの文脈では別環境への移行を指します。
なぜ必要なのか？	変更履歴とロールバックの管理	手作業のSQLでは、誰がいつ何を変えたかが追えず、元に戻せなくなります。
方式は？	バージョン管理型と宣言型	差分を順に適用するか、あるべき姿から差分を生成させるかという違いです。
移行の最大の難所は？	ダウンタイムとデータ整合性	停止できる時間から方式が決まります。リハーサルなしの本番移行は避けます。

この記事でわかること

• データベースマイグレーションが持つ2つの意味と、その見分け方
• マイグレーションファイルの役割と、手作業のSQLでは困る理由
• バージョン管理型と宣言型の違い、スキーマドリフトという問題
• 環境を移行する場合の方式の選び方と、手順6ステップ
• データ量、文字コード、切り戻しなど移行でつまずきやすい点

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発や移行の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。 社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

データベースマイグレーションの2つの意味

まず言葉を切り分けます。ここを整理しないと、調べても混乱するだけです。

意味1｜スキーマ変更の管理

開発の文脈で使われる意味です。アプリケーションの機能追加に伴って、テーブルや列を追加・変更する作業を、履歴として管理する仕組みを指します。

データベースのスキーマとは、その構造を定義するものです。テーブル名、列名、データ型、制約などが含まれます。機能を変えればスキーマも変わるため、変更は日常的に発生します。

この変更をスクリプトとして記録し、バージョンを付けて管理する。これがスキーマ変更管理としてのマイグレーションです。関わるのは主に開発者です。

意味2｜データベースそのものの移行

インフラの文脈で使われる意味です。データベースを別の環境や別の製品へ移す作業を指します。DB移行、データベース移行とも呼ばれます。

オンプレミスからクラウドへの移行、製品の乗り換え、バージョンアップに伴うサーバー入れ替え。システム全体に影響する作業であり、数か月単位のプロジェクトになることもあります。

こちらで問題になるのは、ダウンタイム、データの整合性、アプリケーションの互換性です。単なるコピー作業ではありません。関わるのはインフラ担当者と業務部門です。

どちらを指しているかの見分け方

周辺の言葉で判別できます。

• マイグレーションファイル、ロールバック、バージョン管理、フレームワーク → スキーマ変更管理
• ダウンタイム、データ量、切り替え、レプリケーション、クラウド → 環境の移行

開発者が「マイグレーションを流す」と言えば前者、インフラ担当者が「マイグレーションの計画」と言えば後者を指していることが多くなります。

この記事では、第2章から第4章で前者、第5章から第8章で後者を扱います。必要な章から読み進めてください。

どちらも非機能要件として扱われる

共通する点もあります。いずれも「移行性」という観点で、事前に要件として定義しておくべき事項です。

IPA（情報処理推進機構）が公開する非機能要求グレードでは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティなど6つの大項目について、要求レベルを段階的に整理する枠組みが提供されています。

移行性が独立した大項目として設けられているという点が重要です。移行は開発の付随作業ではなく、それ自体が要件として検討すべき領域だという位置づけです。要件の書き方については要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

スキーマ変更管理としてのマイグレーション

ここからは、開発の中でスキーマの変更を管理する仕組みを扱います。

マイグレーションファイルとは

データベースのスキーマ変更を記述したスクリプトです。スキーマのバージョンを追跡し、新旧のバージョン間での移行を行う役割を果たします。

中身は2つの処理で構成されるのが基本です。変更を適用する処理と、それを元に戻す処理です。

【マイグレーションファイルの構造】

適用（up）　：ALTER TABLE users ADD COLUMN phone VARCHAR(20);

巻き戻し（down）：ALTER TABLE users DROP COLUMN phone;

ファイルには通し番号やタイムスタンプが付き、実行順序が決まります。データベース側には適用済みのバージョンを記録する管理テーブルが作られ、未適用のものだけが実行されます。

手作業のSQLでは何が困るのか

SQL文を直接実行してスキーマを変えることもできます。小規模なら成立しますが、複数人・複数環境になると破綻します。

• 誰がいつ何を変えたか分からない：履歴が残らず、追跡できない
• 環境ごとに状態がずれる：開発環境では動くが検証環境では動かない
• 元に戻せない：問題が起きたときに、変更前の状態を再現できない
• 新しい環境を作れない：ゼロから同じ構造を再現する手順がない

4つ目が特に深刻です。新しいメンバーが参加したとき、あるいは検証環境を追加したいとき、現在のスキーマを再現する方法が誰にも分からないという状態になります。

得られる3つの効果

マイグレーションツールを使うことで、次の効果が得られます。

1つ目は変更履歴の管理です。スキーマがどう変更されてきたかを追跡できます。ソースコードと同じリポジトリで管理すれば、機能の変更とスキーマの変更が対応づけられます。

2つ目はロールバックです。問題が発生した場合に、スキーマを以前の状態に戻せます。ただし後述するとおり、条件があります。

3つ目は環境の再現性です。空のデータベースに対してマイグレーションを順に適用すれば、いつでも同じ構造を作り直せます。新しい環境の構築が数分で終わります。

スキーマ管理の2つのアプローチ

ツールの選び方に直結する分類です。差分を積み上げるか、あるべき姿から差分を作らせるかという違いがあります。

バージョン管理型

データベースをある状態から次の状態へ移行させる手順書に、バージョン番号を付けて1つずつ実行していく方法です。最も広く使われています。

利点は、何が実行されるかが明示的であることです。ファイルを読めば、どういうSQLが流れるかが分かります。複雑な変更や、データの移し替えを伴う処理も記述できます。

難点は2つあります。開発者が正確でかつ安全に巻き戻せるスクリプトを作る責任を負うこと。そして、多くのスクリプトが積み重なると、現在のスキーマに至るまでの変更履歴を追うのが大変になることです。

宣言型（状態ベース）

スキーマの最終的なあるべき姿をコードで定義し、ツールが現在の状態と比較して差分のSQLを自動生成・実行する方法です。

利点は、定義ファイルを読めば現在のスキーマが一目で分かることです。バージョン管理型のように、何十ものファイルを順に追う必要がありません。

難点は、生成されるSQLを完全には制御できないことです。列名の変更を「削除と追加」として解釈されると、データが失われます。生成された内容を確認する工程が必要になります。

スキーマドリフトという問題

両方のアプローチに共通する落とし穴です。スキーマドリフトとは、バージョン管理されているマイグレーションファイルが示す「あるべきスキーマの姿」と、実際のデータベースの状態が、管理外の変更によって乖離してしまう問題を指します。

原因は、ツールを経由しない手作業の変更です。障害対応で急いで列を追加した、検証のために制約を外した。こうした変更が記録されないまま残ります。

対策は2つです。本番環境での手作業の変更を禁止するというルール、そして定期的に定義と実際の状態を突き合わせる仕組みです。宣言型のツールには、差分を検出する機能が備わっていることが多くあります。

どちらを選ぶか

チームの規模と変更の複雑さで判断します。

少人数で、データの移し替えを伴う複雑な変更が多いなら、バージョン管理型が向きます。何が実行されるかを完全に把握できるためです。

多人数で並行して開発し、スキーマの全体像を把握しにくい状況なら宣言型が有利です。ただし、生成されたSQLのレビューを手順に組み込む必要があります。

併用も可能です。通常の変更は宣言型で進め、データの移し替えを伴う変更だけバージョン管理型のスクリプトで書くという構成が取れます。

移行方式の選定や計画づくりからご相談いただけます 方式は分かっても、自社の環境でどれが現実的かの判断は別の問題です。 現行環境の棚卸しからご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

スキーマ変更で押さえる注意点

本番環境への適用でつまずく点を整理します。

巻き戻しを書いても戻せないことがある

重要な注意点です。ロールバックのスクリプトを書いても、データが失われる変更は元に戻せません。

列を削除するマイグレーションを適用した後に巻き戻せば、列は復活します。しかし、その列に入っていたデータは戻りません。テーブルの削除も同様です。

対策は、破壊的な変更を段階的に行うことです。まず使用を停止し、一定期間そのまま運用し、問題がないと確認できてから削除する。この順序を守れば、途中で引き返せます。

サービスを止めずに変更する

稼働中のシステムでは、スキーマの変更とアプリケーションの入れ替えを同時に行えません。どちらかが先になります。

安全な順序は、まず新旧どちらのアプリでも動くスキーマ変更を適用し、次にアプリを入れ替えるという進め方です。

【列を追加する場合の安全な順序】

1. 列を追加する（NULL許容または既定値つき）

2. 新しいアプリを配置する（新列を使い始める）

3. 必要なら制約を後から追加する

必須制約を最初から付けると、旧アプリからの登録が失敗します。段階を分けることで、切り替え中も動作を保てます。列名を変更する場合は、新列の追加、両方への書き込み、読み取りの切り替え、旧列の削除という4段階になります。

大きなテーブルへの変更

行数が多いテーブルへの変更は、実行に長時間かかり、その間ロックが保持されることがあります。数百万行を超えると現実的な問題になります。

製品とバージョンによって挙動が異なります。列の追加は瞬時に終わる場合もありますが、制約の追加やデータ型の変更はテーブル全体の書き換えを伴うことがあります。

事前に検証環境で、本番相当のデータ量で実行時間を測ります。これを省くと、想定の数十倍の時間がかかってサービスが停止するという事態が起こります。

アプリケーションとの同期

運用上の要点です。スキーマの変更とアプリケーションの変更を、同じ単位で管理します。

Djangoの公式ドキュメントでも、マイグレーションとモデルの変更をバージョン管理システムに1つのコミットとしてコミットすることが推奨されています。他の開発者や本番サーバーがコードを取得したときに、両方が同時に反映されるためです。

マイグレーションファイルに意味のある名前を付けるという配慮も有効です。自動生成された名前のままだと、後から履歴を見ても何の変更か分かりません。

環境の移行としてのマイグレーション

ここからは、データベースを別の環境や製品へ移す作業を扱います。

どういう場面で発生するか

主に4つの場面があります。いずれもシステム全体に影響する作業です。

• クラウドへの移行：オンプレミスのサーバーからクラウドのサービスへ
• 製品の乗り換え：ライセンス費用の見直しや機能要件による変更
• バージョンアップ：サポート終了に伴うサーバーの入れ替え
• システム刷新：新システムへの既存データの移行

1つ目が近年最も多い動機です。設備の維持負担を減らす、拡張性を確保する、災害対策を強化するといった目的で検討されます。

同種移行と異種移行

難易度が大きく変わる区別です。

同じ製品どうしの移行を同種移行と呼びます。同じ製品の同じバージョンであれば、データの入出力機能でそのまま移せます。作業は比較的単純です。

異なる製品間の移行は異種移行と呼ばれ、難易度が跳ね上がります。データ型の対応、SQLの方言、ストアドプロシージャ、シーケンス、照合順序。これらすべてを変換する必要があります。

異種移行では、アプリケーション側の修正も発生します。製品固有のSQLを使っている箇所は、すべて書き換えが必要になります。移行の工数は、データベース側よりアプリ側のほうが大きくなることもあります。

ダウンタイムの許容範囲を決める

この判断が方式の選択を規定します。最初に決めるべき事項です。

何時間サービスを停止できるのか。週末に停止できるのか、深夜の数時間だけなのか、まったく停止できないのか。業務部門と合意して数値で決めます。

あわせて、データ量と回線速度から単純にコピーした場合の所要時間を概算します。1テラバイトのデータを移すのに何時間かかるか。この数字と許容時間を比べることで、取れる方式が絞られます。

移行方式の選び方

代表的な3つの方式があります。停止できる時間によって選択が決まります。

停止して一括移行する

サービスを止め、データを書き出して移行先に読み込むという最も単純な方式です。ダンプとリストアと呼ばれます。

利点は手順が単純で、確実性が高いことです。特別な仕組みを用意する必要がなく、データベース標準の機能で完結します。

制約は停止時間です。データ量に比例して時間がかかります。数百ギガバイトを超えると、一晩では終わらないことがあります。週末に停止できる案件であれば、この方式が最も安全です。

レプリケーションで同期する

移行元から移行先へ継続的にデータを複製し、追いついた時点で切り替える方式です。停止時間を大幅に短縮できます。

事前に大部分のデータを移しておき、差分だけを同期し続けます。切り替えの瞬間だけ停止すれば済むため、停止時間は数分から数十分に収まります。

同種移行では標準の機能が使えることが多く、比較的導入しやすい方式です。異種移行の場合は、変更データを追随させる専用のサービスやツールを使います。

ストレージのスナップショットを使う

ストレージの機能でデータを丸ごと複製する方式です。ブロック単位でコピーするため、データベースの種類を問わず高速に移行できます。

ただし、スキーマの変換やアプリケーションの調整は別途必要です。そのため、単独で使うより補助的な手段として活用されるケースがほとんどです。

大容量のデータを移行元から移行先へ運ぶ初期段階だけこの方式を使い、その後の差分はレプリケーションで追随させるという組み合わせが実務的です。

方式の判断軸

次の3点で絞り込めます。

• 停止できる時間：長く取れるなら一括移行、短いならレプリケーション
• データ量：大きいほど一括移行の現実性が下がる
• 同種か異種か：異種移行では変換の仕組みが必要になる

費用と難易度も比例します。停止時間を短くするほど、必要な仕組みは複雑になり、費用も工数も増えます。停止できるなら停止するのが、最も安く確実な選択です。

移行の手順｜6ステップ

準備と検証に時間を使います。本番作業は最後の数時間です。

ステップ1｜現行環境を棚卸しする

正確な把握が出発点です。データベースの製品、バージョン、規模、利用している機能、スキーマの構造、依存関係、接続しているアプリケーションを洗い出します。

利用機能の確認が特に重要です。ストアドプロシージャ、トリガー、ビュー、ユーザー定義関数、シーケンス。これらは移行先で同じように動くとは限りません。

あわせて、業務への影響度と停止の許容時間を評価します。どの移行方式が現実的かを見極めるための材料になります。

ステップ2｜移行方式と目標を決める

棚卸しの結果をもとに、方式を決定します。停止時間、データの許容損失、切り戻しの条件を数値で定めます。

移行の完了をどう判定するかも決めます。件数の一致、チェックサムの照合、主要な業務の動作確認。合否の基準を事前に合意しておきます。

ステップ3｜スキーマを変換する

異種移行の場合に必要な工程です。データ型の対応、制約、索引、文字コードの設定を移行先の仕様に合わせて作り直します。

変換ツールが用意されている場合もありますが、自動変換できない部分が必ず残ります。ストアドプロシージャやトリガーは、アプリケーション側のロジックへ移す判断が必要になることもあります。

ステップ4｜リハーサルを行う

最も省略されやすく、最も重要な工程です。本番相当のデータ量で、移行の全手順を通して実施します。

ここで測るのは所要時間です。見積りではなく実測値を得ることが目的です。想定の3倍かかると判明することは珍しくありません。

切り戻しの手順もリハーサルします。移行後に問題が発覚した場合、元の環境へ戻せることを確認しておきます。試したことのない切り戻し手順は、いざというときに機能しません。

ステップ5｜本番移行を実施する

リハーサルで確定した手順書に沿って実施します。手順書には、各作業の所要時間と判断のタイミングを記載しておきます。

あわせて、この時刻までに完了しなければ切り戻すという判断ポイントを定めます。時間が押している状況では冷静な判断が難しくなるため、事前に決めておく必要があります。

作業の記録を残します。実施時刻、実施者、各手順の結果。この記録が、問題が発生した際の調査の根拠になります。

ステップ6｜移行後の検証

移行が終わった直後と、稼働後しばらくの両方で検証します。

直後の検証では、件数の一致、主要な業務の動作、性能の体感を確認します。業務部門の担当者に実際の操作で確認してもらうのが確実です。

稼働後は、性能の推移とエラーの発生状況を監視します。異種移行では、実行計画が変わって特定の処理だけ極端に遅くなることがあります。数日から数週間は注視します。

よくある失敗

移行プロジェクトで繰り返される失敗を整理します。

データ量を実測していない

最も多い失敗です。見積りでスケジュールを立て、リハーサルで実測しないまま本番に臨むというパターンです。

実際には、索引の再構築、統計情報の更新、整合性チェックといった処理が想定以上に時間を要します。データの転送だけを見積もっていると、大幅に超過します。

対策はリハーサルの実施です。本番相当の環境が用意できないなら、一部のテーブルで測って全体を推計するという方法もあります。何も測らないのが最悪の選択です。

文字コードや照合順序の差異

異種移行で頻発します。文字化け、絵文字の消失、並び順の変化という形で表面化します。

特に注意すべきは、機種依存文字、外字、サロゲートペアを含む文字です。移行後に一部のレコードだけ表示が崩れるという事象が起こります。

照合順序の違いも影響します。並び順が変わると、画面の表示順や帳票の出力順が変わります。業務上の意味を持つ場合、これは不具合として扱われます。

切り戻しを用意していない

移行後に問題が発覚したとき、元に戻せないという状態です。特にレプリケーション方式で、移行元を止めてしまった場合に起こります。

対策は、移行元の環境を一定期間そのまま残すことです。すぐに撤去せず、数週間は戻せる状態で保持します。費用はかかりますが、保険として合理的です。

移行後に発生したデータを、移行元へ戻す手順も検討しておきます。切り替え後に数時間稼働してから戻す場合、その間のデータをどう扱うかが問題になります。

アプリケーション側の互換性

データベースの移行は完了したが、アプリケーションが動かないというケースです。異種移行で必ず検討すべき点です。

製品固有のSQL構文、接続ドライバの違い、日付や数値の書式、トランザクションの挙動。これらが変わると、アプリケーション側の修正が必要になります。

移行の計画にアプリ側の工数を含めることが前提です。データベースの作業だけを見積もると、総額が大きく外れます。委託時の役割分担についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも整理しています。

まとめ

データベースマイグレーションには2つの意味があります。開発の中でスキーマ変更を管理することと、データベースを別の環境や製品へ移すことです。作業の内容もリスクの性質も異なります。

スキーマ変更管理では、バージョン管理型と宣言型という2つのアプローチがあります。共通する落とし穴はスキーマドリフトで、管理外の手作業による変更が原因です。

本番への適用では、破壊的な変更は段階的に行うという原則を守ります。列の削除は、使用停止、期間をおいた確認、削除という順序に分けます。

環境の移行では、停止できる時間から方式が決まります。長く取れるなら一括移行、短いならレプリケーション。停止できるなら停止するのが最も安く確実な選択です。

そして最も重要なのがリハーサルです。本番相当のデータ量で実測し、切り戻しまで試す。これを省略した移行は、高い確率で予定を超過します。

移行計画から実施まで、無料で相談できます クラウド移行を検討している、受け取った移行計画の妥当性を判断したいといった段階のご相談も承っています。 営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎