Railsのuniquenessバリデーション完全理解！初心者でも失敗しない正解パターン（スコープ・大文字小文字・DB制約）

1. uniquenessバリデーションとは？

1. uniquenessバリデーションとは？

Railsのuniquenessバリデーションは、「同じ値がデータベースに存在しないこと」を確認する仕組みです。 たとえば、ユーザー登録で同じメールアドレスが二回使われないようにする、といった場面で使われます。

プログラミング未経験の方は、「受付名簿で同じ名前を二回書かせないチェック係」だと考えると分かりやすいです。 Railsでは、このチェック係をモデルに書くことで、自動的に確認してくれます。

2. 基本的なuniquenessの書き方

2. 基本的なuniquenessの書き方

まずは一番シンプルな書き方です。Userモデルでメールアドレスの重複を防ぐ例を見てみましょう。

class User < ApplicationRecord
  validates :email, uniqueness: true
end

この設定により、すでに存在するemailと同じ値を保存しようとすると、エラーになります。 ただし、この書き方には落とし穴があります。

3. scopeを使ったuniquenessの正しい考え方

3. scopeを使ったuniquenessの正しい考え方

scope（スコープ）とは、「どの範囲で重複をチェックするか」を指定するものです。 たとえば、「同じ会社の中だけで社員番号が重複しないようにしたい」場合があります。

class Employee < ApplicationRecord
  validates :employee_number, uniqueness: { scope: :company_id }
end

これは「company_idが同じ場合だけ、employee_numberは一意である」という意味です。 学校で例えると、「クラスが違えば出席番号が同じでもOK」という状態です。

scopeを使わないと、「全会社共通で重複不可」という意図しないルールになることがあるため、実務では非常によく使われます。

4. case_sensitiveで大文字・小文字の違いを理解する

4. case_sensitiveで大文字・小文字の違いを理解する

case_sensitiveは、「大文字と小文字を区別するかどうか」を指定するオプションです。 メールアドレスでは、通常は区別しない方が安全です。

class User < ApplicationRecord
  validates :email, uniqueness: { case_sensitive: false }
end

この設定をすると、「test@example.com」と「TEST@example.com」は同じものとして扱われます。 区別してしまうと、見た目がほぼ同じアカウントが複数作れてしまい、トラブルの原因になります。

5. uniquenessだけでは危険な理由

5. uniquenessだけでは危険な理由

ここが初心者の方が一番つまずきやすいポイントです。 uniquenessバリデーションは、アプリ側のチェックにすぎません。

同時に二人が同じデータを登録しようとした場合、チェックをすり抜けて保存される可能性があります。 これは「レジが一台しかなくて、同時に確認できない状態」に似ています。

そのため、本当に安全にするには、データベース側でも重複禁止を設定する必要があります。

6. DBユニークインデックスの設定方法

6. DBユニークインデックスの設定方法

ユニークインデックスとは、「この列は重複してはいけない」というルールをDBに直接設定する仕組みです。 Railsではマイグレーションで設定します。

class AddUniqueIndexToUsersEmail < ActiveRecord::Migration[7.0]
  def change
    add_index :users, :email, unique: true
  end
end

これにより、Railsのチェックをすり抜けても、DBが最後の砦として重複保存を防ぎます。 実務では「バリデーション＋DB制約」は必須の組み合わせです。

7. scope付きユニークインデックスの実例

7. scope付きユニークインデックスの実例

scopeを使ったuniquenessの場合、DB側も同じ条件で制約をかける必要があります。

class AddUniqueIndexToEmployees < ActiveRecord::Migration[7.0]
  def change
    add_index :employees, [:company_id, :employee_number], unique: true
  end
end

これで「同じ会社内では社員番号が重複しない」ことが、RailsとDBの両方で保証されます。

8. before_*コールバックと組み合わせる考え方

8. before_*コールバックと組み合わせる考え方

before_validationなどのコールバックを使うと、バリデーション前に値を整えることができます。 たとえば、メールアドレスをすべて小文字に統一する場合です。

class User < ApplicationRecord
  before_validation :downcase_email
  validates :email, uniqueness: { case_sensitive: false }

  private

  def downcase_email
    self.email = email.downcase if email.present?
  end
end

これにより、入力の揺れを減らし、uniquenessが正しく機能するようになります。 初心者の方は「事前に形をそろえてからチェックする」と覚えると理解しやすいです。