Rails マイグレーションとは？テーブル変更の基本を初心者向けに解説

バックエンド開発•2025/2/6

はじめに

Railsでアプリを作るとき、データを保存するためにテーブルを用意しますよね。
このとき、あとから「ここに新しいカラム（列）を追加したい」「やっぱり型を変更したい」といった場面が必ず出てきます。

そうしたテーブル構造の変更を管理するのがマイグレーションです。
実務でも、機能追加やデータ構造の見直しが行われるたびに、マイグレーションの出番があります。
本記事では、Railsのマイグレーションとは何か、そしてテーブル変更の基本を初めての方でも理解しやすい言葉で解説します。

ここでいう「初心者」の方は、テーブルという言葉はぼんやりと知っているけれど、実際にどうやって作るのかや、修正の流れがよく分からないという状況かもしれません。
そういった疑問を解消する内容をたっぷり盛り込みましたので、ぜひ最後まで読んでみてください。

この記事を読むとわかること

Railsのマイグレーションの基本的な役割と必要性
テーブルのカラム追加・削除・修正などを行う方法
実務で多いテーブル変更の場面と、それぞれの注意点
マイグレーションでよくあるエラーと対処法
変更を安全に行うための事前準備とテストの重要性

ここから順を追って、マイグレーションの仕組みや流れを見ていきましょう。

Railsのマイグレーションとは？

マイグレーションの基本概念

Railsには、テーブル構造をバージョン管理しやすくする仕組みとしてマイグレーションが備わっています。
テーブル変更の手続きをコードファイルで定義し、それを専用のコマンドで実行してデータベースを更新します。

これにより、チーム開発で複数人がアプリをいじっても、「データベース構造がいつどのように変わったか」を明確に管理できます。
また、手作業でSQL文を打つ必要がなく、ファイルにまとめて書くことで履歴を残せるのも大きなメリットです。
もし変更がミスだった場合も、ファイルを見返して修正しやすくなります。

どうして必要なのか？

一度構築したテーブルを、あとから変更する機会は多いものです。
たとえばユーザー情報を保存するテーブルがあったとして、最初はメールアドレスとパスワードだけで十分かもしれません。
しかし、途中で「プロフィール画像も保存したい」となったら、画像URLなどのカラムを追加する必要が出てきます。

こうした変更を、適当なタイミングで手動のSQL操作で行ってしまうと、誰が何をしたか記録が曖昧になります。
作業環境の違いなどもあって、チーム全員のデータベースが揃わないとバグの原因にもなります。
マイグレーションを使えば、同じファイルを実行すれば皆の環境が同じ状態にそろうため、安全で分かりやすい方法なのです。

テーブル変更のフロー

マイグレーションによるテーブル変更の大まかな流れは以下のようになります。

マイグレーションファイルの作成: コマンドを実行して、テーブル変更の指示が書かれたファイルを生成する。
内容を編集: ファイル内で、具体的にどんなカラムを追加・削除・変更するのかを定義する。
マイグレーションの実行: rails db:migrate コマンドを実行して、データベースを更新する。

この「ファイルに書く → コマンドで実行」という流れを繰り返し行うことで、複雑なテーブル構造の変更も管理しやすくなります。

テーブルを変更する基本的な手順

マイグレーションファイルの作成手順

一般的に、Railsでマイグレーションを作成するときには以下の手順を踏みます。

ターミナルでrails generate migration <マイグレーション名>を実行
自動生成されたマイグレーションファイルを開き、変更内容を記入
rails db:migrate で変更を反映

マイグレーション名は、何をするかを分かりやすく表現するとよいでしょう。
たとえば「AddProfileImageToUsers」という名前であれば、「ユーザーテーブルにプロフィール画像を追加する」ことが一目で分かります。

代表的なマイグレーションの種類

テーブル変更といっても、やりたいことはいくつかのパターンに分かれます。
代表的なものは次のとおりです。

カラムを追加（add_column）
カラムを削除（remove_column）
カラム名を変更（rename_column）
カラムの型を変更（change_column）

このほかにも、インデックス追加や外部キー設定など、もっと細かい操作がありますが、まずは基本的な操作を理解するのが第一歩です。
それだけでも実務のほとんどをカバーできます。

add_column や remove_column の例

カラムを追加したり削除したりするときは次のように書きます。


class AddProfileImageToUsers < ActiveRecord::Migration[6.1]
  def change
    add_column :users, :profile_image_url, :string
  end
end

この例では、users テーブルに profile_image_url という文字列型のカラムを追加しています。
カラムの削除は remove_column :テーブル名, :削除するカラム名 という形で記述することが多いです。

rename_column の例

カラム名を変更したいときには rename_column を使います。
たとえば、profile_image_url という名前を avatar_url に変えたい場合は以下のようなマイグレーションを書きます。


class RenameProfileImageUrlColumnToAvatarUrl < ActiveRecord::Migration[6.1]
  def change
    rename_column :users, :profile_image_url, :avatar_url
  end
end

change_column の例

カラムのデータ型を変更するときには change_column を使います。
たとえば、文字列型だったプロフィール画像URLをテキスト型に変えたい場合は以下のように書きます。


class ChangeDataTypeForAvatarUrl < ActiveRecord::Migration[6.1]
  def change
    change_column :users, :avatar_url, :text
  end
end

こうしてコードに落とし込むことで、データベースに変更を適用できます。
これらのマイグレーションをファイルごとに作成し、管理していく形がRails流のやり方です。

テーブル変更の実務活用例

カラム追加のシチュエーション

実務では「後から新しい要素を追加しなければならなくなる」ことは日常茶飯事です。
たとえば下記のような場面があります。

ユーザープロフィールの拡充: 名前やメールアドレスだけでなく、年齢・性別・自己紹介文などを追加したい
商品の在庫管理情報の拡張: 在庫数や入荷予定など、新しい情報を加えたい
ステータスやフラグ: 管理者がユーザー情報を操作できるようにするためのフラグなど

こうした要求が出た場合、まずはマイグレーションファイルを作り、必要なカラムを追加してrails db:migrateすることで反映させます。

さらに実務では、「新しく追加するカラムがnullを許容するか」「デフォルト値をどうするか」といった細かい要件も考慮しなければなりません。
Railsのマイグレーションでは、add_columnにオプションとして null: false, default: "hoge" などを指定できます。
こうしたオプション設定も忘れずに行うことが重要です。

カラム削除のシチュエーション

一方で「もう使わなくなったカラムを削除したい」というケースもよくあります。
たとえば、サービス開始当初には必要だと思って用意していたデータが、運用してみると実際には使われなくなった、ということがあるかもしれません。

削除したいカラムが他の機能に影響しないかどうかを、あらかじめ確認したうえでマイグレーションでremove_columnを実行します。
このとき、削除してしまうと元には戻せないデータも出てくるため、必要に応じてバックアップをとっておくと安全です。

カラムの型変更のシチュエーション

文字列型から整数型、あるいは整数型から日付型への変更など、カラム型を変えたい場合も少なくありません。
例として、「電話番号を保存するカラムは数字しか入らないのだから整数型のほうがいいだろう」と思うこともあるでしょう。

しかし、電話番号に国際電話の国番号をつけるとか、0から始まる番号を保存する場合などはむしろ文字列型で管理したほうが都合が良いという話もあります。
こうした仕様の変更や修正が起きたときは、change_column でデータ型を修正します。

失敗しないためのポイント

バックアップの取り方

データベースを変更するときは、必ず「万が一に備える」姿勢が必要です。
本番環境のデータはとても貴重なので、誤って消えてしまわないように事前にバックアップをとっておくのが理想です。

バックアップにはさまざまな方法がありますが、たとえば以下のようなシンプルなやり方もあります。

本番環境のDBをダンプファイル（SQL形式）で取得する
別の安全な場所に保管しておく
不測の事態があったら、ダンプファイルから復元する

テーブル変更が頻繁にある場合は、定期的なバックアップの自動実行を検討してもよいでしょう。
多少手間がかかっても、失敗したときのリスクに比べれば安全対策に時間をかける価値は十分にあります。

テスト環境での確認

マイグレーションの変更は、本番に適用する前にテスト環境やステージング環境で実行してみるのが基本です。
しっかり動くことを確認してから本番環境に反映すれば、万一のトラブルを回避できます。

特に注意が必要なのは、テーブルの変更によって既存のアプリケーションコードに不整合が出る場合です。
たとえば、削除したカラムをアプリのどこかがまだ参照しているケースなどで、不具合が発生する可能性があります。
そういった不備がないことをテストで確かめるためにも、テスト環境での動作確認は欠かせません。

よくあるエラーとトラブルシューティング

マイグレーション実行時のエラー

マイグレーションを実行した際に、次のようなエラーが発生することがあります。

すでに存在するカラムを再度追加しようとした
存在しないカラムを削除しようとした
データ型変更が不正な型への変更だった

こうしたエラーは、どのマイグレーションが原因かを特定しやすいようにファイル名やクラス名を注意深く確認するのが大切です。
もし同じような名前のマイグレーションを何度も作っていると、「どれが新しくてどれが古いのか分からなくなる」場合があります。
ファイル名の先頭に日付や通し番号が自動で付く仕組みがRailsにはありますが、マイグレーション名自体も分かりやすくしておきましょう。

rollbackがうまくいかない

マイグレーションを実行したあとに、「やっぱり元に戻したい」ということでrails db:rollbackを使うときがあるかもしれません。
しかし、すべての変更を自動的に戻せるとは限りません。
カラム削除などは特にデータを消し去ってしまう操作なので、rollbackしても消えてしまったデータを復活させられないケースもあります。

また、downメソッドに対応する処理が定義されていない場合や、changeメソッドの中でRailsが逆操作を推定できない場合などは、rollbackが正常に動作しません。
このような状況を避けたい場合は、カラムを追加するときにはupメソッド・downメソッドを明示的に記述して「追加されたカラムを削除する」操作を書いておくなど、両方向のマイグレーションを意識しておくと安心です。

デプロイ時にテーブル定義が食い違う

チーム開発では、複数の開発者が並行して作業していると、誰かが先にマイグレーションを本番環境にデプロイしてしまって、別の人が違うマイグレーションを適用しようとするとエラーになる場合があります。
そのため、デプロイ前にマイグレーションの整合性を確認することが必要です。

たとえば、Gitでマイグレーションファイルをプルしないまま作業をしてしまうと、自分が書いたマイグレーションファイルが既存の変更と競合するかもしれません。
デプロイ前に最新のリモートリポジトリを取り込んで、ローカルでテストを走らせ、問題ないことを確認してからリリースするようにしましょう。

マイグレーション同士が衝突すると、アプリが想定外の動きをする可能性があります。特に同じテーブルに対して異なる変更を加える場合には、衝突を防ぐためにチーム内で相談してから作業を進めましょう。

マイグレーションで押さえておきたい追加の要素

インデックスの設定

テーブルのカラムにインデックスを張ることで、検索速度を大幅に向上させられます。
マイグレーションでインデックスを追加するには、add_index :テーブル名, :カラム名 のように書きます。
何度も検索されるカラムや、JOINに使われるカラムにはインデックスをつけるのが一般的です。

ただし、インデックスが増えると書き込みの速度が下がる場合もあるので、どのカラムにインデックスを張るかは事前に検討したほうがいいでしょう。
これも実務でよくある調整ポイントのひとつです。

外部キー制約の設定

アプリで異なるテーブルのデータを関連づけるときは、マイグレーションで外部キー制約を定義することがよくあります。
外部キー制約をかけることで、関連するデータが正しく紐づくかをデータベース側で保護できます。

Railsの場合、外部キー制約を設定するには add_foreign_key :子テーブル, :親テーブル のように書きます。
これにより、子テーブルに存在しない親のIDが入力されるとエラーになりますし、親のレコードを消そうとしたときに子テーブル側のデータをどう扱うか（削除もしくは保持）を決めることもできます。

マイグレーションのバージョン管理

Railsのマイグレーションファイルには、作成日時が自動で付与されており、Railsはそれをもとに適用順を管理しています。
複数人で作業をしていると、マイグレーションファイルがたくさん増えますが、ファイルごとに何をしているかを明確に書いておけば混乱を避けやすくなります。

たとえばクラス名を「AddEmailToUsers」や「ChangeColumnTypeInOrders」のようにして、ファイル名にも同じようなラベルをつけておくのが一般的です。
これによって、レビューやトラブルシューティングの際にもどのファイルを見ればよいかすぐに分かります。

マイグレーションを安全に運用するためのヒント

小さな変更を積み重ねる

実務では、データベースの変更が大きくなりがちです。
しかし、大きな変更を一気に行うのはリスクも高く、エラーが起きたときの範囲が広がります。
そこで小さな変更に分割して、ひとつずつマイグレーションを作成・適用するのがおすすめです。

小さく区切ることで「この変更が原因でどのような不具合が起きたか」を把握しやすくなりますし、途中でキャンセルしなければならないときも対処が楽になります。

事前にデータ移行をシミュレーション

カラム名や型を変更する際、そのカラムに入っている既存データがどうなるのかを考える必要があります。
データ型が変わった結果、正しく読み込めなくなるものがあるかもしれません。
こうした場合には、マイグレーションを実行する前にテスト環境などで十分にシミュレーションするのが安心です。

特に大きなアプリでは、データ量が膨大になるほどマイグレーションの実行時間も長引く可能性があります。
事前に本番と同じようなデータ量を用意して、どのぐらい時間がかかるか測定しておくと、サービスへの影響を最小限に抑えることができるでしょう。

Railsコンソールなどでの動作確認

変更後のテーブルをRailsコンソールで開き、カラムがきちんと追加・変更されているかを確かめるのも手軽です。
rails c を実行して User.columns.map(&:name) のように入力すれば、users テーブルのカラム一覧を見ることができます。
実際にレコードを保存してみて、問題なく動くかどうかをチェックするのも大切です。

もし何らかの理由で間違ったマイグレーションを本番環境に適用してしまったら、一度落ち着いて「どの操作がどこで間違っていたか」を確かめましょう。焦って誤った修正を重ねると、データを壊すリスクが増します。

マイグレーションの実行コマンドの活用

rails db:migrate:status

マイグレーションの状況を確認するときは、rails db:migrate:status コマンドが便利です。
実行すると、どのマイグレーションが適用済みか、まだ適用していないか、といったステータスを一覧で表示してくれます。

複数人で開発しているときは、マイグレーションの漏れがないかをチェックするために活用することが多いです。
「あるはずのマイグレーションが実行されていない」というのはよくあるミスなので、気づいたら rails db:migrate:status で確認してみましょう。

rails db:rollback

前述の通り、最新のマイグレーションを取り消すコマンドです。
ただし、変更内容によっては取り消せないケースもあるので、安易に頼らず慎重に使うのが望ましいところです。
特に本番環境でrollbackを行うのはリスクが高いため、基本はテスト環境で発生する作業だと考えておきましょう。

rails db:seed との違い

Railsでは rails db:seed コマンドで、テーブルに初期データを投入する仕組みがあります。
マイグレーションは「テーブル構造そのものを変える」行為ですが、db:seed は「テーブルに入れるデータを整備する」作業です。
テーブルの定義変更とデータ入力はセットで考えられることも多いですが、目的が異なることは覚えておきましょう。

マイグレーションの設計時に気をつけたいこと

ダウンタイムの最小化

大規模なテーブル変更をするとき、メンテナンスが長引けばサービスを停止しなくてはいけない場合があります。
これをダウンタイムと呼ぶことがありますが、できるだけ短くする、またはゼロにする工夫が求められます。

Railsでは、特に大きなテーブルに対する変更では、インデックスの追加や削除にも時間がかかる可能性が高いです。
必要に応じて、オンラインマイグレーションの手法を検討したり、アプリ側で事前にカラム追加だけをしておいてあとからデータ移行、最終的に古いカラムを削除するといった段階的な方法を取ったりする場合があります。

大きな変更をするときのステップ

たとえば、カラム名変更に伴ってデータ移行が必要なときに、一気にやってしまうのではなく、以下のステップに分割する手法がよく用いられます。

新カラムを追加
アプリコードを修正して、新カラムにデータを書き込むようにする
運用を続けながら、新カラムにデータがたまるのを待つ
古いカラムから新カラムへデータを移行するマイグレーションを実行
アプリコードを再修正し、古いカラムを参照しないようにする
古いカラムを削除

こうすると、サービスを長時間止める必要がなく、万一のときに古いカラムにもまだデータが残っているため、復旧もしやすくなります。

実務でありがちなパターンと対策

テーブルを大きく作りすぎる

アプリケーション設計の初期段階で、何でもかんでも1つのテーブルに詰め込んでしまい、後から分割したくなるケースがあります。
この場合も、マイグレーションで新しいテーブルを作ってデータを移動し、不要になったカラムを削除するといった流れを組むことになります。
移動には少し手間がかかりますが、データベースの正規化を進め、パフォーマンスと保守性を高めるメリットは大きいです。

重複データが発生していた

新しいカラムに移行する途中で、重複データが入り込んでしまう場合があります。
このときは、一度データを整理するためのスクリプトを用意して、可能な限り重複を排除してからマイグレーションを行うほうがスムーズです。
とくにユニーク制約をつけるときは、重複データがあるとマイグレーション自体が失敗する可能性がありますので、事前のチェックが大切です。

大量のデータ移行に時間がかかる

大量のデータを扱うサービスだと、テーブル更新に時間がかかり、その間ユーザーが操作できない事態も考えられます。
対策として、データを小分けに移行するスクリプトを組むか、バックグラウンド処理で順次移行していくなど、リアルタイムの移行を考えることがあります。
マイグレーションファイルにすべてを書いてしまうと大きすぎる変更になりがちなので、運用の工夫で乗り切るケースも珍しくありません。

テーブル変更後のデータ確認と保守

システム全体の動作確認

カラムを追加・削除・変更したら、アプリ全体が想定通り動くかを改めてチェックする必要があります。
APIの返り値が変わっていないか、画面にエラーが出ていないか、ログが異常を示していないかなどを確認しましょう。
テストコードが整備されていれば、テストを回すだけでもある程度は安心できますが、UI周りなども合わせてチェックすると確実です。

運用開始後にバグが出たら？

もしデプロイした直後にバグが見つかった場合、ダウンメンテナンスなどを視野に入れて対応することもあります。
ただし、すでにデータが新しいカラムに書き込まれている可能性があるので、そうしたデータをどう扱うかを慎重に検討しなければなりません。
だからこそ、大きな変更を行う際は事前準備が欠かせないわけです。

バージョン管理リポジトリとの連携

マイグレーションファイルもアプリケーションコードの一部として、通常はGitなどでバージョン管理します。
このときに、マイグレーションと関連するアプリのコード変更はできるだけ同じコミットまたは同じプルリクエストで扱ったほうが、後で見返したときに理解しやすいです。
「このマイグレーションはどの機能と対応していたか」をすぐに追えるようになるため、保守性が高まります。

まとめ

Railsのマイグレーションは、テーブル構造の変更を安全かつ効率的に行うための機能です。
コードで変更内容を定義し、コンソールコマンドで実行する流れは、一見複雑に思えるかもしれませんが、慣れてしまえばデータベース管理が格段に楽になります。

初心者の方がテーブル変更をするときには、とにかく小さな変更をこまめにマイグレーションに落とし込むことがポイントです。
大きな変更を一気にやるとトラブルが発生した際の切り分けが難しくなりますし、最悪データを壊してしまうリスクもあるため、慎重なステップが求められます。

実務では、チーム内でマイグレーションファイルの管理やレビューを行いつつ、テスト環境やステージング環境で検証し、問題なければ本番に適用する流れが基本です。
ぜひ今回の解説をヒントに、Railsでテーブル構造を変更するときの全体的なイメージをつかんでみてください。

小さな一歩を積み重ね、必要に応じてバックアップやテストをしっかり実施しながら、マイグレーションを使いこなしていきましょう。
そうすれば、今後の機能追加や改修で困ることが大幅に減り、柔軟なアプリ開発が実現できますよ。