Railsマイグレーション完全保存版｜change・up・down・reversibleで安全にスキーマ変更する方法

1. マイグレーションにおける「安全」とは何か

1. マイグレーションにおける「安全」とは何か

Railsのマイグレーションで大切なのは、 元に戻せることです。 テーブルやカラムの変更は、 一度失敗するとデータが壊れる可能性があります。

例えるなら、部屋の模様替えです。 家具を動かしても、 元の位置に戻せるなら安心ですよね。 マイグレーションも同じで、 「戻せる設計」が安全なスキーマ変更につながります。

2. changeメソッドとは？一番よく使われる基本形

2. changeメソッドとは？一番よく使われる基本形

changeは、 Railsが自動で「元に戻す方法」を 判断できる場合に使える書き方です。 初心者が最初に覚えるのは、このchangeです。

class AddAgeToUsers < ActiveRecord::Migration[7.0]
  def change
    add_column :users, :age, :integer
  end
end

この場合、 カラムを追加する操作は Railsが自動で「削除」に戻せるため、 changeだけで問題ありません。

3. changeが使えないケースがある理由

3. changeが使えないケースがある理由

すべての変更が、 自動で元に戻せるわけではありません。 データの変換や複雑な操作は、 Railsが判断できない場合があります。

これは料理で言うと、 「材料を切る」だけなら元に戻せませんよね。 そういった場合は、 手動で戻し方を書く必要があります。

4. upとdownとは？戻り道を自分で書く方法

4. upとdownとは？戻り道を自分で書く方法

upとdownは、 「進む処理」と「戻る処理」を 明示的に書く方法です。 Railsに任せず、 開発者が責任を持って定義します。

class ChangePriceType < ActiveRecord::Migration[7.0]
  def up
    change_column :products, :price, :integer
  end

  def down
    change_column :products, :price, :string
  end
end

upが「前に進む道」、 downが「元に戻る道」です。 一本道ではなく、 必ず往復できる道を用意する意識が重要です。

5. up/downが必要になる典型的な場面

5. up/downが必要になる典型的な場面

カラムの型変更、 データの一括変換、 SQLを直接書く場合などは、 changeでは不十分なことがあります。

初心者のうちは、 「changeで書けないと感じたらup/down」 と覚えておくと混乱しません。

6. reversibleとは？changeの中で分岐させる書き方

6. reversibleとは？changeの中で分岐させる書き方

reversibleは、 changeメソッドの中で upとdownの動きを分けたいときに使います。 一つのメソッド内で、 進む処理と戻る処理を書けます。

def change
  reversible do |dir|
    dir.up do
      execute "UPDATE users SET name = 'unknown' WHERE name IS NULL"
    end

    dir.down do
      execute "UPDATE users SET name = NULL WHERE name = 'unknown'"
    end
  end
end

reversibleは、 一本道に見えるchangeの中に、 分かれ道を作るイメージです。

7. change・up/down・reversibleの使い分け

7. change・up/down・reversibleの使い分け

使い分けの基本はとてもシンプルです。 自動で戻せるならchange、 戻し方を自分で決めたいならup/down、 changeの中で分けたいならreversible。

最初から完璧を目指す必要はありません。 「安全に戻せるか？」を考える習慣が、 マイグレーション設計の第一歩です。

8. 初心者が意識すべき安全なスキーマ変更の考え方

8. 初心者が意識すべき安全なスキーマ変更の考え方

マイグレーションは、 チーム全員で共有する履歴です。 自分だけでなく、 将来の自分や他の人が 安心して実行できることが大切です。

change・up・down・reversibleを理解すると、 スキーマ変更は怖い作業ではなくなります。 「戻れる設計」を意識することが、 Rails開発を長く支える基礎になります。