第11回「Rails基礎力を固める模擬問題で学ぶ試験対策」バリデーション

2026年8月3日

みなさん、こんにちは。

前回は、Active Recordの基礎として、モデルとテーブルの対応や、レコードの作成、取得、更新、削除を確認しました。今回は、そのモデルに書く代表的なルールである「バリデーション」を扱います。

バリデーションは、データを保存する前に、入力内容がアプリケーションとして正しいかを確認する仕組みです。試験では、presence、length、uniqueness などの基本的な使い方や、保存に失敗したときの errors の扱いが問われやすいところです。実務でも、バリデーションはとても重要です。ユーザーの入力ミスを防ぐだけでなく、データを一貫した状態に保つ役割があります。単に「空欄を禁止する書き方」として覚えるのではなく、なぜモデルにルールを書くのかを意識しながら見ていきましょう。

バリデーションの基本

Railsでは、モデルに validates を書くことでバリデーションを定義します。たとえば Article モデルで、タイトルと本文を必須にする場合は次のように書きます。

class Article < ApplicationRecord
validates :title, presence: true
validates :body, presence: true
end

presence: true は、その属性が空ではないことを確認します。フォームから空の title が送られてきた場合、@article.save は false を返し、データベースには保存されません。ここで大切なのは、バリデーションが「保存前の確認」であるという点です。new でオブジェクトを作っただけでは、まだ保存は行われません。save や create、update のように保存しようとしたタイミングで、Railsが確認を行います。

valid? と errors

バリデーションの結果は、valid? メソッドで確認できます。valid? は、オブジェクトが保存できる状態なら true を返し、問題があれば false を返します。

article = Article.new(title: “”, body: “本文です”)

article.valid?
article.errors.full_messages

valid? を呼ぶと、バリデーションが実行されます。問題があった場合は、errors にエラー情報が入ります。前々回のフォーム回で扱った errors.full_messages は、この errors から人間が読みやすいメッセージを取り出すためのものです。モデルが入力内容を検証し、コントローラが保存の成否を判断し、ビューがエラーを表示します。この流れを理解しておくと、試験問題でも迷いにくくなります。

よく使うバリデーション

Railsには、よく使うバリデーションがあらかじめ用意されています。代表的なものをコードで見てみましょう。

class User < ApplicationRecord
   validates :name, presence: true, length: { maximum: 30 }
   validates :email, presence: true, uniqueness: true
   validates :age, numericality: { only_integer: true, greater_than_or_equal_to: 0 }
end

length は文字数を確認します。maximum を指定すれば、長すぎる入力を防げます。numericality は数値であることを確認します。only_integer: true を付けると、整数だけを許可できます。uniqueness は、同じ値がすでに存在しないかを確認します。メールアドレスのように、重複してほしくない属性でよく使います。ただし、実務では uniqueness だけに頼りきらず、データベース側の一意制約も組み合わせた方がよいでしょう。

条件付きバリデーション

すべての場面で同じルールを使うとは限りません。たとえば、公開する記事だけ published_at を必須にしたい場合は、if や unless で条件を付けられます。

class Article < ApplicationRecord
   validates :published_at, presence: true, if: :published?

   def published?
       status == “published”
   end
end

この例では、published? が true のときだけ published_at の presence が確認されます。下書きの記事であれば、公開日時がなくてもエラーにはなりません。条件付きバリデーションは便利ですが、条件が複雑になるとモデルが読みづらくなります。どの状態のときに、どの入力が必要なのかを先に整理してから書きましょう。

モデルに書く意味

入力チェックは、ビューやコントローラでも書けそうに見えます。しかし、Railsでは基本的にモデルに書きます。理由は、そのルールがデータ自身に関するものだからです。たとえば「記事のタイトルは必須」というルールは、新規作成画面だけの都合ではありません。編集画面でも、管理画面でも守られるべきルールです。モデルに書いておけば、どの経路から保存しても同じ確認が行われます。同じルールを複数の画面に書くと、あとから変更するときに漏れが起きやすくなります。試験対策としても、実務の設計としても、バリデーションはモデルの責務だと押さえておきましょう。

模擬問題

問題1

次のうち、title が空でないことを確認するバリデーションとして最も適切なものを1つ選びなさい。

1. validates :title, blank: false

2. validates :title, presence: true

3. validate :title, required: true

4. validates_presence title

正解：
2

解説：
Railsで値が存在することを確認する代表的な書き方は validates :title, presence: true です。1はRails標準の書き方ではありません。3は validates ではなく validate になっています。4もRails 7.1で使う基本形ではありません。

問題2

バリデーションに失敗した場合の説明として最も適切なものを1つ選びなさい。

1. save は false を返し、errors にエラー情報が入る

2. save は必ず true を返し、エラーはビューで判定する

3. new を呼んだだけで自動的にデータベースへ保存される

4. errors.full_messages はルーティング情報を返す

正解：
1

解説：
バリデーションに失敗すると、通常 save は false を返し、errors にエラー情報が入ります。ビューでは、その errors を表示します。2はビューに判定を置いています。3は new と保存を混同しています。4の errors.full_messages は、エラーメッセージの配列を返すメソッドです。

問題3

メールアドレスの重複を確実に防ぎたい場合の設計として、最も適切なものを1つ選びなさい。

1. uniqueness バリデーションだけを書けば、実務上も常に十分である

2. ビューで同じメールアドレスがないかを確認すればよい

3. モデルの uniqueness バリデーションに加えて、データベース側にも一意制約を付ける

4. コントローラで文字列を比較し、重複していれば redirect_to する

正解：
3

解説：
uniqueness バリデーションは、分かりやすいエラーを返すために役立ちます。ただし、同時に処理が走る場合を考えると、アプリケーション側の確認だけでは十分でないことがあります。重複を確実に防ぎたい場合は、データベース側の一意制約も組み合わせます。2と4は責務の置き場所としても不十分です。

まとめ

今回は、Active Recordモデルに書くバリデーションについて整理しました。バリデーションは、保存前に入力内容を確認し、正しいデータだけを保存するための仕組みです。試験では、presence、length、numericality、uniqueness といった基本的なバリデーションを押さえておきましょう。あわせて、valid?、save、errors.full_messages の関係も重要です。保存失敗時にモデルへエラー情報が入り、それをフォーム画面で表示する流れまで理解しておくと安心です。また実務では、バリデーションをモデルに書くことで、どの画面や処理から保存しても同じルールを守れます。また、uniqueness のように、データベース側の制約と組み合わせて考える場面もあります。

次回は、複数のモデルをつなぐアソシエーションを扱います。データ同士の関係をRailsではどのように表現するのかを見ていきましょう。