第13回「Rails基礎力を固める模擬問題で学ぶ試験対策」マイグレーション

2026年10月1日

みなさん、こんにちは。

前回は、モデル同士の関係を表すアソシエーションについて学びました。アソシエーションを正しく動かすには、articles テーブルに user_id を用意するなど、データベース側にも必要な構造がなければなりません。そこで今回は、テーブルやカラムを作成・変更するための「マイグレーション」を取り上げます。

試験では、マイグレーションファイルの役割、change メソッド、db:migrate や db:rollback といったコマンドがよく問われます。書き方だけを覚えるのではなく、変更を履歴として残し、開発者同士で同じ状態を再現する仕組みだと理解しておきましょう。

マイグレーションとは何か

マイグレーションは、データベースの構造変更をコードで管理する仕組みです。テーブルの作成やカラムの追加など、変更の手順をRubyで記述します。そのコードを保存するのがマイグレーションファイルです。ファイルは db/migrate ディレクトリに保存され、Railsはファイル名の先頭に付く日時の数字を使って実行順を判断します。

たとえば、articles テーブルに公開状態を表す published カラムを追加する場合、次のコマンドでマイグレーションファイルを生成できます。

bin/rails generate migration AddPublishedToArticles published:boolean

生成されたファイルには、次のようなクラスが作られます。クラス名の後ろにある [7.1] は、そのマイグレーションがRails 7.1の仕様を前提としていることを表します。

class AddPublishedToArticles < ActiveRecord::Migration[7.1]
  def change
    add_column :articles, :published, :boolean
  end
end

changeメソッドと変更内容

change メソッドの中には、データベースに対して行いたい変更を書きます。add_column の第1引数はテーブル名、第2引数はカラム名、第3引数はデータ型です。この例では、articles テーブルに boolean 型の published カラムを追加しています。新しいテーブルには create_table、カラムの削除には remove_column、索引の追加には add_index を使います。アソシエーションで使う外部キーには、add_reference もよく使われます。

add_reference :articles, :user, null: false, foreign_key: true

この記述では、通常は articles テーブルに user_id カラムとインデックスが追加され、foreign_key: true によって外部キー制約も設定されます。前回学んだ belongs_to :user はモデル上の関係を表し、マイグレーションは、その関係を保存する構造を用意します。両方が合って初めて意図した関係として動きます。

マイグレーションを実行する

ファイルを作成しただけでは、データベースはまだ変更されません。未実行のマイグレーションを反映するには、次のコマンドを実行します。

bin/rails db:migrate

Railsは schema_migrations という内部テーブルを使い、実行済みのマイグレーションを管理します。同じコマンドを実行しても、反映済みのファイルは再実行されません。状態の確認には bin/rails db:migrate:status を使います。 db:migrate が完了すると、通常は db/schema.rb も更新されます。schema.rb は、現在のデータベース構造をまとめたスナップショットです。個々の変更の経緯はマイグレーションファイルに残り、現在の完成形は schema.rb で確認できます。この2つを同じものだと考えないことが大切です。

ロールバックと元に戻せる変更

直前のマイグレーションを取り消したいときは、次のコマンドを使います。

bin/rails db:rollback

change メソッドに add_column や create_table などの変更を書いている場合、Railsは多くの操作について逆向きの処理を判断できます。add_column を取り消すならカラムを削除し、create_table を取り消すならテーブルを削除する、という具合です。これを可逆な変更といいます。

マイグレーションでのメソッドは、変更を取り消すときの処理まで考えて選びましょう。カラムを追加する場合は、そのカラムを削除すれば構造を元に戻せます。このように、変更内容から取り消す操作が決まり、Railsがその逆操作に対応している場合は、change メソッドを使います。適用する処理と取り消す処理を重複して書かずに済むため、通常はこちらを使います。

一方、取り消すための情報や手順を別に指定する必要がある場合は、up メソッドと down メソッドを使います。たとえば、カラムの型を string から text に変更する場合、変更後の型を指定するだけでは、元の型が何だったかは分かりません。そこで、change の代わりに up に text 型へ変更する処理を、down に string 型へ戻す処理を書きます。

つまり、変更と取り消しを一つの記述で表せる場合は change、それぞれの処理を明示する必要がある場合は up と down を使います。change の中で一部の処理だけ適用時と取り消し時に分けたい場合には、reversible を使う方法もあります。

実行済みファイルを安易に書き換えない

実務で特に注意したいのは、チームで共有済み、または本番環境で適用済みのマイグレーションファイルを直接書き換えないことです。ほかの開発者の環境や本番環境では、そのファイルに書かれた変更がすでにデータベースへ反映されている可能性があります。

Railsは実行済みのマイグレーションを管理しているため、ファイルを書き換えても、db:migrate でその変更を再び適用することはありません。その結果、修正前の内容を適用した環境と、修正後の内容を初めて適用する環境で、データベースの構造に違いが生じてしまいます。

自分の環境でしか使っていないファイルなら、ロールバックして修正する方法もあります。しかし、チームで共有した変更を直すときは、原則として新しいマイグレーションを追加します。マイグレーションは変更の履歴でもあるからです。

また、大量のデータが入ったテーブルへの変更は、実行時間やロックの影響も考える必要があります。試験ではまず基本構文を押さえれば十分ですが、実務では「コマンドが成功するか」だけでなく、「運用中のデータを安全に変更できるか」まで考えることが重要です。

模擬問題

問題1

未実行のマイグレーションをデータベースに反映するコマンドとして、最も適切なものを1つ選びなさい。

1. bin/rails db:migrate
2. bin/rails db:rollback
3. bin/rails routes
4. bin/rails server

正解：1

解説：
bin/rails db:migrate は、まだ実行されていないマイグレーションを順番に反映します。2は直前の変更を取り消すコマンドです。3はルーティングの一覧を確認するコマンド、4は開発用サーバーを起動するコマンドなので、データベース構造の変更には使いません。

問題2

db/schema.rbの説明として、最も適切なものを1つ選びなさい。

1. コントローラの処理を記録するファイルである
2. 現在のデータベース構造を表すスナップショットである
3. すべてのモデルのバリデーションを定義するファイルである
4. 実行済みマイグレーションの代わりに毎回手作業で編集するファイルである

正解：2

解説：
schema.rb は、現在のデータベース構造をまとめたファイルです。1はコントローラの役割と混同しています。3のバリデーションは通常モデルに書きます。4も誤りです。schema.rb は通常、マイグレーションの実行に伴って更新されるため、構造変更の手順として直接編集するものではありません。

問題3

本番環境ですでに実行されたマイグレーションの内容に誤りが見つかりました。Railsらしい対応として、最も適切なものを1つ選びなさい。

1. 元のファイルだけを書き換え、再度 db:migrate を実行する
2. 本番データベースを削除し、最初から作り直す
3. 必要な修正を行う新しいマイグレーションを追加する
4. schema.rb だけを書き換え、データベースには何もしない

正解：3

解説：
実行済みの変更を修正するときは、新しいマイグレーションを追加するのが基本です。1では、Railsが実行済みと判断するため変更が反映されず、環境差の原因になります。2は本番データを失う危険があります。4では実際のデータベース構造が変わりません。変更手順をコードとして共有し、どの環境でも同じ順序で反映できる状態を保ちます。

まとめ

今回は、マイグレーションの役割と基本的な使い方を確認しました。マイグレーションは、テーブルやカラムなどの構造変更をコードで管理する仕組みです。変更の手順をマイグレーションファイルに残すことで、データベースがどのように変わってきたかをたどれます。

試験では、change メソッドに変更内容を書くこと、bin/rails db:migrate で反映すること、bin/rails db:rollback で直前の変更を戻せることを押さえておきましょう。また、db/schema.rb は現在の構造を表すスナップショットです。マイグレーションファイルとの役割の違いも重要です。

実務では、実行済みファイルを安易に書き換えず、新しいマイグレーションで修正を積み重ねます。そうすることで、チームの開発環境や本番環境に同じ変更を安全に届けやすくなります。次回は、作成したテーブルから必要なデータを取り出すActive Recordクエリを扱います。